From nobody Sat Oct 28 23:11:53 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 4SHwKS45GJz4y9Rk for ; Sat, 28 Oct 2023 23:12:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (using TLSv1.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 4SHwKS1Tj7z3KTj for ; Sat, 28 Oct 2023 23:12:12 +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=1698534730; bh=+NqDXCTyEEkprnlStlrYy+sQ00I+/axKBUF/jPxVvPg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=E/JfwKcFCrRxEOG7OlmBE0A4n95Q/tRdiQCSGZn2l1Yb0+4n3rQ1TuCcOuN0HTrTw81Mpf7L0jN2hr03Jw+YsHRdMkNU98hWMh5QaRL79iDsbt6DUwWQcniZoPF23U9Hc/5odxGPs1s9fUMK90QBH5fzsuJLjbXDSEcFYH1K9zfS4YRbbglN9wjAyQ7UzweR82PWPYqF5Dc1PXcSfSEu4nGxesvDUUjy755rA6z5d8LTAZgqhhEWrVirtPTn13WF1g0pfe2y/gF1zZJxQ+Pak1QjmuTPeXJkuE5orVyDnEPRpvuXzIJv60AT0iogP6uwvHcYrFYUVMu4pwxAwEzVLQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1698534730; bh=T7iHDQcW7FAm5VFXh306NFUOovWXCU238tix5grvFTa=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=eDPPJWnG6LrS9l+dgxWpK/vfclYbEth1isOfjACeEMhF3KJjXBjAI6vXGCWvqmbkW30KZ19mra5Lw44eYDNM+lI55K+9IjwwussmF66hRu6Nix9LPGmKr1iUjJlEZvfRTAJ+VZz2Ynvw8XtfrFsc0sSh2sYdJNolOoj+wdwO2sbW1WEpSjDNwDEX0x0s8zdKd+EJcvW59JrZoto22T4wAo0xU3UXCT1Rue6A7eBgkveFTkJZEiHlCzRYAIvaQ/VdSAzEiJyXQEJD50wK3Y70Jt2cipxule3j3VqNl9YojXLWMRLkdi1m3pFOAK8XE3vk0KoB/1FwKWrLGB+Uk9N1Jg== X-YMail-OSG: ylfd40UVM1naJ.RVvH7Cn91RUr0POCrs3NazMmFhHW5ng0RgpWvhCly0b3nwJGP N17bYjwZ4sZxKx9Gom1DMpLx2kyOqiur7PPE_gxtbLpEdiZddSNHUjvbs0a8ilticAmvnkS0Ae_t 3ZlmLRX5AVomejPQoQHNUnleOt_kgjUuwmdsxyDq.Zi6x2UaPs06iU.vd5dxe5KVBRsPFyepVe3X KTL94Jy4ZUUBj.pKhHBesYgSVXJOXgJjQEJGI0pmF6x3ZhDq7TllWrSwWmGLc0lncFP8.nvB3q6a u0mFaWlsC7bI_biXRtscxo0oPOESb8IN9hN82K0hv3ZshqPmyTCOk3StvjrNl846dbyg4KPKUH08 VqitEgAgj3yj3Yms2Kl.D4jkbQrGwLM1qQyc7zXvxzlS5mwbhDhK2y6Nqx1PVpk_Ryk798KE8q2s O67AtidG.wkZPIUzRY24_jd6anMch.3idwG2gcn2rhdeZn8LyeaLiJ6gfDiHx5SNc5xt2.3TLTbt fNWSsEJuQzv4tj8uVEHtD1hQzaU_2XXJkA8.0Gf2sB8oUu.MxpyKZ.bVUJPXNDzi9eSlXfHFinY9 Gt8cEYSQgCOQiyu6.s5aOvtvCtRxq7mLJQuuQIrgezMVkiDxisUNNRO5KA0wFkuWVZQSyyy8t2f2 BKYq_v7t8K3RGzJBH5XJ72Fv0HZWhrcJbGVbhAq2pxIWStC_aDfRe723TbQW2RGwMvrXXdFTTueR OyhLJWsmtJJBzOwQAVhNTWtATW0KmLfu8pFjJ0omd25NbZGLufAws7SCC43ulhSAyLLYAOVohJ6g nPZRHm_v8wYFJXYC8qfi7TA61ZbowJbe9oNCwsaMDlEGL_ktmFkd.xKAXe4aeUQoSXOtpNEmLNP4 RE4mrwyUMjrPvpYXMkQCRkjCHfC4zyH9MGbGeN43zrcHHnJDbNiQ0ffoZlajf.5kZx87TUBYTX2m wEUYMbwDlHnLps.F140DBWghBx144eVhkGhGzui8.PcfAy10MU9W6mBu45YzZkDP2yHyu.Ia46Yb 998OWR628Lu_NsKYkTjHo1tLpTlHh7x6isyXddPuGiqAEFSriqL34vfBlvB0Rntg9hnZonlllNK6 cSdHr_cV__oXpPmrvD7Hkk86sp6tizVhhNI6STGyeb7YnYgCpqDihiIygjIafD2oVjbWTalhl_xy EkvG3.TlQYjChZ9rZwbIfPol_M04SfhQNSLxu4he5YXEbH77fo15maPMarFinOWzEPUu8eF0LhnN FiTHZN7x6bqgXZgJr4XxbQRNQZc6tAgReKwlHj2RMYndBI3la2f7KM278h6oXuGSoKNfooPFmqck iukX8C99mZe6pgays4zQvnVSp8qXCPOijuSz7dEt7._IMLTBsvtC8xTs4JST6RMJQENmHG.ZE6Ij jVw68fL2I51j1HGQghcWLNPqklLcEBBASf1am8_wx5DHhzOFwVmQRpmhj5LvQNeYgfmHlKBuchE8 LctDve8diudFs_Zvhr5bMlKjFt1p5cnZaEmbW3wOyhdO7dLBm0YJg6MektTPAPTuLgV2kiK2MKho p_fy1nxDg6IQ8vuWMwiYfWS21Sz32lykCqPeP_enDaSSpIGRrw_ApFvy9cchYchSB.c.iLeyfDk9 waCBBHOU88QmVEo3dGDIiTqO3xW1ZBQqXFKXkDGqktyEUQzg9QY6H2POJo4qMQRv8Zsj2qy3wjl_ zkn4EFSqDhDLw1K8c_5VAFTerlsndA8iZ45ufW6..Ccd0vE0NVAP6IENF5kijldjAUXVI29ZueWb k.Tq2W.67sFLctUqwXgaBTsEEv4KGLb643VejuPbEf9YYJSW44cC47nera6fOqGCX05p5FaYkVpv OKfjW3.PgdQm4XMxC71mD24ukNJ0xakrCdAzgC1B7GiHpQwICIMjVquliYZyQsN_e_2yjH1ftj6T x.lzk6lNA942yo1pINzODR1XWR17tOKSCe9GslOnkXKTz.m_Youe7CzrtQWj5CiPSMAVbANj7FRN uD5IkVhmgS8X3Ex9rQP.o4XtNeewdLGdFKfcV6QWPfBfqdukVUcaBvIcEad902wwfXhErnARgB9U Ovu5X.ckCCf3K4fp6176XFY1ZZIQ5pSdsoZLqH4a5zMxInCtaz0JrHURXYQqNCIq5MqrF3iJHyD9 bIpeKKGBDci5wzYMKSN0ZE4XJb4X7.kAGaMxZB47X1UpiqGvCYeiRmzeOXDVcPqU6M7onkFxEoKO E4NrEV_ewksO2frs1a44xThkdrSc1ZUKaGdxtIpefU5t3QNGIa6z0gs5Y0YSSirONYkkdnkSYh1W x9A-- X-Sonic-MF: X-Sonic-ID: c9261f6c-3dcb-4608-a9d0-0e39446dfc16 Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sat, 28 Oct 2023 23:12:10 +0000 Received: by hermes--production-bf1-5b945b6d47-h4jfj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID af296f11fa6e0e069b65358525de277d; Sat, 28 Oct 2023 23:12:06 +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.200.91.1.1\)) Subject: Re: Stable/14 dropping ssh connections to FT232 usb-serial adapter From: Mark Millard In-Reply-To: Date: Sat, 28 Oct 2023 16:11:53 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <5210D449-A4E6-455B-A1BB-754BA3501C3F@yahoo.com> References: <33D1AACD-62FB-444A-868C-B8DE92A7BF50@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3774.200.91.1.1) X-Spamd-Bar: ---- 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-Rspamd-Queue-Id: 4SHwKS1Tj7z3KTj So, if I understand correctly, the general structure here is something = like: RPi4B: ssh to RPi2 v1.1 #0 (to invent simple naming). . . . RPi2 v1.1 #0: tip ucom (which gets to RPi2 v1.1 #1) . . . (Does each RPi2 v1.1 get its own ssh session too? If yes: all from the = same RPi4B?) RPi2 v1.1 #1: tip ucom (which gets to RPi2 v1.1 #2) . . . (ssh session to RPi2 v1.1 #N ?) RPi2 v1.1 #N: tip ucom (which gets to RPi2 v1.1 #0) (An accurate/complete indication of the sessions/connections command sequence for the set up could be useful.) As I understand, you are seeing the ssh session abort, not just a tip session abort. An interesting test might be having another ssh session paired with each one that does a remote tip --but that is not used for any tip or other activity beyond sitting at a shell prompt. The question for each paired ssh session would be: A) Do both ssh sessions of the pair fail/abort at the same time? B) Does only one? If yes: is it always just the one that had used tip? So, a comparison/contrast test. As I remember, there were notes about avoiding special character sequences from getting special interpretations for ssh. That sort of thing could be important to both ssh [-e none] and tip [-n] for testing if that avoids some problems. I've no clue if "tip -n -v" might report anything interesting around a failure (via the -v). =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Oct 29 01:25:18 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 4SHzHQ20knz4yJ5m for ; Sun, 29 Oct 2023 01:25:38 +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 4SHzHP1DR7z3WgW for ; Sun, 29 Oct 2023 01:25:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=I2DPLar7; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1698542734; bh=nT4wqhqFNSpEWNyEfDkrh5LnZT7QCw3a6bGOdCs5L9g=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=I2DPLar7NbmSA0NDp/cYpg/h3Kijuhn0mg7yGEogdUjMSdXcUTQQoWtV34A5PWYKRj6SJXZeEN2uxduBblsFCar0YK4XJGYDHR0BHF8sABjwx7dP8XvrnK2RhRO4hc9Z11l5HtOJyqt3tw/uTvf1oMxBNCUCXDf0T+2UdBW/G3EEzCM/RzRBTYu96GKbqqceX8DgrIqoNyeRaeHZ4m94PRdKIJn2Frnqo7qTuC1e2PQH/T5vmdg7NqsEtTTvV+7cqze05Y0jMwPmcZeNIuBG3zq9uiMzoR8TosocnyvymhebuwuLzBD6FCfM3cTF/9z5g3mYxCXySVOoAgDPRB2DYA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1698542734; bh=2f+hW/ZFsMhr0Grq37i90ScyHnRFgA5lJchgNFUR546=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=VvocaWldJFtgKgDQqT6LPkOktjpJh6ioysJFjBAP8ViJ523zWE1Nip1y9edNKZh1NLCVgna+LdYwh6DZK6TNjDGy3hISO7jIMBkLDmBdGzl869U8Z1NGpFWHnHjzkh08DZoRlPTMtyDEtjpoEuiqar7WeJb91JTHlAORV8rPX9i4JLSa2E7vLtRIUpBkA0K/bp4/R/zIXI2ZpDvLCmC6Qriusggt59YtQFIMMeWp15dqVzE3Qrl3VM7aXaLMqNVHZvloexJoqgYUvt7bwfQkA8ZukTI5sNeBXGCR0/Yu8JkjWxYCz7vtdk48HGiqvU1/qr+lyYG+L88FMLrpAwzS6Q== X-YMail-OSG: uuZvjlkVM1kqZeHufUs5es6ds339fm_ysfuUEMZ_GUSwGSL.BLj5vDSGgqdzlxB hx4_q_2AGIFfUmpRNrC6.g1IC6txVbMAVI4inxLkJIOFz0CZU6yROXe8Ac0TPUPZu1kyuD1Y.vu1 FnyeE921CYL0y1IkWIMlUgYw09EGPvorzFttBKKABC3rWhjR_a9BRSkF5RUcvEkLd.U.6yQJfsJe 891V6FLbtugpQcUYM29nMTdfdvR_24vFmsaUDUeIRHAj4DgoqKqVZX_acF7ablyuzIXb5jLlA9X3 GkbsFEuFvqDSFsLhDaDpgKURrKLDQ6Dnjaw1jevA8KmTQZ6xwOJZJSI8wHP1o2.9_aacsexyAxtc DYOwBiuIrAQ3x7AaWaUSkknIzS3JoV6MRknv0UCciZqTX..cqQSdIMcja2_GthDM8QeeNhlz_.DH WA7XOO0eHPwJavmWhUyvXxDzCmVxq5jaM_Wg7PmE36difxaq.qv6tKW491bH21ClarbgZOZ6GVAz LSIv9PI8Y0Ihw.4uhpGE6.X_faAwP2BZgXtx8MekFM9Cf4Sph.Isr6hMVXaBhCX.tPVFoe08JaAq byTPWgDy9fAK_SEobebx8zf_MWIeNB4NvTyosuKdc5XkXBC0On021SneyYlc1pLOb6Tif0w5BdZ1 3HVzLndI620BYYIjQ6Xifijwl.pfAV1Y65v1yMrRgE4C5rupfvyVZz.equ_Ev7.WhPLPk65DtpV. ToWsXxwbH_fFRfvdBMSguygQ29bu4zp7ueyaP2acVe9pulPhPZg_jWO8PtHr0sKDD7vQBHRm3Kq2 Vhhwvv7_MsDSt9KV1uyakY5OUApdjn3J1eKNkftZNwWVP7TW_jlqsEgXLVUb18Fvmi1kruqxPBjO wpEL35IEPoUiPVf0at_m78QaL6y76YMn6tNL8sr0QCtZNbDZfIbix0Q8FxHKjuXpZCeougskoh3n DNNLetB1Q6d4rr_84fO467Fy4avOso1jzIETGL6R3IRRiIgbHk59NwHCHQcbOFNXsYWXkRdjg9f2 K4ipkWFlYAOnvwmAinOcibiY81lk8JC6z5T_dTwYiHB3TrA_alUlAdA6zfOmvA.I2VmhdPksoFKk kDiEUDR4pOjv4jUvsbjnThq3AuXurTQGv5Rfi7O9IVkGcbsrdI7owd9ax3RGhGgeF8yJvwH4EE3E 1G3HKykjnrLJAk_DEKkuRdxPVc4PcZJS_e27fCJkgrqw1j.XtH77t9WwkZe6Q0gjyPrphg6AsK1M n.9PfkdTCbY7H8jx7Z84_mB2w.1gQnWIj7QnfyruzSYQsvEAT6aRmbqXFUymzy3Tk7PN.TLC.Sx_ yFjWaH07srfb9xGnLxNmUfh4wFzYvL9syawD3N9vJwK_pNcyesgaxJbxeEPcvSiI6CsCXeOphUN8 t_D1NQ44_ZTT5n.CfSrIMGweB_6ybKvtihfyr1IRXli9fuakALkpqKvFkePz707CoE_Cpk5pQaHP 5jAL7wkr_N0qhW4FP3fFehdQNLnOHWu9Ewx1ZhhQHMKU62fqV_27Hs0SunxmNfjdmF3UC2T81QJt NMXpRlPE8bRfJrJl5ijoffDaVGk7.q.gWcIPg.46S3gwC.Rns3iCGsv9rJhkHsZuolNfxoWKuvzf 1cggtz6vDhKl3bQ.gzmeqg9GHGi1hfV2RfT17J_N5F3b6w05sY4gM3UzBcpjWeiZ4BBaNdQNtrlY sLMcE2PZNkYTPbBFHOK103TQDmvdY05Oc2a2t5zJGag_mT5yUdSkbiUqFSjGiqFGU6xZDDYA61Vw lcaZLhmb7nFzbo2juYgwOGb3xVDQRLtbEyKEylpcPobEdLZrxlsxmJlgn95cpG4rENS5cJqA9L.0 Sw_DOYL28ZisIi5NLivGp6BtoeOHT_oiD4ExJdakngsba1W1RfQqUHsJx0met6l4Kz.YkqpuX1FG 6tLkPzynZYJBPeuATvGE6psz8aY_hSbf5tDdySdS2yWLPjGushV8MVhe1G4NuXbLMAomjSUKr4Ng P8j5dsVZmKqO4KuDYKwMt9T2aCaprObDH4d2kpP4GTRYdHXJw6j.Z327A_w6w7v5KEZ36c1oThkZ pfQOdSpxcPwBZeb_c0R5JwwTGKkBJepqtDWyfihqZTzA5RUf378Oy4wKltsr_u6ruQYp3zmebs7Q WfhGHGV3TGI05rIXzE7O_HoHHVj4Hrm1W9H9jIBEhVnLnUw5KSZy.0sxzXT7YCy64cgFB3B47f2I RGnbYTiyZlmsCetu760cPYt4kbDtDh.y7jHW6iY9JwndQ87xvTOKQm6EjC8uw618LVI4gfW3vAdc - X-Sonic-MF: X-Sonic-ID: 5d27aa67-1c3b-4340-acb3-8b227ff3aee2 Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Sun, 29 Oct 2023 01:25:34 +0000 Received: by hermes--production-ne1-56df75844-jh4w4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 72de6089317834b8c07db9aac882124a; Sun, 29 Oct 2023 01:25:30 +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.200.91.1.1\)) Subject: Re: 15-aarch64-RPI-snap From: Mark Millard In-Reply-To: <183A9CD0-42DB-4A0C-982D-FC6D3980163A@yahoo.com> Date: Sat, 28 Oct 2023 18:25:18 -0700 Cc: Colin Percival , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <6CF6E677-CF8F-4DE9-9781-754003FCE0B6@yahoo.com> References: <0100018b6a9d257c-b35e4157-ba97-4aa7-988c-aba797c6d2ca-000000@email.amazonses.com> <13B64416-4334-4070-8588-71F7D938350B@yahoo.com> <3B40F89C-7E5E-427F-A7A1-2D37CCC06A6F@yahoo.com> <183A9CD0-42DB-4A0C-982D-FC6D3980163A@yahoo.com> To: Glen Barber X-Mailer: Apple Mail (2.3774.200.91.1.1) X-Spamd-Result: default: False [-3.48 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.980]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; BLOCKLISTDE_FAIL(0.00)[98.137.68.32:server fail]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.32:from]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.32:from]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4SHzHP1DR7z3WgW X-Spamd-Bar: --- On Oct 28, 2023, at 09:40, Mark Millard wrote: > On Oct 27, 2023, at 23:00, Mark Millard wrote: >=20 >> On Oct 27, 2023, at 22:24, Mark Millard wrote: >>=20 >>> On Oct 27, 2023, at 21:34, Glen Barber wrote: >>>=20 >>>>>> . . . >>>>>> = ^ >>>>>> ./offset.inc:16:19: error: null character ignored = [-Werror,-Wnull-character] >>>>>> = = = = >>>>> 00>#undef _SA >>>>>> = = ^ >>>=20 >>> Are the above from a ZFS file system? UFS? Something else? >>>=20 >>> Back in 2021-Nov (15..21) I had problems where ZFS was leading >>> to blocks of such on aarch64, not specifically RPi*'s, various >>> files but not the same ones from test to test. When I updated >>> past some zfs updates on the 23rd the problem stopped. >>>=20 >>> I also have notes from 2022-Mar (19..22) about replicating >>> another example problem someone was having with files ending >>> up with such blocks of bytes but the testing was on the >>> ThreadRipper 1950X. (The replication showed that ccache did >>> not need to be involved since I've never used it.) Again >>> ZFS was part of the environment that got the replication. >>> Mark Johnson fixed sys/contrib/openzfs/module/zfs/dnode.c >>> during this and my ability to replicate the issue then >>> stopped when I tested the patch. >>>=20 >>> Which ever file system it is that holds the bad bytes, some >>> attempted testing for repeatability of the problem could >>> be of interest, some of that being on aarch64 but not on >>> RPi*'s, some of it not on aarch64 at all. But it might take >>> information about the context to know better what/how to >>> test. That could include information about both the host and >>> the jail OS versions if such is involved. >>=20 >> Those last notes are likely too generic, in that normally >> official buildworld buildkernel activity is done on amd64 >> for all target platforms (last I knew). (Not that running >> such builds on other platforms would be a bad problem-scope >> isolation test.) >>=20 >> Any notes that help delimit what sort of test context >> would be a reasonable partial replication of the original >> context could prove useful. >>=20 >>> . . . >=20 > If the file system is ZFS, I'll note that main [so: 15] already has > a zpool feature that is not part of openzfs-2.2 and so not part of > releng/14.0 or stable/14 . So what zpool features are enabled could > be relevant to problems that only happen in main and might need to > be involved in efforts to replicate the problem. >=20 > But I've not evaluated if redaction_list_spill would be likely to > possibly be involved for the specific type of file corruptions. I'll note that the upstream openzfs master commit for the data corruption issue: "Zpool can start allocating from metaslab before TRIMs have completed" was on 2023-Oct-12, so not long ago. If the official builds use ZFS and TRIM but are based on a system version that predates FreeBSD picking up that commit, then there is a known data zfs data corruption issue present in the official build environment. Since port->package builds are based on a HOST/JAIL such as: Host OSVERSION: 1500000 Jail OSVERSION: 1500002 or: Host OSVERSION: 1500000 Jail OSVERSION: 1400097 but the Host kernel is the one in use (with the Host kernel commit not identified), it could have such an issue. (Because of such issues, I wish that Host OSVERSION related commit identification was also reported for the package builds. Presuming ZFS use, I also wish that the zpool features enabled were reported for similar reasons.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Oct 29 14:01:21 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 4SJJ3Q0kLrz4xkv4 for ; Sun, 29 Oct 2023 14:01:22 +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 4SJJ3P44tHz3WpC for ; Sun, 29 Oct 2023 14:01:21 +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 39TE1Mc0086412 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 29 Oct 2023 07:01:22 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 39TE1MY2086411; Sun, 29 Oct 2023 07:01:22 -0700 (PDT) (envelope-from fbsd) Date: Sun, 29 Oct 2023 07:01:21 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: Stable/14 dropping ssh connections to FT232 usb-serial adapter Message-ID: References: <33D1AACD-62FB-444A-868C-B8DE92A7BF50@yahoo.com> <5210D449-A4E6-455B-A1BB-754BA3501C3F@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: <5210D449-A4E6-455B-A1BB-754BA3501C3F@yahoo.com> X-Spamd-Bar: ---- 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-Rspamd-Queue-Id: 4SJJ3P44tHz3WpC On Sat, Oct 28, 2023 at 04:11:53PM -0700, Mark Millard wrote: > So, if I understand correctly, the general structure here is something like: > > RPi4B: ssh to RPi2 v1.1 #0 (to invent simple naming). > . . . > RPi2 v1.1 #0: tip ucom (which gets to RPi2 v1.1 #1) > . . . > (Does each RPi2 v1.1 get its own ssh session too? If yes: all from the same RPi4B?) > RPi2 v1.1 #1: tip ucom (which gets to RPi2 v1.1 #2) > . . . > (ssh session to RPi2 v1.1 #N ?) > RPi2 v1.1 #N: tip ucom (which gets to RPi2 v1.1 #0) > I think you've got the picture. Here's an ASCII-art diagram: http://www.zefox.net/~fbsd/netmap Each connection originates on a single WiFi-connected Pi4 running RasPiOS (top right). The sessions are separate shells, each running in a tab in one lxterminal window. > (An accurate/complete indication of the sessions/connections > command sequence for the set up could be useful.) > Here's a verbatim sample, including MOTD and usbconfig output: bob@raspberrypi:~ $ ssh 50.1.20.26 Password for bob@www.zefox.com: Last login: Sun Oct 29 03:34:28 2023 from 50.1.20.31 FreeBSD 14.0-RC3 (GENERIC) #39 releng/14.0-n265368-c6cfdc130554-dirty: Fri Oct 27 21:27:20 PDT 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). To display the compression ratio for the ZFS dataset /var/log on the pool mypool, run the following command: zfs get refcompressratio mypool/var/log The refcompressratio will only display the compression ratio for that specific dataset, not the descendant datasets. To include the child datasets, the command looks like this: zfs get compressratio mypool/var -- Benedict Reuschling bob@www:~ % su Password: # usbconfig ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen1.2: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (2mA) ugen1.3: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (2mA) ugen1.4: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (90mA) ugen1.5: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (100mA) ugen1.6: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) # tip ucom Stale lock on cuaU0 PID=1272... overriding. connected FreeBSD/arm64 (pelorus.zefox.org) (ttyu0) > As I understand, you are seeing the ssh session abort, not just a tip > session abort. > That's correct. On the RasPiOS host I see simply client_loop: send disconnect: Broken pipe > An interesting test might be having another ssh session paired with > each one that does a remote tip --but that is not used for any tip > or other activity beyond sitting at a shell prompt. The question for > each paired ssh session would be: > > A) Do both ssh sessions of the pair fail/abort at the same time? > B) Does only one? If yes: is it always just the one that had used tip? > > So, a comparison/contrast test. > At present I have only one usb-serial adapter per RPi2/3/4. However, that still gives me seven tip sessions up at any one time and the one on releng/14 drops reliably. There are usually half a dozen ssh connections running interactive shells from the RasPiOS host to random FreeBSD Pi's and as a rule they only drop when I crash or reboot the RasPiOS host. > As I remember, there were notes about avoiding special character > sequences from getting special interpretations for ssh. That sort of > thing could be important to both ssh [-e none] and tip [-n] for > testing if that avoids some problems. > > I've no clue if "tip -n -v" might report anything interesting around > a failure (via the -v). I've tried ssh -e none, it didn't make an obvious difference. I overlooked tip -v, will try it next time. As it happens the tip sessions sometimes come up "stuck", reporting a connection but refusing to display any output. In that case it's useful to use ~~. to escape back to a root prompt, run usbconfig [-u 0 -a 4] power_off and then power_on to reset the usb-serial adapter, which generally gets a working connection. I'll try tip -n -v at the next opportunity. Thanks for writing! bob prohaska From nobody Sun Oct 29 18:47: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 4SJQPg6Jv5z4y3pL for ; Sun, 29 Oct 2023 18:47:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.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 4SJQPg3m1Tz4MNQ for ; Sun, 29 Oct 2023 18:47:35 +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=1698605253; bh=02JUrx4q+ZIoCy5h/g9wcmJ69TWY36KZkCbs26aAYHw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=oZUBTYV5Yo+MQfV0BgIGbG/maWLT2oCtGKFcajMyjuIk7Z8eXrcgrKTNzR+qrRnIkss0RRn3ScWSqXOZeY2AOkadN8S05HjE1guxjtK3V/NPt8k/xYgUwIBySy03RaN1uj5s3Ww4hPfYlQgDStVXg8kADrMQvsNYlHCBpQTSmdwSF0YDcmomhXLE7TP0bnzNJPn7TqrQCsCflrCzIS4BtnNuDmHxe97E/VEPixJXP38tq9T0p/dEvJKQgrJZtL26eZSE+xeQNh9sy/5ykL7Ejxzm1vKs3lx/380VBFxlI0iRP3DWt6HLFuHWg6ZctuErE23sme8DfUu82GCh9zBeHg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1698605253; bh=ppPsN8oCYwqeXwUK5OuZlm6AOuX6PtxplXjhRw16vvX=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=hoheLL9CKj6wXNq9+ipv546ORDJbS4HwVOY65uaqOi0ILCc9CIyDXR1ltjfGGSw8h5UWoPSEKMbY4/4Itgab6HCsABrPkUq9W2rhbGb3n1z80h/bC5UEJkyEWycfIY1j6UxM9rikkGrEiC5ox2+hOPnC1vJtL/Yx1AbXxxH41irQc2DCXmjpc5aBCywNDhwBxetXB/by9ncqYs7cBAn1bZlwwyVA0eMfoU9pU24m9/dCISe1rWk32qM4agyBMzQuSoB/1Eu8qDgggxGzONf+dWrc1/8dSc9TXMhZ+1AIoXJnUwvftKj26rczQuszIKVKGQLdjgW9L0fUVZwe+Tmpdg== X-YMail-OSG: s3poo8EVM1k0uLmemnoOFgk4WjyXnxcLMj.0Oe0GnxwRIZ7RIHyJMf5QsTamN2s 0PLV8ThFXW5WHjffCEtdezVzsMghgtYiyqNiAqhG_pPVnk3.TcqiZ7rjzrA84ZZopxUm9EBxDjqy tKJ3KSHOFrg.n.pthSXIntBJ22F6sLZqU3paJZtY2ZSrLnuIPELTAXYxTe2L_tTBG3fBlAte0139 DSbPnH0GJkxeeKHiqxbHdtdciJv2K1ZbU7eYCiGhWmfKmXdyEOfczgIKrsPv.7MnPv00PFUV5NNJ .1APOd0MvWXzsL7vbHbRp0xxu9tmv9vMhs4klB2EtNfYHI6UC29Bd4MmWCo0NFdnOnxrGEA6S1N0 Ka3mcemeXaMLMNh0PGNjf7d3i43qzMRJQ.mV4XBqeLM3r0e7brBtp3XgFBbFTtuDSM_IRdj6TGNf ucwbkAnAdBVdUIaq0juA6Ut7RsyKiuOolgrPJAhd1SsgXDnzFvz3ZrsbTIAou_X9Fo7ZooCCGvSe eHsTzt53pnwaROJqz9TTwErI.fV0kGc0g.B5gMV6TO800KQ7WhThatxilm_F8MHBHAD2BZ38lwmY J7QS9Z3fhDs180Fg.XD1OBamfjTDtcE6Y.DjM7CLxQRVdnWos9OTYLuB0XYTbFu1Qay4ipYYdBi8 .URgYI_ilAEHK1uHXHZaQj.6Z14fL7wfdzjT7K1MvUSmD.lAofEi6cZvVKtATiKsU4Ohy40fabah y9vTweVnLwATmck5rY_V_ywGRbwvkCCxhjt_Co9z8beyi06Lqdzipgk5AMtxkLsvZXjK8fn0khKu g5ZwIM9Mixa5vjsecFGy1cYfHjOIHCCn6j.IcUWcPDxR1qIzBOVUMshtr_AZbUfKVL_2uQ__FFxl I6MpXnQ.ZGCQ7QVvx.AcAltIyHLVCA7AoNlY90uC8fDYhj9kYB9UKzAhwa0h0w88tZ9myGs8Qxl. bqF1O3LfSdmA0jDPaNygVIlbc3Di1yFJ9sqYcVi.KXBPMaLZyyaMSiLUMseUJ36R863d1O._ioPP pc8879n0.uNN3v21oNezlsADFZynol.NT0XAvV0f26F7mQM5OpBoV7Yfg.wy0rMQE__LDawx9rdZ dumP8rHir0kGaH1KInOu_0654M.CYTpsF8bpNy9443Tw3ACl0bVnzK4IkuM3DNRTaD9ofsw7FyzO SVvVwgJZyW9R53Hw584kY6.s1ZdvhlePrNmC09pyD8uZ1Cmxi6HPbE5vIpVO09fMnigtrNZtmMHA l446jcXOiqj95QQzKkhJKumIJvZ2rAAtcTogRpkUHIy6tg3NQ3BmnqD4zKD8uTgL7FKgL2jmxs4e gUP81qxiCcZJNdczZC1KQEvcVnutI6jSjcg_4wpKoOw9_qV8523CCvIwXXGOnVK4jUdxi2WGIpgB ll6SBEvw2pE30qUIrqZFcQrlq9tyrWKLUaVzc.pkr3et8Lk_Vog5osKbFmwfZDaYuKNAnRnwmrfu PqqIaeczKVw82VMZRWgTUYJKm4OTESyfcloMUtvoDARmEXeTaTpnP8EdFpeUhLZoHjnC5IudPjQY lSe5jGjDBZUnVT0_6jEC6LRXbZqbw9ikkvK4wE1PdG0MKfbC.6EuE_iAOnZP1FkzuiG4x0dmUg.2 Ug_yRlZ081n8hoQ6ckBN0D_HbmCwqMR2ry7iBujYYBY0N2SwqzzTBZhG5FKPjJJ2W5.d7SCWzGU4 edK0rOdWuHtk3MmEUSAjvZCKmVY812Viw1xnbU2fhdbIgETk3duQxfSENuhnKVfxgZJPDOqrUnI8 DYjnDHMjujwvICdPvUWFjCcZB.XjE3J4Mhz2op.eHwaurzXGOYPe3wNnatUnohIdt1G7rgr3wpqk Dmih6cMsBzMBzcbpeGcgQA_JgBoEhfPLIcRKaCcNgKdIN9vanxZKczZ7dkbFcBtFXjSdanZoKXem MmjLjWVABA0zMtfocEA2B5i1UCRAayvJqgOyw0T9oy756Qea2bOHzkxI4QHWxLevG9RuNKwm27Mg W33iu2HZgqux2Hy8Ue7qKyS.DIfQZCVBDRS3q3trc5ViC5m8FFsfrpz_U8UmrFer6g6BPUdCGI4Q 31KbDrs0yQN.bQPQDy7eIleG8hn5FnXOWeaGDlnY5c9qRibKCm3JK0QWWlVCgV4gdbdcisTwLLEr Scpcj8nfl1JdlL14R9odzvntTifKaIjjSgHlch7ocY1HIDGl88X0Figasfrh1.8pcV46D0sVfwUR 2T3RtcacYmZHdW0zlUCVyYYyv_rEZFNbFbjKj.eJqtBu8g09X916kXAoC2Y0H1ceawB5nG.m9UDv 50g-- X-Sonic-MF: X-Sonic-ID: 1b399d20-e76a-4304-a484-b093e4335a58 Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sun, 29 Oct 2023 18:47:33 +0000 Received: by hermes--production-bf1-5b945b6d47-ssgx9 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1845bad53d5189e12cef3150d169d38f; Sun, 29 Oct 2023 18:47:26 +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.200.91.1.1\)) Subject: Re: Stable/14 dropping ssh connections to FT232 usb-serial adapter From: Mark Millard In-Reply-To: Date: Sun, 29 Oct 2023 11:47:14 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <90CBBDDB-654B-402B-96E8-C16545BFE011@yahoo.com> References: <33D1AACD-62FB-444A-868C-B8DE92A7BF50@yahoo.com> <5210D449-A4E6-455B-A1BB-754BA3501C3F@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3774.200.91.1.1) X-Spamd-Bar: ---- 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-Rspamd-Queue-Id: 4SJQPg3m1Tz4MNQ On Oct 29, 2023, at 07:01, bob prohaska wrote: > On Sat, Oct 28, 2023 at 04:11:53PM -0700, Mark Millard wrote: >> So, if I understand correctly, the general structure here is = something like: >>=20 >> RPi4B: ssh to RPi2 v1.1 #0 (to invent simple naming). >> . . . >> RPi2 v1.1 #0: tip ucom (which gets to RPi2 v1.1 #1) >> . . . >> (Does each RPi2 v1.1 get its own ssh session too? If yes: all from = the same RPi4B?) >> RPi2 v1.1 #1: tip ucom (which gets to RPi2 v1.1 #2) >> . . . >> (ssh session to RPi2 v1.1 #N ?) >> RPi2 v1.1 #N: tip ucom (which gets to RPi2 v1.1 #0) >>=20 >=20 > I think you've got the picture. Here's an ASCII-art diagram: > http://www.zefox.net/~fbsd/netmap >=20 > Each connection originates on a single WiFi-connected Pi4 running = RasPiOS (top right). > The sessions are separate shells, each running in a tab in one = lxterminal window. >=20 >=20 >> (An accurate/complete indication of the sessions/connections >> command sequence for the set up could be useful.) >>=20 >=20 > Here's a verbatim sample, including MOTD and usbconfig output: > bob@raspberrypi:~ $ ssh 50.1.20.26 > Password for bob@www.zefox.com: > Last login: Sun Oct 29 03:34:28 2023 from 50.1.20.31 > FreeBSD 14.0-RC3 (GENERIC) #39 releng/14.0-n265368-c6cfdc130554-dirty: = Fri Oct 27 21:27:20 PDT 2023 >=20 . . . > bob@www:~ % su > Password: > # usbconfig > ugen1.1: at usbus1, cfg=3D0 md=3DHOST spd=3DHIGH = (480Mbps) pwr=3DSAVE (0mA) > ugen1.2: at usbus1, cfg=3D0 md=3DHOST = spd=3DHIGH (480Mbps) pwr=3DSAVE (2mA) > ugen1.3: at usbus1, cfg=3D0 md=3DHOST = spd=3DHIGH (480Mbps) pwr=3DON (2mA) > ugen1.4: at usbus1, cfg=3D0 md=3DHOST spd=3DFULL = (12Mbps) pwr=3DON (90mA) > ugen1.5: at usbus1, cfg=3D0 md=3DHOST = spd=3DHIGH (480Mbps) pwr=3DSAVE (100mA) > ugen1.6: at usbus1, cfg=3D0 md=3DHOST = spd=3DHIGH (480Mbps) pwr=3DON (500mA) > # tip ucom > Stale lock on cuaU0 PID=3D1272... overriding. > connected >=20 >=20 > FreeBSD/arm64 (pelorus.zefox.org) (ttyu0) >=20 >=20 >> As I understand, you are seeing the ssh session abort, not just a tip >> session abort. >>=20 >=20 > That's correct. On the RasPiOS host I see simply > client_loop: send disconnect: Broken pipe >=20 >> An interesting test might be having another ssh session paired with >> each one that does a remote tip --but that is not used for any tip >> or other activity beyond sitting at a shell prompt. The question for >> each paired ssh session would be: >>=20 >> A) Do both ssh sessions of the pair fail/abort at the same time? >> B) Does only one? If yes: is it always just the one that had used = tip? >>=20 >> So, a comparison/contrast test. >>=20 >=20 > At present I have only one usb-serial adapter per RPi2/3/4. However, > that still gives me seven tip sessions up at any one time and the one > on releng/14 drops reliably. I take that wording to mean that the ssh session into: 50.1.20.26 www.zefox.com Pi2 releng/14 fails, not the ssh session into: 50.1.20.27 www.zefox.net Pi2 12.3 2303 usb-serial----50.1.20.26 If I have that wrong, my wording below would need adjustment. So my suggestion would be to have an extra ssh session to the releng/14 RPi2B v1.1 in order to see if both ssh's have problems at the same time. I'm not suggesting a 2nd serial connection: the extra ssh session would just sit at a releng/14 shell prompt, for example. On failure, a question would be if the extra ssh session can still execute commands in that shell or not. If only one ssh session of the pair fails, repeated testing to check if it is always the same one of the pair would be appropriate (always and only the one doing tip?). This might help issolate if tip is involved in initiating the ssh falure or not. tip would likely stop if the ssh session failed for other = reasons. I recommend the experiments be with "ssh -e none" and "tip -n -v", even = if the likes of, say, "tip -n" is unreasonable in general use. > There are usually half a dozen ssh connections > running interactive shells from the RasPiOS host to random FreeBSD = Pi's > and as a rule they only drop when I crash or reboot the RasPiOS host. I'm not really after what happens across multiple RPi*'s in my suggestion. I'm after the pair of ssh sessions into the same RPi* instead --just for the target RPi* that gets the failure. It would be possible to do similarly on more than one target RPi*, not just the releng/14 RPi2B v1.1 . The test would be for whichever target RPi* happens to show the failure. >> As I remember, there were notes about avoiding special character >> sequences from getting special interpretations for ssh. That sort of >> thing could be important to both ssh [-e none] and tip [-n] for >> testing if that avoids some problems. >>=20 >> I've no clue if "tip -n -v" might report anything interesting around >> a failure (via the -v). >=20 > I've tried ssh -e none, it didn't make an obvious difference. I = overlooked=20 > tip -v, will try it next time. As it happens the tip sessions = sometimes > come up "stuck", reporting a connection but refusing to display any=20 > output. In that case it's useful to use ~~. to escape back to a root > prompt, run usbconfig [-u 0 -a 4] power_off and then power_on to reset > the usb-serial adapter, which generally gets a working connection.=20 > I'll try tip -n -v at the next opportunity. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Oct 29 20:25: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 4SJSZW01z1z4y9L2 for ; Sun, 29 Oct 2023 20:25:23 +0000 (UTC) (envelope-from stanislav.silnicki@mailgate.us) Received: from mailgate.us (mailgate.us [185.72.246.236]) by mx1.freebsd.org (Postfix) with ESMTP id 4SJSZV0XZ0z4TK2 for ; Sun, 29 Oct 2023 20:25:22 +0000 (UTC) (envelope-from stanislav.silnicki@mailgate.us) Authentication-Results: mx1.freebsd.org; dkim=fail ("body hash did not verify") header.d=mailgate.us header.s=mail header.b=KzmEcMXn; spf=pass (mx1.freebsd.org: domain of stanislav.silnicki@mailgate.us designates 185.72.246.236 as permitted sender) smtp.mailfrom=stanislav.silnicki@mailgate.us; dmarc=none Received: from localhost (api.telegram.org [192.168.2.1]) by mailgate.us (Postfix) with ESMTPSA id C02899F4B8; Sun, 29 Oct 2023 23:25:19 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailgate.us; s=mail; t=1698611120; bh=9IqogbPA+LaPQNPiEFW6p3jElj3yb0ty6ou75XJaEG8=; h=From:Subject:To:References:Date; b=KzmEcMXnZiE6gSK6HOxPyeAAyZX7yRUDQ50MezFghHVk0GPbJTCXTLQ4giGlSgziM zc4KIizWKXquBcD1pMjqFUq8v1V/DOhKPiyBysEn2YYdbN02wSko2pi+0+LDKYIZ8C GKug4we66aE5CGjlseDQOIu9nEe2z5cBVLss91co= Content-Type: multipart/alternative; boundary="----sinikael-?=_1-16986111093260.8140990208563574" From: Stanislav Silnicki Subject: Re: STM32MP157 X-Type: reply To: Oskar Holmlund , "freebsd-arm" User-Agent: Desktop Message-Id: References: <4d6bf0126f4fb.c24cc5f2fa47c@mailgate.us> <00cab7929791c.8af55c0bd1d5f@mailgate.us> <5d65957f4c04a4bec7ae6ef5469b149c@ohdata.se> Content-Transfer-Encoding: quoted-printable Date: Sun, 29 Oct 2023 20:25:08 +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 X-Spamd-Result: default: False [-1.44 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_DKIM_REJECT(1.00)[mailgate.us:s=mail]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; SUBJ_ALL_CAPS(0.75)[10]; R_SPF_ALLOW(-0.20)[+ip4:185.72.246.236/32:c]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_NO_TLS_LAST(0.10)[]; XM_UA_NO_VERSION(0.01)[]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; BLOCKLISTDE_FAIL(0.00)[185.72.246.236:server fail]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[mailgate.us:-]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; DMARC_NA(0.00)[mailgate.us]; TO_DN_ALL(0.00)[]; ASN(0.00)[asn:47447, ipnet:185.72.246.0/24, country:DE]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4SJSZV0XZ0z4TK2 X-Spamd-Bar: - ------sinikael-?=_1-16986111093260.8140990208563574 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: 7bit OK, I got the idea! As I realize, there is a minor bug in dtc, which affects compilation of stm's originated DTBs. I think it is best to make a PR into https://github.com/davidchisnall/dtc, which I'm discussing with repo owner already. Please tell me, that I need to post PR into FBSD source tree if it is a shorter way for my fix. My current setup is based upon QBASE1 from Karo-Electronics, but there is no goal to support/debug all peripherals, only a subset, including USB, I2C, SDMMC, DSI (and GPU, if lucky). https://www.karo-electronics.com/fileadmin/download/Datasheets/QSMP-QSBASE1-Evalkit.pdf The vendor (Karo) supports only their Yocto based Linux distro. I spent some time to prepare TF-A & Uboot, capable with booting from SD card (that is more robust approach, as I think). STM does not promote/support non-secure boot approach with SPL, they insist to use TF-A or OPTEE, so it is pretty cumbersome path, I had to pass. I think, it will be easier for me to prepare some sort of README to support customization of uboot for STM's port and dig it somewhere in SRC rather than try to post PR's in those repos... Not sure, anyway. So far I'm struggling with uart and early_printf... I'm mixing this activity with my current occupation, so I don't expect rapid progress. Thank you for clarifications! I'll try to do my best! Stan Oskar Holmlund wrote: Hi Stanislav, Please resend your message and CC the arm mailing list. It might be interesting for someone in the future ( https://lists.freebsd.org/archives/freebsd-arm/ ) otherwise they all think you stopped working on the STM32 port. You should always keep one terminal up n running % man 9 style :) https://wiki.freebsd.org/Phabricator will give you some information. Its good if you get to know the people active in the ARM area, just keep an eye on the mailinglist and you will notice some names. If you have the opportunity to join any of the conference (eurobsdcon.org, asiabsdcon.org, bsdcan.org) to get to know even more people. Join the IRC, for example on efnet #bsdmips is a good channel for ARM stuff. Start with small changes and you will get feedback. From there the experience will grow and you will get into it all. Correct, the device-tree import is from the Linux kernel and there is no prior work for the STM32MP15 SoCs. I cant find anything about the STM32MP15x in Net or OpenBSD either. Probably because the STM32MP15 is the first(?) application SoC from ST? 1) hum? Do you need that for the reviews? It should be in SRC 2) Target branch is probably main. 3) It depends, if your custom board is opensource and availble around the globe through mouser/farnell/.. I dont see any problem. Otherwise pick the board from ST that you used as a reference when you developed the custom board. For example in my day job we have a custom board built around the octavosystems OSD3358 that can be found in pocketbeagle/beaglebone black wifi. So the code thats goes into the FreeBSD project are all tested on the beaglebone boards. The stuff we need for our custom board like the device tree is keept as local patches in our inhouse build process. //Oskar 2023-10-28 14:25 skrev Stanislav Silnicki: Hi Oskar! > can you point me some guidelines to help myself to fit development process? I'm sure, there is mature dev. culture around FBSD and I'd be happy to make my contribution coherently from the beginning. > So far I'm done with setup of my account at reviews (keys, 2FA, etc.) > As I understand, there is no considerable progress with STM32, although I have noticed, there are some DTS imported into the project. > > Indeed, several major questions: 1. repo url? 2. tagret branch for patches for stm32 hw? 3. is it possible to target custom board from our project, or I have to ensure support for all dev. boards, provided by STM? > Thank you,Stan > Oskar Holmlund wrote: >> 2023-10-27 22:33 skrev Stanislav Silnicki: >>> Hello! I'm porting onto the subject hardware. So far the progress is modest, while the system boots (without console although...) One of major issues is hardcoded value inside locore-v6.S. Here is my relevant post: >> > https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438 [1] What is the best way to proceed? Patch, vendor kernel build, something else? Stan > Links: ------ >> [1] > > https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438 >> Hi Stan, >> Upload your patch to reviews.freebsd.org >> Love to see your other patches for the STM32MP15x. kquote> > //Oskar ------sinikael-?=_1-16986111093260.8140990208563574 Content-Type: text/html; format=flowed Content-Transfer-Encoding: 7bit
OK, I got the idea!

As I realize, there is a minor bug in dtc, which affects compilation of stm's originated DTBs. I think it is best to make a PR into https://github.com/davidchisnall/dtc, which I'm discussing with repo owner already. Please tell me, that I need to post PR into FBSD source tree if it is a shorter way for my fix.

My current setup is based upon QBASE1 from Karo-Electronics, but there is no goal to support/debug all peripherals, only a subset, including USB, I2C, SDMMC, DSI (and GPU, if lucky).

The vendor (Karo) supports only their Yocto based Linux distro. I spent some time to prepare TF-A & Uboot, capable with booting from SD card (that is more robust approach, as I think). STM does not promote/support non-secure boot approach with SPL, they insist to use TF-A or OPTEE, so it is pretty cumbersome path, I had to pass. I think, it will be easier for me to prepare some sort of README to support customization of uboot for STM's port and dig it somewhere in SRC rather than  ;try to post PR's in those repos... Not sure, anyway.

So far I'm struggling with uart and early_printf...

I'm mixing this activity with my current occupation, so I don't expect rapid progress.

Thank you for clarifications! I'll try to do my best!

Stan

Oskar Holmlund wrote:


Hi Stanislav,

Please resend your message and CC the arm mailing list. It might be interesting for someone in the future ( https://lists.freebsd.org/archives/freebsd-arm/ ) otherwise they all think you stopped working on the STM32 port.

You should always keep one terminal up n running % man 9 style :)
https://wiki.freebsd.org/Phabricator will give you some information.
Its good if you get to know the people active in the ARM area, just keep an eye on the mailinglist and you will notice some names. If you have the opportunity to join any of the conference (eurobsdcon.org, asiabsdcon.org, bsdcan.org) to get to know even more people.
Join the IRC, for example on efnet #bsdmips is a good channel for ARM stuff.

Start with small changes and you will get feedback. From there the experience will grow and you will get into it all.

Correct, the device-tree import is from the Linux kernel and there is no prior work for the STM32MP15 SoCs. I cant find anything about the STM32MP15x in Net or OpenBSD either.
Probably because the STM32MP15 is the first(?) application SoC from ST?


1) hum? Do you need that for the reviews? It should be in SRC
2) Target branch is probably main.
3) It depends, if your custom board is opensource and availble around the globe through mouser/farnell/.. I dont see any problem. Otherwise pick the board from ST that you used as a reference when you developed the custom board.
For example in my day job we have a custom board built around the octavosystems OSD3358 that can be found in pocketbeagle/beaglebone black wifi. So the code thats goes into the FreeBSD project are all tested on the beaglebone boards. The stuff we need for our custom board like the device tree is keept as local patches in our inhouse build process.

//Oskar

2023-10-28 14:25 skrev Stanislav Silnicki:

Hi Oskar!
> can you point me some guidelines to help myself to fit development
process? I'm sure, there is mature dev. culture around FBSD and I'd be
happy to make my contribution coherently from the beginning.
> So far I'm done with setup of my account at reviews (keys, 2FA, etc.)
> As I understand, there is no considerable progress with STM32,
although I have noticed, there are some DTS imported into the project.
> > Indeed, several major questions:
1. repo url?
2. tagret branch for patches for stm32 hw?
3. is it possible to target custom board from our project, or I have
to ensure support for all dev. boards, provided by STM?
> Thank you,Stan
> Oskar Holmlund wrote:
>> 2023-10-27 22:33 skrev Stanislav Silnicki:

quote class="gmail_quote" type="cite" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>>> Hello!


I'm porting onto the subject hardware. So far the progress is
modest,
while the system boots (without console although...)
One of major issues is hardcoded value inside locore-v6.S. Here
is my
relevant post:
>> > https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438
[1]
What is the best way to proceed? Patch, vendor kernel build,
something
else?
Stan



> Links:

------
>> [1] >
> https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438
>> Hi Stan,
>> Upload your patch to reviews.freebsd.org
>> Love to see your other patches for the STM32MP15x.

kquote>

>> //Oskar
------sinikael-?=_1-16986111093260.8140990208563574-- From nobody Sun Oct 29 21:00:45 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 4SJTMK4MHBz4yCMn for ; Sun, 29 Oct 2023 21:00:45 +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 4SJTMK2LMVz4b6v for ; Sun, 29 Oct 2023 21:00:45 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1698613245; 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=O4Xjd8WqJ8aw1+ukI7HtKSUF7a/FNW54ongVnVUWa1Q=; b=gx2yJ1JTZhbVBz3uUpwFMJ1m2p5wkCHBBuFbCWdihztxffDzBBULxNN8h9UvpV1nNl5FFF F+VnjzyOioALcg7n9/+EXMgnUdnoA1b1AZULaE3yZebheGHvuk9j/tWh3wj/DuvGGk/4ME 8cDKoOaEqSTUyq0sePqvvqeZ/4QgT23mGQX4QsV9CpO0nPDzeVUad1nBsmLqrGT5K6atz+ EoFW6ktlf+NjoWfDP2RrqwWR0HhWT8sZ8X3HuJYFkGq/lDCBtIjgc6PI3yZIzl6Y8LlYQ1 y/hnFPMGhCZYibX7TDFpRAQ++8p1/NT7hEKwiemkVzMq6wX9VHODSjL4vzxdWg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1698613245; a=rsa-sha256; cv=none; b=gf/N1b508HRwsEBeOQIZwng2PCI/0n3Jx9OEsa1YNMmHcVJsphiu1VA3L4R5DgDRCG1UUa KS/hEXpGDS8DI6VP+iwIHLnKJ+mEEJezjALTU6M87bp0gzv09FamM7ZKzWlISCUcn9R8hP BWsbBhXYcGL+XOt5IzW9lx/syfKgoMitvytwdbN26/3IB+uhGiG0Tz521QEGYnUGct0q+5 79pGhIuw/HEhbPkK+R0v48b6fFzQb6C3R6NXBkT+49AczQuvw8FCSlcfnz9vb5l/cqOKZP zRxAjZlyEymFdcZgF/CAdWp1tIte5QY6je2dmOewDkXtrw6AtP/OlcpfaLyGpg== 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 4SJTMK1S4YztH9 for ; Sun, 29 Oct 2023 21:00:45 +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 39TL0jsB098214 for ; Sun, 29 Oct 2023 21:00:45 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 39TL0j6D098213 for freebsd-arm@FreeBSD.org; Sun, 29 Oct 2023 21:00:45 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202310292100.39TL0j6D098213@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, 29 Oct 2023 21:00:45 +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="16986132450.0C3Cce8d6.95754" Content-Transfer-Encoding: 7bit --16986132450.0C3Cce8d6.95754 Date: Sun, 29 Oct 2023 21:00:45 +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 ------------+-----------+--------------------------------------------------- Open | 238576 | Raspberry Pi 3B+ "shutdown -p" does not shut off Open | 257670 | mpr(4): SAS3008 PCI-Express Fusion-MPT SAS-3: Fat 2 problems total for which you should take action. --16986132450.0C3Cce8d6.95754 Date: Sun, 29 Oct 2023 21:00:45 +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
------------+-----------+---------------------------------------------------
Open        |    238576 | Raspberry Pi 3B+ "shutdown -p" does not shut off 
Open        |    257670 | mpr(4): SAS3008 PCI-Express Fusion-MPT SAS-3: Fat

2 problems total for which you should take action.
--16986132450.0C3Cce8d6.95754-- From nobody Mon Oct 30 04:47:55 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 4SJgkM4v72z4yg1H for ; Mon, 30 Oct 2023 04:47:55 +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 4SJgkM2m3tz3XG1 for ; Mon, 30 Oct 2023 04:47:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1698641275; 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=ErjJz/3Dhu1w0IeoYG2fdxQ8r7/QIA/uzUV964VlKsw=; b=UL/0NmPXN8xYl6Jm0BrWLNGbRvhcid30a8a8kyV1luqxTnxQFfKP5KQB4gg3QOqzo7tRhA k1YnQIfSp3EbFXfvK4YyREPwqsy5V5XGm4uU4I2hrrl/miczMCQtBPl5Lp3ZzmZa9w712d obcBXfJkra2j72XiUmgCtaIBVjAmXZkDSJ0AK0/HeyEwotYz7OfxT8NlMlMaZlo1E0SOme /y46YWLkVXsTzeRR2DzPucWJAny6vBhTdiwA5AD46ZGsuaedh5GOeh4ruVpbKoub6Cu3Hy uCVCs3FIVHrDKvuCTB1CvYXBnBz6lwO1O/4N3B1jrOJ/v9NMXaOBAYRtAr3ySA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1698641275; a=rsa-sha256; cv=none; b=XXGsHNq2Ji9ILkifkRR8iz99ybd3Z502O/TBilj8lx5O1W+F6WoCjc419uQHpgg8Ht842h QNLDcKH0/b3DAbVrKscbRU5mIbNSspqt8PBqC4IaUFYl1sN6HIvEsiPHG1IzY8dvApcyYX t3XBahX8RadeEvChKuuOy9TMPFQSXUZiQ9K/lvgUXk3IOEiXOaXncEKpNgv7oWSOvAaQDO ZHBYn4ASRO/jIhegUWMW+reFwNCIh8RpikYYm0s5eWCECAvXcoW8r25Kp4UIAvxOqYBXbL b0MEqSP67b/jWi7VIOdmi1Qecg1eQYKUdoONCdAGbliMyf/wcnQ0neqiIzfq5w== 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 4SJgkM1p4Lz16Z0 for ; Mon, 30 Oct 2023 04:47:55 +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 39U4ltbD002154 for ; Mon, 30 Oct 2023 04:47:55 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 39U4ltMw002152 for freebsd-arm@FreeBSD.org; Mon, 30 Oct 2023 04:47:55 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 274804] [PATCH] KERNCONF=GENERIC-VCHIQ enable HDMI AUDIO on Raspberry Pi 4B,400,3B Date: Mon, 30 Oct 2023 04:47:55 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 14.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: wb7odyfred@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: 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=3D274804 Bug ID: 274804 Summary: [PATCH] KERNCONF=3DGENERIC-VCHIQ enable HDMI AUDIO on Raspberry Pi 4B,400,3B Product: Base System Version: 14.0-STABLE Hardware: arm64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: wb7odyfred@yahoo.com Created attachment 245983 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D245983&action= =3Dedit tar.gz compressed file containing several patch files. example CLI patch= < vchiq_arm.c.patch Testing Support of Marcos Patch review D37878=20 https://reviews.freebsd.org/D37878 for Supporting Raspberry Pi 4B HDMI AUDIO output on HDMI TV Speakers. Must be a newer code commit review somewhere. Does someone build Raspberry Pi 4B FreeBSD kernel code with GENERIC-VCHIQ = for a test? https://forums.raspberrypi.com/viewtopic.php?t=3D343233 Fred Finster post = to Raspberry Pi Forums on using Marcos patch file. https://bsdnow.tv/489 minutes 12:00-17:00 Speak about the above forums Pos= t. # Check for existence of configuration file GENERIC-VCHIQ ls -l /usr/src/sys/arm64/conf/GENERIC-VCHIQ # Build the kernel make -j4 buildkernel TARGET_ARCH=3Daarch64 KERNCONF=3DGENERIC-VCHIQ many errors of Format string size not matching, the argument size being pas= sed Since most of these error where in debug log messages=20 Changed (unsigned int) into (unsigned long) Changed format string from %x to %lx vchiq_core.h=20 added for arm64 bit 'dsb(sy)' where for armv7a 'dsb()' #if defined(__arm64__) dsb(sy) #else=20=20 dsb() #endif=20 Yes, I had Compile fail error for ROCKPI device 'dsb()' so changed both s= ides of logic if dsb(sy) else dsb(sy) endif Yes, know that is bad form, to NOT support armv7a 32bit C functions. Someone smarter than I, can offer code change to make 64/32 bit function proper. Happy with the FreeBSD.org/where RPI arm64 snapshot images, so far. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Mon Oct 30 14:31: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 4SJwhB5S9Cz4y0mx for ; Mon, 30 Oct 2023 14:31:54 +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 4SJwhB2J8kz3Hlq for ; Mon, 30 Oct 2023 14:31:54 +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 39UEVo61090150 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 30 Oct 2023 07:31:50 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 39UEVoOp090149; Mon, 30 Oct 2023 07:31:50 -0700 (PDT) (envelope-from fbsd) Date: Mon, 30 Oct 2023 07:31:50 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: Stable/14 dropping ssh connections to FT232 usb-serial adapter Message-ID: References: <33D1AACD-62FB-444A-868C-B8DE92A7BF50@yahoo.com> <5210D449-A4E6-455B-A1BB-754BA3501C3F@yahoo.com> <90CBBDDB-654B-402B-96E8-C16545BFE011@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: <90CBBDDB-654B-402B-96E8-C16545BFE011@yahoo.com> X-Spamd-Bar: ---- 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-Rspamd-Queue-Id: 4SJwhB2J8kz3Hlq On Sun, Oct 29, 2023 at 11:47:14AM -0700, Mark Millard wrote: > > I take that wording to mean that the ssh session into: > > 50.1.20.26 www.zefox.com Pi2 releng/14 > > fails, Correct. > not the ssh session into: > > 50.1.20.27 www.zefox.net Pi2 12.3 2303 usb-serial----50.1.20.26 > > If I have that wrong, my wording below would need adjustment. > > So my suggestion would be to have an extra ssh session to the releng/14 > RPi2B v1.1 in order to see if both ssh's have problems at the same time. > I'm not suggesting a 2nd serial connection: the extra ssh session would > just sit at a releng/14 shell prompt, for example. > > On failure, a question would be if the extra ssh session can still > execute commands in that shell or not. > > If only one ssh session of the pair fails, repeated testing to check if > it is always the same one of the pair would be appropriate (always and > only the one doing tip?). > As a rule, in addition to the ssh session running tip there's also an ssh session running other tasks, often in the background, like buildworld. Those didn't normally drop. > This might help issolate if tip is involved in initiating the ssh falure > or not. tip would likely stop if the ssh session failed for other reasons. > > I recommend the experiments be with "ssh -e none" and "tip -n -v", even if > the likes of, say, "tip -n" is unreasonable in general use. > > > There are usually half a dozen ssh connections > > running interactive shells from the RasPiOS host to random FreeBSD Pi's > > and as a rule they only drop when I crash or reboot the RasPiOS host. > > I'm not really after what happens across multiple RPi*'s in my > suggestion. I'm after the pair of ssh sessions into the same > RPi* instead --just for the target RPi* that gets the failure. At the moment the relevant ssh session uses -e none and tip uses -n -v, and the session stayed up all night. However, there's another change: When preparing to post the link to the network/serial map it dawned on me that the host in question was still on the wired LAN (for configuration), not the public WAN. To my thinking that really shouldn't matter but maybe it does, and the wired WAN is the ultimate destination for the host anyway, so I moved it. The wired LAN doesn't see much use, so its performance isn't well characterized. Apologies for the last-minute revelation 8-( Thanks for writing, bob prohaska From nobody Tue Oct 31 23:55: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 4SKn8s2cBlz4y6cS for ; Tue, 31 Oct 2023 23:56:13 +0000 (UTC) (envelope-from stanislav.silnicki@mailgate.us) Received: from mailgate.us (mailgate.us [185.72.246.236]) by mx1.freebsd.org (Postfix) with ESMTP id 4SKn8r26HDz3Fv1 for ; Tue, 31 Oct 2023 23:56:12 +0000 (UTC) (envelope-from stanislav.silnicki@mailgate.us) Authentication-Results: mx1.freebsd.org; dkim=fail ("body hash did not verify") header.d=mailgate.us header.s=mail header.b="s5Fz9F/k"; spf=pass (mx1.freebsd.org: domain of stanislav.silnicki@mailgate.us designates 185.72.246.236 as permitted sender) smtp.mailfrom=stanislav.silnicki@mailgate.us; dmarc=none Received: from localhost (api.telegram.org [192.168.2.1]) by mailgate.us (Postfix) with ESMTPSA id 558D0A3AB0 for ; Wed, 1 Nov 2023 02:56:03 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailgate.us; s=mail; t=1698796564; bh=E8agSUwB7gEggyBI9Muzh5t1EuPXfZF/i1XEbgyZ0mQ=; h=From:Subject:To:References:Date; b=s5Fz9F/k44OTPaWI8tc7ug/KFFM/0pSReNV3jFYBWQo6qvtCAFehVbGxCqkwSg95G H3utJC9HMCydR0vTaBcX733FM362giEhEd+3utdYp2SNQlDTFa74FxLpK4tOJduHgQ PqLMuM6vetrw8KxLdoIHXa3icQ0Oia+295KRtcuI= Content-Type: multipart/alternative; boundary="----sinikael-?=_1-16987965570640.08956020169587231" From: Stanislav Silnicki Subject: Re: STM32MP157 X-Type: replyAll To: "freebsd-arm" User-Agent: Desktop Message-Id: <0dab0fc75864.77e1118ea80bb@mailgate.us> References: <4d6bf0126f4fb.c24cc5f2fa47c@mailgate.us> <00cab7929791c.8af55c0bd1d5f@mailgate.us> <5d65957f4c04a4bec7ae6ef5469b149c@ohdata.se> Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Oct 2023 23:55:56 +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 X-Spamd-Result: default: False [-1.44 / 15.00]; R_DKIM_REJECT(1.00)[mailgate.us:s=mail]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-1.00)[-0.999]; SUBJ_ALL_CAPS(0.75)[10]; R_SPF_ALLOW(-0.20)[+ip4:185.72.246.236/32]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_NO_TLS_LAST(0.10)[]; XM_UA_NO_VERSION(0.01)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[mailgate.us:-]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:47447, ipnet:185.72.246.0/24, country:DE]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[mailgate.us]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4SKn8r26HDz3Fv1 X-Spamd-Bar: - ------sinikael-?=_1-16987965570640.08956020169587231 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: 7bit Hello, I need an advice on the intial addresses layout when booting the kernel. As I understand, ubldr is the proper way to boot the kernel. What is the correct address to load it, given that I wand to keep default KERNVIRTADDR (=0xc0000000) intact? The u-boot loads ubldr this way in my current setup: // FreeBSD version of environment env_set("baudrate", "115200"); env_set("console", "ttyS0,115200"); env_set("stderr", "serial"); env_set("stdin", "serial"); env_set("stdout", "serial"); env_set("autostart", "yes"); env_set("loaderdev", "mmc 1"); // fbsd's ubldr treats our second mmc at index 1 env_set("bootcmd", "fatload mmc 2 0xc0000000 ubldr && bootelf"); then ubldr leads the kernel from mmc and passes it the control: Loading kernel... /boot/kernel/kernel text=0x1b4 text=0x5b8530 text=0x17d91c data=0xa4a60 data=0x0+0x20c000 0x4+0x88810+0x4+0xe9d98| Loading configured modules... can't find '/boot/entropy' can't find '/etc/hostid' Using DTB compiled into kernel. Kernel entry at 0xc0400200... Kernel args: (null) Then I could correctly pass the init of MMU and get into translated mode only with setting KERNVIRTADDR = 0xc4000000. It looks like kernel and loader clash somehow. So, just need to understand what is best option to load ubldr to? Will it affect further routines? Stan Stanislav Silnicki wrote: OK, I got the idea! As I realize, there is a minor bug in dtc, which affects compilation of stm's originated DTBs. I think it is best to make a PR into https://github.com/davidchisnall/dtc, which I'm discussing with repo owner already. Please tell me, that I need to post PR into FBSD source tree if it is a shorter way for my fix. My current setup is based upon QBASE1 from Karo-Electronics, but there is no goal to support/debug all peripherals, only a subset, including USB, I2C, SDMMC, DSI (and GPU, if lucky). https://www.karo-electronics.com/fileadmin/download/Datasheets/QSMP-QSBASE1-Evalkit.pdf The vendor (Karo) supports only their Yocto based Linux distro. I spent some time to prepare TF-A & Uboot, capable with booting from SD card (that is more robust approach, as I think). STM does not promote/support non-secure boot approach with SPL, they insist to use TF-A or OPTEE, so it is pretty cumbersome path, I had to pass. I think, it will be easier for me to prepare some sort of README to support customization of uboot for STM's port and dig it somewhere in SRC rather than ;try to post PR's in those repos... Not sure, anyway. So far I'm struggling with uart and early_printf... I'm mixing this activity with my current occupation, so I don't expect rapid progress. Thank you for clarifications! I'll try to do my best! Stan Oskar Holmlund wrote: Hi Stanislav, Please resend your message and CC the arm mailing list. It might be interesting for someone in the future ( https://lists.freebsd.org/archives/freebsd-arm/ ) otherwise they all think you stopped working on the STM32 port. You should always keep one terminal up n running % man 9 style :) https://wiki.freebsd.org/Phabricator will give you some information. Its good if you get to know the people active in the ARM area, just keep an eye on the mailinglist and you will notice some names. If you have the opportunity to join any of the conference (eurobsdcon.org, asiabsdcon.org, bsdcan.org) to get to know even more people. Join the IRC, for example on efnet #bsdmips is a good channel for ARM stuff. Start with small changes and you will get feedback. From there the experience will grow and you will get into it all. Correct, the device-tree import is from the Linux kernel and there is no prior work for the STM32MP15 SoCs. I cant find anything about the STM32MP15x in Net or OpenBSD either. Probably because the STM32MP15 is the first(?) application SoC from ST? 1) hum? Do you need that for the reviews? It should be in SRC 2) Target branch is probably main. 3) It depends, if your custom board is opensource and availble around the globe through mouser/farnell/.. I dont see any problem. Otherwise pick the board from ST that you used as a reference when you developed the custom board. For example in my day job we have a custom board built around the octavosystems OSD3358 that can be found in pocketbeagle/beaglebone black wifi. So the code thats goes into the FreeBSD project are all tested on the beaglebone boards. The stuff we need for our custom board like the device tree is keept as local patches in our inhouse build process. //Oskar 2023-10-28 14:25 skrev Stanislav Silnicki: Hi Oskar! > can you point me some guidelines to help myself to fit development process? I'm sure, there is mature dev. culture around FBSD and I'd be happy to make my contribution coherently from the beginning. > So far I'm done with setup of my account at reviews (keys, 2FA, etc.) > As I understand, there is no considerable progress with STM32, although I have noticed, there are some DTS imported into the project. > > Indeed, several major questions: 1. repo url? 2. tagret branch for patches for stm32 hw? 3. is it possible to target custom board from our project, or I have to ensure support for all dev. boards, provided by STM? > Thank you,Stan > Oskar Holmlund wrote: >> 2023-10-27 22:33 skrev Stanislav Silnicki: >>> Hello! I'm porting onto the subject hardware. So far the progress is modest, while the system boots (without console although...) One of major issues is hardcoded value inside locore-v6.S. Here is my relevant post: >> > https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438 [1] What is the best way to proceed? Patch, vendor kernel build, something else? Stan > Links: ------ >> [1] > > https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438 >> Hi Stan, >> Upload your patch to reviews.freebsd.org >> Love to see your other patches for the STM32MP15x. kquote> > //Oskar ------sinikael-?=_1-16987965570640.08956020169587231 Content-Type: text/html; format=flowed Content-Transfer-Encoding: 7bit
Hello, I need an advice on the intial addresses layout when booting the kernel.

As I understand, ubldr is the proper way to boot the kernel.
What is the correct address to load it, given that I wand to keep default KERNVIRTADDR (=0xc0000000) intact?

The u-boot loads ubldr this way in my current setup:

  // FreeBSD version of environment
  env_set("baudrate", "115200");
  env_set("console", "ttyS0,115200");
  env_set("stderr", "serial");
  env_set("stdin", "serial");
  env_set("stdout", "serial");
  env_set("autostart", "yes");
  env_set("loaderdev", "mmc 1"); // fbsd's ubldr treats our second mmc at index 1
  env_set("bootcmd", "fatload mmc 2 0xc0000000 ubldr && bootelf");

then ubldr leads the kernel from mmc and passes it the control:

Loading kernel...
/boot/kernel/kernel text=0x1b4 text=0x5b8530 text=0x17d91c data=0xa4a60 data=0x0+0x20c000 0x4+0x88810+0x4+0xe9d98|
Loading configured modules...
can't find '/boot/entropy'
can't find '/etc/hostid'
Using DTB compiled into kernel.
Kernel entry at 0xc0400200...
Kernel args: (null)

Then I could correctly pass the init of MMU and get into translated mode only with setting KERNVIRTADDR = 0xc4000000. It looks like kernel and loader clash somehow.

So, just need to understand what is best option to load ubldr to? Will it affect further routines?

Stan


Stanislav Silnicki wrote:


OK, I got the idea!

As I realize, there is a minor bug in dtc, which affects compilation of stm's originated DTBs. I think it is best to make a PR into https://github.com/davidchisnall/dtc, which I'm discussing with repo owner already. Please tell me, that I need to post PR into FBSD source tree if it is a shorter way for my fix.

My current setup is based upon QBASE1 from Karo-Electronics, but there is no goal to support/debug all peripherals, only a subset, including USB, I2C, SDMMC, DSI (and GPU, if lucky).

The vendor (Karo) supports only their Yocto based Linux distro. I spent some time to prepare TF-A & Uboot, capable with booting from SD card (that is more robust approach, as I think). STM does not promote/support non-secure boot approach with SPL, they insist to use TF-A or OPTEE, so it is pretty cumbersome path, I had to pass. I think, it will be easier for me to prepare some sort of README to support customization of uboot for STM's port and dig it somewhere in SRC rather than  ; ;try to post PR's in those repos... Not sure, anyway.

So far I'm struggling with uart and early_printf...

I'm mixing this activity with my current occupation, so I don't expect rapid progress.

Thank you for clarifications! I'll try to do my best!

Stan

Oskar Holmlund wrote:


Hi Stanislav,

Please resend your message and CC the arm mailing list. It might be interesting for someone in the future ( https://lists.freebsd.org/archives/freebsd-arm/ ) otherwise they all think you stopped working on the STM32 port.

You should always keep one terminal up n running % man 9 style :)
https://wiki.freebsd.org/Phabricator will give you some information.
Its good if you get to know the people active in the ARM area, just keep an eye on the mailinglist and you will notice some names. If you have the opportunity to join any of the conference (eurobsdcon.org, asiabsdcon.org, bsdcan.org) to get to know even more people.
Join the IRC, for example on efnet #bsdmips is a good channel for ARM stuff.

Start with small changes and you will get feedback. From there the experience will grow and you will get into it all.

Correct, the device-tree import is from the Linux kernel and there is no prior work for the STM32MP15 SoCs. I cant find anything about the STM32MP15x in Net or OpenBSD either.
Probably because the STM32MP15 is the first(?) application SoC from ST?


1) hum? Do you need that for the reviews? It should be in SRC
2) Target branch is probably main.
3) It depends, if your custom board is opensource and availble around the globe through mouser/farnell/.. I dont see any problem. Otherwise pick the board from ST that you used as a reference when you developed the custom board.
For example in my day job we have a custom board built around the octavosystems OSD3358 that can be found in pocketbeagle/beaglebone black wifi. So the code thats goes into the FreeBSD project are all tested on the beaglebone boards. The stuff we need for our custom board like the device tree is keept as local patches in our inhouse build process.

//Oskar

2023-10-28 14:25 skrev Stanislav Silnicki:

Hi Oskar!
> can you point me some guidelines to help myself to fit development
process? I'm sure, there is mature dev. culture around FBSD and I'd be
happy to make my contribution coherently from the beginning.
> So far I'm done with setup of my account at reviews (keys, 2FA, etc.)
> As I understand, there is no considerable progress with STM32,
although I have noticed, there are some DTS imported into the project.
> > Indeed, several major questions:
1. repo url?
2. tagret branch for patches for stm32 hw?
3. is it possible to target custom board from our project, or I have
to ensure support for all dev. boards, provided by STM?
> Thank you,Stan
> Oskar Holmlund wrote:
>> 2023-10-27 22:33 skrev Stanislav Silnicki:

quote class="gmail_quote" type="cite" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>>> Hello!


I'm porting onto the subject hardware. So far the progress is
modest,
while the system boots (without console although...)
One of major issues is hardcoded value inside locore-v6.S. Here
is my
relevant post:
>> > https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438
[1]
What is the best way to proceed? Patch, vendor kernel build,
something
else?
Stan



> Links:

------
>> [1] >
> https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438
>> Hi Stan,
>> Upload your patch to reviews.freebsd.org
>> Love to see your other patches for the STM32MP15x.

kquote>

>> //Oskar
------sinikael-?=_1-16987965570640.08956020169587231-- From nobody Wed Nov 1 08:27: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 4SL0WH33DQz500M6 for ; Wed, 1 Nov 2023 08:27:55 +0000 (UTC) (envelope-from atma@convalesco.org) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SL0WG5RDXz3DRJ for ; Wed, 1 Nov 2023 08:27:54 +0000 (UTC) (envelope-from atma@convalesco.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=convalesco.org header.s=fm3 header.b=Zd5+hf2A; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=B3WH2dyD; spf=pass (mx1.freebsd.org: domain of atma@convalesco.org designates 64.147.123.25 as permitted sender) smtp.mailfrom=atma@convalesco.org; dmarc=pass (policy=reject) header.from=convalesco.org Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 34CE0320093A for ; Wed, 1 Nov 2023 04:27:53 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 01 Nov 2023 04:27:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=convalesco.org; h=cc:content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:sender:subject:subject:to:to; s=fm3; t=1698827272; x=1698913672; bh=7NgU+vuysb2D0FM6M9vGzIhUD xN+RgMCGjYCEXlw/OE=; b=Zd5+hf2AfRVwEBcEo3fd7peZJcaMvtSjn0p+acL2U grw4v0gGwiTlIcx44zkpm4/56Ynqi+QyICoX5X3WuUb3JBtKWBMoLEuhXxhRzXdM ihNERe/r+5MDeZ2FKFkBX8b5DBmwMHg67U1P8YUCLzNuiiZQE68lHrqa11qm30Rx DEzGdneLBFCOVyTWYVwhB0pHLMf5FSbGnx4zh3Nj/4MMJpB1ddrJXmvPZlRlhfdj eD/dJgC83UiKpDuqr8SJrmLiIZR8egvF0z95m3V87J18ZPUntQ8BeUqe+3gzUGcD bK8yhdyKI8YV/t6AivR7OUi8wmgTp6zhbXIFvYZ1QJiug== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1698827272; x=1698913672; bh=7NgU+vuysb2D0FM6M9vGzIhUDxN+RgMCGjY CEXlw/OE=; b=B3WH2dyDaanvvxWeDSBBhkwFeXBQC2uKFZkQ0VNaVNpVqAO8Q5o bi/z0/MpxDZ4Z5ZlPSMlxFOoASqKsrkV0caF8kMUGxdusQZ8Keea1+VSXCHA3q4X rxKqVY5mcPRMpLJsHdzYZi+083lTgHVS74M8yF0ulLUM8abic8aZYeb7Y4EYndzk iUD86S8BA1BZgqcRFsz+IbiQhzs706TQJjDHQznGWmE6W+9J2V8lQGXk0b2/qeOi tIHzVyHXebyGl1CkCF95j9QqxvXoJJanA5ftdelCI2NujEXi74d/7TpB2GjxyfHA vBLXRVQX3qOeNNvBo2NOCt1k+VwDPmXdrWg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddtfedguddujecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhephfgtggfukfffvffosegrtdhmre hhtdejnecuhfhrohhmpefrrghnrghgihhothhishcutehtmhgrthiiihguihhsuceorght mhgrsegtohhnvhgrlhgvshgtohdrohhrgheqnecuggftrfgrthhtvghrnhepkedtteeigf ekuefhleettdetfeffkedufefhffegleetieffffdvkeeikeduffeinecuffhomhgrihhn pegtohhnvhgrlhgvshgtohdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpegrthhmrgestghonhhvrghlvghstghordhorhhg X-ME-Proxy: Feedback-ID: if8a042fc:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Wed, 1 Nov 2023 04:27:51 -0400 (EDT) From: Panagiotis Atmatzidis Content-Type: multipart/alternative; boundary="Apple-Mail=_6E189B1B-A941-4A61-A334-5E7517DE59CD" 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 \(3696.120.41.1.4\)) Subject: tailscaled init script doesn't create tun0 Message-Id: <2328529D-F25F-44D0-B78D-6CED15A2974B@convalesco.org> Date: Wed, 1 Nov 2023 10:27:49 +0200 To: "freebsd-arm@freebsd.org" X-Mailer: Apple Mail (2.3696.120.41.1.4) X-Spamd-Result: default: False [-4.80 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[convalesco.org,reject]; RWL_MAILSPIKE_VERYGOOD(-0.20)[64.147.123.25:from]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.25]; R_DKIM_ALLOW(-0.20)[convalesco.org:s=fm3,messagingengine.com:s=fm3]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.25:from]; MID_RHS_MATCH_FROM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DKIM_TRACE(0.00)[convalesco.org:+,messagingengine.com:+]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_EQ_ADDR_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@FreeBSD.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4SL0WG5RDXz3DRJ X-Spamd-Bar: ---- --Apple-Mail=_6E189B1B-A941-4A61-A334-5E7517DE59CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, I installed =E2=80=9Ctailscale=E2=80=9D application as a binary package = in FreeBSD 13.2 running on RPi2. The architecture is arm7. When adding the the application to startup via `sysrc = tailscaled_enable=3D\=E2=80=9DYES\=E2=80=9D` the application hangs = because device tun0 is not being created. Once the device has been created manually, tailscaled will rename the = device to =E2=80=9Ctailscale0=E2=80=9D. The two existing flags =E2=80=9Ctailscaled_up_args=E2=80=9D and = =E2=80=9Ctailscaled_tun_dev=E2=80=9D cannot be used to create the = device. For the init to work as expected, I added these lines: ``` diff tailscaled /usr/local/etc/rc.d/tailscaled 67a68 > start_precmd=3D"${name}_prestart" 70a72,80 > > > tailscaled_prestart() > { > if [ ! -c /dev/tun ]; then > logger -s -t tailscale "Interface /dev/tun0 not found. = Creating /dev/tun0" > /sbin/ifconfig tun0 create > fi > } ``` I have no idea if this happens to other architectures and I=E2=80=99m = not sure if this should be handled by the init script or the application = itself. Kind regards, -- Panagiotis (atmosx) Atmatzidis email: atma@convalesco.org URL: http://www.convalesco.org GnuPG ID: 0x1A7BFEC5 gpg --keyserver pgp.mit.edu --recv-keys 1A7BFEC5 "Everyone thinks of changing the world, but no one thinks of changing = himself.=E2=80=9D - Leo Tolstoy --Apple-Mail=_6E189B1B-A941-4A61-A334-5E7517DE59CD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello,

I = installed =E2=80=9Ctailscale=E2=80=9D application as a binary package in = FreeBSD 13.2 running on RPi2. The architecture is arm7.

When adding the the = application to startup via `sysrc tailscaled_enable=3D\=E2=80=9DYES\=E2=80= =9D` the application hangs because device tun0 is not being = created.
Once the device has been created manually, = tailscaled will rename the device to =E2=80=9Ctailscale0=E2=80=9D.

The two existing = flags =E2=80=9Ctailscaled_up_args=E2=80=9D and =E2=80=9Ctailscaled_tun_dev= =E2=80=9D cannot be used to create the device.

For the init to work as expected, I = added these lines:

```
diff tailscaled = /usr/local/etc/rc.d/tailscaled
67a68
> start_precmd=3D"${name}_prestart"
70a72,80
>
>
> = tailscaled_prestart()
> {
> = if [ ! -c /dev/tun ]; then
> = logger -s -t tailscale "Interface /dev/tun0 not found. Creating = /dev/tun0"
> /sbin/ifconfig tun0 = create
> fi
> = }
```

I have no idea if this happens to other = architectures and I=E2=80=99m not sure if this should be handled by the = init script or the application itself.


Kind= regards,

--
Panagiotis (atmosx) Atmatzidis

email: atma@convalesco.org
URL: = http://www.convalesco.org
GnuPG ID: 0x1A7BFEC5
gpg --keyserver pgp.mit.edu --recv-keys 1A7BFEC5

"Everyone thinks of changing = the world, but no one thinks of changing himself.=E2=80=9D - Leo = Tolstoy





= --Apple-Mail=_6E189B1B-A941-4A61-A334-5E7517DE59CD-- From nobody Thu Nov 2 15:01:19 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 4SLnBt0xFmz4yYT7 for ; Thu, 2 Nov 2023 15:01:26 +0000 (UTC) (envelope-from void@f-m.fm) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (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 4SLnBs2qRjz4ZSt for ; Thu, 2 Nov 2023 15:01:25 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=lOOirEWB; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=ZsPOvKRu; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.26 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id AAF8B5C00AD for ; Thu, 2 Nov 2023 11:01:24 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 02 Nov 2023 11:01:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:sender:subject:subject:to:to; s=fm3; t=1698937284; x=1699023684; bh=EquFvdBafOZ3IVx7QDX1Ui3gi CfC7slBTwVA+c7H10c=; b=lOOirEWBpb+8dE6UYk2DKnpb61LKIXrJj3uAV+t2u 9+3GqjdrleLyps9KBw9ZYz4AQz2Z35IsS+tvchVqLBsvI+vWFlZ+yLuMRK1+B+GT VIxcqC+BRd2q7TSSKO9yP+kFR3Q0sUgpzT4H/YkVGcrt8u/vKGZ017f8prf8xmL7 SwN2ZhMF9qZWej9OwiJfw8IqfwsN8qJGNB5vU1cg9QH4VhWQRgC5MVoH8XeGKnTy /+61c3K37aoUNNOOmUMUaTDjlTHe/ikRzgCUsELofSgGBrOc7cnKjke9hbwJ+pJM JDGk4WKFE05wT8d19VAjpAIVK3w+L5C6iy4nVDXD1IXqg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1698937284; x=1699023684; bh=EquFvdBafOZ3IVx7QDX1Ui3giCfC7slBTwV A+c7H10c=; b=ZsPOvKRu4MI3Z9ihoENhQCv1ka9Y8BRsLBOnpZH8H8vVW5NcwE5 w/m//6P8AUKmh27cti9biWo86FEMVXydNreWiVDiFmaZm+Oz9+YPNz7jwUpSGPGx 6q8whSxHALZV2GDRhlUzvsUsRCkc/OW00RD3owlmvg+PmDG7cnVL5mdlZCcxzhd5 Zv5iBzwCS8AyS8cCU7vPFEsNSVp+H2U6rtngrnOkJHajXXgGwT2l67KBfNfOr/iP vK4jc0WQ37yoCCXKw2SswZUEoKNsqb2+sJ0cGL3yDtkHFGd2R267IUjJmAx7CYiY Hd+tjeREvbBgfFt3VjXDdyToEvv3rffmX1Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddtiedgjedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkgggtugesthdtredttd dtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthht vghrnhepveduffeivdfffffghfegfeejfefftdeiteehteekfefhvdefgfettdeuheegff eunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhho ihgusehfqdhmrdhfmh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Thu, 2 Nov 2023 11:01:24 -0400 (EDT) Date: Thu, 2 Nov 2023 15:01:19 +0000 From: void To: freebsd-arm@freebsd.org Subject: usb2 problems when connecting multiple devices Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org 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; format=flowed Content-Disposition: inline X-Spamd-Result: default: False [-4.70 / 15.00]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.26]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[66.111.4.26:from]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.26:from]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4SLnBs2qRjz4ZSt X-Spamd-Bar: ---- I've noticed that when more than one device is connected to the onboard usb2 ports, one device's (signalling? i guess) interferes with the other, knocking it offline. It's happened in a number of contexts, only with this hardware: 1. where the os is 13-stable 2. recent 14-stable 3. usb2 is keyboard & wireless mouse 4. usb2 is run0: MAC/BBP RT5390 firmware RT3071 wlan0 & plain usb2 cable connecting to a UPS. 5. the pi4 has the recommended 3.1A PSU At the moment, I don't have a spare usb2 hub to plug into a usb2 port. I've worked around the situation previously, either by using a powered usb3 hub into a usb3 port and plugging the usb2 devices into the hub, and/or using just one usb2 device in one usb2 port and leaving the other on-board usb2 port empty. But both usb ports should be usable and not knock each other offline. How can I capture relevant information for this for a PR? -- From nobody Thu Nov 2 22:12: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 4SLymZ05dVz4yW1G for ; Thu, 2 Nov 2023 22:12:46 +0000 (UTC) (envelope-from j.novak@netsystem.cz) Received: from EUR02-VI1-obe.outbound.protection.outlook.com (mail-vi1eur02on2123.outbound.protection.outlook.com [40.107.241.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SLymX0dvmz4b3k for ; Thu, 2 Nov 2023 22:12:42 +0000 (UTC) (envelope-from j.novak@netsystem.cz) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=netsystem.cz header.s=selector2 header.b=KAqoVRdc; arc=pass ("microsoft.com:s=arcselector9901:i=1"); spf=pass (mx1.freebsd.org: domain of j.novak@netsystem.cz designates 40.107.241.123 as permitted sender) smtp.mailfrom=j.novak@netsystem.cz; dmarc=none ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jbPLcjK3Wil7BTFMiqjmFRoNgKCirjal6ZrmFzgukNjIAsW3DhGG5D7vTYH0Q0NzKP7Pa+mcDE9/K7IPaHf9Cqfb5eQi/S74NkvQe3vZd86YOsGD1kmkrScETP5JvMhqBUKhjOanWgG8US1EG1MXAFdHaVsLXSPZ28E1OQmUad1B/xFlE1zbpfdUOIyaAivnVVOS0SaqIfO2n613k+yaQwKBdhcWegOjRswkTqxUr87hr6nz1lcBG+jqWwMX8UG+PSjeC5Bs8/C89llhUf0AzSQMAUJyHquBVBGquGV/u4PCIgiFttX9FVage3jJFuFyIH2w1cP/vCvMRQ4VRdL55Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1SY5FKw+wpYAMQGKtv2Pm7FmvhYa3CBDr1cuFsYYdo4=; b=I8SkMN1NfHKEiXBVdFuh9LsRTcfLT4aOjEWYO1WQ0NOsclYwSzUiXRLv5lS4RZ8b2/tOp3adUOMLtRW3Vef1eeG3pkrQuYZjopW9DP59wTiEfZTuN0l3d4RBZMUeOJmmJnq0plNxEVpuPq4XEmZvHiTaak9XJqRzy506ic7EeLHBauDMNDBD6hHE+Cc+4CEDlw1ISapy1Z4cDIs5O1iXLlEYumwgO1LPysC9Ay7e4wRaKpjl4BnCYK+Uoa/tNvXJd2Vlt7Voa4topBj1kJLOETTj21pWPDomYRkyHAzxt9gZ9zhs1RHZWsnhGeblTRW2pe0o7umCKZEVwoBEWG9IQw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=netsystem.cz; dmarc=pass action=none header.from=netsystem.cz; dkim=pass header.d=netsystem.cz; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netsystem.cz; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1SY5FKw+wpYAMQGKtv2Pm7FmvhYa3CBDr1cuFsYYdo4=; b=KAqoVRdc0TpUPQWCNUslLMSQdft4xJ9upXKzW07EqYtpAvTeNurZtlNnKrVzLxd0OzjkyubsK11yF+iovQ5Xpd6rQRuFnm2yWHYTRDz5y5aMkybr/dfsUFkfjXvv8J5NHim1/Sx3R/NUOo5dKetudMK2kOVCiPYx/gwunHc2zas= Received: from AM9PR04MB8793.eurprd04.prod.outlook.com (2603:10a6:20b:408::22) by DU0PR04MB9228.eurprd04.prod.outlook.com (2603:10a6:10:353::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6954.19; Thu, 2 Nov 2023 22:12:40 +0000 Received: from AM9PR04MB8793.eurprd04.prod.outlook.com ([fe80::6777:c8e6:755a:461b]) by AM9PR04MB8793.eurprd04.prod.outlook.com ([fe80::6777:c8e6:755a:461b%6]) with mapi id 15.20.6954.019; Thu, 2 Nov 2023 22:12:39 +0000 Message-ID: <24603490-01de-464d-ba15-1ffc097cecb8@netsystem.cz> Date: Thu, 2 Nov 2023 23:12:37 +0100 User-Agent: Mozilla Thunderbird Subject: Re: No sound card on Olimex A20 SOM EVB with FreeBSD 12.4 Content-Language: cs To: Emmanuel Vadot Cc: freebsd-arm@freebsd.org References: <6cbe8605-eb58-4388-a89f-b6009b8d2df0@netsystem.cz> <20231028065848.d3506101a351d8186139a5d0@bidouilliste.com> From: Jirka Novak Autocrypt: addr=j.novak@netsystem.cz; keydata= xsFNBGUTUc0BEAC2t33dm/LrTEerga4rj38NPl85p29s/9NwWUP9kompGA7sViLzOvwvMxLL KviClYR11gi3BBzskj4tECSxmDk93HRz8YeBOJodK0wvXeMQncAd10t7l4ONvmDO0hC5BqWa Vir34pdZkKZjWDoJBR7MmN3Hy8MC8MS7cIuEqG1Dtar4t7bQp5ndddBNGVhMjpS7NeP/iX0i J9rzAEz93NAEMfP4irDmffSHpvqyDKgHn0tTkOhjo13zyKYTCU0PIPwQrLIfIu43XZb361Zr CfIGIYBgSxFaw2wRbU1WbOZQYAnWD5kJ763rvtPEZs+MoxZci2vKBpR3lbWWvniV12OMqViF b7S/fcCDW7VJm4NOFTeysQ6b1Wv48MTgNcSeuaSUb0C44689BxSsS8x4EMikQDFve23PN5I/ IMVHkOxPOpNHKLHUMighTs4L7mJHX1gEESe9huSIXbBExLQjNcd+yPqU439+ZZRCmBqF27fN m+OQAWEmfVJnODupx+dUDrv6wgfHXw0QoV+yVp80tOYbIoZZ1yPMsdCuNULJgdT1W/ikPO13 VJCpDmAenELTKYtSEIbrtYG614z+U5ZQJLG5VraVQmeAf+bu6w5QkutkTDZyGlc4bO8hRLMh iOMbXqSxAceLevmV2pMtxOnfroTh+lNxv3Ii9mPC1t1V/IKhUwARAQABzSJKaXJrYSBOb3Zh ayA8ai5ub3Zha0BuZXRzeXN0ZW0uY3o+wsGRBBMBCAA7FiEEKetxJ5IpKY7wgka4WUaRLtUa HugFAmUTUc0CGwMFCwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQWUaRLtUaHujH9A// dRp/qX0tyS4ReViW7LTVTBqRO2r5FN6OPyYK65tZH0sXERJ8ctI3JXBhbnkpdAeevTsQI+Aj xGGZXwFUBLNS47G7KQbBbd5qzhylphJKFiaoVQiXrrqYeex/3al+P96jS130T+7rhy6pAkto IAQ2nzQLkqZHXsVaGwlReA/5b2pvFFDgXo+peyVrOxF9rbGD3vr/byX/lsHy9tg5D54PO5XF uq1/juO/Sev+nivnRJr2SNnAYVnBrtpM7gnR7YgsBLMP1cFbBO2HnGC0dumFmq6xIgfK7mHv r4catYe7IpiKU+XxoBE2X0Z8St4h/KsgrP81NSAl+Jc5yIQoMkjCxO8aRfnXpsuRSuVTJRaL WLWYIgB0VZ8v8yOGv8y7al5+/cPDm0rvoGDoOtNDDxRM6aSNF8vjbIcjrGGPjjSTNuVXZ0Ql OV+N+ob0xL53pCxpQU2BPO4akzMrrHIBA8lVLe4wZt/c1QKizXDghfc5g2bphMo3SzI7JKbS qQdRutivzDxlecLa14XzSHZPixHss4Vf0RErgr2VWV39djr8HHy+WB/EXfW9YKy8IvLMc04L QF20+MnvGBII3Xdobe6IsBXfIn38pMj4MzD7WOgJwHF/vpshIMSnsNhCGl0omwDNpe6VVG+P J7ahYHfwizioBiLwM3DkdeyeIVsDCSLHYVnOwU0EZRNRzQEQAM1D8DSL48blnzcHPUL728/s tz9gavMuXOnQmOs3pWirDtzgqaRM73PNeWSziX0O27DIFJdu1K533F1uiIxRWiwDgIvpN3lp Chq7nZzLY979gmLqmqssXHqkOqguGjC6EcSJiregR5JDT/yPFmVebTf+H/y4D0cG51oql036 Wkuziw4SzrwGzkP7YZFYYeaYIUkkBJA7cQb8DWjmxWg72Acc4S9PFWeqmoeoukY1nCmXFO4i emcUASQYGUQdYzEJfDzs1uE3LHxFj/1MK/vrfzQdiJnSEmo+5r+X0OhNRS7JKjzdHpXFtPzX NQrvjdTFDcWaHqgvTcHQc/weCoR5+bnoDFbZQoasI8i93IXeJdW+qZLNBTjyEBrRqSoRPht5 bMNymQdAlZXrh4+2HmmloPn/p9jn33ymhHltkysbnkmWpxPZPElf8QEGMEjaJUd+AomMh5vx 3lI6+ZsdsHvSVUJhMvR3JNszUSm4FBt+JyZr63kY5e8iXcMsLeN22KjPJ1ybnt0iyXitSjzb 4tnip7/4YVdw8+PkTMS283UHS36O4WM8Blnse2pqiXumXE+99KTA6M/As+QDGTmKDem/bAkS SMIT3643nrymTbHZeFMpdCUKTXKmdT0fdB30vLgwr+GSq1KzQzis5UKpDqKPfO3hluQxCcka eWozkGaLZ1nvABEBAAHCwXYEGAEIACAWIQQp63EnkikpjvCCRrhZRpEu1Roe6AUCZRNRzQIb DAAKCRBZRpEu1Roe6GA/D/92PNgR2kc5RXjclwl+LCavHwk6TVUFpZKwRMSCKMYjQUoCybm/ eZ/ubF0cujI4zNeXyyhVpO9W/OiQlJT+Tx0m9Ofp4d7jN05hguSH3lG/+31Ekdzc+AZ1j4Nz 9W1+/Wn4vOjl4SKoYAz5v6u12AyKC1ahxez22RH+ohh8oiKp5at0B09wH/FZ9h7/PfeKwrG6 78pQxJ1tHKbLWejUOh78Gotzcfpwuh977O2ebbU53fceaG8SUf50z2ZAgQ31SeMjDxhTfWgH mfnYDsqld10eBaIWUHYZJaLutEsYgxwwGs8P37hnRxMebE8vl16e/rGluHlnCV8EGdKkjw/h xM23iOquo8tOV49Z1YKLrubXuMdv6JjAy6I1bA6iB+2svCnB1AgMCea0cz2nE8gVcK6QyuVY AXgmFW7BAT/JzqTzwL+OUKkBal6gpJPpbgzOA3fio157nUCKU3scsT7EB+4PiZrHGpsMsdHY zn+gNO0E62RQR72K0RSBE1i/CGcw0rKoI9+WcN+Wzj0i1EPUOqM/UML9YpG0+0KkQ7jq96nI SnrJpNkgamTgCnArpeaTP3yTWIY2RzTgZ70nz3tq3LuHHkUw2jFqoWn2J2IrTidBTFPQMekV UT3mbgSnr2irrMeU3aMLo2ZPbASSYuTJobk/3oEaxS3/1yvu2WpTRmBL0w== In-Reply-To: <20231028065848.d3506101a351d8186139a5d0@bidouilliste.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: VI1PR07CA0248.eurprd07.prod.outlook.com (2603:10a6:803:b4::15) To AM9PR04MB8793.eurprd04.prod.outlook.com (2603:10a6:20b:408::22) 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-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM9PR04MB8793:EE_|DU0PR04MB9228:EE_ X-MS-Office365-Filtering-Correlation-Id: 6ebd9e98-f7c6-4dff-67f9-08dbdbf0d3be X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 1c2wjDxs/yzY0wpv12Rg/R/8pzrS6TSe3zXZRVAsQKFzfHrR350je+DkgTYSeEUcIO0MQDaiaVsVyX22EJzoBqYwRAEIppVz3XHmYg7AA7nBIc7wG3y14SVHNqEXBaXN162usFhjSxcWvvgIJkGpAQTVX/NeGKpXk7t1AIkRW+YugU/c68RNhp3Cw/mzyFl7pyWq39Q4QrGA99M3u0VKU1ZowX3ISiRAMkktQQ/SFL9n7FeMlYYM+EYi0k8cJs2gfZSyiFHE+oILjFjVR8QGZrzGcYHTf1of4LNJY5uw5YwNMwJnilJkRF5SAyNZrTx5Sw8CR8fIJngyLPwaHYB8xQZjUKNGP5RtYH0uZXdWPUEIiEHOblUlfoXJ0TItP56KaXLT3fDu4YSNZnHesjJunqKjGZlt7I1wGDjFWrotCut4v7WlzJpdglf1qDNnf64207GNIRxL/MniI7SprQhyIoIjdsN++7NzVazx4rnXqMOPldHKejSzijChcaQN0aAM5h1avh8RY8LryVKLeV8iwitEabYWYrI6fBb2B1LgmP8zvuX5UlkboLlnxA1mSFpo4z3/jzycP5O0XpOGYZ0BAbnVDX/eYPaen6aNW7NIYAB0UEh86764DyPQX+asezf6KUbAlMsieJm/y7FFxMw1bIVsWqBDQc/dgFx8x2IRXeI= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9PR04MB8793.eurprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(39830400003)(366004)(376002)(396003)(346002)(136003)(230922051799003)(1800799009)(64100799003)(186009)(451199024)(31686004)(2616005)(6512007)(4744005)(38100700002)(86362001)(15974865002)(31696002)(36756003)(2906002)(5660300002)(6486002)(8936002)(83380400001)(6506007)(478600001)(8676002)(316002)(4326008)(6916009)(66476007)(41300700001)(66556008)(66946007)(45980500001)(43740500002)(18886075002);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?anlPSXJrcVJEVDFtVXNzZFZuWlJOeUpWcWQrZE9WTnFMNmF5eGRjbGZrS2NW?= =?utf-8?B?ei84bngrbmxNWGszUk5xVUVrVWgxMzQwRndKY3YrRjFNQVVVMmYrR1NXNTVZ?= =?utf-8?B?enprWlM1YjdtYmorZnN2V3FDa0Z1MXZKalBGQytXeXlTeEd0RHFEdC80Rld6?= =?utf-8?B?Szh3LzBGa0hzcDlzUEVLRTJoSGJmZlByVW1neTBOK05FM3J3UENmLzBsVm8x?= =?utf-8?B?aUFsWGpBN05haUtUNlMrbXdlNnAzY2sxRWwwUU03REovQWY2bTlKSEU0YmtG?= =?utf-8?B?VGN2L0VNdFoyRTZWOUp4Z3dXNFJmL1FVbHdxUWRMY0dKOGNDQVN5TFFsd1U2?= =?utf-8?B?cXk4bStxalpaWUtFakhwbk9rTGhFeHNaN0NjTmNUNjNEWGRXL3oyTTExQlRE?= =?utf-8?B?c0hadGViYU5wZ3h6a2Z5OFZzbUVMckZCanloQmYzU2J1WFFIaWJjdVNVNTk0?= =?utf-8?B?K1FoU0ljUGtUcVk1SEwyTElGZmQ4YWtoYmpMSnZlTmc3RkdCelR2a015S1NR?= =?utf-8?B?ajBWd3ZrenAydkdMMjFhZ0dCQkRwK0NTb2d1NGxIMXRBRmM3RERqTnFPcDZP?= =?utf-8?B?N2VneHk4U3NUN2xwUFFENGJKdWZMWWtobjcrWmJzd3dXN1llYUp1bEN5SHl4?= =?utf-8?B?Q0dZY2hlYW1ZUjI2VVA4N2FaZmdjbWIyUktCZTVwV0xySXdkM1FBQ0cxVG16?= =?utf-8?B?eFY1V1ZKTVo1RzBqaGlQQTBQNWhucklUbGdQNFNTU0oxYnF4YVBiSkY3U2Jq?= =?utf-8?B?Y21NTHY4MDFJb0dHNTc3N3c4aWZPSVpXaS81cTNwT0UyaE9HWlhRbWNZazRV?= =?utf-8?B?d1pyZ3RqWmZ1Mmt1Yll1MHRBNkxlT2N5ZHl6dmlYbWRqOUJKMSt4MGNFbXNr?= =?utf-8?B?MXpaY3VkeEdDblRLZ21QTzhORVlScEZRVGlhUFBSTXVaZjJhbVlzWGp2WTFE?= =?utf-8?B?eDU4MEdaYVhpYlZlbStOWThwbWpOUXpjOWdUTFVTVkhlQUk0TWNyOFpsaldD?= =?utf-8?B?dnZCbWlBUU56SUI4L3NOTUl4KzNURVRjRXR5OENpWXhXb2lDa1VmZ0RCalY1?= =?utf-8?B?UW9FMSt2cklZY1NEbGY1YllJYUNYWWFrb2ZscHhJYTZZL1V6cnZSZS85Tmd6?= =?utf-8?B?bmQwbE9RK3Z2TVA0d3NLTTJWZWdaYjZDQ2phZEJnd01Pd29BR0JON3d3cTF2?= =?utf-8?B?dUlpM1F4eUtkZmtsb1IydFRpbDJXdnU4bnNlVy81eXhRTUJaYU00dmN1c0Qr?= =?utf-8?B?Vk4zMFN3ajVWbjlBV3EyeGxhSHpkVkJJdEJJWllBZGExMnEvTzluVzZNL3FN?= =?utf-8?B?ZDFGR0VFOEZuU2RuZHdUSnJmenk2MS9FVUIxSVlNRW04VUlQVmxuODlBQjNz?= =?utf-8?B?RXpFMGJVUUtYQ3dJQTM1VGNESlNVcWJYVGZlZTlVVGFoZWFNNG1STndUL2U3?= =?utf-8?B?N0dHT05nK1pXcHMwUU9QUGplQUh1UXNVaDdFbDRZRE83S1EvUzdXNVV3WS9W?= =?utf-8?B?ZGxLei9NTEdObE1iRFo1UUZzcHhFT2FOb1NER0lWdCs3T2dMVm9aRVhMeXdZ?= =?utf-8?B?L3J2YXNkMEFUSTd3WHg4dmNKNVRMRVY1bHo0b3BHRGswR1pkWlZ1cU5Nemdp?= =?utf-8?B?K1Z1Ty9idmpqck5tUTQrakk2b1VRKzZNNUdZOE5lM3c5ZFdKK1ZuU3djTHkz?= =?utf-8?B?a0VTajZPRHZCUlE3bGFhdk4rQ3l5b0hoQWRDbHpDQTByOEJjN2tRZDV5YzJ6?= =?utf-8?B?ZCtSNDlGTy9nMGJ0bUlicWVXbkRXUE1vMy9hSlN0STI5MGZiVlQreE9TOUVr?= =?utf-8?B?ZFU3SEMrcXpWWE8wNVRKY3VURDJ5Qk9Qck1PQVZiZWs5L2lZSVlDSVEwd1ZD?= =?utf-8?B?Vjkzb2tWdWxVeFNlQ1ZGanlrWVN6anRxVnZnNTZWMERMTFFXcVk0RlEwRU5p?= =?utf-8?B?alFaZjJYTXVVTHhKSmhSak5tRWZoVlY2aG5JRGgxYXpOWDBORmZXc0FZWWc5?= =?utf-8?B?MHN2UnZlb2tnMmxwd0N4SmZLeHRBUDJHMWhCNU9TQ3NHdDdzMHVabXBiZGVC?= =?utf-8?B?V0dKS0JOYlBya29zUW4vdUVUTnJlYkFIOWF6WnRpRko4Ym9mcTcrTTJqdnJ1?= =?utf-8?B?TjQzZkpmQnJLb3llSnpEdWNpenBJUTh1V3FicTgvY2JVTlJWZy9ZUkxMcHNV?= =?utf-8?Q?GMDoBcWOZGuUsO/sYBASESU=3D?= X-OriginatorOrg: netsystem.cz X-MS-Exchange-CrossTenant-Network-Message-Id: 6ebd9e98-f7c6-4dff-67f9-08dbdbf0d3be X-MS-Exchange-CrossTenant-AuthSource: AM9PR04MB8793.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Nov 2023 22:12:39.5958 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 665c9e7c-9ae0-42a7-9216-7f969d73dc42 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 7rwH93X1nir6FUz58zrTVCnHAcjp0czLB8IfMqy19pDlw4GvGKWmySkvvl9myA0pW6ZwSe2azL+6A/yIPWBizg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR04MB9228 X-Spamd-Result: default: False [-4.49 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; R_DKIM_ALLOW(-0.20)[netsystem.cz:s=selector2]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[netsystem.cz:+]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[40.107.241.123:from]; DMARC_NA(0.00)[netsystem.cz]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.241.123:from] X-Rspamd-Queue-Id: 4SLymX0dvmz4b3k X-Spamd-Bar: ---- Hi, > It seems that we are missing some clocks. > We don't support the audio pll and so don't support the codec gate > which is the one that the driver is expecting to find. > It looks like we've never supported this pll since the switch to the > new clock driver (in 2018). Back then a lot of clock were directly > found in the DTB but that ship has sailed a long time ago. > FreeBSD 11 still have the old clock drivers (and the old DTB) which is > why it worked for you. > I don't think that anybody have any plan to work on that tbh. Just for curiosity (I'm new to FreeBSD kernel) - does it make sense to add support/change to 12 branch or 13, 14? If I make change in 12, will it be merged to 13/14 too? I have no time now, but I have plan to solve the issue... Best regards, Jirka Novak -- Ing. Jiří Novák | CTO, Systems Engineer NET-SYSTEM s.r.o. Phone: +420 482 428 139 | Mobile: +420 602 583 815 Email: j.novak@netsystem.cz | Web: www.netsystem.cz From nobody Thu Nov 2 22:54: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 4SLzhK6K3Yz4ygfC for ; Thu, 2 Nov 2023 22:54: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 4SLzhK2xs5z3C53 for ; Thu, 2 Nov 2023 22:54:09 +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 3A2Ms19F025948 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 2 Nov 2023 22:54:01 GMT (envelope-from saper@saper.info) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=saper.info; s=Sep2014; t=1698965641; bh=ncvioh5aYXivM/pU72J3daYP5muL8Cr+2iFsx13MylU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=fYAqRM/nZ4f/CIdx2gSaXF2xJLeOvIo9qt8NqxJ8sV3vqCLruH3y6Y9cqG/8IapWP WjeHR8hqQWDXOdbARy0TmPaVzDkax0CGXEBhRoB1NAKCrLekyTce8ThUZlOhaDv1Oo T6/wwLHv7otAGxkG7DxaEC9HY/2M+VMc5TXci9RE= Received: from localhost (saper@localhost) by q.saper.info (8.17.1/8.17.1/Submit) with ESMTP id 3A2Ms0hZ025945; Thu, 2 Nov 2023 22:54:01 GMT (envelope-from saper@saper.info) X-Authentication-Warning: q.saper.info: saper owned process doing -bs Date: Thu, 2 Nov 2023 22:54:00 +0000 From: Marcin Cieslak To: Jirka Novak cc: freebsd-arm@freebsd.org Subject: Re: No sound card on Olimex A20 SOM EVB with FreeBSD 12.4 In-Reply-To: <24603490-01de-464d-ba15-1ffc097cecb8@netsystem.cz> Message-ID: References: <6cbe8605-eb58-4388-a89f-b6009b8d2df0@netsystem.cz> <20231028065848.d3506101a351d8186139a5d0@bidouilliste.com> <24603490-01de-464d-ba15-1ffc097cecb8@netsystem.cz> 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-1960675020-1698965641=:1187" X-Spamd-Bar: ---- 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-Rspamd-Queue-Id: 4SLzhK2xs5z3C53 --2201072851-1960675020-1698965641=:1187 Content-Type: text/plain; charset=US-ASCII; format=flowed On Thu, 2 Nov 2023, Jirka Novak wrote: > Hi, > >> It seems that we are missing some clocks. >> We don't support the audio pll and so don't support the codec gate >> which is the one that the driver is expecting to find. >> It looks like we've never supported this pll since the switch to the >> new clock driver (in 2018). Back then a lot of clock were directly >> found in the DTB but that ship has sailed a long time ago. >> FreeBSD 11 still have the old clock drivers (and the old DTB) which is >> why it worked for you. >> I don't think that anybody have any plan to work on that tbh. > > Just for curiosity (I'm new to FreeBSD kernel) - does it make sense to add > support/change to 12 branch or 13, 14? If I make change in 12, will it be > merged to 13/14 too? Normally the changes are done to -CURRENT first (FreeBSD 15.x) and then backported to the older ones. It is worth at least having a look at -CURRENT source ("main" branch) to see if the problem might have been fixed there already or how different the source code between the system you are running and testing at the moment and -CURRENT. (I run amd64 -CURRENT as my daily driver so giving it a try is not a very scary perspective. Just keep in mind that installing binary packages for it might require frequent OS upgrades). Marcin --2201072851-1960675020-1698965641=:1187 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 AQcBMBwGCSqGSIb3DQEJBTEPFw0yMzExMDIyMjU0MDBaMC8GCSqGSIb3DQEJ BDEiBCCi1SfMWZVJK4iTdL+5k6lDG9bV6HwdPZP2VSxoRWytgzB5BgkqhkiG 9w0BCQ8xbDBqMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUD BAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAgCe Gsxsn5oydfmig+hmY0N00KQ0PZnuj/O3L9Y5UStH0rUBi3koIU0bAMdoYohx /O+VOSihRQRpPjMxPEMeZVKalsYsIhiDUByoHx4kDpE9cliPWFljOKN27Uaj Kt5fdzzvsixaNvCKDeXKIY02sVOJFogPUgccLiZCPELRLguZ15in005qXaG3 rThpiNyCxMh8BfXc8hI/7Sd5lRKAnjiB0ldm3ZLqz0zrEk6a4AseTBjXt0VC BjdOWHNJucPCvDamo5WoGu8qdesHpAk4mSOzwVHRoyg0h/ArLAkz3KaWlvVO xOrbnOIIOaIgUlb1bhCEKqKxF9RryDuhQAn7FmwFNbbIxZcc7e32yyHD5Jfw KuN1/GnMoO9TbfDQvolmsdhkAF06UpNy/6uWVr+wvhyXmFiw/qv7c/BK/9Ua HysCMo8t9n7SGwcffvnOj6hfBUabNsMN/kxF56STVQFSFQuZ759TBWdKwITS Ec5iTzKWHZYA5G6u/K4HN0/CowUpCiPhONx6H5NIQ+mXd0tj51dVKcfATigd gnxUEH4LwrbHvQNlPqIIHWA0jt4y8+nT7lnIa70BUZYpcrkdLPYj7w458emd WlA0wA0qMrHq+xBov5bxRJa5nDfjLkGLwjd47cp2h2JoQe2Sb5PLJaeMagmZ WxchZQSzcIo1a4f8AB3Lmg== --2201072851-1960675020-1698965641=:1187-- From nobody Fri Nov 3 15:19: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 4SMPYG4VyKz4yTY8 for ; Fri, 3 Nov 2023 15:19: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 4SMPYF3WY3z3bVK for ; Fri, 3 Nov 2023 15:19:29 +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 3A3FJOgO005264 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Fri, 3 Nov 2023 08:19:24 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 3A3FJOoU005263 for freebsd-arm@freebsd.org; Fri, 3 Nov 2023 08:19:24 -0700 (PDT) (envelope-from fbsd) Date: Fri, 3 Nov 2023 08:19:24 -0700 From: bob prohaska To: freebsd-arm@freebsd.org Subject: releng/14 does not honor .forward for root 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]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_LONG(-1.00)[-0.996]; MID_RHS_WWW(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; MIME_TRACE(0.00)[0:+]; R_SPF_NA(0.00)[no SPF record]; BLOCKLISTDE_FAIL(0.00)[50.1.20.27:server fail]; 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: 4SMPYF3WY3z3bVK X-Spamd-Bar: - My RPi2 releng/14 armv7 test host sends and receives mail but for some reason ignores a .forward in root's home directory. I was about to retest mail functioning before sending this, but it seems the host locked up overnight 8-( with 13 lines of ucom_inwakeup: tp=0xd6b3d800 on the console. That's a frequently-seen message, no idea if it's significant. Thanks for reading, bob prohaska From nobody Sat Nov 4 09:27:46 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 4SMshz17f7z50ry4 for ; Sat, 4 Nov 2023 09:27:47 +0000 (UTC) (envelope-from ronald@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4SMshz0bldz3FHc; Sat, 4 Nov 2023 09:27:47 +0000 (UTC) (envelope-from ronald@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1699090067; 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=rIAAryAglfeBWyLv+RyJJeXLOfuR8ELdc3+1npuSCkw=; b=uAviX0z8BnXoEI23N9J/hISkCvYTbXk4WCfaZJ0RkNS/kmLZAMpcsYTlsZvphZrMtundHA ZR7XdVSnnsQXAJ7GCdx7PdgC0mc+oxgLgKTkKnXw/JZ+JrtQvPv+lAxOdYyeSjt28jkbun 8PiSlKy4SDMtnnMKRILOvbYxN0pImN7Vx0AK9JU1wyf7PyMCBZ2du5AQW1UghesR3/HLz+ ddDFNWseVMyZvrJovcd5a3BUkQuiX6DP6UtqjOvUcRBURk/ASOR24ntKZWTcKB0HfXHSa9 Svk7Tjz+XqTzItLRpq4IAdf/Qs2a6xBboUBIApQNl02puNbAwt44nZCVaGc3IQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1699090067; 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=rIAAryAglfeBWyLv+RyJJeXLOfuR8ELdc3+1npuSCkw=; b=PaceHRHo/9K0yIUddREp+hZyTDN15upxrywujWrC4HrY62FRrrYxS8IYsV9/m8KxF5KjIg eLUs75HIT++xih0GbcIU+C1NhzwDdUjyKpZ7rBIEjr+P4wSzorbGidsIDspS+1dJP6bsZE d/Pfsi2hfova+Zk7Qb5jYzJeXsX3QWbJm9ecBUaPkiIPqvx6GBy0Hjrvd0uMyYkgNvtcgD J1gYLe+qz49YRBUyIY+vG4qUJ6TYuxEtqB6DgNAKH7BgfKjSPULt7sP/DF7KhunKFEZw0X dEWhPl4a+GPY7uOFgOWSVbumBP2ZUYpMsByf+y52MsZLihRvUuMkLbbXEi70PQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1699090067; a=rsa-sha256; cv=none; b=pgSY0oALg39QA4MX4ppeKwrEUvzIgy32fZ4YT7TElBJiC/Q5maCt66nIwnxsidJMQ8Jc/v YeTeS1qidhTZ9oKgl1DAOBk7phO56g6oeH9mGRhoh4TiL6CGzKClnqK4uNGqu0mLuj9I2P oVNbJOXch1C+KKydEzofTxTXYbONmTUyyyPWsVupA8CuVnEoncv5aChDs/Si+nIKevMo/4 2J09e2lamHSIzBNW1ptzdfX6B7q0eaUDPT07ilj9Ls6+yhpBq3443VhN4MAdbf5joR3s+c FV/9ww2yMtnqRGhIIhdhotWKg3aEVucied2+xk0LrzMYy+JQ593GKNI1cYMb8A== Received: from [192.168.1.109] (84-105-120-103.cable.dynamic.v4.ziggo.nl [84.105.120.103]) (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: ronald/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4SMshy4TPnz1DGF; Sat, 4 Nov 2023 09:27:46 +0000 (UTC) (envelope-from ronald@FreeBSD.org) Message-ID: <47a0041c-0b12-4f3c-85c8-e94909caf4ec@FreeBSD.org> Date: Sat, 4 Nov 2023 10:27:46 +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: releng/14 does not honor .forward for root Content-Language: en-US To: bob prohaska , freebsd-arm@freebsd.org References: From: Ronald Klop In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/3/23 16:19, bob prohaska wrote: > My RPi2 releng/14 armv7 test host sends and receives mail but for some > reason ignores a .forward in root's home directory. > > I was about to retest mail functioning before sending this, but > it seems the host locked up overnight 8-( with 13 lines of > ucom_inwakeup: tp=0xd6b3d800 > on the console. That's a frequently-seen message, no idea if it's > significant. > > Thanks for reading, > > bob prohaska Are you using dma (the default in 14) or sendmail? For dma this might be relevant: https://github.com/corecode/dma/issues/37 "Support for .forward files". I didn't use sendmail for decades so I wouldn't know about that. Regards, Ronald. From nobody Sat Nov 4 16:50: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 4SN3Xm1K5Kz4yqpy for ; Sat, 4 Nov 2023 16:51:20 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (vogon.madpilot.net [IPv6:2a01:4f8:1c1c:11e5::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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SN3Xk4KNdz3MSw for ; Sat, 4 Nov 2023 16:51:18 +0000 (UTC) (envelope-from mad@madpilot.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=madpilot.net header.s=bjowvop61wgh header.b=MzvKpZjr; spf=pass (mx1.freebsd.org: domain of mad@madpilot.net designates 2a01:4f8:1c1c:11e5::1 as permitted sender) smtp.mailfrom=mad@madpilot.net; dmarc=pass (policy=quarantine) header.from=madpilot.net Received: from mail (mail [IPv6:fd5c:5351:d272::3]) by mail.madpilot.net (Postfix) with ESMTP id 4SN3XX4BDNz6dtS for ; Sat, 4 Nov 2023 17:51:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:subject :subject:from:from:content-language:date:date:message-id :received; s=bjowvop61wgh; t=1699116665; x=1700931066; bh=Rx14Eo lBeW0O4Pj7MGZRgKGmn7/JvGgRpg35AY8atC0=; b=MzvKpZjrtCm7RbFETk6DD1 NsHev/2m5jFTOG8Bau2LsDST67n6UzxWxKJuuiJw5o9CLjdMx6mtT1Wtukn96wAr oL516CeduqD/aCPW+QhHJLpsD38HIQd2S3Y2S21B5/2jZRSldJmY9BMv8HNCiM7N /qj1u0u7h5fUmP0FGOpd+vOTpIjtifGJ8vWChuGL9GpUv4NRXfKrD5050JC/zIdu 9Z2N58sWUkxWR2aqM3AQIStCNcsLmqsmAMFEIxViEaZQQE1AIhfATrmJexYaRPL/ f3yiZwI9dEqrsBCuQdhhWmWRZURLWyshwl95D5QCrokNDBSZD3KGcs56rgmNPpJg == Received: from mail.madpilot.net ([IPv6:fd5c:5351:d272::3]) by mail (mail.madpilot.net [IPv6:fd5c:5351:d272::3]) (amavisd-new, port 10026) with ESMTP id RN49NY13E22Z for ; Sat, 4 Nov 2023 17:51:05 +0100 (CET) Message-ID: Date: Sat, 4 Nov 2023 17:50:59 +0100 To: freebsd-arm Content-Language: en-US, it From: Guido Falsi Subject: NanoBSD on Raspberry Pi3 Autocrypt: addr=mad@madpilot.net; keydata= xsBNBE+G+l0BCADi/WBQ0aRJfnE7LBPsM0G3m/m3Yx7OPu4iYFvS84xawmRHtCNjWIntsxuX fptkmEo3Rsw816WUrek8dxoUAYdHd+EcpBcnnDzfDH5LW/TZ4gbrFezrHPdRp7wdxi23GN80 qPwHEwXuF0X4Wy5V0OO8B6VT/nA0ADYnBDhXS52HGIJ/GCUjgqJn+phDTdCFLvrSFdmgx4Wl c0W5Z1p5cmDF9l8L/hc959AeyNf7I9dXnjekGM9gVv7UDUYzCifR3U8T0fnfdMmS8NeI9NC+ wuREpRO4lKOkTnj9TtQJRiptlhcHQiAlG1cFqs7EQo57Tqq6cxD1FycZJLuC32bGbgalABEB AAHNHkd1aWRvIEZhbHNpIDxtYWRAbWFkcGlsb3QubmV0PsLAeAQTAQIAIgUCT4b6XQIbAwYL CQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQGuaGDlbL0pOWigf/YVTVf3+ZRnzeGP7CjGV1 Wrrxzjc8h8W64NZasV0XLHGFjl5MYwtm9jJ9gbL8Ubtqstey7lYpjOk2fG6YDhY5eptWCpR6 1QqYrioukhCfKbodSk6PnIZcx719nJVK2P7ihdFEN78TavpBwqIf9hGEcKkMpbRFQv1mYvXD hKVwQGY+8bkH/a/pAWmIyD4qMfKCMurH5DexxEt5SYWu5BB5hd/DWyZ0wuZ+F79KMPzLBPJW 5cpdLNbrvenSqFZGJEGhtTp7GFJJr6lTy8VLBArxmFHiY5jGyR45eZEGDcz86FfGgvPnnpi7 aNCc/ROdF7fnZYPh8uZGGjQbd4EYK4xMzc7BTQRTEHtBARAAoWGsNx6g90r8gcNKaiPpJBiK y8ztV2FyV5LsT0OgQBW3vIxt/odtsxVNNjpyS/BNZCyzLAsFc1WrGBzhYsmPN9SGB5/5YTvk zf5YViU5VAsZlj/MRWCZrWtpic4c0A7N4csOYReNtk/q8YB4PIFsZ9A+kTuoZhnu5t5PdfBA 74+SVwKu84+PZk9wDEY1LbFVT8vM42oKsmoswlIhwJ2xuJI/gbk+cMUe0yiRpNjo4Svw4RB8 4B6uFwdRr/PtS7xi2Zqoof5AaQT9YSBpGpKJOe/Qk5MP4PF6Fqq+go89n77Y2kJkwcHaLoD/ GJ+ZDASIiMRe1y54FHOQ1RCTGGpnJLXdKuGhwv3J21pU8HNlq0ASNQMMQmYAwtUWzjmp/KEy I1qkcmjafcxb8TmiaoK8SQN1Zf96fc/sIrZN6Z5oOCEyyCQ0prH/PTA2jlRkKQ487PTGk2JS KU5VuS57Nlk2DrnvjWp57aV9eFAhpnrrJPuGmFz83/Pc8gC0t7N7i7VVHYRcC5naxYB2UoI1 OUkyxpT/HvQFXXVZ3/KmdXMzrx191AggCPWIwUAP+VcaURSYpeDk6/ZVAOVOe1ChqcJisCD7 wK20/OOvJ2AtkWreGu1CZ9zSx7nK/VYdLr34GxQ4bT1G+9rBQNnFSNbX2TJ431Mdo1GCjDeR K4CtSnrNKYkAEQEAAcLAXwQYAQgACQUCUxB7QQIbDAAKCRAa5oYOVsvSkw3nCADhsKRf+rAR ULTpOh5HoLam62ZJZAyCkNqqu/rke5uj5AaaDY/h7BNhBDiDqhhZLTeofGpVVaErPsWN+tX5 0fypsIt9KAhy90GFrtrIZlWuyK4wsoZvDfp9yaRk+lIM58dw/Rcfxn670JaPTFSRPECVn/uL qBhJSkbYlY212YT9fxVUTJe6wIvDLQrQEjrQD/h1FMhfcLhAqsndltRd6DPvTKeMd/6VAxn0 hkoBKhEy5LkWjM9CHppu+bBkQ91/kj2uJQSXO8euonwHHS3c+6N2i2H7I0emcHGu07wuRB2t Dnw/RLBxohffdPZT2kbxuG7lhVHzwVDw5DRwSw8GkOdy Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-1.99 / 15.00]; MISSING_MIME_VERSION(2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.990]; DMARC_POLICY_ALLOW(-0.50)[madpilot.net,quarantine]; R_DKIM_ALLOW(-0.20)[madpilot.net:s=bjowvop61wgh]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[madpilot.net:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4SN3Xk4KNdz3MSw X-Spamd-Bar: - 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 Hi all! I am trying to build a NanoBSD image for a spare RPi3. I started from an existing configuration I am using for a PCEngine APU2 board, I use as an internal DNS and DHCP server. I'd like to replace it. I'd also like to be able to upgrade using the altroot partition and then switching the default one, but am not sure how to do that, maybe I can play with efi variables, anyway I'm going to investigate this once I get at least FreeBSD booting. Unluckily I am unable to make my image properly boot. I have reworked my scripts to replicate how the official release images are made in structure. (copying a lot from src/release) I got t the point where loader_lua.efi (renamed as the standard `/EFI/BOOT/bootaa64.efi` in the fat partition) loads, looks like it is scanning disks but then says: ERROR: cannot open /boot/lua/loader.lua: no such file or directory. It gives me a prompt, but even if I do have a working USB keyboard plugged in I am unable to interact (maybe this is normal at this stage?) I guess it is failing to find the root filesystem but I don't know why. There is a valid root partition. Do I need to put some boot code in it to make loader recognize it? Where could I find some more detailed information about u-boot and UEFI boot? Maybe I can help by creating some configuration file in the UEFI partition? Thanks in advance for any indication. Output of `gpart show` (fromthe image mounted as md): => 63 8617921 md1 MBR (4.1G) 63 961 - free - (481K) 1024 65536 1 fat32lba [active] (32M) 66560 131072 2 freebsd (64M) 197632 4194304 3 freebsd (2.0G) 4391936 4194304 4 freebsd (2.0G) 8586240 31744 - free - (16M) => 0 4194304 md1s3 BSD (2.0G) 0 128 - free - (64K) 128 4194176 1 freebsd-ufs (2.0G) (it looks quite similar to the official image one, as far as I can see) Not sure what other information I can share, but I will send anything that can help shed some light. -- Guido Falsi