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

[Alistair Francis]

On Fri, Oct 7, 2016 at 1:04 PM, Seth K <address@hidden> wrote:
> 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 was hoping that would have fixed it.

It sounds like it should be 0x400 then, although it doesn't sound like
this is causing this issue.

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

Maybe, it is very strange that it's not reaching the read/write functions.

Can you try putting print statements in the guest software to make
sure it is writing to the locations you expect and then make sure
there are no conditionals in QEMU that cause the print statements to
not be printed. See what that uncovers.

Thanks,

Alistair

>
> 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
>
>