qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH] hw: arm: Add basic support for cprman (cloc


From: Guenter Roeck
Subject: Re: [Qemu-devel] [RFC PATCH] hw: arm: Add basic support for cprman (clock subsystem)
Date: Mon, 16 Jul 2018 15:22:50 -0700
User-agent: Mutt/1.5.24 (2015-08-30)

On Mon, Jul 16, 2018 at 03:07:13PM +0100, Peter Maydell wrote:
> On 16 July 2018 at 14:51, Guenter Roeck <address@hidden> wrote:
> > In this context, I can't get mmc to work with ToT Linux on raspi3.
> >
> > / # mount /dev/mmcblk0 /mnt
> > [   47.099074] sdhost-bcm2835 3f202000.mmc: timeout waiting for hardware
> > interrupt.
> > [   57.339803] sdhost-bcm2835 3f202000.mmc: timeout waiting for hardware
> > interrupt.
> > [   57.390449] mmc0: Problem switching card into high-speed mode!
> > [   67.581559] sdhost-bcm2835 3f202000.mmc: timeout waiting for hardware
> > interrupt.
> > [   67.587832] print_req_error: I/O error, dev mmcblk0, sector 2
> > [   67.588908] Buffer I/O error on dev mmcblk0, logical block 1, lost sync
> > page write
> > [   67.610307] EXT4-fs (mmcblk0): I/O error while writing superblock
> > [   67.620842] EXT4-fs (mmcblk0): mount failed
> > [   77.819114] sdhost-bcm2835 3f202000.mmc: timeout waiting for hardware
> > interrupt.
> > [   88.058917] sdhost-bcm2835 3f202000.mmc: timeout waiting for hardware
> > interrupt.
> > [   98.298937] sdhost-bcm2835 3f202000.mmc: timeout waiting for hardware
> > interrupt.
> > [   98.303554] print_req_error: I/O error, dev mmcblk0, sector 2
> > [   98.306044] Buffer I/O error on dev mmcblk0, logical block 1, lost sync
> > page write
> >
> > Any idea what the problem might be ?
> 
> Same thing again -- no hardware documentation for that sd controller.
> We took our best guess about what the behaviour is supposed to be
> for raising hardware interrupts in commit f3d9fe8f959643 earlier
> this year, but that was (as the commit message notes) pure guesswork
> based largely on what the Linux driver was doing. Somebody would have
> to look at what exactly this version of the kernel is expecting the
> hardware to do and try to reverse-engineer what the model needs to do
> that it isn't currently...
> 

This failed for me with all kernel versions I tried, starting with 4.14.y.

I'll send a patch in a minute. It is just as much guesswork as before,
but AFAICS it does work.

Guenter



reply via email to

[Prev in Thread] Current Thread [Next in Thread]