On Fri, Nov 21, 2008 at 08:09:20AM -0700, Grant Likely wrote:
> Juergen, I haven't seen this behaviour. Have you asked you Freescale FAE?
>
> Hey John, have you ever seen this sort of issue?
To keep you updated: It was the PHY which would drive the lines high if
the reset signal was "too long"
Hi Andre,
On Freitag, 21. November 2008, Andre Schwarz wrote:
> Have a look at the manual chapter 4 (=Reset + Config).
> SRESET (issued by gpt0 - watchdog) isn't supposed to do a full hardware
> reset.
> Looks like you should make use of the SRESET and trigger HRESET
> accordingly.
>
> I could sol
Jürgen,
Have a look at the manual chapter 4 (=Reset + Config).
SRESET (issued by gpt0 - watchdog) isn't supposed to do a full hardware
reset.
Looks like you should make use of the SRESET and trigger HRESET accordingly.
I could solve this with _not_ using the internal watchdog but an
external on
Hi Grant,
On Freitag, 21. November 2008, Grant Likely wrote:
> Juergen, I haven't seen this behaviour. Have you asked you Freescale FAE?
Yes. But no answer yet. Thats why I ask here.
Regards,
Juergen
--
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
Pengutronix - Linux Solutions for
Juergen, I haven't seen this behaviour. Have you asked you Freescale FAE?
Hey John, have you ever seen this sort of issue?
g.
On Fri, Nov 21, 2008 at 5:36 AM, Juergen Beisert <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> we have trouble with the eth based config pins (ETH0...ETH6) of the MPC5200B
>
Hi all,
we have trouble with the eth based config pins (ETH0...ETH6) of the MPC5200B
CPU. These pins act as the interface to an external phy and also act as
configurations pins to configure the size of the flash and other things.
While the reset is active these pins should be in their high impe
6 matches
Mail list logo
