On Mon, Aug 05, 2013 at 10:45:31AM +0200, Andreas Färber wrote: > Am 05.08.2013 00:04, schrieb Aurélien Jarno: > > On Mon, Jul 29, 2013 at 10:35:31PM +0200, Stefan Weil wrote: > >> Am 27.07.2013 22:58, schrieb Stefan Weil: > >>> Am 27.07.2013 22:43, schrieb Andreas Färber: > >>>> Am 27.07.2013 21:37, schrieb Stefan Weil: > >>>>> Am 27.07.2013 19:43, schrieb Peter Maydell: > >>>>>> On 27 July 2013 17:18, Hervé Poussineau <hpous...@reactos.org> wrote: > >>>>>>> Another solution would be to add a big dummy memory regions on all > >>>>>>> MIPS boards > >>>>>>> to catch memory accesses and not raise an exception. However, this > >>>>>>> means that > >>>>>>> each MIPS board will have its own unassigned memory handler, > >>>>>>> different from the > >>>>>>> global QEMU one. > >>>>>> Better would be to at least provide fake RAZ/WI implementations of > >>>>>> devices for the boards, rather than making the dummy region cover > >>>>>> the whole of the address space. Not 1.6 material, though. > >> > >> > >> For MIPS Malta, Linux boot can be fixed by handling read access for two > >> addresses: > >> > >> 0x1fbf8008 > >> 0x1bc80110 > >> > >> The corresponding definitions in the Linux kernel code seem to be these > >> lines: > >> > >> #define GCMP_BASE_ADDR 0x1fbf8000 > >> #define GCMP_ADDRSPACE_SZ (256 * 1024) > >> #define GCMP_GCB_GCMPB_OFS 0x0008 /* Global GCMP > >> Base */ > >> > >> #define MSC01_BIU_REG_BASE 0x1bc80000 > >> #define MSC01_BIU_ADDRSPACE_SZ (256 * 1024) > >> #define MSC01_SC_CFG_OFS 0x0110 > >> > >> => mips_malta.c needs a handler for reads of > >> (GCMP_BASE_ADDR + GCMP_GCB_GCMPB_OFS) and > >> (MSC01_BIU_REG_BASE + MSC01_SC_CFG_OFS). > > > > I don't think it would be correct to emulate them as this are not > > present on the real Malta board, at least for the model emulated by > > QEMU. Theses addresses correspond to the SMP controller, and is > > therefore only present when an SMP daughter card is installed. > > > > The Linux kernel probes theses addresses, and look if they return > > something consistent. If not the corresponding devices are latter > > ignored. > > > > 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. > [snip] > > Have you tested Jan's patches limiting the new unassigned read value -1 > to PIO? >
I have tried this patches, and they don't fix the problem. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
