All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <4926DA98.4060401@matrix-vision.de>

diff --git a/a/1.txt b/N1/1.txt
index c897d3d..e2c391f 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,12 +1,11 @@
-J=FCrgen,
+J?rgen,
 
-Have a look at the manual chapter 4 (=3DReset + Config).
-SRESET (issued by gpt0 - watchdog) isn't supposed to do a full hardware=20
+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 according=
-ly.
+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=20
+I could solve this with _not_ using the internal watchdog but an 
 external one (TPS3828),
 i.e. watchdog timeouts and reboots are always issued by PORESET.
 
@@ -19,44 +18,29 @@ Andre
 Juergen Beisert schrieb:
 > Hi all,
 >
-> we have trouble with the eth based config pins (ETH0...ETH6) of the MPC=
-5200B=20
-> CPU. These pins act as the interface to an external phy and also act as=
-=20
-> configurations pins to configure the size of the flash and other things=
-.=20
-> While the reset is active these pins should be in their high impedance =
-state=20
-> and the externally connected pull down resistors should define wire's v=
-oltage=20
-> level. With the rising edge of the reset signal these levels will be la=
-tched=20
+> 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 impedance state 
+> and the externally connected pull down resistors should define wire's voltage 
+> level. With the rising edge of the reset signal these levels will be latched 
 > into internal config registers.
-> We are in trouble when we want to reboot the system (also watchdog base=
-d) or=20
-> the internal watchdog barks and generates the CPU internal reset signal=
-. In=20
-> these cases these config pins will not change their level! So the wrong=
-=20
-> settings are latched in and our CPU is dead (misconfigured), sometimes =
-a=20
+> We are in trouble when we want to reboot the system (also watchdog based) or 
+> the internal watchdog barks and generates the CPU internal reset signal. In 
+> these cases these config pins will not change their level! So the wrong 
+> settings are latched in and our CPU is dead (misconfigured), sometimes a 
 > second reset helps, but most of the time only power cycling helps.
 >
 > What we see is:
 >  - at the pins ETH_0 and ETH_3 (both are output only, when used for
 >    ethernet)
 >
->  * With an external 10k pulldown these lines never change their 3.3V le=
-vel
+>  * With an external 10k pulldown these lines never change their 3.3V level
 >    even if the reset is active!
->  * With an external 1k pulldown these lines change their 3.3V level dow=
-n to
->    something about 2.5V when the falling edge of the reset signal occur=
-s.
->  * This level decreases slowly to 1.2V in about 1.2ms and than a fallin=
-g edge
->    to 0V occures. Problem here is, the internal watchdog's generated re=
-set
+>  * With an external 1k pulldown these lines change their 3.3V level down to
+>    something about 2.5V when the falling edge of the reset signal occurs.
+>  * This level decreases slowly to 1.2V in about 1.2ms and than a falling edge
+>    to 0V occures. Problem here is, the internal watchdog's generated reset
 >    signal is much shorter, so the rising edge of this reset signal also
 >    latches in the wrong settings and the CPU is dead.
 >
@@ -67,25 +51,20 @@ set
 >     -> system restarts
 >    We can see in this case, the ETH_0 and ETH_3 are switching to low
 >    level *immediatly* with the falling edge of the reset signal
->  - an activated interface ("ifconfig up") in Linux with *disconnected* =
-network
+>  - an activated interface ("ifconfig up") in Linux with *disconnected* network
 >     -> system is always dead
->  - an activated interface ("ifconfig up") in Linux with *connected* net=
-work
+>  - an activated interface ("ifconfig up") in Linux with *connected* network
 >     -> system is always dead
 >
-> Does anybody see a behaviour like ours on his/her MPC5200B based system=
-?
-> Does anybody have an idea what the difference between U-Boot und Linux =
-could=20
+> Does anybody see a behaviour like ours on his/her MPC5200B based system?
+> Does anybody have an idea what the difference between U-Boot und Linux could 
 > be? Bug? Feature?
 >
 > Regards,
 > Juergen
 >
->  =20
+>   
 
 
-MATRIX VISION GmbH, Talstra=DFe 16, DE-71570 Oppenweiler  - Registergeric=
-ht: Amtsgericht Stuttgart, HRB 271090
-Gesch=E4ftsf=FChrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
+MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
+Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
diff --git a/a/content_digest b/N1/content_digest
index d56e219..72714fe 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -1,21 +1,18 @@
  "ref\0200811211336.41159.jbe@pengutronix.de\0"
  "From\0Andre Schwarz <andre.schwarz@matrix-vision.de>\0"
- "Subject\0Re: MPC5200B: Trouble with config pins\0"
+ "Subject\0[U-Boot] MPC5200B: Trouble with config pins\0"
  "Date\0Fri, 21 Nov 2008 16:58:16 +0100\0"
- "To\0Juergen Beisert <jbe@pengutronix.de>\0"
- "Cc\0linuxppc-dev@ozlabs.org"
- " u-boot@lists.denx.de\0"
+ "To\0u-boot@lists.denx.de\0"
  "\00:1\0"
  "b\0"
- "J=FCrgen,\n"
+ "J?rgen,\n"
  "\n"
- "Have a look at the manual chapter 4 (=3DReset + Config).\n"
- "SRESET (issued by gpt0 - watchdog) isn't supposed to do a full hardware=20\n"
+ "Have a look at the manual chapter 4 (=Reset + Config).\n"
+ "SRESET (issued by gpt0 - watchdog) isn't supposed to do a full hardware \n"
  "reset.\n"
- "Looks like you should make use of the SRESET and trigger HRESET according=\n"
- "ly.\n"
+ "Looks like you should make use of the SRESET and trigger HRESET accordingly.\n"
  "\n"
- "I could solve this with _not_ using the internal watchdog but an=20\n"
+ "I could solve this with _not_ using the internal watchdog but an \n"
  "external one (TPS3828),\n"
  "i.e. watchdog timeouts and reboots are always issued by PORESET.\n"
  "\n"
@@ -28,44 +25,29 @@
  "Juergen Beisert schrieb:\n"
  "> Hi all,\n"
  ">\n"
- "> we have trouble with the eth based config pins (ETH0...ETH6) of the MPC=\n"
- "5200B=20\n"
- "> CPU. These pins act as the interface to an external phy and also act as=\n"
- "=20\n"
- "> configurations pins to configure the size of the flash and other things=\n"
- ".=20\n"
- "> While the reset is active these pins should be in their high impedance =\n"
- "state=20\n"
- "> and the externally connected pull down resistors should define wire's v=\n"
- "oltage=20\n"
- "> level. With the rising edge of the reset signal these levels will be la=\n"
- "tched=20\n"
+ "> we have trouble with the eth based config pins (ETH0...ETH6) of the MPC5200B \n"
+ "> CPU. These pins act as the interface to an external phy and also act as \n"
+ "> configurations pins to configure the size of the flash and other things. \n"
+ "> While the reset is active these pins should be in their high impedance state \n"
+ "> and the externally connected pull down resistors should define wire's voltage \n"
+ "> level. With the rising edge of the reset signal these levels will be latched \n"
  "> into internal config registers.\n"
- "> We are in trouble when we want to reboot the system (also watchdog base=\n"
- "d) or=20\n"
- "> the internal watchdog barks and generates the CPU internal reset signal=\n"
- ". In=20\n"
- "> these cases these config pins will not change their level! So the wrong=\n"
- "=20\n"
- "> settings are latched in and our CPU is dead (misconfigured), sometimes =\n"
- "a=20\n"
+ "> We are in trouble when we want to reboot the system (also watchdog based) or \n"
+ "> the internal watchdog barks and generates the CPU internal reset signal. In \n"
+ "> these cases these config pins will not change their level! So the wrong \n"
+ "> settings are latched in and our CPU is dead (misconfigured), sometimes a \n"
  "> second reset helps, but most of the time only power cycling helps.\n"
  ">\n"
  "> What we see is:\n"
  ">  - at the pins ETH_0 and ETH_3 (both are output only, when used for\n"
  ">    ethernet)\n"
  ">\n"
- ">  * With an external 10k pulldown these lines never change their 3.3V le=\n"
- "vel\n"
+ ">  * With an external 10k pulldown these lines never change their 3.3V level\n"
  ">    even if the reset is active!\n"
- ">  * With an external 1k pulldown these lines change their 3.3V level dow=\n"
- "n to\n"
- ">    something about 2.5V when the falling edge of the reset signal occur=\n"
- "s.\n"
- ">  * This level decreases slowly to 1.2V in about 1.2ms and than a fallin=\n"
- "g edge\n"
- ">    to 0V occures. Problem here is, the internal watchdog's generated re=\n"
- "set\n"
+ ">  * With an external 1k pulldown these lines change their 3.3V level down to\n"
+ ">    something about 2.5V when the falling edge of the reset signal occurs.\n"
+ ">  * This level decreases slowly to 1.2V in about 1.2ms and than a falling edge\n"
+ ">    to 0V occures. Problem here is, the internal watchdog's generated reset\n"
  ">    signal is much shorter, so the rising edge of this reset signal also\n"
  ">    latches in the wrong settings and the CPU is dead.\n"
  ">\n"
@@ -76,27 +58,22 @@
  ">     -> system restarts\n"
  ">    We can see in this case, the ETH_0 and ETH_3 are switching to low\n"
  ">    level *immediatly* with the falling edge of the reset signal\n"
- ">  - an activated interface (\"ifconfig up\") in Linux with *disconnected* =\n"
- "network\n"
+ ">  - an activated interface (\"ifconfig up\") in Linux with *disconnected* network\n"
  ">     -> system is always dead\n"
- ">  - an activated interface (\"ifconfig up\") in Linux with *connected* net=\n"
- "work\n"
+ ">  - an activated interface (\"ifconfig up\") in Linux with *connected* network\n"
  ">     -> system is always dead\n"
  ">\n"
- "> Does anybody see a behaviour like ours on his/her MPC5200B based system=\n"
- "?\n"
- "> Does anybody have an idea what the difference between U-Boot und Linux =\n"
- "could=20\n"
+ "> Does anybody see a behaviour like ours on his/her MPC5200B based system?\n"
+ "> Does anybody have an idea what the difference between U-Boot und Linux could \n"
  "> be? Bug? Feature?\n"
  ">\n"
  "> Regards,\n"
  "> Juergen\n"
  ">\n"
- ">  =20\n"
+ ">   \n"
  "\n"
  "\n"
- "MATRIX VISION GmbH, Talstra=DFe 16, DE-71570 Oppenweiler  - Registergeric=\n"
- "ht: Amtsgericht Stuttgart, HRB 271090\n"
- Gesch=E4ftsf=FChrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
+ "MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090\n"
+ Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
 
-7520c0af71bf2608c65d0918566bd077639c3e5326372ab36fd58e3d78ed4a30
+aca033fc1e36b583e6fd2de31a1bbdff72d3ff3807c9327ffb88c0b4a1e373bf

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.