From owner-freebsd-arm@FreeBSD.ORG Sun May 22 02:07:54 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 58C18106564A; Sun, 22 May 2011 02:07:54 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id C58F58FC14; Sun, 22 May 2011 02:07:53 +0000 (UTC) Received: by wyf23 with SMTP id 23so4803154wyf.13 for ; Sat, 21 May 2011 19:07:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.254.90 with SMTP id g68mr951005wes.16.1306028329413; Sat, 21 May 2011 18:38:49 -0700 (PDT) Sender: andy@fud.org.nz Received: by 10.216.187.198 with HTTP; Sat, 21 May 2011 18:38:49 -0700 (PDT) In-Reply-To: <1305996468.21869.9.camel@xeon.thinmesh.com> References: <1305996468.21869.9.camel@xeon.thinmesh.com> Date: Sun, 22 May 2011 13:38:49 +1200 X-Google-Sender-Auth: 3zdLajlxlqBOpOIfuFjC-0MFPSQ Message-ID: From: Andrew Thompson To: John Nicholls Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm@freebsd.org Subject: Re: Beagleboard Kernel Development - Load Kernel in 2 seconds 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: Sun, 22 May 2011 02:07:54 -0000 On 22 May 2011 04:47, John Nicholls wrote: > To help speed up Kernel development I have sent some developers a new > version of u-boot that uses the USB device to transfer the Kernel > instead of booting it off the SD card > > The Kernel loads over the USB device port in about 2 seconds. I am using this (previously sent to me) and I have one issue which I am not sure if its a FreeBSD or u-boot problem. If I do not interrupt the 10 second u-boot countdown then the usb device fails to attach on the FreeBSD host, this is because FreeBSD times out on setting the usb address for the u-boot device. Anyone else having this issue? Andrew From owner-freebsd-arm@FreeBSD.ORG Sun May 22 18:03:46 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 62A8B1065673; Sun, 22 May 2011 18:03:46 +0000 (UTC) (envelope-from mlfbsd@kanar.ci0.org) Received: from kanar.ci0.org (unknown [IPv6:2a01:e0b:1:50:40:63ff:feea:93a]) by mx1.freebsd.org (Postfix) with ESMTP id 05CC98FC0C; Sun, 22 May 2011 18:03:45 +0000 (UTC) Received: from kanar.ci0.org (pluxor@localhost [127.0.0.1]) by kanar.ci0.org (8.14.2/8.14.3) with ESMTP id p4MI4NE8048839; Sun, 22 May 2011 20:04:23 +0200 (CEST) (envelope-from mlfbsd@kanar.ci0.org) Received: (from mlfbsd@localhost) by kanar.ci0.org (8.14.2/8.14.3/Submit) id p4MI4MKX048838; Sun, 22 May 2011 20:04:22 +0200 (CEST) (envelope-from mlfbsd) Date: Sun, 22 May 2011 20:04:22 +0200 From: Olivier Houchard To: Damjan Marion Message-ID: <20110522180422.GA46973@ci0.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org, freebsd-arm@freebsd.org Subject: Re: vm_fault when accessing PCI address space 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: Sun, 22 May 2011 18:03:46 -0000 On Sat, May 21, 2011 at 01:34:02AM +0200, Damjan Marion wrote: > > Hi, > Hi Damjan, > I'm made some progress on porting existing marvell orion ARM code > to work on 88F5181L SoC which have embedded PCI controller. > > PCI driver detects resources and recognizes Atheros wlan card, > however when driver tries to access 1st register with > bus_space_write_4 vm_fault happens: > > vm_fault(0xc0e4f000, e8007000, 2, 0) -> 1 > Fatal kernel mode data abort: 'Translation Fault (S)' > trapframe: 0xc0d3faa4 > FSR=00000005, FAR=e800704c, spsr=600000d3 > r0 =00000000, r1 =e8000000, r2 =0000704c, r3 =00000003 > r4 =c13cd000, r5 =c0c4bd60, r6 =c0bece04, r7 =c12dd000 > r8 =00000023, r9 =c0d074c8, r10=c0d3fba4, r11=c0d3fb00 > r12=00000000, ssp=c0d3faf0, slr=c095f830, pc =c0bece04 > > [ thread pid 0 tid 100000 ] > Stopped at generic_bs_w_4: str r3, [r1, r2] > > 0xe8000000 is PCI mem space. I can see that PCI driver (mv_pci.c) allocates this resource: > > pcib0: mem 0xf1030000-0xf1031fff irq 0 on fdtbus0 > pci0: on pcib0 > mv_pcib_alloc_resource: start=0xe8000000 end=0xe800ffff count=0x00010000 flags=0x00 > > What can be the reason for this vm_fault? > I don't know the Marvell, nor the FDT code, well, but you shouldn't access to the PCI mem space using the physical address, so maybe something is missing from the dts ? Also, reading the mv code, there's this in mv_machdep.c : if (fdt_pci_devmap(child, &fdt_devmap[i], MV_PCIE_IO_BASE, MV_PCIE_MEM_BASE) != 0) return (ENXIO); but nothing equivalent for the PCI controller (as it seems the Orion has both PCI and PCIe). So maybe it is lacking ? Regards, Olivier From owner-freebsd-arm@FreeBSD.ORG Sun May 22 20:19:15 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 002CF106566B; Sun, 22 May 2011 20:19:14 +0000 (UTC) (envelope-from damjan.marion@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 527338FC15; Sun, 22 May 2011 20:19:13 +0000 (UTC) Received: by bwz12 with SMTP id 12so5905988bwz.13 for ; Sun, 22 May 2011 13:19:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=+WcYcxXk2hS5gFYis9DKJE8qojeoEirhB7nEbbmlOes=; b=tGGZamQe/ai31zhQAR/qab0hlhQIdf73Fd9f4uFQ3hp2v+muSQWlEyHBADNhoECs1L RNyXTZnJrmZo1LVLDBwChWEe/8EaPB9eI7dPac95sjWUIAQZp2aH7Wg2qyoF6gPOY5wY F43WHPDBTBtjygl7WP1pce7OA1qozG/7Cburg= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=SnJqAI7Fg7SpmonvFGQ10BXikXqgr9P6dQ4iURX9RP3uGPj9/FNpjavH+qeAph1JKY x6XUSF4B+UugLNwzZq2ZYV2h/gTrcLzakgWTHFRV41/eOGhofHvZ/xTmwF74dzT+tOsi /qe3GASjXvdN8gzesAVtaJ4uD4TenQIsnnubY= Received: by 10.204.83.7 with SMTP id d7mr1360584bkl.206.1306095553054; Sun, 22 May 2011 13:19:13 -0700 (PDT) Received: from [192.168.123.4] (cpe-109-60-66-194.zg3.cable.xnet.hr [109.60.66.194]) by mx.google.com with ESMTPS id q25sm3468974bkk.10.2011.05.22.13.19.11 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 22 May 2011 13:19:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Damjan Marion In-Reply-To: <20110522180422.GA46973@ci0.org> Date: Sun, 22 May 2011 22:19:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110522180422.GA46973@ci0.org> To: Olivier Houchard X-Mailer: Apple Mail (2.1084) Cc: freebsd-hackers@freebsd.org, freebsd-arm@freebsd.org Subject: Re: vm_fault when accessing PCI address space 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: Sun, 22 May 2011 20:19:15 -0000 On May 22, 2011, at 8:04 PM, Olivier Houchard wrote: > On Sat, May 21, 2011 at 01:34:02AM +0200, Damjan Marion wrote: >>=20 >> Hi, >>=20 >=20 > Hi Damjan, >=20 >> I'm made some progress on porting existing marvell orion ARM code=20 >> to work on 88F5181L SoC which have embedded PCI controller. >>=20 >> PCI driver detects resources and recognizes Atheros wlan card,=20 >> however when driver tries to access 1st register with >> bus_space_write_4 vm_fault happens: >>=20 >> vm_fault(0xc0e4f000, e8007000, 2, 0) -> 1 >> Fatal kernel mode data abort: 'Translation Fault (S)' >> trapframe: 0xc0d3faa4 >> FSR=3D00000005, FAR=3De800704c, spsr=3D600000d3 >> r0 =3D00000000, r1 =3De8000000, r2 =3D0000704c, r3 =3D00000003 >> r4 =3Dc13cd000, r5 =3Dc0c4bd60, r6 =3Dc0bece04, r7 =3Dc12dd000 >> r8 =3D00000023, r9 =3Dc0d074c8, r10=3Dc0d3fba4, r11=3Dc0d3fb00 >> r12=3D00000000, ssp=3Dc0d3faf0, slr=3Dc095f830, pc =3Dc0bece04 >>=20 >> [ thread pid 0 tid 100000 ] >> Stopped at generic_bs_w_4: str r3, [r1, r2] >>=20 >> 0xe8000000 is PCI mem space. I can see that PCI driver (mv_pci.c) = allocates this resource: >>=20 >> pcib0: mem = 0xf1030000-0xf1031fff irq 0 on fdtbus0 >> pci0: on pcib0 >> mv_pcib_alloc_resource: start=3D0xe8000000 end=3D0xe800ffff = count=3D0x00010000 flags=3D0x00 >>=20 >> What can be the reason for this vm_fault?=20 >>=20 >=20 > I don't know the Marvell, nor the FDT code, well, but you shouldn't = access > to the PCI mem space using the physical address, so maybe something is = missing > from the dts ? > Also, reading the mv code, there's this in mv_machdep.c : > if (fdt_pci_devmap(child, &fdt_devmap[i], > MV_PCIE_IO_BASE, MV_PCIE_MEM_BASE) !=3D 0) > return (ENXIO); > but nothing equivalent for the PCI controller (as it seems the Orion = has both > PCI and PCIe). So maybe it is lacking ? Hi Olivier, yes, that code is wrong. It is inside loop so if there are 2 PCI = adapters=20 (i.e. PCIe + PCI) it will try to map both to same VA. Also different Marvell SoCs are using different PCI regions, so this = needs to be adjusted to work with my SoC. Thanks, Damjan From owner-freebsd-arm@FreeBSD.ORG Mon May 23 11:06:55 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 47AEC106566B for ; Mon, 23 May 2011 11:06:55 +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 37DD78FC20 for ; Mon, 23 May 2011 11:06:55 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4NB6t7C051614 for ; Mon, 23 May 2011 11:06:55 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4NB6sMP051612 for freebsd-arm@FreeBSD.org; Mon, 23 May 2011 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 23 May 2011 11:06:54 GMT Message-Id: <201105231106.p4NB6sMP051612@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, 23 May 2011 11:06:55 -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/156814 arm OpenRD Ultimate does not boot on DB-88F6XXX or SHEEVAP o arm/156771 arm FreeBSD/arm fails to build trampoline code with clang 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/154306 arm named crashes with signal 11 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 13 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon May 23 15:32:29 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 EE7AC106564A for ; Mon, 23 May 2011 15:32:29 +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 7D2988FC18 for ; Mon, 23 May 2011 15:32:29 +0000 (UTC) Received: by wwc33 with SMTP id 33so6032501wwc.31 for ; Mon, 23 May 2011 08:32:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=q1y2zyX7V0LBdDrCp3JpQXm1ZzGnMDxTbbRqKhMCmdM=; b=k/sVFDbzhKNuvgIvwZkB6qQlYb3V4WConAmaRjR8nuYCYf85zF4yDEdHHk/H9Rm5fY yO/N3Bwv6GC+3mUKMj7J/R1+ktSpcY6jRLbkg8BLXvSZSK5isGODJU4oBrwvrbRuJRDj HBBwgdFtPufo6LxuJx1/Zw1BgLGhnnYJFN4fI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=IPQpXplHy4sGsAHe+S5rFx7Cx67+4WIZ55tBPfLjdAaCIXaOK+lEL708ClhMj8NGqA aWW8xJkWF6xgelDgmMHbyfKcRcjonvCnhemG7IKB8BeEAUr+Q74961SpNjNH1mPrqdcx YOvKwB1icyn4RJlETQrX9jR5Bn8zA/6snqFmI= Received: by 10.216.255.201 with SMTP id j51mr2202311wes.94.1306163342973; Mon, 23 May 2011 08:09:02 -0700 (PDT) Received: from Bens-MBP.local (ip-80-238-8-128.bskyb.com [80.238.8.128]) by mx.google.com with ESMTPS id g58sm3320365wen.20.2011.05.23.08.09.01 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 May 2011 08:09:02 -0700 (PDT) Message-ID: <4DDA788C.6020506@gmail.com> Date: Mon, 23 May 2011 16:09:00 +0100 From: Ben Gray User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: L2 cache functions and physical to virtual mappings 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, 23 May 2011 15:32:30 -0000 Hi, I've been working on the OMAP4430 chip (Pandaboard) which uses the ARM PL310 L2 cache controller. I've written basic support for it, but when it comes to mapping it back into cpu_l2cache_??? functions I hit a problem in that these functions take a virtual address rather than a physical address. The PL310 is a PIPT cache and naturally all cache maintenance operations use physical addresses. AFAICT the OMAP4430 doesn't use the nice cp15 instructions for flushing L2 caches (i.e. "mcr p15, 1, r0, c15, c9, 0"), instead operations are performed by writing to registers within the controller. So I guess I'm just after some advice on the best way to get around this, I came up with the following options but none are particularly neat. 1. Create a compile time #define which indicates the type of l2 cache, i.e. pseudo-code #if defined(L2_CACHE_PHYS_ADDR) for (adr= buf & (PAGE_SIZE - 1); adr < len; adr += PAGE_SIZE) cpu_l2cache_wb_range(pmap_extract(pmap, buf), PAGE_SIZE); #else cpu_l2cache_wb_range(buf, len); #endif 2. Perform the virtual to physical translation in the cpu_l2cache_xxx() functions using pmap_extract(). But I think this will require the pmap pointer to be passed to the cpu_l2cache_xxx() functions, therefore changing the current API. 3.Perform the virtual to physical translation in the cpu_l2cache_xxx() functions as above, but use the "CP15 c7, Virtual Address to Physical Address translation operations" to do the translation. Any advice would be greatly appreciated. Cheers, Ben. From owner-freebsd-arm@FreeBSD.ORG Mon May 23 16:41:50 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 EE0CA106566B for ; Mon, 23 May 2011 16:41:49 +0000 (UTC) (envelope-from marktinguely@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 A595D8FC15 for ; Mon, 23 May 2011 16:41:49 +0000 (UTC) Received: by ywf7 with SMTP id 7so2782681ywf.13 for ; Mon, 23 May 2011 09:41:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=3XUuKenHSBkLcU6pfdxebq7GQFQBQopTe63ozWYmJZw=; b=ZrtKGewVbtgPHD7aqxDuAp7fBJCa1KKYaDfyjej4AkdkEiqwNAQQJPZijGQk7c3NNw rg8cMgqtyfKEBX9Qc38y34z+P4+6uj6hLuphcUbm8cB37NL5zaX8mjnkXmqtOJ6wWus+ hmuGMTbwXWCclxV6KdQvq85W4fEGU5v2uvDqs= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=a8OZM1Ok2H6A+aiqwGfDeokUXTKyc44w9CyTPfLvTbl2ndyC7lce3zFmzgXsgHzGku Oke2+w48GnrPNIsvAQoYpo67pNXgnKS1zdVyD0PcN+FpHRJwvzCD2lqBO+guLNDo8F0m sbCS2dHjyzYGtQHIdNM8CXZw7GkQ2g3QMpIuw= Received: by 10.150.75.10 with SMTP id x10mr3171935yba.110.1306168908898; Mon, 23 May 2011 09:41:48 -0700 (PDT) Received: from [192.168.1.111] (c-24-245-26-12.hsd1.mn.comcast.net [24.245.26.12]) by mx.google.com with ESMTPS id r9sm2806310yba.16.2011.05.23.09.41.47 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 May 2011 09:41:48 -0700 (PDT) Message-ID: <4DDA8E4A.6060002@gmail.com> Date: Mon, 23 May 2011 11:41:46 -0500 From: Mark Tinguely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Ben Gray References: <4DDA788C.6020506@gmail.com> In-Reply-To: <4DDA788C.6020506@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: L2 cache functions and physical to virtual mappings 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, 23 May 2011 16:41:50 -0000 On 5/23/2011 10:09 AM, Ben Gray wrote: > Hi, > > I've been working on the OMAP4430 chip (Pandaboard) which uses the > ARM PL310 L2 cache controller. I've written basic support for it, but > when it comes to mapping it back into cpu_l2cache_??? functions I hit > a problem in that these functions take a virtual address rather than a > physical address. > > The PL310 is a PIPT cache and naturally all cache maintenance > operations use physical addresses. AFAICT the OMAP4430 doesn't use the > nice cp15 instructions for flushing L2 caches (i.e. "mcr p15, 1, > r0, c15, c9, 0"), instead operations are performed by writing to > registers within the controller. > > So I guess I'm just after some advice on the best way to get > around this, I came up with the following options but none are > particularly neat. > > > 1. Create a compile time #define which indicates the type of l2 > cache, i.e. pseudo-code > > #if defined(L2_CACHE_PHYS_ADDR) > for (adr= buf & (PAGE_SIZE - 1); adr < len; adr += > PAGE_SIZE) > cpu_l2cache_wb_range(pmap_extract(pmap, buf), > PAGE_SIZE); > #else > cpu_l2cache_wb_range(buf, len); > #endif > > > 2. Perform the virtual to physical translation in the > cpu_l2cache_xxx() functions using pmap_extract(). But I think this > will require the pmap pointer to be passed to the cpu_l2cache_xxx() > functions, therefore changing the current API. > > > 3.Perform the virtual to physical translation in the > cpu_l2cache_xxx() functions as above, but use the "CP15 c7, Virtual > Address to Physical Address translation operations" to do the > translation. > > > Any advice would be greatly appreciated. > > Cheers, > Ben. > I would suggest that you send the PA to the Level 2 cache routines.. There are only a couple situations that the level 2 cache operations are needed. The most common is the DMA case. The DMA routines already does a pmap_extract to determine if the buffer needs to be bounced or if the buffer is contiguous. The "sync list" version of busdma_machdep.c (http://www.tinguelys.info/mark/freebsd/busdma_machdepV7.c) can be easily extended to also keep the extracted pa. The other situation needing cache operation would be the time we change the page mapping type (normal memory -> device memory). This is a memory mapping operation and the PA is already known. --Mark. From owner-freebsd-arm@FreeBSD.ORG Mon May 23 18:11:52 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 8611E106564A for ; Mon, 23 May 2011 18:11:52 +0000 (UTC) (envelope-from damjan.marion@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1246B8FC1A for ; Mon, 23 May 2011 18:11:51 +0000 (UTC) Received: by bwz12 with SMTP id 12so6946523bwz.13 for ; Mon, 23 May 2011 11:11:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=oshp5fdLs7Hn3VihLdl/Rrm63Hw6mPILw5sBpyya/4w=; b=IEnbq99VtlGWiJODLonj55Q38KJ2mj9PYpH2dGCEF8AWHTKwirdwah3rW4pWd/xw/M IjKHJlQNJlAAJnFcfIEoGq8yZf1GeIwumewi5Hb0pA3OsbHSqtbrpF9bNeF6IveGAeD3 KP6AJALzD3RRWVsYPOOjzqWgPFYIreNSICz2U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=tHJx19mC+ay+swN2MbpjYpwzQ0T/EVMUkKRSVlgILV2RoY2IsJyZYbnb8gPEnP8JZ0 M9Awt9J6oVTdU9BdVNMSfy1CzDu2/8UMc4B/OcuZ9wbwvJA9m34Yj5J3d1cH/JrwWS65 Q1PxzY1rYEvdBMaN9VQjc7vrsJ8IYcZrMLa8w= Received: by 10.204.3.193 with SMTP id 1mr2427915bko.72.1306174310829; Mon, 23 May 2011 11:11:50 -0700 (PDT) Received: from [192.168.123.4] (cpe-109-60-66-194.zg3.cable.xnet.hr [109.60.66.194]) by mx.google.com with ESMTPS id q24sm4068199bks.9.2011.05.23.11.11.49 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 May 2011 11:11:49 -0700 (PDT) From: Damjan Marion Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 23 May 2011 20:11:47 +0200 Message-Id: To: freebsd-arm@freebsd.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: NAND Flash Support Status 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, 23 May 2011 18:11:52 -0000 Hi, What is the status of NAND flash support? I can see that wiki page [1] = is outdated and there is no recent activity on perforce repo. Damjan From owner-freebsd-arm@FreeBSD.ORG Tue May 24 09:24:41 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 328A6106566B for ; Tue, 24 May 2011 09:24:41 +0000 (UTC) (envelope-from ben.r.gray@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id B216D8FC14 for ; Tue, 24 May 2011 09:24:40 +0000 (UTC) Received: by wyf23 with SMTP id 23so6568563wyf.13 for ; Tue, 24 May 2011 02:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jgh73Buq7d8IvPtTR/lo8GelyQ0xD3TIP1azd6gFnSk=; b=NFaHzxzmoPZaQrWjU4NOf74KLGANvBb/dTIXeIQZDhvVt7dDHdBcvPXIU6QQMrUUz5 H5pbF6tDaeyt8PwbuepYURwRuE8/yaEMprUYPTa8P+5rR2J/Xc4euxnn5rldzjEKhRA4 BRejOYP5mou73xqmMWAqt4Ka3xz3I5eqYHlWw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=PpWKOvaF5DyJ33BNREFuuPRCkTxBXM/Zb2mWl+CSK/xfi6u+z7pzZvOXYnWXdzySQU PxELr2KKMapDszZiM8meua5SBPkM0+nXPASuHSH0S7pJ0mOaPQV9z1wMu9/mDRXnjjBd VdWEpFYaBF+3qCqb/CcMRShR02alfNkhUUvao= Received: by 10.227.20.67 with SMTP id e3mr3176317wbb.100.1306229079613; Tue, 24 May 2011 02:24:39 -0700 (PDT) Received: from Bens-MBP.local (ip-80-238-8-128.bskyb.com [80.238.8.128]) by mx.google.com with ESMTPS id l24sm4636076wbc.47.2011.05.24.02.24.38 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 May 2011 02:24:38 -0700 (PDT) Message-ID: <4DDB7955.3060803@gmail.com> Date: Tue, 24 May 2011 10:24:37 +0100 From: Ben Gray User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-arm@freebsd.org References: <4DDA788C.6020506@gmail.com> <4DDA8E4A.6060002@gmail.com> In-Reply-To: <4DDA8E4A.6060002@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: L2 cache functions and physical to virtual mappings 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: Tue, 24 May 2011 09:24:41 -0000 On 23/05/2011 17:41, Mark Tinguely wrote: > On 5/23/2011 10:09 AM, Ben Gray wrote: >> Hi, >> >> I've been working on the OMAP4430 chip (Pandaboard) which uses >> the ARM PL310 L2 cache controller. I've written basic support for >> it, but when it comes to mapping it back into cpu_l2cache_??? >> functions I hit a problem in that these functions take a virtual >> address rather than a physical address. >> >> The PL310 is a PIPT cache and naturally all cache maintenance >> operations use physical addresses. AFAICT the OMAP4430 doesn't use >> the nice cp15 instructions for flushing L2 caches (i.e. "mcr p15, >> 1, r0, c15, c9, 0"), instead operations are performed by writing to >> registers within the controller. >> >> So I guess I'm just after some advice on the best way to get >> around this, I came up with the following options but none are >> particularly neat. >> >> >> 1. Create a compile time #define which indicates the type of >> l2 cache, i.e. pseudo-code >> >> #if defined(L2_CACHE_PHYS_ADDR) >> for (adr= buf & (PAGE_SIZE - 1); adr < len; adr += >> PAGE_SIZE) >> cpu_l2cache_wb_range(pmap_extract(pmap, buf), >> PAGE_SIZE); >> #else >> cpu_l2cache_wb_range(buf, len); >> #endif >> >> >> 2. Perform the virtual to physical translation in the >> cpu_l2cache_xxx() functions using pmap_extract(). But I think this >> will require the pmap pointer to be passed to the cpu_l2cache_xxx() >> functions, therefore changing the current API. >> >> >> 3.Perform the virtual to physical translation in the >> cpu_l2cache_xxx() functions as above, but use the "CP15 c7, Virtual >> Address to Physical Address translation operations" to do the >> translation. >> >> >> Any advice would be greatly appreciated. >> >> Cheers, >> Ben. >> > > I would suggest that you send the PA to the Level 2 cache routines.. > > There are only a couple situations that the level 2 cache operations > are needed. The most common is the DMA case. The DMA routines already > does a pmap_extract to determine if the buffer needs to be bounced or > if the buffer is contiguous. The "sync list" version of > busdma_machdep.c > (http://www.tinguelys.info/mark/freebsd/busdma_machdepV7.c) can be > easily extended to also keep the extracted pa. > > The other situation needing cache operation would be the time we > change the page mapping type (normal memory -> device memory). This is > a memory mapping operation and the PA is already known. > > --Mark. > > Thanks Mark, That is beginning to look like the best idea, and as you say, with your version of the busdma code it looks pretty easy to add support for storing physical addresses. On that note, is your "sync list" busdma ready for testing? I notice it's currently missing the L2 cache functions, but it's easy to add those and if you think it's ready, I'd like to try it out. Cheers, Ben. From owner-freebsd-arm@FreeBSD.ORG Tue May 24 14:05: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 327BB1065670 for ; Tue, 24 May 2011 14:05:12 +0000 (UTC) (envelope-from marktinguely@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id EA5928FC0C for ; Tue, 24 May 2011 14:05:11 +0000 (UTC) Received: by iyj12 with SMTP id 12so8018867iyj.13 for ; Tue, 24 May 2011 07:05:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+oDEDTZ9IixqQJDqmsqTyKlI0/MfQqof8VBqT6Lre0I=; b=KPwE9dB28iuqLraw3FxcNgbmuWLxJm4z5czPHlq42Ku662gR2HWa9bR0Ow93Cbqnac vUsl71ZbL0sdQdzlsRnPBDR/q5WcGDWn1UlzRhiFW6XpW7MzBe17HwroMEq/aSJszQFy RrR+wd3Q04ti64Ip/uPCWOvlC4HOrEsStnG1E= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=PXBvs1P1oq+yAJbFTnAkjtjOKRPImWbzMeN+PG86n1FwUBoBVj23hw8SmAxT5TxWV7 eFetFex3zXHqHkVP2QUu+KRgnmeaXgWt6Ag0uAxP05iV/3RCg3qWK3pN+0N+zuo5zrMv lkRwxbJorb2n/eMmZdHUfHhXNl7q6MXOq0Xtc= Received: by 10.42.144.195 with SMTP id c3mr1288477icv.9.1306245911306; Tue, 24 May 2011 07:05:11 -0700 (PDT) Received: from [192.168.1.111] (c-24-245-26-12.hsd1.mn.comcast.net [24.245.26.12]) by mx.google.com with ESMTPS id ww2sm3092101icb.3.2011.05.24.07.05.09 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 May 2011 07:05:10 -0700 (PDT) Message-ID: <4DDBBB13.30401@gmail.com> Date: Tue, 24 May 2011 09:05:07 -0500 From: Mark Tinguely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Ben Gray References: <4DDA788C.6020506@gmail.com> <4DDA8E4A.6060002@gmail.com> <4DDB7955.3060803@gmail.com> In-Reply-To: <4DDB7955.3060803@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: L2 cache functions and physical to virtual mappings 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: Tue, 24 May 2011 14:05:12 -0000 On 5/24/2011 4:24 AM, Ben Gray wrote: > On 23/05/2011 17:41, Mark Tinguely wrote: >> On 5/23/2011 10:09 AM, Ben Gray wrote: >>> Hi, >>> >>> I've been working on the OMAP4430 chip (Pandaboard) which uses >>> the ARM PL310 L2 cache controller. I've written basic support for >>> it, but when it comes to mapping it back into cpu_l2cache_??? >>> functions I hit a problem in that these functions take a virtual >>> address rather than a physical address. >>> >>> The PL310 is a PIPT cache and naturally all cache maintenance >>> operations use physical addresses. AFAICT the OMAP4430 doesn't use >>> the nice cp15 instructions for flushing L2 caches (i.e. "mcr p15, >>> 1, r0, c15, c9, 0"), instead operations are performed by writing to >>> registers within the controller. >>> >>> So I guess I'm just after some advice on the best way to get >>> around this, I came up with the following options but none are >>> particularly neat. >>> >>> >>> 1. Create a compile time #define which indicates the type of >>> l2 cache, i.e. pseudo-code >>> >>> #if defined(L2_CACHE_PHYS_ADDR) >>> for (adr= buf & (PAGE_SIZE - 1); adr < len; adr += >>> PAGE_SIZE) >>> cpu_l2cache_wb_range(pmap_extract(pmap, buf), >>> PAGE_SIZE); >>> #else >>> cpu_l2cache_wb_range(buf, len); >>> #endif >>> >>> >>> 2. Perform the virtual to physical translation in the >>> cpu_l2cache_xxx() functions using pmap_extract(). But I think this >>> will require the pmap pointer to be passed to the cpu_l2cache_xxx() >>> functions, therefore changing the current API. >>> >>> >>> 3.Perform the virtual to physical translation in the >>> cpu_l2cache_xxx() functions as above, but use the "CP15 c7, Virtual >>> Address to Physical Address translation operations" to do the >>> translation. >>> >>> >>> Any advice would be greatly appreciated. >>> >>> Cheers, >>> Ben. >>> >> >> I would suggest that you send the PA to the Level 2 cache routines.. >> >> There are only a couple situations that the level 2 cache operations >> are needed. The most common is the DMA case. The DMA routines already >> does a pmap_extract to determine if the buffer needs to be bounced or >> if the buffer is contiguous. The "sync list" version of >> busdma_machdep.c >> (http://www.tinguelys.info/mark/freebsd/busdma_machdepV7.c) can be >> easily extended to also keep the extracted pa. >> >> The other situation needing cache operation would be the time we >> change the page mapping type (normal memory -> device memory). This >> is a memory mapping operation and the PA is already known. >> >> --Mark. >> >> > Thanks Mark, > > That is beginning to look like the best idea, and as you say, with > your version of the busdma code it looks pretty easy to add support > for storing physical addresses. > > On that note, is your "sync list" busdma ready for testing? I > notice it's currently missing the L2 cache functions, but it's easy to > add those and if you think it's ready, I'd like to try it out. > > Cheers, > Ben. > > _______________________________________________ > 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" > I believe Semihalf is using this busdma_machdep.c for their ARMv6 support. You may remove the lines "#ifdef FIX_DMAP_BUS_DMASYNC_POSTREAD" and the corresponding "endif". For now it is better to be one the safe side and perform the post read operation and not just rely on the pre-read operations. Rather than implement the routine "pmap_dmap_iscurrent()", you may remove those tests. This is an obscure bug, and ARM does not support devices that performs DMA operations straight from user pages. Mainly cryptology hardware device drivers directly DMA to/from the user mapped page. I combined the L1 and L2 operations into one cache operation; you will have to separate them because your L2 operation uses a PA not a VA. --Mark. From owner-freebsd-arm@FreeBSD.ORG Tue May 24 15:45:23 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 D1F201065675 for ; Tue, 24 May 2011 15:45:23 +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 4F46B8FC22 for ; Tue, 24 May 2011 15:45:23 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 7F080C383B; Tue, 24 May 2011 17:27:50 +0200 (CEST) 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 qyk+SJ2p-ELk; Tue, 24 May 2011 17:27:49 +0200 (CEST) Received: from [10.0.0.79] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 9D4FAC383A; Tue, 24 May 2011 17:27:49 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Rafal Jaworowski In-Reply-To: <4DDBBB13.30401@gmail.com> Date: Tue, 24 May 2011 17:27:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <36EEF760-ADB6-4873-905E-0FBC8050614F@semihalf.com> References: <4DDA788C.6020506@gmail.com> <4DDA8E4A.6060002@gmail.com> <4DDB7955.3060803@gmail.com> <4DDBBB13.30401@gmail.com> To: Mark Tinguely X-Mailer: Apple Mail (2.1084) Cc: freebsd-arm@freebsd.org Subject: Re: L2 cache functions and physical to virtual mappings 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: Tue, 24 May 2011 15:45:24 -0000 On 2011-05-24, at 16:05, Mark Tinguely wrote: > On 5/24/2011 4:24 AM, Ben Gray wrote: >> On 23/05/2011 17:41, Mark Tinguely wrote: >>> On 5/23/2011 10:09 AM, Ben Gray wrote: >>>> Hi, >>>>=20 >>>> I've been working on the OMAP4430 chip (Pandaboard) which uses = the ARM PL310 L2 cache controller. I've written basic support for it, = but when it comes to mapping it back into cpu_l2cache_??? functions I = hit a problem in that these functions take a virtual address rather than = a physical address. >>>>=20 >>>> The PL310 is a PIPT cache and naturally all cache maintenance = operations use physical addresses. AFAICT the OMAP4430 doesn't use the = nice cp15 instructions for flushing L2 caches (i.e. "mcr p15, 1, r0, = c15, c9, 0"), instead operations are performed by writing to registers = within the controller. >>>>=20 >>>> So I guess I'm just after some advice on the best way to get = around this, I came up with the following options but none are = particularly neat. >>>>=20 >>>>=20 >>>> 1. Create a compile time #define which indicates the type of = l2 cache, i.e. pseudo-code >>>>=20 >>>> #if defined(L2_CACHE_PHYS_ADDR) >>>> for (adr=3D buf & (PAGE_SIZE - 1); adr < len; adr +=3D= PAGE_SIZE) >>>> cpu_l2cache_wb_range(pmap_extract(pmap, buf), = PAGE_SIZE); >>>> #else >>>> cpu_l2cache_wb_range(buf, len); >>>> #endif >>>>=20 >>>>=20 >>>> 2. Perform the virtual to physical translation in the = cpu_l2cache_xxx() functions using pmap_extract(). But I think this will = require the pmap pointer to be passed to the cpu_l2cache_xxx() = functions, therefore changing the current API. >>>>=20 >>>>=20 >>>> 3.Perform the virtual to physical translation in the = cpu_l2cache_xxx() functions as above, but use the "CP15 c7, Virtual = Address to Physical Address translation operations" to do the = translation. >>>>=20 >>>>=20 >>>> Any advice would be greatly appreciated. >>>>=20 >>>> Cheers, >>>> Ben. >>>>=20 >>>=20 >>> I would suggest that you send the PA to the Level 2 cache routines.. >>>=20 >>> There are only a couple situations that the level 2 cache operations = are needed. The most common is the DMA case. The DMA routines already = does a pmap_extract to determine if the buffer needs to be bounced or if = the buffer is contiguous. The "sync list" version of busdma_machdep.c = (http://www.tinguelys.info/mark/freebsd/busdma_machdepV7.c) can be = easily extended to also keep the extracted pa. >>>=20 >>> The other situation needing cache operation would be the time we = change the page mapping type (normal memory -> device memory). This is a = memory mapping operation and the PA is already known. >>>=20 >>> --Mark. >>>=20 >>>=20 >> Thanks Mark, >>=20 >> That is beginning to look like the best idea, and as you say, with = your version of the busdma code it looks pretty easy to add support for = storing physical addresses. >>=20 >> On that note, is your "sync list" busdma ready for testing? I = notice it's currently missing the L2 cache functions, but it's easy to = add those and if you think it's ready, I'd like to try it out. >>=20 >> Cheers, >> Ben. >>=20 >> _______________________________________________ >> 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" >>=20 >=20 > I believe Semihalf is using this busdma_machdep.c for their ARMv6 = support. Yes, for example this [oldish] diff includes busdma for v6: = http://people.freebsd.org/~raj/patches/arm/dove_v6.diff Rafal From owner-freebsd-arm@FreeBSD.ORG Wed May 25 08:07:03 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 6B1351065670 for ; Wed, 25 May 2011 08:07:03 +0000 (UTC) (envelope-from ben.r.gray@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id ECBA78FC1A for ; Wed, 25 May 2011 08:07:02 +0000 (UTC) Received: by wyf23 with SMTP id 23so7565170wyf.13 for ; Wed, 25 May 2011 01:07:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ExQlBCaLOH7bCIBRbJeUzgMGxn74DpOY7aaAzjurA2I=; b=Fop6uGBtoPd5mSYWaBlAasPzPqZYM/AfohvKdBkimSD5e5kOxR+qT/9/SXB36XVLam sPTA6KHn9WJGHP8Zkz2746ZK3u3rqzSzDphhGKr41o/so4US0wECXPJFPnFWOOa0MFyJ 4ydNJz5abdWE3QpgD3p7dvwx/TN9TQOSM0ZAA= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=P+nnNC1m/ryNg6jQ5C2O5qTG+mvuX4gsp69zzCXHpqDvKYJEpc4Bpxh1JhXsCpq08s LnSizf8pMEdRVHzQHf0I3ml++p1P0QJpAtW976hzM0jgqX1pkXIVXTLIWx3n4wk2nj8e hWtleDAD38XpSRDBVr26C4zmaui6MDwBVcvTY= Received: by 10.227.37.22 with SMTP id v22mr4311923wbd.27.1306310821784; Wed, 25 May 2011 01:07:01 -0700 (PDT) Received: from Bens-MBP.local (ip-80-238-8-128.bskyb.com [80.238.8.128]) by mx.google.com with ESMTPS id m21sm198069wbh.8.2011.05.25.01.06.59 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 May 2011 01:07:00 -0700 (PDT) Message-ID: <4DDCB8A2.4090708@gmail.com> Date: Wed, 25 May 2011 09:06:58 +0100 From: Ben Gray User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Rafal Jaworowski References: <4DDA788C.6020506@gmail.com> <4DDA8E4A.6060002@gmail.com> <4DDB7955.3060803@gmail.com> <4DDBBB13.30401@gmail.com> <36EEF760-ADB6-4873-905E-0FBC8050614F@semihalf.com> In-Reply-To: <36EEF760-ADB6-4873-905E-0FBC8050614F@semihalf.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: L2 cache functions and physical to virtual mappings 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, 25 May 2011 08:07:03 -0000 On 24/05/2011 16:27, Rafal Jaworowski wrote: > On 2011-05-24, at 16:05, Mark Tinguely wrote: > >> On 5/24/2011 4:24 AM, Ben Gray wrote: >>> On 23/05/2011 17:41, Mark Tinguely wrote: >>>> On 5/23/2011 10:09 AM, Ben Gray wrote: >>>>> Hi, >>>>> >>>>> I've been working on the OMAP4430 chip (Pandaboard) which uses the ARM PL310 L2 cache controller. I've written basic support for it, but when it comes to mapping it back into cpu_l2cache_??? functions I hit a problem in that these functions take a virtual address rather than a physical address. >>>>> >>>>> The PL310 is a PIPT cache and naturally all cache maintenance operations use physical addresses. AFAICT the OMAP4430 doesn't use the nice cp15 instructions for flushing L2 caches (i.e. "mcr p15, 1, r0, c15, c9, 0"), instead operations are performed by writing to registers within the controller. >>>>> >>>>> So I guess I'm just after some advice on the best way to get around this, I came up with the following options but none are particularly neat. >>>>> >>>>> >>>>> 1. Create a compile time #define which indicates the type of l2 cache, i.e. pseudo-code >>>>> >>>>> #if defined(L2_CACHE_PHYS_ADDR) >>>>> for (adr= buf& (PAGE_SIZE - 1); adr< len; adr += PAGE_SIZE) >>>>> cpu_l2cache_wb_range(pmap_extract(pmap, buf), PAGE_SIZE); >>>>> #else >>>>> cpu_l2cache_wb_range(buf, len); >>>>> #endif >>>>> >>>>> >>>>> 2. Perform the virtual to physical translation in the cpu_l2cache_xxx() functions using pmap_extract(). But I think this will require the pmap pointer to be passed to the cpu_l2cache_xxx() functions, therefore changing the current API. >>>>> >>>>> >>>>> 3.Perform the virtual to physical translation in the cpu_l2cache_xxx() functions as above, but use the "CP15 c7, Virtual Address to Physical Address translation operations" to do the translation. >>>>> >>>>> >>>>> Any advice would be greatly appreciated. >>>>> >>>>> Cheers, >>>>> Ben. >>>>> >>>> I would suggest that you send the PA to the Level 2 cache routines.. >>>> >>>> There are only a couple situations that the level 2 cache operations are needed. The most common is the DMA case. The DMA routines already does a pmap_extract to determine if the buffer needs to be bounced or if the buffer is contiguous. The "sync list" version of busdma_machdep.c (http://www.tinguelys.info/mark/freebsd/busdma_machdepV7.c) can be easily extended to also keep the extracted pa. >>>> >>>> The other situation needing cache operation would be the time we change the page mapping type (normal memory -> device memory). This is a memory mapping operation and the PA is already known. >>>> >>>> --Mark. >>>> >>>> >>> Thanks Mark, >>> >>> That is beginning to look like the best idea, and as you say, with your version of the busdma code it looks pretty easy to add support for storing physical addresses. >>> >>> On that note, is your "sync list" busdma ready for testing? I notice it's currently missing the L2 cache functions, but it's easy to add those and if you think it's ready, I'd like to try it out. >>> >>> Cheers, >>> Ben. >>> >>> _______________________________________________ >>> 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" >>> >> I believe Semihalf is using this busdma_machdep.c for their ARMv6 support. > Yes, for example this [oldish] diff includes busdma for v6: http://people.freebsd.org/~raj/patches/arm/dove_v6.diff > > Rafal > Thanks guys - hopefully this weekend I'll have some time to have a play with it. I'll let you know if I hit any problems. Once again, thanks a lot. Ben.