From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57490) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCs6v-0002px-HR for qemu-devel@nongnu.org; Fri, 23 Aug 2013 10:13:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VCs6p-0007Hc-Qi for qemu-devel@nongnu.org; Fri, 23 Aug 2013 10:13:09 -0400 Received: from multi.imgtec.com ([194.200.65.239]:18901) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCs6p-0007Gp-K1 for qemu-devel@nongnu.org; Fri, 23 Aug 2013 10:13:03 -0400 Message-ID: <52176DEC.8010207@imgtec.com> Date: Fri, 23 Aug 2013 15:13:00 +0100 From: James Hogan MIME-Version: 1.0 References: <1377244791-56856-1-git-send-email-leon.alrae@imgtec.com> <5217429F.4060606@suse.de> In-Reply-To: <5217429F.4060606@suse.de> Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH] mips/malta: prevent writes to reset flash mapping faulting List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-15?Q?Andreas_F=E4rber?= Cc: paul.burton@imgtec.com, qemu-devel@nongnu.org, yongbok.kim@imgtec.com, cristian.cuna@imgtec.com, Leon Alrae , aurelien@aurel32.net Hi Andreas, On 23/08/13 12:08, Andreas Färber wrote: > Am 23.08.2013 09:59, schrieb Leon Alrae: >> From: James Hogan >> >> Commit a427338 (mips_malta: correct reading MIPS revision at 0x1fc00010) >> altered the behaviour of the monitor flash mapping at the reset address >> by making it read only. However this causes data bus error exceptions >> when it is written to since it is effectively unassigned memory for >> writes. This isn't how the real hardware behaves. That memory can be >> written to (even with the MFWR jumper not fitted) and the new value read >> back from, but it doesn't get written back to the monitor flash so is >> volatile. >> >> This is fixed by converting the bios copy from read only ram to a bios >> device with a nop write callback. > > That sounds like a contradiction: The nop write will not have reads > return the new value, will it? correct. > Why not just remove the _set_readonly and have it reloaded on reset for > volatility? That's what I tried first, but the bios copy is normal ram so it doesn't get reloaded on reset. I'll have a play to see if I can use rom_add_blob (although I seem to remember already trying that...). > Anyway, having a MemoryRegionOps with just a .write looks dangerous, but > I guess you've tested read to work. We had been seeing assertions > elsewhere when either was missing. Yeh reads seem to work fine (it also executes from it fine). Thanks for taking a look James