Windows Dev Kit 2023 usage notes for main [so: 14], including about oddities

Reply: Mark Millard : "Re: Windows Dev Kit 2023 usage notes for main [so: 14], including about oddities"
Go to: [ bottom of page ] [ top of archives ] [ this month ]

From: Mark Millard <marklmi_at_yahoo.com>
Date: Sun, 23 Apr 2023 03:50:37 UTC

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=271012

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=0

(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="YES"
ntpd_sync_on_start="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=270805

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=270935
(not mine) is about (shown in truss output form):

# truss efivar
. . .
openat(AT_FDCWD,"/dev/efi",O_RDWR,00) = 3 (0x3)
ioctl(3,EFIIOC_VAR_NEXT,0x2b0510b84740) ERR#78 'Function not implemented'
. . .

# truss efibootmgr
. . .
openat(AT_FDCWD,"/dev/efi",O_RDWR,00) = 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=crw--w---- ,inode=152,size=0,blksize=4096 }) = 0 (0x0)
ioctl(1,TIOCGETA,0x6c2fa42cd6c8) = 0 (0x0)
BootCurrent: 0000
write(1,"BootCurrent: 0000\n",18) = 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=cc matches the source tree. Not bootstrapping a cross-compiler.
make[1]: "/usr/main-src/Makefile.inc1" line 331: SYSTEM_LINKER: Determined that LD=ld matches the source tree. Not bootstrapping a cross-linker.

===
Mark Millard
marklmi at yahoo.com