Re: Guidance needed: FreeBSD 15.0-CURRENT Driver attachment for AMD Phoenix SoC

On Fri, 1 May 2026 00:15:42 -0500
Anthony Katernoza <[email protected]> wrote:

> >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.

[ snip ]

> >> 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...

[ snip ]

> I have posted a pciconf -lBbcevV log and boot dmesg log to the report.
> In terms of making any tests on isab or chipset c-code tests,
> I myself am not confident. From what I gathered from the new
> pciconf logs, pretty much every error in the nonepci areas
> (ie. ecap 000d[2a0] = ACS 1 Source Validation unavailable)
> looks to be downstream of IOMMU and EC0 communication issues.
> 
> In theory, the test is straightfoward,
> but I'll have to set up some backup
> kernels before I do so.
> In your experience, where else
> could this type of c-code be present
> beyond isab?

So, looking over verbose boot dmesg output, I noticed this:

isab1: <PCI-ISA bridge> at device 20.3 on pci0
device_attach: isab1 attach returned 6

This means, in isab_pci_probe function, device none4 is being correctly
classified as PCI-ISA bridge, problem is in attaching driver to this
device. In the same file, sys/dev/pci/isa_pci.c, look for
isab_pci_attach function. You can see all work is actually done in
isab_attach function, which is defined in some other file...
searching... and sys/isa/isa_common.c is found.

Error 6 is ENXIO, and it comes from

device_add_child(dev, "isa", 0)

call. Earlier in boot, we see

isab0: <ACPI Generic ISA bridge> on acpi0
isa0: <ISA bus> on isab0

If I understand the source right, there could be just one isab device,
and that slot is already taken. At this point, we need someone with more
knowledge in this area, probably. What I'd test now, just for test, I
do not expect anything from it, would be a boot with ACPI disabled
(this could fail, I think ACPI is kind of mandatory for modern boards)
and compare the result of pciconf under this condition with what you
have now.

Regards,
Milan