So, Can I draw the following conclusions from the discussions so far? 1. LinuxBios would like TODO something similar to ACPI for the configuration tables, but not exactly what ACPI does. This brings me to a question, what does a BIOS need todo in order to be called an ACPI BIOS? My feeling is create the tables and implement E820. I am yet to read the complete ACPI spec. The reason for not implementing ACPI is to keep the tables simple and maybe ACPI is over bloat or insufficient or simply unnecessary (I am speculating this).
2. The ACPI aware things in h/w like some of the devices on the LPC chip, can still be enabled by LinuxBios. 3. LinuxBios will come up with its own way of exporting devices to the OS, in a way Patrick just described. Did I miss something? Balbir | |> > 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.. | |> 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.. | |> 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. | |I would really stress trying to adhere to an accurate tree as |much as possible. The ones that tend to not conform are: | |- 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. | |- thermal sensors, fans, etc. |I'd say these are system devices as well, as they usually have |an intimate relationship with the system devices. | |> 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. | |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. | |How would bus IDs change for these devices? 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? 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. | |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. | |You may hate PnP IDs. But, using an existing mechanism would |make some things easier... ;) | | -pat |
**************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ***************************************************************************
