| Message ID | 20240628070216.92609-91-philmd@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | hw/sd/sdcard: Add eMMC support | expand |
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. Thanks, C. > > Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> > --- > hw/sd/sd.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/hw/sd/sd.c b/hw/sd/sd.c > index bd77853419..dc692fe1fa 100644 > --- a/hw/sd/sd.c > +++ b/hw/sd/sd.c > @@ -127,6 +127,7 @@ struct SDState { > > uint8_t spec_version; > BlockBackend *blk; > + bool aspeed_emmc_kludge; > > const SDProto *proto; > > @@ -2567,6 +2568,8 @@ static Property sd_properties[] = { > DEFINE_PROP_UINT8("spec_version", SDState, > spec_version, SD_PHY_SPECv3_01_VERS), > DEFINE_PROP_DRIVE("drive", SDState, blk), > + DEFINE_PROP_BOOL("x-aspeed-emmc-kludge", SDState, > + aspeed_emmc_kludge, false), > /* We do not model the chip select pin, so allow the board to select > * whether card should be in SSI or MMC/SD mode. It is also up to the > * board to ensure that ssi transfers only occur when the chip select
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. Andrew
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?
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. Thanks, C.
diff --git a/hw/sd/sd.c b/hw/sd/sd.c index bd77853419..dc692fe1fa 100644 --- a/hw/sd/sd.c +++ b/hw/sd/sd.c @@ -127,6 +127,7 @@ struct SDState { uint8_t spec_version; BlockBackend *blk; + bool aspeed_emmc_kludge; const SDProto *proto; @@ -2567,6 +2568,8 @@ static Property sd_properties[] = { DEFINE_PROP_UINT8("spec_version", SDState, spec_version, SD_PHY_SPECv3_01_VERS), DEFINE_PROP_DRIVE("drive", SDState, blk), + DEFINE_PROP_BOOL("x-aspeed-emmc-kludge", SDState, + aspeed_emmc_kludge, false), /* We do not model the chip select pin, so allow the board to select * whether card should be in SSI or MMC/SD mode. It is also up to the * board to ensure that ssi transfers only occur when the chip select
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. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> --- hw/sd/sd.c | 3 +++ 1 file changed, 3 insertions(+)