#11200: [bcm63xx] Usb2.0 not working on Huawei HG553
------------------------+-----------------------------------
Reporter: anonymous | Owner: florian
Type: defect | Status: reopened
Priority: normal | Milestone: Barrier Breaker 14.07
Component: luci | Version: Trunk
Resolution: | Keywords:
------------------------+-----------------------------------
Comment (by marcin1j):
Hi guys
I've just tested marcogaio's patch on one of my routers. Works perfectly,
making both ports USB 2.0 capable.
Note that if you want to compile bleeding edge (''Chaos Calmer''), the
original file needs slight adaptation. I'll attach
[attachment:900-board_hw553-usbfix-cc.patch] in case someone needs it.
I hope some solution will soon find its way into the repository as the
lack of high-speed USB is really a show-stopper for most users.
Undoubtedly, the tricky part is to decide where (in the patch, it's the
first statement in `board_bcm963xx_init`, which seems a little awkward)
and when (really all bc6358 devices?) this reset routine should be
performed.
Indeed, in trunk the function `board_early_setup` seems to be a better
place for such routine ie. something like this (except for the inline
variable declaration) would be probably more consistent with existing
code:
{{{
#!diff
--- a/arch/mips/bcm63xx/boards/board_common.c
+++ b/arch/mips/bcm63xx/boards/board_common.c
@@ -15,6 +15,7 @@
#include <linux/platform_device.h>
#include <linux/ssb/ssb.h>
#include <linux/gpio_keys.h>
+#include <linux/delay.h>
#include <linux/spi/spi.h>
#include <asm/addrspace.h>
#include <asm/bootinfo.h>
@@ -132,6 +133,16 @@ void __init board_early_setup(const stru
val |= GPIO_PINMUX_SEL0_GPIO13_PWRON;
bcm_gpio_writel(val, GPIO_PINMUX_SEL0_6318);
}
+
+ /* power cycle the USB PLL */
+ if (BCMCPU_IS_6358()) {
+ unsigned int * reg = (unsigned int *) 0xfffe150c;
+ printk(KERN_INFO PFX "Resetting USB PLL...");
+ *reg &= ~0x02000000;
+ mdelay(1);
+ *reg |= 0x02000000;
+ printk(" done.\n");
+ }
#endif
}
}}}
Moreover, at first glance this memory location seems to be a register.
Isn't this really toggling a GPIO pin, as florian's suggested? The code
for bcm6318, partially seen in the context lines bears some resemblance,
however `GPIO_PINMUX_SEL0_GPIO13_MASK != GPIO_PINMUX_SEL0_GPIO13_PWRON`
toggles 2 bits whereas we toggle only one.
I'm not familiar with low-level architecture in general and Broadcom in
particular, so this is only my guess ;)
--
Ticket URL: <https://dev.openwrt.org/ticket/11200#comment:53>
OpenWrt <http://openwrt.org>
Opensource Wireless Router Technology
_______________________________________________
openwrt-tickets mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-tickets
