On Tue, Mar 3, 2009 at 3:53 PM, Sarah Sharp <[email protected]> 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.
Yinghai Lu wrote:
> On Tue, Mar 3, 2009 at 3:53 PM, Sarah Sharp <[email protected]> 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
* Randy Dunlap <[email protected]> wrote:
> Yinghai Lu wrote:
> > On Tue, Mar 3, 2009 at 3:53 PM, Sarah Sharp <[email protected]> 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
* Randy Dunlap <[email protected]> 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
Greg KH <[email protected]> writes:
> * Randy Dunlap <[email protected]> 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
On Wed, 4 Mar 2009, Eric W. Biederman wrote:
> Greg KH <[email protected]> writes:
>
> > * Randy Dunlap <[email protected]> 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
On Tue, Mar 03, 2009 at 05:31:44PM -0800, Yinghai Lu wrote:
> On Tue, Mar 3, 2009 at 3:53 PM, Sarah Sharp <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Mar 04, 2009 at 04:59:28PM -0500, Alan Stern wrote:
> On Wed, 4 Mar 2009, Eric W. Biederman wrote:
>
> > Greg KH <[email protected]> writes:
> >
> > > * Randy Dunlap <[email protected]> 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
Impact: doc
simple using howto for earlyprintk=dbgp
Signed-off-by: Yinghai Lu <[email protected]>
---
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.
+
On Wed, Mar 04, 2009 at 04:59:28PM -0500, Alan Stern wrote:
> On Wed, 4 Mar 2009, Eric W. Biederman wrote:
>
> > Greg KH <[email protected]> writes:
> >
> > > * Randy Dunlap <[email protected]> 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
Commit-ID: a1aade478862fca8710904532cbc6efed97fd05a
Gitweb: http://git.kernel.org/tip/a1aade478862fca8710904532cbc6efed97fd05a
Author: "Yinghai Lu" <[email protected]>
AuthorDate: Wed, 4 Mar 2009 16:11:35 -0800
Commit: Ingo Molnar <[email protected]>
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 <[email protected]>
Cc: "Eric W. Biederman" <[email protected]>
Cc: Greg KH <[email protected]>
Cc: Randy Dunlap <[email protected]>
Cc: Alan Stern <[email protected]>
Cc: Sarah Sharp <[email protected]>
Cc: Andrew Morton <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
---
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 [email protected]
+mailing list or contact the x86 maintainers.
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
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
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 [email protected]
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.
On Thu, 5 Mar 2009, Daniel Walker wrote:
> Fix up some typos, and make the requirements section slightly cleaner.
>
> Signed-Off-By: Daniel Walker [email protected]
>
> 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
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 [email protected]
> >
> > 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
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 [email protected]
>>>
>>> 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
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 [email protected]
> >>>
> >>> 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
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 [email protected]
>>>>>
>>>>> 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
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
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
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
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 [email protected]
> >
> > 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 <[email protected]>
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.
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 [email protected]
>>>
>>> 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 <[email protected]>
>
> 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
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
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
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
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
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
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
* Alan Stern <[email protected]> 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
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