Date: Mon, 21 Jun 2021 23:30:12 -0700 From: Mark Millard via freebsd-arm <freebsd-arm@freebsd.org> To: freebsd-arm <freebsd-arm@freebsd.org> Subject: HoneyComb first-boot notes Message-ID: <8A6C415F-A57B-4F2F-861F-052B487166D6@yahoo.com> References: <8A6C415F-A57B-4F2F-861F-052B487166D6.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@CA72_16Gp_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/ar= m64.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. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8A6C415F-A57B-4F2F-861F-052B487166D6>