Date: Sat, 24 May 2014 20:08:37 +0900 (JST) From: SAITOU Toshihide <toshi@ruby.ocn.ne.jp> To: ian@FreeBSD.org Cc: freebsd-arm@FreeBSD.org Subject: Re: BBB MMC / SD detection instability with U-Boot 2014.04 (CPU 1GHz) Message-ID: <20140524.200837.142870524.toshi@ruby.ocn.ne.jp> In-Reply-To: <1400768866.1152.231.camel@revolution.hippie.lan> References: <1400765234.1152.224.camel@revolution.hippie.lan> <20140522.231553.186386229.toshi@ruby.ocn.ne.jp> <1400768866.1152.231.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <1400768866.1152.231.camel@revolution.hippie.lan>
Ian Lepore <ian@FreeBSD.org> writes:
> 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.
Thankyou for your infomation, I could revert back and svn up.
But after that I lost .svn repository accidentally, so I can't tell
a revision number (about ~two days before I think) for this report
sorry. Anyway I will never do that.
BEAGLEBONE config is changed to include beaglebone-black.dts, boot
from SD by pressing S2, repeat power cycle and hit enter key randomly
when ``Hit [Enter] to boot immediately''.
result:
'external non-linefetch abort' was disappeared, and very few
'translation fault' was observed.
vm_fault(0xc092d960, 0, 1, 0) -> 1
Fatal kernel mode data abort: 'Translation Fault (S)'
trapframe: 0xc0a26b30
FSR=00000005, FAR=00000018, spsr=80000193
r0 =c288d380, r1 =00000000, r2 =00000019, r3 =60000193
r4 =00000000, r5 =c288d380, r6 =00000006, r7 =c053e8fc
r8 =c288d380, r9 =c28e928c, r10=c28e70c8, r11=c0a26b90
r12=00000000, ssp=c0a26b80, slr=c055fedc, pc =c0391098
[ thread pid 0 tid 100000 ]
Stopped at device_delete_child+0x14: ldr r1, [r4, #0x018]
It maybe that the test has lost the meagning but tried.
without change: 3 error / 20 trial
with change: 1 error / 20 trial
I think operation bias exist from halfway through because the error
disappear against my expectation (it's a happy thing though).
--
SAITOU Toshihide
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140524.200837.142870524.toshi>