On 12 June 2014 14:15, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 12 June 2014 13:09, Ulf Hansson <ulf.hans...@linaro.org> wrote: >> A simple fix; for the arm_variant, go back to use the old behaviour. >> >> A quite simple fix; Invent a new primecell-periphid and a new >> corresponding variant and use the old behaviour for this variant. The >> new primecell-periphid then needs to be provided through DT for the >> QEMU dtb. >> >> Is there any of the above solution you see as the preferred one? > > Those both sound like workarounds, not fixes, to me. Somebody > needs to identify whether the bug here is in: > * the kernel (unlikely, but possibly the kernel has a race > condition that only gets triggered by QEMU's "operations > that take time in h/w happen instantaneously in emulation" > behaviour) > * the QEMU model of the PL181 > * the QEMU model of the SD card > and then fix whichever of these is not conforming to the > specs/docs/etc.
You are right. But... Since we (or actually me) have made the ARM model to break (it worked nicely before), I just wanted to restore the behaviour as a quick fix. I believe going into this in detail can take some more time, especially if it's related to the ARM model, right!? Kind regards Uffe > > Also, there's no such thing as a "QEMU dtb", at least for > most of our board models. QEMU models the actual hardware > (sometimes buggily or incompletely) and so should use the > exact same dtb you would use with the hardware. > > thanks > -- PMM -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
