[U-Boot] Jetson TX2 hangs during dhcp boot

[Andreas Färber]

Am 16.06.19 um 21:27 schrieb Mian Yousaf Kaukab:
> On Fri, Jun 14, 2019 at 11:40:49AM -0600, Stephen Warren wrote:
>> On 6/14/19 11:09 AM, Andreas Färber wrote:
>>> 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:
[...]
>>>>> 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 at 3400000.blk...
>>>>> Disk sdhci at 3400000.blk not ready
>>>>> Scanning disk sdhci at 3460000.blk...
>>>>> Found 32 disks
>>>>> copying carveout for
>>>>> /host1x at 13e00000/display-hub at 15200000/display at 15200000...
>>>>> copying carveout for
>>>>> /host1x at 13e00000/display-hub at 15200000/display at 15210000...
>>>>> copying carveout for
>>>>> /host1x at 13e00000/display-hub at 15200000/display at 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.
>>
>> Ah yes, I do see that path in our ATF code.
>>
>>> 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
>>
>> That's pretty unlikely since ATF code/data is in a protected memory region
>> that non-secure software can't access.

Good point - I was playing with the rpi3 TF-A target, which does have
everything in unprotected DRAM.

>>
>>> differing memory usage is uncovering a missing U-Boot EFI reservation?
>>
>> Perhaps. I know almost nothing about U-Boot EFI though.
>>
>>> (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.)
>>
>> Hmm. Are you building your own copy of ATF (you mentioned 2.1; I can't
>> recall what version we ship)?
> No, I am using the one shipped with R32.1.

Careful: Yousaf is talking about his TX2 setup, whereas I am talking
about my TX1 setup. His answer does not apply to my quoted TX1 section.

Yes, for TX1 I am using an OBS-built upstream TF-A v2.1 / v1.5.
Will check Yousaf's LINUX_KERNEL_IMAGE_HEADER patch helps on TX1.

Let's split the two if they're not connected and focus on TX2 here.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)