Issue using BB-BONE-eMMC1 overlay

[MarcDorval]

Hi,

I'm trying to activate a second SDIO connection on the P8 Header to test some in-house HW.

I'm stuck at the stage where I'm trying to add the BB-BONE-eMMC1 overlay to /sys/devices/platform/bone_capemgr/slots.

I experimented adding another (randomly selected) which I can find under /lib/firmware/, then checking the process using 'dmesg': debian@arm:/etc/init.d$ sudo sh -c "echo 'BB-UART1' > /sys/devices/platform/bone_capemgr/slots" debian@arm:/etc/init.d$ sudo cat /sys/devices/platform/bone_capemgr/slots 0: PF---- -1 1: PF---- -1 2: PF---- -1 3: PF---- -1 9: P-O-L- 0 Override Board Name,00A0,Override Manuf,BB-BONE-BACONE 18: P-O-L- 1 Override Board Name,00A0,Override Manuf,BB-UART1 debian@arm:/etc/init.d$ dmesg [ 3357.065970] bone_capemgr bone_capemgr: part_number 'BB-UART1', version 'N/A' [ 3357.073315] bone_capemgr bone_capemgr: slot #18: override [ 3357.083113] bone_capemgr bone_capemgr: Using override eeprom data at slot 18 [ 3357.092748] bone_capemgr bone_capemgr: slot #18: 'Override Board Name,00A0,Override Manuf,BB-UART1' [ 3357.118427] 48022000.serial: ttyS1 at MMIO 0x48022000 (irq = 188, base_baud = 3000000) is a 8250 [ 3357.138683] bone_capemgr bone_capemgr: slot #18: dtbo 'BB-UART1-00A0.dtbo' loaded; overlay id #1

Now, when I do the same with BB-BONE-EMMC1 it fails:

debian@arm:/etc/init.d$ sudo sh -c "echo 'BB-BONE-eMMC1' > /sys/devices/platform/bone_capemgr/slots" sh: echo: I/O error debian@arm:/etc/init.d$ dmesg [ 3924.210823] bone_capemgr bone_capemgr: part_number 'BB-BONE-eMMC1', version 'N/A' [ 3924.218735] bone_capemgr bone_capemgr: slot #20: override [ 3924.229681] bone_capemgr bone_capemgr: Using override eeprom data at slot 20 [ 3924.242892] bone_capemgr bone_capemgr: slot #20: 'Override Board Name,00A0,Override Manuf,BB-BONE-eMMC1'

Any idea? Thanks for any help you can provide,

MarcDorval

[RobertCNelson]

@MarcDorval due to race issues with mmc/dma in v4.1.x+, BB-BONE-eMMC1 can not be loaded via kernel overlays, you must use U-Boot overlays for mmc/sdio devices:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays

Regards,

[MarcDorval]

Thanks, Robert. I'm gonna have a look at that today. One side question: Where is the source for the BB-BONE-eMMC1.dts file? Best regards, Marc

[RobertCNelson]

Well the source of that file is in the repo of this issue tracker ;)

https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-BONE-eMMC1-01-00A0.dts

Regards,

[MarcDorval]

@RobertCNelson Thanks again, Robert, it helped me find my way.

Can you please confirm that the following is correct (I think I got it, but I like when things are crystal clear)? The next step for me will then be to enable this overlay. I'll go for holidays first, if you don't mind. Best regards, and thanks for the hints.

My understanding of the mmc devicetree control:

Under /sys/firmware/devicetree/base/ocp there are 3 'mmc' items: mmc@47810000 mmc@48060000 mmc@481d8000 Each one corresponds to a separate MMC Host controller block in the HW. There are 3 identical HW blocks in the 335x.

Under each of the corresponding /sys/firmware/devicetree/base/ocp/mmc* folders there is a ti,hwmods 'file' whose content is: mmc@47810000\ti,hwmods mmc3 mmc@48060000\ti,hwmods mmc1 mmc@481d8000\ti,hwmods mmc2

The 'hw target' to use (in the fragment@1 of the dts) for each of the above are: mmc@47810000 target = <&mmc3> mmc@48060000 target = <&mmc1> mmc@481d8000 target = <&mmc2>

fragment@1 { 
    target = <&mmc2>; 
    __overlay__ { 
        vmmc-supply = <&vmmcsd_fixed>; 
        pinctrl-names = "default"; 
        pinctrl-0 = <&emmc_pins>; 
        bus-width = <8>; 
        status = "okay"; 
    }; 
}; 

so in this case, since we're using <&mmc2> we'll use the mmc@481d8000 HW. Fair enough, the only mmc HW whose 'status' reads 'okay' is initially mmc@48060000, i.e. mmc1. (mmc1 is the one used to communicate with the SD card under the PCB)

In the fragment@0 of the dts you control the am33xx_pinmux HW to route the pins you need from the ARM to the headers. Each line uses the pinctrl-single driver to set one pin at a time. The syntax uses the pin offset then a combination of the I/O mode and the MUX mode for the pin. (one can use a mix up of mux_modes, 'mux_mode' is on a pin-per-pin level)

fragment@0 { 
    target = <&am33xx_pinmux>; 
    __overlay__ { 
        emmc_pins: pinmux_emmc_pins { 
            pinctrl-single,pins = < 
                AM33XX_IOPAD(0x880, PIN_INPUT_PULLUP | MUX_MODE2) /* gpmc_csn1.mmc1_clk */ 
      . . .
            >; 
        }; 
    }; 
}; 

At the beginning of the dts you can select which pins will be used in the 'exclusive-use' list: exclusive-use = / the pin header uses / "P8.21", / mmc1: mmc1_clk / "P8.20", / mmc1: mmc1_cmd / "P8.25", / mmc1: mmc1_dat0 / "P8.24", / mmc1: mmc1_dat1 / "P8.5", / mmc1: mmc1_dat2 / "P8.6", / mmc1: mmc1_dat3 / "P8.23", / mmc1: mmc1_dat4 / "P8.22", / mmc1: mmc1_dat5 / "P8.3", / mmc1: mmc1_dat6 / "P8.4", / mmc1: mmc1_dat7 / / the hardware IP uses / "mmc1";

In this 'exclusive-use' part we also see "mmc1", so it's consistent with the selected mmc HW and the 'target' in fragment@1. Things appear in good order, I like that.

[MarcDorval]

@RobertCNelson; When you wrote about race conditions above, is it related to mmc only, or more general with kernel >4.1 when using any overlay?

NB: I recompiled kernel 4.4.59-bone-rt-r17. Maybe I should have used the '-ti-' branch...

The reason I'm asking is that twice in a row I attempted to enable uboot overlays and crashed my beaglebone. To do that I removed the '#' in front of the enable_uboot_overlays=1 in /boot/uEnv.txt enable_uboot_overlays=1

As soon as I reboot following this change I can't connect to my beaglebone. I just see all 4 leds popping up once, then going off and nothing more. No heartbeat... No Putty connection anymore.

This is a pain since my system is running Windows 10 and the USB to network gadget is not working on Win10. I have to revert to an old Win 7 PC to check now...

Any idea? I will probably test with the 'Manually Loading Capes' option next time...

Best regards, Marc

[RobertCNelson]

@MarcDorval

yeah the bone v4.4.x branches aren't working with u-boot overlays this week: (v4.9.x-bone, v4.4.x-ti or v4.9.x-ti are working fine)

https://github.com/RobertCNelson/bb-kernel/issues/42#issuecomment-293320582

The dtc are exactly the same, just pulling hair out on that one...

Regards,

[MarcDorval]

@RobertCNelson Good to know... Just poor timing (The beaglebone I have has been sitting in a drawer for 4 years, just working on it in the past 10 days). Hopefully you'll get it sorted out when I get back, otherwise I will switch to another branch. No way I can pull hair anymore (none left) ...

Regards,