On 09.04.20 02:04, Peter Stuge wrote: > I found something that might be relevant in https://del.dog/raw/cbmemlog > however, search it for Remap: > > --8<-- https://del.dog/raw/cbmemlog#149 > PCI: 00:1c.0: Disabling device > PCI: 00:1c.0: check set enabled > PCH: Remap PCIe function 1 to 0
That's a weird puzzle. I've looked into the code, it's not mapping _to_ a specific number but swapping _with_ what was there last. So if the mapping was: idx 0 1 2 3 4 5 6 7 fn 0 1 2 3 4 5 6 7 this swaps what is at 0 with what is at 1: idx 0 1 2 3 4 5 6 7 fn 1 0 2 3 4 5 6 7 > PCI: 00:1c.1 [8086/1c12] enabled > PCI: 00:1c.2: Disabling device > PCH: Remap PCIe function 3 to 0 Swaps what is at 3 with what is at 0: idx 0 1 2 3 4 5 6 7 fn 3 0 2 1 4 5 6 7 > PCI: 00:1c.3 [8086/1c16] enabled > PCH: Remap PCIe function 4 to 0 Swaps what is at 4 with what is at 0: idx 0 1 2 3 4 5 6 7 fn 4 0 2 1 3 5 6 7 idx 1, 3 and 4 are on in the devicetree. So final relevant state: idx 0 1 2 3 4 5 6 7 fn 0 1 3 This is not wrong. But the algorithm is that complex because it's supposed to leave no gaps. And it fails at that in this case :-/ > --8<-- https://del.dog/raw/cbmemlog#175 > PCI: Leftover static devices: > PCI: 00:01.0 > PCI: 00:16.1 > PCI: 00:16.2 > PCI: 00:16.3 > PCI: 00:1c.4 > PCI: 00:1c.2 > PCI: 00:1c.5 > PCI: 00:1c.7 > PCI: Check your devicetree.cb. > -->8-- Partially my fault, when we added these messages, we didn't consider devices that were hidden on purpose. I guess we should not complain about devices on bus 0 with !dev->enabled (i.e. `off` in the device- tree). But here seems also something fishy wrt. the remapping: What about 1c.6? Nico _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
