Created attachment 219717 [details] loader_horror.png Hello. We have Kunpeng 920, Huawei Taishan 2280 V2 for test. Boot fail see loader_horror.png, loader menu have artefacts ASCII code and not work keyboard Index: sys/arm64/arm64/machdep.c =================================================================== --- sys/arm64/arm64/machdep.c (revision 367627) +++ sys/arm64/arm64/machdep.c (working copy) @@ -1059,6 +1059,8 @@ } freeenv(env); + arm64_bus_method = ARM64_BUS_ACPI; + /* If we set the bus method it is valid */ if (arm64_bus_method != ARM64_BUS_NONE) return (true); @@ -1071,6 +1073,8 @@ arm64_bus_method = ARM64_BUS_ACPI; } + arm64_bus_method = ARM64_BUS_ACPI; + /* * If no option was set the default is valid, otherwise we are * setting one to get cninit() working, then calling panic to tell After this patch, and disable loadre_logo=NO boot escape work, loader have more progress but huawei_acpi_error.png generic_timer0: <ARM Generic Timer> irq 70,71,72 on acpi0 Any help wanted
sorry huawei_acpi_error.png too big https://64.media.tumblr.com/e58ded470bc904057a26267c60999200/e4f72ed3bfb30869-cb/s2048x3072/f49c41b38c8bec7fdce9a35a0268cad16e8194a6.png
Created attachment 219726 [details] acpi dump linux
We don't detect ACPI as there is no Serial Port Console Redirection (SPCR) table. It might be better to just check if there there are any ACPI tables. The SPCR check was to ensure there was some sort of console, however recent devices may just send the console to a display making this check less useful. There is a second issue where we only check for the GICv3, where this has a GICv4. The same driver should work with both, so the check could be updated to also allow the latter.
Fall back to use the GICR address from the distributor struct https://reviews.freebsd.org/D27247
A commit references this bug: Author: andrew Date: Thu Nov 19 09:26:51 UTC 2020 New revision: 367841 URL: https://svnweb.freebsd.org/changeset/base/367841 Log: Fall back to use the GICR address from the generic interrupt struct When there is no ACPI redistributor sub-table in the MADT we need to fall back to use the GICR base address from the GIC CPU interface structure. Handle this fallback when adding memory to the device and when counting the number of redistributors. PR: 251171 Reported by: Andrey Fesenko <f0andrey_gmail.com> Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D27247 Changes: head/sys/arm64/arm64/gic_v3_acpi.c
Created attachment 219818 [details] huawei dmesg cdrom only boot after r367841 path https://dpaste.com/3RVB8SBV9 commented https://github.com/freebsd/freebsd/blob/master/sys/dev/pci/pci_host_generic_acpi.c#L204 system success boot with cd, but requere not active jbod and MegaRAID Tri-Mode SAS3408 (if activate and load mrsas) > mountroot: waiting for device /dev/iso9660/13_0_CURRENT_AARCH64_CD... > Mounting from cd9660:/dev/iso9660/13_0_CURRENT_AARCH64_CD failed with error 19. https://dpaste.com/BB3V4LHYS
Created attachment 219819 [details] pciconf
After commit https://reviews.freebsd.org/D27274 https://svnweb.freebsd.org/base?view=revision&revision=368156 Boot not require any patch, but need disable boot menu and load mrsas.ko if use MegaRAID SAS3408. Sorry, the test period is over and the test platform is no longer available.
Created attachment 220198 [details] MegaRAID-SAS3408 partial boot log MegaRAID SAS3408 with mrsas.ko
Created attachment 220199 [details] zpool create error UFS succes work, zpool create not work > (da9:mrsas0:1:9:0): Ecannot zero first 4096 bytes of '/dev/da9p1': Input/output error