Re[2]: i960RP - host downloading code

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

Text item: 

     Additional comments below::
     
     byron


______________________________ Reply Separator _________________________________
Subject: Re: i960RP - host downloading code
Author:  noam@genie.terra.co.il at SMTPGATE
Date:    8/7/96 4:35 PM


========================================================================= 
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:
>
>      Still I am confused -
>
>
>      see details below...
>
>      noam.
>
>
> ______________________________ Reply Separator ______________________________ 
___
> Subject: i960RP - host downloading code
> Author:  pci-sig-request@znyx.com at SMTPGATE 
> Date:    8/6/96 8:26 AM
>
>
> Hello everybody,
>
> This mail is specificly regurding the i960RP PCI bridge. If anyone has 
> an answer, it is welcomed.
>
> I am working on a PCI design based on the i960RP, and
> I intend to control the device from a PCI host. The fact that the core 
> proccesor code can be downloaded from the host implies that it is
> possible to access the local bus while keeping the core proccesor in
> reset state. However, there are several difficulties and contradictions 
> in the user manual that are not clear to me:
>
> 1) PMCON is not accessible through ATU, (This I conclude from the fact 
> that it is not a PMMR - Peripheral Memory Mapped Register). Thus, it
> cannot be controlled by a PCI host. If we add the fact that the PMCON
> is configured to 8 bit width by power up defualt, it certainly looks like 
> a problem to me.
>
> >>
> >> The PMCON is not accessible via the ATU.  It is a i960 JX Internal 
> >> MMR.  However, it is not a problem.  The PMCON does default to an 
> >> 8-bit region, however, the first thing the 960 does after reset is
> >> de-asserted is read the initialization-boot-record (IBR).  This record 
> >> contains a PMCON (accessible via a 32-bit bus or 8-bit bus) and is
> >> used to configure the Jx Bus Controller for the remainder of the
> >> accesses in the address region without any bus width problems.  The 
> >> reason it does not matter the what the bus width is when accessing
> >> the IBR is because of the addressing used.  It always accesses the low 
> >> byte of a word.  The data is present on the correct byte lanes
> >> regardless of 8-bit or 32-bit memory. 
> >>
>
> >> >> If the IBR is read after reset is de-asserted, then how
> >> >> does the host perfome code loading to 32 bit ram prior to 
> >> >> de-asserted reset? This is not possible if the memory
> >> >> controller is accesing an 8 bit area (as the PMCON 
> >> >> default)...

::
:: 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.
::
>
>
> 2) The ATU limit register and translate register are read only registers, 
> so I don't understand how do I control them.
>
> >>
> >> Yes they are read only ...VIA PCI Configuration Cyles.  If 
> >> you do inbound address translation (ie. memory read or
> >> memory write cycles based on the default translation mechanism
> >> you will accesses the MMR's and have full READ/WRITE capabilities 
> >> as the JX core.
> >>
>
> >> >> a) Still It is a problem: if the limit register defualt is set 
> >> >>    to 4k , then the BIOS power-up routines will initiate the
> >> >>    BAR of the varios devices accordingly. If the driver needs 
> >> >>    more then 4k, it must change the limit register, but this
> >> >>    can be done after the BIOS power-up sequnce, so there is not 
> >> >>    much that can be done, unless I am not missing something... 
> >> >>
> >> >> b) In page 16-5 in the user manual, it is said that the first 4k 
> >> >>    of the translation window is directed to the messaging unit.
> >> >>    If this is so, and if the limit register default is set to 4k, 
> >> >>    how can the MMR's be accessed, based on the default translation 
> >> >>    mechanism ?
> >> >>
::
:: 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.  
::
:: As for the 4K inbound ATU window, you are correct.  The first 4k hits
:: the MU window.  Within this window, the first 20 PCI DWORD addresses
:: are used for Doorbell, Message, APIC, Interrupt status, registers.
:: These first block of registers cannot translate to the RP PMMR address
:: space.  However, the Index registers do translate to the PMMRs.  Therefore
:: you can access the RP PMMR's except the PMMRs from address 0x1000 - 0x104f
:: (Bridge configuration registers).  BUT....the bridge configuration registers
:: in the PMMR range 0x1000-0x104f are accessible via Function 0, pci 
:: configuration cycles.
::
::


     
     
> 3) The PMMR are mapped to low local memory addresses, while the physical 
> memory should be mapped to high local memory addresses. This means
> that every time PCI host needs to access a PMMR (for example, the DMA 
> controller registers) and then the physical memory (in order to build 
> the DMA chain buffers), it must switch the ATU translate register.
> If this is correct, it could be a serious problem in a multitasking 
> operating system.
>
> >>
> >> The DMA Control registers are intended to be controlled by the 
> >> JX core executing software.  Not by a PCI master.  That is why 
> >> it is difficult.
> >>
>
>
>
> 4) Can I get a source code example of a host downloading code? Maybe 
> this would help me understand some of the problems, along with
> specific answers to the above questions. 
>
> >>
> >> I will check and see if we have something available. 
> >>
>
>
> 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.960807160258.6098C-100000@genie.terra.co.il>
In-Reply-To: <Tue, 06 Aug 96 19:23:04 PDT_3@ccm.hf.intel.com>
Subject: Re: i960RP - host downloading code
cc: pci-sig@znyx.com
To: Byron R Gillespie <Byron_R_Gillespie@ccm.ch.intel.com>
X-Sender: noam@genie.terra.co.il
From: Noam Efrati <noam@genie.terra.co.il>
Date: Wed, 7 Aug 1996 16:35:56 +0300 (IDT)
Received: (from noam@localhost) by genie.terra.co.il (8.6.12/8.6.12) id NAA10458
; Wed, 7 Aug 1996 13:35:56 GMT
Received: from genie.terra.co.il (genie.terra.co.il [194.90.101.34]) by ormail.i
ntel.com (8.7.4/8.7.3) with SMTP id GAA27724 for <Byron_R_Gillespie@ccm.ch.intel
.com>; Wed, 7 Aug 1996 06:37:23 -0700 (PDT)
Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by relay.jf.i
ntel.com (8.7.4/8.7.3) with ESMTP id GAA12080 for <Byron_R_Gillespie@ccm.ch.inte
l.com>; Wed, 7 Aug 1996 06:37:25 -0700 (PDT)
Return-Path: noam@genie.terra.co.il
ýøå