From owner-freebsd-arm@FreeBSD.ORG Thu Nov 7 07:20:01 2013 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E28C2E25 for ; Thu, 7 Nov 2013 07:20:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C074A2084 for ; Thu, 7 Nov 2013 07:20:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rA77K1nW028532 for ; Thu, 7 Nov 2013 07:20:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rA77K15R028531; Thu, 7 Nov 2013 07:20:01 GMT (envelope-from gnats) Date: Thu, 7 Nov 2013 07:20:01 GMT Message-Id: <201311070720.rA77K15R028531@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org Cc: From: Ganbold Tsagaankhuu Subject: Re: arm/183740: mutex on some arm hardware requires dcache enabled X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Ganbold Tsagaankhuu List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 07:20:02 -0000 The following reply was made to PR arm/183740; it has been noted by GNATS. From: Ganbold Tsagaankhuu To: John Wehle Cc: freebsd-gnats-submit@freebsd.org Subject: Re: arm/183740: mutex on some arm hardware requires dcache enabled Date: Thu, 7 Nov 2013 15:17:23 +0800 --001a11c1feb69c14b604ea910ed6 Content-Type: text/plain; charset=ISO-8859-1 John, On Thu, Nov 7, 2013 at 3:07 PM, John Wehle wrote: > > >Number: 183740 > >Category: arm > >Synopsis: mutex on some arm hardware requires dcache enabled > >Confidential: no > >Severity: non-critical > >Priority: low > >Responsible: freebsd-arm > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Thu Nov 07 07:10:00 UTC 2013 > >Closed-Date: > >Last-Modified: > >Originator: John Wehle > >Release: FreeBSD svn 257205 > >Organization: > Personal > >Environment: > Not Yet > >Description: > In my spare time I'm working on bringing FreeBSD up on amlogic based > arm processors. While working through various bootstrap issues I got > to the point where initarm calls pmap_bootstrap only to have it splat. > > What happens is pmap_bootstrap calls pmap_extract which does > PMAP_LOCK(pmap). > This trys to acquire a mutex which invokes atomics that use ldrex / strex. > > The ARM documentation at: > > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0464d/CHDIBJGE.html > > notes that the L1 memory system has an internal exclusive monitor which > handles ldrex / strex accesses. > > The README at: > > https://github.com/dwelch67/raspberrypi/tree/master/extest > > has a nice write up which explains some of the wrinkles regarding hardware > and ldrex / strex. > > The attached patch enables the dcache and suffices to get me through > initarm into mi_startup (I'm not to a console login yet ... however > I'm significantly further along). > > -- John > > >How-To-Repeat: > > >Fix: > Enable the dcache prior to using a mutex. > > Patch attached with submission follows: > > --- sys/arm/arm/machdep.c.ORIGINAL 2013-10-27 01:15:39.000000000 -0400 > +++ sys/arm/arm/machdep.c 2013-11-07 01:43:01.000000000 -0500 > @@ -1481,6 +1483,12 @@ initarm(struct arm_boot_params *abp) > */ > cpu_idcache_wbinv_all(); > > + /* > + * Atomics invoked by mutex use ldrex / strex which on some > + * hardware requires the L1 cache. > + */ > + cpu_control(CPU_CONTROL_DC_ENABLE, CPU_CONTROL_DC_ENABLE); > + > /* Set stack for exception handlers */ > data_abort_handler_address = (u_int)data_abort_handler; > prefetch_abort_handler_address = (u_int)prefetch_abort_handler; > > What kind of Amlogic board you are working on? That could be interesting. As for the patch can you try to put it in initarm_late_init() of your board machdep code and try? I meant like in /usr/src/sys/arm/rockchip/rk30xx_machdep.c Please let us know. thanks, Ganbold > > >Release-Note: > >Audit-Trail: > >Unformatted: > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > --001a11c1feb69c14b604ea910ed6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
John,


On Thu, Nov 7, 2013 at 3:07 PM, John Wehle <<= a href=3D"mailto:john@feith.com" target=3D"_blank">john@feith.com> wrote:

>Number: =A0 =A0 =A0 =A0 183740
>Category: =A0 =A0 =A0 arm
>Synopsis: =A0 =A0 =A0 mutex on some arm hardware requires dcache enable= d
>Confidential: =A0 no
>Severity: =A0 =A0 =A0 non-critical
>Priority: =A0 =A0 =A0 low
>Responsible: =A0 =A0freebsd-arm
>State: =A0 =A0 =A0 =A0 =A0open
>Quarter:
>Keywords:
>Date-Required:
>Class: =A0 =A0 =A0 =A0 =A0sw-bug
>Submitter-Id: =A0 current-users
>Arrival-Date: =A0 Thu Nov 07 07:10:00 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator: =A0 =A0 John Wehle
>Release: =A0 =A0 =A0 =A0FreeBSD svn 257205
>Organization:
Personal
>Environment:
Not Yet
>Description:
In my spare time I'm working on bringing FreeBSD up on amlogic based arm processors. =A0While working through various bootstrap issues I got
to the point where initarm calls pmap_bootstrap only to have it splat.

What happens is pmap_bootstrap calls pmap_extract which does PMAP_LOCK(pmap= ).
This trys to acquire a mutex which invokes atomics that use ldrex / strex.<= br>
The ARM documentation at:

=A0 http://infocenter.arm.com/help/= index.jsp?topic=3D/com.arm.doc.ddi0464d/CHDIBJGE.html

notes that the L1 memory system has an internal exclusive monitor which
handles ldrex / strex accesses.

The README at:

=A0 https://github.com/dwelch67/raspberrypi/tree/master/extes= t

has a nice write up which explains some of the wrinkles regarding hardware<= br> and ldrex / strex.

The attached patch enables the dcache and suffices to get me through
initarm into mi_startup (I'm not to a console login yet ... however
I'm significantly further along).

-- John

>How-To-Repeat:

>Fix:
Enable the dcache prior to using a mutex.

Patch attached with submission follows:

--- sys/arm/arm/machdep.c.ORIGINAL =A0 =A0 =A02013-10-27 01:15:39.000000000= -0400
+++ sys/arm/arm/machdep.c =A0 =A0 =A0 2013-11-07 01:43:01.000000000 -0500 @@ -1481,6 +1483,12 @@ initarm(struct arm_boot_params *abp)
=A0 =A0 =A0 =A0 =A0*/
=A0 =A0 =A0 =A0 cpu_idcache_wbinv_all();

+ =A0 =A0 =A0 /*
+ =A0 =A0 =A0 =A0* Atomics invoked by mutex use ldrex / strex which on some=
+ =A0 =A0 =A0 =A0* hardware requires the L1 cache.
+ =A0 =A0 =A0 =A0*/
+ =A0 =A0 =A0 cpu_control(CPU_CONTROL_DC_ENABLE, CPU_CONTROL_DC_ENABLE); +
=A0 =A0 =A0 =A0 /* Set stack for exception handlers */
=A0 =A0 =A0 =A0 data_abort_handler_address =3D (u_int)data_abort_handler; =A0 =A0 =A0 =A0 prefetch_abort_handler_address =3D (u_int)prefetch_abort_ha= ndler;


What kind of Amlogic board you are wor= king on? That could be interesting.

As for the pat= ch can you try to put it in initarm_late_init() of your board machdep code = and try?
I meant like in /usr/src/sys/arm/rockchip/rk30xx_machdep.c
P= lease let us know.

thanks,

Ganbold

=A0

>Release-Note:
>Audit-Trail:
>Unformatted:
_______________________________________________
freebsd-arm@freebsd.org mail= ing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"

--001a11c1feb69c14b604ea910ed6--