Secret diaries of a suspend/resume debugger

[Colin Ian King]

On Tue, 2010-06-22 at 11:37 +0100, Daniel J Blueman wrote:
> On Tue, Jun 22, 2010 at 11:02 AM, Lee Jones <lee.jones at canonical.com> wrote:
> >> Good story and a superb writeup.
> >>
> >> I've been using a USB debug device for console access via the EHCI
> >> debug port on legacy-free systems, and I wonder if it would prove more
> >> useful than the USB-serial mechanism in this case...
> >>
> >> It's quite handy now that support is enabled in the Maverick kernel
> >> (or should be by now), but it's a shame in that USB debug devices seem
> >> hard to find, particularly outside the US.
> >
> > Thank you Dan, that means a lot.
> >
> > Which device are you using? Do you have a web link?
> 
> This is what I have:
> http://www.semiconductorstore.com/cart/pc/viewPrd.asp?idproduct=12083
> 
> it has two NET2270 USB controllers:
> http://www.physics.utoronto.ca/~astummer/pub/mirror/Docs/Engineering/NET2270%20PlxTech,%20USB2.0%20device.pdf
> 
> and a Parallax SX28AC/SS-G microcontroller:
> http://www.parallax.com/dl/docs/prod/datast/SX20AC-SX28AC-Data-v1.6.pdf
> 
> Perhaps they are rarer due to the complexity and reliance on (now
> deprecated) parts...
> 
> > To be honest, I think it would suffer in the same way as my USB->Serial device.
> >
> > Once USB is put to sleep, all bets are off.
> 
> Since this is used for early printk, it is simple and thus robust (by
> virtue of needing only the console lock IIRC). Preventing USB PHY
> power-down may by sufficient to catch all the console output across
> pre and post-suspend.
> 
> Dan
> -- 
> Daniel J Blueman
> 

Thanks Daniel, I too have used this kit, here are my notes from my
experimentation back in late 2009:

---

Long Summary...

1) After a lot of hacking around, I got the debug kit to work; there are
some problems with the USB earlyprintk driver code - namely it does a
lot of register polling without taking into consideration the speed of
the system, hence I was getting timeouts and not being able to reset or
configure the EHCI debug USB port. However, after putting in some hacky
delays in, I've got it up and running.

Issues:

a) About 50% of the time one needs to unplug/replug the USB cables from
the target machine for the reset to work correctly.  This is quite poor
- one never is certain if one has the USB cable connected reliably or
not, and it makes debugging a painful exercise.

b) Early printk messages can be capture on the host side using minicom
capturing /dev/ttyUSB0 - note that the usb_debug module needs to be
loaded on the host for this to work. Unfortunately plugging/unplugging
the USB cable on the target machine means that the USB connection on the
minicom host side is disconnected, and one has to exit and restart
minicom each time ==> a pain.

c) The 2.6.31 kernel hangs on later in the boot doing the USB config -
so this method of debugging has limited use - e.g. for early kernel
boots.

d) The target machine needs to support the USB debug port capability -
however, all the 4 laptops I checked seem to support this.

It's quite awkward to set up and configure - one needs to work through
all the available USB ports on a the target machine to find out which
one is configured up as the USB debug port.  I found the earlyprintk
driver had some debug built in which has to be enabled with: 
#define DBGP_DEBUG 1

This then dumps debug to the console. This is ironic since at this point
in the kernel initialisation I can now debug the kernel without the need
of the USB debug kit(!). Anyhow, enabling this then dumps out messages
stating if the USB port reset failed or not, and enables one to finally
find out which USB port can be used for USB debug.

The documentation to this method of debug is located in the kernel tree,
under Documentation/x86/earlyprintk.txt 

----

Perhaps things are more reliable now with 2.6.35. I need to re-try this
when I have a spare moment.

Colin