We used a kernel module that writes or reads, and when you write any long (4 bytes) to 0xfffe1500 or 0xfffe150c, the usb stops working, at this point when you try to reboot or only to discharge and charge ohci & ehci module, the router (the serial output) is blocked but after some minutes it reboot and both usb work as ehci until you power off the router (like after installation from B21)
I understand better now, so looks like the RSET_USBH_PRIV memory address is directly related with the problem, it's weird that after reboot all the 40 bytes return "normal"
And what means that "0x1c0020" on TestPortControl???
Has someone found the flag values definitions of "USBH_PRIV_TEST_REG"?
the difference between openwrt and stock values is caused by the lines of code that are changing the flag values
reg = bcm_rset_readl(RSET_USBH_PRIV, USBH_PRIV_SWAP_REG); reg &= ~USBH_PRIV_SWAP_OHCI_ENDN_MASK; reg |= USBH_PRIV_SWAP_OHCI_DATA_MASK; bcm_rset_writel(RSET_USBH_PRIV, reg, USBH_PRIV_SWAP_REG);
0x12 -> 10010
0x11 -> 10001
disables USBH_PRIV_SWAP_OHCI_ENDN_MASK (x0x)
enables USBH_PRIV_SWAP_OHCI_DATA_MASK (xx1)
that's why you get 0x11
It should be interesting reading swapcontrol before that changes (on openwrt)
We could test deleting those lines and see what happens
We could change or add the ehci flags:
by the same way
maybe something gets changed inside soc regs (bcm63xx_io.h)
finally i was thinking that it could be a timing problem, because, as i said before, on my router sometimes work and sometimes not (at boot time and without changing anything)
early value change = doesn't work
late value change = kernel freeze
I'm sorry but i cannot make tests atm because i'm using my huawei as main router on my house...