Date: Thu, 30 Apr 2026 08:36:50 +0200 From: Milan Obuch <freebsd-hackers@dino.sk> To: freebsd-hackers@freebsd.org Subject: Re: Guidance needed: FreeBSD 15.0-CURRENT Driver attachment for AMD Phoenix SoC Message-ID: <20260430083650.1ddf024b@dino.sk> In-Reply-To: <CALzeOLTd-4bFKoHTk2LGwhB-vX4JF5R=QZ1C2s6TZ7dBzXTUxw@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
On Wed, 29 Apr 2026 23:07:07 +0000 Anthony Katernoza <anthony.katernoza@gmail.com> wrote: > Hello, > > I am seeking support on hardware gaps for the AMD Phoenix SoC. > This issue is on a FreeBSD 15.0-CURRENT system. > > I have AMD drivers on my system that are unmanaged (none@pci). > Critically, my FCH LPC Bridge (PCI ID: 1022:790e) is unmanaged. Hi, I am just comparing your data with that of mine, on another AMD based box, with Renoir/Cezanne CPU/SoC. In my case, FCH LPC Bridge is isab0, in 'pciconf -lvb' output I see the same PCI ID (vendor and device), but subvendor and subdevice differs. My device has sub-id 0x1022:0x790e, while yours is 0x1028:0x0ca9. > Sensor Fusion (PCI ID: 1022:164a) is also unmanaged. > This looks to be an issue in the SoC's newbus hierarchy, > as it prevents the kernel from attaching to child devices under FCH, > such as the Embedded Controller (EC0). > Confirmation of EC0 issues are in the ACPI dump, > where the ACPI subsystem comes back as "AE_NOT_FOUND". > Furthermore, 9 other related AMD drivers are labeled none@pci. So, none0 is Phoenix IOMMU, I have Renoir/Cezanne IOMMU here as well. none1, none2 and none3 are weird - all fields are zeros, we need to consult TRM for SoC for details I think... did you try to find one? Basically all details should be looked for in TRM for given SoC. But I think those three devices are not important. none4 we already analysed above (LPC bridge) none5 is Phoenix CCP/PSP 3.0 Device, in my case I have none1 with description Raven/Raven2/FireFlight/Renoir/Cezanne Platform Security Processor, so I consider this not that much important for a moment (no idea whether we have support for similar devices). none6 - Audio Coprocessor, no idea on this one. none7 - Sensor Fusion Hub, again, no idea here. none8 - Phoenix Dummy Function, I have none2 Zeppelin/Raven/Raven2 PCIe Dummy Function. I think we can skip this one for now. none9 - AMD IPU Device, no idea on this one none10 - another Phoenix Dummy Function, Skip for now... > I have already filed a formal bug report, which includes evidence from > a compilation of ACPI, dmesg, pciconf & vmstat logs about this issue. > FCH, Sensor Fusion, multimedia & other driver results are included: > (Aforementioned logs are compiled into an attached .txt file). > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294406 My feeling is one attachment per command output would be better, but this is still workable. ACPI dumps are being somewhat bigger, which makes combining them with other output somewhat harder to manage, but I think you compiled relevant bits there. Could you eventually add another attachment with just dmesg output from verbose boot? We can get more info from there. And, while I am on this, you could get more detailed output from 'pciconf -lBbcevV' and attach it (separate attachment would be better in my oppinion) to your PR as well. I think this way you can collect all possible details on your device in well manageable fassion. > This being said, I am looking for technical assistance on: > > 1. Whether the problem devices require new chipset drivers > or if adding the ID to existing isab(4) or chipset(4) logic is viable. Looking quickly over sources, it appears to me isab is handled in sys/dev/pci/isa_pci.c file. In isab_pci_probe function, I see some general logic and exception added... maybe you could add there one more special case and test. But I am not confident I am looking at the right place, I have no special knowledge in this area. But as it is basically just one line added, it is simple to test... > 2. If there are specific testers and/or developers currently working > on this type of SoC fabric, who may need raw data from this device. No idea on this... just wait for someone else to appear. Hope this helps abit. Regards, Milanhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20260430083650.1ddf024b>