Hi all,
I just found out current Genode pci driver does not support a system with multiple root complexes.
More specifically, in the bus_valid() function, it only scans all the devices under the first root complex (starting from bus number 0). As a result, other devices under different root complexes are considered INVALID, thus will be skipped by pci driver code.
Maybe a simple patch will fix the problem.
Best regards, Jilong
-- Jilong Kuang Ph.D. C.Sci. | Samsung Research America - Silicon Valley (SRA-SV)
Senior Research Engineer, Computer Science Lab t: 408-544-2705 c: 951-318-2995 jilong.kuang@...60...mailto:jilong.kuang@...60...
Please consider the environment before printing this email.
This message is intended only for the named recipient(s) above and may contain confidential or privileged information or protected attorney work product. If you are not the intended recipient, any review, dissemination, distribution or copying is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this message and its attachments from your computer and dispose of all other copies or printouts. Thank you.
Hello,
On 08.06.2013 01:13, Jilong Kuang - SISA wrote:
I just found out current Genode pci driver does not support a system with multiple root complexes.
yes, this is true. Until now we had neither the demand nor the hardware to develop for this feature.
I suggest to open at Genode@...197... a feature request. If you have any insights or pointers to some public low level documentation about multiple PCI root complexes in regards to how to use, to handle them, it would be nice to share these information at the github feature request.
Regards,
Alex.
More specifically, in the bus_valid() function, it only scans all the devices under the first root complex (starting from bus number 0). As a result, other devices under different root complexes are considered INVALID, thus will be skipped by pci driver code.
Maybe a simple patch will fix the problem.
Best regards,
Jilong
-- *Jilong Kuang Ph.D. C.Sci. | Samsung Research America – Silicon Valley (SRA-SV)*
Senior Research Engineer, Computer Science Lab t: 408-544-2705 c: 951-318-2995 jilong.kuang@...60... mailto:jilong.kuang@...60...
*P*lease consider the environment before printing this email.
This message is intended only for the named recipient(s) above and may contain confidential or privileged information or protected attorney work product. If you are not the intended recipient, any review, dissemination, distribution or copying is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this message and its attachments from your computer and dispose of all other copies or printouts. Thank you.
How ServiceNow helps IT people transform IT departments:
- A cloud service to automate IT design, transition and operations
- Dashboards that offer high-level views of enterprise services
- A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Alex,
In my opinion, a simple fix is to remove the two lines in _find_next() function in pci_session_component.h
If (!bus_valid(bus)) Continue;
Another way is to scan all buses/devices/functions at the first call of bus_valid(). A simple three level loop will do.
Best, Jilong
On 12.06.2013 19:16, Jilong Kuang - SISA wrote:
In my opinion, a simple fix is to remove the two lines in _find_next() function in pci_session_component.h
If (!bus_valid(bus)) Continue;
Sure, however we would like to know why the pci driver doesn't find the device you are looking for.
Another way is to scan all buses/devices/functions at the first call of bus_valid(). A simple three level loop will do.
The initial scan is done early when pci_drv comes up ~ line 396 in file pci_session_component.h [0].
So, does something happen to the hardware in your setup that a new scan will result in other results ? If yes, can you please explain.
If yes, you may delay the first scan to a later point, by removing the explicit call in line 397 to bus_valid. Without this call the bus_valid function should be triggered as soon as the first pci client connects to the pci driver and looks for a device (calling implicitly _find_next).
Cheers,
Alex.
[0] https://github.com/genodelabs/genode/blob/master/os/src/drivers/pci/pci_sess...
Hi Alex,
I guess the reason why current code doesn't cover all devices is that it assumes all devices can be scanned through recursive function call starting from bus 0 (a single tree structure). However, when there are multiple root complexes, there are more than one tree. So one has to explicitly jump to the next root node and search its tree.
Best, Jilong
Hello,
On Tue, Jun 18, 2013 at 05:14:31PM +0000, Jilong Kuang - SISA wrote:
I guess the reason why current code doesn't cover all devices is that it assumes all devices can be scanned through recursive function call starting from bus 0 (a single tree structure). However, when there are multiple root complexes, there are more than one tree. So one has to explicitly jump to the next root node and search its tree.
Is there any documentation or best practice how to discover "root nodes"? Do we need ACPI or other platform information for that? Scanning through all possible PCI nodes sounds not desirable as it takes its time.
Regards
We were referencing the book <<PCI Express System Architecture>> Chapter 21: PCI Express Enumeration (Enumerating a System with Multiple Root Complexes)
For now I'm not sure about a simpler way to identify root nodes.
Best, Jilong
On Fri, 07 Jun 2013 23:13:18 +0000 Jilong Kuang - SISA (JKS) wrote:
JKS> I just found out current Genode pci driver does not support a system with multiple root complexes. JKS> JKS> More specifically, in the bus_valid() function, it only scans all the devices under the first root complex (starting from bus number 0). As a result, other devices under different root complexes are considered INVALID, thus will be skipped by pci driver code.
Can you provide us with the DSDT from such a machine with multiple root complexes? Under Linux, you can do:
cat /sys/firmware/acpi/tables/DSDT > dsdt.dump
and then send us that file.
Cheers, Udo
Hi Udo,
Please find attached the dump file.
Best, Jilong
On Tue, 18 Jun 2013 20:33:17 +0200 Christian Helmuth (CH) wrote:
CH> On Tue, Jun 18, 2013 at 05:14:31PM +0000, Jilong Kuang - SISA wrote: CH> > I guess the reason why current code doesn't cover all devices is CH> > that it assumes all devices can be scanned through recursive CH> > function call starting from bus 0 (a single tree structure). CH> > However, when there are multiple root complexes, there are more than CH> > one tree. So one has to explicitly jump to the next root node and CH> > search its tree. CH> CH> Is there any documentation or best practice how to discover "root CH> nodes"? Do we need ACPI or other platform information for that? CH> Scanning through all possible PCI nodes sounds not desirable as it CH> takes its time.
Jilong sent the DSDT of his machine, which lists the different PCI root complexes as follows:
Device (PCI0) { Method (^BN00, 0, NotSerialized) { Return (Zero) }
Method (_BBN, 0, NotSerialized) // _BBN: BIOS Bus Number { Return (BN00 ()) } }
Device (PCI1) { Method (^BN40, 0, NotSerialized) { Return (0x40) }
Method (_BBN, 0, NotSerialized) // _BBN: BIOS Bus Number { Return (BN40 ()) } }
Device (PCI2) { Method (^BN80, 0, NotSerialized) { Return (0x80) }
Method (_BBN, 0, NotSerialized) // _BBN: BIOS Bus Number { Return (BN80 ()) } }
Device (PCI3) { Method (^BNC0, 0, NotSerialized) { Return (0xC0) }
Method (_BBN, 0, NotSerialized) // _BBN: BIOS Bus Number { Return (BNC0 ()) } }
There are 4 root complexes, starting at bus numbers 0, 0x40, 0x80, 0xc0 respectively and Genode would have to scan each of them. You can use the _BBN methods in the DSDT to enumerate them.
Cheers, Udo