linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Andrey Volkov <avolkov@varma-el.com>
To: Sylvain Munaut <tnt@246tNt.com>, Wolfgang Denk <wd@denx.de>
Cc: linuxppc-embedded <linuxppc-embedded@ozlabs.org>
Subject: [RFC] MPC5200 Kernel/UBoot PCI problem
Date: Fri, 25 Mar 2005 15:32:34 +0300	[thread overview]
Message-ID: <424404E2.2030602@varma-el.com> (raw)
In-Reply-To: <42430DF0.2050304@varma-el.com>

Hi Sylvain, Wolfgang,

> 
>>
>> Try adding some delays in the pci configuration zone access routines 
>> in mpc52xx_pci.c  I remember someone needed those but still don't know 
>> why, the manual don't say anything about that.
> 
> Board started, after I add udelay(7) in read/write config. Really strange.

Sylvain, answer was in PCI2.2 specification, not in manual.

Wolfgang, as I see, you use same trick in u-boot, as Sylvain suggested 
to me. IMHO this trick is wrong. Below I explain why.

When I insert udelay(1000) after deassertion of RST# (write 0 to PR of 
PCIGSCR), AND remove ALL delays from read/write config, board started 
too ;). Hence problem not in the MPC, but in slow board(s) (re)start
(I was lucky with my board, because udelay must be 1000000).

Here some quotations from "PCI Local Bus Specification rev. 2.2":

 From table 4-6 Timing parameters:
					       |  Min	|Max| Unit
Trhfa| RST# High to First configuration access | 2**25	|   | clocks
Trhff| RST# High to First FRAME# assertion     |   5	|   | clocks

2**25 clocks = 1.016 sec for 33MHz and 0.508 sec for 66MHz PCI.

 From Chapter "4.3.2 Reset":

....
Some PCI devices must be prepared to respond as a target Trhff time 
after RST# deasserts. For example, devices in the path between the CPU 
and the boot ROM (not expansion ROM) must be prepared to respond as a 
target Trhff time after RST# deasserts.

All other devices must be prepared to respond as a target not more than 
Trhfa after the deassertion of RST#. It is recommended that the system 
wait at least Trhfa following the deassertion of RST# to a device before 
the first access to that device, unless the device is in the path 
between the CPU and the boot ROM or the system knows that the device is
ready sooner.

Software that accesses devices prior to the expiration of Trhfa must be 
prepared for the devices either not to respond at all (resulting in 
Master-Abort) or for the devices to respond with Retry until the 
expiration of Trhfa. At no time can a device return invalid data. 
Devices are exempt from the Maximum Retry Time specification and the 
target initial latency requirement until the expiration of Trhfa.
....

-- 
Regards
Andrey Volkov

  reply	other threads:[~2005-03-25 12:32 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-21 23:06 [PATCH 0/6] [RFC] Change MPC52xx to platform bus / ppc_sys model Sylvain Munaut
2005-03-21 23:07 ` [PATCH 1/6] ppc32: Remove unnecessary test in MPC52xx reset code Sylvain Munaut
2005-03-21 23:07 ` [PATCH 2/6] ppc32: Remove the OCP system from the Freescale MPC52xx support Sylvain Munaut
2005-03-21 23:08 ` [PATCH 3/6] ppc32: Change constants style in Freescale MPC52xx related code Sylvain Munaut
2005-03-21 23:08 ` [PATCH 4/6] ppc32: Add platform bus / ppc_sys model to Freescale MPC52xx Sylvain Munaut
2005-03-25 15:15   ` Kumar Gala
2005-03-21 23:09 ` [PATCH 5/6] serial: Update mpc52xx_uart.c to use platform bus Sylvain Munaut
2005-03-21 23:09 ` [PATCH 6/6] ppc32: Adds necessary cpu init to use USB on LITE5200 Platform Sylvain Munaut
2005-03-22  1:11 ` [PATCH 0/6] [RFC] Change MPC52xx to platform bus / ppc_sys model Kumar Gala
2005-03-22  7:12   ` Sylvain Munaut
2005-03-24  8:37     ` [RFC] MPC5200 PCI problem Andrey Volkov
2005-03-24 14:34       ` Sylvain Munaut
2005-03-24 18:58         ` Andrey Volkov
2005-03-25 12:32           ` Andrey Volkov [this message]
2005-03-25 13:02             ` [RFC] MPC5200 Kernel/UBoot " Dale Farnsworth
2005-03-25 14:00             ` Sylvain Munaut
2005-03-22  7:04 ` Future of OCP Lawrence E. Bakst
2005-03-22  7:48   ` Eugene Surovegin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=424404E2.2030602@varma-el.com \
    --to=avolkov@varma-el.com \
    --cc=linuxppc-embedded@ozlabs.org \
    --cc=tnt@246tNt.com \
    --cc=wd@denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).