qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Bug 1630723] [NEW] UART writes to netduino2/stm32f205-


From: Seth K
Subject: Re: [Qemu-devel] [Bug 1630723] [NEW] UART writes to netduino2/stm32f205-soc disappear
Date: Fri, 7 Oct 2016 16:04:31 -0400

I applied that patch, made qemu and ran my code, I didn't see a change.

According to the STM32F20xxx memory map, the memory range seems to be 0x400
-- UART 1 is listed as 0x40010000 - 0x400103FF. Should that memory region
be set to 0x400?

I tried that too, no change yet, but maybe I should look at the other
memory settings.

I also tried making these changes in another branch where I made this chip
have 8 UARTS. That was unchanged: I can only output UARTS 1,4,5,6.

On Fri, Oct 7, 2016 at 12:10 PM, Alistair Francis <address@hidden>
wrote:

> On Fri, Oct 7, 2016 at 9:03 AM, Alistair Francis <address@hidden>
> wrote:
> > On Fri, Oct 7, 2016 at 8:59 AM, Seth K <address@hidden> wrote:
> >> The only machine I saw listed in the help output is "netduino2." I
> pulled
> >> QEMU from github, was that the right thing to do?
> >>
> >> I found the specifications for the stm32f2xx and some similar chips and
> >> verified the addresses and interrupts are correct.
> >
> > Sorry my mistake. It is a the Netduino 2 Plus that we don't support.
> >
> > I think we should move this conversation to the bug report as well, I
> > was hoping that replying to the email would update the bug report but
> > it doesn't look like it.
> >
> >>
> >> The stm32f205 should support 6 UARTs, and the 6 addresses and IRQs are
> coded
> >> correctly. However there is a hard-coded value MAX_SERIAL_PORTS limiting
> >> serial_hds to 4, and I don't know why. I am considering submitting a
> patch.
> >
> > I'm not sure why we have that limit, you can submit a patch and see
> > what everyone says.
> >
> >>
> >> If I increase MAX_SERIAL_PORTS I can write to UARTs 1, 4, 5, and 6 and
> >> output them to sockets. However writes to UARTs 2 and 3 just disappear.
> They
> >> don't even trigger my printf in stm32f2xx_usart_write. It seems like
> they
> >> are being intercepted somewhere, and unfortunately my knowledge of QEMU
> is
> >> too low to know where to look. Any pointers would be greatly
> appreciated.
> >
> > Strange. There could be something else addressed there. If you run
> > 'info mtree' at the QEMU prompt (Ctrl-a + c) you should be able to see
> > the memory map of the system.
>
> Hey Seth,
>
> What if you try this diff? Does that help?
>
> diff --git a/hw/char/stm32f2xx_usart.c b/hw/char/stm32f2xx_usart.c
> index 4c6640d..b07c67b 100644
> --- a/hw/char/stm32f2xx_usart.c
> +++ b/hw/char/stm32f2xx_usart.c
> @@ -204,7 +204,7 @@ static void stm32f2xx_usart_init(Object *obj)
>      sysbus_init_irq(SYS_BUS_DEVICE(obj), &s->irq);
>
>      memory_region_init_io(&s->mmio, obj, &stm32f2xx_usart_ops, s,
> -                          TYPE_STM32F2XX_USART, 0x2000);
> +                          TYPE_STM32F2XX_USART, 0x200);
>      sysbus_init_mmio(SYS_BUS_DEVICE(obj), &s->mmio);
>  }
>
> Thanks,
>
> Alistair
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]