From owner-freebsd-arm@FreeBSD.ORG Sun Jun 28 10:55:16 2009 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 C1FDB106567F for ; Sun, 28 Jun 2009 10:55:16 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.freebsd.org (Postfix) with ESMTP id 4D2998FC19 for ; Sun, 28 Jun 2009 10:55:16 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=Hrwt8fWgTlIA:10 a=hlIU1J3LQChSjWV/CGRL5g==:17 a=m4X4Y5dQOB2DOwTTiTYA:9 a=8ipVIBLg3e7VFiSgQXBdK4HAca8A:4 Received: from [193.217.167.6] (account mc467741@c2i.net HELO laptop.selasky.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1167912719; Sun, 28 Jun 2009 11:55:13 +0200 From: Hans Petter Selasky To: Alexandr Rybalko , freebsd-arm@freebsd.org Date: Sun, 28 Jun 2009 11:54:40 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-CURRENT; KDE/4.2.4; i386; ; ) References: <200906231035.43096.kosmo@semihalf.com> <20090623121129.d18492a3.ray@dlink.ua> <200906231912.20741.hselasky@c2i.net> In-Reply-To: <200906231912.20741.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906281154.43392.hselasky@c2i.net> Cc: freebsd-usb@freebsd.org, Piotr =?utf-8?q?Zi=C4=99cik?= , thompsa@freebsd.org Subject: Re: CPU Cache and busdma usage in USB 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, 28 Jun 2009 10:55:17 -0000 Hi Piotr and Rafal, Your patch is not fully correct. It will break support for x86 and more when bounce pages are uses. Let's get the definitions right: man busdma BUS_DMASYNC_PREREAD Perform any synchronization required prior to an update of host memory by the device. BUS_DMASYNC_PREWRITE Perform any synchronization required after an update of host memory by the CPU and prior to device access to host memory. BUS_DMASYNC_POSTREAD Perform any synchronization required after an update of host memory by the device and prior to CPU access to host memory. BUS_DMASYNC_POSTWRITE Perform any synchronization required after device access to host memory. My view: XXX_PREXXX functions should be used prior to read/write device access. In other words, PRE has to be a flush operation. XXX_POSTXXX functions should be used after read/write device access. In other words, POST has to be an invalidate operation. Reading: src/sys/arm/arm/busdma_machdep.c I find bus_dmamap_sync_buf() to be coherent with this view. Can you check if the COHERENT bit is set for your allocation? if (map->flags & DMAMAP_COHERENT) return; Summed up: The existing code is doing correct. What is known is a problem with the memory mapping, so that the same memory page can get mapped with different attributes, which makes the problem appear. --HPS From owner-freebsd-arm@FreeBSD.ORG Mon Jun 29 07:33:18 2009 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 818C01065674; Mon, 29 Jun 2009 07:33:18 +0000 (UTC) (envelope-from venkiece2005@gmail.com) Received: from mail-gx0-f210.google.com (mail-gx0-f210.google.com [209.85.217.210]) by mx1.freebsd.org (Postfix) with ESMTP id 0E4238FC08; Mon, 29 Jun 2009 07:33:17 +0000 (UTC) (envelope-from venkiece2005@gmail.com) Received: by gxk6 with SMTP id 6so5007507gxk.19 for ; Mon, 29 Jun 2009 00:33:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=bNNrjSbPlhnqL8GO1unoZh80ZMCKfWp1HwMcTExvLZM=; b=qjrR1lkVGHq4tbHtqDznxbETVNRgtLG/Vg3S3V0vs6tV75Dmm11yHraY589G/OVIuX Zg9gqwD6nBpZEB2jQkFz+9K0xbpcJQHAiyl5JotI/YBy68WHrJHWBiXUyorh2en+QAvO fg6EMd6+ZZUyV2Isdhs410bSOOV4kHa8C7o8s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=maO+k150/xXjQh7miTV5PsVBdwvCgjP3NW5aH3zWK4ZOps2pA3mHJa8JvAnpTGh1u3 OYew8IXTvXQq0Dcvh+io0R9HyEHeUZnL2jpcK//xdEqKGlkeRJ0r0rZ3wvOgFHRgzX/q dixurjH+Uxi8OR22FeagFC9OGAuPIx6i26d9Y= MIME-Version: 1.0 Received: by 10.151.83.17 with SMTP id k17mr3298326ybl.125.1246260797487; Mon, 29 Jun 2009 00:33:17 -0700 (PDT) In-Reply-To: <6d53329e0906182148k57b36ab6n6ddf1124ad4dfd6c@mail.gmail.com> References: <6d53329e0906160229j2fdba518h84b13652153a32f6@mail.gmail.com> <6d53329e0906182148k57b36ab6n6ddf1124ad4dfd6c@mail.gmail.com> Date: Mon, 29 Jun 2009 13:03:17 +0530 Message-ID: <6d53329e0906290033g54895993iae826416e9d08f4@mail.gmail.com> From: venki kaps To: kan@FreeBSD.org, netbsd-users@netbsd.org, freebsd-arm@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Fwd: [libc] dlclose gives "invalid shared object handle" without pthread combination. 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, 29 Jun 2009 07:33:18 -0000 Hi, Ref: http://www.mail-archive.com/svn-src-all@freebsd.org/msg10960.html Log: Allow order of initialization of loaded shared objects to be altered through their .init code. This might happen if init vector calls dlopen on its own and that dlopen causes some not yet initialized object to be initialized earlier as part of that dlopened DAG. Do not reset module reference counts to zero on final fini vector run when process is exiting. Just add an additional parameter to force fini vector invocation regardless of current reference count value if object was not destructed yet. This allows dlclose called from fini vector to proceed normally instead of failing with handle validation error. Query: ------- I have one question regarding " Do not reset module reference counts to zero on final fini vector run when process is exiting". Observation: --------------- The above issue normally happened when object is destructed and gives handl= e validation error. I have expected this is related to dl_refcount issue when process is exitin= g. Am just giving some more explanation regarding this issue: When i tested in the my Linux environment it shows the dl_reference count is 1 when dlopen and 0 when dlclose. In this test when the main dlclose invokes, the reference count is decremen= ted to zero But still other dependent objects are present and for these objects dl_reference count is required with one(1) to close the handle successfully= . As per dl* scenario, the dl_reference count has to be incremented by one(1) for the main object(main executable) as well as other ELF dependencies object. Now, I have invoked dl_reference count is incremented by one(1) for main ob= ject handle in _rtld_map_object function which is called by _rtld(). rtld Changes: --------------- _rtld(): /* Load the main program. */ Location: src/libexec/ld.elf_so/rtld.c: _rtld_objmain =3D _rtld_map_object(obj_name, fd, NULL); _rtld_map_object(): / * * Map a shared object into memory. The argument is a file descriptor, * which must be open on the object and positioned at its beginning. * The return value is a pointer to a newly-allocated Obj_Entry structure * for the shared object. Returns NULL on failure. */ --- a/src/libexec/ld.elf_so/map_object.c +++ b/src/libexec/ld.elf_so/map_object.c @@ -181,6 +181,10 @@ _rtld_map_object(const char *path, int f phdr =3D (Elf_Phdr *) ((caddr_t)ehdr + ehdr->e_phoff); phlimit =3D phdr + ehdr->e_phnum; nsegs =3D 0; + + /* + * And it was opened directly If trying to open + * the link map for the main executable. So the dl_recount + * must be the main dlopen one. + */ + ++obj->dl_refcount; + while (phdr < phlimit) { switch (phdr->p_type) { case PT_INTERP: After the above changes, [libc] dlclose does not give "invalid shared object handle" with/without pthread combination Since the dl_reference count is 2 instead of 1 for main object handle and 1 instead of 0 for other dependent objects. Could you give opinion about the above issue? Thanks & Regards, Venkappa ---------- Forwarded message ---------- From: venki kaps Date: Fri, Jun 19, 2009 at 10:18 AM Subject: [libc] dlclose gives "invalid shared object handle" without pthread combination. To: gnats-bugs@netbsd.org Hi, I am using the NetBSD implementation of rtld(src/libexec/ld.elf_so/) for ARM/MIPS and =A0have been porting NetBSD source in the Linux environment with our own pthread library. system environment: Compiler: arm-linux-gcc-4.3.3 OS: Linux Kernel: 2.6.29 I have C++ static constructor/destructor issue with my rtld. Problem Report: "ld.elf_so does not execute .init/.fini functions in order" and [libc] dlclose gives "invalid shared object handle" when called through the fini function of ano= ther module. The similar NetBSD/freeBSD issues are found from the following References: [1] http://gnats.netbsd.org/37347 [2] http://updraft3.jp.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/42956 The above issues are already commited in NetBSD-5-0-RELEASE. I have ported NetBSD-5-0-RELEASE rtld and tested Ref[1] provided static constructor/destructor test and did not find any issues with shared pthread combination but noticed [libc] dlclose gives "invalid shared object handle" without pthread combination. The static constructor/destructor test results: It should be : -------------- $ ./foobar foo_ctor bar_ctor tar_ctor main_ctor dep1_ctor dep2_ctor dll_ctor dll_dtor dep2_dtor dep1_dtor main_dtor tar_dtor bar_dtor foo_dtor While currently I get: ---------------------- with pthreads: $ ./foobar foo_ctor bar_ctor tar_ctor main_ctor dep1_ctor dep2_ctor dll_ctor dll_dtor dep2_dtor dep1_dtor main_dtor tar_dtor bar_dtor foo_dtor without pthreads: $ ./foobar foo_ctor bar_ctor tar_ctor main_ctor dep1_ctor dep2_ctor dll_ctor dll_dtor dep2_dtor dep1_dtor main_dtor tar_dtor bar_dtor foo_dtor Invalid shared object handle 0xbdbed400 This gives a "invalid shared object handle" message because the refcount field (obj->dl_refcount) for the handle is zero. it never even calls dlerr() in dlcose but __dlclose(void *handle) source sequence, int dlclose(void *handle) { =A0 =A0 =A0 Obj_Entry *root =3D _rtld_dlcheck(handle); =A0 =A0 =A0 if (root =3D=3D NULL) =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -1; =A0 =A0 =A0 _rtld_debug.r_state =3D RT_DELETE; =A0 =A0 =A0 _rtld_debug_state(); =A0 =A0 =A0 --root->dl_refcount; =A0 =A0 =A0 _rtld_unload_object(root, true); =A0 =A0 =A0 _rtld_debug.r_state =3D RT_CONSISTENT; =A0 =A0 =A0 _rtld_debug_state(); =A0 =A0 =A0 return 0; } static Obj_Entry * _rtld_dlcheck(void *handle) { =A0 =A0 =A0 Obj_Entry *obj; =A0 =A0 =A0 for (obj =3D _rtld_objlist; obj !=3D NULL; obj =3D obj->next) =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (obj =3D=3D (Obj_Entry *) handle) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break; =A0 =A0 =A0 xprintf("obj->dl_refcount is %d\n",obj->dl_refcount); =A0 =A0 =A0 if (obj =3D=3D NULL || obj->dl_refcount =3D=3D 0) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 xwarnx("Invalid shared object handle %p", handl= e); =A0 =A0 =A0 =A0 =A0 =A0 =A0 return NULL; =A0 =A0 =A0 } =A0 =A0 =A0 return obj; } I have printed =A0xprintf("obj->dl_refcount is %d\n",obj->dl_refcount); =A0obj->dl_refcount is getting zero(0). So due to "obj->dl_refcount =3D=3D 0" the error "invalid shared object handle" is showing. I have little bit confused about dlclose destructor with/without pthreads. I have some queries: 1) Is it required any changes apart from the NetBSD-5-0-RELEASE/{Ref[1],[2]= }? 2) Are any changes required in thread-stub? 3) i do not know why this error is coming even though all the =A0 constructor/destructor sequences are completed. 4) is it rtld_exit/fini/static C++ destructor/dlcose sequence problem? =A0(OR) =A0is it crtstuff/exit/atexit/cxa_finalize/cxa_atexit sequence problem? Could anyone provide any inputs to the my issue? Thanks in advance. Thanks & Regards, Venkappa From owner-freebsd-arm@FreeBSD.ORG Mon Jun 29 08:19:51 2009 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 9EBDD1065672 for ; Mon, 29 Jun 2009 08:19:51 +0000 (UTC) (envelope-from hackr_d@yahoo.com) Received: from web35703.mail.mud.yahoo.com (web35703.mail.mud.yahoo.com [66.163.179.157]) by mx1.freebsd.org (Postfix) with SMTP id 643418FC16 for ; Mon, 29 Jun 2009 08:19:51 +0000 (UTC) (envelope-from hackr_d@yahoo.com) Received: (qmail 91429 invoked by uid 60001); 29 Jun 2009 07:53:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1246261988; bh=yQ00FVu8PMWmnlsC+pbliK+AKYQZnD17t/H7KrwV14Q=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=ppbkng8QIba6cE/4n7KJiI5z5glkFA6VWcOsmHT1gKr1ZGdclc25Kmy4t70KZb72L1EQqXe7UUZjgSdQ/PNg4Z3VDgIblb+uPlvH9zmjpkQMoPEXU3EuxFi9S0oTH6pwgJ0wMamUDXPpLPOPTgKWFdebsy7ALo1W9qnpZ1Qt9Po= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=K91c0sMdVuNkdgXB4PaM4RVZBymxizkNVxgnhDNPpNFUjsElYosManY8FgaNsSY6ICiUnMN1yry53b73u3UoVtqo/NU9+NoYVnTX7azZEHJdeVa9yjNxyisNxi9Tv7oXHWJmhPuMGodOtBchhPK5i9R0chEE5cIhZKj/iXlapIU=; Message-ID: <992872.90651.qm@web35703.mail.mud.yahoo.com> X-YMail-OSG: 7c6VVPUVM1nH.SJh98lFY7ONwIcaABAlX51l.ud3JVz3g1vuoaflVeR9asLofveBkY2VN3VeJLkd7eNFu6eziC1kqtvCUcxfl2LnNpzKZ3MLQG_F6eTq2dPQhKt0G.vPq.BtShhmRgUofw.k9xZjjIIOPLAq6JiekosViVoFP0MTbs9RSxzB32SpauiXHq_RQBrIxtOMpMDT183AqDRj0yGbvjfkzvSNFD69KGLJbVOJ4FUM29ukSB17khoQWrLJZbBjxLNxGcMgFVhxYDB9bkjTrIy3Qx_GXwga_lQQSYGMSqqfLouTWLH_Q8Ptj.r2rO5v0q2KvH7vTIeHMtUMcApX8wwqeDBfwKPTcOduzcGgng-- Received: from [24.239.50.161] by web35703.mail.mud.yahoo.com via HTTP; Mon, 29 Jun 2009 00:53:08 PDT X-Mailer: YahooMailClassic/5.4.17 YahooMailWebService/0.7.289.15 Date: Mon, 29 Jun 2009 00:53:08 -0700 (PDT) From: Donn Miller To: freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1871264675-1246261988=:90651" Subject: Support for the Friendly Arm (mini 2440) development board 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, 29 Jun 2009 08:19:51 -0000 --0-1871264675-1246261988=:90651 Content-Type: text/plain; charset=us-ascii http://www.developmentboard.net/index.php/productdetail/Development+board/ARM9/SAMSUNG/S3C2440/MINI2440+with+LCD/info/1 http://www.friendlyarm.net/products/mini2440 http://code.google.com/p/mini2440/ Partial dmesg of Linux kernel I managed to boot on this device: Linux version 2.6.30-rc8 (dmmiller@localhost) (gcc version 4.4.0 (Gentoo 4.4.0 p1.1) ) #1 Thu Jun 4 07:54:48 EDT 2009^M CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0007177^M CPU: VIVT data cache, VIVT instruction cache^M Machine: MINI2440^M Memory policy: ECC disabled, Data cache writeback^M CPU S3C2440A (id 0x32440001)^M S3C24XX Clocks, (c) 2004 Simtec Electronics^M S3C244X: core 405.000 MHz, memory 101.250 MHz, peripheral 50.625 MHz^M CLOCK: Slow mode (1.500 MHz), fast, MPLL on, UPLL on^M Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256^M Kernel command line: root=/dev/mtdblock3 rootfstype=jffs2 console=ttySAC0,115200^M NR_IRQS:85^M irq: clearing pending status 02000000^M irq: clearing subpending status 00000003^M irq: clearing subpending status 00000002^M PID hash table entries: 256 (order: 8, 1024 bytes)^M Console: colour dummy device 80x30^M console [ttySAC0] enabled^M Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)^M Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)^M Memory: 64MB = 64MB total^M Memory: 60748KB available (3472K code, 409K data, 128K init, 0K highmem)^M I also attached the output from the serial console, showing an attempt to boot a Linux arm kernel. Note that mounting root was unsuccessful (didn't install a small embedded distribution yet). I figured this dmesg, though from Linux, will suffice to sufficiently describe what this device is and if I can boot FreeBSD-arm on it. Thanks for your help. Donn --0-1871264675-1246261988=:90651 Content-Type: text/plain; name="mini2440.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mini2440.txt" U2NyaXB0IHN0YXJ0ZWQgb24gTW9uIEp1biAyOSAwMzo0Nzo0MCAyMDA5Cmdh dGV3YXkjIGN1IC1zIDExNTIwMCAtbCB0dHlVMApDb25uZWN0ZWQK/goKVS1C b290IDEuMy4yLW1pbmkyNDQwIChKdW4gIDQgMjAwOSAtIDAyOjMxOjMzKQoK STJDOiAgIHJlYWR5CkRSQU06ICA2NCBNQgpGbGFzaDogIDIgTUIKTkFORDog IDY0IE1pQgpGb3VuZCBFbnZpcm9ubWVudCBvZmZzZXQgaW4gT09CLi4KVVNC OiAgIFMzQzI0MTAgVVNCIERldmljZWQKSW46ICAgIHNlcmlhbApPdXQ6ICAg c2VyaWFsCkVycjogICBzZXJpYWwKTUFDOiAwODowODoxMToxODoxMjoyNwpI aXQgYW55IGtleSB0byBzdG9wIGF1dG9ib290OiAgMyAICAggMiAICAggMSAI CAggMCAKTUlOSTI0NDAgIyBuYm9vdCBrZXJuZWw7Ym9vdG0KCkxvYWRpbmcg ZnJvbSBOQU5EIDY0TWlCIDMsM1YgOC1iaXQsIG9mZnNldCAweDYwMDAwCiAg IEltYWdlIE5hbWU6ICAgCiAgIENyZWF0ZWQ6ICAgICAgMjAwOS0wNi0xOCAg IDc6MzE6MDMgVVRDCiAgIEltYWdlIFR5cGU6ICAgQVJNIExpbnV4IEtlcm5l bCBJbWFnZSAodW5jb21wcmVzc2VkKQogICBEYXRhIFNpemU6ICAgIDE5OTcy MzIgQnl0ZXMgPSAgMS45IE1CCiAgIExvYWQgQWRkcmVzczogMzAwMDgwMDAK ICAgRW50cnkgUG9pbnQ6ICAzMDAwODAwMAojIyBCb290aW5nIGtlcm5lbCBm cm9tIExlZ2FjeSBJbWFnZSBhdCAzMjAwMDAwMCAuLi4KICAgSW1hZ2UgTmFt ZTogICAKICAgQ3JlYXRlZDogICAgICAyMDA5LTA2LTE4ICAgNzozMTowMyBV VEMKICAgSW1hZ2UgVHlwZTogICBBUk0gTGludXggS2VybmVsIEltYWdlICh1 bmNvbXByZXNzZWQpCiAgIERhdGEgU2l6ZTogICAgMTk5NzIzMiBCeXRlcyA9 ICAxLjkgTUIKICAgTG9hZCBBZGRyZXNzOiAzMDAwODAwMAogICBFbnRyeSBQ b2ludDogIDMwMDA4MDAwCiAgIFZlcmlmeWluZyBDaGVja3N1bSAuLi4gT0sK ICAgTG9hZGluZyBLZXJuZWwgSW1hZ2UgLi4uIE9LCk9LCgpTdGFydGluZyBr ZXJuZWwgLi4uCgpVbmNvbXByZXNzaW5nIExpbnV4Li4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLiBkb25lLCBib290aW5nIHRoZSBrZXJuZWwu CkxpbnV4IHZlcnNpb24gMi42LjMwLXJjOCAoZG1taWxsZXJAbG9jYWxob3N0 KSAoZ2NjIHZlcnNpb24gNC40LjAgKEdlbnRvbyA0LjQuMCBwMS4xKSApICMx IFRodSBKdW4gNCAwNzo1NDo0OCBFRFQgMjAwOQpDUFU6IEFSTTkyMFQgWzQx MTI5MjAwXSByZXZpc2lvbiAwIChBUk12NFQpLCBjcj1jMDAwNzE3NwpDUFU6 IFZJVlQgZGF0YSBjYWNoZSwgVklWVCBpbnN0cnVjdGlvbiBjYWNoZQpNYWNo aW5lOiBNSU5JMjQ0MApNZW1vcnkgcG9saWN5OiBFQ0MgZGlzYWJsZWQsIERh dGEgY2FjaGUgd3JpdGViYWNrCkNQVSBTM0MyNDQwQSAoaWQgMHgzMjQ0MDAw MSkKUzNDMjRYWCBDbG9ja3MsIChjKSAyMDA0IFNpbXRlYyBFbGVjdHJvbmlj cwpTM0MyNDRYOiBjb3JlIDQwNS4wMDAgTUh6LCBtZW1vcnkgMTAxLjI1MCBN SHosIHBlcmlwaGVyYWwgNTAuNjI1IE1IegpDTE9DSzogU2xvdyBtb2RlICgx LjUwMCBNSHopLCBmYXN0LCBNUExMIG9uLCBVUExMIG9uCkJ1aWx0IDEgem9u ZWxpc3RzIGluIFpvbmUgb3JkZXIsIG1vYmlsaXR5IGdyb3VwaW5nIG9uLiAg VG90YWwgcGFnZXM6IDE2MjU2Cktlcm5lbCBjb21tYW5kIGxpbmU6IHJvb3Q9 L2Rldi9tdGRibG9jazMgcm9vdGZzdHlwZT1qZmZzMiBjb25zb2xlPXR0eVNB QzAsMTE1MjAwCk5SX0lSUVM6ODUKaXJxOiBjbGVhcmluZyBwZW5kaW5nIHN0 YXR1cyAwMjAwMDAwMAppcnE6IGNsZWFyaW5nIHN1YnBlbmRpbmcgc3RhdHVz IDAwMDAwMDAzCmlycTogY2xlYXJpbmcgc3VicGVuZGluZyBzdGF0dXMgMDAw MDAwMDIKUElEIGhhc2ggdGFibGUgZW50cmllczogMjU2IChvcmRlcjogOCwg MTAyNCBieXRlcykKQ29uc29sZTogY29sb3VyIGR1bW15IGRldmljZSA4MHgz MApjb25zb2xlIFt0dHlTQUMwXSBlbmFibGVkCkRlbnRyeSBjYWNoZSBoYXNo IHRhYmxlIGVudHJpZXM6IDgxOTIgKG9yZGVyOiAzLCAzMjc2OCBieXRlcykK SW5vZGUtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA0MDk2IChvcmRlcjog MiwgMTYzODQgYnl0ZXMpCk1lbW9yeTogNjRNQiA9IDY0TUIgdG90YWwKTWVt b3J5OiA2MDc0OEtCIGF2YWlsYWJsZSAoMzQ3MksgY29kZSwgNDA5SyBkYXRh LCAxMjhLIGluaXQsIDBLIGhpZ2htZW0pClNMVUI6IEdlbnNsYWJzPTEzLCBI V2FsaWduPTMyLCBPcmRlcj0wLTMsIE1pbk9iamVjdHM9MCwgQ1BVcz0xLCBO b2Rlcz0xCkNhbGlicmF0aW5nIGRlbGF5IGxvb3AuLi4gMjAxLjkzIEJvZ29N SVBTIChscGo9NTA0ODMyKQpNb3VudC1jYWNoZSBoYXNoIHRhYmxlIGVudHJp ZXM6IDUxMgpDUFU6IFRlc3Rpbmcgd3JpdGUgYnVmZmVyIGNvaGVyZW5jeTog b2sKbmV0X25hbWVzcGFjZTogNzA0IGJ5dGVzCk5FVDogUmVnaXN0ZXJlZCBw cm90b2NvbCBmYW1pbHkgMTYKTUlOSTI0NDA6IE9wdGlvbiBzdHJpbmcgbWlu aTI0NDA9MHRiCk1JTkkyNDQwOiBMQ0QgWzA6MjQweDMyMF0gMTo4MDB4NDgw IDI6MTAyNHg3NjgKUzNDMjQ0MDogSW5pdGlhbGlzaW5nIGFyY2hpdGVjdHVy ZQpTM0MyNDQwOiBJUlEgU3VwcG9ydApTM0MyNFhYIERNQSBEcml2ZXIsIChj KSAyMDAzLTIwMDQsMjAwNiBTaW10ZWMgRWxlY3Ryb25pY3MKRE1BIGNoYW5u ZWwgMCBhdCBjNDgwODAwMCwgaXJxIDMzCkRNQSBjaGFubmVsIDEgYXQgYzQ4 MDgwNDAsIGlycSAzNApETUEgY2hhbm5lbCAyIGF0IGM0ODA4MDgwLCBpcnEg MzUKRE1BIGNoYW5uZWwgMyBhdCBjNDgwODBjMCwgaXJxIDM2ClMzQzI0NFg6 IENsb2NrIFN1cHBvcnQsIERWUyBvZmYKYmlvOiBjcmVhdGUgc2xhYiA8Ymlv LTA+IGF0IDAKdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRy aXZlciB1c2Jmcwp1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2Ug ZHJpdmVyIGh1Ygp1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBkZXZpY2UgZHJp dmVyIHVzYgpzM2MyNDQwLWkyYyBzM2MyNDQwLWkyYzogc2xhdmUgYWRkcmVz cyAweDEwCnMzYzI0NDAtaTJjIHMzYzI0NDAtaTJjOiBidXMgZnJlcXVlbmN5 IHNldCB0byA5OCBLSHoKczNjMjQ0MC1pMmMgczNjMjQ0MC1pMmM6IGkyYy0w OiBTM0MgSTJDIGFkYXB0ZXIKTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZh bWlseSAyCklQIHJvdXRlIGNhY2hlIGhhc2ggdGFibGUgZW50cmllczogMTAy NCAob3JkZXI6IDAsIDQwOTYgYnl0ZXMpClRDUCBlc3RhYmxpc2hlZCBoYXNo IHRhYmxlIGVudHJpZXM6IDIwNDggKG9yZGVyOiAyLCAxNjM4NCBieXRlcykK VENQIGJpbmQgaGFzaCB0YWJsZSBlbnRyaWVzOiAyMDQ4IChvcmRlcjogMSwg ODE5MiBieXRlcykKVENQOiBIYXNoIHRhYmxlcyBjb25maWd1cmVkIChlc3Rh Ymxpc2hlZCAyMDQ4IGJpbmQgMjA0OCkKVENQIHJlbm8gcmVnaXN0ZXJlZApO RVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDEKSkZGUzIgdmVyc2lv biAyLjIuIChOQU5EKSDCqSAyMDAxLTIwMDYgUmVkIEhhdCwgSW5jLgpST01G UyBNVEQgKEMpIDIwMDcgUmVkIEhhdCwgSW5jLgptc2dtbmkgaGFzIGJlZW4g c2V0IHRvIDExOAphbGc6IE5vIHRlc3QgZm9yIHN0ZHJuZyAoa3JuZykKaW8g c2NoZWR1bGVyIG5vb3AgcmVnaXN0ZXJlZAppbyBzY2hlZHVsZXIgYW50aWNp cGF0b3J5IHJlZ2lzdGVyZWQgKGRlZmF1bHQpCmlvIHNjaGVkdWxlciBkZWFk bGluZSByZWdpc3RlcmVkCmlvIHNjaGVkdWxlciBjZnEgcmVnaXN0ZXJlZApD b25zb2xlOiBzd2l0Y2hpbmcgdG8gY29sb3VyIGZyYW1lIGJ1ZmZlciBkZXZp Y2UgNjB4NTMKZmIwOiBzM2MyNDEwZmIgZnJhbWUgYnVmZmVyIGRldmljZQpz M2MyNDQwLXVhcnQuMDogdHR5U0FDMCBhdCBNTUlPIDB4NTAwMDAwMDAgKGly cSA9IDcwKSBpcyBhIFMzQzI0NDAKczNjMjQ0MC11YXJ0LjE6IHR0eVNBQzEg YXQgTU1JTyAweDUwMDA0MDAwIChpcnEgPSA3MykgaXMgYSBTM0MyNDQwCnMz YzI0NDAtdWFydC4yOiB0dHlTQUMyIGF0IE1NSU8gMHg1MDAwODAwMCAoaXJx ID0gNzYpIGlzIGEgUzNDMjQ0MApicmQ6IG1vZHVsZSBsb2FkZWQKYXQyNCAw LTAwNTA6IDEwMjQgYnl0ZSAyNGMwOCBFRVBST00gKHdyaXRhYmxlKQpkbTkw MDAgRXRoZXJuZXQgRHJpdmVyLCBWMS4zMQpldGgwIChkbTkwMDApOiBub3Qg dXNpbmcgbmV0X2RldmljZV9vcHMgeWV0CmV0aDA6IGRtOTAwMGUgYXQgYzQ4 NmUzMDAsYzQ4NzIzMDQgSVJRIDUxIE1BQzogMDg6MDg6MTE6MTg6MTI6Mjcg KGNoaXApClMzQzI0WFggTkFORCBEcml2ZXIsIChjKSAyMDA0IFNpbXRlYyBF bGVjdHJvbmljcwpzM2MyNDQwLW5hbmQgczNjMjQ0MC1uYW5kOiBUYWNscz0x LCA5bnMgVHdycGgwPTMgMjlucywgVHdycGgxPTIgMTlucwpOQU5EIGRldmlj ZTogTWFudWZhY3R1cmVyIElEOiAweGVjLCBDaGlwIElEOiAweDc2IChTYW1z dW5nIE5BTkQgNjRNaUIgMywzViA4LWJpdCkKQ3JlYXRpbmcgNCBNVEQgcGFy dGl0aW9ucyBvbiAiTkFORCA2NE1pQiAzLDNWIDgtYml0IjoKMHgwMDAwMDAw MDAwMDAtMHgwMDAwMDAwNDAwMDAgOiAidS1ib290IgpmdGxfY3M6IEZUTCBo ZWFkZXIgbm90IGZvdW5kLgoweDAwMDAwMDA0MDAwMC0weDAwMDAwMDA2MDAw MCA6ICJ1LWJvb3QtZW52IgpmdGxfY3M6IEZUTCBoZWFkZXIgbm90IGZvdW5k LgoweDAwMDAwMDA2MDAwMC0weDAwMDAwMDU2MDAwMCA6ICJrZXJuZWwiCmZ0 bF9jczogRlRMIGhlYWRlciBub3QgZm91bmQuCjB4MDAwMDAwNTYwMDAwLTB4 MDAwMDA0MDAwMDAwIDogInJvb3QiCmZ0bF9jczogRlRMIGhlYWRlciBub3Qg Zm91bmQuCm9oY2lfaGNkOiBVU0IgMS4xICdPcGVuJyBIb3N0IENvbnRyb2xs ZXIgKE9IQ0kpIERyaXZlcgpzM2MyNDEwLW9oY2kgczNjMjQxMC1vaGNpOiBT M0MyNFhYIE9IQ0kKczNjMjQxMC1vaGNpIHMzYzI0MTAtb2hjaTogbmV3IFVT QiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAxCnMzYzI0 MTAtb2hjaSBzM2MyNDEwLW9oY2k6IGlycSA0MiwgaW8gbWVtIDB4NDkwMDAw MDAKdXNiIHVzYjE6IGNvbmZpZ3VyYXRpb24gIzEgY2hvc2VuIGZyb20gMSBj aG9pY2UKaHViIDEtMDoxLjA6IFVTQiBodWIgZm91bmQKaHViIDEtMDoxLjA6 IDIgcG9ydHMgZGV0ZWN0ZWQKdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50 ZXJmYWNlIGRyaXZlciBsaWJ1c3VhbApzM2MyNDQwLXVzYmdhZGdldCBzM2My NDQwLXVzYmdhZGdldDogUzNDMjQ0MDogaW5jcmVhc2luZyBGSUZPIHRvIDEy OCBieXRlcwptaWNlOiBQUy8yIG1vdXNlIGRldmljZSBjb21tb24gZm9yIGFs bCBtaWNlCmlucHV0OiBncGlvLWtleXMgYXMgL2RldmljZXMvcGxhdGZvcm0v Z3Bpby1rZXlzL2lucHV0L2lucHV0MApzM2MyNDQwLXRzIHMzYzI0NDAtdHM6 IFN0YXJ0aW5nCiAgQ3JlYXRlZCBncm91cCB0cyBmaWx0ZXIgbGVuIDEyIGRl cHRoIDIgY2xvc2UgMTAgdGhyZXNoIDYKICBDcmVhdGVkIE1lZGlhbiB0cyBm aWx0ZXIgbGVuIDIwIGRlcHRoIDIgZGVjIDI0CiAgQ3JlYXRlZCBNZWFuIHRz IGZpbHRlciBsZW4gNCBkZXB0aCAyIHRocmVzaCA2NTUzNQogIENyZWF0ZWQg TGluZWFyIHRzIGZpbHRlciBkZXB0aCAyCnMzYzI0NDAtdHMgczNjMjQ0MC10 czogNCBmaWx0ZXIocykgaW5pdGlhbGl6ZWQKczNjMjQ0MC10cyBzM2MyNDQw LXRzOiBzdWNjZXNzZnVsbHkgbG9hZGVkCmlucHV0OiBzM2MyNDEwIFRvdWNo U2NyZWVuIGFzIC9kZXZpY2VzL3ZpcnR1YWwvaW5wdXQvaW5wdXQxClMzQzI0 WFggUlRDLCAoYykgMjAwNCwyMDA2IFNpbXRlYyBFbGVjdHJvbmljcwpzM2My NDEwLXJ0YyBzM2MyNDEwLXJ0YzogcnRjIGRpc2FibGVkLCByZS1lbmFibGlu ZwpzM2MyNDEwLXJ0YyBzM2MyNDEwLXJ0YzogcnRjIGNvcmU6IHJlZ2lzdGVy ZWQgczNjIGFzIHJ0YzAKaTJjIC9kZXYgZW50cmllcyBkcml2ZXIKUzNDMjQx MCBXYXRjaGRvZyBUaW1lciwgKGMpIDIwMDQgU2ltdGVjIEVsZWN0cm9uaWNz CnMzYzI0MTAtd2R0IHMzYzI0MTAtd2R0OiB3YXRjaGRvZyBpbmFjdGl2ZSwg cmVzZXQgZGlzYWJsZWQsIGlycSBlbmFibGVkCmNwdWlkbGU6IHVzaW5nIGdv dmVybm9yIGxhZGRlcgpzZGhjaTogU2VjdXJlIERpZ2l0YWwgSG9zdCBDb250 cm9sbGVyIEludGVyZmFjZSBkcml2ZXIKc2RoY2k6IENvcHlyaWdodChjKSBQ aWVycmUgT3NzbWFuCm1hcHBlZCBjaGFubmVsIDAgdG8gMApzM2MyNDQwLXNk aSBzM2MyNDQwLXNkaTogcG93ZXJlZCBkb3duLgpzM2MyNDQwLXNkaSBzM2My NDQwLXNkaTogaW5pdGlhbGlzYXRpb24gZG9uZS4KUmVnaXN0ZXJlZCBsZWQg ZGV2aWNlOiBsZWQxClJlZ2lzdGVyZWQgbGVkIGRldmljZTogbGVkMgpSZWdp c3RlcmVkIGxlZCBkZXZpY2U6IGxlZDMKUmVnaXN0ZXJlZCBsZWQgZGV2aWNl OiBsZWQ0ClJlZ2lzdGVyZWQgbGVkIGRldmljZTogYmFja2xpZ2h0CnVzYmNv cmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgaGlkZGV2CnVz YmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNiaGlk CnVzYmhpZDogdjIuNjpVU0IgSElEIGNvcmUgZHJpdmVyCkFkdmFuY2VkIExp bnV4IFNvdW5kIEFyY2hpdGVjdHVyZSBEcml2ZXIgVmVyc2lvbiAxLjAuMjAu Ck5vIGRldmljZSBmb3IgREFJIFVEQTEzNFgKTm8gZGV2aWNlIGZvciBEQUkg czNjMjR4eC1pMnMKUzNDMjRYWF9VREExMzRYIFNvQyBBdWRpbyBkcml2ZXIK VURBMTM0WCBTb0MgQXVkaW8gQ29kZWMKYXNvYzogVURBMTM0WCA8LT4gczNj MjR4eC1pMnMgbWFwcGluZyBvawpBTFNBIGRldmljZSBsaXN0OgogICMwOiBT M0MyNFhYX1VEQTEzNFggKFVEQTEzNFgpClRDUCBjdWJpYyByZWdpc3RlcmVk Ck5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTcKUlBDOiBSZWdp c3RlcmVkIHVkcCB0cmFuc3BvcnQgbW9kdWxlLgpSUEM6IFJlZ2lzdGVyZWQg dGNwIHRyYW5zcG9ydCBtb2R1bGUuCnMzYzI0MTAtcnRjIHMzYzI0MTAtcnRj OiBzZXR0aW5nIHN5c3RlbSBjbG9jayB0byAyMDA5LTA2LTI5IDAzOjQzOjA3 IFVUQyAoMTI0NjI0Njk4NykKamZmczJfc2Nhbl9lcmFzZWJsb2NrKCk6IE1h Z2ljIGJpdG1hc2sgMHgxOTg1IG5vdCBmb3VuZCBhdCAweDAzYTk4MzcwOiAw eGZmZmYgaW5zdGVhZApqZmZzMl9zY2FuX2VyYXNlYmxvY2soKTogTWFnaWMg Yml0bWFzayAweDE5ODUgbm90IGZvdW5kIGF0IDB4MDNhOWMzNzA6IDB4ZmZm ZiBpbnN0ZWFkCkNvd2FyZGx5IHJlZnVzaW5nIHRvIGVyYXNlIGJsb2NrcyBv biBmaWxlc3lzdGVtIHdpdGggbm8gdmFsaWQgSkZGUzIgbm9kZXMKZW1wdHlf YmxvY2tzIDM3NDksIGJhZF9ibG9ja3MgMSwgYy0+bnJfYmxvY2tzIDM3NTIK VkZTOiBDYW5ub3Qgb3BlbiByb290IGRldmljZSAibXRkYmxvY2szIiBvciB1 bmtub3duLWJsb2NrKDMxLDMpClBsZWFzZSBhcHBlbmQgYSBjb3JyZWN0ICJy b290PSIgYm9vdCBvcHRpb247IGhlcmUgYXJlIHRoZSBhdmFpbGFibGUgcGFy dGl0aW9uczoKMWYwMCAgICAgICAgICAgICAyNTYgbXRkYmxvY2swIChkcml2 ZXI/KQoxZjAxICAgICAgICAgICAgIDEyOCBtdGRibG9jazEgKGRyaXZlcj8p CjFmMDIgICAgICAgICAgICA1MTIwIG10ZGJsb2NrMiAoZHJpdmVyPykKMWYw MyAgICAgICAgICAgNjAwMzIgbXRkYmxvY2szIChkcml2ZXI/KQpLZXJuZWwg cGFuaWMgLSBub3Qgc3luY2luZzogVkZTOiBVbmFibGUgdG8gbW91bnQgcm9v dCBmcyBvbiB1bmtub3duLWJsb2NrKDMxLDMpCls8YzAwMmQ2NTA+XSAodW53 aW5kX2JhY2t0cmFjZSsweDAvMHhkOCkgZnJvbSBbPGMwMmJiZDFjPl0gKHBh bmljKzB4NDAvMHgxMTApCls8YzAyYmJkMWM+XSAocGFuaWMrMHg0MC8weDEx MCkgZnJvbSBbPGMwMDA4ZTE4Pl0gKG1vdW50X2Jsb2NrX3Jvb3QrMHgxYzgv MHgyMDgpCls8YzAwMDhlMTg+XSAobW91bnRfYmxvY2tfcm9vdCsweDFjOC8w eDIwOCkgZnJvbSBbPGMwMDA5MGFjPl0gKHByZXBhcmVfbmFtZXNwYWNlKzB4 MTYwLzB4MWI4KQpbPGMwMDA5MGFjPl0gKHByZXBhcmVfbmFtZXNwYWNlKzB4 MTYwLzB4MWI4KSBmcm9tIFs8YzAwMDgzZjQ+XSAoa2VybmVsX2luaXQrMHhi OC8weGU0KQpbPGMwMDA4M2Y0Pl0gKGtlcm5lbF9pbml0KzB4YjgvMHhlNCkg ZnJvbSBbPGMwMDNkMjAwPl0gKGRvX2V4aXQrMHgwLzB4NTg4KQpbPGMwMDNk MjAwPl0gKGRvX2V4aXQrMHgwLzB4NTg4KSBmcm9tIFs8YzM4MWEwMDA+XSAo MHhjMzgxYTAwMCkKfgpbRU9UXQpnYXRld2F5IyBeRAgIZXhpdAoKU2NyaXB0 IGRvbmUgb24gTW9uIEp1biAyOSAwMzo0ODoyMyAyMDA5Cg== --0-1871264675-1246261988=:90651-- From owner-freebsd-arm@FreeBSD.ORG Mon Jun 29 08:38:26 2009 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 8DEB61065672 for ; Mon, 29 Jun 2009 08:38:26 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [IPv6:2001:16d8:fffb:4::abba]) by mx1.freebsd.org (Postfix) with ESMTP id 465EC8FC15 for ; Mon, 29 Jun 2009 08:38:26 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from stasss.yandex.ru (dhcp170-227-red.yandex.net [95.108.170.227]) by mx0.deglitch.com (Postfix) with ESMTPSA id 6BE508FC27; Mon, 29 Jun 2009 12:38:24 +0400 (MSD) Date: Mon, 29 Jun 2009 12:38:15 +0400 From: Stanislav Sedov To: Donn Miller Message-Id: <20090629123815.c0c2ad11.stas@FreeBSD.org> In-Reply-To: <992872.90651.qm@web35703.mail.mud.yahoo.com> References: <992872.90651.qm@web35703.mail.mud.yahoo.com> Organization: The FreeBSD Project X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Mon__29_Jun_2009_12_38_15_+0400_iryKmoPvUg72+a+L" Cc: freebsd-arm@freebsd.org Subject: Re: Support for the Friendly Arm (mini 2440) development board 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, 29 Jun 2009 08:38:26 -0000 --Signature=_Mon__29_Jun_2009_12_38_15_+0400_iryKmoPvUg72+a+L Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 29 Jun 2009 00:53:08 -0700 (PDT) Donn Miller mentioned: > http://www.developmentboard.net/index.php/productdetail/Development+board= /ARM9/SAMSUNG/S3C2440/MINI2440+with+LCD/info/1 > http://www.friendlyarm.net/products/mini2440 > http://code.google.com/p/mini2440/ >=20 S3C24xx is not yet supported in FreeBSD. The current code for Samsung CPUs= are available in FreeBSD P4 repo but the ports is not complete yet. --=20 Stanislav Sedov ST4096-RIPE --Signature=_Mon__29_Jun_2009_12_38_15_+0400_iryKmoPvUg72+a+L Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJKSH2AAAoJEKN82nOYvCd0Mo4P/ROAk3GsmhdT0NKuQ/3Z3gLb XkSB6K45cMgqZiRMktMbS2FSC5SMTGeoDsD2+JbWYsGQ88QwBeYdnchfsowR4VIl l6PVXjZKD8yc11YxrHbzXuIfnWRV046wyMeoCfmX1Dib+mQtrHMxNSfVZvTQVjyq XCPigiK2TEE/+Q6cjpf6ogD06OjesGpNT/Epwjf9MYdIK/gAB/Z2VeH32aUuENli Dgp5UEqWfl9z9E80GyuGi7S95E9ADpLg8uJdFJx2Dk+Lw1ftfYOr7kskHk3Iz/el qc9ji2qapOKDM0BkwAqqYxd1XieWGu+Ig3NtBryEr58353BUGENFyM0yyMO8iOms WBhQZg8hzD9GI8ArNcnhYtAAMXP6ae4MTGMVjHsQx4XhFbPfHvuO7lcYjFVafB7q rkU7o3NuxfFO/S9A1cX45si9VlbaFIjko0l4x/a76riIERMDT8g4ifCxG1cxnIFc GnVUpwr8agnVWH+oQFkQuhhH3a5yCCLNEGQ67R5anDejrPdrgbh66qfnRTOaBBC5 mVv81NTHsDgLQykdkNgDbRCSxXKQIwFqyaTLWG+Gb8jKaj8KatppSJY7fmpmwh1T 9ozlqm+TNwH7ta2RnBMDmXYr+6o86w/FmdNmdWaCsUcP92UNHqI9A2J9SggWutcv E2WoFfOpRRBJLsvF5FvM =qY49 -----END PGP SIGNATURE----- --Signature=_Mon__29_Jun_2009_12_38_15_+0400_iryKmoPvUg72+a+L-- From owner-freebsd-arm@FreeBSD.ORG Mon Jun 29 09:29:42 2009 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 627D5106564A for ; Mon, 29 Jun 2009 09:29:42 +0000 (UTC) (envelope-from kosmo@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id C99098FC12 for ; Mon, 29 Jun 2009 09:29:41 +0000 (UTC) (envelope-from kosmo@semihalf.com) Received: from [10.0.0.5] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 7E74CC3BBC; Mon, 29 Jun 2009 11:10:02 +0200 (CEST) From: Piotr =?utf-8?q?Zi=C4=99cik?= Organization: Semihalf To: Hans Petter Selasky Date: Mon, 29 Jun 2009 11:11:20 +0200 User-Agent: PLD Linux KMail/1.9.10 References: <200906231035.43096.kosmo@semihalf.com> <200906231912.20741.hselasky@c2i.net> <200906281154.43392.hselasky@c2i.net> In-Reply-To: <200906281154.43392.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200906291111.20725.kosmo@semihalf.com> Cc: freebsd-arm@freebsd.org, freebsd-usb@freebsd.org, thompsa@freebsd.org Subject: Re: CPU Cache and busdma usage in USB 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, 29 Jun 2009 09:29:42 -0000 Sunday 28 June 2009 11:54:40 Hans Petter Selasky napisa=C5=82(a): > Hi Piotr and Rafal, > > Your patch is not fully correct. It will break support for x86 and more > when bounce pages are uses. > > Let's get the definitions right: > > man busdma > (...) > > My view: > > XXX_PREXXX functions should be used prior to read/write device access. > > In other words, PRE has to be a flush operation. > > XXX_POSTXXX functions should be used after read/write device access. > > In other words, POST has to be an invalidate operation. > > Reading: > > src/sys/arm/arm/busdma_machdep.c > > I find bus_dmamap_sync_buf() to be coherent with this view. If everything is OK, then why USB does not work on ARM and MIPS ? Let's look into busdma for these platforms: usb_pc_cpu_invalidate(): [BUS_DMASYNC_POSTREAD | BUS_DMASYNC_POSTWRITE] i386: NOP arm: Invalidate + hacks for VIPT cache. mips: NOP usb_pc_cpu_flush(): [BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE] i386: NOP arm: Writeback invalidate mips: Writeback invalidate. I do not see direct coherency between flags passed to bus_dma and cache=20 operations, which could be source of problem. Let's also look at usb_pc_cpu_invalidate() usage in=20 sys/dev/usb/controller/ehci.c: while (1) { usb_pc_cpu_invalidate(td->page_cache); status =3D hc32toh(sc, td->qtd_status); (...) if (status & EHCI_QTD_HALTED) { break; } (...) td =3D td->obj_next; In my oppinion usb_pc_cpu_invalidate() used here suggests that it is doing= =20 cache invalidation not "Perform any synchronization required after = =20 an update of host memory by the device and prior to CPU access to host=20 memory". As this function is implemented as bus_dmamap_sync() all busdma rules shoul= d=20 be applied: If read and write operations are not preceded and followed by the appropriate synchronization operations, behavior is undefined. In code shown above (and many more places in USB stack) there is no followi= ng synchronization operation, which also could be source of problem. My major question here is why bus_dma is used for flushing and invalidation CPU caches instead of cpu_*() functions wich was written for this purpuose. > Can you check if the COHERENT bit is set for your allocation? > > if (map->flags & DMAMAP_COHERENT) > return; > No. This bit is not set. > Summed up: > > The existing code is doing correct. What is known is a problem with the > memory mapping, so that the same memory page can get mapped with different > attributes, which makes the problem appear. I don't think so: $ man busdma BUS_DMA_COHERENT Attempt to map this memory such that cache sync operations are as cheap as possible. This flag is typically set on memory that will be accessed by b= oth a CPU and a DMA engine, frequently. Use of this flag does not remove the= =20 requirement of using bus_dmamap_sync, but it may reduce the cost of =09 performing these operations.=20 This means that BUS_DMA_COHERENT does not guarantee no-cache mapping - this= is only a hint for busdma subsystem that region will be synced frequently. Ple= ase=20 look at discussion at=20 http://kerneltrap.org/mailarchive/freebsd-current/2009/5/27/5817243 =2D-=20 Best regards. Piotr Ziecik From owner-freebsd-arm@FreeBSD.ORG Mon Jun 29 09:55:45 2009 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 8CD3E1065674; Mon, 29 Jun 2009 09:55:45 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by mx1.freebsd.org (Postfix) with ESMTP id 7C8DB8FC16; Mon, 29 Jun 2009 09:55:43 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=Hrwt8fWgTlIA:10 a=gg2W7PyvkLb8p4ie143lBA==:17 a=dT19lrtdAAAA:8 a=JB0F7hjHzw5RfXIn3lQA:9 a=awSKR1t7wlnHVe-XWeKBqYDR5Q4A:4 Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.selasky.org) by mailfe08.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1267858797; Mon, 29 Jun 2009 11:55:42 +0200 From: Hans Petter Selasky To: Piotr =?utf-8?q?Zi=C4=99cik?= Date: Mon, 29 Jun 2009 11:55:11 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-CURRENT; KDE/4.2.4; i386; ; ) References: <200906231035.43096.kosmo@semihalf.com> <200906281154.43392.hselasky@c2i.net> <200906291111.20725.kosmo@semihalf.com> In-Reply-To: <200906291111.20725.kosmo@semihalf.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200906291155.13941.hselasky@c2i.net> Cc: freebsd-arm@freebsd.org, freebsd-usb@freebsd.org, thompsa@freebsd.org Subject: Re: CPU Cache and busdma usage in USB 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, 29 Jun 2009 09:55:46 -0000 Hi Piotr and Rafal, On Monday 29 June 2009 11:11:20 Piotr Zi=C4=99cik wrote: > Sunday 28 June 2009 11:54:40 Hans Petter Selasky napisa=C5=82(a): > > Hi Piotr and Rafal, > > > > Your patch is not fully correct. It will break support for x86 and more > > when bounce pages are uses. > > > > Let's get the definitions right: > > > > man busdma > > (...) > > > > My view: > > > > XXX_PREXXX functions should be used prior to read/write device access. > > > > In other words, PRE has to be a flush operation. > > > > XXX_POSTXXX functions should be used after read/write device access. > > > > In other words, POST has to be an invalidate operation. > > > > Reading: > > > > src/sys/arm/arm/busdma_machdep.c > > > > I find bus_dmamap_sync_buf() to be coherent with this view. > > If everything is OK, then why USB does not work on ARM and MIPS ? I'm not saying everything is OK, I just don't agree that the problem is in= =20 USB. If you look at: http://fxr.watson.org/fxr/source/i386/i386/busdma_machdep.c#L931 Then you see the XXX_PREXXX means copy from client buffer (bpage->datavaddr= )=20 to real DMA buffer (bpage->vaddr). That means flush memory from cache to RA= M.=20 You want to change it into a XXX_POSTXXX (???) in the USB code, and that wo= n't=20 work for x86 and amd64 ... Then you also see that XXX_POSTXXX is doing the opposite, cleaning the cach= e=20 and copying from RAM into the "cache" buffer. > Let's look into busdma for these platforms: > > usb_pc_cpu_invalidate(): [BUS_DMASYNC_POSTREAD | BUS_DMASYNC_POSTWRITE] > i386: NOP > arm: Invalidate + hacks for VIPT cache. > mips: NOP Isn't this correct cleaning the cache on ARM? > > usb_pc_cpu_flush(): [BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE] > i386: NOP > arm: Writeback invalidate > mips: Writeback invalidate. Isn't this correct flushing the cache to RAM on ARM? > > I do not see direct coherency between flags passed to bus_dma and cache > operations, which could be source of problem. Can you explain a little bit more what you see is not coherent? > > Let's also look at usb_pc_cpu_invalidate() usage in > sys/dev/usb/controller/ehci.c: > > while (1) { > usb_pc_cpu_invalidate(td->page_cache); > status =3D hc32toh(sc, td->qtd_status); > > (...) > > if (status & EHCI_QTD_HALTED) { > break; > } > > (...) > > td =3D td->obj_next; > > > In my oppinion usb_pc_cpu_invalidate() used here suggests that it is doing > cache invalidation not "Perform any synchronization required after > an update of host memory by the device and prior to CPU access to host > memory". The invalidate means: Clean the cache, so that the succeeding read fetches = its=20 value from RAM. > > As this function is implemented as bus_dmamap_sync() all busdma rules > should be applied: > > If read and write operations are not preceded and followed by the > appropriate synchronization operations, behavior is undefined. > > > In code shown above (and many more places in USB stack) there is no > following synchronization operation, which also could be source of proble= m. All cases where transfer descriptors are updated are wrapped with bus-sync= =20 operations, through the "usb_pc_cpu_xxx()" functions. Else mutexes are used= =2E=20 Please give an example of such a place where improper synchronisation happe= ns. > > My major question here is why bus_dma is used for flushing and invalidati= on > CPU caches instead of cpu_*() functions wich was written for this purpuos= e. Because that is what other drivers are doing. I think using cpu_*() is more= =20 alike Linux, and also, if the memory is on a bounce page, cpu_*() will yiel= d=20 the wrong result. > > Can you check if the COHERENT bit is set for your allocation? > > > > if (map->flags & DMAMAP_COHERENT) > > return; > > No. This bit is not set. > > > Summed up: > > > > The existing code is doing correct. What is known is a problem with the > > memory mapping, so that the same memory page can get mapped with > > different attributes, which makes the problem appear. > =2D-HPS From owner-freebsd-arm@FreeBSD.ORG Mon Jun 29 10:49:45 2009 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 AB050106564A; Mon, 29 Jun 2009 10:49:45 +0000 (UTC) (envelope-from kosmo@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 184568FC0A; Mon, 29 Jun 2009 10:49:44 +0000 (UTC) (envelope-from kosmo@semihalf.com) Received: from [10.0.0.5] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 9A893C3BB0; Mon, 29 Jun 2009 12:48:25 +0200 (CEST) From: Piotr =?utf-8?q?Zi=C4=99cik?= Organization: Semihalf To: Hans Petter Selasky Date: Mon, 29 Jun 2009 12:49:43 +0200 User-Agent: PLD Linux KMail/1.9.10 References: <200906231035.43096.kosmo@semihalf.com> <200906291111.20725.kosmo@semihalf.com> <200906291155.13941.hselasky@c2i.net> In-Reply-To: <200906291155.13941.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200906291249.43983.kosmo@semihalf.com> Cc: freebsd-arm@freebsd.org, freebsd-usb@freebsd.org, thompsa@freebsd.org Subject: Re: CPU Cache and busdma usage in USB 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, 29 Jun 2009 10:49:46 -0000 Monday 29 June 2009 11:55:11 Hans Petter Selasky napisa=C5=82(a): > Hi Piotr and Rafal, > > I'm not saying everything is OK, I just don't agree that the problem is in > USB. > > If you look at: > > http://fxr.watson.org/fxr/source/i386/i386/busdma_machdep.c#L931 > > Then you see the XXX_PREXXX means copy from client buffer > (bpage->datavaddr) to real DMA buffer (bpage->vaddr). That means flush > memory from cache to RAM. You want to change it into a XXX_POSTXXX (???) = in > the USB code, and that won't work for x86 and amd64 ... > > Then you also see that XXX_POSTXXX is doing the opposite, cleaning the > cache and copying from RAM into the "cache" buffer. > > Isn't this correct flushing the cache to RAM on ARM? > It is correct if you use busdma in correct way: [... prepare data to transfer ...] bus_dmamap_sync(..., PREREAD | PREWRITE); [... do transfer ...] bus_dmamap_sync(..., POSTREAD | POSTWRITE); [... check results ...] > > I do not see direct coherency between flags passed to bus_dma and cache > > operations, which could be source of problem. > > Can you explain a little bit more what you see is not coherent? I thought about direct relation between calling bus_dmamap_sync() with given flag and cache operation. usb_pc_cpu_invalidate() not always is doing invalidate and usb_pc_cpu_flush() not always is doing flush. > > In my oppinion usb_pc_cpu_invalidate() used here suggests that it is > > doing cache invalidation not "Perform any synchronization required after > > an update of host memory by the device and prior to CPU access to host > > memory". > > The invalidate means: Clean the cache, so that the succeeding read fetches > its value from RAM. But usb_pc_cpu_invalidate(), which should do cache invalidate, doing NOP or other operations depending on architecture bus_dma implementation.=20 Therefore these functions should not be used for enforcing cache operations. > > As this function is implemented as bus_dmamap_sync() all busdma rules > > should be applied: > > > > If read and write operations are not preceded and followed by the > > appropriate synchronization operations, behavior is undefined. > > > > > > In code shown above (and many more places in USB stack) there is no > > following synchronization operation, which also could be source of > > problem. > > All cases where transfer descriptors are updated are wrapped with bus-sync > operations, through the "usb_pc_cpu_xxx()" functions. Else mutexes are > used. Please give an example of such a place where improper synchronisati= on > happens. Look into ehci_check_transfer() function=20 (http://fxr.watson.org/fxr/source/dev/usb/controller/ehci.c#L1294)=20 usb_pc_cpu_invalidate() [bus_dmamap_sync()] is not used in this function=20 correcly. It is not paired with usb_pc_cpu_flush() [opposite=20 bus_dmamap_sync()] as busdma requires (see part of manpage cited above). The same problem is in part of code shown in previous mail. If usb_pc_cpu_invalidate()/usb_pc_cpu_flush() functions had been implemente= d=20 without using busdma, for example as cpu_*() functions, ehci_check_transfer= ()=20 would have been 100% correct. In current code busdma requirements are simpl= y=20 not met. > > My major question here is why bus_dma is used for flushing and > > invalidation CPU caches instead of cpu_*() functions wich was written f= or > > this purpuose. > > Because that is what other drivers are doing. I think using cpu_*() is mo= re > alike Linux, and also, if the memory is on a bounce page, cpu_*() will > yield the wrong result. Ok. So if you use bus_dma(), please use it in correct way. =2D-=20 Best Regards. Piotr Ziecik From owner-freebsd-arm@FreeBSD.ORG Mon Jun 29 10:55:40 2009 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 9553A10656FE for ; Mon, 29 Jun 2009 10:55:40 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from farnsworth.fubar.geek.nz (farnsworth.fubar.geek.nz [69.55.236.47]) by mx1.freebsd.org (Postfix) with ESMTP id 79C9A8FC20 for ; Mon, 29 Jun 2009 10:55:40 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: by farnsworth.fubar.geek.nz (Postfix, from userid 65534) id 3B32A33C7C; Mon, 29 Jun 2009 03:37:46 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on farnsworth.fubar.geek.nz X-Spam-Level: * X-Spam-Status: No, score=1.5 required=5.0 tests=AWL,BAYES_00,HELO_LOCALHOST, RCVD_IN_PBL,RDNS_DYNAMIC autolearn=no version=3.2.5 Received: from localhost (125-238-22-134.broadband-telecom.global-gateway.net.nz [125.238.22.134]) by farnsworth.fubar.geek.nz (Postfix) with ESMTP id E271233C1A; Mon, 29 Jun 2009 03:37:43 -0700 (PDT) Date: Mon, 29 Jun 2009 22:37:44 +1200 From: Andrew Turner To: Donn Miller Message-ID: <20090629223744.14ff27b3@fubar.geek.nz> In-Reply-To: <992872.90651.qm@web35703.mail.mud.yahoo.com> References: <992872.90651.qm@web35703.mail.mud.yahoo.com> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; amd64-portbld-freebsd7.1) X-Pirate: Arrrr Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: Support for the Friendly Arm (mini 2440) development board 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, 29 Jun 2009 10:55:41 -0000 On Mon, 29 Jun 2009 00:53:08 -0700 (PDT) Donn Miller wrote: > I also attached the output from the serial console, showing an > attempt to boot a Linux arm kernel. Note that mounting root was > unsuccessful (didn't install a small embedded distribution yet). > > I figured this dmesg, though from Linux, will suffice to sufficiently > describe what this device is and if I can boot FreeBSD-arm on it. I have run FreeBSD on a mini2440 board before. Support for it is still in development as I've been working on support for NAND flash. Unfortunately the kernel appears to not boot anymore due to an alignment fault early on in the boot process. Andrew From owner-freebsd-arm@FreeBSD.ORG Mon Jun 29 10:56:17 2009 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 9B35410656C1 for ; Mon, 29 Jun 2009 10:56:17 +0000 (UTC) (envelope-from hackr_d@yahoo.com) Received: from web35704.mail.mud.yahoo.com (web35704.mail.mud.yahoo.com [66.163.179.158]) by mx1.freebsd.org (Postfix) with SMTP id 59E5F8FC15 for ; Mon, 29 Jun 2009 10:56:17 +0000 (UTC) (envelope-from hackr_d@yahoo.com) Received: (qmail 76284 invoked by uid 60001); 29 Jun 2009 10:56:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1246272976; bh=rtoDJyQultWHvrSZJCtphCimL37OOjGNzC9WQkJ1GiY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=4pJfNnYHhNpnfAsxNYnfB12uTgIFjkdyJJResZf8GotcPQkydd+c5WVdrUQ48Ggn0aqne7RiyKAP86m/jzsY1EKInLrvNiNLo4rU4HhJhg/98V1zaAaF0eL37FDmGMSfDg2obRrBOocO/ck3NyfuBtd46r0r51KEQcUjmK/0x5Y= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=wAkulasPTEfWt1UW1QrhWRksU46qXq0IIniexiL9OtaoeRXBBGxfVw/P/llUq6djpvLv/m0QUk0LQWzOiRhrY3Mz/A5hxNrj4Cz2LApzma61tc5QavNoPJCiChc46sqhAor3v9AzdxdIUKYgTyJ+f2ytlHlP6ouTn9VmnXIonhU=; Message-ID: <793595.43066.qm@web35704.mail.mud.yahoo.com> X-YMail-OSG: X.V7_sEVM1mgHLABtvKkC16Y6UqaReBkOlyJv94tp_KzMA1L6KqVfxy5jong8dAAFmCQwd5PEwtkVLrbvNG6SdzR_sJvWK6LAEfnybbV1ud2FqzDTREXAhxohXLHjFwBq8rCTAw3UV7bvYD1_KcpiL2xbEjimGB62AE0Iadf6tE2SED1QK5LYMiL_ZOFJxnfNOIQydSfD5Pf4bYkoqXXxfNzNM0O4TZFbt_UVGT61xMt.kaxcF4hmwbtSiIKnS38wZb1TD2kcxqldswxRpKQuxyNUqwWCf2cMzeLFqQRflij9enbMJPsUIQ59UzpXPjo4UFmtiUJx4c5wHgmae9Bi4RrQ_h64PcEgw-- Received: from [24.239.50.161] by web35704.mail.mud.yahoo.com via HTTP; Mon, 29 Jun 2009 03:56:16 PDT X-Mailer: YahooMailClassic/5.4.17 YahooMailWebService/0.7.289.15 Date: Mon, 29 Jun 2009 03:56:16 -0700 (PDT) From: Donn Miller To: Andrew Turner MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arm@freebsd.org Subject: Re: Support for the Friendly Arm (mini 2440) development board 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, 29 Jun 2009 10:56:18 -0000 =0A=0A--- On Mon, 6/29/09, Andrew Turner wrote:=0A= =0A> From: Andrew Turner =0A> Subject: Re: Support fo= r the Friendly Arm (mini 2440) development board=0A> To: "Donn Miller" =0A> Cc: freebsd-arm@freebsd.org=0A> Date: Monday, June 29, = 2009, 6:37 AM=0A> On Mon, 29 Jun 2009 00:53:08 -0700=0A> (PDT)=0A> Donn Mil= ler =0A> wrote:=0A> > I also attached the output from th= e serial console,=0A> showing an=0A> > attempt to boot a Linux arm kernel.= =A0 Note that=0A> mounting root was=0A> > unsuccessful (didn't install a sm= all embedded=0A> distribution yet).=0A> > =0A> > I figured this dmesg, thou= gh from Linux, will suffice=0A> to sufficiently=0A> > describe what this de= vice is and if I can boot=0A> FreeBSD-arm on it.=0A> I have run FreeBSD on = a mini2440 board before. Support for=0A> it is still=0A> in development as = I've been working on support for NAND=0A> flash.=0A> =0A> Unfortunately the= kernel appears to not boot anymore due to=0A> an alignment fault early on = in the boot process.=0A=0AWere you able to get it to boot FreeBSD from a sm= artmedia card? That would be another area that possibly needs working on a= s well.=0A=0A=0A From owner-freebsd-arm@FreeBSD.ORG Mon Jun 29 11:06:54 2009 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 CC9D3106566C for ; Mon, 29 Jun 2009 11:06:54 +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 B9E338FC1D for ; Mon, 29 Jun 2009 11:06:54 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n5TB6sQq046256 for ; Mon, 29 Jun 2009 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n5TB6sHm046252 for freebsd-arm@FreeBSD.org; Mon, 29 Jun 2009 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 29 Jun 2009 11:06:54 GMT Message-Id: <200906291106.n5TB6sHm046252@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, 29 Jun 2009 11:06:55 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 o arm/134338 arm [patch] Lock GPIO accesses on ixp425 o arm/134092 arm [patch] NSLU.hints contains wrong hints for on board n 3 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Jun 29 11:38:24 2009 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 A17AB1065670; Mon, 29 Jun 2009 11:38:24 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe09.swipnet.se [212.247.155.1]) by mx1.freebsd.org (Postfix) with ESMTP id 965498FC1D; Mon, 29 Jun 2009 11:38:23 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=Hrwt8fWgTlIA:10 a=gg2W7PyvkLb8p4ie143lBA==:17 a=dT19lrtdAAAA:8 a=tPo35w6jI4Rau6MQO3MA:9 a=mkklXvtNmbOxkHJfpxbL30FRJesA:4 a=S1CdNgxGSc7KuUU9:21 a=mYAzaKh1ZkpupjlU:21 Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe09.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 923352543; Mon, 29 Jun 2009 13:38:11 +0200 From: Hans Petter Selasky To: Piotr =?utf-8?q?Zi=C4=99cik?= Date: Mon, 29 Jun 2009 13:37:41 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-CURRENT; KDE/4.2.4; i386; ; ) References: <200906231035.43096.kosmo@semihalf.com> <200906291155.13941.hselasky@c2i.net> <200906291249.43983.kosmo@semihalf.com> In-Reply-To: <200906291249.43983.kosmo@semihalf.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200906291337.43635.hselasky@c2i.net> Cc: freebsd-arm@freebsd.org, freebsd-usb@freebsd.org, thompsa@freebsd.org Subject: Re: CPU Cache and busdma usage in USB 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, 29 Jun 2009 11:38:25 -0000 Hi, On Monday 29 June 2009 12:49:43 Piotr Zi=C4=99cik wrote: > Monday 29 June 2009 11:55:11 Hans Petter Selasky napisa=C5=82(a): > > Hi Piotr and Rafal, > > Look into ehci_check_transfer() function > (http://fxr.watson.org/fxr/source/dev/usb/controller/ehci.c#L1294) > > usb_pc_cpu_invalidate() [bus_dmamap_sync()] is not used in this function > correcly. It is not paired with usb_pc_cpu_flush() [opposite > bus_dmamap_sync()] as busdma requires (see part of manpage cited above). > The same problem is in part of code shown in previous mail. > > If usb_pc_cpu_invalidate()/usb_pc_cpu_flush() functions had been > implemented without using busdma, for example as cpu_*() functions, > ehci_check_transfer() would have been 100% correct. In current code busdma > requirements are simply not met. Good point. Unfortunately I cannot pair like you suggest, because then I ca= n=20 overwrite values updated by the hardware, if I first read the status for=20 example, and the same 32-bits are updated by hardware, before the old value= is=20 flushed over the new one.. Also I cannot find the word "pair" in the busdma= =20 manpage? Where is this requirement stated? I see some things: You wrote earlier that the COHERENT flag was not set. That means your setup= is=20 using bounce pages for DMA? Right? Then I see a problem, if I do several POST operations in a row then I can s= ee=20 that the real DMA memory can get cached: In: "src/sys/arm/arm/busdma_machdep.c" Is "vaddr_nocache" set or cleared? if (op & BUS_DMASYNC_POSTREAD) { if (bpage->vaddr_nocache =3D=3D 0) { cpu_dcache_inv_range(bpage->vaddr, bpage->datacount); cpu_l2cache_inv_range(bpage->vaddr, bpage->datacount); } bcopy((void *)(bpage->vaddr_nocache !=3D 0 ?=20 bpage->vaddr_nocache : bpage->vaddr), (void *)bpage->datavaddr, bpage->datacount); dmat->bounce_zone->total_bounced++; } USB is currently _updating_ (!!) the PAGE offset part of "vaddr". If=20 cpu_dcache_inv_range() is called with an address not starting at the cache= =20 line what will the cpu_dcache_inv_range() do? Will it skip to the next cach= e=20 line? Or will it completely skip the whole cache sync operation?! In the=20 function just above in the file I refer to, "bus_dmamap_sync_buf()", there = is=20 quite some more code to handle invalidation when the destination address is= =20 not properly aligned. I'm not an ARM expert. Maybe you can do an experiment= =20 for me: Change: bpage->vaddr into (bpage->vaddr & ~arm_dcache_align_mask) Change: bpage->datacount into (bpage->datacount + (bpage->vaddr &=20 arm_dcache_align_mask) + arm_dcache_align_mask - 1) & ~arm_dcache_align_mas= k; You don't need any memcpy there, because we own the complete memory page wh= ich=20 vaddr is a part of! > > Ok. So if you use bus_dma(), please use it in correct way. What has to be changed in busdma_machdep.c for ARM/MIPS so that the problem= is=20 resolved. I think there are something missing there and not in USB! =2D-HPS From owner-freebsd-arm@FreeBSD.ORG Mon Jun 29 12:10:18 2009 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 396481065688; Mon, 29 Jun 2009 12:10:18 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [IPv6:2001:16d8:fffb:4::abba]) by mx1.freebsd.org (Postfix) with ESMTP id E1FF18FC12; Mon, 29 Jun 2009 12:10:17 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from stasss.yandex.ru (dhcp170-227-red.yandex.net [95.108.170.227]) by mx0.deglitch.com (Postfix) with ESMTPSA id 05FD08FC27; Mon, 29 Jun 2009 16:10:15 +0400 (MSD) Date: Mon, 29 Jun 2009 16:10:11 +0400 From: Stanislav Sedov To: Hans Petter Selasky Message-Id: <20090629161011.2a657c4b.stas@FreeBSD.org> In-Reply-To: <200906291337.43635.hselasky@c2i.net> References: <200906231035.43096.kosmo@semihalf.com> <200906291155.13941.hselasky@c2i.net> <200906291249.43983.kosmo@semihalf.com> <200906291337.43635.hselasky@c2i.net> Organization: The FreeBSD Project X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Mon__29_Jun_2009_16_10_11_+0400_48N+oT7pWf4xkbzs" Cc: thompsa@freebsd.org, freebsd-arm@freebsd.org, Piotr =?UTF-8?Q?Zi=C4=99cik?= , freebsd-usb@freebsd.org Subject: Re: CPU Cache and busdma usage in USB 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, 29 Jun 2009 12:10:20 -0000 --Signature=_Mon__29_Jun_2009_16_10_11_+0400_48N+oT7pWf4xkbzs Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 29 Jun 2009 13:37:41 +0200 Hans Petter Selasky mentioned: > USB is currently _updating_ (!!) the PAGE offset part of "vaddr". If=20 > cpu_dcache_inv_range() is called with an address not starting at the cach= e=20 > line what will the cpu_dcache_inv_range() do? Will it skip to the next ca= che=20 > line? Or will it completely skip the whole cache sync operation?! Currently, the address passed to cpu_dcache_inv_range will be rounded up to the cache line boundary and the whole line will be invalidated if the range requested is smaller than 16KiB. Otherwise, the whole cache will be invalidated. --=20 Stanislav Sedov ST4096-RIPE --Signature=_Mon__29_Jun_2009_16_10_11_+0400_48N+oT7pWf4xkbzs Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJKSK8nAAoJEKN82nOYvCd08GUP/1Ns07uawfewf/D2UJmxk/uQ stbi+jJj87OAIw04ynXI+JAnUzj/wo3IWhjuD+cfcXUZBL6pFXidsVwG4qFaA4+X iHKOgoD9g6JDa2OfuBSYzVmfNexEPf6wT3ZzgBNJwmUx+zPugvp1T0O4RSi5fFOp asUiNwB+QNnpdIJQop3Spqd+edzr5NUow9EWmil0L3zLDZTUYCs3G367r7goI3of b6fnywftDRPMmRglyS5fCzXqzOe5ZKMEAool8gM3Pyfah4XfR0iqUAcc9p2zGkbE K1wxUrRGzbR5w0nzwoBBRcvmCryM8KSto81AJpl+9RvviNF8+CHBvuV1Nxnd4L0Z UtRRxdC2lzLbe4IjEgeJrMX0lhfkajGI0cgmiFXXnwF1SduTporgFzrTZbZXS6Bb aS33oMFRph7dfJZP/0Q/ytwmFwNwWcsyTkmJ0CMES2GcQpAfwT+jhQaLGe+TThKF XkRjz8X/DEsg60TL4eWZpPqgi/1DweiWll2K1kPVC1dZ6runNZMHk1WOMHPKXc3q E9eeG5diuojnOYHhVaA+oHV+Ve/e+cYWiTEC+fSGskuJmxnAJD7IVITnEveS/Gs3 VIa03BTtwOmnKE3Xvq9BORMrs5XDZ5AGuHFnI25wh5yh0imA/QM6n3vwbXiTBbtA 83IXMTJQAfx7s/AcJaNO =+46g -----END PGP SIGNATURE----- --Signature=_Mon__29_Jun_2009_16_10_11_+0400_48N+oT7pWf4xkbzs-- From owner-freebsd-arm@FreeBSD.ORG Mon Jun 29 12:15:16 2009 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 7EA0C1065670; Mon, 29 Jun 2009 12:15:16 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id 9B8468FC13; Mon, 29 Jun 2009 12:15:15 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=Hrwt8fWgTlIA:10 a=gg2W7PyvkLb8p4ie143lBA==:17 a=8kQB0OdkAAAA:8 a=pR-ycQP4qUUy1Qk1604A:9 a=skV1t3KLyfofAv-qceHNzmgbqzoA:4 a=9aOQ2cSd83gA:10 a=ZZKWQUrvU8IimEav:21 a=GRKjM2PgJTOlfXSK:21 Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1265768735; Mon, 29 Jun 2009 14:15:13 +0200 From: Hans Petter Selasky To: Stanislav Sedov Date: Mon, 29 Jun 2009 14:14:45 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-CURRENT; KDE/4.2.4; i386; ; ) References: <200906231035.43096.kosmo@semihalf.com> <200906291337.43635.hselasky@c2i.net> <20090629161011.2a657c4b.stas@FreeBSD.org> In-Reply-To: <20090629161011.2a657c4b.stas@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906291414.46341.hselasky@c2i.net> Cc: thompsa@freebsd.org, freebsd-arm@freebsd.org, Piotr =?utf-8?q?Zi=C4=99cik?= , freebsd-usb@freebsd.org Subject: Re: CPU Cache and busdma usage in USB 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, 29 Jun 2009 12:15:16 -0000 On Monday 29 June 2009 14:10:11 Stanislav Sedov wrote: > On Mon, 29 Jun 2009 13:37:41 +0200 > > Hans Petter Selasky mentioned: > > USB is currently _updating_ (!!) the PAGE offset part of "vaddr". If > > cpu_dcache_inv_range() is called with an address not starting at the > > cache line what will the cpu_dcache_inv_range() do? Will it skip to the > > next cache line? Or will it completely skip the whole cache sync > > operation?! > > Currently, the address passed to cpu_dcache_inv_range will be rounded up > to the cache line boundary and the whole line will be invalidated if the > range requested is smaller than 16KiB. Otherwise, the whole cache will > be invalidated. That maybe explains it, because USB will require rounding down the address and rounding up the length accordingly, because it uses the "BUS_DMA_KEEP_PG_OFFSET" flag. --HPS From owner-freebsd-arm@FreeBSD.ORG Mon Jun 29 12:16:14 2009 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 ADE451065672; Mon, 29 Jun 2009 12:16:14 +0000 (UTC) (envelope-from kosmo@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 5A3498FC12; Mon, 29 Jun 2009 12:16:14 +0000 (UTC) (envelope-from kosmo@semihalf.com) Received: from [10.0.0.5] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id EAA65C3A96; Mon, 29 Jun 2009 14:14:54 +0200 (CEST) From: Piotr =?utf-8?q?Zi=C4=99cik?= Organization: Semihalf To: Hans Petter Selasky Date: Mon, 29 Jun 2009 14:16:13 +0200 User-Agent: PLD Linux KMail/1.9.10 References: <200906231035.43096.kosmo@semihalf.com> <200906291249.43983.kosmo@semihalf.com> <200906291337.43635.hselasky@c2i.net> In-Reply-To: <200906291337.43635.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200906291416.13749.kosmo@semihalf.com> Cc: freebsd-arm@freebsd.org, freebsd-usb@freebsd.org, thompsa@freebsd.org Subject: Re: CPU Cache and busdma usage in USB 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, 29 Jun 2009 12:16:15 -0000 Monday 29 June 2009 13:37:41 Hans Petter Selasky napisa=C5=82(a): > > Look into ehci_check_transfer() function > > (http://fxr.watson.org/fxr/source/dev/usb/controller/ehci.c#L1294) > > > > usb_pc_cpu_invalidate() [bus_dmamap_sync()] is not used in this function > > correcly. It is not paired with usb_pc_cpu_flush() [opposite > > bus_dmamap_sync()] as busdma requires (see part of manpage cited above). > > The same problem is in part of code shown in previous mail. > > > > If usb_pc_cpu_invalidate()/usb_pc_cpu_flush() functions had been > > implemented without using busdma, for example as cpu_*() functions, > > ehci_check_transfer() would have been 100% correct. In current code > > busdma requirements are simply not met. > > Good point. Unfortunately I cannot pair like you suggest, because then I > can overwrite values updated by the hardware, if I first read the status > for example, and the same 32-bits are updated by hardware, before the old > value is flushed over the new one.. Also I cannot find the word "pair" in > the busdma manpage? Where is this requirement stated? Look for bus_dmamap_sync() sync description, last sentence: If read and write operations are not preceded and followed by the appropriate synchronization operations, behavior is undefined. > I see some things: > > You wrote earlier that the COHERENT flag was not set. That means your set= up > is using bounce pages for DMA? Right? No. On ARM BUS_DMA_COHERENT flag enforces no-cache page mapping. This is performance killer and should be avoided. In addition space for=20 uncached mappings is also limted. Bounce pages are used if busdma subsystem is not able to directly met=20 alignment constrains specified in dma tag. In this case, a bounce page is=20 allocated and data is copied (!) to the bounce page. Busdma returns physica= l=20 address of bounce page which mets constraints specified in the dma tag. When sync operation is preformed and given mapping uses bounce pages, data is copied between the bounce pages and original location. All cache operations are performed on bounce pages. =2D-=20 Best Regards. Piotr Ziecik From owner-freebsd-arm@FreeBSD.ORG Mon Jun 29 13:07:33 2009 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 10A45106566C; Mon, 29 Jun 2009 13:07:33 +0000 (UTC) (envelope-from kosmo@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id B728C8FC12; Mon, 29 Jun 2009 13:07:32 +0000 (UTC) (envelope-from kosmo@semihalf.com) Received: from [10.0.0.5] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id E59C0C3A96; Mon, 29 Jun 2009 15:06:12 +0200 (CEST) From: Piotr =?utf-8?q?Zi=C4=99cik?= Organization: Semihalf To: Hans Petter Selasky Date: Mon, 29 Jun 2009 15:07:31 +0200 User-Agent: PLD Linux KMail/1.9.10 References: <200906231035.43096.kosmo@semihalf.com> <200906291249.43983.kosmo@semihalf.com> <200906291337.43635.hselasky@c2i.net> In-Reply-To: <200906291337.43635.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200906291507.31594.kosmo@semihalf.com> Cc: freebsd-arm@freebsd.org, freebsd-usb@freebsd.org, thompsa@freebsd.org Subject: Re: CPU Cache and busdma usage in USB 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, 29 Jun 2009 13:07:33 -0000 Monday 29 June 2009 13:37:41 Hans Petter Selasky napisa=C5=82(a): > if (op & BUS_DMASYNC_POSTREAD) { > if (bpage->vaddr_nocache =3D=3D 0) { > cpu_dcache_inv_range(bpage->vaddr, > bpage->datacount); > cpu_l2cache_inv_range(bpage->vaddr, > bpage->datacount); > } > bcopy((void *)(bpage->vaddr_nocache !=3D 0 ? > bpage->vaddr_nocache : bpage->vaddr), > (void *)bpage->datavaddr, bpage->datacount); > dmat->bounce_zone->total_bounced++; > } > > Change: bpage->vaddr into (bpage->vaddr & ~arm_dcache_align_mask) > Change: bpage->datacount into (bpage->datacount + (bpage->vaddr & > arm_dcache_align_mask) + arm_dcache_align_mask - 1) & > ~arm_dcache_align_mask; I have checked above changes and I do not observe any changes is USB behaviour. Problem still exists. =2D-=20 Best Regards. Piotr Ziecik From owner-freebsd-arm@FreeBSD.ORG Mon Jun 29 13:17:29 2009 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 100851065672; Mon, 29 Jun 2009 13:17:29 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe10.swipnet.se [212.247.155.33]) by mx1.freebsd.org (Postfix) with ESMTP id 054D58FC1B; Mon, 29 Jun 2009 13:17:27 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=Hrwt8fWgTlIA:10 a=gg2W7PyvkLb8p4ie143lBA==:17 a=Mm9x50jhgXV4_Hr8jdcA:9 a=oA1dRUiy9LCzW5VhFsIA:7 a=Uf1fOaIE_9Flh2HDhU2pLKyBf9gA:4 Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe10.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1098585684; Mon, 29 Jun 2009 15:17:26 +0200 From: Hans Petter Selasky To: Piotr =?iso-8859-2?q?Zi=EAcik?= , freebsd-arm@freebsd.org Date: Mon, 29 Jun 2009 15:16:56 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-CURRENT; KDE/4.2.4; i386; ; ) References: <200906231035.43096.kosmo@semihalf.com> In-Reply-To: <200906231035.43096.kosmo@semihalf.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200906291516.58725.hselasky@c2i.net> Cc: thompsa@freebsd.org, freebsd-usb@freebsd.org Subject: Re: CPU Cache and busdma usage in USB 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, 29 Jun 2009 13:17:29 -0000 On Tuesday 23 June 2009 10:35:42 Piotr Zi=EAcik wrote: > --- a/sys/dev/usb/usb_busdma.c > +++ b/sys/dev/usb/usb_busdma.c > @@ -658,8 +658,7 @@ usb_pc_cpu_invalidate(struct usb_page_cache *pc) > /* nothing has been loaded into this page cache! */ > return; > } > - bus_dmamap_sync(pc->tag, pc->map, > - BUS_DMASYNC_POSTWRITE | BUS_DMASYNC_POSTREAD); > + bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREREAD); > } > > /*----------------------------------------------------------------------= =2D- >* @@ -672,8 +671,7 @@ usb_pc_cpu_flush(struct usb_page_cache *pc) > /* nothing has been loaded into this page cache! */ > return; > } > - bus_dmamap_sync(pc->tag, pc->map, > - BUS_DMASYNC_PREWRITE | BUS_DMASYNC_PREREAD); > + bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREWRITE); > } Hi, Let's restart the discussion with the initial patch. You want to change the flags passed to bus_dmamap_sync() so that the=20 flush/invalidate mapping gets right. I understand why your patch makes it=20 work. That's not the problem. In "src/sys/arm/arm/busdma_machdep.c" there is a function called=20 "_bus_dmamap_sync_bp()". If you look at that function you see that it only= =20 triggers on the "BUS_DMASYNC_PREWRITE" and "BUS_DMASYNC_POSTREAD" flags. Af= ter=20 your patching only the PREXXXX flags are used, so if bouce pages are used o= n=20 ARM and x86 and amd64 +++, then only BUS_DMASYNC_PREWRITE will do anything.= =20 This indicates that your patch is not fully correct. Grepping through the source code for ARM, I found a line like this: /*XXX*/ arm9_dcache_wbinv_range, /* dcache_inv_range */ which is not correct. If we are only invalidating, then it is not correct t= o=20 do a flush first. Summed up: static void bus_dmamap_sync_buf(void *buf, int len, bus_dmasync_op_t op) { char _tmp_cl[arm_dcache_align], _tmp_clend[arm_dcache_align]; if ((op & BUS_DMASYNC_PREWRITE) && !(op & BUS_DMASYNC_PREREAD)) { cpu_dcache_wb_range((vm_offset_t)buf, len); cpu_l2cache_wb_range((vm_offset_t)buf, len); } if (op & BUS_DMASYNC_PREREAD) { if (!(op & BUS_DMASYNC_PREWRITE) && ((((vm_offset_t)(buf) | len) & arm_dcache_align_mask) = =3D=3D=20 0)) { cpu_dcache_inv_range((vm_offset_t)buf, len); cpu_l2cache_inv_range((vm_offset_t)buf, len); } else { Because the USB code specifies both PREREAD and PREWRITE we end up in the=20 following case, which is not implemented correctly. The function name=20 indicates write back first, then invalidate, but when looking at the=20 implementation: arm8_cache_purgeID, /* idcache_wbinv_all */ (void *)arm8_cache_purgeID, /* idcache_wbinv_range */ You see that it only performs purge and no prior flush. This is what needs= =20 fixing! If semihalf could go through the "arm/arm/cpufunc.c" file and fix=20 those flush and invalidate functions then many people would become happy! Again, it is not a problem in USB firstly, it is a problem in "arm/xxx". cpu_dcache_wbinv_range((vm_offset_t)buf, len); cpu_l2cache_wbinv_range((vm_offset_t)buf, len); } } if (op & BUS_DMASYNC_POSTREAD) { if ((vm_offset_t)buf & arm_dcache_align_mask) { memcpy(_tmp_cl, (void *)((vm_offset_t)buf & ~ arm_dcache_align_mask), (vm_offset_t)buf & arm_dcache_align_mask); } if (((vm_offset_t)buf + len) & arm_dcache_align_mask) { memcpy(_tmp_clend, (void *)((vm_offset_t)buf + len), arm_dcache_align - (((vm_offset_t)(buf) + len) & arm_dcache_align_mask)); } cpu_dcache_inv_range((vm_offset_t)buf, len); cpu_l2cache_inv_range((vm_offset_t)buf, len); if ((vm_offset_t)buf & arm_dcache_align_mask) memcpy((void *)((vm_offset_t)buf & ~arm_dcache_align_mask), _tmp_cl,=20 (vm_offset_t)buf & arm_dcache_align_mask); if (((vm_offset_t)buf + len) & arm_dcache_align_mask) memcpy((void *)((vm_offset_t)buf + len), _tmp_clend, arm_dcache_align - (((vm_offset_t)(buf) + len) & arm_dcache_align_mask)); } } =2D-HPS From owner-freebsd-arm@FreeBSD.ORG Mon Jun 29 13:25:19 2009 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 10720106564A for ; Mon, 29 Jun 2009 13:25:19 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe12.tele2.se [212.247.155.97]) by mx1.freebsd.org (Postfix) with ESMTP id 9163F8FC08 for ; Mon, 29 Jun 2009 13:25:18 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=Hrwt8fWgTlIA:10 a=gg2W7PyvkLb8p4ie143lBA==:17 a=k7jeZpGbzUPkrY7CcIoA:9 a=DB5qQmvbDGNFBkEQwdYoMfsj_BYA:4 Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe12.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1096649166; Mon, 29 Jun 2009 14:25:15 +0200 From: Hans Petter Selasky To: Piotr =?utf-8?q?Zi=C4=99cik?= Date: Mon, 29 Jun 2009 14:24:45 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-CURRENT; KDE/4.2.4; i386; ; ) References: <200906231035.43096.kosmo@semihalf.com> <200906291337.43635.hselasky@c2i.net> <200906291416.13749.kosmo@semihalf.com> In-Reply-To: <200906291416.13749.kosmo@semihalf.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200906291424.46954.hselasky@c2i.net> Cc: freebsd-arm@freebsd.org, freebsd-usb@freebsd.org, thompsa@freebsd.org Subject: Re: CPU Cache and busdma usage in USB 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, 29 Jun 2009 13:25:19 -0000 On Monday 29 June 2009 14:16:13 Piotr Zi=C4=99cik wrote: > Look for bus_dmamap_sync() sync description, last sentence: > > If read and write operations are not preceded and followed by the > appropriate synchronization operations, behavior is undefined. > I don't think this is a problem. I do flush read buffers before using them,= =20 and invalidate them afterwards. Write buffers only get flushed once. =2D-HPS From owner-freebsd-arm@FreeBSD.ORG Mon Jun 29 13:34:45 2009 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 325561065675; Mon, 29 Jun 2009 13:34:45 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [IPv6:2001:16d8:fffb:4::abba]) by mx1.freebsd.org (Postfix) with ESMTP id D48038FC15; Mon, 29 Jun 2009 13:34:44 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from stasss.yandex.ru (dhcp170-227-red.yandex.net [95.108.170.227]) by mx0.deglitch.com (Postfix) with ESMTPSA id 218A68FC27; Mon, 29 Jun 2009 17:34:42 +0400 (MSD) Date: Mon, 29 Jun 2009 17:34:38 +0400 From: Stanislav Sedov To: Hans Petter Selasky Message-Id: <20090629173438.75953a18.stas@FreeBSD.org> In-Reply-To: <200906291414.46341.hselasky@c2i.net> References: <200906231035.43096.kosmo@semihalf.com> <200906291337.43635.hselasky@c2i.net> <20090629161011.2a657c4b.stas@FreeBSD.org> <200906291414.46341.hselasky@c2i.net> Organization: The FreeBSD Project X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Mon__29_Jun_2009_17_34_38_+0400_g4SRlaSXA13Hm9UV" Cc: freebsd-arm@freebsd.org, Piotr =?UTF-8?Q?Zi=C4=99cik?= , freebsd-usb@freebsd.org, thompsa@freebsd.org Subject: Re: CPU Cache and busdma usage in USB 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, 29 Jun 2009 13:34:45 -0000 --Signature=_Mon__29_Jun_2009_17_34_38_+0400_g4SRlaSXA13Hm9UV Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 29 Jun 2009 14:14:45 +0200 Hans Petter Selasky mentioned: > On Monday 29 June 2009 14:10:11 Stanislav Sedov wrote: > > On Mon, 29 Jun 2009 13:37:41 +0200 > > > > Hans Petter Selasky mentioned: > > > USB is currently _updating_ (!!) the PAGE offset part of "vaddr". If > > > cpu_dcache_inv_range() is called with an address not starting at the > > > cache line what will the cpu_dcache_inv_range() do? Will it skip to t= he > > > next cache line? Or will it completely skip the whole cache sync > > > operation?! > > > > Currently, the address passed to cpu_dcache_inv_range will be rounded up > > to the cache line boundary and the whole line will be invalidated if the > > range requested is smaller than 16KiB. Otherwise, the whole cache will > > be invalidated. >=20 > That maybe explains it, because USB will require rounding down the addres= s and=20 > rounding up the length accordingly, because it uses the=20 > "BUS_DMA_KEEP_PG_OFFSET" flag. > My apologies, it appears that my wording in previous email was incorrect. = The current cpu_dcache_inv_range ARM implementation obviously rounds down the address passed to the cache line boundary and then invalidates all the lines affected. --=20 Stanislav Sedov ST4096-RIPE --Signature=_Mon__29_Jun_2009_17_34_38_+0400_g4SRlaSXA13Hm9UV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJKSMLyAAoJEKN82nOYvCd0fE8P+wdnphdcU/Rb1JUmrUgMl3nA uo5Qbzx8U0kBckOIkY002zLG22A7nUtTfN0AeBG+HraGRPW6/b+MCWX4Me8YWSSo z3/B74mWe+xScvzZRtIh0gsz3s82H1Sen0F4SxDLX13elee5DueZXpyR80+IYBLq iIiD9vOx07sT3BQRpVObdCAoTgvLpw8Ddsff5uSi45Kur+Bzz3A/3X+xLADuGSVh A/Q9NXKiE5hXr7w19/9db+yXFl8aKCXYZvokH7BuuYfatyIxMZ8E8BRVXb2XRspH z6bYSzBPauzdgNKI4AMl7PB+Fc13bGvLOxzCk2YKBU4IAYZAZwYVXFwSQn7jDYXM XbVvLbsYPnL/JZlpTgm3pNvXdcaacqoQiO2U6YI4ggKEkUatMMgV1glFHtVIbwl+ gcG5vQ5U7EzfEKv5loVxL2mPyUH/Afdws2Y3781xX/c4BYGISMCx034qicpxNd+X 2ePRbPcDS8NmzyUV2fHZq279VFeNVzf6HPaeM0g6EtoILAG9Sk10+LV2nbvqYGwk Yco5WG8wjgGH5avvR3HjNJjVdCz4iHU80LzUPRrutG+ttA5MJUhdMnatnu1Nrxup Qlg7Kv10Dr61fjUHr01+KeuNnEHxFIxps+yg3BlvDL9DrZqJjdhfrrI3/BcMovlV KNaO9AT3+i37AWIcc+7Q =sM7C -----END PGP SIGNATURE----- --Signature=_Mon__29_Jun_2009_17_34_38_+0400_g4SRlaSXA13Hm9UV-- From owner-freebsd-arm@FreeBSD.ORG Mon Jun 29 15:06:41 2009 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 38CB6106570E; Mon, 29 Jun 2009 15:06:41 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.freebsd.org (Postfix) with ESMTP id 9F74D8FC24; Mon, 29 Jun 2009 15:06:40 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.3/8.14.3) with ESMTP id n5TF6bbb010669; Mon, 29 Jun 2009 10:06:37 -0500 (CDT) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1246287997; bh=4VYeITAp4E4qmV1iBoSXFC6PJ/fJeT4f8EZtXCvMg+0=; h=Date:From:Message-Id:To:Subject:Cc:In-Reply-To; b=BC/a5KNQHEDAkfDOxFaEMxFYGPG2ANI0LZbI84wJtRHFI/bTlYYWSNGCxg1UOsbZU uKp5IH2sybf5DRn1GfCgaaprjg2n2BPf0HRhWHXBf+EY0SAkwfgGt3Q3Nio+3aV+G1 bmSV9kJaHZkafvPaw4whoIxd2Yeig9V/6+3Csu88= Received: (from tinguely@localhost) by casselton.net (8.14.3/8.14.2/Submit) id n5TF6boc010668; Mon, 29 Jun 2009 10:06:37 -0500 (CDT) (envelope-from tinguely) Date: Mon, 29 Jun 2009 10:06:37 -0500 (CDT) From: Mark Tinguely Message-Id: <200906291506.n5TF6boc010668@casselton.net> To: hselasky@c2i.net, kosmo@semihalf.com In-Reply-To: <200906291337.43635.hselasky@c2i.net> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.2 (casselton.net [127.0.0.1]); Mon, 29 Jun 2009 10:06:37 -0500 (CDT) Cc: freebsd-arm@freebsd.org, thompsa@freebsd.org, freebsd-usb@freebsd.org Subject: Re: CPU Cache and busdma usage in USB 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, 29 Jun 2009 15:06:41 -0000 > > What has to be changed in busdma_machdep.c for ARM/MIPS so that the problem= > is=20 > resolved. I think there are something missing there and not in USB! > > =2D-HPS I unsuccessfully looked for the start of this thread. Which version of FreeBSD are you using? --Mark T. From owner-freebsd-arm@FreeBSD.ORG Mon Jun 29 15:09:27 2009 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 4A81F106568D; Mon, 29 Jun 2009 15:09:27 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe12.swip.net [212.247.155.97]) by mx1.freebsd.org (Postfix) with ESMTP id 6852A8FC0C; Mon, 29 Jun 2009 15:09:26 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=Hrwt8fWgTlIA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=DSvklMj2ZHpo9BlMfyoA:9 a=prZ1AmeCmHNP7vInEXg6I1RAMg0A:4 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe12.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1096763794; Mon, 29 Jun 2009 17:09:24 +0200 From: Hans Petter Selasky To: Mark Tinguely Date: Mon, 29 Jun 2009 17:08:54 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-CURRENT; KDE/4.2.4; i386; ; ) References: <200906291506.n5TF6boc010668@casselton.net> In-Reply-To: <200906291506.n5TF6boc010668@casselton.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906291708.56737.hselasky@c2i.net> Cc: thompsa@freebsd.org, freebsd-arm@freebsd.org, kosmo@semihalf.com, freebsd-usb@freebsd.org Subject: Re: CPU Cache and busdma usage in USB 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, 29 Jun 2009 15:09:28 -0000 On Monday 29 June 2009 17:06:37 Mark Tinguely wrote: > > What has to be changed in busdma_machdep.c for ARM/MIPS so that the > > problem= is=20 > > resolved. I think there are something missing there and not in USB! > > > > =2D-HPS > > I unsuccessfully looked for the start of this thread. Which version of > FreeBSD are you using? This thread is all about FreeBSD-8-current. --HPS From owner-freebsd-arm@FreeBSD.ORG Mon Jun 29 20:43:11 2009 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 9A39E106564A for ; Mon, 29 Jun 2009 20:43:11 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from farnsworth.fubar.geek.nz (farnsworth.fubar.geek.nz [69.55.236.47]) by mx1.freebsd.org (Postfix) with ESMTP id 7F4728FC22 for ; Mon, 29 Jun 2009 20:43:11 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: by farnsworth.fubar.geek.nz (Postfix, from userid 65534) id 323523502E; Mon, 29 Jun 2009 13:43:11 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on farnsworth.fubar.geek.nz X-Spam-Level: * X-Spam-Status: No, score=1.5 required=5.0 tests=AWL,BAYES_00,HELO_LOCALHOST, RCVD_IN_PBL,RDNS_DYNAMIC autolearn=no version=3.2.5 Received: from localhost (125-238-22-134.broadband-telecom.global-gateway.net.nz [125.238.22.134]) by farnsworth.fubar.geek.nz (Postfix) with ESMTP id 5AC4133C7C; Mon, 29 Jun 2009 13:43:08 -0700 (PDT) Date: Tue, 30 Jun 2009 08:43:10 +1200 From: Andrew Turner To: Donn Miller Message-ID: <20090630084310.02ea492f@fubar.geek.nz> In-Reply-To: <793595.43066.qm@web35704.mail.mud.yahoo.com> References: <793595.43066.qm@web35704.mail.mud.yahoo.com> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; amd64-portbld-freebsd7.1) X-Pirate: Arrrr Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: Support for the Friendly Arm (mini 2440) development board 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, 29 Jun 2009 20:43:11 -0000 On Mon, 29 Jun 2009 03:56:16 -0700 (PDT) Donn Miller wrote: > Were you able to get it to boot FreeBSD from a smartmedia card? That > would be another area that possibly needs working on as well. > I've been loading the kernel from the network then getting the root file system from a md device in the kernel. There is currently a limited number of devices on the board that are supported by FreeBSD. The smartmedia is one of them along with the PHY (DM9000). USB might be working however there are dma issues (see other thread). Andrew From owner-freebsd-arm@FreeBSD.ORG Tue Jun 30 08:37:51 2009 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 EBA111065694; Tue, 30 Jun 2009 08:37:51 +0000 (UTC) (envelope-from kosmo@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 8C2BE8FC1E; Tue, 30 Jun 2009 08:37:51 +0000 (UTC) (envelope-from kosmo@semihalf.com) Received: from [10.0.0.5] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 68B51C3A96; Tue, 30 Jun 2009 10:36:33 +0200 (CEST) From: Piotr =?iso-8859-2?q?Zi=EAcik?= Organization: Semihalf To: Hans Petter Selasky Date: Tue, 30 Jun 2009 10:37:48 +0200 User-Agent: PLD Linux KMail/1.9.10 References: <200906231035.43096.kosmo@semihalf.com> <200906291516.58725.hselasky@c2i.net> In-Reply-To: <200906291516.58725.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200906301037.49367.kosmo@semihalf.com> Cc: freebsd-arm@freebsd.org, thompsa@freebsd.org, freebsd-usb@freebsd.org Subject: Re: CPU Cache and busdma usage in USB 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, 30 Jun 2009 08:37:52 -0000 Monday 29 June 2009 15:16:56 Hans Petter Selasky napisa=B3(a): > > You want to change the flags passed to bus_dmamap_sync() so that the > flush/invalidate mapping gets right. I understand why your patch makes it > work. That's not the problem. > > In "src/sys/arm/arm/busdma_machdep.c" there is a function called > "_bus_dmamap_sync_bp()". If you look at that function you see that it only > triggers on the "BUS_DMASYNC_PREWRITE" and "BUS_DMASYNC_POSTREAD" flags. > After your patching only the PREXXXX flags are used, so if bouce pages are > used on ARM and x86 and amd64 +++, then only BUS_DMASYNC_PREWRITE will do > anything. This indicates that your patch is not fully correct. That is true. I have missed "bounce page" case. I can change flags passed t= o=20 bus_dmamap_sync() to fix this on ARM, but this will break MIPS. This clearly shows the problem - using side effect of busdma to manage CPU= =20 cache. Current USB implementation relies of this side effect assuming that= =20 bus_dmamap_sync() with given flags will do cpu cache flush/invalidation. This is not true even on i386 ! This thread is not about my patch. It is only a fast and dirty hack making USB working on platforms without hardware cache coherency and showing the problem. I see two proper solutions: 1. Implement usb_pc_cpu_invalidate() / usb_pc_cpu_flush() with cpu_*() functions realizing requested operation. 2. Using busdma in proper way: [... prepare data to transfer ...] bus_dmamap_sync(..., PREREAD | PREWRITE); [... do transfer ...] bus_dmamap_sync(..., POSTREAD | POSTWRITE); [... check results ...] as manpage says: If read and write operations are not preceded and followed by the appropriate synchronization operations, behavior is undefined. Requirement cited above is currently not met in USB stack. Funtion shown in http://fxr.watson.org/fxr/source/dev/usb/controller/ehci.c#L1294 is just an example of improper usage of bus_dmamap_sync(), which is hidden= =20 under usb_pc_cpu_invalidate(). This thread started from my question about general usage of usb_pc_cpu_*()= =20 functions. So I am asking once again - why these functions relies on side=20 effect of busdma instead of simply doing cache flush/invalidation through=20 cpu_*() functions ? > Grepping through the source code for ARM, I found a line like this: > (...) > You see that it only performs purge and no prior flush. This is what needs > fixing! If semihalf could go through the "arm/arm/cpufunc.c" file and fix > those flush and invalidate functions then many people would become happy! My developement platform is sheeva. CPU functions for this platform are=20 implemented correctly. > Again, it is not a problem in USB firstly, it is a problem in "arm/xxx". You are suggesting that the problem is in ARM busdma (and in MIPS busdma, a= s=20 on this platform USB also does not work). Could you give me example of=20 platform _without_ hardware coherency where new USB stack simply works ? =2D-=20 Best regards. Piotr Ziecik From owner-freebsd-arm@FreeBSD.ORG Tue Jun 30 09:28:57 2009 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 126DC1065672; Tue, 30 Jun 2009 09:28:57 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe10.swipnet.se [212.247.155.33]) by mx1.freebsd.org (Postfix) with ESMTP id 07FD58FC20; Tue, 30 Jun 2009 09:28:55 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=Hrwt8fWgTlIA:10 a=gg2W7PyvkLb8p4ie143lBA==:17 a=dT19lrtdAAAA:8 a=s9hGD9n5HkASuppt3IgA:9 a=AGuuP_fYWmZ_ObC9u4sA:7 a=2ExIdGNTeNqMt4HR7gWKU41_FtwA:4 Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe10.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1099168685; Tue, 30 Jun 2009 11:28:53 +0200 From: Hans Petter Selasky To: Piotr =?iso-8859-2?q?Zi=EAcik?= Date: Tue, 30 Jun 2009 11:28:23 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-CURRENT; KDE/4.2.4; i386; ; ) References: <200906231035.43096.kosmo@semihalf.com> <200906291516.58725.hselasky@c2i.net> <200906301037.49367.kosmo@semihalf.com> In-Reply-To: <200906301037.49367.kosmo@semihalf.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200906301128.26046.hselasky@c2i.net> Cc: freebsd-arm@freebsd.org, thompsa@freebsd.org, freebsd-usb@freebsd.org Subject: Re: CPU Cache and busdma usage in USB 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, 30 Jun 2009 09:28:57 -0000 On Tuesday 30 June 2009 10:37:48 Piotr Zi=EAcik wrote: > Monday 29 June 2009 15:16:56 Hans Petter Selasky napisa=B3(a): > > You want to change the flags passed to bus_dmamap_sync() so that the > > flush/invalidate mapping gets right. I understand why your patch makes = it > > work. That's not the problem. > > > > In "src/sys/arm/arm/busdma_machdep.c" there is a function called > > "_bus_dmamap_sync_bp()". If you look at that function you see that it > > only triggers on the "BUS_DMASYNC_PREWRITE" and "BUS_DMASYNC_POSTREAD" > > flags. After your patching only the PREXXXX flags are used, so if bouce > > pages are used on ARM and x86 and amd64 +++, then only > > BUS_DMASYNC_PREWRITE will do anything. This indicates that your patch is > > not fully correct. > Hi, > That is true. I have missed "bounce page" case. I can change flags passed > to bus_dmamap_sync() to fix this on ARM, but this will break MIPS. Right, so there is inconsistency among the platforms in how the BUSDMA is=20 implemented, which should be fixed. > This clearly shows the problem - using side effect of busdma to manage CPU > cache. Current USB implementation relies of this side effect assuming that > bus_dmamap_sync() with given flags will do cpu cache flush/invalidation. > This is not true even on i386 ! i386 handles this differently. > This thread is not about my patch. It is only a fast and dirty hack > making USB working on platforms without hardware cache coherency > and showing the problem. I see two proper solutions: Ok. > > 1. Implement usb_pc_cpu_invalidate() / usb_pc_cpu_flush() with > cpu_*() functions realizing requested operation. > > 2. Using busdma in proper way: > [... prepare data to transfer ...] > bus_dmamap_sync(..., PREREAD | PREWRITE); > [... do transfer ...] > bus_dmamap_sync(..., POSTREAD | POSTWRITE); > [... check results ...] > as manpage says: > > If read and write operations are not preceded and followed by the > appropriate synchronization operations, behavior is undefined. > > Requirement cited above is currently not met in USB stack. Funtion > shown in http://fxr.watson.org/fxr/source/dev/usb/controller/ehci.c#L1294 > is just an example of improper usage of bus_dmamap_sync(), which is hidden > under usb_pc_cpu_invalidate(). I'm not violating any rules in busdma. The busdma manual is silent about do= ing=20 multiple sync operations of the same kind in a row. If the sheeva hardware = you=20 are using works differently, you have to fix it. > > This thread started from my question about general usage of usb_pc_cpu_*() > functions. So I am asking once again - why these functions relies on side > effect of busdma instead of simply doing cache flush/invalidation through > cpu_*() functions ? Because busdma is the interface for doing these kinds of operations and not= =20 cpu_xxx(). The DMA memory is allocated using busdma and loaded using busdma= ,=20 and cpu_xxx() is not a part of the busdma interface. > > > Grepping through the source code for ARM, I found a line like this: > > (...) > > You see that it only performs purge and no prior flush. This is what > > needs fixing! If semihalf could go through the "arm/arm/cpufunc.c" file > > and fix those flush and invalidate functions then many people would > > become happy! > > My developement platform is sheeva. CPU functions for this platform are > implemented correctly. > > > Again, it is not a problem in USB firstly, it is a problem in "arm/xxx". > > You are suggesting that the problem is in ARM busdma (and in MIPS busdma, > as on this platform USB also does not work). Could you give me example of > platform _without_ hardware coherency where new USB stack simply works ? If I find time later today I will fix the cache sync operations for AT91RM9= 200=20 which has a built in OHCI, which has been working fine with my new USB stac= k. Can you please add some prints to the "bus_dmamap_sync_buf()" code on ARM, = and=20 verify which cases the CPU is entering, without your patch and with your=20 patch. From my analysis your patch will just change the execution path: With your patch it calls: cpu_dcache_wb_range((vm_offset_t)buf, len); cpu_l2cache_wb_range((vm_offset_t)buf, len); Without your patch it calls: cpu_dcache_wbinv_range((vm_offset_t)buf, len); cpu_l2cache_wbinv_range((vm_offset_t)buf, len); In my view these execution paths are equivalent with regard to clean or cac= he=20 flush. They should both perform a cache flush, which is what the USB code=20 wants to do, but obviously the latter case is not implemented correctly, mo= st=20 likely because it doesn't flush the buffer like expected! Try adding: cpu_dcache_wb_range((vm_offset_t)buf, len); cpu_l2cache_wb_range((vm_offset_t)buf, len); Before: cpu_dcache_wbinv_range((vm_offset_t)buf, len); cpu_l2cache_wbinv_range((vm_offset_t)buf, len); In: sys/arm/arm/busdma_machdep.c Yours, =2D-HPS