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