On Tue, Oct 23, 2012 at 12:20 AM, Josh Cartwright
<josh.cartwri...@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.cartwri...@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
