Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
wakeup_level4_pgt need to be updated in addtion to boot_level4_pgt? also comment could be updated for good unstanding too. 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: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
On 12/12/06, Eric W. Biederman <[EMAIL PROTECTED]> wrote: diff --git a/arch/x86_64/kernel/head.S b/arch/x86_64/kernel/head.S index 1e6f808..2f65469 100644 --- a/arch/x86_64/kernel/head.S +++ b/arch/x86_64/kernel/head.S @@ -328,9 +328,9 @@ ENTRY(wakeup_level4_pgt) .align PAGE_SIZE ENTRY(boot_level4_pgt) .quad phys_level3_ident_pgt | 0x007 - .fill 255,8,0 + .fill 257,8,0 .quad phys_level3_physmem_pgt | 0x007 - .fill 254,8,0 + .fill 252,8,0 /* (2^48-(2*1024*1024*1024))/(2^39) = 511 */ .quad phys_level3_kernel_pgt | 0x007 Good, it seems __PAGE_OFFSET used to be 0xfff8000 and then 1<<40, and then 0xfff8100 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: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
On 12/12/06, Eric W. Biederman [EMAIL PROTECTED] wrote: diff --git a/arch/x86_64/kernel/head.S b/arch/x86_64/kernel/head.S index 1e6f808..2f65469 100644 --- a/arch/x86_64/kernel/head.S +++ b/arch/x86_64/kernel/head.S @@ -328,9 +328,9 @@ ENTRY(wakeup_level4_pgt) .align PAGE_SIZE ENTRY(boot_level4_pgt) .quad phys_level3_ident_pgt | 0x007 - .fill 255,8,0 + .fill 257,8,0 .quad phys_level3_physmem_pgt | 0x007 - .fill 254,8,0 + .fill 252,8,0 /* (2^48-(2*1024*1024*1024))/(2^39) = 511 */ .quad phys_level3_kernel_pgt | 0x007 Good, it seems __PAGE_OFFSET used to be 0xfff8000 and then 140, and then 0xfff8100 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: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
wakeup_level4_pgt need to be updated in addtion to boot_level4_pgt? also comment could be updated for good unstanding too. 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: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
"Yinghai Lu" <[EMAIL PROTECTED]> writes: > On 12/8/06, Eric W. Biederman <[EMAIL PROTECTED]> wrote: >> >> Your or I missed a bug fix/enhancement in there somewhere. >> > > I found the problem. the __set_fixmap need to __va, so the entries > will be referred from PAGE_OFFSET. > > solution will be > 1. move enable_dbgp_console from setup_early_printk, and call it from > setup_arch after init_memory_mapping. > 2. or make __set_fixmap can use __pa or pa()+__START_KERNEL_map in > addtion to _va. 3. Make __va always work. I had this in my tree and I guess it didn't get into my big rollup patch. Eric x86_64: Fix the memory mapping in the early page table diff --git a/arch/x86_64/kernel/head.S b/arch/x86_64/kernel/head.S index 1e6f808..2f65469 100644 --- a/arch/x86_64/kernel/head.S +++ b/arch/x86_64/kernel/head.S @@ -328,9 +328,9 @@ ENTRY(wakeup_level4_pgt) .align PAGE_SIZE ENTRY(boot_level4_pgt) .quad phys_level3_ident_pgt | 0x007 - .fill 255,8,0 + .fill 257,8,0 .quad phys_level3_physmem_pgt | 0x007 - .fill 254,8,0 + .fill 252,8,0 /* (2^48-(2*1024*1024*1024))/(2^39) = 511 */ .quad phys_level3_kernel_pgt | 0x007 - 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: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
On 12/8/06, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
Your or I missed a bug fix/enhancement in there somewhere.
I found the problem. the __set_fixmap need to __va, so the entries
will be referred from PAGE_OFFSET.
solution will be
1. move enable_dbgp_console from setup_early_printk, and call it from
setup_arch after init_memory_mapping.
2. or make __set_fixmap can use __pa or pa()+__START_KERNEL_map in
addtion to _va.
please check attached updated patch that is your patch plus 1.
YH
diff --git a/arch/i386/kernel/head.S b/arch/i386/kernel/head.S
index edef508..c8b1ec9 100644
--- a/arch/i386/kernel/head.S
+++ b/arch/i386/kernel/head.S
@@ -141,6 +141,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
@@ -531,6 +537,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 47b6d90..8b4c6f4 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 */
@@ -156,6 +166,562 @@ 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_OUT 0xe1
+#define USB_PID_IN 0x69
+#define USB_PID_SOF 0xa5
+#define USB_PID_SETUP 0x2d
+/* handshake */
+#define USB_PID_ACK 0xd2
+#define USB_PID_NAK 0x5a
+#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_ERR 0x3c
+#define USB_PID_SPLIT 0x78
+#define USB_PID_PING 0xb4
+#define USB_PID_UNDEF_0 0xf0
+
+#define USB_PID_DATA_TOGGLE 0x88
+#define DBGP_CLAIM (DBGP_OWNER | DBGP_ENABLED | DBGP_INUSE)
+
+#define PCI_CAP_ID_EHCI_DEBUG 0xa
+
+#define HUB_ROOT_RESET_TIME 50 /* times are in msec */
+#define HUB_SHORT_RESET_TIME 10
+#define HUB_LONG_RESET_TIME 200
+#define HUB_RESET_TIMEOUT 500
+
+#define DBGP_MAX_PACKET 8
+
+static int dbgp_wait_until_complete(void)
+{
+ unsigned ctrl;
+ for (;;) {
+ ctrl = readl(_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, _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, _debug->control);
+ ret = dbgp_wait_until_complete();
+ pids = readl(_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_PID_NAK)
+ goto retry;
+
+ return ret;
+}
+
+static void dbgp_set_data(const void *buf, int size)
+{
+ const unsigned char *bytes = buf;
+ unsigned lo, hi;
+ int i;
+ lo = hi = 0;
+ for (i = 0; i < 4 && i < size; i++)
+ lo |= bytes[i] << (8*i);
+ for (; i < 8 && i < size; i++)
+ hi |= bytes[i] << (8*(i - 4));
+ writel(lo, _debug->data03);
+ writel(hi, _debug->data47);
+}
+
+static void dbgp_get_data(void *buf, int size)
+{
+ unsigned char *bytes = buf;
+ unsigned lo, hi;
+ int i;
+ lo = readl(_debug->data03);
+ hi = readl(_debug->data47);
+ for (i = 0; i < 4 && i < size; i++)
+ bytes[i] = (lo >> (8*i)) & 0xff;
+ for (; i < 8 && i < size; i++)
+ bytes[i] = (hi >> (8*(i - 4))) & 0xff;
+}
+
+static int
Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
On 12/8/06, Eric W. Biederman [EMAIL PROTECTED] wrote:
Your or I missed a bug fix/enhancement in there somewhere.
I found the problem. the __set_fixmap need to __va, so the entries
will be referred from PAGE_OFFSET.
solution will be
1. move enable_dbgp_console from setup_early_printk, and call it from
setup_arch after init_memory_mapping.
2. or make __set_fixmap can use __pa or pa()+__START_KERNEL_map in
addtion to _va.
please check attached updated patch that is your patch plus 1.
YH
diff --git a/arch/i386/kernel/head.S b/arch/i386/kernel/head.S
index edef508..c8b1ec9 100644
--- a/arch/i386/kernel/head.S
+++ b/arch/i386/kernel/head.S
@@ -141,6 +141,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
@@ -531,6 +537,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 47b6d90..8b4c6f4 100644
--- a/arch/x86_64/kernel/early_printk.c
+++ b/arch/x86_64/kernel/early_printk.c
@@ -3,9 +3,19 @@
#include linux/init.h
#include linux/string.h
#include linux/screen_info.h
+#include linux/usb_ch9.h
+#include linux/pci_regs.h
+#include linux/pci_ids.h
+#include linux/errno.h
#include asm/io.h
#include asm/processor.h
#include asm/fcntl.h
+#include asm/pci-direct.h
+#include asm/pgtable.h
+#include asm/fixmap.h
+#define EARLY_PRINTK
+#include ../../../drivers/usb/host/ehci.h
+
/* Simple VGA output */
@@ -156,6 +166,562 @@ 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_OUT 0xe1
+#define USB_PID_IN 0x69
+#define USB_PID_SOF 0xa5
+#define USB_PID_SETUP 0x2d
+/* handshake */
+#define USB_PID_ACK 0xd2
+#define USB_PID_NAK 0x5a
+#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_ERR 0x3c
+#define USB_PID_SPLIT 0x78
+#define USB_PID_PING 0xb4
+#define USB_PID_UNDEF_0 0xf0
+
+#define USB_PID_DATA_TOGGLE 0x88
+#define DBGP_CLAIM (DBGP_OWNER | DBGP_ENABLED | DBGP_INUSE)
+
+#define PCI_CAP_ID_EHCI_DEBUG 0xa
+
+#define HUB_ROOT_RESET_TIME 50 /* times are in msec */
+#define HUB_SHORT_RESET_TIME 10
+#define HUB_LONG_RESET_TIME 200
+#define HUB_RESET_TIMEOUT 500
+
+#define DBGP_MAX_PACKET 8
+
+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_PID_NAK)
+ goto retry;
+
+ return ret;
+}
+
+static void dbgp_set_data(const void *buf, int size)
+{
+ const unsigned char *bytes = buf;
+ unsigned lo, hi;
+ int i;
+ lo = hi = 0;
+ for (i = 0; i 4 i size; i++)
+ lo |= bytes[i] (8*i);
+ for (; i 8 i size; i++)
+ hi |= bytes[i] (8*(i - 4));
+ writel(lo, ehci_debug-data03);
+ writel(hi, ehci_debug-data47);
+}
+
+static void dbgp_get_data(void *buf, int size)
+{
+ unsigned char *bytes = buf;
+ unsigned lo, hi;
+ int i;
+ lo = readl(ehci_debug-data03);
+ hi = readl(ehci_debug-data47);
Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
Yinghai Lu [EMAIL PROTECTED] writes: On 12/8/06, Eric W. Biederman [EMAIL PROTECTED] wrote: Your or I missed a bug fix/enhancement in there somewhere. I found the problem. the __set_fixmap need to __va, so the entries will be referred from PAGE_OFFSET. solution will be 1. move enable_dbgp_console from setup_early_printk, and call it from setup_arch after init_memory_mapping. 2. or make __set_fixmap can use __pa or pa()+__START_KERNEL_map in addtion to _va. 3. Make __va always work. I had this in my tree and I guess it didn't get into my big rollup patch. Eric x86_64: Fix the memory mapping in the early page table diff --git a/arch/x86_64/kernel/head.S b/arch/x86_64/kernel/head.S index 1e6f808..2f65469 100644 --- a/arch/x86_64/kernel/head.S +++ b/arch/x86_64/kernel/head.S @@ -328,9 +328,9 @@ ENTRY(wakeup_level4_pgt) .align PAGE_SIZE ENTRY(boot_level4_pgt) .quad phys_level3_ident_pgt | 0x007 - .fill 255,8,0 + .fill 257,8,0 .quad phys_level3_physmem_pgt | 0x007 - .fill 254,8,0 + .fill 252,8,0 /* (2^48-(2*1024*1024*1024))/(2^39) = 511 */ .quad phys_level3_kernel_pgt | 0x007 - 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: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
On Fri, Dec 08, 2006 at 07:16:09PM -0800, Lu, Yinghai wrote: > It works in LinuxBIOS now. Cool, can't wait to try it out. Good work! //Peter - 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: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
On Fri, Dec 08, 2006 at 07:16:09PM -0800, Lu, Yinghai wrote: It works in LinuxBIOS now. Cool, can't wait to try it out. Good work! //Peter - 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: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, December 07, 2006 11:42 PM >> With Eric code in LinuxBIOS, it will report "No device found in debug >> port" >Hmm. At least this is partial progress :) It works in LinuxBIOS now. It will loop all connected port and find debug device. Will check in the code together with MCP55. 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: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
"Yinghai Lu" <[EMAIL PROTECTED]> writes: > On 12/7/06, Eric W. Biederman <[EMAIL PROTECTED]> wrote: >> Ugh. I'd check the code. But it looks like my tweak to the >> early fixmap code. But my hunch is that my tweak to __fixmap >> so that it's pud and pmd were prepopulated didn't take on >> your build. > > I missed some options? Your or I missed a bug fix/enhancement in there somewhere. Basically my very early setup of the fixmap failed. Now. I thought I had that covered by preallocated the pud and the pmd entries. So the only thing missing was the pte entries. If that is not a big enough hint I will look into it in a bit... I'm starting to become a big fan of constant initializers. So our core subsystems don't need initialization code to be useful. All of these early things are just a pain. 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: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
On 12/7/06, Eric W. Biederman <[EMAIL PROTECTED]> wrote: Ugh. I'd check the code. But it looks like my tweak to the early fixmap code. But my hunch is that my tweak to __fixmap so that it's pud and pmd were prepopulated didn't take on your build. I missed some options? 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: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
On 12/7/06, Greg KH <[EMAIL PROTECTED]> wrote: Ugh, no, never use the usb-serial driver as a console device. That was a bad hack done as a bet many years ago. For many obvious reasons it does not work well. understood, I found with usb_serial convertor could lose some chatacter. but the usb-debug cable seem it keep all character. > host with cat /dev/ttyUSB0 > But if use minicom in host, it will not show '\r', I guess the usb debug > cable eat return char. Greg, Can you add that back in usb_debug by > replacing '\n' with '\r', '\n'? The usb-serial console code should handle this, I thought we fixed it a while ago. Is it in the git tree? But this kind of interface is not what these devices are good for. They are for the debug port information, not as a usb-serial console device. Otherwise they are way too expensive of a device... the problem is some "modern" PC will left out serial port. then the cable could get cheap. 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: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
On 12/7/06, Greg KH [EMAIL PROTECTED] wrote: Ugh, no, never use the usb-serial driver as a console device. That was a bad hack done as a bet many years ago. For many obvious reasons it does not work well. understood, I found with usb_serial convertor could lose some chatacter. but the usb-debug cable seem it keep all character. host with cat /dev/ttyUSB0 But if use minicom in host, it will not show '\r', I guess the usb debug cable eat return char. Greg, Can you add that back in usb_debug by replacing '\n' with '\r', '\n'? The usb-serial console code should handle this, I thought we fixed it a while ago. Is it in the git tree? But this kind of interface is not what these devices are good for. They are for the debug port information, not as a usb-serial console device. Otherwise they are way too expensive of a device... the problem is some modern PC will left out serial port. then the cable could get cheap. 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: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
On 12/7/06, Eric W. Biederman [EMAIL PROTECTED] wrote: Ugh. I'd check the code. But it looks like my tweak to the early fixmap code. But my hunch is that my tweak to __fixmap so that it's pud and pmd were prepopulated didn't take on your build. I missed some options? 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: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
Yinghai Lu [EMAIL PROTECTED] writes: On 12/7/06, Eric W. Biederman [EMAIL PROTECTED] wrote: Ugh. I'd check the code. But it looks like my tweak to the early fixmap code. But my hunch is that my tweak to __fixmap so that it's pud and pmd were prepopulated didn't take on your build. I missed some options? Your or I missed a bug fix/enhancement in there somewhere. Basically my very early setup of the fixmap failed. Now. I thought I had that covered by preallocated the pud and the pmd entries. So the only thing missing was the pte entries. If that is not a big enough hint I will look into it in a bit... I'm starting to become a big fan of constant initializers. So our core subsystems don't need initialization code to be useful. All of these early things are just a pain. 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: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, December 07, 2006 11:42 PM With Eric code in LinuxBIOS, it will report No device found in debug port Hmm. At least this is partial progress :) It works in LinuxBIOS now. It will loop all connected port and find debug device. Will check in the code together with MCP55. 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: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
"Lu, Yinghai" <[EMAIL PROTECTED]> writes: > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > > >>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. > > > I got > > Firmware type: LinuxBIOS > Linux version 2.6.19-smp-gc9976797-dirty ([EMAIL PROTECTED]) (gcc version > 4.0.2) #196 6 > Command line: earlyprintk=ttyS0,115200 apic=debug pci=noacpi,routeirq > snd-hda-i > BIOS-provided physical RAM map: > BIOS-e820: - 1000 (reserved) > BIOS-e820: 1000 - 000a (usable) > BIOS-e820: 000c - 000f (usable) > BIOS-e820: 000f - 0010 (reserved) > BIOS-e820: 0010 - c000 (usable) > BIOS-e820: 0001 - 00024000 (usable) > dbgp_num: 0 > Found EHCI debug port > bar: 10 offset: 098 > bar: 10 offset: 098 > dbgp pre-set_fixmap_nocache > PANIC: early exception rip 809c24b4 error 0 cr2 81203ff8 > > Call Trace: > [] __set_fixmap+0x84/0x202 > [] early_dbgp_init+0x259/0x55c > [] __call_console_drivers+0x64/0x72 > [] do_early_param+0x0/0x57 > [] setup_early_printk+0x162/0x17e > [] do_early_param+0x2e/0x57 > [] parse_args+0x159/0x1f3 > [] parse_early_param+0x40/0x4c > [] setup_arch+0x1c1/0x636 > [] start_kernel+0x55/0x208 > [] _sinittext+0x173/0x177 > > RIP __set_fixmap+0x84/0x202 Ugh. I'd check the code. But it looks like my tweak to the early fixmap code. But my hunch is that my tweak to __fixmap so that it's pud and pmd were prepopulated didn't take on your build. > With Eric code in LinuxBIOS, it will report "No device found in debug > port" Hmm. At least this is partial progress :) 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: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
On Thu, Dec 07, 2006 at 07:48:17PM -0800, Lu, Yinghai wrote: > With Greg's USB Debug, host and target can talk. > target with console=ttyUSB0,115200n8 Ugh, no, never use the usb-serial driver as a console device. That was a bad hack done as a bet many years ago. For many obvious reasons it does not work well. > host with cat /dev/ttyUSB0 > But if use minicom in host, it will not show '\r', I guess the usb debug > cable eat return char. Greg, Can you add that back in usb_debug by > replacing '\n' with '\r', '\n'? The usb-serial console code should handle this, I thought we fixed it a while ago. But this kind of interface is not what these devices are good for. They are for the debug port information, not as a usb-serial console device. Otherwise they are way too expensive of a device... thanks, greg k-h - 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: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] >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. I got Firmware type: LinuxBIOS Linux version 2.6.19-smp-gc9976797-dirty ([EMAIL PROTECTED]) (gcc version 4.0.2) #196 6 Command line: earlyprintk=ttyS0,115200 apic=debug pci=noacpi,routeirq snd-hda-i BIOS-provided physical RAM map: BIOS-e820: - 1000 (reserved) BIOS-e820: 1000 - 000a (usable) BIOS-e820: 000c - 000f (usable) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - c000 (usable) BIOS-e820: 0001 - 00024000 (usable) dbgp_num: 0 Found EHCI debug port bar: 10 offset: 098 bar: 10 offset: 098 dbgp pre-set_fixmap_nocache PANIC: early exception rip 809c24b4 error 0 cr2 81203ff8 Call Trace: [] __set_fixmap+0x84/0x202 [] early_dbgp_init+0x259/0x55c [] __call_console_drivers+0x64/0x72 [] do_early_param+0x0/0x57 [] setup_early_printk+0x162/0x17e [] do_early_param+0x2e/0x57 [] parse_args+0x159/0x1f3 [] parse_early_param+0x40/0x4c [] setup_arch+0x1c1/0x636 [] start_kernel+0x55/0x208 [] _sinittext+0x173/0x177 RIP __set_fixmap+0x84/0x202 With Greg's USB Debug, host and target can talk. target with console=ttyUSB0,115200n8 host with cat /dev/ttyUSB0 But if use minicom in host, it will not show '\r', I guess the usb debug cable eat return char. Greg, Can you add that back in usb_debug by replacing '\n' with '\r', '\n'? With Eric code in LinuxBIOS, it will report "No device found in debug port" 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: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
Two side are identical if two side are connected. 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: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
On Wed, Dec 06, 2006 at 01:08:14PM -0800, Lu, Yinghai wrote: > -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. I got my device yesterday and after a small plugfest I can confirm that only one end of the device enumerates when connected to an ICH7 EHCI driven by 2.6.19. --8<-- Bus 001 Device 027: ID 0525:127a Netchip Technology, Inc. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x0525 Netchip Technology, Inc. idProduct 0x127a bcdDevice1.01 iManufacturer 1 NetChip iProduct2 NetChip TurboCONNECT 2.0 iSerial 3 1 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 bNumConfigurations 1 Debug descriptor: bLength 4 bDescriptorType10 bDebugInEndpoint 0x82 bDebugOutEndpoint0x01 -->8-- The device is in fact not self-powered. My theory is that the same set of descriptors are used for both ends, but one end has been locked to address 127 in order to work with simpler debug port drivers that assume it will be there. I guess that the self-powered error is also to simplify life for debug port drivers. IIRC most if not all USB power management concerns are noops for debug ports. //Peter - 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: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
On Wed, Dec 06, 2006 at 01:08:14PM -0800, Lu, Yinghai wrote: -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. I got my device yesterday and after a small plugfest I can confirm that only one end of the device enumerates when connected to an ICH7 EHCI driven by 2.6.19. --8-- Bus 001 Device 027: ID 0525:127a Netchip Technology, Inc. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x0525 Netchip Technology, Inc. idProduct 0x127a bcdDevice1.01 iManufacturer 1 NetChip iProduct2 NetChip TurboCONNECT 2.0 iSerial 3 1 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 bNumConfigurations 1 Debug descriptor: bLength 4 bDescriptorType10 bDebugInEndpoint 0x82 bDebugOutEndpoint0x01 --8-- The device is in fact not self-powered. My theory is that the same set of descriptors are used for both ends, but one end has been locked to address 127 in order to work with simpler debug port drivers that assume it will be there. I guess that the self-powered error is also to simplify life for debug port drivers. IIRC most if not all USB power management concerns are noops for debug ports. //Peter - 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: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
Two side are identical if two side are connected. 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: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] 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. I got Firmware type: LinuxBIOS Linux version 2.6.19-smp-gc9976797-dirty ([EMAIL PROTECTED]) (gcc version 4.0.2) #196 6 Command line: earlyprintk=ttyS0,115200 apic=debug pci=noacpi,routeirq snd-hda-i BIOS-provided physical RAM map: BIOS-e820: - 1000 (reserved) BIOS-e820: 1000 - 000a (usable) BIOS-e820: 000c - 000f (usable) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - c000 (usable) BIOS-e820: 0001 - 00024000 (usable) dbgp_num: 0 Found EHCI debug port bar: 10 offset: 098 bar: 10 offset: 098 dbgp pre-set_fixmap_nocache PANIC: early exception rip 809c24b4 error 0 cr2 81203ff8 Call Trace: [809c24b4] __set_fixmap+0x84/0x202 [809c05bb] early_dbgp_init+0x259/0x55c [8022d958] __call_console_drivers+0x64/0x72 [809b242b] do_early_param+0x0/0x57 [809c0a20] setup_early_printk+0x162/0x17e [809b2459] do_early_param+0x2e/0x57 [8023d051] parse_args+0x159/0x1f3 [809b24c2] parse_early_param+0x40/0x4c [809b88ca] setup_arch+0x1c1/0x636 [809b2534] start_kernel+0x55/0x208 [809b2173] _sinittext+0x173/0x177 RIP __set_fixmap+0x84/0x202 With Greg's USB Debug, host and target can talk. target with console=ttyUSB0,115200n8 host with cat /dev/ttyUSB0 But if use minicom in host, it will not show '\r', I guess the usb debug cable eat return char. Greg, Can you add that back in usb_debug by replacing '\n' with '\r', '\n'? With Eric code in LinuxBIOS, it will report No device found in debug port 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: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
On Thu, Dec 07, 2006 at 07:48:17PM -0800, Lu, Yinghai wrote: With Greg's USB Debug, host and target can talk. target with console=ttyUSB0,115200n8 Ugh, no, never use the usb-serial driver as a console device. That was a bad hack done as a bet many years ago. For many obvious reasons it does not work well. host with cat /dev/ttyUSB0 But if use minicom in host, it will not show '\r', I guess the usb debug cable eat return char. Greg, Can you add that back in usb_debug by replacing '\n' with '\r', '\n'? The usb-serial console code should handle this, I thought we fixed it a while ago. But this kind of interface is not what these devices are good for. They are for the debug port information, not as a usb-serial console device. Otherwise they are way too expensive of a device... thanks, greg k-h - 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: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
Lu, Yinghai [EMAIL PROTECTED] writes: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] 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. I got Firmware type: LinuxBIOS Linux version 2.6.19-smp-gc9976797-dirty ([EMAIL PROTECTED]) (gcc version 4.0.2) #196 6 Command line: earlyprintk=ttyS0,115200 apic=debug pci=noacpi,routeirq snd-hda-i BIOS-provided physical RAM map: BIOS-e820: - 1000 (reserved) BIOS-e820: 1000 - 000a (usable) BIOS-e820: 000c - 000f (usable) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - c000 (usable) BIOS-e820: 0001 - 00024000 (usable) dbgp_num: 0 Found EHCI debug port bar: 10 offset: 098 bar: 10 offset: 098 dbgp pre-set_fixmap_nocache PANIC: early exception rip 809c24b4 error 0 cr2 81203ff8 Call Trace: [809c24b4] __set_fixmap+0x84/0x202 [809c05bb] early_dbgp_init+0x259/0x55c [8022d958] __call_console_drivers+0x64/0x72 [809b242b] do_early_param+0x0/0x57 [809c0a20] setup_early_printk+0x162/0x17e [809b2459] do_early_param+0x2e/0x57 [8023d051] parse_args+0x159/0x1f3 [809b24c2] parse_early_param+0x40/0x4c [809b88ca] setup_arch+0x1c1/0x636 [809b2534] start_kernel+0x55/0x208 [809b2173] _sinittext+0x173/0x177 RIP __set_fixmap+0x84/0x202 Ugh. I'd check the code. But it looks like my tweak to the early fixmap code. But my hunch is that my tweak to __fixmap so that it's pud and pmd were prepopulated didn't take on your build. With Eric code in LinuxBIOS, it will report No device found in debug port Hmm. At least this is partial progress :) 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: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
What do you mean by
+ for (reps = 0; reps >= 0; reps++) {
?
If you will not reps is negative. Roughly it is a loop
that will timeout eventually if a usb debug cable is not present.
So since I didn't know how many loop iterations made sense I allowed
it to loop for 2^31 times or until reps goes negative.
This doesn't work however. Signed overflow in C is undefined,
and GCC actually optimises accordingly (unless -fwrapv is used).
Segher
-
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: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
What do you mean by
+ for (reps = 0; reps = 0; reps++) {
?
If you will not reps is negative. Roughly it is a loop
that will timeout eventually if a usb debug cable is not present.
So since I didn't know how many loop iterations made sense I allowed
it to loop for 2^31 times or until reps goes negative.
This doesn't work however. Signed overflow in C is undefined,
and GCC actually optimises accordingly (unless -fwrapv is used).
Segher
-
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: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 05, 2006 3:50 PM >If you will not reps is negative. Roughly it is a loop >that will timeout eventually if a usb debug cable is not present. >Putting some deliberate delays in there so I could be certain >of timing out after a second or two would probably be better, but >I don't have anything that resembles a good timer at that point. You have dbgp_mdelay in your code. 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: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
"Lu, Yinghai" <[EMAIL PROTECTED]> writes:
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> [EMAIL PROTECTED]
> Sent: Tuesday, December 05, 2006 3:01 AM
>
>>+static int ehci_wait_for_port(int port)
>>+{
>>+ unsigned status;
>>+ int ret, reps;
>>+ for (reps = 0; reps >= 0; reps++) {
>>+ status = readl(_regs->status);
>>+ if (status & STS_PCD) {
>>+ ret = ehci_reset_port(port);
>>+ if (ret == 0)
>>+ return 0;
>>+ }
>>+ }
>>+ return -ENOTCONN;
>>+}
>>+
>
> What do you mean by
> + for (reps = 0; reps >= 0; reps++) {
> ?
If you will not reps is negative. Roughly it is a loop
that will timeout eventually if a usb debug cable is not present.
Putting some deliberate delays in there so I could be certain
of timing out after a second or two would probably be better, but
I don't have anything that resembles a good timer at that point.
The problem is you have to wait until the ehci notices your usb
debug cable before you reset it and get it going and that can be a
non-trivial amount of time. So the loop is 100% necessary.
So since I didn't know how many loop iterations made sense I allowed
it to loop for 2^31 times or until reps goes negative.
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: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Tuesday, December 05, 2006 3:01 AM
>+static int ehci_wait_for_port(int port)
>+{
>+ unsigned status;
>+ int ret, reps;
>+ for (reps = 0; reps >= 0; reps++) {
>+ status = readl(_regs->status);
>+ if (status & STS_PCD) {
>+ ret = ehci_reset_port(port);
>+ if (ret == 0)
>+ return 0;
>+ }
>+ }
>+ return -ENOTCONN;
>+}
>+
What do you mean by
+ for (reps = 0; reps >= 0; reps++) {
?
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: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Tuesday, December 05, 2006 3:01 AM
+static int ehci_wait_for_port(int port)
+{
+ unsigned status;
+ int ret, reps;
+ for (reps = 0; reps = 0; reps++) {
+ status = readl(ehci_regs-status);
+ if (status STS_PCD) {
+ ret = ehci_reset_port(port);
+ if (ret == 0)
+ return 0;
+ }
+ }
+ return -ENOTCONN;
+}
+
What do you mean by
+ for (reps = 0; reps = 0; reps++) {
?
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: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
Lu, Yinghai [EMAIL PROTECTED] writes:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Tuesday, December 05, 2006 3:01 AM
+static int ehci_wait_for_port(int port)
+{
+ unsigned status;
+ int ret, reps;
+ for (reps = 0; reps = 0; reps++) {
+ status = readl(ehci_regs-status);
+ if (status STS_PCD) {
+ ret = ehci_reset_port(port);
+ if (ret == 0)
+ return 0;
+ }
+ }
+ return -ENOTCONN;
+}
+
What do you mean by
+ for (reps = 0; reps = 0; reps++) {
?
If you will not reps is negative. Roughly it is a loop
that will timeout eventually if a usb debug cable is not present.
Putting some deliberate delays in there so I could be certain
of timing out after a second or two would probably be better, but
I don't have anything that resembles a good timer at that point.
The problem is you have to wait until the ehci notices your usb
debug cable before you reset it and get it going and that can be a
non-trivial amount of time. So the loop is 100% necessary.
So since I didn't know how many loop iterations made sense I allowed
it to loop for 2^31 times or until reps goes negative.
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: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 05, 2006 3:50 PM If you will not reps is negative. Roughly it is a loop that will timeout eventually if a usb debug cable is not present. Putting some deliberate delays in there so I could be certain of timing out after a second or two would probably be better, but I don't have anything that resembles a good timer at that point. You have dbgp_mdelay in your code. 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/
