On Thu, Oct 20, 2016 at 3:55 PM, Seth K <skint...@gmail.com> wrote:
> 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?
Try this diff to enable debug prints. That should print more
information about what is happening in QEMU
diff --git a/hw/char/stm32f2xx_usart.c b/hw/char/stm32f2xx_usart.c
index 4c6640d..4be093d 100644
--- a/hw/char/stm32f2xx_usart.c
+++ b/hw/char/stm32f2xx_usart.c
@@ -27,7 +27,7 @@
#include "qemu/log.h"
#ifndef STM_USART_ERR_DEBUG
-#define STM_USART_ERR_DEBUG 0
+#define STM_USART_ERR_DEBUG 1
#endif
#define DB_PRINT_L(lvl, fmt, args...) do { \
When the guest writes to a register it should call back to the
stm32f2xx_usart_write() function. Make sure that is happening and the
offsets are correct.
Thanks,
Alistair
>>
>> 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
>>> >
>>> >
>>
>>
>
