[U-Boot] Jetson TX2 hangs during dhcp boot

[Mian Yousaf Kaukab <ykaukab@suse.de>]

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:
> > > 
> > > What is TF-A?
> > 
> > The artist formerly known as Arm Trusted Firmware.
> 
> Ah OK. I had only ever heard that called ATF before.
4def07d5 Update Arm TF references to TF-A
> 
> > > > 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.
> 
> > 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.
> 
> FWIW, my usptream U-Boot test system uses L4T r28.1 to test Jetson TX1 and
> TX2. It does test DHCP/TFTP, but not EFI or booting a kernel.
> 
> Can you provide complete instructions on how to reproduce this issue (e.g.
> which components in L4T you replaced, how to build those replacements, how
> to get/build/use EFI, any config/script/... files you used from U-Boot/EFI
> to trigger the issue above)?
As shown in the u-boot log, I am using dhcp boot.
setenv boot_targets dhcp
boot

See if the instructions on the following link to setup the server works for you:
https://www.suse.com/documentation/suse-best-practices/singlehtml/sbp-multi-pxe-install/sbp-multi-pxe-install.html
and then populate it with Tumbleweed installation files from following:
http://download.opensuse.org/ports/aarch64/tumbleweed/iso/
Grub EFI binary can be found in EFI/BOOT/.

I am only replacing u-boot with the upstream u-boot using following
command:
./flash.sh -k kernel jetson-tx2 mmcblk0p1

Alternatively, I can do the testing this week if you provide me debug
builds.
> 
> Your best bet is likely to post all this information to the NVIDIA Jetson
> forum so our support people can track the process. I don't expect to have
> much time personally to look at EFI stuff on TX2 right now. Sorry.