From nobody Sun Feb 09 23:51:44 2025 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 4YrkyS5J0rz5myYQ for ; Sun, 09 Feb 2025 23:52:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (using TLSv1.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 4YrkyS2KjDz3tHF for ; Sun, 09 Feb 2025 23:52:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1739145118; bh=etFZrRLIb12QtULSYidU/Zg7FBSbhD+Ul/fx2e4aeCM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=DWkWivQdIywu/PCJ5XR/P21HnYrJ9q4ZLHhPU3PF0qYotugX8+5gR7B3dhtKVAl6MNOhmlW6AQqBTjCQ4m1hAFQNMWprec2eZJ4SPFnLLYxoBD12fue2cro8oNO4bS63mu9Ol/dFYi+/kmAx8N0zPWY+hxEIeQfjXWohbUEXE8i2J7WklsV4IkrqaJQvguKLo+UGVp7IfRvUUKOixPlrlMKyCz4vRRVaWIrcHXU9nxrlxXWxoKDK053rgCQc8kID60L+Yvk5u6PxM6Dm3OBUDDuNryMy+ZbtMkgY5hwBSnkWP/JTf2nLPD+qBYLv8rVSrINWPUGLcY6Z7pxqFoO4Qg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1739145118; bh=VSuDdWBnHl3EnS+aQBpUreah91gPQ+QLPs59MALk4kR=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=BXTjZmigSxz1yToVPCwwKqSlOdLOZi1r3KueViJmEFBSFX6/Fr5cTDlzZxsGsij1zc3Q07WTeSDykdKuLCjFNQaisYa1MQgq+4254Pg4tnpjkajRKLkISW/hvUkAg8g8wK4Oe4ZtAWrqLBW2IZdy6W2TX/Iawgb5FkUObQLpZLg20DQk5D0JdubvEPY1GWj8w2czhiUmkF6n7rPXVXP97K/HeucFfs+no41mpCpNOiS/bZtzgVrIbDrcHf6waPjizcA8vV36gDen2GHdULcKHG77hvt0ZYo2I+Nw3YUviH5X3P7WtEjiHkaNeEFufYe80Z150aunajKQLmoFepkUUQ== X-YMail-OSG: CIiPChsVM1m__3bQn_C6KHsgv_kJ_hOFc_JG2BEcJ9Z0A6JA0cX5rlf3l.8mygB bT0u_PkFVhV1mRRApE1IGV7SXVSeB_Rrj738Puln9dwxSR1apgEUJjLnzcE3h_1MwZUl4VD9x911 pKx5Tk8ODF9tIZOZ.iQEiAcJczF1VFNkuu7VGCfzsHGHBBTXAPF3T77opWOLDA.JnKom425RGLGk dJqAHlfYboBJx9NTpW9nx2C525sLBkvR4vu.7mglk7.outyEMz06K1hiLgDKRkMX31djiU1EKerj OYV_KFi6JZnFGp6ObV_tEK2tFCV8d66PA8iwtlBK_IZNqwbDE4GdxWvvzwuYfbyRAQ2VX._6ArrV aH_62rc7WB6vC6sz_ZUFkOzDzjTSZ1AedfaaxLjj5kezjVi7LTwnqWc8..jeNWRCZB0I7msmCuob DOJnpunXk3Qnuz76eT_8x5b90Cv.ojHzj6rpkKlBCX9SJCB1gWD.dBYQXoK77yHNeo5e4Xa.9azC nE3i1.oDBbvwLxvoCnoG3LLlBijFu346CwXW8Ehqh2ZwJkH_XmLRvPcpO4ZmMXJfi3qllbaEvOYd LRdIsbAMt_3oH8EiRD0LVQzo8eRX9dYzq8bZKQUL76UNfuG9H7LY5AVtQ.VDlYDFoVEW1p.Pv2Ne HfGG_kDZxenEhbWRwmzuOCRrmPqg9mT9rclVXdpldVOsRIkrGgl63R4zACzxRhcJcz6RWX634R.i TXVmgNEb4XPv21mS7MMLlHfcIirUNl.JiNVFdzxlRCPPV93hKDu.MaKJAqj46V7C8Bh2_GtAmj6U eiRJrZtVg9pLyuReSeTYkkJa6vqgKAsz2WuUQEh3e9wo4IujP_00g9u8ql0Ar66ZwNkP_zbbDAaJ q9NTnU_XXRMYsmJfoTWZcDozSZGxYd0wQZrgtiD48ZwmQjSBJIrhagRT0.JIywDT402Rkx3izKg_ QP_EvqjT0lad53rL9an8HMgalQzFvJqaJSC4tf1UpLPOc4NVapmNEbT0_2hx8iw9zoubIxnTiGl4 NycS2WKTLf6oR2TDI9C0dF5aEiFcTB.YcdylA.v8B3PbUiBVR6ee6j31Ke5PCu_3mLjvG3u4Ln6n KlOprM5dgNopz5uSOpqHa6ZurHBH3QQJnRTDd_5GueCDQgARfXX4rDiUHEpVYmtvnstKpCF44a0W gdcifpNe6IvNSTa8WSP48A7PP5mJe7m2Pf7zHkiEiHp5_5vTaO9b31rS8cEOJLWjt3PBmCj.IXyX x.AS7r03lz46S67Z3Uw98GD4Lwisaf.O1Sl4Ny2LfLXgNk2Ylve1A_ZOeh1OUNSn4NDVVf0PB6NG aDAS7OwQ5ZsjhYuAqEyc_BPy3q0tiv4cGmFBxCJot2xinvO1mTutwP89s6NVc7BVO1LIK8n1gOzM Trp8jgMjt2ZsdRevz2_.WH4O75KLeqbflBSdbnG5.sYU4NR949iANWWa9aCqt4lhh_D5tLJPzqzG eBAxxcg22hoH1n2cpwlJcX2vXJhm2cpj94AwPJjAAdEoXv8m_TH4gBk4uk1KzL.LunDaC1wRLJjB _jOFeZcJvNJQf5.9DrKuLrGn3tp7ClNpqbixrdaz3Z8THaV5uweFf5cM7gxfsS0JaLsm3SFGv1qW BijM3n7orbTR6CGBtAEXJebKdRpVyY9PRfxrOkqdFqAXE7bBpkwiX3mLXGf1um0uxht5eN5lMP2k y1cuS6bCtLNrGWZZar.3UBK70EeFY0haDGFQY3hyUpsbEXcDYU7LRbOFCoZwLUlX8S8MQ7S5aKFF juYiv.VmLYrQFECAWwLJwAkvz9cdaiZZQWEQkju6sG6G6W0.sF1HRbjyxYXCMPhB66conzHz0qGM 11siHIrKX3lDSW0bQdM_fhFj.NX8Vfg6OuTjICP5eyGycDyLG2gsdZ1NvA8s8virkZChkTm8OtIh uNfMo7WjxINOKAfDaJLIwVtZX6BNJokWj3AXX7oFBH.FOm5vDj1OXC8xU5nmxMQ9._KqteAxpa8L qm92MHNnHF0hUKFll3jYl3U5BZLlKftW2hWKcuQAQEf1GGHPess__Ixm2AY.wSTV3JydMnr1Gxvj s9.w_VbyMCqHGQ8Q2VFgOWPLjMe7T8jtDcmmIt_lft2.qEQWTxHqbq2xQHUuLElPwzIMvGOadkbA ToozGe1wsiiCdcpeTSK4SiGkTeuS82DxaxHZDlp6rpQOUYgfuBx0bcWHdJRcgD7fLznK4K4eI9Kq iMStRqG9MyFXvHungSfC8sZ9xb8DEd_IWzKRYkC4npXjvvF8jOJLAmW2Myv9hcaqO8dxSrYtpFnd D X-Sonic-MF: X-Sonic-ID: e364cf95-2808-4cc3-90ea-c57ac75ed6e5 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sun, 9 Feb 2025 23:51:58 +0000 Received: by hermes--production-gq1-5dd4b47f46-dvwsq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3b49897c3d5a6c042c86cb5592e9fa47; Sun, 09 Feb 2025 23:51:55 +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 \(3826.400.131.1.6\)) Subject: Re: fdt based rework Re: Raspbery Pi support (release notes/wiki page) update? From: Mark Millard In-Reply-To: <5197CCFA-114C-4D7B-A7E5-D36C383610E4@googlemail.com> Date: Sun, 9 Feb 2025 15:51:44 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <668r286o-584q-616o-5nq3-0233r3259qsr@yvfgf.mnoonqbm.arg> <0B39AEF3-27E8-4715-9FA4-6B95D8AFFB3C@googlemail.com> <5197CCFA-114C-4D7B-A7E5-D36C383610E4@googlemail.com> To: =?utf-8?Q?Klaus_K=C3=BCchemann?= X-Mailer: Apple Mail (2.3826.400.131.1.6) X-Rspamd-Queue-Id: 4YrkyS2KjDz3tHF 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] On Feb 9, 2025, at 13:40, Klaus K=C3=BCchemann = wrote: > As you saw, the rp1 driver is compiled into the specific U-Boot = version that I used and the devicetree is handed over to the = fbsd-kernel... My curiosity about the live Device Tree content and differences across board variations or across kernel updates is not dependent on if FreeBSD ever supports the RPi5 --or even if anyone tries to provide such support. It is also not dependent on if there is ever a rp1 driver. I do not expect satisfying my curiosity would help anyone enable RPi5 support by FreeBSD. (But I'd not object if it accidentally did so somehow.) The ability for me to satisfy my curiosity is more dependent on what U-Boot has working for the RPi5, such that things at least complete the "Using DTB provided by EFI at " message and allow a restart without cutting power. In my context, that likely means not requiring a network based boot process as well. But a microsd card boot process that managed to output the "Using DTB provided by EFI at " message would likely work just fine. I'm monitoring to see if things start to look like they happen to allow me to satisfy my curiosity on the issue, not expecting that to mean anything for future FreeBSD RPi5 support. > Or let's say: a hacked u-boot could currently be considered = operational (except currently USB)... For my point of curiosity, a hacked U-Boot would be sufficient to get the information in a useful form, even if that was not point of the U-Boot but just an accidental status that I could then put to use once I had a copy. >=20 > but of course freebsd is not ready for use yet... I already reliably use FreeBSD on the RPi5 that I have access to --and have been doing since 2024-Mar-15 or so (RPi5-uefi v0.3's release). No need of U-Boot for my existing, limited, old-vintage context. The frozen status of RPi5-uefi does not change that status for my context. I'm not likely to end up with access to any more modern RPi5 variant for the indefinite future. > I'm afraid we need an rp1.c driver... > The original is available here: > https://github.com/raspberrypi/linux/blob/rpi-6.6.y/drivers/mfd/rp1.c >=20 >=20 > but as long as no fbsd developer comes forward who wants/can work on = it, we don't need to talk about it any further or we have to do it = ourselves.. but huh, not that easy and not for everyone I've generally tried to stick to my point of curiosity and to not talk about the rp1 or its driver. I'm no where close to having the background knowledge to deal with such things in any sort of reasonable time frame: a huge learning curve. It is true that my area of curiosity once lead to the discovery of why the FreeBSD kernel used to panic for what was then-more-recent RPi* firmware and the related *.dtb files: QUOTE The sdhci_bcm driver attach routine relies on bcm_dma already being attached, in order to allocate a DMA channel. However, both drivers attached at the default pass so this is not guaranteed. Newer RPI firmware exposes this assumption, and the result is a NULL-dereference in bcm_dma_allocate(). END QUOTE So I had identified the "NULL-dereference in bcm_dma_allocate()" at a given point and its being tied to the ordering of things in the live Device Tree the kernel was given. But it took months before I finally reached an identification of the general structure for the correct type of fix in the FreeBSD kernel's source code. What was actually committed was a variation of my initial changes that used different parameter values for controlling the detailed staging of of an activity. The result was: -DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0); +EARLY_DRIVER_MODULE(bcm_dma, simplebus, bcm_dma_driver, 0, 0, + BUS_PASS_SUPPORTDEV + BUS_PASS_ORDER_MIDDLE); Ignoring the parameter values involved: Just the structure of that type of change took me months to identify, given that I'd already identified the NULL-dereference was due to the ordering of the live Device Tree's content. > Regards >=20 > K. >=20 >> Am 09.02.2025 um 18:18 schrieb Mark Millard : >> =E2=80=A6 >> .. >>=20 >> FYI: The U-Boot fdt print output is sufficient to essentially >> reproduce the live DTB with: It is a complete source and has >> vastly bigger output to capture. With a dtc that follows the >> same conventions, it can be compiled to produce such a .dtb >> file. >> =E2=80=A6.. =3D=3D=3D Mark Millard marklmi at yahoo.com