From nobody Sat Jan 07 20:33: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 4NqBk93Chrz2p3vN for ; Sat, 7 Jan 2023 20:33:37 +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 4NqBk86jsqz3rDZ for ; Sat, 7 Jan 2023 20:33:36 +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=1673123615; bh=I9O8pqec/eYwmOb1UDT33ygBMaNUfnb5trLozMs06/s=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=DFUnPEtS1Ggh3a9qREVsH8WOVG7iVqDqfKgcdTxh9FiduP+/drqKwQlC1HPW9cFBDo4ALeHpYAVVyiMdE2RXqOofHuPHTp65vIHJ37syhjc2hTSYhVFTIodz96e88Zm36ReW3sk57msd4DLx0o6XkJAO/XOwJB8cdvwCImQ65fDWw8gPFgVrvpbIL6+2U+nok1irauH2R7ytHEzrR2dZfk/xfO+4cVV3gQnHrg+UK8zFCL1FqBvF1zevUF0DxuRP+vw8LjhY79Tmic4kSwqCPTmFUioQZcUJ4xQm6X6dxBJHiS+vunJPh4p1CsMQQJtJ6bpS4s6ZPT8G6H9MIGkTwg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1673123615; bh=1TOV3k5Ch5dk6L53wIM1zM5xlwIYfs276nrZIhkvgas=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=NVg4COKVzcanAmu2w61TzyQS5xhodltcuMXwoZEU5SHCRtgGzDdcGbZIW+jQ/TH+RYNU5sU/M4SXjg8z8RKyxXpTgSJDu4okJTjCMBvuuWVn5KdRInANtEQLun2EvAViAl8/9PVpYG/mUvSVSTSOGb3bqEToFYopnOSDHxVmMAf4cVUrcvbh8DJftvuR7It2yjgoWjodtZifRu/PIaAKb4OIf2W3b/aeb4nCXVoy1wiIiSP+noZNEdPHqzQIaDTD3v9wdWJj4xpHpq02PSVGYoTCbhIMInw24Y3RqztaRpJAnfx/5MQQkZ1sjGC+9NBgKZJBJabCY6lKHVWh+2UomQ== X-YMail-OSG: 7mrus7EVM1lOZNA3CEe4GvtaGpnZYiiCS10F9lS4TFD.4tBwoTZn3UG7rtVNjHV zKJdaaVu9gVzQwyG0Is1qQka32lY_LVFzm0Pj50BMsJwJF1btYvM6M55dTc7eAZkZ0F_nsQfSUGA ZOPBehdMa0wWyHuJEYrYqp1CAAI7NJ9ggNJZlYBgIn0_pGVeN21mHclhkTs6yc9cTXwEacX0TXPv r2KI7sArUMlTn0QlZpmckktnXibVEbgP5eHq_YSrYMxlRTkYoVrrMW6BXCC_NOKOoGg3aWfN85L_ Xkwq.KM.B5lL9l.GN74GMnt7lMtOKMSW0i_j.JWlfygE3ELf0KeJ_ReOchQaPjJ_edth8FaxaQiJ hGjNkhA1td5w3Soe8lyihsb.bPQB8IwB8.JsmxFg0Jx5RswGpj8j1IOjyurvJZMqvWQFzdRAyGKd I_9arH60ImJe0pnp7b_bS737wspNCWLfNY5fQ9A0S0TMhvSmAfKbrdIUcGBR5.GN2XFpDYkd40Ty cD.3goy8H9uemdE_0zAmqJFEH52ONgIYw1I6Jgxvh_3_s82BkCt3_rhSN469bRJQKkPmmQC.DzRe dccc.1f9_zZlxvHvnyxLq4kFtYcfWaVbSwQY8_6ybqrYgXeSE241cBWP1adM9EsAIzky108ZFaIn CLTRMiTKYFaKnYZwgllBd8cAu64SNooDVSezasS1n5zJ33Ui10P15P703qi41HjTj_0Py9l6VEjP ad3uChR0SgEGte0916Igr68AMOsYGuZsyMkNWXFzmfyzRpi2Z8CJwP_ZFlmQZkqQwLsRf6uYL0hU 73DFj98H.7XXNcljIq1wLNP6lsAyPVvxJzcW07YLRxlJPa0qwKnf1BN5_95x9GoWNxGYQ.Ith_oa TTBubULfwsVguNRgeeVZnE_F_fxn2rd69JAXRCuRy9RNGwHwcocg5eWWj2WB5t59tC3FKYgQza7B GFsAkNGhJs0lX0N1erOY6Ln4kuLOuTpn8vFF.wylZaZA3paehp5xzVf37T767k_3nrabmq6umz4b mvB6HZisUKXabQMaSFLIA9XQXvCj4utXzIhFYzC8uRJ_UrfTa7qryMu9LkVM5eR4A.MNKb2p__Y4 iHbAcxDBAQAKlXvu4x8X.urXa_RxbPG8Q5Ybkr_Reh27.aitnXCMo_OGA5zKsUxO5TGnZn2OvlkP R7M8L_0TmDuwVXpW1sd2WLnKA4Hm2yZvV_sN9eodumFNygrjetX1rUAlstQS6M975.iAJaZJQEAl LoYuNATmr5pzyAvpjDuaSCe6eYMQqhSBNTTki24h4WOxsifQFm0wGxTLf_Ew4AlfBEsuS1s9wcEK 3G1_tEyCst6kZAjqIgLEvUZ1jlNOv3lKAVsvemK_mqg4Dn.cAE8dNAu1vG44f8DyG9At_qqOS2T8 yDE.jZQ0hqJk2vJ48a4cRogPQK9smcRBSIUmy4UotoeA1vAZmkVgCRQtSiz0YYf4cS9uXxd7Nv7Q 7CAY1Q6xkI46nX7hAEbk7_qNTdki0pbrb93eFuP464QZPB9T88qwB4.LomSHtrUn2Ar9pP47Pb1. C4cBO27eAf8MHUCBrA3MikByxG7U1eF9ALHA_O3yviFmA_59GQYV.f.ak2yj_c7bTZoleyGgWlFP y.5xNn333yb25u8jfyPS6x.xKQ6pVRa.tcQ0p1wtmwr5pFOhWXVShngp99qh4OYWVvb1lLwldnS. yGsLjcZnC.4v_87ovpaWueERrsK5uQVnHjnkdL09r.95zp.ZopxtL94AAX0C2H8DBNZCXbcQsjV4 LK7hQulXgtrd7OYjoOlR4x7kRSTztx2KNTUJlmc2fAUqNyovZYUX73V57OrNNgxSvADY60IePbOE R2dY_3GOc7jNVwEJXWJm8xll0MnVBAVWq6cDSZBlG4PbXiwrMlMHbLv4XO10DwRX9UWYabcYOtEO 1z65O796Mf7tWzC2DTa5wJ5gB7cBt8EIGXQOO6j6bjS4BKWD1JCscjLSlzCZwTV9wHb44js0iR.R A9FGa8JOc5nr31LT5P1udOmG2VdCnM2g4KCtWxtO7xMQCNeATrIuh.vuPCnSeCILahzxliJ3PbWA iaLXcx9S3LhXRmGJaBdCF.s4BtoNaIdkg_qIuM9q2q1RbNpqibGGcg993QST.CMLw7fwB0LMoclA rzgv2O2DXebkto_gASvBm3L90wvP7VvMRX71glM0lKE3cyeWDjuuEM81nFE5d71DaB1WWViL5IQ7 MQFZOo3JArFoYse9k9LcValz2nqdzB6KI6jo1_V8cP82F5UA9gqi9v5PiZtPAuxbYnsNfjwdLm4E - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sat, 7 Jan 2023 20:33:35 +0000 Received: by hermes--production-bf1-5458f64d4-kq8fm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 139bc9d500173296327b66ddf2d39a51; Sat, 07 Jan 2023 20:33:31 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: How to make FreeBSD's kernel boot a RPi4B with modern RPi* firmware From: Mark Millard In-Reply-To: <7EBF1CB8-F6B9-49D4-897D-5EFAD321341F@googlemail.com> Date: Sat, 7 Jan 2023 12:33:18 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <9E36A955-9B22-4D54-9EEB-B74FCB5B67FB@yahoo.com> References: <9C037D3F-A440-4708-993D-117F313691BB@yahoo.com> <374EC3E5-4CB4-4336-A8B9-7A9CF6151691@yahoo.com> <9E9C739E-8308-472A-B797-05A37559DD00@googlemail.com> <7EBF1CB8-F6B9-49D4-897D-5EFAD321341F@googlemail.com> To: =?utf-8?Q?Klaus_K=C3=BCchemann?= X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Rspamd-Queue-Id: 4NqBk86jsqz3rDZ X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Jan 7, 2023, at 10:07, Klaus K=C3=BCchemann = wrote: > Am 07.01.2023 um 11:18 schrieb Mark Millard : >>=20 >> ...In fact, the modern firmware corrects mistakes in the >> .dtb's relative to the RPi4B PCIe description. =E2=80=A6. >=20 > just a short estimation for now... > there is far too much to say and report on the firmware/u-boot and = specially its targeting linux kernel, so I'll just refer to your above = snippet : > In such cases I presume that hacking the .dts files on a per device = basis should do the trick instead of following the upstream = =E2=80=9Eblindly=E2=80=9C because if you fix 1 thing by merging the = upstream you=E2=80=99ll perhaps import the next problem from the = upstream. I'm not aware that FreeBSD maintains patched or replaced versions of any .dt* source files for any device (beyond being able to identify that it is from files that FreeBSD imported). Everything is from an upstream, as far as I know. As far as I know, all such are designed for some linux kernel, mostly for mainline. The RPi* .dtb's used used as binary files may be the only non-mainline=20 examples. > There were cases when even OLDER firmware was better than new = versions, That probably happens more for the RPi*'s than most others but may not be unique to RPI*'s. There are also examples of importing mainline .dt*'s that lead to FreeBSD failures for non-RPi*'s. I've had examples of such (Rock64 and OrangePi+2ed in more modern times). But it normally means a later adjustment of the FreeBSD kernel to support the updated Device Tree established upstream. In all my examples, eventually FreeBSD started working again after the kernel was updated to track the upstream .dt* changes. FreeBSD depends on folks using devices to report when the *.dt* source updates break things for some device(s). There is no general up front work to make sure all the updated *.dt*'s work with the FreeBSD kernel that used to work before the update. > so I would always focus on working fbsd(img.xz) releases on a per = device basis=E2=80=A6 > or you would have to test EVERY embedded device and all (perhaps = fixed)bug reports would have been worthless when you import=20 > the next problem=E2=80=A6 also you will not want confusing dmesg`s = filled up with messages of linux featured drivers which do not exist in = FreeBSD Avoiding a crash for a valid Device Tree (even if not otherwise supported) is not the same as choosing to use the Device Tree that otherwise gets the crash. One can still use the historical one. > =E2=80=A6 but of course: >=20 > If you can fix a relevant issue of an existing driver(like the pcie on = 4b) , please give your device-hack in phabricator review,=20 If I end up concluding that the patching is safe enough to submit, I'd not propose any change to the RPi* firmware version that FreeBSD uses. I have to use more recent firmware to test the patch is doing as intended. That is not the same as saying FreeBSD should change the RPi* firmware version it uses. I view the patching as fixing an example kernel defect of incorrect general structure for handling of a Device Tree resource initialization. (It is normal for various Device Tree resources to need to be initialized early for other Device Tree content to put to use as far as I can tell.) The older Device Trees happen to accidentally have a non-required ordering that happened to accidentally initialize bcm_dma first. In other words, I do not consider the patching a hack, even if someone ends up pointing to something I could have done better than the patching I'm testing. > but also please be warned of =E2=80=9Enew features=E2=80=9C in = fw-releases which taget linux(or even only raspbian) instead of fbsd=E2=80= =A6 > ..just my few cents.. Again, I've not proposed updating the RPi* firmware vintage that FreeBSD uses. I may propose the kernel change to avoid the bcm_dma related crash when anyone happens to try newer RPi* firmware for any reason. =3D=3D=3D Mark Millard marklmi at yahoo.com