From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.3 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 66868C43603 for ; Tue, 10 Dec 2019 19:16:40 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1ECAE20637 for ; Tue, 10 Dec 2019 19:16:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="THJR6EYu" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1ECAE20637 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:34988 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iekzv-0005fV-BV for qemu-devel@archiver.kernel.org; Tue, 10 Dec 2019 14:16:39 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51468) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iekyL-0004VN-45 for qemu-devel@nongnu.org; Tue, 10 Dec 2019 14:15:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iekyI-0007uj-PB for qemu-devel@nongnu.org; Tue, 10 Dec 2019 14:15:00 -0500 Received: from mail-il1-x143.google.com ([2607:f8b0:4864:20::143]:40512) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iekyI-0007uE-I6; Tue, 10 Dec 2019 14:14:58 -0500 Received: by mail-il1-x143.google.com with SMTP id b15so17132461ila.7; Tue, 10 Dec 2019 11:14:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=alOcQcgvp6XCV+enV3qG3D/mHnMQSHhndppzu+ZmGrM=; b=THJR6EYuFy2c4ffOJwBwV2tVu7xDWwN+anvQQK9k3M2/FJEUncl50RXrUcdIdNqPez +HU/QO0vem93nw8qdJaPXnhU/VweuNwD+uk5WLq+r9IKBzxN2zBjPR6lSRhSSrqhGSmj LhBLPOIhkMhc9VX5Hdx078QKKYdAAhQfRKrLhDpyYCXDXdH7Jce7ECcmf0T/Junj7IfP mmOCXfjn+lYE4q8nKrnldPGoCOBW1mCkZPvnIkK/mnfaM1HZYrgIfIADCauHxo7iNPAT Chr5P3U9io3+7t1ZeCsEybz4mXcKB3vsR4Tk3fbAV7YKP7YLBT/+ZJ9cUMfxxKziU3k/ fmDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=alOcQcgvp6XCV+enV3qG3D/mHnMQSHhndppzu+ZmGrM=; b=d8Jmfp6cODObyXtY9K1KQ/TuO9W62pI6mOEzGOe8Hfwr6/IoIZebTW3kWWod9OKG8y FdVnxVrSya3co0vYy2wOkmnC2JQA9rLSeUI/7j6OdQVZ3QvjSPpIaqN0JQvJ3imvzXe0 L5uYqRSqxgSZ6P/lII1Sha6m8tC06bqUYf8hB1LrvCyorHQK1pbKZmkYU4T82p0Yo8UE AC1OxNmVU1VTYvDwvQOvtvVX26RWQhhlbzT5n8h+SsEi/tvRTbB1MHnxcCNOF+lXxCN/ +2uuQMWZeQskBAnltVFhBv9DSLhzt22MY6yB37daILe6nIC1B1yQu1yYO3lpbFdWD3UE /LcQ== X-Gm-Message-State: APjAAAUzovezeHwCXfhWSBoeEj4M9X5dWoUqEk/CgOpVBYc/4CnbKBI4 ULcp10vGEkvZGjMrI+PEaTeu6VhWFvigDBdrHh0= X-Google-Smtp-Source: APXvYqzzy5UFNF3Yf3fNPlPr19aedwr9sNHhvCo1u1K6NZSCjdCr3w/j8e7uLYy2nzHwmQMpJvqGNEWfL/egz8IeIyY= X-Received: by 2002:a92:5a45:: with SMTP id o66mr33950807ilb.67.1576005297574; Tue, 10 Dec 2019 11:14:57 -0800 (PST) MIME-Version: 1.0 References: <20191202210947.3603-1-nieklinnenbank@gmail.com> <20191202210947.3603-3-nieklinnenbank@gmail.com> In-Reply-To: From: Niek Linnenbank Date: Tue, 10 Dec 2019 20:14:46 +0100 Message-ID: Subject: Re: [PATCH 02/10] hw: arm: add Xunlong Orange Pi PC machine To: =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= Content-Type: multipart/alternative; boundary="000000000000ed1a5205995e531e" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::143 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Beniamino Galvani , Peter Maydell , qemu-arm , QEMU Developers Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --000000000000ed1a5205995e531e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Philippe, On Tue, Dec 10, 2019 at 9:59 AM Philippe Mathieu-Daud=C3=A9 wrote: > On 12/6/19 11:15 PM, Niek Linnenbank wrote: > [...] > > > > +static void orangepi_machine_init(MachineClass *mc) > > > > +{ > > > > + mc->desc =3D "Orange Pi PC"; > > > > + mc->init =3D orangepi_init; > > > > + mc->units_per_default_bus =3D 1; > > > > + mc->min_cpus =3D AW_H3_NUM_CPUS; > > > > + mc->max_cpus =3D AW_H3_NUM_CPUS; > > > > + mc->default_cpus =3D AW_H3_NUM_CPUS; > > > > > > mc->default_cpu_type =3D > ARM_CPU_TYPE_NAME("cortex-a7"); > > > > > > > + mc->ignore_memory_transaction_failures =3D true; > > > > > > You should not use this flag in new design. See the > > documentation in > > > include/hw/boards.h: > > > > > > * @ignore_memory_transaction_failures: > > > * [...] New board models > > > * should instead use "unimplemented-device" for all > memory > > > ranges where > > > * the guest will attempt to probe for a device that > > QEMU doesn't > > > * implement and a stub device is required. > > > > > > You already use the "unimplemented-device". > > > > > > Thanks, I'm working on this now. I think that at least I'll need > > to add > > > all of the devices mentioned in the 4.1 Memory Mapping chapter o= f > > the > > > datasheet > > > as an unimplemented device. Previously I only added some that I > > thought > > > were relevant. > > > > > > I added all the missing devices as unimplemented and removed the > > > ignore_memory_transaction_failures flag > > > > I was going to say, "instead of adding *all* the devices regions yo= u > > can > > add the likely bus decoding regions", probably: > > > > 0x01c0.0000 128KiB AMBA AXI > > 0x01c2.0000 64KiB AMBA APB > > > > But too late. > > > > > > Hehe its okey, I can change it to whichever is preferable: the minimum > set > > with unimplemented device entries to get a working linux kernel / u-boo= t > or > > just cover the full memory space from the datasheet. My initial thought > > was that if > > we only provide the minimum set, and the linux kernel later adds a new > > driver for a device > > which is not marked unimplemented, it will trigger the data abort and > > potentially resulting in a non-booting kernel. > > > > But I'm not sure what is normally done here. I do see other board files > > using the create_unimplemented_device() function, > > but I dont know if they are covering the whole memory space or not. > > If they don't cover all memory regions, the guest code can trigger a > data abort indeed. Since we don't know the memory layout of old board, > they are still supported with ignore_memory_transaction_failures=3Dtrue, > so guest still run unaffected. > We expect new boards to implement the minimum layout. > As long as your guest is happy and usable, UNIMP devices are fine, > either as big region or individual device (this requires someone with > access to the datasheet to verify). If you can add a UNIMP for each > device - which is what you did - it is even better because the the unimp > access log will be more useful, having finer granularity. > > > I added all the missing devices as unimplemented and removed the > > ignore_memory_transaction_failures flag > > IOW, you already did the best you could do :) > > > > from the machine. Now it seems Linux gets a data abort while > > probing the > > > uart1 serial device at 0x01c28400, > > > > Did you add the UART1 as UNIMP or 16550? > > > > > > I discovered what goes wrong here. See this kernel oops message: > > > > [ 1.084985] [f08600f8] *pgd=3D6f00a811, *pte=3D01c28653, *ppte=3D01c= 28453 > > [ 1.085564] Internal error: : 8 [#1] SMP ARM > > [ 1.085698] Modules linked in: > > [ 1.085940] CPU: 0 PID: 1 Comm: swapper/0 Not tainted > 5.4.0-11747-g2f13437b8917 #4 > > [ 1.085968] Hardware name: Allwinner sun8i Family > > [ 1.086447] PC is at dw8250_setup_port+0x10/0x10c > > [ 1.086478] LR is at dw8250_probe+0x500/0x56c > > > > It tries to access the UART0 at base address 0x01c28400, which I did > > provide. The strange > > thing is that is accesses offset 0xf8, thus address 0x01c284f8. The > > datasheet does not mention this register > > but if we provide the 1KiB (0x400) I/O space it should at least read as > > zero and writes ignored. Unfortunately the emulated > > serial driver only maps a small portion until 0x1f: > > > > (qemu) info mtree > > ... > > 0000000001c28000-0000000001c2801f (prio 0, i/o): serial > > 0000000001c28400-0000000001c2841f (prio 0, i/o): serial > > 0000000001c28800-0000000001c2881f (prio 0, i/o): serial > > > > > > Apparently, the register that the mainline linux kernel is using is > > DesignWare specific: > > > > drivers/tty/serial/8250/8250_dwlib.c:13: > > > > /* Offsets for the DesignWare specific registers */ > > #define DW_UART_DLF<--->0xc0 /* Divisor Latch Fraction Register */ > > #define DW_UART_CPR<--->0xf4 /* Component Parameter Register */ > > #define DW_UART_UCV<--->0xf8 /* UART Component Version */ > > > > I tried to find a way to increase the memory mapped size of the serial > > device I created with serial_mm_init(), > > but I don't think its possible with that interface. > > > > I did manage to get it working by overlaying the UART0 with another > > unimplemented device > > that does have an I/O size of 0x400, but I guess that is probably not > > the solution we are looking for? > > IMHO this is the correct solution :) > > Memory regions have priority. By default a device has priority 0, and > UNIMP device has priority -1000. > > So you can use: > > serial_mm_init(get_system_memory(), AW_H3_UART0_REG_BASE, 2, > s->irq[AW_H3_GIC_SPI_UART0], 115200, > serial_hd(0), DEVICE_NATIVE_ENDIAN); > create_unimplemented_device("DesignWare-uart",\ > AW_H3_UART0_REG_BASE, > 0x400); > > Now it makes much more sense to me, thanks a lot for explaining this! Allright, I'll use this approach to finish the work for removing mc->ignore_memory_transaction_failures. Regards, Niek > (Or cleaner, add a create_designware_uart(...) function that does both). > > (qemu) info mtree > ... > 0000000001c28000-0000000001c2801f (prio 0, i/o): serial > 0000000001c28000-0000000001c283ff (prio -1000, i/o): DesignWare-uart > > You could create an UNIMP region of 0x400 - 0x20 =3D 0x3e0, but that woul= d > appear this is a different device, so I don't recommend that. > > > I wonder, did any of the other SoC / boards have this problem when > > removing mc->ignore_memory_transaction_failures? > > --=20 Niek Linnenbank --000000000000ed1a5205995e531e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Philippe,

=
On Tue, Dec 10, 2019 at 9:59 AM Phili= ppe Mathieu-Daud=C3=A9 <philmd@redh= at.com> wrote:
On 12/6/19 11:15 PM, Niek Linnenbank wrote:
[...]
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > +static void orangep= i_machine_init(MachineClass *mc)
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > +{
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > +=C2=A0 =C2=A0 mc-&g= t;desc =3D "Orange Pi PC";
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > +=C2=A0 =C2=A0 mc-&g= t;init =3D orangepi_init;
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > +=C2=A0 =C2=A0 mc-&g= t;units_per_default_bus =3D 1;
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > +=C2=A0 =C2=A0 mc-&g= t;min_cpus =3D AW_H3_NUM_CPUS;
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > +=C2=A0 =C2=A0 mc-&g= t;max_cpus =3D AW_H3_NUM_CPUS;
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > +=C2=A0 =C2=A0 mc-&g= t;default_cpus =3D AW_H3_NUM_CPUS;
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 mc->default_cpu_type =3D ARM_CPU_TYPE_NAME("cortex-a7"); >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > +=C2=A0 =C2=A0 mc-&g= t;ignore_memory_transaction_failures =3D true;
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0You should not use this fl= ag in new design. See the
>=C2=A0 =C2=A0 =C2=A0documentation in
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0include/hw/boards.h:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 * @ignore_memory_t= ransaction_failures:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 =C2=A0 [..= .] New board models
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 =C2=A0 sho= uld instead use "unimplemented-device" for all memory
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0ranges where
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 =C2=A0 the= guest will attempt to probe for a device that
>=C2=A0 =C2=A0 =C2=A0QEMU doesn't
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 *=C2=A0 =C2=A0 imp= lement and a stub device is required.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0You already use the "= unimplemented-device".
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Thanks, I'm working on this now. I think = that at least I'll need
>=C2=A0 =C2=A0 =C2=A0to add
>=C2=A0 =C2=A0 =C2=A0 > all of the devices mentioned in the 4.1 Memor= y Mapping chapter of
>=C2=A0 =C2=A0 =C2=A0the
>=C2=A0 =C2=A0 =C2=A0 > datasheet
>=C2=A0 =C2=A0 =C2=A0 > as an unimplemented device. Previously I only= added some that I
>=C2=A0 =C2=A0 =C2=A0thought
>=C2=A0 =C2=A0 =C2=A0 > were relevant.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > I added all the missing devices as unimplemen= ted and removed the
>=C2=A0 =C2=A0 =C2=A0 > ignore_memory_transaction_failures flag
>
>=C2=A0 =C2=A0 =C2=A0I was going to say, "instead of adding *all* t= he devices regions you
>=C2=A0 =C2=A0 =C2=A0can
>=C2=A0 =C2=A0 =C2=A0add the likely bus decoding regions", probably= :
>
>=C2=A0 =C2=A0 =C2=A00x01c0.0000=C2=A0 =C2=A0128KiB=C2=A0 =C2=A0AMBA AXI=
>=C2=A0 =C2=A0 =C2=A00x01c2.0000=C2=A0 =C2=A064KiB=C2=A0 =C2=A0 AMBA APB=
>
>=C2=A0 =C2=A0 =C2=A0But too late.
>
>
> Hehe its okey, I can change it to whichever is preferable: the minimum= set
> with unimplemented device entries to get a working linux kernel / u-bo= ot or
> just cover the full memory space from the datasheet. My initial though= t
> was that if
> we only provide the minimum set, and the linux kernel later adds a new=
> driver for a device
> which is not marked unimplemented, it will trigger the data abort and =
> potentially resulting in a non-booting kernel.
>
> But I'm not sure what is normally done here. I do see other board = files
> using the create_unimplemented_device() function,
> but I dont know if they are covering the whole memory space or not.
If they don't cover all memory regions, the guest code can trigger a data abort indeed. Since we don't know the memory layout of old board, =
they are still supported with ignore_memory_transaction_failures=3Dtrue, so guest still run unaffected.
We expect new boards to implement the minimum layout.
As long as your guest is happy and usable, UNIMP devices are fine,
either as big region or individual device (this requires someone with
access to the datasheet to verify). If you can add a UNIMP for each
device - which is what you did - it is even better because the the unimp access log will be more useful, having finer granularity.

=C2=A0> I added all the missing devices as unimplemented and removed the=
=C2=A0> ignore_memory_transaction_failures flag

IOW, you already did the best you could do :)

>=C2=A0 =C2=A0 =C2=A0 > from the machine. Now it seems Linux gets a d= ata abort while
>=C2=A0 =C2=A0 =C2=A0probing the
>=C2=A0 =C2=A0 =C2=A0 > uart1 serial device at 0x01c28400,
>
>=C2=A0 =C2=A0 =C2=A0Did you add the UART1 as UNIMP or 16550?
>
>
> I discovered what goes wrong here. See this kernel oops message:
>
> [=C2=A0 =C2=A0 1.084985] [f08600f8] *pgd=3D6f00a811, *pte=3D01c28653, = *ppte=3D01c28453
> [=C2=A0 =C2=A0 1.085564] Internal error: : 8 [#1] SMP ARM
> [=C2=A0 =C2=A0 1.085698] Modules linked in:
> [=C2=A0 =C2=A0 1.085940] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.4= .0-11747-g2f13437b8917 #4
> [=C2=A0 =C2=A0 1.085968] Hardware name: Allwinner sun8i Family
> [=C2=A0 =C2=A0 1.086447] PC is at dw8250_setup_port+0x10/0x10c
> [=C2=A0 =C2=A0 1.086478] LR is at dw8250_probe+0x500/0x56c
>
> It tries to access the UART0 at base address 0x01c28400, which I did <= br> > provide. The strange
> thing is that is accesses offset 0xf8, thus address 0x01c284f8. The > datasheet does not mention this register
> but if we provide the 1KiB (0x400) I/O space it should at least read a= s
> zero and writes ignored. Unfortunately the emulated
> serial driver only maps a small portion until 0x1f:
>
> (qemu) info mtree
> ...
>=C2=A0 =C2=A0 =C2=A0 0000000001c28000-0000000001c2801f (prio 0, i/o): s= erial
>=C2=A0 =C2=A0 =C2=A0 0000000001c28400-0000000001c2841f (prio 0, i/o): s= erial
>=C2=A0 =C2=A0 =C2=A0 0000000001c28800-0000000001c2881f (prio 0, i/o): s= erial
>
>
> Apparently, the register that the mainline linux kernel is using is > DesignWare specific:
>
> drivers/tty/serial/8250/8250_dwlib.c:13:
>
> /* Offsets for the DesignWare specific registers */
> #define DW_UART_DLF<--->0xc0 /* Divisor Latch Fraction Register = */
> #define DW_UART_CPR<--->0xf4 /* Component Parameter Register */<= br> > #define DW_UART_UCV<--->0xf8 /* UART Component Version */
>
> I tried to find a way to increase the memory mapped size of the serial=
> device I created with serial_mm_init(),
> but I don't think its possible with that interface.
>
> I did manage to get it working by overlaying the UART0 with another > unimplemented device
> that does have an I/O size of 0x400, but I guess that is probably not =
> the solution we are looking for?

IMHO this is the correct solution :)

Memory regions have priority. By default a device has priority 0, and
UNIMP device has priority -1000.

So you can use:

=C2=A0 =C2=A0 serial_mm_init(get_system_memory(), AW_H3_UART0_REG_BASE, 2,<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0s->= irq[AW_H3_GIC_SPI_UART0], 115200,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0serial= _hd(0), DEVICE_NATIVE_ENDIAN);
=C2=A0 =C2=A0 create_unimplemented_device("DesignWare-uart",\
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 AW_H3_UART0_REG_BASE,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x400);


Now it makes much more sense to me, th= anks a lot for explaining this!

Allright, I'll= use this approach to finish the work for removing mc->ignore_memory_tra= nsaction_failures.

Regards,
Niek
=
=C2=A0
(Or cleaner, add a create_designware_uart(...) function that does both).
(qemu) info mtree
...
=C2=A0 =C2=A0 0000000001c28000-0000000001c2801f (prio 0, i/o): serial
=C2=A0 =C2=A0 0000000001c28000-0000000001c283ff (prio -1000, i/o): DesignWa= re-uart

You could create an UNIMP region of 0x400 - 0x20 =3D 0x3e0, but that would =
appear this is a different device, so I don't recommend that.

=C2=A0> I wonder, did any of the other SoC / boards have this problem wh= en
=C2=A0> removing mc->ignore_memory_transaction_failures?



--
Niek Linnenbank

--000000000000ed1a5205995e531e--