From nobody Sun Apr 23 03:50:37 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 4Q3vSD6tPjz46l2y for ; Sun, 23 Apr 2023 03:50:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (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 4Q3vSD0dqZz3rH2 for ; Sun, 23 Apr 2023 03:50:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=HcD0hpMR; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.147 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=1682221849; bh=tKSJFnXk3Io/6ECvSR2kHwRN3gwkd9zr48FTSXWubb0=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=HcD0hpMRjwx+6hOpbwJI4SJ3lKea1TvEmdVkxazAn/1OlXRWBJnylLvSPKp0mqWQIKWRWE3Yz1owbgq+b4egglblk8+vi1g/fCh+d0wsf1xfvz7eAyfMH+UlGvKSETRRMCW1GmctS6rJoR67A8W/9XrN3FUueaFmudJiS+OnUipAb68HgVJLYlnRsgenWN5rW0buEtirL02Il+khVuWh1CzEkBs+5+ykerkhUu+8CBEd0tZM+i5nbIPKtUgzFiYp19uEoreSe4R6MDukhAaKqOf7xD44sUss2GYh+drWqd5ooePo9QL8sMZJPoFmo4izS2+i2xmoxs9nw4XnBEvFnA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1682221849; bh=ncFysWYcjbInP+4Lm+x1cRtbiVIVWINH2LP36Ta2TKb=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=fHBLNIefUQZIosqjt+6F4GxMS9LKd4mRPUwRA1fnbqXhNgkQAq0VEIavBl6zfPLTzSDBBf2lzCZJvxHAi7rVmpxz4HLRVGO741StJTaDY2ZrhFobWWzxZIFl2YBN5Ks8sEmPwh0Ph5gHeDpGF8iYZlpcSRaA9QUu6pTlFntsb987wou/iqTz94wX/Bms/XXXK08eDTvMHiqhT2iCoBTjJMegy0fqfl9Qq36N3ZptFfYgjZG1X+RdzUmQfA7vKnMRSQmEuYT7ShHWzf5NLv2uBAOXJ5AgR80mrMV73JtD1v43Rj/EQzGuzAewyqAX6o/vp9k7svpY779Z8qToPtQsCw== X-YMail-OSG: G.mHoR8VM1lc_i0CbtXJqUuyhOGl5x.whwx3kyM7vC9ymrICe8OY4VNDY2nTskG l8iEcriIUpegZ37MvgVqIwVzaSYuhOvwTyp0tu3YPtL_UFJ4h9orECE.15gjVyyLd3dCvPbCSjZN dyLHGmnhPuylaoEgqIjbmVDb2mcMhSjkazPIAaDv6OZy8lgQ7Dy8Isi0znO015j0O6ly3_p6Dn79 cYfJFCQAZ7gJHt5Lmm3v9Sow4Xc7idKJYbyd3AcOgSdIlclCymm21J7p3iOPET6fc38jIbrkhUf9 FJnlTybhXPIum3K.2inM5T2Vkub8Tt60fRLoM4F1fjmZdWa7ylN.EHV_S0fjtoXA_v88WJhV1G3D HPr_poRX2mJpHZi_.ukm8wtivDFUwu7rEXY0bvC43cXCDZlg6ZlzN5WCP1KA5LIpvV1pMufmQq6b FRnKO1LhYYW4AJNutujip31J70IXPuX99H4XJjXfUQXhlh9pkhHXbM.VoMyZRBDab_b.OXQNM4Gf IX7jdvpcyHNdZAZd4728oMUcskpeItwUdtjMUOmWDF1QTZbRiV6fR3ay5_Pomo9PZJk1eFOt0qqG NOOgvij68FV1x0zGZApS4CeBvpzt_gm_k8X1flFWDY_ilzZ58BmmDHxeJs_5zFkQhxFqdwRGN68J TS974irtCegU3.EbwdPEEEGtcLK_eYCPBEV7PQJVX.w9W7fkXyQRfBmB3i98PZmB17EYTOiJlY9c .BgoKENPfD1yI0bLN3mWu5Soe8IgrNHJ1TD1ZqArRiU3YMzSyDusAuFyBfoebtFM5uUiO.rW4na1 SdYnAkQJjpUC30XO2liC853VWnI.41zeJNwnEga4x.JhmlnHusRexnaqD1X_eRLk4H9KBKh8Y71E IQNSDkS4pzz5whR1A699dxBRV6xMXVQIp4FfvHhjn8ncghCzD2qGOEzyl.ic6BT4hVizqQenclgO XoX.Rtael0rlhF6xM3ioChtha3WgmkilCkNYQHZVkYkon3z6LHH9kvjeAyE5fqZlbzpvYUuF_yvi PIfsXyUpqt0NwtkWGxjhiCSsayLK19bZ3gNIkkovIq66YIGg7FTzWLj2LDr.ijGA2Tqpwg3gLzWS 7TcADSiSoyzxwLk3NEDdY8I0GsPRhP3QS88NIv6yn55axlna5M1P.4CfdRtROUQLqdlAgogeGJ3J fQatyCYl2Y4yRk5cykoUFNcZoXMrI3bLTBLUZSXDo0X9EIsFKSdxXy33gsdRjkF0KotflIoc0Gsu 8iAqHRO1HtCvjCCUOTkAzY2iE_uWJkhwx_mW4lvalWS0hJmtwTBms_qJ8KrLHkithWe8gPrXt5MK hQ2U3.DSa1_fL2MK7INwLptywzFHUFomMuBbG7F0mQId.CiJ.ZvVM7F4SiNjOLBN.stmeJAsOmk3 GHQpfpbPS9b7fQb.EWXATox.Oms_EpTEgBGan7zU9b9394lAdtuIB7p.V6Cj3gbiM5mPKAakTPVT Ga5WwKO_OkcoLebWgB3vWDtMv3I635AfUkj.YFBVidWFw9tKEBH1tMXVBi1mlPnK8nn78pKvxmuW 24Kr.dFuStx6CDTm_Z09YouRmzavx1zwDFbBy_rdeYcm9j320WHO0cpGd1066Yp_jW0WA2jQoxKl Ue_XJvCF_9ux8Tp8hD0lOnv8lHFslfyGGgDJOqUyvilUlwdtIMX0zTSujMBsr3GNADJqFJq8ZTbO FAy6Z2c7J4Mggb20f7JwF9FlDPVEI.oFzWTNzfpSHWwuT3q.YjkaOLXMCYEJWkIq7yn5bDoq2pfF cyvKwk6TKZROfeJmZWyxcYRBDaLh6xBXVArim64pVqzbRv5naffHg5PlO0l1cyLWVXEB_bY8AWTK dZAMbQZIjnSVPk4GJAFzi.uiH.L8ByaxqJkeEzVPfWRq1ukuiJhPQbZHTpeEZDPWcJ2OU2vqq6HO T4kpZptLPG5zhm1ttGi8EcdQ0tKDxo1yWbcGC08lc.U4YkorxftVEICLNk7_CxzE18QdEEAMiySA u.jJhCll3aRBOWNJUIxkT6SIPfkQspJpAWU5XnGBsqpp_nX_rotsMz3GeDVMmyGNNgcZn98idcRV gs.1EvVy9d.Gr2Z64PSFGVyrUlatThGIyzyjbDxUFQg.PAjXbpDZofcia6BVDjpVVhkHCjehxceI roCuaD.vZ7K192pL2EfuI178Si8veIhGj18o8ExvqwJKtBAJhGaabS.g6sYZkXegMS8Jl3k7O0fS ULaS_2JpT4s2JLGVm2FvGWA6JMylfqMXBKf4kEikUr4cxXNWhU52riB2ztFLpYhA- X-Sonic-MF: X-Sonic-ID: aedf1085-2312-4ceb-99eb-2f710957a5e7 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sun, 23 Apr 2023 03:50:49 +0000 Received: by hermes--production-gq1-546798879c-l2qgj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 69486c39a6526efd5cddead32a773b39; Sun, 23 Apr 2023 03:50:48 +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: Windows Dev Kit 2023 usage notes for main [so: 14], including about oddities Message-Id: Date: Sat, 22 Apr 2023 20:50:37 -0700 To: freebsd-arm X-Mailer: Apple Mail (2.3731.400.51.1.1) References: X-Spamd-Result: default: False [-3.48 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.980]; 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.66.147: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: 4Q3vSD0dqZz3rH2 X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Up front odd requirement just for the USB-C ports: 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. 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. 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. I've submitted: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271012 about the USB-C non-detection issue. I'll note that: https://learn.microsoft.com/en-us/windows/arm/dev-kit/ reports: 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 (It is unclear if that is a Windows specific issue, UEFI issue, both, or even more general.) My notes below will ignore that I had steps that were discovery of the issues above: a simplified history. These notes are based on leaving Windows 11 Pro in place on the internal storage media: So just USB storage media for FreeBSD. First time Powered On: I used the buttons to boot into UEFI and set the secure keys to none, disabling secure boot. 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. An FYI about the UI in UEFI is that, despite lack of visual feedback during a drag, one can: 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. 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. 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. The UEFI has no command shell access presented. After setting up UEFI as I wanted, I made sure that /boot/loader.conf on the USB boot media contained: # # To allow the Cortex-A78C/Cortex-X1C based # Windows Dev Kit 2023 to boot: hw.pac.enable=3D0 (I'd read other material indicating the need. I've never seen what happens without it.) I next rebooted with the FreeBSD media plugged in. (Windows 11 Pro never having a boot even started yet.) 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). 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. 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. A mix of differences for (a line with alternate synonyms from differing places referencing the feature sets): FeatureFlagM/AArch64::AEK_FLAGM/FLAGM/ARMv8.4-CondM/FEAT_FlagM and: FeatureFP16FML/AArch64::AEK_FP16FML/?gcc?/ARMv8.2-FHM/FEAT_FHM clang and gcc13 are not in full agreement about those. But I've not done any tuning variation experiments. The boot shows ACPI related errors/warnings: 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) ACPI Warning: \_SB.GPU._CLS: Return Package is too small - found 1 = element, expected 3 (20221020/nsprepkg-511) can't fetch resource for \_SB|.ADC1 - AE_AML_INVALID_RESOURCE_TYPE 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: acpi_tz0: error fetching current temperature -- AE_NOT_FOUND . . . acpi_tz31: error fetching current temperature -- AE_NOT_FOUND Just FYI: A problem that I've noticed is (e.g.): # date Wed Dec 31 16:50:41 PST 1969 despite /etc/rc.conf having: ntpd_enable=3D"YES" ntpd_sync_on_start=3D"YES" 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. I was unable to replicate the report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D270805 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. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D270935 (not mine) is about (shown in truss output form): # truss efivar . . . openat(AT_FDCWD,"/dev/efi",O_RDWR,00) =3D 3 (0x3) ioctl(3,EFIIOC_VAR_NEXT,0x2b0510b84740) ERR#78 'Function not = implemented' . . . # 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' Performance examples for buildworld buildkernel (the way I normally build such, not defaults): 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: HoneyComb: World built in 3463 seconds, ncpu: 16, make -j16 WDK23: World built in 6601 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 Note for both contexts: 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. =3D=3D=3D Mark Millard marklmi at yahoo.com