Message ID | 20121022142040.GA15461@beefymiracle.amer.corp.natinst.com |
---|---|
State | New |
Headers | show |
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
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;
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(-)