Hi,
for project purpose, I need to load and verify the u-boot using TFTP boot method in TX2 board before flashing to the emmc device. I was able to download u-boot.bin in $load_addr and u-boot-dtb.bin in $fdt_addr_r address. but required to know the tftp boot argument to boot.
Can you please help me.
Thanks in advance,
Muneeswaran R
This is not really an answer, but in serial console under U-Boot most of the information is available via the content of environment variables. See “env print”, look for starting the system with the network controller (e.g., “usb start” for a USB network dongle), and then getting an address (e.g., “dhcp”). You will see a series of “boot*” variables which probably contain what you are looking for, but beware that not all controllers or chipsets are available in U-Boot even if available once the Linux kernel starts.
Thanks for reply. But i am looking for tftpboot method to load uboot image into RAM and and execute from the loaded location. I do not see the tftpboot environment variable in the Tx2 board.
I loaded the u-boot.bin image in 0x80080000 and u-boot-dtb.bin in 0x82000000. but the exiting tftpboot command looking for kernel and rootfilesystem image to boot. So i don’t have correct tftpboot command to load u-boot image.
Please share the procedure do load u-boot with dtb image and boot it up in the RAM.
Are you trying to tftp boot without U-Boot being installed on the Jetson (or going to tftp download prior to U-Boot on eMMC ever loading)? Versus letting U-Boot on Jetson run and load a different U-Boot to overwrite itself (essentially chain loading)?
Yes,you are right.I am trying load the customized u-boot on already running u-boot(booting from EMMC devices) in Jetson board.
Is this the R28.1 release? Earlier releases differed significantly.
How far has your boot succeeded so far? Is there a serial console log?
Example information: Did a DHCP request go out, was an address assigned, and from the TFTP server side was a file download attempt logged?
There is a significant difference between using TFTP to run a boot script versus overwriting itself with a new binary. Just to be clear (I know I sort of asked this already) it isn’t a boot script you are interested in downloading, but instead an entire binary file which would allow you to test a completely independent U-Boot binary (in which case you are probably testing different versions of U-Boot and don’t want to flash)?
yes, I am using R28.1 release package source code of u-boot with some additional functionality added to meet my requirement.
Just interested to test and verify the entire u-boot binary in the jetson board before flashing into it.
After loading the u-boot binary using tftp then while executing it’s stuck in dram_init() and trying to get flash device tree blob file. It means that u-boot try to read dtb file and find the DRAM size and configure it.
Tegra186 (P2771-0000-500) # go 0x80080000
U-Boot 2017.11-rc2 (Oct 25 2017 - 17:48:52 +0530)
TEGRA186
Debug: Model: NVIDIA P2771-0000-500
Debug DRAM:
Let me know how to address this issue.
From what I can see U-Boot has extensions to download and run a kernel with DTB. This seems to expect a command line format which a kernel would use. I’m not really sure at this point if the mechanism to download and store a boot loader binary is supported using the automated methods related to tftp/dhcp/bootp/pxe style boot. You might need to modify the existing U-Boot for that case, but I am not certain.
Does anyone here know if U-Boot is able to download and store a binary boot loader (not a kernel or dtb) and execute this as if the boot loader binary was natively on the Jetson? In particular cboot hands off to U-Boot…does cboot use any kind of command line to pass to U-Boot which would mean that a manually loaded U-Boot would also need arguments passed to it?
Hi muneeswaranr,
U-Boot does have the capability to store a binary in RAM, and execute it via ‘go’ – we believe that you have done that in the comment posted #7 11/2/17 @ 9:09am. However, it will hang, as you showed. That’s most likely because U-Boot depends on some registers at entry to be set up similar to the kernel:
X0 = dtb_addr
X1 = 0
X2 = 0
X3 = 0
Without the DTB addr, U-Boot can’t parse the ‘memory’ node to determine the mem start/end boundaries, and will hang in dram_init()/query_sdram_size().
You can try loading your U-Boot binary into RAM @ 0x80080000 (CONFIG_SYS_TEXT_BASE), loading the DTB from the BSP somewhere else in RAM (that doesn’t conflict with or overwrite U-Boot), and then setting X0 to the physical address of their DTB, and then doing the ‘go 0x80080000’. That might work.
Note that we understand you not wanting to reflash everything for each iteration of your U-Boot code, but you can just flash it with the ‘-k kernel’ (or –k LNX on T210, IIRC) flash.sh command, which would be much quicker.
Thanks
Hi,
Thanks for your response. I tried the instruction as mentioned in the mail and issue remain same.
also used the various dtb address to load the u-boot-dtb.bin to ruled out BSP conflict in the u-boot.
I shared the console message for your ref to verify, please suggest if anything missing here.
Tegra186 (P2771-0000-500) #
Tegra186 (P2771-0000-500) # tftpboot 0x80080000 192.168.1.70:u-boot.bin
ethernet@2490000 Waiting for PHY auto negotiation to complete… done
Using ethernet@2490000 device
TFTP from server 192.168.1.70; our IP address is 192.168.1.126
Filename ‘u-boot.bin’.
Load address: 0x80080000
Loading: *\0x08##################################
\0x09 2.2 MiB/s
done
Bytes transferred = 490478 (77bee hex)
Tegra186 (P2771-0000-500) # tftpboot 0x82000000 192.168.1.70:u-boot-dtb.bin
ethernet@2490000 Waiting for PHY auto negotiation to complete… done
Using ethernet@2490000 device
TFTP from server 192.168.1.70; our IP address is 192.168.1.126
Filename ‘u-boot-dtb.bin’.
Load address: 0x82000000
Loading: *\0x08##################################
\0x09 2.3 MiB/s
done
Bytes transferred = 490478 (77bee hex)
Tegra186 (P2771-0000-500) # X0=0x82000000;X1=0;X2=0;X3=0
Tegra186 (P2771-0000-500) #
Tegra186 (P2771-0000-500) # go 0x80080000
U-Boot 2017.11-rc2 (Nov 17 2017 - 18:00:27 +0530)
TEGRA186
Debug: Model: NVIDIA P2771-0000-500
Debug DRAM:
Regards,
muneeswaranr,
Looks like you are loading u-boot-dtb.bin into the memory space for the DTB. That’s not right - that file is the U-Boot binary with the DTB appended. What you want to load there is the actual DTB file from your BSP, for instance, in the TX1 devkit, that would be:
tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb
Load that to 0x82000000 and try again.
Thanks
Hi,
I am using Tx2 board so downloaded the tegra186-p2771-0000-500.dtb(arch/arm/dts/) into 0x82000000 location.There is no progress still u-boot stuck at the same place.
Tegra186 (P2771-0000-500) # tftpboot 0x82000000 192.168.1.70:tegra186-p2771-0000-500.dtb
ethernet@2490000 Waiting for PHY auto negotiation to complete… done
Using ethernet@2490000 device
TFTP from server 192.168.1.70; our IP address is 192.168.1.126
Filename ‘tegra186-p2771-0000-500.dtb’.
Load address: 0x82000000
Loading: *\0x08#
\0x09 3.9 KiB/s
done
Bytes transferred = 7090 (1bb2 hex)
Tegra186 (P2771-0000-500) # x0=0x82000000;x1=0;x2=0;x3=0
Tegra186 (P2771-0000-500) #
Tegra186 (P2771-0000-500) # go 0x80080000
U-Boot 2017.11-rc2 (Nov 21 2017 - 19:06:41 +0530)
TEGRA186
Debug: Model: NVIDIA P2771-0000-500
Debug DRAM:
Thanks
muneeswaranr,
Sorry, mixed this up with another (TX1) issue.
Just noticed that you’re trying to set the entry regs (X0/X1/X2/X3) via the U-Boot command line. That’ll have no effect - we need some kind of ‘cpu reg’ command, etc. to do that directly, or you’ll need to set X0 = 0x82000000 in the ‘go’ command, or in your modified U-Boot header, maybe in cboot_ll.S (hard-code cboot_boot_x0 with ‘dword 0x82000000’, etc.).
Sorry I missed that - U-Boot isn’t really set up to modify CPU regs easily AFAIK, so you’ll have to do some customizing here.
HTH,
Tom