Kim,
finally found some time to re-work my 8377 board code for submission.
sorry to bother you again, but I again stumbled over the discussed USB init issue :
nack, 837x has a usb controller at IMMR+0x23000.
yes - but offset 0x00-0xff is explicitly reserved regarding to the manual. Don't know whether it is a "should not" or "must not be touched".
All I can see is a CPU hang with arbiter event register reporting a timeout on 0xe0023000.
Check to see whether there is an invalid USB clock setting in the SCCR? All clocks are turned on except SEC and 2nd TSEC.
After all USB is running fine with this patch, i.e. there can hardly be a missing clock.
Please re-think you NAK.
afaik, 834x and 837x don't have any special USB settings in common, so, this patch, at least in it's current form, is not on.
0xe0023500 should be the address of the config register being accessed here; please check the code isn't accessing 0xe0023000, as you mention above.
ok - this was some kind of misunderstanding. ehci regs are based at immr + 0x23000 with the "config" pointing to offset 0x500 inside ehci. This looks sane to me.
If that's correct, try something like the following so we can determine what setting the USB controller didn't agree with:
diff --git a/arch/powerpc/cpu/mpc83xx/cpu_init.c b/arch/powerpc/cpu/mpc83xx/cpu_init.c index 7a1cae7..cbc4157 100644 --- a/arch/powerpc/cpu/mpc83xx/cpu_init.c +++ b/arch/powerpc/cpu/mpc83xx/cpu_init.c @@ -332,7 +332,7 @@ void cpu_init_f (volatile immap_t * im) struct usb_ehci *ehci = (struct usb_ehci *)CONFIG_SYS_FSL_USB_ADDR;
/* Configure interface. */
- setbits_be32(&ehci->control, REFSEL_16MHZ | UTMI_PHY_EN);
MPC837x has only 2 working bits inside the control register :
Bit29: USB_EN -> should be set to 1 before USB can be used. Bit31: ULPI_INT_EN -> enables an ULPI wake-up irq.
Both "REFSEL_16MHZ" and "UTMI_PHY_EN" are completely out of scope for MPC837x.
setbits_be32(&ehci->control, 0);
/* Wait for clock to stabilize */
This loop never returns on MPC837x because "PHY_CLK_VALID" isn't valid.
do { temp = __raw_readl(&ehci->control); udelay(1000); } while (!(temp& PHY_CLK_VALID));
I still wonder how there can be a single working MPC837x board with CONFIG_USB_EHCI_FSL set.
Some pending patches on your side ? What kind of patch might get an ACK from your side ?