We have a custom carrier board holding the Jetson TX1, which has the TX1’s UART0 and UART1 TX and RX pins connected to another embedded board. We power up two boards at the same time and TX1 couldn’t boot into kernel.
I read the documentation about the OEM product design guide and it says that the UART0 and UART1 pins are used for the RAM code strapping and boot select pins during startup.
But when i use the Orbitty Carrier and it has the same UARTs (ttyS0 and ttyTHS2 in Linux), i don’t have this problem when i close the u-boot’s console. I also close the u-boot’s console in custom carrier board, but still the TX1 doesn’t boot when the two boards are powered up at the same time.
I also routed the UART 2 and UART3 of the TX1 in the custom carrier, and i don’t connect these ports anywhere. They are near a uart pin and they also make the TX1 enter into the no boot state when there is a circuit driving their near pins. It seems very interesting.
If U-Boot serial console is not removed before starting U-Boot, then I would expect any activity at all on the port to cause dropping into the U-Boot console and stopping boot. I do not know which of your UARTs might possibly be used as serial console, but you might want to verify the boot loader has had this disabled. Linux and U-Boot are independent of each other for serial console function…if serial console is disabled in one, then the other will still exist until removed.
With Linux and U-Boot having serial disabled, then it would seem to be a bootstrapping issue. I couldn’t tell you though on a custom board what to look for. If you have a JTAG debugger which will work in U-Boot you could possibly get a stack frame at the point of locking…otherwise I am at a loss as to what to check.
I have no JTAG debugger, let me explain the status:
When i first power up the Jetson TX1 with the other embedded board connected to its uarts, the Jetson TX1 doesn’t boot, but when i disconnect the other embedded board and power up the Jetson TX1, then connect the other embedded board and REBOOT the Jetson via sudo reboot, it boots with the other embedded board connected. I think this is not a u-boot issue, am i right?
I can only tell you what it “sounds like”…which is rather vague. During cold boot there is a certain amount of setup done in early stages which are independent of any software loaded. Then there is setup in U-Boot, followed by DTB and kernel setup as the Linux kernel loads. In theory all of that setup would be the same regardless of cold boot or software reboot.
This seems to not be true in your case. There are probably some details of boot which are not initialized on cold boot, but which are preserved during a software reboot command…some hardware and firmware retain a setting which was edited during a live session. I believe this is probably what is going on…something is not initialized during cold boot, but is retaining a correct configuration during a software reboot. Your best bet is to closely examine the device tree file related to those serial ports and make sure that what is there during boot loader stage is the same thing as what is present just prior to a reboot. Consider also exploring “/sys/firmware/devicetree/base/”.
Does anyone here know if he can use serial console to display the equivalent of a device tree from U-Boot command line for comparison to what he sees after boot completes?
EDIT: Just found this…from serial console in U-Boot command line:
I have the devicetree’s source files. But if this is a bootstrap issue, I think it will be about the first stage bootloader, not the second stage bootloader (u-boot). Because the first stage bootloader checks the bootstrap pins and decides where to look for the u-boot (or zImage kernel) headers. I think during cold boot, the first stage bootloader starts, but during software reboot, does the program counter jumps to u-boot start point bypassing the first stage bootloader? Or the first stage bootloader executes in both the cold and warm boot?
In the Tegra X1 technical reference manual, page 789, it says:
The Boot ROM is an actual ROM built into the chip, and the Boot Loader and OS recovery section are externally loaded code.
The Boot Loader is only used for Cold boot; Warm boot utilizes operating-system recovery code
I think the problem is, the FSBL can not decide where to boot in the cold boot. But when i power off the other embedded device which is connected to UART0 and UART1 of the Jetson and successfully boot the Jetson, and give a sudo reboot, Jetson TX1 can boot. I have only problem in cold boot.
What is interesting is, isn’t there anybody facing this boot failure when the uarts 0 and 1 are connected to another device? Am i the only one? I don’t think so. Another interesting thing is, with a u-boot hack, the Orbitty Carrier doesn’t have the boot problem, despite it has the same uarts.
You are probably correct about the stage, but it still feels like some condition of a fully booted system is being retained from a reboot, but not set during a cold boot. If you use the U-Boot command line during both a cold boot and a reboot, then do a diff of the log files (a serial terminal should be able to log, then edit out the parts which are not the actual device tree output), I am hoping there is a difference (literally use “diff -c” between the two files). If you see a difference then you might have an idea of what the source is for causing that difference. If there is no difference, then that too is a clue. In the case that there is a difference, then a change from what is in U-Boot to what is in “/sys” version of the tree would indicate which part of the dtb file might be influencing this.
Keep in mind that how a UART works and what depends on it is at least determined in part by device tree…if the device tree is not constant between two tests then it is hard to know why the two tests differ. I do not have an Orbitty Carrier, but I suspect device tree differs.
If not, perhaps someone with knowledge of first stage boot can elaborate on UART setup prior to U-Boot.
I will try to connect u-boot console with some wirings.
But I have a question:
As described in the OEM Product Design Guide Page 63
I think the First stage BL will open the uart pins as GPIOs, and read them. So, if that is the case, system would not jump into u-boot from FSBL because it will try to boot another device than eMMC I think.
I am not sure about the answer to that. The way I read it is that your hardware using those TX/RX UART0 lines must be tri-state and float during first stage boot for default boot behavior. How changing RAM_CODE by pulling those lines high or low might change boot I do not know (you would have to know how the RAM_CODE is altered, and what each altered state implies).
It seems UART1 TX would best be tri-state as well, but it only claims driving the one pin high would be a problem, so driving it low should be ok.
I guess a relevant question is whether you want to alter RAM_CODE for some reason? Or perhaps your carrier board already does this? Assuming you are just using the UARTs as UARTS, and not doing something with boot, I would think making it all tri-state would be the way to go.
I guess a relevant question is whether you want to alter RAM_CODE for some reason? Or perhaps your carrier board already does this? Assuming you are just using the UARTs as UARTS, and not doing something with boot, I would think making it all tri-state would be the way to go.
No, I do nothing about RAM CODE or bootstrapping on custom carrier.
Shall i make the UART1 TX pull down or tri-stated? The problem is i cannot arrange the boot-up timing of 2 embedded boards (Jetson TX1 and the other one connected to Jetson’s UART0 and UART1).
Make the TX and RX of UART0 tri-state. Make the TX of UART1 tri-state (there’s no reason you couldn’t also tri-state the RX of UART1). Keep floating state until past bootstrapping. You could use a simple RC delay timer or perhaps set up a GPIO pin after kernel boot to enable.
Well, the thing is, as we connect them via TTL after of course a level shifter from TX1 (1.8 to 3.3), with the fast boot of another embedded device which is connected to the Jetson TX1’s uart0 and uart1, the Jetson bootstrap code of first stage bootloader can fail to decide the boot device (looking at the uart1 tx pin).
What i don’t understand is, this is strange to use uart pins for bootstrapping.
I made some pull-down trials to uart1 tx and found out that it needs a pull-down resistor at the bootsrap stage.
I now successfully boot the Jetson TX1 with uart 1 tx pull-downed at the power-up and toggled that pin also to necessary states for uart’s normal operation.
I didn’t touch up any other pins (RX or other uart’s pins) as the bootstrap is dependent on the uart1 tx which i find very strange.