Linux/AM5728: Debugging SPL/MLO on AM5728

Hi,

The code implies a call to a service in the ROM, this looks like an API. Is there any documentation for the services provided by the ROM API and if so where can I find it?

Publicly available information about ROM Code is described in Chapter 33 Initialization of AM5728 TRM.

Best Regards,
Yordan

The materials there are quite high level.  For example, there is no mention of the ROM expectations data structures used by the ROM calling back to board function board_init_r in the SPL code (ignoring the fact that there is no mention or discussion of even requiring board_init_r code, address it is expected to be at or how the ROM is to know about it).

So reverse engineering the SPL code is the only way to work through this?

Also, the API table is only described, there doesn't appear to be documentation for it.

The API table gets two hits, one in figure 33-5 then a descriptive paragraph near the end of 33.3.2.1:

API table
The purpose of this table is to allow external code access to system maintenance, utility, and device
driver functions which are used for ensuring the ROM code boot functionality. These functions can be
reused at run time by calling a fixed address hardcoded in this table.

then nothing. As this is an 8000 page document, searching is the only realistic way to find things. There is no other hit regarding the API table.

The only thing that I can see that this might be referring to is section 33.4, but they only look like supervisory and monitoring functions.

Found information on board_init_r , however, still unable to find anything about the API table. Where is the details of the API table in the documentation?

Chris, Yordan,

We are also developing an AM578-based product and are seeing the same issue when executing "smc 0" from omap_smc1.

Any commendations?

Thanks.

Wilson

In our case, our breadboards are using silicon revision 1.1 while the final form factor boards will use silicon revision 2.0.

Our problem was a mis configured EMIF port.

I was able to isolate it to a memory problem by commenting out the switch to external memory in the SPL and it worked fine indicating that the external memory had a problem.

I worked from scratch with the EMIF configuration spread sheet and got working values.

Best of luck with your bring up.

I did my initial debugging with a JTAG device and Code Composer Studio.

Just looking through my notes, you should be able to get a successful break point at board_init_f in the SPL. This was the first thing I was able to find that got hit after the supervisor was activated (smc 0).

This is very early in the SPL and is all on chip at that point so you should be able to walk forward from there and work out subsequent problems.

Unfortunately, you have to reverse engineer what is going on as there is very little documentation for it. The calling tree I have from my log book looks like this:

board_init_f (hwinit-common.c) *
early_system_init (hwinit-common.c) *
init_omap_revision *
hw_data_init *
watchdog_init (doesn’t call warm_reset)
set_mux_conf_regs *
srcomp_enable *
do_io_settings *
setup_early_clocks *
do_board_detect *
vcores_init *
prcm_init *

sdram_init (arch\arm\cpu\armv7\omap-common\emif-common.c) follows shortly after this and is the point where I found our problem.

Another thing I found that helps is put a break point in the puts calls. Build uboot with debugging on (include/common.h #define DEBUG) The serial port unfortunately isn't initialized until fairly late in the game, but there is a lot of debugging information prior to that. The puts call will go down to an empty procedure where your final break point can be left and you can see the debug string each time it is called.

Also, I was able to put the call to initialize the serial port right at the start of board_init_f and get the debugging to come out of the serial link. The call is preloader_console_init. I don't have the specific details on hand at this point but my note indicates that I added it to arch/arm/mach-omap2/hwinit-common.c to get serial debugging output activated earlier in the boot up.