I have been working with the OMAPL138 Experimenter kit (and EVM) for the past year but all that time I had been working with PSP version .06. Now I am trying to update to PSP .12 and having some issues. Any advice would be appreciated.
I have fabricated my own board for the OMAPL138 64Meg SOM to connect to. This board does not have all the functionality of the experimenter kit. It does not have the audio codec. It does not have the I/O expander chip for LEDS and Switches. It also does not connect the USB pins to USB connectors. I did bring out the USB pins to 0.1inch header pins and plan to connect to them in the future but currently they are not connected except USB_VBUS is jumpered to 5V.
On my board I do have an Ethernet connection (identical to the experimenter kit’s schematic) and the SD card connector (also identical to the experimenter kit’s schematic). I use an external JTAG to connect to the OMAPL138.
With PSP version .06 I have been able to boot Linux and develop a number of applications for both Linux and the DSP.
Currently I am trying to update to PSP .12, which is the current version at TI’s omapl138 getting started guide website. When the SOM is plugged into my board and using the prebuilt images in PSP.12 (that is ais-ubl-spi.bin,u-boot.bin,uImage), Linux does not boot. It gets stuck at the message “done, booting the kernel.” When I disconnect the SOM from my board and plug it back into the Experimenter Kit board everything boots perfectly. So I only have problems when the SOM is plugged into my board. I have tried out the PSP’s .08 and .11 also and they have the same boot problem when the SOM is plugged into my board.
I have also recompiled the kernel with all sorts of options and device drivers removed and still get the same hang. I have recompile the kernel to enable “early_printk” and have found out that the boot is getting stuck in the init thread function “clocksource_done_booting” Digging even deeper I found that the function call that is hanging is a call to the “__raw_readl” function passed a virtual address 0xfec20014. This is the virtual address of the TIM34 register of Timer0.
Again just to restate, if I unplug the SOM from my board and plug it into the Expermenter kit board all boots fine. So I am thinking it must have something to do with the chips on the Experimenter board not being on my board. When the I2C communicates with the io expander or the audio codec, does it setup the timer registers in a different way if it discovers the chips compared to if it does not find the chips on the I2C bus? It also seems to have to do with the address it is trying to read. Just to see if the same issue would happen I changed the address of the __raw_readl call to a register address for UART2. Reading that address did not cause Linux boot to hang.
Also after a bunch of reading last night I found an option that allows the system to boot. If I set in bootargs “clocksource=jiffies” then the SOM boots fine on my board. But this is not my desired fix since linux is not using the high res timer0_1.
Any advice?
Also as a side note for anyone interested. To get early_printk to work I had to change the clock value for PLL1 back to 150MHz in the UBL. If it was at the default of 132MHz the baud rate for the serial port ran slightly too slow and garbage was printed to the console. So I changed PLL1 back to multiple by 25 in the UBL. Anyone no why the PSP.12 UBL set the DDR2 rate to 132Mhz instead of the PSP.06 setting of 150MHZ?