Re: EHCI debug documentation

Re: EHCI debug documentation

[Yinghai Lu]

On Tue, Mar 3, 2009 at 3:53 PM, Sarah Sharp <sarah.a.sharp@intel.com> wrote:
> Greetings,
>
> You wrote the EHCI debug port patch for early printk back in July 2008
> (commit 5c05917e7fe313a187ad6ebb94c1c6cf42862a0b).  Can you add some
> documentation to the Documentation directory about how a Linux user
> would set up a system (cables, files to open to get the printks, etc.)?

please check

==========================================================================================
USB Debug port using Howto

1. HW:

a. target system need to have debug port

00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2
EHCI Controller #1 (rev 03) (prog-if 20 [EHCI])
        Subsystem: Lenovo ThinkPad T61
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin D routed to IRQ 19
        Region 0: Memory at fe227000 (32-bit, non-prefetchable) [size=1K]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME+
        Capabilities: [58] Debug port: BAR=1 offset=00a0
        Kernel driver in use: ehci_hcd
        Kernel modules: ehci-hcd
00: 86 80 36 28 06 01 90 02 03 20 03 0c 00 00 00 00
10: 00 70 22 fe 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 aa 17 ab 20
30: 00 00 00 00 50 00 00 00 00 00 00 00 0b 04 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 01 58 c2 c9 00 80 00 00 0a 00 a0 20 00 00 00 00
60: 20 20 9f 01 00 00 00 00 01 00 00 01 00 00 08 80
70: c0 00 17 3f 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 aa ff 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 88 85 40 00 86 0f 05 00 06 17 02 20

b. netchip USB debug cable

c. console system: have USB port

2. SW setting
a. console system: need to have kernel config
   CONFIG_USB_SERIAL_DEBUG
   you should get /dev/ttyUSBx

   # cat /dev/ttyUSBx could get output

b. target system: need to have kernel config
   CONFIG_EARLY_PRINTK_DBGP

   boot command line: earlyprintk=dbgp

c. for Nvidia Southbridge based system: kernel will try to probe and
find out which port has debug device connected.

Re: EHCI debug documentation

[Randy Dunlap]

Yinghai Lu wrote:
> On Tue, Mar 3, 2009 at 3:53 PM, Sarah Sharp <sarah.a.sharp@intel.com> wrote:
>> Greetings,
>>
>> You wrote the EHCI debug port patch for early printk back in July 2008
>> (commit 5c05917e7fe313a187ad6ebb94c1c6cf42862a0b).  Can you add some
>> documentation to the Documentation directory about how a Linux user
>> would set up a system (cables, files to open to get the printks, etc.)?
> 
> please check
> 
> ==========================================================================================
> USB Debug port using Howto
> 
> 1. HW:
> 
> a. target system need to have debug port
> 
> 00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2
> EHCI Controller #1 (rev 03) (prog-if 20 [EHCI])
>         Subsystem: Lenovo ThinkPad T61
>         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR+ FastB2B- DisINTx-
>         Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>> TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>         Latency: 0
>         Interrupt: pin D routed to IRQ 19
>         Region 0: Memory at fe227000 (32-bit, non-prefetchable) [size=1K]
>         Capabilities: [50] Power Management version 2
>                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
> PME(D0+,D1-,D2-,D3hot+,D3cold+)
>                 Status: D0 PME-Enable- DSel=0 DScale=0 PME+
>         Capabilities: [58] Debug port: BAR=1 offset=00a0
>         Kernel driver in use: ehci_hcd
>         Kernel modules: ehci-hcd
> 00: 86 80 36 28 06 01 90 02 03 20 03 0c 00 00 00 00
> 10: 00 70 22 fe 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 aa 17 ab 20
> 30: 00 00 00 00 50 00 00 00 00 00 00 00 0b 04 00 00
> 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 50: 01 58 c2 c9 00 80 00 00 0a 00 a0 20 00 00 00 00
> 60: 20 20 9f 01 00 00 00 00 01 00 00 01 00 00 08 80
> 70: c0 00 17 3f 00 00 00 00 00 00 00 00 00 00 00 00
> 80: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
> 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> d0: 00 00 00 00 00 aa ff 00 00 00 00 00 00 00 00 00
> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> f0: 00 00 00 00 88 85 40 00 86 0f 05 00 06 17 02 20
> 
> b. netchip USB debug cable

http://www.plxtech.com/products/NET2000/NET20DC/default.asp


> c. console system: have USB port
> 
> 2. SW setting
> a. console system: need to have kernel config
>    CONFIG_USB_SERIAL_DEBUG
>    you should get /dev/ttyUSBx
> 
>    # cat /dev/ttyUSBx could get output
> 
> b. target system: need to have kernel config
>    CONFIG_EARLY_PRINTK_DBGP
> 
>    boot command line: earlyprintk=dbgp
> 
> c. for Nvidia Southbridge based system: kernel will try to probe and
> find out which port has debug device connected.


-- 
~Randy

Re: EHCI debug documentation

[Ingo Molnar]

* Randy Dunlap <randy.dunlap@oracle.com> wrote:

> Yinghai Lu wrote:
> > On Tue, Mar 3, 2009 at 3:53 PM, Sarah Sharp <sarah.a.sharp@intel.com> wrote:
> >> Greetings,
> >>
> >> You wrote the EHCI debug port patch for early printk back in July 2008
> >> (commit 5c05917e7fe313a187ad6ebb94c1c6cf42862a0b).  Can you add some
> >> documentation to the Documentation directory about how a Linux user
> >> would set up a system (cables, files to open to get the printks, etc.)?
> > 
> > please check
> > 
> > ==========================================================================================
> > USB Debug port using Howto
> > 
> > 1. HW:
> > 
> > a. target system need to have debug port
> > 
> > 00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2
> > EHCI Controller #1 (rev 03) (prog-if 20 [EHCI])
> >         Subsystem: Lenovo ThinkPad T61
> >         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> > ParErr- Stepping- SERR+ FastB2B- DisINTx-
> >         Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
> >> TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> >         Latency: 0
> >         Interrupt: pin D routed to IRQ 19
> >         Region 0: Memory at fe227000 (32-bit, non-prefetchable) [size=1K]
> >         Capabilities: [50] Power Management version 2
> >                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
> > PME(D0+,D1-,D2-,D3hot+,D3cold+)
> >                 Status: D0 PME-Enable- DSel=0 DScale=0 PME+
> >         Capabilities: [58] Debug port: BAR=1 offset=00a0
> >         Kernel driver in use: ehci_hcd
> >         Kernel modules: ehci-hcd
> > 00: 86 80 36 28 06 01 90 02 03 20 03 0c 00 00 00 00
> > 10: 00 70 22 fe 00 00 00 00 00 00 00 00 00 00 00 00
> > 20: 00 00 00 00 00 00 00 00 00 00 00 00 aa 17 ab 20
> > 30: 00 00 00 00 50 00 00 00 00 00 00 00 0b 04 00 00
> > 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 50: 01 58 c2 c9 00 80 00 00 0a 00 a0 20 00 00 00 00
> > 60: 20 20 9f 01 00 00 00 00 01 00 00 01 00 00 08 80
> > 70: c0 00 17 3f 00 00 00 00 00 00 00 00 00 00 00 00
> > 80: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
> > 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > d0: 00 00 00 00 00 aa ff 00 00 00 00 00 00 00 00 00
> > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > f0: 00 00 00 00 88 85 40 00 86 0f 05 00 06 17 02 20
> > 
> > b. netchip USB debug cable
> 
> http://www.plxtech.com/products/NET2000/NET20DC/default.asp
> 
> 
> > c. console system: have USB port
> > 
> > 2. SW setting
> > a. console system: need to have kernel config
> >    CONFIG_USB_SERIAL_DEBUG
> >    you should get /dev/ttyUSBx
> > 
> >    # cat /dev/ttyUSBx could get output
> > 
> > b. target system: need to have kernel config
> >    CONFIG_EARLY_PRINTK_DBGP
> > 
> >    boot command line: earlyprintk=dbgp
> > 
> > c. for Nvidia Southbridge based system: kernel will try to probe and
> > find out which port has debug device connected.

Would be nice to turn this all into a patch that adds this info 
to Documentation/x86/early-printk.txt or so.

	Ingo

Re: EHCI debug documentation

[Greg KH]

* Randy Dunlap <randy.dunlap@oracle.com> wrote:
> Yinghai Lu wrote:
> > b. netchip USB debug cable
> 
> http://www.plxtech.com/products/NET2000/NET20DC/default.asp

I have reports that the newer version of this device does not work on
Linux as it isn't enumeratable as a "real" usb device on one end.

I don't have one of these new devices yet to test it out, has anyone
else heard of this problem?

thanks,

greg k-h

Re: EHCI debug documentation

[Eric W. Biederman]

Greg KH <gregkh@suse.de> writes:

> * Randy Dunlap <randy.dunlap@oracle.com> wrote:
>> Yinghai Lu wrote:
>> > b. netchip USB debug cable
>> 
>> http://www.plxtech.com/products/NET2000/NET20DC/default.asp
>
> I have reports that the newer version of this device does not work on
> Linux as it isn't enumeratable as a "real" usb device on one end.
>
> I don't have one of these new devices yet to test it out, has anyone
> else heard of this problem?

With the first generation of devices I remember they were peculiar and
finicky.  I don't recall the exact details but I remember the devices
able to get into weird states that may resemble what you describe.

Eric

Re: EHCI debug documentation

[Alan Stern]

On Wed, 4 Mar 2009, Eric W. Biederman wrote:

> Greg KH <gregkh@suse.de> writes:
> 
> > * Randy Dunlap <randy.dunlap@oracle.com> wrote:
> >> Yinghai Lu wrote:
> >> > b. netchip USB debug cable
> >> 
> >> http://www.plxtech.com/products/NET2000/NET20DC/default.asp
> >
> > I have reports that the newer version of this device does not work on
> > Linux as it isn't enumeratable as a "real" usb device on one end.
> >
> > I don't have one of these new devices yet to test it out, has anyone
> > else heard of this problem?
> 
> With the first generation of devices I remember they were peculiar and
> finicky.  I don't recall the exact details but I remember the devices
> able to get into weird states that may resemble what you describe.

Those devices were a little peculiar in that they were powered only on
one side.  That is, they would take bus power only from the right-hand
connector (looking at the face with the PLX logo).  So if you plugged
in only the left side, the device would not show up or enumerate.  But 
if you plugged in both sides, then both of them would enumerate okay.

Alan Stern

Re: EHCI debug documentation

[Sarah Sharp]

On Wed, Mar 04, 2009 at 04:59:28PM -0500, Alan Stern wrote:
> On Wed, 4 Mar 2009, Eric W. Biederman wrote:
> 
> > Greg KH <gregkh@suse.de> writes:
> > 
> > > * Randy Dunlap <randy.dunlap@oracle.com> wrote:
> > >> Yinghai Lu wrote:
> > >> > b. netchip USB debug cable
> > >> 
> > >> http://www.plxtech.com/products/NET2000/NET20DC/default.asp
> > >
> > > I have reports that the newer version of this device does not work on
> > > Linux as it isn't enumeratable as a "real" usb device on one end.
> > >
> > > I don't have one of these new devices yet to test it out, has anyone
> > > else heard of this problem?
> > 
> > With the first generation of devices I remember they were peculiar and
> > finicky.  I don't recall the exact details but I remember the devices
> > able to get into weird states that may resemble what you describe.
> 
> Those devices were a little peculiar in that they were powered only on
> one side.  That is, they would take bus power only from the right-hand
> connector (looking at the face with the PLX logo).  So if you plugged
> in only the left side, the device would not show up or enumerate.  But 
> if you plugged in both sides, then both of them would enumerate okay.

That comment should be in the documentation for ehci early printks too.

Sarah Sharp

[PATCH] x86/doc: doc the using earlyprintk=dbgp

[Yinghai Lu]

Impact: doc

simple using howto for earlyprintk=dbgp

Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 Documentation/x86/earlyprintk.txt |   41 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)

Index: linux-2.6/Documentation/x86/earlyprintk.txt
===================================================================
--- /dev/null
+++ linux-2.6/Documentation/x86/earlyprintk.txt
@@ -0,0 +1,41 @@
+
+Using earlyprintk with USB2 Debug port and debug cable
+
+1. HW:
+a. target system need to have debug port
+
+# lspci -vvv
+...
+00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03) (prog-if 20 [EHCI])
+        Subsystem: Lenovo ThinkPad T61
+        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
+        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
+        Latency: 0
+        Interrupt: pin D routed to IRQ 19
+        Region 0: Memory at fe227000 (32-bit, non-prefetchable) [size=1K]
+        Capabilities: [50] Power Management version 2
+                Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
+                Status: D0 PME-Enable- DSel=0 DScale=0 PME+
+        Capabilities: [58] Debug port: BAR=1 offset=00a0
+        Kernel driver in use: ehci_hcd
+        Kernel modules: ehci-hcd
+...
+b. netchip USB debug cable
+   http://www.plxtech.com/products/NET2000/NET20DC/default.asp
+
+c. console system: have USB2 port
+
+2. SW setting
+a. console system: need to have kernel config
+   CONFIG_USB_SERIAL_DEBUG
+   you should get /dev/ttyUSBx
+
+   # cat /dev/ttyUSBx could get output
+
+b. target system: need to have kernel config
+   CONFIG_EARLY_PRINTK_DBGP
+
+   boot command line: earlyprintk=dbgp
+
+c. for Nvidia Southbridge based system: kernel will try to probe and find out which port has debug device connneted.
+

[tip:x86/doc] x86/doc: mini-howto for using earlyprintk=dbgp

[Yinghai Lu]

Commit-ID:  a1aade478862fca8710904532cbc6efed97fd05a
Gitweb:     http://git.kernel.org/tip/a1aade478862fca8710904532cbc6efed97fd05a
Author:     "Yinghai Lu" <yinghai@kernel.org>
AuthorDate: Wed, 4 Mar 2009 16:11:35 -0800
Commit:     Ingo Molnar <mingo@elte.hu>
CommitDate: Thu, 5 Mar 2009 10:57:52 +0100

x86/doc: mini-howto for using earlyprintk=dbgp

[ mingo: small edits and extensions. ]

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Greg KH <gregkh@suse.de>
Cc: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Sarah Sharp <sarah.a.sharp@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
LKML-Reference: <49AF18B7.4050305@kernel.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>


---
 Documentation/x86/earlyprintk.txt |  101 +++++++++++++++++++++++++++++++++++++
 1 files changed, 101 insertions(+), 0 deletions(-)

diff --git a/Documentation/x86/earlyprintk.txt b/Documentation/x86/earlyprintk.txt
new file mode 100644
index 0000000..607b1a0
--- /dev/null
+++ b/Documentation/x86/earlyprintk.txt
@@ -0,0 +1,101 @@
+
+Mini-HOWTO for using the earlyprintk=dbgp boot option with a
+USB2 Debug port key and a debug cable, on x86 systems.
+
+You need two computers, the 'USB debug key' special gadget and
+and two USB cables, connected like this:
+
+  [host/target] <-------> [USB debug key] <-------> [client/console]
+
+1. There are three specific hardware requirements:
+
+ a.) Host/target system needs to have USB debug port capability.
+
+ You can check this capability by looking at a 'Debug port' bit in
+ the lspci -vvv output:
+
+ # lspci -vvv
+ ...
+ 00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03) (prog-if 20 [EHCI])
+         Subsystem: Lenovo ThinkPad T61
+         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
+         Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
+         Latency: 0
+         Interrupt: pin D routed to IRQ 19
+         Region 0: Memory at fe227000 (32-bit, non-prefetchable) [size=1K]
+         Capabilities: [50] Power Management version 2
+                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
+                 Status: D0 PME-Enable- DSel=0 DScale=0 PME+
+         Capabilities: [58] Debug port: BAR=1 offset=00a0
+                            ^^^^^^^^^^^ <==================== [ HERE ]
+	 Kernel driver in use: ehci_hcd
+         Kernel modules: ehci-hcd
+ ...
+
+( If your system does not list a debug port capability then you probably
+  wont be able to use the USB debug key. )
+
+ b.) You also need a Netchip USB debug cable/key:
+
+        http://www.plxtech.com/products/NET2000/NET20DC/default.asp
+
+     This is a small blue plastic connector with two USB connections,
+     it draws power from its USB connections.
+
+ c.) Thirdly, you need a second client/console system with a regular USB port.
+
+2. Software requirements:
+
+ a.) On the host/target system:
+
+    You need to enable the following kernel config option:
+
+      CONFIG_EARLY_PRINTK_DBGP=y
+
+    And you need to add the boot command line: "earlyprintk=dbgp".
+    (If you are using Grub, append it to the 'kernel' line in
+     /etc/grub.conf)
+
+    NOTE: normally earlyprintk console gets turned off once the
+    regular console is alive - use "earlyprintk=dbgp,keep" to keep
+    this channel open beyond early bootup. This can be useful for
+    debugging crashes under Xorg, etc.
+
+ b.) On the client/console system:
+
+    You should enable the following kernel config option:
+
+      CONFIG_USB_SERIAL_DEBUG=y
+
+    On the next bootup with the modified kernel you should
+    get a /dev/ttyUSBx device(s).
+
+    Now this channel of kernel messages is ready to be used: start
+    your favorite terminal emulator (minicom, etc.) and set
+    it up to use /dev/ttyUSB0 - or use a raw 'cat /dev/ttyUSBx' to
+    see the raw output.
+
+ c.) On Nvidia Southbridge based systems: the kernel will try to probe
+     and find out which port has debug device connected.
+
+3. Testing that it works fine:
+
+   You can test the output by using earlyprintk=dbgp,keep and provoking
+   kernel messages on the host/target system. You can provoke a harmless
+   kernel message by for example doing:
+
+     echo h > /proc/sysrq-trigger
+
+   On the host/target system you should see this help line in "dmesg" output:
+
+     SysRq : HELP : loglevel(0-9) reBoot Crashdump terminate-all-tasks(E) memory-full-oom-kill(F) kill-all-tasks(I) saK show-backtrace-all-active-cpus(L) show-memory-usage(M) nice-all-RT-tasks(N) powerOff show-registers(P) show-all-timers(Q) unRaw Sync show-task-states(T) Unmount show-blocked-tasks(W) dump-ftrace-buffer(Z)
+
+   On the client/console system do:
+
+       cat /dev/ttyUSB0
+
+   And you should see the help line above displayed shortly after you've
+   provoked it on the host system.
+
+If it does not work then please ask about it on the linux-kernel@vger.kernel.org
+mailing list or contact the x86 maintainers.

Re: [tip:x86/doc] x86/doc: mini-howto for using earlyprintk=dbgp

[Daniel Walker]

On Thu, 2009-03-05 at 10:00 +0000, Yinghai Lu wrote:

> +
> +Mini-HOWTO for using the earlyprintk=dbgp boot option with a
> +USB2 Debug port key and a debug cable, on x86 systems.
> +
> +You need two computers, the 'USB debug key' special gadget and
> +and two USB cables, connected like this:
> +
> +  [host/target] <-------> [USB debug key] <-------> [client/console]
> +
> +1. There are three specific hardware requirements:
> +
> + a.) Host/target system needs to have USB debug port capability.
> +
> + You can check this capability by looking at a 'Debug port' bit in
> + the lspci -vvv output:

...

> + c.) Thirdly, you need a second client/console system with a regular USB port.

You might want to combine a.) and c.) since there is some disconnect
between the two. c.) doesn't explicitly say a second time that the
client/console needs the debug port capability ..

Or say

a.) You will need two USB ports. One on the client/console system and
one one the target system.

b.) The client/console and target USB ports must have the debug port
capability. You can check for this as follows,

c.) ...

I just felt the disconnect between the two a.) , and c.) left some
questions.

> +2. Software requirements:
> +
> + a.) On the host/target system:
> +
> +    You need to enable the following kernel config option:
> +
> +      CONFIG_EARLY_PRINTK_DBGP=y
> +
> +    And you need to add the boot command line: "earlyprintk=dbgp".
> +    (If you are using Grub, append it to the 'kernel' line in
> +     /etc/grub.conf)

Isn't the usual grub.conf in /boot/grub/grub.conf ? That's where mine
always seem to end up.

> +    NOTE: normally earlyprintk console gets turned off once the
> +    regular console is alive - use "earlyprintk=dbgp,keep" to keep
> +    this channel open beyond early bootup. This can be useful for
> +    debugging crashes under Xorg, etc.
> +
> + b.) On the client/console system:
> +
> +    You should enable the following kernel config option:
> +
> +      CONFIG_USB_SERIAL_DEBUG=y
> +
> +    On the next bootup with the modified kernel you should
> +    get a /dev/ttyUSBx device(s).
> +
> +    Now this channel of kernel messages is ready to be used: start
> +    your favorite terminal emulator (minicom, etc.) and set
> +    it up to use /dev/ttyUSB0 - or use a raw 'cat /dev/ttyUSBx' to
> +    see the raw output.

You might want to switch the first /dev/ttyUSB0 to /dev/ttyUSBx .

> + c.) On Nvidia Southbridge based systems: the kernel will try to probe
> +     and find out which port has debug device connected.
> +
> +3. Testing that it works fine:
> +
> +   You can test the output by using earlyprintk=dbgp,keep and provoking
> +   kernel messages on the host/target system. You can provoke a harmless
> +   kernel message by for example doing:
> +
> +     echo h > /proc/sysrq-trigger
> +
> +   On the host/target system you should see this help line in "dmesg" output:
> +
> +     SysRq : HELP : loglevel(0-9) reBoot Crashdump terminate-all-tasks(E) memory-full-oom-kill(F) kill-all-tasks(I) saK show-backtrace-all-active-cpus(L) show-memory-usage(M) nice-all-RT-tasks(N) powerOff show-registers(P) show-all-timers(Q) unRaw Sync show-task-states(T) Unmount show-blocked-tasks(W) dump-ftrace-buffer(Z)
> +
> +   On the client/console system do:
> +
> +       cat /dev/ttyUSB0

Missing "x" here too.

Seems like a nice document. Thanks for writing it.

Daniel

Re: [tip:x86/doc] x86/doc: mini-howto for using earlyprintk=dbgp

[Yinghai Lu]

Daniel Walker wrote:
> On Thu, 2009-03-05 at 10:00 +0000, Yinghai Lu wrote:
> 
>> +
>> +Mini-HOWTO for using the earlyprintk=dbgp boot option with a
>> +USB2 Debug port key and a debug cable, on x86 systems.
>> +
>> +You need two computers, the 'USB debug key' special gadget and
>> +and two USB cables, connected like this:
>> +
>> +  [host/target] <-------> [USB debug key] <-------> [client/console]
>> +
>> +1. There are three specific hardware requirements:
>> +
>> + a.) Host/target system needs to have USB debug port capability.
>> +
>> + You can check this capability by looking at a 'Debug port' bit in
>> + the lspci -vvv output:
> 
> ...
> 
>> + c.) Thirdly, you need a second client/console system with a regular USB port.
> 
> You might want to combine a.) and c.) since there is some disconnect
> between the two. c.) doesn't explicitly say a second time that the
> client/console needs the debug port capability ..
> 
> Or say
> 
> a.) You will need two USB ports. One on the client/console system and
> one one the target system.
> 
> b.) The client/console and target USB ports must have the debug port
> capability. You can check for this as follows,
> 
> c.) ...

thanks for checking it.

can you submit patch to Ingo according to tip/master?

YH

Re: [tip:x86/doc] x86/doc: mini-howto for using earlyprintk=dbgp

[Daniel Walker]

On Thu, 2009-03-05 at 11:22 -0800, Yinghai Lu wrote:

> 
> thanks for checking it.
> 
> can you submit patch to Ingo according to tip/master?


Hows this?

--

Fix up some typos, and make the requirements section slightly cleaner.

Signed-Off-By: Daniel Walker dwalker@fifo99.com

diff --git a/Documentation/x86/earlyprintk.txt b/Documentation/x86/earlyprintk.txt
index 607b1a0..5b51aef 100644
--- a/Documentation/x86/earlyprintk.txt
+++ b/Documentation/x86/earlyprintk.txt
@@ -9,7 +9,9 @@ and two USB cables, connected like this:
 
 1. There are three specific hardware requirements:
 
- a.) Host/target system needs to have USB debug port capability.
+ a.) You will need two USB ports. One on the client/console system and one one the target system.
+ 
+ b.) The client/console and target USB ports must have the debug port capability.
 
  You can check this capability by looking at a 'Debug port' bit in
  the lspci -vvv output:
@@ -35,15 +37,13 @@ and two USB cables, connected like this:
 ( If your system does not list a debug port capability then you probably
   wont be able to use the USB debug key. )
 
- b.) You also need a Netchip USB debug cable/key:
+ c.) You also need a Netchip USB debug cable/key:
 
         http://www.plxtech.com/products/NET2000/NET20DC/default.asp
 
      This is a small blue plastic connector with two USB connections,
      it draws power from its USB connections.
 
- c.) Thirdly, you need a second client/console system with a regular USB port.
-
 2. Software requirements:
 
  a.) On the host/target system:
@@ -54,7 +54,7 @@ and two USB cables, connected like this:
 
     And you need to add the boot command line: "earlyprintk=dbgp".
     (If you are using Grub, append it to the 'kernel' line in
-     /etc/grub.conf)
+     grub.conf (i.e. /boot/grub/grub.conf) )
 
     NOTE: normally earlyprintk console gets turned off once the
     regular console is alive - use "earlyprintk=dbgp,keep" to keep
@@ -72,7 +72,7 @@ and two USB cables, connected like this:
 
     Now this channel of kernel messages is ready to be used: start
     your favorite terminal emulator (minicom, etc.) and set
-    it up to use /dev/ttyUSB0 - or use a raw 'cat /dev/ttyUSBx' to
+    it up to use /dev/ttyUSBx - or use a raw 'cat /dev/ttyUSBx' to
     see the raw output.
 
  c.) On Nvidia Southbridge based systems: the kernel will try to probe
@@ -92,7 +92,7 @@ and two USB cables, connected like this:
 
    On the client/console system do:
 
-       cat /dev/ttyUSB0
+       cat /dev/ttyUSBx
 
    And you should see the help line above displayed shortly after you've
    provoked it on the host system.

Re: [tip:x86/doc] x86/doc: mini-howto for using earlyprintk=dbgp

[Alan Stern]

On Thu, 5 Mar 2009, Daniel Walker wrote:

> Fix up some typos, and make the requirements section slightly cleaner.
> 
> Signed-Off-By: Daniel Walker dwalker@fifo99.com
> 
> diff --git a/Documentation/x86/earlyprintk.txt b/Documentation/x86/earlyprintk.txt
> index 607b1a0..5b51aef 100644
> --- a/Documentation/x86/earlyprintk.txt
> +++ b/Documentation/x86/earlyprintk.txt
> @@ -9,7 +9,9 @@ and two USB cables, connected like this:
>  
>  1. There are three specific hardware requirements:
>  
> - a.) Host/target system needs to have USB debug port capability.
> + a.) You will need two USB ports. One on the client/console system and one one the target system.

s/one one/one on/

You might also try harder to observe the 80-column rule.

> + 
> + b.) The client/console and target USB ports must have the debug port capability.
>  
>   You can check this capability by looking at a 'Debug port' bit in
>   the lspci -vvv output:
> @@ -35,15 +37,13 @@ and two USB cables, connected like this:
>  ( If your system does not list a debug port capability then you probably
>    wont be able to use the USB debug key. )
>  
> - b.) You also need a Netchip USB debug cable/key:
> + c.) You also need a Netchip USB debug cable/key:
>  
>          http://www.plxtech.com/products/NET2000/NET20DC/default.asp
>  
>       This is a small blue plastic connector with two USB connections,
>       it draws power from its USB connections.

No.  It draws power from one of its USB connections (the one on the 
right side when you're looking at the face with the PLX logo).

Alan Stern

Re: [tip:x86/doc] x86/doc: mini-howto for using earlyprintk=dbgp

[Daniel Walker]

On Thu, 2009-03-05 at 17:54 -0500, Alan Stern wrote:
> On Thu, 5 Mar 2009, Daniel Walker wrote:
> 
> > Fix up some typos, and make the requirements section slightly cleaner.
> > 
> > Signed-Off-By: Daniel Walker dwalker@fifo99.com
> > 
> > diff --git a/Documentation/x86/earlyprintk.txt b/Documentation/x86/earlyprintk.txt
> > index 607b1a0..5b51aef 100644
> > --- a/Documentation/x86/earlyprintk.txt
> > +++ b/Documentation/x86/earlyprintk.txt
> > @@ -9,7 +9,9 @@ and two USB cables, connected like this:
> >  
> >  1. There are three specific hardware requirements:
> >  
> > - a.) Host/target system needs to have USB debug port capability.
> > + a.) You will need two USB ports. One on the client/console system and one one the target system.
> 
> s/one one/one on/

Check.

> You might also try harder to observe the 80-column rule.

I wasn't aware it applied to documents ..

> > + 
> > + b.) The client/console and target USB ports must have the debug port capability.
> >  
> >   You can check this capability by looking at a 'Debug port' bit in
> >   the lspci -vvv output:
> > @@ -35,15 +37,13 @@ and two USB cables, connected like this:
> >  ( If your system does not list a debug port capability then you probably
> >    wont be able to use the USB debug key. )
> >  
> > - b.) You also need a Netchip USB debug cable/key:
> > + c.) You also need a Netchip USB debug cable/key:
> >  
> >          http://www.plxtech.com/products/NET2000/NET20DC/default.asp
> >  
> >       This is a small blue plastic connector with two USB connections,
> >       it draws power from its USB connections.
> 
> No.  It draws power from one of its USB connections (the one on the 
> right side when you're looking at the face with the PLX logo).

I didn't write that part, but I suppose I could correct it..

Daniel

Re: [tip:x86/doc] x86/doc: mini-howto for using earlyprintk=dbgp

[Randy Dunlap]

Daniel Walker wrote:
> On Thu, 2009-03-05 at 17:54 -0500, Alan Stern wrote:
>> On Thu, 5 Mar 2009, Daniel Walker wrote:
>>
>>> Fix up some typos, and make the requirements section slightly cleaner.
>>>
>>> Signed-Off-By: Daniel Walker dwalker@fifo99.com
>>>
>>> diff --git a/Documentation/x86/earlyprintk.txt b/Documentation/x86/earlyprintk.txt
>>> index 607b1a0..5b51aef 100644
>>> --- a/Documentation/x86/earlyprintk.txt
>>> +++ b/Documentation/x86/earlyprintk.txt
>>> @@ -9,7 +9,9 @@ and two USB cables, connected like this:
>>>  
>>>  1. There are three specific hardware requirements:
>>>  
>>> - a.) Host/target system needs to have USB debug port capability.
>>> + a.) You will need two USB ports. One on the client/console system and one one the target system.
>> s/one one/one on/
> 
> Check.
> 
>> You might also try harder to observe the 80-column rule.
> 
> I wasn't aware it applied to documents ..

Yes, it does.


Thanks.
-- 
~Randy

Re: [tip:x86/doc] x86/doc: mini-howto for using earlyprintk=dbgp

[Daniel Walker]

On Thu, 2009-03-05 at 15:05 -0800, Randy Dunlap wrote:
> Daniel Walker wrote:
> > On Thu, 2009-03-05 at 17:54 -0500, Alan Stern wrote:
> >> On Thu, 5 Mar 2009, Daniel Walker wrote:
> >>
> >>> Fix up some typos, and make the requirements section slightly cleaner.
> >>>
> >>> Signed-Off-By: Daniel Walker dwalker@fifo99.com
> >>>
> >>> diff --git a/Documentation/x86/earlyprintk.txt b/Documentation/x86/earlyprintk.txt
> >>> index 607b1a0..5b51aef 100644
> >>> --- a/Documentation/x86/earlyprintk.txt
> >>> +++ b/Documentation/x86/earlyprintk.txt
> >>> @@ -9,7 +9,9 @@ and two USB cables, connected like this:
> >>>  
> >>>  1. There are three specific hardware requirements:
> >>>  
> >>> - a.) Host/target system needs to have USB debug port capability.
> >>> + a.) You will need two USB ports. One on the client/console system and one one the target system.
> >> s/one one/one on/
> > 
> > Check.
> > 
> >> You might also try harder to observe the 80-column rule.
> > 
> > I wasn't aware it applied to documents ..
> 
> Yes, it does.
> 

Shall we add that to a document style guide? There's several other docs
that don't conform to that..

Daniel

Re: [tip:x86/doc] x86/doc: mini-howto for using earlyprintk=dbgp

[Randy Dunlap]

Daniel Walker wrote:
> On Thu, 2009-03-05 at 15:05 -0800, Randy Dunlap wrote:
>> Daniel Walker wrote:
>>> On Thu, 2009-03-05 at 17:54 -0500, Alan Stern wrote:
>>>> On Thu, 5 Mar 2009, Daniel Walker wrote:
>>>>
>>>>> Fix up some typos, and make the requirements section slightly cleaner.
>>>>>
>>>>> Signed-Off-By: Daniel Walker dwalker@fifo99.com
>>>>>
>>>>> diff --git a/Documentation/x86/earlyprintk.txt b/Documentation/x86/earlyprintk.txt
>>>>> index 607b1a0..5b51aef 100644
>>>>> --- a/Documentation/x86/earlyprintk.txt
>>>>> +++ b/Documentation/x86/earlyprintk.txt
>>>>> @@ -9,7 +9,9 @@ and two USB cables, connected like this:
>>>>>  
>>>>>  1. There are three specific hardware requirements:
>>>>>  
>>>>> - a.) Host/target system needs to have USB debug port capability.
>>>>> + a.) You will need two USB ports. One on the client/console system and one one the target system.
>>>> s/one one/one on/
>>> Check.
>>>
>>>> You might also try harder to observe the 80-column rule.
>>> I wasn't aware it applied to documents ..
>> Yes, it does.
>>
> 
> Shall we add that to a document style guide? There's several other docs
> that don't conform to that..

Do we have a document style guide?  The comments in Documentation/CodingStyle
apply to documentation text files also, AFAIK.  Maybe that needs to be
stated explicitly.

As for other docs that don't conform:  we typically don't go around just
fixing 80-column rule infractions, but when a file is being modified anyway,
we prefer that other parts of it also be updated.

Thanks,
-- 
~Randy

Re: [tip:x86/doc] x86/doc: mini-howto for using earlyprintk=dbgp

[Daniel Walker]

On Thu, 2009-03-05 at 15:19 -0800, Randy Dunlap wrote:

> Do we have a document style guide?  The comments in Documentation/CodingStyle
> apply to documentation text files also, AFAIK.  Maybe that needs to be
> stated explicitly.

I guess you could assume it applies, but I don't think it's content can
really be applied to Documents.. Since it speaks specifically to code.

> As for other docs that don't conform:  we typically don't go around just
> fixing 80-column rule infractions, but when a file is being modified anyway,
> we prefer that other parts of it also be updated.

I don't have a problem fixing it, but it would be nice to have any other
rules layed out. Like the "No ascii art rule" (if it exists) or whatever
other style guidelines there are. For example the 80 line limit can't
apply to absolutely everything. I mean what about diagrams or /proc
output samples? Most of that is over 80 (way over).

Daniel

Re: [tip:x86/doc] x86/doc: mini-howto for using earlyprintk=dbgp

[Randy Dunlap]

Daniel Walker wrote:
> On Thu, 2009-03-05 at 15:19 -0800, Randy Dunlap wrote:
> 
>> Do we have a document style guide?  The comments in Documentation/CodingStyle
>> apply to documentation text files also, AFAIK.  Maybe that needs to be
>> stated explicitly.
> 
> I guess you could assume it applies, but I don't think it's content can
> really be applied to Documents.. Since it speaks specifically to code.

OK.  Historically we have applied the 80-column rule to text files,
including documentation.  But we haven't documented that.

>> As for other docs that don't conform:  we typically don't go around just
>> fixing 80-column rule infractions, but when a file is being modified anyway,
>> we prefer that other parts of it also be updated.
> 
> I don't have a problem fixing it, but it would be nice to have any other
> rules layed out. Like the "No ascii art rule" (if it exists) or whatever
> other style guidelines there are. For example the 80 line limit can't
> apply to absolutely everything. I mean what about diagrams or /proc
> output samples? Most of that is over 80 (way over).

If you have time to make a proposal for all such rules, please go ahead.
I don't have time for it just now.

Yes, some examples, diagrams, samples, etc. are over 80 columns.
It's not a diehard rule.

And there is no rule against ASCII art AFAIK.

-- 
~Randy

Re: [tip:x86/doc] x86/doc: mini-howto for using earlyprintk=dbgp

[Daniel Walker]

On Thu, 2009-03-05 at 15:41 -0800, Randy Dunlap wrote:

> If you have time to make a proposal for all such rules, please go ahead.
> I don't have time for it just now.

I don't know what kind of rules there are .. The 80 columns thing was
new to me.

> Yes, some examples, diagrams, samples, etc. are over 80 columns.
> It's not a diehard rule.

With code it sort of is die hard , even tho the CodingStyle doesn't
specify it that way.

Daniel

Re: [tip:x86/doc] x86/doc: mini-howto for using earlyprintk=dbgp

[Alan Stern]

On Thu, 5 Mar 2009, Daniel Walker wrote:

> On Thu, 2009-03-05 at 15:41 -0800, Randy Dunlap wrote:
> 
> > If you have time to make a proposal for all such rules, please go ahead.
> > I don't have time for it just now.
> 
> I don't know what kind of rules there are .. The 80 columns thing was
> new to me.

In general, every rule in CodingStyle that _can_ apply to plain text 
documents _should_ apply.  There aren't very many that _can_ apply, 
however.  The 80-column rule may be the only one.

> > Yes, some examples, diagrams, samples, etc. are over 80 columns.
> > It's not a diehard rule.
> 
> With code it sort of is die hard , even tho the CodingStyle doesn't
> specify it that way.

It is _not_ diehard, at least not according to Linus.  He has posted a 
couple of messages expressing his opinion that overall readability is 
more important than sticking rigidly to 80 columns.

Alan Stern

Re: [tip:x86/doc] x86/doc: mini-howto for using earlyprintk=dbgp

[Daniel Walker]

On Fri, 2009-03-06 at 09:57 -0500, Alan Stern wrote:

> It is _not_ diehard, at least not according to Linus.  He has posted a 
> couple of messages expressing his opinion that overall readability is 
> more important than sticking rigidly to 80 columns.

My experience has been that anyone sending over 80 columns is sure to
get slammed, just like with this document patch. So when I say it's die
hard that's what I mean. Plus we have the checkpatch clean phenomenon.
So Linus may not care but everyone else on this list does seem to care..

Daniel

Re: [tip:x86/doc] x86/doc: mini-howto for using earlyprintk=dbgp

[Alan Stern]

On Fri, 6 Mar 2009, Daniel Walker wrote:

> On Fri, 2009-03-06 at 09:57 -0500, Alan Stern wrote:
> 
> > It is _not_ diehard, at least not according to Linus.  He has posted a 
> > couple of messages expressing his opinion that overall readability is 
> > more important than sticking rigidly to 80 columns.
> 
> My experience has been that anyone sending over 80 columns is sure to
> get slammed, just like with this document patch. So when I say it's die
> hard that's what I mean. Plus we have the checkpatch clean phenomenon.
> So Linus may not care but everyone else on this list does seem to care..

Well, I wouldn't have said anything if you ran over by only a few 
characters.  But your line was 97 characters long!

Alan Stern

Re: [tip:x86/doc] x86/doc: mini-howto for using earlyprintk=dbgp

[Daniel Walker]

On Thu, 2009-03-05 at 17:54 -0500, Alan Stern wrote:
> On Thu, 5 Mar 2009, Daniel Walker wrote:
> 
> > Fix up some typos, and make the requirements section slightly cleaner.
> > 
> > Signed-Off-By: Daniel Walker dwalker@fifo99.com
> > 
> > diff --git a/Documentation/x86/earlyprintk.txt b/Documentation/x86/earlyprintk.txt
> > index 607b1a0..5b51aef 100644
> > --- a/Documentation/x86/earlyprintk.txt
> > +++ b/Documentation/x86/earlyprintk.txt
> > @@ -9,7 +9,9 @@ and two USB cables, connected like this:
> >  
> >  1. There are three specific hardware requirements:
> >  
> > - a.) Host/target system needs to have USB debug port capability.
> > + a.) You will need two USB ports. One on the client/console system and one one the target system.
> 
> s/one one/one on/
> 
> You might also try harder to observe the 80-column rule.
> 
> > + 
> > + b.) The client/console and target USB ports must have the debug port capability.
> >  
> >   You can check this capability by looking at a 'Debug port' bit in
> >   the lspci -vvv output:
> > @@ -35,15 +37,13 @@ and two USB cables, connected like this:
> >  ( If your system does not list a debug port capability then you probably
> >    wont be able to use the USB debug key. )
> >  
> > - b.) You also need a Netchip USB debug cable/key:
> > + c.) You also need a Netchip USB debug cable/key:
> >  
> >          http://www.plxtech.com/products/NET2000/NET20DC/default.asp
> >  
> >       This is a small blue plastic connector with two USB connections,
> >       it draws power from its USB connections.
> 
> No.  It draws power from one of its USB connections (the one on the 
> right side when you're looking at the face with the PLX logo).
> 
> Alan Stern

--

Fix up some typos, and make the requirements section slightly cleaner.
Updated the power draw comment per Alan Stern.

Signed-Off-By: Daniel Walker <dwalker@fifo99.com>

diff --git a/Documentation/x86/earlyprintk.txt b/Documentation/x86/earlyprintk.txt
index 607b1a0..ac913a6 100644
--- a/Documentation/x86/earlyprintk.txt
+++ b/Documentation/x86/earlyprintk.txt
@@ -9,7 +9,11 @@ and two USB cables, connected like this:
 
 1. There are three specific hardware requirements:
 
- a.) Host/target system needs to have USB debug port capability.
+ a.) You will need two USB ports. One on the client/console system and one on 
+     the target system.
+ 
+ b.) The client/console and target USB ports must have the debug port
+     capability.
 
  You can check this capability by looking at a 'Debug port' bit in
  the lspci -vvv output:
@@ -35,14 +39,13 @@ and two USB cables, connected like this:
 ( If your system does not list a debug port capability then you probably
   wont be able to use the USB debug key. )
 
- b.) You also need a Netchip USB debug cable/key:
+ c.) You also need a Netchip USB debug cable/key:
 
         http://www.plxtech.com/products/NET2000/NET20DC/default.asp
 
      This is a small blue plastic connector with two USB connections,
-     it draws power from its USB connections.
-
- c.) Thirdly, you need a second client/console system with a regular USB port.
+     it draws power from one of its USB connections (the one on the 
+     right side when you're looking at the face with the PLX logo).
 
 2. Software requirements:
 
@@ -54,7 +57,7 @@ and two USB cables, connected like this:
 
     And you need to add the boot command line: "earlyprintk=dbgp".
     (If you are using Grub, append it to the 'kernel' line in
-     /etc/grub.conf)
+     grub.conf (i.e. /boot/grub/grub.conf) )
 
     NOTE: normally earlyprintk console gets turned off once the
     regular console is alive - use "earlyprintk=dbgp,keep" to keep
@@ -72,7 +75,7 @@ and two USB cables, connected like this:
 
     Now this channel of kernel messages is ready to be used: start
     your favorite terminal emulator (minicom, etc.) and set
-    it up to use /dev/ttyUSB0 - or use a raw 'cat /dev/ttyUSBx' to
+    it up to use /dev/ttyUSBx - or use a raw 'cat /dev/ttyUSBx' to
     see the raw output.
 
  c.) On Nvidia Southbridge based systems: the kernel will try to probe
@@ -92,7 +95,7 @@ and two USB cables, connected like this:
 
    On the client/console system do:
 
-       cat /dev/ttyUSB0
+       cat /dev/ttyUSBx
 
    And you should see the help line above displayed shortly after you've
    provoked it on the host system.

Re: [tip:x86/doc] x86/doc: mini-howto for using earlyprintk=dbgp

[Randy Dunlap]

Daniel Walker wrote:
> On Thu, 2009-03-05 at 17:54 -0500, Alan Stern wrote:
>> On Thu, 5 Mar 2009, Daniel Walker wrote:
>>
>>> Fix up some typos, and make the requirements section slightly cleaner.
>>>
>>> Signed-Off-By: Daniel Walker dwalker@fifo99.com
>>>
>>> diff --git a/Documentation/x86/earlyprintk.txt b/Documentation/x86/earlyprintk.txt
>>> index 607b1a0..5b51aef 100644
>>> --- a/Documentation/x86/earlyprintk.txt
>>> +++ b/Documentation/x86/earlyprintk.txt
>>> @@ -9,7 +9,9 @@ and two USB cables, connected like this:
>>>  
>>>  1. There are three specific hardware requirements:
>>>  
>>> - a.) Host/target system needs to have USB debug port capability.
>>> + a.) You will need two USB ports. One on the client/console system and one one the target system.
>> s/one one/one on/
>>
>> You might also try harder to observe the 80-column rule.
>>
>>> + 
>>> + b.) The client/console and target USB ports must have the debug port capability.
>>>  
>>>   You can check this capability by looking at a 'Debug port' bit in
>>>   the lspci -vvv output:
>>> @@ -35,15 +37,13 @@ and two USB cables, connected like this:
>>>  ( If your system does not list a debug port capability then you probably
>>>    wont be able to use the USB debug key. )
>>>  
>>> - b.) You also need a Netchip USB debug cable/key:
>>> + c.) You also need a Netchip USB debug cable/key:
>>>  
>>>          http://www.plxtech.com/products/NET2000/NET20DC/default.asp
>>>  
>>>       This is a small blue plastic connector with two USB connections,
>>>       it draws power from its USB connections.
>> No.  It draws power from one of its USB connections (the one on the 
>> right side when you're looking at the face with the PLX logo).
>>
>> Alan Stern
> 
> --
> 
> Fix up some typos, and make the requirements section slightly cleaner.
> Updated the power draw comment per Alan Stern.
> 
> Signed-Off-By: Daniel Walker <dwalker@fifo99.com>
> 
> diff --git a/Documentation/x86/earlyprintk.txt b/Documentation/x86/earlyprintk.txt
> index 607b1a0..ac913a6 100644
> --- a/Documentation/x86/earlyprintk.txt
> +++ b/Documentation/x86/earlyprintk.txt
> @@ -9,7 +9,11 @@ and two USB cables, connected like this:
>  
>  1. There are three specific hardware requirements:
>  
> - a.) Host/target system needs to have USB debug port capability.
> + a.) You will need two USB ports. One on the client/console system and one on 
> +     the target system.
> + 
> + b.) The client/console and target USB ports must have the debug port
> +     capability.

Is that correct on the (ugh, I think that the naming/terminology is
still mucked up, but you didn't do that) host/target system?

On the client/console (which I would call the host and I would call the
"Host/target" here just the Target system), a USB debug port is needed,
but on the Host/target, it should just look like a USB device.
At least that was the intent AFAIK/IIRC.  No?


-- 
~Randy

Re: [tip:x86/doc] x86/doc: mini-howto for using earlyprintk=dbgp

[Daniel Walker]

On Thu, 2009-03-05 at 15:59 -0800, Randy Dunlap wrote:

> > - a.) Host/target system needs to have USB debug port capability.
> > + a.) You will need two USB ports. One on the client/console system and one on 
> > +     the target system.
> > + 
> > + b.) The client/console and target USB ports must have the debug port
> > +     capability.
> 
> Is that correct on the (ugh, I think that the naming/terminology is
> still mucked up, but you didn't do that) host/target system?
> 
> On the client/console (which I would call the host and I would call the
> "Host/target" here just the Target system), a USB debug port is needed,
> but on the Host/target, it should just look like a USB device.
> At least that was the intent AFAIK/IIRC.  No?
> 

>From the rest of document I assumed Host/target was referring to both
sides of the connection. So you would need USB on both sides for this
thing to work. I assumed Client/console was just the host. I guess that
is all kind of confusing tho ..

Daniel

Re: [tip:x86/doc] x86/doc: mini-howto for using earlyprintk=dbgp

[Alan Stern]

On Thu, 5 Mar 2009, Daniel Walker wrote:

> On Thu, 2009-03-05 at 15:59 -0800, Randy Dunlap wrote:
> 
> > > - a.) Host/target system needs to have USB debug port capability.
> > > + a.) You will need two USB ports. One on the client/console system and one on 
> > > +     the target system.
> > > + 
> > > + b.) The client/console and target USB ports must have the debug port
> > > +     capability.
> > 
> > Is that correct on the (ugh, I think that the naming/terminology is
> > still mucked up, but you didn't do that) host/target system?
> > 
> > On the client/console (which I would call the host and I would call the
> > "Host/target" here just the Target system), a USB debug port is needed,
> > but on the Host/target, it should just look like a USB device.
> > At least that was the intent AFAIK/IIRC.  No?
> > 
> 
> >From the rest of document I assumed Host/target was referring to both
> sides of the connection. So you would need USB on both sides for this
> thing to work. I assumed Client/console was just the host. I guess that
> is all kind of confusing tho ..

The term "Host" is too confusing to be used here; it has too many other 
meanings.  "Target" is good.

"Client" is probably okay too, but I don't like "Console" so much
because both machines will have a console.  "Debugging console" is more
accurate but also more cumbersome.

> The document indicates you need this one capability on your USB port in
> addition to the USB device (check the complete document for how to find
> the capability). So both host and target need this one capability, and
> then you also need the USB device for the whole thing to work.

In fact the original document was rather clear about this; it says only
that the target machine needs the debug capability.  The client machine 
uses its normal USB driver and treats the debugging cable as a normal 
USB serial device.

Alan Stern

Re: [tip:x86/doc] x86/doc: mini-howto for using earlyprintk=dbgp

[Ingo Molnar]

* Alan Stern <stern@rowland.harvard.edu> wrote:

> On Thu, 5 Mar 2009, Daniel Walker wrote:
> 
> > On Thu, 2009-03-05 at 15:59 -0800, Randy Dunlap wrote:
> > 
> > > > - a.) Host/target system needs to have USB debug port capability.
> > > > + a.) You will need two USB ports. One on the client/console system and one on 
> > > > +     the target system.
> > > > + 
> > > > + b.) The client/console and target USB ports must have the debug port
> > > > +     capability.
> > > 
> > > Is that correct on the (ugh, I think that the naming/terminology is
> > > still mucked up, but you didn't do that) host/target system?
> > > 
> > > On the client/console (which I would call the host and I would call the
> > > "Host/target" here just the Target system), a USB debug port is needed,
> > > but on the Host/target, it should just look like a USB device.
> > > At least that was the intent AFAIK/IIRC.  No?
> > > 
> > 
> > >From the rest of document I assumed Host/target was referring to both
> > sides of the connection. So you would need USB on both sides for this
> > thing to work. I assumed Client/console was just the host. I guess that
> > is all kind of confusing tho ..
> 
> The term "Host" is too confusing to be used here; it has too 
> many other meanings.  "Target" is good.

I used Host/Target for that reason, consistently so. The combo 
gives us the best of both worlds.

> "Client" is probably okay too, but I don't like "Console" so 
> much because both machines will have a console.  "Debugging 
> console" is more accurate but also more cumbersome.

I used client/console term for that reason.

> > The document indicates you need this one capability on your 
> > USB port in addition to the USB device (check the complete 
> > document for how to find the capability). So both host and 
> > target need this one capability, and then you also need the 
> > USB device for the whole thing to work.
> 
> In fact the original document was rather clear about this; it 
> says only that the target machine needs the debug capability.  
> The client machine uses its normal USB driver and treats the 
> debugging cable as a normal USB serial device.

yes.

btw., i think this document is being over-engineered. 
Significantly so.

	Ingo

Re: [tip:x86/doc] x86/doc: mini-howto for using earlyprintk=dbgp

[Daniel Walker]

On Fri, 2009-03-06 at 16:55 +0100, Ingo Molnar wrote:

> > > 
> > > >From the rest of document I assumed Host/target was referring to both
> > > sides of the connection. So you would need USB on both sides for this
> > > thing to work. I assumed Client/console was just the host. I guess that
> > > is all kind of confusing tho ..
> > 
> > The term "Host" is too confusing to be used here; it has too 
> > many other meanings.  "Target" is good.
> 
> I used Host/Target for that reason, consistently so. The combo 
> gives us the best of both worlds.

What meaning of Host did you intend? Is Host/Target just referring to
one machine in this scenario or both?

> > "Client" is probably okay too, but I don't like "Console" so 
> > much because both machines will have a console.  "Debugging 
> > console" is more accurate but also more cumbersome.
> 
> I used client/console term for that reason.

Same questions for this as above, one machine or both? I think it's
clear from the text when you read it all (not to mention this doesn't
seem like a sophisticated setup), but if someone had trouble with this
they might start reading into the terms and get more confused.

> > > The document indicates you need this one capability on your 
> > > USB port in addition to the USB device (check the complete 
> > > document for how to find the capability). So both host and 
> > > target need this one capability, and then you also need the 
> > > USB device for the whole thing to work.
> > 
> > In fact the original document was rather clear about this; it 
> > says only that the target machine needs the debug capability.  
> > The client machine uses its normal USB driver and treats the 
> > debugging cable as a normal USB serial device.
> 
> yes.
> 
> btw., i think this document is being over-engineered. 
> Significantly so.

I agree (but what are you going to do?)

Daniel

Re: [tip:x86/doc] x86/doc: mini-howto for using earlyprintk=dbgp

[Daniel Walker]

On Thu, 2009-03-05 at 15:59 -0800, Randy Dunlap wrote:

> Is that correct on the (ugh, I think that the naming/terminology is
> still mucked up, but you didn't do that) host/target system?
> 
> On the client/console (which I would call the host and I would call the
> "Host/target" here just the Target system), a USB debug port is needed,
> but on the Host/target, it should just look like a USB device.
> At least that was the intent AFAIK/IIRC.  No?
> 

The document indicates you need this one capability on your USB port in
addition to the USB device (check the complete document for how to find
the capability). So both host and target need this one capability, and
then you also need the USB device for the whole thing to work.

Daniel

Re: EHCI debug documentation

[Greg KH]

On Wed, Mar 04, 2009 at 04:59:28PM -0500, Alan Stern wrote:
> On Wed, 4 Mar 2009, Eric W. Biederman wrote:
> 
> > Greg KH <gregkh@suse.de> writes:
> > 
> > > * Randy Dunlap <randy.dunlap@oracle.com> wrote:
> > >> Yinghai Lu wrote:
> > >> > b. netchip USB debug cable
> > >> 
> > >> http://www.plxtech.com/products/NET2000/NET20DC/default.asp
> > >
> > > I have reports that the newer version of this device does not work on
> > > Linux as it isn't enumeratable as a "real" usb device on one end.
> > >
> > > I don't have one of these new devices yet to test it out, has anyone
> > > else heard of this problem?
> > 
> > With the first generation of devices I remember they were peculiar and
> > finicky.  I don't recall the exact details but I remember the devices
> > able to get into weird states that may resemble what you describe.
> 
> Those devices were a little peculiar in that they were powered only on
> one side.  That is, they would take bus power only from the right-hand
> connector (looking at the face with the PLX logo).  So if you plugged
> in only the left side, the device would not show up or enumerate.  But 
> if you plugged in both sides, then both of them would enumerate okay.

Thanks for the information, I'll try to get the person that reported
this to retest and see if both sides plugged in at the same time works
better.

greg k-h

Re: EHCI debug documentation

[Sarah Sharp]

On Tue, Mar 03, 2009 at 05:31:44PM -0800, Yinghai Lu wrote:
> On Tue, Mar 3, 2009 at 3:53 PM, Sarah Sharp <sarah.a.sharp@intel.com> wrote:
> > Greetings,
> >
> > You wrote the EHCI debug port patch for early printk back in July 2008
> > (commit 5c05917e7fe313a187ad6ebb94c1c6cf42862a0b).  Can you add some
> > documentation to the Documentation directory about how a Linux user
> > would set up a system (cables, files to open to get the printks, etc.)?
> 
> please check

This documentation looks fine, aside from the two comments below.  Can
you turn it into a patch, as Ingo suggested?  Thanks!

Sarah Sharp

> ==========================================================================================
> USB Debug port using Howto
> 
> 1. HW:
> 
> a. target system need to have debug port

(I assume the following output is from you running lspci -vvv as root,
so you should mention that in your documentation).

> 00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2
> EHCI Controller #1 (rev 03) (prog-if 20 [EHCI])
>         Subsystem: Lenovo ThinkPad T61
>         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR+ FastB2B- DisINTx-
>         Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
> >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>         Latency: 0
>         Interrupt: pin D routed to IRQ 19
>         Region 0: Memory at fe227000 (32-bit, non-prefetchable) [size=1K]
>         Capabilities: [50] Power Management version 2
>                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
> PME(D0+,D1-,D2-,D3hot+,D3cold+)
>                 Status: D0 PME-Enable- DSel=0 DScale=0 PME+
>         Capabilities: [58] Debug port: BAR=1 offset=00a0
>         Kernel driver in use: ehci_hcd
>         Kernel modules: ehci-hcd

What is the following output from?  Is it useful to the user setting up
the system? How are people supposed to decrypt this?

> 00: 86 80 36 28 06 01 90 02 03 20 03 0c 00 00 00 00
> 10: 00 70 22 fe 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 aa 17 ab 20
> 30: 00 00 00 00 50 00 00 00 00 00 00 00 0b 04 00 00
> 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 50: 01 58 c2 c9 00 80 00 00 0a 00 a0 20 00 00 00 00
> 60: 20 20 9f 01 00 00 00 00 01 00 00 01 00 00 08 80
> 70: c0 00 17 3f 00 00 00 00 00 00 00 00 00 00 00 00
> 80: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
> 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> d0: 00 00 00 00 00 aa ff 00 00 00 00 00 00 00 00 00
> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> f0: 00 00 00 00 88 85 40 00 86 0f 05 00 06 17 02 20
> 
> b. netchip USB debug cable
> 
> c. console system: have USB port
> 
> 2. SW setting
> a. console system: need to have kernel config
>    CONFIG_USB_SERIAL_DEBUG
>    you should get /dev/ttyUSBx
> 
>    # cat /dev/ttyUSBx could get output
> 
> b. target system: need to have kernel config
>    CONFIG_EARLY_PRINTK_DBGP
> 
>    boot command line: earlyprintk=dbgp
> 
> c. for Nvidia Southbridge based system: kernel will try to probe and
> find out which port has debug device connected.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html