From owner-freebsd-arm@FreeBSD.ORG Sun Sep 2 21:31:22 2012 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 AACD7106564A; Sun, 2 Sep 2012 21:31:22 +0000 (UTC) (envelope-from adutkowski@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 79C8D8FC1B; Sun, 2 Sep 2012 21:31:22 +0000 (UTC) Received: by dadr6 with SMTP id r6so3058097dad.13 for ; Sun, 02 Sep 2012 14:31:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=ZyAxMa7DvXF56Jhl+3N1Rq/uCryZxcIWUHTh48PSsMg=; b=vzzP4IGyJrCITCNDsx7LCahrdkP523QaBhLAe6uhQiDLpbsTfxrrKtuufLA9SxV/wn zP8Bec6gvFv1Z8kPJz4EAiCmP50Khycw4T9nd40pOa4Wr3acgoZEvsV+2ZdLPT7uyCZV D9Q37Rf9zRzZW0EOUKVUBwCcXBPE93txmEfWferYm5YMwAioch6YtmpcqJ2vlE9iqzf6 /xevtfe6PVHyMEHzmKy5SmZqVcyUknI3Eqam+jm+9QB1D9LWUEqrJq4z70oSm95QJ4zP Odndg5uKlUD744JRXkk/Ho4q2O4OI+L31k3kyWqY/KsSHMQwpchWaRtQjyaevNT4LeUO xqkQ== MIME-Version: 1.0 Received: by 10.68.221.70 with SMTP id qc6mr33607896pbc.92.1346621482043; Sun, 02 Sep 2012 14:31:22 -0700 (PDT) Sender: adutkowski@gmail.com Received: by 10.66.220.169 with HTTP; Sun, 2 Sep 2012 14:31:21 -0700 (PDT) Date: Sun, 2 Sep 2012 23:31:21 +0200 X-Google-Sender-Auth: hqOJDkGrpUsjezDHiCZ6ou63RLY Message-ID: From: Aleksander Dutkowski To: freebsd-arm@freebsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: availability of interrupts during bootup process 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, 02 Sep 2012 21:31:22 -0000 hello! I have PMIC (TWL4030) module connected to the SoC (ARM/OMAP3) via i2c (iicbus). Current solution is that i2c_attach calls bus_generic_attach(dev); which calls my pmic probe/attach functions, but main configuration of PMIC in done after drivers setup by config_intrhook. But I need it to be configured during device attaching, because usb ehci driver depends on it. Is it possbile? I've tried it but it hangs on waiting for i2c interrupt, but someone told me, that interrupts are available during bootup for some time. -- regards aleek From owner-freebsd-arm@FreeBSD.ORG Mon Sep 3 11:09:15 2012 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 781F9106564A for ; Mon, 3 Sep 2012 11:09:15 +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 6290E8FC1C for ; Mon, 3 Sep 2012 11:09:15 +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 q83B9FlL042390 for ; Mon, 3 Sep 2012 11:09:15 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q83B9DTT042046 for freebsd-arm@FreeBSD.org; Mon, 3 Sep 2012 11:09:13 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 3 Sep 2012 11:09:13 GMT Message-Id: <201209031109.q83B9DTT042046@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, 03 Sep 2012 11:09:15 -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 kern/171096 arm [arm][xscale][ixp]Allow 16bit access on PCI bus o arm/166256 arm build fail in pmap.c 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/158950 arm arm/sheevaplug fails fsx when mmap operations are enab o arm/155894 arm [patch] Enable at91 booting from SDHC (high capacity) p 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/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 14 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Sep 3 16:06:17 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1C9AE1065670 for ; Mon, 3 Sep 2012 16:06:17 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail-out.m-online.net (mail-out.m-online.net [IPv6:2001:a60:0:28:0:1:25:1]) by mx1.freebsd.org (Postfix) with ESMTP id 962288FC0C for ; Mon, 3 Sep 2012 16:06:16 +0000 (UTC) Received: from frontend1.mail.m-online.net (frontend1.mail.intern.m-online.net [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id 3X9bdM11dhz3hhVn for ; Mon, 3 Sep 2012 18:06:15 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.6.68]) by mail.m-online.net (Postfix) with ESMTP id 3X9bdM0L28zbbfg for ; Mon, 3 Sep 2012 18:06:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.180]) by localhost (dynscan1.mail.m-online.net [192.168.6.68]) (amavisd-new, port 10024) with ESMTP id ZH44a4ikW7oT for ; Mon, 3 Sep 2012 18:06:11 +0200 (CEST) Received: from mail.reifenberger.com (ppp-93-104-55-178.dynamic.mnet-online.de [93.104.55.178]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPS for ; Mon, 3 Sep 2012 18:06:10 +0200 (CEST) Received: by mail.reifenberger.com (Postfix, from userid 1001) id 4A9632699D; Mon, 3 Sep 2012 18:06:10 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.reifenberger.com (Postfix) with ESMTP id 2B7532699A for ; Mon, 3 Sep 2012 18:06:10 +0200 (CEST) Date: Mon, 3 Sep 2012 18:06:09 +0200 (CEST) From: Michael Reifenberger To: freebsd-arm@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: FreeBSD on Odroid-X 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, 03 Sep 2012 16:06:17 -0000 Hi, is someone already working on a Odroid-X Port? ODROID-X is a $129 ARMv7 development board that packs four Cortex-A9 cores (Samsung Exynos 4412) along with Mali-400 graphics. Currently it runs linaro (Ubuntu) and Android 4.0.4 quite fastly. Further Infos: http://www.hardkernel.com/renewal_2011/products/prdt_info.php?g_code=G133999328931 http://dev.odroid.com/projects/odroid-xq http://com.odroid.com/sigong/nf_file_board/nfile_board_view.php?keyword=&tag=&bid=64 Bye/2 --- Michael Reifenberger Michael@Reifenberger.com http://www.Reifenberger.com From owner-freebsd-arm@FreeBSD.ORG Mon Sep 3 22:54:32 2012 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 C9121106564A for ; Mon, 3 Sep 2012 22:54:32 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh10.mail.rice.edu (mh10.mail.rice.edu [128.42.201.30]) by mx1.freebsd.org (Postfix) with ESMTP id 90F578FC14 for ; Mon, 3 Sep 2012 22:54:32 +0000 (UTC) Received: from mh10.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh10.mail.rice.edu (Postfix) with ESMTP id ECE09604EA; Mon, 3 Sep 2012 17:54:24 -0500 (CDT) Received: from mh10.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh10.mail.rice.edu (Postfix) with ESMTP id EB280604C8; Mon, 3 Sep 2012 17:54:24 -0500 (CDT) X-Virus-Scanned: by amavis-2.7.0 at mh10.mail.rice.edu, auth channel Received: from mh10.mail.rice.edu ([127.0.0.1]) by mh10.mail.rice.edu (mh10.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id EW83ZfWO3B3B; Mon, 3 Sep 2012 17:54:24 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh10.mail.rice.edu (Postfix) with ESMTPSA id 74966603B0; Mon, 3 Sep 2012 17:54:24 -0500 (CDT) Message-ID: <5045351F.6060201@rice.edu> Date: Mon, 03 Sep 2012 17:54:23 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:8.0) Gecko/20111113 Thunderbird/8.0 MIME-Version: 1.0 To: Ian Lepore References: <502FD67A.7030003@rice.edu> <1345315508.27688.260.camel@revolution.hippie.lan> <503D12AE.1050705@rice.edu> <1346350374.1140.525.camel@revolution.hippie.lan> In-Reply-To: <1346350374.1140.525.camel@revolution.hippie.lan> Content-Type: multipart/mixed; boundary="------------090307060108080103080901" Cc: "arm@freebsd.org" Subject: Re: arm pmap locking 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, 03 Sep 2012 22:54:33 -0000 This is a multi-part message in MIME format. --------------090307060108080103080901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 08/30/2012 13:12, Ian Lepore wrote: > On Tue, 2012-08-28 at 13:49 -0500, Alan Cox wrote: >> Can you please retry with the attached patch? For the time being, I >> decided to address the above problem by simply enabling recursion on the >> new pmap lock. As I mentioned in my prior message, the lock recursion >> in the arm pmap is a mistake. However, I'd rather not change two things >> at once, i.e., replace the page queues lock and fix the lock recursion. >> I'll take a look at eliminating the lock recursion later this week. >> >> Thanks, >> Alan >> > Sorry for the delay, I finally got around to trying this today, and it > seems to be working well initially -- it boots to multiuser and the only > difference in the dmesg.boot with and without the patch is the compile > date, and the kernel image is 128 bytes smaller with the patch. I've > got DIAGNOSTIC and INVARIANTS enabled; I'll run with the patch in place > and let you know if anything glitches. > Could you please test the attached patch? This is a small step toward disentangling the arm pmap locking. Alan --------------090307060108080103080901 Content-Type: text/plain; name="arm_pmap10.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="arm_pmap10.patch" Index: arm/arm/pmap.c =================================================================== --- arm/arm/pmap.c (revision 240002) +++ arm/arm/pmap.c (working copy) @@ -1600,7 +1600,6 @@ static void pmap_enter_pv(struct vm_page *pg, struct pv_entry *pve, pmap_t pm, vm_offset_t va, u_int flags) { - int km; rw_assert(&pvh_global_lock, RA_WLOCKED); @@ -1617,10 +1616,8 @@ pmap_enter_pv(struct vm_page *pg, struct pv_entry TAILQ_INSERT_HEAD(&pg->md.pv_list, pve, pv_list); TAILQ_INSERT_HEAD(&pve->pv_pmap->pm_pvlist, pve, pv_plist); PMAP_UNLOCK(pmap_kernel()); - rw_wunlock(&pvh_global_lock); if ((pve = pmap_get_pv_entry()) == NULL) - panic("pmap_kenter_internal: no pv entries"); - rw_wlock(&pvh_global_lock); + panic("pmap_kenter_pv: no pv entries"); if (km) PMAP_LOCK(pmap_kernel()); } @@ -2835,11 +2832,8 @@ pmap_kenter_internal(vm_offset_t va, vm_offset_t p if (pvzone != NULL && (m = vm_phys_paddr_to_vm_page(pa))) { rw_wlock(&pvh_global_lock); if (!TAILQ_EMPTY(&m->md.pv_list) || m->md.pv_kva) { - /* release vm_page lock for pv_entry UMA */ - rw_wunlock(&pvh_global_lock); if ((pve = pmap_get_pv_entry()) == NULL) panic("pmap_kenter_internal: no pv entries"); - rw_wlock(&pvh_global_lock); PMAP_LOCK(pmap_kernel()); pmap_enter_pv(m, pve, pmap_kernel(), va, PVF_WRITE | PVF_UNMAN); --------------090307060108080103080901-- From owner-freebsd-arm@FreeBSD.ORG Tue Sep 4 01:44:05 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 49E8E106564A for ; Tue, 4 Sep 2012 01:44:05 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id E49D58FC0A for ; Tue, 4 Sep 2012 01:44:04 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id q841i3bb045281 for ; Mon, 3 Sep 2012 19:44:04 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) 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 q841i1HZ040570; Mon, 3 Sep 2012 19:44:01 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Alan Cox In-Reply-To: <5045351F.6060201@rice.edu> References: <502FD67A.7030003@rice.edu> <1345315508.27688.260.camel@revolution.hippie.lan> <503D12AE.1050705@rice.edu> <1346350374.1140.525.camel@revolution.hippie.lan> <5045351F.6060201@rice.edu> Content-Type: text/plain; charset="us-ascii" Date: Mon, 03 Sep 2012 19:44:01 -0600 Message-ID: <1346723041.1140.602.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "arm@freebsd.org" Subject: Re: arm pmap locking 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, 04 Sep 2012 01:44:05 -0000 On Mon, 2012-09-03 at 17:54 -0500, Alan Cox wrote: > On 08/30/2012 13:12, Ian Lepore wrote: > > On Tue, 2012-08-28 at 13:49 -0500, Alan Cox wrote: > >> Can you please retry with the attached patch? For the time being, I > >> decided to address the above problem by simply enabling recursion on the > >> new pmap lock. As I mentioned in my prior message, the lock recursion > >> in the arm pmap is a mistake. However, I'd rather not change two things > >> at once, i.e., replace the page queues lock and fix the lock recursion. > >> I'll take a look at eliminating the lock recursion later this week. > >> > >> Thanks, > >> Alan > >> > > Sorry for the delay, I finally got around to trying this today, and it > > seems to be working well initially -- it boots to multiuser and the only > > difference in the dmesg.boot with and without the patch is the compile > > date, and the kernel image is 128 bytes smaller with the patch. I've > > got DIAGNOSTIC and INVARIANTS enabled; I'll run with the patch in place > > and let you know if anything glitches. > > > > Could you please test the attached patch? This is a small step toward > disentangling the arm pmap locking. > > Alan > Applied the patch, it's running just fine. -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Sep 4 03:06:50 2012 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6F17E106566C; Tue, 4 Sep 2012 03:06:50 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 428B58FC1A; Tue, 4 Sep 2012 03:06:50 +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 q8436oPg000420; Tue, 4 Sep 2012 03:06:50 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q8436nmo000395; Tue, 4 Sep 2012 03:06:50 GMT (envelope-from linimon) Date: Tue, 4 Sep 2012 03:06:50 GMT Message-Id: <201209040306.q8436nmo000395@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org, linimon@FreeBSD.org, linimon@FreeBSD.org, freebsd-ports-bugs@FreeBSD.org, linimon@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: ports/170946: [patch] mark certain ports broken on ARM 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, 04 Sep 2012 03:06:50 -0000 Synopsis: [patch] mark certain ports broken on ARM State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Tue Sep 4 03:06:31 UTC 2012 State-Changed-Why: committed. Responsible-Changed-From-To: freebsd-ports-bugs->linimon Responsible-Changed-By: linimon Responsible-Changed-When: Tue Sep 4 03:06:31 UTC 2012 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=170946 From owner-freebsd-arm@FreeBSD.ORG Tue Sep 4 16:58:28 2012 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 25812106566C; Tue, 4 Sep 2012 16:58:28 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id BC9A78FC08; Tue, 4 Sep 2012 16:58:27 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id q84GwKKN059167; Tue, 4 Sep 2012 10:58:20 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) 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 q84GwHat041353; Tue, 4 Sep 2012 10:58:17 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: freebsd-arm@freebsd.org Content-Type: multipart/mixed; boundary="=-nhYas3YqMWIkbv0iBerz" Date: Tue, 04 Sep 2012 10:58:17 -0600 Message-ID: <1346777897.1140.633.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-mips@freebsd.org Subject: busdma buffer management enhancements - call for review and test 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, 04 Sep 2012 16:58:28 -0000 --=-nhYas3YqMWIkbv0iBerz Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The attached set of patches enhances the ARM v4/v5 busdma management of small DMA buffers, especially for BUS_DMA_COHERENT and uncacheable memory. The existing implementation uses malloc(9) to allocate buffers, then uses arm_remap_nocache() to make the page(s) containing the buffers uncacheable, even when those pages contain data other than DMA buffers. The attached patches address this by: * Adding support for pmap_page_set_memattr() and VM_MEMATTR_UNCACHEABLE to the ARM v4 pmap implemenation. * Adding new common code usable by any platform that uses uma(9) to manage pools of power-of-two sized buffers, keeping them sized and aligned as required to help maintain cache coherency. * Modifying the busdma implementation to use the new pool manager to manage pools of both regular and uncacheable buffers, and also to use uma(9) to manage a pool of map structures. * Using knowledge of the alignment and padding of pool-allocated buffers to avoid doing partial cache line flushes on those buffers. I'm CC'ing freebsd-mips because I think these patches can be adapted to the MIPS busdma implementation as well. The new busdma_bufalloc.[ch] code isn't arm-specific, and shouldn't live in sys/arm/arm/, but I don't know where it should go. Once we have ARM and MIPS able to efficiently manage small cache-aligned DMA buffers, the stage is set to begin updating device drivers to allocate buffers individually, rather than allocating huge chunks and sub-dividing them, possibly violating cache line boundaries in doing so. I've been running these for a couple days on DreamPlug and Atmel hardware (the latter in an 8.x environment) without problems. -- Ian --=-nhYas3YqMWIkbv0iBerz Content-Disposition: attachment; filename="arm_pmap_page_set_memattr.diff" Content-Type: text/x-patch; name="arm_pmap_page_set_memattr.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit # HG changeset patch # User Ian Lepore # Date 1346609105 21600 # Node ID 0d90c8ad4bb328c5b9c6e9a515f571b1a71e9568 # Parent 0599cbc079c9fbd7ed53b525fafff622b939a318 Add ARM v4/v5 support for pmap_page_set_memattr() and one new attribute, VM_MEMATTR_UNCACHEABLE. This helps pave the way for changes in the ARM busdma implementation, including the ability to use kmem_alloc_attr() to allocate large regions of uncached memory which aren't necessarily contiguous, and to use uma(9) to efficiently sub-allocate uncached pages for small IO buffers. Right now, UNCACHEABLE disables both cache and write buffering on the page. In the future we may want more fine-grained control with separate defines, for cache and buffering, and also the armv6+ world may have additional attributes (such as SHARED). diff -r 0599cbc079c9 -r 0d90c8ad4bb3 sys/arm/arm/pmap.c --- sys/arm/arm/pmap.c Sun Sep 02 11:44:13 2012 -0600 +++ sys/arm/arm/pmap.c Sun Sep 02 12:05:05 2012 -0600 @@ -1392,7 +1392,8 @@ pmap_fix_cache(struct vm_page *pg, pmap_ (pv->pv_flags & PVF_NC)) { pv->pv_flags &= ~PVF_NC; - pmap_set_cache_entry(pv, pm, va, 1); + if (!(pg->md.pv_memattr & VM_MEMATTR_UNCACHEABLE)) + pmap_set_cache_entry(pv, pm, va, 1); continue; } /* user is no longer sharable and writable */ @@ -1401,7 +1402,8 @@ pmap_fix_cache(struct vm_page *pg, pmap_ !pmwc && (pv->pv_flags & PVF_NC)) { pv->pv_flags &= ~(PVF_NC | PVF_MWC); - pmap_set_cache_entry(pv, pm, va, 1); + if (!(pg->md.pv_memattr & VM_MEMATTR_UNCACHEABLE)) + pmap_set_cache_entry(pv, pm, va, 1); } } @@ -1452,15 +1454,16 @@ pmap_clearbit(struct vm_page *pg, u_int if (!(oflags & maskbits)) { if ((maskbits & PVF_WRITE) && (pv->pv_flags & PVF_NC)) { - /* It is safe to re-enable cacheing here. */ - PMAP_LOCK(pm); - l2b = pmap_get_l2_bucket(pm, va); - ptep = &l2b->l2b_kva[l2pte_index(va)]; - *ptep |= pte_l2_s_cache_mode; - PTE_SYNC(ptep); - PMAP_UNLOCK(pm); + if (!(pg->md.pv_memattr & + VM_MEMATTR_UNCACHEABLE)) { + PMAP_LOCK(pm); + l2b = pmap_get_l2_bucket(pm, va); + ptep = &l2b->l2b_kva[l2pte_index(va)]; + *ptep |= pte_l2_s_cache_mode; + PTE_SYNC(ptep); + PMAP_UNLOCK(pm); + } pv->pv_flags &= ~(PVF_NC | PVF_MWC); - } continue; } @@ -1489,7 +1492,9 @@ pmap_clearbit(struct vm_page *pg, u_int * permission. */ if (maskbits & PVF_WRITE) { - npte |= pte_l2_s_cache_mode; + if (!(pg->md.pv_memattr & + VM_MEMATTR_UNCACHEABLE)) + npte |= pte_l2_s_cache_mode; pv->pv_flags &= ~(PVF_NC | PVF_MWC); } } else @@ -1830,6 +1835,7 @@ pmap_page_init(vm_page_t m) { TAILQ_INIT(&m->md.pv_list); + m->md.pv_memattr = VM_MEMATTR_DEFAULT; } /* @@ -3427,7 +3433,8 @@ do_l2b_alloc: (m->oflags & VPO_UNMANAGED) == 0) vm_page_aflag_set(m, PGA_WRITEABLE); } - npte |= pte_l2_s_cache_mode; + if (!(m->md.pv_memattr & VM_MEMATTR_UNCACHEABLE)) + npte |= pte_l2_s_cache_mode; if (m && m == opg) { /* * We're changing the attrs of an existing mapping. @@ -4963,3 +4970,24 @@ pmap_devmap_find_va(vm_offset_t va, vm_s return (NULL); } +void +pmap_page_set_memattr(vm_page_t m, vm_memattr_t ma) +{ + /* + * Remember the memattr in a field that gets used to set the appropriate + * bits in the PTEs as mappings are established. + */ + m->md.pv_memattr = ma; + + /* + * It appears that this function can only be called before any mappings + * for the page are established on ARM. If this ever changes, this code + * will need to walk the pv_list and make each of the existing mappings + * uncacheable, being careful to sync caches and PTEs (and maybe + * invalidate TLB?) for any current mapping it modifies. + */ + if (m->md.pv_kva != 0 || TAILQ_FIRST(&m->md.pv_list) != NULL) + panic("Can't change memattr on page with existing mappings"); +} + + diff -r 0599cbc079c9 -r 0d90c8ad4bb3 sys/arm/include/pmap.h --- sys/arm/include/pmap.h Sun Sep 02 11:44:13 2012 -0600 +++ sys/arm/include/pmap.h Sun Sep 02 12:05:05 2012 -0600 @@ -97,10 +97,10 @@ enum mem_type { #endif -#define pmap_page_get_memattr(m) VM_MEMATTR_DEFAULT +#define pmap_page_get_memattr(m) ((m)->md.pv_memattr) #define pmap_page_is_mapped(m) (!TAILQ_EMPTY(&(m)->md.pv_list)) #define pmap_page_is_write_mapped(m) (((m)->aflags & PGA_WRITEABLE) != 0) -#define pmap_page_set_memattr(m, ma) (void)0 +void pmap_page_set_memattr(vm_page_t m, vm_memattr_t ma); /* * Pmap stuff @@ -120,6 +120,7 @@ struct pv_entry; struct md_page { int pvh_attrs; + vm_memattr_t pv_memattr; vm_offset_t pv_kva; /* first kernel VA mapping */ TAILQ_HEAD(,pv_entry) pv_list; }; diff -r 0599cbc079c9 -r 0d90c8ad4bb3 sys/arm/include/vm.h --- sys/arm/include/vm.h Sun Sep 02 11:44:13 2012 -0600 +++ sys/arm/include/vm.h Sun Sep 02 12:05:05 2012 -0600 @@ -29,7 +29,8 @@ #ifndef _MACHINE_VM_H_ #define _MACHINE_VM_H_ -/* Memory attribute configuration is not (yet) implemented. */ +/* Memory attribute configuration. */ #define VM_MEMATTR_DEFAULT 0 +#define VM_MEMATTR_UNCACHEABLE 1 #endif /* !_MACHINE_VM_H_ */ --=-nhYas3YqMWIkbv0iBerz Content-Disposition: attachment; filename="arm_busdma_bufalloc.diff" Content-Type: text/x-patch; name="arm_busdma_bufalloc.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit # HG changeset patch # User Ian Lepore # Date 1346768587 21600 # Node ID a84eaa62a91f0993e70448863192b7a057c227b8 # Parent c327e2b8786cd9f714d9f9df42961a76c0ab0f16 Create an architecture-agnostic buffer pool manager that uses uma(9) to manage a set of power-of-2 sized buffers for bus_dmamem_alloc(). This allows the caller to provide the back-end allocator uma allocator, allowing full control of the memory pages backing the pool. For convenience, it provides an optional builtin allocator that provides pages allocated with the VM_MEMATTR_UNCACHEABLE attribute, for managing pools of DMA buffers for BUS_DMA_COHERENT or BUS_DMA_NOCACHE. This also allows the caller to specify a minimum alignment, and it ensures that all buffers start on a boundary and have a length that's a multiple of that value, to avoid using buffers that trigger partial cache line flushes. Since this is architecture-agnostic, it shouldn't live in arm/arm, but I'm not sure what the right place is. diff -r c327e2b8786c -r a84eaa62a91f sys/arm/arm/busdma_bufalloc.c --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ sys/arm/arm/busdma_bufalloc.c Tue Sep 04 08:23:07 2012 -0600 @@ -0,0 +1,177 @@ +/*- + * Copyright (c) 2012 Ian Lepore + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD: $"); + +/* + * Buffer allocation support routines for bus_dmamem_alloc implementations. + */ + +#include +#include +#include +#include + +#include +#include +#include +#include + +#include + +/* + * We manage buffer zones up to a page in size. Buffers larger than a page can + * be managed by one of the kernel's page-oriented memory allocation routines as + * efficiently as what we can do here. Also, a page is the largest size for + * which we can g'tee contiguity when using uma, and contiguity is one of the + * requirements we have to fulfill. + */ +#define MIN_ZONE_BUFSIZE 32 +#define MAX_ZONE_BUFSIZE PAGE_SIZE + +/* + * The static array of 12 bufzones is big enough to handle all the zones for the + * smallest supported allocation size of 32 through the largest supported page + * size of 64K. If you up the biggest page size number, up the array size too. + * Basically the size of the array needs to be log2(maxsize)-log2(minsize)+1, + * but I don't know of an easy way to express that as a compile-time constant. + */ +#if PAGE_SIZE > 65536 +#error Unsupported page size +#endif + +struct busdma_bufalloc { + bus_size_t min_size; + size_t num_zones; + struct busdma_bufzone buf_zones[12]; +}; + +busdma_bufalloc_t +busdma_bufalloc_create(const char *name, bus_size_t minimum_alignment, + uma_alloc alloc_func, uma_free free_func, u_int32_t zcreate_flags) +{ + struct busdma_bufalloc *ba; + struct busdma_bufzone *bz; + int i; + bus_size_t cursize; + + ba = malloc(sizeof(struct busdma_bufalloc), M_DEVBUF, + M_ZERO | M_WAITOK); + if (ba == NULL) + panic("Cannot allocate busdma_bufalloc for %s", name); + + ba->min_size = MAX(MIN_ZONE_BUFSIZE, minimum_alignment); + + /* + * Each uma zone is created with an alignment of size-1, meaning that + * the alignment is equal to the size (I.E., 64 byte buffers are aligned + * to 64 byte boundaries, etc). This allows for a fast efficient test + * when deciding whether a pool buffer meets the constraints of a given + * tag used for allocation: the buffer is usable if tag->alignment <= + * bufzone->size. + */ + for (i = 0, bz = ba->buf_zones, cursize = ba->min_size; + i < nitems(ba->buf_zones) && cursize <= MAX_ZONE_BUFSIZE; + ++i, ++bz, cursize <<= 1) { + snprintf(bz->name, sizeof(bz->name), "dma %.10s %lu", + name, cursize); + bz->size = cursize; + bz->umazone = uma_zcreate(bz->name, bz->size, + NULL, NULL, NULL, NULL, bz->size - 1, zcreate_flags); + if (bz->umazone == NULL) { + busdma_bufalloc_destroy(ba); + return (NULL); + } + if (alloc_func != NULL) + uma_zone_set_allocf(bz->umazone, alloc_func); + if (free_func != NULL) + uma_zone_set_freef(bz->umazone, free_func); + ++ba->num_zones; + } + + return (ba); +} + +void +busdma_bufalloc_destroy(busdma_bufalloc_t ba) +{ + struct busdma_bufzone *bz; + int i; + + if (ba == NULL) + return; + + for (i = 0, bz = ba->buf_zones; i < ba->num_zones; ++i, ++bz) { + uma_zdestroy(bz->umazone); + } + + free(ba, M_DEVBUF); +} + +struct busdma_bufzone * +busdma_bufalloc_findzone(busdma_bufalloc_t ba, bus_size_t size) +{ + struct busdma_bufzone *bz; + int i; + + if (size > MAX_ZONE_BUFSIZE) + return (NULL); + + for (i = 0, bz = ba->buf_zones; i < ba->num_zones; ++i, ++bz) { + if (bz->size >= size) + return (bz); + } + + panic("Didn't find a buffer zone of the right size"); +} + +void * +busdma_bufalloc_alloc_uncacheable(uma_zone_t zone, int size, u_int8_t *pflag, + int wait) +{ +#ifdef VM_MEMATTR_UNCACHEABLE + + /* Inform UMA that this allocator uses kernel_map/object. */ + *pflag = UMA_SLAB_KERNEL; + + return ((void *)kmem_alloc_attr(kernel_map, size, wait, 0, + BUS_SPACE_MAXADDR, VM_MEMATTR_UNCACHEABLE)); + +#else + + panic("VM_MEMATTR_UNCACHEABLE unavailable"); + +#endif /* VM_MEMATTR_UNCACHEABLE */ +} + +void +busdma_bufalloc_free_uncacheable(void *item, int size, u_int8_t pflag) +{ + + kmem_free(kernel_map, (vm_offset_t)item, size); +} + diff -r c327e2b8786c -r a84eaa62a91f sys/arm/include/busdma_bufalloc.h --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ sys/arm/include/busdma_bufalloc.h Tue Sep 04 08:23:07 2012 -0600 @@ -0,0 +1,114 @@ +/*- + * Copyright (c) 2012 Ian Lepore + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +/* + * A buffer pool manager, for use by a platform's busdma implementation. + */ + +#ifndef _MACHINE_BUSDMA_BUFALLOC_H_ +#define _MACHINE_BUSDMA_BUFALLOC_H_ + +#include +#include + +/* + * Information about a buffer zone, returned by busdma_bufalloc_findzone(). + */ +struct busdma_bufzone { + bus_size_t size; + uma_zone_t umazone; + char name[24]; +}; + +/* + * Opaque handle type returned by busdma_bufalloc_create(). + */ +struct busdma_bufalloc; +typedef struct busdma_bufalloc *busdma_bufalloc_t; + +/* + * Create an allocator that manages a pool of DMA buffers. + * + * The allocator manages a collection of uma(9) zones of buffers in power-of-two + * sized increments ranging from minimum_alignment to the platform's PAGE_SIZE. + * The buffers within each zone are aligned on boundaries corresponding to the + * buffer size, and thus by implication each buffer is contiguous within a page + * and does not cross a power of two boundary larger than the buffer size. + * These rules are intended to make it easy for a busdma implementation to + * check whether a tag's constraints allow use of a buffer from the allocator. + * + * minimum_alignment is also the minimum buffer allocation size. For platforms + * with software-assisted cache coherency, this is typically the data cache line + * size (and MUST not be smaller than the cache line size). + * + * name appears in zone stats as 'dma name nnnnn' where 'dma' is fixed and + * 'nnnnn' is the size of buffers in that zone. + * + * If if the alloc/free function pointers are NULL, the regular uma internal + * allocators are used (I.E., you get "plain old kernel memory"). On a platform + * with an exclusion zone that applies to all DMA operations, a custom allocator + * could be used to ensure no buffer memory is ever allocated from that zone, + * allowing the bus_dmamem_alloc() implementation to make the assumption that + * buffers provided by the allocation could never lead to the need for a bounce. + */ +busdma_bufalloc_t busdma_bufalloc_create(const char *name, + bus_size_t minimum_alignment, + uma_alloc uma_alloc_func, uma_free uma_free_func, + u_int32_t uma_zcreate_flags); + +/* + * Destroy an allocator created by busdma_bufalloc_create(). + * Safe to call with a NULL pointer. + */ +void busdma_bufalloc_destroy(busdma_bufalloc_t ba); + +/* + * Return a pointer to the busdma_bufzone that should be used to allocate or + * free a buffer of the given size. Returns NULL if the size is larger than the + * largest zone handled by the allocator. + */ +struct busdma_bufzone * busdma_bufalloc_findzone(busdma_bufalloc_t ba, + bus_size_t size); + +/* + * These built-in allocation routines are available for managing a pools of + * uncacheable memory on platforms that support VM_MEMATTR_UNCACHEABLE. + * + * Allocation is done using kmem_alloc_attr() with these parameters: + * lowaddr = 0 + * highaddr = BUS_SPACE_MAXADDR + * memattr = VM_MEMATTR_UNCACHEABLE. + * + * If your platform has no exclusion region (lowaddr/highaddr), and its pmap + * routines support pmap_page_set_memattr() and the VM_MEMATTR_UNCACHEABLE flag + * you can probably use these when you need uncacheable buffers. + */ +void * busdma_bufalloc_alloc_uncacheable(uma_zone_t zone, int size, + u_int8_t *pflag, int wait); +void busdma_bufalloc_free_uncacheable(void *item, int size, u_int8_t pflag); + +#endif /* _MACHINE_BUSDMA_BUFALLOC_H_ */ + diff -r c327e2b8786c -r a84eaa62a91f sys/conf/files.arm --- sys/conf/files.arm Sun Sep 02 12:05:05 2012 -0600 +++ sys/conf/files.arm Tue Sep 04 08:23:07 2012 -0600 @@ -12,6 +12,7 @@ arm/arm/bcopyinout.S standard arm/arm/blockio.S standard arm/arm/bootconfig.c standard arm/arm/bus_space_asm_generic.S standard +arm/arm/busdma_bufalloc.c standard arm/arm/busdma_machdep.c optional cpu_arm9 | cpu_arm9e | cpu_fa526 | cpu_sa1100 | cpu_sa1110 | cpu_xscale_80219 | cpu_xscale_80321 | cpu_xscale_81342 | cpu_xscale_ixp425 | cpu_xscale_ixp435 | cpu_xscale_pxa2x0 arm/arm/busdma_machdep-v6.c optional cpu_arm11 | cpu_cortexa | cpu_mv_pj4b arm/arm/copystr.S standard --=-nhYas3YqMWIkbv0iBerz Content-Disposition: attachment; filename="arm_busdma_bufpools.diff" Content-Type: text/x-patch; name="arm_busdma_bufpools.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit # HG changeset patch # User Ian Lepore # Date 1346768844 21600 # Node ID 919b6b57a222c46f2346339391238bf2634bc51b # Parent a84eaa62a91f0993e70448863192b7a057c227b8 Busdma enhancements, especially for managing small uncacheable buffers. - Use the new architecture-agnostic buffer pool manager that uses uma(9) to manage a set of power-of-2 sized buffers for bus_dmamem_alloc(). - Create pools of buffers backed by both regular and uncacheable memory, and use them to handle regular versus BUS_DMA_COHERENT allocations. - Use uma(9) to manage a pool of bus_dmamap structs instead of local code to manage a static list of 500 items (it took 3300 maps to get to multi-user mode, so the static pool wasn't much of an optimization). - Small BUS_DMA_COHERENT allocations no longer waste an entire page per allocation, or set pages to uncached when they contain data other than DMA buffers. There's no longer a need for drivers to work around the inefficiency by allocing large buffers then sub-dividing them. - Because we know the alignment and padding of buffers allocated by bus_dmamem_alloc() (whether coherent or regular memory, and whether obtained from the pool allocator or directly from the kernel) we can avoid doing partial cacheline flushes on them. - Add a fast-out to _bus_dma_could_bounce() (and some comments about what the routine really does because the old misplaced comment was wrong). - Everywhere the dma tag alignment is used, the interpretation is that an alignment of 1 means no special alignment. If the tag is created with an alignment argument of zero, store it in the tag as one, and remove all the code scattered around that changed 0->1 at point of use. - Remove stack-allocated arrays of segments, use a local array of two segments within the tag struct, or dynamically allocate an array at first use if nsegments > 2. On an arm system I tested, only 5 of 97 tags used more than two segments. On my x86 desktop it was only 7 of 111 tags. diff -r a84eaa62a91f -r 919b6b57a222 sys/arm/arm/busdma_machdep.c --- sys/arm/arm/busdma_machdep.c Tue Sep 04 08:23:07 2012 -0600 +++ sys/arm/arm/busdma_machdep.c Tue Sep 04 08:27:24 2012 -0600 @@ -1,4 +1,5 @@ /*- + * Copyright (c) 2012 Ian Lepore * Copyright (c) 2004 Olivier Houchard * Copyright (c) 2002 Peter Grehan * Copyright (c) 1997, 1998 Justin T. Gibbs. @@ -32,7 +33,26 @@ __FBSDID("$FreeBSD: head/sys/arm/arm/busdma_machdep.c 236991 2012-06-13 04:59:55Z imp $"); /* - * ARM bus dma support routines + * ARM bus dma support routines. + * + * XXX Things to investigate / fix some day... + * - What is the earliest that this API can be called? Could there be any + * fallout from changing the SYSINIT() order from SI_SUB_VM to SI_SUB_KMEM? + * - The manpage mentions the BUS_DMA_NOWAIT flag only in the context of the + * bus_dmamap_load() function. This code has historically (and still does) + * honor it in bus_dmamem_alloc(). If we got rid of that we could lose some + * error checking because some resource management calls would become WAITOK + * and thus "cannot fail." + * - The decisions made by _bus_dma_can_bounce() should be made once, at tag + * creation time, and the result stored in the tag. + * - DMAMAP_COHERENT flag is probably obsolete at this point, and also the + * complex code for sniffing out pages that have cache disabled by some + * mechanism other than bus_dmamem_alloc(). + * - It should be possible to take some shortcuts when mapping a buffer we know + * came from the uma(9) allocators based on what we know about such buffers + * (aligned, contiguous, etc). + * - The allocation of bounce pages could probably be cleaned up, then we could + * retire arm_remap_nocache(). */ #define _ARM32_BUS_DMA_PRIVATE @@ -50,12 +70,16 @@ #include #include +#include #include +#include +#include #include #include #include #include +#include #include #include @@ -90,6 +114,13 @@ struct bus_dma_tag { struct arm32_dma_range *ranges; int _nranges; struct bounce_zone *bounce_zone; + /* + * Most tags need one or two segments, and can use the local tagsegs + * array. For tags with a larger limit, we'll allocate a bigger array + * on first use. + */ + bus_dma_segment_t *segments; + bus_dma_segment_t tagsegs[2]; }; struct bounce_page { @@ -133,7 +164,7 @@ SYSCTL_INT(_hw_busdma, OID_AUTO, total_b #define DMAMAP_LINEAR 0x1 #define DMAMAP_MBUF 0x2 #define DMAMAP_UIO 0x4 -#define DMAMAP_ALLOCATED 0x10 +#define DMAMAP_CACHE_ALIGNED 0x10 #define DMAMAP_TYPE_MASK (DMAMAP_LINEAR|DMAMAP_MBUF|DMAMAP_UIO) #define DMAMAP_COHERENT 0x8 struct bus_dmamap { @@ -143,9 +174,6 @@ struct bus_dmamap { bus_dma_tag_t dmat; int flags; void *buffer; - void *origbuffer; - void *allocbuffer; - TAILQ_ENTRY(bus_dmamap) freelist; int len; STAILQ_ENTRY(bus_dmamap) links; bus_dmamap_callback_t *callback; @@ -156,12 +184,6 @@ struct bus_dmamap { static STAILQ_HEAD(, bus_dmamap) bounce_map_waitinglist; static STAILQ_HEAD(, bus_dmamap) bounce_map_callbacklist; -static TAILQ_HEAD(,bus_dmamap) dmamap_freelist = - TAILQ_HEAD_INITIALIZER(dmamap_freelist); - -#define BUSDMA_STATIC_MAPS 500 -static struct bus_dmamap map_pool[BUSDMA_STATIC_MAPS]; - static struct mtx busdma_mtx; MTX_SYSINIT(busdma_mtx, &busdma_mtx, "busdma lock", MTX_DEF); @@ -178,6 +200,89 @@ static void free_bounce_page(bus_dma_tag /* Default tag, as most drivers provide no parent tag. */ bus_dma_tag_t arm_root_dma_tag; +//---------------------------------------------------------------------------- +// Begin block of code useful to transplant to other implementations. + +static struct bus_dmamap coherent_dmamap; /* Dummy; for coherent buffers */ + +static uma_zone_t dmamap_zone; /* Cache of struct bus_dmamap items */ + +static busdma_bufalloc_t coherent_allocator; /* Cache of coherent buffers */ +static busdma_bufalloc_t standard_allocator; /* Cache of standard buffers */ + +/* + * This is the ctor function passed to uma_zcreate() for the pool of dma maps. + * It'll need platform-specific changes if this code is copied. + */ +static int +dmamap_ctor(void *mem, int size, void *arg, int flags) +{ + bus_dmamap_t map; + bus_dma_tag_t dmat; + + map = (bus_dmamap_t)mem; + dmat = (bus_dma_tag_t)arg; + + dmat->map_count++; + + map->dmat = dmat; + map->flags = 0; + STAILQ_INIT(&map->bpages); + + return (0); +} + +/* + * This is the dtor function passed to uma_zcreate() for the pool of dma maps. + * It may need platform-specific changes if this code is copied . + */ +static void +dmamap_dtor(void *mem, int size, void *arg) +{ + bus_dmamap_t map; + + map = (bus_dmamap_t)mem; + + map->dmat->map_count--; +} + +static void +busdma_init(void *dummy) +{ + + /* Create a cache of maps for bus_dmamap_create(). */ + dmamap_zone = uma_zcreate("dma maps", sizeof(struct bus_dmamap), + dmamap_ctor, dmamap_dtor, NULL, NULL, UMA_ALIGN_PTR, 0); + + /* Create a cache of buffers in standard (cacheable) memory. */ + standard_allocator = busdma_bufalloc_create("buffer", + arm_dcache_align, /* minimum_alignment */ + NULL, /* uma_alloc func */ + NULL, /* uma_free func */ + 0); /* uma_zcreate_flags */ + + /* + * Create a cache of buffers in uncacheable memory, to implement the + * BUS_DMA_COHERENT (and potentially BUS_DMA_NOCACHE) flag. + */ + coherent_allocator = busdma_bufalloc_create("coherent", + arm_dcache_align, /* minimum_alignment */ + busdma_bufalloc_alloc_uncacheable, + busdma_bufalloc_free_uncacheable, + 0); /* uma_zcreate_flags */ +} + +/* + * This init historically used SI_SUB_VM, but now the init code requires + * malloc(9) using M_DEVBUF memory, which is set up later than SI_SUB_VM, by + * SI_SUB_KMEM and SI_ORDER_SECOND, so we'll go right after that by using + * SI_SUB_KMEM and SI_ORDER_THIRD. + */ +SYSINIT(busdma, SI_SUB_KMEM, SI_ORDER_THIRD, busdma_init, NULL); + +// End block of code useful to transplant to other implementations. +//---------------------------------------------------------------------------- + /* * Return true if a match is made. * @@ -205,30 +310,26 @@ run_filter(bus_dma_tag_t dmat, bus_addr_ return (retval); } -static void -arm_dmamap_freelist_init(void *dummy) -{ - int i; - - for (i = 0; i < BUSDMA_STATIC_MAPS; i++) - TAILQ_INSERT_HEAD(&dmamap_freelist, &map_pool[i], freelist); -} - -SYSINIT(busdma, SI_SUB_VM, SI_ORDER_ANY, arm_dmamap_freelist_init, NULL); - /* - * Check to see if the specified page is in an allowed DMA range. + * This routine checks the exclusion zone constraints from a tag against the + * physical RAM available on the machine. If a tag specifies an exclusion zone + * but there's no RAM in that zone, then we avoid allocating resources to bounce + * a request, and we can use any memory allocator (as opposed to needing + * kmem_alloc_contig() just because it can allocate pages in an address range). + * + * Most tags have BUS_SPACE_MAXADDR or BUS_SPACE_MAXADDR_32BIT (they are the + * same value on 32-bit architectures) as their lowaddr constraint, and we can't + * possibly have RAM at an address higher than the highest address we can + * express, so we take a fast out. */ - -static __inline int -bus_dmamap_load_buffer(bus_dma_tag_t dmat, bus_dma_segment_t *segs, - bus_dmamap_t map, void *buf, bus_size_t buflen, struct pmap *pmap, - int flags, vm_offset_t *lastaddrp, int *segp); - static __inline int _bus_dma_can_bounce(vm_offset_t lowaddr, vm_offset_t highaddr) { int i; + + if (lowaddr >= BUS_SPACE_MAXADDR) + return (0); + for (i = 0; phys_avail[i] && phys_avail[i + 1]; i += 2) { if ((lowaddr >= phys_avail[i] && lowaddr <= phys_avail[i + 1]) || (lowaddr < phys_avail[i] && @@ -293,38 +394,6 @@ dflt_lock(void *arg, bus_dma_lock_op_t o #endif } -static __inline bus_dmamap_t -_busdma_alloc_dmamap(void) -{ - bus_dmamap_t map; - - mtx_lock(&busdma_mtx); - map = TAILQ_FIRST(&dmamap_freelist); - if (map) - TAILQ_REMOVE(&dmamap_freelist, map, freelist); - mtx_unlock(&busdma_mtx); - if (!map) { - map = malloc(sizeof(*map), M_DEVBUF, M_NOWAIT | M_ZERO); - if (map) - map->flags = DMAMAP_ALLOCATED; - } else - map->flags = 0; - STAILQ_INIT(&map->bpages); - return (map); -} - -static __inline void -_busdma_free_dmamap(bus_dmamap_t map) -{ - if (map->flags & DMAMAP_ALLOCATED) - free(map, M_DEVBUF); - else { - mtx_lock(&busdma_mtx); - TAILQ_INSERT_HEAD(&dmamap_freelist, map, freelist); - mtx_unlock(&busdma_mtx); - } -} - /* * Allocate a device specific dma_tag. */ @@ -353,7 +422,7 @@ bus_dma_tag_create(bus_dma_tag_t parent, } newtag->parent = parent; - newtag->alignment = alignment; + newtag->alignment = alignment ? alignment : 1; newtag->boundary = boundary; newtag->lowaddr = trunc_page((vm_offset_t)lowaddr) + (PAGE_SIZE - 1); newtag->highaddr = trunc_page((vm_offset_t)highaddr) + (PAGE_SIZE - 1); @@ -374,7 +443,19 @@ bus_dma_tag_create(bus_dma_tag_t parent, newtag->lockfunc = dflt_lock; newtag->lockfuncarg = NULL; } - /* + /* + * If all the segments we need fit into the local tagsegs array, set the + * pointer now. Otherwise NULL the pointer and an array of segments + * will be allocated later, on first use. We don't pre-allocate now + * because some tags exist just to pass contraints to children in the + * device hierarchy, and they tend to use BUS_SPACE_UNRESTRICTED and we + * sure don't want to try to allocate an array for that. + */ + if (newtag->nsegments <= nitems(newtag->tagsegs)) + newtag->segments = newtag->tagsegs; + else + newtag->segments = NULL; + /* * Take into account any restrictions imposed by our parent tag */ if (parent != NULL) { @@ -457,6 +538,8 @@ bus_dma_tag_destroy(bus_dma_tag_t dmat) parent = dmat->parent; atomic_subtract_int(&dmat->ref_count, 1); if (dmat->ref_count == 0) { + if (dmat->segments != dmat->tagsegs) + free(dmat->segments, M_DEVBUF); free(dmat, M_DEVBUF); /* * Last reference count, so @@ -481,18 +564,19 @@ bus_dma_tag_destroy(bus_dma_tag_t dmat) int bus_dmamap_create(bus_dma_tag_t dmat, int flags, bus_dmamap_t *mapp) { - bus_dmamap_t newmap; + bus_dmamap_t map; int error = 0; - newmap = _busdma_alloc_dmamap(); - if (newmap == NULL) { - CTR3(KTR_BUSDMA, "%s: tag %p error %d", __func__, dmat, ENOMEM); - return (ENOMEM); - } - *mapp = newmap; - newmap->dmat = dmat; - newmap->allocbuffer = NULL; - dmat->map_count++; + map = uma_zalloc_arg(dmamap_zone, dmat, M_WAITOK); + *mapp = map; + + /* + * If the tag's segments haven't been allocated yet we need to do it + * now, because we can't sleep for resources at map load time. + */ + if (dmat->segments == NULL) + dmat->segments = malloc(dmat->nsegments * + sizeof(*dmat->segments), M_DEVBUF, M_WAITOK); /* * Bouncing might be required if the driver asks for an active @@ -507,7 +591,7 @@ bus_dmamap_create(bus_dma_tag_t dmat, in if (dmat->bounce_zone == NULL) { if ((error = alloc_bounce_zone(dmat)) != 0) { - _busdma_free_dmamap(newmap); + uma_zfree(dmamap_zone, map); *mapp = NULL; return (error); } @@ -560,108 +644,129 @@ bus_dmamap_destroy(bus_dma_tag_t dmat, b __func__, dmat, EBUSY); return (EBUSY); } - _busdma_free_dmamap(map); + uma_zfree(dmamap_zone, map); if (dmat->bounce_zone) dmat->bounce_zone->map_count--; - dmat->map_count--; CTR2(KTR_BUSDMA, "%s: tag %p error 0", __func__, dmat); return (0); } /* - * Allocate a piece of memory that can be efficiently mapped into - * bus device space based on the constraints lited in the dma tag. - * A dmamap to for use with dmamap_load is also allocated. + * Allocate a piece of memory that can be efficiently mapped into bus device + * space based on the constraints listed in the dma tag. Returns a pointer to + * the allocated memory, and a pointer to an associated bus_dmamap. */ int -bus_dmamem_alloc(bus_dma_tag_t dmat, void** vaddr, int flags, +bus_dmamem_alloc(bus_dma_tag_t dmat, void **vaddrp, int flags, bus_dmamap_t *mapp) { - bus_dmamap_t newmap = NULL; - + void * vaddr; + struct busdma_bufzone *bufzone; + busdma_bufalloc_t ba; + bus_dmamap_t map; int mflags; + vm_memattr_t memattr; if (flags & BUS_DMA_NOWAIT) mflags = M_NOWAIT; else mflags = M_WAITOK; + + /* + * If the tag's segments haven't been allocated yet we need to do it + * now, because we can't sleep for resources at map load time. + */ + if (dmat->segments == NULL) + dmat->segments = malloc(dmat->nsegments * + sizeof(*dmat->segments), M_DEVBUF, mflags); + + if (flags & BUS_DMA_COHERENT) { + memattr = VM_MEMATTR_UNCACHEABLE; + ba = coherent_allocator; + map = &coherent_dmamap; + } else { + memattr = VM_MEMATTR_DEFAULT; + ba = standard_allocator; + map = uma_zalloc_arg(dmamap_zone, dmat, mflags); + if (map == NULL) + return (ENOMEM); + /* All buffers we allocate are cache-aligned. */ + map->flags |= DMAMAP_CACHE_ALIGNED; + } + if (flags & BUS_DMA_ZERO) mflags |= M_ZERO; - newmap = _busdma_alloc_dmamap(); - if (newmap == NULL) { - CTR4(KTR_BUSDMA, "%s: tag %p tag flags 0x%x error %d", - __func__, dmat, dmat->flags, ENOMEM); - return (ENOMEM); + /* + * Try to find a bufzone in the allocator that holds a cache of buffers + * of the right size for this request. If the buffer is too big to be + * held in the allocator cache, this returns NULL. + */ + bufzone = busdma_bufalloc_findzone(ba, dmat->maxsize); + + /* + * Allocate the buffer from the uma(9) allocator if... + * - It's small enough to be in the allocator (bufzone not NULL). + * - The alignment constraint isn't larger than the allocation size + * (the allocator aligns buffers to their size boundaries). + * - There's no need to handle lowaddr/highaddr exclusion zones. + * else allocate non-contiguous pages if... + * - The page count that could get allocated doesn't exceed nsegments. + * - The alignment constraint isn't larger than a page boundary. + * - There are no boundary-crossing constraints. + * else allocate a block of contiguous pages because one or more of the + * constraints is something that only the contig allocator can fulfill. + */ + if (bufzone != NULL && dmat->alignment <= bufzone->size && + !_bus_dma_can_bounce(dmat->lowaddr, dmat->highaddr)) { + vaddr = uma_zalloc(bufzone->umazone, mflags); + } else if (dmat->nsegments >= btoc(dmat->maxsize) && + dmat->alignment <= PAGE_SIZE && dmat->boundary == 0) { + vaddr = (void *)kmem_alloc_attr(kernel_map, dmat->maxsize, + mflags, 0, dmat->lowaddr, memattr); + } else { + vaddr = (void *)kmem_alloc_contig(kernel_map, dmat->maxsize, + mflags, 0, dmat->lowaddr, dmat->alignment, dmat->boundary, + memattr); } - dmat->map_count++; - *mapp = newmap; - newmap->dmat = dmat; - - if (dmat->maxsize <= PAGE_SIZE && - (dmat->alignment < dmat->maxsize) && - !_bus_dma_can_bounce(dmat->lowaddr, dmat->highaddr)) { - *vaddr = malloc(dmat->maxsize, M_DEVBUF, mflags); - } else { - /* - * XXX Use Contigmalloc until it is merged into this facility - * and handles multi-seg allocations. Nobody is doing - * multi-seg allocations yet though. - */ - *vaddr = contigmalloc(dmat->maxsize, M_DEVBUF, mflags, - 0ul, dmat->lowaddr, dmat->alignment? dmat->alignment : 1ul, - dmat->boundary); - } - if (*vaddr == NULL) { - if (newmap != NULL) { - _busdma_free_dmamap(newmap); - dmat->map_count--; - } - *mapp = NULL; - return (ENOMEM); + + if (vaddr == NULL && map != &coherent_dmamap) { + uma_zfree(dmamap_zone, map); + map = NULL; } - if (flags & BUS_DMA_COHERENT) { - void *tmpaddr = arm_remap_nocache( - (void *)((vm_offset_t)*vaddr &~ PAGE_MASK), - dmat->maxsize + ((vm_offset_t)*vaddr & PAGE_MASK)); - if (tmpaddr) { - tmpaddr = (void *)((vm_offset_t)(tmpaddr) + - ((vm_offset_t)*vaddr & PAGE_MASK)); - newmap->origbuffer = *vaddr; - newmap->allocbuffer = tmpaddr; - *vaddr = tmpaddr; - } else - newmap->origbuffer = newmap->allocbuffer = NULL; - } else - newmap->origbuffer = newmap->allocbuffer = NULL; - return (0); + *vaddrp = vaddr; + *mapp = map; + + return (vaddr == NULL ? ENOMEM : 0); } /* - * Free a piece of memory and it's allocated dmamap, that was allocated - * via bus_dmamem_alloc. Make the same choice for free/contigfree. + * Free a piece of memory that was allocated via bus_dmamem_alloc, along with + * its associated map. */ void bus_dmamem_free(bus_dma_tag_t dmat, void *vaddr, bus_dmamap_t map) { - if (map->allocbuffer) { - KASSERT(map->allocbuffer == vaddr, - ("Trying to freeing the wrong DMA buffer")); - vaddr = map->origbuffer; - arm_unmap_nocache(map->allocbuffer, - dmat->maxsize + ((vm_offset_t)vaddr & PAGE_MASK)); + struct busdma_bufzone *bufzone; + busdma_bufalloc_t ba; + + if (map == &coherent_dmamap) { + ba = coherent_allocator; + } else { + ba = standard_allocator; + uma_zfree(dmamap_zone, map); } - if (dmat->maxsize <= PAGE_SIZE && - dmat->alignment < dmat->maxsize && + + /* Be careful not to access map from here on. */ + + bufzone = busdma_bufalloc_findzone(ba, dmat->maxsize); + + if (bufzone != NULL && dmat->alignment <= bufzone->size && !_bus_dma_can_bounce(dmat->lowaddr, dmat->highaddr)) - free(vaddr, M_DEVBUF); - else { - contigfree(vaddr, dmat->maxsize, M_DEVBUF); - } - dmat->map_count--; - _busdma_free_dmamap(map); - CTR3(KTR_BUSDMA, "%s: tag %p flags 0x%x", __func__, dmat, dmat->flags); + uma_zfree(bufzone->umazone, vaddr); + else + kmem_free(kernel_map, (vm_offset_t)vaddr, dmat->maxsize); } static int @@ -883,11 +988,6 @@ bus_dmamap_load(bus_dma_tag_t dmat, bus_ { vm_offset_t lastaddr = 0; int error, nsegs = -1; -#ifdef __CC_SUPPORTS_DYNAMIC_ARRAY_INIT - bus_dma_segment_t dm_segments[dmat->nsegments]; -#else - bus_dma_segment_t dm_segments[BUS_DMAMAP_NSEGS]; -#endif KASSERT(dmat != NULL, ("dmatag is NULL")); KASSERT(map != NULL, ("dmamap is NULL")); @@ -898,14 +998,14 @@ bus_dmamap_load(bus_dma_tag_t dmat, bus_ map->buffer = buf; map->len = buflen; error = bus_dmamap_load_buffer(dmat, - dm_segments, map, buf, buflen, kernel_pmap, + dmat->segments, map, buf, buflen, kernel_pmap, flags, &lastaddr, &nsegs); if (error == EINPROGRESS) return (error); if (error) (*callback)(callback_arg, NULL, 0, error); else - (*callback)(callback_arg, dm_segments, nsegs + 1, error); + (*callback)(callback_arg, dmat->segments, nsegs + 1, error); CTR5(KTR_BUSDMA, "%s: tag %p tag flags 0x%x error %d nsegs %d", __func__, dmat, dmat->flags, nsegs + 1, error); @@ -915,23 +1015,28 @@ bus_dmamap_load(bus_dma_tag_t dmat, bus_ /* * Like bus_dmamap_load(), but for mbufs. + * + * Note that the manpage states that BUS_DMA_NOWAIT is implied for mbufs. + * + * We know that the way the system allocates and uses mbufs implies that we can + * treat them as DMAMAP_CACHE_ALIGNED in terms of handling partial cache line + * flushes. Even though the flush may reference the data area within the mbuf + * that isn't aligned to a cache line, we know the overall mbuf itself is + * properly aligned, and we know that the CPU will not touch the header fields + * in front of the data area while the DMA is in progress. */ int bus_dmamap_load_mbuf(bus_dma_tag_t dmat, bus_dmamap_t map, struct mbuf *m0, bus_dmamap_callback2_t *callback, void *callback_arg, int flags) { -#ifdef __CC_SUPPORTS_DYNAMIC_ARRAY_INIT - bus_dma_segment_t dm_segments[dmat->nsegments]; -#else - bus_dma_segment_t dm_segments[BUS_DMAMAP_NSEGS]; -#endif int nsegs = -1, error = 0; M_ASSERTPKTHDR(m0); + flags |= BUS_DMA_NOWAIT; map->flags &= ~DMAMAP_TYPE_MASK; - map->flags |= DMAMAP_MBUF | DMAMAP_COHERENT; + map->flags |= DMAMAP_MBUF | DMAMAP_COHERENT | DMAMAP_CACHE_ALIGNED; map->buffer = m0; map->len = 0; if (m0->m_pkthdr.len <= dmat->maxsize) { @@ -941,7 +1046,7 @@ bus_dmamap_load_mbuf(bus_dma_tag_t dmat, for (m = m0; m != NULL && error == 0; m = m->m_next) { if (m->m_len > 0) { error = bus_dmamap_load_buffer(dmat, - dm_segments, map, m->m_data, m->m_len, + dmat->segments, map, m->m_data, m->m_len, pmap_kernel(), flags, &lastaddr, &nsegs); map->len += m->m_len; } @@ -954,9 +1059,9 @@ bus_dmamap_load_mbuf(bus_dma_tag_t dmat, /* * force "no valid mappings" on error in callback. */ - (*callback)(callback_arg, dm_segments, 0, 0, error); + (*callback)(callback_arg, NULL, 0, 0, error); } else { - (*callback)(callback_arg, dm_segments, nsegs + 1, + (*callback)(callback_arg, dmat->segments, nsegs + 1, m0->m_pkthdr.len, error); } CTR5(KTR_BUSDMA, "%s: tag %p tag flags 0x%x error %d nsegs %d", @@ -976,7 +1081,7 @@ bus_dmamap_load_mbuf_sg(bus_dma_tag_t dm flags |= BUS_DMA_NOWAIT; *nsegs = -1; map->flags &= ~DMAMAP_TYPE_MASK; - map->flags |= DMAMAP_MBUF | DMAMAP_COHERENT; + map->flags |= DMAMAP_MBUF | DMAMAP_COHERENT | DMAMAP_CACHE_ALIGNED; map->buffer = m0; map->len = 0; if (m0->m_pkthdr.len <= dmat->maxsize) { @@ -1012,11 +1117,6 @@ bus_dmamap_load_uio(bus_dma_tag_t dmat, int flags) { vm_offset_t lastaddr = 0; -#ifdef __CC_SUPPORTS_DYNAMIC_ARRAY_INIT - bus_dma_segment_t dm_segments[dmat->nsegments]; -#else - bus_dma_segment_t dm_segments[BUS_DMAMAP_NSEGS]; -#endif int nsegs, i, error; bus_size_t resid; struct iovec *iov; @@ -1048,8 +1148,8 @@ bus_dmamap_load_uio(bus_dma_tag_t dmat, caddr_t addr = (caddr_t) iov[i].iov_base; if (minlen > 0) { - error = bus_dmamap_load_buffer(dmat, dm_segments, map, - addr, minlen, pmap, flags, &lastaddr, &nsegs); + error = bus_dmamap_load_buffer(dmat, dmat->segments, + map, addr, minlen, pmap, flags, &lastaddr, &nsegs); map->len += minlen; resid -= minlen; @@ -1060,9 +1160,9 @@ bus_dmamap_load_uio(bus_dma_tag_t dmat, /* * force "no valid mappings" on error in callback. */ - (*callback)(callback_arg, dm_segments, 0, 0, error); + (*callback)(callback_arg, NULL, 0, 0, error); } else { - (*callback)(callback_arg, dm_segments, nsegs+1, + (*callback)(callback_arg, dmat->segments, nsegs+1, uio->uio_resid, error); } @@ -1088,7 +1188,7 @@ void } static void -bus_dmamap_sync_buf(void *buf, int len, bus_dmasync_op_t op) +bus_dmamap_sync_buf(void *buf, int len, bus_dmasync_op_t op, int bufaligned) { char _tmp_cl[arm_dcache_align], _tmp_clend[arm_dcache_align]; register_t s; @@ -1098,7 +1198,25 @@ bus_dmamap_sync_buf(void *buf, int len, cpu_dcache_wb_range((vm_offset_t)buf, len); cpu_l2cache_wb_range((vm_offset_t)buf, len); } + + /* + * If the caller promises the buffer is properly aligned to a cache line + * (even if the call parms make it look like it isn't) we can avoid + * attempting to preserve the non-DMA part of the cache line in the + * POSTREAD case, but we MUST still do a writeback in the PREREAD case. + * + * This covers the case of mbufs, where we know how they're aligned and + * know the CPU doesn't touch the header in front of the DMA data area + * during the IO, but it may have touched it right before invoking the + * sync, so a PREREAD writeback is required. + * + * It also handles buffers we created in bus_dmamem_alloc(), which are + * always aligned and padded to cache line size even if the IO length + * isn't a multiple of cache line size. In this case the PREREAD + * writeback probably isn't required, but it's harmless. + */ partial = (((vm_offset_t)buf) | len) & arm_dcache_align_mask; + if (op & BUS_DMASYNC_PREREAD) { if (!(op & BUS_DMASYNC_PREWRITE) && !partial) { cpu_dcache_inv_range((vm_offset_t)buf, len); @@ -1109,7 +1227,7 @@ bus_dmamap_sync_buf(void *buf, int len, } } if (op & BUS_DMASYNC_POSTREAD) { - if (partial) { + if (partial && !bufaligned) { s = intr_disable(); if ((vm_offset_t)buf & arm_dcache_align_mask) memcpy(_tmp_cl, (void *)((vm_offset_t)buf & @@ -1123,7 +1241,7 @@ bus_dmamap_sync_buf(void *buf, int len, } cpu_dcache_inv_range((vm_offset_t)buf, len); cpu_l2cache_inv_range((vm_offset_t)buf, len); - if (partial) { + if (partial && !bufaligned) { if ((vm_offset_t)buf & arm_dcache_align_mask) memcpy((void *)((vm_offset_t)buf & ~arm_dcache_align_mask), _tmp_cl, @@ -1194,25 +1312,29 @@ void struct uio *uio; int resid; struct iovec *iov; - + int bufaligned; + if (op == BUS_DMASYNC_POSTWRITE) return; + if (map == &coherent_dmamap) + goto drain; if (STAILQ_FIRST(&map->bpages)) _bus_dmamap_sync_bp(dmat, map, op); - if (map->flags & DMAMAP_COHERENT) - return; CTR3(KTR_BUSDMA, "%s: op %x flags %x", __func__, op, map->flags); + bufaligned = (map->flags & DMAMAP_CACHE_ALIGNED); switch(map->flags & DMAMAP_TYPE_MASK) { case DMAMAP_LINEAR: if (!(_bus_dma_buf_is_in_bp(map, map->buffer, map->len))) - bus_dmamap_sync_buf(map->buffer, map->len, op); + bus_dmamap_sync_buf(map->buffer, map->len, op, + bufaligned); break; case DMAMAP_MBUF: m = map->buffer; while (m) { if (m->m_len > 0 && !(_bus_dma_buf_is_in_bp(map, m->m_data, m->m_len))) - bus_dmamap_sync_buf(m->m_data, m->m_len, op); + bus_dmamap_sync_buf(m->m_data, m->m_len, op, + bufaligned); m = m->m_next; } break; @@ -1227,7 +1349,7 @@ void if (!_bus_dma_buf_is_in_bp(map, iov[i].iov_base, minlen)) bus_dmamap_sync_buf(iov[i].iov_base, - minlen, op); + minlen, op, bufaligned); resid -= minlen; } } @@ -1235,6 +1357,9 @@ void default: break; } + +drain: + cpu_drain_writebuf(); } --=-nhYas3YqMWIkbv0iBerz-- From owner-freebsd-arm@FreeBSD.ORG Tue Sep 4 17:40:24 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 83FB8106566C; Tue, 4 Sep 2012 17:40:24 +0000 (UTC) (envelope-from marktinguely@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 527318FC0A; Tue, 4 Sep 2012 17:40:24 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so9859260pbb.13 for ; Tue, 04 Sep 2012 10:40:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FSKxIKJzxlThRtTL/56QWNlwWO8kJIfLNlxB3TT4TxU=; b=pM7jlDAmlPWR1L7rr/T/rSgH89KjR46um82MUGFGD1PtxgwhkNQuqJdH6rFuxHtKQL l+WoW4L68VzFl0VgKcs8ioSW3PpAqqAz7Ctwnja8Co2ULJ6LR3zzXvO18d8WFx1RBnZw q2Jmq2xW+F6/IrwnmjftHKc1ZoTgMWoGRmlTFZUsBOhWrkEqkHYBBUHspkR0ZjqUKd4+ CUel3XcE7WnCdCbGM9MIpswFVzm5q7Yul5uRvrdmIqke+zB7F1LHahKmEwQVIuFYqeTL 6C/N+KeY5ZeKS5b8mmIWHur+/DEL2VacmnUetOLgDpCBQo+KQIy2Zwd1X5hyuCLlcEhm kmrA== MIME-Version: 1.0 Received: by 10.68.231.130 with SMTP id tg2mr47699707pbc.70.1346780423964; Tue, 04 Sep 2012 10:40:23 -0700 (PDT) Received: by 10.68.229.227 with HTTP; Tue, 4 Sep 2012 10:40:23 -0700 (PDT) In-Reply-To: <1346777897.1140.633.camel@revolution.hippie.lan> References: <1346777897.1140.633.camel@revolution.hippie.lan> Date: Tue, 4 Sep 2012 12:40:23 -0500 Message-ID: From: Mark Tinguely To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org Subject: Re: busdma buffer management enhancements - call for review and test 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, 04 Sep 2012 17:40:24 -0000 On Tue, Sep 4, 2012 at 11:58 AM, Ian Lepore wrote: > The attached set of patches enhances the ARM v4/v5 busdma management of > small DMA buffers, especially for BUS_DMA_COHERENT and uncacheable > memory. The existing implementation uses malloc(9) to allocate buffers, > then uses arm_remap_nocache() to make the page(s) containing the buffers > uncacheable, even when those pages contain data other than DMA buffers. > > The attached patches address this by: > > * Adding support for pmap_page_set_memattr() and > VM_MEMATTR_UNCACHEABLE to the ARM v4 pmap implemenation. > * Adding new common code usable by any platform that uses uma(9) > to manage pools of power-of-two sized buffers, keeping them > sized and aligned as required to help maintain cache coherency. > * Modifying the busdma implementation to use the new pool manager > to manage pools of both regular and uncacheable buffers, and > also to use uma(9) to manage a pool of map structures. > * Using knowledge of the alignment and padding of pool-allocated > buffers to avoid doing partial cache line flushes on those > buffers. > > I'm CC'ing freebsd-mips because I think these patches can be adapted to > the MIPS busdma implementation as well. The new busdma_bufalloc.[ch] > code isn't arm-specific, and shouldn't live in sys/arm/arm/, but I don't > know where it should go. > > Once we have ARM and MIPS able to efficiently manage small cache-aligned > DMA buffers, the stage is set to begin updating device drivers to > allocate buffers individually, rather than allocating huge chunks and > sub-dividing them, possibly violating cache line boundaries in doing so. > > I've been running these for a couple days on DreamPlug and Atmel > hardware (the latter in an 8.x environment) without problems. > > -- Ian How about having a per processor cache line definition rather than using: +#define MIN_ZONE_BUFSIZE 32 For those archs that have a 64 byte cache line. I like the separation of the regular and BUS_DMA_COHERENT or BUS_DMA_NOCACHE. I never liked turning the cache off the entire page for a few DMA buffers. --Mark. From owner-freebsd-arm@FreeBSD.ORG Tue Sep 4 17:56:33 2012 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 A1EDE1065670; Tue, 4 Sep 2012 17:56:33 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 666758FC17; Tue, 4 Sep 2012 17:56:33 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id q84HuWXh060101; Tue, 4 Sep 2012 11:56:32 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) 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 q84HuUmG041462; Tue, 4 Sep 2012 11:56:30 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Mark Tinguely In-Reply-To: References: <1346777897.1140.633.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Tue, 04 Sep 2012 11:56:30 -0600 Message-ID: <1346781390.1140.641.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org Subject: Re: busdma buffer management enhancements - call for review and test 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, 04 Sep 2012 17:56:33 -0000 On Tue, 2012-09-04 at 12:40 -0500, Mark Tinguely wrote: > On Tue, Sep 4, 2012 at 11:58 AM, Ian Lepore > wrote: > How about having a per processor cache line definition rather than using: > > +#define MIN_ZONE_BUFSIZE 32 > > For those archs that have a 64 byte cache line. > > I like the separation of the regular and BUS_DMA_COHERENT or > BUS_DMA_NOCACHE. I never liked turning the cache off the entire page > for a few DMA buffers. > > --Mark. The code in busdma_bufalloc.c (where that constant appears) knows nothing about architecture cache line sizes, that info has to be passed in to the create call as the minimum_alignment parameter. The point of that constant is to enforce internal limits in the implementation... if the caller passes in a minimum_alignment size less than 32, it will still use 32 as the smallest buffer size in the cache, purely because it only allocates enough slots in the array to handle log2(PAGE_SIZE) - log2(MIN_ZONE_BUFSIZE) + 1 zones, but you can't use log2() in a compile time constant expression, so things are a bit hand-tuned, and there's some code for sanity-enforcement. -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Sep 4 18:08:39 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 01209106566B for ; Tue, 4 Sep 2012 18:08:39 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id A44F18FC1D for ; Tue, 4 Sep 2012 18:08:38 +0000 (UTC) Received: by yenl7 with SMTP id l7so1364396yen.13 for ; Tue, 04 Sep 2012 11:08:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=z8YQg6niwhc8cvqOy/Z/95tOdtZM0Zm2d2lfuHAOczA=; b=JJZ2KKt0qayipCzkvZrHq3wJXJMKZ/ogPyfODmtxhnZvdc0De7SHod2HAtON0W7g5s jCNuIClLFQ6zCplAsc49zmOSVgOBv5TQHCxKTx5KaJDaA9sJBlXH+nWNPYS5kpYqJc4j EuqQkg6sEi9/QcSFZVSWfAfrvmHihL3q6T2xfeqJIqCHlK4GSM5rVOhKsRNI6VQ072hL fOdxWXFJUKkdXeZt+3VFoYP325nxWkpGiboliI+bFZEriF7wfxe5if9iJxPqGm4djh3k zDpWsR4vEo1xhj2d3jB0C5ow7hBsDxkgb7BqJHk6/lDlGnxVHZIjelVzpmt394DI5n9N MMUg== Received: by 10.236.74.37 with SMTP id w25mr19454277yhd.30.1346782117695; Tue, 04 Sep 2012 11:08:37 -0700 (PDT) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id b46sm31160808yhm.3.2012.09.04.11.08.34 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Sep 2012 11:08:36 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1346781390.1140.641.camel@revolution.hippie.lan> Date: Tue, 4 Sep 2012 12:08:33 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2C9793BE-70B0-4A18-B5D2-FBA8C63A4552@bsdimp.com> References: <1346777897.1140.633.camel@revolution.hippie.lan> <1346781390.1140.641.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnM5xJrCx1ZVR6MfHSs8iMIH9s0L1nbO+s2qKR7qkCyIahdm7Nr9GLjJEgMyo4tqpMnCRte Cc: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org Subject: Re: busdma buffer management enhancements - call for review and test 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, 04 Sep 2012 18:08:39 -0000 On Sep 4, 2012, at 11:56 AM, Ian Lepore wrote: > On Tue, 2012-09-04 at 12:40 -0500, Mark Tinguely wrote: >> On Tue, Sep 4, 2012 at 11:58 AM, Ian Lepore >> wrote: >> How about having a per processor cache line definition rather than = using: >>=20 >> +#define MIN_ZONE_BUFSIZE 32 >>=20 >> For those archs that have a 64 byte cache line. >>=20 >> I like the separation of the regular and BUS_DMA_COHERENT or >> BUS_DMA_NOCACHE. I never liked turning the cache off the entire page >> for a few DMA buffers. >>=20 >> --Mark. >=20 > The code in busdma_bufalloc.c (where that constant appears) knows > nothing about architecture cache line sizes, that info has to be = passed > in to the create call as the minimum_alignment parameter. >=20 > The point of that constant is to enforce internal limits in the > implementation... if the caller passes in a minimum_alignment size = less > than 32, it will still use 32 as the smallest buffer size in the = cache, > purely because it only allocates enough slots in the array to handle > log2(PAGE_SIZE) - log2(MIN_ZONE_BUFSIZE) + 1 zones, but you can't use > log2() in a compile time constant expression, so things are a bit > hand-tuned, and there's some code for sanity-enforcement. kassert then, because we'll have this problem all over again. Would be = nice if we could make those arrays dynamically sized though... Will read the rest of the patch later today... Warner From owner-freebsd-arm@FreeBSD.ORG Tue Sep 4 19:12:59 2012 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 6D852106566B; Tue, 4 Sep 2012 19:12:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 432078FC1A; Tue, 4 Sep 2012 19:12:59 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 64968B972; Tue, 4 Sep 2012 15:12:58 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 4 Sep 2012 12:05:19 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201209041205.19794.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 04 Sep 2012 15:12:58 -0400 (EDT) Cc: freebsd-arm@freebsd.org, Aleksander Dutkowski Subject: Re: availability of interrupts during bootup process 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, 04 Sep 2012 19:12:59 -0000 On Sunday, September 02, 2012 5:31:21 pm Aleksander Dutkowski wrote: > hello! > > I have PMIC (TWL4030) module connected to the SoC (ARM/OMAP3) via i2c (iicbus). > Current solution is that i2c_attach calls bus_generic_attach(dev); > which calls my pmic probe/attach functions, but main configuration of > PMIC in done after drivers setup by config_intrhook. > But I need it to be configured during device attaching, because usb > ehci driver depends on it. > Is it possbile? I've tried it but it hangs on waiting for i2c > interrupt, but someone told me, that interrupts are available during > bootup for some time. No, interrupts do not work during bootup. If you can poll your hardware you could use polling until interrupts are enabled (using 'if (cold)' to check for the boot time before interrupts are enabled). -- John Baldwin From owner-freebsd-arm@FreeBSD.ORG Tue Sep 4 19:30:30 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 112CA1065678; Tue, 4 Sep 2012 19:30:30 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 842F28FC1B; Tue, 4 Sep 2012 19:30:28 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id q84JURk3061606; Tue, 4 Sep 2012 13:30:27 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) 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 q84JUOus041529; Tue, 4 Sep 2012 13:30:24 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Warner Losh In-Reply-To: <2C9793BE-70B0-4A18-B5D2-FBA8C63A4552@bsdimp.com> References: <1346777897.1140.633.camel@revolution.hippie.lan> <1346781390.1140.641.camel@revolution.hippie.lan> <2C9793BE-70B0-4A18-B5D2-FBA8C63A4552@bsdimp.com> Content-Type: text/plain; charset="us-ascii" Date: Tue, 04 Sep 2012 13:30:24 -0600 Message-ID: <1346787024.1140.654.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org Subject: Re: busdma buffer management enhancements - call for review and test 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, 04 Sep 2012 19:30:30 -0000 On Tue, 2012-09-04 at 12:08 -0600, Warner Losh wrote: > On Sep 4, 2012, at 11:56 AM, Ian Lepore wrote: > > > On Tue, 2012-09-04 at 12:40 -0500, Mark Tinguely wrote: > >> On Tue, Sep 4, 2012 at 11:58 AM, Ian Lepore > >> wrote: > >> How about having a per processor cache line definition rather than using: > >> > >> +#define MIN_ZONE_BUFSIZE 32 > >> > >> For those archs that have a 64 byte cache line. > >> > >> I like the separation of the regular and BUS_DMA_COHERENT or > >> BUS_DMA_NOCACHE. I never liked turning the cache off the entire page > >> for a few DMA buffers. > >> > >> --Mark. > > > > The code in busdma_bufalloc.c (where that constant appears) knows > > nothing about architecture cache line sizes, that info has to be passed > > in to the create call as the minimum_alignment parameter. > > > > The point of that constant is to enforce internal limits in the > > implementation... if the caller passes in a minimum_alignment size less > > than 32, it will still use 32 as the smallest buffer size in the cache, > > purely because it only allocates enough slots in the array to handle > > log2(PAGE_SIZE) - log2(MIN_ZONE_BUFSIZE) + 1 zones, but you can't use > > log2() in a compile time constant expression, so things are a bit > > hand-tuned, and there's some code for sanity-enforcement. > > kassert then, because we'll have this problem all over again. Would be nice if we could make those arrays dynamically sized though... > > Will read the rest of the patch later today... It's not really a kassert kind of thing. The allocator automatically creates an uma zone for each power of two size between minimum_alignment and PAGE_SIZE. If the caller passes in a minimum_alignment of 1 (may be perfectly reasonable on some platforms) then we don't need caches of buffers sized at 1, 2, 4, etc, bytes. The 32 is just a reasonable minimum size of buffer to keep in the cache. The upper size limit is enforced with a compile-time check on PAGE_SIZE greater than 64K and a #error. The alternative to this would be to have the caller pass in an upper size limit for cached buffers as well as the lower limit, but we would have to clip the passed in value to PAGE_SIZE to keep meeting the promises the allocator makes about alignments and boundaries and contiguity of the buffers it serves up. We could certainly add code to malloc the array at just the right size. That would typically eliminate a few unused slots the array, saving like 50-100 bytes. -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Sep 4 22:17:32 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D5B76106566B for ; Tue, 4 Sep 2012 22:17:32 +0000 (UTC) (envelope-from hans.stimer@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id A68E18FC0C for ; Tue, 4 Sep 2012 22:17:32 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so10217631pbb.13 for ; Tue, 04 Sep 2012 15:17:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:subject:x-mailer:mime-version:content-type; bh=gzlrtUxjPgzbVOncPi/5k3hhDjihuOlNA4s+Jt1vysU=; b=BsZEAcafzOwGdJ4uxpcssie4j2OugwFT7ez7GhrCm+YZuK9Wy+wCY9a3A7lT0RPJab Fk8hyyaVzY9k+TBtDfLSgB88DMJjDPrj4l9o3X64ZWJB5Nhu9n6n8kKtqRDEGRq7spRm wyGgv2kcvvaIU6U+bPoWAJ/RiY9VXBTbsFZyMfvGAbss3ts9GaXencBAeyZw4408kJED shvTDAY2rH8aZNXE9rvlIWepTssWv5pH2UhhyL2C5Fr7nlFfOjC41QYEYsmpeJ3os0G0 Gsqlh1BGy+pCqKPwsb1UlDhuyrTUpF0vQtBipYFuEBoKrycgMq2ThTzlG/TgXrpHmGSl 3gpQ== Received: by 10.68.242.42 with SMTP id wn10mr38363778pbc.105.1346797052296; Tue, 04 Sep 2012 15:17:32 -0700 (PDT) Received: from [10.0.1.134] (70-90-170-37-ca.sfba.hfc.comcastbusiness.net. [70.90.170.37]) by mx.google.com with ESMTPS id ka4sm13033748pbc.61.2012.09.04.15.17.30 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Sep 2012 15:17:31 -0700 (PDT) Date: Tue, 4 Sep 2012 15:17:29 -0700 From: Hans Stimer To: arm@freebsd.org Message-ID: X-Mailer: sparrow 1.6.3 (build 1172) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: freebsd-beaglebone install problem 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, 04 Sep 2012 22:17:32 -0000 I'm running into problems getting FreeBSD working on the BeagleBone. I followed the instructions here https://github.com/kientzle/freebsd-beaglebone I didn't get any errors, but the BB isn't responding at the terminal: > # cu -l /dev/ttyU1 -s 115200 > Connected > CCCCCCCC It appears that volumes were created properly on the SD card: > # fdisk -s /dev/da1 > /dev/da1: 474 cyl 255 hd 63 sec > Part Start Size Type Flags > 1: 66 4092 0x0c 0x80 > 2: 4158 7613001 0xa5 0x00 > And as best I can tell, the right files are in place: > # ls -laG /mnt/fat > total 761 > drwxr-xr-x 1 root wheel 16384 Dec 31 1979 . > drwxr-xr-x 4 root wheel 512 Sep 4 14:47 .. > drwxr-xr-x 1 root wheel 512 Sep 4 14:31 .Trashes > -rwxr-xr-x 1 root wheel 4096 Sep 4 14:31 ._.Trashes > drwxr-xr-x 1 root wheel 512 Sep 4 14:31 .fseventsd > -rwxr-xr-x 1 root wheel 13320 Sep 4 10:06 LOADER.HEL > -rwxr-xr-x 1 root wheel 738490 Sep 4 10:06 UBLDR > -rwxr-xr-x 1 root wheel 118 Sep 4 10:06 UENV.TXT > > # ls -laG /mnt/ufs > total 4216 > drwxr-xr-x 18 hans hans 1024 Sep 4 10:07 . > drwxr-xr-x 4 root wheel 512 Sep 4 14:47 .. > -rw-r--r-- 2 root wheel 1005 Sep 4 10:07 .cshrc > -rw-r--r-- 2 root wheel 247 Sep 4 10:07 .profile > drwxrwxr-x 2 root operator 512 Sep 4 10:06 .snap > -r-------- 1 root wheel 4194304 Sep 4 10:06 .sujournal > -r--r--r-- 1 root wheel 6194 Sep 4 10:07 COPYRIGHT > drwxr-xr-x 2 root wheel 1024 Sep 4 10:06 bin > drwxr-xr-x 7 root wheel 512 Sep 4 10:07 boot > dr-xr-xr-x 2 root wheel 512 Sep 4 10:06 dev > drwxr-xr-x 20 hans hans 2048 Sep 4 10:07 etc > drwxr-xr-x 3 root wheel 1536 Sep 4 10:06 lib > drwxr-xr-x 3 root wheel 512 Sep 4 10:06 libexec > drwxr-xr-x 2 root wheel 512 Sep 4 10:06 media > drwxr-xr-x 2 root wheel 512 Sep 4 10:06 mnt > dr-xr-xr-x 2 root wheel 512 Sep 4 10:06 proc > drwxr-xr-x 2 root wheel 2560 Sep 4 10:06 rescue > drwxr-xr-x 2 root wheel 512 Sep 4 10:07 root > drwxr-xr-x 2 root wheel 2560 Sep 4 10:07 sbin > lrwxr-xr-x 1 root wheel 11 Sep 4 10:07 sys -> usr/src/sys > drwxrwxrwt 2 root wheel 512 Sep 4 10:06 tmp > drwxr-xr-x 14 root wheel 512 Sep 4 10:06 usr > drwxr-xr-x 23 root wheel 512 Sep 4 10:06 var > > I checked the logs, and this one stood out: > # less _.uboot.build.log > Generating include/autoconf.mk > include/common.h:43:20: error: stdarg.h: No such file or directory > In file included from include/image.h:36, > from include/common.h:117: > include/compiler.h:8:20: error: stddef.h: No such file or directory > Generating include/autoconf.mk.dep > include/common.h:43:20: error: stdarg.h: No such file or directory > In file included from include/image.h:36, > from include/common.h:117: > include/compiler.h:8:20: error: stddef.h: No such file or directory > arm-freebsd-gcc -DDO_DEPS_ONLY \ > -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x80100000 -DCONFIG_SPL_TEXT_BASE=0x402F0400 -I/usr/home/hans/extern/freebsd-beaglebone/u-boot/include -fno-builtin -ffreestanding -nostdinc -isystem include -pipe -DCONFIG_ARM -D__ARM__ -marm -mabi=aapcs-linux -mno-thumb-interwork -march=armv5 -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security \ > -o lib/asm-offsets.s lib/asm-offsets.c -c -S > In file included from lib/asm-offsets.c:18: > include/common.h:43:20: error: stdarg.h: No such file or directory > In file included from include/image.h:36, > from include/common.h:117, > from lib/asm-offsets.c:18: > include/compiler.h:8:20: error: stddef.h: No such file or directory > In file included from lib/asm-offsets.c:18: > include/common.h:687: error: expected declaration specifiers or '...' before 'va_list' > In file included from lib/asm-offsets.c:18: > include/common.h:719: error: expected declaration specifiers or '...' before 'va_list' > gmake: *** [lib/asm-offsets.s] Error 1 > > From owner-freebsd-arm@FreeBSD.ORG Tue Sep 4 22:37:24 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8C85A106566C; Tue, 4 Sep 2012 22:37:24 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 59AC78FC12; Tue, 4 Sep 2012 22:37:24 +0000 (UTC) Received: by dadr6 with SMTP id r6so4547134dad.13 for ; Tue, 04 Sep 2012 15:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ZJe3OoLFdSsq1rBmGDayZfLAp1Il/rhpWhdamY8Z8bc=; b=MNHakFwHb1fNZ1QAGvDLalimv9oh5MYXZYNwpJeRMyzLbVBQ8KRzNTGecyFkONceTm sQI+X5InEEO85e4UiGNNLWGIpYKCQrw+lDIV0QUs2xuPgWDasuvYbjjRwjw797C6EUiV cD5404fcZnMB70zCHyPA4lXHIxIiRiYqelfwiLl1JCm4y390WkDN3ncH/llYzP4HCbgx aPY42pUtsSceGb2Fqtu5sJmP0JLUTWVdEve0gCh17ZQOS0ma6fFlL4G4a9D+KkP/iRIT edUCtEkQcf6NQJVKyZ3saytqG97qhHbhyJW2v6vsgihjLHhkB1RLosP99asJSXmdjFk2 PLTw== MIME-Version: 1.0 Received: by 10.68.136.40 with SMTP id px8mr49067570pbb.153.1346798243121; Tue, 04 Sep 2012 15:37:23 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.36.106 with HTTP; Tue, 4 Sep 2012 15:37:23 -0700 (PDT) In-Reply-To: <1346777897.1140.633.camel@revolution.hippie.lan> References: <1346777897.1140.633.camel@revolution.hippie.lan> Date: Tue, 4 Sep 2012 15:37:23 -0700 X-Google-Sender-Auth: xymgd16ysxWbbyH4b5OQVWzf11M Message-ID: From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org Subject: Re: busdma buffer management enhancements - call for review and test 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, 04 Sep 2012 22:37:24 -0000 Hiya, This is pretty neat work. :) But by converting drivers to use individual uma allocations, aren't you risking fragmenting FIFO rings and such? I'm sure there are platforms out there whose memory controllers operate on minimum sized bits (say, 512 byte chunks for some intel PC chipsets, if I'm not mistaken) .. right now ath(4)'s RX descriptors are almost always kept in order of allocation, but with your proposal it's quite possible they'll be spread all around the the (fixed size) UMA slab. I can't help but think there's some larger scale issues here that are slightly orthogonal to the requirements of (small) embedded platforms. Adrian From owner-freebsd-arm@FreeBSD.ORG Tue Sep 4 23:57:47 2012 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 13C84106566C; Tue, 4 Sep 2012 23:57:47 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id BC5DE8FC0A; Tue, 4 Sep 2012 23:57:46 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id q84NvjOb065536; Tue, 4 Sep 2012 17:57:45 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) 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 q84NvgSK041858; Tue, 4 Sep 2012 17:57:42 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Adrian Chadd In-Reply-To: References: <1346777897.1140.633.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Tue, 04 Sep 2012 17:57:42 -0600 Message-ID: <1346803062.59094.27.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org Subject: Re: busdma buffer management enhancements - call for review and test 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, 04 Sep 2012 23:57:47 -0000 On Tue, 2012-09-04 at 15:37 -0700, Adrian Chadd wrote: > Hiya, > > This is pretty neat work. :) > > But by converting drivers to use individual uma allocations, aren't > you risking fragmenting FIFO rings and such? I'm sure there are > platforms out there whose memory controllers operate on minimum sized > bits (say, 512 byte chunks for some intel PC chipsets, if I'm not > mistaken) .. right now ath(4)'s RX descriptors are almost always kept > in order of allocation, but with your proposal it's quite possible > they'll be spread all around the the (fixed size) UMA slab. > I'm not quite sure I understand what you mean by that. Or rather, I'm not sure I understand the downside to a bunch of individual descriptors being scattered around in memory. If the hardware treats the descriptors as a linked list, it shouldn't matter where they're scattered. If it treats them as an array, then the only option is to allocate a single chunk of memory to hold the whole array, isn't it? In either case, what to do with the busdma sync ops when working with lists or arrays of descriptors that are shared between the CPU and a controller that accesses the same memory independently... well, that's something that's not directly addressed by this set of changes. If the CPU and the hardware are accessing the memory truly concurrently (such as what happens with a usb host controller), the current busdma code and documentation doesn't really address that. We need more discussion on that, but when I approached the topic in the freebsd-arch thread last week, the discussion fizzled out. We'll have to get back to it eventually. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Sep 5 01:07:58 2012 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 BECF41065679 for ; Wed, 5 Sep 2012 01:07:58 +0000 (UTC) (envelope-from imp@bsdimp.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 7F7738FC0A for ; Wed, 5 Sep 2012 01:07:58 +0000 (UTC) Received: by iayy25 with SMTP id y25so371236iay.13 for ; Tue, 04 Sep 2012 18:07:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=lrQPQLzXPS9mXqvBnlsSUDORlfMVe/Pi4NuWZDgXuqM=; b=f4CX+Osl9tE1a3GsMkk2SS1RxJQsQXqBCKSZPMaGIhCyO9QJXIZ/hsqxk2ZCAIGgrf M3aJ6xsYPHRYZ8y7Hp0TfTcy7Z62xK+jVXtBKXgSEu+AoehGFrUr03T15oFXmIUAw+QY fpiAkvR79X9DgcXJkRsscFdXkQSpMPqKoNuP0x8CclDWeP2U6Lj8rY8W35QT3pvIwVup 0uZ5dzyNTQQJH8V+bAMjYLKpKwYeL3EKeZiRILUqqLRDbxwAoMQ+LFkxEU/FyaTh5NvY +hCXkhEkXdSsAHO2FmZ4w65gx1TGMNiwsIfQ6KqYc5WNu7Vwpa9vieSttKYXutUULA1F 2iLQ== Received: by 10.50.207.35 with SMTP id lt3mr15892817igc.49.1346807277656; Tue, 04 Sep 2012 18:07:57 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id ey10sm29328473igb.17.2012.09.04.18.07.56 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Sep 2012 18:07:56 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Tue, 4 Sep 2012 19:07:55 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <0DCAC001-FF06-431A-A486-2B50BE913B0D@bsdimp.com> References: To: Hans Stimer X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQlWJrbNHfuQYBAFUaC7SYgdK/MrkCWvFb7BiPk8CcFWPJfj3PBR37RiA0r9mwEqE+c1lOPv Cc: arm@freebsd.org Subject: Re: freebsd-beaglebone install problem 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, 05 Sep 2012 01:07:58 -0000 On Sep 4, 2012, at 4:17 PM, Hans Stimer wrote: > I'm running into problems getting FreeBSD working on the BeagleBone. >=20 > I followed the instructions here = https://github.com/kientzle/freebsd-beaglebone >=20 > I didn't get any errors, but the BB isn't responding at the terminal: >=20 >> # cu -l /dev/ttyU1 -s 115200 >> Connected >> CCCCCCCC Oh xmodem, I know ye well. This means that the card is in some recovery = mode or another... Warner >=20 >=20 > It appears that volumes were created properly on the SD card: >=20 >> # fdisk -s /dev/da1 >> /dev/da1: 474 cyl 255 hd 63 sec >> Part Start Size Type Flags >> 1: 66 4092 0x0c 0x80 >> 2: 4158 7613001 0xa5 0x00 >>=20 >=20 >=20 > And as best I can tell, the right files are in place: >=20 >> # ls -laG /mnt/fat >> total 761 >> drwxr-xr-x 1 root wheel 16384 Dec 31 1979 . >> drwxr-xr-x 4 root wheel 512 Sep 4 14:47 .. >> drwxr-xr-x 1 root wheel 512 Sep 4 14:31 .Trashes >> -rwxr-xr-x 1 root wheel 4096 Sep 4 14:31 ._.Trashes >> drwxr-xr-x 1 root wheel 512 Sep 4 14:31 .fseventsd >> -rwxr-xr-x 1 root wheel 13320 Sep 4 10:06 LOADER.HEL >> -rwxr-xr-x 1 root wheel 738490 Sep 4 10:06 UBLDR >> -rwxr-xr-x 1 root wheel 118 Sep 4 10:06 UENV.TXT >>=20 >> # ls -laG /mnt/ufs >> total 4216 >> drwxr-xr-x 18 hans hans 1024 Sep 4 10:07 . >> drwxr-xr-x 4 root wheel 512 Sep 4 14:47 .. >> -rw-r--r-- 2 root wheel 1005 Sep 4 10:07 .cshrc >> -rw-r--r-- 2 root wheel 247 Sep 4 10:07 .profile >> drwxrwxr-x 2 root operator 512 Sep 4 10:06 .snap >> -r-------- 1 root wheel 4194304 Sep 4 10:06 .sujournal >> -r--r--r-- 1 root wheel 6194 Sep 4 10:07 COPYRIGHT >> drwxr-xr-x 2 root wheel 1024 Sep 4 10:06 bin >> drwxr-xr-x 7 root wheel 512 Sep 4 10:07 boot >> dr-xr-xr-x 2 root wheel 512 Sep 4 10:06 dev >> drwxr-xr-x 20 hans hans 2048 Sep 4 10:07 etc >> drwxr-xr-x 3 root wheel 1536 Sep 4 10:06 lib >> drwxr-xr-x 3 root wheel 512 Sep 4 10:06 libexec >> drwxr-xr-x 2 root wheel 512 Sep 4 10:06 media >> drwxr-xr-x 2 root wheel 512 Sep 4 10:06 mnt >> dr-xr-xr-x 2 root wheel 512 Sep 4 10:06 proc >> drwxr-xr-x 2 root wheel 2560 Sep 4 10:06 rescue >> drwxr-xr-x 2 root wheel 512 Sep 4 10:07 root >> drwxr-xr-x 2 root wheel 2560 Sep 4 10:07 sbin >> lrwxr-xr-x 1 root wheel 11 Sep 4 10:07 sys -> = usr/src/sys >> drwxrwxrwt 2 root wheel 512 Sep 4 10:06 tmp >> drwxr-xr-x 14 root wheel 512 Sep 4 10:06 usr >> drwxr-xr-x 23 root wheel 512 Sep 4 10:06 var >>=20 >>=20 >=20 >=20 > I checked the logs, and this one stood out: >=20 >> # less _.uboot.build.log=20 >> Generating include/autoconf.mk >> include/common.h:43:20: error: stdarg.h: No such file or directory >> In file included from include/image.h:36, >> from include/common.h:117: >> include/compiler.h:8:20: error: stddef.h: No such file or directory >> Generating include/autoconf.mk.dep >> include/common.h:43:20: error: stdarg.h: No such file or directory >> In file included from include/image.h:36, >> from include/common.h:117: >> include/compiler.h:8:20: error: stddef.h: No such file or directory >> arm-freebsd-gcc -DDO_DEPS_ONLY \ >> -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ = -DCONFIG_SYS_TEXT_BASE=3D0x80100000 -DCONFIG_SPL_TEXT_BASE=3D0x402F0400 = -I/usr/home/hans/extern/freebsd-beaglebone/u-boot/include -fno-builtin = -ffreestanding -nostdinc -isystem include -pipe -DCONFIG_ARM -D__ARM__ = -marm -mabi=3Daapcs-linux -mno-thumb-interwork -march=3Darmv5 -Wall = -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral = -Wno-format-security \ >> -o lib/asm-offsets.s lib/asm-offsets.c -c -S >> In file included from lib/asm-offsets.c:18: >> include/common.h:43:20: error: stdarg.h: No such file or directory >> In file included from include/image.h:36, >> from include/common.h:117, >> from lib/asm-offsets.c:18: >> include/compiler.h:8:20: error: stddef.h: No such file or directory >> In file included from lib/asm-offsets.c:18: >> include/common.h:687: error: expected declaration specifiers or '...' = before 'va_list' >> In file included from lib/asm-offsets.c:18: >> include/common.h:719: error: expected declaration specifiers or '...' = before 'va_list' >> gmake: *** [lib/asm-offsets.s] Error 1 >>=20 >>=20 >=20 >=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" From owner-freebsd-arm@FreeBSD.ORG Wed Sep 5 01:30:12 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B8C70106564A for ; Wed, 5 Sep 2012 01:30:12 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 813D68FC14 for ; Wed, 5 Sep 2012 01:30:12 +0000 (UTC) Received: by dadr6 with SMTP id r6so4629756dad.13 for ; Tue, 04 Sep 2012 18:30:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=MgCmdp7Y2OPNjUYt0RwQJrXJ8mIt01YXUGfrzawU9bo=; b=Z0dBNv0G3Uh4ZfgUE1/UFQz+2bDXaZL+MuAGruv/cqfBEml9MvrMyzjs8MdK3DpYUe zP1ge1fLzYb7FwjnwJQIyp+4ss2AFUud1vjc5riEg/f1VHzIvC2C26w5xIoVdNKpOZDC cH198vVD5aSV/v22xAS10ivYOwILRcqNImaoAO2iIrSHkVVulWhV8FtKFYnEhUVv2MDH 77ffoonTEs7amGQPRy1mm46wlDCGA+K6Vlhv/1+K6vrYXrI5l5EEhGV97J5TN9BbcNFZ 8WlRDVb/XBL1zyz+ISotYPGmwWyYW/++ZKQ7AYbnMsz0VehKmbHDRA939ZFEXSbqWMbU JQBw== Received: by 10.66.84.130 with SMTP id z2mr45086929pay.77.1346808611583; Tue, 04 Sep 2012 18:30:11 -0700 (PDT) Received: from [10.0.0.63] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id kt8sm247384pbc.1.2012.09.04.18.30.08 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Sep 2012 18:30:11 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <201209041205.19794.jhb@freebsd.org> Date: Tue, 4 Sep 2012 19:30:08 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <13628135-18C7-4D98-B2DC-60C8AB65A643@bsdimp.com> References: <201209041205.19794.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQl6ayuEeyFtTKVSNTjkrOxJU4PCsMTnnbgSnJnqbzFsS7WkkCC07nqHgT16kT2QtK9P6u2V Cc: freebsd-hackers@freebsd.org, freebsd-arm@freebsd.org, Aleksander Dutkowski Subject: Re: availability of interrupts during bootup process 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, 05 Sep 2012 01:30:12 -0000 On Sep 4, 2012, at 10:05 AM, John Baldwin wrote: > On Sunday, September 02, 2012 5:31:21 pm Aleksander Dutkowski wrote: >> hello! >>=20 >> I have PMIC (TWL4030) module connected to the SoC (ARM/OMAP3) via i2c=20= > (iicbus). >> Current solution is that i2c_attach calls bus_generic_attach(dev); >> which calls my pmic probe/attach functions, but main configuration of >> PMIC in done after drivers setup by config_intrhook. >> But I need it to be configured during device attaching, because usb >> ehci driver depends on it. >> Is it possbile? I've tried it but it hangs on waiting for i2c >> interrupt, but someone told me, that interrupts are available during >> bootup for some time. >=20 > No, interrupts do not work during bootup. If you can poll your = hardware > you could use polling until interrupts are enabled (using 'if (cold)' = to > check for the boot time before interrupts are enabled). Are interrupts off, or ithreads not scheduled? I thought I had some = stuff working that needed interrupts, but didn't need scheduling.. Am I = nuts? Warner From owner-freebsd-arm@FreeBSD.ORG Wed Sep 5 03:07:01 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 15766106564A; Wed, 5 Sep 2012 03:07:00 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9A5B58FC0A; Wed, 5 Sep 2012 03:07:00 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so184527pbb.13 for ; Tue, 04 Sep 2012 20:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=G/kkzvt6+mSEyhu95mT6Vickjqa3J2ISwbxd14cYE3I=; b=L/x0qXuZRg5qpp8AIL9lhgTh/PN408IbZ+zbajYhXiNBa9KyUMhXX0xv6XCmHxbf9B Ztl1zsT4vYcquKXf/HZ7BhkimSQyYafQREHPXlHCX4Kc93OsfGsoeN7isrrGm5PYT/Q2 vzPoHbxHuKlk6I5Ls4t4nPKD+j7c6nhtPH7cgqjgisU9CRQMBf2s+ueUA4BYnYN1bQ7c c3yKy+i5ugBJxpp9MYk7gBZ0vn30dirmsxXMPGLCV6Y/Ql2xQPtML4wctcFmkDu/jTLR HavN/qnkYD6ygRFTOHCV32RUT64P1K3JAF3uybnBibAaOCUXPSS0eo8vQeJYfJcX/A5K fNEA== MIME-Version: 1.0 Received: by 10.68.138.169 with SMTP id qr9mr50593434pbb.27.1346814420323; Tue, 04 Sep 2012 20:07:00 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.36.106 with HTTP; Tue, 4 Sep 2012 20:06:59 -0700 (PDT) In-Reply-To: <1346803062.59094.27.camel@revolution.hippie.lan> References: <1346777897.1140.633.camel@revolution.hippie.lan> <1346803062.59094.27.camel@revolution.hippie.lan> Date: Tue, 4 Sep 2012 20:06:59 -0700 X-Google-Sender-Auth: qmYOCfuOZlOdFRKayfgTq13CIbY Message-ID: From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org Subject: Re: busdma buffer management enhancements - call for review and test 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, 05 Sep 2012 03:07:01 -0000 I just want to make sure that you don't assume individual memory access costs are the same regardless of how big the allocations are. Ie, if you have a bunch of scattered L1-sized allocations, versus them all being nearby in the same 512/1024 byte page; the underlying memory architecture may be doing memory transactions at a slightly larger size than your L1 assumption. Damn these hierarchicial memory systems. Adrian From owner-freebsd-arm@FreeBSD.ORG Wed Sep 5 03:19:22 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5BD4C106566C for ; Wed, 5 Sep 2012 03:19:22 +0000 (UTC) (envelope-from hans.stimer@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 25BA18FC0A for ; Wed, 5 Sep 2012 03:19:21 +0000 (UTC) Received: by dadr6 with SMTP id r6so32520dad.13 for ; Tue, 04 Sep 2012 20:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type; bh=iXF0Zw/hCsxPmtd+Mei3Uw1gRyBvvpkSLHaOCT94G40=; b=gBVxBDPpUVt5BoSAY4i75xPrOZEP/hM4j6fg0mDTu/UKJyBQAdog7AwLCeYJBMsxlA qZq1KhE9NZ0IM2OyAGpf/gQWzjc51HNyXDnFX4zt1nWZVUd8g1IDwhui3a8NNWjIW+rA AYyn19WWHqyvNb93Tiae89/YbhMnfWuhzFeLWTcxPFXXdCQrlh+hpeEScd6/7CrxFNxn fUz9+XfQgrjdC21pEw1k60PpSEvaVm5PEpGyyOWjdUPddpx/3ghpWi2wGOy9BYBsJU+j y2OCW0q+T0UQQJ7iJyTQBkCmARXn/FmmJYxr1b7q0CeruCfZiMTCVwAq+cwkXqfdsbPQ sCRg== Received: by 10.68.237.38 with SMTP id uz6mr51457340pbc.23.1346815161508; Tue, 04 Sep 2012 20:19:21 -0700 (PDT) Received: from [10.0.1.134] (70-90-170-37-ca.sfba.hfc.comcastbusiness.net. [70.90.170.37]) by mx.google.com with ESMTPS id jz10sm425268pbc.8.2012.09.04.20.19.19 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Sep 2012 20:19:20 -0700 (PDT) Date: Tue, 4 Sep 2012 20:19:18 -0700 From: Hans Stimer To: Warner Losh Message-ID: <39787E1DC71F4739B78636D9293A09B7@gmail.com> In-Reply-To: <0DCAC001-FF06-431A-A486-2B50BE913B0D@bsdimp.com> References: <0DCAC001-FF06-431A-A486-2B50BE913B0D@bsdimp.com> X-Mailer: sparrow 1.6.3 (build 1172) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: arm@freebsd.org Subject: Re: freebsd-beaglebone install problem 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, 05 Sep 2012 03:19:22 -0000 Any idea how to diagnose? btw - tried same image in another BB and got the same result. On Tuesday, September 4, 2012 at 6:07 PM, Warner Losh wrote: > > On Sep 4, 2012, at 4:17 PM, Hans Stimer wrote: > > > I'm running into problems getting FreeBSD working on the BeagleBone. > > > > I followed the instructions here https://github.com/kientzle/freebsd-beaglebone > > > > I didn't get any errors, but the BB isn't responding at the terminal: > > > > > # cu -l /dev/ttyU1 -s 115200 > > > Connected > > > CCCCCCCC > > > > > > > > > > Oh xmodem, I know ye well. This means that the card is in some recovery mode or another... > > Warner > > > > > > > It appears that volumes were created properly on the SD card: > > > > > # fdisk -s /dev/da1 > > > /dev/da1: 474 cyl 255 hd 63 sec > > > Part Start Size Type Flags > > > 1: 66 4092 0x0c 0x80 > > > 2: 4158 7613001 0xa5 0x00 > > > > > > > > > > > And as best I can tell, the right files are in place: > > > > > # ls -laG /mnt/fat > > > total 761 > > > drwxr-xr-x 1 root wheel 16384 Dec 31 1979 . > > > drwxr-xr-x 4 root wheel 512 Sep 4 14:47 .. > > > drwxr-xr-x 1 root wheel 512 Sep 4 14:31 .Trashes > > > -rwxr-xr-x 1 root wheel 4096 Sep 4 14:31 ._.Trashes > > > drwxr-xr-x 1 root wheel 512 Sep 4 14:31 .fseventsd > > > -rwxr-xr-x 1 root wheel 13320 Sep 4 10:06 LOADER.HEL > > > -rwxr-xr-x 1 root wheel 738490 Sep 4 10:06 UBLDR > > > -rwxr-xr-x 1 root wheel 118 Sep 4 10:06 UENV.TXT > > > > > > # ls -laG /mnt/ufs > > > total 4216 > > > drwxr-xr-x 18 hans hans 1024 Sep 4 10:07 . > > > drwxr-xr-x 4 root wheel 512 Sep 4 14:47 .. > > > -rw-r--r-- 2 root wheel 1005 Sep 4 10:07 .cshrc > > > -rw-r--r-- 2 root wheel 247 Sep 4 10:07 .profile > > > drwxrwxr-x 2 root operator 512 Sep 4 10:06 .snap > > > -r-------- 1 root wheel 4194304 Sep 4 10:06 .sujournal > > > -r--r--r-- 1 root wheel 6194 Sep 4 10:07 COPYRIGHT > > > drwxr-xr-x 2 root wheel 1024 Sep 4 10:06 bin > > > drwxr-xr-x 7 root wheel 512 Sep 4 10:07 boot > > > dr-xr-xr-x 2 root wheel 512 Sep 4 10:06 dev > > > drwxr-xr-x 20 hans hans 2048 Sep 4 10:07 etc > > > drwxr-xr-x 3 root wheel 1536 Sep 4 10:06 lib > > > drwxr-xr-x 3 root wheel 512 Sep 4 10:06 libexec > > > drwxr-xr-x 2 root wheel 512 Sep 4 10:06 media > > > drwxr-xr-x 2 root wheel 512 Sep 4 10:06 mnt > > > dr-xr-xr-x 2 root wheel 512 Sep 4 10:06 proc > > > drwxr-xr-x 2 root wheel 2560 Sep 4 10:06 rescue > > > drwxr-xr-x 2 root wheel 512 Sep 4 10:07 root > > > drwxr-xr-x 2 root wheel 2560 Sep 4 10:07 sbin > > > lrwxr-xr-x 1 root wheel 11 Sep 4 10:07 sys -> usr/src/sys > > > drwxrwxrwt 2 root wheel 512 Sep 4 10:06 tmp > > > drwxr-xr-x 14 root wheel 512 Sep 4 10:06 usr > > > drwxr-xr-x 23 root wheel 512 Sep 4 10:06 var > > > > > > > > > > > I checked the logs, and this one stood out: > > > > > # less _.uboot.build.log > > > Generating include/autoconf.mk > > > include/common.h:43:20: error: stdarg.h: No such file or directory > > > In file included from include/image.h:36, > > > from include/common.h:117: > > > include/compiler.h:8:20: error: stddef.h: No such file or directory > > > Generating include/autoconf.mk.dep > > > include/common.h:43:20: error: stdarg.h: No such file or directory > > > In file included from include/image.h:36, > > > from include/common.h:117: > > > include/compiler.h:8:20: error: stddef.h: No such file or directory > > > arm-freebsd-gcc -DDO_DEPS_ONLY \ > > > -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x80100000 -DCONFIG_SPL_TEXT_BASE=0x402F0400 -I/usr/home/hans/extern/freebsd-beaglebone/u-boot/include -fno-builtin -ffreestanding -nostdinc -isystem include -pipe -DCONFIG_ARM -D__ARM__ -marm -mabi=aapcs-linux -mno-thumb-interwork -march=armv5 -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security \ > > > -o lib/asm-offsets.s lib/asm-offsets.c -c -S > > > In file included from lib/asm-offsets.c:18: > > > include/common.h:43:20: error: stdarg.h: No such file or directory > > > In file included from include/image.h:36, > > > from include/common.h:117, > > > from lib/asm-offsets.c:18: > > > include/compiler.h:8:20: error: stddef.h: No such file or directory > > > In file included from lib/asm-offsets.c:18: > > > include/common.h:687: error: expected declaration specifiers or '...' before 'va_list' > > > In file included from lib/asm-offsets.c:18: > > > include/common.h:719: error: expected declaration specifiers or '...' before 'va_list' > > > gmake: *** [lib/asm-offsets.s] Error 1 > > > > > > > > > > > _______________________________________________ > > freebsd-arm@freebsd.org (mailto: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 (mailto:freebsd-arm-unsubscribe@freebsd.org)" > > > > > From owner-freebsd-arm@FreeBSD.ORG Wed Sep 5 04:22:47 2012 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 D2E9D106564A for ; Wed, 5 Sep 2012 04:22:47 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id AD0338FC14 for ; Wed, 5 Sep 2012 04:22:47 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q854MfFF037887; Wed, 5 Sep 2012 04:22:41 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id qirigqa8r8rprwiqr26f5xujts; Wed, 05 Sep 2012 04:22:41 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: <0DCAC001-FF06-431A-A486-2B50BE913B0D@bsdimp.com> Date: Tue, 4 Sep 2012 21:22:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0DCAC001-FF06-431A-A486-2B50BE913B0D@bsdimp.com> To: Hans Stimer X-Mailer: Apple Mail (2.1278) Cc: arm@freebsd.org Subject: Re: freebsd-beaglebone install problem 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, 05 Sep 2012 04:22:47 -0000 On Sep 4, 2012, at 6:07 PM, Warner Losh wrote: >=20 > On Sep 4, 2012, at 4:17 PM, Hans Stimer wrote: >=20 >> I'm running into problems getting FreeBSD working on the BeagleBone. >>=20 >>> # cu -l /dev/ttyU1 -s 115200 >>> Connected >>> CCCCCCCC >=20 The ROM code for the AM3358 SoC in the BeagleBone falls back to YModem if it can't load the first-stage MLO boot loader from SDHC. If you see this, then either the FAT partition is ill-formed or the MLO file is missing. >> I checked the logs, and this one stood out: >>=20 >>> # less _.uboot.build.log=20 >>> Generating include/autoconf.mk >>> include/common.h:43:20: error: stdarg.h: No such file or directory >>> In file included from include/image.h:36, >>> from include/common.h:117: Yeah, looks like U-Boot didn't build. I haven't updated my local U-Boot sources in a while, I'll go do that and get right back to you=85 Cheers, Tim From owner-freebsd-arm@FreeBSD.ORG Wed Sep 5 04:28:38 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C6CC81065674 for ; Wed, 5 Sep 2012 04:28:38 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 9FCA78FC16 for ; Wed, 5 Sep 2012 04:28:38 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q854Sbwt037911; Wed, 5 Sep 2012 04:28:37 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id uz2vrm5y4xh3cxz5arbbaj9v42; Wed, 05 Sep 2012 04:28:37 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: Date: Tue, 4 Sep 2012 21:28:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7E18623F-3945-4EA0-B332-5A5C717B20F0@kientzle.com> References: <0DCAC001-FF06-431A-A486-2B50BE913B0D@bsdimp.com> To: Hans Stimer X-Mailer: Apple Mail (2.1278) Cc: arm@freebsd.org Subject: Re: freebsd-beaglebone install problem 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, 05 Sep 2012 04:28:38 -0000 On Sep 4, 2012, at 9:22 PM, Tim Kientzle wrote: >=20 > On Sep 4, 2012, at 6:07 PM, Warner Losh wrote: >=20 >>=20 >> On Sep 4, 2012, at 4:17 PM, Hans Stimer wrote: >>=20 >>> I'm running into problems getting FreeBSD working on the BeagleBone. >=20 >>>=20 >>>> # cu -l /dev/ttyU1 -s 115200 >>>> Connected >>>> CCCCCCCC >>=20 >=20 > The ROM code for the AM3358 SoC in the BeagleBone falls > back to YModem if it can't load the first-stage MLO boot loader > from SDHC. >=20 > If you see this, then either the FAT partition is > ill-formed or the MLO file is missing. >=20 >>> I checked the logs, and this one stood out: >>>=20 >>>> # less _.uboot.build.log=20 >>>> Generating include/autoconf.mk >>>> include/common.h:43:20: error: stdarg.h: No such file or directory >>>> In file included from include/image.h:36, >>>> from include/common.h:117: >=20 > Yeah, looks like U-Boot didn't build. >=20 > I haven't updated my local U-Boot sources in a while, > I'll go do that and get right back to you=85 Please update the freebsd-beaglebone scripts and try again. I found and fixed a couple of problems: * I had reversed the logic to decide if patches were already applied, so U-Boot wasn't getting patched. * One of my patches needed to be updated to work with the newest U-Boot sources. * I added some logic so that the beaglebsd.sh script will actually fail with an error message if the U-Boot patch, configure, or build steps fail. This should make problems like this more obvious. Let me know if you run into any other issues. Cheers, Tim From owner-freebsd-arm@FreeBSD.ORG Wed Sep 5 04:52:36 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 01CAF106564A for ; Wed, 5 Sep 2012 04:52:36 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id CE3C28FC17 for ; Wed, 5 Sep 2012 04:52:35 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q854qXr8038039; Wed, 5 Sep 2012 04:52:33 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id cypqu3e2jjaw8yvin9z2jnm9ya; Wed, 05 Sep 2012 04:52:33 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <9896AA3E-D8A0-4CE8-8160-4672AA07388F@cheney.net> Date: Tue, 4 Sep 2012 21:52:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6B74ADD7-3266-4919-BEB4-B10E0C1BAB58@kientzle.com> References: <0DCAC001-FF06-431A-A486-2B50BE913B0D@bsdimp.com> <7E18623F-3945-4EA0-B332-5A5C717B20F0@kientzle.com> <9896AA3E-D8A0-4CE8-8160-4672AA07388F@cheney.net> To: Dave Cheney X-Mailer: Apple Mail (2.1278) Cc: arm@freebsd.org Subject: Towards an ARM system-building script 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, 05 Sep 2012 04:52:36 -0000 On Sep 4, 2012, at 9:33 PM, Dave Cheney wrote: > Sorry to butt in on this discussion, but how feasible would it be to = adapt this build script to the pandaboard. I understand there may be a = config in svn similar to the beaglebone which may be applicable.=20 I've started tinkering with ideas for generalizing my BeagleBone script so it can build system images for other boards. The issue isn't the FreeBSD kernel config but rather juggling all the different pieces of boot machinery and the various filesystem constraints. Still just noodling the idea around, but I think I've got a few things to build on. For now, I'm limiting it to just: * ARM-based boards * Building a disk image I only have a BeagleBone and a RaspberryPi at the moment, so Pandaboard support would require some help. At a minimum, I'd be interested in an outline of what a Pandaboard image looks like in terms of boot files, partitions, etc. Tim From owner-freebsd-arm@FreeBSD.ORG Wed Sep 5 05:03:30 2012 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 4367D106566C for ; Wed, 5 Sep 2012 05:03:30 +0000 (UTC) (envelope-from gonzo@hq.bluezbox.com) Received: from hq.bluezbox.com (hq.bluezbox.com [70.38.37.145]) by mx1.freebsd.org (Postfix) with ESMTP id E85CF8FC0A for ; Wed, 5 Sep 2012 05:03:29 +0000 (UTC) Received: from [207.6.240.242] (helo=[192.168.1.64]) by hq.bluezbox.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1T97lQ-0001Wg-DL; Tue, 04 Sep 2012 22:02:58 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1463\)) From: Oleksandr Tymoshenko In-Reply-To: <6B74ADD7-3266-4919-BEB4-B10E0C1BAB58@kientzle.com> Date: Tue, 4 Sep 2012 22:03:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0DCAC001-FF06-431A-A486-2B50BE913B0D@bsdimp.com> <7E18623F-3945-4EA0-B332-5A5C717B20F0@kientzle.com> <9896AA3E-D8A0-4CE8-8160-4672AA07388F@cheney.net> <6B74ADD7-3266-4919-BEB4-B10E0C1BAB58@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1463) Sender: gonzo@hq.bluezbox.com X-Spam-Level: ---- X-Spam-Report: Spam detection software, running on the system "hq.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 2012-09-04, at 9:52 PM, Tim Kientzle wrote: > > On Sep 4, 2012, at 9:33 PM, Dave Cheney wrote: > >> Sorry to butt in on this discussion, but how feasible would it be to adapt this build script to the pandaboard. I understand there may be a config in svn similar to the beaglebone which may be applicable. > > I've started tinkering with ideas for generalizing my > BeagleBone script so it can build system images for > other boards. > > The issue isn't the FreeBSD kernel config but rather > juggling all the different pieces of boot machinery > and the various filesystem constraints. > > Still just noodling the idea around, but I think I've > got a few things to build on. For now, I'm limiting it to > just: > * ARM-based boards > * Building a disk image > > I only have a BeagleBone and a RaspberryPi at > the moment, so Pandaboard support would require > some help. At a minimum, I'd be interested in > an outline of what a Pandaboard image looks > like in terms of boot files, partitions, etc. [...] Content analysis details: (-4.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Cc: arm@freebsd.org Subject: Re: Towards an ARM system-building script 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, 05 Sep 2012 05:03:30 -0000 On 2012-09-04, at 9:52 PM, Tim Kientzle wrote: >=20 > On Sep 4, 2012, at 9:33 PM, Dave Cheney wrote: >=20 >> Sorry to butt in on this discussion, but how feasible would it be to = adapt this build script to the pandaboard. I understand there may be a = config in svn similar to the beaglebone which may be applicable.=20 >=20 > I've started tinkering with ideas for generalizing my > BeagleBone script so it can build system images for > other boards. >=20 > The issue isn't the FreeBSD kernel config but rather > juggling all the different pieces of boot machinery > and the various filesystem constraints. >=20 > Still just noodling the idea around, but I think I've > got a few things to build on. For now, I'm limiting it to > just: > * ARM-based boards > * Building a disk image >=20 > I only have a BeagleBone and a RaspberryPi at > the moment, so Pandaboard support would require > some help. At a minimum, I'd be interested in > an outline of what a Pandaboard image looks > like in terms of boot files, partitions, etc. I think partition-wise it's pretty much the same - FAT partition=20 with boot loader and the rest is available for OS.=20 Boot partition should contain second-stage loader in file named MLO and the rest is up to this binary. I use MLO + u-boot combination. Here is article on boot process: http://elinux.org/Panda_How_to_MLO_%26_u-boot From owner-freebsd-arm@FreeBSD.ORG Wed Sep 5 13:54:58 2012 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 E6FCA106564A; Wed, 5 Sep 2012 13:54:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id BB55A8FC14; Wed, 5 Sep 2012 13:54:58 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0F126B98E; Wed, 5 Sep 2012 09:54:58 -0400 (EDT) From: John Baldwin To: Warner Losh Date: Wed, 5 Sep 2012 08:17:48 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <201209041205.19794.jhb@freebsd.org> <13628135-18C7-4D98-B2DC-60C8AB65A643@bsdimp.com> In-Reply-To: <13628135-18C7-4D98-B2DC-60C8AB65A643@bsdimp.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201209050817.48698.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 05 Sep 2012 09:54:58 -0400 (EDT) Cc: freebsd-hackers@freebsd.org, freebsd-arm@freebsd.org, Aleksander Dutkowski Subject: Re: availability of interrupts during bootup process 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, 05 Sep 2012 13:54:59 -0000 On Tuesday, September 04, 2012 9:30:08 pm Warner Losh wrote: > > On Sep 4, 2012, at 10:05 AM, John Baldwin wrote: > > > On Sunday, September 02, 2012 5:31:21 pm Aleksander Dutkowski wrote: > >> hello! > >> > >> I have PMIC (TWL4030) module connected to the SoC (ARM/OMAP3) via i2c > > (iicbus). > >> Current solution is that i2c_attach calls bus_generic_attach(dev); > >> which calls my pmic probe/attach functions, but main configuration of > >> PMIC in done after drivers setup by config_intrhook. > >> But I need it to be configured during device attaching, because usb > >> ehci driver depends on it. > >> Is it possbile? I've tried it but it hangs on waiting for i2c > >> interrupt, but someone told me, that interrupts are available during > >> bootup for some time. > > > > No, interrupts do not work during bootup. If you can poll your hardware > > you could use polling until interrupts are enabled (using 'if (cold)' to > > check for the boot time before interrupts are enabled). > > Are interrupts off, or ithreads not scheduled? I thought I had some stuff > working that needed interrupts, but didn't need scheduling.. Am I nuts? No, that's correct. Filters will work, just not scheduling. -- John Baldwin From owner-freebsd-arm@FreeBSD.ORG Wed Sep 5 14:36:10 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2E821106566B for ; Wed, 5 Sep 2012 14:36:10 +0000 (UTC) (envelope-from giovanni.trematerra@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id DF6258FC14 for ; Wed, 5 Sep 2012 14:36:09 +0000 (UTC) Received: by qcsg15 with SMTP id g15so139427qcs.13 for ; Wed, 05 Sep 2012 07:36:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=2EkXyaQFPxWVMrP92h1hhOEnWS0KVYD024ahPtvbTCs=; b=yaTXTd+XOXSApdr3WNdu399rUn/PMjNKnuvZ9wdoy2Y8BwlZgPpFDJkcUWqRsomTLI 24pldNJJTJYgh2iF4zA2N5dradsqAUtflyF8U77amWxbg2kt1OBAi3Xsm8Z3YRhveLH+ wQS1Mbxy10KkwZcwRYAUySK74WSHlirTexv0CC9zhl8QSLbbTK3nuLB/iWlxKxi1fjpo qZkYu9dMe0ve8r8x7MHxzrvv97vaCxVcvtjsi88ny/+yaJb0xfmP+c/1ZSFT3WGo8Cl5 5j3Prw0ao6oPc3zvxKmwyKCx1piSg5tpcbczVa2VBC3WCrJnHnBD/Qi1vHfdplU1z2CI b19Q== MIME-Version: 1.0 Received: by 10.224.28.14 with SMTP id k14mr45927207qac.72.1346855768989; Wed, 05 Sep 2012 07:36:08 -0700 (PDT) Received: by 10.229.128.202 with HTTP; Wed, 5 Sep 2012 07:36:08 -0700 (PDT) Date: Wed, 5 Sep 2012 16:36:08 +0200 Message-ID: From: Giovanni Trematerra To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: FreeBSD on Pandora/Pandora ES boards 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, 05 Sep 2012 14:36:10 -0000 Hi all, I wonder what is the state of support for Pandora and Pandora ES development boards in FreeBSD-Current at the moment. Is FreeBSD capable to boot on such boards? Thank you. -- Gianni From owner-freebsd-arm@FreeBSD.ORG Wed Sep 5 15:10:35 2012 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 61E751065758; Wed, 5 Sep 2012 15:10:35 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id CBC8D8FC08; Wed, 5 Sep 2012 15:10:22 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id q85FAMIF078927; Wed, 5 Sep 2012 09:10:22 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) 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 q85F9xhj042697; Wed, 5 Sep 2012 09:09:59 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Warner Losh In-Reply-To: <3AFC763F-011C-46B4-B500-FE21B704259F@bsdimp.com> References: <1346689154.1140.601.camel@revolution.hippie.lan> <3AFC763F-011C-46B4-B500-FE21B704259F@bsdimp.com> Content-Type: text/plain; charset="us-ascii" Date: Wed, 05 Sep 2012 09:09:59 -0600 Message-ID: <1346857799.59094.66.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Some busdma stats 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, 05 Sep 2012 15:10:35 -0000 On Wed, 2012-09-05 at 08:30 -0600, Warner Losh wrote: > > Regardless of whether we eventually fix every driver to eliminate > > transfers that aren't aligned to cache line boundaries, or somehow > > change the busdma code to automatically bounce unaligned requests, > we > > need efficient allocation of small buffers aligned and sized to > cache > > lines. > > The issue can't be fixed in the busdma code because partial, unaligned > transfers are fine, so long as the calling code avoids the entire > cache line during the transfer. Returning cache-line aligned buffers > from the allocator will do that, of course, but it is also valid for > the code to only use part of the buffer for the transfer. Right. My goal with the dma buffer pool changes isn't some sort of magical automatic fix in the busdma layer, it's just a whittling away of one small roadblock on the path to fixing this stuff. When I first started asking about how we should address these problems, the experts said to keep platform-specific alignment and padding information encapsulated within the busdma layer rather than inventing a new mechanism to export that info to drivers. That implies that drivers should be allocating DMA buffers from busdma instead of allocating big chunks of memory and sub-dividing them into smaller buffers. For that to work, the busdma implementation needs to be able to efficiently allocate buffers that are properly aligned and padded and especially that are guaranteed not to share a cache line with some other unrelated data. The busdma implementation can't get those guarantees from malloc(9), and the alternatives (contigmalloc(), and the kmem_alloc family) only work in page-sized chunks. We're asking drivers to allocate individual buffers of sometimes no more than a few bytes each. So that's all I'm addressing in the patchset I submitted: make sure that when we start fixing drivers to allocate 256 individual 16-byte IO descriptors that it shares with the hardware, that doesn't result in allocating 256 pages of memory. Also, if the request is for BUS_DMA_COHERENT memory, make sure that doesn't result in turning off caching in up to 256 pages that each contain a 16 byte IO buffer and 4080 bytes of unrelated data. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Sep 5 15:22:06 2012 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 2899D1065675 for ; Wed, 5 Sep 2012 15:22:06 +0000 (UTC) (envelope-from gonzo@hq.bluezbox.com) Received: from hq.bluezbox.com (hq.bluezbox.com [70.38.37.145]) by mx1.freebsd.org (Postfix) with ESMTP id DE0728FC15 for ; Wed, 5 Sep 2012 15:22:05 +0000 (UTC) Received: from [127.0.0.1] (helo=[IPv6:::1]) by hq.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1T9HQ8-0006tr-NB; Wed, 05 Sep 2012 08:21:42 -0700 Message-ID: <50476E13.5080208@bluezbox.com> Date: Wed, 05 Sep 2012 08:21:55 -0700 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Giovanni Trematerra References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@hq.bluezbox.com X-Spam-Level: ---- X-Spam-Report: Spam detection software, running on the system "hq.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 9/5/2012 7:36 AM, Giovanni Trematerra wrote: > Hi all, > I wonder what is the state of support for Pandora and Pandora ES > development boards in FreeBSD-Current at the moment. > Is FreeBSD capable to boot on such boards? [...] Content analysis details: (-4.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Cc: freebsd-arm@freebsd.org Subject: Re: FreeBSD on Pandora/Pandora ES boards 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, 05 Sep 2012 15:22:06 -0000 On 9/5/2012 7:36 AM, Giovanni Trematerra wrote: > Hi all, > I wonder what is the state of support for Pandora and Pandora ES > development boards in FreeBSD-Current at the moment. > Is FreeBSD capable to boot on such boards? Pandaboard ES works in multiuser mode. No graphics though. From owner-freebsd-arm@FreeBSD.ORG Wed Sep 5 15:28:57 2012 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 9C5B71065675; Wed, 5 Sep 2012 15:28:57 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 68DDE8FC21; Wed, 5 Sep 2012 15:28:57 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id q85FSu67079141; Wed, 5 Sep 2012 09:28:56 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) 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 q85FSXog042721; Wed, 5 Sep 2012 09:28:33 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Adrian Chadd In-Reply-To: References: <1346777897.1140.633.camel@revolution.hippie.lan> <1346803062.59094.27.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Wed, 05 Sep 2012 09:28:33 -0600 Message-ID: <1346858913.59094.76.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org Subject: Re: busdma buffer management enhancements - call for review and test 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, 05 Sep 2012 15:28:57 -0000 On Tue, 2012-09-04 at 20:06 -0700, Adrian Chadd wrote: > I just want to make sure that you don't assume individual memory > access costs are the same regardless of how big the allocations are. > > Ie, if you have a bunch of scattered L1-sized allocations, versus them > all being nearby in the same 512/1024 byte page; the underlying memory > architecture may be doing memory transactions at a slightly larger > size than your L1 assumption. > > Damn these hierarchicial memory systems. I think nothing about my code significantly changes the current situation in this regard. Right now bus_dmamem_alloc() gets small chunks of memory from malloc(9), which means they come from a set of power-of-two-sized uma zones. With my changes the memory comes from a similar set of 2^N sized uma zones, but they're segregated from the zones used by malloc(9) so that memory in a single cache line never contains data for both DMA and non-DMA (or two unrelated DMA) users at once. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Sep 5 18:13:17 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8DEFD1065676 for ; Wed, 5 Sep 2012 18:13:17 +0000 (UTC) (envelope-from hans.stimer@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 56D498FC1A for ; Wed, 5 Sep 2012 18:13:17 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so1435096pbb.13 for ; Wed, 05 Sep 2012 11:13:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type; bh=rGoHekB4DyHtfWiL5J37tkfeFkR9babidBBQGjcvlXM=; b=xnYMULoii77OS3eN0TTbyR0s+//uWTQ9rXLS+OB9Fq/OY1hcqn4j7cHZpsU6oic0Ju c4+cGvYW0TOjAjjxEC6Wel6ccwbJ2SGjsWdpQxxnmXnExdSED7J/ahDWILGn3t+Jt1RC s6nYsCwQY3ZH+SMbTnPjMA4GMKqPLBrX1dOcHJPpiJcy6vaPhDj0zHFg/ycUKZ+xJDSR PM/Wq4a3xv+rNGEz11cppvCKRHTOyJzn1bKNk0VeIbprsRN9NLpHdOgjXKzhYvmwGJn9 oxl4/AYkRJxiACkkHX8wVkiQLGhkoeKZNu1z7ZRkNTrBhUI94pkPSEdahorwot3fE4q2 4O4w== Received: by 10.66.75.168 with SMTP id d8mr50624491paw.63.1346868796992; Wed, 05 Sep 2012 11:13:16 -0700 (PDT) Received: from [10.0.1.134] (70-90-170-37-ca.sfba.hfc.comcastbusiness.net. [70.90.170.37]) by mx.google.com with ESMTPS id vd4sm1902623pbc.41.2012.09.05.11.13.15 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 05 Sep 2012 11:13:16 -0700 (PDT) Date: Wed, 5 Sep 2012 11:13:14 -0700 From: Hans Stimer To: Tim Kientzle Message-ID: In-Reply-To: <7E18623F-3945-4EA0-B332-5A5C717B20F0@kientzle.com> References: <0DCAC001-FF06-431A-A486-2B50BE913B0D@bsdimp.com> <7E18623F-3945-4EA0-B332-5A5C717B20F0@kientzle.com> X-Mailer: sparrow 1.6.3 (build 1172) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: arm@freebsd.org Subject: Re: freebsd-beaglebone install problem 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, 05 Sep 2012 18:13:17 -0000 Tried the latest in github, but uboot isn't building. I'll have some time= later today to try and figure what is going on. =23 git clone git://arago-project.org/git/projects/u-boot-am33x.git /usr/= home/hans/extern/freebsd-beaglebone/u-boot =23 /bin/sh beaglebsd.sh Starting at Wed Sep 5 11:05:10 PDT 2012 Loading configuration values =46ound =46reeBSD xdev tools for ARM =46ound suitable U-Boot sources in /usr/home/hans/extern/freebsd-beaglebo= ne/u-boot =46ound suitable =46reeBSD source tree in /usr/armsrc Patching U-Boot. (Logging to /usr/home/hans/extern/freebsd-beaglebone/wor= k/=5F.uboot.patch.log) Applying patch /usr/home/hans/extern/freebsd-beaglebone/config/arm/BEA= GLEBONE/files/uboot=5Fpatch1=5Fadd=5Flibc=5Fto=5Flink=5Fon=5F=46reeBSD.pa= tch Applying patch /usr/home/hans/extern/freebsd-beaglebone/config/arm/BEA= GLEBONE/files/uboot=5Fpatch2=5Fadd=5Foptions=5Fto=5Fam335x=5Fconfig.patch= Applying patch /usr/home/hans/extern/freebsd-beaglebone/config/arm/BEA= GLEBONE/files/uboot=5Fpatch3=5Ffix=5Fapi=5Fdisk=5Fenumeration.patch Applying patch /usr/home/hans/extern/freebsd-beaglebone/config/arm/BEA= GLEBONE/files/uboot=5Fpatch4=5Fshrink=5Fspl.patch Applying patch /usr/home/hans/extern/freebsd-beaglebone/config/arm/BEA= GLEBONE/files/uboot=5Fpatch5=5Fset=5Fzero=5Fbootdelay.patch Configuring U-Boot. (Logging to /usr/home/hans/extern/freebsd-beaglebone/= work/=5F.uboot.configure.log) Building U-Boot. (Logging to /usr/home/hans/extern/freebsd-beaglebone/wor= k/=5F.uboot.build.log) =46ailed to build U-Boot. Log in /usr/home/hans/extern/freebsd-beaglebone/work/=5F.uboot.build.lo= g =23 =20 =23 cat work/=5F.uboot.build.log =20 Generating include/autoconf.mk include/common.h:43:20: error: stdarg.h: No such file or directory In file included from include/image.h:36, from include/common.h:117: include/compiler.h:8:20: error: stddef.h: No such file or directory Generating include/autoconf.mk.dep include/common.h:43:20: error: stdarg.h: No such file or directory In file included from include/image.h:36, from include/common.h:117: include/compiler.h:8:20: error: stddef.h: No such file or directory arm-freebsd-gcc -DDO=5FDEPS=5FONLY =5C -g -Os -fno-common -ffixed-r8 -msoft-float -D=5F=5FKERNEL=5F=5F -DCO= N=46IG=5FSYS=5FTEXT=5FBASE=3D0x80100000 -DCON=46IG=5FSPL=5FTEXT=5FBASE=3D= 0x402=460400 -I/usr/home/hans/extern/freebsd-beaglebone/u-boot/include -f= no-builtin -ffreestanding -nostdinc -isystem include -pipe -DCON=46IG=5F= ARM -D=5F=5FARM=5F=5F -marm -mabi=3Daapcs-linux -mno-thumb-interwork -ma= rch=3Darmv5 -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-no= nliteral -Wno-format-security =5C -o lib/asm-offsets.s lib/asm-offsets.c -c -S In file included from lib/asm-offsets.c:18: include/common.h:43:20: error: stdarg.h: No such file or directory In file included from include/image.h:36, from include/common.h:117, from lib/asm-offsets.c:18: include/compiler.h:8:20: error: stddef.h: No such file or directory In file included from lib/asm-offsets.c:18: include/common.h:687: error: expected declaration specifiers or '...' bef= ore 'va=5Flist' In file included from lib/asm-offsets.c:18: include/common.h:719: error: expected declaration specifiers or '...' bef= ore 'va=5Flist' gmake: *** =5Blib/asm-offsets.s=5D Error 1 =23 =20 On Tuesday, September 4, 2012 at 9:28 PM, Tim Kientzle wrote: > =20 > On Sep 4, 2012, at 9:22 PM, Tim Kientzle wrote: > =20 > > =20 > > On Sep 4, 2012, at 6:07 PM, Warner Losh wrote: > > =20 > > > =20 > > > On Sep 4, 2012, at 4:17 PM, Hans Stimer wrote: > > > =20 > > > > I'm running into problems getting =46reeBSD working on the Beagle= Bone. > > =20 > > > > =20 > > > > > =23 cu -l /dev/ttyU1 -s 115200 > > > > > Connected > > > > > CCCCCCCC > > > > > =20 > > > > =20 > > > > =20 > > > =20 > > =20 > > =20 > > The ROM code for the AM3358 SoC in the BeagleBone falls > > back to YModem if it can't load the first-stage MLO boot loader > > from SDHC. > > =20 > > If you see this, then either the =46AT partition is > > ill-formed or the MLO file is missing. > > =20 > > > > I checked the logs, and this one stood out: > > > > =20 > > > > > =23 less =5F.uboot.build.log =20 > > > > > Generating include/autoconf.mk > > > > > include/common.h:43:20: error: stdarg.h: No such file or direct= ory > > > > > In file included from include/image.h:36, > > > > > from include/common.h:117: > > > > > =20 > > > > =20 > > > > =20 > > > =20 > > =20 > > =20 > > Yeah, looks like U-Boot didn't build. > > =20 > > I haven't updated my local U-Boot sources in a while, > > I'll go do that and get right back to you=E2=80=A6 > > =20 > =20 > =20 > Please update the freebsd-beaglebone scripts and > try again. I found and fixed a couple of problems: > =20 > * I had reversed the logic to decide if patches were already > applied, so U-Boot wasn't getting patched. > * One of my patches needed to be updated to work with > the newest U-Boot sources. > * I added some logic so that the beaglebsd.sh (http://beaglebsd.sh) scr= ipt will > actually fail with an error message if the U-Boot patch, > configure, or build steps fail. This should make problems > like this more obvious. > =20 > Let me know if you run into any other issues. > =20 > Cheers, > =20 > Tim =20 From owner-freebsd-arm@FreeBSD.ORG Wed Sep 5 20:29:27 2012 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 7962D106564A for ; Wed, 5 Sep 2012 20:29:27 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3339A8FC15 for ; Wed, 5 Sep 2012 20:29:26 +0000 (UTC) Received: by obbun3 with SMTP id un3so1350568obb.13 for ; Wed, 05 Sep 2012 13:29:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=S6/w0kYEKpk/0wMA8OxMjlByJt4GmKxrhrkBZ8jMWnk=; b=05k0yeo8kvxirTsEyD3c1luDWem6HRx9RYhrpdEL7mU/Kje4qS/LBsi4B5aUiqyF6T NC5hDUEjDdKbn9xOCzYDFwDV0XmYoULI0qmjTo75QXVu/zWrOc0elh2/Zn8n24Pv9FO3 FOPTOQoP1VbmhUxYms+DW9iUBN03RtYvUp8ZyZ258ZJFe0B5LZNfgp/Fwd3XeBCo8/BI +gv4exDskEcEddcaduuQ/xSleifq1NPlMNTO3+joOrdhKLDcCfsInNUodHGQURRAhymW KYEVhHwPuvDCFZOQs8hyT23aumoQ2A2QOJ1HprKnI2VOOm1yG5e8hK0J3R+VdjtxDex0 Qysw== MIME-Version: 1.0 Received: by 10.60.13.130 with SMTP id h2mr2708879oec.63.1346876966178; Wed, 05 Sep 2012 13:29:26 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.76.8.98 with HTTP; Wed, 5 Sep 2012 13:29:26 -0700 (PDT) In-Reply-To: References: <0DCAC001-FF06-431A-A486-2B50BE913B0D@bsdimp.com> <7E18623F-3945-4EA0-B332-5A5C717B20F0@kientzle.com> Date: Wed, 5 Sep 2012 13:29:26 -0700 X-Google-Sender-Auth: dibutE-HH_yxHASEAny1yYCK5Jw Message-ID: From: Adrian Chadd To: Hans Stimer Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: arm@freebsd.org, Tim Kientzle Subject: Re: freebsd-beaglebone install problem 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, 05 Sep 2012 20:29:27 -0000 .. is there any reason we don't have uboot in the tree (under vendor/contrib) and cross-build things that way? Adrian On 5 September 2012 11:13, Hans Stimer wrote: > Tried the latest in github, but uboot isn't building. I'll have some time= later today to try and figure what is going on. > > # git clone git://arago-project.org/git/projects/u-boot-am33x.git /usr/ho= me/hans/extern/freebsd-beaglebone/u-boot > > # /bin/sh beaglebsd.sh > Starting at Wed Sep 5 11:05:10 PDT 2012 > Loading configuration values > Found FreeBSD xdev tools for ARM > Found suitable U-Boot sources in /usr/home/hans/extern/freebsd-beaglebone= /u-boot > Found suitable FreeBSD source tree in /usr/armsrc > Patching U-Boot. (Logging to /usr/home/hans/extern/freebsd-beaglebone/wor= k/_.uboot.patch.log) > Applying patch /usr/home/hans/extern/freebsd-beaglebone/config/arm/BEA= GLEBONE/files/uboot_patch1_add_libc_to_link_on_FreeBSD.patch > Applying patch /usr/home/hans/extern/freebsd-beaglebone/config/arm/BEA= GLEBONE/files/uboot_patch2_add_options_to_am335x_config.patch > Applying patch /usr/home/hans/extern/freebsd-beaglebone/config/arm/BEA= GLEBONE/files/uboot_patch3_fix_api_disk_enumeration.patch > Applying patch /usr/home/hans/extern/freebsd-beaglebone/config/arm/BEA= GLEBONE/files/uboot_patch4_shrink_spl.patch > Applying patch /usr/home/hans/extern/freebsd-beaglebone/config/arm/BEA= GLEBONE/files/uboot_patch5_set_zero_bootdelay.patch > Configuring U-Boot. (Logging to /usr/home/hans/extern/freebsd-beaglebone/= work/_.uboot.configure.log) > Building U-Boot. (Logging to /usr/home/hans/extern/freebsd-beaglebone/wor= k/_.uboot.build.log) > Failed to build U-Boot. > Log in /usr/home/hans/extern/freebsd-beaglebone/work/_.uboot.build.log > # > > > # cat work/_.uboot.build.log > Generating include/autoconf.mk > include/common.h:43:20: error: stdarg.h: No such file or directory > In file included from include/image.h:36, > from include/common.h:117: > include/compiler.h:8:20: error: stddef.h: No such file or directory > Generating include/autoconf.mk.dep > include/common.h:43:20: error: stdarg.h: No such file or directory > In file included from include/image.h:36, > from include/common.h:117: > include/compiler.h:8:20: error: stddef.h: No such file or directory > arm-freebsd-gcc -DDO_DEPS_ONLY \ > -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -DCONFIG_SYS= _TEXT_BASE=3D0x80100000 -DCONFIG_SPL_TEXT_BASE=3D0x402F0400 -I/usr/home/han= s/extern/freebsd-beaglebone/u-boot/include -fno-builtin -ffreestanding -nos= tdinc -isystem include -pipe -DCONFIG_ARM -D__ARM__ -marm -mabi=3Daapcs-l= inux -mno-thumb-interwork -march=3Darmv5 -Wall -Wstrict-prototypes -fno-sta= ck-protector -Wno-format-nonliteral -Wno-format-security \ > -o lib/asm-offsets.s lib/asm-offsets.c -c -S > In file included from lib/asm-offsets.c:18: > include/common.h:43:20: error: stdarg.h: No such file or directory > In file included from include/image.h:36, > from include/common.h:117, > from lib/asm-offsets.c:18: > include/compiler.h:8:20: error: stddef.h: No such file or directory > In file included from lib/asm-offsets.c:18: > include/common.h:687: error: expected declaration specifiers or '...' bef= ore 'va_list' > In file included from lib/asm-offsets.c:18: > include/common.h:719: error: expected declaration specifiers or '...' bef= ore 'va_list' > gmake: *** [lib/asm-offsets.s] Error 1 > # > > > On Tuesday, September 4, 2012 at 9:28 PM, Tim Kientzle wrote: > >> >> On Sep 4, 2012, at 9:22 PM, Tim Kientzle wrote: >> >> > >> > On Sep 4, 2012, at 6:07 PM, Warner Losh wrote: >> > >> > > >> > > On Sep 4, 2012, at 4:17 PM, Hans Stimer wrote: >> > > >> > > > I'm running into problems getting FreeBSD working on the BeagleBon= e. >> > >> > > > >> > > > > # cu -l /dev/ttyU1 -s 115200 >> > > > > Connected >> > > > > CCCCCCCC >> > > > > >> > > > >> > > > >> > > >> > >> > >> > The ROM code for the AM3358 SoC in the BeagleBone falls >> > back to YModem if it can't load the first-stage MLO boot loader >> > from SDHC. >> > >> > If you see this, then either the FAT partition is >> > ill-formed or the MLO file is missing. >> > >> > > > I checked the logs, and this one stood out: >> > > > >> > > > > # less _.uboot.build.log >> > > > > Generating include/autoconf.mk >> > > > > include/common.h:43:20: error: stdarg.h: No such file or directo= ry >> > > > > In file included from include/image.h:36, >> > > > > from include/common.h:117: >> > > > > >> > > > >> > > > >> > > >> > >> > >> > Yeah, looks like U-Boot didn't build. >> > >> > I haven't updated my local U-Boot sources in a while, >> > I'll go do that and get right back to you=85 >> > >> >> >> Please update the freebsd-beaglebone scripts and >> try again. I found and fixed a couple of problems: >> >> * I had reversed the logic to decide if patches were already >> applied, so U-Boot wasn't getting patched. >> * One of my patches needed to be updated to work with >> the newest U-Boot sources. >> * I added some logic so that the beaglebsd.sh (http://beaglebsd.sh) scri= pt will >> actually fail with an error message if the U-Boot patch, >> configure, or build steps fail. This should make problems >> like this more obvious. >> >> Let me know if you run into any other issues. >> >> Cheers, >> >> Tim > > _______________________________________________ > 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 Wed Sep 5 21:23:24 2012 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 40638106566C for ; Wed, 5 Sep 2012 21:23:24 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id B9B1D8FC08 for ; Wed, 5 Sep 2012 21:23:23 +0000 (UTC) Received: by weyx56 with SMTP id x56so856166wey.13 for ; Wed, 05 Sep 2012 14:23:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=6Y+jBH4LY11CqLoLg9oLR6K/lG/WaVPG4ytEdzt3xQU=; b=LTmsm3e6x0uzQ8X65looAJS0uU5odTsXw+UJyK/SMqhEYF+zKijsto1ZrgE0mjMiGo zIV7404HCxd+iN5vbV79IFW4syHX1ZkqoYLOzbGEdlB1caa8Upops1Gn8GjQuz8H31Zd 4ZqMCXBROHaQ4cXT5WMcrG+xM8LiGTXjNUigvXxNgkR3oJl8Kr8lXh60uw5+v4zsahu4 Q4++bMCROz1h46QT19ROtqywUEudP4xcY7+SkUebGr78z99mwbD/koLaoggM8kTEUWLs JZKurJMcVJuUdrg3bFXWynEkZo7A+mtcHLpmp063shFcjJqYMifLA0DSswY6MxsVUupr HkTw== Received: by 10.216.197.162 with SMTP id t34mr15331760wen.5.1346880202407; Wed, 05 Sep 2012 14:23:22 -0700 (PDT) Received: from rnote.ddteam.net (162-74-133-95.pool.ukrtel.net. [95.133.74.162]) by mx.google.com with ESMTPS id w7sm645839wiz.0.2012.09.05.14.23.19 (version=SSLv3 cipher=OTHER); Wed, 05 Sep 2012 14:23:20 -0700 (PDT) Date: Thu, 6 Sep 2012 00:23:14 +0300 From: Aleksandr Rybalko To: Hans Stimer Message-Id: <20120906002314.98ffdc38.ray@ddteam.net> In-Reply-To: References: <0DCAC001-FF06-431A-A486-2B50BE913B0D@bsdimp.com> <7E18623F-3945-4EA0-B332-5A5C717B20F0@kientzle.com> X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQn1nDpnyYabp/a3ZtRPYUlzd1vofdm91USvAiZ3C4LUYSOMJxqLUoiEg7a/CfjLbARCMmXV Cc: arm@freebsd.org, Tim Kientzle Subject: Re: freebsd-beaglebone install problem 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, 05 Sep 2012 21:23:24 -0000 On Wed, 5 Sep 2012 11:13:14 -0700 Hans Stimer wrote: > Tried the latest in github, but uboot isn't building. I'll have some > time later today to try and figure what is going on. > > # git clone > # git://arago-project.org/git/projects/u-boot-am33x.git /usr/home/hans/extern/freebsd-beaglebone/u-boot > > # /bin/sh beaglebsd.sh > Starting at Wed Sep 5 11:05:10 PDT 2012 > Loading configuration values > Found FreeBSD xdev tools for ARM > Found suitable U-Boot sources > in /usr/home/hans/extern/freebsd-beaglebone/u-boot Found suitable > FreeBSD source tree in /usr/armsrc Patching U-Boot. (Logging > to /usr/home/hans/extern/freebsd-beaglebone/work/_.uboot.patch.log) > Applying > patch /usr/home/hans/extern/freebsd-beaglebone/config/arm/BEAGLEBONE/files/uboot_patch1_add_libc_to_link_on_FreeBSD.patch > Applying > patch /usr/home/hans/extern/freebsd-beaglebone/config/arm/BEAGLEBONE/files/uboot_patch2_add_options_to_am335x_config.patch > Applying > patch /usr/home/hans/extern/freebsd-beaglebone/config/arm/BEAGLEBONE/files/uboot_patch3_fix_api_disk_enumeration.patch > Applying > patch /usr/home/hans/extern/freebsd-beaglebone/config/arm/BEAGLEBONE/files/uboot_patch4_shrink_spl.patch > Applying > patch /usr/home/hans/extern/freebsd-beaglebone/config/arm/BEAGLEBONE/files/uboot_patch5_set_zero_bootdelay.patch > Configuring U-Boot. (Logging > to /usr/home/hans/extern/freebsd-beaglebone/work/_.uboot.configure.log) > Building U-Boot. (Logging > to /usr/home/hans/extern/freebsd-beaglebone/work/_.uboot.build.log) > Failed to build U-Boot. Log > in /usr/home/hans/extern/freebsd-beaglebone/work/_.uboot.build.log > # > > > # cat work/_.uboot.build.log > Generating include/autoconf.mk > include/common.h:43:20: error: stdarg.h: No such file or directory > In file included from include/image.h:36, > from include/common.h:117: > include/compiler.h:8:20: error: stddef.h: No such file or directory > Generating include/autoconf.mk.dep > include/common.h:43:20: error: stdarg.h: No such file or directory > In file included from include/image.h:36, > from include/common.h:117: > include/compiler.h:8:20: error: stddef.h: No such file or directory > arm-freebsd-gcc -DDO_DEPS_ONLY \ > -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ > -DCONFIG_SYS_TEXT_BASE=0x80100000 -DCONFIG_SPL_TEXT_BASE=0x402F0400 > -I/usr/home/hans/extern/freebsd-beaglebone/u-boot/include > -fno-builtin -ffreestanding -nostdinc -isystem include -pipe > -DCONFIG_ARM -D__ARM__ -marm -mabi=aapcs-linux -mno-thumb-interwork > -march=armv5 -Wall -Wstrict-prototypes -fno-stack-protector > -Wno-format-nonliteral -Wno-format-security \ -o lib/asm-offsets.s > lib/asm-offsets.c -c -S In file included from lib/asm-offsets.c:18: > include/common.h:43:20: error: stdarg.h: No such file or directory In > file included from include/image.h:36, from include/common.h:117, > from lib/asm-offsets.c:18: include/compiler.h:8:20: error: stddef.h: > No such file or directory In file included from lib/asm-offsets.c:18: > include/common.h:687: error: expected declaration specifiers or '...' > before 'va_list' In file included from lib/asm-offsets.c:18: > include/common.h:719: error: expected declaration specifiers or '...' > before 'va_list' gmake: *** [lib/asm-offsets.s] Error 1 > # > > > On Tuesday, September 4, 2012 at 9:28 PM, Tim Kientzle wrote: > > > > > On Sep 4, 2012, at 9:22 PM, Tim Kientzle wrote: > > > > > > > > On Sep 4, 2012, at 6:07 PM, Warner Losh wrote: > > > > > > > > > > > On Sep 4, 2012, at 4:17 PM, Hans Stimer wrote: > > > > > > > > > I'm running into problems getting FreeBSD working on the > > > > > BeagleBone. > > > > > > > > > > > > > > # cu -l /dev/ttyU1 -s 115200 > > > > > > Connected > > > > > > CCCCCCCC > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The ROM code for the AM3358 SoC in the BeagleBone falls > > > back to YModem if it can't load the first-stage MLO boot loader > > > from SDHC. > > > > > > If you see this, then either the FAT partition is > > > ill-formed or the MLO file is missing. > > > > > > > > I checked the logs, and this one stood out: > > > > > > > > > > > # less _.uboot.build.log > > > > > > Generating include/autoconf.mk > > > > > > include/common.h:43:20: error: stdarg.h: No such file or > > > > > > directory In file included from include/image.h:36, > > > > > > from include/common.h:117: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yeah, looks like U-Boot didn't build. > > > > > > I haven't updated my local U-Boot sources in a while, > > > I'll go do that and get right back to you… > > > > > > > > > Please update the freebsd-beaglebone scripts and > > try again. I found and fixed a couple of problems: > > > > * I had reversed the logic to decide if patches were already > > applied, so U-Boot wasn't getting patched. > > * One of my patches needed to be updated to work with > > the newest U-Boot sources. > > * I added some logic so that the beaglebsd.sh (http://beaglebsd.sh) > > script will actually fail with an error message if the U-Boot patch, > > configure, or build steps fail. This should make problems > > like this more obvious. > > > > Let me know if you run into any other issues. > > > > Cheers, > > > > Tim > > _______________________________________________ > 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" Hi, You can try to use your FreeBSD toolchain for that, it works for me: CROSS=/usr/obj/arm.armv6/usr/src/tmp/usr/bin/ gmake ARCH=arm CROSS_COMPILE=${CROSS} distclean gmake ARCH=arm CROSS_COMPILE=${CROSS} YOUR_BOARD_config gmake ARCH=arm CROSS_COMPILE=${CROSS} Replace /usr/obj/arm.armv6/usr/src/tmp/usr/bin with your path to toolchain made by FreeBSD build system for your board. Ohhh, forget about small patch to make some math symbols also from uboot sources. -------------------------------------------------------- diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile index 39a9550..ec05e33 100644 --- a/arch/arm/lib/Makefile +++ b/arch/arm/lib/Makefile @@ -49,6 +49,15 @@ endif COBJS-y += cache.o COBJS-y += cache-cp15.o +COBJS-y += div0.o +COBJS-y += _ashldi3.o +COBJS-y += _ashrdi3.o +COBJS-y += _divsi3.o +COBJS-y += _lshrdi3.o +COBJS-y += _modsi3.o +COBJS-y += _udivsi3.o +COBJS-y += _umodsi3.o + SRCS := $(GLSOBJS:.o=.S) $(GLCOBJS:.o=.c) \ $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c) OBJS := $(addprefix $(obj),$(SOBJS-y) $(COBJS-y)) -------------------------------------------------------- Hope that helps. WBW -- Aleksandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Wed Sep 5 21:37:38 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 060E21065673 for ; Wed, 5 Sep 2012 21:37:38 +0000 (UTC) (envelope-from imp@bsdimp.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 B33068FC14 for ; Wed, 5 Sep 2012 21:37:37 +0000 (UTC) Received: by iayy25 with SMTP id y25so1677017iay.13 for ; Wed, 05 Sep 2012 14:37:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=ayvfFM19c2eHLM3zvqUUS8veAt2RhakYTg/4PsfblNI=; b=U55tf4GuP9XSps550EqnMAqWyLAzPeJuK6FglBpRx+bAhzWbOBS/LOlugesJPfAf8o 46XtvKUL/lbZqe/X2VrPzmYQiSW+v27q4+laljx5R0PXP49G88Uawp8hYVNhCvMrR9G3 xGeXBH+wIAjrlyU9NKr5rBrSaFnjPnoaFHLP7MfjPjPWwOxCMZ+ttH8vJn+Bqtp8W34m TFpCvrc79iyd4nBU0AvGceNHrO7yFpFN8K+/KIZvcMjlOwPh8ZC2Byitstp7u2ewD6s8 D3FxDL54vB8vQqhkRiQm3qFEIxBjx5l1qP3HqGKbYv+wxRPwAgR4aPINHo+C2Y7zv1K4 bN1Q== Received: by 10.50.214.1 with SMTP id nw1mr19484395igc.2.1346881057004; Wed, 05 Sep 2012 14:37:37 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id fu4sm471451igc.4.2012.09.05.14.37.35 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 05 Sep 2012 14:37:36 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warner Losh In-Reply-To: Date: Wed, 5 Sep 2012 15:37:34 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <18FFFCEC-36B0-4897-B226-4A2A3A62FD6F@bsdimp.com> References: <0DCAC001-FF06-431A-A486-2B50BE913B0D@bsdimp.com> <7E18623F-3945-4EA0-B332-5A5C717B20F0@kientzle.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQlztoCHMg43urd0mkXLEa02VZOIdnX76Md3JKloG2tsWOzKqH85hX1sGEgcbhmgAhARpgnB Cc: arm@freebsd.org, Tim Kientzle Subject: Re: freebsd-beaglebone install problem 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, 05 Sep 2012 21:37:38 -0000 On Sep 5, 2012, at 2:29 PM, Adrian Chadd wrote: > .. is there any reason we don't have uboot in the tree (under > vendor/contrib) and cross-build things that way? it is too big and fast moving for that. Also, each board or at least = SoC seems to want a different version to be happy. Ports is the answer = here, perhaps. Warner > Adrian >=20 > On 5 September 2012 11:13, Hans Stimer wrote: >> Tried the latest in github, but uboot isn't building. I'll have some = time later today to try and figure what is going on. >>=20 >> # git clone git://arago-project.org/git/projects/u-boot-am33x.git = /usr/home/hans/extern/freebsd-beaglebone/u-boot >>=20 >> # /bin/sh beaglebsd.sh >> Starting at Wed Sep 5 11:05:10 PDT 2012 >> Loading configuration values >> Found FreeBSD xdev tools for ARM >> Found suitable U-Boot sources in = /usr/home/hans/extern/freebsd-beaglebone/u-boot >> Found suitable FreeBSD source tree in /usr/armsrc >> Patching U-Boot. (Logging to = /usr/home/hans/extern/freebsd-beaglebone/work/_.uboot.patch.log) >> Applying patch = /usr/home/hans/extern/freebsd-beaglebone/config/arm/BEAGLEBONE/files/uboot= _patch1_add_libc_to_link_on_FreeBSD.patch >> Applying patch = /usr/home/hans/extern/freebsd-beaglebone/config/arm/BEAGLEBONE/files/uboot= _patch2_add_options_to_am335x_config.patch >> Applying patch = /usr/home/hans/extern/freebsd-beaglebone/config/arm/BEAGLEBONE/files/uboot= _patch3_fix_api_disk_enumeration.patch >> Applying patch = /usr/home/hans/extern/freebsd-beaglebone/config/arm/BEAGLEBONE/files/uboot= _patch4_shrink_spl.patch >> Applying patch = /usr/home/hans/extern/freebsd-beaglebone/config/arm/BEAGLEBONE/files/uboot= _patch5_set_zero_bootdelay.patch >> Configuring U-Boot. (Logging to = /usr/home/hans/extern/freebsd-beaglebone/work/_.uboot.configure.log) >> Building U-Boot. (Logging to = /usr/home/hans/extern/freebsd-beaglebone/work/_.uboot.build.log) >> Failed to build U-Boot. >> Log in = /usr/home/hans/extern/freebsd-beaglebone/work/_.uboot.build.log >> # >>=20 >>=20 >> # cat work/_.uboot.build.log >> Generating include/autoconf.mk >> include/common.h:43:20: error: stdarg.h: No such file or directory >> In file included from include/image.h:36, >> from include/common.h:117: >> include/compiler.h:8:20: error: stddef.h: No such file or directory >> Generating include/autoconf.mk.dep >> include/common.h:43:20: error: stdarg.h: No such file or directory >> In file included from include/image.h:36, >> from include/common.h:117: >> include/compiler.h:8:20: error: stddef.h: No such file or directory >> arm-freebsd-gcc -DDO_DEPS_ONLY \ >> -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ = -DCONFIG_SYS_TEXT_BASE=3D0x80100000 -DCONFIG_SPL_TEXT_BASE=3D0x402F0400 = -I/usr/home/hans/extern/freebsd-beaglebone/u-boot/include -fno-builtin = -ffreestanding -nostdinc -isystem include -pipe -DCONFIG_ARM -D__ARM__ = -marm -mabi=3Daapcs-linux -mno-thumb-interwork -march=3Darmv5 -Wall = -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral = -Wno-format-security \ >> -o lib/asm-offsets.s lib/asm-offsets.c -c -S >> In file included from lib/asm-offsets.c:18: >> include/common.h:43:20: error: stdarg.h: No such file or directory >> In file included from include/image.h:36, >> from include/common.h:117, >> from lib/asm-offsets.c:18: >> include/compiler.h:8:20: error: stddef.h: No such file or directory >> In file included from lib/asm-offsets.c:18: >> include/common.h:687: error: expected declaration specifiers or '...' = before 'va_list' >> In file included from lib/asm-offsets.c:18: >> include/common.h:719: error: expected declaration specifiers or '...' = before 'va_list' >> gmake: *** [lib/asm-offsets.s] Error 1 >> # >>=20 >>=20 >> On Tuesday, September 4, 2012 at 9:28 PM, Tim Kientzle wrote: >>=20 >>>=20 >>> On Sep 4, 2012, at 9:22 PM, Tim Kientzle wrote: >>>=20 >>>>=20 >>>> On Sep 4, 2012, at 6:07 PM, Warner Losh wrote: >>>>=20 >>>>>=20 >>>>> On Sep 4, 2012, at 4:17 PM, Hans Stimer wrote: >>>>>=20 >>>>>> I'm running into problems getting FreeBSD working on the = BeagleBone. >>>>=20 >>>>>>=20 >>>>>>> # cu -l /dev/ttyU1 -s 115200 >>>>>>> Connected >>>>>>> CCCCCCCC >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>> The ROM code for the AM3358 SoC in the BeagleBone falls >>>> back to YModem if it can't load the first-stage MLO boot loader >>>> from SDHC. >>>>=20 >>>> If you see this, then either the FAT partition is >>>> ill-formed or the MLO file is missing. >>>>=20 >>>>>> I checked the logs, and this one stood out: >>>>>>=20 >>>>>>> # less _.uboot.build.log >>>>>>> Generating include/autoconf.mk >>>>>>> include/common.h:43:20: error: stdarg.h: No such file or = directory >>>>>>> In file included from include/image.h:36, >>>>>>> from include/common.h:117: >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>> Yeah, looks like U-Boot didn't build. >>>>=20 >>>> I haven't updated my local U-Boot sources in a while, >>>> I'll go do that and get right back to you=85 >>>>=20 >>>=20 >>>=20 >>> Please update the freebsd-beaglebone scripts and >>> try again. I found and fixed a couple of problems: >>>=20 >>> * I had reversed the logic to decide if patches were already >>> applied, so U-Boot wasn't getting patched. >>> * One of my patches needed to be updated to work with >>> the newest U-Boot sources. >>> * I added some logic so that the beaglebsd.sh (http://beaglebsd.sh) = script will >>> actually fail with an error message if the U-Boot patch, >>> configure, or build steps fail. This should make problems >>> like this more obvious. >>>=20 >>> Let me know if you run into any other issues. >>>=20 >>> Cheers, >>>=20 >>> Tim >>=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" > _______________________________________________ > 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 Thu Sep 6 03:11:57 2012 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 52CC1106566C for ; Thu, 6 Sep 2012 03:11:57 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 2D5448FC0C for ; Thu, 6 Sep 2012 03:11:56 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q863Bq1l043504; Thu, 6 Sep 2012 03:11:52 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id gac6ww73fuzs9jbbkrzxj39tf2; Thu, 06 Sep 2012 03:11:51 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: <20120906002314.98ffdc38.ray@ddteam.net> Date: Wed, 5 Sep 2012 20:11:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0DCAC001-FF06-431A-A486-2B50BE913B0D@bsdimp.com> <7E18623F-3945-4EA0-B332-5A5C717B20F0@kientzle.com> <20120906002314.98ffdc38.ray@ddteam.net> To: Aleksandr Rybalko X-Mailer: Apple Mail (2.1278) Cc: arm@freebsd.org Subject: Re: freebsd-beaglebone install problem 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: Thu, 06 Sep 2012 03:11:57 -0000 On Sep 5, 2012, at 2:23 PM, Aleksandr Rybalko wrote: > On Wed, 5 Sep 2012 11:13:14 -0700 > Hans Stimer wrote: >=20 >> Tried the latest in github, but uboot isn't building. I'll have some >> time later today to try and figure what is going on. >>=20 >> # git clone >> # git://arago-project.org/git/projects/u-boot-am33x.git = /usr/home/hans/extern/freebsd-beaglebone/u-boot >>=20 >> # /bin/sh beaglebsd.sh >> Starting at Wed Sep 5 11:05:10 PDT 2012 >> Loading configuration values >> Found FreeBSD xdev tools for ARM >> Found suitable U-Boot sources >> in /usr/home/hans/extern/freebsd-beaglebone/u-boot Found suitable >> FreeBSD source tree in /usr/armsrc Patching U-Boot. (Logging >> to /usr/home/hans/extern/freebsd-beaglebone/work/_.uboot.patch.log) >> Applying >> patch = /usr/home/hans/extern/freebsd-beaglebone/config/arm/BEAGLEBONE/files/uboot= _patch1_add_libc_to_link_on_FreeBSD.patch >> Applying >> patch = /usr/home/hans/extern/freebsd-beaglebone/config/arm/BEAGLEBONE/files/uboot= _patch2_add_options_to_am335x_config.patch >> Applying >> patch = /usr/home/hans/extern/freebsd-beaglebone/config/arm/BEAGLEBONE/files/uboot= _patch3_fix_api_disk_enumeration.patch >> Applying >> patch = /usr/home/hans/extern/freebsd-beaglebone/config/arm/BEAGLEBONE/files/uboot= _patch4_shrink_spl.patch >> Applying >> patch = /usr/home/hans/extern/freebsd-beaglebone/config/arm/BEAGLEBONE/files/uboot= _patch5_set_zero_bootdelay.patch >> Configuring U-Boot. (Logging >> to = /usr/home/hans/extern/freebsd-beaglebone/work/_.uboot.configure.log) >> Building U-Boot. (Logging >> to /usr/home/hans/extern/freebsd-beaglebone/work/_.uboot.build.log) >> Failed to build U-Boot. Log >> in /usr/home/hans/extern/freebsd-beaglebone/work/_.uboot.build.log >> # =20 >>=20 >>=20 >> # cat work/_.uboot.build.log =20 >> Generating include/autoconf.mk >> include/common.h:43:20: error: stdarg.h: No such file or directory >> In file included from include/image.h:36, >> from include/common.h:117: >> include/compiler.h:8:20: error: stddef.h: No such file or directory >> Generating include/autoconf.mk.dep >> include/common.h:43:20: error: stdarg.h: No such file or directory >> In file included from include/image.h:36, >> from include/common.h:117: >> include/compiler.h:8:20: error: stddef.h: No such file or directory >> arm-freebsd-gcc -DDO_DEPS_ONLY \ >> -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ >> -DCONFIG_SYS_TEXT_BASE=3D0x80100000 -DCONFIG_SPL_TEXT_BASE=3D0x402F0400= >> -I/usr/home/hans/extern/freebsd-beaglebone/u-boot/include >> -fno-builtin -ffreestanding -nostdinc -isystem include -pipe >> -DCONFIG_ARM -D__ARM__ -marm -mabi=3Daapcs-linux = -mno-thumb-interwork >> -march=3Darmv5 -Wall -Wstrict-prototypes -fno-stack-protector >> -Wno-format-nonliteral -Wno-format-security \ -o lib/asm-offsets.s >> lib/asm-offsets.c -c -S In file included from lib/asm-offsets.c:18: >> include/common.h:43:20: error: stdarg.h: No such file or directory In >> file included from include/image.h:36, from include/common.h:117, >> from lib/asm-offsets.c:18: include/compiler.h:8:20: error: stddef.h: >> No such file or directory In file included from lib/asm-offsets.c:18: >> include/common.h:687: error: expected declaration specifiers or '...' >> before 'va_list' In file included from lib/asm-offsets.c:18: >> include/common.h:719: error: expected declaration specifiers or '...' >> before 'va_list' gmake: *** [lib/asm-offsets.s] Error 1 >> # =20 >>=20 >>=20 >> On Tuesday, September 4, 2012 at 9:28 PM, Tim Kientzle wrote: >>=20 >>>=20 >>> On Sep 4, 2012, at 9:22 PM, Tim Kientzle wrote: >>>=20 >>>>=20 >>>> On Sep 4, 2012, at 6:07 PM, Warner Losh wrote: >>>>=20 >>>>>=20 >>>>> On Sep 4, 2012, at 4:17 PM, Hans Stimer wrote: >>>>>=20 >>>>>> I'm running into problems getting FreeBSD working on the >>>>>> BeagleBone. >>>>=20 >>>>>>=20 >>>>>>> # cu -l /dev/ttyU1 -s 115200 >>>>>>> Connected >>>>>>> CCCCCCCC >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>> The ROM code for the AM3358 SoC in the BeagleBone falls >>>> back to YModem if it can't load the first-stage MLO boot loader >>>> from SDHC. >>>>=20 >>>> If you see this, then either the FAT partition is >>>> ill-formed or the MLO file is missing. >>>>=20 >>>>>> I checked the logs, and this one stood out: >>>>>>=20 >>>>>>> # less _.uboot.build.log =20 >>>>>>> Generating include/autoconf.mk >>>>>>> include/common.h:43:20: error: stdarg.h: No such file or >>>>>>> directory In file included from include/image.h:36, >>>>>>> from include/common.h:117: >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>> Yeah, looks like U-Boot didn't build. >>>>=20 >>>> I haven't updated my local U-Boot sources in a while, >>>> I'll go do that and get right back to you=85 >>>>=20 >>>=20 >>>=20 >>> Please update the freebsd-beaglebone scripts and >>> try again. I found and fixed a couple of problems: >>>=20 >>> * I had reversed the logic to decide if patches were already >>> applied, so U-Boot wasn't getting patched. >>> * One of my patches needed to be updated to work with >>> the newest U-Boot sources. >>> * I added some logic so that the beaglebsd.sh (http://beaglebsd.sh) >>> script will actually fail with an error message if the U-Boot patch, >>> configure, or build steps fail. This should make problems >>> like this more obvious. >>>=20 >>> Let me know if you run into any other issues. >>>=20 >>> Cheers, >>>=20 >>> Tim =20 >>=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 > Hi, >=20 > You can try to use your FreeBSD toolchain for that, it works for me: > CROSS=3D/usr/obj/arm.armv6/usr/src/tmp/usr/bin/ > gmake ARCH=3Darm CROSS_COMPILE=3D${CROSS} distclean > gmake ARCH=3Darm CROSS_COMPILE=3D${CROSS} YOUR_BOARD_config > gmake ARCH=3Darm CROSS_COMPILE=3D${CROSS} >=20 > Replace /usr/obj/arm.armv6/usr/src/tmp/usr/bin with your path to > toolchain made by FreeBSD build system for your board. Better yet, use the FreeBSD xdev toolchain. > Ohhh, forget about small patch to make some math symbols also from = uboot > sources. > -------------------------------------------------------- > diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile > index 39a9550..ec05e33 100644 > --- a/arch/arm/lib/Makefile > +++ b/arch/arm/lib/Makefile > @@ -49,6 +49,15 @@ endif > COBJS-y +=3D cache.o > COBJS-y +=3D cache-cp15.o >=20 > +COBJS-y +=3D div0.o > +COBJS-y +=3D _ashldi3.o > +COBJS-y +=3D _ashrdi3.o > +COBJS-y +=3D _divsi3.o > +COBJS-y +=3D _lshrdi3.o > +COBJS-y +=3D _modsi3.o > +COBJS-y +=3D _udivsi3.o > +COBJS-y +=3D _umodsi3.o > + > SRCS :=3D $(GLSOBJS:.o=3D.S) $(GLCOBJS:.o=3D.c) \ > $(SOBJS-y:.o=3D.S) $(COBJS-y:.o=3D.c) > OBJS :=3D $(addprefix $(obj),$(SOBJS-y) $(COBJS-y)) > -------------------------------------------------------- Somewhere FreeBSD screwed up and on ARM these functions all ended up in libc instead of in libcompiler_rt. It's a one-line patch to the U-Boot makefile to link against libc, but it would probably be better long-term to move these into the right place. Tim From owner-freebsd-arm@FreeBSD.ORG Thu Sep 6 05:14:19 2012 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 CA6641065670 for ; Thu, 6 Sep 2012 05:14:19 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 9519E8FC08 for ; Thu, 6 Sep 2012 05:14:18 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q865ECVn043918; Thu, 6 Sep 2012 05:14:12 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 2mih6r9i6366w2jxk74gbw78ns; Thu, 06 Sep 2012 05:14:12 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: Date: Wed, 5 Sep 2012 22:14:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <66A3DBA3-CF84-4ACF-BF5D-1C37D7720676@kientzle.com> References: <0DCAC001-FF06-431A-A486-2B50BE913B0D@bsdimp.com> <7E18623F-3945-4EA0-B332-5A5C717B20F0@kientzle.com> To: Hans Stimer X-Mailer: Apple Mail (2.1278) Cc: arm@freebsd.org Subject: Re: freebsd-beaglebone install problem 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: Thu, 06 Sep 2012 05:14:19 -0000 Ah. I see now. You're using the xdev tools from RELENG_9_0. There's a fix in -CURRENT to add support for GCC's -print-file-name=3Dinclude option. That option is used by U-Boot to initialize the gccincdir variable with the location of suitable system headers. To workaround it, you can edit the definition of gccincdir in u-boot/config.mk so that it reads as follows: gccincdir :=3D /usr/arm-freebsd/usr/include (And make sure that directory actually exists on your system, of course.) I'll go track down the commit in -CURRENT that fixes this and MFC it as soon as I get a chance. Cheers, Tim On Sep 5, 2012, at 11:13 AM, Hans Stimer wrote: > Tried the latest in github, but uboot isn't building. I'll have some = time later today to try and figure what is going on. >=20 > # git clone git://arago-project.org/git/projects/u-boot-am33x.git = /usr/home/hans/extern/freebsd-beaglebone/u-boot >=20 > # /bin/sh beaglebsd.sh > Starting at Wed Sep 5 11:05:10 PDT 2012 > Loading configuration values > Found FreeBSD xdev tools for ARM > Found suitable U-Boot sources in = /usr/home/hans/extern/freebsd-beaglebone/u-boot > Found suitable FreeBSD source tree in /usr/armsrc > Patching U-Boot. (Logging to = /usr/home/hans/extern/freebsd-beaglebone/work/_.uboot.patch.log) > Applying patch = /usr/home/hans/extern/freebsd-beaglebone/config/arm/BEAGLEBONE/files/uboot= _patch1_add_libc_to_link_on_FreeBSD.patch > Applying patch = /usr/home/hans/extern/freebsd-beaglebone/config/arm/BEAGLEBONE/files/uboot= _patch2_add_options_to_am335x_config.patch > Applying patch = /usr/home/hans/extern/freebsd-beaglebone/config/arm/BEAGLEBONE/files/uboot= _patch3_fix_api_disk_enumeration.patch > Applying patch = /usr/home/hans/extern/freebsd-beaglebone/config/arm/BEAGLEBONE/files/uboot= _patch4_shrink_spl.patch > Applying patch = /usr/home/hans/extern/freebsd-beaglebone/config/arm/BEAGLEBONE/files/uboot= _patch5_set_zero_bootdelay.patch > Configuring U-Boot. (Logging to = /usr/home/hans/extern/freebsd-beaglebone/work/_.uboot.configure.log) > Building U-Boot. (Logging to = /usr/home/hans/extern/freebsd-beaglebone/work/_.uboot.build.log) > Failed to build U-Boot. > Log in = /usr/home/hans/extern/freebsd-beaglebone/work/_.uboot.build.log > #=20 >=20 >=20 > # cat work/_.uboot.build.log=20 > Generating include/autoconf.mk > include/common.h:43:20: error: stdarg.h: No such file or directory > In file included from include/image.h:36, > from include/common.h:117: > include/compiler.h:8:20: error: stddef.h: No such file or directory > Generating include/autoconf.mk.dep > include/common.h:43:20: error: stdarg.h: No such file or directory > In file included from include/image.h:36, > from include/common.h:117: > include/compiler.h:8:20: error: stddef.h: No such file or directory > arm-freebsd-gcc -DDO_DEPS_ONLY \ > -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ = -DCONFIG_SYS_TEXT_BASE=3D0x80100000 -DCONFIG_SPL_TEXT_BASE=3D0x402F0400 = -I/usr/home/hans/extern/freebsd-beaglebone/u-boot/include -fno-builtin = -ffreestanding -nostdinc -isystem include -pipe -DCONFIG_ARM -D__ARM__ = -marm -mabi=3Daapcs-linux -mno-thumb-interwork -march=3Darmv5 -Wall = -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral = -Wno-format-security \ > -o lib/asm-offsets.s lib/asm-offsets.c -c -S > In file included from lib/asm-offsets.c:18: > include/common.h:43:20: error: stdarg.h: No such file or directory > In file included from include/image.h:36, > from include/common.h:117, > from lib/asm-offsets.c:18: > include/compiler.h:8:20: error: stddef.h: No such file or directory > In file included from lib/asm-offsets.c:18: > include/common.h:687: error: expected declaration specifiers or '...' = before 'va_list' > In file included from lib/asm-offsets.c:18: > include/common.h:719: error: expected declaration specifiers or '...' = before 'va_list' > gmake: *** [lib/asm-offsets.s] Error 1 > #=20 >=20 > On Tuesday, September 4, 2012 at 9:28 PM, Tim Kientzle wrote: >=20 >>=20 >> On Sep 4, 2012, at 9:22 PM, Tim Kientzle wrote: >>=20 >>>=20 >>> On Sep 4, 2012, at 6:07 PM, Warner Losh wrote: >>>=20 >>>>=20 >>>> On Sep 4, 2012, at 4:17 PM, Hans Stimer wrote: >>>>=20 >>>>> I'm running into problems getting FreeBSD working on the = BeagleBone. >>>=20 >>>>>=20 >>>>>> # cu -l /dev/ttyU1 -s 115200 >>>>>> Connected >>>>>> CCCCCCCC >>>=20 >>> The ROM code for the AM3358 SoC in the BeagleBone falls >>> back to YModem if it can't load the first-stage MLO boot loader >>> from SDHC. >>>=20 >>> If you see this, then either the FAT partition is >>> ill-formed or the MLO file is missing. >>>=20 >>>>> I checked the logs, and this one stood out: >>>>>=20 >>>>>> # less _.uboot.build.log >>>>>> Generating include/autoconf.mk >>>>>> include/common.h:43:20: error: stdarg.h: No such file or = directory >>>>>> In file included from include/image.h:36, >>>>>> from include/common.h:117: >>>=20 >>> Yeah, looks like U-Boot didn't build. >>>=20 >>> I haven't updated my local U-Boot sources in a while, >>> I'll go do that and get right back to you=85 >>=20 >> Please update the freebsd-beaglebone scripts and >> try again. I found and fixed a couple of problems: >>=20 >> * I had reversed the logic to decide if patches were already >> applied, so U-Boot wasn't getting patched. >> * One of my patches needed to be updated to work with >> the newest U-Boot sources. >> * I added some logic so that the beaglebsd.sh script will >> actually fail with an error message if the U-Boot patch, >> configure, or build steps fail. This should make problems >> like this more obvious. >>=20 >> Let me know if you run into any other issues. >>=20 >> Cheers, >>=20 >> Tim >=20 From owner-freebsd-arm@FreeBSD.ORG Sat Sep 8 16:52:36 2012 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 82E491065674; Sat, 8 Sep 2012 16:52:36 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id D7F418FC12; Sat, 8 Sep 2012 16:52:35 +0000 (UTC) Received: from marcelm-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q88GqOsO028614 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 8 Sep 2012 09:52:24 -0700 (PDT) (envelope-from marcel@xcllnt.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Marcel Moolenaar In-Reply-To: <1346857799.59094.66.camel@revolution.hippie.lan> Date: Sat, 8 Sep 2012 09:52:23 -0700 Content-Transfer-Encoding: 7bit Message-Id: <01CF0B3B-1F24-4BAA-A662-356796DE2EDA@xcllnt.net> References: <1346689154.1140.601.camel@revolution.hippie.lan> <3AFC763F-011C-46B4-B500-FE21B704259F@bsdimp.com> <1346857799.59094.66.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1486) Cc: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Some busdma stats 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, 08 Sep 2012 16:52:36 -0000 On Sep 5, 2012, at 8:09 AM, Ian Lepore wrote: > For that to work, the busdma implementation needs to be able to > efficiently allocate buffers that are properly aligned and padded and > especially that are guaranteed not to share a cache line with some other > unrelated data. The busdma implementation can't get those guarantees > from malloc(9), and the alternatives (contigmalloc(), and the kmem_alloc > family) only work in page-sized chunks. We're asking drivers to > allocate individual buffers of sometimes no more than a few bytes each. In my new busdma implementation this is indeed one of the things that get addressed. In fact, it contains a reverse mapping from the busdma tag as we know it (representing the device's perspective) to a new memory tag used to represent the corresponding CPU perspective. It's the memory tag that can only be used for allocating DMA-capable memory, as bus implementation may have non-trivial address transfor- mations. Note that the memory tag is where you assert CPU constraints, like cacheline alignment. See also: http://wiki.freebsd.org/UnifiedBusDma I'm working on the projects/altix2 branch right now. > So that's all I'm addressing in the patchset I submitted: make sure > that when we start fixing drivers to allocate 256 individual 16-byte IO > descriptors that it shares with the hardware, that doesn't result in > allocating 256 pages of memory. Yup. > Also, if the request is for > BUS_DMA_COHERENT memory, make sure that doesn't result in turning off > caching in up to 256 pages that each contain a 16 byte IO buffer and > 4080 bytes of unrelated data. Or worse: you end up with multiple incompatible translations for the same physical page. This tends to cause machine checks. The busdma infrastructure needs to maintain it's own list of physical pages and do so per "attribute". BTW: Are you interested in fixing bounce buffering as well? -- Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-arm@FreeBSD.ORG Sat Sep 8 17:52:01 2012 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 B943D106564A for ; Sat, 8 Sep 2012 17:52:01 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh10.mail.rice.edu (mh10.mail.rice.edu [128.42.201.30]) by mx1.freebsd.org (Postfix) with ESMTP id 854268FC12 for ; Sat, 8 Sep 2012 17:52:01 +0000 (UTC) Received: from mh10.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh10.mail.rice.edu (Postfix) with ESMTP id 8D2DC672EA; Sat, 8 Sep 2012 12:52:00 -0500 (CDT) Received: from mh10.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh10.mail.rice.edu (Postfix) with ESMTP id 8BB71672E9; Sat, 8 Sep 2012 12:52:00 -0500 (CDT) X-Virus-Scanned: by amavis-2.7.0 at mh10.mail.rice.edu, auth channel Received: from mh10.mail.rice.edu ([127.0.0.1]) by mh10.mail.rice.edu (mh10.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id uXoyBJfRjKBB; Sat, 8 Sep 2012 12:52:00 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh10.mail.rice.edu (Postfix) with ESMTPSA id 185F76050E; Sat, 8 Sep 2012 12:51:59 -0500 (CDT) Message-ID: <504B85BE.3030101@rice.edu> Date: Sat, 08 Sep 2012 12:51:58 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:8.0) Gecko/20111113 Thunderbird/8.0 MIME-Version: 1.0 To: Ian Lepore References: <502FD67A.7030003@rice.edu> <1345315508.27688.260.camel@revolution.hippie.lan> <503D12AE.1050705@rice.edu> <1346350374.1140.525.camel@revolution.hippie.lan> <5045351F.6060201@rice.edu> <1346723041.1140.602.camel@revolution.hippie.lan> In-Reply-To: <1346723041.1140.602.camel@revolution.hippie.lan> Content-Type: multipart/mixed; boundary="------------090708090103090700060808" Cc: "arm@freebsd.org" , Alan Cox Subject: Re: arm pmap locking 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, 08 Sep 2012 17:52:01 -0000 This is a multi-part message in MIME format. --------------090708090103090700060808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 09/03/2012 20:44, Ian Lepore wrote: > On Mon, 2012-09-03 at 17:54 -0500, Alan Cox wrote: >> On 08/30/2012 13:12, Ian Lepore wrote: >>> On Tue, 2012-08-28 at 13:49 -0500, Alan Cox wrote: >>>> Can you please retry with the attached patch? For the time being, I >>>> decided to address the above problem by simply enabling recursion on the >>>> new pmap lock. As I mentioned in my prior message, the lock recursion >>>> in the arm pmap is a mistake. However, I'd rather not change two things >>>> at once, i.e., replace the page queues lock and fix the lock recursion. >>>> I'll take a look at eliminating the lock recursion later this week. >>>> >>>> Thanks, >>>> Alan >>>> >>> Sorry for the delay, I finally got around to trying this today, and it >>> seems to be working well initially -- it boots to multiuser and the only >>> difference in the dmesg.boot with and without the patch is the compile >>> date, and the kernel image is 128 bytes smaller with the patch. I've >>> got DIAGNOSTIC and INVARIANTS enabled; I'll run with the patch in place >>> and let you know if anything glitches. >>> >> Could you please test the attached patch? This is a small step toward >> disentangling the arm pmap locking. >> >> Alan >> > Applied the patch, it's running just fine. > Here is another patch. This simplifies the kernel pmap locking in pmap_enter_pv() and corrects some comments. Thanks in advance, Alan --------------090708090103090700060808 Content-Type: text/plain; name="arm_pmap13.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="arm_pmap13.patch" Index: arm/arm/pmap.c =================================================================== --- arm/arm/pmap.c (revision 240166) +++ arm/arm/pmap.c (working copy) @@ -1588,11 +1588,11 @@ pmap_clearbit(struct vm_page *pg, u_int maskbits) */ /* - * pmap_enter_pv: enter a mapping onto a vm_page lst + * pmap_enter_pv: enter a mapping onto a vm_page's PV list * * => caller should hold the proper lock on pvh_global_lock * => caller should have pmap locked - * => we will gain the lock on the vm_page and allocate the new pv_entry + * => we will (someday) gain the lock on the vm_page's PV list * => caller should adjust ptp's wire_count before calling * => caller should not adjust pmap's wire_count */ @@ -1600,33 +1600,26 @@ static void pmap_enter_pv(struct vm_page *pg, struct pv_entry *pve, pmap_t pm, vm_offset_t va, u_int flags) { - int km; rw_assert(&pvh_global_lock, RA_WLOCKED); - + PMAP_ASSERT_LOCKED(pm); if (pg->md.pv_kva != 0) { - /* PMAP_ASSERT_LOCKED(pmap_kernel()); */ - pve->pv_pmap = pmap_kernel(); + pve->pv_pmap = kernel_pmap; pve->pv_va = pg->md.pv_kva; pve->pv_flags = PVF_WRITE | PVF_UNMAN; + if (pm != kernel_pmap) + PMAP_LOCK(kernel_pmap); + TAILQ_INSERT_HEAD(&pg->md.pv_list, pve, pv_list); + TAILQ_INSERT_HEAD(&kernel_pmap->pm_pvlist, pve, pv_plist); + if (pm != kernel_pmap) + PMAP_UNLOCK(kernel_pmap); pg->md.pv_kva = 0; - - if (!(km = PMAP_OWNED(pmap_kernel()))) - PMAP_LOCK(pmap_kernel()); - TAILQ_INSERT_HEAD(&pg->md.pv_list, pve, pv_list); - TAILQ_INSERT_HEAD(&pve->pv_pmap->pm_pvlist, pve, pv_plist); - PMAP_UNLOCK(pmap_kernel()); if ((pve = pmap_get_pv_entry()) == NULL) panic("pmap_kenter_pv: no pv entries"); - if (km) - PMAP_LOCK(pmap_kernel()); } - - PMAP_ASSERT_LOCKED(pm); pve->pv_pmap = pm; pve->pv_va = va; pve->pv_flags = flags; - TAILQ_INSERT_HEAD(&pg->md.pv_list, pve, pv_list); TAILQ_INSERT_HEAD(&pm->pm_pvlist, pve, pv_plist); pg->md.pvh_attrs |= flags & (PVF_REF | PVF_MOD); --------------090708090103090700060808--