Bug 238344 - sysutils/u-boot-beaglebone : eMMC access is broken
Summary: sysutils/u-boot-beaglebone : eMMC access is broken
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: arm Any
: --- Affects Many People
Assignee: freebsd-uboot (Nobody)
Depends on:
Reported: 2019-06-05 16:57 UTC by Sergey Manucharian
Modified: 2019-10-16 15:53 UTC (History)
8 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Sergey Manucharian 2019-06-05 16:57:16 UTC
This commit:

replaced "am335x_boneblack_defconfig" with "am335x_evm_defconfig".

The latter has an option which wasn't in the former:

which brakes access to eMMC:
sdhci_ti1-slot0: Controller timeout
sdhci_ti1-slot0: ============== REGISTER DUMP ==============
sdhci_ti1-slot0: Sys addr: 0x00000000 | Version:  0x00003101
sdhci_ti1-slot0: Blk size: 0x00000000 | Blk cnt:  0x00000000
sdhci_ti1-slot0: Argument: 0x00000000 | Trn mode: 0x00000102
sdhci_ti1-slot0: Present:  0x01f70000 | Host ctl: 0x00000000
sdhci_ti1-slot0: Power:    0x00000000 | Blk gap:  0x00000000
sdhci_ti1-slot0: Wake-up:  0x00000000 | Clock:    0x00008007
sdhci_ti1-slot0: Timeout:  0x00000000 | Int stat: 0x00000000
sdhci_ti1-slot0: Int enab: 0x017f00fb | Sig enab: 0x017f00fb
sdhci_ti1-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000
sdhci_ti1-slot0: Caps:     0x04e10080 | Caps2:    0x00000000
sdhci_ti1-slot0: Max curr: 0x00000000 | ADMA err: 0x00000000
sdhci_ti1-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000
sdhci_ti1-slot0: ===========================================

The boot process is delayed, and the corresponding devices /dev/mmcsd1* are missing.

Replacing that option with 

fixes the issue. I didn't dig deep enough to find the root cause.
Comment 1 Bugzilla Automation freebsd_committer 2019-06-05 16:57:16 UTC
Maintainer informed via mail
Comment 2 Denis Polygalov 2019-07-14 09:02:55 UTC
FYI this bug renders following images useless:


and therefore cause averse reaction in new people
who like FreeBSD on big PCs and trying to get 
into FreeBSD+ARM world which already desperately 
lacking developers and users.
Comment 3 Poul-Henning Kamp freebsd_committer 2019-09-22 09:31:18 UTC
This issue still seems to be present in

Comment 4 Emmanuel Vadot freebsd_committer 2019-09-22 12:39:24 UTC
This should have been fixed with https://svnweb.freebsd.org/ports?view=revision&revision=512180
Also this doesn't affect old release as the u-boot image was built back then and the release image do not change after being built.
Comment 5 Poul-Henning Kamp freebsd_committer 2019-09-22 15:46:18 UTC
Will this fix be merged in time for 12.1 ?
Comment 6 Emmanuel Vadot freebsd_committer 2019-09-25 07:31:29 UTC
12.1 switched to quarterly packages when it was branched (20 september) but my commit to the ports tree is only in head.
2019Q4 will be created in a few days and 12.1 will then use it so it will be ok then.
Comment 7 Emmanuel Vadot freebsd_committer 2019-09-25 08:12:06 UTC
I was wrong, 12.1 uses head for building the image so 12.1-BETA1 uses my latest u-boot patch and can boot from sd or eMMC and eMMC works in both cases.
Comment 8 Poul-Henning Kamp freebsd_committer 2019-09-30 07:16:57 UTC
I tried the 


snapshot, and that still has this bug ?
Comment 9 Mike Karels freebsd_committer 2019-10-15 00:17:44 UTC
12.1-RC1 still has the bug.
Comment 10 bsd 2019-10-16 10:31:25 UTC
I've just got new BeagleBoneBlack and verified FreeBSD-13.0-CURRENT-arm-armv7-BEAGLEBONE-20191011-r353427.img is still buggy w. r. t. eMMC detection.

Freshly svn'upped ports tree, built sysutils/u-boot-beaglebone port and replacing files in FAT partition on uSD card brings no change.

After playing with sysutils/u-boot-beaglebone port a bit I found simple solution for this problem - adding line CONFIG_DM_MMC=y into files/bbb_fragment file and rebuilding port gave me working eMMC and enabled me to install FreeBSD there.
Comment 11 Emmanuel Vadot freebsd_committer 2019-10-16 13:56:22 UTC
(In reply to bsd from comment #10)

I don't see how it can change something as CONFIG_DM_MMC is already set.
manu@skull> pwd
manu@skull> make configure
manu@skull> grep CONFIG_DM_MMC work/u-boot-2019.10/.config 
Comment 12 Ian Lepore freebsd_committer 2019-10-16 15:50:51 UTC
It turns out the problems reported by comment 8 and the followups have the same symptom (sdhci_ti1 controller timeout) but a different cause.  A new bug 241301 has been opened to track it.
Comment 13 bsd 2019-10-16 15:53:57 UTC
(In reply to Emmanuel Vadot from comment #11)

Sorry, this was copy-and-paste error, added line is