Petalinux Image from Imorted HDF boots only if both UART devices are activated

[Rolf Kary-Ehlers]

Hello,

we have succesfully imported a hdf-file from vivado2014.2 into a new "zynq" Petalinux-Project.
We created a Linux image (image.ub) and a (BOOT.bin) including the zynq_fsbl.elf, u-boot.elf and our bitfile (top.bit).
The first tries did not boot the linux kernel: see link for more information:
http://forum.trenz-electronic.de/index.php/topic,355.msg1269.html#msg1269

Then we have activated the second UART device in the vivado design and imported the new hdf file into a new Petalinux Project.
This time the linux booted correctly and worked properly.
Wy is it necessary to implement both UART device even though only the first is needed and the second does not have any external connection (dummy device).
The FSBL and u-boot work fine without a second UART, the Linux Kernel seems to need both devices.

The Petalinux import should not activate a device that is not implemented.

- Wy is it necessary to activate the second UART in the vivado design? If there is a reason for it and we knew about this, it would be helpful.
- Do I have to remove the second UART in Petalinux?
- Where can I deactivate the second UART?


kind regards
Rolf Kary-Ehlers

[Oleksandr Kiyenko]

Hello,

Don't sure that this problem is specially related to petalinux. I face the same problem on 3.12 linux kernel build from scratch. I think that it related to clock system init for linux (UART1 was initialy confirured as primary UART in system, and maybe it still hardcoded somewhere).
You have to enable it to generate correct FSBL and device tree. In petalinux you don't need to deactivate it, just check that UART0 is configured in u-boot and linux kernel parameters.

Best regards
Oleksandr Kiyenko

[Rolf Kary-Ehlers]

Hello Oleksandr,

thanks for your reply.
I found the reason for the access to the second UART in the Petalinux configuration files.
By default the second UART device is activated as low level kernel debug device. That is the reason why we did not get any messages from the kernel, the system simply hung accessing this device.

Fortunately it is configurable:
> petalinux-config -c kernel
deactivate --> Kernel Hacking --> Kernel low-level debugging functions
Maybe it can also be changed to annother configuration using UART0 or other ports, if you want kernel low level debugging. I did not try that.

best regards
Rolf Kary-Ehlers

[Antti Lukats]

this can very well be so, UART1 is a little better suited for debug than UART0, however it for linux it should be irrelevant.

UART1 registers can be accessed from the BOOTROM register init table, UART0 can not. But this also can make difference in FSBL early debug, not any more when secondary bootloader is working or linux.

[Rolf Kary-Ehlers]

Hi Antti,

this is a good hint for debugging. The bootloaders FSBL and u-boot both printed all necessary debug messages to the UART0. Linux hung with UART1. I am not shure what happens if I activate UART0 for low level debugging. Low level debugging might be helpful for the driver we want to develop.

Is it better to use UART1 for debug output or is does this make no difference for linux?

Kind regards,
Rolf Kary-Ehlers

[Antti Lukats]

as of ZYNQ hardware and bootrom code it SHOULD NOT make a difference for linux.
So it only depends on the linux kernel code only (not zynq hardware/bootrom), and here I do not know the answer.