From nobody Sat Jan 20 14:30:20 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 4THJnS5T23z57FXM for ; Sat, 20 Jan 2024 14:31:08 +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 4THJnS0kMcz4pVN for ; Sat, 20 Jan 2024 14:31:08 +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=Z8BNGrCF; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=nxBzzyTc; dmarc=pass (policy=none) header.from=f-m.fm; 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 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 9BF485C00ED for ; Sat, 20 Jan 2024 09:31:07 -0500 (EST) Received: from imap46 ([10.202.2.96]) by compute6.internal (MEProxy); Sat, 20 Jan 2024 09:31:07 -0500 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 :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1705761067; x=1705847467; bh=Ufj4lzK+N1 a0vLTrzf079bd3jdQjJ/wZlTkZwqC2Ikg=; b=Z8BNGrCFzXsl2JTW9Tl5R7pf0C c7trV107jxMXJEQrSiXJ3r9qfAEwusLT/mQOW84FgLkSUSUx1TcjiM+maXUeUhI6 TXj4+1NFPjc982VwT5719z4jAwe8nfzp3ep08FM326kSFZI/eGEmgkcf/8O6DdDc EsKtbJOxPDYqcmCgmouFyIBNjsy5u1h6HBzgM5fxWK75qjA4XYLeRP8IWJ3yW5YE zhF+CEw4KFYP80LewtnvE2qU6SPw7eoGWI5MZvYcYVastbfMvbrR4zmOdyY+EZFH iMMU/oYFoNly3oj6ihrV06BD7DQivQwubIRA/M5fbzr7tHgV5jYBNO0F9Z3w== 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:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1705761067; x=1705847467; bh=Ufj4lzK+N1a0vLTrzf079bd3jdQj J/wZlTkZwqC2Ikg=; b=nxBzzyTcDjqAqcstCNue1DSRI+KpNW6piQIGXeGJ74sL 9G5Tu4jqAeHEaf7FlN4GX0w/NlGN2elrdzq8SM/9opagQ8f9OD/5XYtW+8cvYY5o Hw4gC+byXraHrVGvnsE9OYw7GX9fFGGSjc++vHldV0U02550l2vycVC1hW3QM5D6 aN9a/mSznlta42KptO2URHjdU8XNmhTF3Di0kOcd8PCSgyaNwPrzE+EETCX2WtzK OBCC+LaAhAMYuLXspk3w2uNXrQaHvC8sflpbFgjXL7m2OPvGwKu7XLBKE1BlYTNp LaWK8YxG2rwpWQ47qh0pYP7NZkJdH2LwwDIzBl9MoQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdekvddgieejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffr rghtthgvrhhnpeelteeffeegueeiueejuddtgffhjedvfedtuefhvddttefgjeeijeeihf eljeeuueenucffohhmrghinhepfhhrvggvsghsugdrohhrghdpghhithhhuhgsrdgtohhm necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhhoih gusehfqdhmrdhfmh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 488A62A2008B; Sat, 20 Jan 2024 09:31:07 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-1374-gc37f3abe3d-fm-20240102.001-gc37f3abe 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 Message-Id: <1048d685-d0ff-4099-ac67-13708a38a919@app.fastmail.com> In-Reply-To: References: <33ECDC54-0595-4323-AC74-783C795CFE67@yahoo.com> Date: Sat, 20 Jan 2024 14:30:20 +0000 From: void To: freebsd-arm Subject: Re: https://github.com/pftf/RPi4 unusable for FreeBSD since at least Sept 2023 Content-Type: text/plain X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.11 / 15.00]; URL_IN_SUBJECT(1.00)[github.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.92)[-0.915]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.26:c]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.26:from]; RWL_MAILSPIKE_GOOD(-0.10)[66.111.4.26:from]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim]; FREEMAIL_ENVFROM(0.00)[f-m.fm] X-Rspamd-Queue-Id: 4THJnS0kMcz4pVN Hi Mark, On Fri, 19 Jan 2024, at 18:34, Mark Millard wrote: > I gather this was during the bsdinstall run, not > during a RPi* boot attempt. yes >> 2. I tried latest 14-stable > > 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. Yes. All images used were official ones either -release or -snapshot. > 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.) > > To have a reliable RPi* system that is unpatched, avoid any > form of UEFI with ACPI, including EDK2. 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? 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 the system works and is accessible via serial console. > 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. I suspect my complete failure to boot is down to a layer 8 problem. The initial problem I sought to address was why, on a current snapshot, the boot went to tftp first, see https://lists.freebsd.org/archives/freebsd-arm/2024-January/003487.html 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. 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. [1] Is it ok or optimal to use 13.1 msdos materials with 14-stable ? --