ERROR: ARI request timed out: req 89 on CPU 4 ASSERT: plat/nvidia/tegra/soc/t186/drivers/mce/ari.c <127> : retries != 0U
This time out means that TEGRA_ARI_ROC_FLUSH_CACHE_TRBITS ARI call timed out. Looks like the firmware responsible for handling this ARI call is stuck or overloaded and not servicing any calls.
-----Original Message----- From: Andreas Färber afaerber@suse.de Sent: Friday, June 14, 2019 10:10 AM To: Stephen Warren swarren@wwwdotorg.org; Mian Yousaf Kaukab ykaukab@suse.de Cc: u-boot@lists.denx.de; Stephen Warren swarren@nvidia.com; Tom Warren TWarren@nvidia.com; Varun Wadekar vwadekar@nvidia.com Subject: Re: [U-Boot] Jetson TX2 hangs during dhcp boot
Am 14.06.19 um 18:41 schrieb Stephen Warren:
On 6/14/19 11:09 AM, Mian Yousaf Kaukab wrote:
Hi, I am seeing a hang with dhcp boot on Jetson TX2. Its running firmware from L4T 32.1 with U-Boot from master branch (c2ea87883e) with [1] applied.
I use following command sequence at u-boot prompt to boot:
Tegra186 (P2771-0000-500) # setenv ftdfile tegra186-p2771-0000.dtb Tegra186 (P2771-0000-500) # setenv boot_targets dhcp Tegra186 (P2771-0000-500) # boot
Last thing I see is the following error from TF-A and the board hangs:
What is TF-A?
The artist formerly known as Arm Trusted Firmware.
U-Boot 2019.07-rc4-00137-g6fefd9c475 (Jun 14 2019 - 16:27:34 +0200)
...
TFTP from server xx.xx.xx.xx; our IP address is xx.xx.xx.xx Filename 'aarch64/grub.efi'. Load address: 0x80280000
...
MMC: no card present Scanning disk sdhci@3400000.blk... Disk sdhci@3400000.blk not ready Scanning disk sdhci@3460000.blk... Found 32 disks copying carveout for /host1x@13e00000/display-hub@15200000/display@15200000... copying carveout for /host1x@13e00000/display-hub@15200000/display@15210000... copying carveout for /host1x@13e00000/display-hub@15200000/display@15220000... ERROR: ARI request timed out: req 89 on CPU 4 ASSERT: plat/nvidia/tegra/soc/t186/drivers/mce/ari.c <127> : retries != 0U
That file doesn't exist in U-Boot; I guess it's part of grub.efi?
Looks rather like a TF-A path to me, CC'ing Varun.
As Yousaf says above, it's the TF-A you guys ship with latest R32.1.0.
Maybe the tftpboot operation is overwriting memory used by your TF-A, or differing memory usage is uncovering a missing U-Boot EFI reservation?
(I recently wondered whether TX1 may be missing some, as I needed multiple tries to boot the kernel successfully there - TF-A 2.1 didn't work there, so some more investigations TBD. R28.3.0 still wasn't booting U-Boot ~2019.04, I needed R24.2.2 still as you once suggested.)
Regards, Andreas
-- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg)
----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------