[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: PC164 SRM problem



On Wed, 17 Oct 2001, Ivan Kokshaysky wrote:

> And what if one of these resources is critical for console operation, and
> other isn't, how can you determine which one to reassign?

 If one of the resources is critical then it already got initialized. 
That is it does not conflict (overlap) with any other or the system
wouldn't function (couldn't use the device).  Thus it need not be
changed.  If certain resources conflict with one another (likely due to
power-on defaults) they are all unusable and may certainly be
reinitialized anyhow. 

> Besides, i386 code can't handle uninitialized PCI-PCI bridges. At all.
> I believe the main reason why i386 port doesn't use "setup PCI yourself"
> approach is that there are lots and lots of various x86 host-to-pci bridges,
> and very few of them are documented.

 Actually classic PCI-PCI bridges (e.g. DEC's 21x5x) are very rare in i386
systems, although it might be worth checking how often they get properly
initialized by firmware (I don't have a card with a bridge to test,
unfortunately).

 More frequent are peer host bridges, such as the one included in the
i450KX/GX chipset or all AGP chipsets.  Most if not all Intel chipsets are
documented sufficiently, others might not.  But there is usually no need
to configure them -- they are not standard PCI devices with explicit
resources.  They usually hardwire the address range they decode to devices
that are directly attached to them (mainly the host's memory).

 Other devices need resource allocation as usual and that happens either
directly using PCI configuration space accesses or via firmware calls,
which also use configuration accesses but may be needed if a host bridge
is not documented sufficiently enough.  It's even quite likely to see PCI
devices left completely uninitialized by i386 firmware due to the infamous
PnP standard.

 In short the absence of handling of PCI-PCI bridges for i386 systems is
likely due to the lack of interest.

> >  But it doesn't work well, either.  If you get dumped back to SRM due to
> > an exception, the whole configuration remains messed up.
> 
> Good point. That was one of the reasons why I thought that save/restore
> code isn't very useful. However, most likely such an exception would mean
> that something is screwed up anyway...

 Of course, and you may wish to do additional diagnostics within SRM
before you reset the system losing the ability to recover system's state
at the time of the fault completely.  Or you may want the system to reboot
automatically (I'm not sure it was possible to be set up, though). 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []