Messages in this thread | | | Date | Fri, 13 Jun 2014 13:35:36 +0200 | Subject | Re: [Regression] 3.15 mmc related ext4 corruption with qemu-system-arm | From | Ulf Hansson <> |
| |
On 12 June 2014 14:15, Peter Maydell <peter.maydell@linaro.org> wrote: > On 12 June 2014 13:09, Ulf Hansson <ulf.hansson@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
| |