|
From: | Philippe Mathieu-Daudé |
Subject: | Re: [Qemu-devel] [Qemu devel v7 PATCH 4/5] msf2: Add Smartfusion2 SoC |
Date: | Thu, 31 Aug 2017 20:40:32 -0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 |
Hi Alistair, On 08/31/2017 08:02 PM, Alistair Francis wrote:
On Wed, Aug 30, 2017 at 7:47 AM, Philippe Mathieu-Daudé <address@hidden> wrote:On 08/30/2017 09:26 AM, Peter Maydell wrote:On 30 August 2017 at 03:45, Philippe Mathieu-Daudé <address@hidden> wrote:I think they might be issues if you start QEMU without -serial and then use a firmware polling for an uart, the device won't be mapped and the memory accesses are mostly ignored. I'd rather use: for (i = 0; i < MSF2_NUM_UARTS && i < MAX_SERIAL_PORTS; i++) { static const char *serial[] = {"serial0", "serial1"}; if (!serial_hds[i]) { serial_hds[i] = qemu_chr_new(serial[i], "null"); }+ serial_mm_init(get_system_memory(), uart_addr[i], 2, + qdev_get_gpio_in(armv7m, uart_irq[i]), + 115200, serial_hds[i], DEVICE_NATIVE_ENDIAN); + } + }It would be better to fix serial_mm_init() to handle having a NULL chardev pointer, because we already have a lot of SoC code that just passes it serial_hds[] regardless.clever :)I'd leave this code as it is and we can fix serial_mm_init separately (somebody pointed out this issue for a xilinx board recently).Ah, I'll look into this then.
I already sent a series to take care of this: http://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg06325.html I'll respin a v2 shortly.
[Prev in Thread] | Current Thread | [Next in Thread] |