Linux/AM3352: Kernel boot hangs

HS FAE Germany

Part Number: AM3352
Other Parts Discussed in Thread: AM3357, AM3359, TLK110, CDCE913

Tool/software: Linux

Hello,
customer want to port ICEv2 to customer boards. They use Linux (ti-processor-sdk-linux-am335x-evm-04.03.00.05) and to adapt it to the custom board which is close to ICEv2.

Main difference in HW (compared to ICEv2) are as follows:
- AM3359 replaced by AM3357
- NAND removed
- eMMC added
- PLL synthziser (I2C) replaced by 25 MHz OSC, one for each PHY (TLK110)
- 25MHz OSC and 32.768kHz OSC connected to AM3357 same way as on ICEv2.
- PLL syntheziser is removed and consequently no clock is fed to XTALIN (V10) of AM3357.

They have adapted SPL and u-boot and were able to boot from MMC1 (SDHC) into u-boot console. After autoboot has expired the board is stuck right after "starting kernel". There are no further printouts to the console. Kernel is stuck at "while (ticks == jiffies)" in function "static unsigned long calibrate_delay_converge(void)" in file "init/calibrate.c". In kernel config they have increased log level to "7", but last printout to console still is "starting kernel".

I can send Kernel config, dts and uboot dts in a seperate email.

What could be the reason? May be the removal of the external PLL syntheziser?

Do you have any suggestions for debugging?

Regards, Holger

over 7 years ago

0 Pavel Botev over 7 years ago

TI__Guru**** 170625 points

Hi Holger,

Check for changes of UART console between ICEv2 board and your custom board. The above problem is typically caused by mis-configuring the tty interface that the linux kernel uses by default for displaying the console messages. The issue might be also caused by error in your DTS file.

See the below pointers for more details:

processors.wiki.ti.com/.../Kernel_-_Common_Problems_Booting_Linux

e2e.ti.com/.../2231166

e2e.ti.com/.../658579
e2e.ti.com/.../664962
e2e.ti.com/.../605958
e2e.ti.com/.../677706
e2e.ti.com/.../366802

Regards,
Pavel

0 HS FAE Germany over 7 years ago in reply to Pavel Botev

TI__Mastermind 32220 points

Hello,
customer followed the links and tried all the UARTs from menuconfig without success.
In u-Boot they were using uart0 (pinmux) which is working fine. Therefore they guess uart0..3 in u-boot map to UART1..4 in kernel.
Can you please confirm which uart to be used in kernel – AM33XX UART1?

Kernel low-level debugging port
> 1. OMAP2/3/4 UART1 (omap2/3 sdp boards and some omap3 boards) (DEBUG_OMAP2UART1)
2. Kernel low-level debugging messages via OMAP2/3/4 UART2 (DEBUG_OMAP2UART2)
3. Kernel low-level debugging messages via OMAP2 UART3 (n8x0) (DEBUG_OMAP2UART3)
4. Kernel low-level debugging messages via OMAP3 UART3 (most omap3 boards) (DEBUG_OMAP3UART3)
5. Kernel low-level debugging messages via OMAP4/5 UART3 (omap4 blaze, panda, omap5 sevm) (DEBUG_OMAP4UART3)
6. Kernel low-level debugging messages via OMAP36XX UART4 (DEBUG_OMAP3UART4)
7. Kernel low-level debugging messages via OMAP4/5 UART4 (DEBUG_OMAP4UART4)
8. Kernel low-level debugging messages via TI81XX UART1 (ti8148evm) (DEBUG_TI81XXUART1)
9. Kernel low-level debugging messages via TI81XX UART2 (DEBUG_TI81XXUART2)
10. Kernel low-level debugging messages via TI81XX UART3 (ti8168evm) (DEBUG_TI81XXUART3)
11. Kernel low-level debugging messages via AM33XX UART1 (DEBUG_AM33XXUART1) (NEW)
12. Kernel low-level debugging messages via Zoom2/3 UART (DEBUG_ZOOM_UART)
13. Kernel low-level debugging via EmbeddedICE DCC channel (DEBUG_ICEDCC)
14. Kernel low-level debug output via semihosting I/O (DEBUG_SEMIHOSTING)
15. Kernel low-level debugging via 8250 UART (DEBUG_LL_UART_8250)
16. Kernel low-level debugging via ARM Ltd PL01x Primecell UART (DEBUG_LL_UART_PL01X)
choice[1-16]: 11

May be the main issue they have is that jiffies counter is stuck. Looks like the timer doesn´t fire. Their current understanding is that jiffies is derived from RTC. They have checked RTC_OSC_REG in u-boot as well as kernel and it is set to 0x48 (EN_32KCLK = 1, SEL_32KCLK_SRC = 1) in both cases. They tried also to set RTC_OSC_REG from 0x48 to 0x40, but behaviour is still the same. Can you please explain from which clock jiffies is derived on ICEv2?
Is their assumption is right that no clock must by fed to XTALIN (PLL sythesizer is removed on our board) as long as 25MHz crystal is connected to AM3357?

Regards, Holger

0 Pavel Botev over 7 years ago in reply to HS FAE Germany

TI__Guru**** 170625 points

Holger,

HS WG-FAE said:
In u-Boot they were using uart0 (pinmux) which is working fine. Therefore they guess uart0..3 in u-boot map to UART1..4 in kernel.
Can you please confirm which uart to be used in kernel – AM33XX UART1?

UART0 base address is 0x44E09000.

UART0 is described as uart0 (serial0) in u-boot DTS file (am33xx.dtsi). On ICEv2 board (file am335x-icev2.dts), UART3 is used for console, so you swith this to UART0.

UART0 is described as uart0 (serial0) in linux kernel DTS file (am33xx.dtsi). On ICEv2 board (file am335x-icev2.dts), UART3 is used for console. You need to change UART3 to UART0, not to UART1.

uart0..5 in u-boot map to uart0..5 in kernel.

linux-4.9.69/arch/arm/boot/dts/am33xx.dtsi

       serial0 = &uart0;
       serial1 = &uart1;
       serial2 = &uart2;
       serial3 = &uart3;
       serial4 = &uart4;
       serial5 = &uart5;

uart0: serial@44e09000 {
           compatible = "ti,am3352-uart", "ti,omap3-uart";
           ti,hwmods = "uart1";
           clock-frequency = <48000000>;
           reg = <0x44e09000 0x2000>;
           interrupts = <72>;
           status = "disabled";
           dmas = <&edma 26 0>, <&edma 27 0>;
           dma-names = "tx", "rx";
       };

0 Pavel Botev over 7 years ago in reply to HS FAE Germany

TI__Guru**** 170625 points

HS WG-FAE said:
May be the main issue they have is that jiffies counter is stuck. Looks like the timer doesn´t fire. Their current understanding is that jiffies is derived from RTC. They have checked RTC_OSC_REG in u-boot as well as kernel and it is set to 0x48 (EN_32KCLK = 1, SEL_32KCLK_SRC = 1) in both cases. They tried also to set RTC_OSC_REG from 0x48 to 0x40, but behaviour is still the same. Can you please explain from which clock jiffies is derived on ICEv2?
Is their assumption is right that no clock must by fed to XTALIN (PLL sythesizer is removed on our board) as long as 25MHz crystal is connected to AM3357?

On ICEv2 board, CDCE913 clock synthesizer provide clock (25MHz) to external PHYs only, NOT to AM335x device XTALIN/OSC0_IN/V10. On schematic, R144 is not populated, which means this connection is cut off. On ICEv2 board, AM335x V10 pin is supplied ONLY from 24MHz crystal Y3.

So I think removing CDCE913 Clock Synthesizer from your board is not an issue, clock jiffies are not related to it.

From what I understand, on your custom board you have 25MHz crystal connected to AM335x V10 pin, in place of 24MHz used in ICEv2. Make sure you have stable and good 25MHz clock supplied by that pin. Make sure you are aligned with AM335x datasheet requirements (stability, tolerance, etc) regarding input clock, check section 6.2 Clock Specifications. Check also OSC1 32KHz clock requirements (stability, capacitance, etc), as this clock might be also related to jiffies. See the below e2e thread:

e2e.ti.com/.../1080804

Make sure also your sysboot [15:14] pins has the correct value for 25MHz (b10), when your flow stuck.

Regards,
Pavel

Processors

Processors forum

Linux/AM3352: Kernel boot hangs