From nobody Wed Apr 26 12:22:30 2023 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 4Q5ygV6VGpz47vdj for ; Wed, 26 Apr 2023 12:22:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-20.consmr.mail.gq1.yahoo.com (sonic310-20.consmr.mail.gq1.yahoo.com [98.137.69.146]) (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 4Q5ygT5L0Bz43m1 for ; Wed, 26 Apr 2023 12:22:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=okslHnFz; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1682511763; bh=VUEetB3rUILCZMW5GhPqQfw30iTixljQu7BLUHxAAQ8=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=okslHnFzFkE06yPL7G2IxOtpaw/1WxbIOtOOu5fw/N1rn2OBsroRODrpFdrRedhZFoodD/Bm0pKHSALGXbgX2AEcMzhoPWzUMYVSbfmrNY/edc79mWun2+ztxDOIqXd5uvEI2Ez81h/A4PI3DQ8YpnXpoZ4piZcc9mInP+g1nlrinwnCt3L4+DUisJC5aD8hL9aZOfFIlD7+50t1mS6CgWmBtJXC6PgnXwT25Ci0Z7rNxZvNRuan5lZguZdkj8OL0Jj9cF8ykhD4A/GKnNGCLY1G77XlABUUHaarX/rFlC9ncKw0Qz3pQOe9SvvDUiaWpYS/aFldMdr1dSvLnZHB4Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1682511763; bh=uyXjfwuvOVIBoe+CZFFZSS9iQpZuSQo0b5eUCrATHmk=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=hmHrLWavu8tta8tc98rIRJ7z5jJ2ifCLnbGFf+Pw69vn34ftCV6LUfvi8tzxziOC97oG37kxiORNPWi0wMzkpMIMPuO91czrviSWc/0M/EUGqc/bBxUqDSwD4R5UpXrX10oMAnf/RJsiKZfTYIBZAi7mXF1Bw/rftVcvaHDgMm7lQo01GEka1OtPYJt90aEZOxsp5132b/QFkPDn1J7FRFWcsJnVvO10P8L7HA16ZM+Q8yU5zE6aQsM3PyWQfdKTlLZbuz+kwDXRCCjQVtU6ERsPZQvHUoOdn31Yy4IE4yegdBlhfpoDnuFexa/603JgfWSV13nOHbzz0UknybkEGQ== X-YMail-OSG: 775Rfo0VM1l080DG6.iw_AFpy440pzdp3U8F2TpQ0Ig.fb62hugoLxNnjngctdm POkt3wve4__anY8L7L3zIWnbRebuYGlIREUYOPu0qYHYTP_SKRyaeHWG3f9Vqjro2mXAjr2qc0h_ GCDVRKn6LnBpPAI6a32Qh0_6wnejvHGgUgh.tZzoq2XyPMHniuZPlvXDv2b_GSVh1V6Q535IVhoW O11Ug9lXZt51O1lhE4Zh2odoEljsNUB53kjJnGu8mED7euYlWsZhi.x5w_TcGYlUd3A2twZhD9Bc Pbf9ULHVOp0_UCg7nXrfDrhM3usQO4BtiuCkuhohKVauPgQYIENweAjHhYumMwfPQPD.UcPL5UXZ 7MwJjp7HKDI8vqqV7wIcWa6GxkqDc3xD_pX57JgOyKjGelFtl9IaZOBuszDyHN1MJ1SEusoagpDZ v8WI1v.0FQ3LLfaBzAInmb3MSQy3L7RVCIh1PQpi9Zrrj3qGXhQInn1TtZrR.dFN95_LLtW7sXFK X3KleuMIc25jNIeozJNpwsK5sD8XxlgVOKIb5Uv8QGCXZADsxXguR9v0ZWuIFHlq5hPVrt6kL1ZE ItlEDEAdk_6DIT35EpgQaHJuwsaajYTCWlpVH.SFiWWY7aJU46MSi1NzrvSVDb_bSTB3hsSYjrTU RDh_5_SZIxiF9UFg5G1Cav2iDIot7etvd8pCLUEKOd3YdyQmxl7L_mpubi1Ya9v5CUzKa2zw6eF. laFUGwXfVwTDBsE_0Aqjj60CaAf2zBP0UDKae4a5XTv3aSdGDCvpR51ZWNtAicxILd8EZ3BCEp48 bPRKStK7kErlLo6Tky9tiEnv7z0BofZ0ig1xy1YbrEpATkNv1QZVPol_IGrlzOLbf4v.gbVnST6x 72lxkuCI08vdUx9B.gGKLppG.RB.4fI70TvaZgRGLmWbzhyWmvLSZxPPWiaAN3EFfD8Yvs5MusI7 E9XWrUzYQpGdTEEHfJ2NxYI8rj3_pUR8P7Cv4tJEZQ7USt9yP.8KQVypO67gKiwGoL9KfxhYFvGQ NjhywLjt0V1TDz3df0tAj5JMWACgHGdRgR6BBXq7.JBSzefRFFknRoyntFkK96oTssSVKLdM9gcV 3fvVGNU4Yc1RvMAG0zE2wf6igS85z1.MYTuzWGKdKPR4qDRMLCEzhumufNis0eNn5VnAP8KA.4y2 z9U4f9VYcxRj4ipRUk3_QNzErFlLYqjzJnQ.CMZHaGTCW3jBw.9xo66MecGo3u5rOKYrJduXbXbh Xi4oCZ.pcWgRufYXwDUchDoVJmm.9Z1EZBIvCx33sdZFR02xVIrBGQRzmM93NH2QHqSg5A9V6Nxy Xyq8F8TCydCeCr17qz399z_GMAJtENm6fnejCCQvqujpNwNyxXbYipFVzSPPitrG4q0ELtLWuxbc t305vMivWYpdf87tttuJagngddFCe7Vx2QrolKhaqxpPI3QyPguKXPTqiuwdTa07D6W5URpS3yYk yYxDDTBsr5A7VaDd1qNY_ouGNQjKXuwam5j4tXVzvPvGDZp8l.XwPbLdirTPeGjWA2iQY5u2n0mL ZlFHNehrdGnOfI4E7y18wPOoc2Ylk6IgZs6ItyXaye7X6nxzPRxSBlOZ4lDTQLNMsr_XEO7PvQh. awmkaB0tMJJEHLzTYkehkdMHV0LULSkhZsVIQkYYsAKD.SqVYJaROEx1LR6FmFp1_5LbvzkKV3SJ cBLiJEVVfnrmV319wmPXSywoMEhINLWwycBnLH2XUHtZ8UBY9gus7e8eGWeGcc7HOJ7nkMVPRP4u R5TiHXSkkH2ctEm2fsqFTj5xD7aj4wi67UvWA.zS0bhkkJMmPmWjtzPitJu8TgpUDIsLww_nTPLd rekjSOUAzOY9eW1ajacn1_DjTXyUnzFy2HHIs1SEqseTPNp_pyLFN0MzAa3iZIIO.i5Rq7R3L2mZ NCC116XhkSYcydAoDtjNzyCwk44ky9f0V85hsmnzWAldXMGRHKTQmY6YnPWdUAbsiVSxdcPAIKbe Cu2C6llqFUwhubf9Pg4JjZDiuT3tlOtyKCx1UhFlEnIn84wazII5lkxdzt3ZQLr3RQzNLVhkTrkM qR.al22MgHzOPq6DfPeG4x6A.IAaJGoRuNjyytpOpVQGH1dlwUfh27sv9Eoflp4MwXEHZ.dLMsKi 0xdXWh42vQCyQ4hyd3sE6_yNoPe1fjh3yERtw.R9LFP2vxtEaKBWCXf7IU.fVk9Bvu4v6RsGmLgq 4TBA71HXwDravEmyz50HTEv72_ROl5YxBu1ZLeTazCxB.opiNPj2kipQwQbOw X-Sonic-MF: X-Sonic-ID: d56aa234-2723-4421-ac92-e1f2087b04d1 Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Wed, 26 Apr 2023 12:22:43 +0000 Received: by hermes--production-gq1-546798879c-dcj2l (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ac3e6ba72471c2d3c84c1f92a8ee8df0; Wed, 26 Apr 2023 12:22:41 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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.400.51.1.1\)) Subject: Re: Windows Dev Kit 2023 usage notes for main [so: 14], including about oddities Date: Wed, 26 Apr 2023 05:22:30 -0700 References: To: freebsd-arm In-Reply-To: Message-Id: <3BA13B38-6C80-4224-BAD3-25DF1CA863E3@yahoo.com> X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spamd-Result: default: False [-3.42 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.92)[-0.919]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.146:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-Rspamd-Queue-Id: 4Q5ygT5L0Bz43m1 X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N [I'm inserting some updates as in-line comments.] On Apr 22, 2023, at 20:50, Mark Millard wrote: > Up front odd requirement just for the USB-C ports: >=20 > At least my examples of USB3.2 storage media plugged > into the USB-C ports are not detected by the FeeBSD > kernel but are detected and handled by UEFI ( and, > so, by FreeBSD's loader.efi ). Thus the combination > may need to be avoided for now. >=20 > Plugged into the USB-A ports, I had no storage media > problems. I had no problems with my example USB3.0 > media in USB-A ports. >=20 > But I do not have a way to plug a USB3.0 storage > media example into a USB-C port so I've no information > on that combination. >=20 > I've submitted: >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271012 >=20 > about the USB-C non-detection issue. >=20 > I'll note that: >=20 > https://learn.microsoft.com/en-us/windows/arm/dev-kit/ >=20 > reports: >=20 > QUOTE > When connecting an external keyboard or mouse, use the USB-A ports, > not USB-C. Using USB-C to connect a keyboard or mouse will only work > intermittently. > END QUOTE >=20 > (It is unclear if that is a Windows specific issue, UEFI issue, > both, or even more general.) >=20 >=20 > My notes below will ignore that I had steps that were > discovery of the issues above: a simplified history. >=20 >=20 > These notes are based on leaving Windows 11 Pro in place > on the internal storage media: So just USB storage media > for FreeBSD. >=20 > First time Powered On: >=20 > I used the buttons to boot into UEFI and set the secure > keys to none, disabling secure boot. >=20 > The (small round) UEFI button is not made to be easy > to press/hold. The USB-boot button is bigger and > easier to press but is still not made to be easy. > (I've set up to avoid its use.) As I understand, these > two buttons are to be operated when also pressing the > power/reset button. >=20 > An FYI about the UI in UEFI is that, despite lack of visual > feedback during a drag, one can: >=20 > A) Drag left somewhat and release in order to "swipe left". > B) Drag up/down and release in order to change the boot > order for finding EFI boot media and such. >=20 > I moved USB to the top for the boot order and diabled > all the other enabled selections. But, if it does not > find EFI media on USB, it still eventually boots > Windwos 11 Pro. >=20 > It appears that once powered on, the power switch being > held down will eventually force a restart, not a power > off. It looks like the power cord is the way to force a > power off. >=20 > The UEFI has no command shell access presented. >=20 > After setting up UEFI as I wanted, I made sure that > /boot/loader.conf on the USB boot media contained: >=20 > # > # To allow the Cortex-A78C/Cortex-X1C based > # Windows Dev Kit 2023 to boot: > hw.pac.enable=3D0 Recent enough kernels now automatically deal with the above for the Windows Dev Kit 2023: no need to be explicit once having progressed to such. > (I'd read other material indicating the need. I've > never seen what happens without it.) >=20 > I next rebooted with the FreeBSD media plugged in. > (Windows 11 Pro never having a boot even started yet.) >=20 > Note: > My boot media here is main with enabling of tuning > for cortex-a72 (media I use with other matchines as > well). The build of main is a non-debug build (but > with symbols not stripped). >=20 > The absence of feature-register value reports by the > kernel after CPU 0 is an implicit indication of "same > as for prior CPU". Only CPU 0 gets such feature > register value reports. >=20 > Note: > It is known that the cortex-a78c and cortex-x1c > feature regsters reports are not exact matches > to the clang or gcc13+ defaults for targetting > those parts. Even more: There are committed changes for LLVM defaults for the A78C and X1C. It still does not seem to be a full match to the reported feature- register values f or WDK23. (Operating systems normally do not report about various feature fields that they always ignore.) FYI, FreeBSD indicates (HoneyComb then WDK23): CPU 0: ARM Cortex-A72 r0p3 affinity: 0 0 Cache Type =3D <64 byte D-cacheline,64 byte = I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG> Instruction Set Attributes 0 =3D Instruction Set Attributes 1 =3D <> Instruction Set Attributes 2 =3D <> Processor Features 0 =3D Processor Features 1 =3D <> Memory Model Features 0 =3D Memory Model Features 1 =3D <8bit VMID> Memory Model Features 2 =3D <32bit CCIDX,48bit VA> Debug Features 0 =3D Debug Features 1 =3D <> Auxiliary Features 0 =3D <> Auxiliary Features 1 =3D <> AArch32 Instruction Set Attributes 5 =3D = AArch32 Media and VFP Features 0 =3D AArch32 Media and VFP Features 1 =3D CPU 1: ARM Cortex-A72 r0p3 affinity: 0 1 CPU 2: ARM Cortex-A72 r0p3 affinity: 1 0 CPU 3: ARM Cortex-A72 r0p3 affinity: 1 1 CPU 4: ARM Cortex-A72 r0p3 affinity: 2 0 CPU 5: ARM Cortex-A72 r0p3 affinity: 2 1 CPU 6: ARM Cortex-A72 r0p3 affinity: 3 0 CPU 7: ARM Cortex-A72 r0p3 affinity: 3 1 CPU 8: ARM Cortex-A72 r0p3 affinity: 4 0 CPU 9: ARM Cortex-A72 r0p3 affinity: 4 1 CPU 10: ARM Cortex-A72 r0p3 affinity: 5 0 CPU 11: ARM Cortex-A72 r0p3 affinity: 5 1 CPU 12: ARM Cortex-A72 r0p3 affinity: 6 0 CPU 13: ARM Cortex-A72 r0p3 affinity: 6 1 CPU 14: ARM Cortex-A72 r0p3 affinity: 7 0 CPU 15: ARM Cortex-A72 r0p3 affinity: 7 1 No HoneyComb cpu report indicated differences in register values. Windows Dev Kit 2023 (with some notes/warnings added): CPU 0: ARM Cortex-A78C r0p0 affinity: 0 0 Cache Type =3D <64 byte D-cacheline,64 byte = I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG,IDC> Instruction Set Attributes 0 =3D = NOTE: CondM-8.4 indicates: FEAT_FlagM; LLVM: FeatureFlagM, = so: +flagm WARNING: gcc13 has FLAGM missing from the cortex-x1c default features NOTE: DP indicates: FEAT_DotProd; LLVM: FeatureDotProd, = so: +dotprod NOTE: Atomic indicates: FEAT_LSE; LLVM: FeatureLSE = so: +lse WARNING: gcc13 does not seem to have a LSE NOTE: Lack of FreeBSD FHM_IMPL indicates no FEAT_FHM; LLVM: no = FeatureFP16FML, so: -fp16fml WARNING: LLVM has FeatureFP16FML for its -mcpu=3Dcortex-a78c default, at = least in LLVM15 NOTE: gcc13 does not indicate its F16FML. Instruction Set Attributes 1 =3D NOTE: RCPC-8.4 indicates FEAT_LRCPC2; = LLVM: FeatureRCPC_IMMO, so: +rcpc2 WARNING: LLVM has just FeatureRCPC for its -mcpu=3Dcortex-a78c default WARNING: gcc13 seems to only have a RCPC NOTE: APA EPAC2 indicates FEAT_PAUTH2 (QARMA/Architected algorithm) NOTE: LLVM only has: FeaturePAuth, so: +pauth; gcc13 only has PAUTH as = well NOTE: E.g., -mbranch-protection=3Dpac-ret for armv8.2 (avoiding RETAA = that requires armv8.3+) NOTE: not -mbranch-protection=3Dstandard (implicit +BTI): BTI requires = ARMv8.5 NOTE: Lack of API variant indicates lack of support for IMPLEMENTATION = DEFINED algorithm NOTE: DCPoP (old ARMv8.2-DCPoP) indicates FEAT_DPB; = LLVM: FeatureCCPP, so: +ccpp WARNING: gcc13 does not seem to have a DCPoP/DPB/CCPP Instruction Set Attributes 2 =3D <> Processor Features 0 =3D = Processor Features 1 =3D Memory Model Features 0 =3D = Memory Model Features 1 =3D Memory Model Features 2 =3D NOTE: AT indicates: FEAT_LSE2; LLVM: FeatureLSE2, but no = command line notation. WARNING: LLVM has FeatureLSE2 missing for its -mcpu=3Dcortex-a78c = default WARNING: gcc13 does not seem to have any of: LSE2, IESB, CCIDX, UAO, CnP WARNING: LLVM does not seem to have any of: IESB, CnP Debug Features 0 =3D Debug Features 1 =3D <> Auxiliary Features 0 =3D <> Auxiliary Features 1 =3D <> AArch32 Instruction Set Attributes 5 =3D = AArch32 Media and VFP Features 0 =3D AArch32 Media and VFP Features 1 =3D CPU 1: ARM Cortex-A78C r0p0 affinity: 1 0 CPU 2: ARM Cortex-A78C r0p0 affinity: 2 0 CPU 3: ARM Cortex-A78C r0p0 affinity: 3 0 CPU 4: ARM Cortex-X1C r0p0 affinity: 4 0 CPU 5: ARM Cortex-X1C r0p0 affinity: 5 0 CPU 6: ARM Cortex-X1C r0p0 affinity: 6 0 CPU 7: ARM Cortex-X1C r0p0 affinity: 7 0 No WDK32 cpu report indicated differences in register values. Checking the match to documenation and defaults for LLVM via : arm_cortex_a78c_core_trm_102226_0002_03_en.pdf (the "a78c .pdf") arm_cortex_x1c_core_trm_101968_0002_04_en.pdf (the "x1c .pdf") DDI0487_I_a_a-profile_architecture_reference_manual.pdf and: = https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/TargetPar= ser/AArch64TargetParser.h = https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/AArch64/AAr= ch64.td (The first two .pdf's indicate specific field values to look at in the 3rd .pdf .) Considering only cortex-a78c and cortex-x1c, I see that the two should be the same for the relevant features I was looking at but at least one of the 2 has the wrong default feature status for 4 examples of FEAT_??? . ID_AA64ISAR0_EL1 TS, bits [55:52] =3D 0b0001 (FEAT_FlagM) but LLVM git main still has cortex-x1c with AArch64::AEK_FLAGM missing in AArch64TargetParser.h --yet correctly has FeatureFlagM in AArch64.td . It seems -mcpu=3Dcortex-x1c+flagm notation is best used explicitly as things are. ID_AA64ISAR0_EL1 FHM, bits [51:48] =3D 0b0000 (no FEAT_FHM/no fp16fmll) but git main still has cortex-a78c with AArch64::AEK_FP16FML in AArch64TargetParser.h and FeatureFP16FML in AArch64.td . I seems -mcpu=3Dcortex-a78c+nofp16fml notation is best used explicitly as things are. ID_AA64ISAR1_EL1 LRCPC, bits [23:20] =3D 0b0010 (FEAT_LRCPC2) but LLVM git main still has cortex-a78c with FeatureRCPC (FEAT_LRCPC) in AArch64.td instead of FeatureRCPC_IMMO (FEAT_LRCPC2). No notation in AArch64TargetParser.h refers to FEAT_LRCPC2 so no -mcpu=3Dcortex-a78c+??? can cause the FEAT_LRCPC2 status. ID_AA64MMFR2_EL1 AT, bits [35:32] =3D 0b0001 (FEAT_LSE2) but LLVM git main still has cortex-a78c with FeatureLSE2 (FEAT_LSE2) missing in AArch64.td . Nothing in AArch64TargetParser.h refers to FEAT_LSE2 so no -mcpu=3Dcortex-a78c+??? can cause the FEAT_LSE2 status. So it seems that: -mcpu=3Dcortex-x1c+flagm also gets FEAT_LRCPC2 and FEAT_LSE2 status but avoids getting FEAT_FHM (matching the combination of the 3 .pdf files for the 4 FEAT_??? in question). -mcpu=3Dcortex-a78c+nofp16fml also gets FEAT_FLAGM but does not get either of FEAT_LRCPC2 or FEAT_LSE2. (Not fully matching the 3 .pdf files for 2 FAT_??? .) It does avoid getting FEAT_FHM status. > A mix of differences for (a line > with alternate synonyms from differing places > referencing the feature sets): >=20 > FeatureFlagM/AArch64::AEK_FLAGM/FLAGM/ARMv8.4-CondM/FEAT_FlagM > and: > FeatureFP16FML/AArch64::AEK_FP16FML/?gcc?/ARMv8.2-FHM/FEAT_FHM >=20 > clang and gcc13 are not in full agreement about those. >=20 > But I've not done any tuning variation experiments. I now have. More later below. > The boot shows ACPI related errors/warnings: >=20 > ACPI Error: AE_NOT_FOUND, While resolving a named reference package = element -\_SB_.UBF0.PRT0 (20221020/dspkginit-605) > ACPI Error: AE_NOT_FOUND, While resolving a named reference package = element -\_SB_.UBF0.PRT1 (20221020/dspkginit-605) >=20 > ACPI Warning: \_SB.GPU._CLS: Return Package is too small - found 1 = element, expected 3 (20221020/nsprepkg-511) >=20 > can't fetch resource for \_SB|.ADC1 - AE_AML_INVALID_RESOURCE_TYPE >=20 > It also has all 32 temperature sensor accesses as failing, > spaming the console with messages about each on a regular > basis. It contributes to /var/log/messages* turnovers: >=20 > acpi_tz0: error fetching current temperature -- AE_NOT_FOUND > . . . > acpi_tz31: error fetching current temperature -- AE_NOT_FOUND >=20 >=20 > Just FYI: A problem that I've noticed is (e.g.): >=20 > # date > Wed Dec 31 16:50:41 PST 1969 >=20 > despite /etc/rc.conf having: >=20 > ntpd_enable=3D"YES" > ntpd_sync_on_start=3D"YES" >=20 > and it working to set the time when booting other > machines (RPi*'s) that have no RTC. I've explicit > set the date when I've cared. Turns out the ntpd problem was a kernel issue and recent enough kernels have ntpd working again. None of the ntpd lack of time setting was specific to the Windows Dev Kit 2023 context. (I'm also setting up the zfs contexts to have sysutils/fakertc installed and enabled so, hopefully, fewer early timestamps will be wildly messed up for systems without a RTC.) > I was unable to replicate the report: >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D270805 >=20 > in my main [so: 14] context. My earlier notes there > are a mess from an operator error not noticed for some > time and the process of exploration being visible. I'll > not get into the details here but it is another USB > storage device related oddity. >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D270935 > (not mine) is about (shown in truss output form): >=20 > # truss efivar > . . . > openat(AT_FDCWD,"/dev/efi",O_RDWR,00) =3D 3 (0x3) > ioctl(3,EFIIOC_VAR_NEXT,0x2b0510b84740) ERR#78 'Function not = implemented' > . . . >=20 > # truss efibootmgr > . . . > openat(AT_FDCWD,"/dev/efi",O_RDWR,00) =3D 3 (0x3) > ioctl(3,EFIIOC_VAR_NEXT,0x6c2fa42cdd90) ERR#78 'Function not = implemented' > ioctl(3,EFIIOC_VAR_GET,0x6c2fa42cdda0) ERR#78 'Function not = implemented' > ioctl(3,EFIIOC_VAR_GET,0x6c2fa42cdda0) ERR#78 'Function not = implemented' > ioctl(3,EFIIOC_VAR_GET,0x6c2fa42cdda0) ERR#78 'Function not = implemented' > fstat(1,{ mode=3Dcrw--w---- ,inode=3D152,size=3D0,blksize=3D4096 }) =3D = 0 (0x0) > ioctl(1,TIOCGETA,0x6c2fa42cd6c8) =3D 0 (0x0) > BootCurrent: 0000 > write(1,"BootCurrent: 0000\n",18) =3D 18 (0x12) > ioctl(3,EFIIOC_VAR_GET,0x6c2fa42cdda0) ERR#78 'Function not = implemented' > ioctl(3,EFIIOC_VAR_GET,0x6c2fa42cdda0) ERR#78 'Function not = implemented' >=20 >=20 > Performance examples for buildworld buildkernel (the > way I normally build such, not defaults): >=20 > Some idea of performance for building things come from > doing "rm -fr" then rebuilding the world and kernel and > doing the same on another type of machine, here a > HoneyComb. It is the exact same storage media drive > and rebuilding the exact same build directory tree: >=20 > HoneyComb: World built in 3463 seconds, ncpu: 16, make -j16 > WDK23: World built in 6601 seconds, ncpu: 8, make -j8 >=20 > HoneyComb: Kernel(s) GENERIC-NODBG-CA72 built in 318 seconds, ncpu: = 16, make -j16 > WDK23: Kernel(s) GENERIC-NODBG-CA72 built in 597 seconds, ncpu: = 8, make -j8 >=20 > Note for both contexts: >=20 > make[1]: "/usr/main-src/Makefile.inc1" line 326: SYSTEM_COMPILER: = Determined that CC=3Dcc matches the source tree. Not bootstrapping a = cross-compiler. > make[1]: "/usr/main-src/Makefile.inc1" line 331: SYSTEM_LINKER: = Determined that LD=3Dld matches the source tree. Not bootstrapping a = cross-linker. >=20 My normal aarch64 systems are cortex-a72 based and are running a world and kernel that were built based on using -mcpu=3Dcortex-a72 for instruction set selection and other tuning. Well, I've now used a system that was built based on -mcpu=3Dcortex-a78c+flagm for world and kernel and I did the "rm -fr" and from scratch buildworld buildkernel on the WDK23. I reshow the prior results and add the new "optimzed context" ones: HoneyComb: World built in 3463 seconds, ncpu: 16, make -j16 WDK23: World built in 6601 seconds, ncpu: 8, make -j8 WDK23 optimized: World built in 4690 seconds, ncpu: 8, make -j8 HoneyComb: Kernel(s) GENERIC-NODBG-CA72 built in 318 seconds, = ncpu: 16, make -j16 WDK23: Kernel(s) GENERIC-NODBG-CA72 built in 597 seconds, = ncpu: 8, make -j8 WDK23 optimized: Kernel(s) GENERIC-NODBG-CA78C built in 422 seconds, = ncpu: 8, make -j8 Nice decreases in time used for the WDK23. =3D=3D=3D Mark Millard marklmi at yahoo.com