Date: Thu, 22 May 2014 08:27:46 -0600 From: Ian Lepore <ian@FreeBSD.org> To: SAITOU Toshihide <toshi@ruby.ocn.ne.jp> Cc: freebsd-arm@FreeBSD.org Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) Message-ID: <1400768866.1152.231.camel@revolution.hippie.lan> In-Reply-To: <20140522.231553.186386229.toshi@ruby.ocn.ne.jp> References: <CADH-AwGb36EUknNofdch1Q4Pn8GAN%2BEp9SdiJ_f7Q2v9e4kW1g@mail.gmail.com> <20140522.204656.144162099.toshi@ruby.ocn.ne.jp> <1400765234.1152.224.camel@revolution.hippie.lan> <20140522.231553.186386229.toshi@ruby.ocn.ne.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2014-05-22 at 23:15 +0900, SAITOU Toshihide wrote: > In message: <1400765234.1152.224.camel@revolution.hippie.lan> > Ian Lepore <ian@FreeBSD.org> writes: > > On Thu, 2014-05-22 at 20:46 +0900, SAITOU Toshihide wrote: > >> In message: <CADH-AwGb36EUknNofdch1Q4Pn8GAN+Ep9SdiJ_f7Q2v9e4kW1g@mail.gmail.com> > >> Winston Smith <smith.winston.101@gmail.com> writes: > >> > On Wed, May 21, 2014 at 11:20 AM, SAITOU Toshihide <toshi@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1400768866.1152.231.camel>