Conference decwet::windows-nt

5865.0. "AS500 POST fail under ARC?" by QBUS::E_BURKHALTER () Wed Apr 02 1997 14:54

    
    Customer Fore Systems builds ATM machies.
    They design their PCI ATM Card that fits into the PCI bus.
    They run WNT 4.0.
    
    Their card works on AS255, AS600 ans AS2000 with no problems.
    
    When the card is installed in a AS500 and ARC is run at power up,
    the system will not run POST.
    If card is removed, sys boot fine.
    
    They just installed the latest ARC 4.49 from the WEB Site.
    
    Under SRM with the module installed, the system runs power up self test
    with no problems.
    
    Below is the problem description directly from the customer.
    
    ANY IDEAS?
    
    ********************************************************************
    
    The Problem:
    ============
    On a DEC Alphastation 500/500 running windows NT 3.51/4.0 put in a PCA
    200E
    ( the ATM) card. Reboot the machine.
    As soon as this is done the machine fails to boot up. It does not even
    load
    the firmware or show up with the initial boot menu. It acts as if the
    machine
    is dead.
    If the card is removed the machine boots up normally.
    This problem occurs with the DEC Alphastation 500/500 model only. The
    firmware on the machine is 4.49
    It works fine on all other DEC workstation models we have namely,
    Alphastation 600, alphastation 255, alphastation 400 and the
    alphaserver
    2000/400
    ----------------------------------------------------------------------
    The Cause of the above problem as described by hardware
    
    Synopsis:
    ==========
    >This problem appears to be either a BIOS problem or a problem
    >with the SCSI card.   Please check the detailed explanation
    >below. If you have questions, please contact me directly.
    >Otherwise, I will close the bug.  Do we have a good contact at
    >DEC?  It seems like they should have been able to trace this
    >one.
    >
    
    Detailed Explanation:
    ======================
    >   There are numerous odd occurrences which lead to the boot-time
    >failure of
    >the PCA-200E in the DEC Alphastation 500.  Here is a description of
    the
    >same.
    >
    >   First, the BIOS performs faulty write accesses to a SCSI
    controller.
    >During the part of the BIOS routine where the base address registers
    >should be
    >written with 0xFFFFFFFF to determine size, the BARs at 0x14-0x24 are
    >written
    >with values that are incorrect.
    >
    >   When the values in the BARs are read back, 0x14 and 0x18 return
    >0xFFFFFFFF
    >which is an illegal value.  If the space is supposed to be a memory
    >space, bit
    >0 should be a 0.  If the space is supposed to be an I/O space, bit 1
    >should be
    >a 0 (see PCI spec Rev 2.1 section 6.2.5.1).  In either case, all F's
    is
    >not
    >permitted.
    >
    >   The BIOS then assigns addresses to each of the memory regions.  The
    >PCA-200E's Expansion ROM space is assigned the region from 0x00110000
    to
    >0x00111FFF (8 KB).  The SCSI controller's memory BAR at 0x14 is loaded
    >with
    >0x00112000 (abutting the PCA-200E's region).
    >
    >   When the PCA-200E's Expansion ROM contents are read, the BIOS
    starts
    >at
    >0x00110000 and reads every location up to 0x00111FFF successfully.
    >However,
    >it also reads from 0x00112000 (is a counter incorrect?) and receives a
    >target
    >abort.
    >
    >   By looking at the timing of the DEVSEL# signal on a Expansion ROM
    >access to
    >the PCA-200E and the faulty access to 0x00112000, it was determined
    that
    >the
    >PCA-200E does not respond to the access.  On a PCA-200E access,
    DEVSEL#
    >goes
    >from low to high or high to low 8 ns after the clock edge.  On the
    >faulty
    >access, DEVSEL# goes from high to low or low to high 12 ns after the
    >clock
    >edge.
    >
    >   After the access to 0x00112000, there are no more memory
    transactions
    >on
    >the bus.  There are I/O accesses which alternate between reads from a
    >256 byte
    >range (it reads from 0x800 to 0x8FF and then starts over), and writes
    to
    >0xC00.  Because of the low range of these addresses, they are probably
    >some
    >sort of system accesses.
    >
    >   After cycling through these access a number of times, the machine
    >hangs.
    >
    
    
    Ed Burkhalter
    CSC Atlanta

    Ed --
    
    Can you get information about the exact configuration in this system?
    Some things of interest would be
    
    	does the custom ATM card use an AMCC PCI interface chip?
    
    	is there an AccelGraphics card driving the video?
    
    The AlphaStation 500 guys should be interested in knowing everything
    that's in the system.  You could try cross-posting in
    WRKSYS::ALPHASTATION500 (press KP7 now), where most of the hardware and
    firmware guys hang out.
    
    -- Kenny House

Ed,

I tried a FORE PCI ATM card on an AlphaStation 500/500 (Marveric/Bret) and the system booted fine. The ARC
firmware version on the machine is 4.52, running Windows NT 4.0 (build 1381), SP3 RC 1.78.  Could you try update
the firmware? The problem may be resolved.  The pointer is:
	
	http://www.windows.digital.com/support/Firmware/as5-600.asp

Phuc Dinh
DECwest 

An update on the IPMT case below.

Upon booting the Bret,  the firmware enters the x86 bios emulation to handle video cards.  One of the tasks is to
copy any expansion ROM images found into RAM as the PCI spec requires.  The Fore card in question has the ROM
address of 0x104000 (at PCI config offset 0x30) and a required length of (0x2000 found by writing 1's to PCI
config offset 0x30).  The signature of 0x55AA is verified at address 0x104000 so I know we are reading the ROM. 
But when we get the Initialization size (at 0x104002) like the spec says, it returns 0x40 (size of code in units
of 512 byes) giving us an Initialization size of 0x8000.  It is during the copy of these 0x8000 byes into RAM when
the system halts.  In fact, it halts at 0x106000, exactly 0x2000 byes after the base address, the same length of
the requested ROM size!!

Anaylsis:  The Fore card is either wrong in the ROM initialization size (0x40 * 512) or the required length
(0x2000).

                     <<< Note 5865.3 by DECWET::SERRANO >>>

An update on the IPMT case below.

Upon booting the Bret,  the firmware enters the x86 bios emulation to
handle video cards.  One of the tasks is to copy any expansion ROM images
found into RAM as the PCI spec requires.  The Fore card in question has the
ROM address of 0x104000 (at PCI config offset 0x30) and a required length
of (0x2000 found by writing 1's to PCI config offset 0x30).  The signature
of 0x55AA is verified at address 0x104000 so I know we are reading the ROM. 
But when we get the Initialization size (at 0x104002) like the spec says,
it returns 0x40 (size of code in units of 512 byes) giving us an
Initialization size of 0x8000.  It is during the copy of these 0x8000 byes
into RAM when the system halts.  In fact, it halts at 0x106000, exactly
0x2000 byes after the base address, the same length of the requested ROM
size!!

Anaylsis:  The Fore card is either wrong in the ROM initialization size
(0x40 * 512) or the required length (0x2000).

    Re .0 & .3, Ed and i talked a bit about this behavior...  There is a
    distinct possibility that the blasted ROM image contains the wrong data
    (incorrect image length of 0x40 * 512 = 0x8000 bytes).  Please ask the
    FORE engineers to verify that is not the case or they'll have to create
    a new ROM image.
    
    --svb