From owner-freebsd-arm@FreeBSD.ORG Mon Dec 12 10:10:46 2011 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C0051065675 for ; Mon, 12 Dec 2011 10:10:46 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 002CB8FC1B for ; Mon, 12 Dec 2011 10:10:45 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id B6E0AEC2FF; Mon, 12 Dec 2011 10:52:13 +0100 (CET) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id ofJhB5NknfVR; Mon, 12 Dec 2011 10:52:13 +0100 (CET) Received: from [10.0.0.79] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 45089EC2F6; Mon, 12 Dec 2011 10:52:13 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Rafal Jaworowski In-Reply-To: <20194.24585.409976.445767@gromit.timing.com> Date: Mon, 12 Dec 2011 10:52:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <35E122E0-BE99-4757-A76A-C6E559EDB231@semihalf.com> References: <20194.24585.409976.445767@gromit.timing.com> To: John Hein X-Mailer: Apple Mail (2.1084) Cc: arm@freebsd.org Subject: Re: quick summary of arm families on freebsd X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 10:10:46 -0000 On 2011-12-09, at 20:22, John Hein wrote: > What's the status of new arm families (e.g., ARMv6/7) on freebsd? > Pointers to svn or p4 are fine. Particular interest at the moment on > Cortex A8 (e.g., on many of the TI ARMs). There's work in progress on ARMv6 / v7 in SVN, see project "armv6", = http://svn.freebsd.org/base/projects/armv6/. The immediate platforms = supported are Marvell PJ4 CPUs, but the code has been initially brought = up also on Cortex-A9 (Panda), though I'm not sure if anyone is actively = working on A8 adaptations. Rafal From owner-freebsd-arm@FreeBSD.ORG Mon Dec 12 11:07:18 2011 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE9E01065670 for ; Mon, 12 Dec 2011 11:07:18 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id ACB958FC1F for ; Mon, 12 Dec 2011 11:07:18 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pBCB7I4B029944 for ; Mon, 12 Dec 2011 11:07:18 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pBCB7IkF029942 for freebsd-arm@FreeBSD.org; Mon, 12 Dec 2011 11:07:18 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 12 Dec 2011 11:07:18 GMT Message-Id: <201112121107.pBCB7IkF029942@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arm@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 11:07:18 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/162159 arm [panic] USB errors leading to panic on DockStar 9.0-RC o arm/161110 arm /usr/src/sys/arm/include/signal.h is bad o arm/161044 arm devel/icu does not build on arm o arm/160431 arm [patch] Disable interrupts during busdma cache sync op o arm/158950 arm arm/sheevaplug fails fsx when mmap operations are enab o arm/156814 arm OpenRD Ultimate does not boot on DB-88F6XXX or SHEEVAP o arm/156496 arm [patch] Minor bugfixes and enhancements to mmc and mmc o arm/155894 arm [patch] Enable at91 booting from SDHC (high capacity) o arm/155214 arm [patch] MMC/SD IO slow on Atmel ARM with modern large o arm/154227 arm [geli] using GELI leads to panic on ARM o arm/154189 arm lang/perl5.12 doesn't build on arm o arm/153380 arm Panic / translation fault with wlan on ARM o arm/150581 arm [irq] Unknown error generates IRQ address decoding err o arm/149288 arm mail/dovecot causes panic during configure on Sheevapl o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 p arm/134338 arm [patch] Lock GPIO accesses on ixp425 16 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Dec 12 22:10:11 2011 Return-Path: Delivered-To: freebsd-arm@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83BCE106566B for ; Mon, 12 Dec 2011 22:10:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 595AB8FC0C for ; Mon, 12 Dec 2011 22:10:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pBCMABUu040685 for ; Mon, 12 Dec 2011 22:10:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pBCMABe3040684; Mon, 12 Dec 2011 22:10:11 GMT (envelope-from gnats) Date: Mon, 12 Dec 2011 22:10:11 GMT Message-Id: <201112122210.pBCMABe3040684@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org From: Naoyuki Tai Cc: Subject: Re: arm/154189: lang/perl5.12 doesn't build on arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Naoyuki Tai List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 22:10:11 -0000 The following reply was made to PR arm/154189; it has been noted by GNATS. From: Naoyuki Tai To: bug-followup@FreeBSD.org, kvedulv@kvedulv.de Cc: Subject: Re: arm/154189: lang/perl5.12 doesn't build on arm Date: Mon, 12 Dec 2011 16:30:40 -0500 This should be resolved by arm/161128. -- Tai From owner-freebsd-arm@FreeBSD.ORG Wed Dec 14 20:24:24 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99932106567C for ; Wed, 14 Dec 2011 20:24:24 +0000 (UTC) (envelope-from mail.vibi@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5E8DA8FC08 for ; Wed, 14 Dec 2011 20:24:23 +0000 (UTC) Received: by yhfq46 with SMTP id q46so2064482yhf.13 for ; Wed, 14 Dec 2011 12:24:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=KxCQ+YeSNqce64bcO7GzxUgxBYgUv/+Jy0wetuc4a8s=; b=AYX0jRRUmEicQpQ37bEAy+crCkEiQFJHvkma/TnT1zN2/HzbIpIeWS6PlosqlNobnM gzgv+Zdzmhj1/blwwLsyPm02MYCq3QYX0R4OfffZZXZmBrWA581AyxZcwM29KFCIKc6F 5wJbwXY8Buwq4HsZ1haPJ9RVNfcVQ8tBHzYIo= MIME-Version: 1.0 Received: by 10.236.79.38 with SMTP id h26mr112486yhe.39.1323892543377; Wed, 14 Dec 2011 11:55:43 -0800 (PST) Received: by 10.236.51.162 with HTTP; Wed, 14 Dec 2011 11:55:43 -0800 (PST) Date: Thu, 15 Dec 2011 01:25:43 +0530 Message-ID: From: vibi sreenivasan To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: best version of freebsd to start working on arm architecture X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 20:24:24 -0000 Hi, Can anyone please tell me which version of free bsd (8.2 / 9.0 - rc3) is suitable for working with arm architecture ? Porting Freebsd to an arm based soc(OMAPL138) is my final aim. So prior to that i would like to test building & compiling kernel for some available arch. Please Help. Thanks & Regards vibi From owner-freebsd-arm@FreeBSD.ORG Fri Dec 16 12:15:59 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90B12106566B for ; Fri, 16 Dec 2011 12:15:59 +0000 (UTC) (envelope-from ben.r.gray@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 21DF58FC15 for ; Fri, 16 Dec 2011 12:15:58 +0000 (UTC) Received: by wgbdr11 with SMTP id dr11so5964354wgb.31 for ; Fri, 16 Dec 2011 04:15:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=uool7MILecCJMmw+hW673VKbfQ3/INZJvHfFVWshFQo=; b=bVyAj6D2VuOYQRh7xoktcUr7ajhf2twrCtCMRg+cguTSGTQ8Kv++sWITgcShVQasfe YR87hYaSEJ9Vt4zv2XwTHpx9nUsGeEh35xQwjr283BSaFnVytbPFUtt/S5ZP81hvXMGQ edzOnFf+U8KcfuCq3PSfqI+MiWIJLo+I3mBuw= Received: by 10.227.197.147 with SMTP id ek19mr5363682wbb.3.1324036236089; Fri, 16 Dec 2011 03:50:36 -0800 (PST) Received: from Bens-MBP.local (ip-80-238-8-128.bskyb.com. [80.238.8.128]) by mx.google.com with ESMTPS id hb10sm12742476wib.16.2011.12.16.03.50.34 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Dec 2011 03:50:35 -0800 (PST) Message-ID: <4EEB3089.5090000@gmail.com> Date: Fri, 16 Dec 2011 11:50:33 +0000 From: Ben Gray User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org References: <20111130193458.GA57881@ci0.org> In-Reply-To: <20111130193458.GA57881@ci0.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: OMAP4 and FreeBSD X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 12:15:59 -0000 Hi Alex, Sorry to revive an old thread, but just to let you know I think I've fixed the MMC problem Olivier mentioned and the change has been committed to the gitorious page. I am still working on the OMAP stuff albeit very sporadically. For now I'm pushing my changes into gitorous, but I'm hoping it will go into a proper FreeBSD svn repo/branch sometime in the future (thanks Olivier :)). For what it's worth, there is still plenty to do on the OMAP3/4 port, I think the basics work ok (MMC, DMA, USB, L2-Cache, IIC, ETH, PWIC). The key things that are missing are SMP support and the graphics, both of which I'm hoping to work on in the new year when I think I'll have a few weeks free time between contracts. Thanks, Ben. > On Wed, Nov 30, 2011 at 08:29:43PM +0200, Alex T. wrote: >> Good day guys, >> >> I have a question regarding OMAP4 support in FreeBSD. I have pandaboard and >> I would >> like to help to port FreeBSD to OMAP4. Could you suggest the right place to >> start from? >> I have found a note on the web about some work being done on this and that >> there are >> something is available at google code done by Ben Gray (+ repo on >> gitorious). On the >> other hand a have seen a note that ArabBSD project is doing this. Is there >> a united point >> where all their achievements are collected? Or do they work in parallel and >> independently? >> > Hi Alex, > > The central point should probably be the armv6 branch in svn. I took Ben's > code, and merged it with the armv6 code (though it's not committed it, as it's > not in a committable shape yet, I can certainly put it online somewhere if > you're interested). I remember seeing the ArabBSD folks saying they would like > to work on it as well, but never found any public repository. > So far, I can netboot to multiuser (but no SMP yet), so the USB stuff works, > but that's about it. Ben wrote code for the MMC stuff, but it is not working > yet, last time I had a look at it, I was trying to figure out why. > If you're interested in working on it, you're more than welcome ;) > > Regards, > > Olivier > _______________________________________________ > 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" From owner-freebsd-arm@FreeBSD.ORG Fri Dec 16 14:38:27 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A401F106564A for ; Fri, 16 Dec 2011 14:38:27 +0000 (UTC) (envelope-from marktinguely@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 625598FC0A for ; Fri, 16 Dec 2011 14:38:27 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so4274211vcb.13 for ; Fri, 16 Dec 2011 06:38:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cpuRtwguP+AjRPPqWUo9zp0F2S53pLhgs70sk5egnC0=; b=JlvXKMXHUu5k3ZwgoK16BnOYD41UESIRCp1HXdrNLI0icqfqdVEYwTX7me9skU1pM6 oN/Db+0Bti0z8VqBpyqBjLxDiIpSlRG59uctlbCjG6UAxuPn2Y5iG3Gcq5nXtjhYxVYI T5laW0pvWXrbzutFEIyAJ+b/iX5D0Eg57TJ9g= MIME-Version: 1.0 Received: by 10.220.151.137 with SMTP id c9mr3172515vcw.37.1324044683881; Fri, 16 Dec 2011 06:11:23 -0800 (PST) Received: by 10.220.66.72 with HTTP; Fri, 16 Dec 2011 06:11:23 -0800 (PST) In-Reply-To: <4EEB3089.5090000@gmail.com> References: <20111130193458.GA57881@ci0.org> <4EEB3089.5090000@gmail.com> Date: Fri, 16 Dec 2011 08:11:23 -0600 Message-ID: From: Mark Tinguely To: Ben Gray Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm@freebsd.org Subject: Re: OMAP4 and FreeBSD X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 14:38:27 -0000 Please forgive this being a partial side topic. As a side question, what is the status of the Clang cross compiling. I am getting more serious about an experimental ARM implementation using the new ARMv7 features to move us toward ARMv8 changes. I added Damjan to the email because he compiled (world?) using Clang. I remember something about ABI differences and there were some Clang path patches. Thank-you, --Mark Tinguely From owner-freebsd-arm@FreeBSD.ORG Fri Dec 16 14:45:12 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57A2C106564A for ; Fri, 16 Dec 2011 14:45:12 +0000 (UTC) (envelope-from damjan.marion@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id DA9838FC0A for ; Fri, 16 Dec 2011 14:45:11 +0000 (UTC) Received: by wgbdr11 with SMTP id dr11so6199346wgb.31 for ; Fri, 16 Dec 2011 06:45:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=KOMS0B/Y/FZPz8zFJLI4/dXnp7a5MA/h5oDYS572E6c=; b=SvUIDr4GWzeruxo8MJ3Krr6unG42+62wRnJZwCcajxyxwt6/KFkPiNzkWZvmwLm1KQ vu6bWIulP5UGbzqFFkYjgf9J8S4RrX3pDOzPezb8yyrlgeRnes7Y8/XQ06ir3luxbJkT 4uKz4/WPw8Cg1jUSDAhcHsw5L7Z3DFSZ3Fmus= Received: by 10.227.199.16 with SMTP id eq16mr5738172wbb.26.1324045318341; Fri, 16 Dec 2011 06:21:58 -0800 (PST) Received: from [192.168.123.4] (cpe-109-60-82-215.zg3.cable.xnet.hr. [109.60.82.215]) by mx.google.com with ESMTPS id eg7sm13290173wib.8.2011.12.16.06.21.56 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Dec 2011 06:21:57 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Damjan Marion In-Reply-To: Date: Fri, 16 Dec 2011 15:21:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111130193458.GA57881@ci0.org> <4EEB3089.5090000@gmail.com> To: Mark Tinguely X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-arm@freebsd.org Subject: Re: OMAP4 and FreeBSD X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 14:45:12 -0000 On Dec 16, 2011, at 3:11 PM, Mark Tinguely wrote: > Please forgive this being a partial side topic. >=20 > As a side question, what is the status of the Clang cross compiling. I > am getting more serious about an experimental ARM implementation using > the new ARMv7 features to move us toward ARMv8 changes. >=20 > I added Damjan to the email because he compiled (world?) using Clang. > I remember something about ABI differences and there were some Clang > path patches. Main issue is that clang doesn't support ATPCS which FreeBSD is using on = arm. Andrew made some efforts on moving kernel to AAPCS but it is still not = complete. Look at projects/arm_eabi in SVN. Regards, Damjan= From owner-freebsd-arm@FreeBSD.ORG Fri Dec 16 20:13:36 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 759301065670 for ; Fri, 16 Dec 2011 20:13:36 +0000 (UTC) (envelope-from dioxinu@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 313598FC12 for ; Fri, 16 Dec 2011 20:13:35 +0000 (UTC) Received: by qcse13 with SMTP id e13so3075240qcs.13 for ; Fri, 16 Dec 2011 12:13:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ttyZhTrjvPW3asz9UgLDv+HtQVowcFfo0Hp5Qu2nmC0=; b=rERn107v/mQ6vJJcVeZoWsHEbuEaJTd5GCmTPHU735umbB1ifzBWYrS+55akjyVLA+ PYmnajnY6pMrtv59g0WdoHDNv/yL4/KrNYJnkpQjQqJzyL9YtLlVuoG66/J9J7Pie2CX Lbq4IuSrFp45wlmpFEf6VhaN6bqUEW7RnhRS8= MIME-Version: 1.0 Received: by 10.229.134.197 with SMTP id k5mr2154310qct.58.1324066415497; Fri, 16 Dec 2011 12:13:35 -0800 (PST) Received: by 10.229.99.130 with HTTP; Fri, 16 Dec 2011 12:13:35 -0800 (PST) In-Reply-To: <4EEB3089.5090000@gmail.com> References: <20111130193458.GA57881@ci0.org> <4EEB3089.5090000@gmail.com> Date: Fri, 16 Dec 2011 22:13:35 +0200 Message-ID: From: "Alex T." To: Ben Gray Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-arm@freebsd.org Subject: Re: OMAP4 and FreeBSD X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 20:13:36 -0000 Hi Ben, guys, and everyone, On 16 December 2011 13:50, Ben Gray wrote: > Hi Alex, > > Sorry to revive an old thread, but just to let you know I think I've > fixed the MMC problem Olivier mentioned and the change has been committed > to the gitorious page. > Yep, git pulled your changes not so long ago:) I am still working on the OMAP stuff albeit very sporadically. For now > I'm pushing my changes into gitorous, but I'm hoping it will go into a > proper FreeBSD svn repo/branch sometime in the future (thanks Olivier :)). > I have cloned the gitoriuos repo and switched to your branch and also checked out armv6 SVN repository. > For what it's worth, there is still plenty to do on the OMAP3/4 port, I > think the basics work ok (MMC, DMA, USB, L2-Cache, IIC, ETH, PWIC). The key > things that are missing are SMP support and the graphics, both of which I'm > hoping to work on in the new year when I think I'll have a few weeks free > time between contracts. > I also hope I have more time to spend with FreeBSD on pandaboard. At this point I'm sort of trying to get to know what is going on and how it works. My current issue is that booting on my pandaboard unfortunately freezes at ## Transferring control to NetBSD stage-2 loader (at address 802000e0) ... I haven't solved this yet. Do you have a task list or something like this? @Damjan, I just wanted to make sure I undestood you correctly. You suggest to stick with gcc for now when it comes to compiling kernel/world? From owner-freebsd-arm@FreeBSD.ORG Sat Dec 17 14:19:00 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8AB4106564A for ; Sat, 17 Dec 2011 14:19:00 +0000 (UTC) (envelope-from matthieu.kraus@s2008.tu-chemnitz.de) Received: from nick.hrz.tu-chemnitz.de (nick.hrz.tu-chemnitz.de [134.109.228.11]) by mx1.freebsd.org (Postfix) with ESMTP id 056FC8FC0C for ; Sat, 17 Dec 2011 14:18:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tu-chemnitz.de; s=dkim2010; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:To:From:Date:Message-ID; bh=HVYYSIW8toc6iGZS9C4FA9vhzqnIZBbHStH/BF27I1A=; b=AtfYl4SB1AZbRNGJQUrjw85NNzG/EKrH+IMGnl/cXAjsEVutpT7rya22oOhK03sxI7iU0qtAYBJHES3VfZ6Jil0Dpvd0DRHCo42cy02uBy8OL9kdBsIpH/TRpQUJb0fOzpWwKYnhC+DKj3bFyibyO2x0GpibbeuAI+vB3BGL7KY=; Received: from postman.hrz.tu-chemnitz.de ([134.109.133.5] helo=mailbox.hrz.tu-chemnitz.de) by nick.hrz.tu-chemnitz.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1Rbv6I-0008S0-DN for freebsd-arm@freebsd.org; Sat, 17 Dec 2011 15:18:58 +0100 Received: from boogie.hrz.tu-chemnitz.de ([134.109.133.10] helo=localhost) by mailbox.hrz.tu-chemnitz.de with esmtp (Exim 4.76) (envelope-from ) id 1Rbv6I-0001Ib-AE for freebsd-arm@freebsd.org; Sat, 17 Dec 2011 15:18:58 +0100 Received: from 77-64-128-141.dynamic.primacom.net (77-64-128-141.dynamic.primacom.net [77.64.128.141]) by mail.tu-chemnitz.de (Horde Framework) with HTTP; Sat, 17 Dec 2011 15:18:58 +0100 Message-ID: <20111217151858.182523ch5m4bclw2@mail.tu-chemnitz.de> Date: Sat, 17 Dec 2011 15:18:58 +0100 From: Matthieu Kraus To: freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_bx6zcmqegq" Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) X-Originating-IP: 77.64.128.141 X-Scan-Signature: 85a6381b2609643a7b742c04e9a5b8b9 Subject: cesa patch issues X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2011 14:19:00 -0000 This message is in MIME format. --=_bx6zcmqegq Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit Greetings, as I had issues getting CESA as it is working for bigger requests (as those issued by geli) because it either fails to complete the requeusts at all or (after increasing SA and TDMA pools quite a bit) suffers from bad performance I tried to rework it to go with the flow suggested in the functional spec, i.e. preparing the data in regular buffers and upon enqueueing filling out the TDMA/SA descriptors. (see attached patch) However I can't seem to get my modifications to work as I always get: vm_fault(0xc35789c8, 0, 2, 0) -> 1 Fatal kernel mode data abort: 'Translation Fault (P)' trapframe: 0xd2069bb0 FSR=00000017, FAR=00000010, spsr=80000013 r0 =0000001f, r1 =00000000, r2 =00000000, r3 =00000004 r4 =00000000, r5 =00000000, r6 =00000000, r7 =c373d898 r8 =c3736000, r9 =00000000, r10=c3736000, r11=d2069c38 r12=00000000, ssp=d2069bfc, slr=c0c02f40, pc =c0c22d58 [ thread pid 1439 tid 100057 ] Stopped at cpu_initclocks+0x3340: str r4, [r3, #0x00c] I'm completely new to kernel development, so any hints on how to further debug the issue (traces in ddb didn't seem very informational to me) would be highly appreciated. kind regards, Matthieu Kraus --=_bx6zcmqegq Content-Type: text/plain; charset=ISO-8859-1; name="cesa-patch.txt" Content-Disposition: attachment; filename="cesa-patch.txt" Content-Transfer-Encoding: 7bit Index: sys/dev/cesa/cesa.h =================================================================== --- sys/dev/cesa/cesa.h (revision 228127) +++ sys/dev/cesa/cesa.h (working copy) @@ -61,11 +61,11 @@ */ /* Values below are optimized for requests containing about 1.5 kB of data */ -#define CESA_SA_DESC_PER_REQ 2 -#define CESA_TDMA_DESC_PER_REQ 8 +#define CESA_PACKETS_PER_REQ 2 +#define CESA_TDMAS_PER_PACKET 4 -#define CESA_SA_DESCRIPTORS (CESA_SA_DESC_PER_REQ * CESA_REQUESTS) -#define CESA_TDMA_DESCRIPTORS (CESA_TDMA_DESC_PER_REQ * CESA_REQUESTS) +#define CESA_SA_DESCRIPTORS (CESA_PACKETS_PER_REQ * CESA_REQUESTS) +#define CESA_TDMA_DESCRIPTORS ((CESA_PACKETS_PER_REQ*CESA_TDMAS_PER_PACKET+2) * CESA_REQUESTS) /* Useful constants */ #define CESA_HMAC_HASH_LENGTH 12 @@ -99,9 +99,7 @@ bus_space_write_4((sc)->sc_bst, (sc)->sc_bsh, (reg), (val)) /* Generic allocator for objects */ -#define CESA_GENERIC_ALLOC_LOCKED(sc, obj, pool) do { \ - CESA_LOCK(sc, pool); \ - \ +#define CESA_GENERIC_ALLOC(sc, obj, pool) do { \ if (STAILQ_EMPTY(&(sc)->sc_free_ ## pool)) \ obj = NULL; \ else { \ @@ -109,14 +107,23 @@ STAILQ_REMOVE_HEAD(&(sc)->sc_free_ ## pool, \ obj ## _stq); \ } \ - \ +} while(0) + +#define CESA_GENERIC_FREE(sc, obj, pool) do { \ + STAILQ_INSERT_TAIL(&(sc)->sc_free_ ## pool, obj, \ + obj ## _stq); \ +} while (0) + +/* Generic locked allocator for objects */ +#define CESA_GENERIC_ALLOC_LOCKED(sc, obj, pool) do { \ + CESA_LOCK(sc, pool); \ + CESA_GENERIC_ALLOC(sc, obj, pool); \ CESA_UNLOCK(sc, pool); \ } while (0) #define CESA_GENERIC_FREE_LOCKED(sc, obj, pool) do { \ CESA_LOCK(sc, pool); \ - STAILQ_INSERT_TAIL(&(sc)->sc_free_ ## pool, obj, \ - obj ## _stq); \ + CESA_GENERIC_FREE(sc, obj, pool); \ CESA_UNLOCK(sc, pool); \ } while (0) @@ -194,29 +201,40 @@ STAILQ_ENTRY(cesa_session) cs_stq; }; +struct cesa_packet { + uint32_t cp_data; + uint16_t cp_size; + + uint32_t cp_config; + uint16_t cp_enc_src; + uint16_t cp_enc_dst; + uint32_t cp_enc_dlen; + uint16_t cp_mac_src; + uint16_t cp_mac_total_dlen; + uint16_t cp_mac_dlen; + + STAILQ_ENTRY(cesa_packet) cp_stq; +}; + struct cesa_request { - struct cesa_sa_data *cr_csd; - bus_addr_t cr_csd_paddr; struct cryptop *cr_crp; struct cryptodesc *cr_enc; struct cryptodesc *cr_mac; struct cesa_session *cr_cs; + bus_dmamap_t cr_dmap; int cr_dmap_loaded; - STAILQ_HEAD(, cesa_tdma_desc) cr_tdesc; + struct cesa_sa_data *cr_csd; + bus_addr_t cr_csd_paddr; + + unsigned int cr_processing; + STAILQ_HEAD(, cesa_packet) cr_packets; STAILQ_HEAD(, cesa_sa_desc) cr_sdesc; STAILQ_ENTRY(cesa_request) cr_stq; }; -struct cesa_packet { - STAILQ_HEAD(, cesa_tdma_desc) cp_copyin; - STAILQ_HEAD(, cesa_tdma_desc) cp_copyout; - unsigned int cp_size; - unsigned int cp_offset; -}; - struct cesa_softc { device_t sc_dev; int32_t sc_cid; @@ -230,12 +248,12 @@ struct mtx sc_sc_lock; int sc_blocked; + int sc_busy; /* TDMA descriptors pool */ - struct mtx sc_tdesc_lock; struct cesa_tdma_desc sc_tdesc[CESA_TDMA_DESCRIPTORS]; struct cesa_dma_mem sc_tdesc_cdm; - STAILQ_HEAD(, cesa_tdma_desc) sc_free_tdesc; + unsigned int sc_tdesc_curr; /* SA descriptors pool */ struct mtx sc_sdesc_lock; @@ -263,9 +281,16 @@ struct cesa_chain_info { struct cesa_softc *cci_sc; struct cesa_request *cci_cr; + struct cryptodesc *cci_enc; struct cryptodesc *cci_mac; + uint32_t cci_config; + + unsigned int cci_mmask; + unsigned int cci_emask; + unsigned int cci_mpsize; + int cci_error; }; Index: sys/dev/cesa/cesa.c =================================================================== --- sys/dev/cesa/cesa.c (revision 228127) +++ sys/dev/cesa/cesa.c (working copy) @@ -71,7 +71,7 @@ #include #include "cesa.h" -#undef DEBUG +static MALLOC_DEFINE(M_CESA, "cesa packet data", "CESA packet data"); static int cesa_probe(device_t); static int cesa_attach(device_t); @@ -112,30 +112,6 @@ MODULE_DEPEND(cesa, crypto, 1, 1, 1); static void -cesa_dump_cshd(struct cesa_softc *sc, struct cesa_sa_hdesc *cshd) -{ -#ifdef DEBUG - device_t dev; - - dev = sc->sc_dev; - device_printf(dev, "CESA SA Hardware Descriptor:\n"); - device_printf(dev, "\t\tconfig: 0x%08X\n", cshd->cshd_config); - device_printf(dev, "\t\te_src: 0x%08X\n", cshd->cshd_enc_src); - device_printf(dev, "\t\te_dst: 0x%08X\n", cshd->cshd_enc_dst); - device_printf(dev, "\t\te_dlen: 0x%08X\n", cshd->cshd_enc_dlen); - device_printf(dev, "\t\te_key: 0x%08X\n", cshd->cshd_enc_key); - device_printf(dev, "\t\te_iv_1: 0x%08X\n", cshd->cshd_enc_iv); - device_printf(dev, "\t\te_iv_2: 0x%08X\n", cshd->cshd_enc_iv_buf); - device_printf(dev, "\t\tm_src: 0x%08X\n", cshd->cshd_mac_src); - device_printf(dev, "\t\tm_dst: 0x%08X\n", cshd->cshd_mac_dst); - device_printf(dev, "\t\tm_dlen: 0x%08X\n", cshd->cshd_mac_dlen); - device_printf(dev, "\t\tm_tlen: 0x%08X\n", cshd->cshd_mac_total_dlen); - device_printf(dev, "\t\tm_iv_i: 0x%08X\n", cshd->cshd_mac_iv_in); - device_printf(dev, "\t\tm_iv_o: 0x%08X\n", cshd->cshd_mac_iv_out); -#endif -} - -static void cesa_alloc_dma_mem_cb(void *arg, bus_dma_segment_t *segs, int nseg, int error) { struct cesa_dma_mem *cdm; @@ -220,15 +196,6 @@ bus_dmamap_sync(cdm->cdm_tag, cdm->cdm_map, op); } -static void -cesa_sync_desc(struct cesa_softc *sc, bus_dmasync_op_t op) -{ - - cesa_sync_dma_mem(&sc->sc_tdesc_cdm, op); - cesa_sync_dma_mem(&sc->sc_sdesc_cdm, op); - cesa_sync_dma_mem(&sc->sc_requests_cdm, op); -} - static struct cesa_session * cesa_alloc_session(struct cesa_softc *sc) { @@ -252,7 +219,6 @@ static void cesa_free_session(struct cesa_softc *sc, struct cesa_session *cs) { - CESA_GENERIC_FREE_LOCKED(sc, cs, sessions); } @@ -265,8 +231,9 @@ if (!cr) return (NULL); - STAILQ_INIT(&cr->cr_tdesc); STAILQ_INIT(&cr->cr_sdesc); + STAILQ_INIT(&cr->cr_packets); + cr->cr_processing = 0; return (cr); } @@ -274,16 +241,14 @@ static void cesa_free_request(struct cesa_softc *sc, struct cesa_request *cr) { + struct cesa_packet *cp, *tmp; - /* Free TDMA descriptors assigned to this request */ - CESA_LOCK(sc, tdesc); - STAILQ_CONCAT(&sc->sc_free_tdesc, &cr->cr_tdesc); - CESA_UNLOCK(sc, tdesc); + CESA_LOCK(sc, sdesc); + STAILQ_CONCAT(&sc->sc_free_sdesc, &cr->cr_sdesc); + CESA_UNLOCK(sc, sdesc); - /* Free SA descriptors assigned to this request */ - CESA_LOCK(sc, sdesc); - STAILQ_CONCAT(&sc->sc_free_sdesc, &cr->cr_sdesc); - CESA_UNLOCK(sc, sdesc); + STAILQ_FOREACH_SAFE(cp, &cr->cr_packets, cp_stq, tmp) + free(cp, M_CESA); /* Unload DMA memory asociated with request */ if (cr->cr_dmap_loaded) { @@ -303,60 +268,10 @@ CESA_UNLOCK(sc, requests); } -static struct cesa_tdma_desc * -cesa_alloc_tdesc(struct cesa_softc *sc) -{ - struct cesa_tdma_desc *ctd; - - CESA_GENERIC_ALLOC_LOCKED(sc, ctd, tdesc); - - if (!ctd) - device_printf(sc->sc_dev, "TDMA descriptors pool exhaused. " - "Consider increasing CESA_TDMA_DESCRIPTORS.\n"); - - return (ctd); -} - -static struct cesa_sa_desc * -cesa_alloc_sdesc(struct cesa_softc *sc, struct cesa_request *cr) -{ - struct cesa_sa_desc *csd; - - CESA_GENERIC_ALLOC_LOCKED(sc, csd, sdesc); - if (!csd) { - device_printf(sc->sc_dev, "SA descriptors pool exhaused. " - "Consider increasing CESA_SA_DESCRIPTORS.\n"); - return (NULL); - } - - STAILQ_INSERT_TAIL(&cr->cr_sdesc, csd, csd_stq); - - /* Fill-in SA descriptor with default values */ - csd->csd_cshd->cshd_enc_key = CESA_SA_DATA(csd_key); - csd->csd_cshd->cshd_enc_iv = CESA_SA_DATA(csd_iv); - csd->csd_cshd->cshd_enc_iv_buf = CESA_SA_DATA(csd_iv); - csd->csd_cshd->cshd_enc_src = 0; - csd->csd_cshd->cshd_enc_dst = 0; - csd->csd_cshd->cshd_enc_dlen = 0; - csd->csd_cshd->cshd_mac_dst = CESA_SA_DATA(csd_hash); - csd->csd_cshd->cshd_mac_iv_in = CESA_SA_DATA(csd_hiv_in); - csd->csd_cshd->cshd_mac_iv_out = CESA_SA_DATA(csd_hiv_out); - csd->csd_cshd->cshd_mac_src = 0; - csd->csd_cshd->cshd_mac_dlen = 0; - - return (csd); -} - -static struct cesa_tdma_desc * -cesa_tdma_copy(struct cesa_softc *sc, bus_addr_t dst, bus_addr_t src, +static void +cesa_tdma_copy(struct cesa_tdma_desc *ctd, bus_addr_t dst, bus_addr_t src, bus_size_t size) { - struct cesa_tdma_desc *ctd; - - ctd = cesa_alloc_tdesc(sc); - if (!ctd) - return (NULL); - ctd->ctd_cthd->cthd_dst = dst; ctd->ctd_cthd->cthd_src = src; ctd->ctd_cthd->cthd_byte_count = size; @@ -366,83 +281,9 @@ ctd->ctd_cthd->cthd_flags = CESA_CTHD_OWNED; else ctd->ctd_cthd->cthd_flags = 0; - - return (ctd); } -static struct cesa_tdma_desc * -cesa_tdma_copyin_sa_data(struct cesa_softc *sc, struct cesa_request *cr) -{ - - return (cesa_tdma_copy(sc, sc->sc_sram_base + - sizeof(struct cesa_sa_hdesc), cr->cr_csd_paddr, - sizeof(struct cesa_sa_data))); -} - -static struct cesa_tdma_desc * -cesa_tdma_copyout_sa_data(struct cesa_softc *sc, struct cesa_request *cr) -{ - - return (cesa_tdma_copy(sc, cr->cr_csd_paddr, sc->sc_sram_base + - sizeof(struct cesa_sa_hdesc), sizeof(struct cesa_sa_data))); -} - -static struct cesa_tdma_desc * -cesa_tdma_copy_sdesc(struct cesa_softc *sc, struct cesa_sa_desc *csd) -{ - - return (cesa_tdma_copy(sc, sc->sc_sram_base, csd->csd_cshd_paddr, - sizeof(struct cesa_sa_hdesc))); -} - -static void -cesa_append_tdesc(struct cesa_request *cr, struct cesa_tdma_desc *ctd) -{ - struct cesa_tdma_desc *ctd_prev; - - if (!STAILQ_EMPTY(&cr->cr_tdesc)) { - ctd_prev = STAILQ_LAST(&cr->cr_tdesc, cesa_tdma_desc, ctd_stq); - ctd_prev->ctd_cthd->cthd_next = ctd->ctd_cthd_paddr; - } - - ctd->ctd_cthd->cthd_next = 0; - STAILQ_INSERT_TAIL(&cr->cr_tdesc, ctd, ctd_stq); -} - static int -cesa_append_packet(struct cesa_softc *sc, struct cesa_request *cr, - struct cesa_packet *cp, struct cesa_sa_desc *csd) -{ - struct cesa_tdma_desc *ctd, *tmp; - - /* Copy SA descriptor for this packet */ - ctd = cesa_tdma_copy_sdesc(sc, csd); - if (!ctd) - return (ENOMEM); - - cesa_append_tdesc(cr, ctd); - - /* Copy data to be processed */ - STAILQ_FOREACH_SAFE(ctd, &cp->cp_copyin, ctd_stq, tmp) - cesa_append_tdesc(cr, ctd); - STAILQ_INIT(&cp->cp_copyin); - - /* Insert control descriptor */ - ctd = cesa_tdma_copy(sc, 0, 0, 0); - if (!ctd) - return (ENOMEM); - - cesa_append_tdesc(cr, ctd); - - /* Copy back results */ - STAILQ_FOREACH_SAFE(ctd, &cp->cp_copyout, ctd_stq, tmp) - cesa_append_tdesc(cr, ctd); - STAILQ_INIT(&cp->cp_copyout); - - return (0); -} - -static int cesa_set_mkey(struct cesa_session *cs, int alg, const uint8_t *mkey, int mklen) { uint8_t ipad[CESA_MAX_HMAC_BLOCK_LEN]; @@ -547,63 +388,19 @@ } static void -cesa_start_packet(struct cesa_packet *cp, unsigned int size) -{ - - cp->cp_size = size; - cp->cp_offset = 0; - STAILQ_INIT(&cp->cp_copyin); - STAILQ_INIT(&cp->cp_copyout); -} - -static int -cesa_fill_packet(struct cesa_softc *sc, struct cesa_packet *cp, - bus_dma_segment_t *seg) -{ - struct cesa_tdma_desc *ctd; - unsigned int bsize; - - /* Calculate size of block copy */ - bsize = MIN(seg->ds_len, cp->cp_size - cp->cp_offset); - - if (bsize > 0) { - ctd = cesa_tdma_copy(sc, sc->sc_sram_base + - CESA_DATA(cp->cp_offset), seg->ds_addr, bsize); - if (!ctd) - return (-ENOMEM); - - STAILQ_INSERT_TAIL(&cp->cp_copyin, ctd, ctd_stq); - - ctd = cesa_tdma_copy(sc, seg->ds_addr, sc->sc_sram_base + - CESA_DATA(cp->cp_offset), bsize); - if (!ctd) - return (-ENOMEM); - - STAILQ_INSERT_TAIL(&cp->cp_copyout, ctd, ctd_stq); - - seg->ds_len -= bsize; - seg->ds_addr += bsize; - cp->cp_offset += bsize; - } - - return (bsize); -} - -static void cesa_create_chain_cb(void *arg, bus_dma_segment_t *segs, int nseg, int error) { - unsigned int mpsize, fragmented; - unsigned int mlen, mskip, tmlen; struct cesa_chain_info *cci; unsigned int elen, eskip; - unsigned int skip, len; - struct cesa_sa_desc *csd; + unsigned int mlen, mskip, tmlen; + unsigned int skip, len, fragmented; + unsigned int size; + bus_dma_segment_t seg; + struct cesa_request *cr; struct cesa_softc *sc; - struct cesa_packet cp; - bus_dma_segment_t seg; + struct cesa_packet* cp; uint32_t config; - int size; cci = arg; sc = cci->cci_sc; @@ -620,8 +417,8 @@ mskip = cci->cci_mac ? cci->cci_mac->crd_skip : 0; if (elen && mlen && - ((eskip > mskip && ((eskip - mskip) & (cr->cr_cs->cs_ivlen - 1))) || - (mskip > eskip && ((mskip - eskip) & (cr->cr_cs->cs_mblen - 1))) || + ((eskip > mskip && ((eskip - mskip) & cci->cci_emask)) || + (mskip > eskip && ((mskip - eskip) & cci->cci_mmask)) || (eskip > (mskip + mlen)) || (mskip > (eskip + elen)))) { /* * Data alignment in the request does not meet CESA requiremnts @@ -661,23 +458,23 @@ tmlen = mlen; fragmented = 0; - mpsize = CESA_MAX_PACKET_SIZE; - mpsize &= ~((cr->cr_cs->cs_ivlen - 1) | (cr->cr_cs->cs_mblen - 1)); if (elen && mlen) { skip = MIN(eskip, mskip); len = MAX(elen + eskip, mlen + mskip) - skip; + + eskip -= skip; + mskip -= skip; } else if (elen) { skip = eskip; len = elen; + eskip = 0; } else { skip = mskip; len = mlen; + mskip = 0; } - /* Start first packet in chain */ - cesa_start_packet(&cp, MIN(mpsize, len)); - while (nseg-- && len > 0) { seg = *(segs++); @@ -691,105 +488,71 @@ seg.ds_addr += size; seg.ds_len -= size; + } - if (eskip > 0) - eskip -= size; + /* + * Create packet and fill with data from DMA segment + * until there is no more data in current DMA segment + * or an error occured. + */ + while (seg.ds_len > 0) { + cp = malloc(sizeof(struct cesa_packet), M_CESA, M_WAITOK); - if (mskip > 0) - mskip -= size; + cp->cp_size = MIN(seg.ds_len, MIN(cci->cci_mpsize, len)); + cp->cp_data = seg.ds_addr; - if (seg.ds_len == 0) - continue; - } + seg.ds_len -= cp->cp_size; + seg.ds_addr += cp->cp_size; + len -= cp->cp_size; - while (1) { + /* Create SA descriptor for this packet */ + cp->cp_config = cci->cci_config; + cp->cp_mac_total_dlen = tmlen; + /* - * Fill in current packet with data. Break if there is - * no more data in current DMA segment or an error - * occured. + * Enable fragmentation if request will not fit + * into one packet. */ - size = cesa_fill_packet(sc, &cp, &seg); - if (size <= 0) { - error = -size; - break; + if (!fragmented && len > 0) { + fragmented = 1; + cp->cp_config |= CESA_CSHD_FRAG_FIRST; + } else if (len > 0) { + cp->cp_config |= CESA_CSHD_FRAG_MIDDLE; + } else { + cp->cp_config |= CESA_CSHD_FRAG_LAST; } - len -= size; + if (eskip < cp->cp_size && elen > 0) { + cp->cp_enc_src = CESA_DATA(eskip); + cp->cp_enc_dst = CESA_DATA(eskip); + cp->cp_enc_dlen = MIN(elen, cp->cp_size - eskip); + } + else + { + cp->cp_enc_src = 0; + cp->cp_enc_dst = 0; + cp->cp_enc_dlen = 0; + } - /* If packet is full, append it to the chain */ - if (cp.cp_size == cp.cp_offset) { - csd = cesa_alloc_sdesc(sc, cr); - if (!csd) { - error = ENOMEM; - break; - } + if (mskip < cp->cp_size && mlen > 0) { + cp->cp_mac_src = CESA_DATA(mskip); + cp->cp_mac_dlen = MIN(mlen, cp->cp_size - mskip); + } + else + { + cp->cp_mac_src = 0; + cp->cp_mac_dlen = 0; + } - /* Create SA descriptor for this packet */ - csd->csd_cshd->cshd_config = cci->cci_config; - csd->csd_cshd->cshd_mac_total_dlen = tmlen; + elen -= cp->cp_enc_dlen; + eskip -= MIN(eskip, cp->cp_size); + mlen -= cp->cp_mac_dlen; + mskip -= MIN(mskip, cp->cp_size); - /* - * Enable fragmentation if request will not fit - * into one packet. - */ - if (len > 0) { - if (!fragmented) { - fragmented = 1; - csd->csd_cshd->cshd_config |= - CESA_CSHD_FRAG_FIRST; - } else - csd->csd_cshd->cshd_config |= - CESA_CSHD_FRAG_MIDDLE; - } else if (fragmented) - csd->csd_cshd->cshd_config |= - CESA_CSHD_FRAG_LAST; - - if (eskip < cp.cp_size && elen > 0) { - csd->csd_cshd->cshd_enc_src = - CESA_DATA(eskip); - csd->csd_cshd->cshd_enc_dst = - CESA_DATA(eskip); - csd->csd_cshd->cshd_enc_dlen = - MIN(elen, cp.cp_size - eskip); - } - - if (mskip < cp.cp_size && mlen > 0) { - csd->csd_cshd->cshd_mac_src = - CESA_DATA(mskip); - csd->csd_cshd->cshd_mac_dlen = - MIN(mlen, cp.cp_size - mskip); - } - - elen -= csd->csd_cshd->cshd_enc_dlen; - eskip -= MIN(eskip, cp.cp_size); - mlen -= csd->csd_cshd->cshd_mac_dlen; - mskip -= MIN(mskip, cp.cp_size); - - cesa_dump_cshd(sc, csd->csd_cshd); - - /* Append packet to the request */ - error = cesa_append_packet(sc, cr, &cp, csd); - if (error) - break; - - /* Start a new packet, as current is full */ - cesa_start_packet(&cp, MIN(mpsize, len)); - } + /* Append packet to the request */ + STAILQ_INSERT_TAIL(&cr->cr_packets, cp, cp_stq); } - - if (error) - break; } - - if (error) { - /* - * Move all allocated resources to the request. They will be - * freed later. - */ - STAILQ_CONCAT(&cr->cr_tdesc, &cp.cp_copyin); - STAILQ_CONCAT(&cr->cr_tdesc, &cp.cp_copyout); - cci->cci_error = error; - } } static void @@ -804,8 +567,6 @@ cesa_create_chain(struct cesa_softc *sc, struct cesa_request *cr) { struct cesa_chain_info cci; - struct cesa_tdma_desc *ctd; - uint32_t config; int error; error = 0; @@ -829,31 +590,30 @@ CESA_MAX_HASH_LEN); } - ctd = cesa_tdma_copyin_sa_data(sc, cr); - if (!ctd) - return (ENOMEM); - - cesa_append_tdesc(cr, ctd); - /* Prepare SA configuration */ - config = cr->cr_cs->cs_config; + cci.cci_config = cr->cr_cs->cs_config; if (cr->cr_enc && (cr->cr_enc->crd_flags & CRD_F_ENCRYPT) == 0) - config |= CESA_CSHD_DECRYPT; + cci.cci_config |= CESA_CSHD_DECRYPT; if (cr->cr_enc && !cr->cr_mac) - config |= CESA_CSHD_ENC; + cci.cci_config |= CESA_CSHD_ENC; if (!cr->cr_enc && cr->cr_mac) - config |= CESA_CSHD_MAC; + cci.cci_config |= CESA_CSHD_MAC; if (cr->cr_enc && cr->cr_mac) - config |= (config & CESA_CSHD_DECRYPT) ? CESA_CSHD_MAC_AND_ENC : - CESA_CSHD_ENC_AND_MAC; + cci.cci_config |= (cci.cci_config & CESA_CSHD_DECRYPT) + ? CESA_CSHD_MAC_AND_ENC + : CESA_CSHD_ENC_AND_MAC; - /* Create data packets */ + /* Prepare chain configuration */ + cci.cci_emask = cr->cr_cs->cs_ivlen - 1; + cci.cci_mmask = cr->cr_cs->cs_mblen - 1; + cci.cci_mpsize = CESA_MAX_PACKET_SIZE; + cci.cci_mpsize &= ~(cci.cci_emask | cci.cci_mmask); + cci.cci_sc = sc; cci.cci_cr = cr; cci.cci_enc = cr->cr_enc; cci.cci_mac = cr->cr_mac; - cci.cci_config = config; cci.cci_error = 0; if (cr->cr_crp->crp_flags & CRYPTO_F_IOV) @@ -879,21 +639,20 @@ if (error) return (error); - /* Read back request metadata */ - ctd = cesa_tdma_copyout_sa_data(sc, cr); - if (!ctd) - return (ENOMEM); - - cesa_append_tdesc(cr, ctd); - return (0); } static void cesa_execute(struct cesa_softc *sc) { - struct cesa_tdma_desc *prev_ctd, *ctd; - struct cesa_request *prev_cr, *cr; + struct cesa_tdma_desc *ctd; + struct cesa_sa_desc *csd; + struct cesa_request *cr; + struct cesa_packet *cp; + unsigned int tdesc_curr; + bus_addr_t base_data; + bus_addr_t base_sa; + bus_addr_t base_sa_data; CESA_LOCK(sc, requests); @@ -902,8 +661,8 @@ * is not empty, the hardware is busy and we cannot start another * execution. */ - if (STAILQ_EMPTY(&sc->sc_ready_requests) || - !STAILQ_EMPTY(&sc->sc_queued_requests)) { + if ((STAILQ_EMPTY(&sc->sc_ready_requests) + && STAILQ_EMPTY(&sc->sc_queued_requests)) || sc->sc_busy) { CESA_UNLOCK(sc, requests); return; } @@ -912,37 +671,109 @@ STAILQ_CONCAT(&sc->sc_queued_requests, &sc->sc_ready_requests); STAILQ_INIT(&sc->sc_ready_requests); - /* Create one execution chain from all requests on the list */ - if (STAILQ_FIRST(&sc->sc_queued_requests) != - STAILQ_LAST(&sc->sc_queued_requests, cesa_request, cr_stq)) { - prev_cr = NULL; - cesa_sync_dma_mem(&sc->sc_tdesc_cdm, BUS_DMASYNC_POSTREAD | - BUS_DMASYNC_POSTWRITE); + /* Create execution chain from all requests on the list */ + tdesc_curr = 0; - STAILQ_FOREACH(cr, &sc->sc_queued_requests, cr_stq) { - if (prev_cr) { - ctd = STAILQ_FIRST(&cr->cr_tdesc); - prev_ctd = STAILQ_LAST(&prev_cr->cr_tdesc, - cesa_tdma_desc, ctd_stq); + base_sa = sc->sc_sram_base; + base_sa_data = base_sa + sizeof(struct cesa_sa_hdesc); + base_data = base_sa_data + sizeof(struct cesa_sa_data); - prev_ctd->ctd_cthd->cthd_next = - ctd->ctd_cthd_paddr; + cesa_sync_dma_mem(&sc->sc_tdesc_cdm, BUS_DMASYNC_POSTREAD | BUS_DMASYNC_POSTWRITE); + cesa_sync_dma_mem(&sc->sc_sdesc_cdm, BUS_DMASYNC_POSTREAD | BUS_DMASYNC_POSTWRITE); + + /* re-set next handle of tail of previous chain */ + tdesc_curr = sc->sc_tdesc_curr; + if(tdesc_curr != CESA_TDMA_DESCRIPTORS - 1) + { + sc->sc_tdesc[tdesc_curr].ctd_cthd->cthd_next = + sc->sc_tdesc[tdesc_curr + 1].ctd_cthd_paddr; + } + + #define CESA_NEXT_TDESC(obj) do { \ + obj = &sc->sc_tdesc[tdesc_curr++]; \ + } while(0) + + STAILQ_FOREACH(cr, &sc->sc_queued_requests, cr_stq) { + if(!cr->cr_processing) + { + /* check we can queue a write */ + if(tdesc_curr < CESA_TDMA_DESCRIPTORS) + { + break; } - prev_cr = cr; + cr->cr_processing = 1; + + CESA_NEXT_TDESC(ctd); + cesa_tdma_copy(ctd, base_sa_data, cr->cr_csd_paddr, sizeof(struct cesa_sa_data)); } - cesa_sync_dma_mem(&sc->sc_tdesc_cdm, BUS_DMASYNC_PREREAD | - BUS_DMASYNC_PREWRITE); + while(!STAILQ_EMPTY(&cr->cr_packets) && tdesc_curr < CESA_TDMA_DESCRIPTORS - 5) { + CESA_GENERIC_ALLOC_LOCKED(sc, csd, sdesc); + if(!csd) + { + break; + } + STAILQ_INSERT_TAIL(&cr->cr_sdesc, csd, csd_stq); + + cp = STAILQ_FIRST(&cr->cr_packets); + + csd->csd_cshd->cshd_config = cp->cp_config; + csd->csd_cshd->cshd_enc_src = cp->cp_enc_src; + csd->csd_cshd->cshd_enc_dst = cp->cp_enc_dst; + csd->csd_cshd->cshd_enc_dlen = cp->cp_enc_dlen; + csd->csd_cshd->cshd_mac_src = cp->cp_mac_src; + csd->csd_cshd->cshd_mac_total_dlen = cp->cp_mac_total_dlen; + csd->csd_cshd->cshd_mac_dlen = cp->cp_mac_dlen; + + CESA_NEXT_TDESC(ctd); + cesa_tdma_copy(ctd, base_sa, csd->csd_cshd_paddr, sizeof(struct cesa_sa_hdesc)); + + CESA_NEXT_TDESC(ctd); + cesa_tdma_copy(ctd, base_data, cp->cp_data, cp->cp_size); + + /* may be obsolete */ + CESA_NEXT_TDESC(ctd); + cesa_tdma_copy(ctd, 0, 0, 0); + + CESA_NEXT_TDESC(ctd); + cesa_tdma_copy(ctd, cp->cp_data, base_data, cp->cp_size); + + STAILQ_REMOVE_HEAD(&cr->cr_packets, cp_stq); + free(cp, M_CESA); + } + + /* check whether the complete request could be queued */ + if(!STAILQ_EMPTY(&cr->cr_packets)) + { + break; + } + + CESA_NEXT_TDESC(ctd); + cesa_tdma_copy(ctd, cr->cr_csd_paddr, base_sa_data, sizeof(struct cesa_sa_data)); } + #undef CESA_NEXT_TDESC + + /* make sure TDMA gets back to use once it processed all data */ + --tdesc_curr; + if(tdesc_curr != CESA_TDMA_DESCRIPTORS - 1) + { + sc->sc_tdesc[tdesc_curr].ctd_cthd->cthd_next = 0; + } + + cesa_sync_dma_mem(&sc->sc_tdesc_cdm, BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE); + cesa_sync_dma_mem(&sc->sc_sdesc_cdm, BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE); + + sc->sc_tdesc_curr = tdesc_curr; + /* Start chain execution in hardware */ - cr = STAILQ_FIRST(&sc->sc_queued_requests); - ctd = STAILQ_FIRST(&cr->cr_tdesc); + ctd = &sc->sc_tdesc[0]; CESA_WRITE(sc, CESA_TDMA_ND, ctd->ctd_cthd_paddr); CESA_WRITE(sc, CESA_SA_CMD, CESA_SA_CMD_ACTVATE); + sc->sc_busy = 1; CESA_UNLOCK(sc, requests); } @@ -992,6 +823,7 @@ sc = device_get_softc(dev); sc->sc_blocked = 0; + sc->sc_busy = 0; sc->sc_error = 0; sc->sc_dev = dev; @@ -1018,8 +850,6 @@ /* Initialize mutexes */ mtx_init(&sc->sc_sc_lock, device_get_nameunit(dev), "CESA Shared Data", MTX_DEF); - mtx_init(&sc->sc_tdesc_lock, device_get_nameunit(dev), - "CESA TDMA Descriptors Pool", MTX_DEF); mtx_init(&sc->sc_sdesc_lock, device_get_nameunit(dev), "CESA SA Descriptors Pool", MTX_DEF); mtx_init(&sc->sc_requests_lock, device_get_nameunit(dev), @@ -1065,14 +895,16 @@ if (error) goto err3; - STAILQ_INIT(&sc->sc_free_tdesc); + sc->sc_tdesc_curr = 0; for (i = 0; i < CESA_TDMA_DESCRIPTORS; i++) { sc->sc_tdesc[i].ctd_cthd = (struct cesa_tdma_hdesc *)(sc->sc_tdesc_cdm.cdm_vaddr) + i; sc->sc_tdesc[i].ctd_cthd_paddr = sc->sc_tdesc_cdm.cdm_paddr + - (i * sizeof(struct cesa_tdma_hdesc)); - STAILQ_INSERT_TAIL(&sc->sc_free_tdesc, &sc->sc_tdesc[i], - ctd_stq); + i * sizeof(struct cesa_tdma_hdesc); + + if (i != CESA_TDMA_DESCRIPTORS - 1) + sc->sc_tdesc[i].ctd_cthd->cthd_next = sc->sc_tdesc_cdm.cdm_paddr + + (i + 1) * sizeof(struct cesa_tdma_hdesc); } /* Initialize data structures: SA Descriptors Pool */ @@ -1087,6 +919,15 @@ (struct cesa_sa_hdesc *)(sc->sc_sdesc_cdm.cdm_vaddr) + i; sc->sc_sdesc[i].csd_cshd_paddr = sc->sc_sdesc_cdm.cdm_paddr + (i * sizeof(struct cesa_sa_hdesc)); + + /* fill constant descriptor values */ + sc->sc_sdesc[i].csd_cshd->cshd_enc_key = CESA_SA_DATA(csd_key); + sc->sc_sdesc[i].csd_cshd->cshd_enc_iv = CESA_SA_DATA(csd_iv); + sc->sc_sdesc[i].csd_cshd->cshd_enc_iv_buf = CESA_SA_DATA(csd_iv); + sc->sc_sdesc[i].csd_cshd->cshd_mac_dst = CESA_SA_DATA(csd_hash); + sc->sc_sdesc[i].csd_cshd->cshd_mac_iv_in = CESA_SA_DATA(csd_hiv_in); + sc->sc_sdesc[i].csd_cshd->cshd_mac_iv_out = CESA_SA_DATA(csd_hiv_out); + STAILQ_INSERT_TAIL(&sc->sc_free_sdesc, &sc->sc_sdesc[i], csd_stq); } @@ -1195,7 +1036,6 @@ mtx_destroy(&sc->sc_sessions_lock); mtx_destroy(&sc->sc_requests_lock); mtx_destroy(&sc->sc_sdesc_lock); - mtx_destroy(&sc->sc_tdesc_lock); mtx_destroy(&sc->sc_sc_lock); return (ENXIO); } @@ -1240,7 +1080,6 @@ mtx_destroy(&sc->sc_sessions_lock); mtx_destroy(&sc->sc_requests_lock); mtx_destroy(&sc->sc_sdesc_lock); - mtx_destroy(&sc->sc_tdesc_lock); mtx_destroy(&sc->sc_sc_lock); return (0); @@ -1295,10 +1134,30 @@ return; /* Get all finished requests */ + STAILQ_INIT(&requests); CESA_LOCK(sc, requests); - STAILQ_INIT(&requests); - STAILQ_CONCAT(&requests, &sc->sc_queued_requests); - STAILQ_INIT(&sc->sc_queued_requests); + CESA_LOCK(sc, sdesc); + while(!STAILQ_EMPTY(&sc->sc_queued_requests)) + { + cr = STAILQ_FIRST(&sc->sc_queued_requests); + + /* free SA descriptors */ + STAILQ_CONCAT(&sc->sc_free_sdesc, &cr->cr_sdesc); + STAILQ_INIT(&cr->cr_sdesc); + + /* check for partial completion */ + if(STAILQ_EMPTY(&cr->cr_packets)) + { + STAILQ_REMOVE_HEAD(&sc->sc_queued_requests, cr_stq); + STAILQ_INSERT_TAIL(&requests, cr, cr_stq); + } + else + { + break; + } + } + sc->sc_busy = 0; + CESA_UNLOCK(sc, sdesc); CESA_UNLOCK(sc, requests); /* Execute all ready requests */ @@ -1545,8 +1404,9 @@ cr->cr_cs = cs; CESA_LOCK(sc, sessions); - cesa_sync_desc(sc, BUS_DMASYNC_POSTREAD | BUS_DMASYNC_POSTWRITE); + cesa_sync_dma_mem(&sc->sc_requests_cdm, BUS_DMASYNC_POSTREAD | BUS_DMASYNC_POSTWRITE); + if (enc && enc->crd_flags & CRD_F_ENCRYPT) { if (enc->crd_flags & CRD_F_IV_EXPLICIT) memcpy(cr->cr_csd->csd_iv, enc->crd_iv, cs->cs_ivlen); @@ -1586,7 +1446,8 @@ if (!error) error = cesa_create_chain(sc, cr); - cesa_sync_desc(sc, BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE); + cesa_sync_dma_mem(&sc->sc_requests_cdm, BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE); + CESA_UNLOCK(sc, sessions); if (error) { --=_bx6zcmqegq-- From owner-freebsd-arm@FreeBSD.ORG Sat Dec 17 17:37:58 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3842D106566C for ; Sat, 17 Dec 2011 17:37:58 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id 1D61B8FC15 for ; Sat, 17 Dec 2011 17:37:57 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta09.emeryville.ca.mail.comcast.net with comcast id AHcY1i0031smiN4A9HdprC; Sat, 17 Dec 2011 17:37:49 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta20.emeryville.ca.mail.comcast.net with comcast id AGwD1i00Z4NgCEG8gGwE1u; Sat, 17 Dec 2011 16:56:14 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id pBHHbq4a006147; Sat, 17 Dec 2011 10:37:53 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Matthieu Kraus In-Reply-To: <20111217151858.182523ch5m4bclw2@mail.tu-chemnitz.de> References: <20111217151858.182523ch5m4bclw2@mail.tu-chemnitz.de> Content-Type: text/plain Date: Sat, 17 Dec 2011 10:37:52 -0700 Message-Id: <1324143472.3268.147.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: cesa patch issues X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2011 17:37:58 -0000 On Sat, 2011-12-17 at 15:18 +0100, Matthieu Kraus wrote: > [...] > However I can't seem to get my modifications to work as I always get: > > vm_fault(0xc35789c8, 0, 2, 0) -> 1 > Fatal kernel mode data abort: 'Translation Fault (P)' > trapframe: 0xd2069bb0 > FSR=00000017, FAR=00000010, spsr=80000013 > r0 =0000001f, r1 =00000000, r2 =00000000, r3 =00000004 > r4 =00000000, r5 =00000000, r6 =00000000, r7 =c373d898 > r8 =c3736000, r9 =00000000, r10=c3736000, r11=d2069c38 > r12=00000000, ssp=d2069bfc, slr=c0c02f40, pc =c0c22d58 > > [ thread pid 1439 tid 100057 ] > Stopped at cpu_initclocks+0x3340: str r4, [r3, #0x00c] > > I'm completely new to kernel development, so any hints on how to > further debug the issue (traces in ddb didn't seem very informational > to me) would be highly appreciated. > > kind regards, > Matthieu Kraus All that can be seen from what you posted is that the immediate cause of the error is a bad value in register r3. The ddb backtrace that wasn't helpful to you might contain clues that are meaningful to others; you should post it. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Dec 17 18:46:26 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25B601065670 for ; Sat, 17 Dec 2011 18:46:26 +0000 (UTC) (envelope-from matthieu.kraus@s2008.tu-chemnitz.de) Received: from nick.hrz.tu-chemnitz.de (nick.hrz.tu-chemnitz.de [134.109.228.11]) by mx1.freebsd.org (Postfix) with ESMTP id C1C2E8FC08 for ; Sat, 17 Dec 2011 18:46:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tu-chemnitz.de; s=dkim2010; h=Content-Transfer-Encoding:Content-Type:Mime-Version:Date:Subject:Cc:To:From:Message-ID:References; bh=adSfy8Uysfw2+nD4y3OlBnLTUsq8kq5vFROBOncPPv4=; b=pscBxPUEws0VCJ9EhtJt3Oj8sn9TtjZfO0dmheaWG0HdjswmYNyqMELFENinUQv+HgXqKF9S+eq5bvQI1nUN9T8ociEbZdps+/vnv0vHvoWE2NgXig5moCtPdtqLsRStYan9JL7iilbsHh2cutiGjun82SgMN5K1rUpE9U7mX6g=; Received: from postman.hrz.tu-chemnitz.de ([134.109.133.5] helo=mailbox.hrz.tu-chemnitz.de) by nick.hrz.tu-chemnitz.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RbzH6-0007Dq-Go; Sat, 17 Dec 2011 19:46:24 +0100 Received: from rlydontknow.csn.tu-chemnitz.de ([134.109.92.98] helo=rlydontknow) by mailbox.hrz.tu-chemnitz.de with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1RbzH6-0003Yx-CQ; Sat, 17 Dec 2011 19:46:24 +0100 References: <20111217151858.182523ch5m4bclw2@mail.tu-chemnitz.de> <1324143472.3268.147.camel@revolution.hippie.lan> Message-ID: X-Mailer: http://www.courier-mta.org/cone/ From: Matthieu Kraus To: Ian Lepore Date: Sat, 17 Dec 2011 18:46:23 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: 7bit X-Scan-Signature: 83a5f8de2c0ef3b8f39a5f9e6c2450f2 Cc: freebsd-arm@freebsd.org Subject: Re: cesa patch issues X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2011 18:46:26 -0000 vm_fault(0xc35789c8, 0, 2, 0) -> 1 Fatal kernel mode data abort: 'Translation Fault (P)' trapframe: 0xd2069bb0 FSR=00000017, FAR=00000010, spsr=80000013 r0 =0000001f, r1 =00000000, r2 =00000000, r3 =00000004 r4 =00000000, r5 =00000000, r6 =00000000, r7 =c373d898 r8 =c3736000, r9 =00000000, r10=c3736000, r11=d2069c38 r12=00000000, ssp=d2069bfc, slr=c0c02f40, pc =c0c22d58 [ thread pid 1439 tid 100057 ] Stopped at cpu_initclocks+0x3340: str r4, [r3, #0x00c] Tracing pid 1439 tid 100057 td 0xc390f5c0 cpu_initclocks() at cpu_initclocks+0x3114 scp=0xc0c22b2c rlv=0xc0c246c0 (cpu_initclocks+0x4ca8) rsp=0xd2069c3c rfp=0xd2069ca0 r10=0xc3736000 r9=0xc37410c0 r8=0xc374141c r7=0x00000000 r6=0x00000000 r5=0x00000000 r4=0xc373d898 cpu_initclocks() at cpu_initclocks+0x46e8 scp=0xc0c24100 rlv=0xc0ba9348 (crypto_freesession+0x20c) rsp=0xd2069ca4 rfp=0xd2069cc4 r10=0xc3a3f000 r9=0xc3a16940 r8=0xc3731600 r7=0x00000000 r6=0x00000000 r5=0xc3a3d000 r4=0xc35d8600 crypto_freesession() at crypto_freesession+0x11c scp=0xc0ba9258 rlv=0xc0ba9704 (crypto_dispatch+0x68) rsp=0xd2069cc8 rfp=0xd2069ce0 r6=0xc3a3d000 r5=0x01000000 r4=0x00000006 crypto_dispatch() at crypto_dispatch+0x10 scp=0xc0ba96ac rlv=0xc0baa7cc (crypto_getreq+0xcec) rsp=0xd2069ce4 rfp=0xd2069d80 r6=0xc3a3d000 r5=0xc3a16900 r4=0x00000000 crypto_getreq() at crypto_getreq+0x498 scp=0xc0ba9f78 rlv=0xc0af0a04 (kern_ioctl+0x2d8) rsp=0xd2069d84 rfp=0xd2069db4 r10=0xc3a15c00 r9=0x00000000 r8=0xc390f5c0 r7=0x00000004 r6=0xc01c6367 r5=0x00000000 r4=0xc3731600 kern_ioctl() at kern_ioctl+0x10 scp=0xc0af073c rlv=0xc0af0b70 (sys_ioctl+0x114) rsp=0xd2069db8 rfp=0xd2069de4 r10=0xc390f5c0 r8=0xc3731600 r7=0xd2069e40 r6=0x00000000 r5=0x0000001c r4=0xc01c6367 sys_ioctl() at sys_ioctl+0x10 scp=0xc0af0a6c rlv=0xc0c14a20 (swi_handler+0x268) rsp=0xd2069de8 rfp=0xd2069ea8 r10=0x00000004 r8=0x00000000 r7=0xc3a14888 r6=0x00000000 r5=0xc390f5c0 r4=0x00000001 swi_handler() at swi_handler+0x10 scp=0xc0c147c8 rlv=0xc0c06b98 (swi_entry+0x3c) rsp=0xd2069eac rfp=0xbfffe924 r8=0x20407038 r7=0x00000008 r6=0x00000008 r5=0x20407030 r4=0x00000001 Ian Lepore writes: > On Sat, 2011-12-17 at 15:18 +0100, Matthieu Kraus wrote: >> [...] >> However I can't seem to get my modifications to work as I always get: >> >> vm_fault(0xc35789c8, 0, 2, 0) -> 1 >> Fatal kernel mode data abort: 'Translation Fault (P)' >> trapframe: 0xd2069bb0 >> FSR=00000017, FAR=00000010, spsr=80000013 >> r0 =0000001f, r1 =00000000, r2 =00000000, r3 =00000004 >> r4 =00000000, r5 =00000000, r6 =00000000, r7 =c373d898 >> r8 =c3736000, r9 =00000000, r10=c3736000, r11=d2069c38 >> r12=00000000, ssp=d2069bfc, slr=c0c02f40, pc =c0c22d58 >> >> [ thread pid 1439 tid 100057 ] >> Stopped at cpu_initclocks+0x3340: str r4, [r3, #0x00c] >> >> I'm completely new to kernel development, so any hints on how to >> further debug the issue (traces in ddb didn't seem very informational >> to me) would be highly appreciated. >> >> kind regards, >> Matthieu Kraus > > All that can be seen from what you posted is that the immediate cause of > the error is a bad value in register r3. The ddb backtrace that wasn't > helpful to you might contain clues that are meaningful to others; you > should post it. > > -- Ian > > >