On 2/7/24 22:05, Philippe Mathieu-Daudé wrote:
On 2/7/24 18:21, Cédric Le Goater wrote:
On 7/2/24 6:15 PM, 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?
If these differences are eMMC related, why not simply test :
if (sd_is_emmc(sd)) ...
in commands ALL_SEND_CID and APP_CMD ? The extra property looks
ambiguous to me.
I'd like to keep the sd_is_emmc() check for code respecting
the eMMC spec. I believe the commands in sd_proto_emmc[] in
this series do respect it, modulo some register field
definitions that are SD specific. So 'x-emmc-kludge' would
be a property to allow eMMC use -- without delaying it further
--, by bypassing a *bug* in our current model. I'm willing to
figure out the problem and fix it, but /after/ the 9.1 release.
We are too close of the soft freeze and trying to fix that
before is too much pressure on my right now.
(Similar pressure I'm putting on you to review this huge series...)
