Patrick Mochel <[EMAIL PROTECTED]> writes: > > > One thing that was talked about at OLS this year was a common table > > > standard for platforms that control their own firwmare: linuxbios, some > > > embedded PPC folk, and some arm folk. Typically, each wants to be able to > > > tell the kernel about the devices that are on the system (feed the kernel > > > an already constructured device tree), and resource information about some > > > of those devices. > > > > If the other platforms already have a table then we may not be able to > > change it. Because tables tend to be the ABI of the firmware to the kernel. > > At the very least you don't want to change the recognition sequence. > > AFAIK, they don't have table formats. Or, they have some minimal mechanism > for passing configuration data. But, there was no unified mechanism for > representing devices until 2.5, so it's always been a PITA to do something > like this..
Then this is the time to start looking at this. > > What is shareable is a good model kernel side, and possibly some subtables. > > Roughly prepopulating the kernels device tree so it doesn't need to do > > dangerous probes for onboard ISA type devices. Having a version of lm_sensors > > > that automatically configures itself would be very nice. > > Yes, that is very nice, and exactly what is needed by all parties. That is > actually what ACPI wants to do. One ACPI requirement is that the OS use > ACPI to enumerate as many devices as it can before the OS does any probing > (native enumeration in ACPI-speak). > > I have a patch I wrote a few months ago that uses the ACPI tables to > discover devices, rather than probing for them. It's pretty nifty, and > will probably be instructive to see how another firmware 'driver' does it. > I'll be updating it and posting probably in the next month (once some > other issues get resolved.) I'll be sure to touch bases with you when I > do.. I would encourage you to always assume that the firmware is buggy, and do some kind of confirmation probe to make certain that the firmware isn't lying. > > When I started looking at this the first thing I realized is that > > devices are not connected as a tree. So the idea of a device tree is > > basically silly. There are devices with multiple ways to get to them, > > and various other interesting tidbits. > > Most devices are connected in a tree, and the kernel really wants to > believe that, for various reasons - power management, shutdown sequences, > hotplugging. You want to represent ancestral relationships as accurately > as possible, to make these things easier to do. It is convinient to have deives arranged as a tree, but it is a matter of perspective. If you were to build a tree based on the irq routing perspective, where you had top level irq controllers, then the devices that feed into them etc. A very different tree but valid tree would be constructed from the traditional tree. My current draft design calls for a graph with a tree backbone, so I can accurately represent all of the interesting interactions. If you just care about the tree you can ignore the extra links. But whichever way I do it, I will pick the representation that is convinient and maintainable from LinuBIOS and I won't aim at a one true tree representation, as I am quite certain there is no such thing. > I would really stress trying to adhere to an accurate tree as much as > possible. The ones that tend to not conform are: I need that information more than the kernel. So accuracy should not be something hard to accomplish. > - legacy devices > These are typically hanging off the southbridge, usually as functions of > the superio chipset. Make them children of the southbridge. > > - system devices > CPUs, APICs, PITs (?), etc. In the device tree, I've made a pseudo system > bus for these devices. I would recommend grouping them under something > similar, or have some sort of ID tag to identify that it's a device of > Type X, so you know it belongs on the system bus. For APICs and PITs I have a very valid reason for sticking them in various places around my device tree for purposes of resource allocation. > > In addition, there are several times when you run into cases where > > devices need some aditional information to run. lm_sensors needs > > calibration data on their sensors. ioapics need data that maps > > their irq inputs to irq sources, etc. Given that bus id's change > > the only sane way of handling this information is attaching it > > to the device tree. > > Yes, and legacy devices need resource information, since you don't > necessarily want to assume that they appear at their legacy I/O port. Agreed. What I would like to say is not that I have a serial port at address X. But that I have a winond superio chip at addres x, and it has subfunctions, of a serial port, a parellel port, a temperature sensors, and other goodies. > I don't know how you represent this, but I might suggest something like > > - define a resource structure for each type of device > - create a table type for resource structures for each type of device > - index each device of a particular type in the device tree, so it > can map back to an entry of the resource table for that type > > You will end up with several more table types, but each will be simple and > their meaning clear. What I am looking at is a more or less tree structure. One important rule for me is that it should be possible to relocate the table arbitrarily without breaking the meaning so no absolute pointers only relative ones are allowed. Beyond this I am looking at a generic structure for a device, and a generic structure for a resource. But a seperate table type for each different use of a resource. So valid temperature ranges, the type of an irq etc. With irq routing connection information (needed to rout irqs) the base tree can easily turn into a graph. > How would bus IDs change for these devices? In that case I was thinking more along the lines of irq routing, then the sensor calibration information. But in the general case these devices could be pci as well. Plus if they are on an i^2c bus, and you have 3 pci i^2c controllers in your system there are definitely bus id's in the path. > The types of devices that you > typically need this information for are the ones that are attached to the > motherboard. If you change these devices, you'll have to change the table > anyway.. > > One final question: do you use PnP IDs? Where applicable. I have just recently done the work so etherboot will return the PnP ID or PCI ID of the type of nic they system is booting from. I'm really not yet certain how to handle superio chips or sensor devices because I don't think they have native IDs. I am tempeted to use manufacturer and part number for those cases where I can't use any previously defined IDs. But first I need to compare notes with what ACPI and the PnP BIOS are doing to be certain there isn't a standard PnP ID already, and I just haven't seen it. > I don't buy into a lot of the > cruft of Microsoft and Intel specs, esp. WRT firmware. But, they have gone > through and attached IDs to nearly all types of devices that are found on > motherboards. It's what ACPI and PnP BIOSes use to tell the OS about > devices. My impression has always been, with all of the good engineer how can the final product be so flakey? So unreliable. And my only answer ever seemed to be over complicated interfaces. Last time I I looked at ACPI tables, the information I could obtain that way looked rather spotty. I'm not certain I have ever gotten a good dump of the PnP BIOS information. As LinuxBIOS is rarely the first BIOS on a lot of boards the ability to dump that information and turn it into a form that LinuxBIOS can digest is very useful. > In the patch that I wrote to do ACPI-based enumeration, I map the PnP IDs > to something generic in the kernel, like "serial" or "pci" (host bus). For > whatever mechanism that you use to identify devices, you'll have to do > something similar. Agreed. > You may hate PnP IDs. But, using an existing mechanism would make some > things easier... ;) I'm pretty reasonable. I just dislike an over complicated inaccurate solution. Eric
