When booting a beaglebone black with the SD-boot button held down, the eMMC connected to the sdhci_ti1 device does not work. Booting without holding down the SD-boot button does work, presumably because that causes the am335x ROM to configure the hardware. This was originally thought to be bug 238344, because the symptoms are the same, but in this case the problem is in freebsd code, not u-boot.
A commit references this bug: Author: ian Date: Wed Oct 16 16:03:19 UTC 2019 New revision: 353651 URL: https://svnweb.freebsd.org/changeset/base/353651 Log: Relax the sdhci(4) check that filters out the 1.8v voltage option unless the slot is flagged as 'embedded'. The features related to embedded and shared slots were added in v3.0 of the sdhci spec. Hardware prior to v3 sometimes supported 1.8v on non- removable devices in embedded systems, but had no way to indicate that via the standard sdhci registers (instead they use out of band metadata such as FDT data). This change adds the controller specification version to the check for whether to filter out the 1.8v selection. On older hardware, the 1.8v option is allowed to remain. On 3.0 or later it still requires the embedded-slot flag to remain. This is part of the fix for PR 241301 (eMMC not detected on Beaglebone). Changes to the sdhci_ti driver are also needed for a full fix. PR: 241301 Changes: head/sys/dev/sdhci/sdhci.c
A commit references this bug: Author: ian Date: Wed Oct 16 16:19:21 UTC 2019 New revision: 353652 URL: https://svnweb.freebsd.org/changeset/base/353652 Log: Revert r351218 (by manu). While the changes in r351218 appear to be (and should be) correct, they lead to the eMMC on a Beaglebone failing to work in some situations. The TI sdhci hardware is kind of strange. The first device inherently supports 1.8v and 3.3v and the abililty to switch between them, and the other two devices must be set to 1.8v in the sdhci power control register to operate correctly, but doing so actually makes them run at 3.3v (unless an external level-shifter is present in the signal path). Even the 1.8v on the first device may actually be 3.3v (or any other value), depending on what voltage is fed to the VDDS1-VDDS7 power supply pins on the am335x chip. Another strange quirk is that the convention for am335x sdhci drivers in linux and uboot and the am335x boot ROM seems to be to set the voltage in the sdhci capabilities register to 3.0v even though the actual voltage is 3.3v. Why this is done is a complete mystery to me, but it seems to be required for correct operation. If we had complete modern support for the am335x chip we could get the actual voltages from the FDT data and the regulator framework. But our am335x code currently doesn't have any regulator framework support. Reverting to the prior code will get the popular Beaglebone boards working again. This is part of the fix for PR 241301, but also requires r353651 for a complete fix. PR: 241301 Discussed with: manu Changes: head/sys/arm/ti/ti_sdhci.c
With r353651 and r353652 applied, I can now boot with or without holding down the SD-boot button on a beaglebone and the eMMC is detected and available at runtime. (I still sometimes get a single 'controller timeout' during boot that seems to be unrelated to this problem, but then it continues and detects the device). This will be MFC'd to 12-stable asap, and then to 12.1-release if possible.
A commit references this bug: Author: ian Date: Thu Oct 17 01:30:38 UTC 2019 New revision: 353675 URL: https://svnweb.freebsd.org/changeset/base/353675 Log: MFC r353651-r353652 r353651: Relax the sdhci(4) check that filters out the 1.8v voltage option unless the slot is flagged as 'embedded'. The features related to embedded and shared slots were added in v3.0 of the sdhci spec. Hardware prior to v3 sometimes supported 1.8v on non- removable devices in embedded systems, but had no way to indicate that via the standard sdhci registers (instead they use out of band metadata such as FDT data). This change adds the controller specification version to the check for whether to filter out the 1.8v selection. On older hardware, the 1.8v option is allowed to remain. On 3.0 or later it still requires the embedded-slot flag to remain. This is part of the fix for PR 241301 (eMMC not detected on Beaglebone). Changes to the sdhci_ti driver are also needed for a full fix. PR: 241301 r353652: Revert r351218 (by manu). While the changes in r351218 appear to be (and should be) correct, they lead to the eMMC on a Beaglebone failing to work in some situations. The TI sdhci hardware is kind of strange. The first device inherently supports 1.8v and 3.3v and the abililty to switch between them, and the other two devices must be set to 1.8v in the sdhci power control register to operate correctly, but doing so actually makes them run at 3.3v (unless an external level-shifter is present in the signal path). Even the 1.8v on the first device may actually be 3.3v (or any other value), depending on what voltage is fed to the VDDS1-VDDS7 power supply pins on the am335x chip. Another strange quirk is that the convention for am335x sdhci drivers in linux and uboot and the am335x boot ROM seems to be to set the voltage in the sdhci capabilities register to 3.0v even though the actual voltage is 3.3v. Why this is done is a complete mystery to me, but it seems to be required for correct operation. If we had complete modern support for the am335x chip we could get the actual voltages from the FDT data and the regulator framework. But our am335x code currently doesn't have any regulator framework support. Reverting to the prior code will get the popular Beaglebone boards working again. This is part of the fix for PR 241301, but also requires r353651 for a complete fix. PR: 241301 Discussed with: manu Approved by: re(gjb) for MFC without 3-day wait Changes: _U stable/12/ stable/12/sys/arm/ti/ti_sdhci.c stable/12/sys/dev/sdhci/sdhci.c
A commit references this bug: Author: ian Date: Thu Oct 17 01:30:37 UTC 2019 New revision: 353675 URL: https://svnweb.freebsd.org/changeset/base/353675 Log: MFC r353651-r353652 r353651: Relax the sdhci(4) check that filters out the 1.8v voltage option unless the slot is flagged as 'embedded'. The features related to embedded and shared slots were added in v3.0 of the sdhci spec. Hardware prior to v3 sometimes supported 1.8v on non- removable devices in embedded systems, but had no way to indicate that via the standard sdhci registers (instead they use out of band metadata such as FDT data). This change adds the controller specification version to the check for whether to filter out the 1.8v selection. On older hardware, the 1.8v option is allowed to remain. On 3.0 or later it still requires the embedded-slot flag to remain. This is part of the fix for PR 241301 (eMMC not detected on Beaglebone). Changes to the sdhci_ti driver are also needed for a full fix. PR: 241301 r353652: Revert r351218 (by manu). While the changes in r351218 appear to be (and should be) correct, they lead to the eMMC on a Beaglebone failing to work in some situations. The TI sdhci hardware is kind of strange. The first device inherently supports 1.8v and 3.3v and the abililty to switch between them, and the other two devices must be set to 1.8v in the sdhci power control register to operate correctly, but doing so actually makes them run at 3.3v (unless an external level-shifter is present in the signal path). Even the 1.8v on the first device may actually be 3.3v (or any other value), depending on what voltage is fed to the VDDS1-VDDS7 power supply pins on the am335x chip. Another strange quirk is that the convention for am335x sdhci drivers in linux and uboot and the am335x boot ROM seems to be to set the voltage in the sdhci capabilities register to 3.0v even though the actual voltage is 3.3v. Why this is done is a complete mystery to me, but it seems to be required for correct operation. If we had complete modern support for the am335x chip we could get the actual voltages from the FDT data and the regulator framework. But our am335x code currently doesn't have any regulator framework support. Reverting to the prior code will get the popular Beaglebone boards working again. This is part of the fix for PR 241301, but also requires r353651 for a complete fix. PR: 241301 Discussed with: manu Approved by: re(gjb) for MFC without 3-day wait Changes: _U stable/12/ stable/12/sys/arm/ti/ti_sdhci.c stable/12/sys/dev/sdhci/sdhci.c
A commit references this bug: Author: ian Date: Thu Oct 17 16:20:24 UTC 2019 New revision: 353684 URL: https://svnweb.freebsd.org/changeset/base/353684 Log: MFC r353675 from stable-12 (r353651-r353652 from head)... r353651: Relax the sdhci(4) check that filters out the 1.8v voltage option unless the slot is flagged as 'embedded'. The features related to embedded and shared slots were added in v3.0 of the sdhci spec. Hardware prior to v3 sometimes supported 1.8v on non- removable devices in embedded systems, but had no way to indicate that via the standard sdhci registers (instead they use out of band metadata such as FDT data). This change adds the controller specification version to the check for whether to filter out the 1.8v selection. On older hardware, the 1.8v option is allowed to remain. On 3.0 or later it still requires the embedded-slot flag to remain. This is part of the fix for PR 241301 (eMMC not detected on Beaglebone). Changes to the sdhci_ti driver are also needed for a full fix. PR: 241301 r353652: Revert r351218 (by manu). While the changes in r351218 appear to be (and should be) correct, they lead to the eMMC on a Beaglebone failing to work in some situations. The TI sdhci hardware is kind of strange. The first device inherently supports 1.8v and 3.3v and the abililty to switch between them, and the other two devices must be set to 1.8v in the sdhci power control register to operate correctly, but doing so actually makes them run at 3.3v (unless an external level-shifter is present in the signal path). Even the 1.8v on the first device may actually be 3.3v (or any other value), depending on what voltage is fed to the VDDS1-VDDS7 power supply pins on the am335x chip. Another strange quirk is that the convention for am335x sdhci drivers in linux and uboot and the am335x boot ROM seems to be to set the voltage in the sdhci capabilities register to 3.0v even though the actual voltage is 3.3v. Why this is done is a complete mystery to me, but it seems to be required for correct operation. If we had complete modern support for the am335x chip we could get the actual voltages from the FDT data and the regulator framework. But our am335x code currently doesn't have any regulator framework support. Reverting to the prior code will get the popular Beaglebone boards working again. This is part of the fix for PR 241301, but also requires r353651 for a complete fix. PR: 241301 Discussed with: manu Approved by: re(kib) Changes: _U releng/12.1/ releng/12.1/sys/arm/ti/ti_sdhci.c releng/12.1/sys/dev/sdhci/sdhci.c