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
next prev parent 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).