qemu-devel
[Top][All Lists]
Advanced

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

Re: [SPAM] [RFC PATCH v42 90/98] hw/sd/sdcard: Add experimental 'x-aspee


From: Cédric Le Goater
Subject: Re: [SPAM] [RFC PATCH v42 90/98] hw/sd/sdcard: Add experimental 'x-aspeed-emmc-kludge' property
Date: Wed, 3 Jul 2024 07:39:26 +0200
User-agent: Mozilla Thunderbird

On 7/3/24 7:10 AM, Andrew Jeffery wrote:
On Tue, 2024-07-02 at 18:15 +0200, Philippe Mathieu-Daudé wrote:
On 2/7/24 07:06, Andrew Jeffery wrote:
On Fri, 2024-06-28 at 11:16 +0200, Cédric Le Goater wrote:
On 6/28/24 9:02 AM, Philippe Mathieu-Daudé wrote:
When booting U-boot/Linux on Aspeed boards via eMMC,
some commands don't behave as expected from the spec.

Add the 'x-aspeed-emmc-kludge' property to allow non
standard uses until we figure out the reasons.

I am not aware of any singularity in the eMMC logic provided by Aspeed.
U-Boot and Linux drivers seem very generic. May be others can tell.

I'm not aware of any command kludges. The main problem I had when I
wrote the Linux driver for the Aspeed controller was the phase tuning,
but that doesn't sound related.

Yeah I don't think anything Aspeed nor U-boot related, we
model CSD/CID registers per the SD spec, not MMC. Various
fields are identical, but few differ, this might be the
problem.

I rather respect the spec by default, so until we figure
the issue, are you OK to use a 'x-emmc-kludge' property
and set it on the Aspeed boards?

Dropping the implication that it's the fault of the Aspeed controller
seems reasonable (without further evidence that it's true).

Yes. Let's introduce 'x-emmc-kludge' and move on.

I dropped all emmc support from the aspeed-9.1 branch for now.

Thanks,

C.




reply via email to

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