No output on UART0 after loading u-boot

I am working on it now...big learning curve trying to figure out how to do this with CCS.

I just noticed the SK has the data (DDR_DQx) pins all mixed up.  My pins are all mapped 1:1.  Is this going to cause a problem?

U-boot doesn't really "depend" upon the eeprom. If it's not there u-boot will just say "read_eeprom() failure" and continue.

Not sure why you're referring to CCS - you should be building u-boot in linux.

Beaglebone has DDR2 on it. The newer AM335x SK has DDR3 on it.

http://processors.wiki.ti.com/index.php/AM335X_EVM-SK_Android_Devkit_Guide

If your board has DDR3 on it, you'll probably find it easier to start with that board and its sources.

I need CCS if I am going to perform the EMIF/DDR tuning procedure recommended in the previous post.  I already tried u-boot based on the AM3358-SK and it doesn't boot, thus I need to figure out the problem.  Any ideas?

Also, I saw in the uboot code a halt() function in some cases if the EEPROM read doesn't return what is expected...plus uboot will default to the DDR2 configuration if it gets an unexpected header name from the EEPROM.

OK, I reviewed the U-Boot SPL code and it looks like I should be getting a few lines of output on UART0 before the DDR is initialized.  By this, I assume that the DDR is not yet the problem (since I get no SPL output on UART0).

I booted up both boards without the SD card installed and checked several items between my board and the AM3358-SK, and I found a few differences: (1) the nTRST is HIGH on the SK, but LOW on my board (the SK's onboard JTAG interface seems to drive this high), (2) the 32KHz oscillator is running on the SK, but not on my board, (3) I have the SYSBOOT setup to put the ethernet in RMII mode instead of MII mode, but all other SYSBOOT pins are the same as the SK.

I added a 10K pullup to nTRST and it is now about 2.5V (should be 3.3 if all the way up), but I wonder if this would even prevent boot since the "CCCC..." appears as it was.  I tried swapping out the 32K crystal, but I still have no oscillation there.  If there was a problem starting up the RTC, would this cause SPL to hang (pll, rtc, and uart0 are initialized before the first output message).

Also, the CLKOUT1 select is disabled on my board.  I tried setting both CLKOUT1 and Ethernet PHY mode to MII (SYSBOOT6 = 0, SYSBOOT5 = 1) like the SK board, but it didn't have any effect.

I did notice that out CLKOUT1 line is not the same swing as the SK board...mine is about 2.0V max, but the IO is supplied by 3.3V.  I'm wondering if our chip isn't mounted properly.

I am using TPS65217C.  I have verified the startup sequence and all voltage outputs from the TPS chip.  All rails are good.  We're working on putting a second board together.

Just tried board number 2 and I have the same issue with RTC clock not starting up.  I guess I need to go back to the schematic and check again for errors.

Is there any errata/differences between the XAM3359 and the AM3359 parts?

OK, we found the problem.  Since I took a combination of BeagleBone and SK, I used the voltage divider from BeagleBone on the RTC_PWRONRST line.  However, I later went back and changed the VIO on TPS65217C to 1.8V to optimize out the extra LDO regulator, but I forgot to remove the divider.  It looks like the CPU still starts up in this condition, but U-Boot SPL hangs waiting for the RTC to startup.

Also, it seems XAM3359 CPUs enable the RTC on startup while the release AM3359 CPUs do not (there is a note in the TRM that the RTC is off by default on boot, which doesn't seem to match the XAM3359 behavior).