> Date: Wed, 08 Jan 2025 13:03:56 +0100 > From: Kirill A. Korinsky <kir...@korins.ky>
Hi Kirill, > arm@, > > My Honor Magicbook Art 14 Snapdragon basicly working and I've started poking > around to answer question why "nothing works". > > Here no battery status, nor "cpu speed", nor almot anything. > > sysctl hw is quite brief: > > hw.machine=arm64 > hw.model=Qualcomm Oryon r2p1 > hw.ncpu=12 > hw.byteorder=1234 > hw.pagesize=4096 > hw.disknames=sd0:,sd1:8de18473f5716cc3 > hw.diskcount=2 > hw.sensors.acpibtn0.indicator0=On (lid open) > hw.sensors.acpitz28.temp0=36.60 degC (zone temperature) > hw.setperf=0 > hw.vendor=HONOR > hw.product=MRO-XXX > hw.version=M3010 > hw.serialno=A8AVCP4B25400027 > hw.uuid=290908f3-a7a3-914f-8db0-a9a55ebc6308 > hw.physmem=33856348160 > hw.usermem=33856344064 > hw.ncpufound=12 > hw.allowpowerdown=1 > hw.perfpolicy=auto > hw.smt=0 > hw.ncpuonline=12 > hw.power=1 > hw.ucomnames= > > why? Because our drivers expect that everything is discovered via FDT and it > isn't true for that machine, see: > https://kirill.korins.ky/pub/honor-magicbook-art-14-snapdragon.eeprom.txt > > Everything can be discovered in ACPI instead, here the dump: > https://kirill.korins.ky/pub/honor-magicbook-art-14-snapdragon.acpi.tgz > > I not sure that copy drivers such as qcipcc or qcaoss is the right idea, but > I haven't see any other way. > > Have I miss something? Maybe here some magic that allows to discover > everything on FDT tree? The ACPI information on these machines is barely usable. ACPI is just not a very good match for these SoC based systems. Microsoft "solved" that problem with PEPs, which are basically system-specific drivers that encode a lot of information about the SoC and how it's actually wired up in the machine in the driver itself. Basically it means you have to write a customized driver for each system... And the interfaces between PEP and ACPI are largely undocumented. So the way we support these systems on OpenBSD is that we require a proper FDT for the machine. These FDTs are made available through the arm64-qcom-dtb "firmware" package that is built from the sysutils/firmware/arm64-qcom-dtb port. The way this is works is that we have implemented some minimal ACPI support that is good enough to run the installer. The installer will download the firmware package and installs it. Upon the next boot, the bootloader will find the FDT and load it before passing control to the kernel. So in order to properly support your system you need to: 1. Create an FDT for your system. I don't think this particular system is supported by Linux yet, but it might be worth asking on the #aarch64-laptops channel on the OFTC IRC server (irc.oftc.net) if someone is working on it. If not, maybe ask mglocker@ for some guidance; he created an FDT for his Samsung Galaxy Book4 Edge. 2. Add the FDT to the sysutils/firmware/arm64-qcom-dtb package. 3. Add an entry for your machine to the mapping table in sys/arch/arm64/stand/efiboot/efiboot.c such that the FDT gets loaded automatically. Cheers, Mark
