Re: Mycable XXS board

Re: Mycable XXS board

[Tiemo Krueger - mycable GmbH]

Hi Alexander,

next to the things written by Bruno and the rest I wanted to add:

The processor-architecture is MIPS32, this is what you can choose in the 
config.
The Pb1500 or Db1500 is a good point to start with.

Tiemo

 >Hi all,
 >
 >Has anyone used the kernel on a Mycable XXS board ( it has Alchemy 
au1500 )...
 >What CPU type should I choose for the au1500? R5000? Sorry for the 
lame question but I haven't used MIPS-based boards and I know nothing 
baout the CPU...
 >
 >Regards,
>-- 
 >Alexander Popov

-- 
-------------------------------------------------------
Tiemo Krueger       Tel:  +49 48 73 90 19 86
mycable GmbH        Fax: +49 48 73 90 19 76
Boeker Stieg 43
D-24613 Aukrug      eMail: tk@mycable.de

Public Kryptographic Key is available on request
-------------------------------------------------------

Re: Mycable XXS board

[Tiemo Krueger - mycable GmbH]

Hi Alexander,

next to the things written by Bruno and the rest I wanted to add:

The processor-architecture is MIPS32, this is what you can choose in the
config.
The Pb1500 or Db1500 is a good point to start with.

Tiemo

  >Hi all,
  >
  >Has anyone used the kernel on a Mycable XXS board ( it has Alchemy
au1500 )...
  >What CPU type should I choose for the au1500? R5000? Sorry for the
lame question but I haven't used MIPS-based boards and I know nothing
baout the CPU...
  >
  >Regards,
 >--
  >Alexander Popov

-- 
-------------------------------------------------------
Tiemo Krueger       Tel:  +49 48 73 90 19 86
mycable GmbH        Fax: +49 48 73 90 19 76
Boeker Stieg 43
D-24613 Aukrug      eMail: tk@mycable.de

Public Kryptographic Key is available on request
-------------------------------------------------------

Re: Mycable XXS board

[Alexander Popov]

Thanks to all that helped me up with that...

I managed to compile the kernel (2.4.21). There were some problems with unresolved symbols, but when 
I fixed the support to only pb1500 and removed the MTD CFI support , the framebuffer and a few other 
things it worked.

Thanks againg guys.

Best Regards,

-- 
Alexander Popov
RTOS&JVM Team Leader
Prosyst Bulgaria, Inc.
email: s_popov@prosyst.bg
mobile: +35987663193
icq: 29207350

Re: Mycable XXS board

[Alexander Popov]

Thanks to all that helped me up with that...

I managed to compile the kernel (2.4.21). There were some problems with unresolved symbols, but when 
I fixed the support to only pb1500 and removed the MTD CFI support , the framebuffer and a few other 
things it worked.

Thanks againg guys.

Best Regards,

-- 
Alexander Popov
RTOS&JVM Team Leader
Prosyst Bulgaria, Inc.
email: s_popov@prosyst.bg
mobile: +35987663193
icq: 29207350

Mycable XXS board

[Alexander Popov]

Hi all,

Has anyone used the kernel on a Mycable XXS board ( it has Alchemy au1500 )...
What CPU type should I choose for the au1500? R5000? Sorry for the lame question but I haven't used 
MIPS-based boards and I know nothing baout the CPU...

Regards,
-- 
Alexander Popov

Re: Mycable XXS board

[Pete Popov]

On Fri, 2003-03-07 at 04:36, Alexander Popov wrote:
> Hi all,
> 
> Has anyone used the kernel on a Mycable XXS board ( it has Alchemy au1500 )...
> What CPU type should I choose for the au1500? R5000? Sorry for the lame question but I haven't used 
> MIPS-based boards and I know nothing baout the CPU...

Given that the board has an Alchemy Au1500 CPU, I would say you should
chose the Au1500 :)  Start with the Pb1500 board port that's in
linux-mips.org. Maybe, just maybe, a Pb1500 kernel will boot fine on
your board. And if it doesn't, creating a port for the above mentioned
board should be fairly easy.

Pete

Re: Mycable XXS board

[Bruno Randolf]

[-- Attachment #1: Type: text/plain, Size: 1466 bytes --]

hello!

we are also working with this board and it it supported thru the Pb1500 board 
configuration of the linux-mips.org kernel. we use the 2_4 branch and some 
patches of pete (ftp://ftp.linux-mips.org/pub/linux/mips/people/ppopov). with 
these patches i can already see my pci cards (but i dont yet have a driver 
for them). usb does not yet work - it complains that it cannot assign new 
numbers to the devices. the flash chip (AM29LV641DL) is also not recognized 
yet.

if you dont use YAMON, you have to add a patch to deal with the nonexistent 
command line parameters. i attached it for you, but its an ugly hack.

and to enable one of the ethernet ports you can use the second patch. it's 
also quite a hack, cause it does not yet deal with the second port... 

bruno


On Friday 07 March 2003 13:40, you wrote:
> On Fri, 2003-03-07 at 04:36, Alexander Popov wrote:
> > Hi all,
> >
> > Has anyone used the kernel on a Mycable XXS board ( it has Alchemy au1500
> > )... What CPU type should I choose for the au1500? R5000? Sorry for the
> > lame question but I haven't used MIPS-based boards and I know nothing
> > baout the CPU...
>
> Given that the board has an Alchemy Au1500 CPU, I would say you should
> chose the Au1500 :)  Start with the Pb1500 board port that's in
> linux-mips.org. Maybe, just maybe, a Pb1500 kernel will boot fine on
> your board. And if it doesn't, creating a port for the above mentioned
> board should be fairly easy.
>
> Pete

[-- Attachment #2: cfc_startup.diff --]
[-- Type: text/x-diff, Size: 1381 bytes --]

--- arch/mips/au1000/common/prom.c	Wed Dec 12 19:30:52 2001
+++ arch/mips/au1000/common/prom.c	Tue Feb  4 00:41:08 2003
@@ -62,21 +62,21 @@
 
 void  prom_init_cmdline(void)
 {
-	char *cp;
-	int actr;
+//	char *cp;
+//	int actr;
 
-	actr = 1; /* Always ignore argv[0] */
+//	actr = 1; /* Always ignore argv[0] */
 
-	cp = &(arcs_cmdline[0]);
-	while(actr < prom_argc) {
-	        strcpy(cp, prom_argv[actr]);
-		cp += strlen(prom_argv[actr]);
-		*cp++ = ' ';
-		actr++;
-	}
-	if (cp != &(arcs_cmdline[0])) /* get rid of trailing space */
-		--cp;
-	*cp = '\0';
+//	cp = &(arcs_cmdline[0]);
+//	while(actr < prom_argc) {
+//	        strcpy(cp, prom_argv[actr]);
+//		cp += strlen(prom_argv[actr]);
+//		*cp++ = ' ';
+//		actr++;
+//	}
+//	if (cp != &(arcs_cmdline[0])) /* get rid of trailing space */
+//		--cp;
+//	*cp = '\0';
 
 }
 
@@ -88,17 +88,17 @@
 	 * Environment variables are stored in the form of "memsize=64".
 	 */
 
-	t_env_var *env = (t_env_var *)prom_envp;
-	int i;
+//	t_env_var *env = (t_env_var *)prom_envp;
+//	int i;
 
-	i = strlen(envname);
+//	i = strlen(envname);
 
-	while(env->name) {
-		if(strncmp(envname, env->name, i) == 0) {
-			return(env->name + strlen(envname) + 1);
-		}
-		env++;
-	}
+//	while(env->name) {
+//		if(strncmp(envname, env->name, i) == 0) {
+//			return(env->name + strlen(envname) + 1);
+//		}
+//		env++;
+//	}
 	return(NULL);
 }
 

[-- Attachment #3: au1000_eth_BCM5222_hack.diff --]
[-- Type: text/x-diff, Size: 600 bytes --]

--- ../linux-mips-2_4-cvs-clean/drivers/net/au1000_eth.c	Wed Dec 11 07:12:30 2002
+++ drivers/net/au1000_eth.c	Fri Feb  7 14:37:49 2003
@@ -471,6 +471,7 @@
 } mii_chip_table[] = {
 	{"Broadcom BCM5201 10/100 BaseT PHY",  0x0040, 0x6212, &bcm_5201_ops },
 	{"Broadcom BCM5221 10/100 BaseT PHY",  0x0040, 0x61e4, &bcm_5201_ops },
+	{"Broadcom BCM5222 10/100 BaseT PHY",  0x0040, 0x6322, &bcm_5201_ops },
 	{"AMD 79C901 HomePNA PHY",  0x0000, 0x35c8, &am79c901_ops },
 	{"AMD 79C874 10/100 BaseT PHY",  0x0022, 0x561b, &am79c874_ops },
 	{"LSI 80227 10/100 BaseT PHY", 0x0016, 0xf840, &lsi_80227_ops },

Re: Mycable XXS board

[Jun Sun]

On Fri, Mar 07, 2003 at 04:47:13PM +0100, Bruno Randolf wrote:
> hello!
> 
> we are also working with this board and it it supported thru the Pb1500 board 
> configuration of the linux-mips.org kernel. we use the 2_4 branch and some 
> patches of pete (ftp://ftp.linux-mips.org/pub/linux/mips/people/ppopov). with 
> these patches i can already see my pci cards (but i dont yet have a driver 
> for them). usb does not yet work - it complains that it cannot assign new 
> numbers to the devices. 

More than likely this is due to the interrupt routing for USB controller
not being setup correctly.

Jun

Re: Mycable XXS board

[Dan Malek]

Jun Sun wrote:

> More than likely this is due to the interrupt routing for USB controller
> not being setup correctly.

How did you come to this conclusion?  Is this a PCI USB controller or the
on-chip peripheral?  I have Au1xxx boards were on-chip usb is
required and is working fine.  There aren't any options to configuring
on-chip USB interrupts on Au1xxx.  It could just as likely be a Linux kernel
configuration problem.  We know there is something amiss with Au1xxx USB
in big endian mode, but all LE boards should work fine.

Thanks.


	-- Dan

Re: Mycable XXS board

[Jun Sun]

On Fri, Mar 07, 2003 at 03:12:17PM -0500, Dan Malek wrote:
> Jun Sun wrote:
> 
> > More than likely this is due to the interrupt routing for USB controller
> > not being setup correctly.
> 
> How did you come to this conclusion?  Is this a PCI USB controller or the
> on-chip peripheral?  I have Au1xxx boards were on-chip usb is
> required and is working fine.  There aren't any options to configuring
> on-chip USB interrupts on Au1xxx.  It could just as likely be a Linux kernel
> configuration problem.  We know there is something amiss with Au1xxx USB
> in big endian mode, but all LE boards should work fine.
>

I have seen USB working under BE mode in many instances.  (Acutally
that I have two that work.).  I don't think endianess is the issue.

I have seen "number assign failures" a couple of times before, and it
is all because interrupt not routed correctedly.  That is where "more than
likely" comes from.

Of course, I have only dealt with PCI USB controllers.  On-chip ones may
have another set of additional issues that I am not aware of.

Jun

Re: Mycable XXS board

[Dan Malek]

Jun Sun wrote:

> I have seen USB working under BE mode in many instances.  (Acutally
> that I have two that work.).  I don't think endianess is the issue.

Guess I wasn't clear :-)  That comment was directed toward the on-chip
peripheral version of the USB controller.

> Of course, I have only dealt with PCI USB controllers.  On-chip ones may
> have another set of additional issues that I am not aware of.

That's what I wanted to clarify.  Are we discussing one of the on-chip
peripheral USB controllers of the Au1xxx, or is it a PCI USB controller
that was plugged into the Au1500.  In the case of the on-chip controller,
there aren't any interrupt routing problems, it's identical (and the same
code) on all Au1xxx boards.

Thanks.

	-- Dan

Re: Mycable XXS board

[Bruno Randolf]

On Friday 07 March 2003 22:54, Dan Malek wrote:

> That's what I wanted to clarify.  Are we discussing one of the on-chip
> peripheral USB controllers of the Au1xxx, or is it a PCI USB controller
> that was plugged into the Au1500.  In the case of the on-chip controller,
> there aren't any interrupt routing problems, it's identical (and the same
> code) on all Au1xxx boards.

we are discussing the on-chip USB controller for the mycable board. and its 
little endian...

any ideas where the assignment errors could come from in this case?

thanks,
bruno

Re: Mycable XXS board

[Pete Popov]

On Tue, 2003-03-11 at 02:30, Bruno Randolf wrote:
> On Friday 07 March 2003 22:54, Dan Malek wrote:
> 
> > That's what I wanted to clarify.  Are we discussing one of the on-chip
> > peripheral USB controllers of the Au1xxx, or is it a PCI USB controller
> > that was plugged into the Au1500.  In the case of the on-chip controller,
> > there aren't any interrupt routing problems, it's identical (and the same
> > code) on all Au1xxx boards.
> 
> we are discussing the on-chip USB controller for the mycable board. and its 
> little endian...
> 
> any ideas where the assignment errors could come from in this case?

There wouldn't be any. So the problem is not irq assignment related.

I'm not what to suggest here but it feels like it might be a hardware
issue.  Try adding some printks (the abatron bdi jtag debugger works
great if you have one) and narrow down what's going on. Do you have any
jumpers on the board that are not setup correctly?


Pete

Re: Mycable XXS board

[Eric DeVolder]

[-- Attachment #1: Type: text/plain, Size: 1287 bytes --]

Check linux/arch/mips/au1000/common/irq.c, in function init_IRQ().
Currently all the interrupt assignment are conditionalized per-board,
rather than per-cpu where appropriate. Unless you've changed this
file, I suspect many IRQ setups may be wrong.

Eric

Pete Popov wrote:

>On Tue, 2003-03-11 at 02:30, Bruno Randolf wrote:
>  
>
>>On Friday 07 March 2003 22:54, Dan Malek wrote:
>>
>>    
>>
>>>That's what I wanted to clarify.  Are we discussing one of the on-chip
>>>peripheral USB controllers of the Au1xxx, or is it a PCI USB controller
>>>that was plugged into the Au1500.  In the case of the on-chip controller,
>>>there aren't any interrupt routing problems, it's identical (and the same
>>>code) on all Au1xxx boards.
>>>      
>>>
>>we are discussing the on-chip USB controller for the mycable board. and its 
>>little endian...
>>
>>any ideas where the assignment errors could come from in this case?
>>    
>>
>
>There wouldn't be any. So the problem is not irq assignment related.
>
>I'm not what to suggest here but it feels like it might be a hardware
>issue.  Try adding some printks (the abatron bdi jtag debugger works
>great if you have one) and narrow down what's going on. Do you have any
>jumpers on the board that are not setup correctly?
>
>
>Pete
>
>
>
>  
>


[-- Attachment #2: Type: text/html, Size: 1761 bytes --]

Re: Mycable XXS board

[Dan Malek]

Eric DeVolder wrote:

> Check linux/arch/mips/au1000/common/irq.c, in function init_IRQ().
> Currently all the interrupt assignment are conditionalized per-board,

Well, only some of them, in particular the custom GPIO configurations.
In the case of USB and other on-chip peripherals, these are always
configured on all boards.

> ... I suspect many IRQ setups may be wrong.

I don't really think so.  I've done several different Au1xxx boards and
never touch this configuration for USB.  I would like to hear the
results of the message posted earlier today about the proper power up
of the USB interface on this board :-)


Thanks.


	-- Dan

Re: Mycable XXS board

[Bruno Randolf]

[-- Attachment #1: Type: text/plain, Size: 713 bytes --]

On Tuesday 11 March 2003 22:57, Dan Malek wrote:
> I would like to hear the
> results of the message posted earlier today about the proper power up
> of the USB interface on this board :-)

hello!

i got USB to work with the proper power up :)
the builtin usb devices still dont accept a new address (maybe thats ok?), but 
i can see the attached usb devices and they are powered. i tested a serial 
driver which also loads and detects the device fine. looks good, but i havent 
tested any functionality yet.

i attach a patch with the usb power up for the mycable XXS board, which also 
defines a new config option for this board. i'm not sure if this is the 
correct way to do it, so please correct me...

bruno

[-- Attachment #2: mycable_XXS_config.diff --]
[-- Type: text/x-diff, Size: 705 bytes --]

--- cvs-linux-mips-2_4/arch/mips/config-shared.in	Fri Mar  7 18:29:18 2003
+++ mips-2_4/arch/mips/config-shared.in	Thu Mar 13 13:52:47 2003
@@ -29,6 +29,9 @@
 fi
 dep_bool 'Support for Alchemy PB1100 board' CONFIG_MIPS_PB1100 $CONFIG_MIPS32
 dep_bool 'Support for Alchemy PB1500 board' CONFIG_MIPS_PB1500 $CONFIG_MIPS32
+if [ "$CONFIG_MIPS_PB1500" = "y" ]; then
+   bool '  Support for mycable XXS board' CONFIG_MYCABLE_XXS_1500
+fi
 dep_bool 'Support for BAGET MIPS series (EXPERIMENTAL)' CONFIG_BAGET_MIPS $CONFIG_MIPS32 $CONFIG_EXPERIMENTAL
 bool 'Support for CASIO CASSIOPEIA E-10/15/55/65' CONFIG_CASIO_E55
 dep_bool 'Support for Cobalt Server (EXPERIMENTAL)' CONFIG_MIPS_COBALT $CONFIG_EXPERIMENTAL

[-- Attachment #3: mycable_XXS_usb_power.diff --]
[-- Type: text/x-diff, Size: 980 bytes --]

--- cvs-linux-mips-2_4/arch/mips/au1000/pb1500/setup.c	Thu Mar 13 14:00:00 2003
+++ mips-2_4/arch/mips/au1000/pb1500/setup.c	Thu Mar 13 14:04:53 2003
@@ -197,8 +197,24 @@
 	pin_func |= 0x8000;
 #endif
 	au_writel(pin_func, SYS_PINFUNC);
-#endif // defined (CONFIG_USB_OHCI) || defined (CONFIG_AU1X00_USB_DEVICE)
 
+#ifdef CONFIG_MYCABLE_XXS_1500
+	// set multiple use pins (UART3/GPIO) to UART (it's used as UART too)
+	pin_func = au_readl(SYS_PINFUNC) & (u32)(~SYS_PF_UR3);
+	pin_func |= SYS_PF_UR3;
+	au_writel(pin_func, SYS_PINFUNC);
+
+	// enable UART
+	au_writel(0x01, UART3_ADDR+UART_MOD_CNTRL); // clock enable (CE)
+	mdelay(10);
+	au_writel(0x03, UART3_ADDR+UART_MOD_CNTRL); // CE and "enable"
+	mdelay(10);
+
+	// enable DTR = USB power up
+	au_writel(0x01, UART3_ADDR+UART_MCR); //? UART_MCR_DTR is 0x01???
+#endif
+
+#endif // defined (CONFIG_USB_OHCI) || defined (CONFIG_AU1X00_USB_DEVICE)
 
 #ifdef CONFIG_USB_OHCI
 	// enable host controller and wait for reset done

Re: Mycable XXS board

[Dan Malek]

Bruno Randolf wrote:

> i got USB to work with the proper power up :)

Cool, thanks for the update.

> i attach a patch with the usb power up for the mycable XXS board,

The way this should really be done is to have a board definition,
directory and files unique to the XXS board.  Hacking the PB1500
may be the fast way to get it done locally, but it isn't the right
way from a Linux structure/maintenance viewpoint.

Thanks.

	-- Dan

Re: Mycable XXS board

[Bruno Randolf]

On Thursday 13 March 2003 17:03, Dan Malek wrote:

> The way this should really be done is to have a board definition,
> directory and files unique to the XXS board.  Hacking the PB1500
> may be the fast way to get it done locally, but it isn't the right
> way from a Linux structure/maintenance viewpoint.

allright, i can do that - but doesn't this create a lot of unnecessary copied 
code?

bruno

Re: Mycable XXS board

[Dan Malek]

Bruno Randolf wrote:

> allright, i can do that - but doesn't this create a lot of unnecessary copied 
> code?

Initially, perhaps, but over time similar software will be moved into
common areas.  IMHO, it helps to keep these boards separate because
it serves to remind us the XXS board is not a PB1500.  You may also
find more things unique to your board, so the unique board configuration
will become useful to isolate features.

Thanks.


	-- Dan

Re: Mycable XXS board

[Pete Popov]

On Thu, 2003-03-13 at 09:50, Dan Malek wrote:
> Bruno Randolf wrote:
> 
> > allright, i can do that - but doesn't this create a lot of unnecessary copied 
> > code?
> 
> Initially, perhaps, but over time similar software will be moved into
> common areas.  IMHO, it helps to keep these boards separate because
> it serves to remind us the XXS board is not a PB1500.  You may also
> find more things unique to your board, so the unique board configuration
> will become useful to isolate features.

I agree with that.  Everything that's in common between the Au boards
should be in the common directory, arch/mips/au1000/common. But like Dan
said, by the time you're done with the entire board port, you may find
other unique things to your board which require additional ifdefs, and
keeping the board separate would be cleaner.

If this a board that's available off the shelf to customers?

Pete


> Thanks.
> 
> 
> 	-- Dan
> 
> 
> 
> 

Re: Mycable XXS board

[Tiemo Krueger - mycable GmbH]

Hi Bruno, Hi group!

There is a separate power switch on the mycable XXS1500 Board:

1. GPIO1  switch on UART3
2.  Enable UART3
3.  Set DTR from UART3 to low-level

The voltage switch for USB is controlled by the unused DTR line of the 
Au1500.

below the code we use with QNX for this procedure:

/*-------------------------------------------------------------------------*/
/*                                                                         
*/
/*  
main                                                                   */
/*                                                                         
*/
/*  action: enable and start AU1500 onchip USB 
controller                  */
/*                                                                         
*/
/*  passing param.  : 
-none-                                               */
/*  global  param.  : 
-none-                                               */
/*  return  param.  : 
-none-                                               */
/*                                                                         
*/
/*  programmer      : 
JR                                                   */
/*                                                                         
*/
/*  04.03.03  JR    : build this 
function                                  */
/*                                                                         
*/
/*-------------------------------------------------------------------------*/

int main(int argc, char *argv[]) {
   
    volatile uint32_t *sysctrlptr;
    volatile uint32_t *uart3_mdmptr;
    volatile uint32_t *usb_baseptr;
   
   
    printf("Prepare AU1500 onchip USB host controller\n");
    printf("  map memory\n");
    sysctrlptr = mmap_device_memory(NULL, 1000, 
PROT_READ|PROT_WRITE|PROT_NOCACHE, 0, 0x011900000);
    if ( sysctrlptr == MAP_FAILED ) {
        perror( "couldn't map sysctrl mem.\n" );
        exit( EXIT_FAILURE );
    }
    uart3_mdmptr = mmap_device_memory(NULL, 1000, 
PROT_READ|PROT_WRITE|PROT_NOCACHE, 0, 0x011400000);
    if ( uart3_mdmptr == MAP_FAILED ) {
        perror( "couldn't map uart3 mem.\n" );
        exit( EXIT_FAILURE );
    }
    usb_baseptr = mmap_device_memory(NULL, 0x80000, 
PROT_READ|PROT_WRITE|PROT_NOCACHE, 0, 0x010100000);
    if ( usb_baseptr == MAP_FAILED ) {
        perror( "couldn't map usb mem.\n" );
        exit( EXIT_FAILURE );
    }

    // configure some multiple use pins for UART3
    sysctrlptr[0x2c/4] |= (1 << 7);  // sys_pinctrl
   
    printf("  power on\n");
    uart3_mdmptr[0x100/4] |= 0x01;    // CE
    delay(10);
    uart3_mdmptr[0x100/4] |= 0x03;    // CE | EN
    delay(10);
    uart3_mdmptr[0x18/4]  |= 0x01;    // power on
   
    // enable usb OCHI controller
    usb_baseptr[0x7fffc/4] = 0x08;    // CE
    delay(10);
    usb_baseptr[0x7fffc/4] = 0x0c ;    // CE | EN
    delay(10);
    // clear HCFS bits in HcControl
    usb_baseptr[0x0004/4] = 0x00; 
   
    while ((usb_baseptr[0x7fffc/4] & 0x10) == 0); // wait for reset done
   
    printf("  USB OHCI ver. 0x%x\n", usb_baseptr[0]);
   
    return EXIT_SUCCESS;
}

Tiemo

-- 
-------------------------------------------------------
Tiemo Krueger       Tel:  +49 48 73 90 19 86
mycable GmbH        Fax: +49 48 73 90 19 76
Boeker Stieg 43
D-24613 Aukrug      eMail: tk@mycable.de

Public Kryptographic Key is available on request
-------------------------------------------------------


Pete Popov wrote:

>On Tue, 2003-03-11 at 02:30, Bruno Randolf wrote:
>  
>
>>On Friday 07 March 2003 22:54, Dan Malek wrote:
>>
>>    
>>
>>>That's what I wanted to clarify.  Are we discussing one of the on-chip
>>>peripheral USB controllers of the Au1xxx, or is it a PCI USB controller
>>>that was plugged into the Au1500.  In the case of the on-chip controller,
>>>there aren't any interrupt routing problems, it's identical (and the same
>>>code) on all Au1xxx boards.
>>>      
>>>
>>we are discussing the on-chip USB controller for the mycable board. and its 
>>little endian...
>>
>>any ideas where the assignment errors could come from in this case?
>>    
>>
>
>There wouldn't be any. So the problem is not irq assignment related.
>
>I'm not what to suggest here but it feels like it might be a hardware
>issue.  Try adding some printks (the abatron bdi jtag debugger works
>great if you have one) and narrow down what's going on. Do you have any
>jumpers on the board that are not setup correctly?
>
>
>Pete
>
>
>
>  
>


-- 
-------------------------------------------------------
Tiemo Krueger       Tel:  +49 48 73 90 19 86
mycable GmbH        Fax: +49 48 73 90 19 76
Boeker Stieg 43
D-24613 Aukrug      eMail: tk@mycable.de

Public Kryptographic Key is available on request
-------------------------------------------------------