Hi,
On 17.08.20 12:07, Michal Simek wrote:
Hi,
ne 16. 8. 2020 v 13:43 odesílatel Norbert Braun norbert@xrpbot.org napsal:
Hi,
I am running into a problem with U-Boot v2020.07 on Xilinx Zynq (Zedboard). If I build U-Boot with the default config (xilinx_zynq_virt_defconfig, DEVICE_TREE=zynq-zed), autoboot will abort, even if no key is pressed. This happens regardless of whether the USB UART is even connected to a PC.
I am using boot.bin as generated by U-Boot as the SPL (plus u-boot.img for U-Boot proper).
While debugging this, I noticed two things:
- The Zynq TRM [1] notes in section 19.2.3 ("Baud generator"): IMPORTANT: It is essential to disable the transmitter and receiver before writing to the Baud Rate Generator register (uart.Baud_rate_gen_reg0), or the baud rate divider register (uart.Baud_rate_divider_reg0). A soft reset must be issued to both the transmitter and receiver before they are re-enabled.
However, the code in _uart_zynq_serial_setbrg() (in drivers/serial/serial_zynq.c) does not seem to do that.
I have reported this internally at Xilinx to fix this but none has looked at it yet. But definitely feel free to send a patch to fix it. I expect the similar issue is when you change baudrate via prompt.
Ok, I will send a patch (see next mail).
The patch does not seem to make much of a difference for changing the baud rate via prompt; it works for me with or without the patch. One thing I have noticed is that on_baudrate prints a string ("## Switch baudrate to [...]") and then waits for a fixed 50ms delay before changing the baud rate. If the original baud rate is low (e.g. 4800 bps), this causes the string to be truncated, but again, the patch makes no difference there.
- It seems that the Zynq BootROM actually touches the registers for
UART1. I have no idea why it does that, but table 6-22 ("BootROM Modified Registers") in the TRM lists several UART1 registers that have been modified from their reset value. In particular, the control register at 0xE0001000 contains the value 0x00000114 after the BootROM ran.
As zynq_serial_probe() checks if TX is enabled (bit 4 in the control register), and only writes to the control register if it is not, the end result is that U-Boot never really initializes UART1 or resets its TX or RX path.
I have added this code because when reinitialization was happening there were random chars emitted. Not sure which flow you use. But I didn't see any issue in SPL boot flow.
Basically, I do the following:
git checkout v2020.07 export CROSS_COMPILE=arm-linux-gnueabihf- export ARCH=arm export DEVICE_TREE=zynq-zed make xilinx_zynq_virt_defconfig make
cp u-boot.img [ to SD card ] cp spl/boot.bin [ to SD card ]
This is sufficient to demonstrate the problem on my Zedboard. (There are no other files on the SD card.)
One thing I should have mentioned (sorry!) is that I have a Rev. C Zedboard with an ES (engineering sample) Zynq SoC on it. Maybe there is some difference that is causing the problem, and production silicon is unaffected. Still, following the recommendation in the TRM when changing the baud rate probably cannot hurt.
If the debug UART functionality (CONFIG_DEBUG_UART_ZYNQ) is enabled, _debug_uart_init() writes to the control register unconditionally and resets the TX/RX path. Indeed, enabling the debug UART functionality makes my problem disappear. The debug UART was enabled by default in zynq_zed_defconfig (in v2019.10), but this changed when switching to a single Zynq configuration (xilinx_zynq_virt_defconfig) for v2020.07.
Note that the above workaround fixes the problem for me, but I wanted to report it in case other people run into the same issue.
Bootrom shouldn't touch these regs. It is code in ps7_init which does it. It means take a look at it. It should do full uart initialization.
I looked at board/xilinx/zynq/zynq-zed/ps7_init_gpl.c, but it does not seem to touch the UART registers. It does set up pinmuxing and enables the UART peripheral clock, but it does not access any register in the 0XE0001xxx range.
Thanks, Michal
Thanks,
Norbert