From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37431) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gaj09-0001LW-8Z for qemu-devel@nongnu.org; Sat, 22 Dec 2018 10:15:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gaj05-0003Rm-7C for qemu-devel@nongnu.org; Sat, 22 Dec 2018 10:15:41 -0500 Received: from indium.canonical.com ([91.189.90.7]:33588) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gaj05-0003Nh-0g for qemu-devel@nongnu.org; Sat, 22 Dec 2018 10:15:37 -0500 Received: from loganberry.canonical.com ([91.189.90.37]) by indium.canonical.com with esmtp (Exim 4.86_2 #2 (Debian)) id 1gaj03-0006rq-DI for ; Sat, 22 Dec 2018 15:15:35 +0000 Received: from loganberry.canonical.com (localhost [127.0.0.1]) by loganberry.canonical.com (Postfix) with ESMTP id 613792E805B for ; Sat, 22 Dec 2018 15:15:35 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Sat, 22 Dec 2018 15:08:25 -0000 From: Daniels Umanovskis <1809546@bugs.launchpad.net> Reply-To: Bug 1809546 <1809546@bugs.launchpad.net> Sender: bounces@canonical.com Message-Id: <154549130563.19742.15114184471142076379.malonedeb@soybean.canonical.com> Errors-To: bounces@canonical.com Subject: [Qemu-devel] [Bug 1809546] [NEW] Writing a byte to a pl011 SFR overwrites the whole SFR List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Public bug reported: The bug is present in QEMU 2.8.1 and, if my analysis is correct, also on master. I first noticed that a PL011 UART driver, which is fine on real hardware, fails to enable the RX interrupt in the IMSC register when running in QEMU. However, the problem only comes up if the code is compiled without optimizations. I think I've narrowed it down to a minimal example that will exhibit the problem if run as a bare-metal application. Given: pl011_addr: .word 0x10009000 The following snippet will be problematic: ldr r3, pl011_addr ldrb r2, [r3, #0x38] // IMSC mov r2, #0 orr r2, r2, #0x10 // R2 =3D=3D 0x10 strb r2, [r3, #0x38] // Whole word reads correctly after this ldrb r2, [r3, #0x39] mov r2, #0 strb r2, [r3, #0x39] // Problem here! Overwrites offset 0x38 as= well After the first strb instruction, which writes to 0x10009038, everything is fine. It can be seen in the QEMU monitor: (qemu) xp 0x10009038 0000000010009038: 0x00000010 After the second strb instruction, the write to 0x10009039 clears the entire word: (qemu) xp 0x10009038 0000000010009038: 0x00000000 QEMU command-line, using the vexpress-a9 which has the PL011 at 0x10009000: qemu-system-arm -S -M vexpress-a9 -m 32M -no-reboot -nographic -monitor telnet:127.0.0.1:1234,server,nowait -kernel pl011-sfr.bin -gdb tcp::2159 -serial mon:stdio Compiling the original C code with optimizations makes the driver work. It compiles down to assembly that only does a single write: ldr r3, pl011_addr mov r2, #0x10 str r2, [r3, #0x38] Attached is the an assembly file, and linkscript, that shows the problem, and also includes the working code. I haven't debugged inside of QEMU itself but it seems to me that the problem is in pl011_write in pl011.c - the functions looks at which offset is being written, and then writes the entire SFR that offset falls under, which means that changing a single byte will change the whole SFR. ** Affects: qemu Importance: Undecided Status: New ** Attachment added: "startup.s" https://bugs.launchpad.net/bugs/1809546/+attachment/5224336/+files/start= up.s -- = You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1809546 Title: Writing a byte to a pl011 SFR overwrites the whole SFR Status in QEMU: New Bug description: The bug is present in QEMU 2.8.1 and, if my analysis is correct, also on master. I first noticed that a PL011 UART driver, which is fine on real hardware, fails to enable the RX interrupt in the IMSC register when running in QEMU. However, the problem only comes up if the code is compiled without optimizations. I think I've narrowed it down to a minimal example that will exhibit the problem if run as a bare-metal application. Given: pl011_addr: .word 0x10009000 The following snippet will be problematic: ldr r3, pl011_addr ldrb r2, [r3, #0x38] // IMSC mov r2, #0 orr r2, r2, #0x10 // R2 =3D=3D 0x10 strb r2, [r3, #0x38] // Whole word reads correctly after this ldrb r2, [r3, #0x39] mov r2, #0 strb r2, [r3, #0x39] // Problem here! Overwrites offset 0x38 = as well After the first strb instruction, which writes to 0x10009038, everything is fine. It can be seen in the QEMU monitor: (qemu) xp 0x10009038 0000000010009038: 0x00000010 After the second strb instruction, the write to 0x10009039 clears the entire word: (qemu) xp 0x10009038 0000000010009038: 0x00000000 QEMU command-line, using the vexpress-a9 which has the PL011 at 0x10009000: qemu-system-arm -S -M vexpress-a9 -m 32M -no-reboot -nographic -monitor telnet:127.0.0.1:1234,server,nowait -kernel pl011-sfr.bin -gdb tcp::2159 -serial mon:stdio Compiling the original C code with optimizations makes the driver work. It compiles down to assembly that only does a single write: ldr r3, pl011_addr mov r2, #0x10 str r2, [r3, #0x38] Attached is the an assembly file, and linkscript, that shows the problem, and also includes the working code. I haven't debugged inside of QEMU itself but it seems to me that the problem is in pl011_write in pl011.c - the functions looks at which offset is being written, and then writes the entire SFR that offset falls under, which means that changing a single byte will change the whole SFR. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1809546/+subscriptions