From nobody Sat Apr 22 20:56:56 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 4Q3kGn5G6Dz46HtR for ; Sat, 22 Apr 2023 20:57:05 +0000 (UTC) (envelope-from SRS0=/qSc=AN=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (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 4Q3kGm5WXvz3lRn; Sat, 22 Apr 2023 20:57:04 +0000 (UTC) (envelope-from SRS0=/qSc=AN=klop.ws=ronald-lists@realworks.nl) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=sz8T1UQh; spf=pass (mx1.freebsd.org: domain of "SRS0=/qSc=AN=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=/qSc=AN=klop.ws=ronald-lists@realworks.nl"; dmarc=pass (policy=quarantine) header.from=klop.ws Date: Sat, 22 Apr 2023 22:56:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1682197016; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to; bh=VhnEQeEJQG+kVVs6556xEJ2Iwy9dzonx4MlMat3PwU4=; b=sz8T1UQhDymAqnyIJP/w3MYZt0HanweVpXtdaMyYNjA1jo/2wClNlJmlrI96w7P5ngiCjH rzeI7i+12jVP8uDTu1MizAXL+hqrAkf0+8+cBtAsZsgD4tYlOj2CXFDPBZMvLkwYFhrr7n VsaD5bs+S7A9kZQ27x060bCy97MxrW4IwA+8cQzhhVd9pk432SPk4s6ECG6YqjAybfg/PF pDhJLNZiV2oZY1VlytGGKTemq3fcnB4dE9BQc6aZCvRPz92L64fY2l2fogi4/JX8U2RvB4 GTnZbZHiNCx6831O6u2CCq6+eM2IaNgorof+mzNuKU28OELZnEhLJlYpa5oClQ== From: Ronald Klop To: Ronald Klop , Stefan Parvu , freebsd-arm Message-ID: <637984360.34613.1682197016771@localhost> In-Reply-To: <75CC4130-F3E1-4B01-BA90-1C3030AEBA76@kronometrix.org> Subject: Re: RBPI3/4 onboard Wifi status 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: multipart/alternative; boundary="----=_Part_34612_196881058.1682197016766" X-Mailer: Realworks (652.99) Importance: Normal X-Priority: 3 (Normal) X-Spamd-Result: default: False [-3.19 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.994]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=/qSc=AN=klop.ws=ronald-lists@realworks.nl]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_ZERO(0.00)[0]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; FROM_HAS_DN(0.00)[]; HAS_X_PRIO_THREE(0.00)[3]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=/qSc=AN=klop.ws=ronald-lists@realworks.nl] X-Rspamd-Queue-Id: 4Q3kGm5WXvz3lRn X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N ------=_Part_34612_196881058.1682197016766 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Van: Stefan Parvu Datum: 6 april 2023 15:55 Aan: Ronald Klop CC: freebsd-arm Onderwerp: Re: RBPI3/4 onboard Wifi status >=20 >=20 > Im testing RBPI 3/4 capturing data from some sensors using MODBUS=20 > running FreeBSD and default Raspberry PI OS (Debian).=20 > >=20 > > Didn't read any news on this for a long time. So I think nobody is work= ing on RBPI WiFi. Sorry. >=20 > Its too bad we dont have support for on-board wifi. >=20 > Bjoern, if Im not wrong started the work on this part. Havent heard anyth= ing. >=20 > FreeBSD seems more stable for my tests than Debian/Raspberry PI OS. I hav= e several > crashes from Debian using Wifi. No crashes from FreeBSD but using wired c= onnection. >=20 > Really appreciated if anyone else can share any light on this. >=20 > Cheers, > Stefan >=20 >=20 >=20 >=20 I=E2=80=99m wondering if the Linux kpi Wifi driver framework can help here.= =20 Regards, Ronald ------=_Part_34612_196881058.1682197016766 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Van: Stefan Parvu &= lt;sparvu@kronometrix.org>
Datum: 6 april 2023 15:55=
Aan: Ronald Klop <ronald@FreeBSD.org>
CC: freebsd-arm <freebsd-arm@freebsd.org>
Onderw= erp: Re: RBPI3/4 onboard Wifi status

Im testing RBPI 3/4 capturing data from some sensors u= sing MODBUS
running FreeBSD and default Raspberry PI OS (Debian).
>
> Didn't read any news on this for a long time. So I think nobody is wor= king on RBPI WiFi. Sorry.

Its too bad we dont have support for on-board wifi.

Bjoern, if Im not wrong started the work on this part. Havent heard anythin= g.

FreeBSD seems more stable for my tests than Debian/Raspberry PI OS. I have = several
crashes from Debian using Wifi. No crashes from FreeBSD but using wired con= nection.

Really appreciated if anyone else can share any light on this.

Cheers,
Stefan


I=E2=80=99m wondering if the Linux kpi Wifi driver fra= mework can help here. 

Regards,
Ronald
------=_Part_34612_196881058.1682197016766-- 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 From nobody Sun Apr 23 21:00:22 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 4Q4LJ66Pktz46Shv for ; Sun, 23 Apr 2023 21:00:22 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q4LJ64XRxz3Hcm for ; Sun, 23 Apr 2023 21:00:22 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682283622; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=7Jx50gIWXqkUB7wtzYOrzxT4mF++j27ULJ3003MdRTk=; b=ySXLGHmGNYyyUNYLlMvpanWWM5Ei+FFZ5rBFK/svgs0W62Qsr3/Z0gVyup6zFb8bKgDsfb nq6M0iEYlDJcooz+t8CpJE1Fw36ZponZaLDMyPF+0mGcB9G6VKQ0CEDUMGd8S8c/At5xuB jemEra+BXNcVFBSazED084cjc19xIEV/zH9vTKzXyYL6eVg5tr0GfRTMbWKQMXK/E50tOP gNnFPrUExHK7O00OGkbA8Myslj9u6nVAEbn9MyUjZxBxzx68g4Wnnv/wJsPu1giQ2YfcSx VTEvEYRElYtH+OR6gWqxJlAtTKB5V2xRAtkZIXfDkY0puIQ3vsU9q6aDeBOKLw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1682283622; a=rsa-sha256; cv=none; b=txWEb8iSuE0mb2lYJBUq83QsF4sHEGiEczEkUkmsxZlPNe0LOI+Ij+8xTZ0OEpILA/tAGy +AYjDuPJC6eEg7QT+djHfxTLZ4ff3F5R/lU5FANaqCtaT/Pi6rZ4ZP0IBCj/k26sXoRvsF 9myA2RMm2z6GtivWNrSfVcYQOGVH0sel0bvvAxVT1YztRRVpwmV5v2oihB6iTB0lXusNNJ Gyx3LKkp/4d07RpOS7z64TCdMinoI4VFHfYVelt6//EuBAXtD6RWcSkbU9+Ct4snziPpg3 RYlezhv2sXLqdTbOu/9q2w8DGhYeA3XRdOuQKdtaAswuIyJk35uVQPUHTTCxXQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Q4LJ63VRfzyJb for ; Sun, 23 Apr 2023 21:00:22 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 33NL0MnS042910 for ; Sun, 23 Apr 2023 21:00:22 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 33NL0MVj042907 for freebsd-arm@FreeBSD.org; Sun, 23 Apr 2023 21:00:22 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202304232100.33NL0MVj042907@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: freebsd-arm@FreeBSD.org Subject: Problem reports for freebsd-arm@FreeBSD.org that need special attention Date: Sun, 23 Apr 2023 21:00:22 +0000 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: multipart/alternative; boundary="16822836221.FaA8De.40354" Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N --16822836221.FaA8De.40354 Date: Sun, 23 Apr 2023 21:00:22 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 238576 | Raspberry Pi 3B+ "shutdown -p" does not shut off Open | 257670 | mpr(4): SAS3008 PCI-Express Fusion-MPT SAS-3: Fat 2 problems total for which you should take action. --16822836221.FaA8De.40354 Date: Sun, 23 Apr 2023 21:00:22 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" 
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.

Status      |    Bug Id | Description
------------+-----------+---------------------------------------------------
Open        |    238576 | Raspberry Pi 3B+ "shutdown -p" does not shut off 
Open        |    257670 | mpr(4): SAS3008 PCI-Express Fusion-MPT SAS-3: Fat

2 problems total for which you should take action.
--16822836221.FaA8De.40354-- From nobody Mon Apr 24 14:43:36 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 4Q4nty1gTyz46vkX for ; Mon, 24 Apr 2023 14:43:38 +0000 (UTC) (envelope-from mhorne@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q4ntx6TbLz3pvv for ; Mon, 24 Apr 2023 14:43:37 +0000 (UTC) (envelope-from mhorne@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682347417; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/sFI2/117sGbbj1elBynR6pWTvelPcwywRduBG5LpJ4=; b=Oa15CRQFk2kPaFNuC6fx/DY8gWpuZwIRUuta/G/mW9abxF+wwSr/RkpaksI31jWGOro08y URWW8SrEONz53u18MnZr6kwdQUgfTgUcG5PFzSIdjSA4M0COXR6xcAymqUnM9M9FUwC44R Zxxsf+SFsnFwzcievOBtiC+5sx0dbfyjfckTQrgctUYRuiJVI6WDSDM3DbRMGJp/B3HBZu e9uHdiAakzeeJDo92BjDdH+jRtxq4KsX/OrIqA0nQtkEO9RQbGfIbIlaMiuN0iETHBGJJF caU5+7x/h70hdT8FgR9CuDIF+dK/663S45dYbO+EYnSqTSaxqNCIXDmFBYQQhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682347417; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/sFI2/117sGbbj1elBynR6pWTvelPcwywRduBG5LpJ4=; b=S4xKlGbjLNNNX6aIQwFdRrm8vXbWRaDqVgqJq+sLYKv4jf1OH3uf3GXzzdehHL39K51zip b/JqwY6QcwvDgZU4JJrrCrDTBC951f19ro4F9IkuTJpEH8GWYp7Xu4dQPYU6AAOaK/43BG XHhPB9MlZzYJSwv3iKHGv2+G0Bm+Bw/zRKuvyu0TpE8T1Ukez1H17FhW+ZnThATjCq2GAg fvuR3hOJimZoZqo8NNdKRE91gfgG00xlZvqWG0hsmZ0AUU/b4tFtB8hfeOHmY3k9qaUh6R okyJ6JMV4v9Fd2dfxd9eyAWT+CsmBkuHbdsVgS8L1qNIycoCAI5YAoBiwXLOjw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1682347417; a=rsa-sha256; cv=none; b=Ps+HpBXVArEuE3jQYg+/CVFaDVVPUHYYM0u2OuCb7KtiQHK5CgHfolJJkFlT76ezIxhwIE AbnuTke9gydRMVkJHh5PD0N7CE21P1+e71KRlv3l0f+mTQfi2VLFl+TNcoZRvId5wYx5qU x5ecQEtvun17MMd9Hnt/3/is2YAQUHuP7SMkEXTtqxg0mjHwxj4UXTqUW6gIe81dVZgDmE 7zaG4NXHbqhylc+jfCfl5N24VsqyjdVOqqW8KieX5/TG9RRohddaOM8qSNV0KtrUCEnQyD XGIEUBrGesSRs+ty2jblFDlkJ53Q5/G6+qr0pxBcux1TOx+SMG7WvRljqJCEZw== Received: from [192.168.1.151] (host-173-212-76-127.public.eastlink.ca [173.212.76.127]) (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) (Authenticated sender: mhorne) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Q4ntx4hKZzfB7 for ; Mon, 24 Apr 2023 14:43:37 +0000 (UTC) (envelope-from mhorne@freebsd.org) Message-ID: <08ff62fd-89db-d429-9ef3-04f213118f83@freebsd.org> Date: Mon, 24 Apr 2023 11:43:36 -0300 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 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: About PHYS_TO_DMAP To: freebsd-arm@freebsd.org References: <86ildyucuv.fsf@peasant.tower.home> <86zg78s2bj.fsf@peasant.tower.home> Content-Language: en-CA From: Mitchell Horne In-Reply-To: <86zg78s2bj.fsf@peasant.tower.home> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N On 4/16/23 04:06, Dmitry Salychev wrote: > > Mitchell Horne writes: > >> On 4/14/23 04:31, Dmitry Salychev wrote: >>> Hi, >>> I'm struggling to understand which KVA will be returned by >>> PHYS_TO_DMAP >>> on arm64. For example, if I'll create a DMA tag this way: >>> bus_dma_tag_create( >>> bus_get_dma_tag(dev), >>> sc->buf_align, 0, /* alignment, boundary */ >>> DMAP_MAX_PHYSADDR, /* low restricted addr */ >>> DMAP_MIN_PHYSADDR, /* high restricted addr */ >> >> I think you are confused about the purpose of lowaddr and >> highaddr. They specify the window of bus-space addresses that are >> *inaccessible* *to the device* for DMA. It does not prevent you from >> providing a buffer backed by physical memory within this range, but in >> this case bounce pages will be used as an intermediate to perform the >> DMA transaction. >> >> Most commonly, if the device can only address a 32-bit range, then the >> values lowaddr=BUS_SPACE_MAXADDR_32BIT and highaddr=BUS_SPACE_MAXADDR >> will be given. If the entire bus range is accessible to the device for >> DMA, a zero-sized window will be given: lowaddr=BUS_SPACE_MAXADDR, >> highaddr=BUS_SPACE_MAXADDR. >> >> This is all described in adequate detail in busdma(9), but it is still >> not easily understood without a lot of code study, in my experience. >> > > According to busdma(9), the window contains all addresses *greater than* > lowaddr and *less than or equal to* highaddr, i.e. your example with the > 32-bit range looks like: > > > allowed prohibited > ------------------------------(xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> > lowaddr highaddr > BUS_SPACE_MAXADDR_32BIT BUS_SPACE_MAXADDR > > But my example looks a bit different: > > prohibited allowed prohibited > xxxxxxxxxxxxxxxx]----------------------------(xxxxxxxxxxxxxxxxxxx> > highaddr lowaddr > DMAP_MIN_PHYSADDR DMAP_MAX_PHYSADDR > Okay I see, you are using MAX as lowaddr and MIN as highaddr. I read it backwards the first time. However, I looked at the code and I'm not sure that it will handle the case where lowaddr > highaddr correctly. Just a warning to you. > I've found the only example of such DMA tag configuration in > src/sys/dev/vnic/nicvf_queues.c at line 379 (rbdr_buff_dmat). > I think this example is misleading, if not incorrect. All DMA transactions for this tag will have a destination (physical memory address) that falls within the [DMAP_MIN_PHYSADDR,DMAP_MAX_PHYSADDR] range. So, the specified boundaries are not meaningful, and don't represent a real constraint of the device. At least, this is my understanding of it. > >>> NULL, NULL, /* filter, filterarg */ >>> BUF_SIZE, 1, /* maxsize, nsegments */ >>> BUF_SIZE, 0, /* maxsegsize, flags */ >>> NULL, NULL, /* lockfunc, lockarg */ >>> &dmat); >>> in order to restrict any physical addresses but a window defined by >>> DMAP_MIN_PHYSADDR and DMAP_MAX_PHYSADDR. Later on when I'll be >>> mapping my mbuf (BUF_SIZE) with >>> bus_dmamap_load_mbuf_sg(dmat, dmap, >>> m, &segs, &nsegs, BUS_DMA_NOWAIT); >>> I expect that >>> m->m_data == PHYS_TO_DMAP(segs[0].ds_addr) >> >> Why do you expect or need this to be the case? >> >> busdma is not responsible for setting or modifying m_data, it comes >> from wherever you allocated the mbuf. Calling >> bus_dmamap_load_mbuf_sg() will prepare a DMA mapping where the m_data >> buffer is used as the source/destination for the DMA transaction, but >> busdma does not allocate the buffer itself. >> > > I don't need this to be the case exactly, but I'd like to be able to > access a "frame annotation" (64 bytes long) which is located exactly at > the start of m_data buffer having that physical address is provided, i.e. > > fa = (struct dpaa2_fa *) mbuf->m_data; > /* ... fa populated ... */ > /* ... DMA transaction of the Tx frame (together with fa) ... */ > > /* ... Tx confirmation from HW (bus address of the frame only) ...*/ > fa = (struct dpaa2_fa *) PHYS_TO_DMAP(paddr); > The short answer is that you are using PHYS_TO_DMAP correctly. Every real paddr should have a corresponding VA in the DMAP that is valid for read/write access to that memory. However, it is unusual to see DMAP usage in driver code. It is hard for me to say exactly what you should be doing without more information. In general, the m_data pointer remains valid after the DMA transaction. If your updated frame annotation is located at the beginning of this buffer, then you want to use the same m_data pointer to access it. I guess the challenge is that the TX confirmation occurs in a separate context (interrupt handler?) where the mbuf reference is lost? I believe the usual practice is to maintain some kind of ring or queue of transmitted mbuf+dma_map_t pairs, which can be handled together in the TX interrupt handler (unload DMA map, free and/or reassign mbuf). Of course, you must use appropriate sync calls before accessing the buffer again on the host, probably: bus_dmamap_sync(tag, map, BUS_DMASYNC_POSTREAD | BUS_DMASYNC_POSTWRITE). I'm sure you know this. >>> but it isn't true. Could somebody explain what exactly is returned >>> by >>> PHYS_TO_DMAP in this case and whether it's possible to translate >>> physical address to KVA as fast as possible (O(1) ideally). >>> >> >> PHYS_TO_DMAP is always a linear calculation of: physaddr + DMAP_MIN_ADDRESS. >> >> I do not think PHYS_TO_DMAP is in use at all in this example, or >> anywhere within busdma really. >> > > Is there any other way to obtain KVA of a buffer mapped for DMA > transaction by the physical address? I've been crawling source code for > sometime already, but DMAP is the only thing I managed to find. > >>> Regards, >>> Dmitry >>> -- >>> Open source software/hardware enthusiast >>> hackaday.io/dsl | github.com/mcusim | patreon.com/salychev >>> > > Regards, > Dmitry From nobody Mon Apr 24 15:00:01 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 4Q4pFt3Ft8z46wpY for ; Mon, 24 Apr 2023 15:00:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q4pFs5H3qz3rW1 for ; Mon, 24 Apr 2023 15:00:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682348401; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SzdrIwtuL2nAcbS1J+YO4031PSdEvcT/nabuer82ssg=; b=Ah84qwI2ogbATQfbWUj1jf0wIR/xOe3vtln4uKHej3VeaCJw3loRLGCFLslfnSavcdh2XF zgOaCvUcCU1PYFujFtWw3qM9AFAdO4ZcnG2jNV8eLJOwvuvKASviMKRapsTxqT3xR6n8aF qiMAXLzwveJem2MLj9xaspyVR+seJVlXGOHY/n8czygLU+ip7gperf/Qo61XZ2NIpr/A3R D0pMvKvRQnlwmMTI1zRH64TVndjqP/QW5lBBf5rVNMw6de93zXdDqdCe10ciwHoOzjCGjg Hluj6KQ4Q1CICVCKUa98y4wrF29vyPX0H/cQkTcbFJf4bbLnVED/4aazzsLZUA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1682348401; a=rsa-sha256; cv=none; b=KZeuHM4ZyxA93IxVofUYefdv1YiTst2VP3j1HxqD2yjlDLZr0QuQybc1SVavHmSo6dUNyh LXEtNGLfR/wsgb4/NtD01+/0KFhch9nhKSQVuV8RfWsLP6WkdmISjScclBOTArah3VypqY 8zP3oZGrJMnix98MSUX7vWrm9qmgJTXKdWFs9K3OOWrF56V9R/fohWfEveoiyXLstw62a+ fYJoYRcxtyZ56A438kBbQ+K9EKl9OKgaHrz7x4pv+SFogD965lo5abh5paextU/i8Xwd1O r12o6AhrzQvM/dzveVtmLDsKLwwE/IjvX6fby0k4QSTH7y53jwkligqu+d1/Aw== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Q4pFs4NxkzVLH for ; Mon, 24 Apr 2023 15:00:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 33OF01Z6095857 for ; Mon, 24 Apr 2023 15:00:01 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 33OF01gV095850 for freebsd-arm@FreeBSD.org; Mon, 24 Apr 2023 15:00:01 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 253574] buffers passed to efi readblocks needs to be block aligned on arm. Date: Mon, 24 Apr 2023 15:00:01 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 12.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: mhorne@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Works As Intended X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253574 Mitchell Horne changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mhorne@freebsd.org Resolution|--- |Works As Intended Status|New |Closed --- Comment #2 from Mitchell Horne --- Closing. It appears this was already fixed in -CURRENT at the time of the report. https://cgit.freebsd.org/src/commit/?id=3D3d5e12ebce94791aa0d6df3e81e7a8ac4= 8ee4b51 --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Wed Apr 26 11:18:33 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 4Q5xFQ085Yz47rN1 for ; Wed, 26 Apr 2023 11:18:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q5xFP4Mcpz3qC7 for ; Wed, 26 Apr 2023 11:18:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682507913; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=rebJW36cMVp21TfxjFY3o/2Lf6gvllARG7V69HI7oVQ=; b=Y844t77mc2Tyg7s0E987CzkhNedraA6Dic0WbA7V8mK9SIFcsyOS92BHwwd2ADmAqxC35W BJnqiHYprE4U0WjAF0OUea/4SVcWJXtr7cT7//P1ZZc/YASMhfVtEPcTjFQYf8xvTsLuTI E0ohfdPzBBsLARcLlX/WMcGhCj1zDocAnmO6AFWm8gEGUpfpG/euvQJo9XdCScmGVSMly3 LfFHyM2pqkMWCBZ4OMIg5JfsmZmFJAUn+3Z4ayoVUQhSp2kZQMtd++lyGu8rRHhHDbF20Z H4Jv6t9xXDb5Jw9KAl6xwBKeug5y2x0g3xz2vKQK3t1aZzTPLI37NhkbVhqghQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1682507913; a=rsa-sha256; cv=none; b=nD8gV4q8hzT4zvrQfwoiEMCIbKvUlOB5eXWNLhwctZcq94U+/tzz2vRcow7Akmup/oIe0E nIBdO7KulSM7BEDPvDszMWCtPO5DXWbi+zgtSADpHLVlTWkQj9DU0hvbI+vh8fFZxFf3mg 5qoykYM9xWgHS78Fg3GdsJvR2QdmdAidvIy1Mxr102gTDuiZklx8k/0IzShThyRkcevJtn o4ID5PeroarFy2KjfsgmoIUS3Ea+1GXPnJjNS/BHSDYThlWYKC9gCfvI1yz6m35iiOnqCp 3Sl9sW9lkBQ4wRMcqkyTfgfhSR5mGL9hiaIZEMhinI9CiJkRzbYWZodfv+1sIw== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Q5xFP3SDlzXLp for ; Wed, 26 Apr 2023 11:18:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 33QBIXge057905 for ; Wed, 26 Apr 2023 11:18:33 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 33QBIXtU057904 for freebsd-arm@FreeBSD.org; Wed, 26 Apr 2023 11:18:33 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 271078] [nanobsd] embedded/common script does not copy FAT slice recursively Date: Wed, 26 Apr 2023 11:18:33 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 13.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: hondareyte.luc@laposte.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271078 Bug ID: 271078 Summary: [nanobsd] embedded/common script does not copy FAT slice recursively Product: Base System Version: 13.2-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: hondareyte.luc@laposte.net Hello Since ubldr support is removed for armv7, I try to build a nanbsd image usi= ng EFI. So I add the following function to add bootarm.efi on the FAT slice: cust_efi_loader() { NANO_EFI_DIR=3D${NANO_FAT_DIR}/EFI mkdir -p ${NANO_EFI_DIR}/BOOT ${NANO_EFI_DIR}/FREEBSD LOADER_ENV=3D${NANO_EFI_DIR}/FREEBSD/loader.env echo "rootdev=3Ddisk0${NANO_SLICE_ROOT}:" >> ${LOADER_ENV} cp ${NANO_WORLDDIR}/boot/loader_lua.efi \ ${NANO_EFI_DIR}/BOOT/bootarm.efi } customize_cmd cust_efi_loader But EFI/* subdirs are not copied on the final slice. With this simple patch, it works. --- common.ori 2023-04-26 13:05:49.229317000 +0200 +++ common 2023-04-26 13:06:01.783766000 +0200 @@ -217,7 +217,7 @@ if [ -d ${NANO_FAT_DIR} ]; then # Need to copy files from ${NANO_FATDIR} with mtool= s, or use # makefs -t msdos once that's supported - mcopy -i ${NANO_LOG}/_.${NANO_SLICE_FAT} ${NANO_FAT_DIR}/* :: + mcopy -si ${NANO_LOG}/_.${NANO_SLICE_FAT} ${NANO_FAT_DIR}/* :: fi fi Note that the patch in PR255639 need to be applied. Regards, Luc --=20 You are receiving this mail because: You are the assignee for the bug.= 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 From nobody Wed Apr 26 20:45:03 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 4Q69qT3xqvz47HTg for ; Wed, 26 Apr 2023 20:45:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-20.consmr.mail.gq1.yahoo.com (sonic317-20.consmr.mail.gq1.yahoo.com [98.137.66.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 4Q69qM6x7pz4Pk9 for ; Wed, 26 Apr 2023 20:45:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=RaCjDoxo; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.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=1682541918; bh=li7+K5/Olm/YSkC9Ide4kMRGEGNmVP7MG0Jr8sIAiXY=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=RaCjDoxoVBlaQvvJZcarWAjlUkdJTzN/zOANJo/HXapd1IW2KN4dXBG+rY2kG5mreEvmlpHdDknMuba/+wKdcEtZdBPZjxypPU8pBc4uJutXHqfWap4evQOXF/3zMu8T1U62VIj3r6XwtZPZBHCJEOCoJZv02YGvPMfZP8f0LMlnZCsxGiz+ZOipQv8+i2GClr/83x7LcJJEaUtF05iVnJI9QmKU6FwRklDQNBQkSrT0/8eyMieT640lrQGM6JZWYeSr3kLuzFWBYhALwcXjvagZtXl/sCt75Bf5xB9lEP+wrjWCfTLizizk/vwPBlEPV2+EpCqAJxofw7pgnDgT6w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1682541918; bh=clhm7C4aXAI4j0L7B+NaZsi1RDj2O9EZKBlRMrlqfrm=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=sb+OF5NNMPci5cvPbDrmPD/sEx7EmXlonrCm5aTqNe7jxUf5YOj1tcdd7FlZxReSdzPmClIq8YgyiSosRFTjV7IkSMUYtOVdkV+Pkgp8mr0VcHlOVggvmdK7QJMf/j0wLtcHf2kALYZdguGyD+h5zVpmPGXQPKqyqiJK6q1zUB8FPDkIrB7j3tj4y8Vp+CgrBpvn27ve1b99sCU920l7AUkdi3ti+/Anoc531KqojGtlzDEExZyIIRdNo6mLaXS73AWOkVRx9X/r8xwpbFM1PME+tUXxagRUd04njZ0T3h9fPtqYOxzuy9C0F4wSPeNA1OBY+lWfIAvoz2hMIN6pcg== X-YMail-OSG: dUV4m0sVM1nCNSGi_PXlk6SUzX0_hs4zLDKfrq.WTZSNHcGJ_QZnRMA0RFZtf3s Djr2xJXf.aVJ53lzItf2Qjo3LokecNtLTJjS.C.PlCCqhp3WMdpnUaep16BkAByKF.Ulic1ROw.k 9GwkoVk0TozDtRFdza_kxaG4HmeNVceUu2zE8Use4WZp88x9Q3k6y8cK78g7bmc7CEddHnmJ86HF TAAPv6BXnNJuiKVeuK9qaU4Cgv7xNNU3sQIJ7zI30IOWwEn700zphBlDw.uyGpGAc2yp39HDtmYu 5FevksQbLTbUofs4FKCZ6wuPm0hMcrH68UFhyTVNaSGk1RZ2v.h6otC.Dtfx04H9QA8pJ04SN7RE haQtACI0vOMMSWW_IsuVnEgZx0AvMTyybjaWWTxfdB7RHNcD6tEPU2D12atRab_fHIlmRdfcIMe9 gouw23Vha6LE43S3n3WRmIRUiwOBtvj.PGDseiE8WeXCEPGbIRtY0sUtz4Dm8d6RVEIgPEpv_fDy vmAIs93.nauxwm_LCn8WXuUvKdqZPalAfDDGLGiMk6bwmLAhkprvdSRiwExr.boQGHwLYgRCPLxG hhQVYFcmpXaIC5Y8Vwa8fV8Z2ZTVQ5quKE3.eCDctE.LiCgwmXmy7sLmpkb.V43j8rDfz2a.Ir7z cJQU2lrbS_af3kErai6ng8R3cQpbwMtS5fjtvM0Lb4MCyEtB6070n3yP7K7fiZgIFtueGz0idzrR hFFEWmy0as0l6sXAbhbrwwxpo71R9IjcMQv0pHzxrZa7ygh05zEeVuZjTjuo2rkdDCdRKDX0ZxW_ QB1dT_oQM04PQVnML8KPJBJgu_4TqUjCwI6TG.kMRhuOCsQR4CHZGwIf5zQMNqDey.0J0w5ocMGa TXtAZwWZOrb7Vr_zfXlvwtPlsjgZVwVOARVwD7s_PceAKPM0RWScgRjyrQytLJlFfo6AyOHxCzwz Aj_NIsRkjbozFY_qbYXudpnzkYI_mRTz9Ce5LvxmumlbnHCqLYYfU5vCo3g3lAszmzV9lCW.3dTj zJNXLNPKebxrHXsROOyBRipy8GTtfYAYTneupz3yd9r47D2pHvxKdj1wtxW9jzUJdNItPyzp1qlO RmJoSON67L_bk.y.rQNlNHeCHIOSsmwHxgnXOmJu8cTb59KWwxjQPPAUa2O0TM4BfTd0L_kE8ZoW NFf5KYWuJfj1tzSXw4npIVSJJvhcWQWV3K9LMNwFKMON0tqGOEqdkmN3QEz9OACHbVGOGsRgPJEF eKLSnmnjSxXuZFoQbAZIXK0yYDfonRuxAvi8dUzg1psF4iipBPPQ0Vnl8FbHbBxuxR2sNSEmp8uT 3eC1K6VO9x52SOHFL7n66lvcfucLf0ToqDLhC4vCkPSUZBC7p3hFiJPvcEGTgxWEoHBgerSkWVgf 7TX_iD53VbnsyTTxUdHgkG7WMzFAWDSoRHtbHg_KGmyGSx9dUoVYWuDnHIk2tWlf.wXPXxEp9DEq ce5NLEjzpVYeagDJP.2eQ9tmfoQeZdh880R0mWGSWyvFVkJm02inGNewP0wa6zP8yyTrNLxsx7Pv dF.7kTX_yectwXJov3mHBktrR0KoFGxlTZZSGyO_DtSeQk.36EqrvCR7OvTfYwX4Xy.NgzSESTc0 dhumqByJWhhz6t_RhIgTS15mBtLU5noEa4KvrALPGJBApVHTKB.Oca_iY_Y6YKcPLMlveb5zJhoB TApOY2Smox_I41fuTdWHvxbdDpCW0bWRDD9edDJS0s_RG5OCWwmm0JcZbR8ICPbk_33J_5klg41h taY44QSXPFdpVOH7FYGXOMC8NP42745ppaa37KjHSAXSmqvbnEp42myWFIzPDEQPYoHH3GELbfUK BK.LnYC.SGkfl68M5q15hfjs31v0v13FcfC1dMx8OIM1FP75qXspTLVlp_QxIlFDPhCiYe2wxZoP TvLubm0OFe4RpQmxfa6GVQW6wcE1APYWCxa.o70PQ1Tqnf2gbjkvTrFtelS_uRxUTT_4qhMgsUwH Ha9eARixn19UEVYEwlYad9iRVM9pVYWlK7KAWo8nh3wgVNR0HIKuw53i857zRzn8ZwlUQG8XzYWy X_Ad02uT2zz0CQzjNhMgKmmii0iwpfIjMt6O4aAtg50NsGN2qgmA5m5tUfJMEKf56vJr.swdcSda 9WtyXr1nIhoML8HqrzTPBZ1AiJrCZppjuX6qnekI4ljwRRWiZXDI0oWOIEOlkOANWJ8A2N654Ijq O55S9Nzvlj6ZQjkHPOHMzcLMYK7p19jT5s7ep2Ad_dC.c3NeMGCx1CeCTUmNParw4ync6OoPL7gp YOhg- X-Sonic-MF: X-Sonic-ID: 56b1a212-86fc-46f4-a777-7e55c3992542 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Wed, 26 Apr 2023 20:45:18 +0000 Received: by hermes--production-bf1-5f9df5c5c4-v79q2 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b45bf486a2a996065fc5e5d3c32d3eb8; Wed, 26 Apr 2023 20:45:15 +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: I submitted https://github.com/llvm/llvm-project/issues/62383 (against main) for cortex-a78c and cortex-x1c Message-Id: <04C5E972-250B-4E71-94EA-01496FBAF194@yahoo.com> Date: Wed, 26 Apr 2023 13:45:03 -0700 To: freebsd-arm , FreeBSD Toolchain X-Mailer: Apple Mail (2.3731.400.51.1.1) References: <04C5E972-250B-4E71-94EA-01496FBAF194.ref@yahoo.com> X-Spamd-Result: default: False [-2.92 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.42)[-0.419]; 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)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; BLOCKLISTDE_FAIL(0.00)[98.137.66.146:query timed out]; 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.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:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-Rspamd-Queue-Id: 4Q69qM6x7pz4Pk9 X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N I have submitted: https://github.com/llvm/llvm-project/issues/62383 against LLVM main for cortex-a78c and cortex-x1c having 4 default features messed up for the likes of use of at least one of: -mcpu=3Dcoretex-a78c and: -mcpu=3Dcoretex-x1c (the core types in the Windows Dev Kit 2023). Things are somewhat different in LLVM15 and I'm not sure about the LLVM16 details but there are still problems. But as there were already some attempts at fixing cortex-x1c in main I did not bother with the LLVM15/LLVM16 contexts for the submittal. I'm hoping that, if/when fixes are made, backporting whatever is in place atthe time would probably be doable. One presentation of the details of the status in main for what I found in LLVM's main is: QUOTE 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. END QUOTE=20 The materials that the above is based on are: 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 = 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 .) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Apr 26 22:57:01 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 4Q6DlK57THz47gw3 for ; Wed, 26 Apr 2023 22:57:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q6DlK3MH7z3NLK for ; Wed, 26 Apr 2023 22:57:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682549821; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=IvXuMWoQfzmuYlROeWjUsOvL86M1+NicDkJodDxDEI4=; b=Ey2y34qv3cg1UW6VIPLCrETjWAQKYqw5whNPUYUMnJ4oykIXbwcM6s8G2qSA5eta10aW4k RV53yNGfMBMIRdK3eEUej2c8MphlIdYM8oBV398v75aR5LVWt12yDHKSICp7A1FCosuFpV Whuktx6PQfvK/vqBwUoiry0vbuPgN5UpRQfh/6bKw2mJVi/RELWR+r+r+jhdTFjHMv0hqG k2ELid/NWVDezbSAEsT2LK2pm6JcQwWdbtT4chmFn5ZNRocCilhETaIagKl3CHPp6DJPn+ t04Bhh/8eGIQBcexDWN6s3rxdjABYla3KKbF3wQd4xYQ2FYHYmyfwrxrr1BX7w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1682549821; a=rsa-sha256; cv=none; b=Yi5FwtEwN1WD/8CYQrH7Pc/HuZBRx0JvB1lO73++mRdxzarR8E8AqBP6X0supKi1E4iCY+ I6lXRKkI4l0RIcupHdsg4gavOoEPf1CU7yUPjBDJnvPWMvjb/L0usBmGRvZLiG1YRQXKAY bV78y79V8nuPYOBnpy+dI+/7/7tc9GUhBEVIsQ/a4zlanuOPiKl/9GIPRbqH73uRppVT4s Ta6qbK569ov2OSnfzRmDw9DExwvrc8lI/r6Hfv4ih6xfGTXo8uYjjH6gMpIq7DQYlR1Ki7 280ArqIxTsPyUs9hYpRinMvGHW2JQKxFOeS5jt1GG9FDVE8QrEvCLqVhAZxnEw== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Q6DlK2MP8zsP9 for ; Wed, 26 Apr 2023 22:57:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 33QMv1Vv046474 for ; Wed, 26 Apr 2023 22:57:01 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 33QMv1qS046472 for freebsd-arm@FreeBSD.org; Wed, 26 Apr 2023 22:57:01 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 259617] ARM support function __aeabi_d2uiz missing Date: Wed, 26 Apr 2023 22:57:01 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 13.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jrtc27@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: DUPLICATE X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: mfc-stable13? mfc-stable12? X-Bugzilla-Changed-Fields: resolution bug_status cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D259617 Jessica Clarke changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|Open |Closed CC| |jrtc27@freebsd.org --- Comment #3 from Jessica Clarke --- *** This bug has been marked as a duplicate of bug 271087 *** --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Thu Apr 27 00:15:25 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 4Q6GV72plBz47lZk for ; Thu, 27 Apr 2023 00:15:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (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 4Q6GV56Q8Mz3l6H for ; Thu, 27 Apr 2023 00:15:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=CDnRCuV5; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 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=1682554539; bh=KBY7QDlC+MOULO0pvKCEuXHpww8KiiqPEibA/tLf3PQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=CDnRCuV5pMF2BVeqEGffzaUYiuIhOrs3IBuaK+iCiPLT5bxx4yqyTKKggyHckWUY/9axLtDmaRYLTBc/wDoyyPNpyD83G4X9RBHLYZUn5vF6HIM05raFetivIAdS44w/di+nplT5w3yFPHCgSTjQ+OnZieahFVwc3TSUcQXkt0dpFohV+3pG520UHGd7fXC2ZDnuNuxR8Czln9yKNYuc/Ej/v6OZMaxYEbN/XhvVfITF/adzGxmExmsUdgo8Uetwre1gkht7gTt1JVI6pKwhW+TjFJShB1kibmCAtB58kmz+Mi3LslbfurzUo6ltd+NmWul0Pelv1GXkfXjzbQ9Mrg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1682554539; bh=F6eyRhWfuDbrQ/L9fwcPiHX3TVf3ReLGrzjNaxfPfVt=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=eDm9FoxfWqfdUz9DBrCBOUOv1kH9cw+HbqKK4evKS/3/4z5kUV0gQpdEdoEH4ud0YNat1gMJh4GmCe0woDLPgZc6xGDwpHd3rkn+3+juNc3fH+pEnktWpnwdjByZjb88hZO2/Mizge4T4bge3HSVIQWyVIQHg1lOcma/36sq3nSYukBo3kGOGpCVrC0QpDEY9ePzN/OLzOUP0rsKU+iR6o3eDrmRF3XsLMon7Vb8JK+PHrOTj0h90x3O2C/KLpqPeTkXtECmN5RGy27gCKhfhvz4e2MXmrhd4QXmrARpph+/tkm3MvurSArBFk2g7Y56RCGbqowKjJnWFEGfUQjTOg== X-YMail-OSG: lG2u7d0VM1mC_wlBsraJtWRbtw8SWnlp5o2TrMKGOZsqdB2lGttZoZWjcwXO47X z0GNoPQCD.BmLL18wDIjwgN9Nwqz83olqjilu.Lkc36H8gkkyH85u3AR73_cebCbue3YTxPo45td RAwYAFYstB6Hwdzrd_vvCWzagvH4HU6FW9iwJHvIANoPTuJ8releRvwVKME1S_ItIHlVTGLSdhty KHwewtbWE1VpHiMTTnZ30_jGu_R81VtXW9qo1b9Oe2KzhQXPqL34NCtIrMPUV5wD2rb7QtQBmXLg KR.UMMomHoPBbCtsKwa7yz3wf6s.Oxdni.kxo7Kw_nNilBkHsiPI7q_32qHtRLTVLVxYo9RbqTlz ixEwke5pmVIj3V98mKAaJCD0tE3vqinfUV80z9KyDflggb4ww.5OjQ35zH5e.33Fd4w1ZOtc45k2 sVpulxXN_wFy2jmNLz8vZsYv02EEbVjyE6vfRA8oLZmSOrlrs6Rmko.x5GkYczB52l2UUhwv9CRC pY.cock_CvxrIhE4qKDnywgLO0VqNXBvGNZ612GpsJFpEWodCShKBYS_QjvB5Tu5u2yK8lVEyJQ9 RJns4tF_Yu7.E2JQmHFXN_ZTglVlt4aD1FbzjwFeNL9f4Br5aPfl8MqPUqe5OHQzQRHjU2jMENP1 f6ZXdQZh7NilyOV7DsB_jyfNm2hbLjEfPIPz.Z1cVXWqVbAf06C1K9JxQBkUmMVOrbyPcT6u3O4L oya8pVEWdvyHoIax73ntHCMizEj8flCTSTHNnt.31Y...C7W5d1kzlRz.V42iEuh8W9wUUEj4ks3 sIDmEPYkSaQHuT1TjLTotiaZhMVHr23dlrMcHgHvN07QR.8bSqTOt5PTu13l6ftDZWhQh2AKbrD8 1Sbxe3pdSN1T5b.ZEuJydHuf9XT405Ell8KgvhAn6bFjlO0xKStAOSTkQFSbn8wLiEDby_EIlN8e B9Ip9t0jFBftGUHZKNPvT75mENhB2LF1JDFk8ZwbqqCMksvXXKCg0vro3zWMYbQZXGqj8A5oxyV4 rWhdtBy9ganloZCrGHUdzpTLvdF.bMsqhiv0YZOA66aMKuREZLWdAxhMXxUwccSQz7CGtCuRKZBY nmVVPje1CSZtbEF3mUaNwe8Dr6_PE1uzkxk0dRCtn453GygQG7_.Mdvple8Bwr3bj0Y..fSmHbJH LY1gWxdjD5K0vm5jmMU98qBiWlL9shDlwjhUNQaiCNQiozA9uWBD9Og4rgTfODY.qpz_Kh8nSGr9 c2qJQBEYRD7PwdMNszCNUxcc.ZvrB60mXRRYEW_5ZYjNXyuE8xP58r5LML5NS28DfFpzOmDvqSK5 hgPQUfsKcZPPsLp2nw4bD9L5p3Fu_DDzbwZv61qLSehC.WMq4103J29aZRxlv9qSajrod_mT8yjd j3R2dc_cbpzTw8U.5gQS.uT_cvIQKbJEKgw3_mj4EGVSxTICuOpbdkcLKnwOSFwDnlALdSvy82EN jz1tqBki55504MPWG2STUicSVw1o7of.A0lzzcVM87x0jBa9jeEt8CRmg538CQdmAc528JSxrLMY 15O5Te6gvkuUYYObnD0ndISm.krjd3ziYUOJYTL3GaEXMh1fpt5OEFCGJcvuaqrbkTZ3HJx11efZ DcGqG6J1ewUywMxikh2vzS74._OSwdkigCphbbyliFyCvRtGf9C4ay.X3aBCqQXf.kfnLD04zpQG 6Eea1KewV4nDB1T0F4hI2RcYlm38Obutsq3OK0.KtL.y4RiMTFf9k_IEBbcZLA3MR2sc0V4_xPnj XI9SFQaZIY0_oPply4JnDeas2RAw0CxZ9BbbcnHNGjOEtYa2b0O2t4or6tVIPyYFWC149sdK1V9n RfKcZRil1nWGDw1lCYoqa6K2knsIqlJCbFGvcfffeldnJ5nAPaBUg9_xjx8qEBxW0XoO7W8K1sqV f74vJIPT.FzrI_cM4ipEy8eiuvq1GaK08YyXuvrnPTWufEmKl5kuVcbbzM05o1Zrw0GV4bokyc0l XeWpCVHtxPmqGBDFoUe9_uS5o_B.2U6aZxMpQ4ofK64m_ZdMMO_oquWgRHR4bslUaVW5676dZs_U x12pBuBP6KMMEikWOtWO6HKoqlkt8zFSRJSSNAt5Ef6eE7IVbRNo9.jdm6rjj.FpNP.8IIvzlkET VnbWVetriXAzgkIo5P..pHpYHmYBvugLZk5ynz58jkWEhD35OmVNnPuuPwGmpvIG1Ldb62.ng5jH UAC3SC6ONziXBIvgTJ8AeQ5C8qAt01w8HBgVlMJYkUo9BWai6qM1QaGzR3Lhw4gbkDFpzGe75YAF jMWs- X-Sonic-MF: X-Sonic-ID: 1a1f43fa-1a76-43d9-b7d1-46ab74f2cc32 Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Thu, 27 Apr 2023 00:15:39 +0000 Received: by hermes--production-gq1-546798879c-kkjqb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 8aaf785c9e8ff8272d7493745652b26e; Thu, 27 Apr 2023 00:15:36 +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 \(3731.400.51.1.1\)) Subject: Re: FreeBSD 14: Poll armv6 deprecated or removed (. . .) From: Mark Millard In-Reply-To: Date: Wed, 26 Apr 2023 17:15:25 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <59E6F239-10E1-4958-87BA-49960C7C146E.ref@yahoo.com> <59E6F239-10E1-4958-87BA-49960C7C146E@yahoo.com> To: Warner Losh X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spamd-Result: default: False [-2.56 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_SHORT(-0.06)[-0.057]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-Rspamd-Queue-Id: 4Q6GV56Q8Mz3l6H X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N [The text replaced by ". . ." in the Subject line would have been confusing at this point.] On Dec 13, 2022, at 10:57, Warner Losh wrote: > On Tue, Dec 13, 2022 at 11:48 AM Mark Millard = wrote: >> FYI: The old 2021-Oct-28 message related to armv6 removal >> sequencing/timing has a new follow up finally: >>=20 >> = https://lists.freebsd.org/archives/freebsd-arch/2022-December/000313.html >>=20 >> (Nothing about this changes the armv7 status.) >>=20 > Nope. >=20 > tl;dr: armv6 packages will stop, we'll stop doing -current armv6 = snapshots, we'll move armv6 to > an 'extra' architecture in universe for stable/14. post stable/14 = we'll tear down support for armv6 > in base and later in ports. Ports mention armv6 ~500 times, maybe 1/4 = of them also mention armv7, > and the vast majority of them mark things as broken in some way = (though there are exceptions). Any updates on what the intended status of armv6 will be as of 14.0-RELEASE being available? =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Apr 27 12:52:21 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 4Q6bHB1JCBz477cl for ; Thu, 27 Apr 2023 12:52:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q6bH96HkDz3vn4 for ; Thu, 27 Apr 2023 12:52:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682599941; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=gKxnoIEhaYHumNPuQGou42/Y51AdKZOIpzN0qJyZtX8=; b=yex6d5Nnt1f0IRBmUqzqeYfra0Um3JfhNRzot6C1lWSMlQAJOLwGXJG9XIS3kb/p1+H3kd 0b0vKb27V8MP1s6iR6bMqCY9nHX/WAvnGAckla5wfNOcx0Ep55QR8AvMPN8EC6TYW+oZ2j wz33hQcFY/DYiEwU5bHnCLRMdVyjzXEgHzMqf04MNDx8OI+UDHSk+E7kHVX5akj1m2Q/Wr E5dSSGordadtBFAmBiUKeNH3t4bPiUPdb+caPDwiyVO579i/ehhGmyuvlagsjw0JwcVgur TO2wsowMDgi2kDryyBk/dgmYmAxryUf3+wOk5jdO23yvZNudxVWgJkdxVsW7kA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1682599941; a=rsa-sha256; cv=none; b=txpR/NhypJFoYp7mbdj/ZmNfzsfqTpky/0k5SO5n9Q9QKqOSVBJDjP4CsJt0DW0BvhB+fI 3o++xyB47X+8AV6p7jMIsZNY6A7YJ6u5jogQcZZDJ4+Zyxyrd+orAPJKV9cdG2EdWjPPOB LM5hP2+Y1/ubU8tdNIZWaw0t20LFHSll2OgvcoV67p1TtliH4kWiKz65SkKVhaMAaWm+MJ cTUlt6bBaGpBJrrMLLT9dNixPrgBzjaCcO0Zz4oIy+lDpeuEvFk36QrISX8xzNLc/NHGlt W/IUzxsVvnU1QAoCd0KXDnxZYRqRneNOaervFGHz40IzSxa6pGH0QMkm6ipoHw== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Q6bH95LrxzJ83 for ; Thu, 27 Apr 2023 12:52:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 33RCqLmn034991 for ; Thu, 27 Apr 2023 12:52:21 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 33RCqLeD034990 for freebsd-arm@FreeBSD.org; Thu, 27 Apr 2023 12:52:21 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 271098] [nanobsd] cannot boot any NANO_LAYOUT model on armv7 Date: Thu, 27 Apr 2023 12:52:21 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 13.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: hondareyte.luc@laposte.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271098 Bug ID: 271098 Summary: [nanobsd] cannot boot any NANO_LAYOUT model on armv7 Product: Base System Version: 13.2-RELEASE Hardware: arm OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: hondareyte.luc@laposte.net Hello, I try to build a bootable image on amd64 for armv7 with EFI for an orangepi= -pc and nanopi neo, but it does not work. The only layout that build without er= ror is 'std-embedded'. But it is not bootable because the offset of the FAT partition is wrong. With an offset of 1M (like GPT) it works. The good one: =3D> 1 402511 md0 MBR (197M) 1 2047 - free - (1.0M) 2048 65536 1 fat16 [active] (32M) 67584 65536 2 freebsd (32M) 133120 269392 3 freebsd (132M) =3D> 0 269392 md0s3 BSD (132M) 0 16 - free - (8.0K) 16 269376 1 freebsd-ufs (132M) The partition layout with 'std-embedded' is as follow (I have manually acti= vate FAT16 partition): The bad: =3D> 1 400464 md0 MBR (196M) 1 65536 1 fat16 [active] (32M) 65537 65536 2 freebsd (32M) 131073 269392 3 freebsd (132M) =3D> 0 269392 md0s3 BSD (132M) 0 16 - free - (8.0K) 16 269376 1 freebsd-ufs (132M) And the ugly: here a patch which a new scheme named 'std-armv7' (not sure t= his is the best way to solve the problem) which add an offset to _.s1. --- common.ori 2023-04-26 13:05:49.229317000 +0200 +++ common.new 2023-04-27 14:42:41.388647000 +0200 @@ -268,6 +268,13 @@ # but there's problems: it marks all partitions as active, so you h= ave to # boot off partition 3 or 2 by hand if you're playing around with t= his WIP case ${NANO_LAYOUT} in + std-armv7) + # Layout for armv7 with EFI + mkimg -a 1 -s mbr -p ${s1}:=3D${NANO_LOG}/_.s1:1M \ + -p ${s2}:=3D${NANO_LOG}/_.s2 \ + -p ${s3}:=3D${NANO_LOG}/_.s3 \ + -o ${out} + ;; std-embedded) mkimg -a 3 ${skiparg} ${fmtarg} ${bootmbr} -s mbr -p ${s1}:=3D${NANO_LOG}/_.s1 \ -p ${s2}:=3D${NANO_LOG}/_.s2 \ @@ -593,7 +600,7 @@ : ${NANO_MAKEFS_UFS:=3Dmakefs -t ffs -B ${NANO_ENDIAN}} : ${NANO_DISK_SCHEME:=3Dmbr} # No others really supported ATM (well, g= pt) case ${NANO_LAYOUT} in -std-embedded) +std-embedded|std-armv7) NANO_SLICE_FAT=3Ds1 NANO_SLICE_CFG=3Ds2 NANO_SLICE_ROOT=3Ds3 Regards, Luc --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Thu Apr 27 16:31:01 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 4Q6h7T5Y3gz47P1q for ; Thu, 27 Apr 2023 16:31:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q6h7T093Gz3QFx for ; Thu, 27 Apr 2023 16:31:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682613061; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=D+ZIp/Lcq9gz63fpX71KCx3bqIrg1N/zyIwj01wDwSg=; b=GqcYUZNEQFvk69f8hVBAllKBGvlHxMtg+gtcFeUvXn9f3w9PUmB8PvkBjaDF+hf3lEZU/u YCwl7DWXI8AxYOvxypBS2KRucDDFOywcI/SXMjtSA9AqlxWs+pFreGUCQcw5TRT2BJZRcZ Pw8Au0q2mINmiUGtk9e0RDirn2SFN003HRSorVmVspjqq2nsmx+4Ba1AzG/CiR7gGXVRDr pbmclGFkQMqkiz84juo7Oj3IqqF6B4VrNdbqEqmjS898P51Gb5ZW2n47NgFsSnavzqIZn3 3VgmmvJB6RRROsvF2mxxyeloaEdfZ9hOa9jfuSMs8BQQjXY0PRQRX7QW3WEpoQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1682613061; a=rsa-sha256; cv=none; b=uwCYF2Fnb4OICdq+SEHClds/z2uLJAASceFeC3ATc82qF4Eyb6gygS9U+bq0vXkc3k5wzX Gri5IaIY5ayjlrclNDqiDXwZxAwLY15DKc4vKIdmSGxUgN4q7at8SNyLAR6Pu7DBM2jb5s zsP8bk7UGWdYNpLSLOcdSZAmUbW+WwKQbsTCRe1+JMZlIIdU6UhOA116NU1PsHevlcwz7+ Q4wivLHQTNQmeExzxOe6e5cgPfoz3DXQmt3IXJYMUGsfQB3zpR/738neLsOz9T3VgbKzHg 88/i6Dnr+YEi4Ciu91MGnBzlc0oK+rXMXAi7h2XGeev2Eqh5irAtULOBP2DaJg== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Q6h7S6NsmzQ06 for ; Thu, 27 Apr 2023 16:31:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 33RGV06l066985 for ; Thu, 27 Apr 2023 16:31:00 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 33RGV06f066984 for freebsd-arm@FreeBSD.org; Thu, 27 Apr 2023 16:31:00 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 271102] Bagalore Escorts Date: Thu, 27 Apr 2023 16:31:01 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: Unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: streetnight908@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271102 Bug ID: 271102 Summary: Bagalore Escorts Product: Base System Version: Unspecified Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: streetnight908@gmail.com https://streetnightfun.com/call-girls/bangalore/ https://streetnightfun.com/call-girls/delhi-call-girls/ https://streetnightfun.com/call-girls/goa/ https://streetnightfun.com/call-girls/mumbai-call-girls/ https://streetnightfun.com/call-girls/rajasthan/jaipur/ --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Thu Apr 27 16:34:03 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 4Q6hBz2hm4z47P38 for ; Thu, 27 Apr 2023 16:34:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q6hBz0lfSz3hjQ for ; Thu, 27 Apr 2023 16:34:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682613243; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=kMXltRV5n+eERIDDTN2X7TsJ5idVZxI2PRQJwvakTso=; b=JKqjIQ7gjgjiXWvaI5IEpWnyFgvdSPnIxg2BsBgoXAvc42sRre7TfWZMaDNvufz8oGik43 2jx457mO42t5EeQXIjhbi3PIgTBRbDVkuih1TA37C3ygH6vfADg+T5PduzOezunJ06H5i3 UWMervBVdNL6uLo51zLX3Z89PB2zA9qRP8lhcjgPcwZm7Pa/p0nZi5V9aUmOWGbSQyj56Z WLD+uWKKB284vVifYirDW+auNwxD2VTuBz7evBXsSgk0xfiZhX/9NNdCIpvObmqKWYoLKb RE8uDd3GRI+aJdVj0tzeP+gBhat2nDdFbfuvtiFvMNDcJjZ1aY3sI9avLuNg6w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1682613243; a=rsa-sha256; cv=none; b=BxvtkS37KEiqhfU8z7bPQcs63vnU38k9el7cYUhbvBkJHGksGwsizm+VccUg5YgUEHF7Ho RnZfxYV4JTUHNUTxJaz81hVoPPhzJs3xuBzC75sv1y/xZd2noqNHJd6XrqgBsOTgP8PbNf rgxqURgpGM39J2ywz1L+Od7m/c+bPCQ0H564+5rIBsCh9Bk0aeYzK8n/gL9UKURVxD3ifP FFeSoPzVkVlRWSQfcCS6ipNDZrRPn8EcsqHrz3GopU1X3wTUOvLT+KKVheK0I6unwB/xHF rMzvEC+818cgWGcXIgrV9mCLv9pcG/YS6DS0UxIt0qR4rUuxAzyhB5WGXobwgw== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Q6hBy6wdzzPx9 for ; Thu, 27 Apr 2023 16:34:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 33RGY2mi075585 for ; Thu, 27 Apr 2023 16:34:02 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 33RGY2Qv075583 for freebsd-arm@FreeBSD.org; Thu, 27 Apr 2023 16:34:02 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 271102] Bagalore Escorts Date: Thu, 27 Apr 2023 16:34:03 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Other X-Bugzilla-Component: Spam X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: vishwin@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Not Accepted X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugmeister@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status component assigned_to version product Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271102 Charlie Li changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |Not Accepted Status|New |Closed Component|arm |Spam Assignee|freebsd-arm@FreeBSD.org |bugmeister@FreeBSD.org Version|Unspecified |unspecified Product|Base System |Other --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sat Apr 29 21:09:17 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 4Q82Cy2DCrz48GKS for ; Sat, 29 Apr 2023 21:09:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.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 4Q82Cw3N0rz3n0S for ; Sat, 29 Apr 2023 21:09:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=PCLmk6CF; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.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=1682802570; bh=8YcqB/ws+4OyS94d2bsWpKaKQSMb40BWDad0bUhTw44=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=PCLmk6CFbDhKGFirdAJxz1mEJoaDBIb+5/T09kPj2fqrkAtq5GQMxinLrOyCCiH4KCdRbZegvAqA/9+li/wdeZ7lUd9K7DIaBzXRlIXf0RhdGtqKqdeXKhiSjz2XJuPPKMXxQUYFmquo3vWAKJpjnszUgWehOGCUg9nhVroAWg7AqB7GViCS/mpFF1wVVMrdsVffn6WPMCH2xuGEbEqJy0zNsoYzxB1u6J6jgBEi/TH8Lx8jDY2E4SH7t0m5ZNvrquyoB7XLV5aHq9NJ18e1+14B6FPiUMiTn7nhxXm5aKHYk+eP8x2T9K7g38Zw1vADevWxdAalVS3aurltpZsDWw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1682802570; bh=d7WS8dUBZeYB8BCHUqLCFfojSms0EaeIA/VXv4CUSpm=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=UxvdF07mxHFrjvXA9bsvARY2OyTy/7QXpDNPR/nMTRT4ltVFNoSU5BsE0mJwlFdMNYrhvgWic+CGU75VhF7tlMAuk3D2MPVEiumY+EtrKpJ6KaKFEkeTSaU5aoqwuc7fxI4MCwNo8prd1IZ6wZh395Jr+yxXhCuKYEX6NHk4KtUaYZE0cqk3N4Qi8ktFVRr+yxrGVl5Vt64Bjpo5Rn5vfNTXYDc5gBl9Qur03uykpLE86QXcTlXIbDSRz7+gb26KZ1giVQkxQnZ4TV9cN9+vMPwjjXs7/lQGuVOmCO5x2DDDYCeoEmYJBwGl/C8QYvAXjE1OtmijJtpVwPsckLnyFQ== X-YMail-OSG: vMyEWc8VM1likePTgbc6e9nv8fTHT.UXSE0J9dHqC_Rkxmm2FihNrBvogvdgbDH aYCUb8h74wXcO1A.ARNxbCzUwivUpY87s71dP.HkGzZOCwEbsfnF6H_Jd1byO1I6nE4aOBHKQVHD 48kUl6MFnsPyjyoCbDjpqopRbCHsHABaBix5gK5VJcX9ycvc.KintqHAuVKNryxA6VKWJYcBcmd7 4ptQgH97cbCH6jWCborrdfGdB_5E5JN97ZI3WXqdEHRmLCUUtlchJD4Cyu8NNsOaIhxXDRpGHkjL Y.0HrknkkdSSuWMjl3ob.GzRGL9LgPHiN9_xdZftbuceVFFJSkIgolpMayjt9Dzxj_po8zMnu03L 1ytwp2qr6ifule7qJLI9XOuO.yFLdfBWHyGRagA34O_quf8KZx.U.6gLL2fUqg70gGMUDmqcscbI aa1hD_QspEnsO9EOuDXQiKtMjjxyQyJT9_9nEoq0cztQHNyPq5J6ELy8GunUr2o4m.1N3Vh8zig1 1Hv2vJGWW1K4UlBveetvDqcX66KMVIYGcLn6JH_js3VDbvvuQURSTRxFoNxrgfkfmMx1cYJkCHPw X4lmvPYm827rfKsKGQRHTVHPFCzFMI7I3Wigq.VVeJ.aYYY0xBfdUu_ponMQdRZscojFrWecimCQ sAJ5neOWO1F1bKEuSG.XeZZ.nbziwA._zQ_5q1v4ylvUxIuOQibeJV1V5HzGCtc3we2pfAjdLqQM qUgh3yg.r6kw_be2kxnrmFBDgHRx8IYYRa5rl7N78w9TPKB0rCbKGQr_t9ODoCFXIY5nvjFQRUsp eYsExvCT5Y8D6TxWZWf4T1EfxTemHvX8lNJC_n4skad1GU1W33pKhqGXUmsVk0WNedFw4kQrMDTj L25NwC3WqETYj8fj1AjtOlrWevn9F07Tdk_sKMYfFhHK9kBC4SydrGfp4lAJIghJCRlAU.XIoQsO xNnUctwOFjKkDMtqhfFyf6UF.w4jTpPliPmoWvMib5SqGU._k9FBtmv06q9YZ5000Wm.8iS6Mtu2 PYPt3w4fT4Uyxv258pj5REh0XTr02wjN3C3_FiRardeaUpomKUPVZGwaS9Bwc8qnbub2tkb.DleX izR8m52KtOQa1S.eTWtWCTnpWu1CrORAh6_ED4Qwr2DJ2MWj_.e8j2BmpxN.4Z5N3LuCns7MsqDR TywC2JRQxXSvrqa7q5BCNbhuzQJsQvCoLhV41JQauaeNfnh8LVkp2F2Fm1Avh8KzrOvpbWM8KUhH OYmKZf56eEQL_SclIyGE0ERexpp16vp06kZcUuxpzGV5N.pvSyJGA3Q37YyzErnCHMyr7rsiV4gT D.2mUYS0J9_aBSItHl5.8OqH_an1hvWK3.bzWdeFjh_aNXgXVVzNigEWHG5VkSN2jNBo4HTUNqDO aZor7RvKwqJWXQSWBfChlQ65Pd5e7N.U.nA7qlbjJhd_ZzR084sAT_5XlPYYkANlDaXBf62Jmxyp UHD9nWaR7KsbxnHoVPLjCUl4azUh6qWx46snJjHUMjO71Jw7N5.BwV4tkorbQalxtTQ7Ai81ukmd LegF4CNKhvQ5i6CsjdEVxdyKbKBRZ_RCU31PpBdGj6frSynS7QT053ChvJpO5.URhCHJJgKQT6Mm 1fWstW77DzX5bAPXUkng7TF37.AR6DpXWovUieI0ix22WSZZ_wSIUD644L4sExD097EtrZeXC6dd I8USyuZe.2b3WAG9yAPG5mpxINdRv_nYIBld9bLjXq8jPGb6wIiVQcfn6ZauCImu0SNok1ZDoZB3 hs6IDj174XSMD_sBPrLhYzXG_UaF.IkS.s76DMWrx2zpNO5eMizS4UoL_MSxDOK3K0x3m5pQfF9a VEXwqxld2QZ5BBlxn4qtunbDKB.JzIvAr5RV_E5NBAsl7fOC2lDk9tODQFOYJhQQ8MDukKSm6XRt IAPDKX_d.qxOO17vqPjOmh5oSb5ts1RRxdAhzoUzr9_6GjhOrBAecmd42Q5l8zAvD.4s.r2C6VtO NpITJORNdLbeKoEFDf9TE86Ar6.yXn77GX_z.xGtNKNv43svQy02_CSpNg8dHkwhN3cX0FQaapCQ iTdnWWA5qj53W9WdYRiwm4nn609o0TqqbTR4MSNiZN5NN_tvjQCQ14EpEUuIgI4EQY7el4nPANX7 xPy9eaDYsOkSmzCP478CCWbDmtYxSQeSEzG9FrfjDDL5jEpLGJaXHJj0QGvl0ZZrLyS9T6Z8MN8L kxQgfOrBpqcfcgNNHMHXqz4sI2O.WDWebaG9ESc1GiCF4EqKgoqTV6Gj_8aimkyEndR7MbGoxBg5 lcgo- X-Sonic-MF: X-Sonic-ID: f0e58359-f89c-44f2-96c6-3247303c2dc6 Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sat, 29 Apr 2023 21:09:30 +0000 Received: by hermes--production-ne1-7dbd98dd99-qthmr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f994fac8294747fd934df0c16472a593; Sat, 29 Apr 2023 21: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 \(3731.400.51.1.1\)) Subject: Re: armv8.2-A+ tuned FreeBSD kernels and buildworld buildkernel times: an example From: Mark Millard In-Reply-To: <177A2369-1751-4DB5-B316-E140ED156B6E@yahoo.com> Date: Sat, 29 Apr 2023 14:09:17 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <4E8BB159-38D1-4EF0-B486-DF6C8B49D7AB@yahoo.com> References: <177A2369-1751-4DB5-B316-E140ED156B6E@yahoo.com> To: FreeBSD Hackers X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spamd-Result: default: False [-2.39 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_SPAM_SHORT(0.11)[0.114]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; 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.65.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:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-Rspamd-Queue-Id: 4Q82Cw3N0rz3n0S X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N On Apr 29, 2023, at 12:16, Mark Millard wrote: > Context: all world's and kernel's involved/built are non-debug style. >=20 > Note: clang15 through LLVM main (so far) has errors in both directions > for the features for cortex-a78c. So I also used +flagm+nofp16fml . > (The cortex-x1c also has such problems, but the details are > different.) >=20 > Notation in table below: > CA72: matching world or kernel had been built using -mcpu=3Dcortex-a72 > CA78C: matching world or kernel had been built using = -mcpu=3Dcortex-a78C+flagm+nofp16fml >=20 > System: Windows Dev Kit 2023 (4 cortex-a78c's and 4 cortex-x1c's): > (both: armv8.2-A with a few more modern features) >=20 > Times to build system from scratch (buildworld buildkernel from same > sources) . . . >=20 > System running: World built in: kernel built in: > CA72 kernel, CA72 world 6601 sec 597 sec > CA78C kernel, CA78C world 4680 sec 413 sec > CA78C kernel, CA72 world (chroot) 4715 sec 422 sec >=20 > The CA72/CA72 is from before I'd built the CA78C world and kernel. > All builds used -j8 . None had competing activity on the machine. >=20 > What this suggests is having an explicitly armv8.2+ tuned kernel > makes a notable difference for -j8 buildworld buildkernel times > on aarch64. "Tuned" here includes newer-feature use, so incompatible with the likes of armv8.0-A hardware, for example. The FEAT_LSE atomics use would be an example. But I've done nothing to investigate subsetting the new-feature use to isolate what makes the biggest contributions to the elapsed-time decrease. > The Windows Dev Kit 2023 is the first (and only) armv8.1+ based > system that I've have access to. So testing such properties is > limited to the one context. >=20 > Also, I've not had access to the Windows Dev Kit 2023 for long: > first experiments. >=20 >=20 > Notes on my historically-usual aarch64 builds: >=20 > On cortex-a72 hardware, my context is -mcpu=3Dcortex-a72 based. This > once exposed a lack of sufficient synchronization in a palce in > the USB subsystem. (Running the same system on cortex-a53 hardware > did not fail. Running -mcpu=3Dcortex-a53 based world+kernel on a > cortex-a72 did not fail. A cortex-a53 hardware running the > -mcpu=3Dcortex-a53 based world+kernel did not fail.) >=20 > Until the hardware failed, there was a time when I also had > access to a cortex-a57 FreeBSD system. >=20 > I do not do such -mcpu=3D tailoring on the only FreeBSD amd64 that > I've access to, a ThreadRipper 1950X. I do such only for the lower > end systems that I have access to. My aarch64 access is all to > lower end, not upper end. I should have reported that my recent activity for this is based on: main-n262658-b347c2284603-dirty, b347c2284603 being from late Apr 28, 2023 UTC. (The "-dirty" is from some historical patches that I use.) Some of my activity has been from somewhat earlier but I wanted to pick up another openzfs fix nor 2 that had happened since then.) =3D=3D=3D Mark Millard marklmi at yahoo.com