Re: [Qemu-arm] [PATCH 4/8] bcm2835_emmc: add bcm2835 MMC/SD controller

[Peter Crosthwaite]

On Tue, Dec 8, 2015 at 10:19 PM, Andrew Baumann
<address@hidden> wrote:
>> From: Peter Crosthwaite [mailto:address@hidden
>> Sent: Saturday, 5 December 2015 21:26
>> Is this IP just SDHCI? We already model SDHCI in QEMU, see
>> hw/sd/sdhci.c. If there are RPi specific features to the SDHCI
>> implementation they should be added as optional extensions (probabably
>> via subclassing) to the existing SDHCI model.
>
> So yes, it turns out this is fairly similar to SDHCI (-> lots of wasted work 
> by Gregory and me, sigh), and indeed Linux boots with the existing sdhci 
> emulation. However, there are some quirks, and UEFI/Windows depend on them. 
> Namely:
>  * The host control registers (offset 0x28 and above) seem to differ 
> significantly. Maybe this is due to the SDHC version -- according to the 
> BCM2835 peripherals spec, the controller implements "Version 3.0 Draft 1.0" 
> of the SDHC spec, but of course I can't find that spec online anywhere. 
> Luckily nothing seems to depend on this, besides a few spurious warnings 
> about invalid writes.

Looks reasonably consistent from a quick scan? 0x28 in shdci.c is only
doing the ADMA stuff while there are other fields on the BCM model.

>  * Power is assumed to be always on -- the sdhci model requires the guest to 
> turn it on by a write at offset 0x29 before issuing any commands, but on pi 
> this bit is marked reserved, and commands are issued immediately after reset.

Does this help?:

https://lists.gnu.org/archive/html/qemu-devel/2015-11/msg06271.html

>  * The card inserted interrupt is rather broken on pi: it is set at the start 
> of day, but a reset command clears it and it stays clear thereafter (and 
> never generates interrupts).
>

Is that more likely to be an IP connectivity problem (wierd input to
the card-detect pin in the SoC)?

> There's an inconsistency with response handling, too, although I'm not sure 
> if it's a quirk of the Pi or a general bug in sdhci. Pi UEFI sends a CMD23 
> without setting any of the response bits, but this command does in fact 
> generate a 4-byte R1 response. The question is whether this should be treated 
> as an error, or whether it simply means that the host wants to ignore the 
> response. In sdhci, the following code path (around line 246) raises a 
> "command index" error in the case that a non-zero response is returned but no 
> response bits were set in the command register:
>
>     } else if (rlen != 0 && (s->errintstsen & SDHC_EISEN_CMDIDX)) {
>         s->errintsts |= SDHC_EIS_CMDIDX;
>         s->norintsts |= SDHC_NIS_ERR;
>     }
>
> I do not observe this behaviour on the real Pi2 (and it breaks UEFI). The 
> hardware semantics appear to be "if the command generates a response, but you 
> didn't want to see it, we'll successfully complete the command and ignore the 
> response", whereas the sdhci implementation raises an error for this as well 
> as signalling completion. I have read the "SD Specifications Part A2 SD Host 
> Controller Simplified Specification Version 2.00", but did not find anything 
> describing this case, so it could be that this is open to interpretation. (It 
> could also be specified in SDHC v3.) The specific error also seems odd -- my 
> understanding is that a "command index" error means that the index in the 
> response didn't match the index of the issued command, but that's hardly what 
> is happening here.
>

Starting to sound like a bug.

> Assuming this latter bug can be fixed generically, how do you propose 
> handling the Pi quirks? I could add a bool property for "bcm2835-quirks" or 
> similar and just special-case the relevant code (my preferred approach). I'm 
> also open to subclassing, but no idea how that would work in practice, so 
> would need some pointers.
>

I think we need a more definitive list of the register level features
that are different or added, I am not seeing what is BCM specific just
yet.

Regards,
Peter

> Thanks,
> Andrew