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: Andrew Jeffery
Subject: Re: [SPAM] [RFC PATCH v42 90/98] hw/sd/sdcard: Add experimental 'x-aspeed-emmc-kludge' property
Date: Wed, 03 Jul 2024 14:40:19 +0930
User-agent: Evolution 3.46.4-2

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).

Andrew




reply via email to

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