BBB & IMX6 Hummingboard SDIO driver

Russell Haley russ.haley at gmail.com
Thu Jul 20 23:08:33 UTC 2017


On Thu, Jul 20, 2017 at 1:56 AM, Ilya Bakulin <ilya at bakulin.de> wrote:
> On 2017-07-19 05:19, Russell Haley wrote:
>>
>> Current Status:
>>
>> Building and Installing - BBB
>> - Either the information about building a Beaglebone has fallen out of
>> date, or the beaglebone black has different requirements that should
>> be documented on that page. Boot pieces:
>> - MLO
>> -u-boot.img
>> -ubldr.bin
>>
>> - The kernel I built yesterday panics during load due to a sleep lock
>> that has already been identified by kibab (aka Ilya). I will attempt
>> to patch it tomorrow.
>
>
> I'm not sure what problem are you talking about. The patch on Phabricator
> tries to address a problem that there are several sleep() calls
> used in the MMC/SD probe code.
> This code shouldn't sleep. So I'm trying to get rid of sleeps,
> but the patch I've generated so far doesn't work -- this is just a starting
> point.
> So if the version from -HEAD panics at boot -- this is a bug and I need
> to address it. I haven't booted BBB in ages and will have sufficient time
> to debug the problem myself in two weeks (during DevSummit in Cambridge).
In an effort to eliminate as many of MY errors as possible, I copied a
BB snapshot image from July 17. Once that successfully booted and I
had an ip address and written an echo to file, I replaced the kernel
with a BEAGLEBONE-MMCCAM kernel. I did not see the same results as I
did with my own image built using an older revision, so I am
discarding my kernel panic for now. The snapshot with a
BEAGELBONE-MMCCAM kernel (r321242) doesn't panic, but it fails to
mount the second slice on mmcsd0s2. My complete "lots of freakin
output" (you weren't kidding) is here: https://pastebin.com/CrWYPZtv

For completeness sake I created a standard BEAGELBONE kernel and
installed it and everything booted fine.

Cheers,

Russ

>> Source Code
>> The following is my examination of the code I can identify as
>> involving the new MMCCAM stack. I am reading first to understand how
>> the pieces fit and then will get into the details.
>>
>>  - All mmccam functions for BBB sd cards is run through the sdhci
>> driver in /sys/dev/sdhci/sdhci.c which is extended by
>> arm/ti/ti_sdhci.c. When a custom kernel configuration is used, the
>> MMCCAM flag is specified and the MMCCAM specific code is compiled into
>> /sys/dev/sdhci/sdhci.c and .h.
>
> Yes, that's right.
>
>>  - There seems to be a implementation specific startup routine
>> compiled into the arm/ti/ti_sdhci.c using an ifdef. There is also a
>> custom read and write defined so I assume there is some board specific
>> things that need adjusting. Need to look closer
>
> Yes, initialization function for MMCCAM is different.
> Also there is #ifdef'ed code in write_1 and read_1 because I need to adjust
> a 8-bit enable bit when writing to SDHC control register.
> Old stack did it in ios handling, but MMCCAM doesn't allow device drivers
> to have their own ios handling.
>
>>  - sdhci code paths seem to directly use the cam_ccb and cam_sim
>> rather than call any mmc specific code. It seems the sdhci uses the
>> cam bus but not the mmc_sdio code, nore the cam_xpt_* code.
>
> This is correct -- every CAM request/response is routed by the CAM
> subsystem.
>
>> - Note: in /sys/dev/sdhci/sdhci.c the includes on lines 51 through 55
>> are duplicated in an ifdef MMCCAM at lines 1979 through 1985. Is that
>> intentional?
>
> No, this should be corrected. Thanks!
>
>>
>> cam/mmc
>> - mmc_sdio seems to be it's own thing. It includes both the
>> cam_sim/cam_ccb and the cam_xpt_* headers but I don't know yet if it
>> uses both sets of functionality (code is still opaque to me).
>
> This code is not used yet since there is no SDIO-specific code for now.
>>
>>
>> Okay, back at it tomorrow. Ilya, Warner, if you're around at all I'd
>> love to get a state of the union from you.
>
>
> Replying to your question on IRC wrt communication protocol: I don't
> frequently
> monitor all FreeBSD mailing lists and can easily miss SDIO-related stuff
> unless I'm directly CC'ed.
> I have a highlight setup for the #bsdmips IRC channel that notifies me
> when SDIO or my nickname is mentioned, so I will know someone was talking
> about these things.
>
> I'm in Munich (timezone is CEST), so reply times might be longer for
> US-based folk.
> --
> Mit freundlichen Grüßen,
> Ilya Bakulin


More information about the freebsd-arm mailing list