Here are the voltages that I measured on my custom board that I think
are correct.
VDD1 = 1.2v
VDD2 = 1.2v
VIO_1V8 = 1.8v
VOCORE_1V3 = 1.2v
VDD_PLL1 =1.8v
3.3V = 3.3v
VBATT = 4.2v
Looks all ok.
Here are the bad voltages
VDAC_1V8 =0v
VMMC1 =0v
VDD_PLL2 =.2v
EHCI =.08v
Some of these may need SW-Initialization but VMMC1 should be there.
On a scope I looked at the following signals:
32KCLKOUT on TPS65950 (PIN N10) = Looks like a beautiful
32.77Khz @ 1.9v pk-pk
26Mhz Oscillator Output = It's 26MHz @
800mv pk-pk. Due to a footprint error in the board I did have to dead
bug this component. However, it looks just as good on the scope as the
BeagleBoards output.
HFCLKOUT on TPS65950 (PIN R12) = Looks the same as at the 26Mhz
oscillator but it's @ 1v pk-pk and it appears to be exactly 26.000Mhz
whereas the oscillator was a little less stable.
All ok!
I made a dumb mistake and did not break out REGEN on my board. So I
don't think there is any way for me to probe it.
I think it is not required if you have VDD1/2 power.
I did leave the JTAG interface on my board and I have experimented
with writing to the OMAP registers through JTAG. It seems that I can
write to most of the memory locations but for some reason there are a
bunch of 0x4905#### addresses that I can not write to. I was thinking
that this is either related to a portion of the OMAP not being powered
up OR caused by not yet having MLO and Uboot running (I can't load MLO
or Uboot through the SD Card slot until i figure out what is causing
VMMC1 to no work).
It could also be that some functional blocks don't have their clock enabled.
Hm. Another idea/fault we had on one sample board: there was one 0R
missing for the BOOT selection. So the Boot ROM did never try to read
from MMC. And if I remember correctly, did not enable VMMC1.
Anyways - do you have RS232 I/O? Some "message" 40W or 60?
In that case you could also try to boot over the serial line avoiding
all MMC problems. And if you have U-Boot up and running, you can flash
it (together with x-loader) to NAND. This simplifies analysing a broken
MMC interface.
After that you can add your own test commands to U-Boot to directly address
the subsystems, read registers etc. And, you can read out status registers
of the TPS.
Finally a last issue to check: please don't swap the I2C1 SDA and SCL
lines (as we did through a bug in our component library). We could
work around by horribly patching the I2C drivers but doing a new
layout of the board was the better solution. As far as I remember the
Boot ROM could not communicate with the TPS and therefore could
also not switch on VMMC1. But the patched U-Boot could. So we had to
boot the first phases from NAND and the second one from MMC.
Good luck!
-- hns