On Mon, Aug 05, 2013 at 07:19:08AM +0200, Stefan Weil wrote: > Am 05.08.2013 00:37, schrieb Peter Maydell: > > On 4 August 2013 23:04, Aurélien Jarno <aurel...@aurel32.net> wrote: > >> The real hardware probably returns all 1 or all 0 for addresses not > >> decoded to a device. This is what QEMU should model, and it should > >> not trigger a DBE or IBE exception. Looking at the current MIPS > >> documentation, Bus Error is defined as: > >> > >> A bus error exception occurs when an instruction or data access makes a > >> bus request (due to a cache miss or an uncacheable reference) and > >> that request terminates in an error. > >> > >> Older CPU documentation like the R4000 have a more precise definition: > >> > >> A Bus Error exception is raised by board-level circuitry for events such > >> as bus time-out, backplane bus parity errors, and invalid physical memory > >> addresses or access types. > >> > >> As we don't model this kind of errors, we should definitely just not > >> trigger an exception in that case, and even logging the event as > >> unimplemented is probably wrong. > > Well, we certainly can model invalid-physical-address and > > bus-timeout where that's what the board does for accesses > > to non-decoded addresses; but presumably in this case it > > doesn't... > > > > -- PMM > > Is there anybody who has access to physical Malta hardware? > It would be interesting to see whether there is an exception > during the gcmp test or not. > > With latest QEMU, the MIPS Malta system emulation starts > handling the exception caused by the gcmp test, but then > gets a second exception which is fatal (see below). > > There might be something missing in our very simple bios > emulation.
Booting YAMON in QEMU also shows the same behaviour, that is trying to access to the 1fbf8008 address and getting a DBE exception, causing it to fail. So it is clearly not due to our simple bios emulation, but rather to the way the I/O are emulated. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net