Hi,
from our previous experience of using Zynqs, we assumed the presence of 2 uarts. In the past we have enabled the second uart by editing the device tree and adding a second uart entry virtually identical to the existing uart entry, but using address e0001000 instead of e0000000.
However, adding this definition on our Trenz builds causes the boot to fail.
Can you explain how the second uart should be enabled?
Thanks, Tim
Hi Tim,
With controller base address you should also change interrupt definition.
You can found correct definition for UART in dts files for other zynq boards.
Best regards
Oleksandr Kiyenko
Yes, we are aware we also need to change the interrupt address, and we have used settings that work on other Zynq boards, but I was hoping that Trenz might be able to provide details of something that definitively works on Trenz boards
Hi,
DTS for 2 UARTs should be something like that
ps7_uart_0@e0000000 {
compatible = "xlnx,ps7-uart-1.00.a";
reg = <0xe0000000 0x1000>;
interrupts = <0 27 4>;
interrupt-parent = <&gic>;
clock = <50000000>;
};
ps7_uart_1: serial@e0001000 {
compatible = "xlnx,ps7-uart-1.00.a";
reg = < 0xe0001000 0x1000 >;
interrupts = < 0 50 4 >;
interrupt-parent = <&gic>;
clock = <50000000>;
} ;
Best regards
Oleksandr Kiyenko
The uart definitions I am using are equivalent to those, so I don't think that is where the problem lies for us. When I use the additional uart definition, the boot hangs just after the `Starting kernel..' message.
uart@e0001000 {
compatible = "xlnx,ps7-uart-1.00.a";
reg = <0xe0001000 0x1000>;
interrupts = < 0x0 0x32 0x4 >;
interrupt-parent = <0x1>;
clock = <0x2faf080>;
};
uart@e0000000 {
compatible = "xlnx,ps7-uart-1.00.a";
reg = <0xe0000000 0x1000>;
interrupts = <0x0 0x1b 0x4>;
interrupt-parent = <0x1>;
clock = <0x2faf080>;
};
It seems like the order of the uart definition is important, I have managed to bring the second uart up by defining e0000000 first and e00010000 second..
thanks for your help,
Tim