Patrick Mochel <[EMAIL PROTECTED]> writes: > > Don't use ACPI. The kernel can already support various types of firmwares > and tables, by default of supporting so many architectures. There is > nothing wrong with making up your own format and having a kernel driver to > support it. I believe that you guys have already done some work in this > area...
Right. The first steps. It's nice to see some support for this. I haven't been pushing in the kernel direction lately but the code is clean so it shouldn't be hard to revive. > 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. 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. > Jeff Garzik suggested I look in this direction, as you should already have > such a thing. Unfortunately, I haven't had much time.. Probably talking with me will be a little more productive in the short term as I'm still in the process of fleshing out the LinuxBIOS table. So you can't look at it and see everything, or read the docs. :) What we have right now. A table that lives just above address 0. It starts somewhere in the first 4k, and it has a magic id so you can scan for it. This is very important so we can avoid the legacy interrupt table, and bios paramter table. As there are parts of the x86 kernel that just assume those are there. Beyond that we have the LinuxBIOS version, build information, and the memory map. On the p4dpr I currently have a map that looks like: BIOS-provided physical RAM map: LinuxBIOS: 0000000000000000 - 0000000000000bf0 (reserved) LinuxBIOS: 0000000000000bf0 - 00000000000a0000 (usable) LinuxBIOS: 00000000000c0000 - 00000000000f0000 (usable) LinuxBIOS: 00000000000f0000 - 00000000000f0400 (reserved) LinuxBIOS: 00000000000f0400 - 00000000c0000000 (usable) LinuxBIOS: 0000000100000000 - 0000000140000000 (usable) The two reserved areas actually have a type that says this is a table in ram. But the kernel doesn't know about that yet so it calls them reserved :) In practice that is only useful if you are memtest86 and you want to know which reserved areas are safe to use. For the device tree I am busily working on it but here things get interesting. The kernel assumes all hardware is fairly standard, and if there is a weird case the BIOS will take care of it. In the BIOS for fairly obvious reasons we can't take that approach. So I have to build an interface that allows prepopulation of the device tree, and the ability to find drivers so I can find all of the BAR's on onboard devices. Providing the ability to work around hardware bugs in a modular way. 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. However it is not silly to say, hmm I have this perspective from which I am looking at these hardware devices. What is the path from me to them, for purpose X. The information for a BIOS should pretty much come from the configuration point of view, because that is what a BIOS has to do with the hardware run on cpu0 and assign non-conflicting resources to it all. 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. I'd be happy to work with people on this. Having a table where I can say this is LinuxBIOS's perspective on the world, and this is what I see. And being able to code and develop this at a different pace from the kernel helps to meet schedules. Eric
