static and dynamic devices (again)

[Gregg C Levine]

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 hansolofalcon at worldnet.att.net
------------------------------------------------------------
"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: linuxbios-admin at clustermatic.org [mailto:linuxbios-
> admin at clustermatic.org] On Behalf Of Greg Watson
> Sent: Wednesday, July 23, 2003 12:48 AM
> To: ron minnich
> Cc: linuxbios at clustermatic.org
> 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
> >Linuxbios at clustermatic.org
> >http://www.clustermatic.org/mailman/listinfo/linuxbios
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios