linux-kernel - [RFC][PATCH 0/2] x86_64 Early usb debug port support.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 03 Dec 2006 22:09:08 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	USB development list <linux-usb-devel@...ts.sourceforge.net>
Cc:	Greg KH <gregkh@...e.de>, "Lu, Yinghai" <yinghai.lu@....com>,
	Stefan Reinauer <stepan@...esystems.de>,
	Peter Stuge <stuge-linuxbios@....org>, linuxbios@...uxbios.org,
	linux-kernel@...r.kernel.org, Andi Kleen <ak@...e.de>
Subject: [RFC][PATCH 0/2] x86_64 Early usb debug port support.

With legacy free systems serial ports have stopped being an option
to get early boot traces and other debug information out of a machine.

EHCI USB controllers provide a relatively simple debug interface
that can control port 1 of the root hub.  This interface is limited
to 8 byte packets so it can be used with most USB devices.  But with
a USB debug device this is sufficient to talk to another machine.

When the special feature of the EHCI is not enabled the port
1 of the root hub acts just like any other USB port so machines
with the necessary support are widely available.

This debug device can be used to replace serial ports for
kgdb, kdb, and console support.  And gregkh has a simple usb
serial driver for it so user space applications that control
serial ports should work unmodified.

Currently there only appears to be one manufacturer of debug
devices see:
http://www.plxtech.com/products/NET2000/NET20DC/default.asp

I think simple RS232 serial ports provide a nicer and simpler
interface but the usb debug port looks like a functional alternative
when you don't have that.

My code likely doesn't handle all of the corner cases yet, and needs
a little more work to integrate cleanly into the build.  But this
is getting it out there so other people can look and help make clean
drivers.  When writing a polling driver you do have to be careful
with your logic, because if you do things like reset a usb device at
the wrong time you can completely confuse various EHCI controllers.

My driver should be sufficient to work with any EHCI in a realatively
clean state, and needs no special BIOS support just the hardware.
This appears to be different than the way the windows drivers are
using these debug devices.

Eric

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/