From patchwork Tue Oct 25 22:34:45 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alistair Francis X-Patchwork-Id: 686792 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3t3Sfv3Sbtz9s3s for ; Wed, 26 Oct 2016 09:36:07 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b=hmmjqMa3; dkim-atps=neutral Received: from localhost ([::1]:58555 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bzAKC-0007ah-Pi for incoming@patchwork.ozlabs.org; Tue, 25 Oct 2016 18:36:04 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36051) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bzAJS-0007Il-2o for qemu-devel@nongnu.org; Tue, 25 Oct 2016 18:35:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bzAJQ-0008VC-Qb for qemu-devel@nongnu.org; Tue, 25 Oct 2016 18:35:18 -0400 Received: from mail-oi0-x233.google.com ([2607:f8b0:4003:c06::233]:33379) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1bzAJQ-0008V2-K8 for qemu-devel@nongnu.org; Tue, 25 Oct 2016 18:35:16 -0400 Received: by mail-oi0-x233.google.com with SMTP id y2so123813003oie.0 for ; Tue, 25 Oct 2016 15:35:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dQ8zanbJSpJP3qcBybF4U9rVNmHUo4vay6nqZyiyFQc=; b=hmmjqMa3TsCPi6byqnhccDVivOOhIlzdasTeWSO8b/aOVZOPdsjMu+FFCZNZgVt9XV iQf4MFpNNRPqQYhdj5zqBw+vNCe/PmANsHd0rghjbdu+f0bnX+AsMRgUxmq99d3P66br UG7QtXr7dUINUJ3MJtX9LUwmdwRzK9w6IJCDO5lRAzYyQh//0am1Tfs6yx+TeBE1RHWX fRO+V/SrsLjaoO5701owpKFA7+so6/OCWghj3P9WNkJ5RPnj5wiA45BckIHECMjaGRMV 3qUoOmjEq0F//+SQF+4AxFU+r/cm57aK2CJskYWpX8c06swX0eUQk+NpcsBqpJkKbMPU WPag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dQ8zanbJSpJP3qcBybF4U9rVNmHUo4vay6nqZyiyFQc=; b=Ot+5qinhEQm3f3326mcmRxH8HJnOcipTCA0cbdRCyEvaXGwStwW6TcIhtH758MpM+j ZLxEU4Kb82zPairYd4MlIIb9SaFlaZJkGVqH0HnxC3HERxgYPEQK2/IxDq7WusN6WAqk EUQ7J0mRP8YqI4lmzvfguQTsSq/z9D72fp2G0Fd/6q/+JgRYVhEziXAZpqF50BWXo/De JBz3edZIuyrbQijwklkmMkxnYCYD050KqTQKsO+fRhwcTUzMPU+1aDQOudZK50m+kiXc Y3H0/xDDBCztP2WCR9zIGKg+Doe1sWlDch7d9DJHny5EAtT0aQE4Ns/N5m9v1PVDC11z XJYA== X-Gm-Message-State: AA6/9Rm08Ig1/jkRABquTSJQljOo4pnsQyO/Ghe2uGtcXlA6K689Za/Jw8ISyokGm9PjQdZ3t6tMFNe/OTRl1A== X-Received: by 10.202.235.10 with SMTP id j10mr27534223oih.103.1477434915626; Tue, 25 Oct 2016 15:35:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.122.34 with HTTP; Tue, 25 Oct 2016 15:34:45 -0700 (PDT) In-Reply-To: References: <20161005185604.6432.79423.malonedeb@chaenomeles.canonical.com> From: Alistair Francis Date: Tue, 25 Oct 2016 15:34:45 -0700 Message-ID: To: Seth K X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:4003:c06::233 Subject: Re: [Qemu-devel] [Bug 1630723] [NEW] UART writes to netduino2/stm32f205-soc disappear X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Bug 1630723 <1630723@bugs.launchpad.net>, "qemu-devel@nongnu.org Developers" Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" On Thu, Oct 20, 2016 at 3:55 PM, Seth K 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 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 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 >> wrote: >>> >>> On Fri, Oct 7, 2016 at 1:04 PM, Seth K 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 >>> > >>> > wrote: >>> >> >>> >> On Fri, Oct 7, 2016 at 9:03 AM, Alistair Francis >>> >> >>> >> wrote: >>> >> > On Fri, Oct 7, 2016 at 8:59 AM, Seth K 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 >>> > >>> > >> >> > 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 { \