I tried to enable the HYP mode when the CPU is boot up so that I can run Xen on Jetson TK1 board.
I have successfully flash the u-boot binaries from L4T_R21.4 and I can see that the Linux boot on the TK1 board and that the CPU boot in SVC mode.
In order to enable the HYP mode at U-boot, I have to compile the u-boot from source.
So I downloaded the source code from u-boot repo: git://git.denx.de/u-boot.git
I checkout the tag tag v2016.03.
I compiled u-boot with the command on the TK1 board
make jetson-tk1_defconfig
make
Then I copy the u-boot.bin from the TK1 board to the host machine and place it into the L4T folder/bootloader/ardbeg
Then I flash the u-boot with the command
sudo ./flash.sh -k EBT jetson-tk1 mmcblk0p1
I can see from the flash.sh output that it’s using the new u-boot.bin.
However, after the new u-boot is flashed into the board, the board can no longer boot up. I cannot see any information.
The last information I saw from the TK1’s serial port is:
End Downloading EBT
Time taken to download partition: 190 ms
WriterThread: Exiting
Rebooting device after flashing.
My question is:
Does anyone successfully compile u-boot from source and flash it into the TK1 board?
Did I forget to configure something to make the new uboot work?
I noticed that the new u-boot.bin has a different size with the original u-boot.bin that comes with L4T. I’m not sure if I should configure something?
If you happen to have a u-boot.bin that works and enable the CPU into the HYP mode, could you share it so that I can try it out on my board.
Thank you so much for your time and help on this question!
I have been stuck at this for a whole day… Hope someone could save me… :-(
I believe the u-boot which comes with a JTK1 is modified from mainline, though I can’t swear to it. Have you tried the source code with the R21.4 download page? There are some u-boot compile notes in the documentation which comes with the driver package as well. Compiler version may also matter, probably the Linaro 4.8 arm-none-eabihf would be correct (I’m assuming cross-compile).
FYI, u-boot.bin is NULL-padded before flashing if the binary is not an exact size…the extra bytes of pre-pad versus post-pad should all be NULL.
Thank you so much for your useful information, linuxdev!
I tried the source code downloaded from NVIDEA R21.4. It still does not work…
There are two things interesting/suspicious:
I compiled U-boot on TK1 board, instead of using cross compiling. Does U-boot have to be compiled by cross-compiling? When I read the U-boot documentation on NVIDIA TK1 board, it says we need to do cross compiling. But I don’t understand why cross compiling is a must?
The working u-boot.bin is NULL-padded. If I remove the u-boot.bin under ${L4K_FOLDER}/bootloader/, and flash the original u-boot.bin to eMMC, I found that ./flash.sh will generate a u-boot.bin under ${L4K_FOLDER}/bootloader/ and the generated u-boot.bin is slightly larger (12Bytes larger) than the u-boot.bin under ${L4K_FOLDER}/bootloader/ardbeg/.
However, if I replace the original u-boot.bin with the compiled new u-boot.bin into the ${L4K_FOLDER}/bootloader/ardbeg/, the generated u-boot.bin under ${L4K_FOLDER}/bootloader has exact the same size as the new u-boot.bin. So I guess it’s not NULL padded?
In addition, the size of the new compiled u-boot.bin is different from the original working u-boot.bin.
My question is: If u-boot.bin wants to work, should the size be same?
How can I fix this? Is there any documentation to fix this?
Thank you again for your time and help in this question!
Another question is: how can I determine/find out the exact size the u-boot.bin has to be? If I know the exact size, maybe I can manually pad it by using dd?
The flash software does the padding. If you look at the logs of a regular flash, you’ll notice notes about padding u-boot.bin. I do not know the rules for how the padding is done, and some sizes may not need padding. The ardbeg folder is the unpadded u-boot.bin, and your version should probably go there (don’t forget to save a backup of the original u-boot.bin).
Understand that the boot loader is not running in or under Linux…the boot loader in fact does not have an operating system behind it at all. Boot loaders are essentially a micro operating system of their own, and the only program they know how to run is the kernel of the operating system they are about to load to overwrite themselves (along with drivers specific to loading that kernel). Normally compilers for Linux apps would take into account the environment of what you are building for, e.g., ARM hard float calling convention. Boot loaders are bare metal, there is no environment. You would typically cross compile because the native compile under a JTK1 is essentially alien to bare metal (same instruction set, but nothing supporting execution exists on bare metal). Thus, cross compilers for a Linux user space app might have a name arm-linux-eabihf, whereas a compiler for a boot loader would be arm-none. I do not know what the consequences would be for using code following linux-eabihf within a boot loader running on bare metal.
I would have to do some experimenting to find out about the proper way to add the custom boot loader, but keep in mind that quite often you cannot just flash the boot loader partition itself…all of the partitions which follow after the boot loader may be shifted unless the boot loader you are flashing is the same exact size as the prior boot loader. I’m not sure that flash to EBT will do as you expect without breaking other partitions further out.