From nobody Tue Jul 05 13:51:50 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 2648E1D0F1E7 for ; Tue, 5 Jul 2022 13:53:19 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Lckf619mJz3hWJ for ; Tue, 5 Jul 2022 13:53:18 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (localhost [127.0.0.1]) by phouka1.phouka.net (8.16.1/8.16.1) with ESMTPS id 265Dpo0p019390 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 5 Jul 2022 06:51:50 -0700 (PDT) (envelope-from warlock@phouka1.phouka.net) Received: (from warlock@localhost) by phouka1.phouka.net (8.16.1/8.16.1/Submit) id 265DpogP019389; Tue, 5 Jul 2022 06:51:50 -0700 (PDT) (envelope-from warlock) Date: Tue, 5 Jul 2022 06:51:50 -0700 From: John Kennedy To: "Dr. Rolf Jansen" Cc: freebsd-arm@freebsd.org Subject: Re: Failed to execute custom kernels which where build on a RPi 4 operated by 13.1-RELEASE Message-ID: References: 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4Lckf619mJz3hWJ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of warlock@phouka1.phouka.net has no SPF policy when checking 107.170.196.116) smtp.mailfrom=warlock@phouka1.phouka.net X-Spamd-Result: default: False [-1.78 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.98)[-0.978]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[phouka.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arm]; FORGED_SENDER(0.30)[warlock@phouka.net,warlock@phouka1.phouka.net]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:14061, ipnet:107.170.192.0/18, country:US]; FROM_NEQ_ENVFROM(0.00)[warlock@phouka.net,warlock@phouka1.phouka.net] X-ThisMailContainsUnwantedMimeParts: N Let me take a slightly different track here... I believe you've said that 14.0-CURRENT (which works without hanging) and 13.1-STABLE have fixed the RTC problem but you'd specifically like to be running 13.1-RELEASE. I think you've implied that you've booted up on 13.1-RELEASE (but did have RTC problem, presumably because the changed haven't been MFCed all the way into the releng/13.1 branch. The delay is the whole reason I'm running stable/13 myself, although like I said for amd64 reasons and just keeping the arm64 systems par. While Mark has made me a bit paranoid with what could go wrong at the pre-FreeBSD stages, if you can reliably recompile 14, those wouldn't seem to be an issue, if everything else is constant. Personally, I wouldn't run 14 in a production environment. It's been very good to me in a bhyve environment, but it's not called -STABLE for a reason. The reason I like releng/13.1 over stable/13 is that I have a Pavlovian urge to keep things patched. So I can totally appreciate you wanting to run something stable and secure that doesn't get too many updates. I'd just try to aim you at stable/13 vs main, at least if you can't backport the RTC fix into releng/13.1. But that being said, still a custom kernel of sorts, yes? So is your 14.x setup the same as your -RELEASE setup? When I bootstrapped myself initially, I burned a SDCARD and booted up (passed, so check). Then I did the bsdinstall onto my USB disk, stomped on the EFI/msdos contents with the known-good SDCARD contents. Yanked out SDCARD, booted up, ok, USB-only known-good there. Happily, I could pkg-install things (like git) to recompile the kernel+world. Reboot with that, "custom" kernel check. Recompiling all the packages locally was a nice stress-test. I don't think "downgrading" from 14 to 13 is generally recommended (in my case, ZFS options would generally get me, but I believe you said you're UFS). Basically, you've got situations where uboot can hand off to modern FreeBSD kernels on your hardware. I think you're seeing a lot of lines of text because we're being paranoid about blind spots where you can't see some missing error message that would pinpoint the problem. All else being equal, if you can boot a stock 13.1-RELEASE kernel image, you should be able to recompile that kernel in place and expect it to boot. So we're looking for the "not equal", something that we're assuming that is wrong.