Re: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
On Wednesday 06 December 2006 1:24 pm, Andi Kleen wrote: > > - Host, to which that console connects (through the debug device); > > runs usb_debug, much like any other usb-serial device > > My understanding was that the client could run in user > space only on top of libusb. I suppose it could, if you didn't want to use it like a normal serial consoe. > > It's analagous to debugging an embedded box using a serial console > > with a Linux host ... except the target here is a PC, not an ARM > > (or PPC, MIPS, etc) custom board. > > > > > > Once the coexistence issues between the debug port and normal EHCI > > driver get worked, there's no reason not to keep using that debug > > port as a system console. > > One reason is the one I covered in my last mail -- locking of the PCI > type 1 ports. That'd be part of coexistence. The debug port is _designed_ to share two different drivers like that ... EHCI can see, as it comes up, whether the debug port is in use, and could then ignore it. (At least, unless/until the debug device gets removed.) - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
> > However I suppose it would be ok to switch Eric's code between early > > pci access and locked one once the PCI subsystem is up and running. > > Just don't forget bust_spinlocks() > > No pci access on that path. Hmm good point. Ok ignore that then. keep should be default then. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
Andi Kleen <[EMAIL PROTECTED]> writes: > \ >> - Host, to which that console connects (through the debug device); >> runs usb_debug, much like any other usb-serial device > > My understanding was that the client could run in user > space only on top of libusb. Looks like a normal serial port with greg's patch. I still need to try it though. > One reason is the one I covered in my last mail -- locking of the PCI > type 1 ports. > > However I suppose it would be ok to switch Eric's code between early > pci access and locked one once the PCI subsystem is up and running. > Just don't forget bust_spinlocks() No pci access on that path. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
\ > - Host, to which that console connects (through the debug device); > runs usb_debug, much like any other usb-serial device My understanding was that the client could run in user space only on top of libusb. > > It's analagous to debugging an embedded box using a serial console > with a Linux host ... except the target here is a PC, not an ARM > (or PPC, MIPS, etc) custom board. > > > Once the coexistence issues between the debug port and normal EHCI > driver get worked, there's no reason not to keep using that debug > port as a system console. One reason is the one I covered in my last mail -- locking of the PCI type 1 ports. However I suppose it would be ok to switch Eric's code between early pci access and locked one once the PCI subsystem is up and running. Just don't forget bust_spinlocks() -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
> > or usb_debug that Greg just added > > Ah I didn't notice that. If there is a usb_debug that works later > then yes it would need to be disabled. I detect confusion here ... remember that there are potentially two distinct Linux systems involved here: - Target, with some kind of console hooked up to the debug device; runs this _new_ "early debug port" code. - Host, to which that console connects (through the debug device); runs usb_debug, much like any other usb-serial device It's analagous to debugging an embedded box using a serial console with a Linux host ... except the target here is a PC, not an ARM (or PPC, MIPS, etc) custom board. Once the coexistence issues between the debug port and normal EHCI driver get worked, there's no reason not to keep using that debug port as a system console. Heck, being able to do that might be a huge win with some of the nasty suspend/resume problems we've got. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
Andi Kleen <[EMAIL PROTECTED]> writes: > On Wednesday 06 December 2006 21:43, Lu, Yinghai wrote: >> -Original Message- >> From: Andi Kleen [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, December 06, 2006 9:31 AM >> >> >Also for usb console keep should be made default because the output >> won't >> >be duplicated. >> >> Still need to tx_read to make console can take command? >> >> Or transfer to generic usb_serial > > I think the protocols are incompatible? > >> or usb_debug that Greg just added > > Ah I didn't notice that. If there is a usb_debug that works later > then yes it would need to be disabled. > > However I see a certain advantage to keep using the early > usb console because it doesn't need any interrupts. So when the > kernel is very confused after an oops it might have a higher > chance to still get the oops out. > > I haven't looked how the other usb_debug works -- if it's polled > too then it wouldn't have much advantage. > > Ok one advantage of a non early usb_debug is that it will properly use pci > config space locking. The early implementation just ignores the port cf8 > lock which might lead to corruption later. That's ok after > an oops, but during normal output it can actually lead to > data corruption if it interferes with somebody else's config write. > Also on some systems cf8 is broken and doesn't work. > > Disadvantage of using the locks of course is that it can deadlock > if an oops happen inside the critical region. So they might need > to be added to bust_spinlocks() > > And it would be good if the late usb_debug still wouldn't rely > on interrupts. > > But I agree it's probably better to transition to another usb_debug > console and not do keep by default. The only use of the early pci code is for finding the hardware. Everything else is through mmio. The practical issue is that during the normal initialization of the ehci the reset of the hardware state is going to remove the delegation to the ehci debug registers. Greg's current thing uses the hardware but through the normal interrupt driven usb methods. I think it is worth using the ehci debug registers if possible as that (except for reset) gives us independent control of what is going on. For understanding what needs to happen except for the initialization just look at my dbgp_bulk_write routine. That and the functions it call is the only code in there that is executed. It is just a hair more complicated than other early debug port code because it has to deal with retransmits. But I think it is still under 100 lines of code. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
-Original Message- From: Andi Kleen [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 06, 2006 12:59 PM >I haven't looked how the other usb_debug works -- if it's polled >too then it wouldn't have much advantage. Need to verify if the two sides of debug cable are identical. >And it would be good if the late usb_debug still wouldn't rely >on interrupts. Yes, esp. when usb can not get irq assigned correctly. YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
On Wednesday 06 December 2006 21:43, Lu, Yinghai wrote: > -Original Message- > From: Andi Kleen [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 06, 2006 9:31 AM > > >Also for usb console keep should be made default because the output > won't > >be duplicated. > > Still need to tx_read to make console can take command? > > Or transfer to generic usb_serial I think the protocols are incompatible? > or usb_debug that Greg just added Ah I didn't notice that. If there is a usb_debug that works later then yes it would need to be disabled. However I see a certain advantage to keep using the early usb console because it doesn't need any interrupts. So when the kernel is very confused after an oops it might have a higher chance to still get the oops out. I haven't looked how the other usb_debug works -- if it's polled too then it wouldn't have much advantage. Ok one advantage of a non early usb_debug is that it will properly use pci config space locking. The early implementation just ignores the port cf8 lock which might lead to corruption later. That's ok after an oops, but during normal output it can actually lead to data corruption if it interferes with somebody else's config write. Also on some systems cf8 is broken and doesn't work. Disadvantage of using the locks of course is that it can deadlock if an oops happen inside the critical region. So they might need to be added to bust_spinlocks() And it would be good if the late usb_debug still wouldn't rely on interrupts. But I agree it's probably better to transition to another usb_debug console and not do keep by default. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
-Original Message- From: Andi Kleen [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 06, 2006 9:31 AM >Also for usb console keep should be made default because the output won't >be duplicated. Still need to tx_read to make console can take command? Or transfer to generic usb_serial or usb_debug that Greg just added with console=ttyUSB0 to get tty? Then you still need to disable that early_console sometime later. YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
On Tuesday 05 December 2006 12:01, Eric W. Biederman wrote: > > Ok due to popular demands here is the slightly fixed patch that works > on both i386 and x86_64. For the i386 version you must not have > HIGHMEM64G enabled. > > I just rolled it all into one patch as I'm to lazy to transmit all > 3 of them. You should definitely move the usb code to a separate file Documentation/* needs to document the new option Also for usb console keep should be made default because the output won't be duplicated. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
David Brownell <[EMAIL PROTECTED]> writes: > On Sunday 03 December 2006 9:09 pm, Eric W. Biederman wrote: >> >> 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. > > I'm glad to see someone finally got progress on this ... :) > > Separately, I forwarded some stuff I did last year ... maybe it'll help. > You seem to have gotten further. Have you also observed that the > NetChip device seems to have polarity issues, such that only one > end behaves properly? I haven't yet. But I don't think I have actually tried turning the cable around in a very meaningful way yet either. Possibly this is something that has been fixed. I know there are some odd issues that I have encountered. Like occasionally I would need to stop the software on one side, or I would need to unplug it when things got sufficiently confused. > Note that this should **NOT** be specific to x86_64, since pretty > much any PCI based EHCI can do this. I wouldn't be able to use > this on my NForce2 box, for example ... So I took a quick look what it would take to do this truly generically and even initializing this generally when console code typically is registered looks like a problem. Although only because we don't get around to setting up pci_config space access helpers in a timely manner. To some extent that still sucks because you are still being initialized before the general ehci-hcd code. Regardless an arch specific i386 variant was easy to throw together. It still needs a bit of work but it basically worked. > As for EHCI registers, if this really _needs_ to live outside > of drivers/usb/host, then I'd suggest for > the relevant declarations ... the headers are > provided exactly for sharing such declaration between otherwise > unrelated parts of the tree. Yep that sounds like the right thing to do. I think I at least need to be called from something outside of drivers/usb and may need the code there. Doing this in a truly generic fashion looks like a major pain. Because all of the infrastructure needs to be fixed. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
Ok due to popular demands here is the slightly fixed patch that works
on both i386 and x86_64. For the i386 version you must not have
HIGHMEM64G enabled.
I just rolled it all into one patch as I'm to lazy to transmit all
3 of them.
Eric
arch/i386/kernel/head.S |8 +
arch/x86_64/kernel/early_printk.c | 580 +
arch/x86_64/kernel/head.S | 11 +-
drivers/usb/host/ehci.h |8 +
include/asm-i386/fixmap.h |1 +
include/asm-x86_64/fixmap.h |1 +
6 files changed, 608 insertions(+), 1 deletions(-)
diff --git a/arch/i386/kernel/head.S b/arch/i386/kernel/head.S
index ca31f18..f683565 100644
--- a/arch/i386/kernel/head.S
+++ b/arch/i386/kernel/head.S
@@ -135,6 +135,12 @@ page_pde_offset = (__PAGE_OFFSET >> 20);
jb 10b
movl %edi,(init_pg_tables_end - __PAGE_OFFSET)
+ /* Do an early initialization of the fixmap area */
+ movl $(swapper_pg_dir - __PAGE_OFFSET), %edx
+ movl $(swapper_pg_pmd - __PAGE_OFFSET), %eax
+ addl $0x007, %eax /* 0x007 = PRESENT+RW+USER */
+ movl %eax, 4092(%edx)
+
#ifdef CONFIG_SMP
xorl %ebx,%ebx /* This is the boot CPU (BSP) */
jmp 3f
@@ -477,6 +483,8 @@ ENTRY(_stext)
.section ".bss.page_aligned","w"
ENTRY(swapper_pg_dir)
.fill 1024,4,0
+ENTRY(swapper_pg_pmd)
+ .fill 1024,4,0
ENTRY(empty_zero_page)
.fill 4096,1,0
diff --git a/arch/x86_64/kernel/early_printk.c
b/arch/x86_64/kernel/early_printk.c
index d4050a5..71f2f88 100644
--- a/arch/x86_64/kernel/early_printk.c
+++ b/arch/x86_64/kernel/early_printk.c
@@ -3,9 +3,19 @@
#include
#include
#include
+#include
+#include
+#include
+#include
#include
#include
#include
+#include
+#include
+#include
+#define EARLY_PRINTK
+#include "../../../drivers/usb/host/ehci.h"
+
/* Simple VGA output */
@@ -155,6 +165,564 @@ static struct console early_serial_console = {
.index =-1,
};
+
+static struct ehci_caps __iomem *ehci_caps;
+static struct ehci_regs __iomem *ehci_regs;
+static struct ehci_dbg_port __iomem *ehci_debug;
+static unsigned dbgp_endpoint_out;
+
+#define USB_DEBUG_DEVNUM 127
+
+#define DBGP_DATA_TOGGLE 0x8800
+#define DBGP_PID_UPDATE(x, tok) \
+ x) ^ DBGP_DATA_TOGGLE) & 0x00) | ((tok) & 0xff))
+
+#define DBGP_LEN_UPDATE(x, len) (((x) & ~0x0f) | ((len) & 0x0f))
+/*
+ * USB Packet IDs (PIDs)
+ */
+
+/* token */
+#define USB_PID_OUT0xe1
+#define USB_PID_IN 0x69
+#define USB_PID_SOF0xa5
+#define USB_PID_SETUP 0x2d
+/* handshake */
+#define USB_PID_ACK0xd2
+#define USB_PID_NAK0x5a
+#define USB_PID_STALL 0x1e
+#define USB_PID_NYET 0x96
+/* data */
+#define USB_PID_DATA0 0xc3
+#define USB_PID_DATA1 0x4b
+#define USB_PID_DATA2 0x87
+#define USB_PID_MDATA 0x0f
+/* Special */
+#define USB_PID_PREAMBLE 0x3c
+#define USB_PID_ERR0x3c
+#define USB_PID_SPLIT 0x78
+#define USB_PID_PING 0xb4
+#define USB_PID_UNDEF_00xf0
+
+#define USB_PID_DATA_TOGGLE0x88
+#define DBGP_CLAIM (DBGP_OWNER | DBGP_ENABLED | DBGP_INUSE)
+
+#define PCI_CAP_ID_EHCI_DEBUG 0xa
+
+#define HUB_ROOT_RESET_TIME50 /* times are in msec */
+#define HUB_SHORT_RESET_TIME 10
+#define HUB_LONG_RESET_TIME200
+#define HUB_RESET_TIMEOUT 500
+
+#define DBGP_MAX_PACKET8
+
+static int dbgp_wait_until_complete(void)
+{
+ unsigned ctrl;
+ for (;;) {
+ ctrl = readl(&ehci_debug->control);
+ /* Stop when the transaction is finished */
+ if (ctrl & DBGP_DONE)
+ break;
+ }
+ /* Now that we have observed the completed transaction,
+* clear the done bit.
+*/
+ writel(ctrl | DBGP_DONE, &ehci_debug->control);
+ return (ctrl & DBGP_ERROR) ? -DBGP_ERRCODE(ctrl) : DBGP_LEN(ctrl);
+}
+
+static void dbgp_mdelay(int ms)
+{
+ int i;
+ while (ms--) {
+ for (i = 0; i < 1000; i++)
+ outb(0x1, 0x80);
+ }
+}
+
+static void dbgp_breath(void)
+{
+ /* Sleep to give the debug port a chance to breathe */
+}
+
+static int dbgp_wait_until_done(unsigned ctrl)
+{
+ unsigned pids, lpid;
+ int ret;
+
+retry:
+ writel(ctrl | DBGP_GO, &ehci_debug->control);
+ ret = dbgp_wait_until_complete();
+ pids = readl(&ehci_debug->pids);
+ lpid = DBGP_PID_GET(pids);
+
+ if (ret < 0)
+ return ret;
+
+ /* If the port is getting full or it has dropped data
+* start pacing ourselves, not necessary but it's friendly.
+*/
+ if ((lpid == USB_PID_NAK) || (lpid == USB_PID_NYET))
+ dbgp_breath();
+
+ /* If I get a NACK reissue the transmission */
+ if (lpid == USB_
