Re[4]: i960RP - host downloading code

[Byron R Gillespie <Byron_R_Gillespie@ccm.ch.intel.com>]

Text item: 

     I will try to clarify the download.
     
     see below==
     
     byron


______________________________ Reply Separator _________________________________
Subject: Re[3]: i960RP - host downloading code
Author:  noam@genie.terra.co.il at SMTPGATE
Date:    8/8/96 11:36 AM


>
> Text item:
>
>      First I wish to thank all the people for thier 
>      answers, some of them were helpfull.
>
>      I think my questions were not fully understood, 
>
>      so I will try to make the point. 
>
>      see details below...
>
>      noam.
>
>
> ______________________________ Reply Separator ______________________________
     
     
     
     
1)
     
::
:: The RP has a special powerup mode that keeps JUST THE 
:: CORE in reset.  This allows a host to download the code 
:: to the RP memory, then release the CORE from reset by 
:: clearing a bit in the Extended Bridge Configuration
:: Register.  This ensures the memory is Pre-loaded before 
:: the RP starts to fetch the IBR.
::
>  I understand this powerup mode (mode 0 in page 11-5). The proccess 
>  seems to be quite clear. The point I don't understrand is this:
>  If the memory is configured to 8 bit (this comes from the fact that 
>  the PMCON is set to 8 bit width on power up, and can't be changed
>  as long as the CORE is held in reset), how can the host transfer 
>  the code data to the 32 bit width memory ?
>                       ------------ 
>
>
== The way the PMCON works from the core is....after reset is de-asserted
== the core does four byte reads from the IBR.  The core assumes an 
== 8-bit region when doing the reads.  The addresses used for these
== four reads is 0xfeff.ff30, 0xfeff.ff34, 0xfeff.ff38, and 0xfeff.ff3c.
== Because of the addresses used, the byte lanes the core expects to see
== the data appear on is the low byte lane (AD[7:0]).  If you look closely
== at the addresses, it doesn't matter if 32-bit or 8-bit memory is connected
== to the memory controller.  The data will always appear on the correct 
== byte lanes.  
==
== These first four reads from the IBR contain the control bits to initialize
== the pmcon region 14_15.  All remaining accesses within this region will use
== the bus width setting found in the IBR (as specified by these first four
== reads).  In other words the core can be changed to operation in 32-bit
== bus mode for all the core accesses after reading the first four IBR values.
==
== Now as for the downloading of code. The inbound ATU accesses to memory
== from the PCI bus always perform 32-bit with accesses with one exception, 
== this is the Expansion ROM address range from the PCI bus. The EROM window
== has a bit specifing 8-bit or 32-bit access.  You should NOT be using the 
== EROM window for downloading code.  You should be using the normal memory
== window.  The sequence of events (summarized):
==
== 1) powerup RP, set strap to hold core in reset
== 2) by using inbound memory window, initialize the MCU
== 3) by using inbound memory window, widen the inbound ATU window
==    (i.e.  change the primary inbound ATU limit Register)
==    This is where you need to have control of the PCI initialization.
==    When you widen the window, you need to ensure the larger window
==    does not overlap someone else's PCI address space.  (two pci devices
==    attempting to claim the same address space).
== 4) push the 960 code into the memory
== 5) clear the core-processor-reset-bit in the
==    extended-bridge-configuration-register.
== 
== 
     
2)
     
::
:: You are correct for add-in cards. It is very difficult to implement 
:: downloadable software unless you have control of the configuration 
:: software.  The RP a direct connect memory controller interface to
:: add a small boot FLASH device.  I would recommend this implementation 
:: for add-in card type of applications who do NOT have control of the 
:: Host configuration software.
::
::
>  Let me see if I understand. You are actualy saying that if my device 
>  driver cannot control the configuration software, I can't change the 
>  window size to more than 4k ?
>  If this is the case, then the i960RP will give very poor performance... 
> 
                                                ---------------------
== Unless you have control of the configuration software, you will need to
== go out and look at all of the devices on the PCI bus, create an address 
== map and make sure that when you widen the window, that you don't 
== overlap address spaces amongst the pci devices.
==
== Again I must recommend for add-in cards, using a small boot ROM.  The
== Boot ROM would have just enough code to initialize the inbound limit
== registers with the correct amount of memory to request when the 
== initialization software configures the PCI devices.
==
== Also note, NT does re-configure PCI devices after any bios may have 
== initially set up the address ranges. Therefore, add-in cards should
== use a small boot rom.
==
>
> Thanks in advance,
>
> ========================================================================= 
> Noam Efrati                    | e-mail: noam@terra.co.il
> Terra computers ltd.           | phone : 972-7-467502 
> 6 Ashuach st., Omer,           | fax   : 972-7-467475 
> 84965 Israel                   |
> =========================================================================

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Content-Type: TEXT/PLAIN; charset=US-ASCII
MIME-Version: 1.0
Message-ID: <Pine.SGI.3.91.960808110649.6098D-100000@genie.terra.co.il>
Subject: Re[3]: i960RP - host downloading code
cc: pci-sig@znyx.com
To: Byron_R_Gillespie@ccm.ch.intel.com
X-Sender: noam@genie.terra.co.il
From: Noam Efrati <noam@genie.terra.co.il>
Date: Thu, 8 Aug 1996 11:36:28 +0300 (IDT)
Received: (from noam@localhost) by genie.terra.co.il (8.6.12/8.6.12) id IAA12070
; Thu, 8 Aug 1996 08:36:28 GMT
Received: from genie.terra.co.il by aurora.intel.com (8.7.4/10.0i); Thu, 8 Aug 1
996 08:40:27 GMT
Received: from aurora.intel.com (aurora.intel.com [143.183.152.2]) by relay.jf.i
ntel.com (8.7.4/8.7.3) with ESMTP id CAA04728 for <Byron_R_Gillespie@ccm.ch.inte
l.com>; Thu, 8 Aug 1996 02:41:50 -0700 (PDT)
Return-Path: noam@genie.terra.co.il

˜…