Re: Is there a way to enable a PCI-PCI bridge on bus 3 early?

On Thu, 11 Jan 2024 at 10:52, Nico Huber <[email protected]> wrote:
> > On Fri, 5 Jan 2024 at 09:58, Nico Huber <[email protected]> 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
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]