i.MX6ULL continued eMMC issues - lockups

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

i.MX6ULL continued eMMC issues - lockups

1,592件の閲覧回数
chadwolter
Contributor III

NXP - a few weeks ago, I had an issue with programming a Kioxia eMMC chip on my custom i.MX6ULL host board, as I am attempting to qualify both Kioxia and Macronix as second sources.  For background that thread is here:

https://community.nxp.com/t5/i-MX-Processors/i-MX6ULL-trouble-with-Kioxia-eMMC/m-p/1274578#M173824

The issue I am having now, with both these chips, are that they reach a certain point in my boot process and intermittently hang.  The Kioxia part hangs 1-3 times during 25 power cycles but the Macronix does this a little over half the time under the same number of power cycles.  The interesting thing is that if there is a failure, it ALWAYS does it in the exact same location....in our custom start script, there is a while loop with a sleep 1 statement that prints out a "." character 5 times if there is no serial number in the board.  The board hangs here, and I can at this instant see a drop in current consumption.  Normal current consumption at this point is usually 125mA, but under the hang case, it drops to 20mA.  Another POR at this point will make it restart the boot process, at which point it may or may not hang in the same spot.  I did attempt to remove this wait from our start script, and the board will then always boot normally, and I can log into the command line interface, but again, it will fail and hang at some point.  Any ideas on what we may be running into here?  I have done some searching around, and I can't really find anything helpful.  This is on the 4.9.11 NXP kernel we have been using.

Also, I am not sure whether this is a clue or not, but on one of the trials I was running, I got the following error (but just this one time out of probably 150 different reboots)

..../opt/iprf/firmware/start.sh: lineUnhandled fault: imprecise external abort (0x1c06) at 0x00078c55
364: 1662 Bus error sleep 1
pgd = 82d40000
[00078c55] *pgd=82f42835, *pte=80bf459f, *ppte=80bf4e7e

Please let me know what additional information may be helpful to you.

thanks

Chad

0 件の賞賛
4 返答(返信)

1,421件の閲覧回数
peter_tian
NXP Employee
NXP Employee

Hello @chadwolter

 

NXP released BSP driver reset eMMC through software command sequence. HW reset is optional.
On i.MX6ULL, NAND_ALE pin is input with keeper by default, which maybe an uncertain signal for eMMC RST.

Did you capture the waveform of eMMC_RST# line when system hang occured?

Image 4.jpg

Please add the pin configuration as below into all pinctrl_usdhc2 groups of uboot-imx and linux-imx.


Config: MX6UL_PAD_NAND_ALE__USDHC2_RESET_B 0x170b0

 

Another point, can you please share the log to us for knowing the failed location in the boot process? Thanks.

 

Best Regards,

Peter

0 件の賞賛

1,567件の閲覧回数
igorpadykov
NXP Employee
NXP Employee

Hi Chad

 

random hang may be caused by signal integrity issues as described on

https://community.nxp.com/t5/i-MX-Processors/eMMC-8GB-to-4GB-crash-on-linux-yocto-boot/m-p/373231

also one can try to test ddr memory and update image with new ddr calibration settings found from test in

https://source.codeaurora.org/external/imx/uboot-imx/tree/board/freescale/mx6ullevk/imximage.cfg?h=i...

 

Best regards
igor

0 件の賞賛

1,523件の閲覧回数
asim_zaidi
NXP Employee
NXP Employee

  Can you provide an update  on the previous suggestions and some more details on your testing

  • How is the eMMC /board being reset - is power being removed?
  • Is the hang issue observed when the power is first applied or only after subsequent resets?
  • Is the hardware RST_B pin connected in your design?
  • Is there any SW or HW dependency on the hang?
  • Does the issue occur with the original eMMC memory?

 

0 件の賞賛

1,475件の閲覧回数
chadwolter
Contributor III

Hey Asim -

I still have not found a resolution to our issue.  To answer your questions from below:

  • How is the eMMC /board being reset - is power being removed?

Yes, power is being removed.

  • Is the hang issue observed when the power is first applied or only after subsequent resets?

it can be on the first reboot after the code has been flashed, or subsequent reboots.

  • Is the hardware RST_B pin connected in your design?

Yes, but I noticed the signal is not defined in the dts or dtsi file.  Should I try to define this?

  • Is there any SW or HW dependency on the hang?

No

  • Does the issue occur with the original eMMC memory?

No

 

Also, for the past few days, I have been playing with the registers in this post that @igorpadykov mentioned:

https://community.nxp.com/t5/i-MX-Processors/eMMC-8GB-to-4GB-crash-on-linux-yocto-boot/m-p/373231

I have been unable to make any combinations of the registers work.  There are combinations of the registers that will reliably make the boards containing the alternate eMMC vendors boot, but if I allow them to run overnight they are always locked up the next morning.  If you want to see, I attached the results of this testing.

Chad

 

0 件の賞賛