Dialogic BLT ISA vs. Intel 845, AWARD BIOS, W2K

From: Frantisek Rysanek (Frantisek.Rysanek_at_post.cz)
Date: 02/02/04 

Date: Mon, 2 Feb 2004 10:25:21 +0000 (UTC)

Dear fellow usenetters,

I'm looking for opinions and perhaps help with a particular
PC-based hardware/OS setup of voice call processing gear.
I suspect a resource conflict or ISA MMIO misconfiguration
of some kind. Read on for details if still interested.

I work for a PC hardware reseller. One of our customers,
a systems integrator focusing on call center solutions,
is trying to upgrade the processor board in an older
call processing PC. The PC has been in production use
for some time now. The voice/call processing hardware
by Dialogic was not delivered by us (none of our business).

The current setup of the PC machine consists of an ISA/PCI
backplane and an Intel440BX-based processor board, with
three Dialogic ISA boards (the BLT variety):
D/600SC-2E1 ... 2 pcs
MSI/240SC-GLOBAL ... 1 piece
All of that in a rugged 19" chassis with enough power
supply capacity, ventilation etc.
This setup works fine.

The customer tried to replace the original i440BX(PIII)
processor board by a newer i845GL(P4) processor board.
This way the voice subsystem doesn't work.
The Dialogic boards are detected just fine - the driver
loads, the Dialogic Configuration Manager shows the boards,
IRQ and shared memory is allocated, but the system test
suite fails halfway through. These are the steps taken
by the customer:

1) operating system backup
2) processor boards swapped
3) power up, drivers installed (graphics,..), several restarts
4) checked if devices were OK
5) DCM, autodetection => the familiard old boards detected OK
6) boards started up (via DCM)
7) visual check of the Dialogic boards' status - looked OK at first,
   after approx. 30 seconds they turned off
8) last step repeated several times, including a reset
9) ran the universal boards detection
10) boards detected successfully
11) proceeded with the detection - a test of functionality
    and communication followed
12) a Blue Screen of Death about when testing an EEPROM
    on an E1 port

Again, the operating system used is Windows 2000.

The PC being upgraded is currently in service, the first
(failed) upgrade attempt was made by the customer alone
during an overnight maintenance window. Before we attempt
it again, this time with my assistance, we have to schedule
another overnight maintenance session - therefore I'd like
to get as much information ahead of the act.
Please excuse my trying to ask ridiculous questions even
before I've tried the simple and obvious tweaks and
without having complete information at hand (e.g., a screenshot
of resource allocation in the W2K on the broken setup).
Another obvious objection is that we didn't even install
the PC OS from scratch on the new processor board - right,
we didn't and we know that theoretically it might be a problem.

I could only get a listing of HW resource allocation from
the workable setup. It shows that the Dialogic driver
occupies IRQ 5 and an IO memory segment of 0xD8000-0xDFFFF
(32kB).
Now on another machine that I installed from scratch
(without any Dialogic hardware), based on the same i845
processor board, in the HW resource allocation table
I could see that the memory segment between 0xC0000 and
0xDFFFF was allocated to "the PCI bus", whatever that
exactly means. Also, without the Intel chipset drivers
installed, the USB2.0 root hub remained uninstalled
(with a yellow question mark), occupying IRQ 5.
Once I installed Intel chipset drivers and the USB2.0
update from Microsoft (as part of an SP4 for W2K),
Windows started to use the local APIC in the i845 north
bridge and the USB2.0 root hub was re-routed to IRQ 23
or something like that.

The customer has only mentioned installing drivers for
Intel Graphics. Thus, I can already fancy several glitches.
There could be
1) an IRQ conflict (the customer didn't attempt to reserve
   IRQ5 to "legacy ISA" in the BIOS SETUP, which can be done)
2) an MMIO memory conflict - the original Dialogic range
   of 0xD8000 through 0xDFFFF falls within the respective
   PCI range on the i845 (0xC0000 through 0xDFFFF).

Then again, the boards were re-detected / moved to free
resources. There are several free IRQ's and at least two 32kB
memory windows (based at 0xE0000 and 0xE8000) that could be
utilized by the Dialogic BLT ISA bus interfaces.

If indeed there's no classic resource conflict, it could also
be a more subtle issue. There are two issues that I know of
from the Dialogic knowledge base: caching and shadowing.
Both has to be turned OFF on the 32kB memory window reserved
for the shared IOmem - leaving them on can result in
unpredictable misbehavior.

Now that might be a problem. The BIOS accompanying the i845GL
(AWARD 6.00 PG) doesn't mention shadowing and it only has
two items with respect to caching of particular memory areas:
the "video bios cacheable" and the "system bios cacheable".
I would not consider leaving the L1/L2 cache off entirely
for production use - the gap between the internal CPU clock
and the memory bus clock is nowadays way too high.

So the BIOS SETUP doesn't allow me to explicitly disable
caching and shadowing of a custom memory area.
The documentation of some AWARD BIOSes of this age (that don't
have a single shadowing option either) says that "caching is
much faster than shadowing" - does that mean that shadowing
is not used anymore? I remember meeting it on some 486-class
machines.
Could the "system BIOS cacheable" option really toggle caching
on all of the ISA memory ranges potentially useful for any ISA
onboard expansion ROM's etc? Come to think of it, the Dialogic
shared memory doesn't contain a BIOS and hence doesn't have
a standard "POST hookup header" or whatever it is that allows
the SCSI/Ethernet/VGA BIOSes to self-register at boot...

I remember rumors from the past, saying that BIOS SETUPs have
"hidden options" - variables in the CMOS/NVRAM or PnP
configuration space that aren't displayed in the BIOS SETUP
interface but can be changed in other ways. I remember utils
called amisetup.exe or icu.exe. I've seen DOS utils claiming
ability to mangle configuration of the HMA, also affecting
shadowing/cacheability as a side effect.
Alas, we're speaking Windows 2000 - with bullet-proof memory
protection, no config.sys to tweak and fool-proof PnP handling.

In other words, is there any chance of working out some dirty
tricks along those lines? A DOS-based setup util revealing the
"hidden" BIOS options, an undocumented keyboard shortcut doing
the same directly in the BIOS SETUP screen (yes I've read
reports of that, too), some kind of a dedicated util or W2k
tweak focused on shadowing and caching?

In terms of ISA hardware resources configuration (IRQ,DMA,ports,
memory), the Dialogic BLT ISA boards are jumperless and there's
no DOS-based software utility to achieve analogous jumper-like
hard-wired settings via an onboard NVRAM/EEPROM. The boards use
an auto-configuration mechanism controlled by software running
in the host operating system (W2k in this case). This auto-config
mechanism is NOT based on the standard ISA PnP.
When the Dialogic Configuration Manager is loaded (with the
Dialogic driver already present in kernel space), it detects
the ISA boards present, queries the Windows kernel for free bus
resources (IRQ, memory segments), selects convenient free
resources, sets them to the ISA boards and also stores them on
the host PC for later reference (to be able to detect changes).

Once configured and in operation, the BLT ISA boards use a combination
of an ISA IRQ and an ISA memory-mapped I/O region. Multiple boards
of the same kind share both the IRQ _and_ the 32kB memory block
(8k with the MSI series). Up to 16 boards in the system can share
these resources.
The auto-config mechanism (the Board Locator Technology +
the Dialogic Configuration Manager) can select from virtually
all ISA IRQ's that can ever become free and from a wide range
of MMIO base addresses (0x80000 through 0xEFFFF at any 32k
boundary).

In other words, the BLT ISA by Dialogic is a fairly peculiar
creation. This is the only ISA hardware that I know of that
uses a combination of IRQ and MMIO _only_, moreover shared
among multiple boards. For the matter, it's one of the very
few families of hardware known to me that use ISA MMIO in
RAM mode, for input _and_ output. Most memory-mapped regions
on the ISA bus are BIOS ROM's of the expansion boards.
Most ISA hardware that I know of uses a combination of port
IO + IRQ and maybe DMA - resources are unique per board.
No wonder that the Dialogic ISA MMIO doesn't mix with caching
and shadowing, that are only seamless with general memory
and ROM respectively.
As an interesting side-effect of the global resource sharing,
the Windows "device manager" doesn't show the individual
Dialogic ISA boards. In fact, it doesn't even show a single
"Dialogic device" entity - only the resource allocation table
ordered by resource type shows the occupied items, referring
to a "Dialogic SRAM driver".

The BLT ISA auto-config mechanism suggests an interesting
"chicken-and-egg" mystery. If the resources are allocated
at runtime, after some custom configuration software is run,
then how are the individual boards ever identified and
configured? How can the Dialogic Configuration Manager
(or the respective stub in the kernel-mode driver) talk
to the boards before some available resources are selected
and set to the boards?
There is no out-of-band communication channel beyond the
ISA bus (RS232, I2C or some such).
Do the boards in fact occupy an unpublished "well-known"
port? Or a tiny memory range? Does Dialogic rely on
an obscure resource being unused, without ever claiming it?
Or do the boards initially wake up at some default resources,
with the Dialogic driver hacking the Windows resource
allocation temporarily to talk to them for the first time?

Historically, the Dialogic BLT ISA (BLT = Board Locator Technology)
is one of the three Dialogic ISA flavours - the other flavours
being jumper-configured and "ISA Antares" (employing
software-configurable MMIO/PIO).

The above information related to Dialogic hardware is collected
from the rich documentation publically available at the
Intel/Dialogic web site.
It would be sad if all the wonderful and venerable technology made
by Intel and Dialogic didn't work together, now that it's manufactured
by a single company.

To sum up, if anyone has any hints as to what could go
wrong with the PC hardware or how to tweak the shadowing
/ caching in a modern foolproof PC BIOS, please let me
know.
And, thanks for your time if you've read this far :-)

Frank Rysanek

Relevant Pages

  • Re: Hey Jim! Need to find an article on "isaserver.org" but can find it
    ... published resource through ISA with the resource on the ... Internet by creating Packet Filters but those streams ... through the WAN address can't be received by LAN Hosts. ... same side of ISA ...
    (microsoft.public.isa)
  • Re: ISA on a File Server?
    ... resource consumer, so I your case if you'd like to go weith your setup, I'd ... this you might want to consider large ammounts of memory - faster/more ... I'm not going to go towards your setup with PIX and ISA because I've been ... >>> Is there any reason I can't put ISA on a file server? ...
    (microsoft.public.isa)
  • Re: Client Address Sets (for remote dynamically addressed clients)
    ... control access throught Remote Access Polcies which would provide more ... >> allow remote clients to access a local resource. ... > Control it at the actual resource itself,...not at ISA. ...
    (microsoft.public.isa)
  • Re: SBS 2003 and ISA
    ... Speaking as a newbie, there is no really "newbie" resource I've found on how ... my surprise it went fairly well, having not done this sort of migration ... My main concern is the use of ISA, I've never configured an ISA server ...
    (microsoft.public.windows.server.sbs)
  • Re: HP Web JetAdmin and SBS2K3
    ... I'd try turning off IE's proxy settings when trying to access a local ... resource. ... At worst this will prove it's not an ISA issue, ...
    (microsoft.public.windows.server.sbs)
Loading