10-30-2018 01:44 AM
I'm using ZC702 platform with petalinux 2018.1, when UART (USB to uart) not connected the booting halts/stuck at u-boot prompt. After connecting UART it is verified the booting stuck at u-boot prompt. After issuing 'boot' command it successfully boots linux. When UART is connected there is no issue in loading linux, the entire boot succeeds.
Any pointers to fix this issue, moreover petalinux 2018.1 doesn't clone u-boot.
10-30-2018 11:44 PM
I am confused with your use case.
May I know are you getting any error message in u-boot console? can you share the all u-boot environment varilables?
10-31-2018 01:04 AM - edited 10-31-2018 01:04 AM
There is no error. In my customised board we have separate RS 232 converter added and separately powered, which in turn connects to serial to USB converter to the host PC. When power to RS 232 converter is switch off, there will not be any logs on the console, but the expectation is Linux should be booted but the booting stopped at u-boot prompt when UART is powered and verified on the console. Unable to understand what is causing this issue. Again if I issue 'boot 'command from u-boot it successfully loads Linux. PFA environment variables.
10-31-2018 09:23 PM
So it is the way UART is connected with separate power setup and excepting it is causing the Issue.
In general, u-boot starts decomress its image starting from borad_init_f (which initiates serial initial, baud rate initial, console initial) & board_init_r (takes care of again serial console with intilized variabes from board_init_f , baud rate set for your board, uart address set for your board, here it will check how many uart ports are connected and their proper address and will identify your actual UART console from include/configs/board_zed.h)
If that uart address matches to your physical connected port (u-boot code is Flat memory) then it starts print messaegs on UART console.
This is flow in u-boot code for UART transimission so now identify the your issue.
Thanks & Regards
11-02-2018 12:13 AM
I am not sure on your suggestion. You want me to modify the u-boot code. I do not see u-boot is cloned when petalinux is build.
Do you have procedure how to build the u-boot external image with petalinux?
11-02-2018 12:28 AM
I have provided code flow for U-boot and Intilization part of Uart and can believe it is enabled when it is going to customer build because Xilinx QA team throughly test the Serial console and other I/O Devices
So there is nothing to change U-Boot Code.
I have provided basic code flow for Understanding and more over in U-boot level UART is basic I/O to make it up
Basically there are two UART ports, one is serail console and other one is Debug Console ,In production build Serial consloe will definitely up.
I hope I have cleraed your Issue with UART Initilization part
Thanks & Regards
08-04-2020 05:42 AM
It is a bit old entry, but as it is still open, I wanted to answer.
I have the same issue with the zynqMP, petalinux 2018.2 on a custom board. It seems that, if the UART transceiver (FTDI chip) is not powered (in my case it is power over USB cable), the auto-boot sequence halts, as if a key is pressed. If the FTDI chip is powered, the boot sequence is successful.
I could not find the root cause of it or how to solve it, but got a workaround by stopping the auto boot sequence only by a string, not any key, as the possibility of the FTDI chip generating the exact string is virtually zero.
petalinux-config -c u-boot
→ Command line interface → Autoboot options → [enable] Stop autobooting via specific input key / string
Enter a string in the (for example "stop")
Stop autobooting via specific input key / string options
The boot sequence now stops only when user types "stop" and goes into the u-boot console.
I hope it helps.
08-04-2020 08:10 AM - edited 08-04-2020 08:12 AM
We had a similar issue.
Normally, when you boot, uboot wait a couple of seconds to see if the user enters something to get into the console. When our USB cable was plugged, everything worked fine. But if the usb cable was unplugged, the board would not boot. In fact, the board was fine, it's just that it was stuck in the uboot console.
That was the result of a bad design around the FTDI chip : We needed to put a diode in the power supply between the 5vusb of the chip and the 5v rail of our system.
Thats because when the usb cable is plugged, the chip gets its supply from the 5v usb. But when the cable was unplugged, the chip didnt have power and held the line low or glitchy perhabs, thus "sending caracters" on the UART, which uboot catched and hung to the console.
Adding a diode between the 5v and 5vusb of the chip resolved the issue. It prevents the 5vusb powering the board while off, and it allows the ftsi chip to be powered on when the cable is unplugged