P1022 processor=> mmc0: Timeout waiting for hardware interrupt.

[hemwant]

I am having a custom board with P1022 processor, the uboot is booted with SPI flash , there is eMMC card with 4GiB storage. The eMMC is divided into three partition p1(200 Mb), p2(200Mb) and p3 (3Gb). The p1 partition of eMMC is used for booting the kernel and fs. The p3 partition is used for application data in kernel, and p2 is reserved for now.

 After reboot, there is a corruption in eMMC and mmc0: Timeout waiting for hardware interrupt message is dumped during boot phase and simulaneously lot of input/output error occurs in eMMC. After that file system becomes read only. I am attaching the crash log of kernel and uboot parameters.

The frequency of this error is after every 3-4 reboot given to system.

[hemwant]

We are bitbanging GPIO's to program the xilinx FPGA , and whenever the card boots up the fpga update happens , it creates problem after 3-4 reboot and throws the above dump.

On removing fpga update the card works normally in reboot.

I wanted to know the reason/probable cause of kernel throwing exception " mmc0: Timeout waiting for hardware interrupt" ?

[yipingwang]

Can please you share the block diagram of your custom board, esp. the part which depicts FPGA connectivity with other IP's?

Can you please also share the boot logs from the working setup as well, as there are many error messages throwing up in crash_log_reboot_24_5_msmh?

Since all the mmc logs are showing card status as 0x0, so can you please also check mmc info command on u-boot prompt (in bad case)?

[hemwant]

Hello yipingwang‌ ,

PFA the schematic of fpga and normal log of the card from working setup.

Since all the mmc logs are showing card status as 0x0, so can you please also check mmc info command on u-boot prompt (in bad case)?

I have already shared the log of mmc info in uboot.

I have doubt related to mmc info command output, in which case you want to run mmc info at uboot?

1) We have to stop at the uboot and run mmc info, and check for issue comes or not. If issue has come , then that mmc info will be sent to you.

2) In this case when issue has come in the mmc, we hard reset the processor and then stop at uboot and run mmc info , provide that info to you.

[yipingwang]

Please refer to the feedback from the application team.

Based on the details provided by the customer, there doesn't seem any reason to suspect any issue with P1022.

[hemwant]

yipingwang‌

When i disable CONFIG_SMP in .config of kernel the above issue is not reported but when CONFIG_SMP in .config of kernel is enabled the issue occurs.

Please tell if there is any thing we are missing out on this.

[yipingwang]

Hello Hemwant Rawat ,

Would you please run "mmc info" under u-boot?

Which version Linux SDK do you use? QorIQ Linux SDK 1.8?

Thanks,

Yiping

[hemwant]

Hello yipingwang‌

Would you please run "mmc info" under u-boot?

=> mmc info
Device: FSL_SDHC
Manufacturer ID: fe
OEM: 14e
Name: MMC04
Tran Speed: 52000000
Rd Block Len: 512
MMC version 4.41
High Capacity: Yes
Capacity: 3.5 GiB
Bus Width: 4-bit
Erase Group Size: 512 KiB
HC WP Group Size: 4 MiB
User Capacity: 3.5 GiB
Boot Capacity: 16 MiB ENH
RPMB Capacity: 128 KiB ENH

Which version Linux SDK do you use? QorIQ Linux SDK 1.8?

QorIQ Linux SDK 1.8

[yipingwang]

Let's first Try to clean and re-format the eMMC device.

For doing this (take reference from SDK document)-

1) Make sure that you tftp/copy the ramdisk image on to RAM

2) Change the bootargs in u-boot env variables, make root as /dev/ram0 instead of dev/mmcblk0p1, also change other bootargs supporting ramdisk.

3) Once you get onto linux shell, format your eMMC device with desired partitions using fdisk command options (as mentioned in the SDK document).

4) Reboot and again revert back to mmc device as root rather than ramdisk from u-boot shell.

[hemwant]

With the above flow there is no issue, the issue is related to some firmware(FPGA-xilinx) update that is initiated in case of reboot .

Note: This fpga update is not part of the linux and is customised by us for our case.