Opened 2 years ago

Closed 21 months ago

#12216 closed defect (fixed)

XO-1.75/XO4 don't support 1.8 volt SD cards

Reported by: jvonau Owned by: cjb
Priority: normal Milestone: 13.1.0
Component: kernel Version: Software Build 12.1.0-21
Keywords: Cc: georgejhunt@…, holt@…, wad, dsd, pgf
Blocked By: Blocking:
Deployments affected: Action Needed: test in build
Verified: no

Attachments (5)

0001-update-sdhci-for-voltage-changing-fixes.txt (3.6 KB) - added by dsd 2 years ago.
sdhci fix (3.5)
0001-mmc-core-Fixup-signal-voltage-switch.patch (7.2 KB) - added by dsd 2 years ago.
upstream rfc (3.5)
0001-mmc-core-Fixup-signal-voltage-switch.2.patch (5.7 KB) - added by dsd 2 years ago.
upstream rfc (3.0)
0002-update-sdhci-for-voltage-changing-fixes.patch (3.5 KB) - added by dsd 2 years ago.
sdhci fix (3.0)
ec_sd2.bin (32.0 KB) - added by rsmith 2 years ago.

Download all attachments as: .zip

Change History (25)

comment:1 Changed 2 years ago by holt

  • Cc georgejhunt@… holt@… added

comment:2 Changed 2 years ago by dsd

  • Cc wad added
  • Milestone changed from Not Triaged to 13.1.0
  • Owner set to cjb

comment:3 Changed 2 years ago by cjb

  • Status changed from new to assigned

Already sent a patch to devel@, waiting for testing.

comment:4 Changed 2 years ago by dsd

The patch doesn't make any difference - it for eMMC.

The problem here is that the kernel tries to go back to 3.3V after detecting the failure, but fails.

An upstream RFC patch fixes this for XO-4 (3.5) but not for XO-1.75 (3.0). The failure was obvious, so I fixed it with a sdhci patch. That fixed XO-1.75 and broke XO-4. Sigh.

Changed 2 years ago by dsd

sdhci fix (3.5)

Changed 2 years ago by dsd

upstream rfc (3.5)

Changed 2 years ago by dsd

upstream rfc (3.0)

Changed 2 years ago by dsd

sdhci fix (3.0)

comment:5 Changed 2 years ago by dsd

http://marc.info/?l=linux-mmc&m=135103249232651&w=3

All work in progress posted here.

comment:6 Changed 2 years ago by dsd

  • Cc dsd added

The conclusions from the upstream discussion so far is that we haven't found a reliable way of power-cycling the SD card on XO-1.75. So we were tipping towards adding a quirk.

Then cjb pointed out this code in the xo-1.75 board file:

	gpio_request(35, "ext_sd power");
	gpio_direction_output(35, 1);
	pxa_register_device(&mmp2_device_sdh0, &olpc_xo_1_75_ext_sd, sizeof(olpc_xo_1_75_ext_sd));

So I tried implementing a vmmc regulator on gpio 35, spent more time fiddling, and didn't get anywhere. In fact, it was as if playing with the gpio has no influence at all.

Sure enough, going back to arm-3.0 and modifying the above board file, setting the value to 0 instead of 1, or removing the gpio assignment altogether, doesn't stop the external SD card from working (testing with a normal 3.3V card as a baseline here).

When people are back from XO-4 bringup we should do a bit more investigation here; is GPIO 35 really hooked up to external SD card power? Then we can decide where to go.

comment:7 Changed 2 years ago by pgf

i'm afraid the board file is wrong. gpio 35 is hooked up to a test point. the socket is hardwired to 3.3V.

comment:8 Changed 2 years ago by wad

  • Summary changed from arm doesn't support 1.8 volt card to XO-1.75/XO4 don't support 1.8 volt SD cards

Why doesn't someone ask me, if they don't know ?

On XO-1.75:
Only +3.3V operation of the SD interfaces is supported, but they definitely are NOT hardwired. Power is switched.

The external SD slot power switch is controlled by EN_SD2_PWR#.

Both the internal eMMC and the internal SD slot share an MMC interface. Only one can be used at a time, selected by a jumper when the internal SD slot is installed. As such, they share a power switch, controlled by EN_SD1_PWR#.

However, as with the XO-1.5, these power control lines do NOT go to a GPIO accessible by the main processor. They are instead connected to the embedded controller. They can be turned on and off by sending commands to the EC. I believe the EC firmware already implements these commands, but Linux was not wired up properly to use them.

This method of control was done because we encountered some SD cards which violated the SD spec and lost data if they were turned off immediately after a data transfer. Having the EC control their power allows it to maintain power to the SD card for a second after the main processor is turned off, fixing our random data loss problems. I believe this breaks the simplistic DT model of how things are turned on/off...

comment:9 follow-up: Changed 2 years ago by cjb

  • Cc pgf added

Thanks, Wad. The bug title's confusing: all we're trying to do at the moment is control the 3.3V supply to the external SD so that we can reset it correctly.

The EC command to do that isn't documented in http://wiki.laptop.org/go/XO_1.75_HOST_to_EC_Protocol.

Paul, please could you tell us which EC command to use to control EN_SD2_PWR#?

Dan, I guess we'll need a new platform hook to perform the reset in MMC.

comment:10 in reply to: ↑ 9 ; follow-up: Changed 2 years ago by rsmith

The EC command to do that isn't documented in http://wiki.laptop.org/go/XO_1.75_HOST_to_EC_Protocol.

Paul, please could you tell us which EC command to use to control EN_SD2_PWR#?

-ENOTIMPLEMENTED

In the 1.5 to 1.75 port I guess we never bothered to implement those commands. EC turns on the rails at power up and leaves them up until power down.

Give me an hour or so and I'll re-add the command. It will be EC cmd 0x6f with and arg of 1 or 0 to power up/down.

comment:11 Changed 2 years ago by pgf

dsd -- now you should know never to pay any attention to me when i make pronouncements about hardware. at best i'm only half right.

comment:12 in reply to: ↑ 10 ; follow-up: Changed 2 years ago by rsmith

Give me an hour or so and I'll re-add the command. It will be EC cmd 0x6f with and arg of 1 or 0 to power up/down.

Test EC code attached to this ticket.

Changed 2 years ago by rsmith

comment:13 in reply to: ↑ 12 Changed 2 years ago by rsmith

Replying to rsmith:

Give me an hour or so and I'll re-add the command. It will be EC cmd 0x6f with and arg of 1 or 0 to power up/down.

Test EC code attached to this ticket.

To update from a USB flash stick.

ok flash-ec u:\ec_sd2.bin

comment:14 Changed 2 years ago by wad

pgf,

You are too hard on yourself. You were completely correct, to a first approximation. Until Richard restored that EC command, the power was hardwired on.

comment:15 Changed 2 years ago by dsd

Thanks for all the input. Another question I have (happy to wait til a later date, don't want to further distract from bringup): is the software in general able to perform a complete power cycle of an external SD card, when using this SoC, using only the sdhci interface (no gpios, etc)? Both in our case, and in the normal case, if there is a difference.

What I'm basically wondering is if the driver can safely make the assumption that power cycling a card is impossible unless it has a GPIO or platform reset method.

In other words, is the SD card power supply routed through the SoC where it could potentially have an on/off switch applied at the SDHCI interface level, or does the SoC design effectively mandate that the power supply is something separate?

Can the same response be applied to other sdhci-based systems or is the answer always going to be specific to the hardware implementation?

comment:16 Changed 2 years ago by dsd

The new EC code works great with cmd 0x6f. Thanks. Now I'll work with upstream to see if that is the direction we want to go, with the other options considered too.

comment:17 Changed 2 years ago by wad

It varies whether the SDHCI controller brings the power control pins from the SDHCI interface out for use externally.

On the Via VX850 used in the XO-1.5, the SDHCI power control (both on/off and volt. select) was brought out to pins --- but the circuitry was flawed and they didn't hold their value across suspend/resume. We fixed this with external circuitry but other designers might have used GPIOs instead.

Neither of the Marvell SoCs brought the SDHCI power control signals out to pins, forcing the use of GPIOs instead. Marvell's reference designs tend to either wire the SD cards to +3.3V, providing no control over card power, or wire it to their PMIC which would require an I2C command to turn it on/off.

comment:18 Changed 23 months ago by dsd

  • Action Needed changed from never set to add to build

Thanks for the explanation - that clears it up.

For the upstream XO-1.75 fix, we seem to have settled on simply providing a flag in the device tree that indicates that the controller has no 1.8v supply available. So there is no immediate need for the new EC command, although it would be useful to have around. It was also valuable to be able to verify what we were suspecting.

The upstream patches have been tentatively acked by cjb:

With the upstream path seemingly complete, I've added a hack to arm-3.0-wip to disable 1.8v and this makes George Hunt's UHS-I card work (3453366).

comment:19 Changed 23 months ago by dsd

  • Action Needed changed from add to build to test in build

Test in 13.1.0 build 16.

comment:20 Changed 21 months ago by dsd

  • Resolution set to fixed
  • Status changed from assigned to closed

Tested in 13.1.0 build 30 on XO-1.75 and XO-4, this is working correctly.

Note: See TracTickets for help on using tickets.