From nobody Sat Jan 20 18:09:18 2024 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 4THPdS19L3z56QKN for ; Sat, 20 Jan 2024 18:09:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.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 4THPdR5VfNz4Vgr for ; Sat, 20 Jan 2024 18:09:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705774170; bh=S2BAh6rA6NyiSjUCt+z1V/Y8Yc4+ZzFWnOJ8HgYC3/4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=GfSvK873/LPtA8A9rksvpNZvs9evMqnzjE597UxTZOROEarKlmOhSpH5x29J95YCEXsqSzcJBnTJ++MSblN4gcjoCOMJakYCzveU3pODbAdeLn+xdaGnAp1gPrg2hLTVRfDrsDvHvCyokgYluylZFCWeq1jeKq4s6Rkg5Y1r+tJdEE3KAVCv6ED2BQ5VdJFDE8ZgGg47e3dHfP7w2djNm/bF2Xr5IIWTWPAEyVf5wHDfa6ckn2pBfM7eCHYtL4bRGFshbQSXDIIkvh+KmRWcY21CHy7bCLFdYuWl8bJb1aaOsYnuHpU82L6z7R4/bNsYTfoqywxZGPGpMneyKhAhJw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705774170; bh=OzL+2imN7dEP07OWedkQMFzYILSHg/+JmqKGlOl2IwF=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=XtQMnBhNCGPnE73pIbI8fMI5Ft2ukIkO+aBMNWoXZHNKM5Ea/a39uTpR9oRHDLjVo9YFiVrGpvJR7quT6OF8XrXLpMHhgClHEGIWQWE1yB9/caAPHYSlB7MlVZzOqlXXNooJKKTaK3fVsNpGxMhtpBT7AoK2WhcZcNWJTuFhnhMEP488Ak6z4UGWhKyNHwFbtqrOn9A6YBdZCNlpQNoByW/MzKmE1onRh3SNSK9j9tpNy5TLvK1HgSIIB/crO8diFtxjVxwIFmiNfaN0DvskioX6Cv4cBWlqdvX6dbwp04TCDmY0IIJ+Zo8hsz/qRqmm5qJ1kWXq7UjB5Ko/ASO1PA== X-YMail-OSG: mKr9AkkVM1k88dOvlwvADD9r9RYEYd3kx4s04FsyDBpnBCQuo5ehnnTWP7qmkTC FCIUfmwUtZNES92niqqKZzYvyDutp4SDPnGZaoB_y6MTjljByELa6rx11f73fnpPLDd0A8_XBVtN xtpK14IqwWQpeY01.mNTjtpQ0.2gi3K26t_3C_M7BC_1_cEoP5u.vM.NBORPKSF1ECvkgr5.T0oM 0XrmP3oJW6Bu0alyFzGjLWMNcI3TY0EcWfgqo9kEWTuy.JQp7SIJeGkr5kWh7wRqLhRcUh3XSCgH V8UDMsxypg3ky..7FTKdc9MyvYWmLumQagC6lE6PNG7Y9sT9Kbe0b4MMWwCMitW_c0M7bji.L2Gw uTUzhEfptlMQjUDF7Dixcts5_lkUU7tKoKXH3SpwlzW0KnBXSzg7wl.pnHeXwtuchIKqsekJqokp 389iV8BVOwmxGItge0KCA.0vwX5ivQtF68Kukx.PVn3uQA8yj5VgaPleXIUgOsbZHCqfXXnYRtY4 IiHcLSfc6.8DxCFJ2kKUPggwJ7s2J0MWJFFB4zH4K0n1f9Am4dwOYuFHWDOF4_6ZF2QPxc53M5rc Oi1K0jKvc7J.OwgIHb1OO5Hhx6S9M49WKXsBYx_PFsbEJkkeneOvDhpguxwiGxNparMHED0rqH7a hIKlBdYRNlRyLFQlhrdF8TVtQVrxLBxsZ.YcgsAsZtYldvNm22BIeA1J9GPjTm5hmfGkFiNdBZwK tBjJ85EazfRbdkJEtQ7MXLzLXpeuDfSlebvEo3nCS.TgbRsqbX3VRS5HsvFJp2fdqS2hquKJt906 uC6588.ugDBQtITvLhKAa0rzfczghDrMWfy9lqzmq8E.j11v1xlLWxa59aClG2wDwHG1Sqx2LHrP mJT8Zrt7k10iHhBEKo_p9mpxsFgHZXpfYUDtJ0R_RV26V25_BWVx5UBTe2gUBLgIx6avlzCU8z5n xtnNwgteyKuY8Fo6EAYxUodmts_yWF76Dl6dnSUWCn2VSk145CxKVWzagtceUYPxTeBe6wHI72fi K_w644sqWVqIO6uTbgc4vfHk9owfjWjgOKOxqtXU6oBwJERsG2HjsCiBmUwEUWDS_5TidHsh8npT 7jzQN7g23L1B1GUsZTBztqWdnwzGyPBTpdeCqoIOQ7Egs28jpy4eYi.EU.0t_NbOn1vFVL5DR3Rq 7ugXOo_Ngnwe0NcrZegr3exXvQqsPEDju5Suft_2hIP6uY2XYj4EOeYTGTTdUicBzdQokn5NrXjE NpJB4Z8NBW1V_wwyfgjVQsJWl5OLALp6Am1mHPg_FY1Imu0JOzXILzQ44WB6Dqwzg44jaiRARkQp OWI.Kh71FmZXH3FRA4zcNSLpdsVHfJcG2L1Gh2Xr5RVPx9PK8MzEFO6Qe_YwFm_UJrrXmlbQMBzC apZL6bOt0M51l3Jc5W5jOLc4p7vKIJjbQVx2cGOVEYSg1s5Mmau3ygH_PUqfbXOrgBGtWAs.bqr5 fdaHxo1aXfU32ay_puFszujTenEuNbLEZXOqTEWS5f4re.sAHUSUdqAvERsgoj965Eai3MvzGINC j2chPR20gBT9xXO7qZ9_.JnsCQhi0cxq2eEuANYjQ7FrF25Is6lMz8rlFhDujqvPoEF0Hdhjck.Z 7DFMB9XHeWqaCHF6c59bOYtDyCUAqtU9rf65GxeGN5YSTbMsvr1RuBc0FUNSHo36E9pCaLqxqdHI Zvsj_q9uTEBx78W539lmwgqfWALt49r4Txr_MWexsB2lHaukQX07ebl9YqfoKRjQfmViLuYkxw4s ExEFfILMFev194yKCVE2yoMZh1t9pZKrOsv4iK2MjBYVA2Zkktz8tc7aI0clIt_MHKuV8tjzbacW IVxrRJUc_K5nefDH4lAdCRT0ecsGFcoXAs6EuQQP3HJ7_NRubJIBoHuzz9cWQ.sgwDUztvdTZEUU 4cyY.g4WiDME24xvZObfezOD.BbA1p4gJP6marffaxam7QD5TO9eqNKU.yEw9Ac8GO2qo70YhJqg 9ivF9gD_XqzW8hgMYI5idXLWX65ar2RwQytGVsFoidMQYvAGCu8wN1pKiKWUW.MPax1a50fFrN4p zJIHS3PUXXE48yTP2ECnEJ0TndERd.nfHOB6uy1OMxvmu2fg4TMx5_5c2v.g6bRcpUmDsqtpeCAe JuOhWHMPKFebD6BHOuzlnNlo5oQ8P2Urye84rel.rANv1hvR7iQrDFv034aO422PRxqvLlNNFmZg sTK1iiYVSPSLaip.L44fQWq05R37wfwIpiF5iZXIOUeGheYqSXRD_HFMUyRtTxGiSbqWtUTOFogK ZaLkAfw-- X-Sonic-MF: X-Sonic-ID: cf982a26-eb3e-4563-9dd6-98435cc501e4 Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sat, 20 Jan 2024 18:09:30 +0000 Received: by hermes--production-gq1-78d49cd6df-hlpbq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 92de621ebbf84b7fe9afe50ffab49c40; Sat, 20 Jan 2024 18:09:29 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: https://github.com/pftf/RPi4 unusable for FreeBSD since at least Sept 2023 From: Mark Millard In-Reply-To: <1048d685-d0ff-4099-ac67-13708a38a919@app.fastmail.com> Date: Sat, 20 Jan 2024 10:09:18 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <79F2132D-5B0B-437D-976A-305333D4325D@yahoo.com> References: <33ECDC54-0595-4323-AC74-783C795CFE67@yahoo.com> <1048d685-d0ff-4099-ac67-13708a38a919@app.fastmail.com> To: void X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Queue-Id: 4THPdR5VfNz4Vgr 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 Jan 20, 2024, at 06:30, void wrote: > Hi Mark, >=20 > On Fri, 19 Jan 2024, at 18:34, Mark Millard wrote: >=20 >> I gather this was during the bsdinstall run, not >> during a RPi* boot attempt. >=20 > yes >=20 >>> 2. I tried latest 14-stable >>=20 >> Do you mean an official snapshot of 14-stable dd'd to media? >> Otherwise what was done is unclear: unable to know what to >> do to try replicating the problem. >=20 > Yes. All images used were official ones either -release or -snapshot. >=20 >> FreeBSD does not handle the bounce buffers correctly when >> UEFI/ACPI is used. Only U-Boot is officially supported. >> Ignoring other currently existing problems with booting >> UEFI/ACPI, even if/when it boots, the file system I/O is >> subject to random corruptions from the mishandling. >> (Sufficiently large file use can make the existence of >> some corruptions reliable, but where varies.) >>=20 >> To have a reliable RPi* system that is unpatched, avoid any >> form of UEFI with ACPI, including EDK2. >=20 > I didn't realise at the time EDK2 was explicitly UEFI. I was sure to = select > FDT from its TUI. I also didn't know if ACPI is being used. How would = I tell? Sorry. I made the assumption that you were using the default, which was just UEFI/ACPI as I remember. I use EDK2 in order to also test using UEFI/APCI so I've not tried the other selection(s), using FreeBSD's normal U-Boot for UEFI/fdt style. (In part because FreeBSD is implemented to match the RasPiOS device tree that results. EDK2's fdt need not match --and so the kernel support status is not obvious.) > I want the system to always run headless and reliably, and am not = concerned > or knowledgable enough to differentiate 'legacy' or 'uefi', as long as=20= > the system works and is accessible via serial console.=20 >=20 >> I suggest checking on bootability via official snapshots >> dd'd to media. If that works, then smeothing more specific >> is going on for the other forms of producing media that are >> being tried. >=20 > I suspect my complete failure to boot is down to a layer 8 problem. >=20 > The initial problem I sought to address was why, on a current = snapshot, the > boot went to tftp first, see=20 > = https://lists.freebsd.org/archives/freebsd-arm/2024-January/003487.html My update to the new 2024.01 U-Boot no longer gets that behavior (so far?). > The situation I now have is 14-stable booting with 13.1-R msdos = materials [1] > which is reliable so far and doesn't try tftp first. My stable/14 based boot media is using U-Boot 2023.10 and is not getting the TFTP problem. I expect that stable/14 snapshots will switch to 2024.01 but main [so: 15] just happened to complete the port->package builds first. > It uses config.txt > for overclocking. I don't know if this is uefi or legacy but i suspect = it's > legacy. The serial console works. >=20 > [1] Is it ok or optimal to use 13.1 msdos materials with 14-stable ? The FreeBSD's loader that is used is in the msdosfs and should be updated. Avoiding ZFS creates less dependence on FreeBSD loader updates. The loader has to know about some new ZFS/zpool features in order to allow booting with them. I suspect that normal stable/14 with the 2024.01 U-Boot will work just fine relative to TFTP. I would not want to hold at 13.1's msdosfs content indefinitely. But I'm not aware of problems for never-ZFS contexts for now. I do not know if you noticed main's UPDATING entry: 20231120: If you have an arm64 system that uses ACPI, you will need to = update your loader.efi in the ESP when you update past this point. = Detection of ACPI was moved earlier in the binary so the scripts could use it, but = old binaries don't have this, so we default to 'no ACPI' in this = case. You can undisable ACPI by doing OK unset hint.acpi.0.disabled This can also be used to recover any other system that was = updated in the small window where amd64 was also broken. It would not matter for non-ACPI. (But ACPI support has other issues in FreeBSD.) =3D=3D=3D Mark Millard marklmi at yahoo.com