HoneyComb first-boot notes

From: Mark Millard via freebsd-arm <freebsd-arm_at_freebsd.org>
Date: Mon, 21 Jun 2021 23:30:12 -0700
I put an existing FreeBSD Optane into a just delivered
HoneyComb, put in the RAM and the matching UEFI/ACPI
image on a microsd card and put the card in the slot.
I plugged in a USB3 Ethernet dongle, like I use on some
other systems. Serial console via its USB port for such.
(Optane instead of video card.) The UEFI/ACPI image was
extracted from:

https://solid-run-images.sos-de-fra-1.exo.io/LX2k/lx2160a_uefi/lx2160acex7_2000_700_2900_8_5_2_sd_81b4bbe.img.xz

in order to match the RAM and being based on the
most current vintage at:

https://github.com/SolidRun/lx2160a_uefi/

It booted.

There are some notices during boot, such as:

ACPI: IORT: Dropping unhandled type 1
ACPI: IORT: Dropping unhandled type 1
ACPI: IORT: Dropping unhandled type 1
ACPI: IORT: Dropping unhandled type 1
ACPI: IORT: Dropping unhandled type 1
ACPI: IORT: Dropping unhandled type 1
ACPI: IORT: Dropping unhandled type 1
ACPI: IORT: Dropping unhandled type 1
ACPI: IORT: Dropping unhandled type 1
ACPI: IORT: Dropping unhandled type 6

acpi0: Could not update all GPEs: AE_NOT_CONFIGURED

device_attach: acpi_perf0 attach returned 6
device_attach: acpi_perf1 attach returned 6
device_attach: acpi_perf2 attach returned 6
device_attach: acpi_perf3 attach returned 6
device_attach: acpi_perf4 attach returned 6
device_attach: acpi_perf5 attach returned 6
device_attach: acpi_perf6 attach returned 6
device_attach: acpi_perf7 attach returned 6
device_attach: acpi_perf8 attach returned 6
device_attach: acpi_perf9 attach returned 6
device_attach: acpi_perf10 attach returned 6
device_attach: acpi_perf11 attach returned 6
device_attach: acpi_perf12 attach returned 6
device_attach: acpi_perf13 attach returned 6
device_attach: acpi_perf14 attach returned 6
device_attach: acpi_perf15 attach returned 6

(That block repeats again.)

acpi_tz0: failed to set new freq, disabling passive cooling

But the rest looked normal to me.

For reference:

# uname -apKU
FreeBSD CA72_16Gp_ZFS 13.0-RELEASE-p1 FreeBSD 13.0-RELEASE-p1 #1 releng/13.0-n244744-8023e729a521-dirty: Wed May 26 14:59:50 PDT 2021     root_at_CA72_16Gp_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/sys/GENERIC-NODBG-CA72  arm64 aarch64 1300139 1300139

I've not yet used bectl to try a stable/13 or main boot.
(Currently they are late-May vintages as well.)

There is an under-investigation issue for the recent
processors from NXP that are in use on the new board,
not limited to FreeBSD:

# sysctl -a | grep "therm.*temp"
hw.acpi.thermal.tz8.temperature: 0.1C
hw.acpi.thermal.tz7.temperature: 0.1C
hw.acpi.thermal.tz6.temperature: 53.1C
hw.acpi.thermal.tz5.temperature: 53.1C
hw.acpi.thermal.tz4.temperature: 53.1C
hw.acpi.thermal.tz3.temperature: 53.1C
hw.acpi.thermal.tz2.temperature: 54.1C
hw.acpi.thermal.tz1.temperature: 52.1C
hw.acpi.thermal.tz0.temperature: 53.1C

(I've only had it sitting idle.) Mention
has been made of "I2C bus is locking up
in the AML code".

The UEFI/ACPI user interface does not yet report
the actual RAM, saying "32767 MB RAM" instead of
indicating the actual 64 GB for this test. But
the FreeBSD kernel does see the 64 GB of RAM.

I get to try my first heat sink (and fan) replacement
(to a better pair than shipped). Now that I know it
basically works, can I avoid breaking it? . . .

I'm not likely to push the system until the oddities
related to cooling have been addressed in some way.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Received on Tue Jun 22 2021 - 06:30:12 UTC

Original text of this message