Date: Sun, 27 Apr 2014 12:52:39 -0600 From: Ian Lepore <ian@FreeBSD.org> To: Winston Smith <smith.winston.101@gmail.com> Cc: FreeBSD ARM <freebsd-arm@FreeBSD.org> Subject: Re: FreeBSD-10-STABLE hangs when booting from BeagleBone Black eMMC Message-ID: <1398624759.61646.174.camel@revolution.hippie.lan> In-Reply-To: <CADH-AwE%2B5=A4aiqbTYqor1Any1JGNhz4LHOJwfyykYU92UpirQ@mail.gmail.com> References: <CADH-AwHvaVqycykONkzRsj7oD3xSi8hszvc_Wf4obC=Y_qPiaQ@mail.gmail.com> <1398618984.61646.165.camel@revolution.hippie.lan> <CADH-AwE%2B5=A4aiqbTYqor1Any1JGNhz4LHOJwfyykYU92UpirQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2014-04-27 at 13:43 -0400, Winston Smith wrote: > On Sun, Apr 27, 2014 at 1:16 PM, Ian Lepore <ian@freebsd.org> wrote: > > I only have a BBW, no BBB to play with, so I can't help too much with > > this. I can say however that if you're having trouble with reading the > > eMMC in ubldr, the trouble is probably in u-boot. U-boot is still in > > memory when ubldr is running, and it serves as a kind of mini-bios, > > providing access to console, disk, and network IO. > > > > I heard a rumor a while back that Patrick Kelsey had some patches for > > u-boot to fix problems with probing for disk devices. It may be that > > they were only needed for older versions of u-boot, I'm not sure. > > I do have Patrick's fixes for u-boot. Interestingly, the same u-boot > (2013.4 + Patrick's patches) works with 11-CURRENT but not 10-STABLE > -- that's booting from eMMC, there are no issues booting from SD; also > once booted from SD, there is no issues mounting the eMMC and > accessing it (well ... aside from lock reversal warnings and the > occasional sdhc timeout). > > Is there a way to debug this? > Just ignore the LORs, or even better, turn off WITNESS. IMO, it has become useless, because nobody fixes them anymore, or even responds to reports of them other than to sometimes post a link to a site that tracks "known LORs", but that site hasn't been updated for like 6 years. Note that this is just my personal opinion, not the position of the freebsd project in general. When it comes to the eMMC timeouts that happen after you've booted, that's something in my arena, but hard for me to debug without eMMC hardware. We've recently had a few changes to both the core sdhci driver and to the ti_sdhci code that glues sdhci to the hardware. Do the timeouts happen often, or is this something you can do to trigger them? If so, it might be interesting to try to revert r264099 and see if the problems go away. Those changes were related to configuring the sd clock. I'm pretty sure the old code was wrong, but the replacement code could have errors too. :) -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1398624759.61646.174.camel>