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 <skint...@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 <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
>> >
>> >
>>
>
>
