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