Re: [Qemu-devel] [PATCH] cadence_uart: enable tx/rx on reset

[Peter Crosthwaite]

On Tue, Oct 23, 2012 at 12:20 AM, Josh Cartwright
<address@hidden> wrote:
> Change the cadence_uart such that tx/rx is enabled on reset.  Assuming
> both are enabled makes debugging early Linux kernel bootup a little bit
> easier.
>
> Signed-off-by: Josh Cartwright <address@hidden>
> ---
>
> I've used this patch mostly for my own testing, but it may be of general
> use.  On a real system, I would expect the bootloader to leave the uart
> in an enabled state, but I'm not using a bootloader for my testing :).
>

The difficulty here is QEMU needs to support modelling firmware as
well - QEMU should be usable to test boot-loaders themselves. For this
to work, its preferable that the hardware come out of reset in the
actual hardware reset state rather that the boot hand-off state. If
you need to accurately model the Linux boot-loader process, you can
always pass your actual boot-loader image as the guest to QEMU then
boot Linux as you would the real hardware.

The reverse case is a bigger problem. If our hardware comes out of
reset in the Linux bootstrap state then QEMU cant be used to
accurately model boot-loaders or standalone firmware apps (or anything
non-Linux).

If we want to do this as part of the QEMU arm-Linux boot-loader, then
I think the boot-loader itself should explicitly enable the UART TX.
Currently there is no mechanism for implementing this so its a greater
issue that goes beyond Zynq.

Peter, is there any precedent for this out in the ARM machine models
that you know of?

Regards,
Peter

>  hw/cadence_uart.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/cadence_uart.c b/hw/cadence_uart.c
> index f8afc4e..2fb21a6 100644
> --- a/hw/cadence_uart.c
> +++ b/hw/cadence_uart.c
> @@ -421,7 +421,7 @@ static const MemoryRegionOps uart_ops = {
>
>  static void cadence_uart_reset(UartState *s)
>  {
> -    s->r[R_CR] = 0x00000128;
> +    s->r[R_CR] = UART_CR_RX_EN | UART_CR_TX_EN | UART_CR_STOPBRK;
>      s->r[R_IMR] = 0;
>      s->r[R_CISR] = 0;
>      s->r[R_RTRIG] = 0x00000020;
> --
> 1.7.12.4