Bringing up a new OMAP3530 board (GTA04)

Hi,
we finally have soldered the first of our own GTA04 (TPS65950+OMAP3530)
boards and have got the first "40W" message on UART3 (which means the
boot ROM is working and asks to potentially download boot code from a host).

But I can't get it beyond this message to boot from MMC into U-Boot. What I
have done is to simply use a MMC/SD card that works in the Beagleboard C4
and insert into our SD card reader. The MLO I have on this card identifies itself
as

    Texas Instruments X-Loader 1.4.4ss (Aug 19 2010 - 02:49:27)

The hardware is similar to a BeagleBoard but we have assigned some GPIOs,
McBSPs and McSPIs differently.

Can this be a reason for the failure of the BB-MLO?
Do we have to adapt/write our own MLO?
Or should MLO at least send the greeting line through UART3 even if everything
else does not fit?

What I don't know yet is whether our PoP memory works. Is this important
for MLO to start?

Any hints and sharing experience how to proceed are welcome. The open
source community will finally get a new Openmoko motherboard (GTA04)
based on the OMAP3530.

Nikolaus

Hi,
we finally have soldered the first of our own GTA04 (TPS65950+OMAP3530)
boards and have got the first “40W” message on UART3 (which means the
boot ROM is working and asks to potentially download boot code from a host).

But I can’t get it beyond this message to boot from MMC into U-Boot. What I
have done is to simply use a MMC/SD card that works in the Beagleboard C4
and insert into our SD card reader. The MLO I have on this card identifies itself
as

Have you verified the MMC signals on the card slot? You should have 3.3V (or is that 3.0V?) power for the card in addition to clock, cmd and data lines.

Texas Instruments X-Loader 1.4.4ss (Aug 19 2010 - 02:49:27)

The hardware is similar to a BeagleBoard but we have assigned some GPIOs,
McBSPs and McSPIs differently.

How are you clocking the system? Same 26MHz oscillator as BB?

Can this be a reason for the failure of the BB-MLO?

Without knowing details, yes, it can be. If you have signals that control for example power and the existing X-loader asserts them.

Do we have to adapt/write our own MLO?

Usually yes. Unless your board is really close to some existing one.

Or should MLO at least send the greeting line through UART3 even if everything
else does not fit?

The X-loader greetings comes after cpu, board and serial inits. Maybe some of them fails.

What I don’t know yet is whether our PoP memory works. Is this important
for MLO to start?

X-loader runs (usually) entirely from SRAM so bad SDRAM configuration only shows when it tries to load U-boot.

Any hints and sharing experience how to proceed are welcome. The open
source community will finally get a new Openmoko motherboard (GTA04)
based on the OMAP3530.

After verifying the HW signals I would hook up an emulator and load X-loader to SRAM manually and see where it fails and go from there.

There is also an option of flashing to board through UART3 or USB OTG if it turns out the MMC has problems.

  • Juha

Hi Nikolaus!

I did initial omap3530 bring up a few times and know very well all the issues. Any questions - contact me.

  1. You don’t have to modify x-loader (MLO) right now, because the default one from Koen’s demo must start 100% at any configuration.
  2. X-loader must start with no connection if the DDR is soldered or not, because X-loader is loaded into SRAM in the CPU. U-boot depends on DDR, but MLO not
  3. Booting from MMC or other peripherals depends on BOOT pins of the CPU. What is your configuration?
  4. To start from MMC you need to supply power to MMC slot. The power is generated by 65950. The default voltage level is 3.0V, and I hope you have a probe point on a board to check this voltage. In addition these 3.0 volts are supplied to CPU pins and if the voltage is correct but no MMC-balls at CPU are soldered then it won’t work.
  5. Almost forgot: what is 3530 package do you use? for CBC package there are errors in the documentation; I manufactured the whole board with CBC and then found new revision of CPU datasheet where TI changed ball arrangement. It was really frustrating to realize that all the expenses are useless.
  6. different configuration of GPIO, McBSP or SPI don’t affect the MLO start.
  7. What is the frequency for CPU generator: 26 or 19 Mhz? You better use 26 because all the beagleboard software depends on this frequency, MLO is also!

You can send me your schematic so I could look through for obvious errors.

Max

2010/11/6 Juha Kuikka <juha.kuikka@gmail.com>

Hi,

Hi,
we finally have soldered the first of our own GTA04 (TPS65950+OMAP3530)
boards and have got the first “40W” message on UART3 (which means the
boot ROM is working and asks to potentially download boot code from a host).

But I can’t get it beyond this message to boot from MMC into U-Boot. What I
have done is to simply use a MMC/SD card that works in the Beagleboard C4
and insert into our SD card reader. The MLO I have on this card identifies itself
as

Have you verified the MMC signals on the card slot? You should have 3.3V (or is that 3.0V?) power for the card in addition to clock, cmd and data lines.

That is what I don’t see - no VMMC.

Texas Instruments X-Loader 1.4.4ss (Aug 19 2010 - 02:49:27)

The hardware is similar to a BeagleBoard but we have assigned some GPIOs,
McBSPs and McSPIs differently.

How are you clocking the system? Same 26MHz oscillator as BB?

Yes.

Can this be a reason for the failure of the BB-MLO?

Without knowing details, yes, it can be. If you have signals that control for example power and the existing X-loader asserts them.

Yes, some of my GPIOs control different parts of the system, e.g. the RS232 driver. But it appears
to be unrelated to MMC.

Do we have to adapt/write our own MLO?

Usually yes. Unless your board is really close to some existing one.

I have studies the source code of MLO in the mean time and there is
indeed some pinmux code that may have to be adapted.

Or should MLO at least send the greeting line through UART3 even if everything
else does not fit?

The X-loader greetings comes after cpu, board and serial inits. Maybe some of them fails.

What I don’t know yet is whether our PoP memory works. Is this important
for MLO to start?

X-loader runs (usually) entirely from SRAM so bad SDRAM configuration only shows when it tries to load U-boot.

Ok. Good to know.

Any hints and sharing experience how to proceed are welcome. The open
source community will finally get a new Openmoko motherboard (GTA04)
based on the OMAP3530.

After verifying the HW signals I would hook up an emulator and load X-loader to SRAM manually and see where it fails and go from there.

There is also an option of flashing to board through UART3 or USB OTG if it turns out the MMC has problems.

Ah, that is good. Since I see the “40W”, the UART appears to work. So I may do the first boot from UART and
then have a tool for debugging MMC.

  • Juha

Many thanks,
Nikolaus

Hi Max,

Hi Nikolaus!

I did initial omap3530 bring up a few times and know very well all the issues. Any questions - contact me.

That is good!

  1. You don’t have to modify x-loader (MLO) right now, because the default one from Koen’s demo must start 100% at any configuration.

Ok - if it loads at all. There is now some BB-XM detection inside but I think our board will be detected as BB-A/B (GPIO171-173 floating).

  1. X-loader must start with no connection if the DDR is soldered or not, because X-loader is loaded into SRAM in the CPU. U-boot depends on DDR, but MLO not

Ok.

  1. Booting from MMC or other peripherals depends on BOOT pins of the CPU. What is your configuration?

Same as BB in NAND configuration (i.e. BOOT0-3 pulled up to 1.8V, BOOT4 pulled down, BOOT5 pulled down unless user presses a button, BOOT6 pulled up)

  1. To start from MMC you need to supply power to MMC slot. The power is generated by 65950. The default voltage level is 3.0V, and I hope you have a probe point on a board to check this voltage. In addition these 3.0 volts are supplied to CPU pins and if the voltage is correct but no MMC-balls at CPU are soldered then it won’t work.

Hm. I can’t see VMMC1 coming up. Not even a short pulse. But it does not appear to have a short circuit. Would it be harmful to the TPS if I try to provide an external 3.0 V supply to the LDO output and MMC supply?

What it also could be is that VMMC1.IN (Ball C1) is missing.

  1. Almost forgot: what is 3530 package do you use? for CBC package there are errors in the documentation; I manufactured the whole board with CBC and then found new revision of CPU datasheet where TI changed ball arrangement. It was really frustrating to realize that all the expenses are useless.

CBB package. I hope everthing is ok - triple checked with BB schematics, and different tables in the documentations.

  1. different configuration of GPIO, McBSP or SPI don’t affect the MLO start.
  2. What is the frequency for CPU generator: 26 or 19 Mhz? You better use 26 because all the beagleboard software depends on this frequency, MLO is also!

26 MHz. And the boot ROM is working since I see the “40W”. BTW, there is no difference if the User button is pressed or not.

You can send me your schematic so I could look through for obvious errors.

Another idea - there is some discussion in the data sheets about GPIO0 that
can be used as a card detect for MMC1 power. What I am not sure about is
whether this feature is enabled or disabled by default especially for the Boot ROM.

On the BB this is connected to the CD switch and is pulled up to 1.8V by R62 (10k).

We have it left floating (but available for JTAG) since we use a Micro-SD without CD.

Finally, the MicroSD is connected to MMC1_CLK, CMD, DAT0-3 while DAT4-7 of the OMAP are left floating.

Many thanks,
Nikolaus

Hi Juha,

Hi,
we finally have soldered the first of our own GTA04 (TPS65950+OMAP3530)
boards and have got the first “40W” message on UART3 (which means the
boot ROM is working and asks to potentially download boot code from a host).

But I can’t get it beyond this message to boot from MMC into U-Boot. What I
have done is to simply use a MMC/SD card that works in the Beagleboard C4
and insert into our SD card reader. The MLO I have on this card identifies itself
as

Have you verified the MMC signals on the card slot? You should have 3.3V (or is that 3.0V?) power for the card in addition to clock, cmd and data lines.

That is what I don’t see - no VMMC.

Texas Instruments X-Loader 1.4.4ss (Aug 19 2010 - 02:49:27)

The hardware is similar to a BeagleBoard but we have assigned some GPIOs,
McBSPs and McSPIs differently.

How are you clocking the system? Same 26MHz oscillator as BB?

Yes.

Can this be a reason for the failure of the BB-MLO?

Without knowing details, yes, it can be. If you have signals that control for example power and the existing X-loader asserts them.

Yes, some of my GPIOs control different parts of the system, e.g. the RS232 driver. But it appears
to be unrelated to MMC.

Do we have to adapt/write our own MLO?

Usually yes. Unless your board is really close to some existing one.

I have studied the source code of MLO in the mean time and there is
indeed some pinmux code that may have to be adapted.

Or should MLO at least send the greeting line through UART3 even if everything
else does not fit?

The X-loader greetings comes after cpu, board and serial inits. Maybe some of them fails.

What I don’t know yet is whether our PoP memory works. Is this important
for MLO to start?

X-loader runs (usually) entirely from SRAM so bad SDRAM configuration only shows when it tries to load U-boot.

Ok. Good to know.

Any hints and sharing experience how to proceed are welcome. The open
source community will finally get a new Openmoko motherboard (GTA04)
based on the OMAP3530.

After verifying the HW signals I would hook up an emulator and load X-loader to SRAM manually and see where it fails and go from there.

There is also an option of flashing to board through UART3 or USB OTG if it turns out the MMC has problems.

Ah, that is good. Since I see the “40W”, the UART appears to work. So I may do the first boot from UART3 and
then have a tool for debugging MMC.

  • Juha

Many thanks,
Nikolaus

What do you mean Ball “C1” is missing? You did not supply VBAT to C1?

Forget about CD signal for MMC, because you must have VMMC1 before you insert a card.

Why don’t you send the schematic? As far as I know GTA schematics usually were public.
I suppose your board is soldered bad. Do you have only one soldered? I’m sure Gerald can tell a lot about CBB soldering and 65950 :slight_smile:

What about temperature of 65950 and CPU? Can you hold a finger on the chips? If they are really hot, then there is the probability that there are shorts under the BGA.

2010/11/7 Dr. H. Nikolaus Schaller <hns@goldelico.com>