qemu-arm
[Top][All Lists]
Advanced

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

Re: [Qemu-arm] [PATCH 1/8] sdcard: Update the Configuration Register (SC


From: Philippe Mathieu-Daudé
Subject: Re: [Qemu-arm] [PATCH 1/8] sdcard: Update the Configuration Register (SCR) to Spec Version 1.10
Date: Thu, 7 Jun 2018 12:14:25 -0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

Hi Peter,

On 06/07/2018 08:00 AM, Peter Maydell wrote:
> On 3 June 2018 at 01:08, Philippe Mathieu-Daudé <address@hidden> wrote:
>> This register now matches the description of the header:
>>
>>  * SD Memory Card emulation as defined in the "SD Memory Card Physical
>>  * layer specification, Version 1.10."
> 
> Can you provide a brief justification in the commit message
> of why it makes more sense for us to advertise as 1.10, please?
> 
> (eg a summary of the 1.01 to 1.10 differences and a note
> that we already implement them)

The only differences I found are:

    4.3.11 High-Speed mode (25MB/sec interface speed)
           (This chapter is newly added in version 1.10)

    Though the Rev 1.01 SD memory card supports up to 12.5MB/sec
    interface speed, the speed of 25MB/sec is necessary to support
    increasing performance needs of the host and because of memory
    size which continues to grow.
    To achieve 25MB/sec interface speed, clock rate is increased to
    50MHz and CLK/CMD/DAT signal timing and circuit conditions are
    reconsidered and changed from Physical Layer Specification
    Version 1.01.

    4.3.12 Command system
           (This chapter is newly added in version 1.10)

    SD commands CMD34-37, CMD50, CMD57 are reserved for SD command
    system expansion via the switch command.
    [These commands] will be considered as illegal commands (as
    defined in revision 1.01 of the SD physical layer specification).

The current codebase is a mix of v1 registers and v2 commands (which
were added slowly without updating all registers).
As of now v1 is broken (See the lm3s6965evb machine can not use the
card) and all users are using v2.
My goal with these series is to also support v3.

It might be more obvious to first enforce the current implementation is
v2, then restore v1 support and go for v3. I think this is doable by an
easy rebase of this series (keep v2 and restore v1).

Do you think this is better?

Regards,

Phil.



reply via email to

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