[Bug,1630723,NEW] UART writes to netduino2/stm32f205-soc disappear

On Fri, Oct 7, 2016 at 9:03 AM, Alistair Francis <alistair23@gmail.com> wrote:
> On Fri, Oct 7, 2016 at 8:59 AM, Seth K <skintigh@gmail.com> 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?

Thanks,

Alistair

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 <alistair23@gmail.com>
wrote:

> On Fri, Oct 7, 2016 at 9:03 AM, Alistair Francis <alistair23@gmail.com>
> wrote:
> > On Fri, Oct 7, 2016 at 8:59 AM, Seth K <skintigh@gmail.com> 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
>

On Fri, Oct 7, 2016 at 1:04 PM, Seth K <skintigh@gmail.com> 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 <alistair23@gmail.com>
> wrote:
>>
>> On Fri, Oct 7, 2016 at 9:03 AM, Alistair Francis <alistair23@gmail.com>
>> wrote:
>> > On Fri, Oct 7, 2016 at 8:59 AM, Seth K <skintigh@gmail.com> 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
>
>

It's a bare metal program so I don't really have anywhere to print to,
other than my custom function to output to the uart. I did double check all
the address to make sure they agreed with the documentation and the Qemu
source code. I tried changing around the destinations of the output just to
verify the order of the write or the destination somehow affected the
output. I tried being tricky, like instead of writing to usart 3 I wrote to
uart 4 - 0x400 (the same address, it didn't work). The code should be
simple enough that I don't have room for any crazy mistakes:

volatile unsigned char * const USART1_PTR = (unsigned char *)0x40011000;
volatile unsigned char * const USART2_PTR = (unsigned char *)0x40004400;
volatile unsigned char * const USART3_PTR = (unsigned char *)0x40004800;
volatile unsigned char * const UART4_PTR = (unsigned char *)0x40004c00;

void display(const char *string, volatile unsigned char * uart_addr){
  while(*string != '\0'){
    *(uart_addr+4) = *string;
    string++;
  }
}

int my_init(){
  display("Test 1/4\n", USART1_PTR);
  display("Test 2/4\n", USART2_PTR);
  display("Test 3/4\n", USART3_PTR);
  display("Test 4/4\n", UART4_PTR);
}


In the past I ran a really long test where I wrote to every possible
address just to see what happens. No unexpected output occurred. I can do
that test again, but it takes hours. I could also write code to convert the
address to something printable to verify the address isn't being changed,
but that seems unlikely.

Another thought I had is maybe there is some sort of interaction between
where I am setting the stack top - 0x20001000 - but that doesn't seem like
it should interfere. Maybe the linker or objcopy are doing something crazy?

I don't understand Qemu enough to know what should be calling the functions
that handle UART read/write. Is there something I should look at in Qemu
and try to intercept?

On Fri, Oct 7, 2016 at 6:27 PM, Alistair Francis <alistair23@gmail.com>
wrote:

> On Fri, Oct 7, 2016 at 1:04 PM, Seth K <skintigh@gmail.com> 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 <alistair23@gmail.com>
> > wrote:
> >>
> >> On Fri, Oct 7, 2016 at 9:03 AM, Alistair Francis <alistair23@gmail.com>
> >> wrote:
> >> > On Fri, Oct 7, 2016 at 8:59 AM, Seth K <skintigh@gmail.com> 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
> >
> >
>

I've narrowed this down. In exec.c the address is reduced by
section->offset_within_address_space. However, half the time that seems to
be wrong.

For usart1 at 40011004 it is 40011000, a difference of 4 which signals a
usart write.

For usart2 at 40004404 it is 40000c00, a difference of 3804 which means
nothing.

On Wed, Oct 12, 2016 at 6:25 PM, Seth K <skintigh@gmail.com> wrote:

> It's a bare metal program so I don't really have anywhere to print to,
> other than my custom function to output to the uart. I did double check all
> the address to make sure they agreed with the documentation and the Qemu
> source code. I tried changing around the destinations of the output just to
> verify the order of the write or the destination somehow affected the
> output. I tried being tricky, like instead of writing to usart 3 I wrote to
> uart 4 - 0x400 (the same address, it didn't work). The code should be
> simple enough that I don't have room for any crazy mistakes:
>
> volatile unsigned char * const USART1_PTR = (unsigned char *)0x40011000;
> volatile unsigned char * const USART2_PTR = (unsigned char *)0x40004400;
> volatile unsigned char * const USART3_PTR = (unsigned char *)0x40004800;
> volatile unsigned char * const UART4_PTR = (unsigned char *)0x40004c00;
>
> void display(const char *string, volatile unsigned char * uart_addr){
>   while(*string != '\0'){
>     *(uart_addr+4) = *string;
>     string++;
>   }
> }
>
> int my_init(){
>   display("Test 1/4\n", USART1_PTR);
>   display("Test 2/4\n", USART2_PTR);
>   display("Test 3/4\n", USART3_PTR);
>   display("Test 4/4\n", UART4_PTR);
> }
>
>
> In the past I ran a really long test where I wrote to every possible
> address just to see what happens. No unexpected output occurred. I can do
> that test again, but it takes hours. I could also write code to convert the
> address to something printable to verify the address isn't being changed,
> but that seems unlikely.
>
> Another thought I had is maybe there is some sort of interaction between
> where I am setting the stack top - 0x20001000 - but that doesn't seem like
> it should interfere. Maybe the linker or objcopy are doing something crazy?
>
> I don't understand Qemu enough to know what should be calling the
> functions that handle UART read/write. Is there something I should look at
> in Qemu and try to intercept?
>
> On Fri, Oct 7, 2016 at 6:27 PM, Alistair Francis <alistair23@gmail.com>
> wrote:
>
>> On Fri, Oct 7, 2016 at 1:04 PM, Seth K <skintigh@gmail.com> 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 <alistair23@gmail.com
>> >
>> > wrote:
>> >>
>> >> On Fri, Oct 7, 2016 at 9:03 AM, Alistair Francis <alistair23@gmail.com
>> >
>> >> wrote:
>> >> > On Fri, Oct 7, 2016 at 8:59 AM, Seth K <skintigh@gmail.com> 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
>> >
>> >
>>
>
>