Hi All,
It has a T2081 board.
There is a T2081 with eight cores, it does recognize eight of the boot boot logo, as shown below.
Assemble the two were the same board like that this phenomenon appears in one board.
Because of this problem should have access to the shell.
A hardware fault would not be any part of this phenomenon appear?
fail boot log, board-a |
---|
... CPU up timeout. CPU up mask is 7 should be f ... e6500 family performance monitor hardware support registered Processor 6 is stuck. smp_85xx_kick_cpu: Can not start CPU #7. Start CPU #6 first. smp: failed starting cpu 7 (rc -2) Brought up 6 CPUs |
pass boot log, board-b |
---|
e6500 family performance monitor hardware support registered Brought up 8 CPUs |
Thanks,
Best regards,
Gyosun.
Please provide PVR and SVR values for the processors on both boards.
Ensure that IFC_A[16:20] are not pulled down during power-on reset. This pin may be pulled up, driven high, or if there are any connected devices, left in tristate. If this pin is connected to a device that pulls down during reset, an external pull-up is required to drive this pin to a safe state during reset.
Hello ufedor,
Both boards have the same value.
=> md.l ffe0e0000 32
fe0e0000: 207bff7f ff000000 00000000 00000000 {..............
fe0e0010: 00000000 00000000 00000000 00000000 ................
fe0e0020: ff000000 00000000 24000000 00000000 ........$.......
fe0e0030: 00000000 00000000 00000000 00000000 ................
fe0e0040: 00000000 00000000 00000000 00000000 ................
fe0e0050: 00000000 00000000 00000000 00000000 ................
fe0e0060: 00000000 00000000 00000000 00000000 ................
fe0e0070: 00000200 00000000 00000000 00000000 ................
fe0e0080: 00000000 00000000 00000000 00000000 ................
fe0e0090: 00000000 00000000 00000000 00000000 ................
fe0e00a0: 80400120 85310011 00000040 00000000 .@. .1.....@....
fe0e00b0: 00000000 00000000 00000000 00000000 ................
fe0e00c0: 00004000 00000000 ..@.....
=>
All are pulled up.
Thanks,
Gyosun.
Please provide complete U-Boot and Linux boot logs for both boards.
Use a digital scope to verify IFC_A[16:20] behaviour during POR on the problem board.
Please provide raw memory dumps of CCSR area containing all DDR controller registers (offset 0x00_8000 - 0x00_8FFF) for proper and failing cases.
It will be more convenient to investigate the issue as technical case:
Thank you for your help.
But the problem has not yet been resolved.
With the help of others better.
Thank you.
Best regards,
Gyosun.
Please note that the investigated issue is not general - it is specific to the sigle board.
This is why it was recommended to create a technical case.