Hello again from Gregg C Levine Greg, I am almost always up late. I looked over Ron's dissertation, and it looks to be a doozy. I'm not being crude, or insulting, just that it looks to be the one method for implementing Linux BIOS that should work, with almost any board we choose. Regretfully I have not selected a port, or a board design, because I have not been able to select one board that will work.
Ideally, I, should be able to be working with one, by sometime this coming September. However, I am openminded enough to understand that things change. Both of you have good ideas. ------------------- Gregg C Levine [EMAIL PROTECTED] ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke."� Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda ) > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:linuxbios- > [EMAIL PROTECTED] On Behalf Of Greg Watson > Sent: Wednesday, July 23, 2003 12:48 AM > To: ron minnich > Cc: [EMAIL PROTECTED] > Subject: Re: static and dynamic devices (again) > > Thanks Ron, post this tome at 10pm so I have to stay up late... > > As Ron points out, I spent some time today seeing if it was possible > to unify the static and dynamic device code. It certainly is > possible, but it turns out that we're trying to do things in two > fundamentally different ways. The result is that we just push the > separation between the two types of devices down another level. I'm > not sure is something that we want to do, because it just makes > things more difficult to understand. > > My feeling is that keeping them separate is probably the way to go. > Modifying the current device code so that dynamic trees can hang off > a static device (such as a northbridge) will solve some problems that > are on the horizon. This will also allow code development to move > forward without major changes, but not preclude unifying the two > schemes in the future if it becomes necessary. > > I'm also interested in any comments on this approach. > > Greg > > At 10:08 PM -0600 22/7/03, ron minnich wrote: > >Greg has spent the day exploring options for how to merge the static and > >dynamic device trees in LinuxBIOS, per Eric's comments. He wrote a > >substantial amount of code, which at this point we may not commit. The > >goal of the code was to see if it makes sense to merge the static and > >dynamic trees. I am not convinced such a merger makes sense. > > > >Discussion follows. > > > >The problem is this: on a given motherboard, there are a static set of > >devices, such as northbridges, southbridges, so on: these are soldered to > >the board. Then there are dynamic devices, plugged into PCI slots. > > > >On a motherboard, we know that the static devices are there, and we even > >know a lot about them, such as what certain registers do. We need on > >the motherboard to initialize components of the static devices. In other > >words, we have knowledge about: > >o the type of the device; > >o instances ofthe device; > >o special operations we need to do to the device to modify internal > > state (e.g. turn off the IDE controller, turn on Ethernet, etc.) > >o special control information that is highly device-specific > > > >These operations are operations that we have to do because the OS assumes > >they will be finished when the OS starts, or we need to do them to > >initialize things, such as DRAM. > > > >Dynamic devices are known only in a generic fashion. In LinuxBIOS, the sum > >total of our knowledge of dynamic devices is the Base Address Register > >set, the Command register, and possibly (in future) the IRQ. LinuxBIOS has > >no knowledge of device-specific I/O registers. For dynamic devices, > >LinuxBIOS does a few generic operations and lets the OS do the rest. > > > >So for dynamic devics we know about: > >o instances of the device > >o Generic control information that is not device-specific > > > >So, to sum up: for static devices, LinuxBIOS needs knowledge that goes > >beyond what the OS knows, and will perform device-specific operations > >based on internal knowledge LinuxBIOS has about the device. LinuxBIOS will > >maintain information about the type of the device and all instances of the > >device. In many cases, LinuxBIOS will do operations on the device that the > >OS is not capable of doing. > > > >For dynamic devices, LinuxBIOS only does the most general configuration, > >and has no knowledge of device internals. The OS manages device-specific > >operations. > > > >The dichotomy is pretty clear. > > > >It is kind of like a house. There are walls and floors and outlets and > >phone jacks. These are fixed (static). Then there are chairs and lights > >and phones. These are dynamic. You know all about the phone jacks, but you > >don't know about what phones are plugged in, and the phones change all the > >time, especially if you have children in the house. The static devices > >(walls) are a fundamentally different thing than the dynamic devices > >(chairs). > > > >We are calling static devices 'chips'. Chips are structured as follows: > >there is a chip_control structure for a TYPE of a chip, with generic > >information about the chip and a pointer to a control function that is > >specific to that chip. Then, for each instance of the chip, there is a > >chip structure that contains a pointer to the chip_control structure and > >information specific to the INSTANCE of the chip. > > > >Think of chip_info as the class definition, and chip as instantiations of > >the chip. > > > >Chips are statically declared and initialized, and form a tree with a root > >at the mainboard, with sibling pointers for chips at the same level -- > >e.g., two devices hung off the same southbridge are siblings. These > >structures are filled out at compile time. > > > >Dynamic devices are called struct device. There is (currently) a device > >struct allocated dynamically for each function on a device. > > > >[digression: The PCI heritage of devices is very clear once you start > >looking at them. This is reasonable, as even on HyperTransport everything > >looks like a PCI device. But it may bite us at some point.] > > > >Devices also form a tree, with children, parents, siblings, etc. One > >assumption we've noticed in the device code is that of a 'root bus'. > >Properly, this should not really exist: there can be multiple northbridges > >in a system, each with a PCI bus. But the device code so far inherits from > >freebios 1.0 the PC assumption that there is one root bus, and that it is > >configured from a common point of control -- on PCs, the 0xcf8/0xcfc > >mechanism. > > > >Our early assumption was that we could take the static tree, build a > >dynamic tree, and then populate the tree with dynamic devices. Eric would > >like to see this happen. Greg and I are no longer convinced this makes > >sense. Hence the source of this discussion. > > > >At minimum, if you build a dynamic tree from the static tree, you'll have > >to mark the devices as static. You'll have to handle them differently > >because the resources work differently. Some resources such as Base > >Address Registers won't exist on devices in the static tree. You'll have > >to note that some devices are capable of having device-specific code, and > >others are not. You'll end up with structure that really contains two > >structures inside: structure members for static devices only, and > >structure members for dynamic devices only. It won't be a happy marriage. > >Finally, all your code will have to handle two cases: static and dynamic > >devices. Once we looked at this, we saw that we ended up with a dynamic > >tree with static devices grafted in, with no apparent savings on > >complexity and no real code reuse. > > > >Here is what we think makes sense. The dichotomy between static and > >dynamic devices should remain. The static devices will not be converted > >into some form of dynamic device. There will need to be a linkage from the > >static devices to dynamic devices. This linkage will be at the northbridge > >-- as it is in hardware. > > > >Northbridges, i.e. devices which have an attached PCI bus (or more than > >one), will have a device structure pointer in the device-specific data > >structure (i.e. in the chip structure). At some point, as part of the code > >that walks the statically allocated northbridge, pci enumeration for that > >northbridge takes place. This has a major advantage for non-PC platforms > >(such as PPC) that don't use the standard PC 0xfcf8/0xcfc mechanism for > >configuring the PCI bus -- it makes sense to talk to the northbridge > >device directly to configure the bus(ses) on that northbridge. It is also > >a big win for systems with more than one northbridge -- these will be more > >and more common. And for switched, not bus-based, systems the advantage is > >apparent. > > > >We thus have a static tree (representing the static resources) with links > >at certain places to the dynamic tree (representing dynamic resources). > >LinuxBIOS can do device-specific operations on devices in the static tree, > >and can attach dynamic devices to nodes in the static tree. On the > >whiteboard in Greg's office, this setup makes lots of sense. We'll see how > >it is in practice. > > > >We plan to prototype this in the coming few days and try it out. > > > >Comments and questions are welcome. We need to open this discussion up. I > >would really like to hear from you folks. As Eric pointed out, we're > >trying to define the 2.0 core functionality, and we want to make it a good > >structure but also one that is easy for people to do new ports. It is > >essential to hear from those of you who are doing ports -- there are lots > >of you on this list. > > > >thanks > > > >ron > > > >_______________________________________________ > >Linuxbios mailing list > >[EMAIL PROTECTED] > >http://www.clustermatic.org/mailman/listinfo/linuxbios > > _______________________________________________ > Linuxbios mailing list > [EMAIL PROTECTED] > http://www.clustermatic.org/mailman/listinfo/linuxbios _______________________________________________ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
