Hi,
ne 16. 8. 2020 v 13:43 odesÃlatel Norbert Braun <norb...@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:
>
> 1. 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.
> 2. 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.
>
> 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.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
