Patchwork cadence_uart: enable tx/rx on reset

login
register
mail settings
Submitter Josh Cartwright
Date Oct. 22, 2012, 2:20 p.m.
Message ID <20121022142040.GA15461@beefymiracle.amer.corp.natinst.com>
Download mbox | patch
Permalink /patch/193162/
State New
Headers show

Comments

Josh Cartwright - Oct. 22, 2012, 2:20 p.m.
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 <josh.cartwright@ni.com>
---

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 :).

 hw/cadence_uart.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Peter Crosthwaite - Oct. 23, 2012, 3:30 a.m.
On Tue, Oct 23, 2012 at 12:20 AM, Josh Cartwright
<josh.cartwright@ni.com> 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 <josh.cartwright@ni.com>
> ---
>
> 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

Patch

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;