From nobody Sun Dec 24 00:43:06 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SyMhh1BTdz55F6m for ; Sun, 24 Dec 2023 00:43:16 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4SyMhg0LFbz3MdG for ; Sun, 24 Dec 2023 00:43:14 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=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; dmarc=none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 3BO0h7aC017910 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sat, 23 Dec 2023 16:43:07 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 3BO0h634017909 for freebsd-arm@freebsd.org; Sat, 23 Dec 2023 16:43:06 -0800 (PST) (envelope-from fbsd) Date: Sat, 23 Dec 2023 16:43:06 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Subject: USB-serial adapter suggestions needed Message-ID: List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spamd-Result: default: False [-1.09 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.987]; MID_RHS_WWW(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; DMARC_NA(0.00)[zefox.net]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_TLS_LAST(0.00)[] X-Rspamd-Queue-Id: 4SyMhg0LFbz3MdG X-Spamd-Bar: - What are the best-supported usb-serial adapters for use with FreeBSD on arm systems? I'm specifically interested in Raspberryp Pi 2/3/4 (and maybe 5 someday). I've been using pl2303 and ft232 but wonder if there might be others worth considering. Pl2303 are cheap and have lately been working fairly well, but if there's something better supported or behaved I'd like to know. Thanks for reading, bob prohaska From nobody Sun Dec 24 00:47:56 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SyMpG5B5Mz55DxR for ; Sun, 24 Dec 2023 00:48:06 +0000 (UTC) (envelope-from saper@saper.info) Received: from q.saper.info (q.saper.info [IPv6:2605:2700:0:2:a800:ff:fec7:5c61]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "q.saper.info", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SyMpG2WLpz3N7T for ; Sun, 24 Dec 2023 00:48:06 +0000 (UTC) (envelope-from saper@saper.info) Authentication-Results: mx1.freebsd.org; none Received: from q.saper.info (localhost [127.0.0.1]) by q.saper.info (8.17.1/8.17.1) with ESMTPS id 3BO0luHm022378 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 24 Dec 2023 00:47:56 GMT (envelope-from saper@saper.info) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=saper.info; s=Sep2014; t=1703378876; bh=Xo4hUZS05a6ro8dMWK1i63l99F+a2tg1vWnmX3YhQY8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=gStCbeo1qk0MC0R5mI4XgNEOLR7CueF+9bZ+aXIgm6x9Z8zIrPb7y2hzW4Qv+TUjx 3GSsNpSC69raEZ/8CB11yoUauSmEkRwwiIseqdaoRvcL5wMo3Na4D9E/5xy0WYF/81 e4XLjP7+BEYDGpgzLvaPPYW1SHYLfmBoEpZ4S+S4= Received: from localhost (saper@localhost) by q.saper.info (8.17.1/8.17.1/Submit) with ESMTP id 3BO0lu54022375; Sun, 24 Dec 2023 00:47:56 GMT (envelope-from saper@saper.info) X-Authentication-Warning: q.saper.info: saper owned process doing -bs Date: Sun, 24 Dec 2023 00:47:56 +0000 From: Marcin Cieslak To: bob prohaska cc: freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed In-Reply-To: Message-ID: References: List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="2201072851-1499498499-1703378876=:2993" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:47066, ipnet:2605:2700::/32, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SyMpG2WLpz3N7T --2201072851-1499498499-1703378876=:2993 Content-Type: text/plain; format=flowed; charset=US-ASCII On Sat, 23 Dec 2023, bob prohaska wrote: > What are the best-supported usb-serial adapters for use with FreeBSD on arm systems? I am using uchcom(4)-based CH340, the reason I have it is selectable 3.3V/5V level. I don't have a Raspberry but I use it for other arm boards. Not sure it is "better" than, say ft232 Marcin --2201072851-1499498499-1703378876=:2993 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIOdgYJKoZIhvcNAQcCoIIOZzCCDmMCAQExDzANBglghkgBZQMEAgEFADAL BgkqhkiG9w0BBwGgggq9MIIEvDCCA6SgAwIBAgIQeEqpEhjRpCYIUTzTZlVD ozANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQLExdHbG9iYWxTaWduIFJvb3Qg Q0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMKR2xvYmFs U2lnbjAeFw0yMDA5MTYwMDAwMDBaFw0yOTAzMTgwMDAwMDBaMFsxCzAJBgNV BAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTEwLwYDVQQDEyhH bG9iYWxTaWduIEdDQyBSMyBQZXJzb25hbFNpZ24gMSBDQSAyMDIwMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvxvJBqEapaux2/z3J7fFslRO WjKVJ5rCMfWGsg17dmD7NSnG7Spoa8d3htXsls1IMxoO8PyouQajNQqYmlYo xinlqenMNv7CJyEKMOAtglBmD6C/QC7kT+dSx4HfSTs8xmv8veJOldMzF8S/ BEn/tD4w/Dvpg+oXOqDyOiHPTacRFK0QHoq5eEbBmVS8W0rwcaRotO9fGTA+ NjF0My7GLRNK0eMPGh2hcPZURQhXy7wRQ8XFIfEA6kaQHHN22ncnVtwqiTmA wTR+4GNNVinG3KjNZLAVSnGrdCvT2I4Zo19hKy5PX6o7wrVXvMR4zV5VBFwV 6ZDM+xewao7Mup+SbwIDAQABo4IBiTCCAYUwDgYDVR0PAQH/BAQDAgGGMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/ AgEAMB0GA1UdDgQWBBSFu/DMxDa1CmJ2o5kuj7s6aq3FUTAfBgNVHSMEGDAW gBSP8Et/qC5FJK5NUPpjmove4t0bvDB6BggrBgEFBQcBAQRuMGwwLQYIKwYB BQUHMAGGIWh0dHA6Ly9vY3NwLmdsb2JhbHNpZ24uY29tL3Jvb3RyMzA7Bggr BgEFBQcwAoYvaHR0cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQv cm9vdC1yMy5jcnQwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9i YWxzaWduLmNvbS9yb290LXIzLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIB KDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9y ZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEAWWtqju12g524FdD2HwUX U1rSxeM5aSU1cUC1V/xBjXW0IjA7/3/vG2cietPPP/g3lpoQePVJpQAKZml8 1fHwPPivFK9Ja41jJkgqGzkORSC0xYkh2gGeQg1JVaCzcrRzJElRjT442m6F pbLHCebxIHLu0WBNjLZreB6MYMaqdPL6ItbXtD/BU4k517cEuUbczoBFZAra jq7oUBWXuroln5AMnRwVNwgJN4Np0s4kkJ94KepzbFOLzcbnfUB0+xT4foXm bM0GmmcPGOy0qvqEHJsBwDZXDxIk8oqCnnLngi7N94Sn4eTcmpZ9NH2dDN1O TEPVXgRG5X1pBcNtMWG6MDCCBfkwggThoAMCAQICDCKqoJRMYYx5sYJHGzAN BgkqhkiG9w0BAQsFADBbMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFs U2lnbiBudi1zYTExMC8GA1UEAxMoR2xvYmFsU2lnbiBHQ0MgUjMgUGVyc29u YWxTaWduIDEgQ0EgMjAyMDAeFw0yMzAzMDcxNjExMDlaFw0yNjAzMDcxNjEx MDlaMDwxGTAXBgNVBAMMEHNhcGVyQHNhcGVyLmluZm8xHzAdBgkqhkiG9w0B CQEWEHNhcGVyQHNhcGVyLmluZm8wggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAw ggIKAoICAQC8MB3fTYVrTadH5qE2CIa4VLvlL6QHgDriMRLkTA49SPszYCO0 fZTEpdSw8fc6kK9p2fD63LAfOHeD7jzey5aHBzpIGlxeFkn0Ce2BCYY5yLxK i9byoCwrpLchTR1Itpk1w+zy5E4T9KBTL1+c+w+TKpaIvFLXtjZtz4wQGi0p e/nRkRK9htGG3mETh+APitedl+ImGaI8NK9PELxuSkXnYAvGPpnXir8vbszk tJU1b0TevL/i3Sy6fhOhunZmTo1QDM7Zw4UyVjkQgTvL3y4I0tIrVjlam08x XZeMp+i/Gl51eHGvRVfvdJUJAjrWhrFEp8+2FZouWxWzAlHdd2sRp1AekNdP CeRgHeIF6uNtSseL1grKAjU+4BiixWPp1y1niB0humoQHoub/6fO/mU+//rW l3gTwZNu4FuKgZlfPw+qnvuka0c9dUNIZRCE5z8yXjS8R9yZWirnHNhYxf/e R2y4jaiHzPAjZlZZ2rGx8xVfB2n2JsAicj2+ZxmXlQ1yd5RW1pfxG3cdNNC5 uZ+j4JIN2ElsIjEKmMn9gHdoaEMAy/ENwNiMDBadLnc8qWirq/Ktp2dBSf2y /sH9xMpVyk8wuYjpbCnX4xslAensno5A20MYdKGPRFaItEhNPNbfzc1+4br8 exoXFX1F9ZJK9gGUO2nLbdRycphdyzxzgQIDAQABo4IB2jCCAdYwDgYDVR0P AQH/BAQDAgWgMIGjBggrBgEFBQcBAQSBljCBkzBOBggrBgEFBQcwAoZCaHR0 cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvZ3NnY2NyM3BlcnNv bmFsc2lnbjFjYTIwMjAuY3J0MEEGCCsGAQUFBzABhjVodHRwOi8vb2NzcC5n bG9iYWxzaWduLmNvbS9nc2djY3IzcGVyc29uYWxzaWduMWNhMjAyMDBMBgNV HSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3 dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAJBgNVHRMEAjAAMEkGA1Ud HwRCMEAwPqA8oDqGOGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NnY2Ny M3BlcnNvbmFsc2lnbjFjYTIwMjAuY3JsMBsGA1UdEQQUMBKBEHNhcGVyQHNh cGVyLmluZm8wHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB8GA1Ud IwQYMBaAFIW78MzENrUKYnajmS6PuzpqrcVRMB0GA1UdDgQWBBTW/RrdlRFR y6MgS7liTThMnQA5ozANBgkqhkiG9w0BAQsFAAOCAQEAAwoUJShHMueocVlD 1+vYJbTTTbk9tabr2L4Iyyy4Btu1d1wwl6d9Yx2N9qaVERWcEeP0aR+NB2B7 xIKl/ZnZVuSxep0Raw4s284a/jSIJlsAi4SJItDCU2VrYJDWxP7MxzZHnzPI MLDoTHXPV18gvYTewoNk5/Yo89Kb0v/GpPTpP2sVdrWLHa4uKUHYrAZ0aByp kNw6lXp6o6DXvXaOd6KDTQN5XhmmHwLnuLceODF1t9gicsZIOY+KAxN6YZ6t EqwN48b4OFMpckDE3fm1iTZRqnEIqUHOKOcoCImkub1woEN0zXDQmLXaZigl uVztWSTM4/fapWLrlHBNxfjs1TGCA30wggN5AgEBMGswWzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExMTAvBgNVBAMTKEdsb2Jh bFNpZ24gR0NDIFIzIFBlcnNvbmFsU2lnbiAxIENBIDIwMjACDCKqoJRMYYx5 sYJHGzANBglghkgBZQMEAgEFAKCB5DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0yMzEyMjQwMDQ3NTZaMC8GCSqGSIb3DQEJ BDEiBCBzWtrZe/AdB4nPFIpBjqxvwXGvmjnuaS/3d3iKWzVD4TB5BgkqhkiG 9w0BCQ8xbDBqMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUD BAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAgAk hB2FTeVWuGLykIVTsMvXxsvUxmvOElZ6v/NgW7RConygUYuPCqArDlBBABk8 zc87vL7jQFGlaMAxjFkckLojbb1JkDqrm3pMcpYIzAVnBpEB1bRN6boWjLav fDD55QBXW8GDblsmQlx4g/k90awwixcZRJa0RkblAMjtmz7k5OLJWUrlRcR+ QcXrhJxtQrq5jDFvriRCUhPg8nDrj95Nml81brdEDg4TB/fBgWgg5Cz37i+3 em//OD5XFLINxS9+if1EcyQU+sEunekuKdkh63hwh0L5+XwEFrCy+y1ft3H8 nD3fMsvNxrLOLn89R1lUzsYThShdlzitlvICpSnLeSGKQP7anmixt0Z/QNR7 6C/ScrGyMq0Vs1Ilr08wPhxMW5WoWEjKhjKLcI2ZS5SyyHs39mNPXVaWL0CF 9ZGIu1gCcpBoFcGqWYRlZgDuYCluBO6N/qWfGdukJGOiXHZl1ZXRokl3Mz1r bEh3bmlQ+J8x1Yo89Kf5NDFT1Kicyd8QYvHGliNEOk6xJCR5aXB/rTcNHst+ OeWXR2Qjf2UIMH1xzp9HZ1vZeTH2RwBNzLEQzAPnPUy0utYgpyfDKdsnfN7I Ix+HRFx0uwX0av389jOSGoO+YfRzZDyH6p0M9V56Ugb8DNWl3SB87nYuQeCv nwVjQkTp5nfoXQD0YHC6dA== --2201072851-1499498499-1703378876=:2993-- From nobody Sun Dec 24 01:04:11 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SyN8t0k2zz55Fpk for ; Sun, 24 Dec 2023 01:04:14 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4SyN8s67yrz3PmT for ; Sun, 24 Dec 2023 01:04:13 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 3BO14C0B017978 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 23 Dec 2023 17:04:12 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 3BO14BSS017977; Sat, 23 Dec 2023 17:04:11 -0800 (PST) (envelope-from fbsd) Date: Sat, 23 Dec 2023 17:04:11 -0800 From: bob prohaska To: Marcin Cieslak Cc: freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed Message-ID: References: List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SyN8s67yrz3PmT On Sun, Dec 24, 2023 at 12:47:56AM +0000, Marcin Cieslak wrote: > On Sat, 23 Dec 2023, bob prohaska wrote: > > > What are the best-supported usb-serial adapters for use with FreeBSD on arm systems? > > I am using uchcom(4)-based CH340, the reason I have it is selectable 3.3V/5V level. > I don't have a Raspberry but I use it for other arm boards. > > Not sure it is "better" than, say ft232 Have you run into any oddities using the ch340? Noise on the lines, dropped connections, irreproducible behavior? Thanks for writing & confirming ch340 is an option! bob prohaska From nobody Sun Dec 24 01:21:40 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SyNY16rrXz55Gpj for ; Sun, 24 Dec 2023 01:21:41 +0000 (UTC) (envelope-from saper@saper.info) Received: from q.saper.info (q.saper.info [IPv6:2605:2700:0:2:a800:ff:fec7:5c61]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "q.saper.info", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SyNY15CX0z3RkJ for ; Sun, 24 Dec 2023 01:21:41 +0000 (UTC) (envelope-from saper@saper.info) Authentication-Results: mx1.freebsd.org; none Received: from q.saper.info (localhost [127.0.0.1]) by q.saper.info (8.17.1/8.17.1) with ESMTPS id 3BO1Leew023002 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 24 Dec 2023 01:21:40 GMT (envelope-from saper@saper.info) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=saper.info; s=Sep2014; t=1703380900; bh=idOhdOsUERlUnqtC3RukbdO7GU8BGTzfmr5nPk+/6Pg=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=EZ64TGSbNkZzvWQUX1C1XwbYgJVQGcZX2zNyrM27hhexld+wi7OG429fpwDxrVYGG APN9TXMBgXJyTDn2TWu4/uSw3/coXEmicwiUpO3XN1WfM2IObwtSo8tsFDUPDPnvxP MsPcYdGmKpqbQXKxk+RsS7Tpf2hsIVrDmmOstBUU= Received: from localhost (saper@localhost) by q.saper.info (8.17.1/8.17.1/Submit) with ESMTP id 3BO1LeJo022999; Sun, 24 Dec 2023 01:21:40 GMT (envelope-from saper@saper.info) X-Authentication-Warning: q.saper.info: saper owned process doing -bs Date: Sun, 24 Dec 2023 01:21:40 +0000 From: Marcin Cieslak To: bob prohaska cc: freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed In-Reply-To: Message-ID: <16864054-4os0-pq3p-7qp0-7299666908os@fncre.vasb> References: List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="2201072851-363648928-1703380900=:2993" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:47066, ipnet:2605:2700::/32, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SyNY15CX0z3RkJ --2201072851-363648928-1703380900=:2993 Content-Type: text/plain; charset=US-ASCII; format=flowed On Sat, 23 Dec 2023, bob prohaska wrote: > On Sun, Dec 24, 2023 at 12:47:56AM +0000, Marcin Cieslak wrote: >> On Sat, 23 Dec 2023, bob prohaska wrote: >> >>> What are the best-supported usb-serial adapters for use with FreeBSD on arm systems? >> >> I am using uchcom(4)-based CH340, the reason I have it is selectable 3.3V/5V level. >> I don't have a Raspberry but I use it for other arm boards. >> >> Not sure it is "better" than, say ft232 > > Have you run into any oddities using the ch340? Noise on the lines, > dropped connections, irreproducible behavior? Only this https://lists.freebsd.org/archives/freebsd-arm/2023-March/002422.html - responding to your post about halted boot - but this is an EFI console problem. > Thanks for writing & confirming ch340 is an option! Are you still troubleshooting your broken tip connections? --2201072851-363648928-1703380900=:2993 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIOdgYJKoZIhvcNAQcCoIIOZzCCDmMCAQExDzANBglghkgBZQMEAgEFADAL BgkqhkiG9w0BBwGgggq9MIIEvDCCA6SgAwIBAgIQeEqpEhjRpCYIUTzTZlVD ozANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQLExdHbG9iYWxTaWduIFJvb3Qg Q0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMKR2xvYmFs U2lnbjAeFw0yMDA5MTYwMDAwMDBaFw0yOTAzMTgwMDAwMDBaMFsxCzAJBgNV BAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTEwLwYDVQQDEyhH bG9iYWxTaWduIEdDQyBSMyBQZXJzb25hbFNpZ24gMSBDQSAyMDIwMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvxvJBqEapaux2/z3J7fFslRO WjKVJ5rCMfWGsg17dmD7NSnG7Spoa8d3htXsls1IMxoO8PyouQajNQqYmlYo xinlqenMNv7CJyEKMOAtglBmD6C/QC7kT+dSx4HfSTs8xmv8veJOldMzF8S/ BEn/tD4w/Dvpg+oXOqDyOiHPTacRFK0QHoq5eEbBmVS8W0rwcaRotO9fGTA+ NjF0My7GLRNK0eMPGh2hcPZURQhXy7wRQ8XFIfEA6kaQHHN22ncnVtwqiTmA wTR+4GNNVinG3KjNZLAVSnGrdCvT2I4Zo19hKy5PX6o7wrVXvMR4zV5VBFwV 6ZDM+xewao7Mup+SbwIDAQABo4IBiTCCAYUwDgYDVR0PAQH/BAQDAgGGMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/ AgEAMB0GA1UdDgQWBBSFu/DMxDa1CmJ2o5kuj7s6aq3FUTAfBgNVHSMEGDAW gBSP8Et/qC5FJK5NUPpjmove4t0bvDB6BggrBgEFBQcBAQRuMGwwLQYIKwYB BQUHMAGGIWh0dHA6Ly9vY3NwLmdsb2JhbHNpZ24uY29tL3Jvb3RyMzA7Bggr BgEFBQcwAoYvaHR0cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQv cm9vdC1yMy5jcnQwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9i YWxzaWduLmNvbS9yb290LXIzLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIB KDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9y ZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEAWWtqju12g524FdD2HwUX U1rSxeM5aSU1cUC1V/xBjXW0IjA7/3/vG2cietPPP/g3lpoQePVJpQAKZml8 1fHwPPivFK9Ja41jJkgqGzkORSC0xYkh2gGeQg1JVaCzcrRzJElRjT442m6F pbLHCebxIHLu0WBNjLZreB6MYMaqdPL6ItbXtD/BU4k517cEuUbczoBFZAra jq7oUBWXuroln5AMnRwVNwgJN4Np0s4kkJ94KepzbFOLzcbnfUB0+xT4foXm bM0GmmcPGOy0qvqEHJsBwDZXDxIk8oqCnnLngi7N94Sn4eTcmpZ9NH2dDN1O TEPVXgRG5X1pBcNtMWG6MDCCBfkwggThoAMCAQICDCKqoJRMYYx5sYJHGzAN BgkqhkiG9w0BAQsFADBbMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFs U2lnbiBudi1zYTExMC8GA1UEAxMoR2xvYmFsU2lnbiBHQ0MgUjMgUGVyc29u YWxTaWduIDEgQ0EgMjAyMDAeFw0yMzAzMDcxNjExMDlaFw0yNjAzMDcxNjEx MDlaMDwxGTAXBgNVBAMMEHNhcGVyQHNhcGVyLmluZm8xHzAdBgkqhkiG9w0B CQEWEHNhcGVyQHNhcGVyLmluZm8wggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAw ggIKAoICAQC8MB3fTYVrTadH5qE2CIa4VLvlL6QHgDriMRLkTA49SPszYCO0 fZTEpdSw8fc6kK9p2fD63LAfOHeD7jzey5aHBzpIGlxeFkn0Ce2BCYY5yLxK i9byoCwrpLchTR1Itpk1w+zy5E4T9KBTL1+c+w+TKpaIvFLXtjZtz4wQGi0p e/nRkRK9htGG3mETh+APitedl+ImGaI8NK9PELxuSkXnYAvGPpnXir8vbszk tJU1b0TevL/i3Sy6fhOhunZmTo1QDM7Zw4UyVjkQgTvL3y4I0tIrVjlam08x XZeMp+i/Gl51eHGvRVfvdJUJAjrWhrFEp8+2FZouWxWzAlHdd2sRp1AekNdP CeRgHeIF6uNtSseL1grKAjU+4BiixWPp1y1niB0humoQHoub/6fO/mU+//rW l3gTwZNu4FuKgZlfPw+qnvuka0c9dUNIZRCE5z8yXjS8R9yZWirnHNhYxf/e R2y4jaiHzPAjZlZZ2rGx8xVfB2n2JsAicj2+ZxmXlQ1yd5RW1pfxG3cdNNC5 uZ+j4JIN2ElsIjEKmMn9gHdoaEMAy/ENwNiMDBadLnc8qWirq/Ktp2dBSf2y /sH9xMpVyk8wuYjpbCnX4xslAensno5A20MYdKGPRFaItEhNPNbfzc1+4br8 exoXFX1F9ZJK9gGUO2nLbdRycphdyzxzgQIDAQABo4IB2jCCAdYwDgYDVR0P AQH/BAQDAgWgMIGjBggrBgEFBQcBAQSBljCBkzBOBggrBgEFBQcwAoZCaHR0 cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvZ3NnY2NyM3BlcnNv bmFsc2lnbjFjYTIwMjAuY3J0MEEGCCsGAQUFBzABhjVodHRwOi8vb2NzcC5n bG9iYWxzaWduLmNvbS9nc2djY3IzcGVyc29uYWxzaWduMWNhMjAyMDBMBgNV HSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3 dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAJBgNVHRMEAjAAMEkGA1Ud HwRCMEAwPqA8oDqGOGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NnY2Ny M3BlcnNvbmFsc2lnbjFjYTIwMjAuY3JsMBsGA1UdEQQUMBKBEHNhcGVyQHNh cGVyLmluZm8wHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB8GA1Ud IwQYMBaAFIW78MzENrUKYnajmS6PuzpqrcVRMB0GA1UdDgQWBBTW/RrdlRFR y6MgS7liTThMnQA5ozANBgkqhkiG9w0BAQsFAAOCAQEAAwoUJShHMueocVlD 1+vYJbTTTbk9tabr2L4Iyyy4Btu1d1wwl6d9Yx2N9qaVERWcEeP0aR+NB2B7 xIKl/ZnZVuSxep0Raw4s284a/jSIJlsAi4SJItDCU2VrYJDWxP7MxzZHnzPI MLDoTHXPV18gvYTewoNk5/Yo89Kb0v/GpPTpP2sVdrWLHa4uKUHYrAZ0aByp kNw6lXp6o6DXvXaOd6KDTQN5XhmmHwLnuLceODF1t9gicsZIOY+KAxN6YZ6t EqwN48b4OFMpckDE3fm1iTZRqnEIqUHOKOcoCImkub1woEN0zXDQmLXaZigl uVztWSTM4/fapWLrlHBNxfjs1TGCA30wggN5AgEBMGswWzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExMTAvBgNVBAMTKEdsb2Jh bFNpZ24gR0NDIFIzIFBlcnNvbmFsU2lnbiAxIENBIDIwMjACDCKqoJRMYYx5 sYJHGzANBglghkgBZQMEAgEFAKCB5DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0yMzEyMjQwMTIxNDBaMC8GCSqGSIb3DQEJ BDEiBCB4N1l90Ox4WhITpA15Oi05WpZsz+15q2CBqq/kzEkjNzB5BgkqhkiG 9w0BCQ8xbDBqMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUD BAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAgC4 AGC+ncbUdCJemKn4BXq3waRdC4pvwq1IP/c99MLBIJ+fzUFOj5Pm3tgIdMGF BGQniz6kYMOp88A9jdRbqEQe6KP8mJN0+Y9cZau2cvrNJ1URYGtwwaCgdj6B pKw/RvHcktCuNwqtrErvlrZvWwGCr76zfvfwFDTnFPOH0PFVYQXOvQbBtuhs j3IGKPT4ECwWIbWOkZkMcSwyMi76vLryIyOP09MadE/0ihsE65rUM3CJy1S6 Y0IZFGQ3HLWrkOWOHOomi8i1veMsbe6Y8qKTAOW+QhdvV8HMIQbtWYoqgiCv KUvaTkMZo3UDaH12RVFU4hNFbcLhIfF0waATX7mU7ouKsGbDxWI5i/4RKp80 VTUVFT0sYs0Og/Rac4vGGHVv65ue0qKDWNJQ+vp5Hm/0ACu9EUgw5a9hDhjm Wp8gEGFGEuLtDCmwBl4HwKj4sryFogPknWcZFINkue7zJT/H1WsAWLTBGrol MmRUUt27V3y+3E6DEVl2kK0E68IOUsSejf3vaC3F4+C7fGP8oZtkYAKJE5XH OLFY+fk97+/WvA2mBWImTpgEdK8tz3E9ru0jiXexylj1lHZrWQbHvo1/7RqZ YEIpuqSOU6DOLxprxG4EAbYhF1VSDjFsfZIUiewLMAsI2xQOBt+L753sHFGv fP9BDaegS47s90bReLKW6w== --2201072851-363648928-1703380900=:2993-- From nobody Sun Dec 24 01:33:14 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SyNpM6Q3Dz55HTQ for ; Sun, 24 Dec 2023 01:33:15 +0000 (UTC) (envelope-from saper@saper.info) Received: from q.saper.info (q.saper.info [IPv6:2605:2700:0:2:a800:ff:fec7:5c61]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "q.saper.info", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SyNpM3gwWz3T23 for ; Sun, 24 Dec 2023 01:33:15 +0000 (UTC) (envelope-from saper@saper.info) Authentication-Results: mx1.freebsd.org; none Received: from q.saper.info (localhost [127.0.0.1]) by q.saper.info (8.17.1/8.17.1) with ESMTPS id 3BO1XEYS023080 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 24 Dec 2023 01:33:14 GMT (envelope-from saper@saper.info) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=saper.info; s=Sep2014; t=1703381594; bh=t/2F3RkFQKoVGoR+V7B3MKVt2N9OkqirfFXNP2k8GEA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Hh+R9GXvIiT1/YVGeWCuJ1cVqmM5HHmXEf63pQVJDfkhBCCUaDWGrZKygUSnBDuVp QeyilS7Hs/2RGs8MhpzgyMlu0aVhJGJ2yZM+pIYIecuSntYYnrXkXcxG21nHS8htm4 qx72KHJ7eIjmNvPYqbg0vUVLlG8jP9OaByI5MYs0= Received: from localhost (saper@localhost) by q.saper.info (8.17.1/8.17.1/Submit) with ESMTP id 3BO1XEgo023077; Sun, 24 Dec 2023 01:33:14 GMT (envelope-from saper@saper.info) X-Authentication-Warning: q.saper.info: saper owned process doing -bs Date: Sun, 24 Dec 2023 01:33:14 +0000 From: Marcin Cieslak To: bob prohaska cc: freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed In-Reply-To: Message-ID: <480135o1-0ns4-p9qq-95nn-595s665rn500@fncre.vasb> References: List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="2201072851-1799307222-1703381594=:2993" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:47066, ipnet:2605:2700::/32, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SyNpM3gwWz3T23 --2201072851-1799307222-1703381594=:2993 Content-Type: text/plain; charset=US-ASCII; format=flowed On Sat, 23 Dec 2023, bob prohaska wrote: > Thanks for writing & confirming ch340 is an option! One more thing - please be aware that the adapter I have gives only a simple three-wire connection (RxD, TxD, GND) so there is NO hardware flow control of any sort. --2201072851-1799307222-1703381594=:2993 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIOdgYJKoZIhvcNAQcCoIIOZzCCDmMCAQExDzANBglghkgBZQMEAgEFADAL BgkqhkiG9w0BBwGgggq9MIIEvDCCA6SgAwIBAgIQeEqpEhjRpCYIUTzTZlVD ozANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQLExdHbG9iYWxTaWduIFJvb3Qg Q0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMKR2xvYmFs U2lnbjAeFw0yMDA5MTYwMDAwMDBaFw0yOTAzMTgwMDAwMDBaMFsxCzAJBgNV BAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTEwLwYDVQQDEyhH bG9iYWxTaWduIEdDQyBSMyBQZXJzb25hbFNpZ24gMSBDQSAyMDIwMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvxvJBqEapaux2/z3J7fFslRO WjKVJ5rCMfWGsg17dmD7NSnG7Spoa8d3htXsls1IMxoO8PyouQajNQqYmlYo xinlqenMNv7CJyEKMOAtglBmD6C/QC7kT+dSx4HfSTs8xmv8veJOldMzF8S/ BEn/tD4w/Dvpg+oXOqDyOiHPTacRFK0QHoq5eEbBmVS8W0rwcaRotO9fGTA+ NjF0My7GLRNK0eMPGh2hcPZURQhXy7wRQ8XFIfEA6kaQHHN22ncnVtwqiTmA wTR+4GNNVinG3KjNZLAVSnGrdCvT2I4Zo19hKy5PX6o7wrVXvMR4zV5VBFwV 6ZDM+xewao7Mup+SbwIDAQABo4IBiTCCAYUwDgYDVR0PAQH/BAQDAgGGMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/ AgEAMB0GA1UdDgQWBBSFu/DMxDa1CmJ2o5kuj7s6aq3FUTAfBgNVHSMEGDAW gBSP8Et/qC5FJK5NUPpjmove4t0bvDB6BggrBgEFBQcBAQRuMGwwLQYIKwYB BQUHMAGGIWh0dHA6Ly9vY3NwLmdsb2JhbHNpZ24uY29tL3Jvb3RyMzA7Bggr BgEFBQcwAoYvaHR0cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQv cm9vdC1yMy5jcnQwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9i YWxzaWduLmNvbS9yb290LXIzLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIB KDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9y ZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEAWWtqju12g524FdD2HwUX U1rSxeM5aSU1cUC1V/xBjXW0IjA7/3/vG2cietPPP/g3lpoQePVJpQAKZml8 1fHwPPivFK9Ja41jJkgqGzkORSC0xYkh2gGeQg1JVaCzcrRzJElRjT442m6F pbLHCebxIHLu0WBNjLZreB6MYMaqdPL6ItbXtD/BU4k517cEuUbczoBFZAra jq7oUBWXuroln5AMnRwVNwgJN4Np0s4kkJ94KepzbFOLzcbnfUB0+xT4foXm bM0GmmcPGOy0qvqEHJsBwDZXDxIk8oqCnnLngi7N94Sn4eTcmpZ9NH2dDN1O TEPVXgRG5X1pBcNtMWG6MDCCBfkwggThoAMCAQICDCKqoJRMYYx5sYJHGzAN BgkqhkiG9w0BAQsFADBbMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFs U2lnbiBudi1zYTExMC8GA1UEAxMoR2xvYmFsU2lnbiBHQ0MgUjMgUGVyc29u YWxTaWduIDEgQ0EgMjAyMDAeFw0yMzAzMDcxNjExMDlaFw0yNjAzMDcxNjEx MDlaMDwxGTAXBgNVBAMMEHNhcGVyQHNhcGVyLmluZm8xHzAdBgkqhkiG9w0B CQEWEHNhcGVyQHNhcGVyLmluZm8wggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAw ggIKAoICAQC8MB3fTYVrTadH5qE2CIa4VLvlL6QHgDriMRLkTA49SPszYCO0 fZTEpdSw8fc6kK9p2fD63LAfOHeD7jzey5aHBzpIGlxeFkn0Ce2BCYY5yLxK i9byoCwrpLchTR1Itpk1w+zy5E4T9KBTL1+c+w+TKpaIvFLXtjZtz4wQGi0p e/nRkRK9htGG3mETh+APitedl+ImGaI8NK9PELxuSkXnYAvGPpnXir8vbszk tJU1b0TevL/i3Sy6fhOhunZmTo1QDM7Zw4UyVjkQgTvL3y4I0tIrVjlam08x XZeMp+i/Gl51eHGvRVfvdJUJAjrWhrFEp8+2FZouWxWzAlHdd2sRp1AekNdP CeRgHeIF6uNtSseL1grKAjU+4BiixWPp1y1niB0humoQHoub/6fO/mU+//rW l3gTwZNu4FuKgZlfPw+qnvuka0c9dUNIZRCE5z8yXjS8R9yZWirnHNhYxf/e R2y4jaiHzPAjZlZZ2rGx8xVfB2n2JsAicj2+ZxmXlQ1yd5RW1pfxG3cdNNC5 uZ+j4JIN2ElsIjEKmMn9gHdoaEMAy/ENwNiMDBadLnc8qWirq/Ktp2dBSf2y /sH9xMpVyk8wuYjpbCnX4xslAensno5A20MYdKGPRFaItEhNPNbfzc1+4br8 exoXFX1F9ZJK9gGUO2nLbdRycphdyzxzgQIDAQABo4IB2jCCAdYwDgYDVR0P AQH/BAQDAgWgMIGjBggrBgEFBQcBAQSBljCBkzBOBggrBgEFBQcwAoZCaHR0 cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvZ3NnY2NyM3BlcnNv bmFsc2lnbjFjYTIwMjAuY3J0MEEGCCsGAQUFBzABhjVodHRwOi8vb2NzcC5n bG9iYWxzaWduLmNvbS9nc2djY3IzcGVyc29uYWxzaWduMWNhMjAyMDBMBgNV HSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3 dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAJBgNVHRMEAjAAMEkGA1Ud HwRCMEAwPqA8oDqGOGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NnY2Ny M3BlcnNvbmFsc2lnbjFjYTIwMjAuY3JsMBsGA1UdEQQUMBKBEHNhcGVyQHNh cGVyLmluZm8wHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB8GA1Ud IwQYMBaAFIW78MzENrUKYnajmS6PuzpqrcVRMB0GA1UdDgQWBBTW/RrdlRFR y6MgS7liTThMnQA5ozANBgkqhkiG9w0BAQsFAAOCAQEAAwoUJShHMueocVlD 1+vYJbTTTbk9tabr2L4Iyyy4Btu1d1wwl6d9Yx2N9qaVERWcEeP0aR+NB2B7 xIKl/ZnZVuSxep0Raw4s284a/jSIJlsAi4SJItDCU2VrYJDWxP7MxzZHnzPI MLDoTHXPV18gvYTewoNk5/Yo89Kb0v/GpPTpP2sVdrWLHa4uKUHYrAZ0aByp kNw6lXp6o6DXvXaOd6KDTQN5XhmmHwLnuLceODF1t9gicsZIOY+KAxN6YZ6t EqwN48b4OFMpckDE3fm1iTZRqnEIqUHOKOcoCImkub1woEN0zXDQmLXaZigl uVztWSTM4/fapWLrlHBNxfjs1TGCA30wggN5AgEBMGswWzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExMTAvBgNVBAMTKEdsb2Jh bFNpZ24gR0NDIFIzIFBlcnNvbmFsU2lnbiAxIENBIDIwMjACDCKqoJRMYYx5 sYJHGzANBglghkgBZQMEAgEFAKCB5DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0yMzEyMjQwMTMzMTRaMC8GCSqGSIb3DQEJ BDEiBCDKj9GGLLtvzgVOYqBIfKKfUOlH67757or+ZO4UJrAboTB5BgkqhkiG 9w0BCQ8xbDBqMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUD BAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAgBi 8w39F9KNs5Cf28kNcADCKWQC2dmDLLdHe+ubo1/Nq+nNwdrcm/1ZUTVpGudo ZqF2VOCQ6d0zclB78SZOzFiK2IANcO4qWMY5hpwk8RtGiqcvMTPb5GblmoUG T5R0eZRBhH+tBdC6P+LEd9j4UGrze4115blLuuVOs2G69Q0B4FH7EhavNuF5 4JzaMEsCmljzWs9IM/oCzw6Gu/hTu+7Su6Lb19ctJcgGYaDeqq/7ssm3QYOn zna0Z2xa375IxEgQRoUXXWZiz4S/NVqPHmU5Rmg9+c+QROGhWWdf0O8xkc/l QHKEWpEROuw4YxP4coTkzh0pAPcHnN96vBGmxv3xHOfoAuMqZ63dQegpb89L bcaTGCqynlZrMwa/STSBLWHTEwMxfUjc8Do/s1QWDtCV/l6silMINJeUrOvH PK+uUehX9KjtE4vbQrCkNn+hhEER04HU41Z6O5koAJU7Js+HwE4y521he3Bt sxuEp0l+TmgH0Cjo4fzPQdi/D3QRVT3I5SFDWVW05uy0ie21nqbug0aKjvgi 8VPr8e0GkIJMKuzsgKtuqaRUzpsUkV3djjYc9jImOivulVVK7cwQEMhvDsUf djEN2LQS7dVHwMAG5hAG9Tzefo7X2KUP/ron6WdmZ6jzcjuQLGcueO+00N+G 1O3NtztaCTwPHskkiF6CsA== --2201072851-1799307222-1703381594=:2993-- From nobody Sun Dec 24 05:26:50 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SyV0K5CcFz53qWc for ; Sun, 24 Dec 2023 05:27:13 +0000 (UTC) (envelope-from joseph@josephholsten.com) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SyV0J5qj0z4KNt for ; Sun, 24 Dec 2023 05:27:12 +0000 (UTC) (envelope-from joseph@josephholsten.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=pobox.com header.s=fm1 header.b=nIH27ufe; dkim=pass header.d=messagingengine.com header.s=fm2 header.b="3 mU72iO"; spf=pass (mx1.freebsd.org: domain of joseph@josephholsten.com designates 66.111.4.29 as permitted sender) smtp.mailfrom=joseph@josephholsten.com; dmarc=none Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 8907A5C00A6 for ; Sun, 24 Dec 2023 00:27:11 -0500 (EST) Received: from imap49 ([10.202.2.99]) by compute4.internal (MEProxy); Sun, 24 Dec 2023 00:27:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pobox.com; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1703395631; x=1703482031; bh=QR8gVFF4qbhWbGj2WOFVQYfhC2Tr3nsy1f3+ZJNsMiM=; b= nIH27ufe9Uz528kUHzcZOf5ikPyM8XCt2+uPUCZ0lKsGuqdoTzfipGU2FXNlnllZ jBpF7LOZ7bMpHOleUelyioMYYPBONARFkw6wwSKaVbtI/TiVSz7ZEFaKKKrXmHmp yo1sV2gxyCEYt1zSR5f5Li0w/zRNaLktAhee+gh0JvarrHL5F89cuSrH5rbvKJw/ HJHdM4mq/1R74If7HNK9evOkwcYLjvD9eD9wnXoHqLRRmmB3yKVfZunf9N1gUFnM Re1T2k5krCIrG+gAwtACWl49Z12rW8tu9UqtIOMLrsdykxmQxb12oPhMQUQAEkpN u6eyrGXF++JW/ZajFgJ1ew== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1703395631; x= 1703482031; bh=QR8gVFF4qbhWbGj2WOFVQYfhC2Tr3nsy1f3+ZJNsMiM=; b=3 mU72iO7mr4LM5b0IKqHB6b7tL76fYLxIEGFP4bAI0ZS8qw9kDerNHPUqNu11RCsU 7wj6NFn17ofLCtdJcLjTabPsKMPPBWFETrfwlaXpnDtX1e24I4XA/Yuml1VitP/m xKgHipXCSzeDaTLBariR1Id44VueK4hBf87RC7BlRMpWvro8KJJVJV+7BJwKzx5D 13V349O2JyHoAKLcP7aY26duh6Cz3/eoxTBr2Zwl3vsmlFsKZCJ/uSOGFAFbBLxE 1cLkFYHm1Vh2NaBze64LjqnVDkXfNgkKgC87jmWE42OU9i9JbOLDYUWuKUqztkf+ fC1Ow9OtxD71S1sofTEZg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvddvtddgkeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdflohhsvghphhcujfholhhsthgvnhdfuceojhhoshgv phhhsehjohhsvghphhhhohhlshhtvghnrdgtohhmqeenucggtffrrghtthgvrhhnpedugf ehfefhfedtjeeifeettefhkedtudeuveejiefhhfdvffdvgfeuffejteejvdenucffohhm rghinheprhgrshhpsggvrhhrhihpihdrtghomhdpjhgvfhhfghgvvghrlhhinhhgrdgtoh hmpdgruggrfhhruhhithdrtghomhdpjhhoshgvphhhhhholhhsthgvnhdrtghomhenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehjohhsvghphh esjhhoshgvphhhhhholhhsthgvnhdrtghomh X-ME-Proxy: Feedback-ID: i49d34368:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 33CD515A0092; Sun, 24 Dec 2023 00:27:11 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-1364-ga51d5fd3b7-fm-20231219.001-ga51d5fd3 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Message-Id: <645f8f8c-1817-4e50-8e9c-3153a36838d6@app.fastmail.com> In-Reply-To: References: Date: Sat, 23 Dec 2023 21:26:50 -0800 From: "Joseph Holsten" To: freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-4.99 / 15.00]; DWL_DNSWL_LOW(-1.00)[pobox.com:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; RWL_MAILSPIKE_EXCELLENT(-0.40)[66.111.4.29:from]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.29]; R_DKIM_ALLOW(-0.20)[pobox.com:s=fm1,messagingengine.com:s=fm2]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.29:from]; XM_UA_NO_VERSION(0.01)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; DKIM_TRACE(0.00)[pobox.com:+,messagingengine.com:+]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[josephholsten.com]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4SyV0J5qj0z4KNt X-Spamd-Bar: ---- On Sat, Dec 23, 2023, at 16:43, bob prohaska wrote: > What are the best-supported usb-serial adapters for use with FreeBSD o= n=20 > arm systems? > I'm specifically interested in Raspberryp Pi 2/3/4 (and maybe 5=20 > someday). > > I've been using pl2303 and ft232 but wonder if there might be others w= orth > considering. Pl2303 are cheap and have lately been working fairly well= , but > if there's something better supported or behaved I'd like to know. I ended up going with the Raspberry Pi debug probe: https://www.raspberrypi.com/documentation/microcontrollers/debug-pro= be.html If I remember correctly, it=E2=80=99s a pl2303 inside. I mostly got this= model for the connectors and laziness. Jeff Geerling mentions some of the other options at https://www.jeffgeer= ling.com/blog/2023/testing-raspberry-pis-new-debug-probe If I were doing it again, I=E2=80=99d probably get the Black Magic Probe= which also supports JTAG https://www.adafruit.com/product/3839 -- Joseph Holsten http://josephholsten.com mailto:joseph@josephholsten.com tel:+1-360-927-7234 From nobody Sun Dec 24 15:46:40 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Syll806M4z54n2P for ; Sun, 24 Dec 2023 15:46:44 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4Syll7262Zz4PNm for ; Sun, 24 Dec 2023 15:46:43 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 3BOFkewK020380 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 24 Dec 2023 07:46:41 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 3BOFkeET020379; Sun, 24 Dec 2023 07:46:40 -0800 (PST) (envelope-from fbsd) Date: Sun, 24 Dec 2023 07:46:40 -0800 From: bob prohaska To: Marcin Cieslak Cc: freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed Message-ID: References: <16864054-4os0-pq3p-7qp0-7299666908os@fncre.vasb> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16864054-4os0-pq3p-7qp0-7299666908os@fncre.vasb> X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4Syll7262Zz4PNm On Sun, Dec 24, 2023 at 01:21:40AM +0000, Marcin Cieslak wrote: > On Sat, 23 Dec 2023, bob prohaska wrote: > > > On Sun, Dec 24, 2023 at 12:47:56AM +0000, Marcin Cieslak wrote: > > > On Sat, 23 Dec 2023, bob prohaska wrote: > > > > > > > What are the best-supported usb-serial adapters for use with FreeBSD on arm systems? > > > > > > I am using uchcom(4)-based CH340, the reason I have it is selectable 3.3V/5V level. > > > I don't have a Raspberry but I use it for other arm boards. > > > > > > Not sure it is "better" than, say ft232 > > > > Have you run into any oddities using the ch340? Noise on the lines, > > dropped connections, irreproducible behavior? > > Only this https://lists.freebsd.org/archives/freebsd-arm/2023-March/002422.html - > responding to your post about halted boot - but this is an EFI console problem. > > > Thanks for writing & confirming ch340 is an option! > > Are you still troubleshooting your broken tip connections? I'm still seeing tip sessions and the associated ssh connections drop, but am no closer to understanding what's wrong. There does seem to be a (somewhat imperfect) association between dropped tip sessions and the use of FTDI-232 usb-serial adapters, but the sample is too small (7 units) and too erratic (mix of Pi2, Pi3 & Pi4 hosts) to be sure of anything. That's surprising given the Pl2303's rather poor repute and the ft232's sterling reputation, but far from decisive. In my initial testing a few years ago it seemed the reputations of the pl2303 and ft232 were more or less deserved; the pl2303 seemed a little flakier and the ft232. Now that situation seems to be reversed. If there's another usb-serial bridge option which open-source programmers prefer it seems wise to adopt it. That's what I'm fishing for. Thanks for reading! bob prohaska From nobody Sun Dec 24 15:57:05 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Sylz81VXYz54p6D for ; Sun, 24 Dec 2023 15:57: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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4Sylz75cH3z4QwX for ; Sun, 24 Dec 2023 15:57:07 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 3BOFv6nn020425 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 24 Dec 2023 07:57:06 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 3BOFv6VU020424; Sun, 24 Dec 2023 07:57:06 -0800 (PST) (envelope-from fbsd) Date: Sun, 24 Dec 2023 07:57:05 -0800 From: bob prohaska To: Marcin Cieslak Cc: freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed Message-ID: References: <480135o1-0ns4-p9qq-95nn-595s665rn500@fncre.vasb> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <480135o1-0ns4-p9qq-95nn-595s665rn500@fncre.vasb> X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4Sylz75cH3z4QwX On Sun, Dec 24, 2023 at 01:33:14AM +0000, Marcin Cieslak wrote: > On Sat, 23 Dec 2023, bob prohaska wrote: > > > Thanks for writing & confirming ch340 is an option! > > One more thing - please be aware that the adapter I have > gives only a simple three-wire connection (RxD, TxD, GND) > so there is NO hardware flow control of any sort. I'm using usb-serial adapters to access RPi serial consoles, so no hardware flow control is needed (or usable). RTS/CTS would be nice in principle, for example to connect to a much slower device (a pen plotter comes to mind). Programming support seems to be the most valuable feature. Thanks for reading, bob prohaska From nobody Sun Dec 24 16:54:28 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SynFL2Fypz54spr for ; Sun, 24 Dec 2023 16:54:30 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4SynFK6LPrz4Zb7 for ; Sun, 24 Dec 2023 16:54:29 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 3BOGsSh9020536 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 24 Dec 2023 08:54:28 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 3BOGsSeb020535; Sun, 24 Dec 2023 08:54:28 -0800 (PST) (envelope-from fbsd) Date: Sun, 24 Dec 2023 08:54:28 -0800 From: bob prohaska To: Joseph Holsten Cc: freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed Message-ID: References: <645f8f8c-1817-4e50-8e9c-3153a36838d6@app.fastmail.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <645f8f8c-1817-4e50-8e9c-3153a36838d6@app.fastmail.com> X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SynFK6LPrz4Zb7 On Sat, Dec 23, 2023 at 09:26:50PM -0800, Joseph Holsten wrote: > > > On Sat, Dec 23, 2023, at 16:43, bob prohaska wrote: > > What are the best-supported usb-serial adapters for use with FreeBSD on > > arm systems? > > I'm specifically interested in Raspberryp Pi 2/3/4 (and maybe 5 > > someday). > > > > I've been using pl2303 and ft232 but wonder if there might be others worth > > considering. Pl2303 are cheap and have lately been working fairly well, but > > if there's something better supported or behaved I'd like to know. > > I ended up going with the Raspberry Pi debug probe: > https://www.raspberrypi.com/documentation/microcontrollers/debug-probe.html > If I remember correctly, it???s a pl2303 inside. I mostly got this model for the connectors and laziness. > Laziness and frugality led me to the pl2303 also. At the moment, it looks like the best choice. > Jeff Geerling mentions some of the other options at https://www.jeffgeerling.com/blog/2023/testing-raspberry-pis-new-debug-probe That's a good article, especially the references. > > If I were doing it again, I???d probably get the Black Magic Probe which also supports JTAG https://www.adafruit.com/product/3839 > Present purposes are dedicated to serial console interface. Perhaps someday, but not yet. An apropos search for jtag finds altera_jtag_uart driver for the Altera JTAG UART Core Does that imply the only jtag device supported by FreeBSD must be compatible with the particular device family? Thanks for writing! bob prohaska From nobody Sun Dec 24 17:01:00 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SynP70DVlz54tkv for ; Sun, 24 Dec 2023 17:01:15 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [IPv6:2a02:21e0:16e0:fe::101:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "raven.bwct.de", Issuer "raven.bwct.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SynP64m08z4bW2 for ; Sun, 24 Dec 2023 17:01:14 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Authentication-Results: mx1.freebsd.org; none Received: from mail.cicely.de (mail.cicely.de [IPv6:2a02:21e0:16e0:20fe:0:0:101:c]) by raven.bwct.de (8.15.2/8.15.2) with ESMTPS id 3BOH10I8092794 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=FAIL); Sun, 24 Dec 2023 18:01:02 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cicely.de; s=default; t=1703437262; bh=YOGf7+9qr7S+3v7BSBbC6Zv3V9mspIvIYIZ3TiBxWkk=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=Mq4V471NcYNhCDFKQ9ceYK1jsXS3juiWrndtCWGaCh+Mvn3AqGhJeRfWTyo5oB088 iQlycHghuyRlUy6tLv9lXSoKNXi10gWoM+FulEGIg8BueYVWa1vo7gwhDtI85GV16/ UUXBapHPjMvxHXm9rNzaYvKVHU4rc3NzaCdf4DUY= Received: from cicely7.cicely.de (c7-old.cicely.de [IPv6:2a02:21e0:16e0:20fe:0:0:101:d]) by mail.cicely.de (8.16.1/8.16.1) with ESMTPS id 3BOH102I049534 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 24 Dec 2023 18:01:00 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.17.1/8.17.1) with ESMTP id 3BOH10bJ024308; Sun, 24 Dec 2023 18:01:00 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.17.1/8.17.1/Submit) id 3BOH10Nv024307; Sun, 24 Dec 2023 18:01:00 +0100 (CET) (envelope-from ticso) Date: Sun, 24 Dec 2023 18:01:00 +0100 From: Bernd Walter To: bob prohaska Cc: Marcin Cieslak , freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed Message-ID: Reply-To: ticso@cicely.de References: <16864054-4os0-pq3p-7qp0-7299666908os@fncre.vasb> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 13.2-RELEASE-p3 amd64 X-Rspamd-Server: rspamd.fizon.de X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:44700, ipnet:2a02:21e0::/32, country:DE] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SynP64m08z4bW2 On Sun, Dec 24, 2023 at 07:46:40AM -0800, bob prohaska wrote: > On Sun, Dec 24, 2023 at 01:21:40AM +0000, Marcin Cieslak wrote: > > On Sat, 23 Dec 2023, bob prohaska wrote: > > > > > On Sun, Dec 24, 2023 at 12:47:56AM +0000, Marcin Cieslak wrote: > > > > On Sat, 23 Dec 2023, bob prohaska wrote: > > > > > > > > > What are the best-supported usb-serial adapters for use with FreeBSD on arm systems? > > > > > > > > I am using uchcom(4)-based CH340, the reason I have it is selectable 3.3V/5V level. > > > > I don't have a Raspberry but I use it for other arm boards. > > > > > > > > Not sure it is "better" than, say ft232 > > > > > > Have you run into any oddities using the ch340? Noise on the lines, > > > dropped connections, irreproducible behavior? > > > > Only this https://lists.freebsd.org/archives/freebsd-arm/2023-March/002422.html - > > responding to your post about halted boot - but this is an EFI console problem. > > > > > Thanks for writing & confirming ch340 is an option! > > > > Are you still troubleshooting your broken tip connections? > > I'm still seeing tip sessions and the associated ssh connections drop, > but am no closer to understanding what's wrong. There does seem to be > a (somewhat imperfect) association between dropped tip sessions and > the use of FTDI-232 usb-serial adapters, but the sample is too small > (7 units) and too erratic (mix of Pi2, Pi3 & Pi4 hosts) to be sure of > anything. If you see ssh connections drop then this is network related and has nothing to do with the USB adapter. In case an USB adapter fails you will just drop out of tip into the shell. Most likly this is a statefull network device - e.g. NAT expire on either your or ISP side. TCPKeepAlive is active per default on OpenSSH, but often not enough for some agressive ISP equipment. You might also want to check if you have local firewalls in between, which are misconfigured to expire TCP states too early. If you run through equipment, which isn't in your hands at best you have an OpenVPN or similar connection to handle network instabilities and run ssh on top of it. If however this is not ssh session dropped and just tip, then look up kernel messages if the USB adapter was disconnected. If yes and you have that problem with multiple adapters then this is most likely power related, especially since both systems are connected via ground and can have all kind of electrical issues. In some cases it might be required to have an isolated adapter. That said, beside all chips work well. There are some bad boards however, which are unrelated to the chips themselves. Also at least with the PL2303, CP2102 and some FTDI there are fake chips on the market. Other than that you might need specific features, some FTDI and CH340 can do higher bps rates, which some rockchip based boards may need. Also FTDI and CP2102 and a few others can have uniquie serial numbers, which makes them easier to identify if you have multiple. That's the reason why I like to use FT4232H based for my bench tests. They can handle higher speeds and have serial numbers, plus they support multiple uart at the same time. I also have lots of CP2102, which I build myself and know those are technically good. > That's surprising given the Pl2303's rather poor repute and the ft232's > sterling reputation, but far from decisive. In my initial testing a few > years ago it seemed the reputations of the pl2303 and ft232 were more or > less deserved; the pl2303 seemed a little flakier and the ft232. Now that > situation seems to be reversed. The PL203 pure repute is that there had been tons of crappy adapters out there and also fake chips had been an issue early on. A quality board with a genuine Prolific chip works fine. Still today you will get a bad board with fake chips more likely than a good one if you buy from a random source. > If there's another usb-serial bridge option which open-source programmers > prefer it seems wise to adopt it. That's what I'm fishing for. > > Thanks for reading! > > bob prohaska > > > -- B.Walter https://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From nobody Sun Dec 24 17:02:11 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SynQS6ZtSz54tYj for ; Sun, 24 Dec 2023 17:02:24 +0000 (UTC) (envelope-from soren.schmidt@gmail.com) Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SynQS4zrrz4bnS for ; Sun, 24 Dec 2023 17:02:24 +0000 (UTC) (envelope-from soren.schmidt@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-a2370535060so784270566b.1 for ; Sun, 24 Dec 2023 09:02:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703437343; x=1704042143; darn=freebsd.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=V+UzZ9dT5Rzhq0uMph7DIc6bvcjaZLOwkQGlvO7qtV4=; b=UbGAhETx4izNCFIw09mArL92tc8Y16m++r4kQtLo2UBUqatISlbEFZB1mI6cZtnZG7 KEsnFeJBN0F7x6X4WzD1htYFyNFxjuF8jlEdwG34taEwh+vC68N/vY+gBDnLfWcY54MU pRrxyy9gX+ksLGVKe/OR/VmGVdKZnmd1TpxiA13Hiw5AIMIiJ/u4/0iPF4+rJWo4tYp1 bF6VbeGjyQNdoYsi3qscJ/8JY1T6mCFkSQ73HZz9yvShio2xz1heOJ+NxFQiikka03c/ octMlp12OR4B+4kyL17oXw1JlFf6e2il1P58ziRDrpt3lZhoSR3BXGTwOQnp2JtE2pq+ XFEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703437343; x=1704042143; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=V+UzZ9dT5Rzhq0uMph7DIc6bvcjaZLOwkQGlvO7qtV4=; b=DzRMIyLcZm29LSse5hY3aic7j0H9pMlzxscLSgX1YeNRCiYKq/fogzZmv5+KXzFxkB K18lAI/YcMpjb96gvpFOANrZFsF8gYU6EjpiPUK16FFsX3ktst63YVsjQt1U3mEy9t3/ CoNon4Am474v1hCk1mjsArUzItqXi5fa+Z9bqRwWmLrk0MPftxagfqGyeEN8RDp+g7lB sKtg8HTAv+EWwbXUOM6VGXaFT4H/t8z8FlVjNT00K6qRj7hZPlIA3iZSMRvBsKqzx2/L sOV2MIyraPSX7OqHeJrxFaQbVBx6AINDzaQAxC//yUKR8N4lUKBqcmnLfQ5lytU5yy45 ENNQ== X-Gm-Message-State: AOJu0YyeHGeY9sKSV/tJSGQinjHzKLNG0MSlVH9CiIMRtTHSImX2tj8K vgpYZCxSzTdAQxtYI/utzAg= X-Google-Smtp-Source: AGHT+IHrOdYzPXiK5BUvk1FYpW2x1kWl1IUunRu38ZaK6kEiZcQtKvsV3luGm8Tj8BtI6va0N9usKw== X-Received: by 2002:a17:907:3fa4:b0:a23:671c:2284 with SMTP id hr36-20020a1709073fa400b00a23671c2284mr7544427ejc.29.1703437342559; Sun, 24 Dec 2023 09:02:22 -0800 (PST) Received: from smtpclient.apple ([85.27.186.9]) by smtp.gmail.com with ESMTPSA id fc19-20020a1709073a5300b00a26ea2179e8sm629537ejc.41.2023.12.24.09.02.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 24 Dec 2023 09:02:22 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: =?utf-8?Q?S=C3=B8ren_Schmidt?= List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (1.0) Subject: Re: USB-serial adapter suggestions needed Date: Sun, 24 Dec 2023 18:02:11 +0100 Message-Id: <1C0F21CD-08C6-4BF9-A9BB-E8AAD60C4C31@gmail.com> References: Cc: Joseph Holsten , freebsd-arm@freebsd.org In-Reply-To: To: bob prohaska X-Mailer: iPhone Mail (21C66) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SynQS4zrrz4bnS Hi, Mix of ft232 and ch340 here as I need 1500000 baud for rockchip development.= Picocom as =E2=80=9Cterminal=E2=80=9D on either macOS or FreeBSD. No problem= s with any of those whatsoever. -S=C3=B8ren > On 24 Dec 2023, at 17.54, bob prohaska wrote: >=20 > =EF=BB=BFOn Sat, Dec 23, 2023 at 09:26:50PM -0800, Joseph Holsten wrote: >>=20 >>=20 >>> On Sat, Dec 23, 2023, at 16:43, bob prohaska wrote: >>> What are the best-supported usb-serial adapters for use with FreeBSD on >>> arm systems? >>> I'm specifically interested in Raspberryp Pi 2/3/4 (and maybe 5 >>> someday). >>>=20 >>> I've been using pl2303 and ft232 but wonder if there might be others wor= th >>> considering. Pl2303 are cheap and have lately been working fairly well, b= ut >>> if there's something better supported or behaved I'd like to know. >>=20 >> I ended up going with the Raspberry Pi debug probe: >> https://www.raspberrypi.com/documentation/microcontrollers/debug-probe= .html >> If I remember correctly, it???s a pl2303 inside. I mostly got this model f= or the connectors and laziness. >>=20 >=20 > Laziness and frugality led me to the pl2303 also. At the moment, it looks > like the best choice. >=20 >=20 >> Jeff Geerling mentions some of the other options at https://www.jeffgeerl= ing.com/blog/2023/testing-raspberry-pis-new-debug-probe >=20 > That's a good article, especially the references. >=20 >>=20 >> If I were doing it again, I???d probably get the Black Magic Probe which a= lso supports JTAG https://www.adafruit.com/product/3839 >>=20 >=20 > Present purposes are dedicated to serial console interface. Perhaps someda= y, > but not yet. An apropos search for jtag finds >=20 > altera_jtag_uart driver for the Altera JTAG UART Core >=20 > Does that imply the only jtag device supported by FreeBSD must > be compatible with the particular device family? >=20 > Thanks for writing! >=20 > bob prohaska >=20 >=20 From nobody Sun Dec 24 19:39:24 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Syrvs3GhKz54Mk0 for ; Sun, 24 Dec 2023 19:39:37 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4Syrvr6z18z4v2S for ; Sun, 24 Dec 2023 19:39:36 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 3BOJdPcs021113 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 24 Dec 2023 11:39:26 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 3BOJdOVm021112; Sun, 24 Dec 2023 11:39:24 -0800 (PST) (envelope-from fbsd) Date: Sun, 24 Dec 2023 11:39:24 -0800 From: bob prohaska To: ticso@cicely.de Cc: Marcin Cieslak , freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed Message-ID: References: <16864054-4os0-pq3p-7qp0-7299666908os@fncre.vasb> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4Syrvr6z18z4v2S On Sun, Dec 24, 2023 at 06:01:00PM +0100, Bernd Walter wrote: > If you see ssh connections drop then this is network related and has nothing > to do with the USB adapter. > In case an USB adapter fails you will just drop out of tip into the shell. > Most likly this is a statefull network device - e.g. NAT expire on either > your or ISP side. > TCPKeepAlive is active per default on OpenSSH, but often not enough for some > agressive ISP equipment. > You might also want to check if you have local firewalls in between, which > are misconfigured to expire TCP states too early. The normal network setup is shown at http://www.zefox.net/~fbsd/netmap SSH sessions are initiated from the Pi4 workstation on the LAN to each FreeBSD host, using tip or cu to connect to the corresponding Pi's serial console. It's maybe worth mentioning that changing the host named pelorus from WAN to LAN and booting release/14 seems to make no difference. SSH sessions not involving usb-serial adapters stay up until the WiFi link crashes for some reason. According to the router's (D-Link DI-524) control panel the firewall features are turned off. > If you run through equipment, which isn't in your hands at best you have > an OpenVPN or similar connection to handle network instabilities and run > ssh on top of it. > > If however this is not ssh session dropped and just tip, then look up kernel > messages if the USB adapter was disconnected. There are no messages of the kind seen when an adapter is unplugged or turned off using usbconfig. I've tried turning on usb debugging, but the output is not obviously related to the disconnects, in part due to volume. Interestingly, a "stuck" adapter can usually be "unstuck" by using usbconfig to turn the power off and back on. Prompted by your email, I noticed that under the Advanced > Filters page of the router there's an option called "IP Filters", said to deny LAN access to the Internet. Neither Enabled nor Disabled are checked, no IP numbers are entered and all schedule times are set to zero. When I finish this email I'll explictly disable the filter function to see if some default is making mischief. > If yes and you have that problem with multiple adapters then this is most > likely power related, especially since both systems are connected via ground > and can have all kind of electrical issues. I do see what looks like noise on the serial lines, but only after a spontaneous disconnect and only with FTDI adapters. When the serial connections are working nothing resembling noise is seen. > In some cases it might be required to have an isolated adapter. A close look at the connection diagram will reveal a loop connecting all the FreeBSD systems via the serial port grounds. Breaking that loop by lifting ground on one serial cable ground made no difference. > That said, beside all chips work well. > There are some bad boards however, which are unrelated to the chips themselves. > Also at least with the PL2303, CP2102 and some FTDI there are fake chips on > the market. > Other than that you might need specific features, some FTDI and CH340 can do > higher bps rates, which some rockchip based boards may need. > Also FTDI and CP2102 and a few others can have uniquie serial numbers, which > makes them easier to identify if you have multiple. > That's the reason why I like to use FT4232H based for my bench tests. > They can handle higher speeds and have serial numbers, plus they support > multiple uart at the same time. > I also have lots of CP2102, which I build myself and know those are technically > good. > That's helpful information. It sounds like there's little preference between pl2303, ft232, ch340 and cp2102. Thanks for writing! bob prohaska From nobody Sun Dec 24 19:59:10 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SysMB0Bc6z54NQw for ; Sun, 24 Dec 2023 19:59:50 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SysM86t8lz4vl3 for ; Sun, 24 Dec 2023 19:59:48 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=kzO7UWta; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2a00:1450:4864:20::336 as permitted sender) smtp.mailfrom=marietto2008@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-40d2764c0f2so45545415e9.2 for ; Sun, 24 Dec 2023 11:59:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703447986; x=1704052786; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=UGqMK51hD+V1BegjnWp7QD6aG910jqLFl6edC6M0Rxc=; b=kzO7UWta+bUTMK6AogKNByv4ZJvoafqqQ20oVUhtaMcP+RxyBJEEQwgpwGBp9Ihu92 K4tvgthQDh2IIvQmra4LQrXV+Z5rvUs9e0DZgOXDet6TAtVs7jRKuCw2G7OhD1lED/V2 d44HkK6jnBXxYbavGPmlK4BSOBk7huH+YjYR+G6ntWHdFan7NvM//gDxNs7QLq2DaiYo xI7mZCbmkBK3O61ZHAbTSa2AQC92as3gJQyWgPRnOGIqbjBJYXdNuSU/oERU33me0I8L MZ2ldAtzLqcxmv5BN60zfqNplQZ4gMisvS2q7hjEh/VrDhMuT7PqnDS46TGX9SpyaxTP BcFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703447986; x=1704052786; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=UGqMK51hD+V1BegjnWp7QD6aG910jqLFl6edC6M0Rxc=; b=wEOeNaCCuKkepbYCwArTddhHsDk8vnpKm4Whs+8kfyMOKmhBZOStPWqHwVcykov6FG EsP7e7gSAQRH0KYUTXBh0OVDyXy+CwdGy0zDGOxJ1S16gUQ9wXrjkE32PkUBLsf7xiz7 nXVgrCHw3zke0bzD+6UmLiDHjF9nepq5Q5wy3Blx2vSBBNSBrCZZfWoU62N7RMnI2br6 ghlbW3bu6PJrvvK866lWuvuCGjLcn63rxkT1t0kVIUEkl6nspbAkporQOyse7InYDKXM kTmHIPyxeL6kvu/QEjX1B3V6cnfF58Y/kzQSApPOWaZY+uuLA1rJPZHSiVZYFSWftzxL Ml+w== X-Gm-Message-State: AOJu0YyujtF+PKghFjLbSDA6MN4DPdJkUlmqder0F399f0TTCTh6JUVy 1NDf9wqV63ic/E8Cu8HuPBxWdeujDLP1zxiuHDqhPh1OBZMcffzE X-Google-Smtp-Source: AGHT+IFnlcjWKixFBCO1Bzjh5ArUM6m6mkmMJ5modlGV+ah0ge2FZdeGSzi+hB0q6YGo1JHX0b/3jugCCqVY6RRpa+8= X-Received: by 2002:a05:600c:3ac3:b0:40d:492c:a378 with SMTP id d3-20020a05600c3ac300b0040d492ca378mr2239969wms.191.1703447986140; Sun, 24 Dec 2023 11:59:46 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 From: Mario Marietto Date: Sun, 24 Dec 2023 20:59:10 +0100 Message-ID: Subject: Let's install FreeBSD on my ARM Chromebook To: freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-3.75 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.75)[-0.747]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::336:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4SysM86t8lz4vl3 X-Spamd-Bar: --- Hello, I was looking for the proper source code to install FreeBSD on my ARM Chromebook,so I got this : https://cgit.freebsd.org/src/snapshot/src-d440ef2d7314a383e299ef86144b2879d80569e7.tar.gz (this is the tutorial that I'm following : https://wiki.freebsd.org/arm/Chromebook) I see that this code is older than 9 years. Do you know if there is a newer and less bugged code to try ? thanks. -- Mario. From nobody Sun Dec 24 21:00:22 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Sytj26zTjz54TMM for ; Sun, 24 Dec 2023 21:00:22 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Sytj249wNz3GkY for ; Sun, 24 Dec 2023 21:00:22 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1703451622; a=rsa-sha256; cv=none; b=UejBHlcjnloLyyGkIITb0d8klrkx2AlFC0MIM/PlaGuJHHW86MGDUz1xk8y+yxQsvKYTp9 m961+9zv5YOAhGbCq34jcvn7Q+Y53mffc+3wrD+/ZnrwF/HoZGCPoJ4Mhip1TBi5lzAQIw WXDiV3MM5knWD06b19GO6pJlaF02FJiHnksxX3cfoAKGCRBUWwGlHpYVd8uo1+W3eOH4Zp khsa4hgtyYI9WqlwlkQecRWAzavEzbtLo+M0hnaUToBMt39Xf+sq0i1RwOAZ6wUd8Jj42s 9mD2PqwEZFpDMogBVSe3MXzjzhxn/DUDoLQqlbiTpk81UFDFqTcpxoV4g9flsg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1703451622; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Tc078mXNMbycwE8toaIkGAVThVMwb5rfsFvLk8h90S8=; b=djdKsmKwJPhJZDBWU+Myxo6q0379wiM6s8puX847f/asNAfDc4Hidpdbh3sYn47EHnvn7S fzuF38nTvdb5EYVjODHJQQ/O7asPI7UgqCckKchseSXHDrmKcYizdzvA4nYZ/lHi5oz5Ob FPV6buGlaypAHkZzi0L6vjaWADheo4gTa09T+8cdo9z9F9Jh4QRqfMUBXS+drXnDLfHNNP nz2NyBmEyoRjiDiguODL7DZVN5zqFsPPYp/k/+AHFw8UyXIaCJPgx+wppN4zFhVnzA7ZFR indMa3CZ1qaqyegktMI2R5DGrCAEeeAQoGLy20Aeoq73aenHagsiBTnIeQVS8A== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Sytj23JCpzjr1 for ; Sun, 24 Dec 2023 21:00:22 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 3BOL0M42072136 for ; Sun, 24 Dec 2023 21:00:22 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 3BOL0MSN072135 for freebsd-arm@FreeBSD.org; Sun, 24 Dec 2023 21:00:22 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202312242100.3BOL0MSN072135@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: freebsd-arm@FreeBSD.org Subject: Problem reports for freebsd-arm@FreeBSD.org that need special attention Date: Sun, 24 Dec 2023 21:00:22 +0000 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="17034516222.d68A.69967" Content-Transfer-Encoding: 7bit --17034516222.d68A.69967 Date: Sun, 24 Dec 2023 21:00:22 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- In Progress | 271990 | Panic: IRQ mapping table is full after stress dev Open | 238576 | Raspberry Pi 3B+ "shutdown -p" does not shut off Open | 257670 | mpr(4): SAS3008 PCI-Express Fusion-MPT SAS-3: Fat Open | 264574 | sdhci(4): Support ACPI attachment in BCM2835_sdhc 4 problems total for which you should take action. --17034516222.d68A.69967 Date: Sun, 24 Dec 2023 21:00:22 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" 
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.

Status      |    Bug Id | Description
------------+-----------+---------------------------------------------------
In Progress |    271990 | Panic: IRQ mapping table is full after stress dev
Open        |    238576 | Raspberry Pi 3B+ "shutdown -p" does not shut off 
Open        |    257670 | mpr(4): SAS3008 PCI-Express Fusion-MPT SAS-3: Fat
Open        |    264574 | sdhci(4): Support ACPI attachment in BCM2835_sdhc

4 problems total for which you should take action.
--17034516222.d68A.69967-- From nobody Sun Dec 24 21:31:56 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SyvPy07Ykz54XR6 for ; Sun, 24 Dec 2023 21:32:22 +0000 (UTC) (envelope-from joseph@josephholsten.com) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SyvPx3bKBz3Qmj for ; Sun, 24 Dec 2023 21:32:21 +0000 (UTC) (envelope-from joseph@josephholsten.com) Authentication-Results: mx1.freebsd.org; none Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id D38993200B03; Sun, 24 Dec 2023 16:32:18 -0500 (EST) Received: from imap49 ([10.202.2.99]) by compute4.internal (MEProxy); Sun, 24 Dec 2023 16:32:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pobox.com; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm1; t=1703453538; x=1703539938; bh=ShuyWEYYL3 L5AoT0mw7wlrhNp0i80IK4uSBGq+JGydk=; b=VLanaUn3E9UNE3fpoy5xfEE+it W/kGkKh4+AUYsB7XESCUNDPukaAxiqawkTY4OB2cpzsClA4nSQMp40BiCwvzD3pH seJQMiB9a6FyDWQCekboT22zukCzwmWFre/8Lk16+kA9/cZFO6vXU5gav/Ieg4nQ LZNLjwImhR6fO9M37qa6pFqAg0HDs7u7bju79Tr6zKfI03IpLgvwWvwT7kpj4Nmb b1Wl4YNsOirN/qlccAS84bTnE0bYiElT2VBqwEhmyvdJ6VRxskw7RDqcxqf7tixQ Y+9YWySXp6GVY8vGTYTX0vW1DFiuy6IcpIcM3k9KhuSqpJHojQMOBIH0HRAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1703453538; x=1703539938; bh=ShuyWEYYL3L5AoT0mw7wlrhNp0i8 0IK4uSBGq+JGydk=; b=hANRtVHFN94DKIpWb1D21uRhoBi3f3NJ0Bcr8+Vi5o0i v+LTN/6/y3wIrl4ZY4FUWtsFzOtn+TLHvNDSNXgx5K0L5M4+FtMPRI8gxZASWMy+ hVTDXKYvZ1kp6S+GIycwL7P+3Iid0k40GBw3S3ih5m+BvCyu+zSE0zmWhEmoW5sw Jww6zsazkA7qh3AreHZU4Wu9SPw5wBEu0+9P6hvsrVtf1EVN9GLyRDObS8Bgi3f3 4M7AA7AnCz2cNRVfXwmEZsi02t8pAByRHml6XMe3WZpZrM0xCZ0X4RUq1pLpCKe1 uFSMXqMsvyNEL27KTTXwz09Q/GsLEbromrCTYiZZDQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvddvuddgudehtdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvfevufgtse httdertderredtnecuhfhrohhmpedflfhoshgvphhhucfjohhlshhtvghnfdcuoehjohhs vghphhesjhhoshgvphhhhhholhhsthgvnhdrtghomheqnecuggftrfgrthhtvghrnhepte euhfefjeetueegffeihedugeejiefgfedvudffieffvdeigfffkefftdfhjeegnecuffho mhgrihhnpehjohhsvghphhhhohhlshhtvghnrdgtohhmpdiivghfohigrdhnvghtnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepjhhoshgvphhh sehjohhsvghphhhhohhlshhtvghnrdgtohhm X-ME-Proxy: Feedback-ID: i49d34368:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id A74DD15A0092; Sun, 24 Dec 2023 16:32:17 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-1364-ga51d5fd3b7-fm-20231219.001-ga51d5fd3 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Message-Id: <50011576-256a-4425-9091-7ddcf0c1085b@app.fastmail.com> In-Reply-To: References: <16864054-4os0-pq3p-7qp0-7299666908os@fncre.vasb> Date: Sun, 24 Dec 2023 13:31:56 -0800 From: "Joseph Holsten" To: "bob prohaska" , ticso@cicely.de Cc: "Marcin Cieslak" , freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed Content-Type: text/plain X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SyvPx3bKBz3Qmj Okay you all, where should all this great info go in the docs? -- Joseph Holsten http://josephholsten.com mailto:joseph@josephholsten.com tel:+1-360-927-7234 On Sun, Dec 24, 2023, at 11:39, bob prohaska wrote: > On Sun, Dec 24, 2023 at 06:01:00PM +0100, Bernd Walter wrote: >> If you see ssh connections drop then this is network related and has nothing >> to do with the USB adapter. >> In case an USB adapter fails you will just drop out of tip into the shell. >> Most likly this is a statefull network device - e.g. NAT expire on either >> your or ISP side. >> TCPKeepAlive is active per default on OpenSSH, but often not enough for some >> agressive ISP equipment. >> You might also want to check if you have local firewalls in between, which >> are misconfigured to expire TCP states too early. > > The normal network setup is shown at > http://www.zefox.net/~fbsd/netmap > SSH sessions are initiated from the Pi4 workstation on the LAN to each > FreeBSD host, using tip or cu to connect to the corresponding Pi's serial > console. > > It's maybe worth mentioning that changing the host named pelorus from > WAN to LAN and booting release/14 seems to make no difference. SSH sessions > not involving usb-serial adapters stay up until the WiFi link crashes for > some reason. According to the router's (D-Link DI-524) control panel the > firewall features are turned off. > >> If you run through equipment, which isn't in your hands at best you have >> an OpenVPN or similar connection to handle network instabilities and run >> ssh on top of it. >> >> If however this is not ssh session dropped and just tip, then look up kernel >> messages if the USB adapter was disconnected. > > There are no messages of the kind seen when an adapter is unplugged or > turned off using usbconfig. I've tried turning on usb debugging, but the > output is not obviously related to the disconnects, in part due to volume. > Interestingly, a "stuck" adapter can usually be "unstuck" by using usbconfig > to turn the power off and back on. > > Prompted by your email, I noticed that under the Advanced > Filters page of > the router there's an option called "IP Filters", said to deny LAN access to > the Internet. Neither Enabled nor Disabled are checked, no IP numbers are > entered and all schedule times are set to zero. When I finish this email > I'll explictly disable the filter function to see if some default is making > mischief. > >> If yes and you have that problem with multiple adapters then this is most >> likely power related, especially since both systems are connected via ground >> and can have all kind of electrical issues. > > I do see what looks like noise on the serial lines, but only after a spontaneous > disconnect and only with FTDI adapters. When the serial connections are working > nothing resembling noise is seen. > >> In some cases it might be required to have an isolated adapter. > > A close look at the connection diagram will reveal a loop connecting all > the FreeBSD systems via the serial port grounds. Breaking that loop by > lifting ground on one serial cable ground made no difference. > >> That said, beside all chips work well. >> There are some bad boards however, which are unrelated to the chips themselves. >> Also at least with the PL2303, CP2102 and some FTDI there are fake chips on >> the market. >> Other than that you might need specific features, some FTDI and CH340 can do >> higher bps rates, which some rockchip based boards may need. >> Also FTDI and CP2102 and a few others can have uniquie serial numbers, which >> makes them easier to identify if you have multiple. >> That's the reason why I like to use FT4232H based for my bench tests. >> They can handle higher speeds and have serial numbers, plus they support >> multiple uart at the same time. >> I also have lots of CP2102, which I build myself and know those are technically >> good. >> > > That's helpful information. It sounds like there's little preference between > pl2303, ft232, ch340 and cp2102. > > Thanks for writing! > > bob prohaska From nobody Mon Dec 25 17:45:51 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SzQLR50YTz554k9 for ; Mon, 25 Dec 2023 17:46:07 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4SzQLR1mqCz4X6Y for ; Mon, 25 Dec 2023 17:46:06 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 3BPHjq7F024399 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 25 Dec 2023 09:45:52 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 3BPHjpPO024398; Mon, 25 Dec 2023 09:45:51 -0800 (PST) (envelope-from fbsd) Date: Mon, 25 Dec 2023 09:45:51 -0800 From: bob prohaska To: Joseph Holsten Cc: ticso@cicely.de, Marcin Cieslak , freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed Message-ID: References: <16864054-4os0-pq3p-7qp0-7299666908os@fncre.vasb> <50011576-256a-4425-9091-7ddcf0c1085b@app.fastmail.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50011576-256a-4425-9091-7ddcf0c1085b@app.fastmail.com> X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SzQLR1mqCz4X6Y On Sun, Dec 24, 2023 at 01:31:56PM -0800, Joseph Holsten wrote: > Okay you all, where should all this great info go in the docs? Probably under the heading of "inexplicable miscellany" 8-) In the meantime there's been a new development, maybe. Overnight all four of my ft232 usb-serial sessions dropped their ssh connections. In addition, one session using pl2303 dropped also, the two remaining pl2303 sessions remained up. On trying to reconnect via ssh to the host using the pl2303 adapter, the first connection worked with a long authentication delay but a second connection reported bob@ns2:~ % top Corrupted MAC on input. ssh_dispatch_run_fatal: Connection to 50.1.20.30 port 22: message authentication code incorrect This host is a Pi2v1.1 armv7 running 12.4-STABLE FreeBSD 12.4-STABLE r373269 GENERIC arm Re-try was successful, but I've never seen that error message before, does anybody recognize it? Three of the four restored ftdi sessions had garbage characters mixed up with the login prompt, one was clean and the restored pl2303 session was clean. The two pl2303 sessions that remained connected showed no upset of any kind. Thanks for reading! bob prohaska From nobody Tue Dec 26 00:02:50 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SzZjT6wxZz558dy for ; Tue, 26 Dec 2023 00:03:09 +0000 (UTC) (envelope-from saper@saper.info) Received: from q.saper.info (q.saper.info [IPv6:2605:2700:0:2:a800:ff:fec7:5c61]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "q.saper.info", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SzZjS1wVkz3WJ8 for ; Tue, 26 Dec 2023 00:03:08 +0000 (UTC) (envelope-from saper@saper.info) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=saper.info header.s=Sep2014 header.b=MLoNd2kN; spf=none (mx1.freebsd.org: domain of saper@saper.info has no SPF policy when checking 2605:2700:0:2:a800:ff:fec7:5c61) smtp.mailfrom=saper@saper.info; dmarc=none Received: from q.saper.info (localhost [127.0.0.1]) by q.saper.info (8.17.1/8.17.1) with ESMTPS id 3BQ02p9q041529 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 26 Dec 2023 00:02:51 GMT (envelope-from saper@saper.info) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=saper.info; s=Sep2014; t=1703548971; bh=cjjfJUExh11FtiX3M3+zqCFZrB5R4BuIgCr86y7Lcr0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=MLoNd2kNjLKPcLyhGlImIYp+I/Qp1/E7O4z/q15G4JzDYGmxMPOwZV2mkbFnBAMCN 1i3I7GiITJfwmhNy6zt2qyHPCVAyi1vTIwlwrUfC0+5NyLG3MMbHXLyVrakaXYQykt Q9XRwMl+YHdnG01Vz+gGoW4OJscb1Oo50+BumEag= Received: from localhost (saper@localhost) by q.saper.info (8.17.1/8.17.1/Submit) with ESMTP id 3BQ02oo1041526; Tue, 26 Dec 2023 00:02:50 GMT (envelope-from saper@saper.info) X-Authentication-Warning: q.saper.info: saper owned process doing -bs Date: Tue, 26 Dec 2023 00:02:50 +0000 From: Marcin Cieslak To: bob prohaska cc: ticso@cicely.de, freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed In-Reply-To: Message-ID: <55q37289-ss30-nq9o-7r31-086n999p394s@fncre.vasb> References: <16864054-4os0-pq3p-7qp0-7299666908os@fncre.vasb> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="2201072851-1597646955-1703548971=:2993" X-Spamd-Result: default: False [-5.40 / 15.00]; SIGNED_SMIME(-2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_DKIM_ALLOW(-0.20)[saper.info:s=Sep2014]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[saper.info:+]; DMARC_NA(0.00)[saper.info]; ASN(0.00)[asn:47066, ipnet:2605:2700::/32, country:US]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; HAS_ATTACHMENT(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; HAS_XAW(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4SzZjS1wVkz3WJ8 X-Spamd-Bar: ----- --2201072851-1597646955-1703548971=:2993 Content-Type: text/plain; charset=US-ASCII; format=flowed On Sun, 24 Dec 2023, bob prohaska wrote: > I do see what looks like noise on the serial lines, but only after a spontaneous > disconnect and only with FTDI adapters. When the serial connections are working > nothing resembling noise is seen. How does that noise look like? Did you try to run respective sshd daemons in the debug mode to log disconnects and possible their reason? --2201072851-1597646955-1703548971=:2993 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIOdgYJKoZIhvcNAQcCoIIOZzCCDmMCAQExDzANBglghkgBZQMEAgEFADAL BgkqhkiG9w0BBwGgggq9MIIEvDCCA6SgAwIBAgIQeEqpEhjRpCYIUTzTZlVD ozANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQLExdHbG9iYWxTaWduIFJvb3Qg Q0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMKR2xvYmFs U2lnbjAeFw0yMDA5MTYwMDAwMDBaFw0yOTAzMTgwMDAwMDBaMFsxCzAJBgNV BAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTEwLwYDVQQDEyhH bG9iYWxTaWduIEdDQyBSMyBQZXJzb25hbFNpZ24gMSBDQSAyMDIwMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvxvJBqEapaux2/z3J7fFslRO WjKVJ5rCMfWGsg17dmD7NSnG7Spoa8d3htXsls1IMxoO8PyouQajNQqYmlYo xinlqenMNv7CJyEKMOAtglBmD6C/QC7kT+dSx4HfSTs8xmv8veJOldMzF8S/ BEn/tD4w/Dvpg+oXOqDyOiHPTacRFK0QHoq5eEbBmVS8W0rwcaRotO9fGTA+ NjF0My7GLRNK0eMPGh2hcPZURQhXy7wRQ8XFIfEA6kaQHHN22ncnVtwqiTmA wTR+4GNNVinG3KjNZLAVSnGrdCvT2I4Zo19hKy5PX6o7wrVXvMR4zV5VBFwV 6ZDM+xewao7Mup+SbwIDAQABo4IBiTCCAYUwDgYDVR0PAQH/BAQDAgGGMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/ AgEAMB0GA1UdDgQWBBSFu/DMxDa1CmJ2o5kuj7s6aq3FUTAfBgNVHSMEGDAW gBSP8Et/qC5FJK5NUPpjmove4t0bvDB6BggrBgEFBQcBAQRuMGwwLQYIKwYB BQUHMAGGIWh0dHA6Ly9vY3NwLmdsb2JhbHNpZ24uY29tL3Jvb3RyMzA7Bggr BgEFBQcwAoYvaHR0cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQv cm9vdC1yMy5jcnQwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9i YWxzaWduLmNvbS9yb290LXIzLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIB KDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9y ZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEAWWtqju12g524FdD2HwUX U1rSxeM5aSU1cUC1V/xBjXW0IjA7/3/vG2cietPPP/g3lpoQePVJpQAKZml8 1fHwPPivFK9Ja41jJkgqGzkORSC0xYkh2gGeQg1JVaCzcrRzJElRjT442m6F pbLHCebxIHLu0WBNjLZreB6MYMaqdPL6ItbXtD/BU4k517cEuUbczoBFZAra jq7oUBWXuroln5AMnRwVNwgJN4Np0s4kkJ94KepzbFOLzcbnfUB0+xT4foXm bM0GmmcPGOy0qvqEHJsBwDZXDxIk8oqCnnLngi7N94Sn4eTcmpZ9NH2dDN1O TEPVXgRG5X1pBcNtMWG6MDCCBfkwggThoAMCAQICDCKqoJRMYYx5sYJHGzAN BgkqhkiG9w0BAQsFADBbMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFs U2lnbiBudi1zYTExMC8GA1UEAxMoR2xvYmFsU2lnbiBHQ0MgUjMgUGVyc29u YWxTaWduIDEgQ0EgMjAyMDAeFw0yMzAzMDcxNjExMDlaFw0yNjAzMDcxNjEx MDlaMDwxGTAXBgNVBAMMEHNhcGVyQHNhcGVyLmluZm8xHzAdBgkqhkiG9w0B CQEWEHNhcGVyQHNhcGVyLmluZm8wggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAw ggIKAoICAQC8MB3fTYVrTadH5qE2CIa4VLvlL6QHgDriMRLkTA49SPszYCO0 fZTEpdSw8fc6kK9p2fD63LAfOHeD7jzey5aHBzpIGlxeFkn0Ce2BCYY5yLxK i9byoCwrpLchTR1Itpk1w+zy5E4T9KBTL1+c+w+TKpaIvFLXtjZtz4wQGi0p e/nRkRK9htGG3mETh+APitedl+ImGaI8NK9PELxuSkXnYAvGPpnXir8vbszk tJU1b0TevL/i3Sy6fhOhunZmTo1QDM7Zw4UyVjkQgTvL3y4I0tIrVjlam08x XZeMp+i/Gl51eHGvRVfvdJUJAjrWhrFEp8+2FZouWxWzAlHdd2sRp1AekNdP CeRgHeIF6uNtSseL1grKAjU+4BiixWPp1y1niB0humoQHoub/6fO/mU+//rW l3gTwZNu4FuKgZlfPw+qnvuka0c9dUNIZRCE5z8yXjS8R9yZWirnHNhYxf/e R2y4jaiHzPAjZlZZ2rGx8xVfB2n2JsAicj2+ZxmXlQ1yd5RW1pfxG3cdNNC5 uZ+j4JIN2ElsIjEKmMn9gHdoaEMAy/ENwNiMDBadLnc8qWirq/Ktp2dBSf2y /sH9xMpVyk8wuYjpbCnX4xslAensno5A20MYdKGPRFaItEhNPNbfzc1+4br8 exoXFX1F9ZJK9gGUO2nLbdRycphdyzxzgQIDAQABo4IB2jCCAdYwDgYDVR0P AQH/BAQDAgWgMIGjBggrBgEFBQcBAQSBljCBkzBOBggrBgEFBQcwAoZCaHR0 cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvZ3NnY2NyM3BlcnNv bmFsc2lnbjFjYTIwMjAuY3J0MEEGCCsGAQUFBzABhjVodHRwOi8vb2NzcC5n bG9iYWxzaWduLmNvbS9nc2djY3IzcGVyc29uYWxzaWduMWNhMjAyMDBMBgNV HSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3 dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAJBgNVHRMEAjAAMEkGA1Ud HwRCMEAwPqA8oDqGOGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NnY2Ny M3BlcnNvbmFsc2lnbjFjYTIwMjAuY3JsMBsGA1UdEQQUMBKBEHNhcGVyQHNh cGVyLmluZm8wHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB8GA1Ud IwQYMBaAFIW78MzENrUKYnajmS6PuzpqrcVRMB0GA1UdDgQWBBTW/RrdlRFR y6MgS7liTThMnQA5ozANBgkqhkiG9w0BAQsFAAOCAQEAAwoUJShHMueocVlD 1+vYJbTTTbk9tabr2L4Iyyy4Btu1d1wwl6d9Yx2N9qaVERWcEeP0aR+NB2B7 xIKl/ZnZVuSxep0Raw4s284a/jSIJlsAi4SJItDCU2VrYJDWxP7MxzZHnzPI MLDoTHXPV18gvYTewoNk5/Yo89Kb0v/GpPTpP2sVdrWLHa4uKUHYrAZ0aByp kNw6lXp6o6DXvXaOd6KDTQN5XhmmHwLnuLceODF1t9gicsZIOY+KAxN6YZ6t EqwN48b4OFMpckDE3fm1iTZRqnEIqUHOKOcoCImkub1woEN0zXDQmLXaZigl uVztWSTM4/fapWLrlHBNxfjs1TGCA30wggN5AgEBMGswWzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExMTAvBgNVBAMTKEdsb2Jh bFNpZ24gR0NDIFIzIFBlcnNvbmFsU2lnbiAxIENBIDIwMjACDCKqoJRMYYx5 sYJHGzANBglghkgBZQMEAgEFAKCB5DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0yMzEyMjYwMDAyNTBaMC8GCSqGSIb3DQEJ BDEiBCBkerHg04oLQM8yZAVVyYjdWIbqfwD94aejRc0sZF1UbjB5BgkqhkiG 9w0BCQ8xbDBqMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUD BAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAgBQ inrfnofEPO4iOh3WkP5VLjqvVbGJDEwNPTyVRhIv6UmY6xmdbL1Rj+oKo30H HN/jETNUChrs3bMHXyTbD7U4ClfvfA3h7LRu6AWI1ULQ5/y/K4qVtPAkBcns KCFoezcvrFyl9gPwM2j/QWIqTlYehtbqMbUKyl13AI2YQQDU3E0lgG77hoT4 3rnWxvHLUp2eMgztvccNgcDOanFhfHssPOrwD+vo89lEup9QKEWVFx7q0Xmz z0JIDrbCVTVEFb+xBMuwv89bRjbz5rfM0eQRhmpJVEK5dbtfGBFH4StIT9Kj IvICXA88RDCk2lpx1o9FngMWSBmrewG56YbOI32TyfbTT/1vqJGlo1JRab90 cv9SUvB4HcU+fZL6qsFa/8BYuGPXMjxai9ttcrKBzEH5GTOnJvjghr5oeA7D 6ER63UKSBDrpbR35PaagZMvgI7i58BYPdV6ygi9+44sOnkC0owfjntw6X+wA ruScIhgPxtZSSnG4wn4P5dr5SApQXtGbXOSr2bMIVjU5iaC9OzsU6F+dKG6D TkdCad5bm08cbqJPw6js5+ZtupW6qv3Q541aO1ypQbQJakkL6I3jYbFAk+/P 1ReCQVfEoFwNjdDLEMMivTMQWgZfNjsEoKI+PvIJPwzC2Ek0z0+wnuZ4cwFi ZVMDzECC6Cas0DQ3tflNlA== --2201072851-1597646955-1703548971=:2993-- From nobody Tue Dec 26 01:04:47 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Szc4w0CCsz55FC8 for ; Tue, 26 Dec 2023 01:05:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-8.consmr.mail.gq1.yahoo.com (sonic308-8.consmr.mail.gq1.yahoo.com [98.137.68.32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Szc4v3qknz3cCB for ; Tue, 26 Dec 2023 01:05:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703552700; bh=UlvW/RBDwgJSbJIwUzhfbXXXZ380xqkURNblEUqslMg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=nggistvqZwcD+spJ2LLwFWZBlyFiul06IeCf2CPlq0z/OmizsCMXagq7mbIlaJYIhzWpK4K8Q7f9iiirUO1JhuaUKEt8KwOF6X+Z6DRe8hXYxaPDEbVa+dQ2ekSDUdH8uZUZhhkDJioTIkLT2Fb+HnUIMYwUcmrN0Ao3bi5mRAK2ECRxNvMnCN3+4NaIQZpQj/VJ6Ejp+v6ukg+1W/1Tjme9X98voQAOThaXySHiYo3WanbmObgCfq85NUFXL1/S4+T6lrI3Yqe9732Z6uZyJeIK+t/21ohdXwl5ItU1ietjmpG8O8MYArC0pDAy41wex46Bl0x/GUSWDWhZF8x84w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703552700; bh=vXXVOwwZIc1X3KiSbeGZpJBZVvilcLztrZzQeMK7/iX=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=eGHcc4fDSklclBfNIN+hEq3daGwtFavGgr3pXq5mXkS/4iU2bT2dy6+vWtElqXDAGVuZekV2dYjM6XdvzwiJLJ1ZIsG+Qt8tLU1xqMYENCBW6ec7kncOWsjV4LTFtS0FaU3nmJCQp17YuHNS39Blkn8xs6ZiQSqgbDKhZKHfJuMiPwFfmz94MwmH4j7Kxrsjgc7vn2GWtjgOdUoTZLptOIC1uSGgZrjOzLC7ot7wgz1FzeGfvdeGHwKq4UuYNGNO9DxVreSsKW7Urd0Hm3lWxkUaXWcu2u/M9A+sENm/L5JfKwWLa0tEW9/4aeAujrH663NCHnUqMbI+tHUDOKHlJg== X-YMail-OSG: IN2MHPUVM1nBcjippVjCUVNPDrUQ166BIv_x3wzGcZ0oKlQSgq8ki9S3KeKZXfk Q.OppTdsV3v.mq7ZVsj0a4zbytT9U9L2w1atpziyIip2luV98CM3sABSr2QlDL8LAY_B__aTSB4b Ifj4OBWDRt04NUBmkGSC5V2EuY7WAgwzTfoCbV4kSfz1zOiCMDLnRV0_UEUC81k_adHtKHR5ODHn q0.w95RFYLnY_8hlgW3wWXC_q4PlUFCTMFUn52TKKaSSw6mHJ_ZBd9VYdjLiKUdSw1svQeGMOFzO nRV6EY4_lr_56apMRN.D80FRgpBawSa7ZzcYmpOdDSNEQbiXiarn72DB2hR2DXStM5T3BzIyEEpH 8c2WA0DThjFpPjhCzAGAJ7v_fhNhU9ahq0ipd7Jz8ZlEsk5KfFU6EJuXyB3MIo1kw7pZwnb1bzG8 ehcRN2Juo3tQBiRNoYgc_zluKLnSorLRiCS1FvRvbBrLe03UT6.sf2xuwJQkCEXLK7e4gUaaH8ZE GyVTYdm8g20YwvwTvEeEDnY6goM2HjB5k2xcAU9OpyeD6HpcZfx4yD9k2C5c5vgup.6wOQpc.1DW vWQHruQ225QMC0TbPsy4oOyFjofj9q8i.C29aGSprsoh.XtprIBrAWCWkt9pL7vUmXsPy2oOrIEL 5_o2Woh10.MkM5WR5J1Thiwn8mNvhL6ftmW9WKM78JRdj5anpm5RVw5V7qP.hgQOFOhpmO.lM31x mSfuRofuoF.PANtllm_9j6RUTw5HR4k21ng0G0JVerluS8Hyy3nuC4ysHCZ_2SUI5cucIBO8pL.E nTPEMDF6K7iULNBpc_.KLhm.FooZvi8Dj1_Do4k7DYOv.uIIcyN_Apf4miAlXCl94.5El139wtWm nQxJbkb3dF_gn5BBTpBaWs1q1L8lS.BHxEKzQZ4MbGmKOmsEuNtyptwPPi5DLmE8EKm8zBuO6d0_ BTlo8c.iM7EpOJLx9wKTTwwvZKuhDX0jKs7SQK6d96kdDXaZzxocgjhGuNgn60KwTmy4Z_JEdMr3 oh5A7TYiotF_8Hp5BZD0YCNpBUT8ROoJdXK47hPNYQUH.2V.ZGaL8TKrTWfuVx6aGo8uVg9Sn7pI 0.rwAZ9TXz69LRabFQAQMaSewZ_qb0lzPjuamlZDJ5jOSPZADmCpfh.6ZyO5N3UNi1FfP2eKXV7B ULJ0EG_krd7qQNYNfXppx578l7GcRth8eL719czfFHEzQnzliD3YZWl8f1QvdHfycgyv_GvkvBQE eMudNsgmu6AU8ZoWQufrQIjIL7AmGyBCBHCU9pE0cJaiU8zcbDJnGbwBmCGLSfvDo08v4qnz6ZfZ 9NDEHIJTfcOQ2gbgQaW4ddYkgmFojqr4IKFcHZq2llxwVTVgi3_1KAV0Dx.sS.9nr4MU.2WN7RLo a6koqnogMfq734OhMplrAQT_8YegLn1vbCMIGnbqs4MuYRkKRVGnz.irtNPfooQYPE1jXCVloEjE x6Bki1ykD6f2_rfahFZbo9QXjrdyhNCHTeZgcU8UoT19o1.tdQiIzLHmulpJwF6xyzC6uMXOM7QH brPl5IK3WSxKIt6oo3y2O8dg2lwe3C29R7mlYX.f.14ForxT_HYr3kimVe_PMb2GGhNs0.dDFAND 9HHUsl5ET.vE8zrWjwoCctEaYvDoEJAj_HW.o9rquZQAZvDGnWFHhK0x06E5WIT5khMsX.Pu8wwa fYr5_f2PawH8fV4NHbIjjlFVz5Fgd4_95IxUqRunoloQaREsGwUUdueMFP7f4jLn9.Zu3ZUJsbuq TRf87jUl9b9FP9rUBaZrD9N_irTlij3rv6vd8bhcHT0nDNn9NG_5uQ2Us9aB8AvtvAFrR1diplPL IZ5Yyw27lZaKvqw0wJZEO6YAOiE4BBsIvFVeTubull8a3yCdwcJeMvk7lRj4AmU6m_RBVPlE4bAI 7inU_Fu1r8AYIVqtWR7s7N4O72dKg2P8a5Nc9LZcecUfDN3Tr7xz3Y9xeedSpOzLGi75efZezNwa jwjRBdwi57FB8ZTAaaqvCnQXSIQGwNpQgnFWmkbBPNtSlMEYOTZINgelg7D7HRAomk0tFkOFaIcW 7dYgdnbISktP09FtuLiPSUw7lJNUauD98Bmg2akmBJDNCBc3qo8xvEBTN.jZgEGKMqQ1grYiGTF6 I8GF.yFf9785eFb40ZbpY0Elz7Q184qFhBsHYvAewDpmvV4w1nbB1LPwb_OM2O8MQJTQa1__.vk4 oBPAhrJEMVSU9eFNV.tAQKldtVp8Uebv0ELlw3H1.qQJLp0gi1FqY1suH_ml6S9RjgynN0B9G5zw 6 X-Sonic-MF: X-Sonic-ID: a6903140-2be4-493c-84f6-bca154d40a28 Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Tue, 26 Dec 2023 01:05:00 +0000 Received: by hermes--production-gq1-6949d6d8f9-bvfr7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 868e2ba519c67b42f3b4e2d48bc5791e; Tue, 26 Dec 2023 01:04:58 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: USB-serial adapter suggestions needed From: Mark Millard In-Reply-To: Date: Mon, 25 Dec 2023 17:04:47 -0800 Cc: Joseph Holsten , ticso@cicely.de, Marcin Cieslak , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <5B6EE00A-3E69-4EEC-BB66-259EC9833841@yahoo.com> References: <16864054-4os0-pq3p-7qp0-7299666908os@fncre.vasb> <50011576-256a-4425-9091-7ddcf0c1085b@app.fastmail.com> To: bob prohaska X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4Szc4v3qknz3cCB On Dec 25, 2023, at 09:45, bob prohaska wrote: > On Sun, Dec 24, 2023 at 01:31:56PM -0800, Joseph Holsten wrote: >> Okay you all, where should all this great info go in the docs? >=20 > Probably under the heading of "inexplicable miscellany" 8-) >=20 > In the meantime there's been a new development, maybe. >=20 > Overnight all four of my ft232 usb-serial sessions dropped their ssh > connections. In addition, one session using pl2303 dropped also, the > two remaining pl2303 sessions remained up. >=20 > On trying to reconnect via ssh to the host using the pl2303 adapter, > the first connection worked with a long authentication delay but a > second connection reported >=20 > bob@ns2:~ % top > Corrupted MAC on input. > ssh_dispatch_run_fatal: Connection to 50.1.20.30 port 22: message = authentication code incorrect Are there other historical examples of usch messages shown by: # more /var/log/auth.log FYI: # ssh -Q mac you have mail hmac-sha1 hmac-sha1-96 hmac-sha2-256 hmac-sha2-512 hmac-md5 hmac-md5-96 umac-64@openssh.com umac-128@openssh.com hmac-sha1-etm@openssh.com hmac-sha1-96-etm@openssh.com hmac-sha2-256-etm@openssh.com hmac-sha2-512-etm@openssh.com hmac-md5-etm@openssh.com hmac-md5-96-etm@openssh.com umac-64-etm@openssh.com umac-128-etm@openssh.com When I looked I saw references to system load being an issue and switching from the likes of a more expensive: hmac-sha1-etm@openssh.com to: umac-64-etm@openssh.com solving that message and such broken pipe issues for at least some contexts. # ssh -vvvv NODEID apparently reports what is used in its debug output. You might try something analogous to: # ssh -o macs=3Dumac-64-etm@openssh.com = NODEID Apparently one can use MACs lines in /etc/ssh/sshd_config to control what is used by default. NOTE: I'm not expert in this. https://en.wikipedia.org/wiki/UMAC = reports: QUOTE A specific type of UMAC, also commonly referred to just UMAC, is = specified in RFC 4418, it has provable cryptographic strength and is = usually a lot less computationally intensive than other MACs. UMAC's = design is optimized for 32-bit architectures with SIMD support, with a = performance of 1 CPU cycle per byte (cpb) with SIMD and 2 cpb without = SIMD. A closely related variant of UMAC that is optimized for 64-bit = architectures is given by VMAC, which has been submitted to the IETF as = a draft (draft-krovetz-vmac-01) but never gathered enough attention for = becoming a standardized RFC. END QUOTE There may be better macs=3D??? alternatives for the RPi2B v1.1 for all I = know. > This host is a Pi2v1.1 armv7 running 12.4-STABLE FreeBSD 12.4-STABLE = r373269 GENERIC arm >=20 > Re-try was successful, but I've never seen that error message before, = does anybody > recognize it? >=20 > Three of the four restored ftdi sessions had garbage characters mixed = up with the login > prompt, one was clean and the restored pl2303 session was clean. >=20 > The two pl2303 sessions that remained connected showed no upset of any = kind. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Dec 26 01:06:59 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Szc7S076Mz55FFC for ; Tue, 26 Dec 2023 01:07:16 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [IPv6:2a02:21e0:16e0:fe::101:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "raven.bwct.de", Issuer "raven.bwct.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Szc7R46Bjz3cYD for ; Tue, 26 Dec 2023 01:07:15 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Authentication-Results: mx1.freebsd.org; none Received: from mail.cicely.de (mail.cicely.de [IPv6:2a02:21e0:16e0:20fe:0:0:101:c]) by raven.bwct.de (8.15.2/8.15.2) with ESMTPS id 3BQ170QL037364 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=FAIL); Tue, 26 Dec 2023 02:07:02 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cicely.de; s=default; t=1703552822; bh=mIBsbNICy3iIFmiWDFZl0VoYEZ/RoJa6ulK2Fq9msCE=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=bmkK5ilb/X1c3eFRCUw6h0nP7zWbhX1C1LBTMjIMEIjEEX8m1bQ917QfQT35/RbiT lDRHY4Us4rYbAdXtTznj97mhdtPFXv7S7qUL8nRyEGMMJSAxSj4xBAEJ1+5gyk01p9 FbX1VhMsJXtHguWSf4vTUJsuB3M/qs+9LL/iSwaM= Received: from cicely7.cicely.de (c7-old.cicely.de [IPv6:2a02:21e0:16e0:20fe:0:0:101:d]) by mail.cicely.de (8.16.1/8.16.1) with ESMTPS id 3BQ16xTF001131 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 26 Dec 2023 02:06:59 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.17.1/8.17.1) with ESMTP id 3BQ16xvJ039705; Tue, 26 Dec 2023 02:06:59 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.17.1/8.17.1/Submit) id 3BQ16x21039704; Tue, 26 Dec 2023 02:06:59 +0100 (CET) (envelope-from ticso) Date: Tue, 26 Dec 2023 02:06:59 +0100 From: Bernd Walter To: Marcin Cieslak Cc: bob prohaska , ticso@cicely.de, freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed Message-ID: Reply-To: ticso@cicely.de References: <16864054-4os0-pq3p-7qp0-7299666908os@fncre.vasb> <55q37289-ss30-nq9o-7r31-086n999p394s@fncre.vasb> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55q37289-ss30-nq9o-7r31-086n999p394s@fncre.vasb> X-Operating-System: FreeBSD cicely7.cicely.de 13.2-RELEASE-p3 amd64 X-Rspamd-Server: rspamd.fizon.de X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:44700, ipnet:2a02:21e0::/32, country:DE] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4Szc7R46Bjz3cYD On Tue, Dec 26, 2023 at 12:02:50AM +0000, Marcin Cieslak wrote: > On Sun, 24 Dec 2023, bob prohaska wrote: > > > I do see what looks like noise on the serial lines, but only after a spontaneous > > disconnect and only with FTDI adapters. When the serial connections are working > > nothing resembling noise is seen. > > How does that noise look like? If the tip process was stopped by the ssh disconnect then the uart will fall back to its default bps rate. Some USB uarts still buffer received data in the chip itself, with the wrong bps rate. > Did you try to run respective sshd daemons in the debug mode to log disconnects > and possible their reason? -- B.Walter https://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From nobody Wed Dec 27 02:09:31 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T0FT86dNZz54pLp for ; Wed, 27 Dec 2023 02:09:48 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4T0FT8065kz4Tdl for ; Wed, 27 Dec 2023 02:09:47 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=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; dmarc=none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 3BR29WUt031523 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 26 Dec 2023 18:09:32 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 3BR29V0I031522; Tue, 26 Dec 2023 18:09:31 -0800 (PST) (envelope-from fbsd) Date: Tue, 26 Dec 2023 18:09:31 -0800 From: bob prohaska To: ticso@cicely.de Cc: Marcin Cieslak , freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed Message-ID: References: <16864054-4os0-pq3p-7qp0-7299666908os@fncre.vasb> <55q37289-ss30-nq9o-7r31-086n999p394s@fncre.vasb> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spamd-Result: default: False [-1.10 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_RHS_WWW(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RCPT_COUNT_THREE(0.00)[3]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; DMARC_NA(0.00)[zefox.net]; RCVD_TLS_LAST(0.00)[] X-Rspamd-Queue-Id: 4T0FT8065kz4Tdl X-Spamd-Bar: - On Tue, Dec 26, 2023 at 02:06:59AM +0100, Bernd Walter wrote: > On Tue, Dec 26, 2023 at 12:02:50AM +0000, Marcin Cieslak wrote: > > On Sun, 24 Dec 2023, bob prohaska wrote: > > > > > I do see what looks like noise on the serial lines, but only after a spontaneous > > > disconnect and only with FTDI adapters. When the serial connections are working > > > nothing resembling noise is seen. > > > > How does that noise look like? > It appears to be non-ascii. I can't get it to copy and paste in a way that's recognizable to me, but here's a sample anyway, taken from bob@pelorus:~ % uname -a FreeBSD pelorus 14.0-RELEASE-p4 FreeBSD 14.0-RELEASE-p4 #0 releng/14.0-n265400-4edf3b80733e: Wed Dec 27 20:21:26 PST 2023 bob@pelorus:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64: ........ # tip ucom connected FreeBSD/arm64 (www.zefox.org) (ttyu1) login: �������� Password: Login incorrect ........... The backslash letter pairs are clearly different, but they're displayed on a RasPiOS lxterminal window as a white oval with a dark question mark in the middle. Sometimes printable characters show up, but it doesn't look like my memory of a baudrate mismatch on a serial modem. Maybe that's just an artifact of modern character sets. > If the tip process was stopped by the ssh disconnect then the uart will fall > back to its default bps rate. > Some USB uarts still buffer received data in the chip itself, with the wrong > bps rate. > > > Did you try to run respective sshd daemons in the debug mode to log disconnects > > and possible their reason? I did, and didn't see anything recognizable as an error. It seemed the session just stopped. No errors, nothing. Whether it's ssh that stopped or tip that stopped seems to be the primary mystery. What I see is ssh stopping, but that may be more symptom than cause. Ssh sessions not involving tip/cu don't stop, at least not as often. Thanks for writing, bob prohaska > > > > -- > B.Walter https://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From nobody Wed Dec 27 08:30:26 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T0Pwg5rvTz559JR for ; Wed, 27 Dec 2023 08:30:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-21.consmr.mail.gq1.yahoo.com (sonic301-21.consmr.mail.gq1.yahoo.com [98.137.64.147]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T0Pwg3R7Wz3VnH for ; Wed, 27 Dec 2023 08:30:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703665840; bh=3TT98zaYGcgh/kLGPN2HbCqIB8EkumExqEzovQoP2vk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=BYuT3ZaMpSkiJ7F7gXoXO6vdDh40MeEv4zjbwQfH117Bm4QYxJVgpyW3gN7EYegkEpnFKQ+LsavFC964pyED5zlwG2LeGgDqiQFNwlZf9zlZ16yZvlMOMzUYqRvNKUIzNP7YKwy8DE4U1dE1qDLfFaGtIYLMr28zxaqo0yehKDqwOblwzNW2Fsc9uMoxdTZOSMkFZYZLJvEyvEFgHzY+16KMSUEH24s/DlawGSHpfWjgLnkidx5l6zA/8Ku0v7R/KbU1MPGPbwivcYqI8cBuljtIFdRcTdLPweFQ7f05hb0hbMG/9HHndWmB1mSw37AokV+X/p1bZHVEaizNqeRfiA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703665840; bh=SA5MYCXRI9S3dBTGxsLu5cfEILz2eOBhVkPF3r58oqm=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=daCPNrugYzTIBjbzJGrpYoHYH76Z0Vde9lAAX4mSeTi9K3Lb9q4kyW4uoYbRaKQw2/WuMjhxANdzodzh8t2DqOio3ekux8fGGYrI4DxDY4TufzMcMCvS+D2krbniFJA0CMpQLdtz4IaJjtF1LkhHmIpuCcv0oHeHjAizC6HNGMhWrv3J3n0HgBEp8TXKw2adzuN0qW7d48ZeFLuBUOj0q+O9kZIhyoMh+7Poh9jhsqFoEJ2u/EpF/J5cI+sS/pNE9hHipkYYYqKAbqSn1lWHD3llhburFitrxenvh3HezaEBYYzo5jrMC2Aiqb5ZQB3LrWtSx5UE3c+e83r9Goptgw== X-YMail-OSG: PTzeXaIVM1mdGZyQfdbVu1pYCBiJQz3KkeUUxLrRxe_xd0Ph4qU60Ui_w06A55E mubzuwZS9TQEb531F6dgR8C6DIugry0.642CvOs9HnOhityNrZclP8qRVKauc2bl2OSJqkzVNIxP tE5NrYqoHUA_uZABDg5b4xqc4oFVdP36wBA9isnJ1IK2d2pDt5hFlJxY.U_90VutOVT4IVGMEtSW uDKyGgXA7BqnxQic0w1pZmbkhiRZZeCGCQKozqPajqxN3dNc97O3J2_yqfGwdNaRsqfpPWPt4z2R n9khiKxpguHIEIuHYjFJH.M8jW4DkGw0a7ajpM_3UUkPWeDmrto2WI1h7ctbX0kAFv89dDMKLKVA 0NpRicANG4.JauPId0iq8.ZhRP5GBl7Q32foj8LZJm7cSfhdq1DawjWfsYxmSsYO8dk7eBw60_9T qJoKRBNNyg_QDJ4rp4tJFdO1SGL9PhWFIN8D4wzf9IDg5w_xju3.KDWcAKoCGw6lMUijJp2l94LQ Xb4CmrHrsCTgmF9i8ZeUqOT1F_Nf6yV9LxAT5Ekn2xLqVwfGw0Nc8N_iAhilillxj_VRWXa.UEzP MO34Gp01sMVi_6HrKx0jSSH2zBvuusVbX.4bj8L3YEWPqDa7yulTCsU8YgPKNspcQIVbNGftOCQd yG.9wPI3xUCBhjgJiwNrDzBQawvvykYVUkPZvQJPhCJcVO0MBX0EyXSsRrcrvbOS42ZiXZPl19J0 gmVS2kHndWY.TlhF6G43hVpwBarb3TW.7FxdGO.OoNDFLrB2cxJUDE.RW3juSmsO3P4uHM1kmBv2 x3aVABmkpfBaNatoZublw1lD2gJu9uJvybwERPPWLa6kQuoFMigtcArbxhyn4xED51MatRX2LY2t ZSz276nDiF4dbTCpNc4gS3ceNrJlPMNW78e.e2NCsND4havCuRtaN7EW4WTExtode.yD3bzDTFpK f2S1g_VthJ17msAbP2KA7y2iJxXnf.SrXn1MZaw3R3mC66ILGSBkpl1NrIwnNS6OB7cyoeWqZeXA v1XLZG_d845.tGsPB16NZbdBmAyDzO6LTsr3kmO.MT2fjw7LykDVa2gYvFIgbDISLJusQcRmSk1W tXzk1Aa9vHEAgVFCQ0e1ZEcwtjNTleW28JVrap6hxNTqTjkNknEf4M0Qaip_05S2QVzCywVDAFCq Rq4ZVbnCN6XKwTSc6_40SlReqeEX4DmH4Mp0SMxueFFTbpv0cRZ.WnIL1Lad3d986whXv7lIwlhH HL5ha3VRE6V6.6nTxw_jpQpOq0yNYXiaiLyAsXilYE6JQXIz9_4B8EPkq3arqxXpEjdiH3jk7p.8 hrfrIgK4oeB._mEoC385CsdI_gFdgvcrifJ_CJZZQsKgi3ynpG6j37iZKhHEOXyi1Ir2nr_A3RZX tLsGycVSuHlWdjlOukKHSUGr6dpooN3uuCI5S4eRg.vCRaZEEZrG3sEdp0oHy_cG2BW6J84Pw.SP ygxFczHZu5Zvi9CAOdlTYX0Rbk9c04RggYt6X253re9Yo4JAgO9BcgvyDwXcbg.EzWC1g5NjSsAf unKEJscHeTHAicWPPxYmit8h2IHRCAaKhndTVcnPQ6AGd70mDxbDig65gG9AHnbU1Pj05zu2BDWS AGtYkEICfNqu_QWjK9plSlByUvoEO77f9TMQW6imyMR4kaRTgz07n3523ygkWZq7AiIXeSe3elY7 15ASygzHhh2ZrhPqSGgJE9SzI260KrlEzejrA4MkBuKyYAEfl2.KD054Vymy_qP6T3VX9YpX3HPy x61dpi92luLRYAIJlecKSpITnOe.9MTWjqRXODK.Z2yITZQolq9HU0.2vuhrWwkM8KY3iwPv2UJE 9M2jbcOqAndh9kS5V3lEat7bchF5nE5jVKimYvLLScvn4.nJB8LJ43d0QcHSP0a7GQZnALhQXrfa O4aFZbk2UR75Z3tc4zwAUb6RGOIXqQiuiVF8ovd5RuEBjC2KFd9gE1svc9jFMP8a5ULR1qkzkYYt L6ny79HaIBvabweIaolxpj68eSMbemHrQJvB3trgmPUV9ZJpFd19PKFCJ50VuG0FAuu.IueCYfE2 G7RhkUIu7SB9_47RmdqeAJFIp6FSUY2SGisYOxxHW9QfzgaNWRJeVG9kI_pAbewzm7MvrhHwVejH Jchi3PCdKCjT.syoaCw.7O6vSe7Ul8yykncyEYPcL4Ysy0bKvZWPrEBsUahW_AOjNGQ6ry3a1AnY RkeP7zPr5Xh_mFxO5JhSnXL5E4VIJ38pDX1H5ZJHYDoL9A1jDpAR5.HGkSxaWKWZ4KJLrTtgODlI - X-Sonic-MF: X-Sonic-ID: 6168a1fa-f8d0-4e6c-a59d-5868a67baf87 Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Wed, 27 Dec 2023 08:30:40 +0000 Received: by hermes--production-gq1-6949d6d8f9-gwrdd (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 28e98d4fefcfe714b4e0a9c5891f964d; Wed, 27 Dec 2023 08:30:37 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: USB-serial adapter suggestions needed From: Mark Millard In-Reply-To: Date: Wed, 27 Dec 2023 00:30:26 -0800 Cc: ticso@cicely.de, Marcin Cieslak , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <16864054-4os0-pq3p-7qp0-7299666908os@fncre.vasb> <55q37289-ss30-nq9o-7r31-086n999p394s@fncre.vasb> To: bob prohaska X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4T0Pwg3R7Wz3VnH On Dec 26, 2023, at 18:09, bob prohaska wrote: > On Tue, Dec 26, 2023 at 02:06:59AM +0100, Bernd Walter wrote: >> On Tue, Dec 26, 2023 at 12:02:50AM +0000, Marcin Cieslak wrote: >>> On Sun, 24 Dec 2023, bob prohaska wrote: >>>=20 >>>> I do see what looks like noise on the serial lines, but only after = a spontaneous >>>> disconnect and only with FTDI adapters. When the serial connections = are working >>>> nothing resembling noise is seen. >>>=20 >>> How does that noise look like? >>=20 > It appears to be non-ascii. I can't get it to copy and paste in a way > that's recognizable to me, but here's a sample anyway, taken from > bob@pelorus:~ % uname -a > FreeBSD pelorus 14.0-RELEASE-p4 FreeBSD 14.0-RELEASE-p4 #0 = releng/14.0-n265400-4edf3b80733e: Wed Dec 27 20:21:26 PST 2023 = bob@pelorus:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64: > ....... > # tip ucom > connected >=20 > FreeBSD/arm64 (www.zefox.org) (ttyu1) >=20 > login: =EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF= =BF=BD > Password: > Login incorrect > .......... >=20 > The backslash letter pairs are clearly different, but they're = displayed on a > RasPiOS lxterminal window as a white oval with a dark question mark in = the middle. It shows that way in some programs but not others in my context. But what matters is the byte sequence, not the potentially false interpretations of them. In a program that shows hexadecimal byte values and the printable text (with "." for control characters and for 8-bit characters on the right below): 0000: 6C 6F 67 69 6E 3A 20 C3 AF C2 BF C2 BD C3 AF C2 login: ......... 0010: BF C2 BD C3 AF C2 BF C2 BD C3 AF C2 BF C2 BD C3 ................ 0020: AF C2 BF C2 BD C3 AF C2 BF C2 BD C3 AF C2 BF C2 ................ 0030: BD C3 AF C2 BF C2 BD 0A 50 61 73 73 77 6F 72 64 ........Password 0040: 3A : The byte pairs that start with C3 's and C2's look far from random to me --also they do not look like glitches. (Of course, I'm not looking at original files.) > Sometimes printable characters show up, but it doesn't look like my = memory > of a baudrate mismatch on a serial modem. Maybe that's just an = artifact of > modern character sets. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Dec 27 13:48:33 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T0Xzk5v0vz55gCX for ; Wed, 27 Dec 2023 13:48:50 +0000 (UTC) (envelope-from jfc@mit.edu) Received: from outgoing-exchange-7.mit.edu (outgoing-exchange-7.mit.edu [18.9.28.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.outgoing-exchange.mit.edu", Issuer "InCommon RSA Server CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T0Xzk2Dknz4dgY for ; Wed, 27 Dec 2023 13:48:50 +0000 (UTC) (envelope-from jfc@mit.edu) Authentication-Results: mx1.freebsd.org; none Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-7.mit.edu (8.14.7/8.12.4) with ESMTP id 3BRDmZRP021456; Wed, 27 Dec 2023 08:48:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1703684918; bh=012x/uF5493FC4Wx2VZ6o3I1mCaxSKh+MCzzD93c+X4=; h=From:Subject:Date:Message-ID:Content-Type:MIME-Version; b=Ys+N1b31B9668Y+F42FbBGLWDfXakXtgkmmHVp5cRO4FEhEFyB5lmSz9HZScNEXPX RzrTXpAZ5WReqxfknSNGWSDEC3DpmhIVdqZYK+CvW7wxlG6qnuA0fqTdvC7rIzvL7V IufkrWUL5KIs52F0yY2IWnxBPasT52X0AYb4XbOgTDOeOluSkXnLt8WfL0Rgc2syUt BbC5p2VpFXDQv2cm3As8sumA2HnpOLhhULpcE31Kz3q5dy7Q3WqAzm3fsLVgi4fG9X EAxr7qcLfZte7TH6hm+XZpvapfuUC7IEQAGxiQJVAIL+IKniijI2OjJR28Q4zkx+vj hQdIQF3o8Yvpg== Received: from w92expo6.exchange.mit.edu (18.7.74.60) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1497.48; Wed, 27 Dec 2023 08:48:17 -0500 Received: from oc11exhyb7.exchange.mit.edu (18.9.1.112) by w92expo6.exchange.mit.edu (18.7.74.60) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Wed, 27 Dec 2023 08:48:35 -0500 Received: from NAM02-BN1-obe.outbound.protection.outlook.com (104.47.51.40) by oc11exhyb7.exchange.mit.edu (18.9.1.112) with Microsoft SMTP Server (TLS) id 15.0.1497.48 via Frontend Transport; Wed, 27 Dec 2023 08:48:35 -0500 Received: from SA3PR01MB8450.prod.exchangelabs.com (2603:10b6:806:382::17) by SA1PR01MB7376.prod.exchangelabs.com (2603:10b6:806:1fb::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7113.27; Wed, 27 Dec 2023 13:48:34 +0000 Received: from SA3PR01MB8450.prod.exchangelabs.com ([fe80::79a2:b3b5:bcdf:bdf0]) by SA3PR01MB8450.prod.exchangelabs.com ([fe80::79a2:b3b5:bcdf:bdf0%7]) with mapi id 15.20.7113.027; Wed, 27 Dec 2023 13:48:33 +0000 From: "John F Carr" To: Mark Millard CC: bob prohaska , "ticso@cicely.de" , Marcin Cieslak , "freebsd-arm@freebsd.org" Subject: Re: USB-serial adapter suggestions needed Thread-Topic: USB-serial adapter suggestions needed Thread-Index: AQHaNgI4V05MNlXQo02PMFsyAup+ZLC3maYAgAAEioCAAATjAIAA8a0AgAAUxQCAACxCAIAB2+8AgAAR7ICAAaPOgIAAam0AgABY1AA= Date: Wed, 27 Dec 2023 13:48:33 +0000 Message-ID: <23100FB9-BB4A-48FF-A715-84EF7F6F59A6@mit.edu> References: <16864054-4os0-pq3p-7qp0-7299666908os@fncre.vasb> <55q37289-ss30-nq9o-7r31-086n999p394s@fncre.vasb> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SA3PR01MB8450:EE_|SA1PR01MB7376:EE_ x-ms-office365-filtering-correlation-id: af38032b-7b83-4915-5eec-08dc06e2849f x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +nGcQP987LIO2cObUkfABUgcCoMuA5fU3DVnfEHCO0d0VZUm+oZRVm7UukjP3JWgmB2lsx3+3YwNvGxouBVVwoeraWDLGMR++UL+WaUZ+xaRTgqd24aIDMceX4CsUYP5NY4W+xCvW6nOT4abKvYZ+ajWOcc+/AwabMMo2vb/xh7SiUyaiGlt86T2vprare8xc/EGgdHFjFFCa/USvoApGZq5uIUNKwmP7JQpz+IeYGLAhLhle6itpoonbmmVd7V1V6YFjbrwJ88P0l8aRb8EQCy+qV0xKHMD4126PQkt0s3xhUigvX8RS+PebLxdKRa9Mh0FRROH+TY8RnEC2ZcyBTTo4YKsTaUwOFdzq/pvFQDJjC5/pwpy2LIxURKyYD15PEoDB/uisv0kk3Zlft0n/YQzqhMxLz/+XHGG1sjECXTuI0rGEPiu3GxjaYlpnrdLrPYwNqLg1eUkSAta8MGkmrONVid+UOuuD3KBm68L7JWIYcEp/XHQZUsrVYhPnLl9lfRvQG4N4lffw7KJvyM8wHtY3zwwIZJaDD8K8DFGBTFaQV7a6SEMMiiBnHVgkAQjI/vRNOMdCDStxKuwi8Yy1hP00lUfdE0VEkZvh4QCchTr5lFcgxcoqP6C9RFp2mEZ x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA3PR01MB8450.prod.exchangelabs.com;PTR:;CAT:NONE;SFS:(13230031)(396003)(39860400002)(346002)(376002)(366004)(136003)(230922051799003)(451199024)(64100799003)(186009)(1800799012)(38070700009)(75432002)(4744005)(36756003)(38100700002)(122000001)(2906002)(33656002)(41300700001)(86362001)(66476007)(786003)(64756008)(66446008)(54906003)(66556008)(316002)(6916009)(66946007)(2616005)(91956017)(76116006)(478600001)(83380400001)(6486002)(6506007)(53546011)(71200400001)(8676002)(4326008)(6512007)(8936002)(5660300002)(3480700007);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?TjZWcUYyS2kvYUVGZmVVbkt1eWYwZ1EwZkVCNTFDckZZT2N1eEQyMUlZN2ZJ?= =?utf-8?B?MTJBZlN6bDNVVnlVTGxibUJmWTZ5V0RPUzA5K2RMOGhiT2l2Mkg4MlFsMFhM?= =?utf-8?B?S3VpcEs0Z0F0aXc3V2Z4SzZTOGtBVkZYcjl2cEF6M1NjN1lITXhTMlVCc1g1?= =?utf-8?B?MktFSmJuYVZZMVE1RXYzSlQwYkRsbDhiUHRnWHNyRFVybjVqMmtrRk9XZEM1?= =?utf-8?B?ZzRjMktGTmFtOGd2N2NvRWVVandwcTZweS9xTWtvMzliM3dUd3lOcWkwMi9M?= =?utf-8?B?cEdMblprbUVQUmlqclhucHBKekQwTi9GVmhLTUZkWVhBMHQzUFNFS29RaHRh?= =?utf-8?B?VzRKb3ZjaGI4SzhzSHh0TEJNSnNwcTV2UExaZTdaUlJMZGROQ1IyZXdTQ3BM?= =?utf-8?B?VjJkWFljbWFSNjNyZEpZa1FGTVBqYXNrdzB6NkIwVWhiUnB3VlQ1THExbGVn?= =?utf-8?B?VTV3M09Gd3VhUmNMY1BCbGY3WVd0NEh2ZFhGVDl5dUVPNHVLRmVvR05udGF3?= =?utf-8?B?RFlsczMwRGk3aWFiVnNVZ1l5cDJYVE8zck13RUh1elFRbVd6T2w4VWk5bS96?= =?utf-8?B?UENSQ1BmbWQ0elVpQWp2NXJncVBBRkg1NEhKRUFsUmxlL2o4d2R5L0J6ZmZO?= =?utf-8?B?Vmh4S2lmNkhmemVhQ1dCWWVjbG9yMCtuT2NRYW9tOUpJYTZsMlBCMlA2dmFX?= =?utf-8?B?OENZS2thQXZIRHVJVjVSK3hIOHA4THlza0Qyc3VkM2p2cTlTMGJlazV0YzhH?= =?utf-8?B?WkFBdy82WmdkZzNzaGxFWDJDTitnR1ZJaCtlb2hvMHJlNVhkeHZ2dnZOM3Y4?= =?utf-8?B?NVNYUkVlV1UzNEp0N1pzNjZmcEtBdVBIdk9lUjVyTllKSTVrYTY4REU3T1J3?= =?utf-8?B?N1FTbi9DMnRCMjhKOHo0bTdjWmg0WVRscnIzbVM2OHIrc3hMb1VXWXBlem92?= =?utf-8?B?bi8yQklKWXByVnFqREVNYnpJNmo2NHdUL1h4clRHa1RNaEwxa0p4eWg2Qmo5?= =?utf-8?B?dWZpS0ZuU0ZzUnk1Q3J0RTIzNERYOHluUnRzRTgvMW1zZFpSV1N1bkR4bnNF?= =?utf-8?B?T3hOelFMNjFFWnlBL1dZdmcvYUFxeEVsT1YzRHh3enBBRXFzU2FrelhvOGRS?= =?utf-8?B?dHlubnVNZ2VZZ2xKS3hWcXNOQmhQTU91Sm9CTmZ2NW1jdlBzNWxWdktiQ0x1?= =?utf-8?B?WDRIN3JTbEhPS3RsNUZFUVJoMFJpeS9oaWlhcmlLaW44L0xWc3dicTRSWXU3?= =?utf-8?B?UnQrdXlrNXZ4MHdmUW5TRmVPYUp4aE4yQ2JRL01lcE5Ea2FHVy8zMEg4aEtC?= =?utf-8?B?a1VnUHRKWVVCc1RkVWcvZmsyRDd4SDUwN1MrUmpNdktZQjc3N1VkZ0d2b3Nj?= =?utf-8?B?TnVIaFNYMlZNYWlMWDZlQVp3OUZUd3NQTERxV3dBcVY0L0lBUTM5UG13blBJ?= =?utf-8?B?WXBRNjN2Q0VuNlhSZ1RveFRtT3I3UUpwbnlVSDgzVUkrOVJDS2t2dGsxOTRZ?= =?utf-8?B?dnhzS3U1eC9KaFVtb216QzRoVy9JNUtmQkVlR2paMm1FbEg0azVDUXIrNXYw?= =?utf-8?B?YURXMVpkQWlFMkZPWVRtY24yUUh6YjNkaWVyMzRMeGtQODFiZ2JYMzJGVXdx?= =?utf-8?B?WUpWWE1wcTlVVHZSYkxKVDNXeGgxRDVTai94ak5jaExVZmErOUpVaFhNSGEx?= =?utf-8?B?NHQ5bm5UWXFWeFJlU0pKTkhvTEg1cVM3VlZ0SlpwaFA1MmE3bWxUOG1NdFlG?= =?utf-8?B?OFdvV0hWNmU0c2pUMnF6cW1aUCtEQkdFZDZUdU1veUtwUmoxRE9mUHN6Mm5I?= =?utf-8?B?SVQ4aUlpOE5kSXg1WG9zR1Q3ajEzL2tOaCtuaTEvb0kwZWFTUllQRzVKTUJW?= =?utf-8?B?K0VjaUVsNVFPekZvcUkvanV2VzdNcWFDazdGUitKeGFjWTZRRCtBaVpvTHV1?= =?utf-8?B?WEYvejR3REc4endoZEdPU3pwUXlrVDhzUU44S2EyV1loWXNrMUFiTS9RN0tV?= =?utf-8?B?dVZZQkFEVTh3WFlmMTg3S1NtTE1VUGZyYTRidlB6cEdIK1J6SHBtd0xUZllH?= =?utf-8?B?OXpCclcrSkFwcGdkYzFjYlZRSWNwTFNTWTdpWEtFYWFneUJ4d0p1SWJJcW9m?= =?utf-8?B?OHNzeDRYL2FLVmVGd0FXd1lqYm44Rm5HTmV4dnVMQTVremhkMm96MDViWlFM?= =?utf-8?Q?G2xCmxaUJcbQZRnmjUwn2cw=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA3PR01MB8450.prod.exchangelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: af38032b-7b83-4915-5eec-08dc06e2849f X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Dec 2023 13:48:33.7108 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: W2CRE2OnO+O5kUhC5bv+pFaEBTE9Afi7W45jhifeTSkhMsOACQwQJq3w2wVy4aPb X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR01MB7376 X-OriginatorOrg: mit.edu X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4T0Xzk2Dknz4dgY DQoNCj4gT24gRGVjIDI3LCAyMDIzLCBhdCAwMzozMCwgTWFyayBNaWxsYXJkIDxtYXJrbG1pQHlh aG9vLmNvbT4gd3JvdGU6DQo+IA0KPiAwMDAwOiA2QyA2RiA2NyA2OSA2RSAzQSAyMCBDMyBBRiBD MiBCRiBDMiBCRCBDMyBBRiBDMiAgbG9naW46IC4uLi4uLi4uLg0KPiAwMDEwOiBCRiBDMiBCRCBD MyBBRiBDMiBCRiBDMiBCRCBDMyBBRiBDMiBCRiBDMiBCRCBDMyAgLi4uLi4uLi4uLi4uLi4uLg0K PiAwMDIwOiBBRiBDMiBCRiBDMiBCRCBDMyBBRiBDMiBCRiBDMiBCRCBDMyBBRiBDMiBCRiBDMiAg Li4uLi4uLi4uLi4uLi4uLg0KPiAwMDMwOiBCRCBDMyBBRiBDMiBCRiBDMiBCRCAwQSA1MCA2MSA3 MyA3MyA3NyA2RiA3MiA2NCAgLi4uLi4uLi5QYXNzd29yZA0KPiAwMDQwOiAzQSAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOg0KPiANCj4gVGhlIGJ5dGUgcGFp cnMgdGhhdCBzdGFydCB3aXRoIEMzICdzIGFuZCBDMidzIGxvb2sgZmFyIGZyb20NCj4gcmFuZG9t IHRvIG1lIC0tYWxzbyB0aGV5IGRvIG5vdCBsb29rIGxpa2UgZ2xpdGNoZXMuDQoNClRob3NlIGJ5 dGUgcGFpcnMgYXJlIHZhbGlkIFVURi04Lg0KDQpDMyBBRiA9IDAwMCAxMTEwIDExMTEgPSBFRg0K QzIgQkYgPSAwMDAgMTAxMSAxMTExID0gQkYNCkMyIEJEID0gMDAwIDEwMTEgMTEwMSA9IEJEDQoN CldoYXQgRUYgQkYgQkQgbWVhbnMsIEkgY2FuJ3Qgc2F5LiAgQXMgVW5pY29kZSBpdCBpcyAiw6/C v8K9Ii4NCk1heWJlIFVURi04IGVuY29kZWQgOCBiaXQgbGluZSBub2lzZS4NCg0KDQoNCg== From nobody Wed Dec 27 15:59:37 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T0btr03qnz55sFk for ; Wed, 27 Dec 2023 15:59:48 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4T0btq2vfcz3NlK for ; Wed, 27 Dec 2023 15:59:47 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 3BRFxcps033962 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 27 Dec 2023 07:59:39 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 3BRFxbYd033961; Wed, 27 Dec 2023 07:59:37 -0800 (PST) (envelope-from fbsd) Date: Wed, 27 Dec 2023 07:59:37 -0800 From: bob prohaska To: John F Carr Cc: Mark Millard , "ticso@cicely.de" , Marcin Cieslak , "freebsd-arm@freebsd.org" Subject: Re: USB-serial adapter suggestions needed Message-ID: References: <16864054-4os0-pq3p-7qp0-7299666908os@fncre.vasb> <55q37289-ss30-nq9o-7r31-086n999p394s@fncre.vasb> <23100FB9-BB4A-48FF-A715-84EF7F6F59A6@mit.edu> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23100FB9-BB4A-48FF-A715-84EF7F6F59A6@mit.edu> X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4T0btq2vfcz3NlK On Wed, Dec 27, 2023 at 01:48:33PM +0000, John F Carr wrote: > > > > On Dec 27, 2023, at 03:30, Mark Millard wrote: > > > > 0000: 6C 6F 67 69 6E 3A 20 C3 AF C2 BF C2 BD C3 AF C2 login: ......... > > 0010: BF C2 BD C3 AF C2 BF C2 BD C3 AF C2 BF C2 BD C3 ................ > > 0020: AF C2 BF C2 BD C3 AF C2 BF C2 BD C3 AF C2 BF C2 ................ > > 0030: BD C3 AF C2 BF C2 BD 0A 50 61 73 73 77 6F 72 64 ........Password > > 0040: 3A : > > > > The byte pairs that start with C3 's and C2's look far from > > random to me --also they do not look like glitches. > > Those byte pairs are valid UTF-8. > > C3 AF = 000 1110 1111 = EF > C2 BF = 000 1011 1111 = BF > C2 BD = 000 1011 1101 = BD > > What EF BF BD means, I can't say. As Unicode it is "??????". > Maybe UTF-8 encoded 8 bit line noise. A simple-minded Web search for EF BF BD finds quite a few links, one being https://www.aon.com/cyber-solutions/aon_cyber_labs/when-efbfbd-and-friends-come-knocking-observations-of-byte-array-to-string-conversions/ I don't understand most of it, but it seems to imply EF BF BD are artifacts from some encryption process. What they might be doing on a private wire between two serial ports is a mystery, at least to me. SSH invokes encryption, far as I know tip and cu do not. Maybe something to do with ssh or sshd? Thanks for writing! bob prohaska From nobody Wed Dec 27 16:57:42 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T0dB11lL5z55xgX for ; Wed, 27 Dec 2023 16:58:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T0dB066Z2z3WY8 for ; Wed, 27 Dec 2023 16:58:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703696278; bh=W17UHL43JZvIFeauY/z5SZVe7PYeg1eWoPOZ40LcssQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=LZLJkQLC7266hl5tOUDhuvvLk8bURu8a2iyqwxTFauR20hI0G/Dz2V3b7K+v6uxTQSMV+4iE0Go3iC9UZp0xnWymDKro8bqy2bKk3yiir7fJdJM1m8NGbl1E8JGaK9M78Z2OA/lU5Fq9HEhUyhBV6BIYLYx0BbtQkwGaeI0yPEgSV5Q0gNCkv85MQAnGDFLxxPpCYSJa9tDtOApuA6mUkhk4dzZjRc1LfmO/tM+MJnPMYGdPaaiLejLm4nA86SEvpof5Ne1sD1saUrsiggh0Qfb+3ifWe+78SfRTMJX+pNUmkNje21AB6PIwEnef3Kv4mZs87dij9hM3iCzcHV8wew== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703696278; bh=EyU1OtyLU8/dJomEIUC0H9JO8HexvBrmFnYplfWo5XO=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=e4m6K9rGAEKjcY3jt8j/IfQbVPe1UyxWhlFbA0KAx8IPiycQVtN7LLkttr69nbrf0AiUPr8Kr8Ej1jCQtWDalPZ2PCLuF6lHm8QxsxDaKKe0tDYIh9wMakSJ8SFL+89pDPmAQq+PMMUYhyDLOkh1c1GCOsOIyAaYPUTYCx63CU604orxH0XW17a5AHXg3/1it6wRE5+ndpcc0Wd9E9Ym35OlTOPvKXzacFtPWC4JBeZCYQcEmK2rh7e7+AMAMYPXtXYYI/sLKo/YmT5+mg/GVUjgQe442GQUgUAA2ZvixLnXjM7fTVflf3i5tVucvJOaZ3VP38bD2vylnH6F/FeXGA== X-YMail-OSG: XiM42nsVM1mOYLodq27nSy5MpLU_B3xIuP2_4z0ma68o4AotC3jR_DTFm2slGhZ kzWORJu0WrCHaVu.QwPUaZxplx_c7BWuotEppFJbvKcaDwTyq.W4AESkm.C.AKVht.Yz.TjG2Z69 YLLr5FI1fShayOueppDW_WYBm030t_DjJFY.6l5hF4JLewCpoGQRK8zv.9aN4LF3es_H_xNEQQbv eQDCr6a6R0JPmhHNxIM2P82zDgvkQ8DBiFjKIBAZydUS77kzbUppXfBogugQ9YQTZo8Cz6CCZBO8 rq.TKbpcN8M9cSD.e0tKl8YWURfsLnko0g3ExajY0GpL.wJfTqc3Cb7sNKYdJw6jLhSFZzQFwfRm pIqsy7u8hPQqcFde_ziryGEOcbbalN12Q18FxaKddX4p11HmywGTnQCD7V.i0RjgZlic8DXtTMMs 5jIXyE42SytX80SWnPEorwNnOTwXnysATvDn7XUaBdDVrWo7VRalGTA.3.UqsKqISmXD5gWDAJNc cKtGqT2NSb0gWx9PStV8Jpug0CwdPKtrcK8gsuMdEKldSC3i_SFyBAn8rXToFS4Qs2dPcbgqUBEo fAJ1f4grX7ULLrk1HyT4TCilXUUFVE_Oge5kagHjx1blpLz62j.VnqMHNJWPvlgZ8yPqD7rxQXu5 QFK4ELteum8Lm2RsnXCZvyEs4ulPWGMIEbBteTrJoKmOSMxVvmrIGtNn_Y85Uo1vh0q5M1k.1n.S xtMt3mvZajs14QoNndo5cYU50T7k4dG5aH2CHEPTw3M56EYQYCZmjyqhQLro1t1SxW0LbnFiBFSp Eb8UXGiA8DdsB7i.yHjZ1GXhXsNHDPJpUtUw95g_IUsxWPq.zcOF3QbmR.0cqZz4Me3CgTnyHIW9 Jb2KHNdO5.2V.37JCMzR_nvK5NZHug.IIwO439YowrG_r0rQgXlHgU8QAGUK.z7WJQXXSBPFW1.K IoU8n1g1NxYKExgTlx_vp777oNG7.C1NRGa802EEZYVmgI3yFFFTqqyHQo2FJdKREfdDy_YXgOWz CGfdishEvLSN5vdLZu7mZTntMIYLJac8Ab0EGuz00Y2695AzLHOm8UR1tdQzNZ6UnnuFLNkubSvZ FxAV9dX1icwUusdnbGOhH5Mgy4EuwJOzoHvGACmvTCdQRJKz4i8164Uay.cXmfk5rXNLWkryCPGP hL52yQfs1GB9SgXuZXnTZD0Z.Vvwn52dEXzp8GiP8pe5eoBYxjMg_9_rT3qalDPeDcSCFj5WOT6r cQOAVcl6KGI_XaRR31ta0sE3K1HqJt_GbhlgC2SuBgAQUeRNItO3DILAXHq7wlPw0I4BRVHO6Hqz mn0UnQaZRhj1YEjsecn9D21fWBCkd.5FpJ.7Y9IF0pnIcyUtLCvUP9X8m1FScSrJszw_Aa3m1I03 okqhyMSAp80wJxVklbsRJdM7ghC0.phLERn.dpxHynS_ho0m2YYQdVqCNcwkK1PsQ.Lt4LnwrL4U 8ADa6lJ2B9tpjzUPvsZ__X8yRMaV6NmBS.Bx9a16hTUBzHz4GYA90r4m3vY.I69fhJC73EVS2N63 ypKeRBsTR2fm6wg6QILGLEWRf4qj3dfYBwxhFVNRisC0w1iI5QpwSMZ08I8sgFLDFFLVzFnQJFdL UeeaqXItHOu1ztaZ_yFhaeJetLhopB.msb3ou9QCXygKVgkevYKIOvAJDztni2Jn8QCRV4Ybua84 HYxQHTugUDqUPjZ7KRBiXnFJT3h0pfbxhutUW0nw7gwohozr3xuoOmpXq.EYebIwUldi3OvMrxyj Kq9h5vW2LfoWQdRrVsj27YjKJ6alZuFRo37kjP1Nswnerhqb0RrNG1jmXop2XGehjpogHPIty2tj KX0ThIPivsqN92C49RIMDl3YSawE15YLp.QocTChRGKBFGIskqS1Fsnya4GK902nh8IvZjVrfnuZ UZbrtiZ_4iAEp27dK4sTx4WmunjA7ICld51pHI.X8kGr83caaPMxOnpt5QsM6JwrzJnt7eF9_Myz q.vzr3FYIr.zNOXU7qiHWNha6.rsOhSdV7iAJINV1l97t0eZGmTa4EiC7UikQnqDkhK2CmzZAavg AB387kQ5Ohc.x7B7zEqhUMAVwrryf0YUQaAowulf.LsV3IETmnJrN0eYvr6DLrAD9oI6.Dmfu1RD JwJ.If5lV4dcuuS3UerjZ4.jb23sIIMyqkSxl2PwyRDQbBJutU_Xxy5F6e21uHO23UyYpsiTfc8o RetgAPPs.KRB6cZWHep9AvojZofn3M_ntUmevw9o78UPZl9RlKyvEPCBmuNvnzKVSkvTQ120MI0H xsGEMEA8- X-Sonic-MF: X-Sonic-ID: ba6452c7-4a99-41c5-a0af-3c273142e1c6 Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Wed, 27 Dec 2023 16:57:58 +0000 Received: by hermes--production-gq1-6949d6d8f9-dpfkp (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID dd5c27868e36a85626a2e052e98a0001; Wed, 27 Dec 2023 16:57:53 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: USB-serial adapter suggestions needed From: Mark Millard In-Reply-To: <23100FB9-BB4A-48FF-A715-84EF7F6F59A6@mit.edu> Date: Wed, 27 Dec 2023 08:57:42 -0800 Cc: "ticso@cicely.de" , Marcin Cieslak , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <6DD2FDE4-77DB-499A-AED8-F179A9DAA0EF@yahoo.com> References: <16864054-4os0-pq3p-7qp0-7299666908os@fncre.vasb> <55q37289-ss30-nq9o-7r31-086n999p394s@fncre.vasb> <23100FB9-BB4A-48FF-A715-84EF7F6F59A6@mit.edu> To: John F Carr , bob prohaska X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4T0dB066Z2z3WY8 On Dec 27, 2023, at 05:48, John F Carr wrote: >=20 >> On Dec 27, 2023, at 03:30, Mark Millard wrote: >>=20 >> 0000: 6C 6F 67 69 6E 3A 20 C3 AF C2 BF C2 BD C3 AF C2 login: = ......... >> 0010: BF C2 BD C3 AF C2 BF C2 BD C3 AF C2 BF C2 BD C3 = ................ >> 0020: AF C2 BF C2 BD C3 AF C2 BF C2 BD C3 AF C2 BF C2 = ................ >> 0030: BD C3 AF C2 BF C2 BD 0A 50 61 73 73 77 6F 72 64 = ........Password >> 0040: 3A : >>=20 >> The byte pairs that start with C3 's and C2's look far from >> random to me --also they do not look like glitches. >=20 > Those byte pairs are valid UTF-8. But not unique to a UTF-8 encoding: not self identifying. Extended ASCII is another possibility, for example. > C3 AF =3D 000 1110 1111 =3D EF > C2 BF =3D 000 1011 1111 =3D BF > C2 BD =3D 000 1011 1101 =3D BD >=20 > What EF BF BD means, I can't say. As Unicode it is "=C3=AF=C2=BF=C2=BD"= . > Maybe UTF-8 encoded 8 bit line noise. The subsequence (line split differently): C3 AF C2 BF C2 BD C3 AF C2 BF C2 BD C3 AF C2 BF C2 BD C3 AF C2 BF C2 BD C3 AF C2 BF C2 BD C3 AF C2 BF C2 BD C3 AF C2 BF C2 BD C3 AF C2 BF C2 BD (8 repititions) is rather systematic for a glitch or random line noise. As UTF-8 (also showing UTF-16's alternate, matching John's) ( https://www.charset.org/utf-8 ): C3 AF: 239 U+00EF C3 AF =C3=AF Latin Small Letter I With Diaeresis C2 BF: 191 U+00BF C2 BF =C2=BF Inverted Question Mark C2 BD: 189 U+00BD C2 BD =C2=BD Vulgar Fraction One Half As extended ASCII ( https://www.ascii-code.com/ ): C3: 195 303 C3 11000011 =C3=83 à à Latin capital letter A = with tilde C2: 194 302 C2 11000010 =C3=82   Latin capital letter A = with circumflex BF: 191 277 BF 10111111 =C2=BF ¿ ¿ Inverted question mark BD: 189 275 BD 10111101 =C2=BD ½ ½ Fraction one half AF: 175 257 AF 10101111 =C2=AF ¯ ¯ Spacing macron - overline Binary is ^^^^^^^^ So C3 AF C2 BF C2 BD on separate lines with binary showing are: C3: 11000011 AF: 10101111 C2: 11000010 BF: 10111111 C2: 11000010 BD: 10111101 C3: 11000011 So: multi-bit changes from one to the next across the repeating sequence. Again: It does not appear to me to be gitches or random line noise. Systematic line noise also seems rather unlikely. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Dec 27 18:55:50 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T0gp82bGZz567l7 for ; Wed, 27 Dec 2023 18:56:00 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4T0gp76V8zz4LZy for ; Wed, 27 Dec 2023 18:55:59 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 3BRItpC3034442 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 27 Dec 2023 10:55:52 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 3BRItoAe034441; Wed, 27 Dec 2023 10:55:50 -0800 (PST) (envelope-from fbsd) Date: Wed, 27 Dec 2023 10:55:50 -0800 From: bob prohaska To: Mark Millard Cc: John F Carr , "ticso@cicely.de" , Marcin Cieslak , "freebsd-arm@freebsd.org" Subject: Re: USB-serial adapter suggestions needed Message-ID: References: <16864054-4os0-pq3p-7qp0-7299666908os@fncre.vasb> <55q37289-ss30-nq9o-7r31-086n999p394s@fncre.vasb> <23100FB9-BB4A-48FF-A715-84EF7F6F59A6@mit.edu> <6DD2FDE4-77DB-499A-AED8-F179A9DAA0EF@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6DD2FDE4-77DB-499A-AED8-F179A9DAA0EF@yahoo.com> X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4T0gp76V8zz4LZy Here's another example of a spontaneous disconnect, followed by brining the ssh session back up and re-starting tip. The USB end of the link is a 14-release Pi3 on the local network, so it does not see ssh door-knocking. The serial console display is on a host which is on the public Net and so does see frequent ssh attacks login: login: Login timed out after 300 seconds Dec 26 17:56:56 www login[8694]: 1 LOGIN FAILURE ON ttyu1 FreeBSD/arm64 (www.zefox.org) (ttyu1) login: FreeBSD/arm64 (www.zefox.org) (ttyu1) login: FreeBSD/arm64 (www.zefox.org) (ttyu1) login: client_loop: send disconnect: Broken pipe bob@raspberrypi:~ $ ssh 192.168.1.10 Password for bob@pelorus: Last login: Thu Dec 28 23:01:43 2023 FreeBSD 14.0-RELEASE-p4 (GENERIC) #0 releng/14.0-n265400-4edf3b80733e: Wed Dec 27 20:21:26 PST 2023 Welcome to FreeBSD! Release Notes, Errata: https://www.FreeBSD.org/releases/ Security Advisories: https://www.FreeBSD.org/security/ FreeBSD Handbook: https://www.FreeBSD.org/handbook/ FreeBSD FAQ: https://www.FreeBSD.org/faq/ Questions List: https://www.FreeBSD.org/lists/questions/ FreeBSD Forums: https://forums.FreeBSD.org/ Documents installed with the system are in the /usr/local/share/doc/freebsd/ directory, or can be installed later with: pkg install en-freebsd-doc For other languages, replace "en" with a language code like de or fr. Show the version of FreeBSD installed: freebsd-version ; uname -a Please include that output and any error messages when posting questions. Introduction to manual pages: man man FreeBSD directory layout: man hier To change this login announcement, see motd(5). You can prevent the removal of a ZFS snapshot by using the hold subcommand. For example, to prevent the snapshot called milestone from deletion, run the following command: # zfs hold milestone_hold mypool/projects@my_milestone The "zfs holds" command will list all current snapshots that are protected this way (-r for a recursive list): # zfs holds -r mypool The TIMESTAMP column in the output of the above command is from when the hold was created, not the snapshot it holds. The "zfs destroy" command will echo a "dataset is busy" message on the console when it encounters a hold. Use "zfs release" to release the hold on the snapshot: # zfs release milestone_hold mypool/projects@my_milestone -- Benedict Reuschling bob@pelorus:~ % su Password: # tip ucom Stale lock on cuaU0 PID=1312... overriding. connected Dec 26 2pts exce [enter typed, this looks like a log entry from the public host] Password: [but how did it get reflected back to that host as input?] Login incorrect login: It isn't surprising to see leftover data flushing into the USB end host when tip opens the serial connection. It is surprising that the host at the serial end of the line sees some of that data as input, at least to me. Maybe I simply misunderstand ...... Does getty not flush input before asking for a login and password? Is echo happening between tip sessions? Thanks for reading. bob prohaska From nobody Wed Dec 27 20:27:33 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T0jr92vn9z56GRZ for ; Wed, 27 Dec 2023 20:27:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T0jr90YNLz4TRK for ; Wed, 27 Dec 2023 20:27:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703708869; bh=iGHaoAlAniHEiUtxeDb8MwgJQaqBdQAWxwSVcxYgcSg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ZEB/2KyjMhIv84FluOSe6sp+8xlLCekntWCMkpVHMUokYmKrjvyj683BBzrttU8TAAnek26svyBx3P6ZNZ4UlFJeVjs4cf0kafJBG7pGhGkpfAKOagTaAfeiWeslP2EQ88TdIyQXCHPFXKtdNYKA+xf6TPtlQLgGeMn4H2FMhtMexXQyM5pe6hcPbtRwJEybSFSSNKr9MFr6y2FJgn3/a7aAPt8suLc7qAsuTyOViDs6TV9kmsp2hgUxrBI/hT9/k+c050+xbpzzr3pYMMDWYcY6clfOCqLYfxVdnDE/QgBsZCNQhVX476v+HzIF24bpWWB5FdBbCscuebNHsmqpRQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703708869; bh=efncT5Wz6D8+/Gxz1GLzaM47a14EF8PNIx/qNjrjMEs=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=MXaWK5VJKj/mIDTMPSh/GGcIpgBX+iAtWBorq2vnycoWEPjv6FUdvJzwgUf7emI48L7epHHxQ9clFgHQonwCZJoeWbfqzZZChbiHEKS8sHuQEE2tx0ZfWdD4OmPXC8uUVnobJ2t02FiwjlOqbVf8iadOrrnWvhCkNbOifb1wGe5+hdk0LvlYAcG5Cq/YaInqCLwr2a2s3E8DPUHj64VZORSKPFrEexf36O78no/MrwoTeUh8AVa/b/QANoMEiqJgkCOsGf0c1wIgK81qVbZuDo4GwfFF1YXnXugPLKeQQ7z9yABz9IMquvhepViSkqL5LZlItUM5t/mhnpI24QU96w== X-YMail-OSG: 0UQnoloVM1mCvjJJTfM1YCk2Rr_TZQXpg.G6cQHtw7sH5Ui3DgUsmeDUA5darNJ klXFNU5Dl1HiK33x8JiD1KjqEos_jCOo_SDGSAVyj03r1IseyzVo2SFA66QYz55FdIaAGZ5wQhxK esdSG_5l_8_RfXv2mnZUJiLQfhAp07jQohNjVeBPW6xUf3ZZOeXMqVudjbnc77i0VI.fyOYx1wnR bC1n9YxO3llqbR5X.D3qFIw_KD.JbfStKZU7S0TkIAXywyJ_O8DKmlMI03db4uBBlvhEoLsmkyfQ NXI9XcD3r0yp8Z68T3JbYzVBcrUbP3nJp_pR2CvnEnzrMi2jUGuk1YnuVCfyJADnmZUDhu5pUoFQ KN8guGG_Rssr0s_DAvDBVabz.HjQfp1r8eymTBLE41qCpYX_BD6lOmDuy69pDR.U78xbL6HEMvVA WVYzCeE.DV_JmwClkhhm7qiFlSbHDU8yrFt54UahWNECgBR12QRutlLKQKkSy__UYPYQbQsmznEJ mcneKMrVJFWr1A0tJuwYGPdHlkLHghICLsunhIQRMXNSLKp7D2VnKLRDdozXfYiyMracEINlD2Et Pz21LsSWGgJUT9jm200Osx34tzk6Lk8VIZm.UVMnKBVo3KjxQVwPT1LUbM8iEbiuBgIIszWlgs9e anmh1vbjCjvRDvHH2rdX47GOyrBqrlkh8ti06KmI0KGQJ_xDII5Xl22H4whHyqV3ouCP39CRsswn y.CI.5VKx6Zr.iZmgZ1_SngfRB8VAadaUSWUmPs02HsgcFLsT8dJkQTsKgf3pYpFQDSuHCY9Wr4U 5ptDbFgAdPmX1PnfKXTWbPzgC00vvGxDcJ.njvKuwPr9JLI0Sb9d8NsZ3npFO4FhLBxj5MErEsgU KOUOcHEUI5vFGBeZQUYXTECeJjKBayEzP8xgkxTRU5luBYtHxQXSkgsDIFrJTwySM973sJTnlxX3 .D_9YVhW4If8FDpGgjlNOEfTd5z0tEDQZy_f2Kca3d8uOKUmzF.tvnTyXd86n.kRrrIJUBq5wCmg c_Uur7o.dgZABNUHfnPwbrQVr6882hN1O6aKORrrWomHlvMI0KNHCsnLI380ECVeQTXCnVtRgQK0 SO6pX1TKiQVZCpusziRrEcpl8tzztK0eulmNL6D_eOYKXQYex3tC_.s31RphhfLSsEO534v_TID1 OAfVVisWpcOmigOR4xMWPQ2pvAEXm6giLaYpfT0mhPhYDvtRIM4Oc2uUkMLAIFsTBGD1IoMXdA7z r_nxzIOds0..u16FTBSXMy4LwhkUefkexJt01npLhNiHGzzKTAe7c3MDNLxrCkTOERF6Yt_66stD 3D71CvoC6YUnN_zL0e5hhwJYdpgkgl9gaRX.jP3pN52CFcAvClaedDYfN.8Pzt1Z8_k52394e8Ti rG4DGUFgxIgb4JNEaCcWPrClKkDr99onEr.dNMHWT.IFkVqCcLxQIY1Q6v_2n5noRkOYKzDPSHW5 uPPrixfwqh2lzgbGGopAxEzxeuh9i.Hn69pc8gds9MfYF.pjrXhD2rRdlf7Yjbwl4oUZOOIx0sUx QFsGtTrZIneEzXkuR6TJpNpdouEDO66j__8WUjU4AfkDMgGmsFEx4F4rW5a0ykPIJRe.xLRhGKir G6Y1w6NKc8GmmuEfvFIfyGpy49SnF.8VSMBarnnYn2KoOzjjdMkLqGupDcLnDU5AfeUAccXPuA7G fO_ISt9Mz93zhwlzLPDqrbJ3f5Osy5A8CcqWqRQrr1BqFnX42oG0c5EgTMh0FyRMjD_PlYrF0Ia8 zOe..wapQVhTXf2mAJEluC6ZT1XqhZwqNf2bgKAx_ujszge8PPG82O5Ti6619wtQJBOtJ.wgK7Me q7diBuNJ6.v5HA8MOcsWumpHeHvjuEvPXBhAyZ25KW82ebw5YRn5z1lyknYRrQO7.SspuMPFAWBK RIBw1WcP.1F4eEcqqdvpoRAI0UQdXgHMpbWABw5FPY1yhlJh4hQj.WHjetQxLqEIAEM8YjPZD8IC TbGH317NU9OLKiRK2cLpH3cl.zEhziyJChK5Z_vAlrE7C4fNMOK0dTUi7LcpTHWUS8_mrrQOJDZe RG6MsHGtLomFLF6VkCUBVjIzmMATvDJZdq3MaqKhoAjylloNmyc9cg.H9AxrulsXF0Vmn2P1xI4k hgIzZzuR82a1tOf2OWd5vVuWQBe.U9CoRUeSd_7s6Ab_jcmUsM_VX52oUyWP.dm8X7gBWfiFMfvR RxPXue4z.r8QloX.3pwUxisVD4IVhPylkY_5h8bCkXcpM1DXweGv.vW8Tpkub0.k2w7IfuBQdZbd XJGQ- X-Sonic-MF: X-Sonic-ID: d3f948d7-6e8b-4543-8ce1-37dc0aaa683b Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Wed, 27 Dec 2023 20:27:49 +0000 Received: by hermes--production-gq1-6949d6d8f9-qkzts (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 217c7caf6935a2a9e2873596d0a2a8ca; Wed, 27 Dec 2023 20:27:44 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: USB-serial adapter suggestions needed From: Mark Millard In-Reply-To: Date: Wed, 27 Dec 2023 12:27:33 -0800 Cc: John F Carr , "ticso@cicely.de" , Marcin Cieslak , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <6A38A60B-3281-468D-907C-26AB2F8D07A6@yahoo.com> References: <16864054-4os0-pq3p-7qp0-7299666908os@fncre.vasb> <55q37289-ss30-nq9o-7r31-086n999p394s@fncre.vasb> <23100FB9-BB4A-48FF-A715-84EF7F6F59A6@mit.edu> <6DD2FDE4-77DB-499A-AED8-F179A9DAA0EF@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4T0jr90YNLz4TRK On Dec 27, 2023, at 10:55, bob prohaska wrote: > Here's another example of a spontaneous disconnect, followed by > brining the ssh session back up and re-starting tip. The USB end > of the link is a 14-release Pi3 on the local network, So it is not shown in http://www.zefox.net/~fbsd/netmap ? It would be to the right-of/below "lan", possibly to the right-of/below wifi? > so it does > not see ssh door-knocking. The serial console display is on a host > which is on the public Net and so does see frequent ssh attacks For the just below, which machine is connected to which machine via what technique (ssh vs. tip), including any staging of multiple stages? > login:=20 > login: Login timed out after 300 seconds > Dec 26 17:56:56 www login[8694]: 1 LOGIN FAILURE ON ttyu1 >=20 > FreeBSD/arm64 (www.zefox.org) (ttyu1) >=20 > login:=20 >=20 > FreeBSD/arm64 (www.zefox.org) (ttyu1) >=20 > login:=20 >=20 > FreeBSD/arm64 (www.zefox.org) (ttyu1) >=20 > login: client_loop: send disconnect: Broken pipe > bob@raspberrypi:~ $ ssh 192.168.1.10 Is @raspberrypi the "pi4 RasPiOS workstation" in the diagram? The diagram does not show "192.168.1.10" style notation for anything. > Password for bob@pelorus: > Last login: Thu Dec 28 23:01:43 2023 > FreeBSD 14.0-RELEASE-p4 (GENERIC) #0 releng/14.0-n265400-4edf3b80733e: = Wed Dec 27 20:21:26 PST 2023 The diagram shows releng/14 explicitly only for: |---50.1.20.26 www.zefox.com Pi2 releng/14 ftdi usb-serial---50.1.20.24 (There are 3 "-current" and 3 "12.3" as well.) So, is 192.168.1.10 that "Pi2 releng/14"? > . . . > -- Benedict Reuschling > bob@pelorus:~ % su > Password: > # tip ucom > Stale lock on cuaU0 PID=3D1312... overriding. > connected > Dec 26 2pts exce [enter typed, this looks like a log entry from the = public host] > Password: [but how did it get reflected back to that host as = input?] > Login incorrect > login: So is the login prompt from: |---50.1.20.24 pelorus.zefox.org Pi3 -current via the earlier "ftdi usb-serial---50.1.20.24"? > It isn't surprising to see leftover data flushing into the USB end = host > when tip opens the serial connection. It is surprising that the host = at > the serial end of the line sees some of that data as input, at least = to me. Overall I've not been able to understand what the (various?) hypothesized stage-by-stage byte flow paths are in these notes. > Maybe I simply misunderstand ...... Does getty not flush input before = asking > for a login and password? Is echo happening between tip sessions? For the RPi*'s involved, what does each config.txt have for content and what vintage of RPi* firmware is involved? These get into if the PL011 vs. mini-UART are in use. As I remember it used to be that: RPi2B v1.1 had the PL011 bound to the serial connection by default = (a.k.a.: as primary) RPi3B had the mini-UART bound to the serial connection by default = (a.k.a.: as primary) and: RPi2B v1.1 had the mini-UART as secondary but not bound to anything RPi3B had the PL011 as secondary and bound to Bluetooth (The RPi4B is like the RPi3B in this respect, as I remember.) The PL011 is the fully functional UART. What is your: dtoverlay=3Ddisable-bt vs. dtoverlay=3Dminiuart-bt vs. Niether status for each RPi3B/4B that is involved? =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Dec 27 23:55:31 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T0pS015htz54fQ5 for ; Wed, 27 Dec 2023 23:55:44 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE Root Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T0pRz1d0Sz4tP6; Wed, 27 Dec 2023 23:55:43 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 2a01:4f8:13b:39f::9f:25 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net; dmarc=none Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 1DC438D4A230; Wed, 27 Dec 2023 23:55:33 +0000 (UTC) Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 857952D029D8; Wed, 27 Dec 2023 23:55:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id XDtYOyjk_uaU; Wed, 27 Dec 2023 23:55:32 +0000 (UTC) Received: from strong-iwl0.sbone.de (strong-iwl0.sbone.de [IPv6:fde9:577b:c1a9:4902:b66b:fcff:fef3:e3d2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 841ED2D029D2; Wed, 27 Dec 2023 23:55:32 +0000 (UTC) Date: Wed, 27 Dec 2023 23:55:31 +0000 (UTC) From: "Bjoern A. Zeeb" To: freebsd-arm@FreeBSD.org cc: Warner Losh Subject: MMCCAM hang Message-ID: X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; R_SPF_ALLOW(-0.20)[+ip6:2a01:4f8:13b:39f::9f:25]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arm@FreeBSD.org]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[4]; RCVD_VIA_SMTP_AUTH(0.00)[]; DMARC_NA(0.00)[zabbadoz.net]; ARC_NA(0.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[] X-Rspamd-Queue-Id: 4T0pRz1d0Sz4tP6 X-Spamd-Bar: --- Hi, sdhci_fsl_fdt0: Desired SD/MMC freq: 50000000, actual: 50000000; base 700000000 prescale 1 divisor 14 GEOM: new disk sdda0 sdda0 at sdhci_slot0 bus 0 scbus0 target 0 lun 0 sdda0: Relative addr: 00000002 Card features: Card random: unblocking device. GEOM: new disk sdda0boot0 memory OCR: 00ff8080 sdda0: Serial Number ....... sdda0: MMCHC .................................. by 17 0x0000 GEOM: new disk sdda0boot1 uhub0: 2 ports with 2 removable, self powered at which point basically anything hangs. In auto-boot it is before/during file-system checks. In single user mode camcontrol devlist will show sdda0 but root@:/ # gpart show sdda0 load: 6.06 cmd: gpart 24 [g_waitfor_event] 1.28r 0.00u 0.00s 0% 2088k {forever} Unclear at which point I broke to debugger and this is where it seems to hang: db> trace 100088 Tracing pid 4 tid 100088 td 0xffff0000dc527000 ipi_stop() at ipi_stop+0x34 arm_gic_v3_intr() at arm_gic_v3_intr+0xe4 intr_irq_handler() at intr_irq_handler+0x80 handle_el1h_irq() at handle_el1h_irq+0x14 --- interrupt spinlock_exit() at spinlock_exit+0x44 callout_reset_sbt_on() at callout_reset_sbt_on+0x210 sdhci_cam_action() at sdhci_cam_action+0x284 xpt_run_devq() at xpt_run_devq+0x4c8 xpt_action_default() at xpt_action_default+0x470 sddastart() at sddastart+0x1bc xpt_run_allocq() at xpt_run_allocq+0xa8 xpt_done_process() at xpt_done_process+0x610 xpt_done_td() at xpt_done_td+0x1a8 fork_exit() at fork_exit+0x8c fork_trampoline() at fork_trampoline+0x18 Anyone an idea? -- Bjoern A. Zeeb r15:7 From nobody Thu Dec 28 01:08:43 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T0r4S2d3Xz54mpM for ; Thu, 28 Dec 2023 01:08:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T0r4S0lYCz3KvM for ; Thu, 28 Dec 2023 01:08:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-555144cd330so2304412a12.2 for ; Wed, 27 Dec 2023 17:08:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1703725734; x=1704330534; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=s9Mun0yrcopsahTGpNyyGsvSq4ccY+gk053xPIPX41w=; b=BKEAl3XVuFHIg83Qo0OY/u/Ph9f/DvkgvtceM/DYHkY91rKoMKONL+EdahIP+FMvIy w4NuaaQNIc8ZStJP96syd7LFTEFqdkYDcX4tsAmCzsVkH8alGw0TtoCVDzeA1mKB0DBh iwoOyuAjmdaDjQI3hspOKkv0H/1iZBKcHMBHAqPDKOeTi5zFWfWVMxuFhkDlDymLfwKc uu0S18/moH60scMuw3VTfJoNn4WEmxxGgpKHiDwU5B/KRkZFpDD4Gbub6BXQVDPh/iNP XDOakIzlZvF7QTrgJrZx2kQqNv9xnddOZBLBAIxbwfRuyoDWVHCM5fuFwAPrQQqF452A d0Fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703725734; x=1704330534; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=s9Mun0yrcopsahTGpNyyGsvSq4ccY+gk053xPIPX41w=; b=WjUIoTpb4fqUoqdM5sKEVyM/JKqLS7x6ixSsQzzLVsogZua/NYou8EBu+y6b3sLwgA WMA4oGEsa001+EZMbsYaOZMcPztYhPIMmA2T75fifJG/fvtLzQbr9aoywvmaIyZJHgHM +DMqn/pNSqdeYfhyBN0IcLjQiMoVcdsmfjwX7ItJP+Bp24ZZJBhW7+Dgr8/GrA3aG6YC cRRbwuEn+DGmQEmcfgKF7LEgwBfF3FNBlwl/WJ55wfnu/F+QJX6SCWz1XF1aJ5ag4LNi mfi1iPkHINp8e5TAjE8a8dIFs9NzZkyuoIMKdQKoPI+LNIHxmGb00hDz1E7fiXd0euiG wTkQ== X-Gm-Message-State: AOJu0YxfS9Pj9uwyVtXQeDrnMUnG6/nqhKhmcQRnupqlpWv8NLvHp5RF 7y6l4Uhoc3BvCqydIdNW8ZpNb6BDvWTlO4YikMkp4cwXN4OTnw== X-Google-Smtp-Source: AGHT+IFBRoXnOuWCZLB+6Q19diGvZ+o5ddsfciBXOYpjM6MgDeedF0cthSrbCAy9k3h1aix01EWJG5ZUTcn4N1by73Q= X-Received: by 2002:a17:906:2655:b0:a23:5076:763 with SMTP id i21-20020a170906265500b00a2350760763mr4436175ejc.123.1703725734422; Wed, 27 Dec 2023 17:08:54 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Wed, 27 Dec 2023 18:08:43 -0700 Message-ID: Subject: Re: MMCCAM hang To: "Bjoern A. Zeeb" Cc: "freebsd-arm@freebsd.org" , Warner Losh Content-Type: multipart/alternative; boundary="00000000000031f85b060d878f9a" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4T0r4S0lYCz3KvM --00000000000031f85b060d878f9a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 27, 2023, 4:55=E2=80=AFPM Bjoern A. Zeeb wrote: > Hi, > > sdhci_fsl_fdt0: Desired SD/MMC freq: 50000000, actual: 50000000; base > 700000000 prescale 1 divisor 14 > GEOM: new disk sdda0 > sdda0 at sdhci_slot0 bus 0 scbus0 target 0 lun 0 > sdda0: Relative addr: 00000002 > Card features: > Card random: unblocking device. > GEOM: new disk sdda0boot0 > memory OCR: 00ff8080 > sdda0: Serial Number ....... > sdda0: MMCHC .................................. by 17 0x0000 > GEOM: new disk sdda0boot1 > uhub0: 2 ports with 2 removable, self powered > > at which point basically anything hangs. In auto-boot it is > before/during file-system checks. > In single user mode camcontrol devlist will show sdda0 > but > > root@:/ # gpart show sdda0 > load: 6.06 cmd: gpart 24 [g_waitfor_event] 1.28r 0.00u 0.00s 0% 2088k > {forever} > > > Unclear at which point I broke to debugger and this is where it seems to > hang: > > db> trace 100088 > Tracing pid 4 tid 100088 td 0xffff0000dc527000 > ipi_stop() at ipi_stop+0x34 > arm_gic_v3_intr() at arm_gic_v3_intr+0xe4 > intr_irq_handler() at intr_irq_handler+0x80 > handle_el1h_irq() at handle_el1h_irq+0x14 > --- interrupt > spinlock_exit() at spinlock_exit+0x44 > callout_reset_sbt_on() at callout_reset_sbt_on+0x210 > sdhci_cam_action() at sdhci_cam_action+0x284 > xpt_run_devq() at xpt_run_devq+0x4c8 > xpt_action_default() at xpt_action_default+0x470 > sddastart() at sddastart+0x1bc > xpt_run_allocq() at xpt_run_allocq+0xa8 > xpt_done_process() at xpt_done_process+0x610 > xpt_done_td() at xpt_done_td+0x1a8 > fork_exit() at fork_exit+0x8c > fork_trampoline() at fork_trampoline+0x18 > > > Anyone an idea? > Looks like deadlock with another thread. Anybody else in the time keeping / callout code? Warmer > -- > Bjoern A. Zeeb r15:7 > --00000000000031f85b060d878f9a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Dec 27, 2023, 4:55=E2=80=AFPM Bjoern A. Zeeb &= lt;bzeeb-lists@lists.zabb= adoz.net> wrote:
Hi,

sdhci_fsl_fdt0: Desired SD/MMC freq: 50000000, actual: 50000000; base 70000= 0000 prescale 1 divisor 14
GEOM: new disk sdda0
sdda0 at sdhci_slot0 bus 0 scbus0 target 0 lun 0
sdda0: Relative addr: 00000002
Card features: <MMC Memory High-Capacity>
Card random: unblocking device.
GEOM: new disk sdda0boot0
memory OCR: 00ff8080
sdda0: Serial Number .......
sdda0: MMCHC .................................. by 17 0x0000
GEOM: new disk sdda0boot1
uhub0: 2 ports with 2 removable, self powered

at which point basically anything hangs.=C2=A0 In auto-boot it is
before/during file-system checks.
In single user mode camcontrol devlist will show sdda0
but

root@:/ # gpart show sdda0
load: 6.06=C2=A0 cmd: gpart 24 [g_waitfor_event] 1.28r 0.00u 0.00s 0% 2088k=
{forever}


Unclear at which point I broke to debugger and this is where it seems to hang:

db> trace 100088
Tracing pid 4 tid 100088 td 0xffff0000dc527000
ipi_stop() at ipi_stop+0x34
arm_gic_v3_intr() at arm_gic_v3_intr+0xe4
intr_irq_handler() at intr_irq_handler+0x80
handle_el1h_irq() at handle_el1h_irq+0x14
--- interrupt
spinlock_exit() at spinlock_exit+0x44
callout_reset_sbt_on() at callout_reset_sbt_on+0x210
sdhci_cam_action() at sdhci_cam_action+0x284
xpt_run_devq() at xpt_run_devq+0x4c8
xpt_action_default() at xpt_action_default+0x470
sddastart() at sddastart+0x1bc
xpt_run_allocq() at xpt_run_allocq+0xa8
xpt_done_process() at xpt_done_process+0x610
xpt_done_td() at xpt_done_td+0x1a8
fork_exit() at fork_exit+0x8c
fork_trampoline() at fork_trampoline+0x18


Anyone an idea?


Looks like deadlock with another= thread. Anybody else in the time keeping / callout code?

Warmer
--
Bjoern A. Zeeb=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r15:7
--00000000000031f85b060d878f9a-- From nobody Thu Dec 28 01:24:56 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T0rR81N3Kz54q95 for ; Thu, 28 Dec 2023 01:25: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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4T0rR74m86z3P8b for ; Thu, 28 Dec 2023 01:25:07 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 3BS1OwI2036884 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 27 Dec 2023 17:24:58 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 3BS1OusS036883; Wed, 27 Dec 2023 17:24:56 -0800 (PST) (envelope-from fbsd) Date: Wed, 27 Dec 2023 17:24:56 -0800 From: bob prohaska To: Mark Millard Cc: John F Carr , "ticso@cicely.de" , Marcin Cieslak , "freebsd-arm@freebsd.org" Subject: Re: USB-serial adapter suggestions needed Message-ID: References: <55q37289-ss30-nq9o-7r31-086n999p394s@fncre.vasb> <23100FB9-BB4A-48FF-A715-84EF7F6F59A6@mit.edu> <6DD2FDE4-77DB-499A-AED8-F179A9DAA0EF@yahoo.com> <6A38A60B-3281-468D-907C-26AB2F8D07A6@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6A38A60B-3281-468D-907C-26AB2F8D07A6@yahoo.com> X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4T0rR74m86z3P8b On Wed, Dec 27, 2023 at 12:27:33PM -0800, Mark Millard wrote: > On Dec 27, 2023, at 10:55, bob prohaska wrote: > > > Here's another example of a spontaneous disconnect, followed by > > brining the ssh session back up and re-starting tip. The USB end > > of the link is a 14-release Pi3 on the local network, > > So it is not shown in http://www.zefox.net/~fbsd/netmap ? > > It would be to the right-of/below "lan", possibly to the > right-of/below wifi? > > > so it does > > not see ssh door-knocking. The serial console display is on a host > > which is on the public Net and so does see frequent ssh attacks > > > For the just below, which machine is connected to which > machine via what technique (ssh vs. tip), including any > staging of multiple stages? > > > login: > > login: Login timed out after 300 seconds > > Dec 26 17:56:56 www login[8694]: 1 LOGIN FAILURE ON ttyu1 > > > > FreeBSD/arm64 (www.zefox.org) (ttyu1) > > > > login: > > > > FreeBSD/arm64 (www.zefox.org) (ttyu1) > > > > login: > > > > FreeBSD/arm64 (www.zefox.org) (ttyu1) > > > > login: client_loop: send disconnect: Broken pipe > > bob@raspberrypi:~ $ ssh 192.168.1.10 > > Is @raspberrypi the "pi4 RasPiOS workstation" in the > diagram? > > The diagram does not show "192.168.1.10" style notation > for anything. It's the host named pelorus, formerly 50.1.20.24 The network cabled was simply moved from WAN to LAN. > > > Password for bob@pelorus: > > Last login: Thu Dec 28 23:01:43 2023 > > FreeBSD 14.0-RELEASE-p4 (GENERIC) #0 releng/14.0-n265400-4edf3b80733e: Wed Dec 27 20:21:26 PST 2023 > > The diagram shows releng/14 explicitly only for: > > |---50.1.20.26 www.zefox.com Pi2 releng/14 ftdi usb-serial---50.1.20.24 > > (There are 3 "-current" and 3 "12.3" as well.) > > So, is 192.168.1.10 that "Pi2 releng/14"? > > > . . No, the Pi2 isn't involved. > > -- Benedict Reuschling > > bob@pelorus:~ % su > > Password: > > # tip ucom > > Stale lock on cuaU0 PID=1312... overriding. > > connected > > Dec 26 2pts exce [enter typed, this looks like a log entry from the public host] > > Password: [but how did it get reflected back to that host as input?] > > Login incorrect > > login: > > So is the login prompt from: > > |---50.1.20.24 pelorus.zefox.org Pi3 -current > > via the earlier "ftdi usb-serial---50.1.20.24"? > No, the garbled login prompt originates from www.zefox.org's serial console. It's via an ssh session running on pelorus but displayed on the RasPiOS workstation. > > > It isn't surprising to see leftover data flushing into the USB end host > > when tip opens the serial connection. It is surprising that the host at > > the serial end of the line sees some of that data as input, at least to me. > > Overall I've not been able to understand what the > (various?) hypothesized stage-by-stage byte flow > paths are in these notes. > Understood, it's been hard to articulate 8-( Maybe Workstation > ethernet > pelorus > usb port > gpio 8,10 > console www.zefox.org is a little clearer > > For the RPi*'s involved, what does each config.txt have for content > and what vintage of RPi* firmware is involved? These get into if the > PL011 vs. mini-UART are in use. > I'm using the default serial console port on pins 8, 10 and 12 on all of the Pi's involved. The Pi3 which reported the garbled login prompt uses in config.txt: b@www:/boot/msdos % more config.txt init_uart_clock=3000000 enable_uart=1 kernel=u-boot.bin kernel7=u-boot.bin dtoverlay=mmc force_mac_address=b8:27:eb:71:46:4f The Pi3 hosting the usb-serial adapter has in config.txt bob@pelorus:~ % more /boot/efi/config.txt [all] arm_64bit=1 dtparam=audio=on,i2c_arm=on,spi=on dtoverlay=mmc dtoverlay=disable-bt device_tree_address=0x4000 kernel=u-boot.bin [pi4] hdmi_safe=1 armstub=armstub8-gic.bin > As I remember it used to be that: > > RPi2B v1.1 had the PL011 bound to the serial connection by default (a.k.a.: as primary) > RPi3B had the mini-UART bound to the serial connection by default (a.k.a.: as primary) > and: > RPi2B v1.1 had the mini-UART as secondary but not bound to anything > RPi3B had the PL011 as secondary and bound to Bluetooth > > (The RPi4B is like the RPi3B in this respect, as I remember.) > > The PL011 is the fully functional UART. > > What is your: > > dtoverlay=disable-bt > vs. > dtoverlay=miniuart-bt > vs. > Niether > > status for each RPi3B/4B that is involved? For the Pi3 using its uart in this chain, neither For the Pi3 using ethernet and usb, dtoverlay=disable-bt Thanks for reading! bob prohaska From nobody Thu Dec 28 12:21:23 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T170V4TpPz55kd8 for ; Thu, 28 Dec 2023 12:21:30 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE Root Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T170V1Wkvz4NFw; Thu, 28 Dec 2023 12:21:30 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Authentication-Results: mx1.freebsd.org; none Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 6A58D8D4A142; Thu, 28 Dec 2023 12:21:27 +0000 (UTC) Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 895232D029D7; Thu, 28 Dec 2023 12:21:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id 6lccgxIDY-W4; Thu, 28 Dec 2023 12:21:24 +0000 (UTC) Received: from strong-iwl0.sbone.de (strong-iwl0.sbone.de [IPv6:fde9:577b:c1a9:4902:b66b:fcff:fef3:e3d2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id A643D2D029D2; Thu, 28 Dec 2023 12:21:24 +0000 (UTC) Date: Thu, 28 Dec 2023 12:21:23 +0000 (UTC) From: "Bjoern A. Zeeb" To: Warner Losh cc: "freebsd-arm@freebsd.org" , Warner Losh Subject: Re: MMCCAM hang In-Reply-To: Message-ID: <6sp3659o-21pr-773q-2s04-7s5n60s60481@yvfgf.mnoonqbm.arg> References: X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="1098556516-150255199-1703765891=:54546" Content-ID: X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4T170V1Wkvz4NFw This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1098556516-150255199-1703765891=:54546 Content-Type: text/plain; CHARSET=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: <8934p5r9-2op9-6nq7-3p89-369ons79p08r@mnoonqbm.arg> On Wed, 27 Dec 2023, Warner Losh wrote: > On Wed, Dec 27, 2023, 4:55 PM Bjoern A. Zeeb > wrote: > >> Hi, >> >> sdhci_fsl_fdt0: Desired SD/MMC freq: 50000000, actual: 50000000; base >> 700000000 prescale 1 divisor 14 >> GEOM: new disk sdda0 >> sdda0 at sdhci_slot0 bus 0 scbus0 target 0 lun 0 >> sdda0: Relative addr: 00000002 >> Card features: >> Card random: unblocking device. >> GEOM: new disk sdda0boot0 >> memory OCR: 00ff8080 >> sdda0: Serial Number ....... >> sdda0: MMCHC .................................. by 17 0x0000 >> GEOM: new disk sdda0boot1 >> uhub0: 2 ports with 2 removable, self powered >> >> at which point basically anything hangs. In auto-boot it is >> before/during file-system checks. >> In single user mode camcontrol devlist will show sdda0 >> but >> >> root@:/ # gpart show sdda0 >> load: 6.06 cmd: gpart 24 [g_waitfor_event] 1.28r 0.00u 0.00s 0% 2088k >> {forever} >> >> >> Unclear at which point I broke to debugger and this is where it seems to >> hang: >> >> db> trace 100088 >> Tracing pid 4 tid 100088 td 0xffff0000dc527000 >> ipi_stop() at ipi_stop+0x34 >> arm_gic_v3_intr() at arm_gic_v3_intr+0xe4 >> intr_irq_handler() at intr_irq_handler+0x80 >> handle_el1h_irq() at handle_el1h_irq+0x14 >> --- interrupt >> spinlock_exit() at spinlock_exit+0x44 >> callout_reset_sbt_on() at callout_reset_sbt_on+0x210 >> sdhci_cam_action() at sdhci_cam_action+0x284 >> xpt_run_devq() at xpt_run_devq+0x4c8 >> xpt_action_default() at xpt_action_default+0x470 >> sddastart() at sddastart+0x1bc >> xpt_run_allocq() at xpt_run_allocq+0xa8 >> xpt_done_process() at xpt_done_process+0x610 >> xpt_done_td() at xpt_done_td+0x1a8 >> fork_exit() at fork_exit+0x8c >> fork_trampoline() at fork_trampoline+0x18 >> >> >> Anyone an idea? >> > > > Looks like deadlock with another thread. Anybody else in the time keeping / > callout code? I need to a build a kernel with debugging on... New boot ... so thread 100092 now... which seems to move ... # gpart show load: 9.90 cmd: gpart 20 [g_waitfor_event] 104.65r 0.00u 0.00s 0% 2048k Tracing command kernel pid 0 tid 100011 td 0xffff0000dc2cc2c0 sched_switch() at sched_switch+0x890 mi_switch() at mi_switch+0x108 msleep_spin_sbt() at msleep_spin_sbt+0xf4 gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0x160 fork_exit() at fork_exit+0x8c fork_trampoline() at fork_trampoline+0x18 [...] Tracing command kernel pid 0 tid 100027 td 0xffff0000dc4c2900 sched_switch() at sched_switch+0x890 mi_switch() at mi_switch+0x108 msleep_spin_sbt() at msleep_spin_sbt+0xf4 gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0x160 fork_exit() at fork_exit+0x8c fork_trampoline() at fork_trampoline+0x18 Tracing command kernel pid 0 tid 100028 td 0xffff0000dc4c22c0 sched_switch() at sched_switch+0x890 mi_switch() at mi_switch+0x108 _sleep() at _sleep+0x1e4 taskqueue_thread_loop() at taskqueue_thread_loop+0x124 fork_exit() at fork_exit+0x8c fork_trampoline() at fork_trampoline+0x18 [...] Tracing command kernel pid 0 tid 100175 td 0xffff0000f16fd900 sched_switch() at sched_switch+0x890 mi_switch() at mi_switch+0x108 _sleep() at _sleep+0x1e4 taskqueue_thread_loop() at taskqueue_thread_loop+0x124 fork_exit() at fork_exit+0x8c fork_trampoline() at fork_trampoline+0x18 Tracing command kernel pid 0 tid 100177 td 0xffff0000f36eb2c0 sched_switch() at sched_switch+0x890 mi_switch() at mi_switch+0x108 msleep_spin_sbt() at msleep_spin_sbt+0xf4 taskqueue_thread_loop() at taskqueue_thread_loop+0x160 fork_exit() at fork_exit+0x8c fork_trampoline() at fork_trampoline+0x18 [...] Tracing command kernel pid 0 tid 100181 td 0xffff0000f2116900 sched_switch() at sched_switch+0x890 mi_switch() at mi_switch+0x108 _sleep() at _sleep+0x1e4 taskqueue_thread_loop() at taskqueue_thread_loop+0x124 fork_exit() at fork_exit+0x8c fork_trampoline() at fork_trampoline+0x18 Tracing command init pid 1 tid 100002 td 0xffff0000dc2c5640 sched_switch() at sched_switch+0x890 mi_switch() at mi_switch+0x108 sleepq_catch_signals() at sleepq_catch_signals+0x424 sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x1d8 kern_wait6() at kern_wait6+0x754 sys_wait4() at sys_wait4+0x84 do_el0_sync() at do_el0_sync+0x634 handle_el0_sync() at handle_el0_sync+0x48 --- exception, esr 0x56000000 Tracing command clock pid 2 tid 100057 td 0xffff0000dc4d82c0 sched_switch() at sched_switch+0x890 mi_switch() at mi_switch+0x108 softclock_thread() at softclock_thread+0x104 fork_exit() at fork_exit+0x8c fork_trampoline() at fork_trampoline+0x18 Tracing command clock pid 2 tid 100058 td 0xffff0000dc4d7c80 sched_switch() at sched_switch+0x890 mi_switch() at mi_switch+0x108 softclock_thread() at softclock_thread+0x104 fork_exit() at fork_exit+0x8c fork_trampoline() at fork_trampoline+0x18 [...] Tracing command cam pid 4 tid 100088 td 0xffff0000dc527000 sched_switch() at sched_switch+0x890 mi_switch() at mi_switch+0x108 _sleep() at _sleep+0x1e4 xpt_done_td() at xpt_done_td+0xfc fork_exit() at fork_exit+0x8c fork_trampoline() at fork_trampoline+0x18 Tracing command cam pid 4 tid 100089 td 0xffff0000dc52d000 sched_switch() at sched_switch+0x890 mi_switch() at mi_switch+0x108 _sleep() at _sleep+0x1e4 xpt_done_td() at xpt_done_td+0xfc fork_exit() at fork_exit+0x8c fork_trampoline() at fork_trampoline+0x18 Tracing command cam pid 4 tid 100090 td 0xffff0000dc52c900 sched_switch() at sched_switch+0x890 mi_switch() at mi_switch+0x108 _sleep() at _sleep+0x1e4 xpt_async_td() at xpt_async_td+0xf4 fork_exit() at fork_exit+0x8c fork_trampoline() at fork_trampoline+0x18 Tracing command cam pid 4 tid 100182 td 0xffff0000f21162c0 sched_switch() at sched_switch+0x890 mi_switch() at mi_switch+0x108 _sleep() at _sleep+0x1e4 xpt_scanner_thread() at xpt_scanner_thread+0xfc fork_exit() at fork_exit+0x8c fork_trampoline() at fork_trampoline+0x18 [...] Tracing command intr pid 12 tid 100092 td 0xffff0000dc52bc80 (CPU 1) ipi_stop() at ipi_stop+0x34 arm_gic_v3_intr() at arm_gic_v3_intr+0xe4 intr_irq_handler() at intr_irq_handler+0x80 handle_el1h_irq() at handle_el1h_irq+0x14 --- interrupt generic_bs_r_4() at generic_bs_r_4+0xc sdhci_generic_reset() at sdhci_generic_reset+0x140 sdhci_fsl_fdt_reset() at sdhci_fsl_fdt_reset+0x20 sdhci_finish_command() at sdhci_finish_command+0xf4 sdhci_generic_intr() at sdhci_generic_intr+0x388 ithread_loop() at ithread_loop+0x3ac fork_exit() at fork_exit+0x8c fork_trampoline() at fork_trampoline+0x18 [...] Tracing command geom pid 13 tid 100067 td 0xffff0000dc4da900 sched_switch() at sched_switch+0x890 mi_switch() at mi_switch+0x108 _sleep() at _sleep+0x1e4 biowait() at biowait+0xc4 g_read_data() at g_read_data+0x88 g_raid_md_taste_ddf() at g_raid_md_taste_ddf+0x104 g_raid_taste() at g_raid_taste+0x184 g_new_provider_event() at g_new_provider_event+0xac g_run_events() at g_run_events+0x2e4 fork_exit() at fork_exit+0x8c fork_trampoline() at fork_trampoline+0x18 Tracing command geom pid 13 tid 100068 td 0xffff0000dc4da2c0 sched_switch() at sched_switch+0x890 mi_switch() at mi_switch+0x108 _sleep() at _sleep+0x1e4 g_io_schedule_up() at g_io_schedule_up+0x74 g_up_procbody() at g_up_procbody+0x70 fork_exit() at fork_exit+0x8c fork_trampoline() at fork_trampoline+0x18 Tracing command geom pid 13 tid 100069 td 0xffff0000dc4d9c80 sched_switch() at sched_switch+0x890 mi_switch() at mi_switch+0x108 _sleep() at _sleep+0x1e4 g_io_schedule_down() at g_io_schedule_down+0x7c g_down_procbody() at g_down_procbody+0x70 fork_exit() at fork_exit+0x8c fork_trampoline() at fork_trampoline+0x18 [...] Tracing command gpart pid 20 tid 100206 td 0xffff000042a082c0 sched_switch() at sched_switch+0x890 mi_switch() at mi_switch+0x108 _sleep() at _sleep+0x1e4 g_waitfor_event() at g_waitfor_event+0x118 sysctl_kern_geom_confany() at sysctl_kern_geom_confany+0xd0 sysctl_root_handler_locked() at sysctl_root_handler_locked+0x11c sysctl_root() at sysctl_root+0x21c userland_sysctl() at userland_sysctl+0x190 sys___sysctl() at sys___sysctl+0x6c do_el0_sync() at do_el0_sync+0x634 handle_el0_sync() at handle_el0_sync+0x48 --- exception, esr 0x56000000 db> {out and back in} cpuid = 1 dynamic pcpu = 0x41c17f00 curthread = 0xffff0000dc52bc80: pid 12 tid 100092 critnest 1 "gic0,s28:-_fsl_fdt0" curpcb = 0xffff0000dc64ab20 fpcurthread = none idlethread = 0xffff0000dc2c4900: tid 100004 "idle: cpu1" curvnet = 0 Tracing command intr pid 12 tid 100092 td 0xffff0000dc52bc80 (CPU 1) ipi_stop() at ipi_stop+0x34 arm_gic_v3_intr() at arm_gic_v3_intr+0xe4 intr_irq_handler() at intr_irq_handler+0x80 handle_el1h_irq() at handle_el1h_irq+0x14 --- interrupt spinlock_exit() at spinlock_exit+0x44 wakeup() at wakeup+0x34 xpt_done() at xpt_done+0x164 sdhci_generic_intr() at sdhci_generic_intr+0x388 ithread_loop() at ithread_loop+0x3ac fork_exit() at fork_exit+0x8c fork_trampoline() at fork_trampoline+0x18 Tracing command geom pid 13 tid 100067 td 0xffff0000dc4da900 sched_switch() at sched_switch+0x890 mi_switch() at mi_switch+0x108 _sleep() at _sleep+0x1e4 biowait() at biowait+0xc4 g_read_data() at g_read_data+0x88 g_raid_md_taste_ddf() at g_raid_md_taste_ddf+0x104 g_raid_taste() at g_raid_taste+0x184 g_new_provider_event() at g_new_provider_event+0xac g_run_events() at g_run_events+0x2e4 fork_exit() at fork_exit+0x8c fork_trampoline() at fork_trampoline+0x18 Tracing command geom pid 13 tid 100068 td 0xffff0000dc4da2c0 sched_switch() at sched_switch+0x890 mi_switch() at mi_switch+0x108 _sleep() at _sleep+0x1e4 g_io_schedule_up() at g_io_schedule_up+0x74 g_up_procbody() at g_up_procbody+0x70 fork_exit() at fork_exit+0x8c fork_trampoline() at fork_trampoline+0x18 Tracing command geom pid 13 tid 100069 td 0xffff0000dc4d9c80 sched_switch() at sched_switch+0x890 mi_switch() at mi_switch+0x108 _sleep() at _sleep+0x1e4 g_io_schedule_down() at g_io_schedule_down+0x7c g_down_procbody() at g_down_procbody+0x70 fork_exit() at fork_exit+0x8c fork_trampoline() at fork_trampoline+0x18 Tracing command gpart pid 20 tid 100206 td 0xffff000042a082c0 sched_switch() at sched_switch+0x890 mi_switch() at mi_switch+0x108 _sleep() at _sleep+0x1e4 g_waitfor_event() at g_waitfor_event+0x118 sysctl_kern_geom_confany() at sysctl_kern_geom_confany+0xd0 sysctl_root_handler_locked() at sysctl_root_handler_locked+0x11c sysctl_root() at sysctl_root+0x21c userland_sysctl() at userland_sysctl+0x190 sys___sysctl() at sys___sysctl+0x6c do_el0_sync() at do_el0_sync+0x634 handle_el0_sync() at handle_el0_sync+0x48 --- exception, esr 0x56000000 -- Bjoern A. Zeeb r15:7 --1098556516-150255199-1703765891=:54546-- From nobody Thu Dec 28 16:25:30 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T1DQn1Bpnz566lQ for ; Thu, 28 Dec 2023 16:26:09 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T1DQm2sf5z3TdS for ; Thu, 28 Dec 2023 16:26:08 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=eo5bUL29; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2a00:1450:4864:20::534 as permitted sender) smtp.mailfrom=marietto2008@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-5553cc31f1cso3256817a12.1 for ; Thu, 28 Dec 2023 08:26:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703780767; x=1704385567; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ICPnFp8wXjc1Lixg9nlLaHLRitrp039JWrs0VeIvy5U=; b=eo5bUL296Hw9Gbnm2sTyjNavILWowO/uQiePl6cF1Sl6DIzG16kOGqLKd0TQ1aTHtt Uu48q6zO8JtxyZ2ojvuXeAVhuuSlib0RZIX1GosxNtUOfPZ2WF9BSvSOgeqfBDPl5xzf U0m+01cn72eG6jIawNj9qEUl/Wm6SndhKl4Qi8f5dHJSr0OqiV9KpYM5apO09SzBUU/g Nd5QRjc2Lrp8ly2bW16Wp7J33Y5OXNdN1KCBomvfK846/UxAA3WlugvAKN18J6nL9/7g Mj8vcKu66IV7J7rijpSHbfDoAgYTFSWWKD62/5o0e/1zPQgmBZeufMu24twHQ1BOL34C pIyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703780767; x=1704385567; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ICPnFp8wXjc1Lixg9nlLaHLRitrp039JWrs0VeIvy5U=; b=o7GsphBl0ZRvxjV/Ji27CDoFvCRzpKRwXK5NMBEsZIFWibf7SVN3ZCYnny4yz3kEHF L5D10ZtNduL03XQGOVrhBnaE2QOg3ydr9JB+m6chtDOXPrea9Gswnne2/cnyUq5u5JcP yFH6R7IozM/HPD1OIHg979tAsxKY8ZkljUw9VteOEN/XEQsFwykrGZNc/zWZkn0AnWuY 88nlpmbXcVkAYy09m/8keSTEuXNZvpbzTj2jgV0YE3fvm3Nt7gu4czCfLv2fG4wziRr6 jg1l/xDveB5gYN7AYfQoOGIimJxPMGegoTVstKdtfTnmdQwAhKKe0+Swz1Cq40mZRTf4 G2fg== X-Gm-Message-State: AOJu0Yy+30a2EFG83hZ5D+J9gR095/DEKAz/LAnTN4TqLONZzE+9IDA5 fbLUlBRi/qm2WMPd6MlucOEzTNRXLVFvi16na5c= X-Google-Smtp-Source: AGHT+IGA8yR0RGbKo/HX3+45DGyTMLJbIC6E4yS56LEd7fRLBZtqeSlDmMFPEhPN5fSH7OnGkXLSNIl2l3jSx9sxAiY= X-Received: by 2002:a17:907:1a51:b0:a23:3753:4d3 with SMTP id mf17-20020a1709071a5100b00a23375304d3mr8071300ejc.14.1703780766359; Thu, 28 Dec 2023 08:26:06 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <97aa980b9b44.6eb7f9d5c54e7@mailgate.us> In-Reply-To: From: Mario Marietto Date: Thu, 28 Dec 2023 17:25:30 +0100 Message-ID: Subject: Re: How to boot FreeBSD for arm 32 bit as DomU with u-boot on my ARM Chromebook To: Warner Losh Cc: Stefano Stabellini , Stanislav Silnicki , freebsd-arm@freebsd.org, Michal.Orzel@amd.com, xen-devel@lists.xenproject.org, Artem_Mygaiev@epam.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::534:from]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCPT_COUNT_SEVEN(0.00)[7]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4T1DQm2sf5z3TdS X-Spamd-Bar: --- Hello. I'm trying to compile u-boot-2017.05 (because it can boot a 32-bit ARM board. It is an out-of-tree u-boot build that can execute the ubldr to boot FreeBSD. I found it here : https://src.fedoraproject.org/repo/pkgs/uboot-tools/u-boot-2017.05.tar.bz2/= sha512/be270f9242a72b05463092a022bbabd54996762de1ff23bf7575124ac02e62f49572= a4e2f6f571a5019047d40027e56e35593b5cc373c4a5a39b100c3377ba93/ It has been suggested to me by the U-Boot Xen maintainers. Infact one of them said : Yes, it can boot a 32-bit ARM board. I'm not a FreeBSD person, but I've helped a FreeBSD user booting a 32-bit ARM box with u-boot (GoFlexHome Marvell Kirkwood 6281). The u-boot version was 2017.05. I used an out-of-tree u-boot build. This u-boot executed the ubldr to boot FreeBSD. Please see here : https://forum.doozan.com/read.php?3,49039,82059#msg-82059 So. I tried to compile it directly on my ARM Chromebook,but it failed. And it also fails if compiled with "ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf-" on my Ubuntu 23.04 x86_64 workstation : /Chromebook/freebsd-xen/domU-freebsd/bootloaders/u-boot-2017.05# make snow_defconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf # # configuration written to .config # /Chromebook/freebsd-xen/domU-freebsd/bootloaders/u-boot-2017.05# make scripts/kconfig/conf --silentoldconfig Kconfig CHK include/config.h CFG u-boot.cfg GEN include/autoconf.mk GEN include/autoconf.mk.dep CFG spl/u-boot.cfg GEN spl/include/autoconf.mk CHK include/config/uboot.release CHK include/generated/version_autogenerated.h UPD include/generated/version_autogenerated.h CHK include/generated/timestamp_autogenerated.h UPD include/generated/timestamp_autogenerated.h CC lib/asm-offsets.s gcc: error: unrecognized -march target: armv5 gcc: note: valid arguments are: armv4 armv4t armv5t armv5te armv5tej armv6 armv6j armv6k armv6z armv6kz armv6zk armv6t2 armv6-m armv6s-m armv7 armv7-a armv7ve armv7-r armv7-m armv7e-m armv8-a armv8.1-a armv8.2-a armv8.3-a armv8.4-a armv8.5-a armv8.6-a armv8-m.base armv8-m.main armv8-r armv8.1-m.main armv9-a iwmmxt iwmmxt2 native; did you mean =E2=80=98armv4=E2=80=99? gcc: error: missing argument to =E2=80=98-march=3D=E2=80=99 make[1]: *** [Kbuild:44: lib/asm-offsets.s] Errore 1 make: *** [Makefile:1287: prepare0] Errore 2 What should I do to compile it succesfully ? On Sat, Dec 23, 2023 at 7:36=E2=80=AFPM Mario Marietto wrote: > > I've added this parameter to bootxen.source : > > guest_loglvl=3Dall > > bootxen.source : > > mmc dev 1 > ext2load mmc 1:3 0x42000000 zImage-5.4.261-iommu-dma-on-xen > ext2load mmc 1:3 0x51000000 xen-4.17-armhf-armmp-0x51004000.ub > ext2load mmc 1:3 0x5ffec000 exynos5250-snow.dtb > fdt addr 0x5ffec000 > fdt resize 1024 > fdt set /chosen \#address-cells <0x2> > fdt set /chosen \#size-cells <0x2> > fdt set /chosen xen,xen-bootargs "console=3Ddtuart dtuart=3Dserial0 dom0_= mem=3D1152M dom0_max_vcpus=3D2 bootscrub=3D0 vwfi=3Dnative guest_loglvl=3Da= ll" > fdt mknod /chosen dom0 > fdt set /chosen/dom0 compatible "xen,linux-zimage" "xen,multiboot-module= " "multiboot,module" > fdt set /chosen/dom0 reg <0x0 0x42000000 0x0 0x49F9A8 > > fdt set /chosen xen,dom0-bootargs "console=3Dtty1 root=3D/dev/mmcblk1p4 r= w rootwait clk_ignore_unused --no-log" > bootm 0x51000000 - 0x5ffec000 > > > but when I try to boot FreeBSD I don't get more informations than usual : > > root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/domU/freebsd-xen# ./s= tart-freebsd > > Parsing config from freebsd.cfg > xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader found:= Invalid kernel > libxl: error: libxl_dom.c:571:libxl__build_dom: xc_dom_parse_image failed > libxl: error: libxl_create.c:1640:domcreate_rebuild_done: Domain 1:cannot= (re-)build domain: -3 > libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 1:Non-exis= tent domain > libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 1:Unabl= e to destroy guest > libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Destruction= of domain failed > freebsd is an invalid domain identifier (rc=3D-6) > > Are you aware about a new parameter that I can use to have more detailed = debug information ? > > On Wed, Dec 20, 2023 at 5:52=E2=80=AFAM Warner Losh wrot= e: >> >> I'd think you'd need the right virtualization loader. I'm not entirely s= ure the u-boot.bin you've been creating is for a dom-u.. >> If I misunderstood, then the below isn't good advice. Chain booting the = u-boot, the first u-boot initializes things so you want >> to start with stage after the SPL. But the different error messages sugg= est that it's trying to reboot with kexec, which >> isn't supported on armv7 at the moment. >> >> If you could boot in kvm, I think that the following would work.... Tho= ugh I'm not entirely sure how to >> specify the two .fd files in your setup. The use of qemu is to have an e= asy env to debug things... I don't >> have a chromebook to try... >> >> My first instinct would be to try qemu on x86 (this is the first step of= many to get to your destination). >> >> If you could boot the GENERIC_SD image that we produce using qemu + edk2= -arm-code.fd that would >> be a huge first step. This will give you the boot loader, I believe, to = boot in the VM that you need better >> than going via the u-boot route. Since you are booting in a virtualized = environment, I think it wouldn't >> matter which one :). >> >> So, I did the following to boot the virtualized armv7 FreeBSD environmen= t, following a post on the forums I found and knew to have the right recipe= : >> https://forums.freebsd.org/threads/run-boot-freebsd-arm-32bit-image-in-q= emu.80765/ >> >> 1. pkg install qemu >> 2. mkdir qemu-armv7-env >> 3. cd qemu-armv7-env >> 4. fetch https://download.freebsd.org/releases/arm/armv7/ISO-IMAGES/14.0= /FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD.img.xz >> 5. xz -d -T 0 FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD.img.xz >> 6. dd if=3D/dev/zero of=3Dpflash0.img bs=3D1m count=3D64 >> 7. dd if=3D/dev/zero of=3Dpflash1.img bs=3D1m count=3D64 >> 8. dd if=3D/usr/local/share/qemu/edk2-arm-code.fd of=3Dpflash0.img conv= =3Dnotrunc >> 9. dd if=3D/usr/local/share/qemu/edk2-arm-vars.fd of=3Dpflash1.img conv= =3Dnotrunc >> 10. cat > start-freebsd-arm.sh >> #!/bin/sh >> qemu-system-arm \ >> -M virt \ >> -m 1024 \ >> -drive file=3Dpflash0.img,format=3Draw,if=3Dpflash,readonly=3Don \ >> -drive file=3Dpflash1.img,format=3Draw,if=3Dpflash \ >> -drive file=3D$1.img,if=3Dvirtio,cache=3Dwritethrough \ >> -nographic \ >> -serial mon:stdio >> ^D >> 11. chmod +x start-freebsd-arm.sh >> 12. ./start-freebsd-arm.sh FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD >> >> But I hit a snag with this on qemu 8.1.2 and 8.1.3 with both 13.2 and 14= .0: >> >> Starting devd. >> Starting dhclient. >> DHCPDISCOVER on vtnet0 to 255.255.255.255 port 67 interval 7 >> Fatal kernel mode data abort: 'Alignment Fault' on read >> trapframe: 0xc4b36a60 >> FSR=3D00000001, FAR=3Ddd96701a, spsr=3D20000013 >> r0 =3D00000000, r1 =3D00000001, r2 =3D00000001, r3 =3Dc4b36b4c >> r4 =3D00000014, r5 =3Dd6618800, r6 =3Ddd96702e, r7 =3D0000022c >> r8 =3D00000000, r9 =3D0000022c, r10=3Ddd96701a, r11=3Dc4b36b90 >> r12=3D4300ffff, ssp=3Dc4b36af0, slr=3Dc04a9728, pc =3Dc04a9750 >> >> panic: Fatal abort >> cpuid =3D 0 >> time =3D 1680843057 >> KDB: stack backtrace: >> #0 0xc035786c at kdb_backtrace+0x48 >> #1 0xc02fdd20 at vpanic+0x140 >> #2 0xc02fdbe0 at vpanic+0 >> #3 0xc06304ac at abort_align+0 >> #4 0xc063052c at abort_align+0x80 >> #5 0xc063017c at abort_handler+0x480 >> #6 0xc060f480 at exception_exit+0 >> #7 0xc04a9750 at udp_input+0x288 >> #8 0xc0473f54 at ip_input+0x1e0 >> #9 0xc04447c0 at netisr_dispatch_src+0xf8 >> #10 0xc043bf2c at ether_demux+0x1a4 >> #11 0xc043d5e4 at ether_nh_input+0x480 >> #12 0xc04447c0 at netisr_dispatch_src+0xf8 >> #13 0xc043c404 at ether_input+0x50 >> #14 0xc01c0838 at vtnet_rx_vq_process+0x880 >> #15 0xc01b70d0 at vtpci_intx_intr+0xac >> #16 0xc02b87f0 at ithread_loop+0x2ec >> #17 0xc02b465c at fork_exit+0xc0 >> Uptime: 19s >> >> I don't know if this is a problem with qemu or FreeBSD's kernel... >> >> Warner >> >> On Tue, Dec 19, 2023 at 3:25=E2=80=AFPM Mario Marietto wrote: >>> >>> I've asked some help on the channel #arm on Reddit and someone replied = : >>> >>> https://www.reddit.com/r/arm/comments/18mcir8/i_cant_boot_freebsd_for_a= rm32_bit_as_domu_with/ >>> >>> Maybe his answer can be useful to understand why it does not work. >>> >>> On Tue, Dec 19, 2023 at 8:33=E2=80=AFPM Stefano Stabellini wrote: >>>> >>>> +Michal >>>> >>>> Hi Mario, >>>> >>>> I am not sure about booting FreeBSD, but I am certain that u-boot work= s >>>> fine as DomU kernel on ARMv8 (not sure about ARMv7). With this config >>>> file: >>>> >>>> name=3D"test" >>>> kernel=3D"u-boot.bin" >>>> extra =3D "console=3Dhvc0" >>>> memory=3D256 >>>> vcpus=3D1 >>>> disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ] >>>> >>>> I don't know for sure if you can boot FreeBSD but you should definitel= y >>>> be able to see the u-boot command line prompt. The fact that you are >>>> getting this message: >>>> >>>> xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader fou= nd: Invalid kernel >>>> >>>> Means that something is not right in the u-boot configuration or u-boo= t >>>> build. Michal and Artem (CCed) might know more. From what I recall, >>>> there was nothing special required to get u-boot.bin to boot as domU >>>> kernel, so now I wonder if it is an ARMv7 vs. ARMv8 issue. >>>> >>>> Cheers, >>>> >>>> Stefano >>>> >>>> >>>> On Tue, 19 Dec 2023, Mario Marietto wrote: >>>> > ....I see that some other interesting files have been produced by u-= boot when I have compiled it : >>>> > >>>> > u-boot >>>> > u-boot.lds >>>> > u-boot.bin >>>> > u-boot.map >>>> > u-boot-nodtb.bin >>>> > u-boot.dtb >>>> > u-boot.srec >>>> > u-boot-dtb.bin >>>> > u-boot.sym >>>> > >>>> > So,maybe I should use a different u-boot* file for booting FreeBSD ? >>>> > >>>> > >>>> > On Tue, Dec 19, 2023 at 4:28=E2=80=AFPM Mario Marietto wrote: >>>> > Hello to everyone. >>>> > >>>> > I have compiled the needed u-boot.bin from scratch using this proced= ure : >>>> > >>>> > # git clone https://github.com/u-boot/u-boot.git >>>> > # cd u-boot >>>> > # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make snow_defconfi= g : this line generates the file .config >>>> > # nano .config and I've added these parameters : >>>> > >>>> > CONFIG_ARMV7_NONSEC=3Dn >>>> > CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy >>>> > >>>> > the uboot-bin file is generated with this command : >>>> > >>>> > # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make >>>> > >>>> > At this point,I took a look inside the .config file and I saw that t= he parameter "CONFIG_ARMV7_NONSEC=3Dn" has been removed. So,for >>>> > some reason,it is not accepted and this could be a problem.... >>>> > >>>> > These are the xen config files that I've used : >>>> > >>>> > nano freebsd.cfg >>>> > >>>> > name=3D"test" >>>> > kernel=3D"u-boot.bin" >>>> > extra =3D "console=3Dhvc0" >>>> > memory=3D256 >>>> > vcpus=3D1 >>>> > disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ] >>>> > >>>> > nano start-freebsd >>>> > >>>> > xl create freebsd.cfg >>>> > xl console freebsd >>>> > >>>> > This is what happens when I launch the vm : >>>> > >>>> > # ./start-freebsd >>>> > >>>> > Parsing config from freebsd.cfg >>>> > xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader f= ound: Invalid kernel >>>> > libxl: error: libxl_dom.c:571:libxl__build_dom: xc_dom_parse_image f= ailed >>>> > libxl: error: libxl_create.c:1640:domcreate_rebuild_done: Domain 1:c= annot (re-)build domain: -3 >>>> > libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 1:Non= -existent domain >>>> > libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 1:= Unable to destroy guest >>>> > libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Destru= ction of domain failed >>>> > freebsd is an invalid domain identifier (rc=3D-6) >>>> > >>>> > >>>> > On Mon, Dec 18, 2023 at 12:39=E2=80=AFPM Mario Marietto wrote: >>>> > So,ok,I should have said "the second u-boot" ; since the first= u-boot binary is the "u-boot binary located in the RO >>>> > memory" of the Chromebook". Sorry for the confusion. >>>> > >>>> > On Mon, Dec 18, 2023 at 12:35=E2=80=AFPM Mario Marietto wrote: >>>> > ---> There are no specific options in u-boot devoted to FreeBS= D >>>> > >>>> > This is an important factor. So,what about if,instead of compiling a= new version of u-boot on the partition 2,I will >>>> > recompile the u-boot customized version created by the virtual open = system in 2014,that should be installed on the first >>>> > partition ? It could work if there are no differences between the u-= boot that should boot Linux and the u-boot that >>>> > should boot FreeBSD. >>>> > >>>> > Can you give a look at the u-boot source code created by virtual ope= n systems ? You can find it on my google drive : >>>> > >>>> > https://drive.google.com/file/d/1eAaZMfd6CU0xiqQfH7sq5wGVzzO09BRm/vi= ew?usp=3Dsharing >>>> > >>>> > I need to understand if I can recompile it without problem so that i= t can satisfy my needs (the ability of the file >>>> > u-boot.bin to boot FreeBSD as domU under Xen,as explained by Stefano= Stabellini,the xen developer that suggested to me >>>> > what I could do to have FreeBSD virtualized under Xen on my Arm Chro= mebook) ; otherwise the risk is to find later >>>> > problems that will make me troubles and that I will not able to fix. >>>> > >>>> > I gave a look at the virtual open system u-boot and I didn't see any= arndale_defconfig inside. So,If I have understood >>>> > correctly,I should put that file inside the root of the u-boot sourc= e code,let's say here : >>>> > >>>> > marietto:/home/marietto/Desktop/Files/u-boot_FreeBSD/u-boot-vos # ls >>>> > >>>> > .checkpatch.conf README doc = net >>>> > .git api drivers = onenand_ipl >>>> > .gitignore arch dts = post >>>> > COPYING board examples = rules.mk >>>> > CREDITS boards.cfg fs = scripts >>>> > MAINTAINERS common include = snapshot.commit >>>> > MAKEALL config.mk lib = spl >>>> > Makefile cros mkconfig = test >>>> > PRESUBMIT.cfg disk nand_spl = tools >>>> > >>>> > and I should do : make and make install ? and the file I need,u-boot= .bin will be generated ? >>>> > >>>> > I didn't find any pre made configuration file inside : >>>> > >>>> > u-boot-vos # find . -type f -name "exynos*" >>>> > >>>> > ./include/exynos-fb.h >>>> > ./include/configs/exynos5-common.h >>>> > ./doc/device-tree-bindings/spi/exynos-spi.txt >>>> > ./doc/device-tree-bindings/usb/exynos-usb.txt >>>> > ./drivers/power/exynos-tmu.c >>>> > ./drivers/power/exynos-cpufreq.c >>>> > ./drivers/video/exynos-fb.c >>>> > ./drivers/spi/exynos_spi.c >>>> > ./board/samsung/dts/exynos5250-spring.dts >>>> > ./board/samsung/dts/exynos5250-smdk5250.dts >>>> > ./board/samsung/dts/exynos5250-snow.dts >>>> > ./board/samsung/dts/exynos5250-daisy.dts >>>> > ./arch/arm/include/asm/arch-exynos5/exynos-cpufreq.h >>>> > ./arch/arm/include/asm/arch-exynos5/exynos-tmu.h >>>> > ./arch/arm/dts/exynos5250.dtsi >>>> > ./arch/arm/dts/exynos-periph-id.dtsi >>>> > ./arch/arm/cpu/armv7/exynos5/exynos_cache.c >>>> > >>>> > u-boot-vos # find . -type f -name "arndale*" >>>> > >>>> > For sure I can't use a newer version of u-boot because otherwise the= patches needed to bypass the bootloader protections >>>> > of the Arm Chromebook (such as a lot of different patches needed to = boot correctly Linux) will be broken ; anyway,since >>>> > it works,I don't need to use an updated version of u-boot. >>>> > >>>> > ----> As per my experience, you have to respect these two options, c= ompiling u-boot for >>>> > FreeBSD: https://github.com/freebsd/freebsd-ports/blob/main/sysutils= /u-boot-master/files/FreeBSD_Fragment >>>> > >>>> > It says that I should use these parameters : >>>> > >>>> > CONFIG_ARMV7_NONSEC=3Dn >>>> > CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy >>>> > >>>> > These are the parameters used to configure a Linux kernel. I don't u= nderstand what's the relation between the compilation >>>> > of a linux kernel and u-boot. In the past I tried to recompile u-boo= t,but I didn't have the need to set up those >>>> > parameters,so I don't know how to do it (but I know how to recompile= a Linux kernel). >>>> > >>>> > ---> I'm not sure that I'm getting you right, as I don't understand = what you mean under "the first u-boot". >>>> > >>>> > >>>> > I'm talking about first u-boot because the whole procedure to boot L= inux on the ARM Chromebook,that's explained here : >>>> > >>>> > http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromeb= ook/ >>>> > >>>> > >>>> > at some point they say : >>>> > >>>> > >>>> > To be able to run KVM on ARM platforms, the kernel has to be booted = in hypervisor mode. Because of this relatively recent >>>> > requirement (due to the introduction of the virtualization extension= s), up until now all booting methods would boot the >>>> > kernel in the standard Supervisor mode. >>>> > >>>> > For the ARM Chromebook the default boot procedure doesn't allow us t= o boot in hypervisor mode. Although the laptop's boot >>>> > mechanism is based on the frequently used u-boot, the binary is loca= ted in RO memory. Fortunately, a chained u-boot >>>> > mechanism can be used (i.e. starting another u-boot after the origin= al). We can then enter hypervisor mode from our >>>> > custom iteration of u-boot and subsequently load our kernel and user= space. >>>> > >>>> > So,the first u-boot is the u-boot provided by virtual open systems,t= hat's able to chainload the "u-boot binary located in >>>> > RO memory" , that does not boot Chrome OS in hypervisor mode. We don= 't need it if we want to boot Linux with kvm or xen >>>> > enabled. >>>> > >>>> > >>>> > On Sun, Dec 17, 2023 at 1:28=E2=80=AFAM Stanislav Silnicki wrote: >>>> > I'm not an expert in the topic, I only know, that ARM has divi= ded hardware into two worlds - Secure and >>>> > Not-So, strictly limiting any software, running in non-secure = world with access to functions and >>>> > resources. https://developer.arm.com/documentation/den0013/d/S= ecurity/TrustZone-hardware-architecture?lang=3Den >>>> > >>>> > I'm not sure, that I'm getting you right, as I don't understand what= you mean under "the first u-boot". >>>> > >>>> > As I understand, virtualization (HYP) is running in non-secure world= (https://developer.arm.com/documentation/ddi0406/c/System-Level-Architectur= e/The-System-Level-Programmers--Model/The-Virtualization-Extens >>>> > ions), so my guess (only guess!!!), virtualization software has to p= repare (configure) HW platform in the way, >>>> > that FreeBSD kernel will not lack any resources, required to configu= re MPU, VA, etc. >>>> > So, if you lucky to boot virtualizer, which is aware of target OS, t= hat maybe you can boot the kernel. Although, I >>>> > doubt, that you need to boot 'second' u-boot to boot the kernel - th= ere is simply ubldr, which you can hook somehow >>>> > from virtualizer.... >>>> > >>>> > Stan >>>> > >>>> > >>>> > >>>> > Mario Marietto wrote: >>>> > >>>> > >>>> > ---> As I understand, it makes sure that u-boot keeps in secur= e mode during boot and passes control to >>>> > ubldr, which boots FreeBSD kernel, in that mode. >>>> > >>>> > Can you elaborate your sentence more ? I know that the bootloader se= cure mode is bypassed by the virtual open >>>> > systems u-boot. Are you saying that when the control passes to the s= econd u-boot,it will happen in secure >>>> > mode,so that the bypass that happened loading the first u-boot,is an= nulled ? If this is true,maybe can I boot >>>> > FreeBSD using the virtual-open-system custom u-boot ? Is this compat= ible with FreeBSD ? Where can I find the >>>> > u-boot.bin that the xen developer talked about ? thanks bro'. >>>> > >>>> > >>>> > >>>> > On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM Stanislav Silnicki wrote: >>>> > Hi Mario, >>>> > >>>> > U-Boot beast is hiding in this den: https://source.denx.de/u-boot/u= -boot.git >>>> > I took a brief look at your post and it seems to me, that option CON= FIG_CMO_BY_VA_ONLY is irrelevant to >>>> > your target armv7 32 bit >>>> > platform: https://source.denx.de/u-boot/u-boot/-/blob/master/arch/ar= m/cpu/armv8/Kconfig?ref_type=3Dheads#L3 >>>> > >>>> > As for compiling the u-boot, it is a doable task, given that you und= erstand what you are doing. There >>>> > are no specific options in u-boot devoted to FreeBSD. It is a boot l= oader, whose mission to make basic >>>> > hardware initialization, read you kernel file from some media into R= AM and then pass it control. >>>> > >>>> > Basically, you can grab some defconfig, prepared for any other Exyno= s5250 based board (say, this one: >>>> > https://source.denx.de/u-boot/u-boot/-/blob/master/configs/arndale_d= efconfig?ref_type=3Dheads) and adopt >>>> > it somehow. >>>> > >>>> > As per my experience, you have to respect these two options, compili= ng u-boot for >>>> > FreeBSD: https://github.com/freebsd/freebsd-ports/blob/main/sysutils= /u-boot-master/files/FreeBSD_Fragment >>>> > >>>> > As I understand, it makes sure, that u-boot keeps in secure mode dur= ing boot and passes control to >>>> > ubldr, which boots FreBSD kernel, in that mode. Otherwise, there a l= ot of surprises you may realize. >>>> > >>>> > Hope, this will help to progress you tasks >>>> > Stan >>>> > >>>> > Mario Marietto wrote: >>>> > >>>> > >>>> > Hello. >>>> > >>>> > I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM Chr= omebook. Basically there are >>>> > two ways to accomplish this task : >>>> > >>>> > 1) to write a patch that allows the FreeBSD kernel to boot as = a zImage file. This could be >>>> > accomplished applying this patch to a specific file that's on = the source code of FreeBSD : >>>> > >>>> > >>>> > https://xenbits.xen.org/gitweb/?p=3Dp...8;hb=3D0782e25d98cc139= 1472717035f986c979edef0c9 >>>> > >>>> > >>>> > This patch was written by Julien Grall a lot of time ago and n= ow it does not work anymore. >>>> > This is the reason : >>>> > >>>> > >>>> > It appears FreeBSD-CURRENT removed the last step convert= ing the kernel file to >>>> > kernel.bin. The patch can be readily rebased, but withou= t kernel.bin that >>>> > doesn't do too much >>>> > >>>> > >>>> > >>>> > So,without a rebase of that patch the first option is not applicable= . And I'm not able to fix it. >>>> > >>>> > 2) booting FreeBSD using U-Boot,as explained to me by a xen develope= r : >>>> > >>>> > >>>> > I was trying to explain why and how Julien's patch works so th= at you could be the one >>>> > to re-do something similar or fix the patch on the FreeBSD ker= nel that you are >>>> > working with. I am happy to help review and write patches but = I don't work with the >>>> > FreeBSD kernel so I wouldn't be able to help you quickly. Howe= ver, I might have a >>>> > suggestion. Do you know if FreeBSD can be booted by U-Boot ? B= ecause U-Boot >>>> > definitely boots as Xen on ARM guest firmware/bootloader. You = should be able to build >>>> > U-Boot and use the U-Boot binary as Xen guest kernel, then U-B= oot could load FreeBSD >>>> > from disk or network and start it. For instance as domU config= file: >>>> > >>>> > kernel=3D"/home/petalinux/u-boot.bin" >>>> > disk =3D [ '/home/petalinux/test.img,raw,xvda' ] >>>> > >>>> > I know it is important to build u-boot with the following conf= ig to make it work on >>>> > Xen. >>>> > >>>> > CONFIG_CMO_BY_VA_ONLY=3Dy >>>> > >>>> > >>>> > >>>> > This option seems more doable to me according to my knowledge. But I= need to understand how to do >>>> > it. >>>> > >>>> > Well,let's say that on the ARM Chromebook I'm forced to use and inst= all a customized version of >>>> > u-boot,created by virtual open systems,because it is the only one th= at allows bypassing its >>>> > bootloader protection. You can find more information here : >>>> > >>>> > http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chromeb= ook/?vos=3Dtech >>>> > >>>> > This is the relevant section to read : >>>> > >>>> > >>>> > Bootloader : >>>> > >>>> > If you wish to skip this chapter you can download a pre-compil= ed binary of the >>>> > bootloader: >>>> > >>>> > >>>> > $ wget >>>> > http://www.virtualopensystems.com/downloads/guides/kvm_on_chro= mebook/nv_u-boot-snow.kpart >>>> > >>>> > >>>> > To be able to run KVM on ARM platforms, the kernel has to be b= ooted in hypervisor >>>> > mode. Because of this relatively recent requirement (due to th= e introduction of the >>>> > virtualization extensions), up until now all booting methods w= ould boot the kernel in >>>> > the standard Supervisor mode. For the ARM Chromebook the defau= lt boot procedure >>>> > doesn't allow us to boot in hypervisor mode. Although the lapt= op's boot mechanism is >>>> > based on the frequently used u-boot, the binary is located in = RO memory. Fortunately, >>>> > a chained u-boot mechanism can be used (i.e. starting another = u-boot after the >>>> > original). We can then enter hypervisor mode from our custom i= teration of u-boot and >>>> > subsequently load our kernel and userspace. >>>> > >>>> > Checkout the needed u-boot code : >>>> > >>>> > >>>> > $ git clone git://github.com/virtualopensystems/u-boot.git$ cd= u-boot$ >>>> > ./scripts/build.sh >>>> > >>>> > >>>> > If successful, a message about how to copy the bootloader on t= he USB flash disk or SD >>>> > card will appear. We will use it later when preparing the boot= medium to start our >>>> > system. If you have followed the Setting up the boot medium ch= apter and you have a >>>> > prepared boot device, then you can update u-boot by running : >>>> > >>>> > >>>> > $ sudo dd if=3Dnv_uboot-snow.kpart of=3D/dev/sdX1 >>>> > >>>> > >>>> > >>>> > so,the needed u-boot that we must use should be installed on the fir= st partition of the sd card. >>>> > >>>> > There is another relevant section to read : >>>> > >>>> > >>>> > Setting up the boot medium >>>> > >>>> > Now it is time to copy all the relevant files that we created = in the previous >>>> > chapters,and use them to boot Chromebook with a different kern= el and OS. In all these >>>> > examples the device /dev/sdX is used. Take extra care to chang= e the examples to the >>>> > device that you have attached. Insert the boot medium on your = workstation and >>>> > carefully execute the following step. First we need to properl= y format the boot >>>> > medium. >>>> > >>>> > In the uboot source directory : >>>> > >>>> > >>>> > $ sudo ./scripts/sdcard.sh /dev/sdX >>>> > >>>> > >>>> > This will erase all data and create 4 partitions in the medium= , along with copying >>>> > the u-boot binary to the first partition: >>>> > >>>> > >>>> > Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot) >>>> > Partition 2 =3D not used >>>> > Partition 3 =3D EXT2 partition for u-boot files (uImage and ex= ynos5250-snow.dtb) >>>> > Partition 4 =3D EXT4 partition for userspace files >>>> > >>>> > >>>> > With u-boot being copied, next is the kernel image and DTB fil= e. From the kernel >>>> > source execute : >>>> > >>>> > >>>> > $ mkdir ../mnt/ >>>> > $ sudo mount /dev/sdX3 ../mnt/ >>>> > $ sudo cp arch/arm/boot/uImage ../mnt/ >>>> > $ sudo cp arch/arm/boot/dts/exynos5250-snow.dtb ../mnt/ >>>> > $ sudo umount /dev/sdX3 >>>> > >>>> > >>>> > Finally, we have to copy the Ubuntu userspace filesystem that = we created earlier: >>>> > >>>> > >>>> > $ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./precise/* mnt/$ sudo= umount /dev/sdX4 >>>> > >>>> > >>>> > >>>> > Now,my idea is to chainload the already chain loaded u-boot created = by V.O.S to the new u-boot >>>> > that we need for booting FreeBSD and that can be installed in the pa= rtition n.2,as shown in this >>>> > scheme,because it is not used : >>>> > >>>> > >>>> > Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot) >>>> > Partition 2 =3D not used (maybe we can install the u-boot for arm 32= bit,compatible with FreeBSD on >>>> > this partition) >>>> > Partition 3 =3D EXT2 partition for u-boot files (uImage and exynos52= 50-snow.dtb) >>>> > Partition 4 =3D EXT4 partition for userspace files >>>> > >>>> > >>>> > Take in consideration that default boot string is hardcoded here,in = the snow.h file of the custom >>>> > u-boot created by VOS : >>>> > >>>> > >>>> > https://github.com/virtualopensyste...18a39b6c177dff58a/include/conf= igs/snow.h#L101 >>>> > >>>> > >>>> > and it needs to be recompiled because it should point to the partiti= on n.2,where I will install >>>> > the u-boot files as explained here : >>>> > >>>> > >>>> > https://wiki.freebsd.org/arm/Chromebook >>>> > >>>> > >>>> > I have some questions to ask before I start working on this. >>>> > >>>> > 1) The xen developer said : >>>> > >>>> > >>>> > You should be able to build U-Boot and use the U-Boot binary a= s Xen guest kernel... >>>> > >>>> > >>>> > >>>> > where is the u-boot binary,according to this document ? >>>> > >>>> > https://wiki.freebsd.org/arm/Chromebook >>>> > >>>> > I don't see it. >>>> > >>>> > >>>> > 2) where is the source code of the file that I can get here : >>>> > >>>> > http://commondatastorage.googleapis.com/chromeos-localmirror/distfil= es/nv_uboot-snow-simplefb.kpart.bz2 >>>> > >>>> > I need the source code if I want to recompile u-boot so that it can = point to the partition 4. >>>> > >>>> > Maybe it can be found on this link : >>>> > >>>> > http://linux-exynos.org/dist/chromebook/nv_uboot/ >>>> > >>>> > but it can't be opened.... >>>> > >>>> > >>>> > 3) in this specific scenario the source code of u-boot should run on= arm 32 bit,not on arm >>>> > 64,because I have the Samsung Chromebook "SNOW" model XE303C12,that'= s powered by a Samsung Exynos >>>> > 5250 (ARMv7 32 bit Cortex A15) Soc. >>>> > >>>> > >>>> > 4) I'm not sure if I can chainload the customized u-boot created by = V.O.S that should be >>>> > installed on the first partition with the u-boot tailored for bootin= g FreeBSD that should be >>>> > installed on the partition 2.... >>>> > >>>> > >>>> > 5) the xen developer said that u-boot should be compiled enabling th= is option : >>>> > >>>> > >>>> > Code: >>>> > >>>> > CONFIG_CMO_BY_VA_ONLY=3Dy >>>> > >>>> > >>>> > Well,can you provide some good source that can help me to understand= how I can recompile u-boot >>>> > for FreeBSD ? thanks. >>>> > >>>> > -- >>>> > Mario. >>>> > >>>> > >>>> > >>>> > -- >>>> > Mario. >>>> > >>>> > >>>> > >>>> > -- >>>> > Mario. >>>> > >>>> > >>>> > >>>> > -- >>>> > Mario. >>>> > >>>> > >>>> > >>>> > -- >>>> > Mario. >>>> > >>>> > >>>> > >>>> > -- >>>> > Mario. >>>> > >>>> > >>> >>> >>> >>> -- >>> Mario. > > > > -- > Mario. -- Mario. From nobody Thu Dec 28 19:11:42 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T1J5z2KV1z54QMr for ; Thu, 28 Dec 2023 19:11:51 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T1J5y2JNmz4Nbg for ; Thu, 28 Dec 2023 19:11:50 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=karels.net header.s=mail2 header.b="aU+/y3B/"; spf=pass (mx1.freebsd.org: domain of mike@karels.net designates 3.19.118.201 as permitted sender) smtp.mailfrom=mike@karels.net; dmarc=none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.17.1/8.17.1) with ESMTP id 3BSJBhhf021615 for ; Thu, 28 Dec 2023 13:11:43 -0600 (CST) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1703790703; bh=5XtPxnxyOsjgtAAr6yi4pc9qzhDwuAsVcsWsi4STXzw=; h=From:To:Subject:Date; b=aU+/y3B/R6e+S6aKssAl1iIclXz6+ft5z8ajhZ+re++WySpliEWAwj4Plplzh37QW RGtYB1phRLf5GPeZMXR6qRVoX1uUA6mak459qCZHc1btTZ9dndQQ6bLcydJppJKirZ IVFARI7TWgICF0E88X6kywsRVLeC90VwxH8ICRA7hLjnOw5BbiNsAJRncjchmk/5sF Ql2UM7vVi62k7MCNGRa9b3xru+RxQ3pl+FAMzgb4FV5REMwXDye6IJ1gE/JlDAAMvT b1KubF3emOXqMnMSqO2BfYdTTDGiwE9AOrY8g6lwGpjFdg/DRZV6/7es+gRY4xvr6y mfXxJOKrrX2KQ== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id gK9ECW/IjWVtVAAAs/W3XQ (envelope-from ) for ; Thu, 28 Dec 2023 13:11:43 -0600 From: Mike Karels To: freebsd-arm Subject: enabling powerd on RPi Date: Thu, 28 Dec 2023 13:11:42 -0600 X-Mailer: MailMate (1.14r6015) Message-ID: List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; R_DKIM_ALLOW(-0.20)[karels.net:s=mail2]; R_SPF_ALLOW(-0.20)[+ip4:3.19.118.201]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[karels.net:+]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; TO_DN_ALL(0.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US]; FROM_EQ_ENVFROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[mike]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[karels.net]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4T1J5y2JNmz4Nbg X-Spamd-Bar: --- I am looking at enabling powerd by default on the Raspberry Pi 4 and maybe others. There is a bug from 2021 on the subject which has gotten some recent discussion, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256836. Also, problems come up from time to time about performance problems because people don't know to enable powerd. It makes FreeBSD look much slower than Linux. The simplest action is to enable powerd by default on the arm64-aarch64-RPI images. This would affect RPi 4 and variants, also RPI 3* and later RPi 2. I enabled powerd on an RPi 3B+, and it seems to have no issues; it seems to work. Does anyone know of a disadvantage of enabling powerd on RPI images for all targets? The alternative would be to configure at the first boot, although I'm not positive of a definitive way to identify the RPi variants. Maybe just looking for a dev.cpu.0.freq sysctl node would suffice. If no one objects, I will make changes to enable powerd on RPI snapshots for 15-current, and we can see what happens. Mike From nobody Thu Dec 28 19:14:01 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T1J9D30yJz54Q5p for ; Thu, 28 Dec 2023 19:14:40 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T1J9C4F3hz4NgX for ; Thu, 28 Dec 2023 19:14:39 +0000 (UTC) (envelope-from karl@denninger.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net; dmarc=pass (policy=none) header.from=denninger.net Received: from denninger.net (096-033-195-197.res.spectrum.com [96.33.195.197]) by colo1.denninger.net (Postfix) with ESMTP id 9B85D2110D5 for ; Thu, 28 Dec 2023 14:14:08 -0500 (EST) Received: from dummy.faircode.eu (unknown [IPv6:2607:fb91:2f18:5873:ad2:8251:67e4:adbc]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 97DEC1F6B82 for ; Thu, 28 Dec 2023 14:14:02 -0500 (EST) Date: Thu, 28 Dec 2023 14:14:01 -0500 (EST) From: Karl Denninger To: freebsd-arm@freebsd.org Message-ID: In-Reply-To: References: Subject: enabling powerd on RPi List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha-256; protocol="application/pkcs7-signature"; smime-type=signed-data; boundary="----=_Part_15_223621763.1703790841049" X-Correlation-ID: X-Spamd-Result: default: False [-4.80 / 15.00]; SIGNED_SMIME(-2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[denninger.net,none]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; MIME_BASE64_TEXT(0.10)[]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[karl]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4T1J9C4F3hz4NgX X-Spamd-Bar: ---- ------=_Part_15_223621763.1703790841049 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SSBoYXZlIGhhZCBpdCBlbmFibGVkIG9uIFJQSSAzcyBmb3IgdGhlIGxhc3Qgc2V2ZXJhbCB5ZWFy cyB3aXRob3V0IGluY2lkZW50Lgo= ------=_Part_15_223621763.1703790841049 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExDTALBglghkgBZQMEAgEwCwYJKoZIhvcNAQcBoIAwggcSMIIE +qADAgECAhICxvMh+D0BXW3fcVIJqc5dY18wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMx EDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1 ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0y MjA2MjkxNjE2MzZaFw0yNzA2MjgxNjE2MzZaMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQIDAlUZW5u ZXNzZWUxFzAVBgNVBAMMDkthcmwgRGVubmluZ2VyMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIIC CgKCAgEAvh1UssVbSYctzobPjwBkbjv/w4WvQNepeRTwE6+sLnXvc41+X9pa5EclPL4Ql02Vu1m7 1mSqXGfK9HbWZoivbhefBHOoYb35MSc24PelhwcORbpneWoWc7giQ7QgFlvEe/yjfs8M0H9fgdzF S5m2lwBQbis8kioSjHB2yt/8I1GE4Mvt1Cur9kga6ML5FAQvo8TYN1stdhrE13FEv/BWCF4FVT4H 2Wa2ySW+R1jkKb74SC6Twg98bGCRTShD5bVylh0+0LXNhzaopIDcI/KKjm/j3mRjIlmqbGrSpvJs bjjhjhAYQKE1U8FB5TDU4OkFAibblhQit/KjgspPR2o/vOpVFPERuhZEV1oDGzUJtZlkREIcN2sY Bi0p7Y4585ya+b7L10mEenPlyi3eSkGXEuiy/BR2DY6lShwWDPoQ5602TKmttCSwBdWGoLrQ4jEV EVNt4lku2wPbTHF3KpHJU0g7RbcWoUYn10SOxKathkirhF3v9U32+QhPELGwqRrH0sL9rWf0qalR tPDHUYl8TebZmYkFqNeSMlqHijl5f4SsQPSj7gx54F19Ntm9ZcvuWTmW8QQGWTKHeMuG+BYkVIUS Pe6/ZQsbD/xDx7rkyGfNgWIa4W7Wm/B7kaNqH53tk3wFmNgZQOxMTPF0oTHfW0T2azU6JD0D1Alg oAnSAE0CAwEAAaOCAc8wggHLMDwGCCsGAQUFBwEBBDAwLjAsBggrBgEFBQcwAYYgaHR0cDovL29j c3AuY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwDgYD VR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAzBglghkgBhvhCAQ0E JhYkT3BlblNTTCBHZW5lcmF0ZWQgQ2xpZW50IENlcnRpZmljYXRlMB0GA1UdDgQWBBSxJZjVnlYL AT3uzvDYgc4742J6UTCBygYDVR0jBIHCMIG/gBRdwF7Cp43TzQ+fm8VRAhirXNOOz6GBkaSBjjCB izELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExEjAQBgNVBAcMCU5pY2V2aWxsZTEZMBcG A1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENBMSEwHwYDVQQD DBhDdWRhIFN5c3RlbXMgTExDIDIwMTcgQ0GCEwDkSIqCEM5eu9/FjGMhNdgN2EgwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQCqrnO3LtMXPBTbQEGrmb6H A81kI+xxvWLzG1pzIvnJIYgN63VuTcFoNBwYQYaNWJZ6lfp7QlRNi/Hs6IR1pvigHX14Ka2i/Olb J98sDZWbv9wjjKaNgC7h5Z/GELR92PHm78yjHZX9m+Vgfu5jhSMVyK+AJzTiygpKuWYcwuiVuib8 Nz9HLIhmt1K32rWCA+Tbz4JGkLxIIphIxt6bGasEEy9lsaIb8O/Nz6w7d8EtF3jYb0OtYN0CRWSr r/m5hh92AUj6NbejVBgK/iaM1+ZQ4oQfCRpAbfzcHWHnOPWtPLi9AWz2gCezY7iDxu2NAJOz12U9 +8sf2ZWvT8yzCRYG3pTpGmrXc225TGTwxFWdu5eJRjJlfNy5t2D9e7HQMkv1qZmr+1piVJEPYriC s0qXXPNovTH7o5db2wbcLZBzTz7SrrpSBTOGcKzyo5VXS6k0qg/JvchxImND7gKKKutzqSVheobz GoiDwVhAFSGg1vbhtDLIS5fQ5x5zMqyU37gt92fZjhjM+3UQYyXeWFtNsQM2J1LhATqY/i0L+UfF yBTBxV5LahCr0K13jNkVPj3GaijgZE5LcQS59zSOVXwNeSZNHOVeV3DqqN6dob68L164p629qRER J6Kpn65F098zquWOq8kR/Lu9+JRhBdHSC186FeDzO1xYraE3j6BI5jCCBqAwggSIoAMCAQICEwDk SIqCEM5eu9/FjGMhNdgN2EgwDQYJKoZIhvcNAQELBQAwgYsxCzAJBgNVBAYTAlVTMRAwDgYDVQQI DAdGbG9yaWRhMRIwEAYDVQQHDAlOaWNldmlsbGUxGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMx GDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTEhMB8GA1UEAwwYQ3VkYSBTeXN0ZW1zIExMQyAyMDE3 IENBMB4XDTE3MDgxNzE2NDIxN1oXDTI3MDgxNTE2NDIxN1owezELMAkGA1UEBhMCVVMxEDAOBgNV BAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lz dGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTCCAiIwDQYJKoZI hvcNAQEBBQADggIPADCCAgoCggIBALVomi01Qj5biM/vFAM7wv9vheIXhGyz07QH7e8wfs2OTzl9 nTnZCFmkxWWlpo76wIgqobeg0Ru44fMkH80MkWeqHuKMHCF1a612yrbdTHpO/GBqTIw+lPpNE0Qn NwFVADSSlvLUNUPQQpIr8WtZYGIWZLGDupR+Yir+YzOATp6keS3JEzc4ard1tF05SB+6Zauodc6t 0nPTrET03Ni9z22ipmd3v0VS0T+dJlWbVVLcaurtEpXrmie9fdA5bhbWV0QfCCBpnGBYY2JH8Ph6 iwAYXGe5h5aUoQLvRz30ynWCJa7H7u6vqFzYT4BpMaH58Z6KM7mrjQ4Z3500yArwSzScNHDzWVFy XbhJZQSTL3LwMCuAgWVF3p3dljCBzUMxNaRNq/HdmkBKnlNaKHrIjwALBuhO+VRh6igyw+01r0Tp RDWe3tUSLmzKPGcOW1sQWgthxcFyqFGEURMl70J16ci0AcC07JrfDn5+YLaP/EnPb2iDUodipYeW jcqzCL0bvtqf7OHqdaQy4ez7TcNTwNo4RbNkRq/eVUPi7vpspENNuGHRswCTh5euIYuHgxShfciZ 9yvomjKF5WsB0cMv8GLFswfVRSyl5G6pAxDlvZPqlptc/Sg4HgWqV1aIOAkEZF3NYuAJgbzA8YkZ iAeJuXmsWIjkjHcVCdyKlzpJ1TM5AgMBAAGjggEKMIIBBjAdBgNVHQ4EFgQUXcBewqeN080Pn5vF UQIYq1zTjs8wgcAGA1UdIwSBuDCBtYAUG7WhGFQw0TOM4OiUORrmThAQMGKhgZGkgY4wgYsxCzAJ BgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRIwEAYDVQQHDAlOaWNldmlsbGUxGTAXBgNVBAoM EEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTEhMB8GA1UEAwwYQ3Vk YSBTeXN0ZW1zIExMQyAyMDE3IENBggkArEDLVYGjaRgwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwDQYJKoZIhvcNAQELBQADggIBAIHnrzpQIFUhPnaM7ezP2kq6HG4LaemLxm+g HC38gf2mI8DXn8IYXVd5dR27aqaE6MeRUs2A7tcHUbwK6W7Gh84hRx7RpkbIH69nXKUdeUx4HRHz Z/l3Pf9PtFCyjnljZWiDZlvs9hMLkH2g3LfKWyc0vNqdiVxbcAB/NlxvFi4B2e6rQibcSkabwOgi 1Rx/WkN7O6Aqb/Iq021jqwPIQ2O0TFnfvtxgDch0jCqfUyHg4BP9GaHxq7atkCjT5sxgHL0LXUTH SFDzNZy89kEOfi/hG07yD4q5BlBwmc7T0sk23D3hbd3aaPhrteuwoydkq+bpb0EkhDg2aG3jBcC0 9DXED5CnE9OawYBTQK8eapULtcLerEWFo6sPZ2y84ArpKfcwSkf9it9gJftrtzPnNbcOwlDqjelh +edDP6GfAuXPgwrXs0gDRY50AX0hu1Cpqt/jj48TJRsq3PWvQoZ4Yuz5UZ13YUsDR7vK7PEkNhxo FNXCpoeFTb8Wdr+MZTsGGsoe0ltv9eUt4UnbjK+6JgqlhZBJLJm7VH+C9mMd4ZvfjiMYGxl0IOt3 G1BBxUDo7GwwA9JQ8yuWD0tYQsQRidW6VAl6tbGlR5wYf3Y7TrDCY+DKSTP/9SaaCNVKHsSs28vS VRhQx+6dhU787mHCFb4/iC+IJfMEV5O0Nkfbn07tMIIGpDCCBIygAwIBAgIJAKxAy1WBo2kYMA0G CSqGSIb3DQEBCwUAMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3Rl bXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjIyMTFa Fw0zNzA4MTIxNjIyMTFaMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTCCAiIwDQYJKoZIhvcN AQEBBQADggIPADCCAgoCggIBAMLtuLlcCZbjm/Oeev1Q9nvYhmkSpEwmfMZ1wcNU10QGkO641Jeo fIBUbft1yRBXSAbaNf/9ePVaBriZponFHKg4Ierm2Pnt9oDYhc4u7siS5+6y/BYmLH6IdF/RXQWd g7ZCizR32n2er5enDW/IXJTCzw21V8A4xFdMkEgWOiL1hXrmO7blP93N2Y1luXDOZnIP3lpCDSD4 jKcC9205BAkNjRn0G3yIEo4bMVmdvrz0MfktmxsZMhYG5LMElFKuC8Mo/EGNTOxFVez8BfaJIlVL dRNPx9XSRVv1kfa7ccgvOgspRWxGUexFr6QZN2Sf/S0k/ZgHPqmnmhHMwjfWeqiTXhglzL/jwLn+ G2iZASMEBpig+5/GUFuU2m/vYqsnNoOsUQPQ+3yfO+qJd6cLj3PG1xTFMPJRiSMu9E747yGe7s7j LL8AVX59V3H3MblgKvfZOULBBcGF570EFf2ERIeQiT8V1hYsKfgdQ2veksCMX4iJljpXzWznf7pr yW8lM+VtNwsQ+Y9i8wZJ248K7+0FiSVguTa7Pp3XSfXNlgTzQ5OAjEdYPKB5imrHeK2nekwcMIuu tj2F8iFXRGzTXKUxMqQZHLV2EhB8JItN3PO/jWBbu7CdXfcURYKPx8pifipdd8hkyXkjPUHx9GWH O5ZtZGJN8WsDHwAjU7LWr4x9AgMBAAGjggEHMIIBAzAdBgNVHQ4EFgQUG7WhGFQw0TOM4OiUORrm ThAQMGIwgcAGA1UdIwSBuDCBtYAUG7WhGFQw0TOM4OiUORrmThAQMGKhgZGkgY4wgYsxCzAJBgNV BAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRIwEAYDVQQHDAlOaWNldmlsbGUxGTAXBgNVBAoMEEN1 ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTEhMB8GA1UEAwwYQ3VkYSBT eXN0ZW1zIExMQyAyMDE3IENBggkArEDLVYGjaRgwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8E BAMCAQYwDQYJKoZIhvcNAQELBQADggIBACQkBkaAActTjhVFUObRG2GHEarcmAks+RBVZsazxqie jPwE8LCz2mvp97VhH4l4pBKN9UybsJJrY3zh+0J7/8mhYJ18DqRBEB4/IIeulqGl3Z+n+KbvFs1c +RyqLfkoSjeuhNLs7Fo1D7/m5N6G6J+6Kpo8EP9sAN8uIGqdfGynUsV77BpPVKeEbIozdtxUX0ch lIG7+p19v87iB++p17q04vfkpfp4uOSuJiCMMg53BSxlpDks2zrQBJ5KNSGF/XexUIwk7jc5sL94 Qba7b3ddpPhjKF92yMOQ/utFdD5/4NFTz91MwFjHlrXwGYM7omGzknIbO5qPl12JrsvdvtCpLtJI w73d31k1AvfdigZAvpgWCjlW9rfxeMuc7YAa8sDFjhPBj+k+DBMZBQeSXvzxQO9YnUWScLOj4ulG F/DLbG35SDTXTkalIujmO9HfXumsQfoyFibrMq8cP3rdocC78QFwofv2uQplg6cQbtZDZlrozB0h zFhJ7sbjHf3GbzsJlvCZ2JKSdwbClHBpFsK3V3Ka/bG7XHbivYtasQTe4dY2ROyswPhtQ0L9kzhY q2IB3Y3u2t9ffYXLffO7jvCrYlu5KRoydT4Jaj6jVkIilwEkFDaK4F4mMqaVnYEfZM8cicB7Q+kQ 6ZdKQI+qAUQNsqbA81FG1uncVSTlvUe6AAAxggNUMIIDUAIBATCBkTB7MQswCQYDVQQGEwJVUzEQ MA4GA1UECAwHRmxvcmlkYTEZMBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3Vk YSBTeXN0ZW1zIENBMSUwIwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBAhICxvMh +D0BXW3fcVIJqc5dY18wCwYJYIZIAWUDBAIBoIGWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTIzMTIyODE5MTQwMFowKwYJKoZIhvcNAQk0MR4wHDALBglghkgBZQME AgGhDQYJKoZIhvcNAQELBQAwLwYJKoZIhvcNAQkEMSIEIN7jBEH5ucgYl4qtfmm7YNFaJcO6P0vk l2+4QUlx6tjbMA0GCSqGSIb3DQEBCwUABIICAAOpZvMe/z720USeTulbIGTWWLHZ9bbuYNInKy/W JTTxVPIaOe1dBvYxYCCuXkVr2wIj8cUWWPPJVTBszp++6SpuJ5BenCzQSFCF1Olh3sOvhF487z+3 XL3iNpsdhMVMeikf9lWu83JSSEIYcO5lqpa4xbdRkJ8M4ReuuwPeA0m6cpq58I5tNsmk7+FLr46q ZVtPtBjLbMktxb2rbUfIRKN1qwn/bdozq6qN7lsprWCWr7t7E9bbRH9d7UNcH58nqpGj45cOIkJp 75xO7a47ujIn7bEj9j5gswInxWQ/x84HRVeQVBt6cMbDdcOkREOulHWNW0uFAAs88KDpv2bhCqHY RaqGu1h1hYX0pf/SqzQtRuL1P8Q/BNvhSI5tBhqlnAbeca1hNXOwZoLs5ZDuuNkRCliixHr0wpIQ lS4ZsxmF98HrGwcGeQA4yhkBh0R1UHjunq1KBJ1ogfX+Zxu0bbD8BaDwzV2qZ3Pk1KEergxE4qVG poWUUOMTyCbzCNgYnJPmQZ5mEHbW7uf9d8b7gxytU3aBzHLRVNwLMt4LlPQ3CvKeBbkPjWevwN43 Nh8cQ2Ou2OsL+8awTvZDaJJ+t8Vr5AZSDmBDxl3fr9O03xDaCV3WPp1RLxIc8QMGsUfmBJKP/gm8 V6+IHPg4Wg6K3z2pc8GSQA28jyEBMp4fP3IMAAAAAAAA ------=_Part_15_223621763.1703790841049-- From nobody Thu Dec 28 19:24:08 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T1JNS3Vg0z54Qv6 for ; Thu, 28 Dec 2023 19:24: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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4T1JNR5lJlz4Q0q for ; Thu, 28 Dec 2023 19:24:23 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 3BSJO9Y9041458 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 28 Dec 2023 11:24:10 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 3BSJO8q3041457; Thu, 28 Dec 2023 11:24:08 -0800 (PST) (envelope-from fbsd) Date: Thu, 28 Dec 2023 11:24:08 -0800 From: bob prohaska To: Mark Millard Cc: John F Carr , "ticso@cicely.de" , Marcin Cieslak , "freebsd-arm@freebsd.org" Subject: Re: USB-serial adapter suggestions needed Message-ID: References: <55q37289-ss30-nq9o-7r31-086n999p394s@fncre.vasb> <23100FB9-BB4A-48FF-A715-84EF7F6F59A6@mit.edu> <6DD2FDE4-77DB-499A-AED8-F179A9DAA0EF@yahoo.com> <6A38A60B-3281-468D-907C-26AB2F8D07A6@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6A38A60B-3281-468D-907C-26AB2F8D07A6@yahoo.com> X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4T1JNR5lJlz4Q0q On Wed, Dec 27, 2023 at 12:27:33PM -0800, Mark Millard wrote: > > Overall I've not been able to understand what the > (various?) hypothesized stage-by-stage byte flow > paths are in these notes. > Maybe this will help. The path is workstation> Ethernet > terminal server:usb-serial > serial wires> GPIO 8/10 I hesitated to use the words "terminal server" because that has implications (distinct IP address, multiple serial interfaces) that don't exist here. The workstation is a RasPiOS Pi4, the Pi3 host called pelorus is the terminal server and the GPIO pins are on the Pi3 host named www.zefox.net . The Ethernet connection works well enough for all the other hosts that I think we can disregard whether it's wired or WiFi and LAN or WAN or all four. Thanks for all your help! bob prohaska From nobody Thu Dec 28 20:22:16 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T1KgX2ZKyz54YSN for ; Thu, 28 Dec 2023 20:22:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T1KgW6FGbz4VTR for ; Thu, 28 Dec 2023 20:22:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703794949; bh=cCmlbXiuYDsu3y+I3qMt6y1/MOk/3j/85eAiOgp5mwQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=pUYf1HCaOj/O2B7Q+MaHUM6tTrgdibFKWyzkdd1DDZ6bbcpQfB0hhinC0ZjnbqRJ6mCe6gGCRNavxeoEQCdSa6iRmKw33Vs5XS6dIUlUdxSF/fg/nxyBn1KAX4wdoHEQATKnK94NaET12GB38hJQjuOBG58WWZEY8uNMY7QJjh/NVcSoqLh8m34yGPgxcQ6r1TaaCe+LMrbErlkHBbu2SSRLFZI20EDCVCgBHMTF7RIcHbTFYBq12l6bkpDMNOc2frefDbN6kUUcKWbeA0K+clmjPx0iTGvos3/jxYf67zF9F9/KQ/LTs0pWtKrNfpOgfcK4BRk5TxZTOSEpLrqVOA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703794949; bh=7XT2Pt8ixdLc71EaJDc0TBKbvQW/GzuF4HGQlML50PR=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ubiW2HTMcj2r2kjIDLWcJZKNE1zRagz6QTmfojZibrFIr8B+o9SJ3jOepn6rxBfZG7myiWgtLEahmJnPVhW9LT0HuU1dinDBqpDfcr7Abb01xgfclETfn9Ou9D4cVP2EWbbh0CDFIINJmwRySV7vLdXTHvWKvC2VmsvPw4bVe8ZJjMgIL7WfxZS4akyz/rnJ2Dk81tZY3p778Z6iJY1Ofbv/+FNkM3iT0nqdJ56FycoHaGqK3h3Cmaa3ukeRXXVG8LgSwU+lCb9hAauxwKjr8the24+DASp312nrVcKwPgHk4JxLP6McF5n5hB28ra9QlTkqabcGpcYqb7zvA4Mncg== X-YMail-OSG: FMKy7ZoVM1m1viw.3ITmyBX_o1HioSc3gdvemQ6kiZXLEQNUIqyeEE.v2KtDdHe xaPFM1.8_MF_fk3RWlyJLcSZMQcGVLyMMYk1iJR8m128AQHymAkLNfAqswd.VFIb7w7HRvJpxGnI Hspydj3kANPB7or2qHs89fuYI_DRnjVXMETZRnr5FB0WcLjBNB5JDP6PWke4FFBjKzLqlQC_qWQX TNR1hdxDwEFgHgbl.uCQOtXTS76IbLN0NqEC.ljsedbRZuszD1GIiHt0j5eSLFs988IGsHT7ga8. RKHk3TAZNEerQ2or2RgNL8uEzk14A0srBP5r2efHnyK9Uk9aTDURi6Ocm1p5_TqfXG970TL10Xc0 cR9dY7i2Mx77Ax_oMOBfr8SZXw1IRSNadVc_rmc59hviuWN9YbcNtNYaONB4l6GlWXUqS0HZN5Z6 1dtqh9_r.svOBzzY7evEIYEMkM7WSZk.DZlxhxlETBYEfonB1NKPtukRlIioy.H_QFXp3meUNzJT mE6Xj6BfkDoituxRufvxWLfXvdiBIkfXeQAE6_WlEaG3ooL8LKyG2sstSsUKVGtiV32nMt13DIVm x4nB7P1SsJLeQwR3K3GFiyxvff6j.2Dqbbm.rf48c4whsGnH_ELEFJn8M__cuDEV__Z7gwUbmj8p QhvDx6wS2qe3kxFqyvEK0fOJqnSCu_hbxU3lu0xM7fokR9HRxxXN8edsK58atUgyB7a7M1WDA_z9 BMtQ.5vFpTUDgj4NrORzM1wQRM37Dbf7RxF2V73mb1ukoN_yi4UusOwUPTMev1v0DfcqA.5MfHcb AuWA99oGaFU4Kb1K2kMPgJ_Jc9JhzNO8GGTr6qTzCf_PEMrUqWOxu3Pl.Uy.H8XXwvxnnQQbHpqy GEzh3Z4ta9MpmGS.5m8eptYG1JzqBQgqGuf.GyzKr.jwzevjWATPAd6.Bzkn21xAEVGnxAIhgBro tBUKEm3nkK4yuAagMFJUZ58e7bWK5b4K6PS3yDlygSl9mxTUmGCB37gE2z_hul1w2rrk84L6iduV 6kVBBgWjgL75PZE_.VcBD0yMUdwN69_rGo.AMpUAY6OhcjM_dqXoKE99y8WPlYXXO._a3G0uUA5F ey_7jeXNOwpFOLIiXiEWMYIJxhtBbQj4yzEyjOXZSX4WYjCvknyRBusudKhnEx.HXnrIErODsjdE DRuE2PBJBWOqDR_INud.DHDJh_P3qX8F4rXObGuO8H7eGCZ_5YOGn5VGjHwS1_at3GL_MhIhlzdm FqhOQqtxDiF8RsWQbo_XDM_B56hXO4K20fj_tpo1pg6cWMNSpZbAMvQp1K7L0Z7BN6X9tnMvtyrn O3hy4vETemHKmskNuLJ0v3E4Xu2NEBJfvd6Rhi3QmyG60XgpfchiVzzrWj8yZpO8O1vuv2J2td1S nQs5uOGjw6t8YqPjgU5xlmZzGqtKNQWV845eGtMS_4o0dmtyb14lpAdQJC76CW39.GKvaMevfoOf GfuZTUxGS5L1O7qkCYBMWNyo0pmb5PqsBcIakqOV1pgOMvXqtYUws4ASHI1i2dmb6EAOjokaimIL Wnp7GSbwO.jZ21SqiI8Qz8ljdDL.rE4eq6eaDmU8nO2ALHZSLo6kH7vhy1NfI1fyJnfUi9HlhjPI DmIKBsjhTO4HSUo_azEw4bxVS2eytdCD8kl8OdPiAJyZmdEt8gTqio9Si4V9O4OeOiZPxVWzpmNI Ke2stsdZ5LlE7fh4vqx7RwX4aHP51UpbMP7hszVo3emyveN3vU7KWeAgdi9_W7yh1n64KiuxN_gd BmAPc5Y73CUCZIWHHWC83ABx0RmV1yUkfxZe75CpFfuwmzsEQxrvruKxuHwxjg4xfH7DNobdLxM9 wGZrAs.Rhnip0tHd791r.KaeMurkzlxXUBJyQ2VYvIFASjDnglwf52QSwhiLx3Uto6xOWwBIuUEx tfv4zSrjB3fSugk48vK8fllkEF4AiX_GLZeqFTK3g_ocUrFfmugpOkEJm4GPJdBiy61ONZ2iXdS9 B9BwO.qxSU5fSniFrY4VIaFsF17q56.K94wJ8nKW_dGekiOmnvPza.r6wvj7rFNQld60gEoCFmlm Luz6OBRcWW.VhMKG9PhhXllQaUlae4tyGctI2z21ENL2xHR6jip1Rdp1_9ik0iI8nwWOC2bK68ad yhuIHdoJcrhVaG8w69AjHDBr4ysAAbmnRIeSieyOWF1AldtKLtC041rlCE3hqz9OIAGDwlh.djcI 0uOOCvmX4CGawhleOjBWVJkuAwYSGQaRgTcEHLwtIXYPdbyEJz62JQGOLlfbAPbCFhRJd6yw9ag- - X-Sonic-MF: X-Sonic-ID: a2ee40fc-9e66-433c-9dd5-b1b436db97a2 Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Thu, 28 Dec 2023 20:22:29 +0000 Received: by hermes--production-gq1-6949d6d8f9-7dnvp (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 8fe1ed7bc23f3be0cdb262c7e78c3a68; Thu, 28 Dec 2023 20:22:27 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: enabling powerd on RPi From: Mark Millard In-Reply-To: Date: Thu, 28 Dec 2023 12:22:16 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <0E56E105-2A22-460E-9C58-24074922AA18@yahoo.com> References: To: Mike Karels X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4T1KgW6FGbz4VTR On Dec 28, 2023, at 11:11, Mike Karels wrote: > I am looking at enabling powerd by default on the Raspberry Pi 4 and = maybe > others. There is a bug from 2021 on the subject which has gotten some = recent > discussion, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256836. = Also, > problems come up from time to time about performance problems because = people > don't know to enable powerd. It makes FreeBSD look much slower than = Linux. If performance comparison to linux is a driving issue, seeing what linux does about sdram_freq and sdram_freq_min may be relevant. This may be in whole, or in part, based on the RPi* firmware version the: = https://www.raspberrypi.com/documentation/computers/config_txt.html#overcl= ocking-options and its: "This table gives the default values for the options on various Raspberry Pi models, all frequencies are stated in MHz." content has varied as firmware releases have been made. But I've not always found that the two match for FreeBSD. This might be because they mixed firmware and linux defaults without being explicit, something I've run into before. (I'll note that the history of the documented defaults is available via giuthub, even if somewhat messy as they restructured the documentation over time.) For the RPi4B's and Pi 400's the modern tables indicate sdram_freq_min=3D3200 is the default. It used to be sdram_freq_min=3D400 = . Recent testing of stable/14 snapshots with RPI4B's has shown the 400 figure is in use. Only the RPi4B's, Pi 400's, and Pi5 show non-400 defaults in the modern table. Another such example is that RPi4B Rev 1.4+ is documented to have arm_freq=3D1800 by default if arm_boot=3D1 in config.txt . Otherwise RPi4B's are documented to use 1500 as the default. But FreeBSD does not end up with the documented figures: ending up matching the default arm_freq_min=3D600 instead of (all but Pi0/W, Pi1, and Pi 5 are documhted to have the 600). My guess is that FreeBSD makes its own assignments. Note that the default arm_freq_min is model dependent if Pi0/W, Pi1, or [someday] Pi 5 are to be covered. > The simplest action is to enable powerd by default on the = arm64-aarch64-RPI > images. This would affect RPi 4 and variants, also RPI 3* and later = RPi 2. > I enabled powerd on an RPi 3B+, and it seems to have no issues; it = seems > to work. Does anyone know of a disadvantage of enabling powerd on RPI > images for all targets? Serial port configurations that attempt to use the mini-uart have problems with core_freq changes changing the serial console frequency in use. (mini-uart used for bluetooth instead has such issues too.) Which UART is used by default varies by model, the bluetooth capable families (so, e.g., not Pi2) having the mini-uart for the serial port and full UART for bluetooth. (I'm not clear on the v1.1 vs. v1.2 for the RPi2B's.) core_freq and core_freq_min also vary by model. There is a core_freq_min. core_freq and core_freq_min defaults are documented as model specific. hdmi_enable_4kp60 use changes the default for core_freq and core_freq_min as well. There is enable_uart=3D1 to force the core clock to be fixed for seerial use, which frequency is dependent on force_turbo=3D1 vs. not. I do not know what FreeBSD does about such things if it does not match such documentation. There is: = https://www.raspberrypi.com/documentation/computers/configuration.html#con= figuring-uarts that says, in part, QUOTE In order to use the mini UART, you need to configure the Raspberry Pi to use a fixed VPU core clock frequency END QUOTE I'll also note that arm_64bit=3D1 is the default for the RPi4B's, Pi 400, CM4, and CM4S these days, but not for the rest that are 64=3Dbit capable (ignoring RPi5's, which do not have the parameter). I do not know what FreeBSD does about such things if it does not match such documentation. > The alternative would be to configure at the first > boot, although I'm not positive of a definitive way to identify the = RPi > variants. Maybe just looking for a dev.cpu.0.freq sysctl node would > suffice. >=20 > If no one objects, I will make changes to enable powerd on RPI = snapshots > for 15-current, and we can see what happens. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Dec 28 20:38:58 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T1L2q6KTjz54Zj3 for ; Thu, 28 Dec 2023 20:39:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T1L2q3x0gz4Xt1 for ; Thu, 28 Dec 2023 20:39:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703795953; bh=AXBOxEBbNH3MbT5UlG9j7oAKrcpBwLBqYDtop3wGNdU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Cr0kBjpUjG3bC5tUcla/n6zHzLrYqj9t+eoT99FcY/Hod0f6mexSg4M+M4ejKCiwoCMleE42R7U78uXQKyq838poGvZtBKmS2SK+jwCQhx+3ghtM0zIKg8p7hwtIwcMjxMpgDhIJp9c6XuU/dftWFYbBb+Q9FEGhTx2Rr8cnY/6wkVvEZi0vtwof2H4t2tP0tiR9RARrMlAzchiysa6Zp9kPgMocJVKQVFrO+TE/TmDCsEJROGGy1A6sqyqJGV6AsKRxP8aa9UEN3836HSjEV6BQZljR1BDLiY4hU5qejpu+vkLTeFODN8+t++jCSwXZB3hJP2aq0bt+riazmIf+kA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703795953; bh=FHRSSe0zo0mWNfKZF74YpItv51SXrv69zDn5SDDQd6o=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Req2M/JH5+2W9iMWUL3cuEzSrRnKDMLl5i9WDYLOWM9E7bEfwNeWkjci8vaSJ4f/Dj5LzvIu99FToUQWOn/RyTXg9j39jiA2sSlpcQe7AbYd0syOhylrARK0GoeMQY1xY7PdXy4cNfgFQfRYkwXN3SDb/oZH8tUHbCu316D6ML6bpeAW8kn661V7IUnhiWlFUJDJ/mEkq+wP8+NVsnGWpBw0uq7xvxODkzgtB161gUNurC7WyrtgxmUFLJ6zwdMX78iaRqre/8AYSs7VZkwRg7TbsDBlOwV6iM+BiYalovxFDc9/TyS+5o4N7ykz4n/NVpBzuZGISVUJelbjrye5Gw== X-YMail-OSG: bXp._g0VM1k4TZVm3WT4kfcmodU6VA9Qgz3DBjsMMaWo.pSUdEuSSdUnQOTO3c1 4GWuOBtUQh_bq58ePpYpAqtAG7dsV1V_tCWx5dRTWkOCYQUsIlKsfJNb.5LuJTrpFOl7p0O0cizt 51ztP_hBvyUbOzSDCBCG9SbLY7HZyckLibZXF3iqqmLYABqLJafEGvCjS.SR.Yz78HgcIcICovmi 7whxxiyFJ.FaGJa7PdAb2.Xg1_xkyW12e1UxSXi.RFUClWNYL_pIJtSDMjcQqBNFsqj1kLUr7__4 ycB01cIro_U4PsR_HZ7qzQbGLTjzm.a9h7RVHVzKFUSxyKpir_6fVRS2Q88K6ke0GvPBc8NIHOuK N2gX8C.GyhdSMQNFx9I_XezYLRR5pGH_hSyxpD8Zvc9ZDoOT9NToNowaXor5cnqH4kYAyff0FtRB da2_sgEKc3vLlhPbtTC0Mf5Y4bxDVGPPQKhgfdcO55d_6TNW5OKhZsdjjhd7n55zyp1MqseEDVzY hwER1La45jM4MMZvgnDILnNOUW3wWr6B3ZoVXwWQ1CLRxBS1dsPjHzqAFoIUF8p3IL7p2RnRWNVV TYyaai7yjOXaet4tj5w9X.YUfDXKIcF0VRK8cZIVuv2KxLLhekVMWBNsIToOc7xTYOiUhmrGCmR6 seiPoJPLKmM3BAU0tI6UYL2nWzW91wIhg.usP75Mr01foj5ybxOFda7Fx2Xcz4Zn8S2pwtaf4SRB ZdmmkR7tyV2mCDXNMOWS0Vd1nEoZB_LChUaM5PHKMUuderqUfgV0Cz3Fcb4B.76OypIMfIrnpXgZ d7IRhnoHB0dZk2z40tPJyiMf4dqUpn4sEm3ibtElMJPv2UyXrhdI9Jfiev9wcEYY_.X4qGD9QmY3 db08ZZJYPItvAmEPzVOWSgj1waegJKI360QQB3e3l9oziFwQZC24foODwYAjKu2ew8pgdrsu16iE joEsukqRwkAVX3WttU6cU2HxXctZJ84LgSu71yI.IG7NMY_c1ps_19iUNZEPWfnX7BAU.96yTG6j hS3hDGumwW_ubA51JOH3E7Y1S3Kp00Cna2W2Ye9QZ1YCZrqLguUiC9agiEzHJ6RD19HLFZHHwMSq JGwNkEXsu3mqlHllOnYhcHlSsxao96nVL39CzbnMk27aLOeONEnE9YE2RKjczj2WiQ40n3Y2LGIJ mvKVu9PwRsbOEcBvSeOcxAa7LMEzJ9VJw9tsVGYW0082.XeoqhJL.tXs8NB987veYJnKskUNN7wU nTe6i6bJ0pMmYiGS3PtG_gOPqZc1QFfJOYAFEQ_vgckJ7dR532VXT.Ehxqzl.nzOAQxEruJ8h0.I C91dG14q98njZo9fcWo1zBhgHUQ5brw7CBHb9o51BeOveoq3A41uXqLvJqnBkvB4h58_Y1xt470x 27fDxG_wKYDx3MtbxGyx0IO2fBt5Ta4aVH7h69buK.SQySygj3KRcHQsFdOxVcb9iMEOrNc3C1ES LwNC8LIt16Q9kExx9vBgBimat6tkye3xGVj0xzfQ6AQfbqt31HiI3VhFwA1WtE9FWb0PTCPKPFz. FBun2J69lw.XaKLkAExQkDAQfKEDv__tvnhYqsQBsMcmBsdVV6pfsbYtNFPzFgxcSQJTtgEbynuc gMo6oywllMzd78U5lWr.IaBY5pAqCFlb5hn1Ecbc6.F6gareqtN4_qrRY7uVu52BUXdXac4Gv8DC H6jl4GYi.vTAcp5tMLzCpxax9KPnvWVn8OM4Uez8m0ma7Us7kISFlJzq.kGYRL_kgw1yaPkjDtt9 .VvGpJEX8t7.i6TSZd_8AUJycTo4K_uD6Q4M6g3rWO6sIHPfhZzOIz3LfSzB6wcfLGVJ4Bcuvnqo hBuH_FwrulAyMEebT6rltjEiBdDFlAz3jhMZOL2HRyvsVa5T_st_V1fRG46Wss0uOcxP2juZaH_s .DfZ_yMtb8mXj6zSCb8V5voMX9JAq4qGOO_Kj1qjVB79VBw6Qcc8TgPJ5p9WC3N9e8I.OBItAFkd 158m97aTwVlhXkYKxP.5EDd4McAe7WHbWBDYINXoy1yndIfBD30hJlcfkDuDv2_PKTOsCRy67tDU 0injhf8xQwfIi2Yi2Gdn._tkhaGjMenuYOH3Uxkne1fPQha.tnpomMdt0L27LD8v2DDv9M2.yKsb J.7MIaEz2YYi3JMa0GrVIROjm0tHRAassaeNF7Z_PW5F.LKsk07u1y5vDNX.cULm8AveLBcAKWWs qQGjNyhpzRha_Ye.8TrI5QHh5EQb35dmcKvpoWMpnA.125mGfCvI2l2A8aaYq35FW9P5WiNKyVH0 - X-Sonic-MF: X-Sonic-ID: e7fb1d39-350f-4308-abc6-25c605fe0137 Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Thu, 28 Dec 2023 20:39:13 +0000 Received: by hermes--production-gq1-6949d6d8f9-k52jv (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 8b99a6125183f50aff979d74fbe0fa69; Thu, 28 Dec 2023 20:39:09 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: USB-serial adapter suggestions needed From: Mark Millard In-Reply-To: Date: Thu, 28 Dec 2023 12:38:58 -0800 Cc: John F Carr , "ticso@cicely.de" , Marcin Cieslak , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <55q37289-ss30-nq9o-7r31-086n999p394s@fncre.vasb> <23100FB9-BB4A-48FF-A715-84EF7F6F59A6@mit.edu> <6DD2FDE4-77DB-499A-AED8-F179A9DAA0EF@yahoo.com> <6A38A60B-3281-468D-907C-26AB2F8D07A6@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4T1L2q3x0gz4Xt1 On Dec 28, 2023, at 11:24, bob prohaska wrote: > On Wed, Dec 27, 2023 at 12:27:33PM -0800, Mark Millard wrote: >>=20 >> Overall I've not been able to understand what the >> (various?) hypothesized stage-by-stage byte flow >> paths are in these notes. >>=20 >=20 > Maybe this will help. The path is >=20 > workstation> Ethernet > terminal server:usb-serial > serial wires> = GPIO 8/10 >=20 > I hesitated to use the words "terminal server" because that has = implications > (distinct IP address, multiple serial interfaces) that don't exist = here.=20 >=20 > The workstation is a RasPiOS Pi4, the Pi3 host called pelorus is the = terminal > server and the GPIO pins are on the Pi3 host named www.zefox.net . Your prior messages reported text referencing .org, such as: FreeBSD/arm64 (www.zefox.org) (ttyu1) and: No, the garbled login prompt originates from www.zefox.org's serial console. and: Understood, it's been hard to articulate 8-( Maybe Workstation > ethernet > pelorus > usb port > gpio 8,10 > console = www.zefox.org is a little clearer So: "www.zefox.net " above is a change of report, = if I understand right. > The Ethernet connection works well enough for all the other hosts = that I think=20 > we can disregard whether it's wired or WiFi and LAN or WAN or all = four. You have also reported that: The Pi3 which reported the garbled login prompt=20 uses in config.txt: b@www:/boot/msdos % more config.txt init_uart_clock=3D3000000 enable_uart=3D1 kernel=3Du-boot.bin kernel7=3Du-boot.bin dtoverlay=3Dmmc force_mac_address=3Db8:27:eb:71:46:4f This is using the mini-uart for the serial console and the full-function UART for bluetooth. It also is not using arm_64bit=3D1 . (So armv7 support instead of aarch64 support?) https://elinux.org/RPi_Serial_Connection claims: QUOTE . . . the less capable mini-UART with no break detection, no framing = errors detection, no parity bit, no receive timeout interrupt and no DCD, DSR, DTR or RI signals END QUOTE This contrasts with: The Pi3 hosting the usb-serial adapter has in config.txt bob@pelorus:~ % more /boot/efi/config.txt [all] arm_64bit=3D1 dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don dtoverlay=3Dmmc dtoverlay=3Ddisable-bt device_tree_address=3D0x4000 kernel=3Du-boot.bin which has the full-function UART for its serial console and is using arm_64bit=3D1 . Why the variation? =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Dec 28 21:12:10 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T1Lmr3BqSz54dHy for ; Thu, 28 Dec 2023 21:12:12 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T1Lmr1KPTz4cQR for ; Thu, 28 Dec 2023 21:12:12 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.17.1/8.17.1) with ESMTP id 3BSLCBwB022510; Thu, 28 Dec 2023 15:12:11 -0600 (CST) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1703797931; bh=dc8aAQMwvrzHAE4dgPUGFgYb55hn2GJdBbISXeOeoW8=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=XN3ZISZhAofGX0NkW3GmxOCeaYiV/XjYWIK/myW0V5WxfYUQRR6hzvPC0nohrLbiQ gyH8RLBrCiXt/HVf1NgaFYlVgr1lYvGhhXh4WI+LcJa35I9zHCUNiB9h3N1emGEi/K F8BQHVAEc0+rriR7k6pHQKkxkkA3tun+3cs4/zqzAqgCw0RQuHguDJ9LsZ5kHOJQc7 6NiUikvn3Ur53a06J6yWSyDjzfcEcaisyEQa48v4saaLn06PvlIHH7xhGlgiXMn0wg nDYxgSJUNqSWiQPPCj8yqXp9CL0aN1ZG2fF0grIVwpqAZYf4NnhEbXM+ppH0Ulm9hC eaxx1qGUCRfsA== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id JlR5BKvkjWXsVwAAs/W3XQ (envelope-from ); Thu, 28 Dec 2023 15:12:11 -0600 From: Mike Karels To: Mark Millard Cc: freebsd-arm Subject: Re: enabling powerd on RPi Date: Thu, 28 Dec 2023 15:12:10 -0600 X-Mailer: MailMate (1.14r6015) Message-ID: In-Reply-To: <0E56E105-2A22-460E-9C58-24074922AA18@yahoo.com> References: <0E56E105-2A22-460E-9C58-24074922AA18@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4T1Lmr1KPTz4cQR On 28 Dec 2023, at 14:22, Mark Millard wrote: > On Dec 28, 2023, at 11:11, Mike Karels wrote: > >> I am looking at enabling powerd by default on the Raspberry Pi 4 and m= aybe >> others. There is a bug from 2021 on the subject which has gotten some= recent >> discussion, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256836= =2E Also, >> problems come up from time to time about performance problems because = people >> don't know to enable powerd. It makes FreeBSD look much slower than L= inux. > > If performance comparison to linux is a driving issue, seeing what > linux does about sdram_freq and sdram_freq_min may be relevant. This > may be in whole, or in part, based on the RPi* firmware version the: > > https://www.raspberrypi.com/documentation/computers/config_txt.html#ove= rclocking-options > and its: > "This table gives the default values for the options on various > Raspberry Pi models, all frequencies are stated in MHz." I'm not looking to optimize everything to improve comparison with Linux; people can optimize their own systems based on things like cooling. I just want to get the low-hanging fruit here, with safe defaults. Running at 600 MHz all the time is totally suboptimal. People who want to tweak will always find more improvements. > content has varied as firmware releases have been made. But I've not > always found that the two match for FreeBSD. This might be because > they mixed firmware and linux defaults without being explicit, > something I've run into before. (I'll note that the history of the > documented defaults is available via giuthub, even if somewhat messy > as they restructured the documentation over time.) > > For the RPi4B's and Pi 400's the modern tables indicate > sdram_freq_min=3D3200 is the default. It used to be sdram_freq_min=3D40= 0 . > Recent testing of stable/14 snapshots with RPI4B's has shown the 400 > figure is in use. Only the RPi4B's, Pi 400's, and Pi5 show non-400 > defaults in the modern table. It doesn't sound like there is a single, universal change to be made to optimize sdram in config.txt or rc.conf. I think the most we could do is to add notes as comments, but many people probably never look at config.txt. > Another such example is that RPi4B Rev 1.4+ is documented to have > arm_freq=3D1800 by default if arm_boot=3D1 in config.txt . Otherwise > RPi4B's are documented to use 1500 as the default. > > But FreeBSD does not end up with the documented figures: ending up > matching the default arm_freq_min=3D600 instead of (all but Pi0/W, > Pi1, and Pi 5 are documhted to have the 600). My guess is that > FreeBSD makes its own assignments. Note that the default > arm_freq_min is model dependent if Pi0/W, Pi 1, or [someday] Pi 5 > are to be covered. > >> The simplest action is to enable powerd by default on the arm64-aarch6= 4-RPI >> images. This would affect RPi 4 and variants, also RPI 3* and later R= Pi 2. >> I enabled powerd on an RPi 3B+, and it seems to have no issues; it see= ms >> to work. Does anyone know of a disadvantage of enabling powerd on RPI= >> images for all targets? > > Serial port configurations that attempt to use the mini-uart have > problems with core_freq changes changing the serial console > frequency in use. (mini-uart used for bluetooth instead has such > issues too.) Which UART is used by default varies by model, the > bluetooth capable families (so, e.g., not Pi2) having the > mini-uart for the serial port and full UART for bluetooth. (I'm > not clear on the v1.1 vs. v1.2 for the RPi2B's.) core_freq and > core_freq_min also vary by model. > > There is a core_freq_min. core_freq and core_freq_min defaults > are documented as model specific. hdmi_enable_4kp60 use > changes the default for core_freq and core_freq_min as well. > There is enable_uart=3D1 to force the core clock to be fixed > for seerial use, which frequency is dependent on force_turbo=3D1 > vs. not. It sounds like using the mini-uart will require config changes in any case. I'd also be surprised if many (any?) FreeBSD users are using the mini-uart at all. Anyone know? > I do not know what FreeBSD does about such things if it does > not match such documentation. > > There is: > > https://www.raspberrypi.com/documentation/computers/configuration.html#= configuring-uarts > > that says, in part, > > QUOTE > In order to use the mini UART, you need to configure the > Raspberry Pi to use a fixed VPU core clock frequency > END QUOTE > > I'll also note that arm_64bit=3D1 is the default for the RPi4B's, > Pi 400, CM4, and CM4S these days, but not for the rest that are > 64=3Dbit capable (ignoring RPi5's, which do not have the parameter). > I do not know what FreeBSD does about such things if it does > not match such documentation. In the current config.txt, arm_64bit=3D1 is in the [all] section. >> The alternative would be to configure at the first >> boot, although I'm not positive of a definitive way to identify the RP= i >> variants. Maybe just looking for a dev.cpu.0.freq sysctl node would >> suffice. >> >> If no one objects, I will make changes to enable powerd on RPI snapsho= ts >> for 15-current, and we can see what happens. Any objections? Anything else we should do by default? Mike From nobody Fri Dec 29 00:56:54 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T1RmP20cRz554Wr for ; Fri, 29 Dec 2023 00:57:09 +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.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T1RmN6SlQz3WN8 for ; Fri, 29 Dec 2023 00:57:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703811426; bh=kz+JdHn/wGsv6u7fwN8r+fz9sZYQsJOXbSuNhgXlHKw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=gpUhR5+qGREWKlZTd2+bLc3pFdNBr2qAnot5c5TZRDOLEGuTQj98sqQNzogWXsxt994hDerkf8OOCuFIydSCVdSwaGc5yRO9Ac75iBETWIKeFitqhvqkwaZ/6SweHEAiYdSRuIKXfa7WzUuPTN/xdDbMBird18Wn3ZqDpDI9f4aylwEbXuPJMim3L33lwpfe8gSIM5ZY4hk6w/xPiSv0WGARbzgLrJCIacax/2grzBGwUfMZQoYG0BU3CfjOzeoJTa/3XhyGeg0uClqqiMIFM1I2bGggfRNGVxDqcD2O4OAO5hDLk58JfI0kgKl5bdyBBeXpzu7IfkkiZfOedmodXg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703811426; bh=MfYBfY8kJDSrqxEdntr96YhfSOoeDsGpe0QKZwFGLeY=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=UHtF06FsgsNEN3Bm1R5vlHJ1OKrOvnD35lDs1fizUk0TIY7xexKWgNL7gJq/NrxdfphV8wRly5HtU7VZ3WsZGmkndhcXPBmyShCZSvRHpSi6OG7YEOOng1RZnmzIsybUitMSoBB3P21ItV9y+SWFxS4lJ9JvtnjNQOMQHywdrCK5cQmiDUgLRNIqCGqlQdPqCR/FVZI9UyR4wxouW2bCE2L9yn8/MpWS6J6soKTZ5dDrGHxzzxr9NIrK3WjlXqRaj8mG2HKAZOrapIqxe8epB3Vz0BYh42KyUlgLWKurj+gZt0UMF8OECmm9WyCX8O/QEz17imtB1vacr1IYiLBmVg== X-YMail-OSG: XL.2qLoVM1lZP5yguk5zqXMEYXp45.HAZVlM21o4iJ3_xo2DngwPM4kTS7vXRPb r9upD0XoQc25fCOSQJUqE.VQ0DzwwfbF0LrKp5Jgz1NDxn6cMz.mf5tNT0Gi3nxKc71FbJqPBPrT Gu6aA8bPK6Im91AVDFAnKvYyDZ0gRDHqjsznbhQsViPppkqQssNS8PAk6ejxqBIH5yIKUmhYEqyZ 9OKHKPOfbfZLGPgxryp9ZAtpxfZR1gmIT379TY3vJHUn.0RlL1Kkyb47NyX3gSWR.iPP1brCn_ak jnw3UYRgkx0YYjHOaysZoPDYsr5x458hHwS8P.DdwvxrTQ4gEniwPFWeQU8kAfm4pRJoFrFRhxjM 63cO1CMDx6M0ucLG0WE.IOxVnCzjqL3qW6mSTTP5ToOXTeWjta_IXSX0L0MA1Wvny1155UN8KWWp 5nFR.TkPf3UCSh9WMLXZINCityM4v6YmR8V9tD3JXzXPBbE1XaIxpkSggl3Fk0lLTqe6jIC5M_wB kMNqIPtLukr4SKOdQiHYhmwINg24PbZQA97NODoCe6GQSxdrQI4KIq6EGy2In885bi2wR7O2i1Dw ax.Ya3vlin5gAh3PmVn2vbXabQiL3aWyk_xjxvFbkTy.BGCWFoDh3.6LU6suBg.qqKXf.Cgy5IIt 8XaFXnpxU3HVz5eljTYpvvFy3vVHqNAMIGLsL6Me7rpmaOpoT9iSdzUzFWLEHOKCrJSzoiwkuxcD zeHR9yu8L5DiRwHrbbFCHaYlzLsiwq7eDqXZ_2fQ7olGgML2JxGedUjwKRtvstJBzaqx8vlOVvBe 1sB.GyMyOsH4EjpfFlo8e0nvWr2BemDnlzGOpBElMuuVB30_mvRNJJNCiDdXdvKCzTEx0aH0TOgj nMLQ0nYPr3nA.3Dozd6CysXk8bdlKj3Tu1bAzd_PwZ.zxUNXyBjYGHEAhaoSw9V95LcNLcrI59TI GPdXTsfgPnfN9CpUp68qqrgAaBIAbIvcbLLgSmHtKRDxN1kRQ9UF_xY0a4cIh9.nKDdqVjKY11vP yvtx4KkuB4yYvtR0X22UIU6EI2YVqGOkco9aKXUqrmgthb.ltunIn9Zau2LpRctc8EOtCskYxDSJ 9QAMBPyA0mRqrzUhWHC4KRt2MB797RchKDrR2L2V_OR.jGtCBLl7WdDXashBa1QAi5C_7P2MUBjV JcUVWkzRq6nN2VIwIhJEJVZm9W1h3adF0CRT_zLmh0EAh5MvkvZpM5pvO4fR.7CbV_3duWuIkdmS Gd1bmfq7q2rRslL1CyHhZ4GkWzSmg_KcFsxGVZnm3gy975dC6MAElJfcpMrEP7NeZvDxmfuJMyY_ MLcqbBvq4pA6FeBp6.xg8yOTrfAkrFFM7OOg6ixlA4_Tkp86WboCaKDWPxgRz16K3cMOIhxYLV5W Jm04EfQe2d.gVlhbDvIcxmMKN11iB3ISR4cX9vPAN.kokEoFxdBNhVzTg3oXpUwIXcmYk9iljrBl VpLQMjA.HK1zPP.fHcR9uGm88IfjMsggC1jIr7lD3Jz20SGvO7JIzAayFTZM5BfhyLnIA2q_kcAG lABdUiz13EqpE89.jczYbCgksG_Go4gLoF6ZA6xG8INg1_45kOQdlGjb6IQXbZVE0t_t.KIWjjwU I70z43yzO_r9Mc78J_cvFApD9mK_FrrQPLdjJk3S6J4KdCjL2E7Yv3mPUGwy77iE.cH8GMzPN9Id Urjm.39NiiKGBfodIBAFSq8G1TZDJVXT3magC0ozoMxAWBr35xdstvBbUHHiTv5ZCIkzzTRv7_Wl lPq9rPBCu9zcOT6rQQHYF6G9D6WhUTyZ6WnRDFqAh6SNFmDjk2xU8kkOKgi0jvUjvuK5CjBaljZ. IoL65NvgqiOYBr1z.xXDg.ktEHY1QTDyN6_0urnJSiD1BhLXPR1eAlI.K._zu.420JzL1tUvj0om 4oloUXQzRU57eeBNpBZmVcntjE3qsPVMHLK1ySth2g9Ph3W408m2ZRIDnL1H1QyZ1E0X2_ii5pTO 49PAQDK_bau8EZK8ke0_JBit24VgJQflNfUdujxprEAKUp_6vQoOH68PGS_GUvuMvKNRKQC3ahCY Zjybclb8q.TkfBcFeCyB_ih3ecSxwNfzWwPo8.23MGIUSS2eJfRkuTPuJLEBIek1MYeIfAgddR74 v7DRdqPZbxB448sgsFfoVjfQaF5ovNBrjwNSF9XEdGVWFTkO2uCNKa8YxxKfAfdH2TdPz9SpJbS6 PSSgcnuoQ3hac6RR9fE2Vt1gsM0dCx5Ny8tozDvEaRmpAJmxz55p1YaojQoEnJval0rzBseqX5ZK 07g-- X-Sonic-MF: X-Sonic-ID: 7de136a8-bc0e-4d10-bbf4-72e1a4ff0fc0 Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Fri, 29 Dec 2023 00:57:06 +0000 Received: by hermes--production-gq1-6949d6d8f9-nsbdm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 35c6ac20d646e10761616f4c1e26be00; Fri, 29 Dec 2023 00:57:05 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: enabling powerd on RPi From: Mark Millard In-Reply-To: Date: Thu, 28 Dec 2023 16:56:54 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <1DDBE6DE-2BEC-4061-939E-4C87C3E276B3@yahoo.com> References: <0E56E105-2A22-460E-9C58-24074922AA18@yahoo.com> To: Mike Karels X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4T1RmN6SlQz3WN8 On Dec 28, 2023, at 13:12, Mike Karels wrote: > On 28 Dec 2023, at 14:22, Mark Millard wrote: >=20 >> On Dec 28, 2023, at 11:11, Mike Karels wrote: >>=20 >>> I am looking at enabling powerd by default on the Raspberry Pi 4 and = maybe >>> others. There is a bug from 2021 on the subject which has gotten = some recent >>> discussion, = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256836. Also, >>> problems come up from time to time about performance problems = because people >>> don't know to enable powerd. It makes FreeBSD look much slower than = Linux. >>=20 >> If performance comparison to linux is a driving issue, seeing what >> linux does about sdram_freq and sdram_freq_min may be relevant. This >> may be in whole, or in part, based on the RPi* firmware version the: >>=20 >> = https://www.raspberrypi.com/documentation/computers/config_txt.html#overcl= ocking-options >> and its: >> "This table gives the default values for the options on various >> Raspberry Pi models, all frequencies are stated in MHz." >=20 > I'm not looking to optimize everything to improve comparison with = Linux; > people can optimize their own systems based on things like cooling. > I just want to get the low-hanging fruit here, with safe defaults. > Running at 600 MHz all the time is totally suboptimal. People who > want to tweak will always find more improvements. Okay. Take my notes as just notices about potential points that may be run into by some folks. They are not objections to powerd use in the snapshots or in other default FreeBSD configurations, nor to any specific tradeoffs in the support. Some other background information is noted as well. >> content has varied as firmware releases have been made. But I've not >> always found that the two match for FreeBSD. This might be because >> they mixed firmware and linux defaults without being explicit, >> something I've run into before. (I'll note that the history of the >> documented defaults is available via giuthub, even if somewhat messy >> as they restructured the documentation over time.) >>=20 >> For the RPi4B's and Pi 400's the modern tables indicate >> sdram_freq_min=3D3200 is the default. It used to be = sdram_freq_min=3D400 . >> Recent testing of stable/14 snapshots with RPI4B's has shown the 400 >> figure is in use. Only the RPi4B's, Pi 400's, and Pi5 show non-400 >> defaults in the modern table. >=20 > It doesn't sound like there is a single, universal change to be made = to > optimize sdram in config.txt or rc.conf. I think the most we could do > is to add notes as comments, but many people probably never look at > config.txt. I expect that the config.txt for each RPi* related snapshot starts out to be based on one of: # ls -Tlod /usr/ports/sysutils/rpi-firmware/files/* -rw-r--r-- 1 root wheel uarch 89 Apr 21 21:08:11 2021 = /usr/ports/sysutils/rpi-firmware/files/config.txt -rw-r--r-- 1 root wheel uarch 177 Apr 21 21:08:11 2021 = /usr/ports/sysutils/rpi-firmware/files/config_arm64.txt -rw-r--r-- 1 root wheel uarch 141 Apr 21 21:08:11 2021 = /usr/ports/sysutils/rpi-firmware/files/config_rpi3.txt -rw-r--r-- 1 root wheel uarch 161 Apr 21 21:08:11 2021 = /usr/ports/sysutils/rpi-firmware/files/config_rpi3_edk2.txt -rw-r--r-- 1 root wheel uarch 129 Apr 21 21:08:11 2021 = /usr/ports/sysutils/rpi-firmware/files/config_rpi4.txt -rw-r--r-- 1 root wheel uarch 110 Apr 21 21:08:11 2021 = /usr/ports/sysutils/rpi-firmware/files/config_rpi_0_w.txt sysutils/rpi-firmware/files/config.txt and sysutils/rpi-firmware/files/config_rpi_0_w.txt look to be for armv7 (32-bit) booting. I'll remind that there is only a GENERICSD snapshot for armv7, despite variations in RPi* firmware defaults for RPi2B's (no bluetooth cases) vs. RPi3B's (bluetooth present). But there is a: sysutils/u-boot-rpi3-32 that some folks could be using. A grep for sdram did not show any matches. If the RPi* firmware default is not used, it does look like notable model tracking would end up being involved. >> Another such example is that RPi4B Rev 1.4+ is documented to have >> arm_freq=3D1800 by default if arm_boot=3D1 in config.txt . Typo fix: arm_boost=3D1 A grep for arm_boost did not show any matches, similarly for other forms of control. So RPi4B's would likely get 1500 and 600 as possibilities for powerd to use. >> Otherwise >> RPi4B's are documented to use 1500 as the default. >>=20 >> But FreeBSD does not end up with the documented figures: ending up >> matching the default arm_freq_min=3D600 instead of (all but Pi0/W, >> Pi1, and Pi 5 are documhted to have the 600). My guess is that >> FreeBSD makes its own assignments. Note that the default >> arm_freq_min is model dependent if Pi0/W, Pi 1, or [someday] Pi 5 >> are to be covered. A grep for arm_freq (and related) did not show any matches. So: = defaults. >>> The simplest action is to enable powerd by default on the = arm64-aarch64-RPI >>> images. This would affect RPi 4 and variants, also RPI 3* and later = RPi 2. >>> I enabled powerd on an RPi 3B+, and it seems to have no issues; it = seems >>> to work. Does anyone know of a disadvantage of enabling powerd on = RPI >>> images for all targets? >>=20 >> Serial port configurations that attempt to use the mini-uart have >> problems with core_freq changes changing the serial console >> frequency in use. (mini-uart used for bluetooth instead has such >> issues too.) Which UART is used by default varies by model, the >> bluetooth capable families (so, e.g., not Pi2) having the >> mini-uart for the serial port and full UART for bluetooth. (I'm >> not clear on the v1.1 vs. v1.2 for the RPi2B's.) core_freq and >> core_freq_min also vary by model. >>=20 >> There is a core_freq_min. core_freq and core_freq_min defaults >> are documented as model specific. hdmi_enable_4kp60 use >> changes the default for core_freq and core_freq_min as well. >> There is enable_uart=3D1 to force the core clock to be fixed >> for seerial use, which frequency is dependent on force_turbo=3D1 >> vs. not. >=20 > It sounds like using the mini-uart will require config changes in any > case. I'd also be surprised if many (any?) FreeBSD users are using > the mini-uart at all. Anyone know? # grep -r disable-bt /usr/ports/sysutils/rpi-firmware/ | sort = /usr/ports/sysutils/rpi-firmware/files/config_arm64.txt:dtoverlay=3Ddisabl= e-bt = /usr/ports/sysutils/rpi-firmware/files/config_rpi3.txt:dtoverlay=3Ddisable= -bt = /usr/ports/sysutils/rpi-firmware/files/config_rpi4.txt:dtoverlay=3Ddisable= -bt = /usr/ports/sysutils/rpi-firmware/files/config_rpi_0_w.txt:dtoverlay=3Ddisa= ble-bt = /usr/ports/sysutils/rpi-firmware/pkg-plist:%%DATADIR%%/overlays/disable-bt= .dtbo These avoid the use of the mini-uart for the serial console. So, for FreeBSD, it would take explicit changes to end up with the mini-uart in use for those. Such is not true where the following happen to be used: /usr/ports/sysutils/rpi-firmware/files/config.txt /usr/ports/sysutils/rpi-firmware/files/config_rpi3_edk2.txt sysutils/rpi-firmware/files/config.txt is used for armv7 style snapshot booting. But the RPi2B v1.1 vs. RPi2B v1.2 used as armv7 vs. RPI3B used as armv7 has RPi* firmware default variations in this area (without bluetooth vs. with bluetooth). So, I expect there could be examples of mini-uart use where bluetooth exists for armv7 booting. >> I do not know what FreeBSD does about such things if it does >> not match such documentation. >>=20 >> There is: >>=20 >> = https://www.raspberrypi.com/documentation/computers/configuration.html#con= figuring-uarts >>=20 >> that says, in part, >>=20 >> QUOTE >> In order to use the mini UART, you need to configure the >> Raspberry Pi to use a fixed VPU core clock frequency >> END QUOTE >>=20 >> I'll also note that arm_64bit=3D1 is the default for the RPi4B's, >> Pi 400, CM4, and CM4S these days, but not for the rest that are >> 64=3Dbit capable (ignoring RPi5's, which do not have the parameter). >> I do not know what FreeBSD does about such things if it does >> not match such documentation. >=20 > In the current config.txt, arm_64bit=3D1 is in the [all] section. # grep -r arm_64bit /usr/ports/sysutils/rpi-firmware/ | sort /usr/ports/sysutils/rpi-firmware/files/config_arm64.txt:arm_64bit=3D1 /usr/ports/sysutils/rpi-firmware/files/config_rpi3.txt:arm_64bit=3D1 /usr/ports/sysutils/rpi-firmware/files/config_rpi3_edk2.txt:arm_64bit=3D1 /usr/ports/sysutils/rpi-firmware/files/config_rpi4.txt:arm_64bit=3D1 So: All the non-armv7 ones. sysutils/rpi-firmware/files/config_rpi[34].txt are no longer used by any modern enough snapshot build. sysutils/rpi-firmware/files/config_arm64.txt is used instead. sysutils/rpi-firmware/files/config_rpi3_edk2.txt is not used by any snapshot build. >>> The alternative would be to configure at the first >>> boot, although I'm not positive of a definitive way to identify the = RPi >>> variants. Maybe just looking for a dev.cpu.0.freq sysctl node would >>> suffice. >>>=20 >>> If no one objects, I will make changes to enable powerd on RPI = snapshots >>> for 15-current, and we can see what happens. >=20 > Any objections? Anything else we should do by default? >=20 No objections by me, just notices about potential points that may be run into by some folks --or other background information. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Dec 29 02:45:44 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T1V9v5nrwz55GLL for ; Fri, 29 Dec 2023 02:45: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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4T1V9v2l7Xz3gDD for ; Fri, 29 Dec 2023 02:45:55 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 3BT2jjLY042368 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 28 Dec 2023 18:45:45 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 3BT2jiV5042367; Thu, 28 Dec 2023 18:45:44 -0800 (PST) (envelope-from fbsd) Date: Thu, 28 Dec 2023 18:45:44 -0800 From: bob prohaska To: Mark Millard Cc: John F Carr , "ticso@cicely.de" , Marcin Cieslak , "freebsd-arm@freebsd.org" Subject: Re: USB-serial adapter suggestions needed Message-ID: References: <55q37289-ss30-nq9o-7r31-086n999p394s@fncre.vasb> <23100FB9-BB4A-48FF-A715-84EF7F6F59A6@mit.edu> <6DD2FDE4-77DB-499A-AED8-F179A9DAA0EF@yahoo.com> <6A38A60B-3281-468D-907C-26AB2F8D07A6@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4T1V9v2l7Xz3gDD On Thu, Dec 28, 2023 at 12:38:58PM -0800, Mark Millard wrote: > On Dec 28, 2023, at 11:24, bob prohaska wrote: > > > On Wed, Dec 27, 2023 at 12:27:33PM -0800, Mark Millard wrote: > >> > >> Overall I've not been able to understand what the > >> (various?) hypothesized stage-by-stage byte flow > >> paths are in these notes. > >> > > > > Maybe this will help. The path is > > > > workstation> Ethernet > terminal server:usb-serial > serial wires> GPIO 8/10 > > > > I hesitated to use the words "terminal server" because that has implications > > (distinct IP address, multiple serial interfaces) that don't exist here. > > > > The workstation is a RasPiOS Pi4, the Pi3 host called pelorus is the terminal > > server and the GPIO pins are on the Pi3 host named www.zefox.net . > > Your prior messages reported text referencing .org, such as: > > FreeBSD/arm64 (www.zefox.org) (ttyu1) > > and: > > No, the garbled login prompt originates from www.zefox.org's > serial console. > > and: > > Understood, it's been hard to articulate 8-( Maybe > Workstation > ethernet > pelorus > usb port > gpio 8,10 > console www.zefox.org > is a little clearer > > So: "www.zefox.net " above is a change of report, if I understand > right. > It's my typo 8-( The host generating console output is the Pi3 named www.zefox.org . The host named www.zefox.net isn't involved at all, though it is present and I typed its name in error. > > The Ethernet connection works well enough for all the other hosts that I think > > we can disregard whether it's wired or WiFi and LAN or WAN or all four. > > You have also reported that: > > The Pi3 which reported the garbled login prompt > uses in config.txt: > b@www:/boot/msdos % more config.txt > init_uart_clock=3000000 > enable_uart=1 > kernel=u-boot.bin > kernel7=u-boot.bin > dtoverlay=mmc > force_mac_address=b8:27:eb:71:46:4f > > This is using the mini-uart for the serial console and the > full-function UART for bluetooth. It also is not using > arm_64bit=1 . (So armv7 support instead of aarch64 support?) > You are correct, it's using the mini-uart (which I didn't realize) per sysctl. The machine is running aarch64, the reference to kernel7 in config.txt is a mistake. Bluetooth and WiFi aren't used on www.zefox.org. > https://elinux.org/RPi_Serial_Connection claims: > > QUOTE > . . . the less capable mini-UART with no break detection, no framing errors > detection, no parity bit, no receive timeout interrupt and no DCD, DSR, > DTR or RI signals > END QUOTE > > This contrasts with: > > The Pi3 hosting the usb-serial adapter has in config.txt > bob@pelorus:~ % more /boot/efi/config.txt > [all] > arm_64bit=1 > dtparam=audio=on,i2c_arm=on,spi=on > dtoverlay=mmc > dtoverlay=disable-bt > device_tree_address=0x4000 > kernel=u-boot.bin > > which has the full-function UART for its serial console > and is using arm_64bit=1 . > > Why the variation? > That machine is the terminal server, pelorus, on the LAN. Its internal uart does not participate in the data transmission chain. "Hosting the usb-serial converter" was my euphemism for terminal server. Please accept my apologies for not proofreading more carefully! If there is a better choice of terminology please tell me. Thanks for your patience! bob prohaska From nobody Fri Dec 29 03:40:30 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T1WPC24Qwz55M3g for ; Fri, 29 Dec 2023 03:40:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T1WPB6HBcz4H0V for ; Fri, 29 Dec 2023 03:40:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703821244; bh=u7l9k+Iv5QinV75Cz5FhiQ8RqxySD3hrezKdi/vV4xQ=; h=From:Subject:Date:References:Cc:In-Reply-To:To:From:Subject:Reply-To; b=Uy+N0unA3DPO5WjXTKF9S2sZhBFwJuDyx8Qf4dWWVSYt8kcEZNfGPP2E5I9iPuxCMbJcmD16IkDaS/jkGoFQLXf9c8Oq6mEjVQ+/yD9BMjE07QMF8IYyIuv4+5tl4fW0UDcHmIYdSm1huLgJLPTqsLvqNIA2LoUV/gFH41wu84hwsdkf/9mC+opSf57vqvL4t/UvjRmeSmIjdP65kN1syBA/+BwEpBWptjpg1SAUcKjK6NQgPHAnlwwdHn/8ELEfrEdow+D+X7kqyYzGaWmRUIrCks15TZ/nn3VwaVxtGrakKhE7Q87aty7M9ldGh60f3JUqgX5G34CdjlmOaEDn+A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1703821244; bh=8mJwPwHzQSeJXwzOe1tAfR10qeMV54kL0R5Pfgim2E+=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=JaVlH49MbiwPy0XL0DGKGlfQKiH+l0qm1wzXhIbsE+LwsP7kPLrSKKrxlppC6cO3B+lyn5k0DyM/N7N2GqGqTL55SCq5PCqnrZVcEeB7gM4fqk7Czoz8yacLJMP1WG1om9tXd0k1N2dVltEzcrmTlqKckQncV/lTc6IxrF5f+CTantWpMP3t3XIdtp4GccG+40Fw8UTGmC443QiBaDYTzdoY4AE9X5NJHD73G2Pn9iKZXQ4d1E25V/fxfJPWrJjJ4UlnzKSXQqOMuoOxJEgM5GV1AR7gPdm3IGbaHdhso9EtHSpiJr5f0l1apF5O83xwMt242AkNVgRdln2lnju2dw== X-YMail-OSG: BRuiYMgVM1kaMeS5iY6W0Dc_6fQxXbis.A4pY.5RQi96wZXqFB3KYbaedG8.In5 Ab19B3sL5Ro27EqeAs8uA0ljj9kN2a6qerqddLTQFnMRaMpUdfr9S2k4q8AweoGRnc5v15qB8v_U FsqA5Pl6w.f7pfXKyUNsg1sJk7b_1hiB2F5GDz3JaAMAiinT0l4hSprL9WY.oa54K.5ShOnvgf9k uSkytmZBzAnkHyQGrbPEq.9JYV.5Cu3go047M7W92eepGRjNl.uHk_G8EQj2wmsrQQydvRaLMCl2 gkNrPn9xwIAntnxqVsvPEvB94AI723n49SbyXkHhvYgIUJH_QWYhzK10JGZrWG.zBe8nckX80rjl ZlpuO1v6egigxP6omAFJAuEsvi_MhU0zi_xA6sz7aPjTQ46enoRit6iU1phFGXmd75_IMA9s8oYN 5a0cn8Mnd.u6dYVPYHXTsUjswtdFRTWrdPuKTQtqtN1g0y7Jbw9fvlBQOUU9d8Y0GznkYgvTQKBv JcUB1.UCCvTzv13gGJb8A9OwXJONd3wCFRhTrGvtDUuAwxgOtYs1Xvi6QQoX9KYryT1DxVz3KQOb Jk45jDF2wdjE1ztIN4lTNGv5f.O9C45vSbnbpSy6i.rmJcKNn.kOjvtQIH_A3T_p.XFBDaxyhMEJ C4SZSdjnoLS8noIcjhSXEvpRL3fVVUA73K7RC71qUDhg5ZnoBzxTE1bHTZqnbb_GFkTK70HPCZFK RriGdkv.ID0SgKGMt3vHp2eD_pcvzOq.2Ymqa36jt534FHvw49Lbhjy83NLTvA7dZWGKuYZWAOiY j7q5FbgdnkLcbRGsu0W11ip4mql4ZvZzAZWJBHdHGPA0ZofXlxBlgMGNYnCT3TARWW3Tsf71ofQM BCx.XMHgbTycF0RzsMdaPBduPi9S8v1zsi21n5LK4T4LkKfT3hHN_ZsqE0r7D1WrN8q4vZsI_lu7 I9RL7STLvtoj_uD_3mtz9DijI3QYZIxCd45wu3QpVUh34c8W0fQCikM5S3MTe4dl.4tkcNdASc19 5WVD32ropArdB5IknmK8_gCRU5InhN4ktSTN6nbnsatSjR8Geh2uGhNieQipMNC65J_5pj5iSE3B xrbsC4JWQsYmgsjzkzPh5Y48NbRxq_d3OETVojkx6KNNrJT85OBSm_lw12iJ3O.y465fK0uL.5tr 5jnrqkIK1amzfWwAXhNj7grNAF6fuCKA7S8hGujn4Mqk4Q5GJaHUMHwWZ_BfPwQ_vUHoaMQJnY6a AOwi9eOLEsOpW9sDksH3k3PsJxgC.P_q_m6gAqkh7tmYFjGUM4DG6jr90sUV1bvw5HSiCvRiG6Mj cT1rHlNzi.9GtK05Hxl_0oY61zcb4PTRMd99LufPVIiRqDPI5d3240GJ_gksBfoPLGecp4vbqjyp ShwJ24.GuYnXeDGzDJKFT0TYbXkFuGUekHVC5mUAzyGMPImrG4Yoq_e08GvkoCnmepNLJ0bwE.rf xCeUp04.XHaFpTONResYt0QIWSUqK7gGU8hXfdlspTWFACK0.S6TcCjzjJGTpayXxM79gCN6AhC3 8CmXedEu2DwoZTmOjhYaOh2H3i10NC7eXKJPVVBmzFo6f6ec2TNxbv6BvBxHt.Qhgbl6lu2d_lB. 7V5coWcJmiyj9jdyIBx.bGhcF2yHJGE2wtxf8qw4UxQTUNtA7xqqaSpZnfMXkLJzWR1IN.w3WqgL _JXMryvahgz2RADbTZzDnaAOWIPFL0eUUTyMTMirSOKTt5CCT2I3aGaV5ulqU5PIodT6T3b2nulh ZTRP2og1W56oNT1..f6WL00In55L5HmqczLV4tU9549u.dHAmz8dV2wTr0SaRqha.fs_ojUNOtmM 6K9xSjqNlWJ5Sr4DSMWVmZuUhgqDt5aIVs2YbiXW4qI.WaXlKDMMoAydI7zM.zjrRycKMlpkBRWv 4Iuepx_eSgTn6xqW_ptyioRO837uN2AUUo8Dmt85RFYQ64QUdLRuVepfoQU2ScjHji06DWaihjqv siXItN7CHpUz9q2MT0UqZgNJdQEAH0tOHxXOVMMpLuk5BJINcRaW0g4OrYdir3GrD7MtKAN363YW VNTojVBLs_yktqKsmaDJKGwXWzV6xf3l__R0kWbPm5jLoV9haGZLyEdYvGbCrZT5Q7u_.Wx72pDA 64q1uNU1UI1.hw6bOXKfRLW65MPhMViexcFP6u0cy3z0rATf3gUS5wSy1CKlZPSlnjnVweBYkUJD e..I9P0uMN2z_TY4vIn9rDeQRTNZQYwxHbapcX90kylbhszxQD8LEWIF6NAhxReV9naF1Kj4tfN6 B X-Sonic-MF: X-Sonic-ID: b77f194d-b402-4e88-8963-4ae3db122c34 Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Fri, 29 Dec 2023 03:40:44 +0000 Received: by hermes--production-gq1-6949d6d8f9-gwrdd (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d4727a9b73cc6e6f5a5c8ed07ffcb494; Fri, 29 Dec 2023 03:40:41 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-4C62B640-776D-4FDB-BCD2-23CC7784A5FD Content-Transfer-Encoding: 7bit From: Mark Millard List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (1.0) Subject: Re: USB-serial adapter suggestions needed Date: Thu, 28 Dec 2023 19:40:30 -0800 Message-Id: References: Cc: John F Carr , ticso@cicely.de, Marcin Cieslak , freebsd-arm@freebsd.org In-Reply-To: To: bob prohaska X-Mailer: iPad Mail (21C62) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4T1WPB6HBcz4H0V --Apple-Mail-4C62B640-776D-4FDB-BCD2-23CC7784A5FD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Dec 28, 2023, at 18:46, bob prohaska wrote: >=20 > =EF=BB=BFOn Thu, Dec 28, 2023 at 12:38:58PM -0800, Mark Millard wrote: >> On Dec 28, 2023, at 11:24, bob prohaska wrote: >>=20 >>> On Wed, Dec 27, 2023 at 12:27:33PM -0800, Mark Millard wrote: >>>>=20 >>>> Overall I've not been able to understand what the >>>> (various?) hypothesized stage-by-stage byte flow >>>> paths are in these notes. >>>>=20 >>>=20 >>> Maybe this will help. The path is >>>=20 >>> workstation> Ethernet > terminal server:usb-serial > serial wires> GPIO 8= /10 >>>=20 >>> I hesitated to use the words "terminal server" because that has implicat= ions >>> (distinct IP address, multiple serial interfaces) that don't exist here.= >>>=20 >>> The workstation is a RasPiOS Pi4, the Pi3 host called pelorus is the ter= minal >>> server and the GPIO pins are on the Pi3 host named www.zefox.net . >>=20 >> Your prior messages reported text referencing .org, such as: >>=20 >> FreeBSD/arm64 (www.zefox.org) (ttyu1) >>=20 >> and: >>=20 >> No, the garbled login prompt originates from www.zefox.org's >> serial console. >>=20 >> and: >>=20 >> Understood, it's been hard to articulate 8-( Maybe >> Workstation > ethernet > pelorus > usb port > gpio 8,10 > console www.zef= ox.org >> is a little clearer >>=20 >> So: "www.zefox.net " above is a change of report, i= f I understand >> right. >>=20 >=20 > It's my typo 8-( > The host generating console output is the Pi3 named www.zefox.org . > The host named www.zefox.net isn't involved at all, though it is > present and I typed its name in error. >=20 >>> The Ethernet connection works well enough for all the other hosts that I= think >>> we can disregard whether it's wired or WiFi and LAN or WAN or all four. >>=20 >> You have also reported that: >>=20 >> The Pi3 which reported the garbled login prompt >> uses in config.txt: >> b@www:/boot/msdos % more config.txt >> init_uart_clock=3D3000000 >> enable_uart=3D1 >> kernel=3Du-boot.bin >> kernel7=3Du-boot.bin >> dtoverlay=3Dmmc >> force_mac_address=3Db8:27:eb:71:46:4f >>=20 >> This is using the mini-uart for the serial console and the >> full-function UART for bluetooth. It also is not using >> arm_64bit=3D1 . (So armv7 support instead of aarch64 support?) >>=20 >=20 > You are correct, it's using the mini-uart (which I didn't realize) > per sysctl. The machine is running aarch64, the reference to kernel7 > in config.txt is a mistake. Bluetooth and WiFi aren't used on www.zefox.o= rg. For RPi3B*=E2=80=99s, booting as aarch64 should have arm_64bit=3D1 in config= .txt , as I understand. Use of the mini-uart is probably not a good idea for the serial console: dto= verlay=3Ddisable-bt should also be listed, like for the other RPi3B* . In fact, other than the force_mac_address, the general content should be lik= e the one with arm_64bit=3D1 as far as I can tell. Do you have specific reas= ons for needing any of the differences? >> https://elinux.org/RPi_Serial_Connection claims: >>=20 >> QUOTE >> . . . the less capable mini-UART with no break detection, no framing erro= rs >> detection, no parity bit, no receive timeout interrupt and no DCD, DSR, >> DTR or RI signals >> END QUOTE >>=20 >> This contrasts with: >>=20 >> The Pi3 hosting the usb-serial adapter has in config.txt >> bob@pelorus:~ % more /boot/efi/config.txt >> [all] >> arm_64bit=3D1 >> dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don >> dtoverlay=3Dmmc >> dtoverlay=3Ddisable-bt >> device_tree_address=3D0x4000 >> kernel=3Du-boot.bin >>=20 >> which has the full-function UART for its serial console >> and is using arm_64bit=3D1 . >>=20 >> Why the variation? >>=20 >=20 > That machine is the terminal server, pelorus, on the LAN. Its > internal uart does not participate in the data transmission chain. > "Hosting the usb-serial converter" was my euphemism for terminal server. >=20 > Please accept my apologies for not proofreading more carefully! > If there is a better choice of terminology please tell me. >=20 > Thanks for your patience! >=20 > bob prohaska Note: edited on an iPad. For now, the computers I normally use are not avail= able. My ability to lookup some types of information is greatly limited. I w= ill soon be without internet access for some number of days.= --Apple-Mail-4C62B640-776D-4FDB-BCD2-23CC7784A5FD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Dec 28, 2= 023, at 18:46, bob prohaska <fbsd@www.zefox.net> wrote:

=
=EF=BB=BFOn Thu, Dec= 28, 2023 at 12:38:58PM -0800, Mark Millard wrote:
On Dec 28, 2023, at 11:24= , bob prohaska <fbsd@www.zefox.net> wrote:

On Wed, Dec 27, 2023 at 12:27:33PM -0800, Mark Mil= lard wrote:

Overall I've not been able to understand what t= he
(various?) hypothesized stage-by-stage byte flow
<= /font>
paths are in these notes.

=

Maybe this will help. The path is
=

work= station> Ethernet > terminal server:usb-serial > serial wires> G= PIO 8/10

I hesitated to use the words "terminal= server" because that has implications
(distinct IP address, multiple serial interfaces) that don't e= xist here.

<= /font>
The workstation is a RasPiOS Pi4, th= e Pi3 host called pelorus is the terminal
server and the GPIO pins are on the Pi3 host named www.zef= ox.net .

Your prior messages reporte= d text referencing .org, such as:

FreeBSD/arm64 (w= ww.zefox.org) (ttyu1)

and:
<= span>No, the garbled login prompt originates from www.zefox.org's
=
serial console.
<= font face=3D"Courier New">
and:

<= /font>
Understood, it's been hard to articulate 8-( Maybe
Workstatio= n > ethernet > pelorus > usb port > gpio 8,10 > console www.z= efox.org
is a little clearer

So: "www.= zefox.net <http://www.zefox.net/>" above is a change of report, if I u= nderstand
right.


It's my typo 8-(
= The host generating console output is the Pi3 named www.zefox.org .
The host named www.zefox.net isn't involved at all, though it i= s
present and I typed its name in error.

The Ethernet connection works well enough for all th= e other hosts  that I think
we can disregard whether it's wired or WiFi and LAN or WAN or all f= our.

You have also reported that:

The Pi3 which reported the garbled login prompt
uses in config.txt:
b@www:/boot/msdos % more config.t= xt
init_uart_clock=3D3000000
enable_uart=3D1
kernel7=3Du-boot.bin
dt= overlay=3Dmmc
force_mac_address=3Db8:27:eb:71:46:4f

This is using the mini-uart for the serial console and the
full-function UART for bluetooth. It also is not using
<= /font>
arm_64bit=3D1 . (So armv7 support instead of aarch64 support?)
<= /font>

You are correct, it's using the mini-uart (which I didn't realize)
per sysctl.  The machine is running aarch64, the referenc= e to kernel7
in config.txt is a mistake.  Bluetooth an= d WiFi aren't used on www.zefox.org.

For RPi3B*=E2=80=99s, booting as aarch64 should have arm_64= bit=3D1 in config.txt , as I understand.

Use of the= mini-uart is probably not a good idea for the serial console: dtoverlay=3Dd= isable-bt should also be listed, like for the other RPi3B* .

<= /div>
In fact, other than the force_mac_address, the general content sho= uld be like the one with arm_64bit=3D1 as far as I can tell. Do you have spe= cific reasons for needing any of the differences?

https://elinux.org/RPi_Serial_Connection claims:
=
QUOTE
. . . the less capable mini-UART with no break det= ection, no framing errors
detection, no parity bit, no receive t= imeout interrupt and no DCD, DSR,
DTR or RI signals
END QUOTE

This contrasts with:
=

The Pi3 hosting the usb-serial adapter has in config.txt
bob@pelorus:~ % more /boot/efi/config.txt
=
[all]
<= /font>
arm_64bit=3D1
dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don
dtoverlay=3Dmmc
dtoverlay=3Ddisable-bt
de= vice_tree_address=3D0x4000
kernel=3Du-boot.bin

which has the full-function UART for its serial console
=
and is using arm_64bit=3D1 .

=
Why the variation= ?


That machine is the terminal server, pelorus, on the LAN= . Its
internal uart does not participate in the data transm= ission chain.
"Hosting the usb-serial converter" was my eup= hemism for terminal server.

Please accept m= y apologies for not proofreading more carefully!
If there is= a better choice of terminology please tell me.

= Thanks for your patience!

bob prohask= a

Note: edited on an iPad. For n= ow, the computers I normally use are not available. My ability to lookup som= e types of information is greatly limited. I will soon be without internet a= ccess for some number of days.
= --Apple-Mail-4C62B640-776D-4FDB-BCD2-23CC7784A5FD-- From nobody Fri Dec 29 04:55:37 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T1Y3p1kcxz55Tgx for ; Fri, 29 Dec 2023 04:55:50 +0000 (UTC) (envelope-from yklaxds@gmail.com) Received: from mail-vk1-xa2b.google.com (mail-vk1-xa2b.google.com [IPv6:2607:f8b0:4864:20::a2b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T1Y3n4qRpz4Q0D for ; Fri, 29 Dec 2023 04:55:49 +0000 (UTC) (envelope-from yklaxds@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=TJcAWP5T; spf=pass (mx1.freebsd.org: domain of yklaxds@gmail.com designates 2607:f8b0:4864:20::a2b as permitted sender) smtp.mailfrom=yklaxds@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-vk1-xa2b.google.com with SMTP id 71dfb90a1353d-4b77c844087so46059e0c.1 for ; Thu, 28 Dec 2023 20:55:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703825749; x=1704430549; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=9SSj8CkzfcV4OD1q7T/6lCUkJYorvt4KCg4fAKb1gXk=; b=TJcAWP5TjvKqT1M0G9GWPhMYle0dcpCAYv9F4pDV3QxIrWn+ni7W19YdTavUoGe/ql stfrrKF6M+SYH8rvofC4o86bqhYCjTZVqUP3e4BytcC5McENxu9kGZ4LfNwWxE9ZNyW3 65ClVaPm3J1QkyZxfgGU7FPIcnLPbJyJLSfYY3Gj18qvWjmn+XoRi/jq8VMuWrX0FCQ6 4cy9vvA36HurHo3nc3YJ7qUGnZ5DlNT4WTFAtO1DwjNA/ZbeZrgBx91AgjOXKvd8+3J7 6PZ4HXMCuwqEX0KLgU2hAz+WDsjy0Y7dhaYC17LgAvzoBtP7LydJwAbWBAVHmjjr7yJh 7lig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703825749; x=1704430549; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=9SSj8CkzfcV4OD1q7T/6lCUkJYorvt4KCg4fAKb1gXk=; b=ZAyO8+GvWSm1Gxr+UDNrt6gA2p7jJ+T/A0UwA2XUF3hlkiroELCPYscyB7LTt44oPp +EcvLc4dY2rKgGBmR/ELyKf6zqUJcwAeFg+93RShN+dy5USe50OTUpejgL3FPPbN16or hdjr3ibp4ZIyYajgatF9JJK5pObIjTQe4ZKO3faGVhdI2pkxOJpaV0Ei/TbmBX/SWCgB gsI/2fAQEB3UbvHjRgpaIZMEV4kqTVUZ+oEyIdB7iQZTvZ7p2VBqk1lEwoinW5/25e9J B9DOkrEGrkYq2aAVH9V1zr6/KcbY27ShuJLYR1NwalDaw1sX1v73w9I1lNKJCF0yCH6o zh3g== X-Gm-Message-State: AOJu0YxS/bVUu/ZYty/AjhxBZ8PoT7vt2bvEZboNp/+YHzdaJDoUaBoa olthoI8Yk9k7gW0bKKpOaS/2fvbNweqd+Khfm89A1SEofWQ= X-Google-Smtp-Source: AGHT+IEIXMOHmTF5868qTPkixMOdfT4qEOu7j8XIGJVASY8UIdkl2fjMUZ5vt3oXKezFgwUpksbbzzDGcnAVp2maiAA= X-Received: by 2002:a05:6122:4319:b0:4b7:2c46:32bb with SMTP id cp25-20020a056122431900b004b72c4632bbmr4845574vkb.13.1703825748773; Thu, 28 Dec 2023 20:55:48 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 From: ykla Date: Fri, 29 Dec 2023 12:55:37 +0800 Message-ID: Subject: When will FreeBSD support RPI5? To: FreeBSD ARM List Content-Type: multipart/alternative; boundary="00000000000083d3be060d9ed8ac" X-Spamd-Result: default: False [-2.86 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.86)[-0.858]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a2b:from]; DKIM_TRACE(0.00)[gmail.com:+]; TO_DN_ALL(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-Rspamd-Queue-Id: 4T1Y3n4qRpz4Q0D X-Spamd-Bar: -- --00000000000083d3be060d9ed8ac Content-Type: text/plain; charset="UTF-8" Hi, When will FreeBSD support RPI5, It's seems that most codes form netbsd of rpi4. And WiFi not supported now. But OpenBSD supports rpi WiFi many years. ykla --00000000000083d3be060d9ed8ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

When wil= l FreeBSD support RPI5, It's seems that most codes form netbsd of rpi4.= And WiFi not supported now. But OpenBSD supports rpi WiFi many years.=C2= =A0

ykla
--00000000000083d3be060d9ed8ac-- From nobody Fri Dec 29 06:06:26 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T1ZdG4DG1z55MKt for ; Fri, 29 Dec 2023 06:06:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T1ZdG2zyRz4WMk for ; Fri, 29 Dec 2023 06:06:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1703829986; a=rsa-sha256; cv=none; b=mbb9VnpRqSDJEtsR3H8QvvyUAKHBCJftytoAdd8iJPqoajyywqowc7LH1QTID6evD63D23 Q5q0EWZ/revN/qx5hf5Gsu1TiTF5WH9OKtf7/ol3R//kH91+jYVRdNeoCKw7vh6DLlEr+j tOhEomxYbhB1QnB6zWnzvmAqix2gn0tyzNC11ob4DxDHrODlubkJRhohozC8v0iWOcTG0Y wAAzFRyqRWxLgE90j5nmz7hPXJZBfSyFOQVmzJL+9ThrEXYNfORWRKtiLY5RqjCpC/4Tro xGDsRrtKcTId8JX7FNH65Ur8ywuCwwMGenhGu2GILilECaj4xrdQVBKd52DniQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1703829986; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sY4NcGVuUTWHRx5SUPXRtcb7ZU9SjL5TNBkAfhc/7bY=; b=JJlFJ7Hn7se5/BoHPIsZFY7Q0wrgoFw59M3l/9X5piWVkBLpVBolyJGpBGIXZ6K6s/lYJB rysM6sNCCaeNaNbgaL+BhLExkU8u1Ek5tAB7E2NKATCKKqH/3RJUNGSoW4FayMPFBBs4HS JDt7QKKYcK5C6GMkkrQB4OPaW07nUnaQWBJfVM2wlxCwWaMB/UsIB4yF3v3XFd1N2NXq5T J+42mz11421Ei9PvoYtNOAWt2jNUjYAn0ZUoWiNomNbjDOCKOoDhhhjIyZObZlppE0NwSk 15vaGSCuO7TLiBorH8TknBnVXTIZCt4TSnVQzAECaXa+1FnJY/MJng1thwyIiA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4T1ZdG1x8JztqG for ; Fri, 29 Dec 2023 06:06:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 3BT66Q74043065 for ; Fri, 29 Dec 2023 06:06:26 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 3BT66Q4S043064 for freebsd-arm@FreeBSD.org; Fri, 29 Dec 2023 06:06:26 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 264673] aw_if_dwc does not support current versions of u-boot Date: Fri, 29 Dec 2023 06:06:26 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 13.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: mhorne@freebsd.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution assigned_to bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264673 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Assignee|freebsd-arm@FreeBSD.org |mhorne@freebsd.org Status|New |Closed --- Comment #4 from Mark Linimon --- ^Triage: committed and MFCed back in 2022. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Dec 29 17:05:25 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T1sFs61rrz54WnX for ; Fri, 29 Dec 2023 17:05:37 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T1sFs5TFnz4XvX; Fri, 29 Dec 2023 17:05:37 +0000 (UTC) (envelope-from jsm@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1703869537; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=a7DZqAytqeLJDm22Byvb6evoPTY8nARFkD3OfEaqqFs=; b=TsRGTvpi2ar679GCstaW4vnYK+wtz6+Vwd5f1GWOs7VXu10z+uWwPlfqLVnWRkZBIkLGB+ k+/wFLxeht5FBY9foXYgpYPSM6FPebo6mXyMSOPMKdv7vxZBxJLpdUREMoyGVDVZ+6cMbr vmKDZi+bB8fOHxVR2lBobx8awcKMvvmR7/satKBRYasfkWMOrwFOq897LKUnORkpL5nGSD WSumjd60RHuEISj/nWKEoI8g7bdr2ATjTZeQkg+htGjyoCiHrNMECBKveyMFNsVOaKssqz FRNeuq8Wme+FO5MGpQcGd1q585vLbfGNMCK6e3V9FS18nUSyiOZvImOIpD7Bbw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1703869537; a=rsa-sha256; cv=none; b=oROTJXKHq4yy7uTDlz+iS9/MRV/wzqVaEkjbl510C3b4jUJlyGyZOqNWdKBnH9/4DNenw4 seYxPx3ZQEnwIOZSHCJsfRZJGpak9VOUS1T6xHV60IQNNznxQ1yJcO/yyDWaB9F0iyLFPj EXwZvEi+dFeDUE/rjRrJYoZT1eU3ZQheS3CJmPYEoc9+ofTrugWBf1Mlb4oEpFZwC3VY+7 qBGoDTawA4KHtQp796x6FSJnUlbTf//blQ3qJetoek5S3f0vNLDGfr7wgM+hQXYfvxhdxC V6zIouiOzI3sIA81M4Q0E1fp7j5lMGp2vaL85wDznjU7H/JfXgeSCNGrSznrPw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1703869537; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=a7DZqAytqeLJDm22Byvb6evoPTY8nARFkD3OfEaqqFs=; b=VWv5YlX0z/kRPd1SRaC9bHsCJLDLSyE+gwyBL3g+mRtjQk/OmheFuu1AQgHu3QU9v2ffUt zOvGJHtf7nZUtW9N2iz5vUcyQBuflFSRmJJUEsgddKyLTOKHo+zoQE5yq2LiJE/iyJR3ZG IHDAW2X4LgBCUdVBBVXvW26NPIO0QLjx6jxhe8AuYSaB6ys14NEXvRd9qfoej0+IaIP9NG uQuMgFVxZnwcL3j4gYn9LVBWmNT7W4wgze48T1iJfo1XWobWaXDuGva/V3wmGz9APZ2Xus 1f6Y/CLx3ejVLKw3qYrn/2NOyV7r7aPeXcwmnXQZE5n5lTZmGKsObzKKHhFcjA== Received: from [192.168.1.5] (mail.northatlanticmusicsupplies.com [212.237.182.202]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jsm) by smtp.freebsd.org (Postfix) with ESMTPSA id 4T1sFs2B4gz1423; Fri, 29 Dec 2023 17:05:37 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Message-ID: Date: Fri, 29 Dec 2023 18:05:25 +0100 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: When will FreeBSD support RPI5? To: ykla , FreeBSD ARM List References: Content-Language: en-US From: Jesper Schmitz Mouridsen In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 29.12.2023 05.55, ykla wrote: > Hi, > > When will FreeBSD support RPI5 https://forums.freebsd.org/threads/raspberry-pi-5-status.91406/ > > ykla From nobody Sat Dec 30 12:44:49 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T2MRD63Cxz557R3 for ; Sat, 30 Dec 2023 12:45:28 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T2MRD2Dh1z3KD8 for ; Sat, 30 Dec 2023 12:45:28 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=GYxmyjRy; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2a00:1450:4864:20::534 as permitted sender) smtp.mailfrom=marietto2008@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-5532b45c286so8631066a12.0 for ; Sat, 30 Dec 2023 04:45:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703940327; x=1704545127; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=bPCbbRUS1CrLGmmvlSHwH0vrk0FlX5arqnSW5aeFwJo=; b=GYxmyjRyReJypAnwIoLkoFUYEN9opLFw7uRU3MW2D+5KjH00PjD0dVmaAm+nlpeaLo v1uYY8hlaWx6IQgPxcWDOiajDO+uRySoTEQrD+5hf2+4lMx3yHVCKdH/8Z59l8//hA+D 1STh3TtJJe4oGCudrns1joC4aInAyAXA6LqOSbb4/aVnSTSrycEO568Ci4nE3jfSnnhF yt+SO1a38TSHaRR9etpFS6+k0DW3d88XU8kVYbACYNNTCV26bQqDyGgxNzWp5pQ9UgmE bk9Nm6qZEZdQyGimMziVxDJeF05axM9k9i5NaR/stAnYrOlEdxmW8ZdYBaLCPjVew+N9 OvgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703940327; x=1704545127; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=bPCbbRUS1CrLGmmvlSHwH0vrk0FlX5arqnSW5aeFwJo=; b=O5OhIHqhs5Z40tceAxkQePIBfQQ+OviwmL26LE/HRanUUUL1PfYO15ALVTDLhyZ8gz eLc7XcRvo3jicj+bY6ITXHp4dP2igJbzhitbVExmrvBdLgQSTaPksi1kpLkt6npZtzQs yLFitU7wVQxtWDbs9jKRYyC+CKusdYpfd0tM3MRBZD6QRMAolu92kNp56k2oqDHz51E/ 8MRvxKa9av/TAquNt029ItnBXSwgySEWM3CxejbvjYD0pkKwXXKGO8ovggEsZE7Afs7S ndWu33JAG+kgCo3yWF5IYsNHZIApYXYsB0vnE7/WmM4XlYTY7F4MaY7lvYlIAWrNW1h3 tvWA== X-Gm-Message-State: AOJu0Ywl5II1zOG4wtDk34OiG69rCUHfdoeZmOTwPmQ/lhq7OaVycswV FbC4zFill7RGnR838dXH0DoxPAAobz3YRxqP1VuoqJYgDM8GuA== X-Google-Smtp-Source: AGHT+IE/4hBv5expw63ZixrQDAN/WQk4agJhxcM/Pnhnru9gnhTupPDdMtZqk3YQeLhZTinDhT03EXYTWNJTJdhdwBc= X-Received: by 2002:a17:907:9496:b0:a23:3aff:2a05 with SMTP id dm22-20020a170907949600b00a233aff2a05mr4157508ejc.112.1703940326354; Sat, 30 Dec 2023 04:45:26 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <97aa980b9b44.6eb7f9d5c54e7@mailgate.us> <5ce9eea4-500c-4f06-a7f5-363a0e0d5178@xen.org> In-Reply-To: <5ce9eea4-500c-4f06-a7f5-363a0e0d5178@xen.org> From: Mario Marietto Date: Sat, 30 Dec 2023 13:44:49 +0100 Message-ID: Subject: Re: How to boot FreeBSD for arm 32 bit as DomU with u-boot on my ARM Chromebook To: Julien Grall Cc: Warner Losh , Stefano Stabellini , Stanislav Silnicki , freebsd-arm@freebsd.org, Michal.Orzel@amd.com, xen-devel@lists.xenproject.org, Artem_Mygaiev@epam.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::534:from]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCPT_COUNT_SEVEN(0.00)[8]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4T2MRD2Dh1z3KD8 X-Spamd-Bar: --- > https://src.fedoraproject.org/repo/pkgs/uboot-tools/u-boot-2017.05.tar.bz= 2/sha512/be270f9242a72b05463092a022bbabd54996762de1ff23bf7575124ac02e62f495= 72a4e2f6f571a5019047d40027e56e35593b5cc373c4a5a39b100c3377ba93/ > This source code has no support for Xen guests. This was only added in 20= 20. Can you clarify why you can't use the latest upstream U-boot? It's true. I've got the source code of that custom u-boot implementation in the wrong place. This is the right place : https://forum.doozan.com/read.php?3,49039 an u-boot / xen developer suggested to me to explore that site because there is the one and only u-boot customized and off the tree version that can chainload the freebsd bootloader "ubldr". Unfortunately to work the FreeBSD rootfs should be compiled with armV5,but my ARM Chromebook works with armV7. I don't know if armV7 is retrocompatible with armV5. In addition,armV5 has been removed from FreeBSD starting from version 12. Infact Balanga used FreeBSD 11.2. FreeBSD 11 has gone EOL for several years and it's very hard to make it in a usable state today. ---> In fact, there are some missing low-level layers (e.g. hypercalls) in order to properly use it for 32-bit domU. I don't know if there is support out-of-tree. @Elliott Mitchell some time ago concerning that point,said : I've only ever tried arm64, but since arm32 didn't appear to need much to be operational I tried to make it possible. In theory it /should/work on arm32, but I've never tried it. What was missing was I had never added it to the configuration and one link was needed. Updated "submit" branch has a tiny adjustment. (the only difference is the hypercall wrappers, register naming and where the op code goes, very simple compatibility) I'm not experienced,but it seems to me that only a few patches are needed to make the job done. ---> Do you have a tree with FreeBSD + your patches? I would like to check the zImage code. my patches ? Are you talking about the patches that should have been used on the @Elliott Mitchell github ? https://gitlab.com/ehem/freebsd-src.git yes,I tried to use his code but I've got the same error "invalid kernel" Elliott also said : ---> Julien Grall's patches are very much PoC. As such I've done a lot of updating. Take a look at branch "submit": https://gitlab.com/ehem/freebsd-src.git Problem is that FreeBSD's interrupt situation is troublesome. Rather than 1 interrupt framework, there are 4. Each has different built-in assumptions. "INTRNG" was designed for ARM and deliberately threw away the x86 assumptions, but then added other assumptions. I've got it working, just I'm stuck. He said that it should work,but I get the error "invalid kernel". It seems there is the need to write a patch that allows the FreeBSD kernel to boot as a zImage file. This could be accomplished applying this patch to a specific file that's on the source code of FreeBSD : https://xenbits.xen.org/gitweb/?p=3Dp...8;hb=3D0782e25d98cc1391472717035f98= 6c979edef0c9 This patch was written by Julien Grall a lot of time ago and now it does not work anymore. This is the reason explain by the xen developers : It appears FreeBSD-CURRENT removed the last step converting the kernel file to kernel.bin.The patch can be readily rebased, but without kernel.bin that doesn't do too much. So,without a rebase of that patch the first option is not applicable. Even in this case,it seems that the job is not particularly complicated.... Thanks. On Sat, Dec 30, 2023 at 11:05=E2=80=AFAM Julien Grall wrot= e: > > > > On 28/12/2023 16:25, Mario Marietto wrote: > > Hello. > > Hi, > > > I'm trying to compile u-boot-2017.05 (because it can boot a 32-bit ARM > > board. It is an out-of-tree u-boot build that can execute the ubldr to > > boot FreeBSD. I found it here : > > > > https://src.fedoraproject.org/repo/pkgs/uboot-tools/u-boot-2017.05.tar.= bz2/sha512/be270f9242a72b05463092a022bbabd54996762de1ff23bf7575124ac02e62f4= 9572a4e2f6f571a5019047d40027e56e35593b5cc373c4a5a39b100c3377ba93/ > > This source code has no support for Xen guests. This was only added in > 2020. Can you clarify why you can't use the latest upstream U-boot? > > > > > It has been suggested to me by the U-Boot Xen maintainers. Infact one > > of them said : > > > > > > Yes, it can boot a 32-bit ARM board. I'm not a FreeBSD person, but > > I've helped a FreeBSD user booting a 32-bit ARM box with u-boot > > (GoFlexHome Marvell Kirkwood 6281). The u-boot version was 2017.05. > > I used an out-of-tree u-boot build. This u-boot executed the ubldr to > > boot FreeBSD. Please see here : > > https://forum.doozan.com/read.php?3,49039,82059#msg-82059 > > > > > So. I tried to compile it directly on my ARM Chromebook,but it failed. > > And it also fails if compiled with "ARCH=3Darm > > CROSS_COMPILE=3Darm-linux-gnueabihf-" on my Ubuntu 23.04 x86_64 > > workstation : > > > > > > /Chromebook/freebsd-xen/domU-freebsd/bootloaders/u-boot-2017.05# make > > snow_defconfig > > IIUC, you want to boot FreeBSD in a DomU. So you need to build U-boot > using a Xen specific configuration. Looking at the code, I can find > xenguest_arm64_defconfig but there are no equivalent for arm32. > > In fact, there are some missing low-level layer (e.g. hypercalls) in > order to properly use it for 32-bit domU. I don't know if there are > support out-of-tree. > > So you will probably need to tweak U-boot for your setup. > > Looking at the other thread, you seem to have also tried to load the > binary from xl. > > From the below error, it sounds like you are trying to boot an ELF > rather than a zImage: > > xc: error: panic: xg_dom_elfloader.c:63: xc_dom_guest_type: image not > capable of booting inside a HVM container: Invalid kernel > > Do you have a tree with FreeBSD + your patches? I would like to check > the zImage code. > > Cheers, > > [1] > http://lore.kernel.org/CA+1FSii6RRM7G52kPrD80+yR=3DgiWcB8--kpGDDQkkEK=3D0= dnCmw@mail.gmail.com > > > > > HOSTCC scripts/basic/fixdep > > HOSTCC scripts/kconfig/conf.o > > HOSTCC scripts/kconfig/zconf.tab.o > > HOSTLD scripts/kconfig/conf > > # > > # configuration written to .config > > # > > > > > > /Chromebook/freebsd-xen/domU-freebsd/bootloaders/u-boot-2017.05# make > > > > scripts/kconfig/conf --silentoldconfig Kconfig > > CHK include/config.h > > CFG u-boot.cfg > > GEN include/autoconf.mk > > GEN include/autoconf.mk.dep > > CFG spl/u-boot.cfg > > GEN spl/include/autoconf.mk > > CHK include/config/uboot.release > > CHK include/generated/version_autogenerated.h > > UPD include/generated/version_autogenerated.h > > CHK include/generated/timestamp_autogenerated.h > > UPD include/generated/timestamp_autogenerated.h > > CC lib/asm-offsets.s > > gcc: error: unrecognized -march target: armv5 > > gcc: note: valid arguments are: armv4 armv4t armv5t armv5te armv5tej > > armv6 armv6j armv6k armv6z armv6kz armv6zk armv6t2 armv6-m armv6s-m > > armv7 armv7-a armv7ve armv7-r armv7-m armv7e-m armv8-a armv8.1-a > > armv8.2-a armv8.3-a armv8.4-a > > armv8.5-a armv8.6-a armv8-m.base armv8-m.main armv8-r armv8.1-m.main > > armv9-a iwmmxt iwmmxt2 native; did you mean =E2=80=98armv4=E2=80=99? > > gcc: error: missing argument to =E2=80=98-march=3D=E2=80=99 > > make[1]: *** [Kbuild:44: lib/asm-offsets.s] Errore 1 > > make: *** [Makefile:1287: prepare0] Errore 2 > > > > What should I do to compile it succesfully ? > > > > On Sat, Dec 23, 2023 at 7:36=E2=80=AFPM Mario Marietto wrote: > >> > >> I've added this parameter to bootxen.source : > >> > >> guest_loglvl=3Dall > >> > >> bootxen.source : > >> > >> mmc dev 1 > >> ext2load mmc 1:3 0x42000000 zImage-5.4.261-iommu-dma-on-xen > >> ext2load mmc 1:3 0x51000000 xen-4.17-armhf-armmp-0x51004000.ub > >> ext2load mmc 1:3 0x5ffec000 exynos5250-snow.dtb > >> fdt addr 0x5ffec000 > >> fdt resize 1024 > >> fdt set /chosen \#address-cells <0x2> > >> fdt set /chosen \#size-cells <0x2> > >> fdt set /chosen xen,xen-bootargs "console=3Ddtuart dtuart=3Dserial0 do= m0_mem=3D1152M dom0_max_vcpus=3D2 bootscrub=3D0 vwfi=3Dnative guest_loglvl= =3Dall" > >> fdt mknod /chosen dom0 > >> fdt set /chosen/dom0 compatible "xen,linux-zimage" "xen,multiboot-mod= ule" "multiboot,module" > >> fdt set /chosen/dom0 reg <0x0 0x42000000 0x0 0x49F9A8 > > >> fdt set /chosen xen,dom0-bootargs "console=3Dtty1 root=3D/dev/mmcblk1p= 4 rw rootwait clk_ignore_unused --no-log" > >> bootm 0x51000000 - 0x5ffec000 > >> > >> > >> but when I try to boot FreeBSD I don't get more informations than usua= l : > >> > >> root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/domU/freebsd-xen# = ./start-freebsd > >> > >> Parsing config from freebsd.cfg > >> xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader fou= nd: Invalid kernel > >> libxl: error: libxl_dom.c:571:libxl__build_dom: xc_dom_parse_image fai= led > >> libxl: error: libxl_create.c:1640:domcreate_rebuild_done: Domain 1:can= not (re-)build domain: -3 > >> libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 1:Non-e= xistent domain > >> libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 1:Un= able to destroy guest > >> libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Destruct= ion of domain failed > >> freebsd is an invalid domain identifier (rc=3D-6) > >> > >> Are you aware about a new parameter that I can use to have more detail= ed debug information ? > >> > >> On Wed, Dec 20, 2023 at 5:52=E2=80=AFAM Warner Losh w= rote: > >>> > >>> I'd think you'd need the right virtualization loader. I'm not entirel= y sure the u-boot.bin you've been creating is for a dom-u.. > >>> If I misunderstood, then the below isn't good advice. Chain booting t= he u-boot, the first u-boot initializes things so you want > >>> to start with stage after the SPL. But the different error messages s= uggest that it's trying to reboot with kexec, which > >>> isn't supported on armv7 at the moment. > >>> > >>> If you could boot in kvm, I think that the following would work.... = Though I'm not entirely sure how to > >>> specify the two .fd files in your setup. The use of qemu is to have a= n easy env to debug things... I don't > >>> have a chromebook to try... > >>> > >>> My first instinct would be to try qemu on x86 (this is the first step= of many to get to your destination). > >>> > >>> If you could boot the GENERIC_SD image that we produce using qemu + e= dk2-arm-code.fd that would > >>> be a huge first step. This will give you the boot loader, I believe, = to boot in the VM that you need better > >>> than going via the u-boot route. Since you are booting in a virtualiz= ed environment, I think it wouldn't > >>> matter which one :). > >>> > >>> So, I did the following to boot the virtualized armv7 FreeBSD environ= ment, following a post on the forums I found and knew to have the right rec= ipe: > >>> https://forums.freebsd.org/threads/run-boot-freebsd-arm-32bit-image-i= n-qemu.80765/ > >>> > >>> 1. pkg install qemu > >>> 2. mkdir qemu-armv7-env > >>> 3. cd qemu-armv7-env > >>> 4. fetch https://download.freebsd.org/releases/arm/armv7/ISO-IMAGES/1= 4.0/FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD.img.xz > >>> 5. xz -d -T 0 FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD.img.xz > >>> 6. dd if=3D/dev/zero of=3Dpflash0.img bs=3D1m count=3D64 > >>> 7. dd if=3D/dev/zero of=3Dpflash1.img bs=3D1m count=3D64 > >>> 8. dd if=3D/usr/local/share/qemu/edk2-arm-code.fd of=3Dpflash0.img co= nv=3Dnotrunc > >>> 9. dd if=3D/usr/local/share/qemu/edk2-arm-vars.fd of=3Dpflash1.img co= nv=3Dnotrunc > >>> 10. cat > start-freebsd-arm.sh > >>> #!/bin/sh > >>> qemu-system-arm \ > >>> -M virt \ > >>> -m 1024 \ > >>> -drive file=3Dpflash0.img,format=3Draw,if=3Dpflash,readonly=3Don \ > >>> -drive file=3Dpflash1.img,format=3Draw,if=3Dpflash \ > >>> -drive file=3D$1.img,if=3Dvirtio,cache=3Dwritethrough \ > >>> -nographic \ > >>> -serial mon:stdio > >>> ^D > >>> 11. chmod +x start-freebsd-arm.sh > >>> 12. ./start-freebsd-arm.sh FreeBSD-14.0-RELEASE-arm-armv7-GENERICSD > >>> > >>> But I hit a snag with this on qemu 8.1.2 and 8.1.3 with both 13.2 and= 140: > >>> > >>> Starting devd. > >>> Starting dhclient. > >>> DHCPDISCOVER on vtnet0 to 255.255.255.255 port 67 interval 7 > >>> Fatal kernel mode data abort: 'Alignment Fault' on read > >>> trapframe: 0xc4b36a60 > >>> FSR=3D00000001, FAR=3Ddd96701a, spsr=3D20000013 > >>> r0 =3D00000000, r1 =3D00000001, r2 =3D00000001, r3 =3Dc4b36b4c > >>> r4 =3D00000014, r5 =3Dd6618800, r6 =3Ddd96702e, r7 =3D0000022c > >>> r8 =3D00000000, r9 =3D0000022c, r10=3Ddd96701a, r11=3Dc4b36b90 > >>> r12=3D4300ffff, ssp=3Dc4b36af0, slr=3Dc04a9728, pc =3Dc04a9750 > >>> > >>> panic: Fatal abort > >>> cpuid =3D 0 > >>> time =3D 1680843057 > >>> KDB: stack backtrace: > >>> #0 0xc035786c at kdb_backtrace+0x48 > >>> #1 0xc02fdd20 at vpanic+0x140 > >>> #2 0xc02fdbe0 at vpanic+0 > >>> #3 0xc06304ac at abort_align+0 > >>> #4 0xc063052c at abort_align+0x80 > >>> #5 0xc063017c at abort_handler+0x480 > >>> #6 0xc060f480 at exception_exit+0 > >>> #7 0xc04a9750 at udp_input+0x288 > >>> #8 0xc0473f54 at ip_input+0x1e0 > >>> #9 0xc04447c0 at netisr_dispatch_src+0xf8 > >>> #10 0xc043bf2c at ether_demux+0x1a4 > >>> #11 0xc043d5e4 at ether_nh_input+0x480 > >>> #12 0xc04447c0 at netisr_dispatch_src+0xf8 > >>> #13 0xc043c404 at ether_input+0x50 > >>> #14 0xc01c0838 at vtnet_rx_vq_process+0x880 > >>> #15 0xc01b70d0 at vtpci_intx_intr+0xac > >>> #16 0xc02b87f0 at ithread_loop+0x2ec > >>> #17 0xc02b465c at fork_exit+0xc0 > >>> Uptime: 19s > >>> > >>> I don't know if this is a problem with qemu or FreeBSD's kernel... > >>> > >>> Warner > >>> > >>> On Tue, Dec 19, 2023 at 3:25=E2=80=AFPM Mario Marietto wrote: > >>>> > >>>> I've asked some help on the channel #arm on Reddit and someone repli= ed : > >>>> > >>>> https://www.reddit.com/r/arm/comments/18mcir8/i_cant_boot_freebsd_fo= r_arm32_bit_as_domu_with/ > >>>> > >>>> Maybe his answer can be useful to understand why it does not work. > >>>> > >>>> On Tue, Dec 19, 2023 at 8:33=E2=80=AFPM Stefano Stabellini wrote: > >>>>> > >>>>> +Michal > >>>>> > >>>>> Hi Mario, > >>>>> > >>>>> I am not sure about booting FreeBSD, but I am certain that u-boot w= orks > >>>>> fine as DomU kernel on ARMv8 (not sure about ARMv7). With this conf= ig > >>>>> file: > >>>>> > >>>>> name=3D"test" > >>>>> kernel=3D"u-boot.bin" > >>>>> extra =3D "console=3Dhvc0" > >>>>> memory=3D256 > >>>>> vcpus=3D1 > >>>>> disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ] > >>>>> > >>>>> I don't know for sure if you can boot FreeBSD but you should defini= tely > >>>>> be able to see the u-boot command line prompt. The fact that you ar= e > >>>>> getting this message: > >>>>> > >>>>> xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader = found: Invalid kernel > >>>>> > >>>>> Means that something is not right in the u-boot configuration or u-= boot > >>>>> build. Michal and Artem (CCed) might know more. From what I recall, > >>>>> there was nothing special required to get u-boot.bin to boot as dom= U > >>>>> kernel, so now I wonder if it is an ARMv7 vs. ARMv8 issue. > >>>>> > >>>>> Cheers, > >>>>> > >>>>> Stefano > >>>>> > >>>>> > >>>>> On Tue, 19 Dec 2023, Mario Marietto wrote: > >>>>>> ....I see that some other interesting files have been produced by = u-boot when I have compiled it : > >>>>>> > >>>>>> u-boot > >>>>>> u-boot.lds > >>>>>> u-boot.bin > >>>>>> u-boot.map > >>>>>> u-boot-nodtb.bin > >>>>>> u-boot.dtb > >>>>>> u-boot.srec > >>>>>> u-boot-dtb.bin > >>>>>> u-boot.sym > >>>>>> > >>>>>> So,maybe I should use a different u-boot* file for booting FreeBSD= ? > >>>>>> > >>>>>> > >>>>>> On Tue, Dec 19, 2023 at 4:28=E2=80=AFPM Mario Marietto wrote: > >>>>>> Hello to everyone. > >>>>>> > >>>>>> I have compiled the needed u-boot.bin from scratch using this proc= edure : > >>>>>> > >>>>>> # git clone https://github.com/u-boot/u-boot.git > >>>>>> # cd u-boot > >>>>>> # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make snow_defcon= fig : this line generates the file .config > >>>>>> # nano .config and I've added these parameters : > >>>>>> > >>>>>> CONFIG_ARMV7_NONSEC=3Dn > >>>>>> CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy > >>>>>> > >>>>>> the uboot-bin file is generated with this command : > >>>>>> > >>>>>> # ARCH=3Darm CROSS_COMPILE=3Darm-linux-gnueabihf- make > >>>>>> > >>>>>> At this point,I took a look inside the .config file and I saw that= the parameter "CONFIG_ARMV7_NONSEC=3Dn" has been removed. So,for > >>>>>> some reason,it is not accepted and this could be a problem.... > >>>>>> > >>>>>> These are the xen config files that I've used : > >>>>>> > >>>>>> nano freebsd.cfg > >>>>>> > >>>>>> name=3D"test" > >>>>>> kernel=3D"u-boot.bin" > >>>>>> extra =3D "console=3Dhvc0" > >>>>>> memory=3D256 > >>>>>> vcpus=3D1 > >>>>>> disk =3D [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ] > >>>>>> > >>>>>> nano start-freebsd > >>>>>> > >>>>>> xl create freebsd.cfg > >>>>>> xl console freebsd > >>>>>> > >>>>>> This is what happens when I launch the vm : > >>>>>> > >>>>>> # ./start-freebsd > >>>>>> > >>>>>> Parsing config from freebsd.cfg > >>>>>> xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader= found: Invalid kernel > >>>>>> libxl: error: libxl_dom.c:571:libxl__build_dom: xc_dom_parse_image= failed > >>>>>> libxl: error: libxl_create.c:1640:domcreate_rebuild_done: Domain 1= :cannot (re-)build domain: -3 > >>>>>> libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 1:N= on-existent domain > >>>>>> libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain = 1:Unable to destroy guest > >>>>>> libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Dest= ruction of domain failed > >>>>>> freebsd is an invalid domain identifier (rc=3D-6) > >>>>>> > >>>>>> > >>>>>> On Mon, Dec 18, 2023 at 12:39=E2=80=AFPM Mario Marietto wrote: > >>>>>> So,ok,I should have said "the second u-boot" ; since the fi= rst u-boot binary is the "u-boot binary located in the RO > >>>>>> memory" of the Chromebook". Sorry for the confusion. > >>>>>> > >>>>>> On Mon, Dec 18, 2023 at 12:35=E2=80=AFPM Mario Marietto wrote: > >>>>>> ---> There are no specific options in u-boot devoted to Fre= eBSD > >>>>>> > >>>>>> This is an important factor. So,what about if,instead of compiling= a new version of u-boot on the partition 2,I will > >>>>>> recompile the u-boot customized version created by the virtual ope= n system in 2014,that should be installed on the first > >>>>>> partition ? It could work if there are no differences between the = u-boot that should boot Linux and the u-boot that > >>>>>> should boot FreeBSD. > >>>>>> > >>>>>> Can you give a look at the u-boot source code created by virtual o= pen systems ? You can find it on my google drive : > >>>>>> > >>>>>> https://drive.google.com/file/d/1eAaZMfd6CU0xiqQfH7sq5wGVzzO09BRm/= view?usp=3Dsharing > >>>>>> > >>>>>> I need to understand if I can recompile it without problem so that= it can satisfy my needs (the ability of the file > >>>>>> u-boot.bin to boot FreeBSD as domU under Xen,as explained by Stefa= no Stabellini,the xen developer that suggested to me > >>>>>> what I could do to have FreeBSD virtualized under Xen on my Arm Ch= romebook) ; otherwise the risk is to find later > >>>>>> problems that will make me troubles and that I will not able to fi= x. > >>>>>> > >>>>>> I gave a look at the virtual open system u-boot and I didn't see a= ny arndale_defconfig inside. So,If I have understood > >>>>>> correctly,I should put that file inside the root of the u-boot sou= rce code,let's say here : > >>>>>> > >>>>>> marietto:/home/marietto/Desktop/Files/u-boot_FreeBSD/u-boot-vos # = ls > >>>>>> > >>>>>> .checkpatch.conf README doc = net > >>>>>> .git api drivers = onenand_ipl > >>>>>> .gitignore arch dts = post > >>>>>> COPYING board examples = rules.mk > >>>>>> CREDITS boards.cfg fs = scripts > >>>>>> MAINTAINERS common include = snapshot.commit > >>>>>> MAKEALL config.mk lib = spl > >>>>>> Makefile cros mkconfig = test > >>>>>> PRESUBMIT.cfg disk nand_spl = tools > >>>>>> > >>>>>> and I should do : make and make install ? and the file I need,u-bo= otbin will be generated ? > >>>>>> > >>>>>> I didn't find any pre made configuration file inside : > >>>>>> > >>>>>> u-boot-vos # find . -type f -name "exynos*" > >>>>>> > >>>>>> ./include/exynos-fb.h > >>>>>> ./include/configs/exynos5-common.h > >>>>>> ./doc/device-tree-bindings/spi/exynos-spi.txt > >>>>>> ./doc/device-tree-bindings/usb/exynos-usb.txt > >>>>>> ./drivers/power/exynos-tmu.c > >>>>>> ./drivers/power/exynos-cpufreq.c > >>>>>> ./drivers/video/exynos-fb.c > >>>>>> ./drivers/spi/exynos_spi.c > >>>>>> ./board/samsung/dts/exynos5250-spring.dts > >>>>>> ./board/samsung/dts/exynos5250-smdk5250.dts > >>>>>> ./board/samsung/dts/exynos5250-snow.dts > >>>>>> ./board/samsung/dts/exynos5250-daisy.dts > >>>>>> ./arch/arm/include/asm/arch-exynos5/exynos-cpufreq.h > >>>>>> ./arch/arm/include/asm/arch-exynos5/exynos-tmu.h > >>>>>> ./arch/arm/dts/exynos5250.dtsi > >>>>>> ./arch/arm/dts/exynos-periph-id.dtsi > >>>>>> ./arch/arm/cpu/armv7/exynos5/exynos_cache.c > >>>>>> > >>>>>> u-boot-vos # find . -type f -name "arndale*" > >>>>>> > >>>>>> For sure I can't use a newer version of u-boot because otherwise t= he patches needed to bypass the bootloader protections > >>>>>> of the Arm Chromebook (such as a lot of different patches needed t= o boot correctly Linux) will be broken ; anyway,since > >>>>>> it works,I don't need to use an updated version of u-boot. > >>>>>> > >>>>>> ----> As per my experience, you have to respect these two options,= compiling u-boot for > >>>>>> FreeBSD: https://github.com/freebsd/freebsd-ports/blob/main/sysuti= ls/u-boot-master/files/FreeBSD_Fragment > >>>>>> > >>>>>> It says that I should use these parameters : > >>>>>> > >>>>>> CONFIG_ARMV7_NONSEC=3Dn > >>>>>> CONFIG_EFI_GRUB_ARM32_WORKAROUND=3Dy > >>>>>> > >>>>>> These are the parameters used to configure a Linux kernel. I don't= understand what's the relation between the compilation > >>>>>> of a linux kernel and u-boot. In the past I tried to recompile u-b= oot,but I didn't have the need to set up those > >>>>>> parameters,so I don't know how to do it (but I know how to recompi= le a Linux kernel). > >>>>>> > >>>>>> ---> I'm not sure that I'm getting you right, as I don't understan= d what you mean under "the first u-boot". > >>>>>> > >>>>>> > >>>>>> I'm talking about first u-boot because the whole procedure to boot= Linux on the ARM Chromebook,that's explained here : > >>>>>> > >>>>>> http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chrom= ebook/ > >>>>>> > >>>>>> > >>>>>> at some point they say : > >>>>>> > >>>>>> > >>>>>> To be able to run KVM on ARM platforms, the kernel has to be boote= d in hypervisor mode. Because of this relatively recent > >>>>>> requirement (due to the introduction of the virtualization extensi= ons), up until now all booting methods would boot the > >>>>>> kernel in the standard Supervisor mode. > >>>>>> > >>>>>> For the ARM Chromebook the default boot procedure doesn't allow us= to boot in hypervisor mode. Although the laptop's boot > >>>>>> mechanism is based on the frequently used u-boot, the binary is lo= cated in RO memory. Fortunately, a chained u-boot > >>>>>> mechanism can be used (i.e. starting another u-boot after the orig= inal). We can then enter hypervisor mode from our > >>>>>> custom iteration of u-boot and subsequently load our kernel and us= erspace. > >>>>>> > >>>>>> So,the first u-boot is the u-boot provided by virtual open systems= ,that's able to chainload the "u-boot binary located in > >>>>>> RO memory" , that does not boot Chrome OS in hypervisor mode. We d= on't need it if we want to boot Linux with kvm or xen > >>>>>> enabled. > >>>>>> > >>>>>> > >>>>>> On Sun, Dec 17, 2023 at 1:28=E2=80=AFAM Stanislav Silnicki wrote: > >>>>>> I'm not an expert in the topic, I only know, that ARM has d= ivided hardware into two worlds - Secure and > >>>>>> Not-So, strictly limiting any software, running in non-secu= re world with access to functions and > >>>>>> resources. https://developer.arm.com/documentation/den0013/= d/Security/TrustZone-hardware-architecture?lang=3Den > >>>>>> > >>>>>> I'm not sure, that I'm getting you right, as I don't understand wh= at you mean under "the first u-boot". > >>>>>> > >>>>>> As I understand, virtualization (HYP) is running in non-secure wor= ld(https://developer.arm.com/documentation/ddi0406/c/System-Level-Architect= ure/The-System-Level-Programmers--Model/The-Virtualization-Extens > >>>>>> ions), so my guess (only guess!!!), virtualization software has to= prepare (configure) HW platform in the way, > >>>>>> that FreeBSD kernel will not lack any resources, required to confi= gure MPU, VA, etc. > >>>>>> So, if you lucky to boot virtualizer, which is aware of target OS,= that maybe you can boot the kernel. Although, I > >>>>>> doubt, that you need to boot 'second' u-boot to boot the kernel - = there is simply ubldr, which you can hook somehow > >>>>>> from virtualizer.... > >>>>>> > >>>>>> Stan > >>>>>> > >>>>>> > >>>>>> > >>>>>> Mario Marietto wrote: > >>>>>> > >>>>>> > >>>>>> ---> As I understand, it makes sure that u-boot keeps in se= cure mode during boot and passes control to > >>>>>> ubldr, which boots FreeBSD kernel, in that mode. > >>>>>> > >>>>>> Can you elaborate your sentence more ? I know that the bootloader = secure mode is bypassed by the virtual open > >>>>>> systems u-boot. Are you saying that when the control passes to the= second u-boot,it will happen in secure > >>>>>> mode,so that the bypass that happened loading the first u-boot,is = annulled ? If this is true,maybe can I boot > >>>>>> FreeBSD using the virtual-open-system custom u-boot ? Is this comp= atible with FreeBSD ? Where can I find the > >>>>>> u-boot.bin that the xen developer talked about ? thanks bro'. > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Sun, Dec 17, 2023 at 12:35=E2=80=AFAM Stanislav Silnicki wrote: > >>>>>> Hi Mario, > >>>>>> > >>>>>> U-Boot beast is hiding in this den: https://source.denx.de/u-boot= /u-boot.git > >>>>>> I took a brief look at your post and it seems to me, that option C= ONFIG_CMO_BY_VA_ONLY is irrelevant to > >>>>>> your target armv7 32 bit > >>>>>> platform: https://source.denx.de/u-boot/u-boot/-/blob/master/arch/= arm/cpu/armv8/Kconfig?ref_type=3Dheads#L3 > >>>>>> > >>>>>> As for compiling the u-boot, it is a doable task, given that you u= nderstand what you are doing. There > >>>>>> are no specific options in u-boot devoted to FreeBSD. It is a boot= loader, whose mission to make basic > >>>>>> hardware initialization, read you kernel file from some media into= RAM and then pass it control. > >>>>>> > >>>>>> Basically, you can grab some defconfig, prepared for any other Exy= nos5250 based board (say, this one: > >>>>>> https://source.denx.de/u-boot/u-boot/-/blob/master/configs/arndale= _defconfig?ref_type=3Dheads) and adopt > >>>>>> it somehow. > >>>>>> > >>>>>> As per my experience, you have to respect these two options, compi= ling u-boot for > >>>>>> FreeBSD: https://github.com/freebsd/freebsd-ports/blob/main/sysuti= ls/u-boot-master/files/FreeBSD_Fragment > >>>>>> > >>>>>> As I understand, it makes sure, that u-boot keeps in secure mode d= uring boot and passes control to > >>>>>> ubldr, which boots FreBSD kernel, in that mode. Otherwise, there a= lot of surprises you may realize. > >>>>>> > >>>>>> Hope, this will help to progress you tasks > >>>>>> Stan > >>>>>> > >>>>>> Mario Marietto wrote: > >>>>>> > >>>>>> > >>>>>> Hello. > >>>>>> > >>>>>> I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM = Chromebook. Basically there are > >>>>>> two ways to accomplish this task : > >>>>>> > >>>>>> 1) to write a patch that allows the FreeBSD kernel to boot = as a zImage file. This could be > >>>>>> accomplished applying this patch to a specific file that's = on the source code of FreeBSD : > >>>>>> > >>>>>> > >>>>>> https://xenbits.xen.org/gitweb/?p=3Dp...8;hb=3D0782e25d98cc= 1391472717035f986c979edef0c9 > >>>>>> > >>>>>> > >>>>>> This patch was written by Julien Grall a lot of time ago an= d now it does not work anymore. > >>>>>> This is the reason : > >>>>>> > >>>>>> > >>>>>> It appears FreeBSD-CURRENT removed the last step conv= erting the kernel file to > >>>>>> kernel.bin. The patch can be readily rebased, but wit= hout kernel.bin that > >>>>>> doesn't do too much > >>>>>> > >>>>>> > >>>>>> > >>>>>> So,without a rebase of that patch the first option is not applicab= le And I'm not able to fix it. > >>>>>> > >>>>>> 2) booting FreeBSD using U-Boot,as explained to me by a xen develo= per : > >>>>>> > >>>>>> > >>>>>> I was trying to explain why and how Julien's patch works so= that you could be the one > >>>>>> to re-do something similar or fix the patch on the FreeBSD = kernel that you are > >>>>>> working with. I am happy to help review and write patches b= ut I don't work with the > >>>>>> FreeBSD kernel so I wouldn't be able to help you quickly. H= owever, I might have a > >>>>>> suggestion. Do you know if FreeBSD can be booted by U-Boot = ? Because U-Boot > >>>>>> definitely boots as Xen on ARM guest firmware/bootloader. Y= ou should be able to build > >>>>>> U-Boot and use the U-Boot binary as Xen guest kernel, then = U-Boot could load FreeBSD > >>>>>> from disk or network and start it. For instance as domU con= fig file: > >>>>>> > >>>>>> kernel=3D"/home/petalinux/u-boot.bin" > >>>>>> disk =3D [ '/home/petalinux/test.img,raw,xvda' ] > >>>>>> > >>>>>> I know it is important to build u-boot with the following c= onfig to make it work on > >>>>>> Xen. > >>>>>> > >>>>>> CONFIG_CMO_BY_VA_ONLY=3Dy > >>>>>> > >>>>>> > >>>>>> > >>>>>> This option seems more doable to me according to my knowledge. But= I need to understand how to do > >>>>>> it. > >>>>>> > >>>>>> Well,let's say that on the ARM Chromebook I'm forced to use and in= stall a customized version of > >>>>>> u-boot,created by virtual open systems,because it is the only one = that allows bypassing its > >>>>>> bootloader protection. You can find more information here : > >>>>>> > >>>>>> http://www.virtualopensystems.com/en/solutions/guides/kvm-on-chrom= ebook/?vos=3Dtech > >>>>>> > >>>>>> This is the relevant section to read : > >>>>>> > >>>>>> > >>>>>> Bootloader : > >>>>>> > >>>>>> If you wish to skip this chapter you can download a pre-com= piled binary of the > >>>>>> bootloader: > >>>>>> > >>>>>> > >>>>>> $ wget > >>>>>> http://www.virtualopensystems.com/downloads/guides/kvm_on_c= hromebook/nv_u-boot-snow.kpart > >>>>>> > >>>>>> > >>>>>> To be able to run KVM on ARM platforms, the kernel has to b= e booted in hypervisor > >>>>>> mode. Because of this relatively recent requirement (due to= the introduction of the > >>>>>> virtualization extensions), up until now all booting method= s would boot the kernel in > >>>>>> the standard Supervisor mode. For the ARM Chromebook the de= fault boot procedure > >>>>>> doesn't allow us to boot in hypervisor mode. Although the l= aptop's boot mechanism is > >>>>>> based on the frequently used u-boot, the binary is located = in RO memory. Fortunately, > >>>>>> a chained u-boot mechanism can be used (i.e. starting anoth= er u-boot after the > >>>>>> original). We can then enter hypervisor mode from our custo= m iteration of u-boot and > >>>>>> subsequently load our kernel and userspace. > >>>>>> > >>>>>> Checkout the needed u-boot code : > >>>>>> > >>>>>> > >>>>>> $ git clone git://github.com/virtualopensystems/u-boot.git$= cd u-boot$ > >>>>>> ./scripts/build.sh > >>>>>> > >>>>>> > >>>>>> If successful, a message about how to copy the bootloader o= n the USB flash disk or SD > >>>>>> card will appear. We will use it later when preparing the b= oot medium to start our > >>>>>> system. If you have followed the Setting up the boot medium= chapter and you have a > >>>>>> prepared boot device, then you can update u-boot by running= : > >>>>>> > >>>>>> > >>>>>> $ sudo dd if=3Dnv_uboot-snow.kpart of=3D/dev/sdX1 > >>>>>> > >>>>>> > >>>>>> > >>>>>> so,the needed u-boot that we must use should be installed on the f= irst partition of the sd card. > >>>>>> > >>>>>> There is another relevant section to read : > >>>>>> > >>>>>> > >>>>>> Setting up the boot medium > >>>>>> > >>>>>> Now it is time to copy all the relevant files that we creat= ed in the previous > >>>>>> chapters,and use them to boot Chromebook with a different k= ernel and OS. In all these > >>>>>> examples the device /dev/sdX is used. Take extra care to ch= ange the examples to the > >>>>>> device that you have attached. Insert the boot medium on yo= ur workstation and > >>>>>> carefully execute the following step. First we need to prop= erly format the boot > >>>>>> medium. > >>>>>> > >>>>>> In the uboot source directory : > >>>>>> > >>>>>> > >>>>>> $ sudo ./scripts/sdcard.sh /dev/sdX > >>>>>> > >>>>>> > >>>>>> This will erase all data and create 4 partitions in the med= ium, along with copying > >>>>>> the u-boot binary to the first partition: > >>>>>> > >>>>>> > >>>>>> Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boo= t) > >>>>>> Partition 2 =3D not used > >>>>>> Partition 3 =3D EXT2 partition for u-boot files (uImage and= exynos5250-snow.dtb) > >>>>>> Partition 4 =3D EXT4 partition for userspace files > >>>>>> > >>>>>> > >>>>>> With u-boot being copied, next is the kernel image and DTB = file. From the kernel > >>>>>> source execute : > >>>>>> > >>>>>> > >>>>>> $ mkdir ../mnt/ > >>>>>> $ sudo mount /dev/sdX3 ../mnt/ > >>>>>> $ sudo cp arch/arm/boot/uImage ../mnt/ > >>>>>> $ sudo cp arch/arm/boot/dts/exynos5250-snow.dtb ../mnt/ > >>>>>> $ sudo umount /dev/sdX3 > >>>>>> > >>>>>> > >>>>>> Finally, we have to copy the Ubuntu userspace filesystem th= at we created earlier: > >>>>>> > >>>>>> > >>>>>> $ sudo mount /dev/sdX4 mnt/$ sudo cp -a ./precise/* mnt/$ s= udo umount /dev/sdX4 > >>>>>> > >>>>>> > >>>>>> > >>>>>> Now,my idea is to chainload the already chain loaded u-boot create= d by V.O.S to the new u-boot > >>>>>> that we need for booting FreeBSD and that can be installed in the = partition n.2,as shown in this > >>>>>> scheme,because it is not used : > >>>>>> > >>>>>> > >>>>>> Partition 1 =3D ChromeOS signed binary (V.O.S chained u-boot) > >>>>>> Partition 2 =3D not used (maybe we can install the u-boot for arm = 32 bit,compatible with FreeBSD on > >>>>>> this partition) > >>>>>> Partition 3 =3D EXT2 partition for u-boot files (uImage and exynos= 5250-snow.dtb) > >>>>>> Partition 4 =3D EXT4 partition for userspace files > >>>>>> > >>>>>> > >>>>>> Take in consideration that default boot string is hardcoded here,i= n the snow.h file of the custom > >>>>>> u-boot created by VOS : > >>>>>> > >>>>>> > >>>>>> https://github.com/virtualopensyste...18a39b6c177dff58a/include/co= nfigs/snow.h#L101 > >>>>>> > >>>>>> > >>>>>> and it needs to be recompiled because it should point to the parti= tion n.2,where I will install > >>>>>> the u-boot files as explained here : > >>>>>> > >>>>>> > >>>>>> https://wiki.freebsd.org/arm/Chromebook > >>>>>> > >>>>>> > >>>>>> I have some questions to ask before I start working on this. > >>>>>> > >>>>>> 1) The xen developer said : > >>>>>> > >>>>>> > >>>>>> You should be able to build U-Boot and use the U-Boot binar= y as Xen guest kernel... > >>>>>> > >>>>>> > >>>>>> > >>>>>> where is the u-boot binary,according to this document ? > >>>>>> > >>>>>> https://wiki.freebsd.org/arm/Chromebook > >>>>>> > >>>>>> I don't see it. > >>>>>> > >>>>>> > >>>>>> 2) where is the source code of the file that I can get here : > >>>>>> > >>>>>> http://commondatastorage.googleapis.com/chromeos-localmirror/distf= iles/nv_uboot-snow-simplefb.kpart.bz2 > >>>>>> > >>>>>> I need the source code if I want to recompile u-boot so that it ca= n point to the partition 4. > >>>>>> > >>>>>> Maybe it can be found on this link : > >>>>>> > >>>>>> http://linux-exynos.org/dist/chromebook/nv_uboot/ > >>>>>> > >>>>>> but it can't be opened.... > >>>>>> > >>>>>> > >>>>>> 3) in this specific scenario the source code of u-boot should run = on arm 32 bit,not on arm > >>>>>> 64,because I have the Samsung Chromebook "SNOW" model XE303C12,tha= t's powered by a Samsung Exynos > >>>>>> 5250 (ARMv7 32 bit Cortex A15) Soc. > >>>>>> > >>>>>> > >>>>>> 4) I'm not sure if I can chainload the customized u-boot created b= y V.O.S that should be > >>>>>> installed on the first partition with the u-boot tailored for boot= ing FreeBSD that should be > >>>>>> installed on the partition 2.... > >>>>>> > >>>>>> > >>>>>> 5) the xen developer said that u-boot should be compiled enabling = this option : > >>>>>> > >>>>>> > >>>>>> Code: > >>>>>> > >>>>>> CONFIG_CMO_BY_VA_ONLY=3Dy > >>>>>> > >>>>>> > >>>>>> Well,can you provide some good source that can help me to understa= nd how I can recompile u-boot > >>>>>> for FreeBSD ? thanks. > >>>>>> > >>>>>> -- > >>>>>> Mario. > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Mario. > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Mario. > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Mario. > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Mario. > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Mario. > >>>>>> > >>>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Mario. > >> > >> > >> > >> -- > >> Mario. > > > > > > > > -- > > Mario. > > > > -- > Julien Grall --=20 Mario. From nobody Sat Dec 30 16:42:57 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T2SjY4tpnz55Zhx for ; Sat, 30 Dec 2023 16:43:13 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4T2SjX43jcz4Cmn for ; Sat, 30 Dec 2023 16:43:12 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=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; dmarc=none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 3BUGgwAZ049226 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 30 Dec 2023 08:42:58 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 3BUGgvOr049225; Sat, 30 Dec 2023 08:42:57 -0800 (PST) (envelope-from fbsd) Date: Sat, 30 Dec 2023 08:42:57 -0800 From: bob prohaska To: Mark Millard Cc: John F Carr , ticso@cicely.de, Marcin Cieslak , freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed Message-ID: References: List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spamd-Result: default: False [-1.10 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; AUTH_NA(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_RHS_WWW(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; FREEMAIL_TO(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[zefox.net]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[] X-Rspamd-Queue-Id: 4T2SjX43jcz4Cmn X-Spamd-Bar: - On Thu, Dec 28, 2023 at 07:40:30PM -0800, Mark Millard wrote: > > Use of the mini-uart is probably not a good idea for the serial console: dtoverlay=disable-bt should also be listed, like for the other RPi3B* . That makes perfect sense, especially in concert with use of powerd on www.zefox.org, the serial console being monitored. I switched the console back to the PL011, but left powerd active. About six hours later the ssh session from workstation to terminal server dropped again. After restoring the ssh session from workstation to pelorus (the terminal server) and starting tip through the usb-serial adapter www.zefox.org's console login prompt came up. It still contained a flurry of what looked like garbage characters (a few printable) at the start but they were replaced by a clean login prompt that worked correctly. That was a surprise. Next I turned off powerd on www.zefox.org, rebooted and confirmed both a PL011 console and no powerd running. Brought up the ssh link to pelorus (terminal server) and tip through the usb-serial adapter to www.zefox.org's console. Next the connection to the terminal server dropped again, this time prematurely, as I disturbed the network. It was re-started next morning in the usual way and tip was resumed to www.zefox.org's console. It came up exactly as usual: # tip ucom Stale lock on cuaU0 PID=8335... overriding. connected FreeBSD/arm64 (www.zefox.org) (ttyu0) login: �}�ɽѽ �����������͕ŁɁm�ɕ��ѡu5)5)^Q���������������݁�͡�m����u違�ɽ��^Y�͡}���}�ɽѽ���}��ɽ����������͕Ł́m�ɕ��ѡu5)5)^Q������������݁��݁�͡�m����u遙�х��Q�����с����ɕ���ѡ��ѥ��ѥ�����Ɂ��ݹ�5)�Password: Login incorrect login: Login timed out after 300 seconds Dec 30 07:55:32 www login[1072]: 1 LOGIN FAILURE ON ttyu0 FreeBSD/arm64 (www.zefox.org) (ttyu0) Login: It really looks as if the garbage somehow got into the data stream _from_ the terminal server _to_ the console. > > In fact, other than the force_mac_address, the general content should be like the one with arm_64bit=1 as far as I can tell. Do you have specific reasons for needing any of the differences? > Certainly not that difference, arm_64bit=1 has been restored. No obvious effect so far. It appears that www.zefox.org was set up in June of 2020, the discrepancies are likely due to age and inept administration Might the trouble be the terminal server Pi3? It's running FreeBSD pelorus 14.0-RELEASE-p4 FreeBSD 14.0-RELEASE-p4 #0 releng/14.0-n265400-4edf3b80733e: Wed Dec 27 20:21:26 PST 2023 bob@pelorus:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 The usb serial bridge reports as ugen1.6: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (90mA) [mention of limited Net access noted] Thanks _very_ much for your help and to anyone following this thread. bob prohaska From nobody Sat Dec 30 19:05:32 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T2Wt72T0Fz55psS for ; Sat, 30 Dec 2023 19:05:51 +0000 (UTC) (envelope-from saper@saper.info) Received: from q.saper.info (q.saper.info [IPv6:2605:2700:0:2:a800:ff:fec7:5c61]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "q.saper.info", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T2Wt63V3nz4Qnk for ; Sat, 30 Dec 2023 19:05:50 +0000 (UTC) (envelope-from saper@saper.info) Authentication-Results: mx1.freebsd.org; none Received: from q.saper.info (localhost [127.0.0.1]) by q.saper.info (8.17.1/8.17.1) with ESMTPS id 3BUJ5XQH089372 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 30 Dec 2023 19:05:33 GMT (envelope-from saper@saper.info) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=saper.info; s=Sep2014; t=1703963133; bh=Sv83EZoXhIqvYU7I8w8Izub/1ONPMpu4gBfUysp22DI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=OVk7uor+hjMBXmuSdjJ+Lp01SUJvrvWxptmza6Z5iLMEvMxrbKVHZfMSPYSCQyVQK rcjPua4Hg39m6NnPEnbsmKKLyjZk+SFp2jv2Y/RRxqza3ZsZkQ4tCao+DthSMqw7t6 DztAY5tMEWGwoC77clmN69tmxFVv3whVj90AtMS0= Received: from localhost (saper@localhost) by q.saper.info (8.17.1/8.17.1/Submit) with ESMTP id 3BUJ5Wtc089369; Sat, 30 Dec 2023 19:05:32 GMT (envelope-from saper@saper.info) X-Authentication-Warning: q.saper.info: saper owned process doing -bs Date: Sat, 30 Dec 2023 19:05:32 +0000 From: Marcin Cieslak To: bob prohaska cc: Mark Millard , John F Carr , ticso@cicely.de, freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed In-Reply-To: Message-ID: <9o7q7p36-o7pn-27o9-62no-8p1r6o127123@fncre.vasb> References: List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="2201072851-731748755-1703963133=:2993" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:47066, ipnet:2605:2700::/32, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4T2Wt63V3nz4Qnk --2201072851-731748755-1703963133=:2993 Content-Type: text/plain; charset=US-ASCII; format=flowed Bob, are you running with the default /etc/ttys ? If yes, can you please edit /etc/ttys on the serial port side as follows (as root) # ed /etc/ttys 2216 /ttyu0 ttyu0 "/usr/libexec/getty 3wire" vt100 onifconsole secure .s/3wire/3wire.9600/ . ttyu0 "/usr/libexec/getty 3wire.9600" vt100 onifconsole secure w q --2201072851-731748755-1703963133=:2993 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIOdgYJKoZIhvcNAQcCoIIOZzCCDmMCAQExDzANBglghkgBZQMEAgEFADAL BgkqhkiG9w0BBwGgggq9MIIEvDCCA6SgAwIBAgIQeEqpEhjRpCYIUTzTZlVD ozANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQLExdHbG9iYWxTaWduIFJvb3Qg Q0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMKR2xvYmFs U2lnbjAeFw0yMDA5MTYwMDAwMDBaFw0yOTAzMTgwMDAwMDBaMFsxCzAJBgNV BAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTEwLwYDVQQDEyhH bG9iYWxTaWduIEdDQyBSMyBQZXJzb25hbFNpZ24gMSBDQSAyMDIwMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvxvJBqEapaux2/z3J7fFslRO WjKVJ5rCMfWGsg17dmD7NSnG7Spoa8d3htXsls1IMxoO8PyouQajNQqYmlYo xinlqenMNv7CJyEKMOAtglBmD6C/QC7kT+dSx4HfSTs8xmv8veJOldMzF8S/ BEn/tD4w/Dvpg+oXOqDyOiHPTacRFK0QHoq5eEbBmVS8W0rwcaRotO9fGTA+ NjF0My7GLRNK0eMPGh2hcPZURQhXy7wRQ8XFIfEA6kaQHHN22ncnVtwqiTmA wTR+4GNNVinG3KjNZLAVSnGrdCvT2I4Zo19hKy5PX6o7wrVXvMR4zV5VBFwV 6ZDM+xewao7Mup+SbwIDAQABo4IBiTCCAYUwDgYDVR0PAQH/BAQDAgGGMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/ AgEAMB0GA1UdDgQWBBSFu/DMxDa1CmJ2o5kuj7s6aq3FUTAfBgNVHSMEGDAW gBSP8Et/qC5FJK5NUPpjmove4t0bvDB6BggrBgEFBQcBAQRuMGwwLQYIKwYB BQUHMAGGIWh0dHA6Ly9vY3NwLmdsb2JhbHNpZ24uY29tL3Jvb3RyMzA7Bggr BgEFBQcwAoYvaHR0cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQv cm9vdC1yMy5jcnQwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9i YWxzaWduLmNvbS9yb290LXIzLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIB KDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9y ZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEAWWtqju12g524FdD2HwUX U1rSxeM5aSU1cUC1V/xBjXW0IjA7/3/vG2cietPPP/g3lpoQePVJpQAKZml8 1fHwPPivFK9Ja41jJkgqGzkORSC0xYkh2gGeQg1JVaCzcrRzJElRjT442m6F pbLHCebxIHLu0WBNjLZreB6MYMaqdPL6ItbXtD/BU4k517cEuUbczoBFZAra jq7oUBWXuroln5AMnRwVNwgJN4Np0s4kkJ94KepzbFOLzcbnfUB0+xT4foXm bM0GmmcPGOy0qvqEHJsBwDZXDxIk8oqCnnLngi7N94Sn4eTcmpZ9NH2dDN1O TEPVXgRG5X1pBcNtMWG6MDCCBfkwggThoAMCAQICDCKqoJRMYYx5sYJHGzAN BgkqhkiG9w0BAQsFADBbMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFs U2lnbiBudi1zYTExMC8GA1UEAxMoR2xvYmFsU2lnbiBHQ0MgUjMgUGVyc29u YWxTaWduIDEgQ0EgMjAyMDAeFw0yMzAzMDcxNjExMDlaFw0yNjAzMDcxNjEx MDlaMDwxGTAXBgNVBAMMEHNhcGVyQHNhcGVyLmluZm8xHzAdBgkqhkiG9w0B CQEWEHNhcGVyQHNhcGVyLmluZm8wggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAw ggIKAoICAQC8MB3fTYVrTadH5qE2CIa4VLvlL6QHgDriMRLkTA49SPszYCO0 fZTEpdSw8fc6kK9p2fD63LAfOHeD7jzey5aHBzpIGlxeFkn0Ce2BCYY5yLxK i9byoCwrpLchTR1Itpk1w+zy5E4T9KBTL1+c+w+TKpaIvFLXtjZtz4wQGi0p e/nRkRK9htGG3mETh+APitedl+ImGaI8NK9PELxuSkXnYAvGPpnXir8vbszk tJU1b0TevL/i3Sy6fhOhunZmTo1QDM7Zw4UyVjkQgTvL3y4I0tIrVjlam08x XZeMp+i/Gl51eHGvRVfvdJUJAjrWhrFEp8+2FZouWxWzAlHdd2sRp1AekNdP CeRgHeIF6uNtSseL1grKAjU+4BiixWPp1y1niB0humoQHoub/6fO/mU+//rW l3gTwZNu4FuKgZlfPw+qnvuka0c9dUNIZRCE5z8yXjS8R9yZWirnHNhYxf/e R2y4jaiHzPAjZlZZ2rGx8xVfB2n2JsAicj2+ZxmXlQ1yd5RW1pfxG3cdNNC5 uZ+j4JIN2ElsIjEKmMn9gHdoaEMAy/ENwNiMDBadLnc8qWirq/Ktp2dBSf2y /sH9xMpVyk8wuYjpbCnX4xslAensno5A20MYdKGPRFaItEhNPNbfzc1+4br8 exoXFX1F9ZJK9gGUO2nLbdRycphdyzxzgQIDAQABo4IB2jCCAdYwDgYDVR0P AQH/BAQDAgWgMIGjBggrBgEFBQcBAQSBljCBkzBOBggrBgEFBQcwAoZCaHR0 cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvZ3NnY2NyM3BlcnNv bmFsc2lnbjFjYTIwMjAuY3J0MEEGCCsGAQUFBzABhjVodHRwOi8vb2NzcC5n bG9iYWxzaWduLmNvbS9nc2djY3IzcGVyc29uYWxzaWduMWNhMjAyMDBMBgNV HSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3 dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAJBgNVHRMEAjAAMEkGA1Ud HwRCMEAwPqA8oDqGOGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NnY2Ny M3BlcnNvbmFsc2lnbjFjYTIwMjAuY3JsMBsGA1UdEQQUMBKBEHNhcGVyQHNh cGVyLmluZm8wHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB8GA1Ud IwQYMBaAFIW78MzENrUKYnajmS6PuzpqrcVRMB0GA1UdDgQWBBTW/RrdlRFR y6MgS7liTThMnQA5ozANBgkqhkiG9w0BAQsFAAOCAQEAAwoUJShHMueocVlD 1+vYJbTTTbk9tabr2L4Iyyy4Btu1d1wwl6d9Yx2N9qaVERWcEeP0aR+NB2B7 xIKl/ZnZVuSxep0Raw4s284a/jSIJlsAi4SJItDCU2VrYJDWxP7MxzZHnzPI MLDoTHXPV18gvYTewoNk5/Yo89Kb0v/GpPTpP2sVdrWLHa4uKUHYrAZ0aByp kNw6lXp6o6DXvXaOd6KDTQN5XhmmHwLnuLceODF1t9gicsZIOY+KAxN6YZ6t EqwN48b4OFMpckDE3fm1iTZRqnEIqUHOKOcoCImkub1woEN0zXDQmLXaZigl uVztWSTM4/fapWLrlHBNxfjs1TGCA30wggN5AgEBMGswWzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExMTAvBgNVBAMTKEdsb2Jh bFNpZ24gR0NDIFIzIFBlcnNvbmFsU2lnbiAxIENBIDIwMjACDCKqoJRMYYx5 sYJHGzANBglghkgBZQMEAgEFAKCB5DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0yMzEyMzAxOTA1MzJaMC8GCSqGSIb3DQEJ BDEiBCB7E0yNxsjeOsFs7ed9fKz13VY2uuOKUNOPCgiy9fHYHzB5BgkqhkiG 9w0BCQ8xbDBqMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUD BAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAgCD H1bEF4xQbbKGcoHm0FHoGO/iEPr6N5+xUsD/dBZWlHxEZSp/CLyg7emmHj1b 0+3FRaJCymJqRG95DZxWFtlF/YCv3hxwCsbaCT8/nsWQcIMzwV5c3Jez0FHJ QjE5i0L6s7xyALaHiCMxJqCRSp1Q1VfM+wZK6sKDn+5kKTlv3vV2s1U09/Sn /NVHOgHGSV9gNvVkth5ioRK3dxwJeL6JKOPXUsokXUQhS+/PlmCR3ZNnRKuL aV/d5UKfo0b8ZvJeCoqaV9bCjFgxEgcdRJ+sul4pEIhVx2qasP8+yu4856B7 ZEtCKMraZrjuqNjnHMAWeLCRJLfmbnc0o6Uu9IBrlp++tlQjfpMrJZA8iaUV mSBJKCGJogglx/kS35Madc1YiNosixpukjrIv5R8W5C+QCG9cF0L8b63Y4oo gn3XfsUEJdmP8opePSEgPDaPfXiUWTwwMKe+8KK64nyY/3+Q9NdwuCCpT57y ysKH1GQH/CVoL6CDi9hSrLO4pADVkGLMPyU4ktiTih1qG5IYzp5rBH+PUVc4 OlaEBuzjWz8+QyjoI3gVHymK9YRZNglTRURwWrmzt6SdMO1lSqhCJva5gn3q O+iHrB3ppiCNOfU2P+Zs1yiJbKd5omjJaJIsOlOmKOjdsSzShdpYiVzxGeLn 9NuUS77BVposLrDBLPqS8Q== --2201072851-731748755-1703963133=:2993-- From nobody Sat Dec 30 22:30:29 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T2cR15S5Tz55Q5B for ; Sat, 30 Dec 2023 22:31:09 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T2cR04gmtz4kl8 for ; Sat, 30 Dec 2023 22:31:08 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=ZsN53jDM; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2a00:1450:4864:20::536 as permitted sender) smtp.mailfrom=marietto2008@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-5559bb6b29dso2390125a12.2 for ; Sat, 30 Dec 2023 14:31:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703975467; x=1704580267; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=d2ktSYm0KRPErPafZHnIw8ztX/mRGyfKyOA6id5DzHs=; b=ZsN53jDMNaL289DdU9QwFLg43F34U76BX7Gd8GUy/tEXkNFANCnB0m3UiguP16IeKH wPVERT3Vb10nuTezsghlnb0ALC4cZvdpyOAGpulhLku2jTZz832YGY0PDqkOHQDUJ3rR Yo1HlHliU+KHYo/onSsJX28hRhgGFpr6bg8TmtnJX3awmSroFKyGcXhFtD28qWD+IHj6 iAV18q3rzCY+J5ZYYNGBUoCknxNR4CWcuqPurpYI83GGBo5PaJEHlIU5ye0skepcCfnX 1INz+istVEiuegvux+ppXPcMqLk5AupLwqIZ3nQr7CMUUCm8INXqVeONPdjki00FQna/ 2obg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703975467; x=1704580267; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=d2ktSYm0KRPErPafZHnIw8ztX/mRGyfKyOA6id5DzHs=; b=Eq/ip6UpqIr8xrI6ctKRIM6B3AGGUmaLz5NopEwIZOXbW/lnHGq5vtebwIboEWnP9h v3RXFgmtU/4WYq9H9ZMMg3E9ErQjEAASWqtJJnzaa38D1MWbdFTWUTNlujeTvnWvKEnG K59IUHtvjW+e+AqbXi4u/J/odnjbPTikihtbocjqzSmNaPOkpJGDKZY9ydhQUR+6y3/I q6uAJjNwaYiwKK4L5VF3lH5SAJ+GsZW5NwIqZ9rIvry+OiOmzczrgbnsjeZEa5v1BmCM 6S+QXHBhCwo2LorEXLcL36dNyKz5KTVEyXX+oTvzn5oqF8VX+/t7FrdO6owTgdqMxfrj +k0w== X-Gm-Message-State: AOJu0YwqfMK+nP+nkTE4Jqkn5sh2UAvOBYVDsxiOt8+nCeSo0rXqu0Po Bxvm9rLGmJnD3otdSSgNOGrVhr2Ncml8jeW29Cw= X-Google-Smtp-Source: AGHT+IFOiKojpb8egL3YYiFRhk4Egwl5ueKE1JO2kliK9kwmWKcov5NloQcSGpainLECj6XiBJyK9va3hzQ82n/cm8Q= X-Received: by 2002:a17:906:251:b0:a27:5ff2:121c with SMTP id 17-20020a170906025100b00a275ff2121cmr1857161ejl.139.1703975466727; Sat, 30 Dec 2023 14:31:06 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <97aa980b9b44.6eb7f9d5c54e7@mailgate.us> <5ce9eea4-500c-4f06-a7f5-363a0e0d5178@xen.org> <46b0d8be-0e08-4737-9bf4-7db3b9b213a7@xen.org> In-Reply-To: <46b0d8be-0e08-4737-9bf4-7db3b9b213a7@xen.org> From: Mario Marietto Date: Sat, 30 Dec 2023 23:30:29 +0100 Message-ID: Subject: Re: How to boot FreeBSD for arm 32 bit as DomU with u-boot on my ARM Chromebook To: Julien Grall Cc: Warner Losh , Stefano Stabellini , Stanislav Silnicki , freebsd-arm@freebsd.org, Michal.Orzel@amd.com, xen-devel@lists.xenproject.org, Artem_Mygaiev@epam.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.992]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::536:from]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCPT_COUNT_SEVEN(0.00)[8]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4T2cR04gmtz4kl8 X-Spamd-Bar: --- ---> That said, I don't understand why it would matter that binaries are built with Armv5. U-boot should only care about the filesystem type (e.g. ZFS). So you should be able to build your own filesystem. I also don't understand why. I'm trying to do is exactly what has been suggested to do in the site below : https://forum.doozan.com/read.php?3,49039 scroll down and search these words : Whether you use "go" or "bootelf", you will need to have some knowledge about what files are the kernel files in your ARMV5 rootfs.The BSD rootfs must be built for this architecture. And how to pass parameters to the kernel. Bootelf with API is more powerful, "go" is primitive. ---> It is it not clear to me whether the last sentence is from you or Elli= ott It is from Elliott. I wanted you to know what has been done and what's missing from the FreeBSD code for arm 32 patched by Elliott. I don't understand what's the easiest thing to do to fix the problem. I can barely understand from Elliott's words that fixing the missing low level hypercalls for arm32 seems to be easy. What I don't understand is if it requires modifying some code that's inside the Elliott's github : https://gitlab.com/ehem/freebsd-src.git It seems that he patched everything inside his github,but since something is changed on the FreeBSD side,he won't fix the problem within his github because he thinks that it is a waste of time. Can you clone his repo and can you fix what's broken there ? thanks. ---> If you plan to use U-boot, then I recommend you first focus on U-boot. Then you could look at FreeBSD. That's the point. I don't know what's the easiest way to go. To use the off the tree u-boot code (that unfortunately requires to install a a lot of old packages on FreeBSD 11 because the rootfs require to be compiled using armv5) or the code that needs to be fixed to allow FreeBSD to boot as an zImage kernel file. If for you it does not take a lot of time,I think that would be a nice idea to take the bull by the horns,allowing FreeBSD to boot as Domu without u-boot,but booting it as if it was an zImage file. ---> This is likely the culprit. I haven't used FreeBSD for a while,so I can't advise on how to fix it. If it were me, I would try to revert the commiting removing the step to create kernel.bin. No idea about how to do this. I don't even know if I can do that. On Sat, Dec 30, 2023 at 9:00=E2=80=AFPM Julien Grall wrote= : > > Hi, > > On 30/12/2023 12:44, Mario Marietto wrote: > >> https://src.fedoraproject.org/repo/pkgs/uboot-tools/u-boot-2017.05.tar= .bz2/sha512/be270f9242a72b05463092a022bbabd54996762de1ff23bf7575124ac02e62f= 49572a4e2f6f571a5019047d40027e56e35593b5cc373c4a5a39b100c3377ba93/ > > > >> This source code has no support for Xen guests. This was only added in= 2020. Can you clarify why you can't use the latest upstream U-boot? > > > > It's true. I've got the source code of that custom u-boot > > implementation in the wrong place. This is the right place : > > > > https://forum.doozan.com/read.php?3,49039 > > > > an u-boot / xen developer suggested to me to explore that site because > > there is the one and only u-boot customized and off the tree version > > that can chainload the freebsd bootloader "ubldr". Unfortunately to > > work the FreeBSD rootfs should be compiled with armV5,but my ARM > > Chromebook works with armV7. I don't know if armV7 is retrocompatible > > with armV5. > > In addition,armV5 has been removed from FreeBSD starting from version > > 12. Infact Balanga used FreeBSD 11.2. FreeBSD 11 has gone EOL for > > several years and it's very hard to make it in a usable state today. > > I am not entirely sure. The Arm Arm implies that there are some sort of > compatibility between Armv5 and Armv7, but they also removed some feature= s. > > That said, I don't understand why it would matter that binaries are > built with Armv5. U-boot should only care about the filesystem type > (e.g. ZFS). So you should be able to build your own filesystem. > > > > > ---> In fact, there are some missing low-level layers (e.g. > > hypercalls) in order to properly use it for 32-bit domU. I don't know > > if there is support out-of-tree. > > > > @Elliott Mitchell some time ago concerning that point,said : > > > > I've only ever tried arm64, but since arm32 didn't appear to need much > > to be operational I tried to make it possible. In theory it > > /should/work on arm32, but I've never tried it. What was missing was > > I had never added it to the configuration and one link was needed. > > Updated "submit" branch has a tiny adjustment. (the only difference is > > the hypercall wrappers, register naming and where the op code goes, > > very simple compatibility) > > > > I'm not experienced,but it seems to me that only a few patches are > > needed to make the job done. > > It is it not clear to me whether the last sentence is from you or > Elliott. Regardless that, I think we are talking about two different > things. Elliott seems to refer to FreeBSD whereas I was referring to U-bo= ot. > > If you plan to use U-boot, then I recommend to first focus on U-boot. > Then you could look at FreeBSD. > > > ---> Do you have a tree with FreeBSD + your patches? I would like to > > check the zImage code. > > > > my patches ? Are you talking about the patches that should have been > > used on the @Elliott Mitchell github ? > > I am referring to what ever you are trying. > > > > > https://gitlab.com/ehem/freebsd-src.git > > > > yes,I tried to use his code but I've got the same error "invalid kernel= " > > [...] > > > He said that it should work,but I get the error "invalid kernel". > > [...] > > > It appears FreeBSD-CURRENT removed the last step converting the kernel > > file to kernel.bin.The patch can be readily rebased, but without > > kernel.bin that doesn't do too much. So,without a rebase of that patch > > the first option is not applicable. > > This is likely the culprit. I haven't used FreeBSD for a while, so I > can't advise on how to fix it. If it were me, I would try to revert the > commiting removing the step to create kernel.bin. > > Cheers, > > -- > Julien Grall -- Mario. From nobody Sat Dec 30 22:38:13 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T2cbN27W9z55QY3 for ; Sat, 30 Dec 2023 22:38: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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4T2cbM6C3Fz4l4K for ; Sat, 30 Dec 2023 22:38:23 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 3BUMcF66049972 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 30 Dec 2023 14:38:15 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 3BUMcDNZ049971; Sat, 30 Dec 2023 14:38:13 -0800 (PST) (envelope-from fbsd) Date: Sat, 30 Dec 2023 14:38:13 -0800 From: bob prohaska To: Marcin Cieslak Cc: Mark Millard , John F Carr , ticso@cicely.de, freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed Message-ID: References: <9o7q7p36-o7pn-27o9-62no-8p1r6o127123@fncre.vasb> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9o7q7p36-o7pn-27o9-62no-8p1r6o127123@fncre.vasb> X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4T2cbM6C3Fz4l4K On Sat, Dec 30, 2023 at 07:05:32PM +0000, Marcin Cieslak wrote: > are you running with the default /etc/ttys ? > Yes, I am. > If yes, > > can you please edit /etc/ttys on the serial port > side as follows (as root) > > # ed /etc/ttys 2216 > /ttyu0 > ttyu0 "/usr/libexec/getty 3wire" vt100 onifconsole secure > .s/3wire/3wire.9600/ > . > ttyu0 "/usr/libexec/getty 3wire.9600" vt100 onifconsole secure > w > q Couple of questions: Is it necessary to use ed? I'm less bad with vi 8-) Should I plan to change tip settings once FreeBSD boots? Right not the Pi uses 115200 at boot, changing is ok for an experiment but undesirable in normal use. The serial link has stayed up since a second reboot after turning off powerd last night. I'd like to give it until tomorrow to fail. I'll add in passing that in the past www.zefox.org's serial console did spontaneously seem to run at 9600, despite my starting the tip session with 115200. That confused me, but it worked so I ignored it. It also set the terminal window background to light grey. That stopped, I think after I switched from the mini-UART to PL011. Thanks for writing, I'll follow up in a day or two. bob prohaska