From nobody Tue Dec 06 18:40:36 2022 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 4NRTks508Vz4jcc2 for ; Tue, 6 Dec 2022 18:40:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-55.consmr.mail.gq1.yahoo.com (sonic307-55.consmr.mail.gq1.yahoo.com [98.137.64.31]) (using TLSv1.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 4NRTks2Q5Gz4P7C for ; Tue, 6 Dec 2022 18:40:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1670352052; bh=lZ9RsHcP+KEHPjubku9HrTl2QAM18BkdNLdX5A8sRvo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ei7WGqyir4Mm3mPEL3WKkfRM4tf5fZWxDH7VoFMiIg9yDvobhQMca4sRBN7S4cq+7sFquY8E7aRXb7vFh5uSGjlWq4LTezvN8uEV/QHrc3TmYb1ktpVoX4a3nJw1EL6PeQvI6Ag2r88zOdeoyjJJtauMKYwYbNBMgMSeYI8sHGGQmYXj00Y9PUJZJdxUlEwWXg6ZyxZUpq4NhqzhIDQ2r8FVnAQ5mdLh05lD7wl7ZGgScascjO1dfuyoy7b3r2XTtnAgxRP3uKPqkhoKkDd5XtXjpuOSij85ELdx9y03Ie6itfjye29+NAthAA5vWgNR7F+67XaeVP/6UXl3sRdgRA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1670352052; bh=1kldmtaXbDyNSMY2mlWjkSej97MQtbO2Vpu7VbDzTWV=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=PfgthbRVatwDhUDavFn2w08Rcz9vsPU3GF7/4IjXadY6gf0eccNSyG9vmf5XdblV7WIOC6n0nXl6NCnqvnV9n46yuVNBA84zLVklupuuiBdM9+Z6maUNR/XIGtUd7voXYG7Wb7q181UY+qTYuGLTbrQ96mLwdJ1nYsvJfW648D6yBpK3CHpPVxItV58bkdoo5pob0NchNVto0FQlkVyUdZsKmozsiHVxzixMhgFqwOMHNayPbJdVE0pZmiUXH7bNfUqG/P0h7Qjk3FfXrq8+hH/+y/7WWSa61m+iz1VrLsA3ivWVtT5gH8TpRMWVAyQnrMlehzNnFd1Zz5c4KK/19w== X-YMail-OSG: 4QQ8hpoVM1k579gGtcbrqcZHLyZYa26XiaSbObkTMXjPOcozjNNbbw0jYQeuz7J UCMeSrdWgfEXATbP.yRdqJilueteRRN26f6U5WDHN.4dw9ifIhmu4gpsmK.0GK7moznU4KDOf8YF 1sfrK1iuQDPnc2PteTP0wXL0yFMD0avHG5fCOTpmkk5pfE7hgevRt74pt5pPg2wKbA.JnhWzJ4UO FApL98eBXjzDyamPDnwqHSJrfyOcV00cEWTkpAcXNMSrz6Q8G7qRz_Buffs3I49UBEuhMOVCMt7E 1eNY.MRXUE6naxB.B3D_vdxQJrR9eVfvMQWSUF21p0eLax9Q_Nlz.M5.qT32m.E1lkGpzXC8x.km Zs5G9i22CDavOZCIsvfRUMIGV0cK8Itz15k0Z27ew2eMj6LcX6N87wzlRkxki.Kx4NuUNE5d9ErR AVLfpesZkH_hzoVO.qsCCA7V5KBVTr7rB1wy0GeJv.bP9PNqpMwEpLPplpgnH.U1bVp77kir8JvC Be2TLFVOFMGSAak.vrSBGYnThTpZKjaFqO3JRdopAX1YtEW0tvUCwlh2HlY64_y70oGlNQB9CLK. yv0bxlyKQ3f1U8ouotihDms4PYgzR32gIt3Y4Qit8IXQbcILDgP0Jgathdmj9z3Ty_JoIl5Nprd. s3hhhXLpebr5tO8JeR0nK16xNWwJIUeVa5Yav.opWUwuExA76sHueMOiAeOH.K409yPyY4VjghVN jlt1f2OwM_xW4Wj5xiDDa.mmg9QvlJFICCM7tQGJQ1_CDOtnKjSMcm8hQgpT0cFnCUmFdGQ6Zd.u ODQkuhBtIjcHvWXt1yK60laJZQToj7P0h1u_y0F2k.QPKf82U2AZkFteI6AlWvD76qGarsBo5haE BqTm9GpaZibY0sxVsWwuRUe._.hcQYTzc3Kk_oYtHKog0nHARqRPlucnJdfaMm9KflAWie..e4wq odDD7I4iVuOtW2zikuK_IVjG9WQRPsJh0mJlwMvzxgP1m6UwAB43ds5Z4VuEuGDfaFVI79tFZBR9 7Lghaw.xt5UV6_9QYK32JbbvpSco.heYG3pxYOdrIk3xhlFGC91e2SHNTwPhtY6ENc04No.Oaf1X yDxiCwvyPFDwgJWwpPpM7ujbb7806VbSXtxmdYIoK6Ph9uGCGCz3Ad9l.hvyQkqxGmtpqfoShga0 k4Hsif04ZhB.JJyyd3sA6J4mClfK6QUtJmz3MCcP1NO.DntCQYJc35zQd_vpY0TaEMlnHOKmOatT bgdfMaxBIoeMJxMXmZZ5mL7sOFcb8cQK4xxMM3kTxeaBokzavs_7.LgU_5u1ZtOu5BKizTeRSRtu c26UGEnw9iPUrZuJah4oCtxAt3ll3AoRMIVzw6ke_eM0WLjyvx_m8Z2X8UGkSYPP_7u3qTrmJQSN ZQpDlAWpKRFBrf7VdlmZBhLc2ILUSzhM5I3KgbCpgXj7dEX56Jhi6ubo_F9zEc1ctpNWrn1_Ooal 5kh_Oau6gnoST3i6onQcVTag.KRmf.5kv7q_6Gia4IDnO9Ueir4KsP6MBHOJNRr7RPfX9r9vYpXl mYROWOEO8wGOYLoeXgsG10mzFf_8AT5C5a9J8c9aNMl48LEwvLse9gT1uNx2TxJEwUAfbm0r4e3b kukKLT36hhrYti_dhP.s5xFLRHd9jntD0TDddLJNOui.wDelbxbwX0ojy3.oImZVnOcw3sZLU1tD HLDGiRqEpHJo6xQ7o_hE5YCVs8EOCC1skz8VtnjJTj3MyYftBbJnB0TckpQBzrBx08s3EpiCNqm0 _U5LN4X_dvYv4DuFYFy86xP.unqpZjcH6nq0LDYNi0srwbf2wOR3wTKsWrXv6.8TB6JsvXdtz4Wv RWjrdbCWU4wHX6vZyw12z3EW_jRC_cU255jpq3K4nXNW7mcxMn_fMep0b6TWkypMWma3L0TTA0W2 Yn.Tr94oi4yNr9dmAzOJo3Nx8WpoDEYEJa_Ms1UWk5tvBHasZeSnRm1Zo_kEt_EhKMCMUTsoq_0v IIlbaMLtpaG9tkChfHeKz0.4vJ3LxSVJytT3UME05a4lLmFcmv_uSE6bL8YeG3x70RF9akeFIHT2 OLCf0NsNqt94gDVCrMXjx6vFeqe4BUkrcADQAtgukwgC7e_3dWj0uw5dcyO3BH.dMjrTyib2BK_1 8KOk3aOd_Ga.kEPJM8j0E_viOpBeNGIVQx858k9jQRtP88pL246KfQm72cLm1aopQ4IFRyzc7WcD oY.QXyXpOdGgHF2WBqgjAB26LmBVPSe0KmmgGM6XzDmZHwg2Ctm_c.sa9.dj1p1Zn1kONLs.iRU5 EWg-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Tue, 6 Dec 2022 18:40:52 +0000 Received: by hermes--production-gq1-d898c4779-4ndbh (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0ef2dfc38259307e04135ca905abfec6; Tue, 06 Dec 2022 18:40:46 +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 \(3731.200.110.1.12\)) Subject: Re: FreeBSD on RPI4 B 8G rev 1.4 From: Mark Millard In-Reply-To: <9c587c3-b6e5-fbe2-7dcc-f7d98dd47ace@SDF.ORG> Date: Tue, 6 Dec 2022 10:40:36 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <047DB634-2D87-402D-A65C-A4F517E042BD@yahoo.com> References: <9c587c3-b6e5-fbe2-7dcc-f7d98dd47ace@SDF.ORG> To: adr X-Mailer: Apple Mail (2.3731.200.110.1.12) X-Rspamd-Queue-Id: 4NRTks2Q5Gz4P7C 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 Dec 6, 2022, at 08:56, adr wrote: > I'm giving a try again to freebsd in arm (I'd problems before) > looking principally for system stability and a reasonable state of > the ports tree, something I can't find anymore in other BSDs, at > least with arm. > > I'm using at this moment an Rpi4 B 8G rev 1.4. The only way I can > run this board no matter of using 13 release, stable or current > is with the EDK2 uefi firmware, in acpi mode only, and only with > the ram limit. I assume this means you run into some sort of failure(s) in some kind(s) of contexts. But you do not describe the contexts and their kinds of failures. If you want help, describe the context and symptoms for the failure. Given the lack of background information, my notes below may reference things that do not apply to your context: general notes. One issue is that you can not use modern RPi* firmware. You should use the RPi* firmware that is in the ports tree. The official FreeBSD build materials are based on that. (I tend to use something somewhat newer but I self support such and did my own testing.) The FreeBSD kernel mishandles the modern Device Tree content ordering, leading to a crash. Note: PCIe is internally involved with the XHCI (USB3) hardware. This explains the references to PCIe below. I use both FDT and ACPI style booting of various Rev 1.4 "B0T" 8 GiByte RPi4B's without using a 3 GiByte mode. ("B0T" is from the end of an ID printed on top of the SOC. "C0T" ones no longer have the bad wrapper logic around the PCIe block. But FDT based FreeBSD support does not treat "C0T" parts any differently. "C0T" work just as well that way.) For FDT based booting, I've had no problems testing/using official build FreeBSD materials for releng/13.* , stable/13 , or main [so: 14]. (But I also sometimes run with a patch that assigns a different highest DMA address to use with the PCIe. Both ranges work for what I've been doing. NetBSD vs. OpenBSD varies the address range used as well, last I knew.) For ACPI, FreeBSD does not have the handling of limited address range for PCIe bus mastering in the "B0T" parts. This can be tested via duplicating huge files in 8 GiByte mode (such as, significantly bigger than RAM) --and if that completes comparing the files. The fairly recent UFS valdiation code added tends to catch problems during the copy. Previously it was silently corrupting some data. I have a patch to the sources that I use to deal with making ACPI respect the "B0T" limitation: ACPI does provide the information. So my ACPI use is with 8 GiBytes --but via my self support for the issue. WARNING: the huge file testing can corrupt the file system beyond repair when FreeBSD is not using a correctly limited address range. Test only media that it is okay to reinitialize to see if a combination of materials is working! (It turns out that, like FreeBSD's kernel, the ACPI implementation always indicates a configuration valid for the "B0T" DMA addressing limitation, even on "C0T" parts. Again, "C0T" works fine that way.) Note: the emmc2bus in the "B0T" parts also have a addressing limitation that is not in the "C0T" parts. I've not yet done any testing for this. > I didn't expect this limitation after reading the > wiki. The xhci dma bug has been corrected in netbsd and openbsd. > Could someone share the state of this issue in freebsd? Also with > acpi the ethernet interface is not detected, I'm using RTL8152/3 > usb cards. FreeBSD has no ACPI drivers that cover the built-in Ethernet. To my knowledge, the FreeBSD folks that used to work on the RPi* support never claimed any ACPI support: only the port U-Boot's FDT --and only with the versions of RPi* firmware that have in the ports tree a the time. The same sort of thing applies to trying to use microsd cards in the built-in slot from FreeBSD after ACPI booting: no ACPI drivers that cover the context. The normal U-Boot FDT configuration has both of these working. Use of ACPI is historically: strictly self-support. > I'm impressed with the performance (without overclocking the cpu), > really impressed. And the usb subsystem looks more stable. I had > problems in the past (and in the present with other bsds), like the > system crashing when attaching or detaching some devices. > > Apart from the loss of ram and the inconvenience of not be able to > use the ethernet interface, I'm feeling very comfortable right > know. Glad it is working okay for your context. === Mark Millard marklmi at yahoo.com