BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz)

[Ian Lepore]

On Thu, 2014-05-22 at 23:15 +0900, SAITOU Toshihide wrote:
> In message: <1400765234.1152.224.camel at revolution.hippie.lan>
>             Ian Lepore <ian at FreeBSD.org> writes:
> > On Thu, 2014-05-22 at 20:46 +0900, SAITOU Toshihide wrote:
> >> In message: <CADH-AwGb36EUknNofdch1Q4Pn8GAN+Ep9SdiJ_f7Q2v9e4kW1g at mail.gmail.com>
> >>             Winston Smith <smith.winston.101 at gmail.com> writes:
> >> > On Wed, May 21, 2014 at 11:20 AM, SAITOU Toshihide <toshi at ruby.ocn.ne.jp> wrote:
> >> >> If abort like
> >> >>
> >> >>   musbotg0: TI AM335X USBSS v0.0.13
> >> >>   Fatal kernel mode data abort: 'External Non-Linefetch Abort (S)'
> >> >>   trapframe: 0xc0a2eb60
> >> > 
> >> > I see this with the 1Ghz uboot, it occurs about 50% of the time, see:
> >> > 
> >> > http://comments.gmane.org/gmane.os.freebsd.devel.arm/8200
> >> 
> >> Although it is an ad hoc workaround but ``usb start'' at u-boot command
> >> prompt (someone mentioned before) or add device_printf("!\n") before
> >> ``rev = USBSS_READ4(sc, USBSS_REVREG);'' in the musbotg_attach of
> >> am335x_usbss.c prevent this panic for me.
> > 
> > An 'external non-linefetch abort' on a TI chip usually means that the
> > clocks for a device never got turned on and you attempted to read or
> > write a register in that device.  If 'usb start' makes the problem go
> > away, that tends to confirm that thought.
> > 
> > The thing is, I don't understand why adding a printf to the code with no
> > other changes would help in any way.  I though maybe it was adding some
> > delay to allow the clock-start call to take effect, but the clock enable
> > call is after the USBSS_REVREG read, and that seems wrong.
> > 
> > Does it fix the problem to move the ti_prcm_clk_enable() call to be
> > before the USBSS_REVREG read in attach?
> 
> I will try ti_prcm_clk_enable() at the weekend. But someone's report
> would be appriciated because I remove the src and svn up now.
> 

If you have done svn up -rnnnnn on individual files, I think svn will
then leave those files at that revision when you do future updates.
Doing 'svn revert -R .' in the src directory should get everything reset
so that 'svn up' will pull the latest versions of everything again.  Of
course, it will also revert *every* change you've made under src, so use
it carefully!  It should be faster than checking out a fresh copy, and
you can still do a -DNO_CLEAN build and rebuild just the things that
have changed.  Of course you can also use svn revert on a single file or
directory too.

-- Ian