OMAP-L138, Linux kernel boot hangs after

Gilbert Brisset

Other Parts Discussed in Thread: OMAP-L138

Hello,

We are developping a custom board based on the OMAP-L138 SOC with a design closest as possible to the LogicPD da850evm board.

Main differences are :

- DDR2 instead of mDDR

- 83848 PHY chip instead of 8720 PHY chip without I2C stuff

- serial console available only on UART 0.

I am using the last psp : DaVinci-PSP-SDK-03.22.00.02.tgz.

I have modified succesfully U-Boot and it now works fine. It loads the Linux kernel uImage through TFTP and launch it.

The kernel hangs after :

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

I have done some modifications to Linux Kernel board-da850-evm.c file :

- add a davini_cfg_reg_list(da850_uart0_pins) call

- comment the __raw_writel(0, IO_ADDRESS(DA8XXX_UART0_BASE) + 0x30);

- in the da850_evm_console_init() function, set the preferred console at 0 instead of 2

In the U-Boot bootargs, I set the console to ttyS0.

I had configured the kernel to use the RMII PHY instead of MII.

I have enabled CONFIG_SERIAL_8250_CONSOLE in the kernel config Drivers section and

enabled CONFIG_DEBUG_LL in the Kernel hacking section.

I had also tried to replace, in the bootargs, the console=/dev/ttyS0 by console=uart,io,0xe1020000 without success.

Does the kernel reconfigure the memory controller ? (I have not find where).

Have I to apply the same modifications than that applied to U-Boot ?

Do I miss some modification needed to use the UART0 instead of UART2 allowing early kernel traces.Any help is welcome.

Thank you

Gilbert Brisset.

over 12 years ago

0 chethu gowda over 12 years ago

Genius 4090 points

Hi please share your boot.scr script.

0 Gilbert Brisset over 12 years ago in reply to chethu gowda

Prodigy 160 points

I don't know what is boot.scr script. I don't have such a file on my development host.

0 Prabhakar Lad over 12 years ago

Guru 11260 points

Hi,

Please refer this link for debugging where its getting hung

http://processors.wiki.ti.com/index.php/FAQ_for_DaVinci_Linux

Regards,

--Prabhakar Lad

0 Gilbert Brisset over 12 years ago in reply to Prabhakar Lad

Prodigy 160 points

Hi,

I had already check that link :

1) Kernel hacking -> Kernel debugging -> Kernel low-level debugging functions :

done, that enable the CONFIG_DEBUG_LL kernel option.

2) ... console=uart,io,0xe1020000,115200n8 ...  :

done, no results

3) Drop a printascii() in printk() and see where it hangs

    The link says :

          Use the debugging printascii() stuff for your platform in arch/arm/kernel/debug-armv.S (enabled by CONFIG_DEBUG_LL) and drop a printascii() into printk() (kernel/printk.c) just after the vsprintf() call, and monitor the relevant serial port.

I do not understand that. There is no vsprintf() call in the printk() function in my psp.

Any suggestion ?

Regards

Gilbert Brisset.

0 Bartosz Bosowiec over 12 years ago in reply to Gilbert Brisset

Intellectual 750 points

Hi,

Add vsprintf() call - after va_start() - and then call printascii(). Create some buffer there for this.

0 Gilbert Brisset over 12 years ago in reply to Bartosz Bosowiec

Prodigy 160 points

Hi,

Thank you for the tip.

The printascii() adds just one extra line of trace .

Kernel hangs just after :

Booting Linux on physical CPU %d.

I just have added printascii(fmt);

So it is normal that it prints %d.

I think that there is something about that in the TI forums.

I will continue to investigate.

But any good idea is welcome.

Gilbert Brisset.

0 Gilbert Brisset over 12 years ago in reply to Gilbert Brisset

Prodigy 160 points

No, it does not hangs here.

It was an old code that I forgot to remove.

Now thanks to printascii, I got a lot of traces.

As I have done a lot of trials, I had to restart from a neat configuration and study that.

I'm no longer stucked.

0 Gilbert Brisset over 12 years ago in reply to Gilbert Brisset

Prodigy 160 points

Hi,

It makes me reakky crazy.

I have removed all the printascii I had added, and now it runs OK.

I should have done a mix of modifications.

I have to troubles now,

I have configured the kernel to use RMII instead of MII, but it is the MII that was configured.

I have forced the usage of RMII now, but I think to do things to have our PHY DP83848

0 Gilbert Brisset over 12 years ago in reply to Gilbert Brisset

Prodigy 160 points

HI,

Sorry for the previous post that started too much early, without rereading.

My problem is solved now.

The main issue was to disable PINMUX support in kernel config.

I had done a very exhaustive job in U-Boot to have a INMUX configuration that matches exactly my specific hardware.

I don't check all the da850evm Linux kernel code, but I guess that there is default PINMUX configurations in the kernel that conflicts with the use of UART0.

Dropping printascci is a good help.

Thank you

Processors

Processors forum

OMAP-L138, Linux kernel boot hangs after