On Thu, 11 Jan 2024 at 10:52, Nico Huber nico.h@gmx.de wrote:
On Fri, 5 Jan 2024 at 09:58, Nico Huber nico.h@gmx.de wrote:
Hi again, and a happy new year!
With this code below I did just enough to enable subtractive decode in the root port and legacy PCI bridge (datasheet does call for doing both for legacy PCI mode) and nothing else. That ASM1083 just worked, and I finally got POST codes on PCI slot.
That is interesting, so the ASM1083 forwards port 80h without configuration?
Pretty much. Documentation on this chip is very minimal - it only has a register listing and their defaults, no explaining what any of them do.
It too has a subtractive decode bit that defaults to off, but no minute details around it.
On 11.01.24 14:43, Nico Huber via coreboot wrote:
On 11.01.24 07:03, Keith Hui wrote:
However, I lost integrated graphics completely. A boot log is attached.
I fear it is not. Did you forget the attachment?
Found it now. It says early in ramstage:
[INFO ] PCI: Static device PCI: 00:02.0 not found, disabling it.
So that's definitely an issue. But I really can't imagine how this is happening, and why this particular device. As I understand the hardware, all the decoding settings in the PCH shouldn't affect the northbridge devices.
There's more
[DEBUG] IGD decoded, subtracting 160M UMA and 0M GTT
0M isn't a good idea. This just prints what register settings were found. Those were probably set in romstage (compiled into bootblock with your settings if I interpreted the log correctly).
It looks all very odd and alas I have no clue how it could relate to the subtractive-decode settings.
Me neither - I didn't know where this setting resides.
After giving an arbitrary out-of-the-way bus number (10) to the root port, I finally got both POST codes and integrated graphic working.
Thanks Nico for your help so far - but wait, there's more!
Seems all the troubles I have encountered along the way: System becoming inoperative - turns out it got hung up during PCI bus scan Loss of integrated graphics Loss of ability to soft reboot and power off ... are all the results of bus number conflict.
Another takeaway is I don't really need the legacy PCI bridge device aka D30F0 at all. All my troubles old and new this guy doesn't seem to make any difference.
Leaving this setup in, now I have a Sound Blaster Live! in the PCI slot and it can't initialize.
Kernel reports: pci 0000:0a:00.0: can't derive routing for PCI INT A snd_emu10k1 0000:0b:00.0: PCI INT A: no GSI genirq: Flags mismatch irq 0. 00000080 (snd_emu10k1) vs. 00015a00 (timer) snd_emu10k1: probe of 0000:0b:00.0 failed with error -16 (that -16 is -EBUSY.)
Since I shut the I/O window on the (subtractive) root port and the PCI code in ramstage didn't touch it, the sound card didn't have I/O allocated and can't possibly work.
I also see that ramstage did not scan bus 10. Is it by design? Will I have to probe for a device and abort this attempt if one is found? My thinking is POST cards tend to be cheap designs that don't respond to bus scans nor have a config space. I have no experience with PCIe POST cards because I don't have one, and are more expensive starting at $50.
How can I convince the PCI enumerator to work on this fudged root port like any other?
Thanks Keith