Date: Thu, 20 Jul 2017 16:08:30 -0700 From: Russell Haley <russ.haley@gmail.com> To: Ilya Bakulin <ilya@bakulin.de> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: BBB & IMX6 Hummingboard SDIO driver Message-ID: <CABx9NuRuC5xfgG2%2Bm4kq3fA90afJnd07ehcdAwrKnsqZv8R6dg@mail.gmail.com> In-Reply-To: <703c195298dd3bbbd3abd53603758f14@bakulin.de> References: <CABx9NuR-ahQ3-PF2DV_6zAzMdFKhkyCt0b8%2BcyQ1KDBcaYHU=g@mail.gmail.com> <CABx9NuS89JcgzMkO0tq8gLFP64Rt3R-y3esaXHGu0%2BdW9XSU9A@mail.gmail.com> <703c195298dd3bbbd3abd53603758f14@bakulin.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 20, 2017 at 1:56 AM, Ilya Bakulin <ilya@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 starti= ng > 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 adju= st > 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=C3=BC=C3=9Fen, > Ilya Bakulin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABx9NuRuC5xfgG2%2Bm4kq3fA90afJnd07ehcdAwrKnsqZv8R6dg>