path: root/results/classifier/zero-shot/118/all/1630723

peripherals: 0.979
arm: 0.978
permissions: 0.978
PID: 0.967
semantic: 0.956
risc-v: 0.956
user-level: 0.955
device: 0.953
files: 0.950
graphic: 0.949
architecture: 0.946
register: 0.946
TCG: 0.943
socket: 0.940
performance: 0.939
kernel: 0.928
boot: 0.928
assembly: 0.926
network: 0.924
vnc: 0.914
hypervisor: 0.913
virtual: 0.910
VMM: 0.907
KVM: 0.903
debug: 0.901
ppc: 0.862
x86: 0.836
i386: 0.735
mistranslation: 0.637

UART writes to netduino2/stm32f205-soc disappear

Writes to UART 2 and 3 disappear. As a sanity check I put printf statements in the function stm32f2xx_usart_write in qemu/hw/char/stm32f2xx_usart.c and recompiled qemu. The result confirmed text sent to UART1 and UART4 are sent to that function while text sent to UART 2 and 3 are not. I assume writes to all 4 need to make it to that function for emulations to operate correctly.

Example code that writes to all 4 UARTs/USARTs (does not contain the printf statements mention above):
https://github.com/skintigh/baremetal_netduino2

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.

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.

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.

Thanks again for all your help

On Thu, Oct 6, 2016 at 8:18 PM, Alistair Francis <email address hidden>
wrote:

> QEMU only supports the Netduino (not Netduino 2) it is possible that
> the base addresses are different and that is why you aren't seeing the
> serial output.
>
> Thanks,
>
> Alistair
>
>
> On Wed, Oct 5, 2016 at 11:56 AM, Seth <email address hidden> wrote:
> > Public bug reported:
> >
> > Writes to UART 2 and 3 disappear. As a sanity check I put printf
> > statements in the function stm32f2xx_usart_write in
> > qemu/hw/char/stm32f2xx_usart.c and recompiled qemu. The result confirmed
> > text sent to UART1 and UART4 are sent to that function while text sent
> > to UART 2 and 3 are not. I assume writes to all 4 need to make it to
> > that function for emulations to operate correctly.
> >
> > Example code that writes to all 4 UARTs/USARTs (does not contain the
> printf statements mention above):
> > https://github.com/skintigh/baremetal_netduino2
> >
> > ** Affects: qemu
> >      Importance: Undecided
> >          Status: New
> >
> > --
> > You received this bug notification because you are a member of qemu-
> > devel-ml, which is subscribed to QEMU.
> > https://bugs.launchpad.net/bugs/1630723
> >
> > Title:
> >   UART writes to netduino2/stm32f205-soc disappear
> >
> > Status in QEMU:
> >   New
> >
> > Bug description:
> >   Writes to UART 2 and 3 disappear. As a sanity check I put printf
> >   statements in the function stm32f2xx_usart_write in
> >   qemu/hw/char/stm32f2xx_usart.c and recompiled qemu. The result
> >   confirmed text sent to UART1 and UART4 are sent to that function while
> >   text sent to UART 2 and 3 are not. I assume writes to all 4 need to
> >   make it to that function for emulations to operate correctly.
> >
> >   Example code that writes to all 4 UARTs/USARTs (does not contain the
> printf statements mention above):
> >   https://github.com/skintigh/baremetal_netduino2
> >
> > To manage notifications about this bug go to:
> > https://bugs.launchpad.net/qemu/+bug/1630723/+subscriptions
> >
>


On 7 October 2016 at 17:03, Alistair Francis <email address hidden> wrote:
> On Fri, Oct 7, 2016 at 8:59 AM, Seth K <email address hidden> wrote:
>> 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.

Almost certainly purely historical reasons. MAX_SERIAL_PORTS has
been 4 since it was introduced in commit 8d11df9e5aa584 in 2004,
because the x86 PC has 4 serial ports. Presumably nobody since
has found the limit annoying enough to adjust.

thanks
-- PMM


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 <email address hidden>
wrote:

> On Fri, Oct 7, 2016 at 9:03 AM, Alistair Francis <email address hidden>
> wrote:
> > On Fri, Oct 7, 2016 at 8:59 AM, Seth K <email 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
>


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 <email address hidden>
wrote:

> On Fri, Oct 7, 2016 at 1:04 PM, Seth K <email 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 <email address hidden>
> > wrote:
> >>
> >> On Fri, Oct 7, 2016 at 9:03 AM, Alistair Francis <email address hidden>
> >> wrote:
> >> > On Fri, Oct 7, 2016 at 8:59 AM, Seth K <email 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
> >
> >
>


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 <email address hidden> 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 <email address hidden>
> wrote:
>
>> On Fri, Oct 7, 2016 at 1:04 PM, Seth K <email 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 <<email address hidden>
>> >
>> > wrote:
>> >>
>> >> On Fri, Oct 7, 2016 at 9:03 AM, Alistair Francis <<email address hidden>
>> >
>> >> wrote:
>> >> > On Fri, Oct 7, 2016 at 8:59 AM, Seth K <email 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
>> >
>> >
>>
>
>


The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting all older bugs to
"Incomplete" now.
If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Thank you and sorry for the inconvenience.


Example program tested successfully on commit 3493c36f037.

Eventually fixed by fc38a1120c2 ("Remove checks on MAX_SERIAL_PORTS that are just bounds checks").