From owner-freebsd-embedded@FreeBSD.ORG Mon Feb 24 04:51:43 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 37527E72; Mon, 24 Feb 2014 04:51:43 +0000 (UTC) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D88EA109D; Mon, 24 Feb 2014 04:51:42 +0000 (UTC) Received: by mail-qg0-f41.google.com with SMTP id i50so13633167qgf.0 for ; Sun, 23 Feb 2014 20:51:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=NdPuiLKscc9Kkdc9aHQOMHnpvnzggrOXcTzoq+bF7d8=; b=atai7ZL4rv0zDtp4O8cnJY8Kt/c7eJQ6fm4Bx3IIDu4zMATIoH7peznDcml9PqYZmO AAFBvTICZpKUw8aHWPwZtk3YXR88s0ZGLVUjc18MPo6oySYbFgfgQgtp0i65M+ltpyjF 4g0H5MoF9nLIiA1mdQL59ZlPhEK8Zn5FuSHyr5g+axEMbzOgmG7yjXAuFJctD6qjs5kO 9XCyGHgiBNFi90trEg6CmAhg11JfsBEQ055XPjXEeDoj8lOJ06G6Y0qH7oZTpeRXlnuB W/QiN1hXJUGhwzjtVImb7J/sHQmtR2hi/FvE0wQm4I/iJWVcDEaoyKR76Fqw9LBWMGaY +49Q== MIME-Version: 1.0 X-Received: by 10.140.42.54 with SMTP id b51mr25496673qga.87.1393217501974; Sun, 23 Feb 2014 20:51:41 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.16.10 with HTTP; Sun, 23 Feb 2014 20:51:41 -0800 (PST) Date: Sun, 23 Feb 2014 20:51:41 -0800 X-Google-Sender-Auth: 6WVaegGOjoFA-hUbRQtiXvAlqeA Message-ID: Subject: (initial) AR8327 switch support is in -HEAD From: Adrian Chadd To: "freebsd-mips@freebsd.org" , "freebsd-embedded@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 04:51:43 -0000 Hi all, I've finally sat down and finished the AR8327 switch (and general driver) support enough to bring it up on my DB120 development board. It survives pings. :-) I have to finish off the platform data and LED code so it can be generically programmed and run on boards other than the DB120 (ie,what y'all will be buying.) It also absolutely has no VLAN support so don't bother with it just yet. Luckily I've methodized the VLAN hooks from the driver so someone feeling intrepid enough can port over the missing bits as appropriate. Go forth and hack! -a From owner-freebsd-embedded@FreeBSD.ORG Mon Feb 24 11:06:46 2014 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7288CA66 for ; Mon, 24 Feb 2014 11:06:46 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 54BD21611 for ; Mon, 24 Feb 2014 11:06:46 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s1OB6kXA027468 for ; Mon, 24 Feb 2014 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1OB6jxJ027466 for freebsd-embedded@FreeBSD.org; Mon, 24 Feb 2014 11:06:45 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 24 Feb 2014 11:06:45 GMT Message-Id: <201402241106.s1OB6jxJ027466@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-embedded@FreeBSD.org Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 11:06:46 -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 misc/52256 embedded [picobsd] picobsd build script does not read in user/s o kern/42728 embedded [picobsd] many problems in src/usr.sbin/ppp/* after c 2 problems total. From owner-freebsd-embedded@FreeBSD.ORG Fri Feb 28 18:38:58 2014 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E18E275; Fri, 28 Feb 2014 18:38:58 +0000 (UTC) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D3781191E; Fri, 28 Feb 2014 18:38:54 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id rp18so3662680iec.5 for ; Fri, 28 Feb 2014 10:38:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version; bh=3UPKEhTrbl8My9ESswor5KY1M16YT99NxFSlK0hFB3s=; b=tVriGWI8uQhoDi3B4NBnzFwGuggDB34U6V0KptlmO4cHpQF0clrUPyqXojmm2Gp/hU 8I00VdW9R+8acY+aG4iNXcHRjJADjJazFzwK3zyEK7cR3UGYdiybeTAGThVbuL7E4ILT tKFubAPcTb6jPjDYCsZW8pVyLoxb6rw3hytBjr/RwLCcvhzYmyKrd6WX8S6OOXTObjEM FSAOR42nyXElclIprFFoKoPrYlK0IdWI7GWIUA0nLkcQq01qMsSGq4nYWVvbiG/7zc/N WlZXa6B+bWt8/DOxbxJGoGsXhSzimUGFLIyirGeKu24X0RchM4nEKox/uL1d/6pi+IWU EP9A== X-Received: by 10.42.215.207 with SMTP id hf15mr12605462icb.17.1393612733737; Fri, 28 Feb 2014 10:38:53 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id qk2sm19587991igc.1.2014.02.28.10.38.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Feb 2014 10:38:52 -0800 (PST) From: Warner Losh Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Fwd: svn commit: r262614 - in head: . share/mk sys/boot/fdt/dts sys/boot/fdt/dts/arm sys/boot/fdt/dts/mips sys/boot/fdt/dts/powerpc sys/conf sys/tools/fdt Date: Fri, 28 Feb 2014 11:38:50 -0700 References: <201402281829.s1SITAQk019090@svn.freebsd.org> To: freebsd-arm , mips@freebsd.org, powerpc@freebsd.org, embedded@freebsd.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 18:38:58 -0000 Greetings, This commit changes how we do DTS -> DTB compiling. For the most part, = it should be a NOP, if all my tests are good, but I may have oopsed = something without realizing it. This commit does switch us back to the GPL dtc. That cannot be helped. = The BSDL one was too far away from working, but if that status ever changes, = I=92m happy to change the defaults back. This change was discussed by most of = the major workers in arm@ and mips@ land before changing back, and they = felt, as I do, that using vendor dts files unmodified was a bigger win for = embedded than the regression back to a GPL=92d piece of software when the BSDL=92d = one isn=92t up to the task today of coping with this new world order. If = that changes, then I=92d be happy to switch back. Hope this doesn=92t break anybody. I=92ll be around if it does. Warner Begin forwarded message: > From: Warner Losh > Subject: svn commit: r262614 - in head: . share/mk sys/boot/fdt/dts = sys/boot/fdt/dts/arm sys/boot/fdt/dts/mips sys/boot/fdt/dts/powerpc = sys/conf sys/tools/fdt > Date: February 28, 2014 at 11:29:10 AM MST > To: src-committers@freebsd.org, svn-src-all@freebsd.org, = svn-src-head@freebsd.org >=20 > Author: imp > Date: Fri Feb 28 18:29:09 2014 > New Revision: 262614 > URL: http://svnweb.freebsd.org/changeset/base/262614 >=20 > Log: > Integrate device-tree upstream files into the build process: > (1) Invoke cpp to bring in files via #include (although the old > /include/ stuff is supported still). > (2) bring in files from either vendor tree or freebsd-custom files > when building. > (3) move all dts* files from sys/boot/fdt/dts to > sys/boot/fdt/dts/${MACHINE} as appropriate. > (4) encode all the magic to do the build in sys/tools/fdt/make_dtb.sh > so that the different places in the tree use the exact same = logic. > (5) switch back to gpl dtc by default. the bsdl one in the tree has > significant issues not easily addressed by those unfamiliar with > the code. >=20 > Added: > head/sys/boot/fdt/dts/arm/ > head/sys/boot/fdt/dts/arm/am335x-evm.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/am335x-evm.dts > head/sys/boot/fdt/dts/arm/am335x.dtsi > - copied, changed from r262613, head/sys/boot/fdt/dts/am335x.dtsi > head/sys/boot/fdt/dts/arm/bcm2835.dtsi > - copied, changed from r262613, head/sys/boot/fdt/dts/bcm2835.dtsi > head/sys/boot/fdt/dts/arm/beaglebone-black.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/beaglebone-black.dts > head/sys/boot/fdt/dts/arm/beaglebone.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/beaglebone.dts > head/sys/boot/fdt/dts/arm/cubieboard.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/cubieboard.dts > head/sys/boot/fdt/dts/arm/cubieboard2.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/cubieboard2.dts > head/sys/boot/fdt/dts/arm/db78100.dts > - copied, changed from r262613, head/sys/boot/fdt/dts/db78100.dts > head/sys/boot/fdt/dts/arm/db78460.dts > - copied, changed from r262613, head/sys/boot/fdt/dts/db78460.dts > head/sys/boot/fdt/dts/arm/db88f5182.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/db88f5182.dts > head/sys/boot/fdt/dts/arm/db88f5281.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/db88f5281.dts > head/sys/boot/fdt/dts/arm/db88f6281.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/db88f6281.dts > head/sys/boot/fdt/dts/arm/digi-ccwmx53.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/digi-ccwmx53.dts > head/sys/boot/fdt/dts/arm/dockstar.dts > - copied, changed from r262613, head/sys/boot/fdt/dts/dockstar.dts > head/sys/boot/fdt/dts/arm/dreamplug-1001.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/dreamplug-1001.dts > head/sys/boot/fdt/dts/arm/dreamplug-1001N.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/dreamplug-1001N.dts > head/sys/boot/fdt/dts/arm/ea3250.dts > - copied, changed from r262613, head/sys/boot/fdt/dts/ea3250.dts > head/sys/boot/fdt/dts/arm/efikamx.dts > - copied, changed from r262613, head/sys/boot/fdt/dts/efikamx.dts > head/sys/boot/fdt/dts/arm/exynos5250-arndale.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/exynos5250-arndale.dts > head/sys/boot/fdt/dts/arm/exynos5250.dtsi > - copied, changed from r262613, = head/sys/boot/fdt/dts/exynos5250.dtsi > head/sys/boot/fdt/dts/arm/imx51x.dtsi > - copied, changed from r262613, head/sys/boot/fdt/dts/imx51x.dtsi > head/sys/boot/fdt/dts/arm/imx53-qsb.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/imx53-qsb.dts > head/sys/boot/fdt/dts/arm/imx53x.dtsi > - copied, changed from r262613, head/sys/boot/fdt/dts/imx53x.dtsi > head/sys/boot/fdt/dts/arm/imx6.dtsi > - copied, changed from r262613, head/sys/boot/fdt/dts/imx6.dtsi > head/sys/boot/fdt/dts/arm/p1020rdb.dts > - copied, changed from r262613, head/sys/boot/fdt/dts/p1020rdb.dts > head/sys/boot/fdt/dts/arm/p2020ds.dts > - copied, changed from r262613, head/sys/boot/fdt/dts/p2020ds.dts > head/sys/boot/fdt/dts/arm/p2041rdb.dts > - copied, changed from r262613, head/sys/boot/fdt/dts/p2041rdb.dts > head/sys/boot/fdt/dts/arm/p2041si.dtsi > - copied, changed from r262613, head/sys/boot/fdt/dts/p2041si.dtsi > head/sys/boot/fdt/dts/arm/p3041ds.dts > - copied, changed from r262613, head/sys/boot/fdt/dts/p3041ds.dts > head/sys/boot/fdt/dts/arm/p3041si.dtsi > - copied, changed from r262613, head/sys/boot/fdt/dts/p3041si.dtsi > head/sys/boot/fdt/dts/arm/p5020ds.dts > - copied, changed from r262613, head/sys/boot/fdt/dts/p5020ds.dts > head/sys/boot/fdt/dts/arm/p5020si.dtsi > - copied, changed from r262613, head/sys/boot/fdt/dts/p5020si.dtsi > head/sys/boot/fdt/dts/arm/pandaboard.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/pandaboard.dts > head/sys/boot/fdt/dts/arm/rk3188-radxa.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/rk3188-radxa.dts > head/sys/boot/fdt/dts/arm/rk3188.dtsi > - copied, changed from r262613, head/sys/boot/fdt/dts/rk3188.dtsi > head/sys/boot/fdt/dts/arm/rpi.dts > - copied, changed from r262613, head/sys/boot/fdt/dts/rpi.dts > head/sys/boot/fdt/dts/arm/sheevaplug.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/sheevaplug.dts > head/sys/boot/fdt/dts/arm/tegra20-paz00.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/tegra20-paz00.dts > head/sys/boot/fdt/dts/arm/tegra20.dtsi > - copied, changed from r262613, head/sys/boot/fdt/dts/tegra20.dtsi > head/sys/boot/fdt/dts/arm/trimslice.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/trimslice.dts > head/sys/boot/fdt/dts/arm/ts7800.dts > - copied, changed from r262613, head/sys/boot/fdt/dts/ts7800.dts > head/sys/boot/fdt/dts/arm/versatilepb.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/versatilepb.dts > head/sys/boot/fdt/dts/arm/vybrid-colibri-vf50.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/vybrid-colibri-vf50.dts > head/sys/boot/fdt/dts/arm/vybrid-cosmic.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/vybrid-cosmic.dts > head/sys/boot/fdt/dts/arm/vybrid-quartz.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/vybrid-quartz.dts > head/sys/boot/fdt/dts/arm/vybrid.dtsi > - copied, changed from r262613, head/sys/boot/fdt/dts/vybrid.dtsi > head/sys/boot/fdt/dts/arm/wandboard-dual.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/wandboard-dual.dts > head/sys/boot/fdt/dts/arm/wandboard-quad.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/wandboard-quad.dts > head/sys/boot/fdt/dts/arm/wandboard-solo.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/wandboard-solo.dts > head/sys/boot/fdt/dts/arm/zedboard.dts > - copied, changed from r262613, head/sys/boot/fdt/dts/zedboard.dts > head/sys/boot/fdt/dts/mips/ > head/sys/boot/fdt/dts/mips/beri-netfpga.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/beri-netfpga.dts > head/sys/boot/fdt/dts/mips/beri-sim.dts > - copied, changed from r262613, head/sys/boot/fdt/dts/beri-sim.dts > head/sys/boot/fdt/dts/mips/beripad-de4.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/beripad-de4.dts > head/sys/boot/fdt/dts/mips/xlp-basic.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/xlp-basic.dts > head/sys/boot/fdt/dts/powerpc/ > head/sys/boot/fdt/dts/powerpc/mpc8555cds.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/mpc8555cds.dts > head/sys/boot/fdt/dts/powerpc/mpc8572ds.dts > - copied, changed from r262613, = head/sys/boot/fdt/dts/mpc8572ds.dts > head/sys/tools/fdt/make_dtb.sh (contents, props changed) > Deleted: > head/sys/boot/fdt/dts/am335x-evm.dts > head/sys/boot/fdt/dts/am335x.dtsi > head/sys/boot/fdt/dts/bcm2835.dtsi > head/sys/boot/fdt/dts/beaglebone-black.dts > head/sys/boot/fdt/dts/beaglebone.dts > head/sys/boot/fdt/dts/beri-netfpga.dts > head/sys/boot/fdt/dts/beri-sim.dts > head/sys/boot/fdt/dts/beripad-de4.dts > head/sys/boot/fdt/dts/cubieboard.dts > head/sys/boot/fdt/dts/cubieboard2.dts > head/sys/boot/fdt/dts/db78100.dts > head/sys/boot/fdt/dts/db78460.dts > head/sys/boot/fdt/dts/db88f5182.dts > head/sys/boot/fdt/dts/db88f5281.dts > head/sys/boot/fdt/dts/db88f6281.dts > head/sys/boot/fdt/dts/digi-ccwmx53.dts > head/sys/boot/fdt/dts/dockstar.dts > head/sys/boot/fdt/dts/dreamplug-1001.dts > head/sys/boot/fdt/dts/dreamplug-1001N.dts > head/sys/boot/fdt/dts/ea3250.dts > head/sys/boot/fdt/dts/efikamx.dts > head/sys/boot/fdt/dts/exynos5250-arndale.dts > head/sys/boot/fdt/dts/exynos5250.dtsi > head/sys/boot/fdt/dts/imx51x.dtsi > head/sys/boot/fdt/dts/imx53-qsb.dts > head/sys/boot/fdt/dts/imx53x.dtsi > head/sys/boot/fdt/dts/imx6.dtsi > head/sys/boot/fdt/dts/mpc8555cds.dts > head/sys/boot/fdt/dts/mpc8572ds.dts > head/sys/boot/fdt/dts/p1020rdb.dts > head/sys/boot/fdt/dts/p2020ds.dts > head/sys/boot/fdt/dts/p2041rdb.dts > head/sys/boot/fdt/dts/p2041si.dtsi > head/sys/boot/fdt/dts/p3041ds.dts > head/sys/boot/fdt/dts/p3041si.dtsi > head/sys/boot/fdt/dts/p5020ds.dts > head/sys/boot/fdt/dts/p5020si.dtsi > head/sys/boot/fdt/dts/pandaboard.dts > head/sys/boot/fdt/dts/rk3188-radxa.dts > head/sys/boot/fdt/dts/rk3188.dtsi > head/sys/boot/fdt/dts/rpi.dts > head/sys/boot/fdt/dts/sheevaplug.dts > head/sys/boot/fdt/dts/tegra20-paz00.dts > head/sys/boot/fdt/dts/tegra20.dtsi > head/sys/boot/fdt/dts/trimslice.dts > head/sys/boot/fdt/dts/ts7800.dts > head/sys/boot/fdt/dts/versatilepb.dts > head/sys/boot/fdt/dts/vybrid-colibri-vf50.dts > head/sys/boot/fdt/dts/vybrid-cosmic.dts > head/sys/boot/fdt/dts/vybrid-quartz.dts > head/sys/boot/fdt/dts/vybrid.dtsi > head/sys/boot/fdt/dts/wandboard-dual.dts > head/sys/boot/fdt/dts/wandboard-quad.dts > head/sys/boot/fdt/dts/wandboard-solo.dts > head/sys/boot/fdt/dts/xlp-basic.dts > head/sys/boot/fdt/dts/zedboard.dts > Modified: > head/Makefile.inc1 > head/share/mk/bsd.own.mk > head/sys/conf/files >=20 > Modified: head/Makefile.inc1 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > --- head/Makefile.inc1 Fri Feb 28 18:06:00 2014 = (r262613) > +++ head/Makefile.inc1 Fri Feb 28 18:29:09 2014 = (r262614) > @@ -1262,7 +1262,7 @@ _dtrace_tools=3D cddl/usr.bin/sgsmsg cddl/ > lib/libdwarf cddl/usr.bin/ctfconvert cddl/usr.bin/ctfmerge > .endif >=20 > -# Default to building the BSDL DTC, but build the GPL one if users = explicitly > +# Default to building the GPL DTC, but build the BSDL one if users = explicitly > # request it. > _dtc=3D usr.bin/dtc > .if ${MK_GPL_DTC} !=3D "no" > @@ -1853,7 +1853,7 @@ builddtb: > echo "ERROR: FDT_DTS_FILE must be specified!"; \ > exit 1; \ > fi; \ > - if [ ! -f ${.CURDIR}/sys/boot/fdt/dts/${FDT_DTS_FILE} ]; then \ > + if [ ! -f ${.CURDIR}/sys/boot/fdt/dts/${MACHINE}/${FDT_DTS_FILE} = ]; then \ > echo "ERROR: Specified DTS file (${FDT_DTS_FILE}) does = not \ > exist!"; \ > exit 1; \ > @@ -1863,9 +1863,9 @@ builddtb: > directory"; \ > fi > @PATH=3D${TMPPATH} \ > - dtc -O dtb -o \ > - ${DTBOUTPUTPATH}/`echo ${FDT_DTS_FILE} | cut -d. -f1`.dtb -b = 0 \ > - -p 1024 ${.CURDIR}/sys/boot/fdt/dts/${FDT_DTS_FILE} > + ${.CURDIR}/sys/tools/fdt/make_dtb.sh ${.CURDIR}/sys \ > + ${FDT_DTS_FILE} \ > + ${DTBOUTPUTPATH}/`basename ${FDT_DTS_FILE} .dts` >=20 > ############### >=20 >=20 > Modified: head/share/mk/bsd.own.mk > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > --- head/share/mk/bsd.own.mk Fri Feb 28 18:06:00 2014 = (r262613) > +++ head/share/mk/bsd.own.mk Fri Feb 28 18:29:09 2014 = (r262614) > @@ -287,6 +287,7 @@ __DEFAULT_YES_OPTIONS =3D \ > GNU \ > GPIB \ > GPIO \ > + GPL_DTC \ > GROFF \ > HTML \ > ICONV \ > @@ -368,7 +369,6 @@ __DEFAULT_NO_OPTIONS =3D \ > CLANG_EXTRAS \ > CTF \ > DEBUG_FILES \ > - GPL_DTC \ > HESIOD \ > INSTALL_AS_USER \ > LLDB \ >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/am335x-evm.dts (from = r262613, head/sys/boot/fdt/dts/am335x-evm.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/am335x.dtsi (from = r262613, head/sys/boot/fdt/dts/am335x.dtsi) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/bcm2835.dtsi (from = r262613, head/sys/boot/fdt/dts/bcm2835.dtsi) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/beaglebone-black.dts = (from r262613, head/sys/boot/fdt/dts/beaglebone-black.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/beaglebone.dts (from = r262613, head/sys/boot/fdt/dts/beaglebone.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/cubieboard.dts (from = r262613, head/sys/boot/fdt/dts/cubieboard.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/cubieboard2.dts (from = r262613, head/sys/boot/fdt/dts/cubieboard2.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/db78100.dts (from = r262613, head/sys/boot/fdt/dts/db78100.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/db78460.dts (from = r262613, head/sys/boot/fdt/dts/db78460.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/db88f5182.dts (from = r262613, head/sys/boot/fdt/dts/db88f5182.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/db88f5281.dts (from = r262613, head/sys/boot/fdt/dts/db88f5281.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/db88f6281.dts (from = r262613, head/sys/boot/fdt/dts/db88f6281.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/digi-ccwmx53.dts (from = r262613, head/sys/boot/fdt/dts/digi-ccwmx53.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/dockstar.dts (from = r262613, head/sys/boot/fdt/dts/dockstar.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/dreamplug-1001.dts = (from r262613, head/sys/boot/fdt/dts/dreamplug-1001.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/dreamplug-1001N.dts = (from r262613, head/sys/boot/fdt/dts/dreamplug-1001N.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/ea3250.dts (from = r262613, head/sys/boot/fdt/dts/ea3250.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/efikamx.dts (from = r262613, head/sys/boot/fdt/dts/efikamx.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/exynos5250-arndale.dts = (from r262613, head/sys/boot/fdt/dts/exynos5250-arndale.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/exynos5250.dtsi (from = r262613, head/sys/boot/fdt/dts/exynos5250.dtsi) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/imx51x.dtsi (from = r262613, head/sys/boot/fdt/dts/imx51x.dtsi) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/imx53-qsb.dts (from = r262613, head/sys/boot/fdt/dts/imx53-qsb.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/imx53x.dtsi (from = r262613, head/sys/boot/fdt/dts/imx53x.dtsi) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/imx6.dtsi (from = r262613, head/sys/boot/fdt/dts/imx6.dtsi) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/p1020rdb.dts (from = r262613, head/sys/boot/fdt/dts/p1020rdb.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/p2020ds.dts (from = r262613, head/sys/boot/fdt/dts/p2020ds.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/p2041rdb.dts (from = r262613, head/sys/boot/fdt/dts/p2041rdb.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/p2041si.dtsi (from = r262613, head/sys/boot/fdt/dts/p2041si.dtsi) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/p3041ds.dts (from = r262613, head/sys/boot/fdt/dts/p3041ds.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/p3041si.dtsi (from = r262613, head/sys/boot/fdt/dts/p3041si.dtsi) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/p5020ds.dts (from = r262613, head/sys/boot/fdt/dts/p5020ds.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/p5020si.dtsi (from = r262613, head/sys/boot/fdt/dts/p5020si.dtsi) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/pandaboard.dts (from = r262613, head/sys/boot/fdt/dts/pandaboard.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/rk3188-radxa.dts (from = r262613, head/sys/boot/fdt/dts/rk3188-radxa.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/rk3188.dtsi (from = r262613, head/sys/boot/fdt/dts/rk3188.dtsi) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/rpi.dts (from r262613, = head/sys/boot/fdt/dts/rpi.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/sheevaplug.dts (from = r262613, head/sys/boot/fdt/dts/sheevaplug.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/tegra20-paz00.dts (from = r262613, head/sys/boot/fdt/dts/tegra20-paz00.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/tegra20.dtsi (from = r262613, head/sys/boot/fdt/dts/tegra20.dtsi) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/trimslice.dts (from = r262613, head/sys/boot/fdt/dts/trimslice.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/ts7800.dts (from = r262613, head/sys/boot/fdt/dts/ts7800.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/versatilepb.dts (from = r262613, head/sys/boot/fdt/dts/versatilepb.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/vybrid-colibri-vf50.dts = (from r262613, head/sys/boot/fdt/dts/vybrid-colibri-vf50.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/vybrid-cosmic.dts (from = r262613, head/sys/boot/fdt/dts/vybrid-cosmic.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/vybrid-quartz.dts (from = r262613, head/sys/boot/fdt/dts/vybrid-quartz.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/vybrid.dtsi (from = r262613, head/sys/boot/fdt/dts/vybrid.dtsi) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/wandboard-dual.dts = (from r262613, head/sys/boot/fdt/dts/wandboard-dual.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/wandboard-quad.dts = (from r262613, head/sys/boot/fdt/dts/wandboard-quad.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/wandboard-solo.dts = (from r262613, head/sys/boot/fdt/dts/wandboard-solo.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/arm/zedboard.dts (from = r262613, head/sys/boot/fdt/dts/zedboard.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/mips/beri-netfpga.dts (from = r262613, head/sys/boot/fdt/dts/beri-netfpga.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/mips/beri-sim.dts (from = r262613, head/sys/boot/fdt/dts/beri-sim.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/mips/beripad-de4.dts (from = r262613, head/sys/boot/fdt/dts/beripad-de4.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/mips/xlp-basic.dts (from = r262613, head/sys/boot/fdt/dts/xlp-basic.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/powerpc/mpc8555cds.dts = (from r262613, head/sys/boot/fdt/dts/mpc8555cds.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Copied and modified: head/sys/boot/fdt/dts/powerpc/mpc8572ds.dts (from = r262613, head/sys/boot/fdt/dts/mpc8572ds.dts) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Modified: head/sys/conf/files > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > --- head/sys/conf/files Fri Feb 28 18:06:00 2014 = (r262613) > +++ head/sys/conf/files Fri Feb 28 18:29:09 2014 = (r262614) > @@ -14,11 +14,12 @@ acpi_quirks.h optional acpi = \ > # from the specified source (DTS) file: .dts -> = .dtb > # > fdt_dtb_file optional fdt \ > - compile-with "if [ -f $S/boot/fdt/dts/${FDT_DTS_FILE} ]; then = dtc -O dtb -o ${FDT_DTS_FILE:R}.dtb -b 0 -p 1024 = $S/boot/fdt/dts/${FDT_DTS_FILE}; fi" \ > + compile-with "sh $S/tools/fdt/make_dtb.sh $S ${FDT_DTS_FILE} = ${.CURDIR}/${FDT_DTS_FILE:R}.dtb" \ > no-obj no-implicit-rule before-depend \ > clean "${FDT_DTS_FILE:R}.dtb" > fdt_static_dtb.h optional fdt fdt_dtb_static \ > - compile-with "sh $S/tools/fdt/make_dtbh.sh ${FDT_DTS_FILE} ." \ > + compile-with "sh $S/tools/fdt/make_dtbh.sh ${FDT_DTS_FILE} = ${.CURDIR}" \ > + dependency "fdt_dtb_file" \ > no-obj no-implicit-rule before-depend \ > clean "fdt_static_dtb.h" > feeder_eq_gen.h optional sound = \ > @@ -1370,7 +1371,7 @@ dev/fb/splash.c optional sc = splash > dev/fdt/fdt_common.c optional fdt > dev/fdt/fdt_slicer.c optional fdt cfi | fdt nand > dev/fdt/fdt_static_dtb.S optional fdt fdt_dtb_static \ > - dependency "$S/boot/fdt/dts/${FDT_DTS_FILE}" > + dependency "$S/boot/fdt/dts/${MACHINE}/${FDT_DTS_FILE}" > dev/fdt/simplebus.c optional fdt > dev/fe/if_fe.c optional fe > dev/fe/if_fe_pccard.c optional fe pccard >=20 > Added: head/sys/tools/fdt/make_dtb.sh > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > --- /dev/null 00:00:00 1970 (empty, because file is newly added) > +++ head/sys/tools/fdt/make_dtb.sh Fri Feb 28 18:29:09 2014 = (r262614) > @@ -0,0 +1,11 @@ > +#!/bin/sh > +# > +# $FreeBSD$ > + > +# Script generates dtb file ($3) from dts source ($2) in build tree S = ($1) > +S=3D$1 > +dts=3D$2 > +dtb=3D$3 > + > +cpp -x assembler-with-cpp -I $S/gnu/dts/include -I = $S/boot/fdt/dts/${MACHINE} -I $S/gnu/dts/${MACHINE} -include $dts = /dev/null |=20 > + dtc -O dtb -o $dtb -b 0 -p 1024 -i $S/boot/fdt/dts -i = $S/gnu/dts/${MACHINE} >=20 From owner-freebsd-embedded@FreeBSD.ORG Sat Mar 1 10:06:50 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94093ACA; Sat, 1 Mar 2014 10:06:50 +0000 (UTC) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 45BF81130; Sat, 1 Mar 2014 10:06:50 +0000 (UTC) Received: by mail-qg0-f42.google.com with SMTP id q107so5288559qgd.1 for ; Sat, 01 Mar 2014 02:06:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=VKqaMVw3jHiVLQvVXujuVOox6jfcmaaAHvkP3JFt72Q=; b=ZFxee0FprsBuF9bq6Fj3kJrxyPLioNmmZRFhjsDJMwUmLRwGNTnE1pbZucb3kYxLy2 h0LunF6QqviIK7lx+4dpKB9oliUrza73pUdXxKAnatYSBR+ier51bm68PZhf/3Q2FokB oJ2+9ifzB6kBoNBueRJ0YMcLP1HazMkc07UVAMzVdfMkp0IP0z+3kdWjmCeLQ298w3zN 4Os74VHs3GDvpDUeyuaF4YHbF87z6Pa6KDhHLGjHZcunn/w7jePIfSud54m8LSapny+8 JF+8P+EHOMx3y/UeKWfqVXRVfteD4PhwoW/2csfAy2TwC72wumzV1oNoL/nsU2CkYySc jMrw== MIME-Version: 1.0 X-Received: by 10.224.136.195 with SMTP id s3mr1178357qat.95.1393668409330; Sat, 01 Mar 2014 02:06:49 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.16.10 with HTTP; Sat, 1 Mar 2014 02:06:49 -0800 (PST) Date: Sat, 1 Mar 2014 02:06:49 -0800 X-Google-Sender-Auth: f08bzxKj3qKoPqlQwjZbe7Rg2ow Message-ID: Subject: I (think) the AR8327 switch support now works From: Adrian Chadd To: "freebsd-embedded@freebsd.org" , "freebsd-mips@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 10:06:50 -0000 Hi, I think I just figured out the last bits of missing magic to get the AR8327 to work out of the box. VLANs just plain don't work yet, so don't ask me about that. Also if port 6 is hooked up to anything (it isn't on my DB120) then please let me know; I'd really like to debug that particular support. But, I'm now using my DB120 development board (AR9344, dual-band wifi and AR8327 switch) as an AP. I'll move to using it as my day to day access point and see what happens. Next - those mikrotik boards. And maybe Sean's DIR-825 rev C1. -a From owner-freebsd-embedded@FreeBSD.ORG Sun Mar 2 23:56:19 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D2664517; Sun, 2 Mar 2014 23:56:19 +0000 (UTC) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 10F6B184E; Sun, 2 Mar 2014 23:56:18 +0000 (UTC) Received: by mail-ea0-f177.google.com with SMTP id h10so3984767eak.22 for ; Sun, 02 Mar 2014 15:56:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=r/EEzXsRPt4GOCkAdcyDJVvG3PgQOpvyegLiLjx3MFQ=; b=g9eCkjZ9KGXnmYP7/YwkGBH8H1yFa3F1BXl5mTyP2l4MGNx9dXww9Fz0SW2XRZ/MjH KoEEBN2O4cPjMYNkzjO0wvBi9qJuQGFAZYPGvSPgmRpFbHXJzTEZmJNHOJ+sBIWcK1g5 IFWdztAl7sCCZFYXqX7c17Wln4MvaSlK5EjpzwqwpUzEM3YJ/zomSRo7KGXdE/E0iv3m cgUxPjzx9SwOPlHZ5R9ElEIXgn8zu8PJiqSoMfS/jkdCHReZMEKlKexHgQ/72DKWyGYs B04YLHBYv/sTTdiIbxUTxFhwwYazDyiM/1f8ZcCi48xA3D9H73ZsEOgnxLiXY5eoOoQe Y1Ug== MIME-Version: 1.0 X-Received: by 10.204.81.14 with SMTP id v14mr5909456bkk.3.1393804577340; Sun, 02 Mar 2014 15:56:17 -0800 (PST) Sender: pkelsey@gmail.com Received: by 10.205.71.201 with HTTP; Sun, 2 Mar 2014 15:56:17 -0800 (PST) Date: Sun, 2 Mar 2014 18:56:17 -0500 X-Google-Sender-Auth: 0fIeyW3wagW4_GZIa8h4rRj6W2U Message-ID: Subject: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Patrick Kelsey To: freebsd-embedded@freebsd.org Content-Type: multipart/mixed; boundary=047d7beb9394b8344804f3a86a73 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" , freebsd-arm@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 23:56:19 -0000 --047d7beb9394b8344804f3a86a73 Content-Type: text/plain; charset=ISO-8859-1 Hi, The attached patch (fdt_probe_order_control.patch) allows control over the probe order of simplebus child devices by using a "probe-order" property in simplebus child nodes in the .dts file. This was motivated by booting FreeBSD from the eMMC on a BeagleBone Black, which has a pluggable microSD card slot in addition to the eMMC. The order that the mmc units are defined in sys/boot/fdt/dts/am335x.dtsi causes the pluggable slot to be probed/attached first, so the device name assigned to the eMMC soldered to the board changes depending on whether there is a card in the pluggable slot, which makes establishing appropriate /etc/fstab contents less than convenient. By using the "probe-order" property in sys/boot/fdt/dts/beaglebone-black.dts (see attached beaglebone_black_mmc_probe_order.patch), I am able to swap the order in which the mmc units are probed/attached for that board. This avoids inappropriate hacking of the mmc definition order in am335x.dtsi, which is shared among multiple boards. This is not a general solution to the problem of wanting stable device names for hard-wired MMC devices when pluggable slots are present in the system. There could, for example, be a multi-slot MMC controller with a mixture of hard-wired and pluggable devices attached, and this would not address that case. However, it does address the needs of BeagleBone Black, and the mechanism may be of use for similar issues on other platforms. Both patches were generated against 10-STABLE, r262447. -Patrick --047d7beb9394b8344804f3a86a73 Content-Type: application/octet-stream; name="fdt_probe_order_control.patch" Content-Disposition: attachment; filename="fdt_probe_order_control.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hsaz0nxi0 SW5kZXg6IHN5cy9kZXYvZmR0L3NpbXBsZWJ1cy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9kZXYvZmR0 L3NpbXBsZWJ1cy5jCShyZXZpc2lvbiAyNjI0NDcpCisrKyBzeXMvZGV2L2ZkdC9zaW1wbGVidXMu Ywkod29ya2luZyBjb3B5KQpAQCAtMTYxLDE2ICsxNjEsNjEgQEAKIAlzdHJ1Y3Qgc2ltcGxlYnVz X2RldmluZm8gKmRpOwogCXN0cnVjdCBzaW1wbGVidXNfc29mdGMgKnNjOwogCXBoYW5kbGVfdCBk dF9ub2RlLCBkdF9jaGlsZDsKKyNkZWZpbmUgUFJPQkVfVU5PUkRFUkVEIElOVDMyX01JTgorCWlu dDMyX3QgcHJvYmVfb3JkZXI7CisJc3RydWN0IHNvcnRxX2VudHJ5IHsKKwkJVEFJTFFfRU5UUlko c29ydHFfZW50cnkpIGxpbms7CisJCWludDMyX3QgcHJvYmVfb3JkZXI7CisJCXBoYW5kbGVfdCBk dF9jaGlsZDsKKwl9ICpuZXdfc3FlLCAqc3FlLCAqc3FlX3RtcDsKKwlUQUlMUV9IRUFEKHNvcnRx X2hlYWQsIHNvcnRxX2VudHJ5KSBzcSA9IFRBSUxRX0hFQURfSU5JVElBTElaRVIoc3EpOwogCiAJ c2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CiAKIAkvKgotCSAqIFdhbGsgc2ltcGxlLWJ1cyBh bmQgYWRkIGRpcmVjdCBzdWJvcmRpbmF0ZXMgYXMgb3VyIGNoaWxkcmVuLgorCSAqIFdhbGsgc2lt cGxlLWJ1cyBhbmQgcXVldWUgZGlyZWN0IHN1Ym9yZGluYXRlcyB0byBiZSBhZGRlZCBhcyBvdXIK KwkgKiBjaGlsZHJlbiBiZWxvdywgcmVzcGVjdGluZyBhbnkgc3BlY2lmaWVkIHByb2JlIG9yZGVy aW5nLgogCSAqLwogCWR0X25vZGUgPSBvZndfYnVzX2dldF9ub2RlKGRldik7CiAJZm9yIChkdF9j aGlsZCA9IE9GX2NoaWxkKGR0X25vZGUpOyBkdF9jaGlsZCAhPSAwOwogCSAgICBkdF9jaGlsZCA9 IE9GX3BlZXIoZHRfY2hpbGQpKSB7CiAKKwkJbmV3X3NxZSA9IG1hbGxvYyhzaXplb2YoKnNxZSks IE1fU0lNUExFQlVTLCBNX1dBSVRPSyk7CisJCW5ld19zcWUtPmR0X2NoaWxkID0gZHRfY2hpbGQ7 CisKKwkJLyoKKwkJICogUHJlc2VydmUgdGhlIGV4aXN0aW5nIG9yZGVyLCB1bmxlc3MgdGhpcyBj aGlsZCBoYXMgYQorCQkgKiBzcGVjaWZpZWQgcHJvYmUtb3JkZXIgYW5kIGl0IGlzIGxlc3MgdGhh biB0aGUgc3BlY2lmaWVkCisJCSAqIHByb2JlIG9yZGVyIG9mIGEgcHJldmlvdXMgY2hpbGQsIGlu IHdoaWNoIGNhc2UgdGhpcyBjaGlsZAorCQkgKiBpcyBpbnNlcnRlZCBqdXN0IHByaW9yIHRvIHRo YXQgcHJldmlvdXMgY2hpbGQuCisJCSAqLworCQlpZiAoT0ZfZ2V0cHJvcChkdF9jaGlsZCwgInBy b2JlLW9yZGVyIiwgJnByb2JlX29yZGVyLCBzaXplb2YocHJvYmVfb3JkZXIpKSA+IDApIHsKKwkJ CW5ld19zcWUtPnByb2JlX29yZGVyID0gKGludDMyX3QpZmR0X2RhdGFfZ2V0KCZwcm9iZV9vcmRl ciwgMSk7CisKKwkJCVRBSUxRX0ZPUkVBQ0goc3FlLCAmc3EsIGxpbmspIHsKKwkJCQlpZiAoKFBS T0JFX1VOT1JERVJFRCAhPSBzcWUtPnByb2JlX29yZGVyKSAmJgorCQkJCSAgICAobmV3X3NxZS0+ cHJvYmVfb3JkZXIgPCBzcWUtPnByb2JlX29yZGVyKSkgeworCQkJCQlUQUlMUV9JTlNFUlRfQkVG T1JFKHNxZSwgbmV3X3NxZSwgbGluayk7CisJCQkJCWJyZWFrOworCQkJCX0KKwkJCX0KKworCQkJ aWYgKE5VTEwgPT0gc3FlKSB7CisJCQkJVEFJTFFfSU5TRVJUX1RBSUwoJnNxLCBuZXdfc3FlLCBs aW5rKTsKKwkJCX0KKwkJfSBlbHNlIHsKKwkJCW5ld19zcWUtPnByb2JlX29yZGVyID0gUFJPQkVf VU5PUkRFUkVEOworCQkJVEFJTFFfSU5TRVJUX1RBSUwoJnNxLCBuZXdfc3FlLCBsaW5rKTsKKwkJ fQorCX0KKworCS8qCisJICogQWRkIHRoZSBxdWV1ZWQgc3Vib3JkaW5hdGVzIGFzIGNoaWxkcmVu LgorCSAqLworCVRBSUxRX0ZPUkVBQ0hfU0FGRShzcWUsICZzcSwgbGluaywgc3FlX3RtcCkgewor CQlkdF9jaGlsZCA9IHNxZS0+ZHRfY2hpbGQ7CisJCWZyZWUoc3FlLCBNX1NJTVBMRUJVUyk7CisK IAkJLyogQ2hlY2sgYW5kIHByb2Nlc3MgJ3N0YXR1cycgcHJvcGVydHkuICovCiAJCWlmICghKGZk dF9pc19lbmFibGVkKGR0X2NoaWxkKSkpCiAJCQljb250aW51ZTsK --047d7beb9394b8344804f3a86a73 Content-Type: application/octet-stream; name="beaglebone_black_probe_order.patch" Content-Disposition: attachment; filename="beaglebone_black_probe_order.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hsaz0qzm1 SW5kZXg6IHN5cy9ib290L2ZkdC9kdHMvYmVhZ2xlYm9uZS1ibGFjay5kdHMKPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQot LS0gc3lzL2Jvb3QvZmR0L2R0cy9iZWFnbGVib25lLWJsYWNrLmR0cwkocmV2aXNpb24gMjYyNDQ3 KQorKysgc3lzL2Jvb3QvZmR0L2R0cy9iZWFnbGVib25lLWJsYWNrLmR0cwkod29ya2luZyBjb3B5 KQpAQCAtMTM2LDggKzEzNiwxMiBAQAogCQltbWNoczFANDgxRDgwMDAgewogICAgICAgICAgICAg ICAgIAlidXMtd2lkdGggPSA8OD47CiAJCQlzdGF0dXMgPSAib2theSI7CisJCQlwcm9iZS1vcmRl ciA9IDwxMDAwPjsKIAkJfTsKIAorCQltbWNoczBANDgwNjAwMDAgeworCQkJcHJvYmUtb3JkZXIg PSA8MTAwMT47CisJCX07CiAgCiAJCWkyY0A0NGUwYjAwMCB7CiAJCQlwbWljQDI0IHsK --047d7beb9394b8344804f3a86a73-- From owner-freebsd-embedded@FreeBSD.ORG Mon Mar 3 02:38:15 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9DDEDA14 for ; Mon, 3 Mar 2014 02:38:15 +0000 (UTC) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 644A014AC for ; Mon, 3 Mar 2014 02:38:15 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id rl12so2285160iec.32 for ; Sun, 02 Mar 2014 18:38:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=2sMHPLd4EibfAk/WkktsSivFvzO+978wges/RFSKv48=; b=IuXutxMPkAHT+pPEzid7hMxepYPAxinUQTei7sQbRXzcF00bPcAFwxJftHGGrn3pDU Xqt27sPqz15h6YL9vK9zXNm0a7gX3q99Gs09AqP1/7Zh1tw8lORL71CKZhiIbP0kbIAW g8sDqVc4BItWKPtuccEZuwixmgv1CreUMsQDVJxTXiAOTYBRWSRWsaM/OtFDgAnAnnhp 1dRyl7TCrwPsSmLhzaCWgW0D1XkCqV6h25th+taUXd/dHww3jrFT8/mYJ3/+X53ElMIP GyLdfG8WsyTmWddb8EfTZr/runLk7w31hG7QwqRRtRPmVYgzoLQCDVa8Z3ov9LOhdGbd gkxw== X-Gm-Message-State: ALoCoQnXa/VPVOzjaJgMqm5xL75+QjBzfy4TkTvlYIFBP8bUfmwHMQ1wcwhbscu1goas32WDlADl X-Received: by 10.43.155.209 with SMTP id lj17mr95356icc.94.1393814289789; Sun, 02 Mar 2014 18:38:09 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id sc8sm34675367igb.0.2014.03.02.18.38.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Mar 2014 18:38:09 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Warner Losh In-Reply-To: Date: Sun, 2 Mar 2014 19:38:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> References: To: Patrick Kelsey X-Mailer: Apple Mail (2.1874) Cc: "freebsd-hackers@freebsd.org" , freebsd-arm@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 02:38:15 -0000 On Mar 2, 2014, at 4:56 PM, Patrick Kelsey wrote: > Hi, >=20 > The attached patch (fdt_probe_order_control.patch) allows control over = the > probe order of simplebus child devices by using a "probe-order" = property in > simplebus child nodes in the .dts file Where is the probe-order property defined? I can=92t seem to find it in = the bindings. Also, I don=92t think it is necessary. This is a software construct, so = doesn=92t really belong in the dts file. I=92d really like to avoid FreeBSD specific = hacks in the DTS files. > This was motivated by booting FreeBSD from the eMMC on a BeagleBone = Black, > which has a pluggable microSD card slot in addition to the eMMC. The = order > that the mmc units are defined in sys/boot/fdt/dts/am335x.dtsi causes = the > pluggable slot to be probed/attached first, so the device name = assigned to > the eMMC soldered to the board changes depending on whether there is a = card > in the pluggable slot, which makes establishing appropriate /etc/fstab > contents less than convenient. Sounds like you=92d like to have some sort of name to instance mapping. The typical way this is solved is by naming the partitions so that = ordering doesn=92t matter. Even if you don=92t handle this at the filesystem = level, which is how others cope, you=92d want this to be more of a direct binding = rather than an ordering so that you get the effect you want (constant name) directly, = rather than as a side-effect of ordering. If you insist on that, then having a something more like = =93freesbd,unit-number=94 property would also accomplish this. But that would only wire the = controller unit number, and not the resulting mmcsdX device. > By using the "probe-order" property in > sys/boot/fdt/dts/beaglebone-black.dts (see attached > beaglebone_black_mmc_probe_order.patch), I am able to swap the order = in > which the mmc units are probed/attached for that board. This avoids > inappropriate hacking of the mmc definition order in am335x.dtsi, = which is > shared among multiple boards. >=20 > This is not a general solution to the problem of wanting stable device > names for hard-wired MMC devices when pluggable slots are present in = the > system. There could, for example, be a multi-slot MMC controller with = a > mixture of hard-wired and pluggable devices attached, and this would = not > address that case. However, it does address the needs of BeagleBone = Black, > and the mechanism may be of use for similar issues on other platforms. As it isn=92t a generic solution, I=92d be biased against adopting it. = What=92s wrong with using glabel to accomplish this (either with a label specific = property, or by using a ufs label and mounting /dev/ufs/foo). Warner > Both patches were generated against 10-STABLE, r262447. >=20 > -Patrick > = _______= ________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-embedded@FreeBSD.ORG Mon Mar 3 07:40:18 2014 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54446393; Mon, 3 Mar 2014 07:40:18 +0000 (UTC) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EC1A63EB; Mon, 3 Mar 2014 07:40:17 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id ar20so603435iec.30 for ; Sun, 02 Mar 2014 23:40:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PKpK/B01s6I7GcDkjM7cbaMvBaxPhT1keHDjsu7wPQw=; b=agd7ZP75QEqhDq5Nbq6YwxNLGsYqIGlKLlNcHSfxqqqJRg8w9Iq2YSAKAkM8y5CwJU wfpjNHnp9Sh93L8hkis+YXjbLsyOZydvPH+iLrbY1EKEJHGFqezavSBl+fzT8DzbxRy9 Ghs2N4rgnq9MI0uCjc9yTFiJhF+nNhFLXRdZ9+96ZGW9s91Z4Wpn/oXkQtc8ior+WZE0 GpyIqvAv/I4fj+a0Dh/VDyPwcPVDhT/nV7bT1lzVZzugdoq1nIGN3mEfVbRMhdlFVgi6 EJ7/keqA+nCsuQLhgJcgTHB1olS6iFUpqm5X6jVdqfcvhQ63lzM0c8Fud38fX/lZHDJl p7Kw== MIME-Version: 1.0 X-Received: by 10.50.111.226 with SMTP id il2mr19872147igb.15.1393832417380; Sun, 02 Mar 2014 23:40:17 -0800 (PST) Received: by 10.64.107.3 with HTTP; Sun, 2 Mar 2014 23:40:17 -0800 (PST) In-Reply-To: References: <201402281829.s1SITAQk019090@svn.freebsd.org> Date: Mon, 3 Mar 2014 15:40:17 +0800 Message-ID: Subject: Re: svn commit: r262614 - in head: . share/mk sys/boot/fdt/dts sys/boot/fdt/dts/arm sys/boot/fdt/dts/mips sys/boot/fdt/dts/powerpc sys/conf sys/tools/fdt From: Ganbold Tsagaankhuu To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm , embedded@freebsd.org, mips@freebsd.org, powerpc@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 07:40:18 -0000 Hi, On Sat, Mar 1, 2014 at 2:38 AM, Warner Losh wrote: > Greetings, > > This commit changes how we do DTS -> DTB compiling. For the most part, it > should be a NOP, if all my tests are good, but I may have oopsed somethin= g > without realizing it. > > This commit does switch us back to the GPL dtc. That cannot be helped. Th= e > BSDL one was too far away from working, but if that status ever changes, > I'm > happy to change the defaults back. This change was discussed by most of t= he > major workers in arm@ and mips@ land before changing back, and they felt, > as I do, that using vendor dts files unmodified was a bigger win for > embedded > than the regression back to a GPL'd piece of software when the BSDL'd one > isn't up to the task today of coping with this new world order. If that > changes, > then I'd be happy to switch back. > > Hope this doesn't break anybody. I'll be around if it does. > It seems crashing when building kernel for cubieboard2. Part of build log: -------------------------------------------------------------- >>> stage 3.1: making dependencies -------------------------------------------------------------- cd /usr/obj/arm.armv6/usr/src/sys/CUBIEBOARD2; MAKEOBJDIRPREFIX=3D/usr/obj/arm.armv6 MACHINE_ARCH=3Darmv6 MACHINE=3Darm CPUTYPE=3D GROFF_BIN_PATH=3D/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=3D/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/share/groff_fo= nt GROFF_TMAC_PATH=3D/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=3D/usr/obj/arm.armv6/usr/src/tmp _LDSCRIPTROOT=3D VERSION=3D"FreeBSD 11.0-CURRENT armv6 1100010" INSTALL=3D"sh /usr/src/tools/install.sh" PATH=3D/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/sbin:/usr/obj/arm.armv6/u= sr/src/tmp/legacy/usr/bin:/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/games:/= usr/obj/arm.armv6/usr/src/tmp/legacy/bin:/usr/obj/arm.armv6/usr/src/tmp/usr= /sbin:/usr/obj/arm.armv6/usr/src/tmp/usr/bin:/usr/obj/arm.armv6/usr/src/tmp= /usr/games:/sbin:/bin:/usr/sbin:/usr/bin CC=3D"cc " CXX=3D"c++ " CPP=3D"cpp " AS=3D"as" AR=3D"ar" LD=3D"ld" NM=3Dn= m OBJDUMP=3D RANLIB=3Dranlib STRINGS=3D COMPILER_TYPE=3Dclang make -m /usr/src/share/mk KERNEL=3Dkernel depend -DNO_MODULES_OBJ machine -> /usr/src/sys/arm/include awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h cc -c -O -pipe -std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-unused-function -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/dev/cxgb -I/usr/src/sys/dev/cxgbe -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding /usr/src/sys/arm/arm/genassym.c NM=3D'nm' sh /usr/src/sys/kern/genassym.sh genassym.o > assym.s awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -p awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -q awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -h sh /usr/src/sys/tools/fdt/make_dtb.sh /usr/src/sys cubieboard2.dts /usr/obj/arm.armv6/usr/src/sys/CUBIEBOARD2/cubieboard2.dtb Segmentation fault (core dumped) *** Error code 139 Stop. make: stopped in /usr/obj/arm.armv6/usr/src/sys/CUBIEBOARD2 *** Error code 1 Stop. make: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src root@bsd:/usr/src # sh /usr/src/sys/tools/fdt/make_dtb.sh /usr/src/sys cubieboard2.dts /usr/obj/arm.armv6/usr/src/sys/CUBIEBOARD2/cubieboard2.dtb :158:10: fatal error: 'cubieboard2.dts' file not found #include "cubieboard2.dts" ^ 1 error generated. Segmentation fault (core dumped) Ganbold > > Warner > > Begin forwarded message: > > > From: Warner Losh > > Subject: svn commit: r262614 - in head: . share/mk sys/boot/fdt/dts > sys/boot/fdt/dts/arm sys/boot/fdt/dts/mips sys/boot/fdt/dts/powerpc > sys/conf sys/tools/fdt > > Date: February 28, 2014 at 11:29:10 AM MST > > To: src-committers@freebsd.org, svn-src-all@freebsd.org, > svn-src-head@freebsd.org > > > > Author: imp > > Date: Fri Feb 28 18:29:09 2014 > > New Revision: 262614 > > URL: http://svnweb.freebsd.org/changeset/base/262614 > > > > Log: > > Integrate device-tree upstream files into the build process: > > (1) Invoke cpp to bring in files via #include (although the old > > /include/ stuff is supported still). > > (2) bring in files from either vendor tree or freebsd-custom files > > when building. > > (3) move all dts* files from sys/boot/fdt/dts to > > sys/boot/fdt/dts/${MACHINE} as appropriate. > > (4) encode all the magic to do the build in sys/tools/fdt/make_dtb.sh > > so that the different places in the tree use the exact same logic. > > (5) switch back to gpl dtc by default. the bsdl one in the tree has > > significant issues not easily addressed by those unfamiliar with > > the code. > > > > Added: > > head/sys/boot/fdt/dts/arm/ > > head/sys/boot/fdt/dts/arm/am335x-evm.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/am335x-evm.dt= s > > head/sys/boot/fdt/dts/arm/am335x.dtsi > > - copied, changed from r262613, head/sys/boot/fdt/dts/am335x.dtsi > > head/sys/boot/fdt/dts/arm/bcm2835.dtsi > > - copied, changed from r262613, head/sys/boot/fdt/dts/bcm2835.dtsi > > head/sys/boot/fdt/dts/arm/beaglebone-black.dts > > - copied, changed from r262613, > head/sys/boot/fdt/dts/beaglebone-black.dts > > head/sys/boot/fdt/dts/arm/beaglebone.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/beaglebone.dt= s > > head/sys/boot/fdt/dts/arm/cubieboard.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/cubieboard.dt= s > > head/sys/boot/fdt/dts/arm/cubieboard2.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/cubieboard2.d= ts > > head/sys/boot/fdt/dts/arm/db78100.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/db78100.dts > > head/sys/boot/fdt/dts/arm/db78460.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/db78460.dts > > head/sys/boot/fdt/dts/arm/db88f5182.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/db88f5182.dts > > head/sys/boot/fdt/dts/arm/db88f5281.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/db88f5281.dts > > head/sys/boot/fdt/dts/arm/db88f6281.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/db88f6281.dts > > head/sys/boot/fdt/dts/arm/digi-ccwmx53.dts > > - copied, changed from r262613, > head/sys/boot/fdt/dts/digi-ccwmx53.dts > > head/sys/boot/fdt/dts/arm/dockstar.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/dockstar.dts > > head/sys/boot/fdt/dts/arm/dreamplug-1001.dts > > - copied, changed from r262613, > head/sys/boot/fdt/dts/dreamplug-1001.dts > > head/sys/boot/fdt/dts/arm/dreamplug-1001N.dts > > - copied, changed from r262613, > head/sys/boot/fdt/dts/dreamplug-1001N.dts > > head/sys/boot/fdt/dts/arm/ea3250.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/ea3250.dts > > head/sys/boot/fdt/dts/arm/efikamx.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/efikamx.dts > > head/sys/boot/fdt/dts/arm/exynos5250-arndale.dts > > - copied, changed from r262613, > head/sys/boot/fdt/dts/exynos5250-arndale.dts > > head/sys/boot/fdt/dts/arm/exynos5250.dtsi > > - copied, changed from r262613, head/sys/boot/fdt/dts/exynos5250.dt= si > > head/sys/boot/fdt/dts/arm/imx51x.dtsi > > - copied, changed from r262613, head/sys/boot/fdt/dts/imx51x.dtsi > > head/sys/boot/fdt/dts/arm/imx53-qsb.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/imx53-qsb.dts > > head/sys/boot/fdt/dts/arm/imx53x.dtsi > > - copied, changed from r262613, head/sys/boot/fdt/dts/imx53x.dtsi > > head/sys/boot/fdt/dts/arm/imx6.dtsi > > - copied, changed from r262613, head/sys/boot/fdt/dts/imx6.dtsi > > head/sys/boot/fdt/dts/arm/p1020rdb.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/p1020rdb.dts > > head/sys/boot/fdt/dts/arm/p2020ds.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/p2020ds.dts > > head/sys/boot/fdt/dts/arm/p2041rdb.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/p2041rdb.dts > > head/sys/boot/fdt/dts/arm/p2041si.dtsi > > - copied, changed from r262613, head/sys/boot/fdt/dts/p2041si.dtsi > > head/sys/boot/fdt/dts/arm/p3041ds.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/p3041ds.dts > > head/sys/boot/fdt/dts/arm/p3041si.dtsi > > - copied, changed from r262613, head/sys/boot/fdt/dts/p3041si.dtsi > > head/sys/boot/fdt/dts/arm/p5020ds.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/p5020ds.dts > > head/sys/boot/fdt/dts/arm/p5020si.dtsi > > - copied, changed from r262613, head/sys/boot/fdt/dts/p5020si.dtsi > > head/sys/boot/fdt/dts/arm/pandaboard.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/pandaboard.dt= s > > head/sys/boot/fdt/dts/arm/rk3188-radxa.dts > > - copied, changed from r262613, > head/sys/boot/fdt/dts/rk3188-radxa.dts > > head/sys/boot/fdt/dts/arm/rk3188.dtsi > > - copied, changed from r262613, head/sys/boot/fdt/dts/rk3188.dtsi > > head/sys/boot/fdt/dts/arm/rpi.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/rpi.dts > > head/sys/boot/fdt/dts/arm/sheevaplug.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/sheevaplug.dt= s > > head/sys/boot/fdt/dts/arm/tegra20-paz00.dts > > - copied, changed from r262613, > head/sys/boot/fdt/dts/tegra20-paz00.dts > > head/sys/boot/fdt/dts/arm/tegra20.dtsi > > - copied, changed from r262613, head/sys/boot/fdt/dts/tegra20.dtsi > > head/sys/boot/fdt/dts/arm/trimslice.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/trimslice.dts > > head/sys/boot/fdt/dts/arm/ts7800.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/ts7800.dts > > head/sys/boot/fdt/dts/arm/versatilepb.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/versatilepb.d= ts > > head/sys/boot/fdt/dts/arm/vybrid-colibri-vf50.dts > > - copied, changed from r262613, > head/sys/boot/fdt/dts/vybrid-colibri-vf50.dts > > head/sys/boot/fdt/dts/arm/vybrid-cosmic.dts > > - copied, changed from r262613, > head/sys/boot/fdt/dts/vybrid-cosmic.dts > > head/sys/boot/fdt/dts/arm/vybrid-quartz.dts > > - copied, changed from r262613, > head/sys/boot/fdt/dts/vybrid-quartz.dts > > head/sys/boot/fdt/dts/arm/vybrid.dtsi > > - copied, changed from r262613, head/sys/boot/fdt/dts/vybrid.dtsi > > head/sys/boot/fdt/dts/arm/wandboard-dual.dts > > - copied, changed from r262613, > head/sys/boot/fdt/dts/wandboard-dual.dts > > head/sys/boot/fdt/dts/arm/wandboard-quad.dts > > - copied, changed from r262613, > head/sys/boot/fdt/dts/wandboard-quad.dts > > head/sys/boot/fdt/dts/arm/wandboard-solo.dts > > - copied, changed from r262613, > head/sys/boot/fdt/dts/wandboard-solo.dts > > head/sys/boot/fdt/dts/arm/zedboard.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/zedboard.dts > > head/sys/boot/fdt/dts/mips/ > > head/sys/boot/fdt/dts/mips/beri-netfpga.dts > > - copied, changed from r262613, > head/sys/boot/fdt/dts/beri-netfpga.dts > > head/sys/boot/fdt/dts/mips/beri-sim.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/beri-sim.dts > > head/sys/boot/fdt/dts/mips/beripad-de4.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/beripad-de4.d= ts > > head/sys/boot/fdt/dts/mips/xlp-basic.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/xlp-basic.dts > > head/sys/boot/fdt/dts/powerpc/ > > head/sys/boot/fdt/dts/powerpc/mpc8555cds.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/mpc8555cds.dt= s > > head/sys/boot/fdt/dts/powerpc/mpc8572ds.dts > > - copied, changed from r262613, head/sys/boot/fdt/dts/mpc8572ds.dts > > head/sys/tools/fdt/make_dtb.sh (contents, props changed) > > Deleted: > > head/sys/boot/fdt/dts/am335x-evm.dts > > head/sys/boot/fdt/dts/am335x.dtsi > > head/sys/boot/fdt/dts/bcm2835.dtsi > > head/sys/boot/fdt/dts/beaglebone-black.dts > > head/sys/boot/fdt/dts/beaglebone.dts > > head/sys/boot/fdt/dts/beri-netfpga.dts > > head/sys/boot/fdt/dts/beri-sim.dts > > head/sys/boot/fdt/dts/beripad-de4.dts > > head/sys/boot/fdt/dts/cubieboard.dts > > head/sys/boot/fdt/dts/cubieboard2.dts > > head/sys/boot/fdt/dts/db78100.dts > > head/sys/boot/fdt/dts/db78460.dts > > head/sys/boot/fdt/dts/db88f5182.dts > > head/sys/boot/fdt/dts/db88f5281.dts > > head/sys/boot/fdt/dts/db88f6281.dts > > head/sys/boot/fdt/dts/digi-ccwmx53.dts > > head/sys/boot/fdt/dts/dockstar.dts > > head/sys/boot/fdt/dts/dreamplug-1001.dts > > head/sys/boot/fdt/dts/dreamplug-1001N.dts > > head/sys/boot/fdt/dts/ea3250.dts > > head/sys/boot/fdt/dts/efikamx.dts > > head/sys/boot/fdt/dts/exynos5250-arndale.dts > > head/sys/boot/fdt/dts/exynos5250.dtsi > > head/sys/boot/fdt/dts/imx51x.dtsi > > head/sys/boot/fdt/dts/imx53-qsb.dts > > head/sys/boot/fdt/dts/imx53x.dtsi > > head/sys/boot/fdt/dts/imx6.dtsi > > head/sys/boot/fdt/dts/mpc8555cds.dts > > head/sys/boot/fdt/dts/mpc8572ds.dts > > head/sys/boot/fdt/dts/p1020rdb.dts > > head/sys/boot/fdt/dts/p2020ds.dts > > head/sys/boot/fdt/dts/p2041rdb.dts > > head/sys/boot/fdt/dts/p2041si.dtsi > > head/sys/boot/fdt/dts/p3041ds.dts > > head/sys/boot/fdt/dts/p3041si.dtsi > > head/sys/boot/fdt/dts/p5020ds.dts > > head/sys/boot/fdt/dts/p5020si.dtsi > > head/sys/boot/fdt/dts/pandaboard.dts > > head/sys/boot/fdt/dts/rk3188-radxa.dts > > head/sys/boot/fdt/dts/rk3188.dtsi > > head/sys/boot/fdt/dts/rpi.dts > > head/sys/boot/fdt/dts/sheevaplug.dts > > head/sys/boot/fdt/dts/tegra20-paz00.dts > > head/sys/boot/fdt/dts/tegra20.dtsi > > head/sys/boot/fdt/dts/trimslice.dts > > head/sys/boot/fdt/dts/ts7800.dts > > head/sys/boot/fdt/dts/versatilepb.dts > > head/sys/boot/fdt/dts/vybrid-colibri-vf50.dts > > head/sys/boot/fdt/dts/vybrid-cosmic.dts > > head/sys/boot/fdt/dts/vybrid-quartz.dts > > head/sys/boot/fdt/dts/vybrid.dtsi > > head/sys/boot/fdt/dts/wandboard-dual.dts > > head/sys/boot/fdt/dts/wandboard-quad.dts > > head/sys/boot/fdt/dts/wandboard-solo.dts > > head/sys/boot/fdt/dts/xlp-basic.dts > > head/sys/boot/fdt/dts/zedboard.dts > > Modified: > > head/Makefile.inc1 > > head/share/mk/bsd.own.mk > > head/sys/conf/files > > > > Modified: head/Makefile.inc1 > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > --- head/Makefile.inc1 Fri Feb 28 18:06:00 2014 (r262613) > > +++ head/Makefile.inc1 Fri Feb 28 18:29:09 2014 (r262614) > > @@ -1262,7 +1262,7 @@ _dtrace_tools=3D cddl/usr.bin/sgsmsg cddl/ > > lib/libdwarf cddl/usr.bin/ctfconvert cddl/usr.bin/ctfmerge > > .endif > > > > -# Default to building the BSDL DTC, but build the GPL one if users > explicitly > > +# Default to building the GPL DTC, but build the BSDL one if users > explicitly > > # request it. > > _dtc=3D usr.bin/dtc > > .if ${MK_GPL_DTC} !=3D "no" > > @@ -1853,7 +1853,7 @@ builddtb: > > echo "ERROR: FDT_DTS_FILE must be specified!"; \ > > exit 1; \ > > fi; \ > > - if [ ! -f ${.CURDIR}/sys/boot/fdt/dts/${FDT_DTS_FILE} ]; then \ > > + if [ ! -f ${.CURDIR}/sys/boot/fdt/dts/${MACHINE}/${FDT_DTS_FILE} > ]; then \ > > echo "ERROR: Specified DTS file (${FDT_DTS_FILE}) does no= t > \ > > exist!"; \ > > exit 1; \ > > @@ -1863,9 +1863,9 @@ builddtb: > > directory"; \ > > fi > > @PATH=3D${TMPPATH} \ > > - dtc -O dtb -o \ > > - ${DTBOUTPUTPATH}/`echo ${FDT_DTS_FILE} | cut -d. -f1`.dtb -b = 0 > \ > > - -p 1024 ${.CURDIR}/sys/boot/fdt/dts/${FDT_DTS_FILE} > > + ${.CURDIR}/sys/tools/fdt/make_dtb.sh ${.CURDIR}/sys \ > > + ${FDT_DTS_FILE} \ > > + ${DTBOUTPUTPATH}/`basename ${FDT_DTS_FILE} .dts` > > > > ############### > > > > > > Modified: head/share/mk/bsd.own.mk > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > --- head/share/mk/bsd.own.mk Fri Feb 28 18:06:00 2014 (r262613) > > +++ head/share/mk/bsd.own.mk Fri Feb 28 18:29:09 2014 (r262614) > > @@ -287,6 +287,7 @@ __DEFAULT_YES_OPTIONS =3D \ > > GNU \ > > GPIB \ > > GPIO \ > > + GPL_DTC \ > > GROFF \ > > HTML \ > > ICONV \ > > @@ -368,7 +369,6 @@ __DEFAULT_NO_OPTIONS =3D \ > > CLANG_EXTRAS \ > > CTF \ > > DEBUG_FILES \ > > - GPL_DTC \ > > HESIOD \ > > INSTALL_AS_USER \ > > LLDB \ > > > > Copied and modified: head/sys/boot/fdt/dts/arm/am335x-evm.dts (from > r262613, head/sys/boot/fdt/dts/am335x-evm.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/am335x.dtsi (from > r262613, head/sys/boot/fdt/dts/am335x.dtsi) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/bcm2835.dtsi (from > r262613, head/sys/boot/fdt/dts/bcm2835.dtsi) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/beaglebone-black.dts > (from r262613, head/sys/boot/fdt/dts/beaglebone-black.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/beaglebone.dts (from > r262613, head/sys/boot/fdt/dts/beaglebone.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/cubieboard.dts (from > r262613, head/sys/boot/fdt/dts/cubieboard.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/cubieboard2.dts (from > r262613, head/sys/boot/fdt/dts/cubieboard2.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/db78100.dts (from > r262613, head/sys/boot/fdt/dts/db78100.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/db78460.dts (from > r262613, head/sys/boot/fdt/dts/db78460.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/db88f5182.dts (from > r262613, head/sys/boot/fdt/dts/db88f5182.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/db88f5281.dts (from > r262613, head/sys/boot/fdt/dts/db88f5281.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/db88f6281.dts (from > r262613, head/sys/boot/fdt/dts/db88f6281.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/digi-ccwmx53.dts (from > r262613, head/sys/boot/fdt/dts/digi-ccwmx53.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/dockstar.dts (from > r262613, head/sys/boot/fdt/dts/dockstar.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/dreamplug-1001.dts (from > r262613, head/sys/boot/fdt/dts/dreamplug-1001.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/dreamplug-1001N.dts (fro= m > r262613, head/sys/boot/fdt/dts/dreamplug-1001N.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/ea3250.dts (from r262613= , > head/sys/boot/fdt/dts/ea3250.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/efikamx.dts (from > r262613, head/sys/boot/fdt/dts/efikamx.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/exynos5250-arndale.dts > (from r262613, head/sys/boot/fdt/dts/exynos5250-arndale.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/exynos5250.dtsi (from > r262613, head/sys/boot/fdt/dts/exynos5250.dtsi) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/imx51x.dtsi (from > r262613, head/sys/boot/fdt/dts/imx51x.dtsi) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/imx53-qsb.dts (from > r262613, head/sys/boot/fdt/dts/imx53-qsb.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/imx53x.dtsi (from > r262613, head/sys/boot/fdt/dts/imx53x.dtsi) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/imx6.dtsi (from r262613, > head/sys/boot/fdt/dts/imx6.dtsi) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/p1020rdb.dts (from > r262613, head/sys/boot/fdt/dts/p1020rdb.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/p2020ds.dts (from > r262613, head/sys/boot/fdt/dts/p2020ds.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/p2041rdb.dts (from > r262613, head/sys/boot/fdt/dts/p2041rdb.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/p2041si.dtsi (from > r262613, head/sys/boot/fdt/dts/p2041si.dtsi) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/p3041ds.dts (from > r262613, head/sys/boot/fdt/dts/p3041ds.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/p3041si.dtsi (from > r262613, head/sys/boot/fdt/dts/p3041si.dtsi) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/p5020ds.dts (from > r262613, head/sys/boot/fdt/dts/p5020ds.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/p5020si.dtsi (from > r262613, head/sys/boot/fdt/dts/p5020si.dtsi) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/pandaboard.dts (from > r262613, head/sys/boot/fdt/dts/pandaboard.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/rk3188-radxa.dts (from > r262613, head/sys/boot/fdt/dts/rk3188-radxa.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/rk3188.dtsi (from > r262613, head/sys/boot/fdt/dts/rk3188.dtsi) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/rpi.dts (from r262613, > head/sys/boot/fdt/dts/rpi.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/sheevaplug.dts (from > r262613, head/sys/boot/fdt/dts/sheevaplug.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/tegra20-paz00.dts (from > r262613, head/sys/boot/fdt/dts/tegra20-paz00.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/tegra20.dtsi (from > r262613, head/sys/boot/fdt/dts/tegra20.dtsi) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/trimslice.dts (from > r262613, head/sys/boot/fdt/dts/trimslice.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/ts7800.dts (from r262613= , > head/sys/boot/fdt/dts/ts7800.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/versatilepb.dts (from > r262613, head/sys/boot/fdt/dts/versatilepb.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/vybrid-colibri-vf50.dts > (from r262613, head/sys/boot/fdt/dts/vybrid-colibri-vf50.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/vybrid-cosmic.dts (from > r262613, head/sys/boot/fdt/dts/vybrid-cosmic.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/vybrid-quartz.dts (from > r262613, head/sys/boot/fdt/dts/vybrid-quartz.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/vybrid.dtsi (from > r262613, head/sys/boot/fdt/dts/vybrid.dtsi) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/wandboard-dual.dts (from > r262613, head/sys/boot/fdt/dts/wandboard-dual.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/wandboard-quad.dts (from > r262613, head/sys/boot/fdt/dts/wandboard-quad.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/wandboard-solo.dts (from > r262613, head/sys/boot/fdt/dts/wandboard-solo.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/arm/zedboard.dts (from > r262613, head/sys/boot/fdt/dts/zedboard.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/mips/beri-netfpga.dts (from > r262613, head/sys/boot/fdt/dts/beri-netfpga.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/mips/beri-sim.dts (from > r262613, head/sys/boot/fdt/dts/beri-sim.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/mips/beripad-de4.dts (from > r262613, head/sys/boot/fdt/dts/beripad-de4.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/mips/xlp-basic.dts (from > r262613, head/sys/boot/fdt/dts/xlp-basic.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/powerpc/mpc8555cds.dts (from > r262613, head/sys/boot/fdt/dts/mpc8555cds.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Copied and modified: head/sys/boot/fdt/dts/powerpc/mpc8572ds.dts (from > r262613, head/sys/boot/fdt/dts/mpc8572ds.dts) > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > Modified: head/sys/conf/files > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > --- head/sys/conf/files Fri Feb 28 18:06:00 2014 (r262613) > > +++ head/sys/conf/files Fri Feb 28 18:29:09 2014 (r262614) > > @@ -14,11 +14,12 @@ acpi_quirks.h optional acpi > \ > > # from the specified source (DTS) file: .dts -> .dt= b > > # > > fdt_dtb_file optional fdt \ > > - compile-with "if [ -f $S/boot/fdt/dts/${FDT_DTS_FILE} ]; then dtc > -O dtb -o ${FDT_DTS_FILE:R}.dtb -b 0 -p 1024 > $S/boot/fdt/dts/${FDT_DTS_FILE}; fi" \ > > + compile-with "sh $S/tools/fdt/make_dtb.sh $S ${FDT_DTS_FILE} > ${.CURDIR}/${FDT_DTS_FILE:R}.dtb" \ > > no-obj no-implicit-rule before-depend \ > > clean "${FDT_DTS_FILE:R}.dtb" > > fdt_static_dtb.h optional fdt fdt_dtb_static \ > > - compile-with "sh $S/tools/fdt/make_dtbh.sh ${FDT_DTS_FILE} ." \ > > + compile-with "sh $S/tools/fdt/make_dtbh.sh ${FDT_DTS_FILE} > ${.CURDIR}" \ > > + dependency "fdt_dtb_file" \ > > no-obj no-implicit-rule before-depend \ > > clean "fdt_static_dtb.h" > > feeder_eq_gen.h optional sound > \ > > @@ -1370,7 +1371,7 @@ dev/fb/splash.c optional sc splas= h > > dev/fdt/fdt_common.c optional fdt > > dev/fdt/fdt_slicer.c optional fdt cfi | fdt nand > > dev/fdt/fdt_static_dtb.S optional fdt fdt_dtb_static \ > > - dependency "$S/boot/fdt/dts/${FDT_DTS_FILE}" > > + dependency "$S/boot/fdt/dts/${MACHINE}/${FDT_DTS_FILE}" > > dev/fdt/simplebus.c optional fdt > > dev/fe/if_fe.c optional fe > > dev/fe/if_fe_pccard.c optional fe pccard > > > > Added: head/sys/tools/fdt/make_dtb.sh > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > --- /dev/null 00:00:00 1970 (empty, because file is newly added) > > +++ head/sys/tools/fdt/make_dtb.sh Fri Feb 28 18:29:09 2014 > (r262614) > > @@ -0,0 +1,11 @@ > > +#!/bin/sh > > +# > > +# $FreeBSD$ > > + > > +# Script generates dtb file ($3) from dts source ($2) in build tree S > ($1) > > +S=3D$1 > > +dts=3D$2 > > +dtb=3D$3 > > + > > +cpp -x assembler-with-cpp -I $S/gnu/dts/include -I > $S/boot/fdt/dts/${MACHINE} -I $S/gnu/dts/${MACHINE} -include $dts /dev/nu= ll > | > > + dtc -O dtb -o $dtb -b 0 -p 1024 -i $S/boot/fdt/dts -i > $S/gnu/dts/${MACHINE} > > > > _______________________________________________ > freebsd-mips@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" > From owner-freebsd-embedded@FreeBSD.ORG Mon Mar 3 08:44:12 2014 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 797CCFEF; Mon, 3 Mar 2014 08:44:12 +0000 (UTC) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1C4DDB1E; Mon, 3 Mar 2014 08:44:12 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id lx4so1312074iec.9 for ; Mon, 03 Mar 2014 00:44:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BDg11Jj52PUCaqZIvLHLXN1rO0gIzuDSJNdVcRWuDYc=; b=mSByb1iD3U4zx0JwHlmjc1CMNIDuZiM+FeAixZ8fspG9hFgkieUZj94Mfa6vtqUQNt 4VJzJ1Frixo0w7T0UFJ306rmbrTj3gd2O82PIhEGEEGwEtKIn6Uo9vF9okmCaatxQNzZ 4Ct7C/GzacjME+kKfp1W/boY0jJqkkHuAQfluMIKWkGfLta46YWawYYZTJ+QHlFoKjIi We2P4EMaVR9BatwminJZZ+gVBQ5UYq282fZmhckLwJFI0vtArgYK+kRY7i0mhs7LCvRN nTjNkh+VX7/2tD8n2jIPy0DYdPeyMQx72gxq4oWiTCaf8i6IFoYgmiUzsaWXR1wC9qNu HFrw== MIME-Version: 1.0 X-Received: by 10.51.17.104 with SMTP id gd8mr20406337igd.48.1393836251474; Mon, 03 Mar 2014 00:44:11 -0800 (PST) Received: by 10.64.107.3 with HTTP; Mon, 3 Mar 2014 00:44:11 -0800 (PST) In-Reply-To: References: <201402281829.s1SITAQk019090@svn.freebsd.org> Date: Mon, 3 Mar 2014 16:44:11 +0800 Message-ID: Subject: Re: svn commit: r262614 - in head: . share/mk sys/boot/fdt/dts sys/boot/fdt/dts/arm sys/boot/fdt/dts/mips sys/boot/fdt/dts/powerpc sys/conf sys/tools/fdt From: Ganbold Tsagaankhuu To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm , embedded@freebsd.org, mips@freebsd.org, powerpc@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 08:44:12 -0000 On Mon, Mar 3, 2014 at 3:40 PM, Ganbold Tsagaankhuu wrot= e: > Hi, > > On Sat, Mar 1, 2014 at 2:38 AM, Warner Losh wrote: > >> Greetings, >> >> This commit changes how we do DTS -> DTB compiling. For the most part, i= t >> should be a NOP, if all my tests are good, but I may have oopsed somethi= ng >> without realizing it. >> >> This commit does switch us back to the GPL dtc. That cannot be helped. T= he >> BSDL one was too far away from working, but if that status ever changes, >> I'm >> happy to change the defaults back. This change was discussed by most of >> the >> major workers in arm@ and mips@ land before changing back, and they felt= , >> as I do, that using vendor dts files unmodified was a bigger win for >> embedded >> than the regression back to a GPL'd piece of software when the BSDL'd on= e >> isn't up to the task today of coping with this new world order. If that >> changes, >> then I'd be happy to switch back. >> >> Hope this doesn't break anybody. I'll be around if it does. >> > > > It seems crashing when building kernel for cubieboard2. > > Part of build log: > > -------------------------------------------------------------- > >>> stage 3.1: making dependencies > -------------------------------------------------------------- > cd /usr/obj/arm.armv6/usr/src/sys/CUBIEBOARD2; > MAKEOBJDIRPREFIX=3D/usr/obj/arm.armv6 MACHINE_ARCH=3Darmv6 MACHINE=3Dar= m > CPUTYPE=3D GROFF_BIN_PATH=3D/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/bi= n > GROFF_FONT_PATH=3D/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/share/groff_= font > GROFF_TMAC_PATH=3D/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/share/tmac > _SHLIBDIRPREFIX=3D/usr/obj/arm.armv6/usr/src/tmp _LDSCRIPTROOT=3D > VERSION=3D"FreeBSD 11.0-CURRENT armv6 1100010" INSTALL=3D"sh > /usr/src/tools/install.sh" > PATH=3D/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/sbin:/usr/obj/arm.armv6= /usr/src/tmp/legacy/usr/bin:/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/games= :/usr/obj/arm.armv6/usr/src/tmp/legacy/bin:/usr/obj/arm.armv6/usr/src/tmp/u= sr/sbin:/usr/obj/arm.armv6/usr/src/tmp/usr/bin:/usr/obj/arm.armv6/usr/src/t= mp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin > CC=3D"cc " CXX=3D"c++ " CPP=3D"cpp " AS=3D"as" AR=3D"ar" LD=3D"ld" NM= =3Dnm OBJDUMP=3D > RANLIB=3Dranlib STRINGS=3D COMPILER_TYPE=3Dclang make -m /usr/src/share/= mk > KERNEL=3Dkernel depend -DNO_MODULES_OBJ > machine -> /usr/src/sys/arm/include > awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h > awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h > cc -c -O -pipe -std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions > -Wmissing-include-dirs -fdiagnostics-show-option > -Wno-error-tautological-compare -Wno-error-empty-body > -Wno-error-parentheses-equality -Wno-unused-function -nostdinc -I. > -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilte= r > -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal > -I/usr/src/sys/contrib/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm > -I/usr/src/sys/dev/twa -I/usr/src/sys/dev/cxgb -I/usr/src/sys/dev/cxgbe > -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > -include opt_global.h -funwind-tables -mllvm -arm-enable-ehabi > -ffreestanding /usr/src/sys/arm/arm/genassym.c > NM=3D'nm' sh /usr/src/sys/kern/genassym.sh genassym.o > assym.s > awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -p > awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -q > awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -h > sh /usr/src/sys/tools/fdt/make_dtb.sh /usr/src/sys cubieboard2.dts > /usr/obj/arm.armv6/usr/src/sys/CUBIEBOARD2/cubieboard2.dtb > Segmentation fault (core dumped) > *** Error code 139 > > Stop. > make: stopped in /usr/obj/arm.armv6/usr/src/sys/CUBIEBOARD2 > *** Error code 1 > > Stop. > make: stopped in /usr/src > *** Error code 1 > > Stop. > make: stopped in /usr/src > root@bsd:/usr/src # sh /usr/src/sys/tools/fdt/make_dtb.sh /usr/src/sys > cubieboard2.dts /usr/obj/arm.armv6/usr/src/sys/CUBIEBOARD2/cubieboard2.dt= b > :158:10: fatal error: 'cubieboard2.dts' file not found > #include "cubieboard2.dts" > ^ > 1 error generated. > Segmentation fault (core dumped) > > Sorry for the noise, I had to build kernel toolchain again, now it works. Ganbold > > > Ganbold > > > > >> >> Warner >> >> Begin forwarded message: >> >> > From: Warner Losh >> > Subject: svn commit: r262614 - in head: . share/mk sys/boot/fdt/dts >> sys/boot/fdt/dts/arm sys/boot/fdt/dts/mips sys/boot/fdt/dts/powerpc >> sys/conf sys/tools/fdt >> > Date: February 28, 2014 at 11:29:10 AM MST >> > To: src-committers@freebsd.org, svn-src-all@freebsd.org, >> svn-src-head@freebsd.org >> > >> > Author: imp >> > Date: Fri Feb 28 18:29:09 2014 >> > New Revision: 262614 >> > URL: http://svnweb.freebsd.org/changeset/base/262614 >> > >> > Log: >> > Integrate device-tree upstream files into the build process: >> > (1) Invoke cpp to bring in files via #include (although the old >> > /include/ stuff is supported still). >> > (2) bring in files from either vendor tree or freebsd-custom files >> > when building. >> > (3) move all dts* files from sys/boot/fdt/dts to >> > sys/boot/fdt/dts/${MACHINE} as appropriate. >> > (4) encode all the magic to do the build in sys/tools/fdt/make_dtb.sh >> > so that the different places in the tree use the exact same logic= . >> > (5) switch back to gpl dtc by default. the bsdl one in the tree has >> > significant issues not easily addressed by those unfamiliar with >> > the code. >> > >> > Added: >> > head/sys/boot/fdt/dts/arm/ >> > head/sys/boot/fdt/dts/arm/am335x-evm.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/am335x-evm.d= ts >> > head/sys/boot/fdt/dts/arm/am335x.dtsi >> > - copied, changed from r262613, head/sys/boot/fdt/dts/am335x.dtsi >> > head/sys/boot/fdt/dts/arm/bcm2835.dtsi >> > - copied, changed from r262613, head/sys/boot/fdt/dts/bcm2835.dtsi >> > head/sys/boot/fdt/dts/arm/beaglebone-black.dts >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/beaglebone-black.dts >> > head/sys/boot/fdt/dts/arm/beaglebone.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/beaglebone.d= ts >> > head/sys/boot/fdt/dts/arm/cubieboard.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/cubieboard.d= ts >> > head/sys/boot/fdt/dts/arm/cubieboard2.dts >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/cubieboard2.dts >> > head/sys/boot/fdt/dts/arm/db78100.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/db78100.dts >> > head/sys/boot/fdt/dts/arm/db78460.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/db78460.dts >> > head/sys/boot/fdt/dts/arm/db88f5182.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/db88f5182.dt= s >> > head/sys/boot/fdt/dts/arm/db88f5281.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/db88f5281.dt= s >> > head/sys/boot/fdt/dts/arm/db88f6281.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/db88f6281.dt= s >> > head/sys/boot/fdt/dts/arm/digi-ccwmx53.dts >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/digi-ccwmx53.dts >> > head/sys/boot/fdt/dts/arm/dockstar.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/dockstar.dts >> > head/sys/boot/fdt/dts/arm/dreamplug-1001.dts >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/dreamplug-1001.dts >> > head/sys/boot/fdt/dts/arm/dreamplug-1001N.dts >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/dreamplug-1001N.dts >> > head/sys/boot/fdt/dts/arm/ea3250.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/ea3250.dts >> > head/sys/boot/fdt/dts/arm/efikamx.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/efikamx.dts >> > head/sys/boot/fdt/dts/arm/exynos5250-arndale.dts >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/exynos5250-arndale.dts >> > head/sys/boot/fdt/dts/arm/exynos5250.dtsi >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/exynos5250.dtsi >> > head/sys/boot/fdt/dts/arm/imx51x.dtsi >> > - copied, changed from r262613, head/sys/boot/fdt/dts/imx51x.dtsi >> > head/sys/boot/fdt/dts/arm/imx53-qsb.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/imx53-qsb.dt= s >> > head/sys/boot/fdt/dts/arm/imx53x.dtsi >> > - copied, changed from r262613, head/sys/boot/fdt/dts/imx53x.dtsi >> > head/sys/boot/fdt/dts/arm/imx6.dtsi >> > - copied, changed from r262613, head/sys/boot/fdt/dts/imx6.dtsi >> > head/sys/boot/fdt/dts/arm/p1020rdb.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/p1020rdb.dts >> > head/sys/boot/fdt/dts/arm/p2020ds.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/p2020ds.dts >> > head/sys/boot/fdt/dts/arm/p2041rdb.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/p2041rdb.dts >> > head/sys/boot/fdt/dts/arm/p2041si.dtsi >> > - copied, changed from r262613, head/sys/boot/fdt/dts/p2041si.dtsi >> > head/sys/boot/fdt/dts/arm/p3041ds.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/p3041ds.dts >> > head/sys/boot/fdt/dts/arm/p3041si.dtsi >> > - copied, changed from r262613, head/sys/boot/fdt/dts/p3041si.dtsi >> > head/sys/boot/fdt/dts/arm/p5020ds.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/p5020ds.dts >> > head/sys/boot/fdt/dts/arm/p5020si.dtsi >> > - copied, changed from r262613, head/sys/boot/fdt/dts/p5020si.dtsi >> > head/sys/boot/fdt/dts/arm/pandaboard.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/pandaboard.d= ts >> > head/sys/boot/fdt/dts/arm/rk3188-radxa.dts >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/rk3188-radxa.dts >> > head/sys/boot/fdt/dts/arm/rk3188.dtsi >> > - copied, changed from r262613, head/sys/boot/fdt/dts/rk3188.dtsi >> > head/sys/boot/fdt/dts/arm/rpi.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/rpi.dts >> > head/sys/boot/fdt/dts/arm/sheevaplug.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/sheevaplug.d= ts >> > head/sys/boot/fdt/dts/arm/tegra20-paz00.dts >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/tegra20-paz00.dts >> > head/sys/boot/fdt/dts/arm/tegra20.dtsi >> > - copied, changed from r262613, head/sys/boot/fdt/dts/tegra20.dtsi >> > head/sys/boot/fdt/dts/arm/trimslice.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/trimslice.dt= s >> > head/sys/boot/fdt/dts/arm/ts7800.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/ts7800.dts >> > head/sys/boot/fdt/dts/arm/versatilepb.dts >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/versatilepb.dts >> > head/sys/boot/fdt/dts/arm/vybrid-colibri-vf50.dts >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/vybrid-colibri-vf50.dts >> > head/sys/boot/fdt/dts/arm/vybrid-cosmic.dts >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/vybrid-cosmic.dts >> > head/sys/boot/fdt/dts/arm/vybrid-quartz.dts >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/vybrid-quartz.dts >> > head/sys/boot/fdt/dts/arm/vybrid.dtsi >> > - copied, changed from r262613, head/sys/boot/fdt/dts/vybrid.dtsi >> > head/sys/boot/fdt/dts/arm/wandboard-dual.dts >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/wandboard-dual.dts >> > head/sys/boot/fdt/dts/arm/wandboard-quad.dts >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/wandboard-quad.dts >> > head/sys/boot/fdt/dts/arm/wandboard-solo.dts >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/wandboard-solo.dts >> > head/sys/boot/fdt/dts/arm/zedboard.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/zedboard.dts >> > head/sys/boot/fdt/dts/mips/ >> > head/sys/boot/fdt/dts/mips/beri-netfpga.dts >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/beri-netfpga.dts >> > head/sys/boot/fdt/dts/mips/beri-sim.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/beri-sim.dts >> > head/sys/boot/fdt/dts/mips/beripad-de4.dts >> > - copied, changed from r262613, >> head/sys/boot/fdt/dts/beripad-de4.dts >> > head/sys/boot/fdt/dts/mips/xlp-basic.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/xlp-basic.dt= s >> > head/sys/boot/fdt/dts/powerpc/ >> > head/sys/boot/fdt/dts/powerpc/mpc8555cds.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/mpc8555cds.d= ts >> > head/sys/boot/fdt/dts/powerpc/mpc8572ds.dts >> > - copied, changed from r262613, head/sys/boot/fdt/dts/mpc8572ds.dt= s >> > head/sys/tools/fdt/make_dtb.sh (contents, props changed) >> > Deleted: >> > head/sys/boot/fdt/dts/am335x-evm.dts >> > head/sys/boot/fdt/dts/am335x.dtsi >> > head/sys/boot/fdt/dts/bcm2835.dtsi >> > head/sys/boot/fdt/dts/beaglebone-black.dts >> > head/sys/boot/fdt/dts/beaglebone.dts >> > head/sys/boot/fdt/dts/beri-netfpga.dts >> > head/sys/boot/fdt/dts/beri-sim.dts >> > head/sys/boot/fdt/dts/beripad-de4.dts >> > head/sys/boot/fdt/dts/cubieboard.dts >> > head/sys/boot/fdt/dts/cubieboard2.dts >> > head/sys/boot/fdt/dts/db78100.dts >> > head/sys/boot/fdt/dts/db78460.dts >> > head/sys/boot/fdt/dts/db88f5182.dts >> > head/sys/boot/fdt/dts/db88f5281.dts >> > head/sys/boot/fdt/dts/db88f6281.dts >> > head/sys/boot/fdt/dts/digi-ccwmx53.dts >> > head/sys/boot/fdt/dts/dockstar.dts >> > head/sys/boot/fdt/dts/dreamplug-1001.dts >> > head/sys/boot/fdt/dts/dreamplug-1001N.dts >> > head/sys/boot/fdt/dts/ea3250.dts >> > head/sys/boot/fdt/dts/efikamx.dts >> > head/sys/boot/fdt/dts/exynos5250-arndale.dts >> > head/sys/boot/fdt/dts/exynos5250.dtsi >> > head/sys/boot/fdt/dts/imx51x.dtsi >> > head/sys/boot/fdt/dts/imx53-qsb.dts >> > head/sys/boot/fdt/dts/imx53x.dtsi >> > head/sys/boot/fdt/dts/imx6.dtsi >> > head/sys/boot/fdt/dts/mpc8555cds.dts >> > head/sys/boot/fdt/dts/mpc8572ds.dts >> > head/sys/boot/fdt/dts/p1020rdb.dts >> > head/sys/boot/fdt/dts/p2020ds.dts >> > head/sys/boot/fdt/dts/p2041rdb.dts >> > head/sys/boot/fdt/dts/p2041si.dtsi >> > head/sys/boot/fdt/dts/p3041ds.dts >> > head/sys/boot/fdt/dts/p3041si.dtsi >> > head/sys/boot/fdt/dts/p5020ds.dts >> > head/sys/boot/fdt/dts/p5020si.dtsi >> > head/sys/boot/fdt/dts/pandaboard.dts >> > head/sys/boot/fdt/dts/rk3188-radxa.dts >> > head/sys/boot/fdt/dts/rk3188.dtsi >> > head/sys/boot/fdt/dts/rpi.dts >> > head/sys/boot/fdt/dts/sheevaplug.dts >> > head/sys/boot/fdt/dts/tegra20-paz00.dts >> > head/sys/boot/fdt/dts/tegra20.dtsi >> > head/sys/boot/fdt/dts/trimslice.dts >> > head/sys/boot/fdt/dts/ts7800.dts >> > head/sys/boot/fdt/dts/versatilepb.dts >> > head/sys/boot/fdt/dts/vybrid-colibri-vf50.dts >> > head/sys/boot/fdt/dts/vybrid-cosmic.dts >> > head/sys/boot/fdt/dts/vybrid-quartz.dts >> > head/sys/boot/fdt/dts/vybrid.dtsi >> > head/sys/boot/fdt/dts/wandboard-dual.dts >> > head/sys/boot/fdt/dts/wandboard-quad.dts >> > head/sys/boot/fdt/dts/wandboard-solo.dts >> > head/sys/boot/fdt/dts/xlp-basic.dts >> > head/sys/boot/fdt/dts/zedboard.dts >> > Modified: >> > head/Makefile.inc1 >> > head/share/mk/bsd.own.mk >> > head/sys/conf/files >> > >> > Modified: head/Makefile.inc1 >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > --- head/Makefile.inc1 Fri Feb 28 18:06:00 2014 (r262613= ) >> > +++ head/Makefile.inc1 Fri Feb 28 18:29:09 2014 (r262614= ) >> > @@ -1262,7 +1262,7 @@ _dtrace_tools=3D cddl/usr.bin/sgsmsg cddl/ >> > lib/libdwarf cddl/usr.bin/ctfconvert cddl/usr.bin/ctfmerge >> > .endif >> > >> > -# Default to building the BSDL DTC, but build the GPL one if users >> explicitly >> > +# Default to building the GPL DTC, but build the BSDL one if users >> explicitly >> > # request it. >> > _dtc=3D usr.bin/dtc >> > .if ${MK_GPL_DTC} !=3D "no" >> > @@ -1853,7 +1853,7 @@ builddtb: >> > echo "ERROR: FDT_DTS_FILE must be specified!"; \ >> > exit 1; \ >> > fi; \ >> > - if [ ! -f ${.CURDIR}/sys/boot/fdt/dts/${FDT_DTS_FILE} ]; then \ >> > + if [ ! -f ${.CURDIR}/sys/boot/fdt/dts/${MACHINE}/${FDT_DTS_FILE} >> ]; then \ >> > echo "ERROR: Specified DTS file (${FDT_DTS_FILE}) does >> not \ >> > exist!"; \ >> > exit 1; \ >> > @@ -1863,9 +1863,9 @@ builddtb: >> > directory"; \ >> > fi >> > @PATH=3D${TMPPATH} \ >> > - dtc -O dtb -o \ >> > - ${DTBOUTPUTPATH}/`echo ${FDT_DTS_FILE} | cut -d. -f1`.dtb -b >> 0 \ >> > - -p 1024 ${.CURDIR}/sys/boot/fdt/dts/${FDT_DTS_FILE} >> > + ${.CURDIR}/sys/tools/fdt/make_dtb.sh ${.CURDIR}/sys \ >> > + ${FDT_DTS_FILE} \ >> > + ${DTBOUTPUTPATH}/`basename ${FDT_DTS_FILE} .dts` >> > >> > ############### >> > >> > >> > Modified: head/share/mk/bsd.own.mk >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > --- head/share/mk/bsd.own.mk Fri Feb 28 18:06:00 2014 (r262613= ) >> > +++ head/share/mk/bsd.own.mk Fri Feb 28 18:29:09 2014 (r262614= ) >> > @@ -287,6 +287,7 @@ __DEFAULT_YES_OPTIONS =3D \ >> > GNU \ >> > GPIB \ >> > GPIO \ >> > + GPL_DTC \ >> > GROFF \ >> > HTML \ >> > ICONV \ >> > @@ -368,7 +369,6 @@ __DEFAULT_NO_OPTIONS =3D \ >> > CLANG_EXTRAS \ >> > CTF \ >> > DEBUG_FILES \ >> > - GPL_DTC \ >> > HESIOD \ >> > INSTALL_AS_USER \ >> > LLDB \ >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/am335x-evm.dts (from >> r262613, head/sys/boot/fdt/dts/am335x-evm.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/am335x.dtsi (from >> r262613, head/sys/boot/fdt/dts/am335x.dtsi) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/bcm2835.dtsi (from >> r262613, head/sys/boot/fdt/dts/bcm2835.dtsi) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/beaglebone-black.dts >> (from r262613, head/sys/boot/fdt/dts/beaglebone-black.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/beaglebone.dts (from >> r262613, head/sys/boot/fdt/dts/beaglebone.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/cubieboard.dts (from >> r262613, head/sys/boot/fdt/dts/cubieboard.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/cubieboard2.dts (from >> r262613, head/sys/boot/fdt/dts/cubieboard2.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/db78100.dts (from >> r262613, head/sys/boot/fdt/dts/db78100.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/db78460.dts (from >> r262613, head/sys/boot/fdt/dts/db78460.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/db88f5182.dts (from >> r262613, head/sys/boot/fdt/dts/db88f5182.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/db88f5281.dts (from >> r262613, head/sys/boot/fdt/dts/db88f5281.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/db88f6281.dts (from >> r262613, head/sys/boot/fdt/dts/db88f6281.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/digi-ccwmx53.dts (from >> r262613, head/sys/boot/fdt/dts/digi-ccwmx53.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/dockstar.dts (from >> r262613, head/sys/boot/fdt/dts/dockstar.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/dreamplug-1001.dts (fro= m >> r262613, head/sys/boot/fdt/dts/dreamplug-1001.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/dreamplug-1001N.dts >> (from r262613, head/sys/boot/fdt/dts/dreamplug-1001N.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/ea3250.dts (from >> r262613, head/sys/boot/fdt/dts/ea3250.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/efikamx.dts (from >> r262613, head/sys/boot/fdt/dts/efikamx.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/exynos5250-arndale.dts >> (from r262613, head/sys/boot/fdt/dts/exynos5250-arndale.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/exynos5250.dtsi (from >> r262613, head/sys/boot/fdt/dts/exynos5250.dtsi) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/imx51x.dtsi (from >> r262613, head/sys/boot/fdt/dts/imx51x.dtsi) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/imx53-qsb.dts (from >> r262613, head/sys/boot/fdt/dts/imx53-qsb.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/imx53x.dtsi (from >> r262613, head/sys/boot/fdt/dts/imx53x.dtsi) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/imx6.dtsi (from r262613= , >> head/sys/boot/fdt/dts/imx6.dtsi) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/p1020rdb.dts (from >> r262613, head/sys/boot/fdt/dts/p1020rdb.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/p2020ds.dts (from >> r262613, head/sys/boot/fdt/dts/p2020ds.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/p2041rdb.dts (from >> r262613, head/sys/boot/fdt/dts/p2041rdb.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/p2041si.dtsi (from >> r262613, head/sys/boot/fdt/dts/p2041si.dtsi) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/p3041ds.dts (from >> r262613, head/sys/boot/fdt/dts/p3041ds.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/p3041si.dtsi (from >> r262613, head/sys/boot/fdt/dts/p3041si.dtsi) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/p5020ds.dts (from >> r262613, head/sys/boot/fdt/dts/p5020ds.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/p5020si.dtsi (from >> r262613, head/sys/boot/fdt/dts/p5020si.dtsi) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/pandaboard.dts (from >> r262613, head/sys/boot/fdt/dts/pandaboard.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/rk3188-radxa.dts (from >> r262613, head/sys/boot/fdt/dts/rk3188-radxa.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/rk3188.dtsi (from >> r262613, head/sys/boot/fdt/dts/rk3188.dtsi) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/rpi.dts (from r262613, >> head/sys/boot/fdt/dts/rpi.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/sheevaplug.dts (from >> r262613, head/sys/boot/fdt/dts/sheevaplug.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/tegra20-paz00.dts (from >> r262613, head/sys/boot/fdt/dts/tegra20-paz00.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/tegra20.dtsi (from >> r262613, head/sys/boot/fdt/dts/tegra20.dtsi) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/trimslice.dts (from >> r262613, head/sys/boot/fdt/dts/trimslice.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/ts7800.dts (from >> r262613, head/sys/boot/fdt/dts/ts7800.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/versatilepb.dts (from >> r262613, head/sys/boot/fdt/dts/versatilepb.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/vybrid-colibri-vf50.dts >> (from r262613, head/sys/boot/fdt/dts/vybrid-colibri-vf50.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/vybrid-cosmic.dts (from >> r262613, head/sys/boot/fdt/dts/vybrid-cosmic.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/vybrid-quartz.dts (from >> r262613, head/sys/boot/fdt/dts/vybrid-quartz.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/vybrid.dtsi (from >> r262613, head/sys/boot/fdt/dts/vybrid.dtsi) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/wandboard-dual.dts (fro= m >> r262613, head/sys/boot/fdt/dts/wandboard-dual.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/wandboard-quad.dts (fro= m >> r262613, head/sys/boot/fdt/dts/wandboard-quad.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/wandboard-solo.dts (fro= m >> r262613, head/sys/boot/fdt/dts/wandboard-solo.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/arm/zedboard.dts (from >> r262613, head/sys/boot/fdt/dts/zedboard.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/mips/beri-netfpga.dts (from >> r262613, head/sys/boot/fdt/dts/beri-netfpga.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/mips/beri-sim.dts (from >> r262613, head/sys/boot/fdt/dts/beri-sim.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/mips/beripad-de4.dts (from >> r262613, head/sys/boot/fdt/dts/beripad-de4.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/mips/xlp-basic.dts (from >> r262613, head/sys/boot/fdt/dts/xlp-basic.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/powerpc/mpc8555cds.dts (fro= m >> r262613, head/sys/boot/fdt/dts/mpc8555cds.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Copied and modified: head/sys/boot/fdt/dts/powerpc/mpc8572ds.dts (from >> r262613, head/sys/boot/fdt/dts/mpc8572ds.dts) >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > Modified: head/sys/conf/files >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > --- head/sys/conf/files Fri Feb 28 18:06:00 2014 (r262613= ) >> > +++ head/sys/conf/files Fri Feb 28 18:29:09 2014 (r262614= ) >> > @@ -14,11 +14,12 @@ acpi_quirks.h optional acpi >> \ >> > # from the specified source (DTS) file: .dts -> .d= tb >> > # >> > fdt_dtb_file optional fdt \ >> > - compile-with "if [ -f $S/boot/fdt/dts/${FDT_DTS_FILE} ]; then dt= c >> -O dtb -o ${FDT_DTS_FILE:R}.dtb -b 0 -p 1024 >> $S/boot/fdt/dts/${FDT_DTS_FILE}; fi" \ >> > + compile-with "sh $S/tools/fdt/make_dtb.sh $S ${FDT_DTS_FILE} >> ${.CURDIR}/${FDT_DTS_FILE:R}.dtb" \ >> > no-obj no-implicit-rule before-depend \ >> > clean "${FDT_DTS_FILE:R}.dtb" >> > fdt_static_dtb.h optional fdt fdt_dtb_static \ >> > - compile-with "sh $S/tools/fdt/make_dtbh.sh ${FDT_DTS_FILE} ." \ >> > + compile-with "sh $S/tools/fdt/make_dtbh.sh ${FDT_DTS_FILE} >> ${.CURDIR}" \ >> > + dependency "fdt_dtb_file" \ >> > no-obj no-implicit-rule before-depend \ >> > clean "fdt_static_dtb.h" >> > feeder_eq_gen.h optional sound >> \ >> > @@ -1370,7 +1371,7 @@ dev/fb/splash.c optional sc spla= sh >> > dev/fdt/fdt_common.c optional fdt >> > dev/fdt/fdt_slicer.c optional fdt cfi | fdt nand >> > dev/fdt/fdt_static_dtb.S optional fdt fdt_dtb_static \ >> > - dependency "$S/boot/fdt/dts/${FDT_DTS_FILE}" >> > + dependency "$S/boot/fdt/dts/${MACHINE}/${FDT_DTS_FILE}" >> > dev/fdt/simplebus.c optional fdt >> > dev/fe/if_fe.c optional fe >> > dev/fe/if_fe_pccard.c optional fe pccard >> > >> > Added: head/sys/tools/fdt/make_dtb.sh >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > --- /dev/null 00:00:00 1970 (empty, because file is newly added) >> > +++ head/sys/tools/fdt/make_dtb.sh Fri Feb 28 18:29:09 2014 >> (r262614) >> > @@ -0,0 +1,11 @@ >> > +#!/bin/sh >> > +# >> > +# $FreeBSD$ >> > + >> > +# Script generates dtb file ($3) from dts source ($2) in build tree S >> ($1) >> > +S=3D$1 >> > +dts=3D$2 >> > +dtb=3D$3 >> > + >> > +cpp -x assembler-with-cpp -I $S/gnu/dts/include -I >> $S/boot/fdt/dts/${MACHINE} -I $S/gnu/dts/${MACHINE} -include $dts /dev/n= ull >> | >> > + dtc -O dtb -o $dtb -b 0 -p 1024 -i $S/boot/fdt/dts -i >> $S/gnu/dts/${MACHINE} >> > >> >> _______________________________________________ >> freebsd-mips@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-mips >> To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" >> > > From owner-freebsd-embedded@FreeBSD.ORG Mon Mar 3 11:06:42 2014 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E5B1DAC for ; Mon, 3 Mar 2014 11:06:42 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4B3B6934 for ; Mon, 3 Mar 2014 11:06:42 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s23B6gew008444 for ; Mon, 3 Mar 2014 11:06:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s23B6f7R008442 for freebsd-embedded@FreeBSD.org; Mon, 3 Mar 2014 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 3 Mar 2014 11:06:41 GMT Message-Id: <201403031106.s23B6f7R008442@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-embedded@FreeBSD.org Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 11:06:42 -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 misc/52256 embedded [picobsd] picobsd build script does not read in user/s o kern/42728 embedded [picobsd] many problems in src/usr.sbin/ppp/* after c 2 problems total. From owner-freebsd-embedded@FreeBSD.ORG Mon Mar 3 14:17:35 2014 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 36F5FBDD for ; Mon, 3 Mar 2014 14:17:35 +0000 (UTC) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EE651D72 for ; Mon, 3 Mar 2014 14:17:34 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id tp5so2791541ieb.12 for ; Mon, 03 Mar 2014 06:17:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=WQTdnqPXPGEIoxHa/1CyVhEXUBv8PQS62DYno1KCfMA=; b=SIqpnGwfWryiMNc8t/XPDqm4Y5JZfoYxb1h3jD3fcK5BvKfErj3IcWoZdMTdEKOdXO bFD93s4SD33M8yV19bBJUJ2FXDU0ILTttFO3ixF8RvKZqm8hs+MF8IhZIkCCB5J97+x6 C0/uL7WDtzb2PdbTWFi6CST3OPZOm7ENv7HQoz48ovenTh15qSunedqaHP8w7PU8iNdw 66uj44D2MoQtEPJOCjTjkIgbDxPnpDlRevBpNFuaMlmGqV7U/OkkAbl75LG60mmhZUKd ZDo4F9rw5d6t/SlHs/oqYmRnLWx54wG0ayv/0L6gsExnMbA0EHi8TsCmoxG2TgVvmb32 LzBA== X-Gm-Message-State: ALoCoQnNi0o8h6kffx+Zp72pVu0K7pD0t+TctkefHB/tQpio8Lz4PrhUY2EDrIhGILP09/nSLXlu X-Received: by 10.43.65.145 with SMTP id xm17mr26753435icb.35.1393856254039; Mon, 03 Mar 2014 06:17:34 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id u1sm39633048igm.8.2014.03.03.06.17.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Mar 2014 06:17:33 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: svn commit: r262614 - in head: . share/mk sys/boot/fdt/dts sys/boot/fdt/dts/arm sys/boot/fdt/dts/mips sys/boot/fdt/dts/powerpc sys/conf sys/tools/fdt From: Warner Losh In-Reply-To: Date: Mon, 3 Mar 2014 07:17:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <017B0102-1A8E-4E0B-96BD-BF0213AB3B48@gmail.com> References: <201402281829.s1SITAQk019090@svn.freebsd.org> To: Ganbold Tsagaankhuu X-Mailer: Apple Mail (2.1874) Cc: freebsd-arm , embedded@freebsd.org, mips@freebsd.org, powerpc@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 14:17:35 -0000 On Mar 3, 2014, at 1:44 AM, Ganbold Tsagaankhuu = wrote: > On Mon, Mar 3, 2014 at 3:40 PM, Ganbold Tsagaankhuu = wrote: >=20 >> Hi, >>=20 >> On Sat, Mar 1, 2014 at 2:38 AM, Warner Losh wrote: >>=20 >>> Greetings, >>>=20 >>> This commit changes how we do DTS -> DTB compiling. For the most = part, it >>> should be a NOP, if all my tests are good, but I may have oopsed = something >>> without realizing it. >>>=20 >>> This commit does switch us back to the GPL dtc. That cannot be = helped. The >>> BSDL one was too far away from working, but if that status ever = changes, >>> I'm >>> happy to change the defaults back. This change was discussed by most = of >>> the >>> major workers in arm@ and mips@ land before changing back, and they = felt, >>> as I do, that using vendor dts files unmodified was a bigger win for >>> embedded >>> than the regression back to a GPL'd piece of software when the = BSDL'd one >>> isn't up to the task today of coping with this new world order. If = that >>> changes, >>> then I'd be happy to switch back. >>>=20 >>> Hope this doesn't break anybody. I'll be around if it does. >>>=20 >>=20 >>=20 >> It seems crashing when building kernel for cubieboard2. >>=20 >> Part of build log: >>=20 >> -------------------------------------------------------------- >>>>> stage 3.1: making dependencies >> -------------------------------------------------------------- >> cd /usr/obj/arm.armv6/usr/src/sys/CUBIEBOARD2; >> MAKEOBJDIRPREFIX=3D/usr/obj/arm.armv6 MACHINE_ARCH=3Darmv6 = MACHINE=3Darm >> CPUTYPE=3D = GROFF_BIN_PATH=3D/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/bin >> = GROFF_FONT_PATH=3D/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/share/groff_fo= nt >> GROFF_TMAC_PATH=3D/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/share/tmac >> _SHLIBDIRPREFIX=3D/usr/obj/arm.armv6/usr/src/tmp _LDSCRIPTROOT=3D >> VERSION=3D"FreeBSD 11.0-CURRENT armv6 1100010" INSTALL=3D"sh >> /usr/src/tools/install.sh" >> = PATH=3D/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/sbin:/usr/obj/arm.armv6/u= sr/src/tmp/legacy/usr/bin:/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/games:= /usr/obj/arm.armv6/usr/src/tmp/legacy/bin:/usr/obj/arm.armv6/usr/src/tmp/u= sr/sbin:/usr/obj/arm.armv6/usr/src/tmp/usr/bin:/usr/obj/arm.armv6/usr/src/= tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin >> CC=3D"cc " CXX=3D"c++ " CPP=3D"cpp " AS=3D"as" AR=3D"ar" LD=3D"ld" = NM=3Dnm OBJDUMP=3D >> RANLIB=3Dranlib STRINGS=3D COMPILER_TYPE=3Dclang make -m = /usr/src/share/mk >> KERNEL=3Dkernel depend -DNO_MODULES_OBJ >> machine -> /usr/src/sys/arm/include >> awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m = -h >> awk -f /usr/src/sys/tools/makeobjops.awk = /usr/src/sys/kern/device_if.m -h >> cc -c -O -pipe -std=3Dc99 -g -Wall -Wredundant-decls = -Wnested-externs >> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline >> -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions >> -Wmissing-include-dirs -fdiagnostics-show-option >> -Wno-error-tautological-compare -Wno-error-empty-body >> -Wno-error-parentheses-equality -Wno-unused-function -nostdinc -I. >> -I/usr/src/sys -I/usr/src/sys/contrib/altq = -I/usr/src/sys/contrib/ipfilter >> -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal >> -I/usr/src/sys/contrib/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm >> -I/usr/src/sys/dev/twa -I/usr/src/sys/dev/cxgb = -I/usr/src/sys/dev/cxgbe >> -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS >> -include opt_global.h -funwind-tables -mllvm -arm-enable-ehabi >> -ffreestanding /usr/src/sys/arm/arm/genassym.c >> NM=3D'nm' sh /usr/src/sys/kern/genassym.sh genassym.o > assym.s >> awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src = -p >> awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src = -q >> awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src = -h >> sh /usr/src/sys/tools/fdt/make_dtb.sh /usr/src/sys cubieboard2.dts >> /usr/obj/arm.armv6/usr/src/sys/CUBIEBOARD2/cubieboard2.dtb >> Segmentation fault (core dumped) >> *** Error code 139 >>=20 >> Stop. >> make: stopped in /usr/obj/arm.armv6/usr/src/sys/CUBIEBOARD2 >> *** Error code 1 >>=20 >> Stop. >> make: stopped in /usr/src >> *** Error code 1 >>=20 >> Stop. >> make: stopped in /usr/src >> root@bsd:/usr/src # sh /usr/src/sys/tools/fdt/make_dtb.sh = /usr/src/sys >> cubieboard2.dts = /usr/obj/arm.armv6/usr/src/sys/CUBIEBOARD2/cubieboard2.dtb >> :158:10: fatal error: 'cubieboard2.dts' file not found >> #include "cubieboard2.dts" >> ^ >> 1 error generated. >> Segmentation fault (core dumped) >>=20 >>=20 >=20 > Sorry for the noise, I had to build kernel toolchain again, now it = works. Sounds like I should add an entry in UPDATING=85 Warner > Ganbold >=20 >=20 >=20 >>=20 >>=20 >> Ganbold >>=20 >>=20 >>=20 >>=20 >>>=20 >>> Warner >>>=20 >>> Begin forwarded message: >>>=20 >>>> From: Warner Losh >>>> Subject: svn commit: r262614 - in head: . share/mk sys/boot/fdt/dts >>> sys/boot/fdt/dts/arm sys/boot/fdt/dts/mips sys/boot/fdt/dts/powerpc >>> sys/conf sys/tools/fdt >>>> Date: February 28, 2014 at 11:29:10 AM MST >>>> To: src-committers@freebsd.org, svn-src-all@freebsd.org, >>> svn-src-head@freebsd.org >>>>=20 >>>> Author: imp >>>> Date: Fri Feb 28 18:29:09 2014 >>>> New Revision: 262614 >>>> URL: http://svnweb.freebsd.org/changeset/base/262614 >>>>=20 >>>> Log: >>>> Integrate device-tree upstream files into the build process: >>>> (1) Invoke cpp to bring in files via #include (although the old >>>> /include/ stuff is supported still). >>>> (2) bring in files from either vendor tree or freebsd-custom files >>>> when building. >>>> (3) move all dts* files from sys/boot/fdt/dts to >>>> sys/boot/fdt/dts/${MACHINE} as appropriate. >>>> (4) encode all the magic to do the build in = sys/tools/fdt/make_dtb.sh >>>> so that the different places in the tree use the exact same = logic. >>>> (5) switch back to gpl dtc by default. the bsdl one in the tree has >>>> significant issues not easily addressed by those unfamiliar = with >>>> the code. >>>>=20 >>>> Added: >>>> head/sys/boot/fdt/dts/arm/ >>>> head/sys/boot/fdt/dts/arm/am335x-evm.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/am335x-evm.dts >>>> head/sys/boot/fdt/dts/arm/am335x.dtsi >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/am335x.dtsi >>>> head/sys/boot/fdt/dts/arm/bcm2835.dtsi >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/bcm2835.dtsi >>>> head/sys/boot/fdt/dts/arm/beaglebone-black.dts >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/beaglebone-black.dts >>>> head/sys/boot/fdt/dts/arm/beaglebone.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/beaglebone.dts >>>> head/sys/boot/fdt/dts/arm/cubieboard.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/cubieboard.dts >>>> head/sys/boot/fdt/dts/arm/cubieboard2.dts >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/cubieboard2.dts >>>> head/sys/boot/fdt/dts/arm/db78100.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/db78100.dts >>>> head/sys/boot/fdt/dts/arm/db78460.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/db78460.dts >>>> head/sys/boot/fdt/dts/arm/db88f5182.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/db88f5182.dts >>>> head/sys/boot/fdt/dts/arm/db88f5281.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/db88f5281.dts >>>> head/sys/boot/fdt/dts/arm/db88f6281.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/db88f6281.dts >>>> head/sys/boot/fdt/dts/arm/digi-ccwmx53.dts >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/digi-ccwmx53.dts >>>> head/sys/boot/fdt/dts/arm/dockstar.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/dockstar.dts >>>> head/sys/boot/fdt/dts/arm/dreamplug-1001.dts >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/dreamplug-1001.dts >>>> head/sys/boot/fdt/dts/arm/dreamplug-1001N.dts >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/dreamplug-1001N.dts >>>> head/sys/boot/fdt/dts/arm/ea3250.dts >>>> - copied, changed from r262613, head/sys/boot/fdt/dts/ea3250.dts >>>> head/sys/boot/fdt/dts/arm/efikamx.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/efikamx.dts >>>> head/sys/boot/fdt/dts/arm/exynos5250-arndale.dts >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/exynos5250-arndale.dts >>>> head/sys/boot/fdt/dts/arm/exynos5250.dtsi >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/exynos5250.dtsi >>>> head/sys/boot/fdt/dts/arm/imx51x.dtsi >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/imx51x.dtsi >>>> head/sys/boot/fdt/dts/arm/imx53-qsb.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/imx53-qsb.dts >>>> head/sys/boot/fdt/dts/arm/imx53x.dtsi >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/imx53x.dtsi >>>> head/sys/boot/fdt/dts/arm/imx6.dtsi >>>> - copied, changed from r262613, head/sys/boot/fdt/dts/imx6.dtsi >>>> head/sys/boot/fdt/dts/arm/p1020rdb.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/p1020rdb.dts >>>> head/sys/boot/fdt/dts/arm/p2020ds.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/p2020ds.dts >>>> head/sys/boot/fdt/dts/arm/p2041rdb.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/p2041rdb.dts >>>> head/sys/boot/fdt/dts/arm/p2041si.dtsi >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/p2041si.dtsi >>>> head/sys/boot/fdt/dts/arm/p3041ds.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/p3041ds.dts >>>> head/sys/boot/fdt/dts/arm/p3041si.dtsi >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/p3041si.dtsi >>>> head/sys/boot/fdt/dts/arm/p5020ds.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/p5020ds.dts >>>> head/sys/boot/fdt/dts/arm/p5020si.dtsi >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/p5020si.dtsi >>>> head/sys/boot/fdt/dts/arm/pandaboard.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/pandaboard.dts >>>> head/sys/boot/fdt/dts/arm/rk3188-radxa.dts >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/rk3188-radxa.dts >>>> head/sys/boot/fdt/dts/arm/rk3188.dtsi >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/rk3188.dtsi >>>> head/sys/boot/fdt/dts/arm/rpi.dts >>>> - copied, changed from r262613, head/sys/boot/fdt/dts/rpi.dts >>>> head/sys/boot/fdt/dts/arm/sheevaplug.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/sheevaplug.dts >>>> head/sys/boot/fdt/dts/arm/tegra20-paz00.dts >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/tegra20-paz00.dts >>>> head/sys/boot/fdt/dts/arm/tegra20.dtsi >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/tegra20.dtsi >>>> head/sys/boot/fdt/dts/arm/trimslice.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/trimslice.dts >>>> head/sys/boot/fdt/dts/arm/ts7800.dts >>>> - copied, changed from r262613, head/sys/boot/fdt/dts/ts7800.dts >>>> head/sys/boot/fdt/dts/arm/versatilepb.dts >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/versatilepb.dts >>>> head/sys/boot/fdt/dts/arm/vybrid-colibri-vf50.dts >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/vybrid-colibri-vf50.dts >>>> head/sys/boot/fdt/dts/arm/vybrid-cosmic.dts >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/vybrid-cosmic.dts >>>> head/sys/boot/fdt/dts/arm/vybrid-quartz.dts >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/vybrid-quartz.dts >>>> head/sys/boot/fdt/dts/arm/vybrid.dtsi >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/vybrid.dtsi >>>> head/sys/boot/fdt/dts/arm/wandboard-dual.dts >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/wandboard-dual.dts >>>> head/sys/boot/fdt/dts/arm/wandboard-quad.dts >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/wandboard-quad.dts >>>> head/sys/boot/fdt/dts/arm/wandboard-solo.dts >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/wandboard-solo.dts >>>> head/sys/boot/fdt/dts/arm/zedboard.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/zedboard.dts >>>> head/sys/boot/fdt/dts/mips/ >>>> head/sys/boot/fdt/dts/mips/beri-netfpga.dts >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/beri-netfpga.dts >>>> head/sys/boot/fdt/dts/mips/beri-sim.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/beri-sim.dts >>>> head/sys/boot/fdt/dts/mips/beripad-de4.dts >>>> - copied, changed from r262613, >>> head/sys/boot/fdt/dts/beripad-de4.dts >>>> head/sys/boot/fdt/dts/mips/xlp-basic.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/xlp-basic.dts >>>> head/sys/boot/fdt/dts/powerpc/ >>>> head/sys/boot/fdt/dts/powerpc/mpc8555cds.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/mpc8555cds.dts >>>> head/sys/boot/fdt/dts/powerpc/mpc8572ds.dts >>>> - copied, changed from r262613, = head/sys/boot/fdt/dts/mpc8572ds.dts >>>> head/sys/tools/fdt/make_dtb.sh (contents, props changed) >>>> Deleted: >>>> head/sys/boot/fdt/dts/am335x-evm.dts >>>> head/sys/boot/fdt/dts/am335x.dtsi >>>> head/sys/boot/fdt/dts/bcm2835.dtsi >>>> head/sys/boot/fdt/dts/beaglebone-black.dts >>>> head/sys/boot/fdt/dts/beaglebone.dts >>>> head/sys/boot/fdt/dts/beri-netfpga.dts >>>> head/sys/boot/fdt/dts/beri-sim.dts >>>> head/sys/boot/fdt/dts/beripad-de4.dts >>>> head/sys/boot/fdt/dts/cubieboard.dts >>>> head/sys/boot/fdt/dts/cubieboard2.dts >>>> head/sys/boot/fdt/dts/db78100.dts >>>> head/sys/boot/fdt/dts/db78460.dts >>>> head/sys/boot/fdt/dts/db88f5182.dts >>>> head/sys/boot/fdt/dts/db88f5281.dts >>>> head/sys/boot/fdt/dts/db88f6281.dts >>>> head/sys/boot/fdt/dts/digi-ccwmx53.dts >>>> head/sys/boot/fdt/dts/dockstar.dts >>>> head/sys/boot/fdt/dts/dreamplug-1001.dts >>>> head/sys/boot/fdt/dts/dreamplug-1001N.dts >>>> head/sys/boot/fdt/dts/ea3250.dts >>>> head/sys/boot/fdt/dts/efikamx.dts >>>> head/sys/boot/fdt/dts/exynos5250-arndale.dts >>>> head/sys/boot/fdt/dts/exynos5250.dtsi >>>> head/sys/boot/fdt/dts/imx51x.dtsi >>>> head/sys/boot/fdt/dts/imx53-qsb.dts >>>> head/sys/boot/fdt/dts/imx53x.dtsi >>>> head/sys/boot/fdt/dts/imx6.dtsi >>>> head/sys/boot/fdt/dts/mpc8555cds.dts >>>> head/sys/boot/fdt/dts/mpc8572ds.dts >>>> head/sys/boot/fdt/dts/p1020rdb.dts >>>> head/sys/boot/fdt/dts/p2020ds.dts >>>> head/sys/boot/fdt/dts/p2041rdb.dts >>>> head/sys/boot/fdt/dts/p2041si.dtsi >>>> head/sys/boot/fdt/dts/p3041ds.dts >>>> head/sys/boot/fdt/dts/p3041si.dtsi >>>> head/sys/boot/fdt/dts/p5020ds.dts >>>> head/sys/boot/fdt/dts/p5020si.dtsi >>>> head/sys/boot/fdt/dts/pandaboard.dts >>>> head/sys/boot/fdt/dts/rk3188-radxa.dts >>>> head/sys/boot/fdt/dts/rk3188.dtsi >>>> head/sys/boot/fdt/dts/rpi.dts >>>> head/sys/boot/fdt/dts/sheevaplug.dts >>>> head/sys/boot/fdt/dts/tegra20-paz00.dts >>>> head/sys/boot/fdt/dts/tegra20.dtsi >>>> head/sys/boot/fdt/dts/trimslice.dts >>>> head/sys/boot/fdt/dts/ts7800.dts >>>> head/sys/boot/fdt/dts/versatilepb.dts >>>> head/sys/boot/fdt/dts/vybrid-colibri-vf50.dts >>>> head/sys/boot/fdt/dts/vybrid-cosmic.dts >>>> head/sys/boot/fdt/dts/vybrid-quartz.dts >>>> head/sys/boot/fdt/dts/vybrid.dtsi >>>> head/sys/boot/fdt/dts/wandboard-dual.dts >>>> head/sys/boot/fdt/dts/wandboard-quad.dts >>>> head/sys/boot/fdt/dts/wandboard-solo.dts >>>> head/sys/boot/fdt/dts/xlp-basic.dts >>>> head/sys/boot/fdt/dts/zedboard.dts >>>> Modified: >>>> head/Makefile.inc1 >>>> head/share/mk/bsd.own.mk >>>> head/sys/conf/files >>>>=20 >>>> Modified: head/Makefile.inc1 >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>> --- head/Makefile.inc1 Fri Feb 28 18:06:00 2014 = (r262613) >>>> +++ head/Makefile.inc1 Fri Feb 28 18:29:09 2014 = (r262614) >>>> @@ -1262,7 +1262,7 @@ _dtrace_tools=3D cddl/usr.bin/sgsmsg cddl/ >>>> lib/libdwarf cddl/usr.bin/ctfconvert cddl/usr.bin/ctfmerge >>>> .endif >>>>=20 >>>> -# Default to building the BSDL DTC, but build the GPL one if users >>> explicitly >>>> +# Default to building the GPL DTC, but build the BSDL one if users >>> explicitly >>>> # request it. >>>> _dtc=3D usr.bin/dtc >>>> .if ${MK_GPL_DTC} !=3D "no" >>>> @@ -1853,7 +1853,7 @@ builddtb: >>>> echo "ERROR: FDT_DTS_FILE must be specified!"; \ >>>> exit 1; \ >>>> fi; \ >>>> - if [ ! -f ${.CURDIR}/sys/boot/fdt/dts/${FDT_DTS_FILE} ]; then = \ >>>> + if [ ! -f = ${.CURDIR}/sys/boot/fdt/dts/${MACHINE}/${FDT_DTS_FILE} >>> ]; then \ >>>> echo "ERROR: Specified DTS file (${FDT_DTS_FILE}) does >>> not \ >>>> exist!"; \ >>>> exit 1; \ >>>> @@ -1863,9 +1863,9 @@ builddtb: >>>> directory"; \ >>>> fi >>>> @PATH=3D${TMPPATH} \ >>>> - dtc -O dtb -o \ >>>> - ${DTBOUTPUTPATH}/`echo ${FDT_DTS_FILE} | cut -d. -f1`.dtb = -b >>> 0 \ >>>> - -p 1024 ${.CURDIR}/sys/boot/fdt/dts/${FDT_DTS_FILE} >>>> + ${.CURDIR}/sys/tools/fdt/make_dtb.sh ${.CURDIR}/sys \ >>>> + ${FDT_DTS_FILE} \ >>>> + ${DTBOUTPUTPATH}/`basename ${FDT_DTS_FILE} .dts` >>>>=20 >>>> ############### >>>>=20 >>>>=20 >>>> Modified: head/share/mk/bsd.own.mk >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>> --- head/share/mk/bsd.own.mk Fri Feb 28 18:06:00 2014 = (r262613) >>>> +++ head/share/mk/bsd.own.mk Fri Feb 28 18:29:09 2014 = (r262614) >>>> @@ -287,6 +287,7 @@ __DEFAULT_YES_OPTIONS =3D \ >>>> GNU \ >>>> GPIB \ >>>> GPIO \ >>>> + GPL_DTC \ >>>> GROFF \ >>>> HTML \ >>>> ICONV \ >>>> @@ -368,7 +369,6 @@ __DEFAULT_NO_OPTIONS =3D \ >>>> CLANG_EXTRAS \ >>>> CTF \ >>>> DEBUG_FILES \ >>>> - GPL_DTC \ >>>> HESIOD \ >>>> INSTALL_AS_USER \ >>>> LLDB \ >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/am335x-evm.dts (from >>> r262613, head/sys/boot/fdt/dts/am335x-evm.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/am335x.dtsi (from >>> r262613, head/sys/boot/fdt/dts/am335x.dtsi) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/bcm2835.dtsi (from >>> r262613, head/sys/boot/fdt/dts/bcm2835.dtsi) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/beaglebone-black.dts >>> (from r262613, head/sys/boot/fdt/dts/beaglebone-black.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/beaglebone.dts (from >>> r262613, head/sys/boot/fdt/dts/beaglebone.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/cubieboard.dts (from >>> r262613, head/sys/boot/fdt/dts/cubieboard.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/cubieboard2.dts = (from >>> r262613, head/sys/boot/fdt/dts/cubieboard2.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/db78100.dts (from >>> r262613, head/sys/boot/fdt/dts/db78100.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/db78460.dts (from >>> r262613, head/sys/boot/fdt/dts/db78460.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/db88f5182.dts (from >>> r262613, head/sys/boot/fdt/dts/db88f5182.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/db88f5281.dts (from >>> r262613, head/sys/boot/fdt/dts/db88f5281.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/db88f6281.dts (from >>> r262613, head/sys/boot/fdt/dts/db88f6281.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/digi-ccwmx53.dts = (from >>> r262613, head/sys/boot/fdt/dts/digi-ccwmx53.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/dockstar.dts (from >>> r262613, head/sys/boot/fdt/dts/dockstar.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/dreamplug-1001.dts = (from >>> r262613, head/sys/boot/fdt/dts/dreamplug-1001.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/dreamplug-1001N.dts >>> (from r262613, head/sys/boot/fdt/dts/dreamplug-1001N.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/ea3250.dts (from >>> r262613, head/sys/boot/fdt/dts/ea3250.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/efikamx.dts (from >>> r262613, head/sys/boot/fdt/dts/efikamx.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: = head/sys/boot/fdt/dts/arm/exynos5250-arndale.dts >>> (from r262613, head/sys/boot/fdt/dts/exynos5250-arndale.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/exynos5250.dtsi = (from >>> r262613, head/sys/boot/fdt/dts/exynos5250.dtsi) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/imx51x.dtsi (from >>> r262613, head/sys/boot/fdt/dts/imx51x.dtsi) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/imx53-qsb.dts (from >>> r262613, head/sys/boot/fdt/dts/imx53-qsb.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/imx53x.dtsi (from >>> r262613, head/sys/boot/fdt/dts/imx53x.dtsi) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/imx6.dtsi (from = r262613, >>> head/sys/boot/fdt/dts/imx6.dtsi) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/p1020rdb.dts (from >>> r262613, head/sys/boot/fdt/dts/p1020rdb.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/p2020ds.dts (from >>> r262613, head/sys/boot/fdt/dts/p2020ds.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/p2041rdb.dts (from >>> r262613, head/sys/boot/fdt/dts/p2041rdb.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/p2041si.dtsi (from >>> r262613, head/sys/boot/fdt/dts/p2041si.dtsi) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/p3041ds.dts (from >>> r262613, head/sys/boot/fdt/dts/p3041ds.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/p3041si.dtsi (from >>> r262613, head/sys/boot/fdt/dts/p3041si.dtsi) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/p5020ds.dts (from >>> r262613, head/sys/boot/fdt/dts/p5020ds.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/p5020si.dtsi (from >>> r262613, head/sys/boot/fdt/dts/p5020si.dtsi) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/pandaboard.dts (from >>> r262613, head/sys/boot/fdt/dts/pandaboard.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/rk3188-radxa.dts = (from >>> r262613, head/sys/boot/fdt/dts/rk3188-radxa.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/rk3188.dtsi (from >>> r262613, head/sys/boot/fdt/dts/rk3188.dtsi) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/rpi.dts (from = r262613, >>> head/sys/boot/fdt/dts/rpi.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/sheevaplug.dts (from >>> r262613, head/sys/boot/fdt/dts/sheevaplug.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/tegra20-paz00.dts = (from >>> r262613, head/sys/boot/fdt/dts/tegra20-paz00.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/tegra20.dtsi (from >>> r262613, head/sys/boot/fdt/dts/tegra20.dtsi) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/trimslice.dts (from >>> r262613, head/sys/boot/fdt/dts/trimslice.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/ts7800.dts (from >>> r262613, head/sys/boot/fdt/dts/ts7800.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/versatilepb.dts = (from >>> r262613, head/sys/boot/fdt/dts/versatilepb.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: = head/sys/boot/fdt/dts/arm/vybrid-colibri-vf50.dts >>> (from r262613, head/sys/boot/fdt/dts/vybrid-colibri-vf50.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/vybrid-cosmic.dts = (from >>> r262613, head/sys/boot/fdt/dts/vybrid-cosmic.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/vybrid-quartz.dts = (from >>> r262613, head/sys/boot/fdt/dts/vybrid-quartz.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/vybrid.dtsi (from >>> r262613, head/sys/boot/fdt/dts/vybrid.dtsi) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/wandboard-dual.dts = (from >>> r262613, head/sys/boot/fdt/dts/wandboard-dual.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/wandboard-quad.dts = (from >>> r262613, head/sys/boot/fdt/dts/wandboard-quad.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/wandboard-solo.dts = (from >>> r262613, head/sys/boot/fdt/dts/wandboard-solo.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/arm/zedboard.dts (from >>> r262613, head/sys/boot/fdt/dts/zedboard.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/mips/beri-netfpga.dts = (from >>> r262613, head/sys/boot/fdt/dts/beri-netfpga.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/mips/beri-sim.dts (from >>> r262613, head/sys/boot/fdt/dts/beri-sim.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/mips/beripad-de4.dts = (from >>> r262613, head/sys/boot/fdt/dts/beripad-de4.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/mips/xlp-basic.dts (from >>> r262613, head/sys/boot/fdt/dts/xlp-basic.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/powerpc/mpc8555cds.dts = (from >>> r262613, head/sys/boot/fdt/dts/mpc8555cds.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Copied and modified: head/sys/boot/fdt/dts/powerpc/mpc8572ds.dts = (from >>> r262613, head/sys/boot/fdt/dts/mpc8572ds.dts) >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>=20 >>>> Modified: head/sys/conf/files >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>> --- head/sys/conf/files Fri Feb 28 18:06:00 2014 = (r262613) >>>> +++ head/sys/conf/files Fri Feb 28 18:29:09 2014 = (r262614) >>>> @@ -14,11 +14,12 @@ acpi_quirks.h optional acpi >>> \ >>>> # from the specified source (DTS) file: .dts -> = .dtb >>>> # >>>> fdt_dtb_file optional fdt \ >>>> - compile-with "if [ -f $S/boot/fdt/dts/${FDT_DTS_FILE} ]; then = dtc >>> -O dtb -o ${FDT_DTS_FILE:R}.dtb -b 0 -p 1024 >>> $S/boot/fdt/dts/${FDT_DTS_FILE}; fi" \ >>>> + compile-with "sh $S/tools/fdt/make_dtb.sh $S ${FDT_DTS_FILE} >>> ${.CURDIR}/${FDT_DTS_FILE:R}.dtb" \ >>>> no-obj no-implicit-rule before-depend \ >>>> clean "${FDT_DTS_FILE:R}.dtb" >>>> fdt_static_dtb.h optional fdt fdt_dtb_static \ >>>> - compile-with "sh $S/tools/fdt/make_dtbh.sh ${FDT_DTS_FILE} ." = \ >>>> + compile-with "sh $S/tools/fdt/make_dtbh.sh ${FDT_DTS_FILE} >>> ${.CURDIR}" \ >>>> + dependency "fdt_dtb_file" \ >>>> no-obj no-implicit-rule before-depend \ >>>> clean "fdt_static_dtb.h" >>>> feeder_eq_gen.h optional sound >>> \ >>>> @@ -1370,7 +1371,7 @@ dev/fb/splash.c optional sc = splash >>>> dev/fdt/fdt_common.c optional fdt >>>> dev/fdt/fdt_slicer.c optional fdt cfi | fdt nand >>>> dev/fdt/fdt_static_dtb.S optional fdt fdt_dtb_static \ >>>> - dependency "$S/boot/fdt/dts/${FDT_DTS_FILE}" >>>> + dependency "$S/boot/fdt/dts/${MACHINE}/${FDT_DTS_FILE}" >>>> dev/fdt/simplebus.c optional fdt >>>> dev/fe/if_fe.c optional fe >>>> dev/fe/if_fe_pccard.c optional fe pccard >>>>=20 >>>> Added: head/sys/tools/fdt/make_dtb.sh >>>>=20 >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>> --- /dev/null 00:00:00 1970 (empty, because file is newly added) >>>> +++ head/sys/tools/fdt/make_dtb.sh Fri Feb 28 18:29:09 2014 >>> (r262614) >>>> @@ -0,0 +1,11 @@ >>>> +#!/bin/sh >>>> +# >>>> +# $FreeBSD$ >>>> + >>>> +# Script generates dtb file ($3) from dts source ($2) in build = tree S >>> ($1) >>>> +S=3D$1 >>>> +dts=3D$2 >>>> +dtb=3D$3 >>>> + >>>> +cpp -x assembler-with-cpp -I $S/gnu/dts/include -I >>> $S/boot/fdt/dts/${MACHINE} -I $S/gnu/dts/${MACHINE} -include $dts = /dev/null >>> | >>>> + dtc -O dtb -o $dtb -b 0 -p 1024 -i $S/boot/fdt/dts -i >>> $S/gnu/dts/${MACHINE} >>>>=20 >>>=20 >>> _______________________________________________ >>> freebsd-mips@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-mips >>> To unsubscribe, send any mail to = "freebsd-mips-unsubscribe@freebsd.org" >>>=20 >>=20 >>=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-embedded@FreeBSD.ORG Tue Mar 4 06:06:02 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 27FFAFD0; Tue, 4 Mar 2014 06:06:02 +0000 (UTC) Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4FDDD375; Tue, 4 Mar 2014 06:06:01 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id 6so72137bkj.13 for ; Mon, 03 Mar 2014 22:05:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=tVdIUYm5kt+YkZnrRacL1NYu17ePDQ7GXK52gXApz7g=; b=JGLrmJsQ3dtGliR+P3ATx8jVkPsJ3S//bhPK6YYS18CMzGrtpqgeXxTHbei7/kKsLr DddGISsDboav4zJjseL7Gg4gIzqKV99tp3BvfYGhgAlK645At6hGfHVoP6wBqBJ6JIEg LW+WkkFTF730J7Z5CN9pPWek9DkI1vo4bq4MQpRDFqQpKFo44UQQGk2xHtMOS21RY3OK YIv5nqmkFjV2GJ06M2+9g/dRCfiG/yLgf1/Oq7yMuocPNr+lHmCpGdkBicZ2YCJmyehs Pb+3hoR1AtnvnZe2aobmFeFDoUK0Fuh4sWFpYYfK38KHIYdNpH0uw1Qc2i34dWU0LR6b u1wA== MIME-Version: 1.0 X-Received: by 10.204.62.5 with SMTP id v5mr85191bkh.46.1393913159443; Mon, 03 Mar 2014 22:05:59 -0800 (PST) Sender: pkelsey@gmail.com Received: by 10.205.71.201 with HTTP; Mon, 3 Mar 2014 22:05:59 -0800 (PST) In-Reply-To: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> Date: Tue, 4 Mar 2014 01:05:59 -0500 X-Google-Sender-Auth: YT_NCq_RQT_IPHoqb53emVfKswk Message-ID: Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Patrick Kelsey To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" , freebsd-arm@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 06:06:02 -0000 On Sun, Mar 2, 2014 at 9:38 PM, Warner Losh wrote: > > On Mar 2, 2014, at 4:56 PM, Patrick Kelsey wrote: > > > Hi, > > > > The attached patch (fdt_probe_order_control.patch) allows control over > the > > probe order of simplebus child devices by using a "probe-order" property > in > > simplebus child nodes in the .dts file > > Where is the probe-order property defined? I can't seem to find it in the > bindings. > Also, I don't think it is necessary. This is a software construct, so > doesn't really > belong in the dts file. I'd really like to avoid FreeBSD specific hacks in > the DTS > files. > It is currently not in any bindings, and has the status of being something of my own invention and something possibly not ever used outside of private codebases. I think this is something that would fit conceptually with the miscellaneous bindings defined in ePAPR, as it is a rather generic property. As to this being a software construct, I appreciate and support the goal of keeping DTS files as pure hardware descriptions (and I'd also argue that the way the status property is sometimes used turns it into a software construct). Let's completely avoid the issue of am I arguing for adding a software construct to DTS files by looking at this another way. Instead of a 'probe-order' property that specifies a sort key, I could have the same quality of result (same warts and all, as discussed below) with a property that indicates whether the device is hardwired or has some sort of pluggable interface (a property, say, called 'pluggable'). That would be a pure hardware-as-it-is-designed description, and having that information would allow me to do a sort that orders non-pluggable ahead of pluggable in the probe/attach process. > > > This was motivated by booting FreeBSD from the eMMC on a BeagleBone > Black, > > which has a pluggable microSD card slot in addition to the eMMC. The > order > > that the mmc units are defined in sys/boot/fdt/dts/am335x.dtsi causes the > > pluggable slot to be probed/attached first, so the device name assigned > to > > the eMMC soldered to the board changes depending on whether there is a > card > > in the pluggable slot, which makes establishing appropriate /etc/fstab > > contents less than convenient. > > Sounds like you'd like to have some sort of name to instance mapping. > The typical way this is solved is by naming the partitions so that ordering > doesn't matter. Even if you don't handle this at the filesystem level, > which > is how others cope, you'd want this to be more of a direct binding rather > than an > ordering so that you get the effect you want (constant name) directly, > rather > than as a side-effect of ordering. > Yes, ideally I'd like to be able to assign a name to every MMC/SD card slot (hardwired or otherwise) in a system that depends only on the physical location of that slot, and be able to resolve that name to an mmcsd device instance. This works-here-side-effect-based approach is a result of the ideal solution seemingly not being within reach given the available resources. Using partition naming/glabel is a fair point, and does address the /etc/fstab issue, but it still leaves me short of being able to construct a product function that relies on knowing what's where when there is no partitioning/filesystem in place, for example, something that boils down to 'dd this image to the eMMC [or to the card in the card slot]'. Perhaps the answer to that is to build something using devinfo(3)/devd(8) to identify what mmcsdX is currently attached to each controller when I need to know. > If you insist on that, then having a something more like > "freesbd,unit-number" > property would also accomplish this. But that would only wire the > controller unit > number, and not the resulting mmcsdX device. > I understand fully that the utility of this goes as far as having none of the hardwired devices sharing controllers with pluggable devices in such a way that the controllers can find the attached pluggable devices first. Subject to that limitation as it is, this does usefully apply to at least one real system now, and it is a behavior I can take advantage of when designing new hardware to make developing the associated FreeBSD-based product software easier (namely, by not having to cobble together a poor-man's udev [which is not saying users of udev are exactly rich], and/or worry about how a customer might label the fat partition on an SD card they insert). More generally, whether this is or isn't a widely useful thing in the end, what is the current process for introducing a new property for use in DTS files? > > By using the "probe-order" property in > > sys/boot/fdt/dts/beaglebone-black.dts (see attached > > beaglebone_black_mmc_probe_order.patch), I am able to swap the order in > > which the mmc units are probed/attached for that board. This avoids > > inappropriate hacking of the mmc definition order in am335x.dtsi, which > is > > shared among multiple boards. > > > > This is not a general solution to the problem of wanting stable device > > names for hard-wired MMC devices when pluggable slots are present in the > > system. There could, for example, be a multi-slot MMC controller with a > > mixture of hard-wired and pluggable devices attached, and this would not > > address that case. However, it does address the needs of BeagleBone > Black, > > and the mechanism may be of use for similar issues on other platforms. > > As it isn't a generic solution, I'd be biased against adopting it. What's > wrong > with using glabel to accomplish this (either with a label specific > property, or > by using a ufs label and mounting /dev/ufs/foo). > > It is not my intention to lobby for adding this to the kernel at this point. Whether it is widely-enough or only very-narrowly useful I would say is currently unknown. My intention in posting this patch was for others on the list(s) that might find it useful to see it and have access to it, and to attract thoughtful criticism such as yours. I appreciate you taking the time to respond. -Patrick From owner-freebsd-embedded@FreeBSD.ORG Tue Mar 4 13:21:28 2014 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0AB69B40; Tue, 4 Mar 2014 13:21:28 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BDC5E398; Tue, 4 Mar 2014 13:21:27 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WKpHd-000F1l-5E; Tue, 04 Mar 2014 13:21:21 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s24DLHnf048013; Tue, 4 Mar 2014 06:21:17 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19j/00SiHz8tybK9XhxlVbs Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Ian Lepore To: Patrick Kelsey In-Reply-To: References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> Content-Type: text/plain; charset="us-ascii" Date: Tue, 04 Mar 2014 06:21:17 -0700 Message-ID: <1393939277.1149.300.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , freebsd-arm@FreeBSD.org, freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 13:21:28 -0000 On Tue, 2014-03-04 at 01:05 -0500, Patrick Kelsey wrote: > On Sun, Mar 2, 2014 at 9:38 PM, Warner Losh wrote: > > > > > On Mar 2, 2014, at 4:56 PM, Patrick Kelsey wrote: > > > > > Hi, > > > > > > The attached patch (fdt_probe_order_control.patch) allows control over > > the > > > probe order of simplebus child devices by using a "probe-order" property > > in > > > simplebus child nodes in the .dts file > > > > Where is the probe-order property defined? I can't seem to find it in the > > bindings. > > Also, I don't think it is necessary. This is a software construct, so > > doesn't really > > belong in the dts file. I'd really like to avoid FreeBSD specific hacks in > > the DTS > > files. > > > > It is currently not in any bindings, and has the status of being something > of my own invention and something possibly not ever used outside of private > codebases. I think this is something that would fit conceptually with the > miscellaneous bindings defined in ePAPR, as it is a rather generic > property. As to this being a software construct, I appreciate and support > the goal of keeping DTS files as pure hardware descriptions (and I'd also > argue that the way the status property is sometimes used turns it into a > software construct). > > Let's completely avoid the issue of am I arguing for adding a software > construct to DTS files by looking at this another way. Instead of a > 'probe-order' property that specifies a sort key, I could have the same > quality of result (same warts and all, as discussed below) with a property > that indicates whether the device is hardwired or has some sort of > pluggable interface (a property, say, called 'pluggable'). That would be a > pure hardware-as-it-is-designed description, and having that information > would allow me to do a sort that orders non-pluggable ahead of pluggable in > the probe/attach process. > > > > > > > This was motivated by booting FreeBSD from the eMMC on a BeagleBone > > Black, > > > which has a pluggable microSD card slot in addition to the eMMC. The > > order > > > that the mmc units are defined in sys/boot/fdt/dts/am335x.dtsi causes the > > > pluggable slot to be probed/attached first, so the device name assigned > > to > > > the eMMC soldered to the board changes depending on whether there is a > > card > > > in the pluggable slot, which makes establishing appropriate /etc/fstab > > > contents less than convenient. > > > > Sounds like you'd like to have some sort of name to instance mapping. > > The typical way this is solved is by naming the partitions so that ordering > > doesn't matter. Even if you don't handle this at the filesystem level, > > which > > is how others cope, you'd want this to be more of a direct binding rather > > than an > > ordering so that you get the effect you want (constant name) directly, > > rather > > than as a side-effect of ordering. > > > > Yes, ideally I'd like to be able to assign a name to every MMC/SD card slot > (hardwired or otherwise) in a system that depends only on the physical > location of that slot, and be able to resolve that name to an mmcsd device > instance. This works-here-side-effect-based approach is a result of the > ideal solution seemingly not being within reach given the available > resources. Using partition naming/glabel is a fair point, and does address > the /etc/fstab issue, but it still leaves me short of being able to > construct a product function that relies on knowing what's where when there > is no partitioning/filesystem in place, for example, something that boils > down to 'dd this image to the eMMC [or to the card in the card slot]'. > Perhaps the answer to that is to build something using devinfo(3)/devd(8) > to identify what mmcsdX is currently attached to each controller when I > need to know. > > > > If you insist on that, then having a something more like > > "freesbd,unit-number" > > property would also accomplish this. But that would only wire the > > controller unit > > number, and not the resulting mmcsdX device. > > > > I understand fully that the utility of this goes as far as having none of > the hardwired devices sharing controllers with pluggable devices in such a > way that the controllers can find the attached pluggable devices first. > Subject to that limitation as it is, this does usefully apply to at least > one real system now, and it is a behavior I can take advantage of when > designing new hardware to make developing the associated FreeBSD-based > product software easier (namely, by not having to cobble together a > poor-man's udev [which is not saying users of udev are exactly rich], > and/or worry about how a customer might label the fat partition on an SD > card they insert). > > More generally, whether this is or isn't a widely useful thing in the end, > what is the current process for introducing a new property for use in DTS > files? > > > > > By using the "probe-order" property in > > > sys/boot/fdt/dts/beaglebone-black.dts (see attached > > > beaglebone_black_mmc_probe_order.patch), I am able to swap the order in > > > which the mmc units are probed/attached for that board. This avoids > > > inappropriate hacking of the mmc definition order in am335x.dtsi, which > > is > > > shared among multiple boards. > > > > > > This is not a general solution to the problem of wanting stable device > > > names for hard-wired MMC devices when pluggable slots are present in the > > > system. There could, for example, be a multi-slot MMC controller with a > > > mixture of hard-wired and pluggable devices attached, and this would not > > > address that case. However, it does address the needs of BeagleBone > > Black, > > > and the mechanism may be of use for similar issues on other platforms. > > > > As it isn't a generic solution, I'd be biased against adopting it. What's > > wrong > > with using glabel to accomplish this (either with a label specific > > property, or > > by using a ufs label and mounting /dev/ufs/foo). > > > > > It is not my intention to lobby for adding this to the kernel at this > point. Whether it is widely-enough or only very-narrowly useful I would > say is currently unknown. My intention in posting this patch was for > others on the list(s) that might find it useful to see it and have access > to it, and to attract thoughtful criticism such as yours. > > I appreciate you taking the time to respond. > > -Patrick There's a standard property for mmc/sd devices, "non-removable" whose presence denotes things like soldered-on eMMC parts. Only one of our many sdhci drivers supports it right now (imx). In general the core part of the driver (dev/sdhci) doesn't have good support for insert/remove/presence detection that's handled off to the side (whether it's non-removable or a gpio pin). That alone doesn't solve the wider problem, though, which I think breaks down into two pieces. Let's say you've got two slots, call them left and right. You end up with these two problems... * Sometimes the right slot is mmcsd0, but it turns into mmcsd1 if there's a card in the left slot when I boot; I don't want it to change. * I want the slot on the left to be named '1' and the right to be '0'. The first problem is easily solved without impacting dts in any way. We just wire down the relationship controllerN -> mmcN -> mmcsdN. This is exactly equivelent to the old ATA_STATIC_ID option in its effect -- you don't get to choose the names, but you know they won't change based on which devices are present. It could be controlled with a tunable. It's harder to envision the fix for the second part without adding an ad-hoc property for the devices. Even with a property I'm not sure how easy it would be. There's been talk of moving mmcsd towards using CAM. I don't know that much about cam, but I suspect it rules out doing anything about #1 as well. At least, I've never heard of wiring down /dev/daN to a specific device/slot/whatever. -- Ian From owner-freebsd-embedded@FreeBSD.ORG Tue Mar 4 14:18:33 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E3232C84 for ; Tue, 4 Mar 2014 14:18:33 +0000 (UTC) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A9ABDB1A for ; Tue, 4 Mar 2014 14:18:33 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id tp5so4268583ieb.12 for ; Tue, 04 Mar 2014 06:18:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=1WAyLUBy7JVV90a7udK3Tk3JWwo/TVbXYKXh3yKcOmw=; b=aO7yzhnYPSi+Sn1cjZ19FCnXlxJ/AgUrwlXIJQ1mEthuT9ACF6lEiEIzfAvpq9GmTx MTNujV0nhLLq1IYkrH/bDp+TF/lRU/zXe89KmE0JNl9qTn4HKPPmxSwojjv66X9mdw3i ChgDRcOBV6VkMTTwLX3BvSXMJ/kEo4f7Jooh4BkjHKQpA8rtEHhcjirqTW06dQ/qTxqy VDKhRP35aXvpMkFQCGoZlkp0OhCdKFVFIDlcwSBsGKEcRz58QMB9N3WMiA0iAp6N+Bui 6QY6szE6eUo/0OJE7WlXndYqks8LzEi5oKNsVKNrk4LZsW/s7eG4vkGWkyww3W8TfdU/ p8Vw== X-Gm-Message-State: ALoCoQmfOniTg7XjgHZPTFyvOxiNKZQhBYnN90r3dIIOYE5kETG3pTfNCTVtdW2D8Guiw4UUKfmD X-Received: by 10.42.129.9 with SMTP id o9mr31419798ics.38.1393942707471; Tue, 04 Mar 2014 06:18:27 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id gd5sm3012340igd.5.2014.03.04.06.18.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Mar 2014 06:18:26 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Warner Losh In-Reply-To: <1393939277.1149.300.camel@revolution.hippie.lan> Date: Tue, 4 Mar 2014 07:18:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <04264938-F826-4B3A-8285-94C1092EC3F5@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) Cc: "freebsd-hackers@freebsd.org" , freebsd-arm@FreeBSD.org, freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 14:18:33 -0000 On Mar 4, 2014, at 6:21 AM, Ian Lepore wrote: > There's been talk of moving mmcsd towards using CAM. I don't know = that > much about cam, but I suspect it rules out doing anything about #1 as > well. At least, I've never heard of wiring down /dev/daN to a = specific > device/slot/whatever. CAM has supported this for years, through hints. Not sure there=92s an = FDT binding for it yet. Warner From owner-freebsd-embedded@FreeBSD.ORG Tue Mar 4 14:30:13 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C790433; Tue, 4 Mar 2014 14:30:13 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2EAA2CAC; Tue, 4 Mar 2014 14:30:12 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s24EPOB9027697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Mar 2014 15:25:25 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id s24EPEvL082602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2014 15:25:14 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id s24EPE8f038990; Tue, 4 Mar 2014 15:25:14 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s24EPDlY038989; Tue, 4 Mar 2014 15:25:13 +0100 (CET) (envelope-from ticso) Date: Tue, 4 Mar 2014 15:25:13 +0100 From: Bernd Walter To: Ian Lepore Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) Message-ID: <20140304142513.GH15675@cicely7.cicely.de> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1393939277.1149.300.camel@revolution.hippie.lan> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: "freebsd-hackers@freebsd.org" , freebsd-arm@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ticso@cicely.de List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 14:30:13 -0000 On Tue, Mar 04, 2014 at 06:21:17AM -0700, Ian Lepore wrote: > There's a standard property for mmc/sd devices, "non-removable" whose > presence denotes things like soldered-on eMMC parts. Only one of our > many sdhci drivers supports it right now (imx). In general the core > part of the driver (dev/sdhci) doesn't have good support for > insert/remove/presence detection that's handled off to the side (whether > it's non-removable or a gpio pin). > > That alone doesn't solve the wider problem, though, which I think breaks > down into two pieces. Let's say you've got two slots, call them left > and right. You end up with these two problems... > > * Sometimes the right slot is mmcsd0, but it turns into mmcsd1 if > there's a card in the left slot when I boot; I don't want it to > change. > * I want the slot on the left to be named '1' and the right to be > '0'. > > The first problem is easily solved without impacting dts in any way. We > just wire down the relationship controllerN -> mmcN -> mmcsdN. This is > exactly equivelent to the old ATA_STATIC_ID option in its effect -- you > don't get to choose the names, but you know they won't change based on > which devices are present. It could be controlled with a tunable. > > It's harder to envision the fix for the second part without adding an > ad-hoc property for the devices. Even with a property I'm not sure how > easy it would be. > > There's been talk of moving mmcsd towards using CAM. I don't know that > much about cam, but I suspect it rules out doing anything about #1 as > well. At least, I've never heard of wiring down /dev/daN to a specific > device/slot/whatever. CAM has wiring support. This had been the case for SCSI even before CAM was written and was vital in the days with many SCSI drives but without disk labeling support. Example from sys/conf/NOTES: hint.scbus.0.at="ahc0" hint.scbus.1.at="ahc1" hint.scbus.1.bus="0" hint.scbus.3.at="ahc2" hint.scbus.3.bus="0" hint.scbus.2.at="ahc2" hint.scbus.2.bus="1" hint.da.0.at="scbus0" hint.da.0.target="0" hint.da.0.unit="0" hint.da.1.at="scbus3" hint.da.1.target="1" hint.da.2.at="scbus2" hint.da.2.target="3" hint.sa.1.at="scbus1" hint.sa.1.target="6" -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-embedded@FreeBSD.ORG Tue Mar 4 15:05:10 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 91546E41 for ; Tue, 4 Mar 2014 15:05:10 +0000 (UTC) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 57354FC6 for ; Tue, 4 Mar 2014 15:05:09 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id tp5so4337395ieb.12 for ; Tue, 04 Mar 2014 07:05:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=MDjqcPoGmamcHa+Kgfi5I4de6f3Jgf4TgNPAYEMpwhc=; b=mZY5y9q3dgM5hAG7ZLTQLEmF/uHrGJE8jp2BXI418pEEvE3kPLahBjuRMz3VoksdMl AeN6A3lpb30JvsCBUllN/IdqYndIw21a0HEMPlJaDs3ownpov7wQ33+EO//yHDFXq9Nu OaquDCbmI9gAFMIJy3teGKiHeq91kpZfGcLpSpFzRsh1+mev/r/e7aeUR6T71GetFjyg hEsgqOjNsK+A2SBRmoFCE93vvLutD2cbpBZCPUH/zDEe29ge0sLrGJ2NK8UKRjSVkluy jR6ABNw1HBrGUC/2nEh7fAxSPThbdHn5F/GeqSp0fngHlJ0veTGSmgiEdQ2HSHw6aku5 QTCA== X-Gm-Message-State: ALoCoQl/KZghYnxR8aXHdJUl4YJIPk4yRYCwawmEai5xraSEuQAF/N9/A/FJCAnI1yshyBRIGdcG X-Received: by 10.43.65.145 with SMTP id xm17mr628294icb.35.1393945509501; Tue, 04 Mar 2014 07:05:09 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id rj10sm50728789igc.8.2014.03.04.07.05.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Mar 2014 07:05:08 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Warner Losh In-Reply-To: Date: Tue, 4 Mar 2014 08:05:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7110A2B6-A7E4-42F8-8232-9B09BE769C74@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> To: Patrick Kelsey X-Mailer: Apple Mail (2.1874) Cc: "freebsd-hackers@freebsd.org" , freebsd-arm@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 15:05:10 -0000 On Mar 3, 2014, at 11:05 PM, Patrick Kelsey wrote: > On Sun, Mar 2, 2014 at 9:38 PM, Warner Losh wrote: >=20 > On Mar 2, 2014, at 4:56 PM, Patrick Kelsey wrote: >=20 > > Hi, > > > > The attached patch (fdt_probe_order_control.patch) allows control = over the > > probe order of simplebus child devices by using a "probe-order" = property in > > simplebus child nodes in the .dts file >=20 > Where is the probe-order property defined? I can=92t seem to find it = in the bindings. > Also, I don=92t think it is necessary. This is a software construct, = so doesn=92t really > belong in the dts file. I=92d really like to avoid FreeBSD specific = hacks in the DTS > files. >=20 > It is currently not in any bindings, and has the status of being = something of my own invention and something possibly not ever used = outside of private codebases. I think this is something that would fit = conceptually with the miscellaneous bindings defined in ePAPR, as it is = a rather generic property. As to this being a software construct, I = appreciate and support the goal of keeping DTS files as pure hardware = descriptions (and I'd also argue that the way the status property is = sometimes used turns it into a software construct). Generally, anything that=92s a FreeBSD invention needs to be prefixed by = =91freebsd,=92 or we need to get it through the semi-standarded = device-tree list process. > Let's completely avoid the issue of am I arguing for adding a software = construct to DTS files by looking at this another way. Instead of a = 'probe-order' property that specifies a sort key, I could have the same = quality of result (same warts and all, as discussed below) with a = property that indicates whether the device is hardwired or has some sort = of pluggable interface (a property, say, called 'pluggable'). That = would be a pure hardware-as-it-is-designed description, and having that = information would allow me to do a sort that orders non-pluggable ahead = of pluggable in the probe/attach process. There=92s already properties for this defined, so that wouldn=92t be = terrible. But I=92m not sure how that would affect the order. > > This was motivated by booting FreeBSD from the eMMC on a BeagleBone = Black, > > which has a pluggable microSD card slot in addition to the eMMC. = The order > > that the mmc units are defined in sys/boot/fdt/dts/am335x.dtsi = causes the > > pluggable slot to be probed/attached first, so the device name = assigned to > > the eMMC soldered to the board changes depending on whether there is = a card > > in the pluggable slot, which makes establishing appropriate = /etc/fstab > > contents less than convenient. >=20 > Sounds like you=92d like to have some sort of name to instance = mapping. > The typical way this is solved is by naming the partitions so that = ordering > doesn=92t matter. Even if you don=92t handle this at the filesystem = level, which > is how others cope, you=92d want this to be more of a direct binding = rather than an > ordering so that you get the effect you want (constant name) directly, = rather > than as a side-effect of ordering. >=20 > Yes, ideally I'd like to be able to assign a name to every MMC/SD card = slot (hardwired or otherwise) in a system that depends only on the = physical location of that slot, and be able to resolve that name to an = mmcsd device instance. This works-here-side-effect-based approach is a = result of the ideal solution seemingly not being within reach given the = available resources. Using partition naming/glabel is a fair point, and = does address the /etc/fstab issue, but it still leaves me short of being = able to construct a product function that relies on knowing what's where = when there is no partitioning/filesystem in place, for example, = something that boils down to 'dd this image to the eMMC [or to the card = in the card slot]'. Perhaps the answer to that is to build something = using devinfo(3)/devd(8) to identify what mmcsdX is currently attached = to each controller when I need to know. We don=92t assign names based on physical location in FreeBSD generally. = The old concept of wiring a card to an address is mostly gone at this = point. You can get information from devinfo to find where the devices actually = live, and do things based on that. There=92s supposed to be (but might = not actually be) sufficient plug and play information so that people = that are invested in tying a physical location to a particular task can = dig that information out. > If you insist on that, then having a something more like = =93freesbd,unit-number=94 > property would also accomplish this. But that would only wire the = controller unit > number, and not the resulting mmcsdX device. >=20 > I understand fully that the utility of this goes as far as having none = of the hardwired devices sharing controllers with pluggable devices in = such a way that the controllers can find the attached pluggable devices = first. Subject to that limitation as it is, this does usefully apply to = at least one real system now, and it is a behavior I can take advantage = of when designing new hardware to make developing the associated = FreeBSD-based product software easier (namely, by not having to cobble = together a poor-man's udev [which is not saying users of udev are = exactly rich], and/or worry about how a customer might label the fat = partition on an SD card they insert). Device security goes well beyond device enumeration ordering, but that=92s= a fair point. > More generally, whether this is or isn't a widely useful thing in the = end, what is the current process for introducing a new property for use = in DTS files? You need to get it approved via the devicetree-spec@vger.kernel.org = mailing list to make it official. There are efforts to move this away = from Linux infrastructure to its own infrastructure... > > By using the "probe-order" property in > > sys/boot/fdt/dts/beaglebone-black.dts (see attached > > beaglebone_black_mmc_probe_order.patch), I am able to swap the order = in > > which the mmc units are probed/attached for that board. This avoids > > inappropriate hacking of the mmc definition order in am335x.dtsi, = which is > > shared among multiple boards. > > > > This is not a general solution to the problem of wanting stable = device > > names for hard-wired MMC devices when pluggable slots are present in = the > > system. There could, for example, be a multi-slot MMC controller = with a > > mixture of hard-wired and pluggable devices attached, and this would = not > > address that case. However, it does address the needs of BeagleBone = Black, > > and the mechanism may be of use for similar issues on other = platforms. >=20 > As it isn=92t a generic solution, I=92d be biased against adopting it. = What=92s wrong > with using glabel to accomplish this (either with a label specific = property, or > by using a ufs label and mounting /dev/ufs/foo). >=20 >=20 > It is not my intention to lobby for adding this to the kernel at this = point. Whether it is widely-enough or only very-narrowly useful I would = say is currently unknown. My intention in posting this patch was for = others on the list(s) that might find it useful to see it and have = access to it, and to attract thoughtful criticism such as yours. Sure. Tying devices name to physical location is a hardish FreeBSD = problem, but has been since around FreeBSD 3. =46rom the sounds of things, you=92d want any SD card found on this = controller to have a unique name=85 The move to CAM may help that, but = we=92d need to invent FDT bindings, I think, for CAM to get the device = wiring info it currently gets from hints... > I appreciate you taking the time to respond. Sure thing=85 Warner= From owner-freebsd-embedded@FreeBSD.ORG Wed Mar 5 06:53:49 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD21F76C; Wed, 5 Mar 2014 06:53:49 +0000 (UTC) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B0D09CDA; Wed, 5 Mar 2014 06:53:48 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id ec20so382897lab.39 for ; Tue, 04 Mar 2014 22:53:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=w7LcJ9uQP48xbWxPvvAoLfI8VUVFNN5THwn5WqSEtCk=; b=g86DhWM7ElFTgtbR2FBjwDsOQI1dvkLjLvct/C5XnW/Gfyys07xQtFWKC+Y2dLMzAP X3pm/j5PogPTlY41AWBGI1ZIHAHP6PMz9yu5QjQ2Pd8rDi4uSSag+YjphBxLX/DQ+Fl/ mf5h08WdIBDAv66Fl3LnvXeEziP1gCV/rKborvSP9DeLjZu9KcxqoCE8QFzhEeD7ytdq GXeTW5ZxMrf72q9jQJsLDcZoyblfAEnJRuHNSFEmcJNM87nOdAjyxGiUHwyZ2WbVx6nY k/uhWKiBA7fEjqJdgUUyH8LcMdB4NTDie2ZtZhmDll+I5/bY2M6xv8q22wOruOUMHC9+ hEnw== MIME-Version: 1.0 X-Received: by 10.112.77.138 with SMTP id s10mr110546lbw.59.1394002426743; Tue, 04 Mar 2014 22:53:46 -0800 (PST) Sender: pkelsey@gmail.com Received: by 10.112.142.5 with HTTP; Tue, 4 Mar 2014 22:53:46 -0800 (PST) In-Reply-To: <1393939277.1149.300.camel@revolution.hippie.lan> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> Date: Wed, 5 Mar 2014 01:53:46 -0500 X-Google-Sender-Auth: RcUlIv0UuuCSFCW0q6fIaFcdswc Message-ID: Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Patrick Kelsey To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" , freebsd-arm@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 06:53:50 -0000 On Tue, Mar 4, 2014 at 8:21 AM, Ian Lepore wrote: > > There's a standard property for mmc/sd devices, "non-removable" whose > presence denotes things like soldered-on eMMC parts. Only one of our > many sdhci drivers supports it right now (imx). In general the core > part of the driver (dev/sdhci) doesn't have good support for > insert/remove/presence detection that's handled off to the side (whether > it's non-removable or a gpio pin). > > That alone doesn't solve the wider problem, though, which I think breaks > down into two pieces. Let's say you've got two slots, call them left > and right. You end up with these two problems... > > * Sometimes the right slot is mmcsd0, but it turns into mmcsd1 if > there's a card in the left slot when I boot; I don't want it to > change. > And not just a boot-time issue, of course. If you were to remove those two cards and then reinsert them in the opposite time-order, their device names would swap. > * I want the slot on the left to be named '1' and the right to be > '0'. > > The first problem is easily solved without impacting dts in any way. We > just wire down the relationship controllerN -> mmcN -> mmcsdN. This is > exactly equivelent to the old ATA_STATIC_ID option in its effect -- you > don't get to choose the names, but you know they won't change based on > which devices are present. It could be controlled with a tunable. > > It's harder to envision the fix for the second part without adding an > ad-hoc property for the devices. Even with a property I'm not sure how > easy it would be. > We should be able to assign a geographic address (controllerX:slotY) to each mmcsd device in a given system (let's ignore for now the theoretical possibility of multiple cards on one bus). The 'controllerX' part of the address could be the controller's pathname from the devicetree, or an index assigned by mmcbr machinery at attach time. The "slotY" part of the address is assigned by the specific controller device driver using some internally-determined fixed mapping between the assigned values and its physical slots. This geographic address could be used to create an additional set of /dev entries with stable names. There could be a mechanism for user-configurable aliases for the geographical addresses. That kind of approach addresses both concerns, avoids trying to control device unit number assignment, and doesn't require any special support from the device tree. In the theoretically possible case of multiple MMC devices on one bus, the next piece of identifying information in the geographic address would have to be the RCA assigned to the card. As far as I am aware, in such a multidrop configuration, there is generally no way for a controller to know which RCA is assigned to which slot due to the contention-based (that is, non-geographic) nature of the initialization protocol, so this would be a configuration in which stable names would not be possible without an ad-hoc, out-of-band hardware support. Does anyone know if sharing a bus is only a possibility with MMC cards? I *think*, but am not feeling authoritative, that SD/SDIO cards do not support multiple devices on one bus. > > There's been talk of moving mmcsd towards using CAM. I don't know that > much about cam, but I suspect it rules out doing anything about #1 as > well. At least, I've never heard of wiring down /dev/daN to a specific > device/slot/whatever. > > -- Ian > > > From owner-freebsd-embedded@FreeBSD.ORG Wed Mar 5 10:59:27 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0CD11BCF for ; Wed, 5 Mar 2014 10:59:27 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 97F839BE for ; Wed, 5 Mar 2014 10:59:26 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 6954DB828; Wed, 5 Mar 2014 12:59:17 +0200 (SAST) Date: Wed, 5 Mar 2014 12:59:17 +0200 From: John Hay To: freebsd-embedded@freebsd.org Subject: embedded board with 3 X wireless Message-ID: <20140305105917.GA55874@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 10:59:27 -0000 Hi Guys, We have been using AVILA, xscale arm based boards with 4 X MiniPCI slots for a long time now. They are getting EOL and I was wondering what to replace it with. Any ideas? Here is my short list of requirements: - Run FreeBSD - Boot from itself, even if you need to add some flash. We used CF on AVILA. - Possible to have 3 X wireless. It can be a mix of builtin and some form of expansion. Wireless needs an antenna connector so that an external antenna can be connected. - 1 X Ethernet. More won't hurt, but is not needed. - 128MB RAM or more. Thanks John -- John Hay -- jhay@freebsd.org / jhay@meraka.org.za From owner-freebsd-embedded@FreeBSD.ORG Wed Mar 5 11:33:16 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE51C350 for ; Wed, 5 Mar 2014 11:33:16 +0000 (UTC) Received: from pzwet.vanderzwet.net (pzwet.vanderzwet.net [IPv6:2a01:4f8:190:8221::1:1]) by mx1.freebsd.org (Postfix) with ESMTP id A2476CA7 for ; Wed, 5 Mar 2014 11:33:16 +0000 (UTC) Received: from [192.168.99.86] (D57DF752.static.ziggozakelijk.nl [213.125.247.82]) by pzwet.vanderzwet.net (Postfix) with ESMTPSA id 2BCEAF4FF9A7; Wed, 5 Mar 2014 11:33:13 +0000 (UTC) Message-ID: <53170B77.1060607@rickvanderzwet.nl> Date: Wed, 05 Mar 2014 12:33:11 +0100 From: Rick van der Zwet User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: John Hay , freebsd-embedded@freebsd.org Subject: Re: embedded board with 3 X wireless References: <20140305105917.GA55874@zibbi.meraka.csir.co.za> In-Reply-To: <20140305105917.GA55874@zibbi.meraka.csir.co.za> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on pzwet.vanderzwet.net X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 11:33:16 -0000 On 05/03/14 11:59, John Hay wrote:> We have been using AVILA, xscale arm based boards with 4 X MiniPCI slots > for a long time now. They are getting EOL and I was wondering what to > replace it with. Any ideas? Here is my short list of requirements: > > - Run FreeBSD > - Boot from itself, even if you need to add some flash. We used CF on AVILA. > - Possible to have 3 X wireless. It can be a mix of builtin and some form > of expansion. Wireless needs an antenna connector so that an > external antenna can be connected. > - 1 X Ethernet. More won't hurt, but is not needed. > - 128MB RAM or more. Look at the ALIX boards, like http://www.pcengines.ch/alix2d2.htm if you are OK with using USB->WiFi Dongles. Best regards, /Rick -- http://rickvanderzwet.nl From owner-freebsd-embedded@FreeBSD.ORG Wed Mar 5 13:31:47 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D03B2C25 for ; Wed, 5 Mar 2014 13:31:47 +0000 (UTC) Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 952B59E9 for ; Wed, 5 Mar 2014 13:31:47 +0000 (UTC) Received: by mail-ig0-f172.google.com with SMTP id uq10so7717184igb.5 for ; Wed, 05 Mar 2014 05:31:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=v3nL8+l2MOPOQwrfj7uRwzmfI/Vvjwopc6aX8ig5em8=; b=AmhIyCXn/GA5uxomwnromQJooJT8Dh4yGOO75JuuVxkBaBixIZOYBKlCoE0JCcyZQ9 H/U8t0R9Mh6XBdIraqLItBTvdu7ZQuTNMsHyQH6naj2fm+7amDV2aLNaWhO3vX05ThUz ov3DHA2yQQLQvoV7YqL9UAqlRVt0lEI35Gn4m8JnH2wkQu15ExRTgCwgT4+p16UByvi0 vVd9JnKGefdE6KYLsOfolyMA0yWsXFx5hxfGnRG6ciJKOiZngpA57vcGvnS8Yg+wIdsa nOvgebqMz6S+tyoeFmWstnhVIMddPFuJb/XqoWsJaXzNCe4SP8FQeKICNetVHt+j2jTZ voQw== X-Gm-Message-State: ALoCoQkN8GHJsl2BAQcV3on5zrtK2NU9gXXWKtDBovp2zW6sw3cI6c780nT7XG7h4WVFhNGcg+bR X-Received: by 10.50.119.132 with SMTP id ku4mr8927242igb.35.1394026300866; Wed, 05 Mar 2014 05:31:40 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id v2sm13404632igk.7.2014.03.05.05.31.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 05:31:40 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Warner Losh In-Reply-To: Date: Wed, 5 Mar 2014 06:31:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> To: Patrick Kelsey X-Mailer: Apple Mail (2.1874) Cc: "freebsd-hackers@freebsd.org" , freebsd-arm , freebsd-embedded@freebsd.org, Ian Lepore X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 13:31:47 -0000 On Mar 4, 2014, at 11:53 PM, Patrick Kelsey wrote: >=20 >=20 >=20 > On Tue, Mar 4, 2014 at 8:21 AM, Ian Lepore wrote: >=20 > There's a standard property for mmc/sd devices, "non-removable" whose > presence denotes things like soldered-on eMMC parts. Only one of our > many sdhci drivers supports it right now (imx). In general the core > part of the driver (dev/sdhci) doesn't have good support for > insert/remove/presence detection that's handled off to the side = (whether > it's non-removable or a gpio pin). >=20 > That alone doesn't solve the wider problem, though, which I think = breaks > down into two pieces. Let's say you've got two slots, call them left > and right. You end up with these two problems... >=20 > * Sometimes the right slot is mmcsd0, but it turns into mmcsd1 = if > there's a card in the left slot when I boot; I don't want it = to > change. >=20 > And not just a boot-time issue, of course. If you were to remove = those two cards and then reinsert them in the opposite time-order, their = device names would swap. > =20 > * I want the slot on the left to be named '1' and the right to = be > '0'. >=20 > The first problem is easily solved without impacting dts in any way. = We > just wire down the relationship controllerN -> mmcN -> mmcsdN. This = is > exactly equivelent to the old ATA_STATIC_ID option in its effect -- = you > don't get to choose the names, but you know they won't change based on > which devices are present. It could be controlled with a tunable. >=20 > It's harder to envision the fix for the second part without adding an > ad-hoc property for the devices. Even with a property I'm not sure = how > easy it would be. >=20 > We should be able to assign a geographic address (controllerX:slotY) = to each mmcsd device in a given system (let's ignore for now the = theoretical possibility of multiple cards on one bus). The = 'controllerX' part of the address could be the controller's pathname = from the devicetree, or an index assigned by mmcbr machinery at attach = time. The "slotY" part of the address is assigned by the specific = controller device driver using some internally-determined fixed mapping = between the assigned values and its physical slots. This geographic = address could be used to create an additional set of /dev entries with = stable names. There could be a mechanism for user-configurable aliases = for the geographical addresses. There=92s already a chance to run a script when a device is attached = that can create /dev/slot0 or /dev/slot1 that has geographical = information available to it. People use ddvd for this in the USB world = all the time to make sure that tty devices get a symlink based on their = location or serial number. Why is mmc so different it needs its own mechanism? Warner > That kind of approach addresses both concerns, avoids trying to = control device unit number assignment, and doesn't require any special = support from the device tree. >=20 > In the theoretically possible case of multiple MMC devices on one bus, = the next piece of identifying information in the geographic address = would have to be the RCA assigned to the card. As far as I am aware, in = such a multidrop configuration, there is generally no way for a = controller to know which RCA is assigned to which slot due to the = contention-based (that is, non-geographic) nature of the initialization = protocol, so this would be a configuration in which stable names would = not be possible without an ad-hoc, out-of-band hardware support. Does = anyone know if sharing a bus is only a possibility with MMC cards? I = *think*, but am not feeling authoritative, that SD/SDIO cards do not = support multiple devices on one bus. > =20 >=20 > There's been talk of moving mmcsd towards using CAM. I don't know = that > much about cam, but I suspect it rules out doing anything about #1 as > well. At least, I've never heard of wiring down /dev/daN to a = specific > device/slot/whatever. >=20 > -- Ian >=20 >=20 >=20 From owner-freebsd-embedded@FreeBSD.ORG Wed Mar 5 18:13:31 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A2A0DE6A for ; Wed, 5 Mar 2014 18:13:31 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7E8E5ADA for ; Wed, 5 Mar 2014 18:13:31 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s25IDTEr071956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Mar 2014 10:13:30 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s25IDRhl071955; Wed, 5 Mar 2014 10:13:27 -0800 (PST) (envelope-from jmg) Date: Wed, 5 Mar 2014 10:13:27 -0800 From: John-Mark Gurney To: Rick van der Zwet Subject: Re: embedded board with 3 X wireless Message-ID: <20140305181327.GS47921@funkthat.com> Mail-Followup-To: Rick van der Zwet , John Hay , freebsd-embedded@freebsd.org References: <20140305105917.GA55874@zibbi.meraka.csir.co.za> <53170B77.1060607@rickvanderzwet.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53170B77.1060607@rickvanderzwet.nl> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 05 Mar 2014 10:13:30 -0800 (PST) Cc: freebsd-embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 18:13:31 -0000 Rick van der Zwet wrote this message on Wed, Mar 05, 2014 at 12:33 +0100: > On 05/03/14 11:59, John Hay wrote:> We have been using AVILA, xscale arm > based boards with 4 X MiniPCI slots > > for a long time now. They are getting EOL and I was wondering what to > > replace it with. Any ideas? Here is my short list of requirements: > > > > - Run FreeBSD > > - Boot from itself, even if you need to add some flash. We used CF on > AVILA. > > - Possible to have 3 X wireless. It can be a mix of builtin and some form > > of expansion. Wireless needs an antenna connector so that an > > external antenna can be connected. > > - 1 X Ethernet. More won't hurt, but is not needed. > > - 128MB RAM or more. > > Look at the ALIX boards, like http://www.pcengines.ch/alix2d2.htm if you > are OK with using USB->WiFi Dongles. Last I looked, most USB-Wifi dongles could not handled AP point duties very well, or if they could, they could only handle ONE SSID, which means setting up multiple networks would be an issue... Just make sure you do your research before you dive... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-embedded@FreeBSD.ORG Wed Mar 5 18:55:58 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE3E1E98; Wed, 5 Mar 2014 18:55:58 +0000 (UTC) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AA6F4E6D; Wed, 5 Mar 2014 18:55:57 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id w7so1020371lbi.30 for ; Wed, 05 Mar 2014 10:55:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=I7zc9OQgiYTicjrU8DpLYtH888nxwDgi952COvK+C1o=; b=KporpxlEpERvTCqkrUSvDFJBIwj1uyxHYtwkIjsuIYSjFiXq48bB983EvxOBojxHDo cbBj5uGRHJaI0cspJLd4277FJQxn9iZCjx7oq0vrygfl+DP10pXnpXMa0zMoiiOvloy1 DsmRNGsrmw6tFoeuTY2zwUfh6oxCfiHMrk/+iUzPO58XOSS3WM6OU2ym/j0K6C7DfX5p bYcb86klyryBk4oBK3E3nF8SdsZol6CVgOOAqN7YpBal14VENpcb7zdNbVM4xBqIZDAm MmgjGjFCC4nC/7AAnAk/vhXgLe2sYGBlT+MnLzrVQu9BxrUOH5PxB4u73jL6lVdoPGYs 476Q== MIME-Version: 1.0 X-Received: by 10.152.172.103 with SMTP id bb7mr2520422lac.49.1394045755731; Wed, 05 Mar 2014 10:55:55 -0800 (PST) Sender: pkelsey@gmail.com Received: by 10.112.142.5 with HTTP; Wed, 5 Mar 2014 10:55:55 -0800 (PST) In-Reply-To: <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> Date: Wed, 5 Mar 2014 13:55:55 -0500 X-Google-Sender-Auth: hUgRJUIBql3DzZ-hk-6J0zryuhU Message-ID: Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Patrick Kelsey To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" , freebsd-arm , freebsd-embedded@freebsd.org, Ian Lepore X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 18:55:58 -0000 On Wed, Mar 5, 2014 at 8:31 AM, Warner Losh wrote: > > On Mar 4, 2014, at 11:53 PM, Patrick Kelsey wrote: > > > > > > > > > On Tue, Mar 4, 2014 at 8:21 AM, Ian Lepore wrote: > > > > There's a standard property for mmc/sd devices, "non-removable" whose > > presence denotes things like soldered-on eMMC parts. Only one of our > > many sdhci drivers supports it right now (imx). In general the core > > part of the driver (dev/sdhci) doesn't have good support for > > insert/remove/presence detection that's handled off to the side (whether > > it's non-removable or a gpio pin). > > > > That alone doesn't solve the wider problem, though, which I think breaks > > down into two pieces. Let's say you've got two slots, call them left > > and right. You end up with these two problems... > > > > * Sometimes the right slot is mmcsd0, but it turns into mmcsd1 if > > there's a card in the left slot when I boot; I don't want it to > > change. > > > > And not just a boot-time issue, of course. If you were to remove those > two cards and then reinsert them in the opposite time-order, their device > names would swap. > > > > * I want the slot on the left to be named '1' and the right to be > > '0'. > > > > The first problem is easily solved without impacting dts in any way. We > > just wire down the relationship controllerN -> mmcN -> mmcsdN. This is > > exactly equivelent to the old ATA_STATIC_ID option in its effect -- you > > don't get to choose the names, but you know they won't change based on > > which devices are present. It could be controlled with a tunable. > > > > It's harder to envision the fix for the second part without adding an > > ad-hoc property for the devices. Even with a property I'm not sure how > > easy it would be. > > > > We should be able to assign a geographic address (controllerX:slotY) to > each mmcsd device in a given system (let's ignore for now the theoretical > possibility of multiple cards on one bus). The 'controllerX' part of the > address could be the controller's pathname from the devicetree, or an index > assigned by mmcbr machinery at attach time. The "slotY" part of the > address is assigned by the specific controller device driver using some > internally-determined fixed mapping between the assigned values and its > physical slots. This geographic address could be used to create an > additional set of /dev entries with stable names. There could be a > mechanism for user-configurable aliases for the geographical addresses. > > There's already a chance to run a script when a device is attached that > can create /dev/slot0 or /dev/slot1 that has geographical information > available to it. People use ddvd for this in the USB world all the time to > make sure that tty devices get a symlink based on their location or serial > number. > > Why is mmc so different it needs its own mechanism? > I'm laying out my view of the information that would be needed and the types of actions that would have to be taken based on that information to solve the issue. I'm not saying devd can't be the piece that is used to implement the actions (indeed, I noted devd as a potential building block for a solution in my initial response). I'm also not saying mmc needs its own mechanism, I'm saying it needs /a/ mechanism, and so far there still seems to be something missing (because it's not there, or I'm still ignorant of it). What seems to be missing is geographical addressing for mmc devices. I think what you might be saying is that the existing mmcsd add/remove code could be augmented to send devctl notifications, along the lines of: devctl_notify("MMC", "DEVICE", "ATTACH"|"DETACH", "... controller= slot= rca=") and then I and the fine author of devctl and devd would be pleased. -Patrick From owner-freebsd-embedded@FreeBSD.ORG Wed Mar 5 21:25:07 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1119D1AD for ; Wed, 5 Mar 2014 21:25:07 +0000 (UTC) Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C8438F71 for ; Wed, 5 Mar 2014 21:25:06 +0000 (UTC) Received: by mail-ig0-f180.google.com with SMTP id hl1so5427629igb.1 for ; Wed, 05 Mar 2014 13:25:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=1Q85jbcZOR80W0xpcwTOj/Eq244eAbVtni/k61r9+Sc=; b=SlPDki26jRd7HnI/eL8y3BuyUc920smIaDh4VCHMhNKtARbZ2Rs5/SrrGaQsdtX786 oFPcdjiA0iUD99dDqo7ccOo9LvaVr8/VjvEICwzSGw2M6pLRiZ2gXGD2s+g4XiLo4S3L QMiTB2+Y36IofmSwkumc809pWjss2MO4LYVKhiyp8Dg48fXrV9iwGtXlR7aAQP41SgTf 0KudOM5X/OgUHTle54i4CvmkVheTEAd5JeThyW6YlqcX2I/OqrFZyOppoSxLg2nEDamy 4mVx0/shm65hPFVdEVcmYCMengzKHFK4OFp3PAeu5fuB1IKFPCaGL7ZxS7PmnTAbCD1F BKSw== X-Gm-Message-State: ALoCoQk0Th2W2ieIM9bnDrNPHcNgfEAigmJTyLMYkgtZ0S2qNwqYJz/tu6+F20J+EtMZw+/xe28e X-Received: by 10.43.170.193 with SMTP id nr1mr2457087icc.82.1394054700459; Wed, 05 Mar 2014 13:25:00 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id f1sm17122264igy.2.2014.03.05.13.24.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 13:24:59 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Warner Losh In-Reply-To: Date: Wed, 5 Mar 2014 14:24:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <16A5203B-B06D-4129-A54F-F34D5FA28D2B@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> To: Patrick Kelsey X-Mailer: Apple Mail (2.1874) Cc: "freebsd-hackers@freebsd.org" , freebsd-arm , freebsd-embedded@freebsd.org, Ian Lepore X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 21:25:07 -0000 On Mar 5, 2014, at 11:55 AM, Patrick Kelsey wrote: >=20 >=20 >=20 > On Wed, Mar 5, 2014 at 8:31 AM, Warner Losh wrote: >=20 > On Mar 4, 2014, at 11:53 PM, Patrick Kelsey wrote: >=20 > > > > > > > > On Tue, Mar 4, 2014 at 8:21 AM, Ian Lepore wrote: > > > > There's a standard property for mmc/sd devices, "non-removable" = whose > > presence denotes things like soldered-on eMMC parts. Only one of = our > > many sdhci drivers supports it right now (imx). In general the core > > part of the driver (dev/sdhci) doesn't have good support for > > insert/remove/presence detection that's handled off to the side = (whether > > it's non-removable or a gpio pin). > > > > That alone doesn't solve the wider problem, though, which I think = breaks > > down into two pieces. Let's say you've got two slots, call them = left > > and right. You end up with these two problems... > > > > * Sometimes the right slot is mmcsd0, but it turns into mmcsd1 = if > > there's a card in the left slot when I boot; I don't want it = to > > change. > > > > And not just a boot-time issue, of course. If you were to remove = those two cards and then reinsert them in the opposite time-order, their = device names would swap. > > > > * I want the slot on the left to be named '1' and the right to = be > > '0'. > > > > The first problem is easily solved without impacting dts in any way. = We > > just wire down the relationship controllerN -> mmcN -> mmcsdN. This = is > > exactly equivelent to the old ATA_STATIC_ID option in its effect -- = you > > don't get to choose the names, but you know they won't change based = on > > which devices are present. It could be controlled with a tunable. > > > > It's harder to envision the fix for the second part without adding = an > > ad-hoc property for the devices. Even with a property I'm not sure = how > > easy it would be. > > > > We should be able to assign a geographic address (controllerX:slotY) = to each mmcsd device in a given system (let's ignore for now the = theoretical possibility of multiple cards on one bus). The = 'controllerX' part of the address could be the controller's pathname = from the devicetree, or an index assigned by mmcbr machinery at attach = time. The "slotY" part of the address is assigned by the specific = controller device driver using some internally-determined fixed mapping = between the assigned values and its physical slots. This geographic = address could be used to create an additional set of /dev entries with = stable names. There could be a mechanism for user-configurable aliases = for the geographical addresses. >=20 > There=92s already a chance to run a script when a device is attached = that can create /dev/slot0 or /dev/slot1 that has geographical = information available to it. People use ddvd for this in the USB world = all the time to make sure that tty devices get a symlink based on their = location or serial number. >=20 > Why is mmc so different it needs its own mechanism? >=20 > I'm laying out my view of the information that would be needed and the = types of actions that would have to be taken based on that information = to solve the issue. I'm not saying devd can't be the piece that is used = to implement the actions (indeed, I noted devd as a potential building = block for a solution in my initial response). I'm also not saying mmc = needs its own mechanism, I'm saying it needs /a/ mechanism, and so far = there still seems to be something missing (because it's not there, or = I'm still ignorant of it). >=20 > What seems to be missing is geographical addressing for mmc devices. >=20 > I think what you might be saying is that the existing mmcsd add/remove = code could be augmented to send devctl notifications, along the lines = of: >=20 > devctl_notify("MMC", "DEVICE", "ATTACH"|"DETACH", "... = controller=3D = slot=3D rca=3D") >=20 > and then I and the fine author of devctl and devd would be pleased. MMC doesn=92t need anything special here. That=92s already present. = Looking at the device tree we see on one of the platforms that=92s handy = for me to access: at91_mci0 mmc0 mmcsd0 at rca=3D0xb368 So you know that mmcsd0 is on mmc0 bus attached to at91_mci0, which is = ultimately the FDT node where things came from. There=92s not a = user-defined slot associated with this (and we should have a SLOT A vs = SLOT B as a location info for this platform, because we can have two = cards on the one bus in the MMC case), true, but for your use case I = don=92t think that you need it. We should be attaching the host = controller regardless of whether the or not there=92s a card in there, = so it will be fixed. While some additional information would be useful = to publish, I don=92t think your use case requires it=85 Warner= From owner-freebsd-embedded@FreeBSD.ORG Wed Mar 5 21:56:05 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6C2858AA; Wed, 5 Mar 2014 21:56:05 +0000 (UTC) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4B7E02BE; Wed, 5 Mar 2014 21:56:04 +0000 (UTC) Received: by mail-la0-f50.google.com with SMTP id y1so1139360lam.37 for ; Wed, 05 Mar 2014 13:56:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ng7adWkPMKnLijqoT28RKh0vpUtyT+ZOZ/fwDaFiiGM=; b=xkEheOH7OouvT4awjNT3rOGk7usqHOrAqPQ4ij42FOg16Ssk9VwxpPPnwcocJ+R8yD F94Ry4jA3aQFPToQl8Sq0W1y310ljn4qc4y3w21FFA1lpHv75HmEdC9ft5O0UtON5Cc0 9V23CrDsS9w9eXFXLGOc1hrjs7HjLgQhReuheLwbSo+tIJr5j+IXWRPiJKTB7EySs8an MOnxJSmwyUda0lmfRK9nXY+6eHglqbAQ1/Qlk35taWNizHafeCeqbdFjB0W+nCVxRa7U hwwqavb0ZggV4hJ2ed664Lj9MX/28u91HsXVXDsxb2t3FuxtgbghOWCdfMPM09Q6k2Rv adgA== MIME-Version: 1.0 X-Received: by 10.152.181.37 with SMTP id dt5mr3242115lac.43.1394056562325; Wed, 05 Mar 2014 13:56:02 -0800 (PST) Sender: pkelsey@gmail.com Received: by 10.112.142.5 with HTTP; Wed, 5 Mar 2014 13:56:02 -0800 (PST) In-Reply-To: <16A5203B-B06D-4129-A54F-F34D5FA28D2B@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> <16A5203B-B06D-4129-A54F-F34D5FA28D2B@bsdimp.com> Date: Wed, 5 Mar 2014 16:56:02 -0500 X-Google-Sender-Auth: ZCJ9SdXeFPz5hc2HF0Hels8UoLQ Message-ID: Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Patrick Kelsey To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" , freebsd-arm , freebsd-embedded@freebsd.org, Ian Lepore X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 21:56:05 -0000 On Wed, Mar 5, 2014 at 4:24 PM, Warner Losh wrote: > > On Mar 5, 2014, at 11:55 AM, Patrick Kelsey wrote: > > > > > > > > > On Wed, Mar 5, 2014 at 8:31 AM, Warner Losh wrote: > > > > On Mar 4, 2014, at 11:53 PM, Patrick Kelsey wrote: > > > > > > > > > > > > > > On Tue, Mar 4, 2014 at 8:21 AM, Ian Lepore wrote: > > > > > > There's a standard property for mmc/sd devices, "non-removable" whose > > > presence denotes things like soldered-on eMMC parts. Only one of our > > > many sdhci drivers supports it right now (imx). In general the core > > > part of the driver (dev/sdhci) doesn't have good support for > > > insert/remove/presence detection that's handled off to the side > (whether > > > it's non-removable or a gpio pin). > > > > > > That alone doesn't solve the wider problem, though, which I think > breaks > > > down into two pieces. Let's say you've got two slots, call them left > > > and right. You end up with these two problems... > > > > > > * Sometimes the right slot is mmcsd0, but it turns into mmcsd1 if > > > there's a card in the left slot when I boot; I don't want it to > > > change. > > > > > > And not just a boot-time issue, of course. If you were to remove > those two cards and then reinsert them in the opposite time-order, their > device names would swap. > > > > > > * I want the slot on the left to be named '1' and the right to be > > > '0'. > > > > > > The first problem is easily solved without impacting dts in any way. > We > > > just wire down the relationship controllerN -> mmcN -> mmcsdN. This is > > > exactly equivelent to the old ATA_STATIC_ID option in its effect -- you > > > don't get to choose the names, but you know they won't change based on > > > which devices are present. It could be controlled with a tunable. > > > > > > It's harder to envision the fix for the second part without adding an > > > ad-hoc property for the devices. Even with a property I'm not sure how > > > easy it would be. > > > > > > We should be able to assign a geographic address (controllerX:slotY) > to each mmcsd device in a given system (let's ignore for now the > theoretical possibility of multiple cards on one bus). The 'controllerX' > part of the address could be the controller's pathname from the devicetree, > or an index assigned by mmcbr machinery at attach time. The "slotY" part > of the address is assigned by the specific controller device driver using > some internally-determined fixed mapping between the assigned values and > its physical slots. This geographic address could be used to create an > additional set of /dev entries with stable names. There could be a > mechanism for user-configurable aliases for the geographical addresses. > > > > There's already a chance to run a script when a device is attached that > can create /dev/slot0 or /dev/slot1 that has geographical information > available to it. People use ddvd for this in the USB world all the time to > make sure that tty devices get a symlink based on their location or serial > number. > > > > Why is mmc so different it needs its own mechanism? > > > > I'm laying out my view of the information that would be needed and the > types of actions that would have to be taken based on that information to > solve the issue. I'm not saying devd can't be the piece that is used to > implement the actions (indeed, I noted devd as a potential building block > for a solution in my initial response). I'm also not saying mmc needs its > own mechanism, I'm saying it needs /a/ mechanism, and so far there still > seems to be something missing (because it's not there, or I'm still > ignorant of it). > > > > What seems to be missing is geographical addressing for mmc devices. > > > > I think what you might be saying is that the existing mmcsd add/remove > code could be augmented to send devctl notifications, along the lines of: > > > > devctl_notify("MMC", "DEVICE", "ATTACH"|"DETACH", "... > controller= > slot= rca=") > > > > and then I and the fine author of devctl and devd would be pleased. > > MMC doesn't need anything special here. That's already present. Looking at > the device tree we see on one of the platforms that's handy for me to > access: > > at91_mci0 > mmc0 > mmcsd0 at rca=0xb368 > > So you know that mmcsd0 is on mmc0 bus attached to at91_mci0, which is > ultimately the FDT node where things came from. There's not a user-defined > slot associated with this (and we should have a SLOT A vs SLOT B as a > location info for this platform, because we can have two cards on the one > bus in the MMC case), true, but for your use case I don't think that you > need it. We should be attaching the host controller regardless of whether > the or not there's a card in there, so it will be fixed. While some > additional information would be useful to publish, I don't think your use > case requires it... > > The reason you need something extra here is that what is there now breaks down whenever you don't have a one-to-one mapping between controllers and buses. Any controller with more than one slot can yield something of the form: sdhci0 mmc0 mmcsd0 at rca=0xabcd mmc1 mmcsd1 at rca=0x1234 and you have no idea what physical slot in the system mmcsd0 and mmcsd1 are in. For my immediate use case, sure, I can rely on the one-to-one relationship between controllers and buses. At this point, though, rather than skate by on that happy coincidence, I'd rather invest what now seems to be a rather small amount of effort adding mmcsd devctl notifications that would cover the multiple-slots-per-controller case as well, and then build the rest of what I want on top of that information coming out of devd. On the at91 platform cited above, that allows you to connect two MMC cards to the same bus (i.e., multidrop configuration), is there any way to distinguish which card is in which physical slot? I'm still under the impression that this is the one case where we aren't going to be able to determine the physical location of every mmcsd device. -Patrick From owner-freebsd-embedded@FreeBSD.ORG Wed Mar 5 22:44:25 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DBF5C89A for ; Wed, 5 Mar 2014 22:44:25 +0000 (UTC) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9D245926 for ; Wed, 5 Mar 2014 22:44:25 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id lx4so1822796iec.23 for ; Wed, 05 Mar 2014 14:44:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=HOq1Ddfp1unL9wCPfgLIjB5qtYWTIUKcoPHCR3P70ZU=; b=OFZGMk/0vb87hafW59AXESwxv41xWNh9JpoRpbc4LdoGtVl/J/84fMznNPYxbTAXPV E0meBX72QKZ+jdbnSaORlpSDphiHBRbYbWEiH1Nvci3KaArlMtNB0yPiYhzDww9Cvjeb 97d6MV9O0EjSmORsU3j49WVX4VNuAwgFtEG8PNVeig42XPP35R3HQg5f2ZL35QoFKFPs QgdbbLpvrX34C810OeQ1ePoAPwAmhDTEKGJKkEDwp6xH60xbwFmaB9YdKTmWtxmx2LJF oe4e7jmNYrapxvOGWPLmcX0sZn1vNRPu5VLG1FAUt6IxNiBNFUvPbkGKnGW4tJbqz0lb 5H+g== X-Gm-Message-State: ALoCoQm534GdevCn5Pb3Y7UfzRMqTIN4KptxdET5BoB5/AlTEM2zJZEvMZ6ErN6t6zNgv4et0Ire X-Received: by 10.50.47.79 with SMTP id b15mr12006255ign.12.1394059464805; Wed, 05 Mar 2014 14:44:24 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id f1sm17748349igy.2.2014.03.05.14.44.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 14:44:24 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Warner Losh In-Reply-To: Date: Wed, 5 Mar 2014 15:44:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <39ED4040-2A6A-4D85-97D5-DCDE4ECCA0EC@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> <16A5203B-B06D-4129-A54F-F34D5FA28D2B@bsdimp.com> To: Patrick Kelsey X-Mailer: Apple Mail (2.1874) Cc: "freebsd-hackers@freebsd.org" , freebsd-arm , freebsd-embedded@freebsd.org, Ian Lepore X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 22:44:25 -0000 On Mar 5, 2014, at 2:56 PM, Patrick Kelsey wrote: >=20 >=20 >=20 > On Wed, Mar 5, 2014 at 4:24 PM, Warner Losh wrote: >=20 > On Mar 5, 2014, at 11:55 AM, Patrick Kelsey wrote: >=20 > > > > > > > > On Wed, Mar 5, 2014 at 8:31 AM, Warner Losh wrote: > > > > On Mar 4, 2014, at 11:53 PM, Patrick Kelsey wrote: > > > > > > > > > > > > > > On Tue, Mar 4, 2014 at 8:21 AM, Ian Lepore = wrote: > > > > > > There's a standard property for mmc/sd devices, "non-removable" = whose > > > presence denotes things like soldered-on eMMC parts. Only one of = our > > > many sdhci drivers supports it right now (imx). In general the = core > > > part of the driver (dev/sdhci) doesn't have good support for > > > insert/remove/presence detection that's handled off to the side = (whether > > > it's non-removable or a gpio pin). > > > > > > That alone doesn't solve the wider problem, though, which I think = breaks > > > down into two pieces. Let's say you've got two slots, call them = left > > > and right. You end up with these two problems... > > > > > > * Sometimes the right slot is mmcsd0, but it turns into = mmcsd1 if > > > there's a card in the left slot when I boot; I don't want = it to > > > change. > > > > > > And not just a boot-time issue, of course. If you were to remove = those two cards and then reinsert them in the opposite time-order, their = device names would swap. > > > > > > * I want the slot on the left to be named '1' and the right = to be > > > '0'. > > > > > > The first problem is easily solved without impacting dts in any = way. We > > > just wire down the relationship controllerN -> mmcN -> mmcsdN. = This is > > > exactly equivelent to the old ATA_STATIC_ID option in its effect = -- you > > > don't get to choose the names, but you know they won't change = based on > > > which devices are present. It could be controlled with a tunable. > > > > > > It's harder to envision the fix for the second part without adding = an > > > ad-hoc property for the devices. Even with a property I'm not = sure how > > > easy it would be. > > > > > > We should be able to assign a geographic address = (controllerX:slotY) to each mmcsd device in a given system (let's ignore = for now the theoretical possibility of multiple cards on one bus). The = 'controllerX' part of the address could be the controller's pathname = from the devicetree, or an index assigned by mmcbr machinery at attach = time. The "slotY" part of the address is assigned by the specific = controller device driver using some internally-determined fixed mapping = between the assigned values and its physical slots. This geographic = address could be used to create an additional set of /dev entries with = stable names. There could be a mechanism for user-configurable aliases = for the geographical addresses. > > > > There=92s already a chance to run a script when a device is attached = that can create /dev/slot0 or /dev/slot1 that has geographical = information available to it. People use ddvd for this in the USB world = all the time to make sure that tty devices get a symlink based on their = location or serial number. > > > > Why is mmc so different it needs its own mechanism? > > > > I'm laying out my view of the information that would be needed and = the types of actions that would have to be taken based on that = information to solve the issue. I'm not saying devd can't be the piece = that is used to implement the actions (indeed, I noted devd as a = potential building block for a solution in my initial response). I'm = also not saying mmc needs its own mechanism, I'm saying it needs /a/ = mechanism, and so far there still seems to be something missing (because = it's not there, or I'm still ignorant of it). > > > > What seems to be missing is geographical addressing for mmc devices. > > > > I think what you might be saying is that the existing mmcsd = add/remove code could be augmented to send devctl notifications, along = the lines of: > > > > devctl_notify("MMC", "DEVICE", "ATTACH"|"DETACH", "... = controller=3D = slot=3D rca=3D") > > > > and then I and the fine author of devctl and devd would be pleased. >=20 > MMC doesn=92t need anything special here. That=92s already present. = Looking at the device tree we see on one of the platforms that=92s handy = for me to access: >=20 > at91_mci0 > mmc0 > mmcsd0 at rca=3D0xb368 >=20 > So you know that mmcsd0 is on mmc0 bus attached to at91_mci0, which is = ultimately the FDT node where things came from. There=92s not a = user-defined slot associated with this (and we should have a SLOT A vs = SLOT B as a location info for this platform, because we can have two = cards on the one bus in the MMC case), true, but for your use case I = don=92t think that you need it. We should be attaching the host = controller regardless of whether the or not there=92s a card in there, = so it will be fixed. While some additional information would be useful = to publish, I don=92t think your use case requires it=85 >=20 >=20 > The reason you need something extra here is that what is there now = breaks down whenever you don't have a one-to-one mapping between = controllers and buses. Any controller with more than one slot can yield = something of the form: >=20 > sdhci0 > mmc0 > mmcsd0 at rca=3D0xabcd > mmc1 > mmcsd1 at rca=3D0x1234 >=20 > and you have no idea what physical slot in the system mmcsd0 and = mmcsd1 are in. The driver isn=92t going to be able to help you, because it reports mmc0 = based on the data it gets from slot 0 status registers, and mmc1 based = on slot 1 status registers. Since there=92s no notion of how that maps = to physical hardware, the driver can=92t do anything automatically. And = since mmc on down is populated by FreeSBD, there=92s no hints in the FDT = tree for them. > For my immediate use case, sure, I can rely on the one-to-one = relationship between controllers and buses. At this point, though, = rather than skate by on that happy coincidence, I'd rather invest what = now seems to be a rather small amount of effort adding mmcsd devctl = notifications that would cover the multiple-slots-per-controller case as = well, and then build the rest of what I want on top of that information = coming out of ddvd. Trouble is, how do we know what to send with this new notification. = That=92s the part I=92m having trouble with. Where does that data come = from? And how is it different than what=92s in the device tree? > On the at91 platform cited above, that allows you to connect two MMC = cards to the same bus (i.e., multidrop configuration), is there any way = to distinguish which card is in which physical slot? I'm still under = the impression that this is the one case where we aren't going to be = able to determine the physical location of every mmcsd device. Actually, there=92s two different configurations, I believe. One that = supports two SD cards (SLOT A / SLOT B) and one that supports MMC multi = drop. The former has been tested at least once, while the latter I don=92t= think had ever been checked. Warner= From owner-freebsd-embedded@FreeBSD.ORG Thu Mar 6 00:53:14 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0C23811; Thu, 6 Mar 2014 00:53:13 +0000 (UTC) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CE6FF64B; Thu, 6 Mar 2014 00:53:12 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id w7so1276322lbi.30 for ; Wed, 05 Mar 2014 16:53:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=q/enwDvvL6xYQB36OxlVhzTMsF1J81oWV/NRWNPFDd8=; b=WoedIAuoQiwKgK4JubQ6fNYUJeAbgeYcXeu5dMPUcyGnNlY1j23DbC+WUGxKohUGVI cQLtTOd9lnKGcEZebx4VNFDgueheWPRTZlMrJAF+Cq9JVjROObscTVhwVCCFzuhFRxL1 oxX1Q0KoJkLlg1rIbPc+HbhTxCysohUAIL6YOaeCvkznDQ3b9akurAyWBRaeH9IE8UKR bilvw87e1PQVvykeOQImRYIINB99uBqhESHscDQpZzFSj9BTYUGe+xKMxJb/7GSSRZ3z xb6Fszw4rG81mjxVsTFBWnz9+wo0Ca9UGnQMJYN7g2RE7j1QRz0oGJiCvz/xmLVXILpH 1J1A== MIME-Version: 1.0 X-Received: by 10.152.234.130 with SMTP id ue2mr5781303lac.0.1394067190985; Wed, 05 Mar 2014 16:53:10 -0800 (PST) Sender: pkelsey@gmail.com Received: by 10.112.142.5 with HTTP; Wed, 5 Mar 2014 16:53:10 -0800 (PST) In-Reply-To: <39ED4040-2A6A-4D85-97D5-DCDE4ECCA0EC@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> <16A5203B-B06D-4129-A54F-F34D5FA28D2B@bsdimp.com> <39ED4040-2A6A-4D85-97D5-DCDE4ECCA0EC@bsdimp.com> Date: Wed, 5 Mar 2014 19:53:10 -0500 X-Google-Sender-Auth: 8ktgL6o7K4ty-hbimS3WPZBpxlU Message-ID: Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Patrick Kelsey To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" , freebsd-arm , freebsd-embedded@freebsd.org, Ian Lepore X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 00:53:14 -0000 On Wed, Mar 5, 2014 at 5:44 PM, Warner Losh wrote: > > On Mar 5, 2014, at 2:56 PM, Patrick Kelsey wrote: > > > > > > > > > On Wed, Mar 5, 2014 at 4:24 PM, Warner Losh wrote: > > > > On Mar 5, 2014, at 11:55 AM, Patrick Kelsey wrote: > > > > > > > > > > > > > > On Wed, Mar 5, 2014 at 8:31 AM, Warner Losh wrote: > > > > > > On Mar 4, 2014, at 11:53 PM, Patrick Kelsey wrote: > > > > > > > > > > > > > > > > > > > On Tue, Mar 4, 2014 at 8:21 AM, Ian Lepore wrote: > > > > > > > > There's a standard property for mmc/sd devices, "non-removable" whose > > > > presence denotes things like soldered-on eMMC parts. Only one of our > > > > many sdhci drivers supports it right now (imx). In general the core > > > > part of the driver (dev/sdhci) doesn't have good support for > > > > insert/remove/presence detection that's handled off to the side > (whether > > > > it's non-removable or a gpio pin). > > > > > > > > That alone doesn't solve the wider problem, though, which I think > breaks > > > > down into two pieces. Let's say you've got two slots, call them left > > > > and right. You end up with these two problems... > > > > > > > > * Sometimes the right slot is mmcsd0, but it turns into mmcsd1 > if > > > > there's a card in the left slot when I boot; I don't want it > to > > > > change. > > > > > > > > And not just a boot-time issue, of course. If you were to remove > those two cards and then reinsert them in the opposite time-order, their > device names would swap. > > > > > > > > * I want the slot on the left to be named '1' and the right to > be > > > > '0'. > > > > > > > > The first problem is easily solved without impacting dts in any way. > We > > > > just wire down the relationship controllerN -> mmcN -> mmcsdN. This > is > > > > exactly equivelent to the old ATA_STATIC_ID option in its effect -- > you > > > > don't get to choose the names, but you know they won't change based > on > > > > which devices are present. It could be controlled with a tunable. > > > > > > > > It's harder to envision the fix for the second part without adding an > > > > ad-hoc property for the devices. Even with a property I'm not sure > how > > > > easy it would be. > > > > > > > > We should be able to assign a geographic address (controllerX:slotY) > to each mmcsd device in a given system (let's ignore for now the > theoretical possibility of multiple cards on one bus). The 'controllerX' > part of the address could be the controller's pathname from the devicetree, > or an index assigned by mmcbr machinery at attach time. The "slotY" part > of the address is assigned by the specific controller device driver using > some internally-determined fixed mapping between the assigned values and > its physical slots. This geographic address could be used to create an > additional set of /dev entries with stable names. There could be a > mechanism for user-configurable aliases for the geographical addresses. > > > > > > There's already a chance to run a script when a device is attached > that can create /dev/slot0 or /dev/slot1 that has geographical information > available to it. People use ddvd for this in the USB world all the time to > make sure that tty devices get a symlink based on their location or serial > number. > > > > > > Why is mmc so different it needs its own mechanism? > > > > > > I'm laying out my view of the information that would be needed and the > types of actions that would have to be taken based on that information to > solve the issue. I'm not saying devd can't be the piece that is used to > implement the actions (indeed, I noted devd as a potential building block > for a solution in my initial response). I'm also not saying mmc needs its > own mechanism, I'm saying it needs /a/ mechanism, and so far there still > seems to be something missing (because it's not there, or I'm still > ignorant of it). > > > > > > What seems to be missing is geographical addressing for mmc devices. > > > > > > I think what you might be saying is that the existing mmcsd add/remove > code could be augmented to send devctl notifications, along the lines of: > > > > > > devctl_notify("MMC", "DEVICE", "ATTACH"|"DETACH", "... > controller= > slot= rca=") > > > > > > and then I and the fine author of devctl and devd would be pleased. > > > > MMC doesn't need anything special here. That's already present. Looking > at the device tree we see on one of the platforms that's handy for me to > access: > > > > at91_mci0 > > mmc0 > > mmcsd0 at rca=0xb368 > > > > So you know that mmcsd0 is on mmc0 bus attached to at91_mci0, which is > ultimately the FDT node where things came from. There's not a user-defined > slot associated with this (and we should have a SLOT A vs SLOT B as a > location info for this platform, because we can have two cards on the one > bus in the MMC case), true, but for your use case I don't think that you > need it. We should be attaching the host controller regardless of whether > the or not there's a card in there, so it will be fixed. While some > additional information would be useful to publish, I don't think your use > case requires it... > > > > > > The reason you need something extra here is that what is there now > breaks down whenever you don't have a one-to-one mapping between > controllers and buses. Any controller with more than one slot can yield > something of the form: > > > > sdhci0 > > mmc0 > > mmcsd0 at rca=0xabcd > > mmc1 > > mmcsd1 at rca=0x1234 > > > > and you have no idea what physical slot in the system mmcsd0 and mmcsd1 > are in. > > The driver isn't going to be able to help you, because it reports mmc0 > based on the data it gets from slot 0 status registers, and mmc1 based on > slot 1 status registers. Since there's no notion of how that maps to > physical hardware, the driver can't do anything automatically. And since > mmc on down is populated by FreeSBD, there's no hints in the FDT tree for > them. > > > For my immediate use case, sure, I can rely on the one-to-one > relationship between controllers and buses. At this point, though, rather > than skate by on that happy coincidence, I'd rather invest what now seems > to be a rather small amount of effort adding mmcsd devctl notifications > that would cover the multiple-slots-per-controller case as well, and then > build the rest of what I want on top of that information coming out of ddvd. > > Trouble is, how do we know what to send with this new notification. That's > the part I'm having trouble with. Where does that data come from? And how > is it different than what's in the device tree? > > Each controller driver maintains an instance of struct mmc_host for each physical bus interface (typically referred to as a 'slot' in the drivers) it has. When a card is detected in a given slot by the driver, the driver creates an mmc bus instance and attaches the struct mmc_host corresponding to that slot to provide the ivar values. So let's say struct mmc_host gets a new member 'slot_number', and a new ivar MMC_IVAR_SLOT_NUMBER is defined. The slot number in each instance of struct mmc_host a driver maintains gets set to a controller-relative index of the corresponding physical interface - the controller will do this the same way every time, because it is tied to the register layout of the controller. After the mmc bus instance is created and its ivars are set, probe-and-attach is run on that bus, and an mmcsd device instance is created for each card that is found. At the point where the mmcsd device instance is created, one knows the parent bus for that new mmcsd device, and thus one can get the value of MMC_IVAR_SLOT_NUMBER for that bus, as well as the name of the controller device instance that is the parent of the parent bus. It thus possible at that point to devctl_notify("MMC", "DEVICE", "ATTACH", "... controller= slot= ") Because the controller attachment order is the same on every boot, as is the slot number ivar for a given bus interface on each controller hardware instance, an identical attach message will be generated every time a card is discovered in that physical location in the system. For a given system, there will thus be a fixed mapping between {controller_instance,slot} tuples that appear in these messages and the physical MMC/SD device locations. In the above, I've left out the value of rca from the discussion because upon further reflection, it cannot be stably tied to a physical location. If there is a multidrop MMC bus in a system, the physical card locations on that bus will not be able to be referred to with stable names. This is the one area where a new property in the FDT could be useful to convey multidrop-or-not for each bus interface on a controller. The new property could be 'freebsd,max-devices' and would be an array of cells that indicates the maximum number of MMC/SD devices that can be connected to the controller bus interface corresponding to that cell index. The devctl notification could then include a multidrop indicator in the message. > > On the at91 platform cited above, that allows you to connect two MMC > cards to the same bus (i.e., multidrop configuration), is there any way to > distinguish which card is in which physical slot? I'm still under the > impression that this is the one case where we aren't going to be able to > determine the physical location of every mmcsd device. > > Actually, there's two different configurations, I believe. One that > supports two SD cards (SLOT A / SLOT B) and one that supports MMC multi > drop. The former has been tested at least once, while the latter I don't > think had ever been checked. > I think MMC multidrop will remain a limitation, and perhaps an insignificant one (does *anyone* know of a current system that does this?). -Patrick From owner-freebsd-embedded@FreeBSD.ORG Thu Mar 6 01:03:08 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB2E4A62 for ; Thu, 6 Mar 2014 01:03:08 +0000 (UTC) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7877B765 for ; Thu, 6 Mar 2014 01:03:08 +0000 (UTC) Received: by mail-pb0-f44.google.com with SMTP id rp16so1856177pbb.3 for ; Wed, 05 Mar 2014 17:03:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=7sbU++ktENm+Fyc+1OZHbIBRsCavaa50VhRDyZ7/RLY=; b=NjIhOqsBrAY5VhIWvN3t5GG835QJS6zRrZJyWgVSpy5/ELVUHwV25qcC9rX8TyQuW+ npnR4ppK+MClAXWqsHrbK5bPKsSG+vTRsasvfm+uD8LNyigrh2PCXDpDNKscPYAiEtC5 6sZHgUEwGgAR4FaF1lIzECffSusgCMD5ucyIMcOi26NDaGENMS8hUXZ7lBgG4/q0JmXM s1ZHP8PXMndnPY5o1bPDzm02F/tiLnjziV6iLDo0MwMX34CCd7QD8Sgoqc1yvX+MmiIO 0W6ZINLNAO5fuGxOynxrzWsW1hcKWFFrOrM7IkuB5IIJPTKNqa3stI/QlQOJyQDdCqy9 zx6A== X-Gm-Message-State: ALoCoQnY2cq4qsf7G9hYKlx5xuUQ3r6ABUV8qCB7PlmrW5+1XV6p5o5VQiZlEMEjYA7iGRBbTczy X-Received: by 10.68.245.162 with SMTP id xp2mr10768179pbc.69.1394067782329; Wed, 05 Mar 2014 17:03:02 -0800 (PST) Received: from lglt-rottaway.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id sm5sm24991394pab.19.2014.03.05.17.03.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 17:03:01 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Warner Losh In-Reply-To: Date: Wed, 5 Mar 2014 18:02:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <899B9ABD-0ACC-49F2-9520-CCE837D39875@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> <16A5203B-B06D-4129-A54F-F34D5FA28D2B@bsdimp.com> <39ED4040-2A6A-4D85-97D5-DCDE4ECCA0EC@bsdimp.com> To: Patrick Kelsey X-Mailer: Apple Mail (2.1874) Cc: "freebsd-hackers@freebsd.org" , freebsd-arm , freebsd-embedded@freebsd.org, Ian Lepore X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 01:03:09 -0000 On Mar 5, 2014, at 5:53 PM, Patrick Kelsey wrote: >=20 >=20 >=20 > On Wed, Mar 5, 2014 at 5:44 PM, Warner Losh wrote: >=20 > On Mar 5, 2014, at 2:56 PM, Patrick Kelsey wrote: >=20 > > > > > > > > On Wed, Mar 5, 2014 at 4:24 PM, Warner Losh wrote: > > > > On Mar 5, 2014, at 11:55 AM, Patrick Kelsey wrote: > > > > > > > > > > > > > > On Wed, Mar 5, 2014 at 8:31 AM, Warner Losh = wrote: > > > > > > On Mar 4, 2014, at 11:53 PM, Patrick Kelsey = wrote: > > > > > > > > > > > > > > > > > > > On Tue, Mar 4, 2014 at 8:21 AM, Ian Lepore = wrote: > > > > > > > > There's a standard property for mmc/sd devices, "non-removable" = whose > > > > presence denotes things like soldered-on eMMC parts. Only one = of our > > > > many sdhci drivers supports it right now (imx). In general the = core > > > > part of the driver (dev/sdhci) doesn't have good support for > > > > insert/remove/presence detection that's handled off to the side = (whether > > > > it's non-removable or a gpio pin). > > > > > > > > That alone doesn't solve the wider problem, though, which I = think breaks > > > > down into two pieces. Let's say you've got two slots, call them = left > > > > and right. You end up with these two problems... > > > > > > > > * Sometimes the right slot is mmcsd0, but it turns into = mmcsd1 if > > > > there's a card in the left slot when I boot; I don't = want it to > > > > change. > > > > > > > > And not just a boot-time issue, of course. If you were to = remove those two cards and then reinsert them in the opposite = time-order, their device names would swap. > > > > > > > > * I want the slot on the left to be named '1' and the = right to be > > > > '0'. > > > > > > > > The first problem is easily solved without impacting dts in any = way. We > > > > just wire down the relationship controllerN -> mmcN -> mmcsdN. = This is > > > > exactly equivelent to the old ATA_STATIC_ID option in its effect = -- you > > > > don't get to choose the names, but you know they won't change = based on > > > > which devices are present. It could be controlled with a = tunable. > > > > > > > > It's harder to envision the fix for the second part without = adding an > > > > ad-hoc property for the devices. Even with a property I'm not = sure how > > > > easy it would be. > > > > > > > > We should be able to assign a geographic address = (controllerX:slotY) to each mmcsd device in a given system (let's ignore = for now the theoretical possibility of multiple cards on one bus). The = 'controllerX' part of the address could be the controller's pathname = from the devicetree, or an index assigned by mmcbr machinery at attach = time. The "slotY" part of the address is assigned by the specific = controller device driver using some internally-determined fixed mapping = between the assigned values and its physical slots. This geographic = address could be used to create an additional set of /dev entries with = stable names. There could be a mechanism for user-configurable aliases = for the geographical addresses. > > > > > > There=92s already a chance to run a script when a device is = attached that can create /dev/slot0 or /dev/slot1 that has geographical = information available to it. People use ddvd for this in the USB world = all the time to make sure that tty devices get a symlink based on their = location or serial number. > > > > > > Why is mmc so different it needs its own mechanism? > > > > > > I'm laying out my view of the information that would be needed and = the types of actions that would have to be taken based on that = information to solve the issue. I'm not saying devd can't be the piece = that is used to implement the actions (indeed, I noted devd as a = potential building block for a solution in my initial response). I'm = also not saying mmc needs its own mechanism, I'm saying it needs /a/ = mechanism, and so far there still seems to be something missing (because = it's not there, or I'm still ignorant of it). > > > > > > What seems to be missing is geographical addressing for mmc = devices. > > > > > > I think what you might be saying is that the existing mmcsd = add/remove code could be augmented to send devctl notifications, along = the lines of: > > > > > > devctl_notify("MMC", "DEVICE", "ATTACH"|"DETACH", "... = controller=3D = slot=3D rca=3D") > > > > > > and then I and the fine author of devctl and devd would be = pleased. > > > > MMC doesn=92t need anything special here. That=92s already present. = Looking at the device tree we see on one of the platforms that=92s handy = for me to access: > > > > at91_mci0 > > mmc0 > > mmcsd0 at rca=3D0xb368 > > > > So you know that mmcsd0 is on mmc0 bus attached to at91_mci0, which = is ultimately the FDT node where things came from. There=92s not a = user-defined slot associated with this (and we should have a SLOT A vs = SLOT B as a location info for this platform, because we can have two = cards on the one bus in the MMC case), true, but for your use case I = don=92t think that you need it. We should be attaching the host = controller regardless of whether the or not there=92s a card in there, = so it will be fixed. While some additional information would be useful = to publish, I don=92t think your use case requires it=85 > > > > > > The reason you need something extra here is that what is there now = breaks down whenever you don't have a one-to-one mapping between = controllers and buses. Any controller with more than one slot can yield = something of the form: > > > > sdhci0 > > mmc0 > > mmcsd0 at rca=3D0xabcd > > mmc1 > > mmcsd1 at rca=3D0x1234 > > > > and you have no idea what physical slot in the system mmcsd0 and = mmcsd1 are in. >=20 > The driver isn=92t going to be able to help you, because it reports = mmc0 based on the data it gets from slot 0 status registers, and mmc1 = based on slot 1 status registers. Since there=92s no notion of how that = maps to physical hardware, the driver can=92t do anything automatically. = And since mmc on down is populated by FreeSBD, there=92s no hints in the = FDT tree for them. >=20 >=20 > > For my immediate use case, sure, I can rely on the one-to-one = relationship between controllers and buses. At this point, though, = rather than skate by on that happy coincidence, I'd rather invest what = now seems to be a rather small amount of effort adding mmcsd devctl = notifications that would cover the multiple-slots-per-controller case as = well, and then build the rest of what I want on top of that information = coming out of ddvd. >=20 > Trouble is, how do we know what to send with this new notification. = That=92s the part I=92m having trouble with. Where does that data come = from? And how is it different than what=92s in the device tree? >=20 >=20 > Each controller driver maintains an instance of struct mmc_host for = each physical bus interface (typically referred to as a 'slot' in the = drivers) it has. When a card is detected in a given slot by the driver, = the driver creates an mmc bus instance and attaches the struct mmc_host = corresponding to that slot to provide the ivar values. So let's say = struct mmc_host gets a new member 'slot_number', and a new ivar = MMC_IVAR_SLOT_NUMBER is defined. The slot number in each instance of = struct mmc_host a driver maintains gets set to a controller-relative = index of the corresponding physical interface - the controller will do = this the same way every time, because it is tied to the register layout = of the controller. >=20 > After the mmc bus instance is created and its ivars are set, = probe-and-attach is run on that bus, and an mmcsd device instance is = created for each card that is found. At the point where the mmcsd = device instance is created, one knows the parent bus for that new mmcsd = device, and thus one can get the value of MMC_IVAR_SLOT_NUMBER for that = bus, as well as the name of the controller device instance that is the = parent of the parent bus. It thus possible at that point to=20 >=20 > devctl_notify("MMC", "DEVICE", "ATTACH", "... = controller=3D = slot=3D ") >=20 > Because the controller attachment order is the same on every boot, as = is the slot number ivar for a given bus interface on each controller = hardware instance, an identical attach message will be generated every = time a card is discovered in that physical location in the system. For = a given system, there will thus be a fixed mapping between = {controller_instance,slot} tuples that appear in these messages and the = physical MMC/SD device locations. I=92m curious how that=92s materially different than the parent=92s mmc = instance number. That too is invariant between boots. There=92s a 1:1 - = onto mapping between this instance number and any controller/slot tuple = that would be created. Also, there doesn=92t need to be a special MMC message for this. If we = do create the notion of a slot number per controller, that would be part = of the location information that is in the location string for the = normal attach message. > In the above, I've left out the value of rca from the discussion = because upon further reflection, it cannot be stably tied to a physical = location. If there is a multidrop MMC bus in a system, the physical = card locations on that bus will not be able to be referred to with = stable names. This is the one area where a new property in the FDT = could be useful to convey multidrop-or-not for each bus interface on a = controller. The new property could be 'freebsd,max-devices' and would = be an array of cells that indicates the maximum number of MMC/SD devices = that can be connected to the controller bus interface corresponding to = that cell index. The devctl notification could then include a multidrop = indicator in the message. rca is more of a serial number than a location number. Useful for other = reasons. I=92m not sure how =91freebsd,max-devices=92 would solve the problem. = The controller already knows that. If we really want to tie things to a = physical location/ description, I=92d opt for something more like = =91freebsd,slot-names =3D =93Slot 0=94, =93Slot 1=94;=92 type of thing, = where you could just as easily have =93Top Card=94 =93bottom card=94 or = =93boot card=94 and =93customer card=94 if you wanted. Then the = controller could query this property to get the names to populate = somewhere in the PNP info for this device. The mmcsd driver would then = be free to also create a /dev/Blah alias as well for the disk, but I = don=92t know if that would cause aliases to get created for all the geom = children or not... > > On the at91 platform cited above, that allows you to connect two MMC = cards to the same bus (i.e., multidrop configuration), is there any way = to distinguish which card is in which physical slot? I'm still under = the impression that this is the one case where we aren't going to be = able to determine the physical location of every mmcsd device. >=20 > Actually, there=92s two different configurations, I believe. One that = supports two SD cards (SLOT A / SLOT B) and one that supports MMC multi = drop. The former has been tested at least once, while the latter I don=92t= think had ever been checked. >=20 > I think MMC multidrop will remain a limitation, and perhaps an = insignificant one (does *anyone* know of a current system that does = this?). I=92ve never heard of anybody trying this and having it fail in the past = 8 or so years since I wrote the SD/MMC stack. At the time I wrote it, it = was already ancient history=85 Warner= From owner-freebsd-embedded@FreeBSD.ORG Thu Mar 6 02:48:57 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7EB012FB; Thu, 6 Mar 2014 02:48:57 +0000 (UTC) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EF25BF1C; Thu, 6 Mar 2014 02:48:56 +0000 (UTC) Received: by mail-qc0-f180.google.com with SMTP id x3so2241400qcv.39 for ; Wed, 05 Mar 2014 18:48:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=4/A2H+UPg0fQbuHEF8sPKkJWLna4IZhWjRoy7VgDBCU=; b=bYRNRKA/9GTei0KzMEPLQ3YaPsthw6IjYFdaB9SoDXYcBixyEl9o+b3CTmP+nom8ED 0nbpjZkjIl3HLpgy07jm8Iqxc3Il+penhh6YuC/dNCFa7t4qe0ehro4qLuQFvmYYltr5 y2cyPstCJFws3fIYtW2zcbAabPiHeRFXleKpwnBhfIZpF3eWJYJnY748RgwWq7ehXf/V xrTQKKLjwIsN98SaRsZMdjom8iPtO0Vjk3AF6E+dvxRwApvGpSWSOzqySbLdnHQucLvF H6vdcGK2mzyoyOyVR+wefiPDm/+dIq5kV9wPiGEh68Lj4XLdMNV2cURwQs/vNTOGYbqG XUvg== X-Received: by 10.140.40.5 with SMTP id w5mr10374914qgw.65.1394074136077; Wed, 05 Mar 2014 18:48:56 -0800 (PST) Received: from [172.16.0.124] (c-174-54-20-106.hsd1.pa.comcast.net. [174.54.20.106]) by mx.google.com with ESMTPSA id v12sm14100254qav.23.2014.03.05.18.48.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 18:48:54 -0800 (PST) Sender: Patrick Kelsey References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> <16A5203B-B06D-4129-A54F-F34D5FA28D2B@bsdimp.com> <39ED4040-2A6A-4D85-97D5-DCDE4ECCA0EC@bsdimp.com> <899B9ABD-0ACC-49F2-9520-CCE837D39875@bsdimp.com> Mime-Version: 1.0 (1.0) In-Reply-To: <899B9ABD-0ACC-49F2-9520-CCE837D39875@bsdimp.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <9CEFA586-0319-4390-AC9A-B54EE77AD735@ieee.org> X-Mailer: iPhone Mail (10B329) From: Patrick Kelsey Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) Date: Wed, 5 Mar 2014 21:48:50 -0500 To: Warner Losh Cc: "freebsd-hackers@freebsd.org" , freebsd-arm , "freebsd-embedded@freebsd.org" , Ian Lepore X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 02:48:57 -0000 On Mar 5, 2014, at 8:02 PM, Warner Losh wrote: >=20 > On Mar 5, 2014, at 5:53 PM, Patrick Kelsey wrote: >=20 >>=20 >>=20 >>=20 >> On Wed, Mar 5, 2014 at 5:44 PM, Warner Losh wrote: >>=20 >> On Mar 5, 2014, at 2:56 PM, Patrick Kelsey wrote: >>=20 >>>=20 >>>=20 >>>=20 >>> On Wed, Mar 5, 2014 at 4:24 PM, Warner Losh wrote: >>>=20 >>> On Mar 5, 2014, at 11:55 AM, Patrick Kelsey wrote: >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Wed, Mar 5, 2014 at 8:31 AM, Warner Losh wrote: >>>>=20 >>>> On Mar 4, 2014, at 11:53 PM, Patrick Kelsey wrote: >>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Tue, Mar 4, 2014 at 8:21 AM, Ian Lepore wrote: >>>>>=20 >>>>> There's a standard property for mmc/sd devices, "non-removable" whose >>>>> presence denotes things like soldered-on eMMC parts. Only one of our >>>>> many sdhci drivers supports it right now (imx). In general the core >>>>> part of the driver (dev/sdhci) doesn't have good support for >>>>> insert/remove/presence detection that's handled off to the side (wheth= er >>>>> it's non-removable or a gpio pin). >>>>>=20 >>>>> That alone doesn't solve the wider problem, though, which I think brea= ks >>>>> down into two pieces. Let's say you've got two slots, call them left >>>>> and right. You end up with these two problems... >>>>>=20 >>>>> * Sometimes the right slot is mmcsd0, but it turns into mmcsd1 if= >>>>> there's a card in the left slot when I boot; I don't want it to= >>>>> change. >>>>>=20 >>>>> And not just a boot-time issue, of course. If you were to remove thos= e two cards and then reinsert them in the opposite time-order, their device n= ames would swap. >>>>>=20 >>>>> * I want the slot on the left to be named '1' and the right to be= >>>>> '0'. >>>>>=20 >>>>> The first problem is easily solved without impacting dts in any way. W= e >>>>> just wire down the relationship controllerN -> mmcN -> mmcsdN. This i= s >>>>> exactly equivelent to the old ATA_STATIC_ID option in its effect -- yo= u >>>>> don't get to choose the names, but you know they won't change based on= >>>>> which devices are present. It could be controlled with a tunable. >>>>>=20 >>>>> It's harder to envision the fix for the second part without adding an >>>>> ad-hoc property for the devices. Even with a property I'm not sure ho= w >>>>> easy it would be. >>>>>=20 >>>>> We should be able to assign a geographic address (controllerX:slotY) t= o each mmcsd device in a given system (let's ignore for now the theoretical p= ossibility of multiple cards on one bus). The 'controllerX' part of the add= ress could be the controller's pathname from the devicetree, or an index ass= igned by mmcbr machinery at attach time. The "slotY" part of the address is= assigned by the specific controller device driver using some internally-det= ermined fixed mapping between the assigned values and its physical slots. T= his geographic address could be used to create an additional set of /dev ent= ries with stable names. There could be a mechanism for user-configurable al= iases for the geographical addresses. >>>>=20 >>>> There=E2=80=99s already a chance to run a script when a device is attac= hed that can create /dev/slot0 or /dev/slot1 that has geographical informati= on available to it. People use ddvd for this in the USB world all the time t= o make sure that tty devices get a symlink based on their location or serial= number. >>>>=20 >>>> Why is mmc so different it needs its own mechanism? >>>>=20 >>>> I'm laying out my view of the information that would be needed and the t= ypes of actions that would have to be taken based on that information to sol= ve the issue. I'm not saying devd can't be the piece that is used to implem= ent the actions (indeed, I noted devd as a potential building block for a so= lution in my initial response). I'm also not saying mmc needs its own mecha= nism, I'm saying it needs /a/ mechanism, and so far there still seems to be s= omething missing (because it's not there, or I'm still ignorant of it). >>>>=20 >>>> What seems to be missing is geographical addressing for mmc devices. >>>>=20 >>>> I think what you might be saying is that the existing mmcsd add/remove c= ode could be augmented to send devctl notifications, along the lines of: >>>>=20 >>>> devctl_notify("MMC", "DEVICE", "ATTACH"|"DETACH", "... controller=3D slot=3D rca= =3D") >>>>=20 >>>> and then I and the fine author of devctl and devd would be pleased. >>>=20 >>> MMC doesn=E2=80=99t need anything special here. That=E2=80=99s already p= resent. Looking at the device tree we see on one of the platforms that=E2=80= =99s handy for me to access: >>>=20 >>> at91_mci0 >>> mmc0 >>> mmcsd0 at rca=3D0xb368 >>>=20 >>> So you know that mmcsd0 is on mmc0 bus attached to at91_mci0, which is u= ltimately the FDT node where things came from. There=E2=80=99s not a user-de= fined slot associated with this (and we should have a SLOT A vs SLOT B as a l= ocation info for this platform, because we can have two cards on the one bus= in the MMC case), true, but for your use case I don=E2=80=99t think that yo= u need it. We should be attaching the host controller regardless of whether t= he or not there=E2=80=99s a card in there, so it will be fixed. While some a= dditional information would be useful to publish, I don=E2=80=99t think your= use case requires it=E2=80=A6 >>>=20 >>>=20 >>> The reason you need something extra here is that what is there now break= s down whenever you don't have a one-to-one mapping between controllers and b= uses. Any controller with more than one slot can yield something of the for= m: >>>=20 >>> sdhci0 >>> mmc0 >>> mmcsd0 at rca=3D0xabcd >>> mmc1 >>> mmcsd1 at rca=3D0x1234 >>>=20 >>> and you have no idea what physical slot in the system mmcsd0 and mmcsd1 a= re in. >>=20 >> The driver isn=E2=80=99t going to be able to help you, because it reports= mmc0 based on the data it gets from slot 0 status registers, and mmc1 based= on slot 1 status registers. Since there=E2=80=99s no notion of how that map= s to physical hardware, the driver can=E2=80=99t do anything automatically. A= nd since mmc on down is populated by FreeSBD, there=E2=80=99s no hints in th= e FDT tree for them. >>=20 >>=20 >>> For my immediate use case, sure, I can rely on the one-to-one relationsh= ip between controllers and buses. At this point, though, rather than skate b= y on that happy coincidence, I'd rather invest what now seems to be a rather= small amount of effort adding mmcsd devctl notifications that would cover t= he multiple-slots-per-controller case as well, and then build the rest of wh= at I want on top of that information coming out of ddvd. >>=20 >> Trouble is, how do we know what to send with this new notification. That=E2= =80=99s the part I=E2=80=99m having trouble with. Where does that data come f= rom? And how is it different than what=E2=80=99s in the device tree? >>=20 >>=20 >> Each controller driver maintains an instance of struct mmc_host for each p= hysical bus interface (typically referred to as a 'slot' in the drivers) it= has. When a card is detected in a given slot by the driver, the driver cre= ates an mmc bus instance and attaches the struct mmc_host corresponding to t= hat slot to provide the ivar values. So let's say struct mmc_host gets a ne= w member 'slot_number', and a new ivar MMC_IVAR_SLOT_NUMBER is defined. The= slot number in each instance of struct mmc_host a driver maintains gets set= to a controller-relative index of the corresponding physical interface - th= e controller will do this the same way every time, because it is tied to the= register layout of the controller. >>=20 >> After the mmc bus instance is created and its ivars are set, probe-and-at= tach is run on that bus, and an mmcsd device instance is created for each ca= rd that is found. At the point where the mmcsd device instance is created, o= ne knows the parent bus for that new mmcsd device, and thus one can get the v= alue of MMC_IVAR_SLOT_NUMBER for that bus, as well as the name of the contro= ller device instance that is the parent of the parent bus. It thus possible= at that point to=20 >>=20 >> devctl_notify("MMC", "DEVICE", "ATTACH", "... controller=3D slot=3D ") >>=20 >> Because the controller attachment order is the same on every boot, as is t= he slot number ivar for a given bus interface on each controller hardware in= stance, an identical attach message will be generated every time a card is d= iscovered in that physical location in the system. For a given system, ther= e will thus be a fixed mapping between {controller_instance,slot} tuples tha= t appear in these messages and the physical MMC/SD device locations. >=20 > I=E2=80=99m curious how that=E2=80=99s materially different than the paren= t=E2=80=99s mmc instance number. That too is invariant between boots. There=E2= =80=99s a 1:1 - onto mapping between this instance number and any controller= /slot tuple that would be created. >=20 Controller instance (unit) numbers are the same across boots. The mmc insta= nce (unit) number for the mmc instance created for a given bus interface on a= given controller is not, because the instance is created dynamically in res= ponse to card detection and thus depends on the ordering of card insertions.= Sure, there's a one-to-one and onto mapping at any given moment between mm= c instance numbers and the tuples I'm talking about, but the mapping is subj= ect to change with card insertions and removals. The material difference be= tween the two sets of labels is that a given tuple value will *always* refer= to the same physical device location in the system, whereas a given mmc uni= t number could refer to any physical device location in the system depending= on the time order of insertions in the various card slots. > Also, there doesn=E2=80=99t need to be a special MMC message for this. If w= e do create the notion of a slot number per controller, that would be part o= f the location information that is in the location string for the normal att= ach message Ah, so I can just append more variable definitions to the location string, w= hich is already fed through to the existing generic devctl notification? Wo= rks for me. >> In the above, I've left out the value of rca from the discussion because u= pon further reflection, it cannot be stably tied to a physical location. If= there is a multidrop MMC bus in a system, the physical card locations on th= at bus will not be able to be referred to with stable names. This is the on= e area where a new property in the FDT could be useful to convey multidrop-o= r-not for each bus interface on a controller. The new property could be 'fr= eebsd,max-devices' and would be an array of cells that indicates the maximum= number of MMC/SD devices that can be connected to the controller bus interf= ace corresponding to that cell index. The devctl notification could then in= clude a multidrop indicator in the message. >=20 > rca is more of a serial number than a location number. Useful for other re= asons. >=20 > I=E2=80=99m not sure how =E2=80=98freebsd,max-devices=E2=80=99 would solve= the problem. The controller already knows that. If we really want to tie th= ings to a physical location/ description, I=E2=80=99d opt for something more= like =E2=80=98freebsd,slot-names =3D =E2=80=9CSlot 0=E2=80=9D, =E2=80=9CSlo= t 1=E2=80=9D;=E2=80=99 type of thing, where you could just as easily have =E2= =80=9CTop Card=E2=80=9D =E2=80=9Cbottom card=E2=80=9D or =E2=80=9Cboot card=E2= =80=9D and =E2=80=9Ccustomer card=E2=80=9D if you wanted. Then the controlle= r could query this property to get the names to populate somewhere in the PN= P info for this device. The mmcsd driver would then be free to also create a= /dev/Blah alias as well for the disk, but I don=E2=80=99t know if that woul= d cause aliases to get created for all the geom children or not... >=20 freebsd,max-devices is not already known by the controller. The controller k= nows how many bus interfaces it has, but it doesn't know how many devices ca= n be attached to that bus, as that depends on the board design. freebsd,max= -devices informs us whether the board design is multidrop or not for each bu= s interface on each controller. Passing through a multidrop indication in t= he devctl notification informs the devctl consumer as to whether or not a un= ique stable name can be assigned to the mmcsd instance based on the tuple (i= f multidrop, then no). Not essential, but would be thorough. I disagree with 'freebsd,slot-names' because meaningful/descriptive slot nam= es are going to be something that are often defined at the product level, so= I think it's better to just let them be defined via a devd action script. O= therwise we build in an invitation to the experience of having board-level s= lot names and product-level slot names from the same namespace, which is in m= y experience awful. "Oh, wait, does this bug report refer to board-'top slo= t' or front-panel-'top slot'?" In other words, I think it's handy to have u= p until the board goes into an enclosure, then it could be trouble from then= on. Plus it could also encourage further knee-jerk, inappropriate .dts pat= ching of the sort I started out with here :) "Why make a devd script when I c= an just edit the names in the .dts file?" Agreed geom children are an open question. -Patrick= From owner-freebsd-embedded@FreeBSD.ORG Thu Mar 6 03:53:08 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 53A9FE24 for ; Thu, 6 Mar 2014 03:53:08 +0000 (UTC) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 18473771 for ; Thu, 6 Mar 2014 03:53:07 +0000 (UTC) Received: by mail-pd0-f173.google.com with SMTP id z10so1960320pdj.32 for ; Wed, 05 Mar 2014 19:53:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=tiIANlcRjuRuB95hHe5CQhbKfLDg1t4mKn9lwSaGQKU=; b=OACE/solOrOLS+hO6azJ1bZgwCjaBN6ca6Cx+9nJ2R3qd7HjUIOA7fIuS0E54JMUMi 2+Lmjx9eh7s6fv6aajblAdZzP+BRxxIS8NY1SmYUkPnL3Xe+1N6A4JHJawqOu/ID2uKj zfnI9nQ2O8v+WFL8dcINz5NeZF81dVn3L5L4sfQSc/QxC/IOJ+XeNNcDqydaOGQtAtwF TK2+uJ1zzYKfdv5gumnLOQtd0fJysG5YuYa7HduKwjEtdXVl/6BB1Tu1Kl/YbWP1BjWs O0NZWDOe1zvpmuQczdNZ5jRHEqBugPf5ZhlFBL0fsujRUWfxWXt5SNI5aOrNcNg1ZH54 s2Xw== X-Gm-Message-State: ALoCoQkJ/Gn42Z7QRRzqdCEvjyhv+m8Semr1J8HIFiY+21yhuqIWSr+XuQEUMa35JOPVly7HgwmQ X-Received: by 10.66.141.165 with SMTP id rp5mr11713909pab.90.1394077981033; Wed, 05 Mar 2014 19:53:01 -0800 (PST) Received: from lglt-rottaway.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id yo9sm27484830pab.16.2014.03.05.19.52.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 19:53:00 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Warner Losh In-Reply-To: <9CEFA586-0319-4390-AC9A-B54EE77AD735@ieee.org> Date: Wed, 5 Mar 2014 20:52:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7F5BD549-6A25-48F5-989A-F2D43C241CFF@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> <16A5203B-B06D-4129-A54F-F34D5FA28D2B@bsdimp.com> <39ED4040-2A6A-4D85-97D5-DCDE4ECCA0EC@bsdimp.com> <899B9ABD-0ACC-49F2-9520-CCE837D39875@bsdimp.com> <9CEFA586-0319-4390-AC9A-B54EE77AD735@ieee.org> To: Patrick Kelsey X-Mailer: Apple Mail (2.1874) Cc: "freebsd-hackers@freebsd.org" , freebsd-arm , "freebsd-embedded@freebsd.org" , Ian Lepore X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 03:53:08 -0000 On Mar 5, 2014, at 7:48 PM, Patrick Kelsey wrote: >=20 >=20 > On Mar 5, 2014, at 8:02 PM, Warner Losh wrote: >=20 >>=20 >> On Mar 5, 2014, at 5:53 PM, Patrick Kelsey wrote: >>=20 >>>=20 >>>=20 >>>=20 >>> On Wed, Mar 5, 2014 at 5:44 PM, Warner Losh wrote: >>>=20 >>> On Mar 5, 2014, at 2:56 PM, Patrick Kelsey wrote: >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Wed, Mar 5, 2014 at 4:24 PM, Warner Losh wrote: >>>>=20 >>>> On Mar 5, 2014, at 11:55 AM, Patrick Kelsey = wrote: >>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Wed, Mar 5, 2014 at 8:31 AM, Warner Losh = wrote: >>>>>=20 >>>>> On Mar 4, 2014, at 11:53 PM, Patrick Kelsey = wrote: >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Tue, Mar 4, 2014 at 8:21 AM, Ian Lepore = wrote: >>>>>>=20 >>>>>> There's a standard property for mmc/sd devices, "non-removable" = whose >>>>>> presence denotes things like soldered-on eMMC parts. Only one of = our >>>>>> many sdhci drivers supports it right now (imx). In general the = core >>>>>> part of the driver (dev/sdhci) doesn't have good support for >>>>>> insert/remove/presence detection that's handled off to the side = (whether >>>>>> it's non-removable or a gpio pin). >>>>>>=20 >>>>>> That alone doesn't solve the wider problem, though, which I think = breaks >>>>>> down into two pieces. Let's say you've got two slots, call them = left >>>>>> and right. You end up with these two problems... >>>>>>=20 >>>>>> * Sometimes the right slot is mmcsd0, but it turns into = mmcsd1 if >>>>>> there's a card in the left slot when I boot; I don't want = it to >>>>>> change. >>>>>>=20 >>>>>> And not just a boot-time issue, of course. If you were to remove = those two cards and then reinsert them in the opposite time-order, their = device names would swap. >>>>>>=20 >>>>>> * I want the slot on the left to be named '1' and the right = to be >>>>>> '0'. >>>>>>=20 >>>>>> The first problem is easily solved without impacting dts in any = way. We >>>>>> just wire down the relationship controllerN -> mmcN -> mmcsdN. = This is >>>>>> exactly equivelent to the old ATA_STATIC_ID option in its effect = -- you >>>>>> don't get to choose the names, but you know they won't change = based on >>>>>> which devices are present. It could be controlled with a = tunable. >>>>>>=20 >>>>>> It's harder to envision the fix for the second part without = adding an >>>>>> ad-hoc property for the devices. Even with a property I'm not = sure how >>>>>> easy it would be. >>>>>>=20 >>>>>> We should be able to assign a geographic address = (controllerX:slotY) to each mmcsd device in a given system (let's ignore = for now the theoretical possibility of multiple cards on one bus). The = 'controllerX' part of the address could be the controller's pathname = from the devicetree, or an index assigned by mmcbr machinery at attach = time. The "slotY" part of the address is assigned by the specific = controller device driver using some internally-determined fixed mapping = between the assigned values and its physical slots. This geographic = address could be used to create an additional set of /dev entries with = stable names. There could be a mechanism for user-configurable aliases = for the geographical addresses. >>>>>=20 >>>>> There=92s already a chance to run a script when a device is = attached that can create /dev/slot0 or /dev/slot1 that has geographical = information available to it. People use ddvd for this in the USB world = all the time to make sure that tty devices get a symlink based on their = location or serial number. >>>>>=20 >>>>> Why is mmc so different it needs its own mechanism? >>>>>=20 >>>>> I'm laying out my view of the information that would be needed and = the types of actions that would have to be taken based on that = information to solve the issue. I'm not saying devd can't be the piece = that is used to implement the actions (indeed, I noted devd as a = potential building block for a solution in my initial response). I'm = also not saying mmc needs its own mechanism, I'm saying it needs /a/ = mechanism, and so far there still seems to be something missing (because = it's not there, or I'm still ignorant of it). >>>>>=20 >>>>> What seems to be missing is geographical addressing for mmc = devices. >>>>>=20 >>>>> I think what you might be saying is that the existing mmcsd = add/remove code could be augmented to send devctl notifications, along = the lines of: >>>>>=20 >>>>> devctl_notify("MMC", "DEVICE", "ATTACH"|"DETACH", "... = controller=3D = slot=3D rca=3D") >>>>>=20 >>>>> and then I and the fine author of devctl and devd would be = pleased. >>>>=20 >>>> MMC doesn=92t need anything special here. That=92s already present. = Looking at the device tree we see on one of the platforms that=92s handy = for me to access: >>>>=20 >>>> at91_mci0 >>>> mmc0 >>>> mmcsd0 at rca=3D0xb368 >>>>=20 >>>> So you know that mmcsd0 is on mmc0 bus attached to at91_mci0, which = is ultimately the FDT node where things came from. There=92s not a = user-defined slot associated with this (and we should have a SLOT A vs = SLOT B as a location info for this platform, because we can have two = cards on the one bus in the MMC case), true, but for your use case I = don=92t think that you need it. We should be attaching the host = controller regardless of whether the or not there=92s a card in there, = so it will be fixed. While some additional information would be useful = to publish, I don=92t think your use case requires it=85 >>>>=20 >>>>=20 >>>> The reason you need something extra here is that what is there now = breaks down whenever you don't have a one-to-one mapping between = controllers and buses. Any controller with more than one slot can yield = something of the form: >>>>=20 >>>> sdhci0 >>>> mmc0 >>>> mmcsd0 at rca=3D0xabcd >>>> mmc1 >>>> mmcsd1 at rca=3D0x1234 >>>>=20 >>>> and you have no idea what physical slot in the system mmcsd0 and = mmcsd1 are in. >>>=20 >>> The driver isn=92t going to be able to help you, because it reports = mmc0 based on the data it gets from slot 0 status registers, and mmc1 = based on slot 1 status registers. Since there=92s no notion of how that = maps to physical hardware, the driver can=92t do anything automatically. = And since mmc on down is populated by FreeSBD, there=92s no hints in the = FDT tree for them. >>>=20 >>>=20 >>>> For my immediate use case, sure, I can rely on the one-to-one = relationship between controllers and buses. At this point, though, = rather than skate by on that happy coincidence, I'd rather invest what = now seems to be a rather small amount of effort adding mmcsd devctl = notifications that would cover the multiple-slots-per-controller case as = well, and then build the rest of what I want on top of that information = coming out of ddvd. >>>=20 >>> Trouble is, how do we know what to send with this new notification. = That=92s the part I=92m having trouble with. Where does that data come = from? And how is it different than what=92s in the device tree? >>>=20 >>>=20 >>> Each controller driver maintains an instance of struct mmc_host for = each physical bus interface (typically referred to as a 'slot' in the = drivers) it has. When a card is detected in a given slot by the driver, = the driver creates an mmc bus instance and attaches the struct mmc_host = corresponding to that slot to provide the ivar values. So let's say = struct mmc_host gets a new member 'slot_number', and a new ivar = MMC_IVAR_SLOT_NUMBER is defined. The slot number in each instance of = struct mmc_host a driver maintains gets set to a controller-relative = index of the corresponding physical interface - the controller will do = this the same way every time, because it is tied to the register layout = of the controller. >>>=20 >>> After the mmc bus instance is created and its ivars are set, = probe-and-attach is run on that bus, and an mmcsd device instance is = created for each card that is found. At the point where the mmcsd = device instance is created, one knows the parent bus for that new mmcsd = device, and thus one can get the value of MMC_IVAR_SLOT_NUMBER for that = bus, as well as the name of the controller device instance that is the = parent of the parent bus. It thus possible at that point to=20 >>>=20 >>> devctl_notify("MMC", "DEVICE", "ATTACH", "... = controller=3D = slot=3D ") >>>=20 >>> Because the controller attachment order is the same on every boot, = as is the slot number ivar for a given bus interface on each controller = hardware instance, an identical attach message will be generated every = time a card is discovered in that physical location in the system. For = a given system, there will thus be a fixed mapping between = {controller_instance,slot} tuples that appear in these messages and the = physical MMC/SD device locations. >>=20 >> I=92m curious how that=92s materially different than the parent=92s = mmc instance number. That too is invariant between boots. There=92s a = 1:1 - onto mapping between this instance number and any controller/slot = tuple that would be created. >>=20 >=20 > Controller instance (unit) numbers are the same across boots. The mmc = instance (unit) number for the mmc instance created for a given bus = interface on a given controller is not, because the instance is created = dynamically in response to card detection and thus depends on the = ordering of card insertions. That=92s the problem right there. The should always be the same from = boot to boot. sdhci must be doing things wrong. I=92ll have to take a = look. That=92s the real problem here. That=92s certainly how it is = supposed to be working. We always attach PCI busses to PCI bridges, = regardless of what=92s on the bus. mmc should be the same thing. I=92ll = work up some patches for that. > Sure, there's a one-to-one and onto mapping at any given moment = between mmc instance numbers and the tuples I'm talking about, but the = mapping is subject to change with card insertions and removals. The = material difference between the two sets of labels is that a given tuple = value will *always* refer to the same physical device location in the = system, whereas a given mmc unit number could refer to any physical = device location in the system depending on the time order of insertions = in the various card slots. I understand better now... >> Also, there doesn=92t need to be a special MMC message for this. If = we do create the notion of a slot number per controller, that would be = part of the location information that is in the location string for the = normal attach message >=20 > Ah, so I can just append more variable definitions to the location = string, which is already fed through to the existing generic devctl = notification? Works for me. Sure. >>> In the above, I've left out the value of rca from the discussion = because upon further reflection, it cannot be stably tied to a physical = location. If there is a multidrop MMC bus in a system, the physical card = locations on that bus will not be able to be referred to with stable = names. This is the one area where a new property in the FDT could be = useful to convey multidrop-or-not for each bus interface on a = controller. The new property could be 'freebsd,max-devices' and would = be an array of cells that indicates the maximum number of MMC/SD devices = that can be connected to the controller bus interface corresponding to = that cell index. The devctl notification could then include a multidrop = indicator in the message. >>=20 >> rca is more of a serial number than a location number. Useful for = other reasons. >>=20 >> I=92m not sure how =91freebsd,max-devices=92 would solve the problem. = The controller already knows that. If we really want to tie things to a = physical location/ description, I=92d opt for something more like = =91freebsd,slot-names =3D =93Slot 0=94, =93Slot 1=94;=92 type of thing, = where you could just as easily have =93Top Card=94 =93bottom card=94 or = =93boot card=94 and =93customer card=94 if you wanted. Then the = controller could query this property to get the names to populate = somewhere in the PNP info for this device. The mmcsd driver would then = be free to also create a /dev/Blah alias as well for the disk, but I = don=92t know if that would cause aliases to get created for all the geom = children or not... >>=20 >=20 > freebsd,max-devices is not already known by the controller. The = controller knows how many bus interfaces it has, but it doesn't know how = many devices can be attached to that bus, as that depends on the board = design. freebsd,max-devices informs us whether the board design is = multidrop or not for each bus interface on each controller. Passing = through a multidrop indication in the devctl notification informs the = devctl consumer as to whether or not a unique stable name can be = assigned to the mmcsd instance based on the tuple (if multidrop, then = no). Not essential, but would be thorough. Hmmm, this sure sounds like something that should already be in the FDT = file. I=92ll have to do a survey. > I disagree with 'freebsd,slot-names' because meaningful/descriptive = slot names are going to be something that are often defined at the = product level, so I think it's better to just let them be defined via a = devd action script. Otherwise we build in an invitation to the = experience of having board-level slot names and product-level slot names = from the same namespace, which is in my experience awful. "Oh, wait, = does this bug report refer to board-'top slot' or front-panel-'top = slot'?" In other words, I think it's handy to have up until the board = goes into an enclosure, then it could be trouble from then on. Plus it = could also encourage further knee-jerk, inappropriate .dts patching of = the sort I started out with here :) "Why make a devd script when I can = just edit the names in the .dts file?=94 Good points. > Agreed geom children are an open question. >=20 > -Patrick Warner From owner-freebsd-embedded@FreeBSD.ORG Thu Mar 6 04:17:20 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41C433A5; Thu, 6 Mar 2014 04:17:20 +0000 (UTC) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E6EEA8F9; Thu, 6 Mar 2014 04:17:18 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id mc6so1344335lab.41 for ; Wed, 05 Mar 2014 20:17:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=hkOQBHNASLYrEFplC3Gb8JbQ3Yi8Za76kbshZSBEO1o=; b=LDdV6LclMQGNvCJ9cKpREOtZlcI2TvowrsPQAzWx6c6KFpiEe/TwqcZPrdfpxJumMe ML0c9IzknHhRk7BDFM7+ARQnNfdbcpF3oNzo/gXHCnqaSusmUJ0mLxhTLE5GyX+XVIie csguAJOK3gmoUvRLqnb6MvDS1gDQWEROZhO6RhclvCbM3IRxoiRcGc7x+V2cYSoIz3DD D9ffMv8ttSSS5Ku+QpwGkA1Eqa7xAKsEFPnnE+iACCvrUy/PsvNDPFIAE7vze+tMwp4T Ugvqf4/Cu5QgIwux+816a6pqI8+9eN5UWX385Tk4s70gCbqid6e/3/hQ/79FWYVgYPmY ZbPg== MIME-Version: 1.0 X-Received: by 10.152.43.47 with SMTP id t15mr29450lal.38.1394079436185; Wed, 05 Mar 2014 20:17:16 -0800 (PST) Sender: pkelsey@gmail.com Received: by 10.112.142.5 with HTTP; Wed, 5 Mar 2014 20:17:16 -0800 (PST) In-Reply-To: <7F5BD549-6A25-48F5-989A-F2D43C241CFF@bsdimp.com> References: <7C2B7036-51CC-4C97-80C4-0A439874357D@bsdimp.com> <1393939277.1149.300.camel@revolution.hippie.lan> <438620C4-7712-4B01-A46F-CB57946A30BF@bsdimp.com> <16A5203B-B06D-4129-A54F-F34D5FA28D2B@bsdimp.com> <39ED4040-2A6A-4D85-97D5-DCDE4ECCA0EC@bsdimp.com> <899B9ABD-0ACC-49F2-9520-CCE837D39875@bsdimp.com> <9CEFA586-0319-4390-AC9A-B54EE77AD735@ieee.org> <7F5BD549-6A25-48F5-989A-F2D43C241CFF@bsdimp.com> Date: Wed, 5 Mar 2014 23:17:16 -0500 X-Google-Sender-Auth: gpLx7WI8-H7OzRN9jECszCw8tB0 Message-ID: Subject: Re: [PATCH] simplebus child device probe order control via FDT (motivated by BeagleBone Black) From: Patrick Kelsey To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-hackers@freebsd.org" , freebsd-arm , "freebsd-embedded@freebsd.org" , Ian Lepore X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 04:17:20 -0000 On Wed, Mar 5, 2014 at 10:52 PM, Warner Losh wrote: > > On Mar 5, 2014, at 7:48 PM, Patrick Kelsey wrote: > > > > > > > On Mar 5, 2014, at 8:02 PM, Warner Losh wrote: > > > >> > >> On Mar 5, 2014, at 5:53 PM, Patrick Kelsey wrote: > >> > >>> > >>> > >>> > >>> On Wed, Mar 5, 2014 at 5:44 PM, Warner Losh wrote: > >>> > >>> On Mar 5, 2014, at 2:56 PM, Patrick Kelsey wrote: > >>> > >>>> > >>>> > >>>> > >>>> On Wed, Mar 5, 2014 at 4:24 PM, Warner Losh wrote: > >>>> > >>>> On Mar 5, 2014, at 11:55 AM, Patrick Kelsey wrote: > >>>> > >>>>> > >>>>> > >>>>> > >>>>> On Wed, Mar 5, 2014 at 8:31 AM, Warner Losh wrote: > >>>>> > >>>>> On Mar 4, 2014, at 11:53 PM, Patrick Kelsey wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Tue, Mar 4, 2014 at 8:21 AM, Ian Lepore wrote: > >>>>>> > >>>>>> There's a standard property for mmc/sd devices, "non-removable" > whose > >>>>>> presence denotes things like soldered-on eMMC parts. Only one of > our > >>>>>> many sdhci drivers supports it right now (imx). In general the core > >>>>>> part of the driver (dev/sdhci) doesn't have good support for > >>>>>> insert/remove/presence detection that's handled off to the side > (whether > >>>>>> it's non-removable or a gpio pin). > >>>>>> > >>>>>> That alone doesn't solve the wider problem, though, which I think > breaks > >>>>>> down into two pieces. Let's say you've got two slots, call them > left > >>>>>> and right. You end up with these two problems... > >>>>>> > >>>>>> * Sometimes the right slot is mmcsd0, but it turns into mmcsd1 > if > >>>>>> there's a card in the left slot when I boot; I don't want it > to > >>>>>> change. > >>>>>> > >>>>>> And not just a boot-time issue, of course. If you were to remove > those two cards and then reinsert them in the opposite time-order, their > device names would swap. > >>>>>> > >>>>>> * I want the slot on the left to be named '1' and the right to > be > >>>>>> '0'. > >>>>>> > >>>>>> The first problem is easily solved without impacting dts in any > way. We > >>>>>> just wire down the relationship controllerN -> mmcN -> mmcsdN. > This is > >>>>>> exactly equivelent to the old ATA_STATIC_ID option in its effect -- > you > >>>>>> don't get to choose the names, but you know they won't change based > on > >>>>>> which devices are present. It could be controlled with a tunable. > >>>>>> > >>>>>> It's harder to envision the fix for the second part without adding > an > >>>>>> ad-hoc property for the devices. Even with a property I'm not sure > how > >>>>>> easy it would be. > >>>>>> > >>>>>> We should be able to assign a geographic address > (controllerX:slotY) to each mmcsd device in a given system (let's ignore > for now the theoretical possibility of multiple cards on one bus). The > 'controllerX' part of the address could be the controller's pathname from > the devicetree, or an index assigned by mmcbr machinery at attach time. > The "slotY" part of the address is assigned by the specific controller > device driver using some internally-determined fixed mapping between the > assigned values and its physical slots. This geographic address could be > used to create an additional set of /dev entries with stable names. There > could be a mechanism for user-configurable aliases for the geographical > addresses. > >>>>> > >>>>> There's already a chance to run a script when a device is attached > that can create /dev/slot0 or /dev/slot1 that has geographical information > available to it. People use ddvd for this in the USB world all the time to > make sure that tty devices get a symlink based on their location or serial > number. > >>>>> > >>>>> Why is mmc so different it needs its own mechanism? > >>>>> > >>>>> I'm laying out my view of the information that would be needed and > the types of actions that would have to be taken based on that information > to solve the issue. I'm not saying devd can't be the piece that is used to > implement the actions (indeed, I noted devd as a potential building block > for a solution in my initial response). I'm also not saying mmc needs its > own mechanism, I'm saying it needs /a/ mechanism, and so far there still > seems to be something missing (because it's not there, or I'm still > ignorant of it). > >>>>> > >>>>> What seems to be missing is geographical addressing for mmc devices. > >>>>> > >>>>> I think what you might be saying is that the existing mmcsd > add/remove code could be augmented to send devctl notifications, along the > lines of: > >>>>> > >>>>> devctl_notify("MMC", "DEVICE", "ATTACH"|"DETACH", "... > controller= > slot= rca=") > >>>>> > >>>>> and then I and the fine author of devctl and devd would be pleased. > >>>> > >>>> MMC doesn't need anything special here. That's already present. > Looking at the device tree we see on one of the platforms that's handy for > me to access: > >>>> > >>>> at91_mci0 > >>>> mmc0 > >>>> mmcsd0 at rca=0xb368 > >>>> > >>>> So you know that mmcsd0 is on mmc0 bus attached to at91_mci0, which > is ultimately the FDT node where things came from. There's not a > user-defined slot associated with this (and we should have a SLOT A vs SLOT > B as a location info for this platform, because we can have two cards on > the one bus in the MMC case), true, but for your use case I don't think > that you need it. We should be attaching the host controller regardless of > whether the or not there's a card in there, so it will be fixed. While some > additional information would be useful to publish, I don't think your use > case requires it... > >>>> > >>>> > >>>> The reason you need something extra here is that what is there now > breaks down whenever you don't have a one-to-one mapping between > controllers and buses. Any controller with more than one slot can yield > something of the form: > >>>> > >>>> sdhci0 > >>>> mmc0 > >>>> mmcsd0 at rca=0xabcd > >>>> mmc1 > >>>> mmcsd1 at rca=0x1234 > >>>> > >>>> and you have no idea what physical slot in the system mmcsd0 and > mmcsd1 are in. > >>> > >>> The driver isn't going to be able to help you, because it reports mmc0 > based on the data it gets from slot 0 status registers, and mmc1 based on > slot 1 status registers. Since there's no notion of how that maps to > physical hardware, the driver can't do anything automatically. And since > mmc on down is populated by FreeSBD, there's no hints in the FDT tree for > them. > >>> > >>> > >>>> For my immediate use case, sure, I can rely on the one-to-one > relationship between controllers and buses. At this point, though, rather > than skate by on that happy coincidence, I'd rather invest what now seems > to be a rather small amount of effort adding mmcsd devctl notifications > that would cover the multiple-slots-per-controller case as well, and then > build the rest of what I want on top of that information coming out of ddvd. > >>> > >>> Trouble is, how do we know what to send with this new notification. > That's the part I'm having trouble with. Where does that data come from? > And how is it different than what's in the device tree? > >>> > >>> > >>> Each controller driver maintains an instance of struct mmc_host for > each physical bus interface (typically referred to as a 'slot' in the > drivers) it has. When a card is detected in a given slot by the driver, > the driver creates an mmc bus instance and attaches the struct mmc_host > corresponding to that slot to provide the ivar values. So let's say struct > mmc_host gets a new member 'slot_number', and a new ivar > MMC_IVAR_SLOT_NUMBER is defined. The slot number in each instance of > struct mmc_host a driver maintains gets set to a controller-relative index > of the corresponding physical interface - the controller will do this the > same way every time, because it is tied to the register layout of the > controller. > >>> > >>> After the mmc bus instance is created and its ivars are set, > probe-and-attach is run on that bus, and an mmcsd device instance is > created for each card that is found. At the point where the mmcsd device > instance is created, one knows the parent bus for that new mmcsd device, > and thus one can get the value of MMC_IVAR_SLOT_NUMBER for that bus, as > well as the name of the controller device instance that is the parent of > the parent bus. It thus possible at that point to > >>> > >>> devctl_notify("MMC", "DEVICE", "ATTACH", "... > controller= slot= > ") > >>> > >>> Because the controller attachment order is the same on every boot, as > is the slot number ivar for a given bus interface on each controller > hardware instance, an identical attach message will be generated every time > a card is discovered in that physical location in the system. For a given > system, there will thus be a fixed mapping between > {controller_instance,slot} tuples that appear in these messages and the > physical MMC/SD device locations. > >> > >> I'm curious how that's materially different than the parent's mmc > instance number. That too is invariant between boots. There's a 1:1 - onto > mapping between this instance number and any controller/slot tuple that > would be created. > >> > > > > Controller instance (unit) numbers are the same across boots. The mmc > instance (unit) number for the mmc instance created for a given bus > interface on a given controller is not, because the instance is created > dynamically in response to card detection and thus depends on the ordering > of card insertions. > > That's the problem right there. The should always be the same from boot to > boot. sdhci must be doing things wrong. I'll have to take a look. That's > the real problem here. That's certainly how it is supposed to be working. > We always attach PCI busses to PCI bridges, regardless of what's on the > bus. mmc should be the same thing. I'll work up some patches for that. > > > Sure, there's a one-to-one and onto mapping at any given moment between > mmc instance numbers and the tuples I'm talking about, but the mapping is > subject to change with card insertions and removals. The material > difference between the two sets of labels is that a given tuple value will > *always* refer to the same physical device location in the system, whereas > a given mmc unit number could refer to any physical device location in the > system depending on the time order of insertions in the various card slots. > > I understand better now... > Yes, this fully explains the disconnect we were having. I was under the impression that sdhci was doing it that way to make way for reprobe/attach/discovery because it's actually doing card detect. It felt a bit weird at the time, but this is the example I followed when I did the mmcspi driver I posted to the list sometime back, as that also had card detect support. > > >> Also, there doesn't need to be a special MMC message for this. If we do > create the notion of a slot number per controller, that would be part of > the location information that is in the location string for the normal > attach message > > > > Ah, so I can just append more variable definitions to the location > string, which is already fed through to the existing generic devctl > notification? Works for me. > > Sure. > > >>> In the above, I've left out the value of rca from the discussion > because upon further reflection, it cannot be stably tied to a physical > location. If there is a multidrop MMC bus in a system, the physical card > locations on that bus will not be able to be referred to with stable names. > This is the one area where a new property in the FDT could be useful to > convey multidrop-or-not for each bus interface on a controller. The new > property could be 'freebsd,max-devices' and would be an array of cells that > indicates the maximum number of MMC/SD devices that can be connected to the > controller bus interface corresponding to that cell index. The devctl > notification could then include a multidrop indicator in the message. > >> > >> rca is more of a serial number than a location number. Useful for other > reasons. > >> > >> I'm not sure how 'freebsd,max-devices' would solve the problem. The > controller already knows that. If we really want to tie things to a > physical location/ description, I'd opt for something more like > 'freebsd,slot-names = "Slot 0", "Slot 1";' type of thing, where you could > just as easily have "Top Card" "bottom card" or "boot card" and "customer > card" if you wanted. Then the controller could query this property to get > the names to populate somewhere in the PNP info for this device. The mmcsd > driver would then be free to also create a /dev/Blah alias as well for the > disk, but I don't know if that would cause aliases to get created for all > the geom children or not... > >> > > > > freebsd,max-devices is not already known by the controller. The > controller knows how many bus interfaces it has, but it doesn't know how > many devices can be attached to that bus, as that depends on the board > design. freebsd,max-devices informs us whether the board design is > multidrop or not for each bus interface on each controller. Passing > through a multidrop indication in the devctl notification informs the > devctl consumer as to whether or not a unique stable name can be assigned > to the mmcsd instance based on the tuple (if multidrop, then no). Not > essential, but would be thorough. > > Hmmm, this sure sounds like something that should already be in the FDT > file. I'll have to do a survey. > > > I disagree with 'freebsd,slot-names' because meaningful/descriptive slot > names are going to be something that are often defined at the product > level, so I think it's better to just let them be defined via a devd action > script. Otherwise we build in an invitation to the experience of having > board-level slot names and product-level slot names from the same > namespace, which is in my experience awful. "Oh, wait, does this bug > report refer to board-'top slot' or front-panel-'top slot'?" In other > words, I think it's handy to have up until the board goes into an > enclosure, then it could be trouble from then on. Plus it could also > encourage further knee-jerk, inappropriate .dts patching of the sort I > started out with here :) "Why make a devd script when I can just edit the > names in the .dts file?" > > Good points. > > > Agreed geom children are an open question. > > > > -Patrick > > Warner > > From owner-freebsd-embedded@FreeBSD.ORG Thu Mar 6 14:36:49 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BCC9E56B for ; Thu, 6 Mar 2014 14:36:49 +0000 (UTC) Received: from homiemail-a7.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by mx1.freebsd.org (Postfix) with ESMTP id A08B3C7D for ; Thu, 6 Mar 2014 14:36:49 +0000 (UTC) Received: from homiemail-a7.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTP id ADAE925C06E; Thu, 6 Mar 2014 06:36:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=koffein.net; h= content-type:from:to:cc:subject:in-reply-to:references:date :message-id:content-transfer-encoding; s=koffein.net; bh=sJ9bo2P FSiZonv8cC+CFJN3POws=; b=K351vkmd1sUi2nJraqx/WbMCsDKM5J75Kiwc6+M nXvCvaytXByt62sxrahRhe6MZxQq57AvuRnk1fmuRj2Vjmw0AxqNLEGQuWk+8woR NXm/WDpyBQjkgenpzBHqmzl3mD6ejsr+m8sxj8XdvjHFz8nomhjsTQPaRBGR7KbC poYM= Received: from localhost (unknown [77.109.102.205]) (Authenticated sender: stl@koffein.net) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTPA id 56A3825C06D; Thu, 6 Mar 2014 06:36:42 -0800 (PST) Content-Type: text/plain; charset=UTF-8 From: Steven Lawrance To: John Hay Subject: Re: embedded board with 3 X wireless In-reply-to: <20140305105917.GA55874@zibbi.meraka.csir.co.za> References: <20140305105917.GA55874@zibbi.meraka.csir.co.za> Date: Thu, 06 Mar 2014 15:35:09 +0100 Message-Id: <1394115523-sup-9508@luwak.koffein.net> User-Agent: Sup/git Content-Transfer-Encoding: quoted-printable Cc: freebsd-embedded X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 14:36:49 -0000 Excerpts from John Hay's message of 2014-03-05 11:59:17 +0100: > We have been using AVILA, xscale arm based boards with 4 X MiniPCI slot= s > for a long time now. They are getting EOL and I was wondering what to > replace it with. Any ideas? Here is my short list of requirements: >=20 > - Run FreeBSD > - Boot from itself, even if you need to add some flash. We used CF on A= VILA. > - Possible to have 3 X wireless. It can be a mix of builtin and some fo= rm > of expansion. Wireless needs an antenna connector so that an > external antenna can be connected. > - 1 X Ethernet. More won't hurt, but is not needed. > - 128MB RAM or more. I'm not sure just how _good_ the support is, but since nobody else has mentioned it, it might be worth taking a look at some of the MIPS boards, such as the RouterStation Pro (http://www.ubnt.com/rspro) or MikroTik RB433AH (http://routerboard.com/RB433AH). They both have three MiniPCI slots and the former already has a kernel config in sys/mips/conf... cheers, Steven From owner-freebsd-embedded@FreeBSD.ORG Thu Mar 6 15:38:58 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C80901A9 for ; Thu, 6 Mar 2014 15:38:58 +0000 (UTC) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 90926355 for ; Thu, 6 Mar 2014 15:38:58 +0000 (UTC) Received: by mail-ob0-f169.google.com with SMTP id va2so2723146obc.0 for ; Thu, 06 Mar 2014 07:38:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7CGXGaJWBe6AY0p20zbgI+eH+SOh8sCcAuGl464qLoM=; b=Iqi/xlz+k8FcqTo4+iUuf2VHdFZBbywlubAfPGyW9IJFT6wmYslwDFpIcaaQjZ40tu 30EqL2a5bJ37AF4dWrzw0wXASVILgIHLl5s594hk0GrpeSaXpHYCyIzTdVqIyB3NfydF U/E85KcAQ1BU/WZcD6uHYcGTeKAbKmYUFGw1XvHuQWFHPlmC3f3hqZ7QqqGrNOEFR6NJ Px8XuwgVH9D4yGq4FfdOuQKNxqMIux0zojhL+EH8nL4G2V96JPvLdfWUMZnAQPHJMuku W0K+kIUQpR9zt8m04+6Ef0tzfUbAoZaGLw4Q7dShnqWCUSb7SqzoNrueqf1oOYGFidA2 4q3A== MIME-Version: 1.0 X-Received: by 10.60.46.98 with SMTP id u2mr6254795oem.44.1394120337839; Thu, 06 Mar 2014 07:38:57 -0800 (PST) Received: by 10.76.18.148 with HTTP; Thu, 6 Mar 2014 07:38:57 -0800 (PST) In-Reply-To: <1394115523-sup-9508@luwak.koffein.net> References: <20140305105917.GA55874@zibbi.meraka.csir.co.za> <1394115523-sup-9508@luwak.koffein.net> Date: Thu, 6 Mar 2014 10:38:57 -0500 Message-ID: Subject: Re: embedded board with 3 X wireless From: Outback Dingo To: Steven Lawrance Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-embedded X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 15:38:58 -0000 On Thu, Mar 6, 2014 at 9:35 AM, Steven Lawrance wrote: > Excerpts from John Hay's message of 2014-03-05 11:59:17 +0100: > > We have been using AVILA, xscale arm based boards with 4 X MiniPCI slots > > for a long time now. They are getting EOL and I was wondering what to > > replace it with. Any ideas? Here is my short list of requirements: > > > > - Run FreeBSD > > - Boot from itself, even if you need to add some flash. We used CF on > AVILA. > > - Possible to have 3 X wireless. It can be a mix of builtin and some form > > of expansion. Wireless needs an antenna connector so that an > > external antenna can be connected. > > - 1 X Ethernet. More won't hurt, but is not needed. > > - 128MB RAM or more. > > I'm not sure just how _good_ the support is, but since nobody else has > mentioned it, it might be worth taking a look at some of the MIPS > boards, such as the RouterStation Pro (http://www.ubnt.com/rspro) or > Im fairly sure the RS/RSPRO line from Ubiquiti has already long been end of life. you can buy them anymore, unless used on ebay i would guess Aside from that, look at ALIX, they have a new ALIX APU board coming w/ 3x minipci and run FreeBSD fine > MikroTik RB433AH (http://routerboard.com/RB433AH). They both have > three MiniPCI slots and the former already has a kernel config in > sys/mips/conf... > > cheers, > Steven > _______________________________________________ > freebsd-embedded@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-embedded > To unsubscribe, send any mail to "freebsd-embedded-unsubscribe@freebsd.org > " > From owner-freebsd-embedded@FreeBSD.ORG Thu Mar 6 15:47:59 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D2FAE599 for ; Thu, 6 Mar 2014 15:47:59 +0000 (UTC) Received: from pzwet.vanderzwet.net (pzwet.vanderzwet.net [IPv6:2a01:4f8:190:8221::1:1]) by mx1.freebsd.org (Postfix) with ESMTP id 94D3D627 for ; Thu, 6 Mar 2014 15:47:59 +0000 (UTC) Received: from [192.168.99.86] (D57DF752.static.ziggozakelijk.nl [213.125.247.82]) by pzwet.vanderzwet.net (Postfix) with ESMTPSA id CA7B0F4FFB4A; Thu, 6 Mar 2014 15:47:55 +0000 (UTC) Message-ID: <531898AA.3080604@rickvanderzwet.nl> Date: Thu, 06 Mar 2014 16:47:54 +0100 From: Rick van der Zwet User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Outback Dingo , Steven Lawrance Subject: Re: embedded board with 3 X wireless References: <20140305105917.GA55874@zibbi.meraka.csir.co.za> <1394115523-sup-9508@luwak.koffein.net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on pzwet.vanderzwet.net Cc: freebsd-embedded X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 15:47:59 -0000 On 06/03/14 16:38, Outback Dingo wrote: ... > Aside from that, look at ALIX, they have a new ALIX APU board coming w/ 3x > minipci and run FreeBSD fine Be careful with MiniPCI Express slots. They are 'abused' these days for all kind of non-compatible connector layouts. This three slots all have different functions (SATA, WiFi, GSM). Best regards, /Rick -- http://rickvanderzwet.nl From owner-freebsd-embedded@FreeBSD.ORG Thu Mar 6 15:49:16 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3FE8A6D2 for ; Thu, 6 Mar 2014 15:49:16 +0000 (UTC) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 08689637 for ; Thu, 6 Mar 2014 15:49:15 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n16so2771572oag.13 for ; Thu, 06 Mar 2014 07:49:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZkZ1DYK/8P5k8+TF6kaLqxsBC3OkS6XQHMdMtAZTY1Y=; b=sGk5tgbfWHio3DqO68LOzQv/2g6mvxb9785PqTrAP9A1Ys/8/cOcFrHKBqgi2GcQlx pGzBdj8GDacxmm+wElJwKiJKzGcVGIFAFQwZ25cxD8mzDs0+H//LHGdn8s4EGxcnc1Fz ULHIgwsRCTn/DVAHLj4oPttay2cD+AhPXZgPepsdH3HjhxQE4fUdivyT9szNl8fX5kv2 8uuDdzvJ7Vj02CBDtQWPJ4ws0fH6js+49Z87d6SJi3K7S3bpthFCmcUJigIuO7h0LNFP /33xQ8BwJ0IeOtdmNix9Q+FWhGfKCrayqmFHvaJH9mB3TCDdNCmeBMNVANTGQYExdCfr V3OA== MIME-Version: 1.0 X-Received: by 10.60.246.10 with SMTP id xs10mr6315315oec.18.1394120955447; Thu, 06 Mar 2014 07:49:15 -0800 (PST) Received: by 10.76.18.148 with HTTP; Thu, 6 Mar 2014 07:49:15 -0800 (PST) In-Reply-To: <531898AA.3080604@rickvanderzwet.nl> References: <20140305105917.GA55874@zibbi.meraka.csir.co.za> <1394115523-sup-9508@luwak.koffein.net> <531898AA.3080604@rickvanderzwet.nl> Date: Thu, 6 Mar 2014 10:49:15 -0500 Message-ID: Subject: Re: embedded board with 3 X wireless From: Outback Dingo To: Rick van der Zwet Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-embedded X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 15:49:16 -0000 On Thu, Mar 6, 2014 at 10:47 AM, Rick van der Zwet wrote: > On 06/03/14 16:38, Outback Dingo wrote: > ... > > Aside from that, look at ALIX, they have a new ALIX APU board coming w/ > 3x > > minipci and run FreeBSD fine > > Be careful with MiniPCI Express slots. They are 'abused' these days for > all kind of non-compatible connector layouts. This three slots all have > different functions (SATA, WiFi, GSM). > this is also true, luckily we only use them for GSM, and WIFI :) > > Best regards, > /Rick > -- > http://rickvanderzwet.nl > From owner-freebsd-embedded@FreeBSD.ORG Thu Mar 6 16:01:19 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A6767D0F for ; Thu, 6 Mar 2014 16:01:19 +0000 (UTC) Received: from homiemail-a1.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by mx1.freebsd.org (Postfix) with ESMTP id 89233818 for ; Thu, 6 Mar 2014 16:01:19 +0000 (UTC) Received: from homiemail-a1.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTP id CF7A0348072; Thu, 6 Mar 2014 08:01:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=koffein.net; h= content-type:from:to:cc:subject:in-reply-to:references:date :message-id:content-transfer-encoding; s=koffein.net; bh=S6LLEVT dCINNEv8rckv86ECXXVg=; b=C+KGYjvnzRYS7q8AS3oWAXBFaDLKMbMTxgTsA1U db2WX7l2JSZI1zPTPAt7sTuiawwRd4iPLuHkGEyEsiZrToPRUl6Q3xNQ6pdxbr+W iwCGLuuygQ90po1hHjLtO2kdO0n5FoFppQ8julS8hz5rS+auzE3/INuO0Ts/79Yv K8TE= Received: from localhost (unknown [77.109.102.205]) (Authenticated sender: stl@koffein.net) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTPA id 58C6434806F; Thu, 6 Mar 2014 08:01:13 -0800 (PST) Content-Type: text/plain; charset=UTF-8 From: Steven Lawrance To: Outback Dingo Subject: Re: embedded board with 3 X wireless In-reply-to: References: <20140305105917.GA55874@zibbi.meraka.csir.co.za> <1394115523-sup-9508@luwak.koffein.net> Date: Thu, 06 Mar 2014 16:59:42 +0100 Message-Id: <1394121159-sup-867@luwak.koffein.net> User-Agent: Sup/git Content-Transfer-Encoding: quoted-printable Cc: freebsd-embedded X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 16:01:19 -0000 Excerpts from Outback Dingo's message of 2014-03-06 16:38:57 +0100: > On Thu, Mar 6, 2014 at 9:35 AM, Steven Lawrance wrote= : > > I'm not sure just how _good_ the support is, but since nobody else ha= s > > mentioned it, it might be worth taking a look at some of the MIPS > > boards, such as the RouterStation Pro (http://www.ubnt.com/rspro) or >=20 > Im fairly sure the RS/RSPRO line from Ubiquiti has already long been en= d of > life. > you can buy them anymore, unless used on ebay i would guess >=20 > Aside from that, look at ALIX, they have a new ALIX APU board coming w/= 3x > minipci and run FreeBSD fine I just noticed that this has moved to production but while that looks like three MiniPCI-E slots, one of them is actually a micro SATA port. The price looks good for those specs, though. Steven From owner-freebsd-embedded@FreeBSD.ORG Fri Mar 7 04:42:47 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 269ACE65 for ; Fri, 7 Mar 2014 04:42:47 +0000 (UTC) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E4D3D967 for ; Fri, 7 Mar 2014 04:42:46 +0000 (UTC) Received: by mail-oa0-f43.google.com with SMTP id g12so3696967oah.30 for ; Thu, 06 Mar 2014 20:42:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=6BrGJdSqxAA99DXAvaCkw3z7q1n4T21ntxnP5rvAFCU=; b=QIN8sOJqCXiS0ztZUVx2oZtdCTadF8r4CIN67aC21jRVV6hVbT84VdKsItaO6FUXdU gMBDPSDy4koTlhavgHii2KLYJGJHdiSvelIdvqPok+mapjA6F9Zc0FvQJIsB9SPgcJGk XeR5y/CwKFEn1MvoKmdMLSnblrw3hygA9n4SvOzvRDb1VZ8KJ7L55FlpIAm7pnNswk+b cirP0d6tFV5inkvYf/pRghBKexmKThwiWPT/xcPC86pK5SOg/qh4IojtgvUhU7+Y2zGQ D1N5ePhdmsjPJegYV1zZ5oYV3rgVSWu0g6BG0btLpq4yzW/CPidFX2Va2I6TrvyzbXSx tgIA== X-Received: by 10.182.53.72 with SMTP id z8mr13410288obo.36.1394167366104; Thu, 06 Mar 2014 20:42:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.80.194 with HTTP; Thu, 6 Mar 2014 20:42:15 -0800 (PST) In-Reply-To: <531898AA.3080604@rickvanderzwet.nl> References: <20140305105917.GA55874@zibbi.meraka.csir.co.za> <1394115523-sup-9508@luwak.koffein.net> <531898AA.3080604@rickvanderzwet.nl> From: Jia-Shiun Li Date: Fri, 7 Mar 2014 12:42:15 +0800 Message-ID: Subject: Re: embedded board with 3 X wireless To: Rick van der Zwet Content-Type: text/plain; charset=UTF-8 Cc: freebsd-embedded X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 04:42:47 -0000 On Thu, Mar 6, 2014 at 11:47 PM, Rick van der Zwet wrote: > On 06/03/14 16:38, Outback Dingo wrote: > ... >> Aside from that, look at ALIX, they have a new ALIX APU board coming w/ 3x >> minipci and run FreeBSD fine > > Be careful with MiniPCI Express slots. They are 'abused' these days for > all kind of non-compatible connector layouts. This three slots all have > different functions (SATA, WiFi, GSM). > UIM signals are actually defined in PCIe Mini Card ECM spec. Just that only one SIM socket is connected to onboard socket, for obvious reason. WiFi device control signals are also defined in the spec, but again not every socket have these pinouts connected. Care needed, yes. But abuse? probably not. The spec is not intended to make device/slot universal among all implementations like PCIe slots do. There are more than main PCIe signals to take care of, and that's left to system integrators on purpose. The name is just misleading. Probably it should not have been called PCIe Mini Card, but "Versatile Mini Card for PCie, USB, UIM, WiFi" instead. ;) (and yes, mSATA is not in the spec. That's another story.) -Jia-Shiun. From owner-freebsd-embedded@FreeBSD.ORG Fri Mar 7 19:57:41 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B489D53E; Fri, 7 Mar 2014 19:57:41 +0000 (UTC) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EF40D898; Fri, 7 Mar 2014 19:57:40 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id w61so5689771wes.18 for ; Fri, 07 Mar 2014 11:57:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=mwOdQ9ItlBUjtabe5D1FLwnoCTsc88EPKnJnF/0rYvw=; b=sARdBKyG3XJ/lXx4I+s6w5D7Ti+lV7CNqs0v3v1MzjM7e33LayMZ2WSNoWJItx3yoI +qdFB7RuUQbdoaY53DdVoPFUIlU0vah3sFyamc7vwoHHqWjIYc/xJ56FGToJ5HKPnIA1 8vjVyyzaK1xSjeePowHny3tMVP7Lfb88lbFpQ6kcnzRI247QSIRoizq5z095QFvV9aqv AyrSG3YN8lXVXTscsgMj+dIb642nJzw7DOUMtdSDIHM8Nc9G/xKpB85Ad82LsLIKJLm1 ZGkBoXcsMoS/KdheeXwKXk3gow9faIi9Rz+ye+J2QxIc3XbLA098zpRwwcKhxOu+cQmS 5Gcg== MIME-Version: 1.0 X-Received: by 10.180.19.35 with SMTP id b3mr162665wie.20.1394222259384; Fri, 07 Mar 2014 11:57:39 -0800 (PST) Received: by 10.216.188.132 with HTTP; Fri, 7 Mar 2014 11:57:39 -0800 (PST) Date: Fri, 7 Mar 2014 16:57:39 -0300 Message-ID: Subject: bsnmp lm75 module From: Luiz Otavio O Souza To: "freebsd-embedded@freebsd.org" , freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary=bcaec53d5eb583d78b04f409aa66 X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 19:57:41 -0000 --bcaec53d5eb583d78b04f409aa66 Content-Type: text/plain; charset=ISO-8859-1 Hello, I've written a bsnmp module to export the lm75 sensor's temperature (and some other data) over SNMP. With this module it is simple and easy to monitor the temperature of rooms and other devices over the network with help of a RPi, a BBB or others. This is my first module for bsnmp, so i would appreciate if someone more clueful about it could take a look (can i just pick any free MIB ?) The lm75 kernel driver is the same published on http://lists.freebsd.org/pipermail/freebsd-embedded/2013-November/002195.html I'll publish an updated version soon (for the lm75 kernel driver) which include a man page and support for non FDT systems. The SNMP data usually looks like: http://pastebin.com/cHYYBY1R It includes the number of sensors on system, the driver name, the compat string, the i2c bus and address and, sure, the sensor temperature. Cheers, Luiz --bcaec53d5eb583d78b04f409aa66 Content-Type: text/plain; charset=US-ASCII; name="snmp_lm75.diff" Content-Disposition: attachment; filename="snmp_lm75.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hshvmpyy0 SW5kZXg6IGV0Yy9zbm1wZC5jb25maWcKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gZXRjL3NubXBkLmNvbmZpZwko cmV2aXNpb24gMjYyODYwKQorKysgZXRjL3NubXBkLmNvbmZpZwkod29ya2luZyBjb3B5KQpAQCAt Mjk2LDYgKzI5NiwxMiBAQAogI2JlZ2Vtb3RTbm1wZE1vZHVsZVBhdGguImJyaWRnZSIgPSAiL3Vz ci9saWIvc25tcF9icmlkZ2Uuc28iCiAKICMKKyMgTE03NSBTZW5zb3IgbW9kdWxlCisjICBUaGlz IHJlcXVpcmVzIHRoZSBtaWJJSSBtb2R1bGUuCisjCisjYmVnZW1vdFNubXBkTW9kdWxlUGF0aC4i bG03NSIgPSAiL3Vzci9saWIvc25tcF9sbTc1LnNvIgorCisjCiAjIFdpcmVsZXNzIG1vZHVsZQog IyAgVGhpcyByZXF1aXJlcyB0aGUgbWliSUkgbW9kdWxlLgogIwpJbmRleDogdXNyLnNiaW4vYnNu bXBkL21vZHVsZXMvTWFrZWZpbGUKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gdXNyLnNiaW4vYnNubXBkL21vZHVs ZXMvTWFrZWZpbGUJKHJldmlzaW9uIDI2Mjg2MCkKKysrIHVzci5zYmluL2Jzbm1wZC9tb2R1bGVz L01ha2VmaWxlCSh3b3JraW5nIGNvcHkpCkBAIC0xMiw2ICsxMiw3IEBACiAJc25tcF9icmlkZ2Ug XAogCXNubXBfaGFzdCBcCiAJc25tcF9ob3N0cmVzIFwKKwlzbm1wX2xtNzUgXAogCXNubXBfbWli SUkgXAogCXNubXBfdGFyZ2V0IFwKIAlzbm1wX3VzbSBcCkluZGV4OiB1c3Iuc2Jpbi9ic25tcGQv bW9kdWxlcy9zbm1wX2xtNzUvQkVHRU1PVC1MTTc1LU1JQi50eHQKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gdXNy LnNiaW4vYnNubXBkL21vZHVsZXMvc25tcF9sbTc1L0JFR0VNT1QtTE03NS1NSUIudHh0CShyZXZp c2lvbiAwKQorKysgdXNyLnNiaW4vYnNubXBkL21vZHVsZXMvc25tcF9sbTc1L0JFR0VNT1QtTE03 NS1NSUIudHh0CSh3b3JraW5nIGNvcHkpCkBAIC0wLDAgKzEsMTYwIEBACistLQorLS0gQ29weXJp Z2h0IChjKSAyMDE0IEx1aXogT3RhdmlvIE8gU291emEgPGxvb3NARnJlZUJTRC5vcmc+CistLSBB bGwgcmlnaHRzIHJlc2VydmVkLgorLS0KKy0tIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291 cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAorLS0gbW9kaWZpY2F0aW9uLCBh cmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zCistLSBh cmUgbWV0OgorLS0gMS4gUmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWlu IHRoZSBhYm92ZSBjb3B5cmlnaHQKKy0tICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlv bnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4KKy0tIDIuIFJlZGlzdHJpYnV0aW9ucyBp biBiaW5hcnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0CistLSAgICBu b3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWlt ZXIgaW4gdGhlCistLSAgICBkb2N1bWVudGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlhbHMgcHJv dmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9uLgorLS0KKy0tIFRISVMgU09GVFdBUkUgSVMgUFJP VklERUQgQlkgVEhFIFJFR0VOVFMgQU5EIENPTlRSSUJVVE9SUyBgYEFTIElTJycgQU5ECistLSBB TlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1J VEVEIFRPLCBUSEUKKy0tIElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5E IEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFCistLSBBUkUgRElTQ0xBSU1FRC4gIElO IE5PIEVWRU5UIFNIQUxMIFRIRSBSRUdFTlRTIE9SIENPTlRSSUJVVE9SUyBCRSBMSUFCTEUKKy0t IEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZ LCBPUiBDT05TRVFVRU5USUFMCistLSBEQU1BR0VTIChJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRF RCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVURSBHT09EUworLS0gT1IgU0VSVklDRVM7IExP U1MgT0YgVVNFLCBEQVRBLCBPUiBQUk9GSVRTOyBPUiBCVVNJTkVTUyBJTlRFUlJVUFRJT04pCist LSBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIg SU4gQ09OVFJBQ1QsIFNUUklDVAorLS0gTElBQklMSVRZLCBPUiBUT1JUIChJTkNMVURJTkcgTkVH TElHRU5DRSBPUiBPVEhFUldJU0UpIEFSSVNJTkcgSU4gQU5ZIFdBWQorLS0gT1VUIE9GIFRIRSBV U0UgT0YgVEhJUyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElUWSBP RgorLS0gU1VDSCBEQU1BR0UuCistLQorLS0gJEZyZWVCU0QkCistLQorCitCRUdFTU9ULUxNNzUt TUlCIERFRklOSVRJT05TIDo6PSBCRUdJTgorCitJTVBPUlRTCisgICAgTU9EVUxFLUlERU5USVRZ LCBPQkpFQ1QtVFlQRSwgTk9USUZJQ0FUSU9OLVRZUEUsCisgICAgQ291bnRlcjY0LCBJbnRlZ2Vy MzIKKwlGUk9NIFNOTVB2Mi1TTUkKKyAgICBURVhUVUFMLUNPTlZFTlRJT04sIFJvd1N0YXR1cwor CUZST00gU05NUHYyLVRDCisgICAgYmVnZW1vdAorCUZST00gQkVHRU1PVC1NSUI7CisKK2JlZ2Vt b3RMb29zIE1PRFVMRS1JREVOVElUWQorICAgIExBU1QtVVBEQVRFRCAiMjAxNDAyMjQwMDAwWiIK KyAgICBPUkdBTklaQVRJT04gIkZyZWVCU0QiCisgICAgQ09OVEFDVC1JTkZPCisJICAgICIJCUx1 aXogT3RhdmlvIE8gU291emEKKworCSAgICAgUG9zdGFsOglOL0EKKworCSAgICAgRmF4OglOL0EK KworCSAgICAgRS1NYWlsOglsb29zQEZyZWVCU0Qub3JnIgorICAgIERFU0NSSVBUSU9OCisJICAg ICJUaGUgQmVnZW1vdCBNSUIgZm9yIHJlYWRpbmcgbG03NSBzZW5zb3JzIGRhdGEuIgorICAgIFJF VklTSU9OICAgICAiMjAxNDAyMjQwMDAwWiIKKyAgICBERVNDUklQVElPTgorCSAgICAiSW5pdGlh bCByZXZpc2lvbi4iCisgICAgOjo9IHsgYmVnZW1vdCA0MDAgfQorCitiZWdlbW90TG03NU9iamVj dHMJT0JKRUNUIElERU5USUZJRVIgOjo9IHsgYmVnZW1vdExtNzUgMSB9CisKKy0tIC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gLS0KKy0t IENvbmZpZ3VyYXRpb24gcGFyYW1ldGVycworLS0gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAtLQorCitsbTc1U2Vuc29yCU9CSkVDVCBJ REVOVElGSUVSIDo6PSB7IGJlZ2Vtb3RsbTc1T2JqZWN0cyAxIH0KKworbG03NVNlbnNvcnMJT0JK RUNULVRZUEUKKyAgICBTWU5UQVgJSW50ZWdlcjMyCisgICAgTUFYLUFDQ0VTUwlyZWFkLW9ubHkK KyAgICBTVEFUVVMJY3VycmVudAorICAgIERFU0NSSVBUSU9OCisJIk51bWJlciBvZiBMTTc1IHNl bnNvcnMgaW4gdGhlIHN5c3RlbS4iCisgICAgOjo9IHsgbG03NVNlbnNvcnMgMSB9CisKKy0tIC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0g LS0KKy0tIFRlbXBTZW5zb3IgVGFibGUKKy0tIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gLS0KK2xtNzVTZW5zb3JUYWJsZSBPQkpFQ1Qt VFlQRQorICAgIFNZTlRBWAlTRVFVRU5DRSBPRiBMbTc1U2Vuc29yRW50cnkKKyAgICBNQVgtQUND RVNTCW5vdC1hY2Nlc3NpYmxlCisgICAgU1RBVFVTCWN1cnJlbnQKKyAgICBERVNDUklQVElPTgor CSJBIHRhYmxlIGNvbnRhaW5pbmcgaW5mb3JtYXRpb24gYWJvdXQgYWxsIHRlbXBlcmF0dXJlIHNl bnNvcnMuIgorICAgIDo6PSB7IGJlZ2Vtb3RMbTc1T2JqZWN0cyAyIH0KKworbG9vc1RlbXBTZW5z b3JFbnRyeSBPQkpFQ1QtVFlQRQorICAgIFNZTlRBWAlMbTc1U2Vuc29yRW50cnkKKyAgICBNQVgt QUNDRVNTCW5vdC1hY2Nlc3NpYmxlCisgICAgU1RBVFVTCWN1cnJlbnQKKyAgICBERVNDUklQVElP TgorCSJUYWJsZSBlbnRyeSB0aGF0IGRlc2NyaWJlcyBvbmUgdGVtcGVyYXR1cmUgc2Vuc29yLiIK KyAgICBJTkRFWAl7IGxtNzVTZW5zb3JJbmRleCB9CisgICAgOjo9IHsgbG03NVNlbnNvclRhYmxl IDEgfQorCitMbTc1U2Vuc29yRW50cnkgOjo9IFNFUVVFTkNFIHsKKyAgICBsbTc1U2Vuc29ySW5k ZXgJCQlJbnRlZ2VyMzIsCisgICAgbG03NVNlbnNvclN5c2N0bEluZGV4CQlJbnRlZ2VyMzIsCisg ICAgbG03NVNlbnNvckRlc2MJCQlPQ1RFVCBTVFJJTkcsCisgICAgbG03NVNlbnNvckxvY2F0aW9u CQkJT0NURVQgU1RSSU5HLAorICAgIGxtNzVTZW5zb3JQbnBJbmZvCQkJT0NURVQgU1RSSU5HLAor ICAgIGxtNzVTZW5zb3JQYXJlbnQJCQlPQ1RFVCBTVFJJTkcsCisgICAgbG03NVNlbnNvclRlbXBl cmF0dXJlCQlJbnRlZ2VyMzIKK30KKworbG03NVNlbnNvckluZGV4IE9CSkVDVC1UWVBFCisgICAg U1lOVEFYCUludGVnZXIzMgorICAgIE1BWC1BQ0NFU1MJcmVhZC1vbmx5CisgICAgU1RBVFVTCWN1 cnJlbnQKKyAgICBERVNDUklQVElPTgorCSJMTTc1IFNlbnNvciBpbmRleC4iCisgICAgOjo9IHsg bG03NVNlbnNvckVudHJ5IDEgfQorCitsbTc1U2Vuc29yU3lzY3RsSW5kZXggT0JKRUNULVRZUEUK KyAgICBTWU5UQVgJSW50ZWdlcjMyCisgICAgTUFYLUFDQ0VTUwlyZWFkLW9ubHkKKyAgICBTVEFU VVMJY3VycmVudAorICAgIERFU0NSSVBUSU9OCisJIkxNNzUgU2Vuc29yIHN5c2N0bCBpbmRleC4i CisgICAgOjo9IHsgbG03NVNlbnNvckVudHJ5IDIgfQorCitsbTc1U2Vuc29yRGVzYyBPQkpFQ1Qt VFlQRQorICAgIFNZTlRBWAlPQ1RFVCBTVFJJTkcKKyAgICBNQVgtQUNDRVNTCXJlYWQtb25seQor ICAgIFNUQVRVUwljdXJyZW50CisgICAgREVTQ1JJUFRJT04KKwkiTE03NSBTZW5zb3IgZGVzY3Jp cHRpb24uIgorICAgIDo6PSB7IGxtNzVTZW5zb3JFbnRyeSAzIH0KKworbG03NVNlbnNvckxvY2F0 aW9uIE9CSkVDVC1UWVBFCisgICAgU1lOVEFYCU9DVEVUIFNUUklORworICAgIE1BWC1BQ0NFU1MJ cmVhZC1vbmx5CisgICAgU1RBVFVTCWN1cnJlbnQKKyAgICBERVNDUklQVElPTgorCSJMTTc1IFNl bnNvciBsb2NhdGlvbi4iCisgICAgOjo9IHsgbG03NVNlbnNvckVudHJ5IDQgfQorCitsbTc1U2Vu c29yUG5wSW5mbyBPQkpFQ1QtVFlQRQorICAgIFNZTlRBWAlPQ1RFVCBTVFJJTkcKKyAgICBNQVgt QUNDRVNTCXJlYWQtb25seQorICAgIFNUQVRVUwljdXJyZW50CisgICAgREVTQ1JJUFRJT04KKwki TE03NSBTZW5zb3IgcG5wIGluZm9ybWF0aW9uLiIKKyAgICA6Oj0geyBsbTc1U2Vuc29yRW50cnkg NSB9CisKK2xtNzVTZW5zb3JQYXJlbnQgT0JKRUNULVRZUEUKKyAgICBTWU5UQVgJT0NURVQgU1RS SU5HCisgICAgTUFYLUFDQ0VTUwlyZWFkLW9ubHkKKyAgICBTVEFUVVMJY3VycmVudAorICAgIERF U0NSSVBUSU9OCisJIkxNNzUgU2Vuc29yIHBhcmVudCBidXMuIgorICAgIDo6PSB7IGxtNzVTZW5z b3JFbnRyeSA2IH0KKworbG03NVNlbnNvclRlbXBlcmF0dXJlIE9CSkVDVC1UWVBFCisgICAgU1lO VEFYCUludGVnZXIzMgorICAgIE1BWC1BQ0NFU1MJcmVhZC1vbmx5CisgICAgU1RBVFVTCWN1cnJl bnQKKyAgICBERVNDUklQVElPTgorCSJMTTc1IFNlbnNvciB0ZW1wZXJhdHVyZS4iCisgICAgOjo9 IHsgbG03NVNlbnNvckVudHJ5IDcgfQorCitFTkQKClByb3BlcnR5IGNoYW5nZXMgb246IHVzci5z YmluL2Jzbm1wZC9tb2R1bGVzL3NubXBfbG03NS9CRUdFTU9ULUxNNzUtTUlCLnR4dApfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCkFkZGVkOiBzdm46ZW9sLXN0eWxlCiMjIC0wLDAgKzEgIyMKK25hdGl2ZQpcIE5vIG5ld2xp bmUgYXQgZW5kIG9mIHByb3BlcnR5CkFkZGVkOiBzdm46bWltZS10eXBlCiMjIC0wLDAgKzEgIyMK K3RleHQvcGxhaW4KXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBwcm9wZXJ0eQpBZGRlZDogc3ZuOmtl eXdvcmRzCiMjIC0wLDAgKzEgIyMKK0ZyZWVCU0Q9JUgKXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBw cm9wZXJ0eQpJbmRleDogdXNyLnNiaW4vYnNubXBkL21vZHVsZXMvc25tcF9sbTc1L01ha2VmaWxl Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0KLS0tIHVzci5zYmluL2Jzbm1wZC9tb2R1bGVzL3NubXBfbG03NS9NYWtlZmls ZQkocmV2aXNpb24gMCkKKysrIHVzci5zYmluL2Jzbm1wZC9tb2R1bGVzL3NubXBfbG03NS9NYWtl ZmlsZQkod29ya2luZyBjb3B5KQpAQCAtMCwwICsxLDEzIEBACisjICRGcmVlQlNEJAorCisuaW5j bHVkZSA8YnNkLm93bi5taz4KKworTU9EPSAgICBsbTc1CitTUkNTPSAgIHNubXBfbG03NS5jCitY U1lNPSAgIGJlZ2Vtb3RMbTc1CitNQU49ICAgIHNubXBfbG03NS4zCisKK0JNSUJTPSAgQkVHRU1P VC1MTTc1LU1JQi50eHQKK0RFRlM9ICAgJHtNT0R9X3RyZWUuZGVmCisKKy5pbmNsdWRlIDxic2Qu c25tcG1vZC5taz4KClByb3BlcnR5IGNoYW5nZXMgb246IHVzci5zYmluL2Jzbm1wZC9tb2R1bGVz L3NubXBfbG03NS9NYWtlZmlsZQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkFkZGVkOiBzdm46ZW9sLXN0eWxlCiMjIC0w LDAgKzEgIyMKK25hdGl2ZQpcIE5vIG5ld2xpbmUgYXQgZW5kIG9mIHByb3BlcnR5CkFkZGVkOiBz dm46bWltZS10eXBlCiMjIC0wLDAgKzEgIyMKK3RleHQvcGxhaW4KXCBObyBuZXdsaW5lIGF0IGVu ZCBvZiBwcm9wZXJ0eQpBZGRlZDogc3ZuOmtleXdvcmRzCiMjIC0wLDAgKzEgIyMKK0ZyZWVCU0Q9 JUgKXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBwcm9wZXJ0eQpJbmRleDogdXNyLnNiaW4vYnNubXBk L21vZHVsZXMvc25tcF9sbTc1L2xtNzVfdHJlZS5kZWYKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gdXNyLnNiaW4v YnNubXBkL21vZHVsZXMvc25tcF9sbTc1L2xtNzVfdHJlZS5kZWYJKHJldmlzaW9uIDApCisrKyB1 c3Iuc2Jpbi9ic25tcGQvbW9kdWxlcy9zbm1wX2xtNzUvbG03NV90cmVlLmRlZgkod29ya2luZyBj b3B5KQpAQCAtMCwwICsxLDU2IEBACisjLQorIyBDb3B5cmlnaHQgKGMpIDIwMTQgTHVpeiBPdGF2 aW8gTyBTb3V6YSA8bG9vc0BGcmVlQlNELm9yZz4KKyMgQWxsIHJpZ2h0cyByZXNlcnZlZC4KKyMK KyMgUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0 aCBvciB3aXRob3V0CisjIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0 IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucworIyBhcmUgbWV0OgorIyAxLiBSZWRpc3RyaWJ1dGlv bnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdodAorIyAgICBu b3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWlt ZXIuCisjIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0 aGUgYWJvdmUgY29weXJpZ2h0CisjICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMg YW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBpbiB0aGUKKyMgICAgZG9jdW1lbnRhdGlvbiBh bmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlIGRpc3RyaWJ1dGlvbi4KKyMK KyMgVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgUkVHRU5UUyBBTkQgQ09OVFJJQlVU T1JTIGBgQVMgSVMnJyBBTkQKKyMgQU5ZIEVYUFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVTLCBJ TkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFCisjIElNUExJRUQgV0FSUkFOVElFUyBP RiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFCisj IEFSRSBESVNDTEFJTUVELiAgSU4gTk8gRVZFTlQgU0hBTEwgVEhFIFJFR0VOVFMgT1IgQ09OVFJJ QlVUT1JTIEJFIExJQUJMRQorIyBGT1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1QsIElOQ0lERU5UQUws IFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09OU0VRVUVOVElBTAorIyBEQU1BR0VTIChJTkNMVURJ TkcsIEJVVCBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVURSBHT09EUwor IyBPUiBTRVJWSUNFUzsgTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNT IElOVEVSUlVQVElPTikKKyMgSE9XRVZFUiBDQVVTRUQgQU5EIE9OIEFOWSBUSEVPUlkgT0YgTElB QklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QKKyMgTElBQklMSVRZLCBPUiBUT1JU IChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0UpIEFSSVNJTkcgSU4gQU5ZIFdBWQor IyBPVVQgT0YgVEhFIFVTRSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhF IFBPU1NJQklMSVRZIE9GCisjIFNVQ0ggREFNQUdFLgorIworIyAkRnJlZUJTRCQKKyMKKworKDEg aW50ZXJuZXQKKyAgKDQgcHJpdmF0ZQorICAgICgxIGVudGVycHJpc2VzCisgICAgICAoMTIzMjUg Zm9rdXMKKyAgICAgICAgKDEgYmVnZW1vdAorICAgICAgICAgICg0MDAgYmVnZW1vdExtNzUKKyAg ICAgICAgICAgICgxIGJlZ2Vtb3RMbTc1T2JqZWN0cworICAgICAgICAgICAgICAoMSBsbTc1U2Vu c29ycworICAgICAgICAgICAgICAgICgxIGxtNzVTZW5zb3JzIElOVEVHRVIzMiBvcF9sbTc1U2Vu c29ycyBHRVQpCisgICAgICAgICAgICAgICkKKyAgICAgICAgICAgICAgKDIgbG03NVNlbnNvclRh YmxlCisgICAgICAgICAgICAgICAgKDEgbG03NVNlbnNvckVudHJ5IDogT0NURVRTVFJJTkcgb3Bf bG03NVNlbnNvclRhYmxlCisgICAgICAgICAgICAgICAgICAoMSBsbTc1U2Vuc29ySW5kZXggSU5U RUdFUjMyIEdFVCkKKyAgICAgICAgICAgICAgICAgICgyIGxtNzVTZW5zb3JTeXNjdGxJbmRleCBJ TlRFR0VSMzIgR0VUKQorICAgICAgICAgICAgICAgICAgKDMgbG03NVNlbnNvckRlc2MgT0NURVRT VFJJTkcgR0VUKQorICAgICAgICAgICAgICAgICAgKDQgbG03NVNlbnNvckxvY2F0aW9uIE9DVEVU U1RSSU5HIEdFVCkKKyAgICAgICAgICAgICAgICAgICg1IGxtNzVTZW5zb3JQbnBJbmZvIE9DVEVU U1RSSU5HIEdFVCkKKyAgICAgICAgICAgICAgICAgICg2IGxtNzVTZW5zb3JQYXJlbnQgT0NURVRT VFJJTkcgR0VUKQorICAgICAgICAgICAgICAgICAgKDcgbG03NVNlbnNvclRlbXBlcmF0dXJlIElO VEVHRVIzMiBHRVQpCisgICAgICAgICAgICAgICAgKQorICAgICAgICAgICAgICApCisgICAgICAg ICAgICApCisgICAgICAgICAgKQorICAgICAgICApCisgICAgICApCisgICAgKQorICApCispCklu ZGV4OiB1c3Iuc2Jpbi9ic25tcGQvbW9kdWxlcy9zbm1wX2xtNzUvc25tcF9sbTc1LjMKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQotLS0gdXNyLnNiaW4vYnNubXBkL21vZHVsZXMvc25tcF9sbTc1L3NubXBfbG03NS4zCShy ZXZpc2lvbiAwKQorKysgdXNyLnNiaW4vYnNubXBkL21vZHVsZXMvc25tcF9sbTc1L3NubXBfbG03 NS4zCSh3b3JraW5nIGNvcHkpCkBAIC0wLDAgKzEsNjAgQEAKKy5cIi0KKy5cIiBDb3B5cmlnaHQg KGMpIDIwMTQgTHVpeiBPdGF2aW8gTyBTb3V6YSA8bG9vc0BGcmVlQlNELm9yZz4KKy5cIiBBbGwg cmlnaHRzIHJlc2VydmVkLgorLlwiCisuXCIgUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3Vy Y2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0CisuXCIgbW9kaWZpY2F0aW9uLCBh cmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zCisuXCIg YXJlIG1ldDoKKy5cIiAxLiBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRh aW4gdGhlIGFib3ZlIGNvcHlyaWdodAorLlwiICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRp dGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4KKy5cIiAyLiBSZWRpc3RyaWJ1dGlv bnMgaW4gYmluYXJ5IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAorLlwi ICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlz Y2xhaW1lciBpbiB0aGUKKy5cIiAgICBkb2N1bWVudGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlh bHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9uLgorLlwiCisuXCIgVEhJUyBTT0ZUV0FS RSBJUyBQUk9WSURFRCBCWSBUSEUgUkVHRU5UUyBBTkQgQ09OVFJJQlVUT1JTIGBgQVMgSVMnJyBB TkQKKy5cIiBBTlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVU IE5PVCBMSU1JVEVEIFRPLCBUSEUKKy5cIiBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRB QklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRQorLlwiIEFSRSBESVND TEFJTUVELiAgSU4gTk8gRVZFTlQgU0hBTEwgVEhFIFJFR0VOVFMgT1IgQ09OVFJJQlVUT1JTIEJF IExJQUJMRQorLlwiIEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lB TCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMCisuXCIgREFNQUdFUyAoSU5DTFVESU5HLCBC VVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9GIFNVQlNUSVRVVEUgR09PRFMKKy5cIiBP UiBTRVJWSUNFUzsgTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNTIElO VEVSUlVQVElPTikKKy5cIiBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFC SUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVAorLlwiIExJQUJJTElUWSwgT1IgVE9S VCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBBUklTSU5HIElOIEFOWSBXQVkK Ky5cIiBPVVQgT0YgVEhFIFVTRSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0Yg VEhFIFBPU1NJQklMSVRZIE9GCisuXCIgU1VDSCBEQU1BR0UuCisuXCIKKy5cIiAkRnJlZUJTRCQK Ky5cIgorLkRkIEZlYnJ1YXJ5IDI0LCAyMDE0CisuRHQgU05NUF9MTTc1IDMKKy5PcworLlNoIE5B TUUKKy5ObSBzbm1wX2xtNzUKKy5OZCAiTE03NSBTZW5zb3IgbW9kdWxlIGZvciIKKy5YciBic25t cGQgMQorLlNoIExJQlJBUlkKKy5QcSBiZWdlbW90U25tcGRNb2R1bGVQYXRoLiJsbTc1IiA9ICIv dXNyL2xpYi9zbm1wX2xtNzUuc28iCisuU2ggREVTQ1JJUFRJT04KK1RoZQorLk5tIHNubXBfbG03 NQorbW9kdWxlIGltcGxlbWVudHMgYSBwcml2YXRlIEJFR0VNT1QtTE03NS1NSUIsIHdoaWNoIGFs bG93cworcmVhZGluZyB0aGUgdGVtcGVyYXR1cmUgb2YgdGhlIExNNzUgc2Vuc29ycyBvbiB0aGUg c3lzdGVtLgorLlBwCitUaGUgbW9kdWxlIHJlYWRzIHRoZSBzZW5zb3IocykgdGVtcGVyYXR1cmUg dXNpbmcgdGhlCisuWHIgc3lzY3RsIDgKK0FQSS4KKy5TaCBGSUxFUworLkJsIC10YWcgLXdpZHRo ICJYWFhYWFhYWFgiCisuSXQgUGEgL3Vzci9zaGFyZS9zbm1wL2RlZnMvbG03NV90cmVlLmRlZgor VGhlIGRlc2NyaXB0aW9uIG9mIHRoZSBNSUIgdHJlZSBpbXBsZW1lbnRlZCBieQorLk5tIC4KKy5J dCBQYSAvdXNyL3NoYXJlL3NubXAvbWlicy9CRUdFTU9ULUxNNzUtTUlCLnR4dAorVGhlIHByaXZh dGUgQkVHRU1PVC1MTTc1LU1JQiB0aGF0IGlzIGltcGxlbWVudGVkIGJ5IHRoaXMgbW9kdWxlLgor LkVsCisuU2ggU0VFIEFMU08KKy5YciBic25tcGQgMSAsCisuWHIgZ2Vuc25tcHRyZWUgMSAsCisu WHIgc25tcG1vZCAzICwKKy5YciBsbTc1IDQKKy5TaCBBVVRIT1JTCisuQW4gTHVpeiBPdGF2aW8g TyBTb3V6YSBBcSBsb29zQEZyZWVCU0Qub3JnCgpQcm9wZXJ0eSBjaGFuZ2VzIG9uOiB1c3Iuc2Jp bi9ic25tcGQvbW9kdWxlcy9zbm1wX2xtNzUvc25tcF9sbTc1LjMKX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpBZGRlZDog c3ZuOmVvbC1zdHlsZQojIyAtMCwwICsxICMjCituYXRpdmUKXCBObyBuZXdsaW5lIGF0IGVuZCBv ZiBwcm9wZXJ0eQpBZGRlZDogc3ZuOm1pbWUtdHlwZQojIyAtMCwwICsxICMjCit0ZXh0L3BsYWlu ClwgTm8gbmV3bGluZSBhdCBlbmQgb2YgcHJvcGVydHkKQWRkZWQ6IHN2bjprZXl3b3JkcwojIyAt MCwwICsxICMjCitGcmVlQlNEPSVIClwgTm8gbmV3bGluZSBhdCBlbmQgb2YgcHJvcGVydHkKSW5k ZXg6IHVzci5zYmluL2Jzbm1wZC9tb2R1bGVzL3NubXBfbG03NS9zbm1wX2xtNzUuYwo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09Ci0tLSB1c3Iuc2Jpbi9ic25tcGQvbW9kdWxlcy9zbm1wX2xtNzUvc25tcF9sbTc1LmMJKHJl dmlzaW9uIDApCisrKyB1c3Iuc2Jpbi9ic25tcGQvbW9kdWxlcy9zbm1wX2xtNzUvc25tcF9sbTc1 LmMJKHdvcmtpbmcgY29weSkKQEAgLTAsMCArMSw0MzYgQEAKKy8qLQorICogQ29weXJpZ2h0IChj KSAyMDE0IEx1aXogT3RhdmlvIE8gU291emEgPGxvb3NARnJlZUJTRC5vcmc+CisgKiBBbGwgcmln aHRzIHJlc2VydmVkLgorICoKKyAqIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFu ZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAorICogbW9kaWZpY2F0aW9uLCBhcmUgcGVy bWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zCisgKiBhcmUgbWV0 OgorICogMS4gUmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBh Ym92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5k IHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4KKyAqIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5h cnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2Us IHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgaW4g dGhlCisgKiAgICBkb2N1bWVudGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQg d2l0aCB0aGUgZGlzdHJpYnV0aW9uLgorICoKKyAqIFRISVMgU09GVFdBUkUgSVMgUFJPVklERUQg QlkgVEhFIFJFR0VOVFMgQU5EIENPTlRSSUJVVE9SUyBgYEFTIElTJycgQU5ECisgKiBBTlkgRVhQ UkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRP LCBUSEUKKyAqIElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5F U1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFCisgKiBBUkUgRElTQ0xBSU1FRC4gIElOIE5PIEVW RU5UIFNIQUxMIFRIRSBSRUdFTlRTIE9SIENPTlRSSUJVVE9SUyBCRSBMSUFCTEUKKyAqIEZPUiBB TlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUiBD T05TRVFVRU5USUFMCisgKiBEQU1BR0VTIChJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywg UFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVURSBHT09EUworICogT1IgU0VSVklDRVM7IExPU1MgT0Yg VVNFLCBEQVRBLCBPUiBQUk9GSVRTOyBPUiBCVVNJTkVTUyBJTlRFUlJVUFRJT04pCisgKiBIT1dF VkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQ09O VFJBQ1QsIFNUUklDVAorICogTElBQklMSVRZLCBPUiBUT1JUIChJTkNMVURJTkcgTkVHTElHRU5D RSBPUiBPVEhFUldJU0UpIEFSSVNJTkcgSU4gQU5ZIFdBWQorICogT1VUIE9GIFRIRSBVU0UgT0Yg VEhJUyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElUWSBPRgorICog U1VDSCBEQU1BR0UuCisgKi8KKworI2luY2x1ZGUgPHN5cy9jZGVmcy5oPgorX19GQlNESUQoIiRG cmVlQlNEJCIpOworCisjaW5jbHVkZSA8c3lzL3BhcmFtLmg+CisjaW5jbHVkZSA8c3lzL3F1ZXVl Lmg+CisjaW5jbHVkZSA8c3lzL3N5c2N0bC5oPgorCisjaW5jbHVkZSA8YnNubXAvc25tcG1vZC5o PgorCisjaW5jbHVkZSA8c3RkaW8uaD4KKyNpbmNsdWRlIDxzdGRsaWIuaD4KKyNpbmNsdWRlIDxz dHJpbmcuaD4KKyNpbmNsdWRlIDxzeXNsb2cuaD4KKworI2luY2x1ZGUgImxtNzVfb2lkLmgiCisj aW5jbHVkZSAibG03NV90cmVlLmgiCisKKyNpZm5kZWYJTE03NUJVRgorI2RlZmluZQlMTTc1QlVG CQk2NAorI2VuZGlmCisjZGVmaW5lCVRaX1pFUk9DCTI3MzIKKyNkZWZpbmUgVVBEQVRFX0lOVEVS VkFMCTUwMAkvKiB1cGRhdGUgaW50ZXJ2YWwgaW4gdGlja3MgKi8KKworc3RhdGljIHN0cnVjdCBs bW9kdWxlICptb2R1bGU7CisKK3N0YXRpYyBjb25zdCBzdHJ1Y3QgYXNuX29pZCBvaWRfbG03NSA9 IE9JRFhfYmVnZW1vdExtNzU7CisKKy8qIHRoZSBPYmplY3QgUmVzb3VyY2UgcmVnaXN0cmF0aW9u IGluZGV4ICovCitzdGF0aWMgdV9pbnQgbG03NV9pbmRleCA9IDA7CisKKy8qIE51bWJlciBvZiBh dmFpbGFibGUgc2Vuc29ycyBpbiB0aGUgc3lzdGVtLiAqLworc3RhdGljIGludCBsbTc1X3NlbnNv cnM7CisKKy8qCisgKiBTdHJ1Y3R1cmUgdGhhdCBkZXNjcmliZXMgc2luZ2xlIHNlbnNvci4KKyAq Lworc3RydWN0IGxtNzVfc25tcF9zZW5zb3IgeworCVRBSUxRX0VOVFJZKGxtNzVfc25tcF9zZW5z b3IpIGxpbms7CisJaW50MzJfdAkJaW5kZXg7CisJaW50MzJfdAkJc3lzY3RsaWR4OworCWludDMy X3QJCXRlbXA7CisJY2hhcgkJZGVzY1tMTTc1QlVGXTsKKwljaGFyCQlsb2NhdGlvbltMTTc1QlVG XTsKKwljaGFyCQlwYXJlbnRbTE03NUJVRl07CisJY2hhcgkJcG5waW5mb1tMTTc1QlVGXTsKK307 CisKK3N0YXRpYyBUQUlMUV9IRUFEKCwgbG03NV9zbm1wX3NlbnNvcikgc2Vuc29ycyA9CisgICAg VEFJTFFfSEVBRF9JTklUSUFMSVpFUihzZW5zb3JzKTsKKworLyogVGlja3Mgb2YgdGhlIGxhc3Qg c2Vuc29ycyByZWFkaW5nLiAqLworc3RhdGljIHVpbnQ2NF90IGxhc3Rfc2Vuc29yc191cGRhdGU7 CisKK3N0YXRpYyB2b2lkIGZyZWVfc2Vuc29ycyh2b2lkKTsKK3N0YXRpYyBpbnQgbG03NV9maW5p KHZvaWQpOworc3RhdGljIGludCBsbTc1X2luaXQoc3RydWN0IGxtb2R1bGUgKm1vZCwgaW50IGFy Z2MsIGNoYXIgKmFyZ3ZbXSk7CitzdGF0aWMgdm9pZCBsbTc1X3N0YXJ0KHZvaWQpOworc3RhdGlj IGludCB1cGRhdGVfc2Vuc29ycyh2b2lkKTsKKworY29uc3Qgc3RydWN0IHNubXBfbW9kdWxlIGNv bmZpZyA9IHsKKyAgICAuY29tbWVudCAgID0KKwkiVGhpcyBtb2R1bGUgaW1wbGVtZW50cyB0aGUg QkVHRU1PVCBNSUIgZm9yIHJlYWRpbmcgTE03NSBzZW5zb3JzIGRhdGEuIiwKKyAgICAuaW5pdCAg ICAgID0gbG03NV9pbml0LAorICAgIC5zdGFydCAgICAgPSBsbTc1X3N0YXJ0LAorICAgIC5maW5p ICAgICAgPSBsbTc1X2ZpbmksCisgICAgLnRyZWUgICAgICA9IGxtNzVfY3RyZWUsCisgICAgLnRy ZWVfc2l6ZSA9IGxtNzVfQ1RSRUVfU0laRSwKK307CisKK3N0YXRpYyBpbnQKK2xtNzVfaW5pdChz dHJ1Y3QgbG1vZHVsZSAqbW9kLCBpbnQgYXJnYyBfX3VudXNlZCwgY2hhciAqYXJndltdIF9fdW51 c2VkKQoreworCisJbW9kdWxlID0gbW9kOworCisJbG03NV9zZW5zb3JzID0gMDsKKwlvcGVubG9n KCJzbm1wX2xtNzUiLCBMT0dfTkRFTEFZIHwgTE9HX1BJRCwgTE9HX0RBRU1PTik7CisKKwlyZXR1 cm4oMCk7Cit9CisKK3N0YXRpYyB2b2lkCitsbTc1X3N0YXJ0KHZvaWQpCit7CisKKwlsbTc1X2lu ZGV4ID0gb3JfcmVnaXN0ZXIoJm9pZF9sbTc1LAorCSAgICAiVGhlIE1JQiBtb2R1bGUgZm9yIHJl YWRpbmcgbG03NSBzZW5zb3JzIGRhdGEuIiwgbW9kdWxlKTsKK30KKworc3RhdGljIGludAorbG03 NV9maW5pKHZvaWQpCit7CisKKwlvcl91bnJlZ2lzdGVyKGxtNzVfaW5kZXgpOworCWZyZWVfc2Vu c29ycygpOworCWNsb3NlbG9nKCk7CisKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgdm9pZAor ZnJlZV9zZW5zb3JzKHZvaWQpCit7CisJc3RydWN0IGxtNzVfc25tcF9zZW5zb3IgKnNlbnNvcjsK KworCXdoaWxlICgoc2Vuc29yID0gVEFJTFFfRklSU1QoJnNlbnNvcnMpKSAhPSBOVUxMKSB7CisJ CVRBSUxRX1JFTU9WRSgmc2Vuc29ycywgc2Vuc29yLCBsaW5rKTsKKwkJZnJlZShzZW5zb3IpOwor CX0KK30KKworc3RhdGljIGludAorc3lzY3RsbmFtZShpbnQgKm9pZCwgaW50IG5sZW4sIGNoYXIg Km5hbWUsIHNpemVfdCBsZW4pCit7CisJaW50IG1pYlsxMl07CisKKwlpZiAobmxlbiA+IChpbnQp c2l6ZW9mKG1pYikgKyAyKQorCQlyZXR1cm4gKC0xKTsKKworCW1pYlswXSA9IDA7CisJbWliWzFd ID0gMTsKKwltZW1jcHkobWliICsgMiwgb2lkLCBubGVuICogc2l6ZW9mKGludCkpOworCisJaWYg KHN5c2N0bChtaWIsIG5sZW4gKyAyLCBuYW1lLCAmbGVuLCAwLCAwKSA9PSAtMSkKKwkJcmV0dXJu ICgtMSk7CisKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgaW50CitzeXNjdGxnZXRuZXh0KGlu dCAqb2lkLCBpbnQgbmxlbiwgaW50ICpuZXh0LCBzaXplX3QgKm5leHRsZW4pCit7CisJaW50IG1p YlsxMl07CisKKwlpZiAobmxlbiAgPiAoaW50KXNpemVvZihtaWIpICsgMikKKwkJcmV0dXJuICgt MSk7CisKKwltaWJbMF0gPSAwOworCW1pYlsxXSA9IDI7CisJbWVtY3B5KG1pYiArIDIsIG9pZCwg bmxlbiAqIHNpemVvZihpbnQpKTsKKworCWlmIChzeXNjdGwobWliLCBubGVuICsgMiwgbmV4dCwg bmV4dGxlbiwgMCwgMCkgPT0gLTEpCisJCXJldHVybiAoLTEpOworCisJcmV0dXJuICgwKTsKK30K Kworc3RhdGljIGludAordXBkYXRlX3NlbnNvcl9zeXNjdGwoY2hhciAqb2J1Ziwgc2l6ZV90ICpv YnVmbGVuLCBpbnQgaWR4LCBjb25zdCBjaGFyICpuYW1lKQoreworCWNoYXIgYnVmW0xNNzVCVUZd OworCWludCBtaWJbNV07CisJc2l6ZV90IGxlbjsKKworCS8qIEZpbGwgb3V0IHRoZSBtaWIgaW5m b3JtYXRpb24uICovCisJc25wcmludGYoYnVmLCBzaXplb2YoYnVmKSAtIDEsICJkZXYubG03NS4l ZC4lcyIsIGlkeCwgbmFtZSk7CisJbGVuID0gNDsKKwlpZiAoc3lzY3RsbmFtZXRvbWliKGJ1Ziwg bWliLCAmbGVuKSA9PSAtMSkKKwkJcmV0dXJuICgtMSk7CisKKwkvKiBSZWFkIHRoZSBzeXNjdGwg ZGF0YS4gKi8KKwlpZiAoc3lzY3RsKG1pYiwgbGVuLCBvYnVmLCBvYnVmbGVuLCBOVUxMLCAwKSA9 PSAtMSkKKwkJcmV0dXJuICgtMSk7CisKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgdm9pZAor dXBkYXRlX3NlbnNvcihzdHJ1Y3QgbG03NV9zbm1wX3NlbnNvciAqc2Vuc29yLCBpbnQgaWR4KQor eworCXNpemVfdCBsZW47CisKKwlsZW4gPSBzaXplb2Yoc2Vuc29yLT5kZXNjKTsKKwl1cGRhdGVf c2Vuc29yX3N5c2N0bChzZW5zb3ItPmRlc2MsICZsZW4sIGlkeCwgIiVkZXNjIik7CisKKwlsZW4g PSBzaXplb2Yoc2Vuc29yLT5sb2NhdGlvbik7CisJdXBkYXRlX3NlbnNvcl9zeXNjdGwoc2Vuc29y LT5sb2NhdGlvbiwgJmxlbiwgaWR4LCAiJWxvY2F0aW9uIik7CisKKwlsZW4gPSBzaXplb2Yoc2Vu c29yLT5wbnBpbmZvKTsKKwl1cGRhdGVfc2Vuc29yX3N5c2N0bChzZW5zb3ItPnBucGluZm8sICZs ZW4sIGlkeCwgIiVwbnBpbmZvIik7CisKKwlsZW4gPSBzaXplb2Yoc2Vuc29yLT5wYXJlbnQpOwor CXVwZGF0ZV9zZW5zb3Jfc3lzY3RsKHNlbnNvci0+cGFyZW50LCAmbGVuLCBpZHgsICIlcGFyZW50 Iik7Cit9CisKK3N0YXRpYyBpbnQKK2FkZF9zZW5zb3IoY2hhciAqYnVmLCBzaXplX3QgbmxlbikK K3sKKwlpbnQgaWR4LCBtaWJbNV0sIHRlbXA7CisJc2l6ZV90IGxlbjsKKwlzdHJ1Y3QgbG03NV9z bm1wX3NlbnNvciAqc2Vuc29yOworCisJaWYgKHNzY2FuZihidWYsICJkZXYubG03NS4lZC50ZW1w ZXJhdHVyZSIsICZpZHgpICE9IDEpCisJCXJldHVybiAoLTEpOworCisJLyogRmlsbCBvdXQgdGhl IG1pYiBpbmZvcm1hdGlvbi4gKi8KKwlpZiAoc3lzY3RsbmFtZXRvbWliKGJ1ZiwgbWliLCAmbmxl bikgPT0gLTEpCisJCXJldHVybiAoLTEpOworCisJLyogUmVhZCB0aGUgc2Vuc29yIHRlbXBlcmF0 dXJlLiAqLworCWxlbiA9IHNpemVvZih0ZW1wKTsKKwlpZiAoc3lzY3RsKG1pYiwgbmxlbiwgJnRl bXAsICZsZW4sIE5VTEwsIDApID09IC0xKQorCQlyZXR1cm4gKC0xKTsKKworCS8qIEFkZCB0aGUg c2Vuc29yIGRhdGEgdG8gdGhlIHRhYmxlLiAqLworCXNlbnNvciA9IGNhbGxvYygxLCBzaXplb2Yo KnNlbnNvcikpOworCWlmIChzZW5zb3IgPT0gTlVMTCkgeworCQlzeXNsb2coTE9HX0VSUiwgIlVu YWJsZSB0byBhbGxvY2F0ZSAlenUgYnl0ZXMgZm9yIHJlc291cmNlIiwKKwkJICAgIHNpemVvZigq c2Vuc29yKSk7CisJCXJldHVybiAoLTEpOworCX0KKwlzZW5zb3ItPmluZGV4ID0gKytsbTc1X3Nl bnNvcnM7CisJc2Vuc29yLT5zeXNjdGxpZHggPSBpZHg7CisJc2Vuc29yLT50ZW1wID0gKHRlbXAg LSBUWl9aRVJPQykgLyAxMDsKKwlUQUlMUV9JTlNFUlRfVEFJTCgmc2Vuc29ycywgc2Vuc29yLCBs aW5rKTsKKworCXVwZGF0ZV9zZW5zb3Ioc2Vuc29yLCBpZHgpOworCisJcmV0dXJuICgwKTsKK30K Kworc3RhdGljIGludAordXBkYXRlX3NlbnNvcnModm9pZCkKK3sKKwljaGFyIGJ1ZltMTTc1QlVG XTsKKwlpbnQgaSwgcm9vdFs1XSwgKm5leHQsICpvaWQ7CisJc2l6ZV90IGxlbiwgbmV4dGxlbiwg cm9vdGxlbjsKKwlzdGF0aWMgdWludDY0X3Qgbm93OworCisJbm93ID0gZ2V0X3RpY2tzKCk7CisJ aWYgKG5vdyAtIGxhc3Rfc2Vuc29yc191cGRhdGUgPCBVUERBVEVfSU5URVJWQUwpCisJCXJldHVy biAoMCk7CisKKwlsYXN0X3NlbnNvcnNfdXBkYXRlID0gbm93OworCisJLyogUmVzZXQgdGhlIHNl bnNvciBkYXRhLiAqLworCWZyZWVfc2Vuc29ycygpOworCWxtNzVfc2Vuc29ycyA9IDA7CisKKwkv KiBTdGFydCBmcm9tIHRoZSBsbTc1IGRlZmF1bHQgcm9vdCBub2RlLiAqLworCXJvb3RsZW4gPSAy OworCWlmIChzeXNjdGxuYW1ldG9taWIoImRldi5sbTc1Iiwgcm9vdCwgJnJvb3RsZW4pID09IC0x KQorCQlyZXR1cm4gKDApOworCisJb2lkID0gKGludCAqKW1hbGxvYyhzaXplb2YoaW50KSAqIHJv b3RsZW4pOworCWlmIChvaWQgPT0gTlVMTCkgeworCQlwZXJyb3IoIm1hbGxvYyIpOworCQlyZXR1 cm4gKC0xKTsKKwl9CisJbWVtY3B5KG9pZCwgcm9vdCwgcm9vdGxlbiAqIHNpemVvZihpbnQpKTsK KwlsZW4gPSByb290bGVuOworCisJLyogVHJhdmVyc2UgdGhlIHN5c2N0bCgzKSBpbnRlcmZhY2Ug YW5kIGZpbmQgdGhlIGFjdGl2ZSBzZW5zb3JzLiAqLworCWZvciAoOzspIHsKKworCQkvKiBGaW5k IHRoZSBzaXplIG9mIHRoZSBuZXh0IG1pYi4gKi8KKwkJbmV4dGxlbiA9IDA7CisJCWlmIChzeXNj dGxnZXRuZXh0KG9pZCwgbGVuLCBOVUxMLCAmbmV4dGxlbikgPT0gLTEpIHsKKwkJCWZyZWUob2lk KTsKKwkJCXJldHVybiAoMCk7CisJCX0KKwkJLyogQWxvY2F0ZSBhbmQgcmVhZCB0aGUgbmV4dCBt aWIuICovCisJCW5leHQgPSAoaW50ICopbWFsbG9jKG5leHRsZW4pOworCQlpZiAobmV4dCA9PSBO VUxMKSB7CisJCQlzeXNsb2coTE9HX0VSUiwKKwkJCSAgICAiVW5hYmxlIHRvIGFsbG9jYXRlICV6 dSBieXRlcyBmb3IgcmVzb3VyY2UiLAorCQkJICAgIG5leHRsZW4pOworCQkJZnJlZShvaWQpOwor CQkJcmV0dXJuICgtMSk7CisJCX0KKwkJaWYgKHN5c2N0bGdldG5leHQob2lkLCBsZW4sIG5leHQs ICZuZXh0bGVuKSA9PSAtMSkgeworCQkJZnJlZShvaWQpOworCQkJZnJlZShuZXh0KTsKKwkJCXJl dHVybiAoMCk7CisJCX0KKwkJZnJlZShvaWQpOworCQkvKiBDaGVjayBpZiB3ZSBjYXJlIGFib3V0 IHRoZSBuZXh0IG1pYi4gKi8KKwkJZm9yIChpID0gMDsgaSA8IChpbnQpcm9vdGxlbjsgaSsrKQor CQkJaWYgKG5leHRbaV0gIT0gcm9vdFtpXSkgeworCQkJCWZyZWUobmV4dCk7CisJCQkJcmV0dXJu ICgwKTsKKwkJCX0KKwkJb2lkID0gKGludCAqKW1hbGxvYyhuZXh0bGVuKTsKKwkJaWYgKG9pZCA9 PSBOVUxMKSB7CisJCQlzeXNsb2coTE9HX0VSUiwKKwkJCSAgICAiVW5hYmxlIHRvIGFsbG9jYXRl ICV6dSBieXRlcyBmb3IgcmVzb3VyY2UiLAorCQkJICAgIG5leHRsZW4pOworCQkJZnJlZShuZXh0 KTsKKwkJCXJldHVybiAoLTEpOworCQl9CisJCW1lbWNweShvaWQsIG5leHQsIG5leHRsZW4pOwor CQlmcmVlKG5leHQpOworCQlsZW4gPSBuZXh0bGVuIC8gc2l6ZW9mKGludCk7CisKKwkJLyogRmlu ZCB0aGUgbWliIG5hbWUuICovCisJCWlmIChzeXNjdGxuYW1lKG9pZCwgbGVuLCBidWYsIHNpemVv ZihidWYpKSAhPSAwKQorCQkJY29udGludWU7CisKKwkJaWYgKHN0cnN0cihidWYsICJ0ZW1wZXJh dHVyZSIpKQorCQkJaWYgKGFkZF9zZW5zb3IoYnVmLCBsZW4pICE9IDApIHsKKwkJCQlmcmVlKG9p ZCk7CisJCQkJcmV0dXJuICgtMSk7CisJCQl9CisJfQorCisJcmV0dXJuICgwKTsKK30KKworaW50 CitvcF9sbTc1U2Vuc29ycyhzdHJ1Y3Qgc25tcF9jb250ZXh0ICpjb250ZXh0IF9fdW51c2VkLCBz dHJ1Y3Qgc25tcF92YWx1ZSAqdmFsdWUsCisgICAgdV9pbnQgc3ViLCB1X2ludCBpaWR4IF9fdW51 c2VkLCBlbnVtIHNubXBfb3Agb3ApCit7CisJYXNuX3N1YmlkX3Qgd2hpY2g7CisKKwlpZiAodXBk YXRlX3NlbnNvcnMoKSA9PSAtMSkKKwkJcmV0dXJuIChTTk1QX0VSUl9SRVNfVU5BVkFJTCk7CisK Kwl3aGljaCA9IHZhbHVlLT52YXIuc3Vic1tzdWIgLSAxXTsKKworCXN3aXRjaCAob3ApIHsKKwlj YXNlIFNOTVBfT1BfR0VUOgorCQlzd2l0Y2ggKHdoaWNoKSB7CisJCWNhc2UgTEVBRl9sbTc1U2Vu c29yczoKKwkJCXZhbHVlLT52LmludGVnZXIgPSBsbTc1X3NlbnNvcnM7CisJCQlicmVhazsKKwkJ ZGVmYXVsdDoKKwkJCXJldHVybiAoU05NUF9FUlJfUkVTX1VOQVZBSUwpOworCQl9CisJCWJyZWFr OworCWNhc2UgU05NUF9PUF9TRVQ6CisJCXJldHVybiAoU05NUF9FUlJfTk9UX1dSSVRFQUJMRSk7 CisJY2FzZSBTTk1QX09QX0dFVE5FWFQ6CisJY2FzZSBTTk1QX09QX1JPTExCQUNLOgorCWNhc2Ug U05NUF9PUF9DT01NSVQ6CisJCXJldHVybiAoU05NUF9FUlJfTk9FUlJPUik7CisJZGVmYXVsdDoK KwkJcmV0dXJuIChTTk1QX0VSUl9SRVNfVU5BVkFJTCk7CisJfQorCisJcmV0dXJuIChTTk1QX0VS Ul9OT0VSUk9SKTsKK30KKworaW50CitvcF9sbTc1U2Vuc29yVGFibGUoc3RydWN0IHNubXBfY29u dGV4dCAqY29udGV4dCBfX3VudXNlZCwKKyAgICBzdHJ1Y3Qgc25tcF92YWx1ZSAqdmFsdWUsIHVf aW50IHN1YiwgdV9pbnQgaWlkeCBfX3VudXNlZCwgZW51bSBzbm1wX29wIG9wKQoreworCXN0cnVj dCBsbTc1X3NubXBfc2Vuc29yICpzZW5zb3I7CisJYXNuX3N1YmlkX3Qgd2hpY2g7CisJaW50IHJl dDsKKworCWlmICh1cGRhdGVfc2Vuc29ycygpID09IC0xKQorCQlyZXR1cm4gKFNOTVBfRVJSX1JF U19VTkFWQUlMKTsKKworCXdoaWNoID0gdmFsdWUtPnZhci5zdWJzW3N1YiAtIDFdOworCisJc3dp dGNoIChvcCkgeworCWNhc2UgU05NUF9PUF9HRVRORVhUOgorCQlzZW5zb3IgPSBORVhUX09CSkVD VF9JTlQoJnNlbnNvcnMsICZ2YWx1ZS0+dmFyLCBzdWIpOworCQlpZiAoc2Vuc29yID09IE5VTEwp CisJCQlyZXR1cm4gKFNOTVBfRVJSX05PU1VDSE5BTUUpOworCQl2YWx1ZS0+dmFyLmxlbiA9IHN1 YiArIDE7CisJCXZhbHVlLT52YXIuc3Vic1tzdWJdID0gc2Vuc29yLT5pbmRleDsKKwkJYnJlYWs7 CisJY2FzZSBTTk1QX09QX0dFVDoKKwkJaWYgKHZhbHVlLT52YXIubGVuIC0gc3ViICE9IDEpCisJ CQlyZXR1cm4gKFNOTVBfRVJSX05PU1VDSE5BTUUpOworCQlzZW5zb3IgPSBGSU5EX09CSkVDVF9J TlQoJnNlbnNvcnMsICZ2YWx1ZS0+dmFyLCBzdWIpOworCQlpZiAoc2Vuc29yID09IE5VTEwpCisJ CQlyZXR1cm4gKFNOTVBfRVJSX05PU1VDSE5BTUUpOworCQlicmVhazsKKwljYXNlIFNOTVBfT1Bf U0VUOgorCQlyZXR1cm4gKFNOTVBfRVJSX05PVF9XUklURUFCTEUpOworCWNhc2UgU05NUF9PUF9S T0xMQkFDSzoKKwljYXNlIFNOTVBfT1BfQ09NTUlUOgorCQlyZXR1cm4gKFNOTVBfRVJSX05PRVJS T1IpOworCWRlZmF1bHQ6CisJCXJldHVybiAoU05NUF9FUlJfUkVTX1VOQVZBSUwpOworCX0KKwor CXJldCA9IFNOTVBfRVJSX05PRVJST1I7CisKKwlzd2l0Y2ggKHdoaWNoKSB7CisJY2FzZSBMRUFG X2xtNzVTZW5zb3JJbmRleDoKKwkJdmFsdWUtPnYuaW50ZWdlciA9IHNlbnNvci0+aW5kZXg7CisJ CWJyZWFrOworCWNhc2UgTEVBRl9sbTc1U2Vuc29yU3lzY3RsSW5kZXg6CisJCXZhbHVlLT52Lmlu dGVnZXIgPSBzZW5zb3ItPnN5c2N0bGlkeDsKKwkJYnJlYWs7CisJY2FzZSBMRUFGX2xtNzVTZW5z b3JEZXNjOgorCQlyZXQgPSBzdHJpbmdfZ2V0KHZhbHVlLCBzZW5zb3ItPmRlc2MsIC0xKTsKKwkJ YnJlYWs7CisJY2FzZSBMRUFGX2xtNzVTZW5zb3JMb2NhdGlvbjoKKwkJcmV0ID0gc3RyaW5nX2dl dCh2YWx1ZSwgc2Vuc29yLT5sb2NhdGlvbiwgLTEpOworCQlicmVhazsKKwljYXNlIExFQUZfbG03 NVNlbnNvclBucEluZm86CisJCXJldCA9IHN0cmluZ19nZXQodmFsdWUsIHNlbnNvci0+cG5waW5m bywgLTEpOworCQlicmVhazsKKwljYXNlIExFQUZfbG03NVNlbnNvclBhcmVudDoKKwkJcmV0ID0g c3RyaW5nX2dldCh2YWx1ZSwgc2Vuc29yLT5wYXJlbnQsIC0xKTsKKwkJYnJlYWs7CisJY2FzZSBM RUFGX2xtNzVTZW5zb3JUZW1wZXJhdHVyZToKKwkJdmFsdWUtPnYuaW50ZWdlciA9IHNlbnNvci0+ dGVtcDsKKwkJYnJlYWs7CisJZGVmYXVsdDoKKwkJcmV0ID0gU05NUF9FUlJfUkVTX1VOQVZBSUw7 CisJCWJyZWFrOworCX0KKworCXJldHVybiAocmV0KTsKK30KClByb3BlcnR5IGNoYW5nZXMgb246 IHVzci5zYmluL2Jzbm1wZC9tb2R1bGVzL3NubXBfbG03NS9zbm1wX2xtNzUuYwpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f CkFkZGVkOiBzdm46ZW9sLXN0eWxlCiMjIC0wLDAgKzEgIyMKK25hdGl2ZQpcIE5vIG5ld2xpbmUg YXQgZW5kIG9mIHByb3BlcnR5CkFkZGVkOiBzdm46bWltZS10eXBlCiMjIC0wLDAgKzEgIyMKK3Rl eHQvcGxhaW4KXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBwcm9wZXJ0eQpBZGRlZDogc3ZuOmtleXdv cmRzCiMjIC0wLDAgKzEgIyMKK0ZyZWVCU0Q9JUgKXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBwcm9w ZXJ0eQo= --bcaec53d5eb583d78b04f409aa66-- From owner-freebsd-embedded@FreeBSD.ORG Mon Mar 10 11:06:42 2014 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9B90FF6 for ; Mon, 10 Mar 2014 11:06:42 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A6544800 for ; Mon, 10 Mar 2014 11:06:42 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s2AB6grg043141 for ; Mon, 10 Mar 2014 11:06:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s2AB6giw043139 for freebsd-embedded@FreeBSD.org; Mon, 10 Mar 2014 11:06:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 10 Mar 2014 11:06:42 GMT Message-Id: <201403101106.s2AB6giw043139@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-embedded@FreeBSD.org Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 11:06:42 -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 misc/52256 embedded [picobsd] picobsd build script does not read in user/s o kern/42728 embedded [picobsd] many problems in src/usr.sbin/ppp/* after c 2 problems total. From owner-freebsd-embedded@FreeBSD.ORG Mon Mar 10 17:50:21 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 89D3A362 for ; Mon, 10 Mar 2014 17:50:21 +0000 (UTC) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EAB1E91E for ; Mon, 10 Mar 2014 17:50:20 +0000 (UTC) Received: by mail-we0-f175.google.com with SMTP id q58so8949185wes.20 for ; Mon, 10 Mar 2014 10:50:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=LqMHhqRnbOnv8ZwDd/3SrDB6i8lqen6+UGrJWoTLXm8=; b=XcHbuiUUaZyNk3GuJnnml80jUhHtNGhRUYYB/CNaUz7tbaoNW6zjAAc0Wxnb7b8T8p kcqqDc0xpdGxd74n9mrfyDg41xH8k6ok6d8pW4wJWf9zUmb2wTgPLXHq3NjnFiGpWbAa Z34uc7p768x6IPjzIsUi0/ZTbj4ofEzr8RmG4l2HMhPZE6J20Qm67OzRuiZbcFjx6uEi P8nsp1sm0OxKEP0jWJUtYrB3cgMeOm2PpVhIkHLbVvecaUJotPfrwf4/Wz8cgYDdl7fv PJzqCDt+E/Jr2mHkfvKDUEXwZ+Hq9BcQ2g5WvsCfRR4oduHNmVbMBPqOB/vEr9ZAMBug 7+Vg== MIME-Version: 1.0 X-Received: by 10.194.203.200 with SMTP id ks8mr2878977wjc.61.1394473819386; Mon, 10 Mar 2014 10:50:19 -0700 (PDT) Received: by 10.216.79.132 with HTTP; Mon, 10 Mar 2014 10:50:18 -0700 (PDT) In-Reply-To: <69CF7423-FD5B-44B3-8B90-E76BA96BB31A@gmail.com> References: <69CF7423-FD5B-44B3-8B90-E76BA96BB31A@gmail.com> Date: Mon, 10 Mar 2014 14:50:18 -0300 Message-ID: Subject: Re: [patch] LM75 kernel driver From: Luiz Otavio O Souza To: "freebsd-embedded@freebsd.org" Content-Type: multipart/mixed; boundary=047d7bb70ae4a7569804f4443c0b X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 17:50:21 -0000 --047d7bb70ae4a7569804f4443c0b Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 29, 2013 at 5:28 PM, Luiz Otavio O Souza wrote: > Hi, > > I've written a kernel driver for lm75 (i2c temperature sensor). > > It's a very simple, convenient and cheap way to verify an i2c bus. > > This driver provides full control of the lm75 registers (configuration bits, over temperature and hysteresis settings) and so provides basic read and write test abilities. > > The high resolution version (lm75b - 11 bits) isn't supported ATM, but i have plans to do so. The high resolution version (lm75[a/b]) is now tested and supported. This new version is tested on RSPRO (with gpioiic(4)), on BBB and RPi using both, gpioiic(4) and embedded i2c controllers. It can be used together with snmp_lm75 (http://lists.freebsd.org/pipermail/freebsd-embedded/2014-March/002281.html) to export the lm75 temperature via SNMP, it's use is quite straightforward. The updated version is attached. Luiz > > On my RPi i've added this to sys/boot/fdt/dts/rpi.dts: > > bsc0 { > > lm750 { > compatible = "lm75"; > i2c-address = <0x96>; > }; > > lm751 { > compatible = "lm75"; > i2c-address = <0x9e>; > }; > }; > > And 'device lm75' to RPI-B kernel file (after apply the attached patch). > > Here is the result: > > iichb0: mem 0x20205000-0x2020501f irq 61 on simplebus0 > iicbus1: on iichb0 > iic1: on iicbus1 > lm751: at addr 0x96 on iicbus1 > lm752: at addr 0x9e on iicbus1 > > # sysctl dev.lm75.1 > dev.lm75.1.%desc: LM75 temperature sensor > dev.lm75.1.%driver: lm75 > dev.lm75.1.%location: addr=0x96 > dev.lm75.1.%pnpinfo: name=lm750 compat=lm75 > dev.lm75.1.%parent: iicbus1 > dev.lm75.1.temperature: 30.0C > dev.lm75.1.thyst: 75.0C > dev.lm75.1.tos: 80.0C > dev.lm75.1.conf.faults: 1 > dev.lm75.1.conf.mode: comparator > dev.lm75.1.conf.polarity: active-low > dev.lm75.1.conf.shutdown: 0 > > # sysctl dev.lm75.2 > dev.lm75.2.%desc: LM75 temperature sensor > dev.lm75.2.%driver: lm75 > dev.lm75.2.%location: addr=0x9e > dev.lm75.2.%pnpinfo: name=lm751 compat=lm75 > dev.lm75.2.%parent: iicbus1 > dev.lm75.2.temperature: 29.5C > dev.lm75.2.thyst: 60.0C > dev.lm75.2.tos: 80.0C > dev.lm75.2.conf.faults: 2 > dev.lm75.2.conf.mode: interrupt > dev.lm75.2.conf.polarity: active-low > dev.lm75.2.conf.shutdown: 0 > > > I hope this may be useful for someone else. > > Luiz > > --047d7bb70ae4a7569804f4443c0b Content-Type: text/plain; charset=US-ASCII; name="lm75.diff" Content-Disposition: attachment; filename="lm75.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hsm1mtdq1 SW5kZXg6IHN5cy9jb25mL2ZpbGVzCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9jb25mL2ZpbGVzCShyZXZp c2lvbiAyNjI4NjApCisrKyBzeXMvY29uZi9maWxlcwkod29ya2luZyBjb3B5KQpAQCAtMTQ0Myw2 ICsxNDQzLDcgQEAKIGRldi9paWNidXMvaWljc21iLmMJCW9wdGlvbmFsIGlpY3NtYgkJCQlcCiAJ ZGVwZW5kZW5jeQkiaWljYnVzX2lmLmgiCiBkZXYvaWljYnVzL2lpY29jLmMJCW9wdGlvbmFsIGlp Y29jCitkZXYvaWljYnVzL2xtNzUuYwkJb3B0aW9uYWwgbG03NQogZGV2L2lpY2J1cy9wY2Y4NTYz LmMJCW9wdGlvbmFsIHBjZjg1NjMKIGRldi9paWNidXMvczM1MzkwYS5jCQlvcHRpb25hbCBzMzUz OTBhCiBkZXYvaWlyL2lpci5jCQkJb3B0aW9uYWwgaWlyCkluZGV4OiBzeXMvZGV2L2lpY2J1cy9s bTc1LmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQotLS0gc3lzL2Rldi9paWNidXMvbG03NS5jCShyZXZpc2lvbiAwKQor Kysgc3lzL2Rldi9paWNidXMvbG03NS5jCSh3b3JraW5nIGNvcHkpCkBAIC0wLDAgKzEsNTU3IEBA CisvKi0KKyAqIENvcHlyaWdodCAoYykgMjAxMCBBbmRyZWFzIFRvYmxlci4KKyAqIENvcHlyaWdo dCAoYykgMjAxMyBMdWl6IE90YXZpbyBPIFNvdXphIDxsb29zQGZyZWVic2Qub3JnPi4KKyAqIEFs bCByaWdodHMgcmVzZXJ2ZWQuCisgKgorICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3Vy Y2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0CisgKiBtb2RpZmljYXRpb24sIGFy ZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMKKyAqIGFy ZSBtZXQ6CisgKiAxLiBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4g dGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9u cyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyLgorICogMi4gUmVkaXN0cmlidXRpb25zIGlu IGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAgIG5v dGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1l ciBpbiB0aGUKKyAqICAgIGRvY3VtZW50YXRpb24gYW5kL29yIG90aGVyIG1hdGVyaWFscyBwcm92 aWRlZCB3aXRoIHRoZSBkaXN0cmlidXRpb24uCisgKgorICogVEhJUyBTT0ZUV0FSRSBJUyBQUk9W SURFRCBCWSBUSEUgQVVUSE9SIGBgQVMgSVMnJyBBTkQgQU5ZIEVYUFJFU1MgT1IKKyAqIElNUExJ RUQgV0FSUkFOVElFUywgSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFRIRSBJTVBMSUVE IFdBUlJBTlRJRVMKKyAqIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQQVJU SUNVTEFSIFBVUlBPU0UgQVJFIERJU0NMQUlNRUQuCisgKiBJTiBOTyBFVkVOVCBTSEFMTCBUSEUg QVVUSE9SIEJFIExJQUJMRSBGT1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1QsCisgKiBJTkNJREVOVEFM LCBTUEVDSUFMLCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwgREFNQUdFUyAoSU5DTFVESU5H LAorICogQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RT IE9SIFNFUlZJQ0VTOworICogTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lO RVNTIElOVEVSUlVQVElPTikgSE9XRVZFUiBDQVVTRUQKKyAqIEFORCBPTiBBTlkgVEhFT1JZIE9G IExJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUIExJQUJJTElUWSwKKyAqIE9S IFRPUlQgKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkg V0FZCisgKiBPVVQgT0YgVEhFIFVTRSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQg T0YgVEhFIFBPU1NJQklMSVRZIE9GCisgKiBTVUNIIERBTUFHRS4KKyAqLworCisjaW5jbHVkZSA8 c3lzL2NkZWZzLmg+CitfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CisKKyNpbmNsdWRlICJvcHRfcGxh dGZvcm0uaCIKKworI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgorI2luY2x1ZGUgPHN5cy9idXMuaD4K KyNpbmNsdWRlIDxzeXMvZW5kaWFuLmg+CisjaW5jbHVkZSA8c3lzL2tlcm5lbC5oPgorI2luY2x1 ZGUgPHN5cy9tb2R1bGUuaD4KKyNpbmNsdWRlIDxzeXMvc3lzY3RsLmg+CisjaW5jbHVkZSA8c3lz L3N5c3RtLmg+CisKKyNpbmNsdWRlIDxtYWNoaW5lL2J1cy5oPgorCisjaW5jbHVkZSA8ZGV2L2lp Y2J1cy9paWNidXMuaD4KKyNpbmNsdWRlIDxkZXYvaWljYnVzL2lpY29uZi5oPgorCisjaWZkZWYg RkRUCisjaW5jbHVkZSA8ZGV2L29mdy9vcGVuZmlybS5oPgorI2luY2x1ZGUgPGRldi9vZncvb2Z3 X2J1cy5oPgorI2luY2x1ZGUgPGRldi9vZncvb2Z3X2J1c19zdWJyLmg+CisjZW5kaWYKKworLyog TE03NSByZWdpc3RlcnMuICovCisjZGVmaW5lCUxNNzVfVEVNUAkweDAKKyNkZWZpbmUJTE03NV9D T05GCTB4MQorI2RlZmluZQlMTTc1X0NPTkZfRlNISUZUCTMKKyNkZWZpbmUJTE03NV9DT05GX0ZB VUxUCQkweDE4CisjZGVmaW5lCUxNNzVfQ09ORl9QT0wJCTB4MDQKKyNkZWZpbmUJTE03NV9DT05G X01PREUJCTB4MDIKKyNkZWZpbmUJTE03NV9DT05GX1NIVVRECQkweDAxCisjZGVmaW5lCUxNNzVf Q09ORl9NQVNLCQkweDFmCisjZGVmaW5lCUxNNzVfVEhZU1QJMHgyCisjZGVmaW5lCUxNNzVfVE9T CTB4MworCisvKiBMTTc1IGNvbnN0YW50cy4gKi8KKyNkZWZpbmUJTE03NV9NSU5fVEVNUAktNTUK KyNkZWZpbmUJTE03NV9NQVhfVEVNUAkxMjUKKyNkZWZpbmUJTE03NV8wNTAwQwkweDgwCisjZGVm aW5lCUxNNzVfMDI1MEMJMHg0MAorI2RlZmluZQlMTTc1XzAxMjVDCTB4MjAKKyNkZWZpbmUJTE03 NV9NU0IJMHg4MDAwCisjZGVmaW5lCUxNNzVfTkVHX0JJVAlMTTc1X01TQgorI2RlZmluZQlUWl9a RVJPQwkyNzMyCisKKy8qIExNNzUgc3VwcG9ydGVkIG1vZGVscy4gKi8KKyNkZWZpbmUJSFdUWVBF X05PTkUJMAorI2RlZmluZQlIV1RZUEVfTE03NQkxCisjZGVmaW5lCUhXVFlQRV9MTTc1QQkyCisK KyNpZmRlZiBGRFQKK3N0YXRpYyBzdHJ1Y3Qgb2Z3X2NvbXBhdF9kYXRhIGNvbXBhdF9kYXRhW10g PSB7CisJeyAiZnJlZWJzZCxsbTc1IiwJSFdUWVBFX0xNNzUgfSwKKwl7ICJmcmVlYnNkLGxtNzVh IiwJSFdUWVBFX0xNNzVBIH0sCisJeyBOVUxMLAkJCUhXVFlQRV9OT05FIH0sCit9OworI2VuZGlm CisKKy8qIFJlZ3VsYXIgYnVzIGF0dGFjaG1lbnQgZnVuY3Rpb25zICovCitzdGF0aWMgaW50ICBs bTc1X3Byb2JlKGRldmljZV90KTsKK3N0YXRpYyBpbnQgIGxtNzVfYXR0YWNoKGRldmljZV90KTsK Kworc3RydWN0IGxtNzVfc29mdGMgeworCWRldmljZV90CQlzY19kZXY7CisJc3RydWN0IGludHJf Y29uZmlnX2hvb2sgZW51bV9ob29rOworCWludDMyX3QJCQlzY19od3R5cGU7CisJdWludDMyX3QJ CXNjX2FkZHI7CisJdWludDMyX3QJCXNjX2NvbmY7Cit9OworCitpbnQgbG03NV9mYXVsdHNbNF0g PSB7IDEsIDIsIDQsIDYgfTsKKworLyogVXRpbGl0eSBmdW5jdGlvbnMgKi8KK3N0YXRpYyBpbnQg IGxtNzVfY29uZl9yZWFkKHN0cnVjdCBsbTc1X3NvZnRjICopOworc3RhdGljIGludCAgbG03NV9j b25mX3dyaXRlKHN0cnVjdCBsbTc1X3NvZnRjICopOworc3RhdGljIGludCAgbG03NV90ZW1wX3Jl YWQoc3RydWN0IGxtNzVfc29mdGMgKiwgdWludDhfdCwgaW50ICopOworc3RhdGljIGludCAgbG03 NV90ZW1wX3dyaXRlKHN0cnVjdCBsbTc1X3NvZnRjICosIHVpbnQ4X3QsIGludCk7CitzdGF0aWMg dm9pZCBsbTc1X3N0YXJ0KHZvaWQgKik7CitzdGF0aWMgaW50ICBsbTc1X3JlYWQoZGV2aWNlX3Qs IHVpbnQzMl90LCB1aW50OF90LCB1aW50OF90ICosIHNpemVfdCk7CitzdGF0aWMgaW50ICBsbTc1 X3dyaXRlKGRldmljZV90LCB1aW50MzJfdCwgdWludDhfdCAqLCBzaXplX3QpOworc3RhdGljIGlu dCAgbG03NV9zdHJfbW9kZShjaGFyICopOworc3RhdGljIGludCAgbG03NV9zdHJfcG9sKGNoYXIg Kik7CitzdGF0aWMgaW50ICBsbTc1X3RlbXBfc3lzY3RsKFNZU0NUTF9IQU5ETEVSX0FSR1MpOwor c3RhdGljIGludCAgbG03NV9mYXVsdHNfc3lzY3RsKFNZU0NUTF9IQU5ETEVSX0FSR1MpOworc3Rh dGljIGludCAgbG03NV9tb2RlX3N5c2N0bChTWVNDVExfSEFORExFUl9BUkdTKTsKK3N0YXRpYyBp bnQgIGxtNzVfcG9sX3N5c2N0bChTWVNDVExfSEFORExFUl9BUkdTKTsKK3N0YXRpYyBpbnQgIGxt NzVfc2h1dGRvd25fc3lzY3RsKFNZU0NUTF9IQU5ETEVSX0FSR1MpOworCitzdGF0aWMgZGV2aWNl X21ldGhvZF90ICBsbTc1X21ldGhvZHNbXSA9IHsKKwkvKiBEZXZpY2UgaW50ZXJmYWNlICovCisJ REVWTUVUSE9EKGRldmljZV9wcm9iZSwJCWxtNzVfcHJvYmUpLAorCURFVk1FVEhPRChkZXZpY2Vf YXR0YWNoLAlsbTc1X2F0dGFjaCksCisKKwlERVZNRVRIT0RfRU5ECit9OworCitzdGF0aWMgZHJp dmVyX3QgbG03NV9kcml2ZXIgPSB7CisJImxtNzUiLAorCWxtNzVfbWV0aG9kcywKKwlzaXplb2Yo c3RydWN0IGxtNzVfc29mdGMpCit9OworCitzdGF0aWMgZGV2Y2xhc3NfdCBsbTc1X2RldmNsYXNz OworCitEUklWRVJfTU9EVUxFKGxtNzUsIGlpY2J1cywgbG03NV9kcml2ZXIsIGxtNzVfZGV2Y2xh c3MsIDAsIDApOworCitzdGF0aWMgaW50CitsbTc1X3JlYWQoZGV2aWNlX3QgZGV2LCB1aW50MzJf dCBhZGRyLCB1aW50OF90IHJlZywgdWludDhfdCAqZGF0YSwgc2l6ZV90IGxlbikKK3sKKwlpbnQg dHJ5OworCisJc3RydWN0IGlpY19tc2cgbXNnWzJdID0geworCSAgICB7IGFkZHIsIElJQ19NX1dS IHwgSUlDX01fTk9TVE9QLCAxLCAmcmVnIH0sCisJICAgIHsgYWRkciwgSUlDX01fUkQsIGxlbiwg ZGF0YSB9LAorCX07CisKKwl0cnkgPSAwOworCWZvciAoOzspIHsKKwkJaWYgKGlpY2J1c190cmFu c2ZlcihkZXYsIG1zZywgMikgIT0gMCkKKwkJCWdvdG8gcmV0cnk7CisKKwkJcmV0dXJuICgwKTsK KwlyZXRyeToKKwkJaWYgKCsrdHJ5ID4gNSkgeworCQkJZGV2aWNlX3ByaW50ZihkZXYsICJpaWNi dXMgcmVhZCBmYWlsZWRcbiIpOworCQkJcmV0dXJuICgtMSk7CisJCX0KKwkJcGF1c2UoImxtNzVf cmVhZCIsIGh6KTsKKwl9Cit9CisKK3N0YXRpYyBpbnQKK2xtNzVfd3JpdGUoZGV2aWNlX3QgZGV2 LCB1aW50MzJfdCBhZGRyLCB1aW50OF90ICpkYXRhLCBzaXplX3QgbGVuKQoreworCWludCB0cnk7 CisKKwlzdHJ1Y3QgaWljX21zZyBtc2dbMV0gPSB7CisJICAgIHsgYWRkciwgSUlDX01fV1IsIGxl biwgZGF0YSB9LAorCX07CisKKwl0cnkgPSAwOworCWZvciAoOzspIHsKKwkJaWYgKGlpY2J1c190 cmFuc2ZlcihkZXYsIG1zZywgMSkgIT0gMCkKKwkJCWdvdG8gcmV0cnk7CisKKwkJcmV0dXJuICgw KTsKKwlyZXRyeToKKwkJaWYgKCsrdHJ5ID4gNSkgeworCQkJZGV2aWNlX3ByaW50ZihkZXYsICJp aWNidXMgd3JpdGUgZmFpbGVkXG4iKTsKKwkJCXJldHVybiAoLTEpOworCQl9CisJCXBhdXNlKCJs bTc1X3dyaXRlIiwgaHopOworCX0KK30KKworc3RhdGljIGludAorbG03NV9wcm9iZShkZXZpY2Vf dCBkZXYpCit7CisJaW50IHR5cGU7CisJc3RydWN0IGxtNzVfc29mdGMgKnNjOworCisJdHlwZSA9 IDA7CisJc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisjaWZkZWYgRkRUCisJc2MtPnNjX2h3 dHlwZSA9IG9md19idXNfc2VhcmNoX2NvbXBhdGlibGUoZGV2LCBjb21wYXRfZGF0YSktPm9jZF9k YXRhOworCWlmIChzYy0+c2NfaHd0eXBlID09IEhXVFlQRV9OT05FKQorCQlyZXR1cm4gKEVOWElP KTsKKyNlbHNlCisJc2MtPnNjX2h3dHlwZSA9IEhXVFlQRV9MTTc1OworCWlmIChyZXNvdXJjZV9p bnRfdmFsdWUoZGV2aWNlX2dldF9uYW1lKGRldiksIGRldmljZV9nZXRfdW5pdChkZXYpLAorCSAg ICAibG03NWEiLCAmdHlwZSkgPT0gMCAmJiB0eXBlKQorCQlzYy0+c2NfaHd0eXBlID0gSFdUWVBF X0xNNzVBOworI2VuZGlmCisKKwlzd2l0Y2ggKHNjLT5zY19od3R5cGUpIHsKKwljYXNlIEhXVFlQ RV9MTTc1QToKKwkJZGV2aWNlX3NldF9kZXNjKGRldiwgIkxNNzVBIHRlbXBlcmF0dXJlIHNlbnNv ciIpOworCQlicmVhazsKKwlkZWZhdWx0OgorCQlkZXZpY2Vfc2V0X2Rlc2MoZGV2LCAiTE03NSB0 ZW1wZXJhdHVyZSBzZW5zb3IiKTsKKwl9CisKKwlyZXR1cm4gKEJVU19QUk9CRV9HRU5FUklDKTsK K30KKworc3RhdGljIGludAorbG03NV9hdHRhY2goZGV2aWNlX3QgZGV2KQoreworCXN0cnVjdCBs bTc1X3NvZnRjICpzYzsKKworCXNjID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOworCXNjLT5zY19k ZXYgPSBkZXY7CisJc2MtPnNjX2FkZHIgPSBpaWNidXNfZ2V0X2FkZHIoZGV2KTsKKworCXNjLT5l bnVtX2hvb2suaWNoX2Z1bmMgPSBsbTc1X3N0YXJ0OworCXNjLT5lbnVtX2hvb2suaWNoX2FyZyA9 IGRldjsKKworCS8qCisJICogV2UgaGF2ZSB0byB3YWl0IHVudGlsIGludGVycnVwdHMgYXJlIGVu YWJsZWQuIEkyQyByZWFkIGFuZCB3cml0ZQorCSAqIG9ubHkgd29ya3MgaWYgdGhlIGludGVycnVw dHMgYXJlIGF2YWlsYWJsZS4KKwkgKi8KKwlpZiAoY29uZmlnX2ludHJob29rX2VzdGFibGlzaCgm c2MtPmVudW1faG9vaykgIT0gMCkKKwkJcmV0dXJuIChFTk9NRU0pOworCisJcmV0dXJuICgwKTsK K30KKworc3RhdGljIHZvaWQKK2xtNzVfc3RhcnQodm9pZCAqeGRldikKK3sKKwlkZXZpY2VfdCBk ZXY7CisJc3RydWN0IGxtNzVfc29mdGMgKnNjOworCXN0cnVjdCBzeXNjdGxfY3R4X2xpc3QgKmN0 eDsKKwlzdHJ1Y3Qgc3lzY3RsX29pZCAqdHJlZV9ub2RlOworCXN0cnVjdCBzeXNjdGxfb2lkX2xp c3QgKnRyZWU7CisKKwlkZXYgPSAoZGV2aWNlX3QpeGRldjsKKwlzYyA9IGRldmljZV9nZXRfc29m dGMoZGV2KTsKKwljdHggPSBkZXZpY2VfZ2V0X3N5c2N0bF9jdHgoZGV2KTsKKwl0cmVlX25vZGUg PSBkZXZpY2VfZ2V0X3N5c2N0bF90cmVlKGRldik7CisJdHJlZSA9IFNZU0NUTF9DSElMRFJFTih0 cmVlX25vZGUpOworCisJY29uZmlnX2ludHJob29rX2Rpc2VzdGFibGlzaCgmc2MtPmVudW1faG9v ayk7CisKKwkvKiBSZWFkIHRoZSBjb25maWd1cmF0aW9uIHJlZ2lzdGVyLiAqLworCWlmIChsbTc1 X2NvbmZfcmVhZChzYykgIT0gMCkgeworCQlkZXZpY2VfcHJpbnRmKGRldiwgImNhbm5vdCByZWFk IHRoZSBjb25maWd1cmF0aW9uIHJlZ2lzdGVyLlxuIik7CisJCXJldHVybjsKKwl9CisKKwkvKiBU ZW1wZXJhdHVyZS4gKi8KKwlTWVNDVExfQUREX1BST0MoY3R4LCB0cmVlLCBPSURfQVVUTywgInRl bXBlcmF0dXJlIiwKKwkgICAgQ1RMVFlQRV9JTlQgfCBDVExGTEFHX1JEIHwgQ1RMRkxBR19NUFNB RkUsIGRldiwgTE03NV9URU1QLAorCSAgICBsbTc1X3RlbXBfc3lzY3RsLCAiSUsiLCAiQ3VycmVu dCB0ZW1wZXJhdHVyZSIpOworCVNZU0NUTF9BRERfUFJPQyhjdHgsIHRyZWUsIE9JRF9BVVRPLCAi dGh5c3QiLAorCSAgICBDVExUWVBFX0lOVCB8IENUTEZMQUdfUlcgfCBDVExGTEFHX01QU0FGRSwg ZGV2LCBMTTc1X1RIWVNULAorCSAgICBsbTc1X3RlbXBfc3lzY3RsLCAiSUsiLCAiSHlzdGVyZXNp cyB0ZW1wZXJhdHVyZSIpOworCVNZU0NUTF9BRERfUFJPQyhjdHgsIHRyZWUsIE9JRF9BVVRPLCAi dG9zIiwKKwkgICAgQ1RMVFlQRV9JTlQgfCBDVExGTEFHX1JXIHwgQ1RMRkxBR19NUFNBRkUsIGRl diwgTE03NV9UT1MsCisJICAgIGxtNzVfdGVtcF9zeXNjdGwsICJJSyIsICJPdmVydGVtcGVyYXR1 cmUiKTsKKworCS8qIENvbmZpZ3VyYXRpb24gcGFyYW1ldGVycy4gKi8KKwlTWVNDVExfQUREX1BS T0MoY3R4LCB0cmVlLCBPSURfQVVUTywgImZhdWx0cyIsCisJICAgIENUTEZMQUdfUlcgfCBDVExU WVBFX1VJTlQsIGRldiwgMCwKKwkgICAgbG03NV9mYXVsdHNfc3lzY3RsLCAiSVUiLCAiTE03NSBm YXVsdCBxdWV1ZSIpOworCVNZU0NUTF9BRERfUFJPQyhjdHgsIHRyZWUsIE9JRF9BVVRPLCAibW9k ZSIsCisJICAgIENUTEZMQUdfUlcgfCBDVExUWVBFX1NUUklORywgZGV2LCAwLAorCSAgICBsbTc1 X21vZGVfc3lzY3RsLCAiQSIsICJMTTc1IG1vZGUiKTsKKwlTWVNDVExfQUREX1BST0MoY3R4LCB0 cmVlLCBPSURfQVVUTywgInBvbGFyaXR5IiwKKwkgICAgQ1RMRkxBR19SVyB8IENUTFRZUEVfU1RS SU5HLCBkZXYsIDAsCisJICAgIGxtNzVfcG9sX3N5c2N0bCwgIkEiLCAiTE03NSBPUyBwb2xhcml0 eSIpOworCVNZU0NUTF9BRERfUFJPQyhjdHgsIHRyZWUsIE9JRF9BVVRPLCAic2h1dGRvd24iLAor CSAgICBDVExGTEFHX1JXIHwgQ1RMVFlQRV9VSU5ULCBkZXYsIDAsCisJICAgIGxtNzVfc2h1dGRv d25fc3lzY3RsLCAiSVUiLCAiTE03NSBzaHV0ZG93biIpOworfQorCitzdGF0aWMgaW50CitsbTc1 X2NvbmZfcmVhZChzdHJ1Y3QgbG03NV9zb2Z0YyAqc2MpCit7CisJdWludDhfdCBidWY4OworCisJ aWYgKGxtNzVfcmVhZChzYy0+c2NfZGV2LCBzYy0+c2NfYWRkciwgTE03NV9DT05GLCAmYnVmOCwg MSkgPCAwKQorCQlyZXR1cm4gKC0xKTsKKworCXNjLT5zY19jb25mID0gKHVpbnQzMl90KWJ1Zjg7 CisKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgaW50CitsbTc1X2NvbmZfd3JpdGUoc3RydWN0 IGxtNzVfc29mdGMgKnNjKQoreworCXVpbnQ4X3QgYnVmOFsyXTsKKworCWJ1ZjhbMF0gPSBMTTc1 X0NPTkY7CisJYnVmOFsxXSA9ICh1aW50OF90KXNjLT5zY19jb25mICYgTE03NV9DT05GX01BU0s7 CisKKwlpZiAobG03NV93cml0ZShzYy0+c2NfZGV2LCBzYy0+c2NfYWRkciwgYnVmOCwgMikgPCAw KQorCQlyZXR1cm4gKC0xKTsKKworCXJldHVybiAoMCk7Cit9CisKK3N0YXRpYyBpbnQKK2xtNzVf dGVtcF9yZWFkKHN0cnVjdCBsbTc1X3NvZnRjICpzYywgdWludDhfdCByZWcsIGludCAqdGVtcCkK K3sKKwl1aW50OF90IGJ1ZjhbMl07CisJdWludDE2X3QgYnVmOworCWludCB0OworCisJaWYgKGxt NzVfcmVhZChzYy0+c2NfZGV2LCBzYy0+c2NfYWRkciwgcmVnLCBidWY4LCAyKSA8IDApCisJCXJl dHVybiAoLTEpOworCisJYnVmID0gKGJ1ZjhbMF0gPDwgOCkgfCAoYnVmOFsxXSAmIDB4ZmYpOwor CisJLyoKKwkgKiBMTTc1IGhhcyBhIDkgYml0IEFEQyB3aXRoIHJlc29sdXRpb24gb2YgMC41IEMg cGVyIGJpdC4KKwkgKiBMTTc1QSBoYXMgYSAxMSBiaXQgQURDIHdpdGggcmVzb2x1dGlvbiBvZiAw LjEyNSBDIHBlciBiaXQuCisJICogVGVtcGVyYXR1cmUgaXMgc3RvcmVkIHdpdGggdHdvJ3MgY29t cGxlbWVudC4KKwkgKi8KKwlpZiAoYnVmICYgTE03NV9ORUdfQklUKQorCQlidWYgPSB+YnVmICsg MTsKKwkqdGVtcCA9ICgoaW50MTZfdClidWYgPj4gOCkgKiAxMDsKKwl0ID0gMDsKKwlpZiAoc2Mt PnNjX2h3dHlwZSA9PSBIV1RZUEVfTE03NUEpIHsKKwkJaWYgKGJ1ZiAmIExNNzVfMDEyNUMpCisJ CQl0ICs9IDEyNTsKKwkJaWYgKGJ1ZiAmIExNNzVfMDI1MEMpCisJCQl0ICs9IDI1MDsKKwl9CisJ aWYgKGJ1ZiAmIExNNzVfMDUwMEMpCisJCXQgKz0gNTAwOworCXQgLz0gMTAwOworCSp0ZW1wICs9 IHQ7CisJaWYgKGJ1ZiAmIExNNzVfTkVHX0JJVCkKKwkJKnRlbXAgPSAtKCp0ZW1wKTsKKwkqdGVt cCArPSBUWl9aRVJPQzsKKworCXJldHVybiAoMCk7Cit9CisKK3N0YXRpYyBpbnQKK2xtNzVfdGVt cF93cml0ZShzdHJ1Y3QgbG03NV9zb2Z0YyAqc2MsIHVpbnQ4X3QgcmVnLCBpbnQgdGVtcCkKK3sK Kwl1aW50OF90IGJ1ZjhbM107CisJdWludDE2X3QgYnVmOworCisJaWYgKHRlbXAgPiBMTTc1X01B WF9URU1QKQorCQl0ZW1wID0gTE03NV9NQVhfVEVNUDsKKwlpZiAodGVtcCA8IExNNzVfTUlOX1RF TVApCisJCXRlbXAgPSBMTTc1X01JTl9URU1QOworCisJYnVmID0gKHVpbnQxNl90KXRlbXA7CisJ YnVmIDw8PSA4OworCisJYnVmOFswXSA9IHJlZzsKKwlidWY4WzFdID0gYnVmID4+IDg7CisJYnVm OFsyXSA9IGJ1ZiAmIDB4ZmY7CisKKwlpZiAobG03NV93cml0ZShzYy0+c2NfZGV2LCBzYy0+c2Nf YWRkciwgYnVmOCwgMykgPCAwKQorCQlyZXR1cm4gKC0xKTsKKworCXJldHVybiAoMCk7Cit9CisK K3N0YXRpYyBpbnQKK2xtNzVfc3RyX21vZGUoY2hhciAqYnVmKQoreworCWludCBsZW4sIHJ0cm47 CisKKwlydHJuID0gLTE7CisJbGVuID0gc3RybGVuKGJ1Zik7CisJaWYgKGxlbiA+IDIgJiYgc3Ry bmNhc2VjbXAoImludGVycnVwdCIsIGJ1ZiwgbGVuKSA9PSAwKQorCQlydHJuID0gMTsKKwllbHNl IGlmIChsZW4gPiAyICYmIHN0cm5jYXNlY21wKCJjb21wYXJhdG9yIiwgYnVmLCBsZW4pID09IDAp CisJCXJ0cm4gPSAwOworCisJcmV0dXJuIChydHJuKTsKK30KKworc3RhdGljIGludAorbG03NV9z dHJfcG9sKGNoYXIgKmJ1ZikKK3sKKwlpbnQgbGVuLCBydHJuOworCisJcnRybiA9IC0xOworCWxl biA9IHN0cmxlbihidWYpOworCWlmIChsZW4gPiAxICYmIHN0cm5jYXNlY21wKCJoaWdoIiwgYnVm LCBsZW4pID09IDApCisJCXJ0cm4gPSAxOworCWVsc2UgaWYgKGxlbiA+IDEgJiYgc3RybmNhc2Vj bXAoImxvdyIsIGJ1ZiwgbGVuKSA9PSAwKQorCQlydHJuID0gMDsKKwllbHNlIGlmIChsZW4gPiA4 ICYmIHN0cm5jYXNlY21wKCJhY3RpdmUtaGlnaCIsIGJ1ZiwgbGVuKSA9PSAwKQorCQlydHJuID0g MTsKKwllbHNlIGlmIChsZW4gPiA4ICYmIHN0cm5jYXNlY21wKCJhY3RpdmUtbG93IiwgYnVmLCBs ZW4pID09IDApCisJCXJ0cm4gPSAwOworCisJcmV0dXJuIChydHJuKTsKK30KKworc3RhdGljIGlu dAorbG03NV90ZW1wX3N5c2N0bChTWVNDVExfSEFORExFUl9BUkdTKQoreworCWRldmljZV90IGRl djsKKwlpbnQgZXJyb3IsIHRlbXA7CisJc3RydWN0IGxtNzVfc29mdGMgKnNjOworCXVpbnQ4X3Qg cmVnOworCisJZGV2ID0gYXJnMTsKKwlyZWcgPSBhcmcyOworCXNjID0gZGV2aWNlX2dldF9zb2Z0 YyhkZXYpOworCisJaWYgKGxtNzVfdGVtcF9yZWFkKHNjLCByZWcsICZ0ZW1wKSAhPSAwKQorCQly ZXR1cm4gKEVJTyk7CisKKwllcnJvciA9IHN5c2N0bF9oYW5kbGVfaW50KG9pZHAsICZ0ZW1wLCAw LCByZXEpOworCWlmIChlcnJvciAhPSAwIHx8IHJlcS0+bmV3cHRyID09IE5VTEwpCisJCXJldHVy biAoZXJyb3IpOworCisJaWYgKGxtNzVfdGVtcF93cml0ZShzYywgcmVnLCB0ZW1wKSAhPSAwKQor CQlyZXR1cm4gKEVJTyk7CisKKwlyZXR1cm4gKGVycm9yKTsKK30KKworc3RhdGljIGludAorbG03 NV9mYXVsdHNfc3lzY3RsKFNZU0NUTF9IQU5ETEVSX0FSR1MpCit7CisJZGV2aWNlX3QgZGV2Owor CWludCBlcnJvciwgZmF1bHRzLCBpLCBuZXdmLCB0bXA7CisJc3RydWN0IGxtNzVfc29mdGMgKnNj OworCisJZGV2ID0gYXJnMTsKKwlzYyA9IGRldmljZV9nZXRfc29mdGMoZGV2KTsKKwl0bXAgPSAo c2MtPnNjX2NvbmYgJiBMTTc1X0NPTkZfRkFVTFQpID4+IExNNzVfQ09ORl9GU0hJRlQ7CisJaWYg KHRtcCA+IG5pdGVtcyhsbTc1X2ZhdWx0cykpCisJCXRtcCA9IG5pdGVtcyhsbTc1X2ZhdWx0cyk7 CisJZmF1bHRzID0gbG03NV9mYXVsdHNbdG1wXTsKKworCWVycm9yID0gc3lzY3RsX2hhbmRsZV9p bnQob2lkcCwgJmZhdWx0cywgMCwgcmVxKTsKKwlpZiAoZXJyb3IgIT0gMCB8fCByZXEtPm5ld3B0 ciA9PSBOVUxMKQorCQlyZXR1cm4gKGVycm9yKTsKKworCWlmIChmYXVsdHMgIT0gbG03NV9mYXVs dHNbdG1wXSkgeworCQluZXdmID0gMDsKKwkJZm9yIChpID0gMDsgaSA8IG5pdGVtcyhsbTc1X2Zh dWx0cyk7IGkrKykKKwkJCWlmIChmYXVsdHMgPj0gbG03NV9mYXVsdHNbaV0pCisJCQkJbmV3ZiA9 IGk7CisJCXNjLT5zY19jb25mICY9IH5MTTc1X0NPTkZfRkFVTFQ7CisJCXNjLT5zY19jb25mIHw9 IG5ld2YgPDwgTE03NV9DT05GX0ZTSElGVDsKKwkJaWYgKGxtNzVfY29uZl93cml0ZShzYykgIT0g MCkKKwkJCXJldHVybiAoRUlPKTsKKwl9CisKKwlyZXR1cm4gKGVycm9yKTsKK30KKworc3RhdGlj IGludAorbG03NV9tb2RlX3N5c2N0bChTWVNDVExfSEFORExFUl9BUkdTKQoreworCWNoYXIgYnVm WzE2XTsKKwlkZXZpY2VfdCBkZXY7CisJaW50IGVycm9yLCBtb2RlLCBuZXdtOworCXN0cnVjdCBs bTc1X3NvZnRjICpzYzsKKworCWRldiA9IGFyZzE7CisJc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRl dik7CisJaWYgKHNjLT5zY19jb25mICYgTE03NV9DT05GX01PREUpIHsKKwkJbW9kZSA9IDE7CisJ CXN0cmxjcHkoYnVmLCAiaW50ZXJydXB0Iiwgc2l6ZW9mKGJ1ZikpOworCX0gZWxzZSB7CisJCW1v ZGUgPSAwOworCQlzdHJsY3B5KGJ1ZiwgImNvbXBhcmF0b3IiLCBzaXplb2YoYnVmKSk7CisJfQor CisJZXJyb3IgPSBzeXNjdGxfaGFuZGxlX3N0cmluZyhvaWRwLCBidWYsIHNpemVvZihidWYpLCBy ZXEpOworCWlmIChlcnJvciAhPSAwIHx8IHJlcS0+bmV3cHRyID09IE5VTEwpCisJCXJldHVybiAo ZXJyb3IpOworCisJbmV3bSA9IGxtNzVfc3RyX21vZGUoYnVmKTsKKwlpZiAobmV3bSAhPSAtMSAm JiBtb2RlICE9IG5ld20pIHsKKwkJc2MtPnNjX2NvbmYgJj0gfkxNNzVfQ09ORl9NT0RFOworCQlp ZiAobmV3bSA9PSAxKQorCQkJc2MtPnNjX2NvbmYgfD0gTE03NV9DT05GX01PREU7CisJCWlmIChs bTc1X2NvbmZfd3JpdGUoc2MpICE9IDApCisJCQlyZXR1cm4gKEVJTyk7CisJfQorCisJcmV0dXJu IChlcnJvcik7Cit9CisKK3N0YXRpYyBpbnQKK2xtNzVfcG9sX3N5c2N0bChTWVNDVExfSEFORExF Ul9BUkdTKQoreworCWNoYXIgYnVmWzE2XTsKKwlkZXZpY2VfdCBkZXY7CisJaW50IGVycm9yLCBu ZXdwLCBwb2w7CisJc3RydWN0IGxtNzVfc29mdGMgKnNjOworCisJZGV2ID0gYXJnMTsKKwlzYyA9 IGRldmljZV9nZXRfc29mdGMoZGV2KTsKKwlpZiAoc2MtPnNjX2NvbmYgJiBMTTc1X0NPTkZfUE9M KSB7CisJCXBvbCA9IDE7CisJCXN0cmxjcHkoYnVmLCAiYWN0aXZlLWhpZ2giLCBzaXplb2YoYnVm KSk7CisJfSBlbHNlIHsKKwkJcG9sID0gMDsKKwkJc3RybGNweShidWYsICJhY3RpdmUtbG93Iiwg c2l6ZW9mKGJ1ZikpOworCX0KKworCWVycm9yID0gc3lzY3RsX2hhbmRsZV9zdHJpbmcob2lkcCwg YnVmLCBzaXplb2YoYnVmKSwgcmVxKTsKKwlpZiAoZXJyb3IgIT0gMCB8fCByZXEtPm5ld3B0ciA9 PSBOVUxMKQorCQlyZXR1cm4gKGVycm9yKTsKKworCW5ld3AgPSBsbTc1X3N0cl9wb2woYnVmKTsK KwlpZiAobmV3cCAhPSAtMSAmJiBwb2wgIT0gbmV3cCkgeworCQlzYy0+c2NfY29uZiAmPSB+TE03 NV9DT05GX1BPTDsKKwkJaWYgKG5ld3AgPT0gMSkKKwkJCXNjLT5zY19jb25mIHw9IExNNzVfQ09O Rl9QT0w7CisJCWlmIChsbTc1X2NvbmZfd3JpdGUoc2MpICE9IDApCisJCQlyZXR1cm4gKEVJTyk7 CisJfQorCisJcmV0dXJuIChlcnJvcik7Cit9CisKK3N0YXRpYyBpbnQKK2xtNzVfc2h1dGRvd25f c3lzY3RsKFNZU0NUTF9IQU5ETEVSX0FSR1MpCit7CisJZGV2aWNlX3QgZGV2OworCWludCBlcnJv ciwgc2h1dGRvd24sIHRtcDsKKwlzdHJ1Y3QgbG03NV9zb2Z0YyAqc2M7CisKKwlkZXYgPSBhcmcx OworCXNjID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOworCXRtcCA9IHNodXRkb3duID0gKHNjLT5z Y19jb25mICYgTE03NV9DT05GX1NIVVREKSA/IDEgOiAwOworCisJZXJyb3IgPSBzeXNjdGxfaGFu ZGxlX2ludChvaWRwLCAmc2h1dGRvd24sIDAsIHJlcSk7CisJaWYgKGVycm9yICE9IDAgfHwgcmVx LT5uZXdwdHIgPT0gTlVMTCkKKwkJcmV0dXJuIChlcnJvcik7CisKKwlpZiAoc2h1dGRvd24gIT0g dG1wKSB7CisJCXNjLT5zY19jb25mICY9IH5MTTc1X0NPTkZfU0hVVEQ7CisJCWlmIChzaHV0ZG93 bikKKwkJCXNjLT5zY19jb25mIHw9IExNNzVfQ09ORl9TSFVURDsKKwkJaWYgKGxtNzVfY29uZl93 cml0ZShzYykgIT0gMCkKKwkJCXJldHVybiAoRUlPKTsKKwl9CisKKwlyZXR1cm4gKGVycm9yKTsK K30KClByb3BlcnR5IGNoYW5nZXMgb246IHN5cy9kZXYvaWljYnVzL2xtNzUuYwpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f CkFkZGVkOiBzdm46ZW9sLXN0eWxlCiMjIC0wLDAgKzEgIyMKK25hdGl2ZQpcIE5vIG5ld2xpbmUg YXQgZW5kIG9mIHByb3BlcnR5CkFkZGVkOiBzdm46bWltZS10eXBlCiMjIC0wLDAgKzEgIyMKK3Rl eHQvcGxhaW4KXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBwcm9wZXJ0eQpBZGRlZDogc3ZuOmtleXdv cmRzCiMjIC0wLDAgKzEgIyMKK0ZyZWVCU0Q9JUgKXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBwcm9w ZXJ0eQpJbmRleDogc2hhcmUvbWFuL21hbjQvTWFrZWZpbGUKPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2hhcmUv bWFuL21hbjQvTWFrZWZpbGUJKHJldmlzaW9uIDI2Mjg2MCkKKysrIHNoYXJlL21hbi9tYW40L01h a2VmaWxlCSh3b3JraW5nIGNvcHkpCkBAIC0yMjMsNiArMjIzLDcgQEAKIAlsZ2UuNCBcCiAJJHtf bGluZGV2LjR9IFwKIAkke19saW51eC40fSBcCisJbG03NS40IFwKIAlsbWMuNCBcCiAJbG8uNCBc CiAJbHAuNCBcCkluZGV4OiBzaGFyZS9tYW4vbWFuNC9sbTc1LjQKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2hh cmUvbWFuL21hbjQvbG03NS40CShyZXZpc2lvbiAwKQorKysgc2hhcmUvbWFuL21hbjQvbG03NS40 CSh3b3JraW5nIGNvcHkpCkBAIC0wLDAgKzEsMTkyIEBACisuXCIKKy5cIiBDb3B5cmlnaHQgKGMp IDIwMTQgTHVpeiBPdGF2aW8gTyBTb3V6YSA8bG9vc0BmcmVlYnNkLm9yZz4KKy5cIiBBbGwgcmln aHRzIHJlc2VydmVkLgorLlwiCisuXCIgUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2Ug YW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0CisuXCIgbW9kaWZpY2F0aW9uLCBhcmUg cGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zCisuXCIgYXJl IG1ldDoKKy5cIiAxLiBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4g dGhlIGFib3ZlIGNvcHlyaWdodAorLlwiICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlv bnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4KKy5cIiAyLiBSZWRpc3RyaWJ1dGlvbnMg aW4gYmluYXJ5IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAorLlwiICAg IG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xh aW1lciBpbiB0aGUKKy5cIiAgICBkb2N1bWVudGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlhbHMg cHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9uLgorLlwiCisuXCIgVEhJUyBTT0ZUV0FSRSBJ UyBQUk9WSURFRCBCWSBUSEUgQVVUSE9SIGBgQVMgSVMnJyBBTkQgQU5ZIEVYUFJFU1MgT1IKKy5c IiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUg SU1QTElFRCBXQVJSQU5USUVTCisuXCIgT0YgTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZP UiBBIFBBUlRJQ1VMQVIgUFVSUE9TRSBBUkUgRElTQ0xBSU1FRC4KKy5cIiBJTiBOTyBFVkVOVCBT SEFMTCBUSEUgQVVUSE9SIEJFIExJQUJMRSBGT1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1QsCisuXCIg SU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMIERBTUFHRVMg KElOQ0xVRElORywgQlVUCisuXCIgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9GIFNVQlNU SVRVVEUgR09PRFMgT1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLAorLlwiIERBVEEsIE9SIFBST0ZJ VFM7IE9SIEJVU0lORVNTIElOVEVSUlVQVElPTikgSE9XRVZFUiBDQVVTRUQgQU5EIE9OIEFOWQor LlwiIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVCBMSUFC SUxJVFksIE9SIFRPUlQKKy5cIiAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBB UklTSU5HIElOIEFOWSBXQVkgT1VUIE9GIFRIRSBVU0UgT0YKKy5cIiBUSElTIFNPRlRXQVJFLCBF VkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GIFNVQ0ggREFNQUdFLgorLlwiCisu XCIgJEZyZWVCU0QkCisuXCIKKy5EZCBNYXJjaCA3LCAyMDE0CisuRHQgTE03NSA0CisuT3MKKy5T aCBOQU1FCisuTm0gbG03NQorLk5kIGxtNzUgaTJjIGRpZ2l0YWwgdGVtcGVyYXR1cmUgc2Vuc29y IGRyaXZlcgorLlNoIFNZTk9QU0lTCisuQ2QgImRldmljZSBpaWMiCisuQ2QgImRldmljZSBpaWNi dXMiCisuQ2QgImRldmljZSBsbTc1IgorLlNoIERFU0NSSVBUSU9OCitUaGUKKy5ObQorZHJpdmVy IHByb3ZpZGVzIGFjY2VzcyB0byBzZW5zb3IgZGF0YSBhbmQgY29uZmlndXJhdGlvbiBvdmVyIHRo ZQorLlhyIGlpY2J1cyA0IC4KKy5QcAorSXQgcHJvdmlkZXMgYW4gZWFzeSBhbmQgc2ltcGxlIHdh eSB0byBjaGVjayB0aGUgZnVuY3Rpb25hbGl0eSBvZiBhbiBpMmMgYnVzCithcyBpdCBwcm92aWRl cyByZWFkIGFuZCB3cml0ZSBhY2Nlc3MgdG8gdGhlCisuTm0KK2NvbmZpZ3VyYXRpb24gcmVnaXN0 ZXIuCisuUHAKK1RoZSBhY2Nlc3MgdG8KKy5ObQorZGF0YSBpcyBtYWRlIHZpYSB0aGUKKy5YciBz eXNjdGwgOAoraW50ZXJmYWNlOgorLkJkIC1saXRlcmFsCitkZXYubG03NS4wLiVkZXNjOiBMTTc1 QSB0ZW1wZXJhdHVyZSBzZW5zb3IKK2Rldi5sbTc1LjAuJWRyaXZlcjogbG03NQorZGV2LmxtNzUu MC4lbG9jYXRpb246IGFkZHI9MHg0OQorZGV2LmxtNzUuMC4lcG5waW5mbzogbmFtZT1sbTc1MCBj b21wYXQ9ZnJlZWJzZCxsbTc1YQorZGV2LmxtNzUuMC4lcGFyZW50OiBpaWNidXMzCitkZXYubG03 NS4wLnRlbXBlcmF0dXJlOiAyNy4xQworZGV2LmxtNzUuMC50aHlzdDogNzUuMEMKK2Rldi5sbTc1 LjAudG9zOiA4MC4wQworZGV2LmxtNzUuMC5mYXVsdHM6IDEKK2Rldi5sbTc1LjAubW9kZTogY29t cGFyYXRvcgorZGV2LmxtNzUuMC5wb2xhcml0eTogYWN0aXZlLWxvdworZGV2LmxtNzUuMC5zaHV0 ZG93bjogMAorLkVkCisuQmwgLXRhZyAtd2lkdGggIi5WYSBkZXYubG03NS4lZC50ZW1wZXJhdHVy ZSIKKy5JdCBWYSBkZXYubG03NS4lZC50ZW1wZXJhdHVyZQorSXMgdGhlIHJlYWQtb25seSB2YWx1 ZSBvZiB0aGUgY3VycmVudCB0ZW1wZXJhdHVyZSByZWFkIGJ5IHRoZSBzZW5zb3IuCisuSXQgVmEg ZGV2LmxtNzUuJWQudGh5c3QKK1NldHMgdGhlIGh5c3RlcmVzaXMgdGVtcGVyYXR1cmUuCitPbmNl IHRoZSB0ZW1wZXJhdHVyZSBnZXQgb3ZlciB0aGUgb3ZlcnRlbXBlcmF0dXJlIHNodXRkb3duIHZh bHVlICh0b3MpCitpdCBuZWVkIHRvIGRyb3AgYmVsbG93IHRoZSBoeXN0ZXJlc2lzIHRlbXBlcmF0 dXJlIHRvIGRpc2FibGUgdGhlIG91dHB1dAorKGludGVycnVwdCkgcGluIGFnYWluLgorLkl0IFZh IGRldi5sbTc1LiVkLnRvcworU2V0cyB0aGUgb3ZlcnRlbXBlcmF0dXJlIHNodXRkb3duIHZhbHVl LgorT25jZSB0aGUgdGVtcGVyYXR1cmUgZ2V0IG92ZXIgdGhpcyB2YWx1ZSB0aGUgb3V0cHV0IHBp biB3aWxsIGJlIGVuYWJsZWQuCitUaGUgd2F5IHRoZSBvdXRwdXQgKGludGVycnVwdCkgcGluIHdv cmtzLCBkZXBlbmRzIG9uIHRoZSBtb2RlLgorLkl0IFZhIGRldi5sbTc1LiVkLmZhdWx0cworSXMg dGhlIG51bWJlciBvZiBmYXVsdHMgdGhhdCBtdXN0IG9jY3VyIGNvbnNlY3V0aXZlbHkgdG8gYWN0 aXZhdGUgdGhlCitpbnRlcnJ1cHQgKG91dHB1dCkgcGluLgorSXQgY2FuIGJlIHNldCB0byAxLCAy LCA0LCBhbmQgNi4KKy5JdCBWYSBkZXYubG03NS4lZC5tb2RlCitTZXQgdGhlIG9wZXJhdGlvbiBt b2RlIGZvciB0aGUgc2Vuc29yIGludGVycnVwdCBwaW4uCitJdCBjYW4gYmUgc2V0IHRvICdjb21w YXJhdG9yJyAoZGVmYXVsdCkgb3IgJ2ludGVycnVwdCcuCisuSXQgVmEgZGV2LmxtNzUuJWQucG9s YXJpdHkKK1NldCB0aGUgcG9sYXJpdHkgb2YgdGhlIHNlbnNvciBpbnRlcnJ1cHQgcGluLgorSXQg Y2FuIGJlIHNldCB0byAnYWN0aXZlLWxvdycgKGRlZmF1bHQpIG9yICdhY3RpdmUtaGlnaCcuCitQ bGVhc2Ugbm90ZSB0aGF0IHRoZSBvdXRwdXQgcGluIGlzIGFuIG9wZW4tZHJhaW4gb3V0cHV0IGFu ZCBpdCBuZWVkcyBhCitwcm9wZXIgcHVsbC11cCByZXNpc3RvciB0byB3b3JrLgorLkl0IFZhIGRl di5sbTc1LiVkLnNodXRkb3duCitXaGVuIHNldCB0byAnMScgaXQgc2h1dGRvd24gdGhlIHNlbnNv ci4KK1RoZSB0ZW1wZXJhdHVyZSBjb252ZXJ0aW9uIHN0b3BzIGJ1dCB0aGUgc2Vuc29yIHJlbWFp bnMgd2l0aCBpdHMgaTJjIGJ1cworYWN0aXZlLCBpLmUuLCBpdCBjYW4gYmUgd29rZW4gdXAgYnkg c2V0dGluZyB0aGlzIG9wdGlvbiB0byAnMCcgYWdhaW4uCisuRWwKKy5QcAorUGxlYXNlIGNoZWNr IHRoZQorLk5tCitkYXRhc2hlZXQgZm9yIG1vcmUgZGV0YWlscy4KKy5QcAorV2hlbiB1c2VkIHRv Z2V0aGVyIHdpdGgKKy5YciBzbm1wX2xtNzUgMworaXQgYWxsb3dzIHRoZSBtb25pdG9yaW5nIG9m CisuTm0KK3RlbXBlcmF0dXJlIGRhdGEgb3ZlciBTTk1QLgorLlBwCitUaGUKKy5ObQorZHJpdmVy IHN1cHBvcnRzIGJvdGggdGhlIGxvdyBhbmQgdGhlIGhpZ2ggcmVzb2x1dGlvbiBtb2RlbHMuCisu UHAKK1RoZSBsb3cgcmVzb2x1dGlvbiBtb2RlbCAobG03NSkgcHJvdmlkZXMgYSA5IGJpdCBvdXRw dXQgd2l0aCB0aGUgTFNCCityZXByZXNlbnRpbmcgMC41Qy4KKy5QcAorVGhlIGhpZ2ggcmVzb2x1 dGlvbiBtb2RlbCAobG03NWEpIHByb3ZpZGVzIGFuIDExIGJpdCBvdXRwdXQgd2l0aCB0aGUgTFNC CityZXByZXNlbnRpbmcgMC4xMjVDLgorLlBwCitPbiBhCisuWHIgZGV2aWNlLmhpbnRzIDUKK2Jh c2VkIHN5c3RlbSwgbGlrZQorLkxpIE1JUFMgLAordGhlc2UgdmFsdWVzIGFyZSBjb25maWd1cmFi bGUgZm9yIHRoZQorLk5tIDoKKy5CbCAtdGFnIC13aWR0aCAiLlZhIGhpbnQubG03NS4lZC5sbTc1 YSIKKy5JdCBWYSBoaW50LmxtNzUuJWQuYXQKK0lzIHRoZQorLlhyIGlpY2J1cyA0Cit5b3UgYXJl IGF0dGFjaGluZyB0by4KKy5JdCBWYSBoaW50LmxtNzUuJWQuYWRkcgorSXMgdGhlCisuTm0KK2ky YyBhZGRyZXNzIG9uIHRoZQorLlhyIGlpY2J1cyA0IC4KKy5JdCBWYSBoaW50LmxtNzUuJWQubG03 NWEKK1doZW4gc2V0IHRvICcxJyBlbmFibGVzIHRoZSBoaWdoIHJlc29sdXRpb24gdGVtcGVyYXR1 cmUgcmVhZGluZyBmb3IgdGhpcworc2Vuc29yLgorLkVsCisuUHAKK09uIGEKKy5YciBGRFQgNAor YmFzZWQgc3lzdGVtLCBsaWtlCisuTGkgQVJNICwKK3RoZSBEVFMgcGFydCBmb3IgYQorLk5tCitk ZXZpY2UgdXN1YWxseSBsb29rcyBsaWtlOgorLkJkIC1saXRlcmFsCitpMmMgeworCisJLi4uCisK KwlsbTc1MCB7CisJCWNvbXBhdGlibGUgPSAiZnJlZWJzZCxsbTc1IjsKKwkJaTJjLWFkZHJlc3Mg PSA8MHg0OD47CisJfTsKKworCWxtNzUxIHsKKwkJY29tcGF0aWJsZSA9ICJmcmVlYnNkLGxtNzVh IjsKKwkJaTJjLWFkZHJlc3MgPSA8MHg0OT47CisJfTsKK307CisuRWQKKy5QcAorV2hlcmU6Cisu QmwgLXRhZyAtd2lkdGggIi5WYSBpMmMtYWRkcmVzcyIKKy5JdCBWYSBjb21wYXRpYmxlCitTaG91 bGQgYmUgc2V0IHRvICJmcmVlYnNkLGxtNzUiIGZvciB0aGUgbG93IHJlc29sdXRpb24gZGV2aWNl cyBhbmQKKyJmcmVlYnNkLGxtNzVhIiBmb3IgdGhlIGhpZ2ggcmVzb2x1dGlvbiBkZXZpY2VzLgor Lkl0IFZhIGkyYy1hZGRyZXNzCitUaGUKKy5WYSBpMmMtYWRkcmVzcworcHJvcGVydHkgaW5kaWNh dGVzIHdoaWNoIGkyYyBhZGRyZXNzIHRoZQorLk5tCitpcyB3aXJlZCBhdC4KKy5ObQordGVtcGVy YXR1cmUgc2Vuc29ycyBjYW4gYmUgd2lyZWQgdG8gOCBkaWZmZXJlbnQgYWRkcmVzcywgYWxsb3dp bmcgdXAgdG8gOAorc2Vuc29ycyBvbiB0aGUgc2FtZQorLlhyIGlpY2J1cyA0IC4KKy5FbAorLlNo IFNFRSBBTFNPCisuWHIgc25tcF9sbTc1IDMgLAorLlhyIGZkdCA0ICwKKy5YciBpaWMgNCAsCisu WHIgaWljYnVzIDQgLAorLlhyIHN5c2N0bCA4CisuU2ggSElTVE9SWQorVGhlCisuTm0KK2RyaXZl ciBmaXJzdCBhcHBlYXJlZCBpbgorLkZ4IDExLjAgLgorLlNoIEFVVEhPUlMKKy5BbiAtbm9zcGxp dAorVGhlIGRyaXZlciBhbmQgdGhpcyBtYW51YWwgcGFnZSB3YXMgd3JpdHRlbiBieQorLkFuIEx1 aXogT3RhdmlvIE8gU291emEgQXEgbG9vc0BGcmVlQlNELm9yZwoKUHJvcGVydHkgY2hhbmdlcyBv bjogc2hhcmUvbWFuL21hbjQvbG03NS40Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KQWRkZWQ6IHN2bjptaW1lLXR5cGUK IyMgLTAsMCArMSAjIwordGV4dC9wbGFpbgpcIE5vIG5ld2xpbmUgYXQgZW5kIG9mIHByb3BlcnR5 CkFkZGVkOiBzdm46a2V5d29yZHMKIyMgLTAsMCArMSAjIworRnJlZUJTRD0lSApcIE5vIG5ld2xp bmUgYXQgZW5kIG9mIHByb3BlcnR5CkFkZGVkOiBzdm46ZW9sLXN0eWxlCiMjIC0wLDAgKzEgIyMK K25hdGl2ZQpcIE5vIG5ld2xpbmUgYXQgZW5kIG9mIHByb3BlcnR5Cg== --047d7bb70ae4a7569804f4443c0b-- From owner-freebsd-embedded@FreeBSD.ORG Mon Mar 17 11:06:42 2014 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 76FBA88F for ; Mon, 17 Mar 2014 11:06:42 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 62FAF28A for ; Mon, 17 Mar 2014 11:06:42 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s2HB6gLU011182 for ; Mon, 17 Mar 2014 11:06:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s2HB6f8Q011180 for freebsd-embedded@FreeBSD.org; Mon, 17 Mar 2014 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 17 Mar 2014 11:06:41 GMT Message-Id: <201403171106.s2HB6f8Q011180@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-embedded@FreeBSD.org Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 11:06:42 -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 misc/52256 embedded [picobsd] picobsd build script does not read in user/s o kern/42728 embedded [picobsd] many problems in src/usr.sbin/ppp/* after c 2 problems total. From owner-freebsd-embedded@FreeBSD.ORG Mon Mar 17 12:55:48 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54643ADC; Mon, 17 Mar 2014 12:55:48 +0000 (UTC) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ABD23FB2; Mon, 17 Mar 2014 12:55:47 +0000 (UTC) Received: by mail-we0-f174.google.com with SMTP id t60so4555313wes.33 for ; Mon, 17 Mar 2014 05:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8MqxqFoUZPkJWLgDlwifomYwlNQyvGECRCbNKZ0zex0=; b=qPq5BXdME9+Tt14cjxPzD+Dptv4M6s3suTkmXVusVa7/FQIfAUbxcWDn4ZFfPoGKl0 hnrX1s41OqKvfs+oaItZYTqlen0Fv2EYNyhDinwESf4yRW1TkbEH5RMHpmt5nIZ2hSey z/KTbhAkiHyTw/DvB61anZc8yIzztD929rN3WEtz0G6zbM33zbWxRFTgeVQh9BX43jk1 S7nSGd3I076ALeo9PQMIJrd8C+8p7K8RQJwFJXQLlTAeyjfDxU1sXGzf2eUTyzAROBTr ZWm5uh/KA3tBIv34AZnjMBA7i42cEwoq4fs4f1rb7d32XCraryAGH0tU+FEe/Yv/uL1Y zPDw== MIME-Version: 1.0 X-Received: by 10.180.87.162 with SMTP id az2mr9338371wib.23.1395060946092; Mon, 17 Mar 2014 05:55:46 -0700 (PDT) Received: by 10.216.79.132 with HTTP; Mon, 17 Mar 2014 05:55:45 -0700 (PDT) In-Reply-To: References: <2D5F2707-FD55-46BB-A44F-8870B48E2BB1@gmail.com> Date: Mon, 17 Mar 2014 09:55:45 -0300 Message-ID: Subject: Re: FDT/OFW GPIO bus From: Luiz Otavio O Souza To: Warner Losh Content-Type: multipart/mixed; boundary=f46d0444ecaf21df5704f4ccf00f Cc: freebsd-arm@freebsd.org, "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 12:55:48 -0000 --f46d0444ecaf21df5704f4ccf00f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Feb 7, 2014 at 1:21 AM, Warner Losh wrote: > > On Feb 6, 2014, at 11:53 AM, Luiz Otavio O Souza wrote: > >> Hello guys, >> >> Last call for alcohol^Wtest and reviews. >> >> I've finally managed to test these changes on a some FDT and non FDT sys= tems, so now it is all cleared to commit. >> >> I plan to commit these changes on the weekend unless someone objects. > > This is cool. > >> They add support to describe GPIO connections on the DTS files. It also = add the support to the in tree GPIO devices (gpioiic(4), gpioled(4)). >> >> The last patch (005-bbb-gpioled.diff) sets the gpioled(4) for the 4 on b= oard LEDs on BBB (beaglebone-black). The RPi led is already set and just ne= ed the first patch (001-ofw-gpiobus.diff) to work. >> >> The tests were done on RPi and BBB using I2C devices (two lm75 on the sa= me bus), LEDs (for gpioled(4)) and even with some non committed ethernet ov= er SPI. The I2C tests are conducted using the hardware I2C controller (when= available) and also the software big bang controller - gpioiic(4). >> >> I used the RSPRO (MIPS/ar71xx) to check for regressions without any visi= ble problem. >> >> gpioiic(4) devices can be described in DTS as follow: >> >> gpio { >> >> gpioiic { >> compatible =3D "gpioiic"; > > Linux uses 'i2c-gpio' here. Can we follow that standard rather than inven= t our own? Or at least support both? > >> gpios =3D <&gpio 17 2 0 >> &gpio 21 2 0>; >> scl =3D <0>; >> sda =3D <1>; > > Linux doesn't have these at all, it seems, since they are implicit in the= gpios property. It would be ideal if the scl and sda properties were optio= nal... > > In addition, you'll often see things like: > > i2c-gpio,sda-open-drain; > i2c-gpio,scl-open-drain; > i2c-gpio,delay-us =3D <2>; > > as well. These should be easy enough to add and shouldn't gate things. > > There's also many DTS files that don't have this as a direct child of gpi= o... But that's not strictly required. I'll cope with adding support for th= at when I get the Atmel stuff working... The first attached adds the ability to attach nodes compatible with 'i2c-gpio' and also nodes that are not direct childs of gpio controllers (tested with parts of an Atmel dts). The second patch changes the string identification for gpioiic(4) and gpioled(4) from 'gpioiic'/'gpioled' to 'freebsd,gpioiic' and 'freebsd,gpioled'. Did they look fine ? Thanks, Luiz --f46d0444ecaf21df5704f4ccf00f Content-Type: text/plain; charset=US-ASCII; name="gpioiic-linux-dts.diff" Content-Disposition: attachment; filename="gpioiic-linux-dts.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hsvr22830 SW5kZXg6IHN5cy9kZXYvZ3Bpby9ncGlvaWljLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2Rldi9ncGlv L2dwaW9paWMuYwkocmV2aXNpb24gMjYyMTMxKQorKysgc3lzL2Rldi9ncGlvL2dwaW9paWMuYwko d29ya2luZyBjb3B5KQpAQCAtNDEsOSArNDEsOSBAQAogI2luY2x1ZGUgImdwaW9idXNfaWYuaCIK IAogI2lmZGVmIEZEVAotI2luY2x1ZGUgPGRldi9vZncvb2Z3X2J1cy5oPgorI2luY2x1ZGUgPGRl di9mZHQvZmR0X2NvbW1vbi5oPgorI2luY2x1ZGUgPGRldi9ncGlvL2dwaW9idXN2YXIuaD4KICNp bmNsdWRlIDxkZXYvb2Z3L29md19idXNfc3Vici5oPgotI2luY2x1ZGUgPGRldi9mZHQvZmR0X2Nv bW1vbi5oPgogI2VuZGlmCiAKICNpbmNsdWRlIDxkZXYvaWljYnVzL2lpY29uZi5oPgpAQCAtNTQs NiArNTQsMTggQEAKICNkZWZpbmUJU0NMX1BJTl9ERUZBVUxUCTAJLyogZGVmYXVsdCBpbmRleCBv ZiBTQ0wgcGluIG9uIGdwaW9idXMgKi8KICNkZWZpbmUJU0RBX1BJTl9ERUZBVUxUCTEKIAorI2lm ZGVmIEZEVAorI2RlZmluZQlBVFRBQ0hfTk9ORQkwCisjZGVmaW5lCUFUVEFDSF9HUElPSUlDCTEK KyNkZWZpbmUJQVRUQUNIX0kyQ0dQSU8JMgorCitzdGF0aWMgc3RydWN0IG9md19jb21wYXRfZGF0 YSBjb21wYXRfZGF0YVtdID0geworCXsgImdwaW9paWMiLAkJQVRUQUNIX0dQSU9JSUMgfSwKKwl7 ICJpMmMtZ3BpbyIsCQlBVFRBQ0hfSTJDR1BJTyB9LAorCXsgTlVMTCwJCQlBVFRBQ0hfTk9ORSB9 LAorfTsKKyNlbmRpZgorCiBzdHJ1Y3QgZ3Bpb2lpY19zb2Z0YyAKIHsKIAlkZXZpY2VfdAlzY19k ZXY7CkBAIC03NCwxNCArODYsNDIgQEAKIHN0YXRpYyBpbnQgZ3Bpb2lpY19nZXRzY2woZGV2aWNl X3QpOwogc3RhdGljIGludCBncGlvaWljX3Jlc2V0KGRldmljZV90LCB1X2NoYXIsIHVfY2hhciwg dV9jaGFyICopOwogCisjaWZkZWYgRkRUCisvKgorICogVGhlIGlkZW50aWZ5KCkgbWV0aG9kIGlz IHVzZWQgaGVyZSB0byBnaXZlIGEgY2hhbmNlIHRvIGdwaW9paWMgdG8gdHJhdmVyc2UKKyAqIHRo ZSB3aG9sZSBEVEIgZGF0YSB0byBmaW5kIHRoZSBjb21wYXRpYmxlIG5vZGVzIHdoaWNoIGFyZSBu b3QgZGlyZWN0CisgKiBkZWNlbmRhbnRzIGZyb20gdGhlIGdwaW9idXMoNCkuICBUaGlzIGZvbGxv d3MgdGhlIGxpbnV4IHN0YW5kYXJkLgorICovCitzdGF0aWMgdm9pZAorZ3Bpb2lpY19pZGVudGlm eShkcml2ZXJfdCAqZHJpdmVyLCBkZXZpY2VfdCBidXMpCit7CisJcGhhbmRsZV90IGNoaWxkLCBy b290OwogCisJcm9vdCA9IE9GX2ZpbmRkZXZpY2UoIi8iKTsKKwlpZiAocm9vdCA9PSAwKQorCQly ZXR1cm47CisKKwkvKgorCSAqIFRyYXZlcnNlIGFsbCBjaGlsZHJlbiBvZiAncm9vdCcgbm9kZSwg ZmluZCB0aGUgb25lcyBjb21wYXRpYmxlCisJICogd2l0aCAnaTJjLWdwaW8nLgorICAgICAgICAg Ki8KKwlmb3IgKGNoaWxkID0gT0ZfY2hpbGQocm9vdCk7IGNoaWxkICE9IDA7IGNoaWxkID0gT0Zf cGVlcihjaGlsZCkpCisJCWlmIChmZHRfaXNfY29tcGF0aWJsZShjaGlsZCwgImkyYy1ncGlvIikg JiYKKwkJICAgIGZkdF9pc19jb21wYXRpYmxlX3N0cmljdChjaGlsZCwgImkyYy1ncGlvIikpCisJ CQlpZiAob2Z3X2dwaW9idXNfYWRkX2ZkdF9jaGlsZChidXMsIGNoaWxkKSA9PSBOVUxMKQorCQkJ CWNvbnRpbnVlOworfQorI2VuZGlmCisKIHN0YXRpYyBpbnQKIGdwaW9paWNfcHJvYmUoZGV2aWNl X3QgZGV2KQogeworI2lmZGVmIEZEVAorCWludCBtYXRjaDsKIAotI2lmZGVmIEZEVAotCWlmICgh b2Z3X2J1c19pc19jb21wYXRpYmxlKGRldiwgImdwaW9paWMiKSkKLQkJcmV0dXJuIChFTlhJTyk7 CisJbWF0Y2ggPSBvZndfYnVzX3NlYXJjaF9jb21wYXRpYmxlKGRldiwgY29tcGF0X2RhdGEpLT5v Y2RfZGF0YTsKKyAgICAgICAgaWYgKG1hdGNoID09IEFUVEFDSF9OT05FKQorICAgICAgICAgICAg ICAgIHJldHVybiAoRU5YSU8pOwogI2VuZGlmCiAJZGV2aWNlX3NldF9kZXNjKGRldiwgIkdQSU8g STJDIGJpdC1iYW5naW5nIGRyaXZlciIpOwogCkBAIC0yNjEsNiArMzAxLDkgQEAKIAlERVZNRVRI T0QoaWljYmJfcmVzZXQsCQlncGlvaWljX3Jlc2V0KSwKIAogI2lmZGVmIEZEVAorCS8qIERldmlj ZSBpbnRlcmZhY2UgKi8KKwlERVZNRVRIT0QoZGV2aWNlX2lkZW50aWZ5LAlncGlvaWljX2lkZW50 aWZ5KSwKKwogCS8qIE9GVyBidXMgaW50ZXJmYWNlICovCiAJREVWTUVUSE9EKG9md19idXNfZ2V0 X25vZGUsCWdwaW9paWNfZ2V0X25vZGUpLAogI2VuZGlmCkluZGV4OiBzaGFyZS9tYW4vbWFuNC9n cGlvaWljLjQKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQotLS0gc2hhcmUvbWFuL21hbjQvZ3Bpb2lpYy40CShyZXZpc2lv biAyNjIxMzEpCisrKyBzaGFyZS9tYW4vbWFuNC9ncGlvaWljLjQJKHdvcmtpbmcgY29weSkKQEAg LTI0LDcgKzI0LDcgQEAKIC5cIgogLlwiICRGcmVlQlNEJAogLlwiCi0uRGQgRmVicnVhcnkgMTMs IDIwMTQKKy5EZCBNYXJjaCAxMSwgMjAxNAogLkR0IEdQSU9JSUMgNAogLk9zCiAuU2ggTkFNRQpA QCAtMTE0LDEwICsxMTQsMzQgQEAKIH07CiAuRWQKIC5QcAorT3B0aW9uYWxseSB0aGUKKy5ObQor bm9kZSBjYW4gYmUgZGVzY3JpYmVkIHVuZGVyIHRoZSByb290IG5vZGUgd2l0aG91dCBiZWluZyBh IGRpcmVjdGx5IGRlc2NlbmRhbnQgb2YgYW55CisuWHIgZ3BpbyA0Citjb250cm9sbGVyOgorLkJk IC1saXRlcmFsCitzaW1wbGVidXMwIHsKKworCS4uLgorCisJaTJjQDAgeworCQljb21wYXRpYmxl ID0gImkyYy1ncGlvIjsKKwkJZ3Bpb3MgPSA8JkdQSU8gMyAxIDAKKyAgICAgICAgICAgICAgICAg ICAgICAgICAmR1BJTyAyIDEgMD47CisKKwkJLyogVGhpcyBpcyBhbm90aGVyIGV4YW1wbGUgb2Yg YSBncGlvaWljIGNoaWxkLiAqLworCQlncGlvaWljLWNoaWxkMCB7CisJCQljb21wYXRpYmxlID0g ImxtNzUiOworCQkJaTJjLWFkZHJlc3MgPSA8MHg0Zj47CisJCX07CisJfTsKK307CisuRWQKKy5Q cAogV2hlcmU6CiAuQmwgLXRhZyAtd2lkdGggIi5WYSBjb21wYXRpYmxlIgogLkl0IFZhIGNvbXBh dGlibGUKLVNob3VsZCBhbHdheXMgYmUgc2V0IHRvICJncGlvaWljIi4KK1Nob3VsZCBiZSBzZXQg dG8gImdwaW9paWMiIG9yICJpMmMtZ3BpbyIuCiAuSXQgVmEgZ3Bpb3MKIFRoZQogLlZhIGdwaW9z Cg== --f46d0444ecaf21df5704f4ccf00f Content-Type: text/plain; charset=US-ASCII; name="gpioiic-gpioled-freebsd-specific.diff" Content-Disposition: attachment; filename="gpioiic-gpioled-freebsd-specific.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hsvr29wf1 SW5kZXg6IHN5cy9kZXYvZ3Bpby9ncGlvbGVkLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2Rldi9ncGlv L2dwaW9sZWQuYwkocmV2aXNpb24gMjYyMTMxKQorKysgc3lzL2Rldi9ncGlvL2dwaW9sZWQuYwko d29ya2luZyBjb3B5KQpAQCAtMTI4LDcgKzEyOCw3IEBACiAJICogbGVkcyBub2RlcyBvbiB0aGUg ZHRzLgogCSAqLwogCW1hdGNoID0gMDsKLQlpZiAob2Z3X2J1c19pc19jb21wYXRpYmxlKGRldiwg ImdwaW9sZWQiKSkKKwlpZiAob2Z3X2J1c19pc19jb21wYXRpYmxlKGRldiwgImZyZWVic2QsZ3Bp b2xlZCIpKQogCQltYXRjaCA9IDE7CiAKIAlpZiAobWF0Y2ggPT0gMCkgewotLS0gc3lzL2Rldi9n cGlvL2dwaW9paWMuYy5vcmlnCTIwMTQtMDMtMTEgMTU6MjI6MzMuMjkxOTc4OTc1IC0wMzAwCisr KyBzeXMvZGV2L2dwaW8vZ3Bpb2lpYy5jCTIwMTQtMDMtMTEgMTU6MjM6MTAuODA5OTc2MDYzIC0w MzAwCkBAIC02MCw3ICs2MCw3IEBACiAjZGVmaW5lCUFUVEFDSF9JMkNHUElPCTIKIAogc3RhdGlj IHN0cnVjdCBvZndfY29tcGF0X2RhdGEgY29tcGF0X2RhdGFbXSA9IHsKLQl7ICJncGlvaWljIiwJ CUFUVEFDSF9HUElPSUlDIH0sCisJeyAiZnJlZWJzZCxncGlvaWljIiwJQVRUQUNIX0dQSU9JSUMg fSwKIAl7ICJpMmMtZ3BpbyIsCQlBVFRBQ0hfSTJDR1BJTyB9LAogCXsgTlVMTCwJCQlBVFRBQ0hf Tk9ORSB9LAogfTsKSW5kZXg6IHNoYXJlL21hbi9tYW40L2dwaW9sZWQuNAo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0t LSBzaGFyZS9tYW4vbWFuNC9ncGlvbGVkLjQJKHJldmlzaW9uIDI2MjEzMSkKKysrIHNoYXJlL21h bi9tYW40L2dwaW9sZWQuNAkod29ya2luZyBjb3B5KQpAQCAtMjQsNyArMjQsNyBAQAogLlwiCiAu XCIgJEZyZWVCU0QkCiAuXCIKLS5EZCBGZWJydWFyeSAxMywgMjAxNAorLkRkIE1hcmNoIDExLCAy MDE0CiAuRHQgR1BJT0xFRCA0CiAuT3MKIC5TaCBOQU1FCkBAIC04MiwxMyArODIsMTMgQEAKIAku Li4KIAogCWxlZDAgewotCQljb21wYXRpYmxlID0gImdwaW9sZWQiOworCQljb21wYXRpYmxlID0g ImZyZWVic2QsZ3Bpb2xlZCI7CiAJCWdwaW9zID0gPCZncGlvIDE2IDIgMD47CQkvKiBHUElPIHBp biAxNi4gKi8KIAkJbmFtZSA9ICJvayI7CiAJfTsKIAogCWxlZDEgewotCQljb21wYXRpYmxlID0g ImdwaW9sZWQiOworCQljb21wYXRpYmxlID0gImZyZWVic2QsZ3Bpb2xlZCI7CiAJCWdwaW9zID0g PCZncGlvIDE3IDIgMD47CQkvKiBHUElPIHBpbiAxNy4gKi8KIAkJbmFtZSA9ICJ1c2VyLWxlZDEi OwogCX07Ci0tLSBzaGFyZS9tYW4vbWFuNC9ncGlvaWljLjQub3JpZwkyMDE0LTAzLTE2IDEwOjQ2 OjQxLjU4MjQ4NDE3OSAtMDMwMAorKysgc2hhcmUvbWFuL21hbjQvZ3Bpb2lpYy40CTIwMTQtMDMt MTYgMTA6NDY6MTguNTU3NDg0NDUzIC0wMzAwCkBAIC05NSw3ICs5NSw3IEBACiAJLi4uCiAKIAln cGlvaWljMCB7Ci0JCWNvbXBhdGlibGUgPSAiZ3Bpb2lpYyI7CisJCWNvbXBhdGlibGUgPSAiZnJl ZWJzZCxncGlvaWljIjsKIAkJLyoKIAkJICogQXR0YWNoIHRvIEdQSU8gcGlucyAyMSBhbmQgMjIu ICBTZXQgdGhlbQogCQkgKiBpbml0aWFsbHkgYXMgaW5wdXRzLgpAQCAtMTA3LDcgKzEwNyw3IEBA CiAKIAkJLyogVGhpcyBpcyBhbiBleGFtcGxlIG9mIGEgZ3Bpb2lpYyBjaGlsZC4gKi8KIAkJZ3Bp b2lpYy1jaGlsZDAgewotCQkJY29tcGF0aWJsZSA9ICJsbTc1IjsKKwkJCWNvbXBhdGlibGUgPSAi ZnJlZWJzZCxsbTc1IjsKIAkJCWkyYy1hZGRyZXNzID0gPDB4NGY+OwogCQl9OwogCX07CkBAIC0x MzEsNyArMTMxLDcgQEAKIAogCQkvKiBUaGlzIGlzIGFub3RoZXIgZXhhbXBsZSBvZiBhIGdwaW9p aWMgY2hpbGQuICovCiAJCWdwaW9paWMtY2hpbGQwIHsKLQkJCWNvbXBhdGlibGUgPSAibG03NSI7 CisJCQljb21wYXRpYmxlID0gImZyZWVic2QsbG03NSI7CiAJCQlpMmMtYWRkcmVzcyA9IDwweDRm PjsKIAkJfTsKIAl9OwpAQCAtMTQxLDcgKzE0MSw3IEBACiBXaGVyZToKIC5CbCAtdGFnIC13aWR0 aCAiLlZhIGNvbXBhdGlibGUiCiAuSXQgVmEgY29tcGF0aWJsZQotU2hvdWxkIGJlIHNldCB0byAi Z3Bpb2lpYyIgb3IgImkyYy1ncGlvIi4KK1Nob3VsZCBiZSBzZXQgdG8gImZyZWVic2QsZ3Bpb2lp YyIgb3IgImkyYy1ncGlvIi4KIC5JdCBWYSBncGlvcwogVGhlCiAuVmEgZ3Bpb3MK --f46d0444ecaf21df5704f4ccf00f-- From owner-freebsd-embedded@FreeBSD.ORG Mon Mar 17 13:31:57 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 74509318; Mon, 17 Mar 2014 13:31:57 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B0701368; Mon, 17 Mar 2014 13:31:56 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id cc10so2152779wib.4 for ; Mon, 17 Mar 2014 06:31:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=aRoczenZ3BV+5U6wqvyC8hIzYvNtMrcV5cCmZWyy/7A=; b=d8D7kgntvMLQYDsP5Biq/BI+fI9Lad83SguZDxD+DDOlxZv/09bd5nHhWf+yM5A6/b oGwe41Y4BdTsbytljsAjZFHkmgu30x7CNSeww002LxQUot7OFbWXARZvqoWr/pDq0brU B4i7NZWl/eKAepoSzOfAJvwW9ltVqMEXCojb3lnyw43dVdJSBJZVNJNzVT26cw6swGTc gIBjYX85zaObYTxJuX+gOg7+WgapO2xf31OJ7ZcazV1QQf4ZruRbvA4viQenoa5k0Gpa PLVZgfpJlYrxd4robq74OPC/A2wU7KNg5yVqApBkshI3wtR0LhxP0h6OEzah+bs0fBmA rN8Q== MIME-Version: 1.0 X-Received: by 10.180.21.225 with SMTP id y1mr9602005wie.24.1395063115145; Mon, 17 Mar 2014 06:31:55 -0700 (PDT) Received: by 10.216.79.132 with HTTP; Mon, 17 Mar 2014 06:31:54 -0700 (PDT) Date: Mon, 17 Mar 2014 10:31:54 -0300 Message-ID: Subject: [RFC] AM335x (Beaglebone-black) ADC driver From: Luiz Otavio O Souza To: freebsd-arm@freebsd.org, "freebsd-embedded@freebsd.org" Content-Type: multipart/mixed; boundary=047d7bb709886b3cc004f4cd7118 X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 13:31:57 -0000 --047d7bb709886b3cc004f4cd7118 Content-Type: text/plain; charset=ISO-8859-1 Hi, I've written a driver for the am335x ADC module (AIN inputs on BBB). It works from the sysctl(8) interface, each input can be individually enabled/disabled. When all the inputs are disabled, the ADC is turned off. The sysctl(8) interface also allows the selection of the number of the samples average for each input (none, 2, 4, 8, 16) and the setting of the ADC prescaler value (low clock speeds gives far stable readings with the cost of loading - sometimes too much - the input circuit as conversions can take a long time). The converted values are exported as raw values (12 bits - 0 ~ 4095). The ADC module can also work as a touchscreen sensor, but i have no idea how to program the module as TSC sensor neither have the hardware to test it, so this driver only works for reading the AIN converted values. Here is the output of the sysctl(8) for this driver: # sysctl dev.am335x_adc.0 dev.am335x_adc.0.%desc: AM335x ADC controller dev.am335x_adc.0.%driver: am335x_adc dev.am335x_adc.0.%pnpinfo: name=adc@44E0D000 compat=ti,am335x-adc dev.am335x_adc.0.%parent: simplebus0 dev.am335x_adc.0.clockdiv: 30000 dev.am335x_adc.0.ain.0.enable: 0 dev.am335x_adc.0.ain.0.samples_avg: 0 dev.am335x_adc.0.ain.0.input: 0 dev.am335x_adc.0.ain.1.enable: 0 dev.am335x_adc.0.ain.1.samples_avg: 0 dev.am335x_adc.0.ain.1.input: 0 dev.am335x_adc.0.ain.2.enable: 0 dev.am335x_adc.0.ain.2.samples_avg: 0 dev.am335x_adc.0.ain.2.input: 0 dev.am335x_adc.0.ain.3.enable: 0 dev.am335x_adc.0.ain.3.samples_avg: 0 dev.am335x_adc.0.ain.3.input: 0 dev.am335x_adc.0.ain.4.enable: 0 dev.am335x_adc.0.ain.4.samples_avg: 0 dev.am335x_adc.0.ain.4.input: 0 dev.am335x_adc.0.ain.5.enable: 0 dev.am335x_adc.0.ain.5.samples_avg: 0 dev.am335x_adc.0.ain.5.input: 0 dev.am335x_adc.0.ain.6.enable: 1 dev.am335x_adc.0.ain.6.samples_avg: 0 dev.am335x_adc.0.ain.6.input: 2176 I've checked the 7 AINs with a potentiometer connected to them (and using VDD_ADC and GNDA_ADC). I am now writing the man page so i can ask for a approval to commit it. Comments ? Regards, Luiz --047d7bb709886b3cc004f4cd7118 Content-Type: text/plain; charset=US-ASCII; name="am335x_adc.diff" Content-Disposition: attachment; filename="am335x_adc.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hsvse87w0 SW5kZXg6IHN5cy9hcm0vdGkvYW0zMzV4L2FtMzM1eF9wcmNtLmMKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lz L2FybS90aS9hbTMzNXgvYW0zMzV4X3ByY20uYwkocmV2aXNpb24gMjYyMTMxKQorKysgc3lzL2Fy bS90aS9hbTMzNXgvYW0zMzV4X3ByY20uYwkod29ya2luZyBjb3B5KQpAQCAtMTA3LDYgKzEwNyw3 IEBACiAjZGVmaW5lIENNX1dLVVBfQ01fQ0xLRENPTERPX0RQTExfUEVSCShDTV9XS1VQICsgMHgw N0MpCiAjZGVmaW5lIENNX1dLVVBfQ01fQ0xLTU9ERV9EUExMX0RJU1AJKENNX1dLVVAgKyAweDA5 OCkKICNkZWZpbmUgQ01fV0tVUF9JMkMwX0NMS0NUUkwJCShDTV9XS1VQICsgMHgwQjgpCisjZGVm aW5lIENNX1dLVVBfQURDX1RTQ19DTEtDVFJMCQkoQ01fV0tVUCArIDB4MEJDKQogCiAjZGVmaW5l IENNX0RQTEwJCQkJMHg1MDAKICNkZWZpbmUgQ0xLU0VMX1RJTUVSN19DTEsJCShDTV9EUExMICsg MHgwMDQpCkBAIC0yNjAsNiArMjYxLDkgQEAKIAlBTTMzNVhfR0VORVJJQ19DTE9DS19ERVYoSTJD MV9DTEspLAogCUFNMzM1WF9HRU5FUklDX0NMT0NLX0RFVihJMkMyX0NMSyksCiAKKwkvKiBUU0Nf QURDICovCisJQU0zMzVYX0dFTkVSSUNfQ0xPQ0tfREVWKFRTQ19BRENfQ0xLKSwKKwogCS8qIEVE TUEgKi8KIAlBTTMzNVhfR0VORVJJQ19DTE9DS19ERVYoRURNQV9UUENDX0NMSyksCiAJQU0zMzVY X0dFTkVSSUNfQ0xPQ0tfREVWKEVETUFfVFBUQzBfQ0xLKSwKQEAgLTMzNyw2ICszNDEsOSBAQAog CV9DTEtfREVUQUlMKEkyQzFfQ0xLLCBDTV9QRVJfSTJDMV9DTEtDVFJMLCAwKSwKIAlfQ0xLX0RF VEFJTChJMkMyX0NMSywgQ01fUEVSX0kyQzJfQ0xLQ1RSTCwgMCksCiAKKwkvKiBUU0NfQURDIG1v ZHVsZSAqLworCV9DTEtfREVUQUlMKFRTQ19BRENfQ0xLLCBDTV9XS1VQX0FEQ19UU0NfQ0xLQ1RS TCwgMCksCisKIAkvKiBFRE1BIG1vZHVsZXMgKi8KIAlfQ0xLX0RFVEFJTChFRE1BX1RQQ0NfQ0xL LCBDTV9QRVJfVFBDQ19DTEtDVFJMLCAwKSwKIAlfQ0xLX0RFVEFJTChFRE1BX1RQVEMwX0NMSywg Q01fUEVSX1RQVEMwX0NMS0NUUkwsIDApLApJbmRleDogc3lzL2FybS90aS9hbTMzNXgvZmlsZXMu YmVhZ2xlYm9uZQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvYXJtL3RpL2FtMzM1eC9maWxlcy5iZWFnbGVi b25lCShyZXZpc2lvbiAyNjIxMzEpCisrKyBzeXMvYXJtL3RpL2FtMzM1eC9maWxlcy5iZWFnbGVi b25lCSh3b3JraW5nIGNvcHkpCkBAIC0xLDMgKzEsNCBAQAogIyRGcmVlQlNEJAogCithcm0vdGkv YW0zMzV4L2FtMzM1eF9hZGMuYwkJCW9wdGlvbmFsCWFtMzM1eF9hZGMKIGFybS90aS9hbTMzNXgv YW0zMzV4X3BtaWMuYwkJCW9wdGlvbmFsCWFtMzM1eF9wbWljCkluZGV4OiBzeXMvYXJtL3RpL3Rp X3ByY20uaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvYXJtL3RpL3RpX3ByY20uaAkocmV2aXNpb24gMjYy MTMxKQorKysgc3lzL2FybS90aS90aV9wcmNtLmgJKHdvcmtpbmcgY29weSkKQEAgLTE2Miw2ICsx NjIsOCBAQAogCiAJUFJVU1NfQ0xLID0gMTcwMCwKIAorCVRTQ19BRENfQ0xLID0gMTgwMCwKKwog CUlOVkFMSURfQ0xLX0lERU5UCiAKIH0gY2xrX2lkZW50X3Q7Ci0tLSAvZGV2L251bGwJMjAxNC0w My0xNiAxMTowMDowMC4wMDAwMDAwMDAgLTAzMDAKKysrIHN5cy9hcm0vdGkvYW0zMzV4L2FtMzM1 eF9hZGMuYwkyMDE0LTAzLTE1IDIzOjQ4OjM3LjA5OTIwNTgwMyAtMDMwMApAQCAtMCwwICsxLDQ5 NyBAQAorLyotCisgKiBDb3B5cmlnaHQgMjAxNCBMdWl6IE90YXZpbyBPIFNvdXphIDxsb29zQGZy ZWVic2Qub3JnPgorICogQWxsIHJpZ2h0cyByZXNlcnZlZC4KKyAqCisgKiBSZWRpc3RyaWJ1dGlv biBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKKyAq IG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcg Y29uZGl0aW9ucworICogYXJlIG1ldDoKKyAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2Ug Y29kZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMg bGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIuCisgKiAyLiBS ZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNv cHlyaWdodAorICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZv bGxvd2luZyBkaXNjbGFpbWVyIGluIHRoZQorICogICAgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3Ro ZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlIGRpc3RyaWJ1dGlvbi4KKyAqCisgKiBUSElT IFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBBVVRIT1IgQU5EIENPTlRSSUJVVE9SUyBgYEFT IElTJycgQU5ECisgKiBBTlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElO RywgQlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUKKyAqIElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJD SEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFCisgKiBBUkUg RElTQ0xBSU1FRC4gIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBBVVRIT1IgT1IgQ09OVFJJQlVUT1JT IEJFIExJQUJMRQorICogRk9SIEFOWSBESVJFQ1QsIElORElSRUNULCBJTkNJREVOVEFMLCBTUEVD SUFMLCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwKKyAqIERBTUFHRVMgKElOQ0xVRElORywg QlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTCisgKiBP UiBTRVJWSUNFUzsgTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNTIElO VEVSUlVQVElPTikKKyAqIEhPV0VWRVIgQ0FVU0VEIEFORCBPTiBBTlkgVEhFT1JZIE9GIExJQUJJ TElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUCisgKiBMSUFCSUxJVFksIE9SIFRPUlQg KElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZCisg KiBPVVQgT0YgVEhFIFVTRSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhF IFBPU1NJQklMSVRZIE9GCisgKiBTVUNIIERBTUFHRS4KKyAqLworCisjaW5jbHVkZSA8c3lzL2Nk ZWZzLmg+CitfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CisKKyNpbmNsdWRlIDxzeXMvcGFyYW0uaD4K KyNpbmNsdWRlIDxzeXMvc3lzdG0uaD4KKyNpbmNsdWRlIDxzeXMvYnVzLmg+CisKKyNpbmNsdWRl IDxzeXMva2VybmVsLmg+CisjaW5jbHVkZSA8c3lzL2xvY2suaD4KKyNpbmNsdWRlIDxzeXMvbW9k dWxlLmg+CisjaW5jbHVkZSA8c3lzL211dGV4Lmg+CisjaW5jbHVkZSA8c3lzL3Jlc291cmNlLmg+ CisjaW5jbHVkZSA8c3lzL3JtYW4uaD4KKyNpbmNsdWRlIDxzeXMvc3lzY3RsLmg+CisKKyNpbmNs dWRlIDxtYWNoaW5lL2J1cy5oPgorCisjaW5jbHVkZSA8ZGV2L29mdy9vcGVuZmlybS5oPgorI2lu Y2x1ZGUgPGRldi9vZncvb2Z3X2J1cy5oPgorI2luY2x1ZGUgPGRldi9vZncvb2Z3X2J1c19zdWJy Lmg+CisKKyNpbmNsdWRlIDxhcm0vdGkvdGlfcHJjbS5oPgorI2luY2x1ZGUgPGFybS90aS9hbTMz NXgvYW0zMzV4X2FkY3JlZy5oPgorI2luY2x1ZGUgPGFybS90aS9hbTMzNXgvYW0zMzV4X2FkY3Zh ci5oPgorCisvKiBEZWZpbmUgb3VyIDcgc3RlcHMsIG9uZSBmb3IgZWFjaCBpbnB1dCBjaGFubmVs LiAqLworc3RhdGljIHN0cnVjdCBhbTMzNXhfYWRjX2lucHV0IGFtMzM1eF9hZGNfaW5wdXRzW0FN MzM1WF9BRENfTlBJTlNdID0geworCXsgLnN0ZXByZWcgPSBBRENfU1RFUENGRzEsIH0sCisJeyAu c3RlcHJlZyA9IEFEQ19TVEVQQ0ZHMiwgfSwKKwl7IC5zdGVwcmVnID0gQURDX1NURVBDRkczLCB9 LAorCXsgLnN0ZXByZWcgPSBBRENfU1RFUENGRzQsIH0sCisJeyAuc3RlcHJlZyA9IEFEQ19TVEVQ Q0ZHNSwgfSwKKwl7IC5zdGVwcmVnID0gQURDX1NURVBDRkc2LCB9LAorCXsgLnN0ZXByZWcgPSBB RENfU1RFUENGRzcsIH0sCit9OworCitzdGF0aWMgaW50IGFtMzM1eF9hZGNfc2FtcGxlc1s1XSA9 IHsgMCwgMiwgNCwgOCwgMTYgfTsKKworc3RhdGljIHZvaWQKK2FtMzM1eF9hZGNfZW5hYmxlKHN0 cnVjdCBhbTMzNXhfYWRjX3NvZnRjICpzYykKK3sKKwl1aW50MzJfdCB2YWw7CisKKwlBTTMzNVhf QURDX0xPQ0tfQVNTRVJUKHNjKTsKKworCS8qIEVuYWJsZSB0aGUgRklGTzAgdGhyZXNob2xkIGlu dGVycnVwdC4gKi8KKwlBRENfV1JJVEU0KHNjLCBBRENfSVJRRU5BQkxFX1NFVCwgQURDX0lSUV9G SUZPMF9USFJFUyk7CisKKwkvKiBFbmFibGUgdGhlIEFEQy4gIFJ1biB0aHJ1IGVuYWJsZWQgc3Rl cHMsIHN0YXJ0IHRoZSBjb252ZXJ0aW9ucy4gKi8KKwl2YWwgPSBBRENfUkVBRDQoc2MsIEFEQ19D VFJMKTsKKwlBRENfV1JJVEU0KHNjLCBBRENfQ1RSTCwgdmFsIHwgQURDX0NUUkxfRU5BQkxFKTsK K30KKworc3RhdGljIHZvaWQKK2FtMzM1eF9hZGNfZGlzYWJsZShzdHJ1Y3QgYW0zMzV4X2FkY19z b2Z0YyAqc2MpCit7CisJdWludDMyX3QgdmFsOworCisJQU0zMzVYX0FEQ19MT0NLX0FTU0VSVChz Yyk7CisKKwkvKiBEaXNhYmxlIHRoZSBGSUZPMCB0aHJlc2hvbGQgaW50ZXJydXB0LiAqLworCUFE Q19XUklURTQoc2MsIEFEQ19JUlFFTkFCTEVfQ0xSLCBBRENfSVJRX0ZJRk8wX1RIUkVTKTsKKwor CS8qIERpc2FibGUgdGhlIEFEQy4gKi8KKwl2YWwgPSBBRENfUkVBRDQoc2MsIEFEQ19DVFJMKTsK Kwl2YWwgJj0gfkFEQ19DVFJMX0VOQUJMRTsKKwlBRENfV1JJVEU0KHNjLCBBRENfQ1RSTCwgdmFs KTsKK30KKworc3RhdGljIHZvaWQKK2FtMzM1eF9hZGNfZW5hYmxlX2lucHV0KHN0cnVjdCBhbTMz NXhfYWRjX3NvZnRjICpzYywgaW50MzJfdCBpbnB1dCkKK3sKKwl1aW50MzJfdCByZWcsIHZhbDsK KworCUFNMzM1WF9BRENfTE9DS19BU1NFUlQoc2MpOworCisJcmVnID0gYW0zMzV4X2FkY19pbnB1 dHNbaW5wdXRdLnN0ZXByZWc7CisJdmFsID0gQURDX1JFQUQ0KHNjLCByZWcpOworCisJLyogU2V0 IHRoZSBuZWdhdGl2ZSB2b2x0YWdlIHJlZmVyZW5jZS4gKi8KKwl2YWwgJj0gfkFEQ19TVEVQX1JG TV9NU0s7CisJdmFsIHw9IEFEQ19TVEVQX1JGTV9WUkVGTiA8PCBBRENfU1RFUF9SRk1fU0hJRlQ7 CisKKwkvKiBTZXQgdGhlIHBvc2l0aXZlIHZvbHRhZ2UgcmVmZXJlbmNlLiAqLworCXZhbCAmPSB+ QURDX1NURVBfUkZQX01TSzsKKwl2YWwgfD0gQURDX1NURVBfUkZQX1ZSRUZQIDw8IEFEQ19TVEVQ X1JGUF9TSElGVDsKKworCS8qIFNldCB0aGUgc2FtcGxlcyBhdmVyYWdlLiAqLworCXZhbCAmPSB+ QURDX1NURVBfQVZHX01TSzsKKwl2YWwgfD0gYW0zMzV4X2FkY19pbnB1dHNbaW5wdXRdLnNhbXBs ZXMgPDwgQURDX1NURVBfQVZHX1NISUZUOworCisJLyogU2VsZWN0IHRoZSBkZXNpcmVkIGlucHV0 LiAqLworCXZhbCAmPSB+QURDX1NURVBfSU5QX01TSzsKKwl2YWwgfD0gaW5wdXQgPDwgQURDX1NU RVBfSU5QX1NISUZUOworCisJLyogU2V0IHRoZSBBREMgdG8gY29udGludW91cyBtb2RlLiAqLwor CXZhbCAmPSB+QURDX1NURVBfTU9ERV9NU0s7CisJdmFsIHw9IEFEQ19TVEVQX01PREVfQ09OVElO VU9VUzsKKworCUFEQ19XUklURTQoc2MsIHJlZywgdmFsKTsKK30KKworc3RhdGljIHZvaWQKK2Ft MzM1eF9hZGNfZGlzYWJsZV9pbnB1dChzdHJ1Y3QgYW0zMzV4X2FkY19zb2Z0YyAqc2MsIGludDMy X3QgaW5wdXQpCit7CisJdWludDMyX3QgcmVnLCB2YWw7CisKKwlBTTMzNVhfQURDX0xPQ0tfQVNT RVJUKHNjKTsKKworCS8qIFJlc2V0IHRoZSBpbnB1dCByZWFkIGRhdGEuICovCisJYW0zMzV4X2Fk Y19pbnB1dHNbaW5wdXRdLnZhbHVlID0gMDsKKworCXJlZyA9IGFtMzM1eF9hZGNfaW5wdXRzW2lu cHV0XS5zdGVwcmVnOworCXZhbCA9IEFEQ19SRUFENChzYywgcmVnKTsKKworCS8qIFJlc2V0IHRo ZSBBREMgb3BlcmF0aW9uIG1vZGUuICovCisJdmFsICY9IH5BRENfU1RFUF9NT0RFX01TSzsKKwor CS8qIFJlc2V0IHRoZSBpbnB1dCBwaW4gc2VsZWN0aW9uLiAqLworCXZhbCAmPSB+QURDX1NURVBf SU5QX01TSzsKKworCS8qIFJlc2V0IHRoZSBzYW1wbGVzIGF2ZXJhZ2UuICovCisJdmFsICY9IH5B RENfU1RFUF9BVkdfTVNLOworCisJLyogUmVzZXQgdGhlIHBvc2l0aXZlIHZvbHRhZ2UgcmVmZXJl bmNlLiAqLworCXZhbCAmPSB+QURDX1NURVBfUkZQX01TSzsKKworCS8qIFJlc2V0IHRoZSBuZWdh dGl2ZSB2b2x0YWdlIHJlZmVyZW5jZS4gKi8KKwl2YWwgJj0gfkFEQ19TVEVQX1JGTV9NU0s7CisK KwlBRENfV1JJVEU0KHNjLCByZWcsIHZhbCk7Cit9CisKK3N0YXRpYyB2b2lkCithbTMzNXhfYWRj X3Jlc2V0KHN0cnVjdCBhbTMzNXhfYWRjX3NvZnRjICpzYykKK3sKKwlpbnQgaTsKKworCUFNMzM1 WF9BRENfTE9DS19BU1NFUlQoc2MpOworCisJLyogRGlzYWJsZSBhbGwgdGhlIGlucHV0cy4gKi8K Kwlmb3IgKGkgPSAwOyBpIDwgQU0zMzVYX0FEQ19OUElOUzsgaSsrKQorCQlhbTMzNXhfYWRjX2lu cHV0c1tpXS5lbmFibGUgPSAwOworfQorCitzdGF0aWMgaW50CithbTMzNXhfYWRjX3NldHVwKHN0 cnVjdCBhbTMzNXhfYWRjX3NvZnRjICpzYykKK3sKKwlpbnQgZW5hYmxlZCwgaTsKKworCUFNMzM1 WF9BRENfTE9DS19BU1NFUlQoc2MpOworCisJLyogQ2hlY2sgaWYgd2UgaGF2ZSBhbnkgaW5wdXQg ZW5hYmxlZC4gKi8KKwllbmFibGVkID0gMDsKKwlmb3IgKGkgPSAwOyBpIDwgQU0zMzVYX0FEQ19O UElOUzsgaSsrKSB7CisJCWlmIChhbTMzNXhfYWRjX2lucHV0c1tpXS5lbmFibGUpIHsKKwkJCWVu YWJsZWQgfD0gKDFVIDw8IChpICsgMSkpOworCQkJYW0zMzV4X2FkY19lbmFibGVfaW5wdXQoc2Ms IGkpOworCQl9IGVsc2UKKwkJCWFtMzM1eF9hZGNfZGlzYWJsZV9pbnB1dChzYywgaSk7CisJfQor CisJLyogRW5hYmxlIHRoZSBzZWxlY3RlZCBzdGVwcy4gKi8KKwlBRENfV1JJVEU0KHNjLCBBRENf U1RFUEVOQUJMRSwgZW5hYmxlZCk7CisKKwkvKiBTZXQgdGhlIGdsb2JhbCBBREMgc3RhdHVzLiAq LworCWlmIChlbmFibGVkICE9IDApCisJCWFtMzM1eF9hZGNfZW5hYmxlKHNjKTsKKwllbHNlCisJ CWFtMzM1eF9hZGNfZGlzYWJsZShzYyk7CisKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgaW50 CithbTMzNXhfYWRjX2Nsb2NrZGl2X3Byb2MoU1lTQ1RMX0hBTkRMRVJfQVJHUykKK3sKKwlpbnQg ZXJyb3IsIHJlZzsKKwlzdHJ1Y3QgYW0zMzV4X2FkY19zb2Z0YyAqc2M7CisKKwlzYyA9IChzdHJ1 Y3QgYW0zMzV4X2FkY19zb2Z0YyAqKWFyZzE7CisKKwlBTTMzNVhfQURDX0xPQ0soc2MpOworCXJl ZyA9IChpbnQpQURDX1JFQUQ0KHNjLCBBRENfQ0xLRElWKSArIDE7CisJQU0zMzVYX0FEQ19VTkxP Q0soc2MpOworCisJZXJyb3IgPSBzeXNjdGxfaGFuZGxlX2ludChvaWRwLCAmcmVnLCBzaXplb2Yo cmVnKSwgcmVxKTsKKwlpZiAoZXJyb3IgIT0gMCB8fCByZXEtPm5ld3B0ciA9PSBOVUxMKQorCQly ZXR1cm4gKGVycm9yKTsKKworCS8qIFRoZSBhY3R1YWwgd3JpdHRlbiB2YWx1ZSBpcyB0aGUgcHJl c2NhbGVyIHNldHRpbmcgLSAxLiAqLworCXJlZy0tOworCWlmIChyZWcgPCAwKQorCQlyZWcgPSAw OworCWlmIChyZWcgPiA2NTUzNSkKKwkJcmVnID0gNjU1MzU7CisKKwlBTTMzNVhfQURDX0xPQ0so c2MpOworCS8qIERpc2FibGUgdGhlIEFEQy4gKi8KKwlhbTMzNXhfYWRjX2Rpc2FibGUoc2MpOwor CS8qIFVwZGF0ZSB0aGUgQURDIHByZXNjYWxlciBzZXR0aW5nLiAqLworCUFEQ19XUklURTQoc2Ms IEFEQ19DTEtESVYsIHJlZyk7CisJLyogRW5hYmxlIHRoZSBBREMgYWdhaW4uICovCisJYW0zMzV4 X2FkY19zZXR1cChzYyk7CisJQU0zMzVYX0FEQ19VTkxPQ0soc2MpOworCisJcmV0dXJuICgwKTsK K30KKworc3RhdGljIGludAorYW0zMzV4X2FkY19lbmFibGVfcHJvYyhTWVNDVExfSEFORExFUl9B UkdTKQoreworCWludCBlcnJvcjsKKwlpbnQzMl90IGVuYWJsZTsKKwlzdHJ1Y3QgYW0zMzV4X2Fk Y19zb2Z0YyAqc2M7CisJc3RydWN0IGFtMzM1eF9hZGNfaW5wdXQgKmlucHV0OworCisJaW5wdXQg PSAoc3RydWN0IGFtMzM1eF9hZGNfaW5wdXQgKilhcmcxOworCXNjID0gaW5wdXQtPnNjOworCisJ ZW5hYmxlID0gaW5wdXQtPmVuYWJsZTsKKwllcnJvciA9IHN5c2N0bF9oYW5kbGVfaW50KG9pZHAs ICZlbmFibGUsIHNpemVvZihlbmFibGUpLAorCSAgICByZXEpOworCWlmIChlcnJvciAhPSAwIHx8 IHJlcS0+bmV3cHRyID09IE5VTEwpCisJCXJldHVybiAoZXJyb3IpOworCisJaWYgKGVuYWJsZSkK KwkJZW5hYmxlID0gMTsKKworCUFNMzM1WF9BRENfTE9DSyhzYyk7CisJLyogU2V0dXAgdGhlIEFE QyBhcyBuZWVkZWQuICovCisJaWYgKGlucHV0LT5lbmFibGUgIT0gZW5hYmxlKSB7CisJCWlucHV0 LT5lbmFibGUgPSBlbmFibGU7CisJCWFtMzM1eF9hZGNfc2V0dXAoc2MpOworCX0KKwlBTTMzNVhf QURDX1VOTE9DSyhzYyk7CisKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgaW50CithbTMzNXhf YWRjX3NhbXBsZXNfYXZnX3Byb2MoU1lTQ1RMX0hBTkRMRVJfQVJHUykKK3sKKwlpbnQgZXJyb3Is IHNhbXBsZXMsIGk7CisJc3RydWN0IGFtMzM1eF9hZGNfc29mdGMgKnNjOworCXN0cnVjdCBhbTMz NXhfYWRjX2lucHV0ICppbnB1dDsKKworCWlucHV0ID0gKHN0cnVjdCBhbTMzNXhfYWRjX2lucHV0 ICopYXJnMTsKKwlzYyA9IGlucHV0LT5zYzsKKworCWlmIChpbnB1dC0+c2FtcGxlcyA+IG5pdGVt cyhhbTMzNXhfYWRjX3NhbXBsZXMpKQorCQlpbnB1dC0+c2FtcGxlcyA9IG5pdGVtcyhhbTMzNXhf YWRjX3NhbXBsZXMpOworCXNhbXBsZXMgPSBhbTMzNXhfYWRjX3NhbXBsZXNbaW5wdXQtPnNhbXBs ZXNdOworCisJZXJyb3IgPSBzeXNjdGxfaGFuZGxlX2ludChvaWRwLCAmc2FtcGxlcywgMCwgcmVx KTsKKwlpZiAoZXJyb3IgIT0gMCB8fCByZXEtPm5ld3B0ciA9PSBOVUxMKQorCQlyZXR1cm4gKGVy cm9yKTsKKworCWlmIChzYW1wbGVzICE9IGFtMzM1eF9hZGNfc2FtcGxlc1tpbnB1dC0+c2FtcGxl c10pIHsKKwkJQU0zMzVYX0FEQ19MT0NLKHNjKTsKKwkJYW0zMzV4X2FkY19kaXNhYmxlKHNjKTsK KwkJaW5wdXQtPnNhbXBsZXMgPSAwOworCQlmb3IgKGkgPSAwOyBpIDwgbml0ZW1zKGFtMzM1eF9h ZGNfc2FtcGxlcyk7IGkrKykKKwkJCWlmIChzYW1wbGVzID49IGFtMzM1eF9hZGNfc2FtcGxlc1tp XSkKKwkJCQlpbnB1dC0+c2FtcGxlcyA9IGk7CisKKwkJLyogVXBkYXRlIHRoZSBBREMgc2V0dXAg YXMgbmVlZGVkLiAqLworCQlhbTMzNXhfYWRjX3NldHVwKHNjKTsKKwkJQU0zMzVYX0FEQ19VTkxP Q0soc2MpOworCX0KKworCXJldHVybiAoZXJyb3IpOworfQorCitzdGF0aWMgdm9pZAorYW0zMzV4 X2FkY19pbnRyKHZvaWQgKmFyZykKK3sKKwlpbnQgY291bnQsIGlucHV0OworCXN0cnVjdCBhbTMz NXhfYWRjX3NvZnRjICpzYzsKKwl1aW50MzJfdCBkYXRhLCBzdGF0dXM7CisKKwlzYyA9IChzdHJ1 Y3QgYW0zMzV4X2FkY19zb2Z0YyAqKWFyZzsKKworCXN0YXR1cyA9IEFEQ19SRUFENChzYywgQURD X0lSUVNUQVRVUyk7CisJaWYgKHN0YXR1cyAmIH5BRENfSVJRX0ZJRk8wX1RIUkVTKQorCQlkZXZp Y2VfcHJpbnRmKHNjLT5zY19kZXYsICJzdHJheSBpbnRlcnJ1cHQ6ICUjeFxuIiwgc3RhdHVzKTsK KworCS8qIENsZWFyIHRoZSBpbnRlcnJ1cHQuICovCisJQURDX1dSSVRFNChzYywgQURDX0lSUVNU QVRVUywgQURDX0lSUV9GSUZPMF9USFJFUyk7CisKKwkvKiBSZWFkIHRoZSBhdmFpbGFibGUgZGF0 YS4gKi8KKwljb3VudCA9IEFEQ19SRUFENChzYywgQURDX0ZJRk8wQ09VTlQpICYgQURDX0ZJRk9f Q09VTlRfTVNLOworCXdoaWxlIChjb3VudC0tID4gMCkgeworCQlkYXRhID0gQURDX1JFQUQ0KHNj LCBBRENfRklGTzBEQVRBKTsKKwkJaW5wdXQgPSAoZGF0YSAmIEFEQ19GSUZPX1NURVBfSURfTVNL KSA+PiBBRENfRklGT19TVEVQX0lEX1NISUZUOworCQlhbTMzNXhfYWRjX2lucHV0c1tpbnB1dF0u dmFsdWUgPSBkYXRhICYgQURDX0ZJRk9fREFUQV9NU0s7CisJfQorfQorCitzdGF0aWMgdm9pZAor YW0zMzV4X2FkY19zeXNjdGxfaW5pdChzdHJ1Y3QgYW0zMzV4X2FkY19zb2Z0YyAqc2MpCit7CisJ Y2hhciBwaW5idWZbM107CisJc3RydWN0IHN5c2N0bF9jdHhfbGlzdCAqY3R4OworCXN0cnVjdCBz eXNjdGxfb2lkICp0cmVlX25vZGUsICppbnBfbm9kZSwgKmlucE5fbm9kZTsKKwlzdHJ1Y3Qgc3lz Y3RsX29pZF9saXN0ICp0cmVlLCAqaW5wX3RyZWUsICppbnBOX3RyZWU7CisJaW50IGk7CisKKwkv KgorCSAqIEFkZCBwZXItcGluIHN5c2N0bCB0cmVlL2hhbmRsZXJzLgorCSAqLworCWN0eCA9IGRl dmljZV9nZXRfc3lzY3RsX2N0eChzYy0+c2NfZGV2KTsKKwl0cmVlX25vZGUgPSBkZXZpY2VfZ2V0 X3N5c2N0bF90cmVlKHNjLT5zY19kZXYpOworCXRyZWUgPSBTWVNDVExfQ0hJTERSRU4odHJlZV9u b2RlKTsKKwlTWVNDVExfQUREX1BST0MoY3R4LCB0cmVlLCBPSURfQVVUTywgImNsb2NrZGl2IiwK KwkgICAgQ1RMRkxBR19SVyB8IENUTFRZUEVfVUlOVCwgIHNjLCAwLAorCSAgICBhbTMzNXhfYWRj X2Nsb2NrZGl2X3Byb2MsICJJVSIsICJBREMgY2xvY2sgcHJlc2NhbGVyIik7CisJaW5wX25vZGUg PSBTWVNDVExfQUREX05PREUoY3R4LCB0cmVlLCBPSURfQVVUTywgImFpbiIsCisJICAgIENUTEZM QUdfUkQsIE5VTEwsICJBREMgaW5wdXRzIik7CisJaW5wX3RyZWUgPSBTWVNDVExfQ0hJTERSRU4o aW5wX25vZGUpOworCisJZm9yIChpID0gMDsgaSA8IEFNMzM1WF9BRENfTlBJTlM7IGkrKykgewor CisJCXNucHJpbnRmKHBpbmJ1Ziwgc2l6ZW9mKHBpbmJ1ZiksICIlZCIsIGkpOworCQlpbnBOX25v ZGUgPSBTWVNDVExfQUREX05PREUoY3R4LCBpbnBfdHJlZSwgT0lEX0FVVE8sIHBpbmJ1ZiwKKwkJ ICAgIENUTEZMQUdfUkQsIE5VTEwsICJBREMgaW5wdXQiKTsKKwkJaW5wTl90cmVlID0gU1lTQ1RM X0NISUxEUkVOKGlucE5fbm9kZSk7CisKKwkJYW0zMzV4X2FkY19pbnB1dHNbaV0uc2MgPSBzYzsK KwkJYW0zMzV4X2FkY19pbnB1dHNbaV0uaW5wdXQgPSBpOworCQlhbTMzNXhfYWRjX2lucHV0c1tp XS52YWx1ZSA9IDA7CisJCWFtMzM1eF9hZGNfaW5wdXRzW2ldLmVuYWJsZSA9IDA7CisJCWFtMzM1 eF9hZGNfaW5wdXRzW2ldLnNhbXBsZXMgPSAwOworCQlTWVNDVExfQUREX1BST0MoY3R4LCBpbnBO X3RyZWUsIE9JRF9BVVRPLCAiZW5hYmxlIiwKKwkJICAgIENUTEZMQUdfUlcgfCBDVExUWVBFX1VJ TlQsICZhbTMzNXhfYWRjX2lucHV0c1tpXSwgMCwKKwkJICAgIGFtMzM1eF9hZGNfZW5hYmxlX3By b2MsICJJVSIsICJFbmFibGUgQURDIGlucHV0Iik7CisJCVNZU0NUTF9BRERfUFJPQyhjdHgsIGlu cE5fdHJlZSwgT0lEX0FVVE8sICJzYW1wbGVzX2F2ZyIsCisJCSAgICBDVExGTEFHX1JXIHwgQ1RM VFlQRV9VSU5ULCAgJmFtMzM1eF9hZGNfaW5wdXRzW2ldLCAwLAorCQkgICAgYW0zMzV4X2FkY19z YW1wbGVzX2F2Z19wcm9jLCAiSVUiLCAiQURDIHNhbXBsZXMgYXZlcmFnZSIpOworCQlTWVNDVExf QUREX0lOVChjdHgsIGlucE5fdHJlZSwgT0lEX0FVVE8sICJpbnB1dCIsCisJCSAgICBDVExGTEFH X1JELCAmYW0zMzV4X2FkY19pbnB1dHNbaV0udmFsdWUsIDAsCisJCSAgICAiQ29udmVydGVkIHZh bHVlIGZvciB0aGUgQURDIGlucHV0Iik7CisJfQorfQorCitzdGF0aWMgaW50CithbTMzNXhfYWRj X3Byb2JlKGRldmljZV90IGRldikKK3sKKworCWlmICghb2Z3X2J1c19pc19jb21wYXRpYmxlKGRl diwgInRpLGFtMzM1eC1hZGMiKSkKKwkJcmV0dXJuIChFTlhJTyk7CisJZGV2aWNlX3NldF9kZXNj KGRldiwgIkFNMzM1eCBBREMgY29udHJvbGxlciIpOworCisJcmV0dXJuIChCVVNfUFJPQkVfREVG QVVMVCk7Cit9CisKK3N0YXRpYyBpbnQKK2FtMzM1eF9hZGNfYXR0YWNoKGRldmljZV90IGRldikK K3sKKwlpbnQgZXJyLCByaWQ7CisJc3RydWN0IGFtMzM1eF9hZGNfc29mdGMgKnNjOworCXVpbnQz Ml90IHJlZywgcmV2OworCisJc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisJc2MtPnNjX2Rl diA9IGRldjsKKworCXJpZCA9IDA7CisJc2MtPnNjX21lbV9yZXMgPSBidXNfYWxsb2NfcmVzb3Vy Y2VfYW55KGRldiwgU1lTX1JFU19NRU1PUlksICZyaWQsCisJICAgIFJGX0FDVElWRSk7CisJaWYg KCFzYy0+c2NfbWVtX3JlcykgeworCQlkZXZpY2VfcHJpbnRmKGRldiwgImNhbm5vdCBhbGxvY2F0 ZSBtZW1vcnkgd2luZG93XG4iKTsKKwkJcmV0dXJuIChFTlhJTyk7CisJfQorCisJcmlkID0gMDsK KwlzYy0+c2NfaXJxX3JlcyA9IGJ1c19hbGxvY19yZXNvdXJjZV9hbnkoZGV2LCBTWVNfUkVTX0lS USwgJnJpZCwKKwkgICAgUkZfQUNUSVZFKTsKKwlpZiAoIXNjLT5zY19pcnFfcmVzKSB7CisJCWJ1 c19yZWxlYXNlX3Jlc291cmNlKGRldiwgU1lTX1JFU19NRU1PUlksIDAsIHNjLT5zY19tZW1fcmVz KTsKKwkJZGV2aWNlX3ByaW50ZihkZXYsICJjYW5ub3QgYWxsb2NhdGUgaW50ZXJydXB0XG4iKTsK KwkJcmV0dXJuIChFTlhJTyk7CisJfQorCisJaWYgKGJ1c19zZXR1cF9pbnRyKGRldiwgc2MtPnNj X2lycV9yZXMsIElOVFJfVFlQRV9NSVNDIHwgSU5UUl9NUFNBRkUsCisJICAgIE5VTEwsIGFtMzM1 eF9hZGNfaW50ciwgc2MsICZzYy0+c2NfaW50cmhhbmQpICE9IDApIHsKKwkJYnVzX3JlbGVhc2Vf cmVzb3VyY2UoZGV2LCBTWVNfUkVTX0lSUSwgMCwgc2MtPnNjX2lycV9yZXMpOworCQlidXNfcmVs ZWFzZV9yZXNvdXJjZShkZXYsIFNZU19SRVNfTUVNT1JZLCAwLCBzYy0+c2NfbWVtX3Jlcyk7CisJ CWRldmljZV9wcmludGYoZGV2LCAiVW5hYmxlIHRvIHNldHVwIHRoZSBpcnEgaGFuZGxlci5cbiIp OworCQlyZXR1cm4gKEVOWElPKTsKKwl9CisKKwkvKiBBY3RpdmF0ZSB0aGUgQURDX1RTQyBtb2R1 bGUuICovCisJZXJyID0gdGlfcHJjbV9jbGtfZW5hYmxlKFRTQ19BRENfQ0xLKTsKKwlpZiAoZXJy KQorCQlyZXR1cm4gKGVycik7CisKKwkvKiBDaGVjayB0aGUgQURDIHJldmlzaW9uLiAqLworCXJl diA9IEFEQ19SRUFENChzYywgQURDX1JFVklTSU9OKTsKKwlkZXZpY2VfcHJpbnRmKGRldiwKKwkg ICAgInNjaGVtZTogJSN4IGZ1bmM6ICUjeCBydGw6ICVkIHJldjogJWQuJWQgY3VzdG9tIHJldjog JWRcbiIsCisJICAgIChyZXYgJiBBRENfUkVWX1NDSEVNRV9NU0spID4+IEFEQ19SRVZfU0NIRU1F X1NISUZULAorCSAgICAocmV2ICYgQURDX1JFVl9GVU5DX01TSykgPj4gQURDX1JFVl9GVU5DX1NI SUZULAorCSAgICAocmV2ICYgQURDX1JFVl9SVExfTVNLKSA+PiBBRENfUkVWX1JUTF9TSElGVCwK KwkgICAgKHJldiAmIEFEQ19SRVZfTUFKT1JfTVNLKSA+PiBBRENfUkVWX01BSk9SX1NISUZULAor CSAgICByZXYgJiBBRENfUkVWX01JTk9SX01TSywKKwkgICAgKHJldiAmIEFEQ19SRVZfQ1VTVE9N X01TSykgPj4gQURDX1JFVl9DVVNUT01fU0hJRlQpOworCisJLyoKKwkgKiBEaXNhYmxlIHRoZSBz dGVwIHdyaXRlIHByb3RlY3QgYW5kIG1ha2UgaXQgc3RvcmUgdGhlIHN0ZXAgSUQgZm9yCisJICog dGhlIGNhcHR1cmVkIGRhdGEgb24gRklGTy4KKwkgKi8KKwlyZWcgPSBBRENfUkVBRDQoc2MsIEFE Q19DVFJMKTsKKwlBRENfV1JJVEU0KHNjLCBBRENfQ1RSTCwgcmVnIHwgQURDX0NUUkxfU1RFUF9X UCB8IEFEQ19DVFJMX1NURVBfSUQpOworCisJLyoKKwkgKiBTZXQgdGhlIEFEQyBwcmVzY2FsZXIg dG8gMjAwMCAoeWVzLCB0aGUgYWN0dWFsIHZhbHVlIHdyaXR0ZW4gaGVyZQorCSAqIGlzIDIwMDAg LSAxKS4KKwkgKi8KKwlBRENfV1JJVEU0KHNjLCBBRENfQ0xLRElWLCAxOTk5KTsKKworCUFNMzM1 WF9BRENfTE9DS19JTklUKHNjKTsKKworCWFtMzM1eF9hZGNfc3lzY3RsX2luaXQoc2MpOworCisJ cmV0dXJuICgwKTsKK30KKworc3RhdGljIGludAorYW0zMzV4X2FkY19kZXRhY2goZGV2aWNlX3Qg ZGV2KQoreworCXN0cnVjdCBhbTMzNXhfYWRjX3NvZnRjICpzYzsKKworCXNjID0gZGV2aWNlX2dl dF9zb2Z0YyhkZXYpOworCisJLyogVHVybiBvZmYgdGhlIEFEQy4gKi8KKwlBTTMzNVhfQURDX0xP Q0soc2MpOworCWFtMzM1eF9hZGNfcmVzZXQoc2MpOworCWFtMzM1eF9hZGNfc2V0dXAoc2MpOwor CUFNMzM1WF9BRENfVU5MT0NLKHNjKTsKKworCUFNMzM1WF9BRENfTE9DS19ERVNUUk9ZKHNjKTsK KworCWlmIChzYy0+c2NfaW50cmhhbmQpCisJCWJ1c190ZWFyZG93bl9pbnRyKGRldiwgc2MtPnNj X2lycV9yZXMsIHNjLT5zY19pbnRyaGFuZCk7CisJaWYgKHNjLT5zY19pcnFfcmVzKQorCQlidXNf cmVsZWFzZV9yZXNvdXJjZShkZXYsIFNZU19SRVNfSVJRLCAwLCBzYy0+c2NfaXJxX3Jlcyk7CisJ aWYgKHNjLT5zY19tZW1fcmVzKQorCQlidXNfcmVsZWFzZV9yZXNvdXJjZShkZXYsIFNZU19SRVNf TUVNT1JZLCAwLCBzYy0+c2NfbWVtX3Jlcyk7CisKKwlyZXR1cm4gKGJ1c19nZW5lcmljX2RldGFj aChkZXYpKTsKK30KKworc3RhdGljIGRldmljZV9tZXRob2RfdCBhbTMzNXhfYWRjX21ldGhvZHNb XSA9IHsKKwlERVZNRVRIT0QoZGV2aWNlX3Byb2JlLAkJYW0zMzV4X2FkY19wcm9iZSksCisJREVW TUVUSE9EKGRldmljZV9hdHRhY2gsCWFtMzM1eF9hZGNfYXR0YWNoKSwKKwlERVZNRVRIT0QoZGV2 aWNlX2RldGFjaCwJYW0zMzV4X2FkY19kZXRhY2gpLAorCisJREVWTUVUSE9EX0VORAorfTsKKwor c3RhdGljIGRyaXZlcl90IGFtMzM1eF9hZGNfZHJpdmVyID0geworCSJhbTMzNXhfYWRjIiwKKwlh bTMzNXhfYWRjX21ldGhvZHMsCisJc2l6ZW9mKHN0cnVjdCBhbTMzNXhfYWRjX3NvZnRjKSwKK307 CisKK3N0YXRpYyBkZXZjbGFzc190IGFtMzM1eF9hZGNfZGV2Y2xhc3M7CisKK0RSSVZFUl9NT0RV TEUoYW0zMzV4X2FkYywgc2ltcGxlYnVzLCBhbTMzNXhfYWRjX2RyaXZlciwgYW0zMzV4X2FkY19k ZXZjbGFzcywgMCwgMCk7CitNT0RVTEVfVkVSU0lPTihhbTMzNXhfYWRjLCAxKTsKK01PRFVMRV9E RVBFTkQoYW0zMzV4X2FkYywgc2ltcGxlYnVzLCAxLCAxLCAxKTsKLS0tIC9kZXYvbnVsbAkyMDE0 LTAzLTE2IDExOjAwOjAwLjAwMDAwMDAwMCAtMDMwMAorKysgc3lzL2FybS90aS9hbTMzNXgvYW0z MzV4X2FkY3JlZy5oCTIwMTQtMDMtMTYgMTE6MDc6NDcuMjA0Mzk2OTcwIC0wMzAwCkBAIC0wLDAg KzEsMTA1IEBACisvKi0KKyAqIENvcHlyaWdodCAyMDE0IEx1aXogT3RhdmlvIE8gU291emEgPGxv b3NAZnJlZWJzZC5vcmc+CisgKiBBbGwgcmlnaHRzIHJlc2VydmVkLgorICoKKyAqIFJlZGlzdHJp YnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91 dAorICogbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxv d2luZyBjb25kaXRpb25zCisgKiBhcmUgbWV0OgorICogMS4gUmVkaXN0cmlidXRpb25zIG9mIHNv dXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZSwg dGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4KKyAq IDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJv dmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0 aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgaW4gdGhlCisgKiAgICBkb2N1bWVudGF0aW9uIGFuZC9v ciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9uLgorICoKKyAq IFRISVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkgVEhFIEFVVEhPUiBBTkQgQ09OVFJJQlVUT1JT IGBgQVMgSVMnJyBBTkQKKyAqIEFOWSBFWFBSRVNTIE9SIElNUExJRUQgV0FSUkFOVElFUywgSU5D TFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFRIRQorICogSU1QTElFRCBXQVJSQU5USUVTIE9G IE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UKKyAq IEFSRSBESVNDTEFJTUVELiAgSU4gTk8gRVZFTlQgU0hBTEwgVEhFIEFVVEhPUiBPUiBDT05UUklC VVRPUlMgQkUgTElBQkxFCisgKiBGT1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1QsIElOQ0lERU5UQUws IFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09OU0VRVUVOVElBTAorICogREFNQUdFUyAoSU5DTFVE SU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9GIFNVQlNUSVRVVEUgR09PRFMK KyAqIE9SIFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFUQSwgT1IgUFJPRklUUzsgT1IgQlVTSU5F U1MgSU5URVJSVVBUSU9OKQorICogSE9XRVZFUiBDQVVTRUQgQU5EIE9OIEFOWSBUSEVPUlkgT0Yg TElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QKKyAqIExJQUJJTElUWSwgT1Ig VE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBBUklTSU5HIElOIEFOWSBX QVkKKyAqIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBP RiBUSEUgUE9TU0lCSUxJVFkgT0YKKyAqIFNVQ0ggREFNQUdFLgorICoKKyAqICRGcmVlQlNEJAor ICovCisKKyNpZm5kZWYgX0FNMzM1WF9BRENSRUdfSF8KKyNkZWZpbmUgX0FNMzM1WF9BRENSRUdf SF8KKworI2RlZmluZQlBRENfUkVWSVNJT04JCTB4MDAwCisjZGVmaW5lCUFEQ19SRVZfU0NIRU1F X01TSwkJMHhjMDAwMDAwMAorI2RlZmluZQlBRENfUkVWX1NDSEVNRV9TSElGVAkJMzAKKyNkZWZp bmUJQURDX1JFVl9GVU5DX01TSwkJMHgwZmZmMDAwMAorI2RlZmluZQlBRENfUkVWX0ZVTkNfU0hJ RlQJCTE2CisjZGVmaW5lCUFEQ19SRVZfUlRMX01TSwkJCTB4MDAwMGY4MDAKKyNkZWZpbmUJQURD X1JFVl9SVExfU0hJRlQJCTExCisjZGVmaW5lCUFEQ19SRVZfTUFKT1JfTVNLCQkweDAwMDAwNzAw CisjZGVmaW5lCUFEQ19SRVZfTUFKT1JfU0hJRlQJCTgKKyNkZWZpbmUJQURDX1JFVl9DVVNUT01f TVNLCQkweDAwMDAwMGMwCisjZGVmaW5lCUFEQ19SRVZfQ1VTVE9NX1NISUZUCQk2CisjZGVmaW5l CUFEQ19SRVZfTUlOT1JfTVNLCQkweDAwMDAwMDNmCisjZGVmaW5lCUFEQ19TWVNDRkcJCTB4MDEw CisjZGVmaW5lCUFEQ19TWVNDRkdfSURMRV9NU0sJCTB4MDAwMDAwYzAKKyNkZWZpbmUJQURDX1NZ U0NGR19JRExFX1NISUZUCQkyCisjZGVmaW5lCUFEQ19JUlFTVEFUVVNfUkFXCTB4MDI0CisjZGVm aW5lCUFEQ19JUlFTVEFUVVMJCTB4MDI4CisjZGVmaW5lCUFEQ19JUlFFTkFCTEVfU0VUCTB4MDJj CisjZGVmaW5lCUFEQ19JUlFFTkFCTEVfQ0xSCTB4MDMwCisjZGVmaW5lCUFEQ19JUlFfSFdfUEVO X1NZTkMJCSgxIDw8IDEwKQorI2RlZmluZQlBRENfSVJRX1BFTl9VUAkJCSgxIDw8IDkpCisjZGVm aW5lCUFEQ19JUlFfT1VUX1JBTkdFCQkoMSA8PCA4KQorI2RlZmluZQlBRENfSVJRX0ZJRk8xX1VO RFIJCSgxIDw8IDcpCisjZGVmaW5lCUFEQ19JUlFfRklGTzFfT1ZFUlIJCSgxIDw8IDYpCisjZGVm aW5lCUFEQ19JUlFfRklGTzFfVEhSRVMJCSgxIDw8IDUpCisjZGVmaW5lCUFEQ19JUlFfRklGTzBf VU5EUgkJKDEgPDwgNCkKKyNkZWZpbmUJQURDX0lSUV9GSUZPMF9PVkVSUgkJKDEgPDwgMykKKyNk ZWZpbmUJQURDX0lSUV9GSUZPMF9USFJFUwkJKDEgPDwgMikKKyNkZWZpbmUJQURDX0lSUV9FTkRf T0ZfU0VRCQkoMSA8PCAxKQorI2RlZmluZQlBRENfSVJRX0hXX1BFTl9BU1lOQwkJKDEgPDwgMCkK KyNkZWZpbmUJQURDX0NUUkwJCTB4MDQwCisjZGVmaW5lCUFEQ19DVFJMX1NURVBfV1AJCTB4MDAw MDAwMDQKKyNkZWZpbmUJQURDX0NUUkxfU1RFUF9JRAkJMHgwMDAwMDAwMgorI2RlZmluZQlBRENf Q1RSTF9FTkFCTEUJCQkweDAwMDAwMDAxCisjZGVmaW5lCUFEQ19DTEtESVYJCTB4MDRjCisjZGVm aW5lCUFEQ19TVEVQRU5BQkxFCQkweDA1NAorI2RlZmluZQlBRENfU1RFUENGRzEJCTB4MDY0Cisj ZGVmaW5lCUFEQ19TVEVQQ0ZHMgkJMHgwNmMKKyNkZWZpbmUJQURDX1NURVBDRkczCQkweDA3NAor I2RlZmluZQlBRENfU1RFUENGRzQJCTB4MDdjCisjZGVmaW5lCUFEQ19TVEVQQ0ZHNQkJMHgwODQK KyNkZWZpbmUJQURDX1NURVBDRkc2CQkweDA4YworI2RlZmluZQlBRENfU1RFUENGRzcJCTB4MDk0 CisjZGVmaW5lCUFEQ19TVEVQX1JGTV9NU0sJCTB4MDE4MDAwMDAKKyNkZWZpbmUJQURDX1NURVBf UkZNX1NISUZUCQkyMworI2RlZmluZQlBRENfU1RFUF9SRk1fVlNTQQkJMAorI2RlZmluZQlBRENf U1RFUF9SRk1fWE5VUgkJMQorI2RlZmluZQlBRENfU1RFUF9SRk1fWU5MUgkJMgorI2RlZmluZQlB RENfU1RFUF9SRk1fVlJFRk4JCTMKKyNkZWZpbmUJQURDX1NURVBfSU5QX01TSwkJMHgwMDc4MDAw MAorI2RlZmluZQlBRENfU1RFUF9JTlBfU0hJRlQJCTE5CisjZGVmaW5lCUFEQ19TVEVQX0lOTV9N U0sJCTB4MDAwNzgwMDAKKyNkZWZpbmUJQURDX1NURVBfSU5NX1NISUZUCQkxNQorI2RlZmluZQlB RENfU1RFUF9SRlBfTVNLCQkweDAwMDA3MDAwCisjZGVmaW5lCUFEQ19TVEVQX1JGUF9TSElGVAkJ MTIKKyNkZWZpbmUJQURDX1NURVBfUkZQX1ZEREEJCTAKKyNkZWZpbmUJQURDX1NURVBfUkZQX1hQ VUwJCTEKKyNkZWZpbmUJQURDX1NURVBfUkZQX1lQTEwJCTIKKyNkZWZpbmUJQURDX1NURVBfUkZQ X1ZSRUZQCQkzCisjZGVmaW5lCUFEQ19TVEVQX1JGUF9JTlRSRUYJCTQKKyNkZWZpbmUJQURDX1NU RVBfQVZHX01TSwkJMHgwMDAwMDAxYworI2RlZmluZQlBRENfU1RFUF9BVkdfU0hJRlQJCTIKKyNk ZWZpbmUJQURDX1NURVBfTU9ERV9NU0sJCTB4MDAwMDAwMDMKKyNkZWZpbmUJQURDX1NURVBfTU9E RV9PTkVTSE9UCQkweDAwMDAwMDAwCisjZGVmaW5lCUFEQ19TVEVQX01PREVfQ09OVElOVU9VUwkw eDAwMDAwMDAxCisjZGVmaW5lCUFEQ19GSUZPMENPVU5UCQkweDBlNAorI2RlZmluZQlBRENfRklG TzBUSFJFU0hPTEQJMHgwZTgKKyNkZWZpbmUJQURDX0ZJRk8wREFUQQkJMHgxMDAKKyNkZWZpbmUJ QURDX0ZJRk9fQ09VTlRfTVNLCQkweDAwMDAwMDdmCisjZGVmaW5lCUFEQ19GSUZPX1NURVBfSURf TVNLCQkweDAwMGYwMDAwCisjZGVmaW5lCUFEQ19GSUZPX1NURVBfSURfU0hJRlQJCTE2CisjZGVm aW5lCUFEQ19GSUZPX0RBVEFfTVNLCQkweDAwMDAwZmZmCisKKyNlbmRpZiAvKiBfQU0zMzVYX0FE Q1JFR19IXyAqLwotLS0gL2Rldi9udWxsCTIwMTQtMDMtMTYgMTE6MDA6MDAuMDAwMDAwMDAwIC0w MzAwCisrKyBzeXMvYXJtL3RpL2FtMzM1eC9hbTMzNXhfYWRjdmFyLmgJMjAxNC0wMy0xNSAyMjoy Njo0Ny4zMTM1NDI5NTkgLTAzMDAKQEAgLTAsMCArMSw2NyBAQAorLyotCisgKiBDb3B5cmlnaHQg MjAxNCBMdWl6IE90YXZpbyBPIFNvdXphIDxsb29zQGZyZWVic2Qub3JnPgorICogQWxsIHJpZ2h0 cyByZXNlcnZlZC4KKyAqCisgKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQg YmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKKyAqIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1p dHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucworICogYXJlIG1ldDoK KyAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJv dmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0 aGUgZm9sbG93aW5nIGRpc2NsYWltZXIuCisgKiAyLiBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5 IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgbm90aWNlLCB0 aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyIGluIHRo ZQorICogICAgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdp dGggdGhlIGRpc3RyaWJ1dGlvbi4KKyAqCisgKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZ IFRIRSBBVVRIT1IgQU5EIENPTlRSSUJVVE9SUyBgYEFTIElTJycgQU5ECisgKiBBTlkgRVhQUkVT UyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBU SEUKKyAqIElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1Mg Rk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFCisgKiBBUkUgRElTQ0xBSU1FRC4gIElOIE5PIEVWRU5U IFNIQUxMIFRIRSBBVVRIT1IgT1IgQ09OVFJJQlVUT1JTIEJFIExJQUJMRQorICogRk9SIEFOWSBE SVJFQ1QsIElORElSRUNULCBJTkNJREVOVEFMLCBTUEVDSUFMLCBFWEVNUExBUlksIE9SIENPTlNF UVVFTlRJQUwKKyAqIERBTUFHRVMgKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9D VVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTCisgKiBPUiBTRVJWSUNFUzsgTE9TUyBPRiBVU0Us IERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVSUlVQVElPTikKKyAqIEhPV0VWRVIg Q0FVU0VEIEFORCBPTiBBTlkgVEhFT1JZIE9GIExJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFD VCwgU1RSSUNUCisgKiBMSUFCSUxJVFksIE9SIFRPUlQgKElOQ0xVRElORyBORUdMSUdFTkNFIE9S IE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZCisgKiBPVVQgT0YgVEhFIFVTRSBPRiBUSElT IFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GCisgKiBTVUNI IERBTUFHRS4KKyAqCisgKiAkRnJlZUJTRCQKKyAqLworCisjaWZuZGVmIF9BTTMzNVhfQURDVkFS X0hfCisjZGVmaW5lIF9BTTMzNVhfQURDVkFSX0hfCisKKyNkZWZpbmUJQU0zMzVYX0FEQ19OUElO Uwk3CisKKyNkZWZpbmUJQURDX1JFQUQ0KF9zYywgcmVnKQlidXNfcmVhZF80KChfc2MpLT5zY19t ZW1fcmVzLCByZWcpCisjZGVmaW5lCUFEQ19XUklURTQoX3NjLCByZWcsIHZhbHVlKQlcCisJYnVz X3dyaXRlXzQoKF9zYyktPnNjX21lbV9yZXMsIHJlZywgdmFsdWUpCisKK3N0cnVjdCBhbTMzNXhf YWRjX3NvZnRjIHsKKwlkZXZpY2VfdAkJc2NfZGV2OworCXN0cnVjdCBtdHgJCXNjX210eDsKKwlz dHJ1Y3QgcmVzb3VyY2UJCSpzY19tZW1fcmVzOworCXN0cnVjdCByZXNvdXJjZQkJKnNjX2lycV9y ZXM7CisJdm9pZAkJCSpzY19pbnRyaGFuZDsKK307CisKK3N0cnVjdCBhbTMzNXhfYWRjX2lucHV0 IHsKKwlpbnQzMl90CQkJZW5hYmxlOwkJLyogaW5wdXQgZW5hYmxlZCAqLworCWludDMyX3QJCQlz YW1wbGVzOwkvKiBzYW1wbGVzIGF2ZXJhZ2UgKi8KKwlpbnQzMl90CQkJaW5wdXQ7CQkvKiBpbnB1 dCBudW1iZXIgKi8KKwlpbnQzMl90CQkJdmFsdWU7CQkvKiByYXcgY29udmVydGVkIHZhbHVlICov CisJdWludDMyX3QJCXN0ZXByZWc7CS8qIHN0ZXAgcmVnaXN0ZXIgKi8KKwlzdHJ1Y3QgYW0zMzV4 X2FkY19zb2Z0Ywkqc2M7CQkvKiBwb2ludGVyIHRvIGFkYyBzb2Z0YyAqLworfTsKKworI2RlZmlu ZQlBTTMzNVhfQURDX0xPQ0soX3NjKQkJXAorCW10eF9sb2NrKCYoX3NjKS0+c2NfbXR4KQorI2Rl ZmluZQlBTTMzNVhfQURDX1VOTE9DSyhfc2MpCQlcCisJbXR4X3VubG9jaygmKF9zYyktPnNjX210 eCkKKyNkZWZpbmUJQU0zMzVYX0FEQ19MT0NLX0lOSVQoX3NjKQlcCisJbXR4X2luaXQoJl9zYy0+ c2NfbXR4LCBkZXZpY2VfZ2V0X25hbWV1bml0KF9zYy0+c2NfZGV2KSwgXAorCSAgICAiYW0zMzV4 X2FkYyIsIE1UWF9ERUYpCisjZGVmaW5lCUFNMzM1WF9BRENfTE9DS19ERVNUUk9ZKF9zYykJXAor CW10eF9kZXN0cm95KCZfc2MtPnNjX210eCk7CisjZGVmaW5lCUFNMzM1WF9BRENfTE9DS19BU1NF UlQoX3NjKQlcCisJbXR4X2Fzc2VydCgmKF9zYyktPnNjX210eCwgTUFfT1dORUQpCisKKyNlbmRp ZiAvKiBfQU0zMzVYX0FEQ1ZBUl9IXyAqLwpJbmRleDogc3lzL2Jvb3QvZmR0L2R0cy9hbTMzNXgu ZHRzaQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09Ci0tLSBzeXMvYm9vdC9mZHQvZHRzL2FtMzM1eC5kdHNpCShyZXZpc2lv biAyNjIxMzEpCisrKyBzeXMvYm9vdC9mZHQvZHRzL2FtMzM1eC5kdHNpCSh3b3JraW5nIGNvcHkp CkBAIC03NSw2ICs3NSwxMyBAQAogCQkJaW50ZXJydXB0LXBhcmVudCA9IDwmQUlOVEM+OwogCQl9 OwogCisJCWFkYzA6IGFkY0A0NEUwRDAwMCB7CisJCQljb21wYXRpYmxlID0gInRpLGFtMzM1eC1h ZGMiOworCQkJcmVnID0gPDB4NDRFMEQwMDAgMHgyMDAwPjsKKwkJCWludGVycnVwdHMgPSA8IDE2 ID47CisJCQlpbnRlcnJ1cHQtcGFyZW50ID0gPCZBSU5UQz47CisgCQl9OworIAkJCiAJCUdQSU86 IGdwaW8gewogCQkJI2dwaW8tY2VsbHMgPSA8Mz47CiAJCQljb21wYXRpYmxlID0gInRpLGdwaW8i OwpJbmRleDogc3lzL2FybS9jb25mL0JFQUdMRUJPTkUKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2FybS9j b25mL0JFQUdMRUJPTkUJKHJldmlzaW9uIDI2MjEzMSkKKysrIHN5cy9hcm0vY29uZi9CRUFHTEVC T05FCSh3b3JraW5nIGNvcHkpCkBAIC0xMDMsNiArMTAzLDkgQEAKIGRldmljZQkJZ3BpbwogZGV2 aWNlCQlncGlvbGVkCiAKKyMgQURDIHN1cHBvcnQKK2RldmljZQkJYW0zMzV4X2FkYworCiAjIFVT QiBzdXBwb3J0CiBkZXZpY2UJCXVzYgogb3B0aW9ucyAJVVNCX0hPU1RfQUxJR049NjQJIyBDYWNo ZWxpbmUgc2l6ZSBpcyA2NCBvbiBBTTMzNXguCg== --047d7bb709886b3cc004f4cd7118-- From owner-freebsd-embedded@FreeBSD.ORG Tue Mar 18 11:35:03 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 74A00E79 for ; Tue, 18 Mar 2014 11:35:03 +0000 (UTC) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 39642196 for ; Tue, 18 Mar 2014 11:35:03 +0000 (UTC) Received: by mail-qc0-f179.google.com with SMTP id m20so7434767qcx.24 for ; Tue, 18 Mar 2014 04:35:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=6BxDlXK4zHb9Kx9HxC7hf9SEtCyL1PpFCJwXvbmYM/s=; b=TURgs7lhOLi7XKXjo91EgDYUPvjHeL9PL9gX35Sas36UVDyGKaqK1OfgrK6mlYk9zt CjG8qCU3JCfawweZh7niI5A83gt5hDnd1a6PvbKcTBWLmzgT6lER656XwNWX2dMH13ce 0A6E1MFqp9n9YKx1E0ri2BLpmjvl2L4JNdxv28G7qgCoL5ZZ3Z2w+gSvt61gDWBTOo9F W4FD1Hu+X+EMrTcDVoT1KghkuANGH5/xRcbt4ptAUh4Gc0NH3V62gb1GRLqmLoI1RcbS oeKRwqZBYMzeTqY3SZpyC+3lrL50ymRCV69bdRcFn8Y6EzePncPp2SM64rFYpiyEVITR T2fw== MIME-Version: 1.0 X-Received: by 10.140.98.203 with SMTP id o69mr1616051qge.102.1395142502424; Tue, 18 Mar 2014 04:35:02 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.8.137 with HTTP; Tue, 18 Mar 2014 04:35:02 -0700 (PDT) Date: Tue, 18 Mar 2014 04:35:02 -0700 X-Google-Sender-Auth: hzryyHC88TrqV3unzr3dn9_tXTo Message-ID: Subject: nand controller - how should one handle controllers that want the command+address bits together? From: Adrian Chadd To: "freebsd-embedded@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 11:35:03 -0000 Hiya, I've got the atheros ar934x nand controller bits looking like they're working on freebsd-head enough to send/receive a READID command with an address of 0x0. However, the NAND controller sends commands with the cmd and address phases as part of the command, rather than calling send_command / send_address methods called multiple times. It seems like our nandbus and nand controller layer is a very thin shim over what the NAND control messages look like, rather than some higher level 'thing' that allows for slightly more intelligent (read: DMA/ECC capable) hardware. So, what gives? -a From owner-freebsd-embedded@FreeBSD.ORG Tue Mar 18 12:55:34 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 397516E2 for ; Tue, 18 Mar 2014 12:55:34 +0000 (UTC) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EE39AC98 for ; Tue, 18 Mar 2014 12:55:33 +0000 (UTC) Received: by mail-qc0-f171.google.com with SMTP id c9so1821962qcz.30 for ; Tue, 18 Mar 2014 05:55:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=bzk/LJLcO+rEzJL78yIzoeSzpiVexTB75rC/Zo23+ws=; b=gflOUVNWdErpAQLmwdLMq4ZyU6q6223zU1qlQwq7SfT5rSi/hQr2J4uVJAzNHH2DXl HQsPWrz0sG8MSCvGHz9gBaYXCXJe4XxHvUeQ91wtfoOEY3zmGdnDyGaALyDSVUroWWyM SxnKwuaTUbc2aQcZJc0T0ypQg6VN5HtJM+KloJdBKEm7Zqznp/KgHVa46NGpZjk7Hgdu VbJD4DiDEHrj2v+D9Fm7EhOhXXTauQmHx93dADa/+911x2J2Inix+ZiKbdQ5HJiQKS3a IPve+6uoS1vqGWNkcYx9hGtBCsoprXQattAg/LJ4Im2EPdpl/6j04pSSE39tifTDibuC U9Pw== MIME-Version: 1.0 X-Received: by 10.140.42.9 with SMTP id b9mr10062518qga.87.1395147333183; Tue, 18 Mar 2014 05:55:33 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.8.137 with HTTP; Tue, 18 Mar 2014 05:55:33 -0700 (PDT) In-Reply-To: References: Date: Tue, 18 Mar 2014 05:55:33 -0700 X-Google-Sender-Auth: WDWU9PYE-0yYoTZxI1lQlnNWb7g Message-ID: Subject: Re: nand controller - how should one handle controllers that want the command+address bits together? From: Adrian Chadd To: "freebsd-embedded@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 12:55:34 -0000 .. wow. So, this gets even more problematic. The AR934x NAND controller does DMA for the read/program phases as well as command results (eg READID.) Now, I can likely easily hack around it for simple commands like READID by overloading the nfc_start_command() method. For the read phase, I'd have to do a copy out of the buffer into the buffer supplied to the NAND bus code. Cool, that's just highly inefficient (why aren't we doing buffer IO here again? Bueller?) but that's a different story. For the write phase though, it's totally horrible. I'd have to buffer the command byte(s), the address byte(s) and the NAND bus write (which would copy it into the outgoing buffer), then issue it all at once. So, at first glance: * why aren't these (command; address; address; start) method runs just wrapped up into a command method that looks vaguely like (command, command2, row, column, id, buffer) and let the controller code either unravel it into serialised writes out, or in the case of the ar934x NAND controller, use all that information to setup a DMA transfer; * .. and for reads/writes, the buffer is supplied here, so they can also be used to setup the DMA transfer, else they're just serialised out via port banging for dumber NAND controller latches. I really want to try and bring this flash chip up (even without hardware ECC) but I'm kinda worried that in order to do this cleanly I'm going to have to overhaul nandbus/nfc and a couple of NAND controllers I don't have (and currently don't want) hardware for. So, any help/ideas? Thanks, -a On 18 March 2014 04:35, Adrian Chadd wrote: > Hiya, > > I've got the atheros ar934x nand controller bits looking like they're > working on freebsd-head enough to send/receive a READID command with > an address of 0x0. However, the NAND controller sends commands with > the cmd and address phases as part of the command, rather than calling > send_command / send_address methods called multiple times. > > It seems like our nandbus and nand controller layer is a very thin > shim over what the NAND control messages look like, rather than some > higher level 'thing' that allows for slightly more intelligent (read: > DMA/ECC capable) hardware. > > So, what gives? > > > -a From owner-freebsd-embedded@FreeBSD.ORG Tue Mar 18 14:07:12 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF36746D for ; Tue, 18 Mar 2014 14:07:12 +0000 (UTC) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9926661B for ; Tue, 18 Mar 2014 14:07:12 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id rl12so7186323iec.32 for ; Tue, 18 Mar 2014 07:07:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=htULXrsYFYUEeS5Hd0VzFptP3VskuTndtnEt1MI8Nko=; b=meSR8z7y9CuCEBLZUEg7Q/smaPNZjPLq88MYRZotwBdffJQ5galxlAzT3ois9lQzN3 fTXk0dHnuDP/M7hIzSWyMPzgSlspvFJBArcmF+6SZarypNesn9hkfS6Pkj663fPBY0s1 KCTHDaIL9OUAgBlw9IJkPz7sTUtsKfUOBj0WUZlud0WF7/1BBytejOs+RIEw7ra1Q1Ia gxe+tAIj0bVBUlqYOxzDwqKsr+RggWJV3gnVDN4gsxbwDqL4ojeF9eSRgxnyYBYcJ8iD LAB2wBOanD6HFNFSFx7p6/4mk2N16BZRjKj4iqioi4jbByKiPdK030+MrFQOGaFFAp4O qBFA== X-Gm-Message-State: ALoCoQkR0u/gprC2slxr6JOY5KJXpSoOSejOgJF9DTxABL/3UM9T2lbDUoifZ1v9sJtAsjPzA4zF X-Received: by 10.42.64.17 with SMTP id e17mr24382954ici.26.1395151626104; Tue, 18 Mar 2014 07:07:06 -0700 (PDT) Received: from [172.29.91.92] ([198.202.203.177]) by mx.google.com with ESMTPSA id nh12sm23834335igb.12.2014.03.18.07.07.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Mar 2014 07:07:05 -0700 (PDT) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: nand controller - how should one handle controllers that want the command+address bits together? From: Warner Losh In-Reply-To: Date: Tue, 18 Mar 2014 08:07:04 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <72611BD5-E115-497D-82FC-3C1065E8A3F5@bsdimp.com> References: To: Adrian Chadd X-Mailer: Apple Mail (2.1874) Cc: "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 14:07:12 -0000 On Mar 18, 2014, at 5:35 AM, Adrian Chadd wrote: > Hiya, >=20 > I've got the atheros ar934x nand controller bits looking like they're > working on freebsd-head enough to send/receive a READID command with > an address of 0x0. However, the NAND controller sends commands with > the cmd and address phases as part of the command, rather than calling > send_command / send_address methods called multiple times. >=20 > It seems like our nandbus and nand controller layer is a very thin > shim over what the NAND control messages look like, rather than some > higher level 'thing' that allows for slightly more intelligent (read: > DMA/ECC capable) hardware. >=20 > So, what gives? Our NAND layer is very thin. The early controllers that were targeted by = the NAND controller were rather dump, little more than bit-bang controllers that = could modulate ALE and CLE as needed. There=92s no provision for DMA, at all = really. There=92s very little provision for ECC, since that=92s usually done as = part of the DMA operation. I=92m surprised you haven=92t complained about the excruciatingly long = busy waits yet. Our complete ignoring of the B/NR signal. The lack of any kind of = interrupt attempts for the GPIO pins we=92re driving, the hardwired state machines for the = NAND that just happen to work with the older generation parts but will encounter issues = on the latest NAND. Warner From owner-freebsd-embedded@FreeBSD.ORG Tue Mar 18 14:12:46 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 85FAD623 for ; Tue, 18 Mar 2014 14:12:46 +0000 (UTC) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4D50874C for ; Tue, 18 Mar 2014 14:12:46 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id as1so7196921iec.31 for ; Tue, 18 Mar 2014 07:12:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=HBmcIw3LZ4EjkVlLH1RaV0D8UnviVEG9mKTIXdDbpts=; b=WcmwFtL3YkbNZHT3EA7FFNRlm00xbo01xjnj/omlb38ll2mgq/GxQKnb06p/gC7jfF k+50pzOg+5SI+9+6/e1D8u7YUq8vIxv/gjKKovMqDcNu1ch3rhFaSvwPSFpWrSwJegmy 40I+nDZTNcM5/xi2ji9L3N0J1btbsvnC7TnVLP/YQc3z6O6wzAur0LRGGKDYyc3CnG/u TJ7ze2TR2dNqGRsdtr4VFDpAq5/JsL2iVgHEycJ0qBnkkghYwBa5WB3y5NNu5zPrPQVd w6fkrtlk8v/QxeCSakjF3fNLeaajlJx9pGgAyUY8o84nqJtDIt5eSNJsdu4F8vrf9Qzr qupA== X-Gm-Message-State: ALoCoQnnRBv/B72UDln692Qca2s1i7phxNbPA6IrxIk83kfVbAtcT0Q1ZeFtbe3TWDm8SBe/8NG2 X-Received: by 10.43.137.5 with SMTP id im5mr6864901icc.55.1395151964893; Tue, 18 Mar 2014 07:12:44 -0700 (PDT) Received: from [172.29.91.92] (63-156-62-129.dia.static.qwest.net. [63.156.62.129]) by mx.google.com with ESMTPSA id m6sm27142425igx.9.2014.03.18.07.12.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Mar 2014 07:12:44 -0700 (PDT) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: nand controller - how should one handle controllers that want the command+address bits together? From: Warner Losh In-Reply-To: Date: Tue, 18 Mar 2014 08:12:43 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <5BF1217D-6423-443B-A3AB-1722CDDDAD74@bsdimp.com> References: To: Adrian Chadd X-Mailer: Apple Mail (2.1874) Cc: "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 14:12:46 -0000 On Mar 18, 2014, at 6:55 AM, Adrian Chadd wrote: > .. wow. So, this gets even more problematic. >=20 > The AR934x NAND controller does DMA for the read/program phases as > well as command results (eg READID.) Now, I can likely easily hack > around it for simple commands like READID by overloading the > nfc_start_command() method. Quite ugly, yes. > For the read phase, I'd have to do a copy out of the buffer into the > buffer supplied to the NAND bus code. Cool, that's just highly > inefficient (why aren't we doing buffer IO here again? Bueller?) but > that's a different story. Since most of this stuff was bit-banged or PIOd out, who cares if = there=92s a copy... > For the write phase though, it's totally horrible. I'd have to buffer > the command byte(s), the address byte(s) and the NAND bus write (which > would copy it into the outgoing buffer), then issue it all at once. That=92s not the worst of it. that=92s child=92s play, really. > So, at first glance: >=20 > * why aren't these (command; address; address; start) method runs just > wrapped up into a command method that looks vaguely like (command, > command2, row, column, id, buffer) and let the controller code either > unravel it into serialised writes out, or in the case of the ar934x > NAND controller, use all that information to setup a DMA transfer; Because the state machines needed for different NAND types more or less require the =91low level=92 interface that we have today. The = different phases in setting up a transaction vary somewhat between the different types of NAND, and we have no real knowledge of that in the NAND layer today. It was written 4 years ago when most controllers on the market did little more than bit-bang and/or module the signals to the NAND = since the interfaces at the time were little more than fancy memory mapped memory controllers. > * .. and for reads/writes, the buffer is supplied here, so they can > also be used to setup the DMA transfer, else they're just serialised > out via port banging for dumber NAND controller latches. Yes. > I really want to try and bring this flash chip up (even without > hardware ECC) but I'm kinda worried that in order to do this cleanly > I'm going to have to overhaul nandbus/nfc and a couple of NAND > controllers I don't have (and currently don't want) hardware for. I=92ve also been looking towards this area as well, given my recent NAND history. In fact, I=92ve been putting together a talk for BSDcan on what needs to be done to make the NAND layer sane, cool and groovy. > So, any help/ideas? You already layer it out: You have to be ugly. BTW specifically, what NAND are you talking to? Warner > On 18 March 2014 04:35, Adrian Chadd wrote: >> Hiya, >>=20 >> I've got the atheros ar934x nand controller bits looking like they're >> working on freebsd-head enough to send/receive a READID command with >> an address of 0x0. However, the NAND controller sends commands with >> the cmd and address phases as part of the command, rather than = calling >> send_command / send_address methods called multiple times. >>=20 >> It seems like our nandbus and nand controller layer is a very thin >> shim over what the NAND control messages look like, rather than some >> higher level 'thing' that allows for slightly more intelligent (read: >> DMA/ECC capable) hardware. >>=20 >> So, what gives? >>=20 >>=20 >> -a > _______________________________________________ > freebsd-embedded@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-embedded > To unsubscribe, send any mail to = "freebsd-embedded-unsubscribe@freebsd.org" From owner-freebsd-embedded@FreeBSD.ORG Tue Mar 18 19:05:22 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA6CEAF8 for ; Tue, 18 Mar 2014 19:05:22 +0000 (UTC) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 89D34EEF for ; Tue, 18 Mar 2014 19:05:22 +0000 (UTC) Received: by mail-qc0-f173.google.com with SMTP id r5so8482139qcx.32 for ; Tue, 18 Mar 2014 12:05:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=17/hE3Q3DsM3qKu2VzCc/xjfTOH1xo4kghBeDNqp+7k=; b=UmpVyabx0WD+S+V8aVdJaaHMlzcA4KvxmzrGTZFK+LAkpJpECjk4DZNPi9gUpsHW2W /gq1C9r+dQMc2DfjweHBpxqHta4AH11nkHzIp0fNIp6MbO0G3bpxvVyjFCP5SMwA97x6 6RCZK2JMh5NOP416anQGM2Xw8xG9RTrw3WR707w1dlZXtHgPMQncN/WPP7BoKmeSKkeS X7i42ECshMGfZjJean/D/S2JPVz+hBgsUAiQ2eaAnZMRmPXSdivmxGUvrK7iNhM4BzSB suQb/uQomHuRmJjIA3Z1YaDqLoDeGV+JspTn29NO8DtecT4ltr6ajco/hcmSwmxf/FPz Wk9w== MIME-Version: 1.0 X-Received: by 10.140.50.169 with SMTP id s38mr36003972qga.12.1395169521779; Tue, 18 Mar 2014 12:05:21 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.8.137 with HTTP; Tue, 18 Mar 2014 12:05:20 -0700 (PDT) In-Reply-To: <5BF1217D-6423-443B-A3AB-1722CDDDAD74@bsdimp.com> References: <5BF1217D-6423-443B-A3AB-1722CDDDAD74@bsdimp.com> Date: Tue, 18 Mar 2014 12:05:20 -0700 X-Google-Sender-Auth: 6lXUbFZRYIuW1VUNY-unSix3Dfs Message-ID: Subject: Re: nand controller - how should one handle controllers that want the command+address bits together? From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 19:05:22 -0000 [snip] Off-hand, it's some 128MiB Hynix part. I'd give you the ID bytes, but so far I can't get at them all. :-) -a From owner-freebsd-embedded@FreeBSD.ORG Tue Mar 18 20:59:22 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ACEC5FDC for ; Tue, 18 Mar 2014 20:59:22 +0000 (UTC) Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7CAD2D5F for ; Tue, 18 Mar 2014 20:59:22 +0000 (UTC) Received: by mail-pd0-f178.google.com with SMTP id x10so7626184pdj.23 for ; Tue, 18 Mar 2014 13:59:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=QgQXl+E7ZaQUkc5McNmmSdKtzJatRTpHpwmD0gXCiKM=; b=WeM4Rci/c4ChiepoxtqrvJ5pQbahsDw0OR7c1CWe4rVZztflOm/kLd/+TyBZWPd0Mn e5Dyq+cH4cFFnsxUDiiwXtH8+hZtlzRvAXmQfn7t8tOPf2f0qEHFhEurFs88HWMNn9tW kR0oVq7oWXP2ydecCa7DQPG800Thi4F2JelIw+zDJ2ksUAgfHB/lSRMyzJBqF3Upv1+Z /Qzpy+0xY5Rqu1IgUtzPl4IWeaq0KqnuRnHh93oIw9b4r5Lypsd/i6OmSp95A5Bi4dTy 6gi+l4AXB0WhhmObMdeXoTLgg5PUjJiE2Gfa0tiwcNQIo+RSf2DwgPW/limWzTRavkbK 8TaQ== X-Gm-Message-State: ALoCoQm5URSgW3mQ5Sv3pXqQECY7PsvOJ3JlrmO6Np+TrE70NzFIqUNohazTezr7KMeiXl+LaNm6 X-Received: by 10.66.193.161 with SMTP id hp1mr27305185pac.20.1395175983155; Tue, 18 Mar 2014 13:53:03 -0700 (PDT) Received: from bsdimp.corp.netflix.com ([69.53.237.72]) by mx.google.com with ESMTPSA id sh5sm55546064pbc.21.2014.03.18.13.53.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Mar 2014 13:53:02 -0700 (PDT) Sender: Warner Losh Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: nand controller - how should one handle controllers that want the command+address bits together? From: Warner Losh In-Reply-To: Date: Tue, 18 Mar 2014 13:53:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5BF1217D-6423-443B-A3AB-1722CDDDAD74@bsdimp.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1874) Cc: "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 20:59:22 -0000 On Mar 18, 2014, at 12:05 PM, Adrian Chadd wrote: > [snip] >=20 > Off-hand, it's some 128MiB Hynix part. >=20 > I'd give you the ID bytes, but so far I can't get at them all. :-) >=20 128MiB is 1Gib part. On that part, 1 bit of ECC is almost certainly = sufficient, especially if this is a SLC part, which we have with our software = implementation. Warner From owner-freebsd-embedded@FreeBSD.ORG Wed Mar 19 07:51:59 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4B17FCD0 for ; Wed, 19 Mar 2014 07:51:59 +0000 (UTC) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0AD1A1C0 for ; Wed, 19 Mar 2014 07:51:58 +0000 (UTC) Received: by mail-qa0-f52.google.com with SMTP id m5so8048128qaj.25 for ; Wed, 19 Mar 2014 00:51:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=siCM9bq/kK64UMZ+XHJ1v8qi2khac21D4aZB29ylSV4=; b=gLw8jCkKAVEy35qHfb22336/VCSRMkgPp+tgYyJq9UC6EWbeyabMkz7jpAwPnPtHQ0 bsC86/T3dAwf4J1PZZp+4lel36/w13tsnK8fXO7d/ZpUeBkUXtEsYeIjVJjcSSCZpkTw Nkycrtu9wHncnnbR1XR9bicGsFNKL2uWMDUba9HmcA6C62CtdtEbFxXqSJMfPH3CTSUj LALcE7BnP+ZTH2iXEzoIbFVwvrYrQmAyb+g0E4XAIMaNoKr7kxR8KVYfFpIRM3DpPv9/ DfyUPshlQpQ5zCRQhN87s5M7Ut1NOFi+iRdTOJzg9qvVA5hYu88V4DoSceJwiVCLBJwu F+Kg== MIME-Version: 1.0 X-Received: by 10.224.29.4 with SMTP id o4mr19760983qac.55.1395215518284; Wed, 19 Mar 2014 00:51:58 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.8.137 with HTTP; Wed, 19 Mar 2014 00:51:58 -0700 (PDT) In-Reply-To: <5BF1217D-6423-443B-A3AB-1722CDDDAD74@bsdimp.com> References: <5BF1217D-6423-443B-A3AB-1722CDDDAD74@bsdimp.com> Date: Wed, 19 Mar 2014 00:51:58 -0700 X-Google-Sender-Auth: N_38wnC1pcLWO_HKvJTZD_se3O0 Message-ID: Subject: Re: nand controller - how should one handle controllers that want the command+address bits together? From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 07:51:59 -0000 On 18 March 2014 07:12, Warner Losh wrote: > Because the state machines needed for different NAND types more or > less require the 'low level' interface that we have today. The different > phases in setting up a transaction vary somewhat between the different > types of NAND, and we have no real knowledge of that in the NAND layer > today. It was written 4 years ago when most controllers on the market > did little more than bit-bang and/or module the signals to the NAND since > the interfaces at the time were little more than fancy memory mapped > memory controllers. Right. > I've also been looking towards this area as well, given my recent > NAND history. In fact, I've been putting together a talk for BSDcan > on what needs to be done to make the NAND layer sane, cool and > groovy. I may have to come to bsdcan then. You have a DB120; take a look at the ar934x-nfc.c code in openwrt and see what they do. There's apparently a PIO mechanism. It's unclear how to use it and honestly I wouldn't want to. -a From owner-freebsd-embedded@FreeBSD.ORG Wed Mar 19 15:07:11 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 56D1BE08 for ; Wed, 19 Mar 2014 15:07:11 +0000 (UTC) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 26E46262 for ; Wed, 19 Mar 2014 15:07:10 +0000 (UTC) Received: by mail-pa0-f50.google.com with SMTP id kq14so9127430pab.9 for ; Wed, 19 Mar 2014 08:07:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Z4fVQowOcrCOQTOBworxY+6C6jT8BFL1YjlQ+DJk/lI=; b=UBuHkPTDcehHdN9YiWs3JL4mufu4nncv/4RXe7oRrGnvw667/Px2aX3fNPZh8IH1Qt vMfdVVUomyAyl7a5QyOV8V5b4d6ON5MdImu5aL+A38UqWvB4jNcXTmNNcs7CMtZ9yAP+ h2DpVRcWX1EvEbOhpKk/9+tA20DrvOlTZbVlbVx0hafAQmw6ZNC6aCjJgED4e20cHe4+ t73KdKi2V+mXvvDD9qLXmc7r2Jk2OuoJZZWVmQIfcw4c2DAnRkAdVBVaUYPpHdCK7JNb MfH9kcYDkIm99qMmOJCDQUsgylzHiqEk5O8Arivcw3KbsmRGr4W/VJ+psFZEx7P8Yryt MssQ== X-Gm-Message-State: ALoCoQlTyW0g02ie754BK0QK0VxhCLdla2Z+BNolUMRfk8/3TXkX72h0sno/7JAfkviRlGNlG+t6 X-Received: by 10.68.201.10 with SMTP id jw10mr40449754pbc.25.1395241630274; Wed, 19 Mar 2014 08:07:10 -0700 (PDT) Received: from bsdimp.corp.netflix.com ([69.53.237.72]) by mx.google.com with ESMTPSA id vd8sm11865677pac.12.2014.03.19.08.06.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Mar 2014 08:06:31 -0700 (PDT) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: nand controller - how should one handle controllers that want the command+address bits together? From: Warner Losh In-Reply-To: Date: Wed, 19 Mar 2014 08:06:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <72D01ACF-F827-48E7-82DF-6728E5FC24EE@bsdimp.com> References: <5BF1217D-6423-443B-A3AB-1722CDDDAD74@bsdimp.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1874) Cc: "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 15:07:11 -0000 On Mar 19, 2014, at 12:51 AM, Adrian Chadd wrote: > On 18 March 2014 07:12, Warner Losh wrote: >=20 >> Because the state machines needed for different NAND types more or >> less require the 'low level' interface that we have today. The = different >> phases in setting up a transaction vary somewhat between the = different >> types of NAND, and we have no real knowledge of that in the NAND = layer >> today. It was written 4 years ago when most controllers on the market >> did little more than bit-bang and/or module the signals to the NAND = since >> the interfaces at the time were little more than fancy memory mapped >> memory controllers. >=20 > Right. >=20 >=20 >> I've also been looking towards this area as well, given my recent >> NAND history. In fact, I've been putting together a talk for BSDcan >> on what needs to be done to make the NAND layer sane, cool and >> groovy. >=20 > I may have to come to bsdcan then. >=20 > You have a DB120; take a look at the ar934x-nfc.c code in openwrt and > see what they do. OK. > There's apparently a PIO mechanism. It's unclear how to use it and > honestly I wouldn't want to. I=92ll give it a look when I climb back into the NAND world here next = week or so (I was planning on being somewhat specific in my talk at BSDcan, so need to re-review my notes I=92ve taken so far). I=92ll see if I can get = you early access to my talk (meaning, I=92ll see if I can finish early :). Warner From owner-freebsd-embedded@FreeBSD.ORG Mon Mar 24 11:06:43 2014 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 69989F48 for ; Mon, 24 Mar 2014 11:06:43 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 55BE4168 for ; Mon, 24 Mar 2014 11:06:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s2OB6htn013809 for ; Mon, 24 Mar 2014 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s2OB6g8u013807 for freebsd-embedded@FreeBSD.org; Mon, 24 Mar 2014 11:06:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 24 Mar 2014 11:06:42 GMT Message-Id: <201403241106.s2OB6g8u013807@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-embedded@FreeBSD.org Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 11:06:43 -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 misc/52256 embedded [picobsd] picobsd build script does not read in user/s o kern/42728 embedded [picobsd] many problems in src/usr.sbin/ppp/* after c 2 problems total. From owner-freebsd-embedded@FreeBSD.ORG Wed Mar 26 21:48:11 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E17F9A4D; Wed, 26 Mar 2014 21:48:11 +0000 (UTC) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 93D74B4; Wed, 26 Mar 2014 21:48:11 +0000 (UTC) Received: by mail-oa0-f51.google.com with SMTP id i4so3362289oah.38 for ; Wed, 26 Mar 2014 14:48:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=dhIs9ATkYT7shaF2Jf4GhdTAth5bI+QiKB3sGIOXtR4=; b=m8xOIm3ffKIvHEB5EM/ejMfMzkg4wDHeU/8qeXJ8qmdhK/hcMpqg7TdVIA077YjZSL lWYDSHi2ty6cLV6nelFDRStB1qPJRAV/UdTrtDP1aOJ3mIo0Z2MiIdptlP8x+ZBQd8OH cap6ooqbAw+mPvK2qUArnG7Juv+zb4zeYrxczz3oH8rtJWzdrMvio4XYHKTVrcYietF/ x5HgxqqY39KHC6tfmUFi38ooqCbY8TTXYeBR73M3oGq4Vfd/Rs6Tpm9xIoG2ksqxs/Zi Hw2unKg7kiQG3QTZtjToscJY7hKbAp6EofRsjeDl86puQ/nBi/tN81Ej4EbK9SFsX6Um LOUQ== MIME-Version: 1.0 X-Received: by 10.182.33.6 with SMTP id n6mr18203249obi.48.1395870490992; Wed, 26 Mar 2014 14:48:10 -0700 (PDT) Received: by 10.60.227.194 with HTTP; Wed, 26 Mar 2014 14:48:10 -0700 (PDT) Date: Wed, 26 Mar 2014 18:48:10 -0300 Message-ID: Subject: Cross-compiling a kernel module? From: Martin Galvan To: freebsd-arm@freebsd.org, freebsd-drivers@freebsd.org, freebsd-embedded@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 21:48:12 -0000 Hi everyone! I'm trying to cross-compile a simple Hello World module for the A10 Cubieboard (which is ARM/Allwinner10 based) but I'm not sure of how to write my makefile. What I'm using to test it (on an amd64) is: KMOD=hello SRCS=hello.c .include I've been browsing the mailing list a bit and so far I've found a way but it involves rebuilding the whole kernel, and I just want to compile this module to load/unload in runtime. Also, before you answer this: try and be as specific as you can, since I'm kind of a newbie at this. Stuff like where should I put/look for files, run commands, etc would be appreciated. From owner-freebsd-embedded@FreeBSD.ORG Wed Mar 26 22:44:50 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE049E42; Wed, 26 Mar 2014 22:44:50 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9AA0084F; Wed, 26 Mar 2014 22:44:50 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s2QMihjj085315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Mar 2014 15:44:43 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s2QMihw3085314; Wed, 26 Mar 2014 15:44:43 -0700 (PDT) (envelope-from jmg) Date: Wed, 26 Mar 2014 15:44:43 -0700 From: John-Mark Gurney To: Martin Galvan Subject: Re: Cross-compiling a kernel module? Message-ID: <20140326224443.GN60889@funkthat.com> Mail-Followup-To: Martin Galvan , freebsd-arm@freebsd.org, freebsd-drivers@freebsd.org, freebsd-embedded@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 26 Mar 2014 15:44:43 -0700 (PDT) Cc: freebsd-arm@freebsd.org, freebsd-drivers@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 22:44:50 -0000 Martin Galvan wrote this message on Wed, Mar 26, 2014 at 18:48 -0300: > Hi everyone! I'm trying to cross-compile a simple Hello World module for > the A10 Cubieboard (which is ARM/Allwinner10 based) but I'm not sure of how > to write my makefile. What I'm using to test it (on an amd64) is: > > KMOD=hello > SRCS=hello.c > > .include > > I've been browsing the mailing list a bit and so far I've found a way but > it involves rebuilding the whole kernel, and I just want to compile this > module to load/unload in runtime. > > Also, before you answer this: try and be as specific as you can, since I'm > kind of a newbie at this. Stuff like where should I put/look for files, run > commands, etc would be appreciated. $ cd $SRC $ make kernel-toolchain TARGET_ARCH=armXX $ make buildenv TARGET_ARCH=armXX BUILDENV_SHELL=/usr/local/bin/shell $ cd $ make The buildenv command sets up the new shell with an environment that is the same as if you were running under a buildkernel or buildworld environment.. You can use this to build one off programs like bin/ls too. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-embedded@FreeBSD.ORG Thu Mar 27 02:48:27 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 742132BC for ; Thu, 27 Mar 2014 02:48:27 +0000 (UTC) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 42655F3B for ; Thu, 27 Mar 2014 02:48:26 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id lx4so2644773iec.24 for ; Wed, 26 Mar 2014 19:48:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=Qw2cJDgDN8Ml1k3/7GLIzae94RPnDUzcqjKVdPRrSVA=; b=nMVT3H/WxtX1ofiIcFNOXBV68hjmVXSc5wPtcOdHNoOCrRW12hgu73rVKt8WBa3kgh XNG/9IE2+QuGfC2QTC9OGt2sLqRlh8StGBUGfluXS8GPxo9MJvQYwNIlfwu0Rp2U1pMe psfdijV2cRMeQqZOXufOod3GA7XrawjW0qbEx+QQLDlJfVcdFHO3OUmoZl6YfXJlyj9f ZWuHMP0vo8dxzpqRzOb0ACLDt9GFuYZQnWBcqIut5a0qdHWflKi9CgLyWrOEjhasuzH/ dFn3T1e+sU1/okrd+522DOH9AJla5kxW4Uh0/pBG0rsg027XBNXIM79h/6+XxsVupgrM YkPA== X-Gm-Message-State: ALoCoQk4OficPVlvBwvBIYo1Vmq6V7XE8EXPBsfoC/FadfnFHHPmQlsnOLEOQmtOfpJgFaiofTn9n6MGVtHyZ6RAxkR6CIbv9kkhmpxgvtjan6G3/1PMjok= X-Received: by 10.42.10.82 with SMTP id p18mr61724659icp.30.1395888500717; Wed, 26 Mar 2014 19:48:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.128.200 with HTTP; Wed, 26 Mar 2014 19:48:05 -0700 (PDT) From: "Lundberg, Johannes" Date: Thu, 27 Mar 2014 11:48:05 +0900 Message-ID: Subject: Jetson TK1 from nVidia ships in April, pre-order started To: freebsd-embedded@freebsd.org, "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 02:48:27 -0000 Hi Just noticed that K1 development board from nVidia has been publicly announced. https://developer.nvidia.com/jetson-tk1 It would enable some really cool applications if we could achieve two things 1) Get FreeBSD running on TK1 including HDMI graphical output support 2) Get nVidia to add native CUDA support for FreeBSD Think we can make this happen? Best regards -- Johannes Lundberg -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- $BHkL)J];}$K$D$$$F!'$3$NEE;R%a!<%k$O!"L>08?M$KAw?.$7$?$b$N$G$"$j!"HkF?FC8"$NBP>]$H$J$k>pJs$r4^$s$G$$$^$9!#(B $B$b$7!"L>08?M0J30$NJ}$,l9g!"$3$N%a!<%k$NGK4~!"$*$h$S$3$N%a!<%k$K4X$9$k0l@Z$N3+<(!"(B $BJ#$NMxMQ!"$^$?$O5-:\FbMF$K4p$E$/$$$+$J$k9TF0$b$5$l$J$$$h$&$*4j$$?=$7>e$2$^$9!#(B --- CONFIDENTIALITY NOTE: The information in this email is confidential and intended solely for the addressee. Disclosure, copying, distribution or any other action of use of this email by person other than intended recipient, is prohibited. If you are not the intended recipient and have received this email in error, please destroy the original message. From owner-freebsd-embedded@FreeBSD.ORG Thu Mar 27 04:52:49 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE954393; Thu, 27 Mar 2014 04:52:49 +0000 (UTC) Received: from mx0.deglitch.com (unknown [IPv6:2001:16d8:ff00:19d::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8943AC62; Thu, 27 Mar 2014 04:52:49 +0000 (UTC) Received: from [192.168.11.2] (unknown [98.234.106.231]) by mx0.deglitch.com (Postfix) with ESMTPSA id CB4258FC40; Thu, 27 Mar 2014 08:52:16 +0400 (MSK) Content-Type: multipart/signed; boundary="Apple-Mail=_17B55FD1-4D6A-4AF4-AA36-6FF2ADE37135"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Cross-compiling a kernel module? From: Stanislav Sedov In-Reply-To: <20140326224443.GN60889@funkthat.com> Date: Wed, 26 Mar 2014 21:52:05 -0700 Message-Id: <28B91494-CCBB-4050-8E01-7B2BF0C4ABC9@freebsd.org> References: <20140326224443.GN60889@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1874) Cc: freebsd-arm@freebsd.org, Martin Galvan , freebsd-drivers@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 04:52:49 -0000 --Apple-Mail=_17B55FD1-4D6A-4AF4-AA36-6FF2ADE37135 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Mar 26, 2014, at 3:44 PM, John-Mark Gurney wrote: > $ cd $SRC > $ make kernel-toolchain TARGET_ARCH=3DarmXX > $ make buildenv TARGET_ARCH=3DarmXX = BUILDENV_SHELL=3D/usr/local/bin/shell > $ cd > $ make >=20 > The buildenv command sets up the new shell with an environment that is > the same as if you were running under a buildkernel or buildworld > environment.. You can use this to build one off programs like bin/ls > too. Don=92t forget to set the KERNBUILDDIR option as well to point to your kernel object dir so the module will pick up all the right options. -- ST4096-RIPE --Apple-Mail=_17B55FD1-4D6A-4AF4-AA36-6FF2ADE37135 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJTM651AAoJEG2OTJ9WF+r7tpsH/2OjyJcF/w2b24ETxVDePTXW U+nvYCU5ZwC2abZfkZ0Y41q3oKgzNp9kcphu4IDzhnSgcaVxDtxl6g/EsmTvaeJs VKq/4PJUL5qpO2HFdnEiVM7xO8ipGk+lp0prRIG2KXEznQfZC8EcYd0lvyC/vcqY hNKX3daGA7L+qPcGrcCeBkYS21MOGKGvRmHJvZ02I7aZVqcKB8HMWXITIjkRmI/0 ryHb27JLLQ88ZezZWrU/csRiDrSsYhJzPOv9eMBwIml2bULQXjhQUX+UixfFtZw8 R9wWmhjUb0i5jdk2clCtnVPkHkyiNON+WMOJrw2qczdJXPUhE/hEyjZF/jBd9q4= =ntF/ -----END PGP SIGNATURE----- --Apple-Mail=_17B55FD1-4D6A-4AF4-AA36-6FF2ADE37135-- From owner-freebsd-embedded@FreeBSD.ORG Thu Mar 27 17:19:38 2014 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0DB272CC; Thu, 27 Mar 2014 17:19:38 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B57F9B95; Thu, 27 Mar 2014 17:19:37 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WTDxo-000HPG-3M; Thu, 27 Mar 2014 17:19:36 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s2RHJXbm078895; Thu, 27 Mar 2014 11:19:33 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/wh05co1opAsvxX2mjGbDa Subject: Supporting higher baud rates in newer FTDI chips From: Ian Lepore To: freebsd-embedded@FreeBSD.org, freebsd-usb@FreeBSD.org Content-Type: multipart/mixed; boundary="=-IEciT+MNHOgmdlZ3e4gk" Date: Thu, 27 Mar 2014 11:19:33 -0600 Message-ID: <1395940773.81853.113.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 17:19:38 -0000 --=-IEciT+MNHOgmdlZ3e4gk Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have added support to the uftdi driver for the higher baud rates supported by the latest H-series chips. I hope to commit the changes soon; the patch is attached for review. In the process I discovered we've been setting the rate wrong on the older chips (we put the high bit of the fractional rate in the wrong place, but it only affects very high non-standard bit rates). Because the old code was wrong I ended up basically rewriting everything related to calculating and setting the baud rate. The newer chips use the same product ID as the earlier ones, so I wrote some new code to use the bcdDevice field from the device descriptor to determine the model and version of chip. I've tested this on all the chips I have around: 232R, 2232C, 2232D, 2232H, and 4232H. -- Ian --=-IEciT+MNHOgmdlZ3e4gk Content-Disposition: inline; filename="uftdi_baudrate2.diff" Content-Type: text/x-patch; name="uftdi_baudrate2.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: sys/dev/usb/serial/uftdi_reg.h =================================================================== --- sys/dev/usb/serial/uftdi_reg.h (revision 263112) +++ sys/dev/usb/serial/uftdi_reg.h (working copy) @@ -75,31 +75,13 @@ /* * BmRequestType: 0100 0000B * bRequest: FTDI_SIO_SET_BAUDRATE - * wValue: BaudRate value - see below - * wIndex: Port + * wValue: BaudRate low bits + * wIndex: Port and BaudRate high bits * wLength: 0 * Data: None */ /* FTDI_SIO_SET_BAUDRATE */ -enum { - ftdi_sio_b300 = 0, - ftdi_sio_b600 = 1, - ftdi_sio_b1200 = 2, - ftdi_sio_b2400 = 3, - ftdi_sio_b4800 = 4, - ftdi_sio_b9600 = 5, - ftdi_sio_b19200 = 6, - ftdi_sio_b38400 = 7, - ftdi_sio_b57600 = 8, - ftdi_sio_b115200 = 9 -}; -#define FTDI_8U232AM_FREQ 3000000 - -/* Bounds for normal divisors as 4-bit fixed precision ints. */ -#define FTDI_8U232AM_MIN_DIV 0x20 -#define FTDI_8U232AM_MAX_DIV 0x3fff8 - /* * BmRequestType: 0100 0000B * bRequest: FTDI_SIO_SET_DATA Index: sys/dev/usb/serial/uftdi.c =================================================================== --- sys/dev/usb/serial/uftdi.c (revision 263112) +++ sys/dev/usb/serial/uftdi.c (working copy) @@ -92,6 +92,21 @@ enum { UFTDI_N_TRANSFER, }; +enum { + DEVT_SIO, + DEVT_232A, + DEVT_232B, + DEVT_2232D, /* Includes 2232C */ + DEVT_232R, + DEVT_2232H, + DEVT_4232H, + DEVT_232H, + DEVT_230X, +}; + +#define DEVF_BAUDBITS_HINDEX 0x01 /* Baud bits in high byte of index. */ +#define DEVF_BAUDCLK_12M 0X02 /* Base baud clock is 12MHz. */ + struct uftdi_softc { struct ucom_super_softc sc_super_ucom; struct ucom_softc sc_ucom; @@ -105,15 +120,16 @@ struct uftdi_softc { uint16_t sc_last_lcr; - uint8_t sc_type; - uint8_t sc_iface_index; + uint8_t sc_devtype; + uint8_t sc_devflags; uint8_t sc_hdrlen; uint8_t sc_msr; uint8_t sc_lsr; }; struct uftdi_param_config { - uint16_t rate; + uint16_t baud_lobits; + uint16_t baud_hibits; uint16_t lcr; uint8_t v_start; uint8_t v_stop; @@ -135,8 +151,8 @@ static void uftdi_cfg_open(struct ucom_softc *); static void uftdi_cfg_set_dtr(struct ucom_softc *, uint8_t); static void uftdi_cfg_set_rts(struct ucom_softc *, uint8_t); static void uftdi_cfg_set_break(struct ucom_softc *, uint8_t); -static int uftdi_set_parm_soft(struct termios *, - struct uftdi_param_config *, uint8_t); +static int uftdi_set_parm_soft(struct ucom_softc *, struct termios *, + struct uftdi_param_config *); static int uftdi_pre_param(struct ucom_softc *, struct termios *); static void uftdi_cfg_param(struct ucom_softc *, struct termios *); static void uftdi_cfg_get_status(struct ucom_softc *, uint8_t *, @@ -145,7 +161,6 @@ static void uftdi_start_read(struct ucom_softc *); static void uftdi_stop_read(struct ucom_softc *); static void uftdi_start_write(struct ucom_softc *); static void uftdi_stop_write(struct ucom_softc *); -static uint8_t uftdi_8u232am_getrate(uint32_t, uint16_t *); static void uftdi_poll(struct ucom_softc *ucom); static const struct usb_config uftdi_config[UFTDI_N_TRANSFER] = { @@ -846,6 +861,80 @@ static const STRUCT_USB_HOST_ID uftdi_devs[] = { #undef UFTDI_DEV }; +/* + * Set up softc fields whose value depends on the device type. + * + * Note that the 2232C and 2232D devices are the same for our purposes. In the + * silicon the difference is that the D series has CPU FIFO mode and C doesn't. + * I haven't found any way of determining the C/D difference from info provided + * by the chip other than trying to set CPU FIFO mode and having it work or not. + * + * Due to a hardware bug, a 232B chip without an eeprom reports itself as a + * 232A, but if the serial number is also zero we know it's really a 232B. + */ +static void +uftdi_devtype_setup(struct uftdi_softc *sc, struct usb_attach_arg *uaa) +{ + struct usb_device_descriptor *dd; + + switch (uaa->info.bcdDevice) { + case 0x200: + dd = usbd_get_device_descriptor(sc->sc_udev); + if (dd->iSerialNumber == 0) { + sc->sc_devtype = DEVT_232B; + } else { + sc->sc_devtype = DEVT_232A; + } + sc->sc_ucom.sc_portno = 0; + break; + case 0x400: + sc->sc_devtype = DEVT_232B; + sc->sc_ucom.sc_portno = 0; + break; + case 0x500: + sc->sc_devtype = DEVT_2232D; + sc->sc_devflags |= DEVF_BAUDBITS_HINDEX; + sc->sc_ucom.sc_portno = FTDI_PIT_SIOA + uaa->info.bIfaceNum; + break; + case 0x600: + sc->sc_devtype = DEVT_232R; + sc->sc_ucom.sc_portno = 0; + break; + case 0x700: + sc->sc_devtype = DEVT_2232H; + sc->sc_devflags |= DEVF_BAUDBITS_HINDEX | DEVF_BAUDCLK_12M; + sc->sc_ucom.sc_portno = FTDI_PIT_SIOA + uaa->info.bIfaceNum; + break; + case 0x800: + sc->sc_devtype = DEVT_4232H; + sc->sc_devflags |= DEVF_BAUDBITS_HINDEX | DEVF_BAUDCLK_12M; + sc->sc_ucom.sc_portno = FTDI_PIT_SIOA + uaa->info.bIfaceNum; + break; + case 0x900: + sc->sc_devtype = DEVT_232H; + sc->sc_devflags |= DEVF_BAUDBITS_HINDEX | DEVF_BAUDCLK_12M; + sc->sc_ucom.sc_portno = FTDI_PIT_SIOA + uaa->info.bIfaceNum; + break; + case 0x1000: + sc->sc_devtype = DEVT_230X; + sc->sc_devflags |= DEVF_BAUDBITS_HINDEX; + sc->sc_ucom.sc_portno = FTDI_PIT_SIOA + uaa->info.bIfaceNum; + break; + default: + if (uaa->info.bcdDevice < 0x200) { + sc->sc_devtype = DEVT_SIO; + sc->sc_hdrlen = 1; + } else { + sc->sc_devtype = DEVT_232R; + device_printf(sc->sc_dev, "Warning: unknown FTDI " + "device type, bcdDevice=0x%04x, assuming 232R", + uaa->info.bcdDevice); + } + sc->sc_ucom.sc_portno = 0; + break; + } +} + static int uftdi_probe(device_t dev) { @@ -885,6 +974,8 @@ uftdi_attach(device_t dev) struct uftdi_softc *sc = device_get_softc(dev); int error; + DPRINTF("\n"); + sc->sc_udev = uaa->device; sc->sc_dev = dev; sc->sc_unit = device_get_unit(dev); @@ -893,34 +984,11 @@ uftdi_attach(device_t dev) mtx_init(&sc->sc_mtx, "uftdi", NULL, MTX_DEF); ucom_ref(&sc->sc_super_ucom); - DPRINTF("\n"); - sc->sc_iface_index = uaa->info.bIfaceIndex; - sc->sc_type = USB_GET_DRIVER_INFO(uaa) & UFTDI_TYPE_MASK; + uftdi_devtype_setup(sc, uaa); - switch (sc->sc_type) { - case UFTDI_TYPE_AUTO: - /* simplified type check */ - if (uaa->info.bcdDevice >= 0x0200 || - usbd_get_iface(uaa->device, 1) != NULL) { - sc->sc_type = UFTDI_TYPE_8U232AM; - sc->sc_hdrlen = 0; - } else { - sc->sc_type = UFTDI_TYPE_SIO; - sc->sc_hdrlen = 1; - } - break; - case UFTDI_TYPE_SIO: - sc->sc_hdrlen = 1; - break; - case UFTDI_TYPE_8U232AM: - default: - sc->sc_hdrlen = 0; - break; - } - error = usbd_transfer_setup(uaa->device, - &sc->sc_iface_index, sc->sc_xfer, uftdi_config, + &uaa->info.bIfaceIndex, sc->sc_xfer, uftdi_config, UFTDI_N_TRANSFER, sc, &sc->sc_mtx); if (error) { @@ -928,8 +996,6 @@ uftdi_attach(device_t dev) "transfers failed\n"); goto detach; } - sc->sc_ucom.sc_portno = FTDI_PIT_SIOA + uaa->info.bIfaceNum; - /* clear stall at first run */ mtx_lock(&sc->sc_mtx); usbd_xfer_set_stall(sc->sc_xfer[UFTDI_BULK_DT_WR]); @@ -1192,58 +1258,162 @@ uftdi_cfg_set_break(struct ucom_softc *ucom, uint8 &req, NULL, 0, 1000); } +/* + * Return true if the given speed is within operational tolerance of the target + * speed. FTDI recommends that the hardware speed be within 3% of nominal. + */ +static inline boolean_t +uftdi_baud_within_tolerance(uint64_t speed, uint64_t target) +{ + return ((speed >= (target * 100) / 103) && + (speed <= (target * 100) / 97)); +} + static int -uftdi_set_parm_soft(struct termios *t, - struct uftdi_param_config *cfg, uint8_t type) +uftdi_sio_encode_baudrate(struct uftdi_softc *sc, speed_t speed, + struct uftdi_param_config *cfg) { + u_int i; + const speed_t sio_speeds[] = { + 300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200 + }; - memset(cfg, 0, sizeof(*cfg)); - - switch (type) { - case UFTDI_TYPE_SIO: - switch (t->c_ospeed) { - case 300: - cfg->rate = ftdi_sio_b300; - break; - case 600: - cfg->rate = ftdi_sio_b600; - break; - case 1200: - cfg->rate = ftdi_sio_b1200; - break; - case 2400: - cfg->rate = ftdi_sio_b2400; - break; - case 4800: - cfg->rate = ftdi_sio_b4800; - break; - case 9600: - cfg->rate = ftdi_sio_b9600; - break; - case 19200: - cfg->rate = ftdi_sio_b19200; - break; - case 38400: - cfg->rate = ftdi_sio_b38400; - break; - case 57600: - cfg->rate = ftdi_sio_b57600; - break; - case 115200: - cfg->rate = ftdi_sio_b115200; - break; - default: - return (EINVAL); + /* + * The original SIO chips were limited to a small choice of speeds + * listed in an internal table of speeds chosen by an index value. + */ + for (i = 0; i < nitems(sio_speeds); ++i) { + if (speed == sio_speeds[i]) { + cfg->baud_lobits = i; + cfg->baud_hibits = 0; + return (0); } - break; + } + return (ERANGE); +} - case UFTDI_TYPE_8U232AM: - if (uftdi_8u232am_getrate(t->c_ospeed, &cfg->rate)) { - return (EINVAL); - } - break; +static int +uftdi_encode_baudrate(struct uftdi_softc *sc, speed_t speed, + struct uftdi_param_config *cfg) +{ + static const uint8_t encoded_fraction[8] = {0, 3, 2, 4, 1, 5, 6, 7}; + static const uint8_t roundoff_232a[16] = { + 0, 1, 0, 1, 0, -1, 2, 1, + 0, -1, -2, -3, 4, 3, 2, 1, + }; + uint32_t clk, divisor, fastclk_flag, frac, hwspeed; + + /* + * If this chip has the fast clock capability and the speed is within + * range, use the 12MHz clock, otherwise the standard clock is 3MHz. + */ + if ((sc->sc_devflags & DEVF_BAUDCLK_12M) && speed >= 1200) { + clk = 12000000; + fastclk_flag = (1 << 17); + } else { + clk = 3000000; + fastclk_flag = 0; } + /* + * Make sure the requested speed is reachable with the available clock + * and a 14-bit divisor. + */ + if (speed < (clk >> 14) || speed > clk) + return (ERANGE); + + /* + * Calculate the divisor, initially yielding a fixed point number with a + * 4-bit (1/16ths) fraction, then round it to the nearest fraction the + * hardware can handle. When the integral part of the divisor is + * greater than one, the fractional part is in 1/8ths of the base clock. + * The FT8U232AM chips can handle only 0.125, 0.250, and 0.5 fractions. + * Later chips can handle all 1/8th fractions. + * + * If the integral part of the divisor is 1, a special rule applies: the + * fractional part can only be .0 or .5 (this is a limitation of the + * hardware). We handle this by truncating the fraction rather than + * rounding, because this only applies to the two fastest speeds the + * chip can achieve and rounding doesn't matter, either you've asked for + * that exact speed or you've asked for something the chip can't do. + * + * For the FT8U232AM chips, use a roundoff table to adjust the result + * to the nearest 1/8th fraction that is supported by the hardware, + * leaving a fixed-point number with a 3-bit fraction which exactly + * represents the math the hardware divider will do. For later-series + * chips that support all 8 fractional divisors, just round 16ths to + * 8ths by adding 1 and dividing by 2. + */ + divisor = (clk << 4) / speed; + if ((divisor & 0xfffffff0) == 1) + divisor &= 0xfffffff8; + else if (sc->sc_devtype == DEVT_232A) + divisor += roundoff_232a[divisor & 0x0f]; + else + divisor += 1; /* Rounds odd 16ths up to next 8th. */ + divisor >>= 1; + + /* + * Ensure the resulting hardware speed will be within operational + * tolerance (within 3% of nominal). + */ + hwspeed = (clk << 3) / divisor; + if (!uftdi_baud_within_tolerance(hwspeed, speed)) + return (ERANGE); + + /* + * Re-pack the divisor into hardware format. The lower 14-bits hold the + * integral part, while the upper bits specify the fraction by indexing + * a table of fractions within the hardware which is laid out as: + * {0.0, 0.5, 0.25, 0.125, 0.325, 0.625, 0.725, 0.875} + * The A-series chips only have the first four table entries; the + * roundoff table logic above ensures that the fractional part for those + * chips will be one of the first four values. + * + * When the divisor is 1 a special encoding applies: 1.0 is encoded as + * 0.0, and 1.5 is encoded as 1.0. The rounding logic above has already + * ensured that the fraction is either .0 or .5 if the integral is 1. + */ + frac = divisor & 0x07; + divisor >>= 3; + if (divisor == 1) { + if (frac == 0) + divisor = 0; /* 1.0 becomes 0.0 */ + else + frac = 0; /* 1.5 becomes 1.0 */ + } + divisor |= (encoded_fraction[frac] << 14) | fastclk_flag; + + cfg->baud_lobits = (uint16_t)divisor; + cfg->baud_hibits = (uint16_t)(divisor >> 16); + + /* + * If this chip requires the baud bits to be in the high byte of the + * index word, move the bits up to that location. + */ + if (sc->sc_devflags & DEVF_BAUDBITS_HINDEX) { + cfg->baud_hibits <<= 8; + } + + return (0); +} + +static int +uftdi_set_parm_soft(struct ucom_softc *ucom, struct termios *t, + struct uftdi_param_config *cfg) +{ + struct uftdi_softc *sc = ucom->sc_parent; + int err; + + memset(cfg, 0, sizeof(*cfg)); + + if (sc->sc_devtype == DEVT_SIO) + err = uftdi_sio_encode_baudrate(sc, t->c_ospeed, cfg); + else + err = uftdi_encode_baudrate(sc, t->c_ospeed, cfg); + if (err != 0) + return (err); + if (t->c_cflag & CSTOPB) cfg->lcr = FTDI_SIO_SET_DATA_STOP_BITS_2; else @@ -1293,12 +1463,11 @@ static int static int uftdi_pre_param(struct ucom_softc *ucom, struct termios *t) { - struct uftdi_softc *sc = ucom->sc_parent; struct uftdi_param_config cfg; DPRINTF("\n"); - return (uftdi_set_parm_soft(t, &cfg, sc->sc_type)); + return (uftdi_set_parm_soft(ucom, t, &cfg)); } static void @@ -1309,7 +1478,7 @@ uftdi_cfg_param(struct ucom_softc *ucom, struct te struct uftdi_param_config cfg; struct usb_device_request req; - if (uftdi_set_parm_soft(t, &cfg, sc->sc_type)) { + if (uftdi_set_parm_soft(ucom, t, &cfg)) { /* should not happen */ return; } @@ -1319,8 +1488,8 @@ uftdi_cfg_param(struct ucom_softc *ucom, struct te req.bmRequestType = UT_WRITE_VENDOR_DEVICE; req.bRequest = FTDI_SIO_SET_BAUD_RATE; - USETW(req.wValue, cfg.rate); - USETW(req.wIndex, wIndex); + USETW(req.wValue, cfg.baud_lobits); + USETW(req.wIndex, cfg.baud_hibits | wIndex); USETW(req.wLength, 0); ucom_cfg_do_request(sc->sc_udev, &sc->sc_ucom, &req, NULL, 0, 1000); @@ -1386,75 +1555,6 @@ uftdi_stop_write(struct ucom_softc *ucom) usbd_transfer_stop(sc->sc_xfer[UFTDI_BULK_DT_WR]); } -/*------------------------------------------------------------------------* - * uftdi_8u232am_getrate - * - * Return values: - * 0: Success - * Else: Failure - *------------------------------------------------------------------------*/ -static uint8_t -uftdi_8u232am_getrate(uint32_t speed, uint16_t *rate) -{ - /* Table of the nearest even powers-of-2 for values 0..15. */ - static const uint8_t roundoff[16] = { - 0, 2, 2, 4, 4, 4, 8, 8, - 8, 8, 8, 8, 16, 16, 16, 16, - }; - uint32_t d; - uint32_t freq; - uint16_t result; - - if ((speed < 178) || (speed > ((3000000 * 100) / 97))) - return (1); /* prevent numerical overflow */ - - /* Special cases for 2M and 3M. */ - if ((speed >= ((3000000 * 100) / 103)) && - (speed <= ((3000000 * 100) / 97))) { - result = 0; - goto done; - } - if ((speed >= ((2000000 * 100) / 103)) && - (speed <= ((2000000 * 100) / 97))) { - result = 1; - goto done; - } - d = (FTDI_8U232AM_FREQ << 4) / speed; - d = (d & ~15) + roundoff[d & 15]; - - if (d < FTDI_8U232AM_MIN_DIV) - d = FTDI_8U232AM_MIN_DIV; - else if (d > FTDI_8U232AM_MAX_DIV) - d = FTDI_8U232AM_MAX_DIV; - - /* - * Calculate the frequency needed for "d" to exactly divide down to - * our target "speed", and check that the actual frequency is within - * 3% of this. - */ - freq = (speed * d); - if ((freq < ((FTDI_8U232AM_FREQ * 1600ULL) / 103)) || - (freq > ((FTDI_8U232AM_FREQ * 1600ULL) / 97))) - return (1); - - /* - * Pack the divisor into the resultant value. The lower 14-bits - * hold the integral part, while the upper 2 bits encode the - * fractional component: either 0, 0.5, 0.25, or 0.125. - */ - result = (d >> 4); - if (d & 8) - result |= 0x4000; - else if (d & 4) - result |= 0x8000; - else if (d & 2) - result |= 0xc000; - -done: - *rate = result; - return (0); -} - static void uftdi_poll(struct ucom_softc *ucom) { --=-IEciT+MNHOgmdlZ3e4gk-- From owner-freebsd-embedded@FreeBSD.ORG Fri Mar 28 01:10:15 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8BAC6998; Fri, 28 Mar 2014 01:10:15 +0000 (UTC) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F387198; Fri, 28 Mar 2014 01:10:15 +0000 (UTC) Received: by mail-ig0-f176.google.com with SMTP id uy17so239698igb.9 for ; Thu, 27 Mar 2014 18:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/afRAZHIg8M3DkTrWGt/xSP9kpVk7081kQ52s4lpfQQ=; b=Elo3rOMlWH9U6bDU8wqFTl9z171qFrTAsKAIOqeydzTHlKUSOKs0kcO4yzkiuhPadB Kr7efqndB24HrSc0R+XyyMiuiBcX6lEzABBJb268i7Co6fCwl8sZQ2IUu3EupFBVpr+q YJzteorNKKAgOaHoocMtTrgUjAIJu9kEzUbPn6Hc8GvCjl1DW/biYgiXFWL+3Wnb+nar cxtZhrdil9Vr984IOe+rVqhqFpyQwhps0WOgSu8fquj7HtJhU4cdDxQwrWuxkhSwDvBr nqp1/MB6EhSVAinGmD3SRKYRbJuwbb4piH7Fu1CGPdtwhLLsUYWXAafZNnkdd52aHFII 2+hw== MIME-Version: 1.0 X-Received: by 10.42.50.3 with SMTP id y3mr5335802icf.12.1395969014690; Thu, 27 Mar 2014 18:10:14 -0700 (PDT) Received: by 10.64.107.3 with HTTP; Thu, 27 Mar 2014 18:10:14 -0700 (PDT) In-Reply-To: References: Date: Fri, 28 Mar 2014 09:10:14 +0800 Message-ID: Subject: Re: Jetson TK1 from nVidia ships in April, pre-order started From: Ganbold Tsagaankhuu To: "Lundberg, Johannes" Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-arm@freebsd.org" , freebsd-embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 01:10:15 -0000 On Thu, Mar 27, 2014 at 10:48 AM, Lundberg, Johannes < johannes@brilliantservice.co.jp> wrote: > Hi > > Just noticed that K1 development board from nVidia has been publicly > announced. > > https://developer.nvidia.com/jetson-tk1 > > It would enable some really cool applications if we could achieve two > things > > 1) Get FreeBSD running on TK1 including HDMI graphical output support > 2) Get nVidia to add native CUDA support for FreeBSD > > Think we can make this happen? > I'm not sure how good its documentation or how open it is. By reading incomplete doc and looking through linux/android source code makes slower development, sometimes waste of time, at least in my case. In terms of tegra SoC, we have tegra code bits in src tree, however it seems not complete. On the other hand, definitely we should try to bring FreeBSD on newer ARM boards, and it seems this board is fast, which could bring us some nice possibilities like port/package buildings. There may be exist some possibilities to build ports using qemu or some other sort of emulation technics, however that doesn't mean we should stop bringing new SoC/board supports. Last but not least, we lack developers working on ARM platforms. But all above is just my opinion, so correct me if I'm wrong here. regards, Ganbold > > Best regards > -- > Johannes Lundberg > > -- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > $BHkL)J];}$K$D$$$F!'$3$NEE;R%a!<%k$O!"L>08?M$KAw?.$7$?$b$N$G$"$j!"HkF?FC8"$NBP>]$H$J$k>pJs$r4^$s$G$$$^$9!#(B > $B$b$7!"L>08?M0J30$NJ}$,l9g!"$3$N%a!<%k$NGK4~!"$*$h$S$3$N%a!<%k$K4X$9$k0l@Z$N3+<(!"(B > $BJ#$NMxMQ!"$^$?$O5-:\FbMF$K4p$E$/$$$+$J$k9TF0$b$5$l$J$$$h$&$*4j$$?=$7>e$2$^$9!#(B > --- > CONFIDENTIALITY NOTE: The information in this email is confidential > and intended solely for the addressee. > Disclosure, copying, distribution or any other action of use of this > email by person other than intended recipient, is prohibited. > If you are not the intended recipient and have received this email in > error, please destroy the original message. > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-embedded@FreeBSD.ORG Fri Mar 28 01:30:32 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7EE46FBB; Fri, 28 Mar 2014 01:30:32 +0000 (UTC) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2E562326; Fri, 28 Mar 2014 01:30:32 +0000 (UTC) Received: by mail-qg0-f41.google.com with SMTP id e89so172578qgf.0 for ; Thu, 27 Mar 2014 18:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zxfXir/SZygnra9HDOu0GSJqyohKyMA2GAd8+5/45UI=; b=Q0herf7XxOZQoW29Uso/kC4MGrJzG65g55m5ACxuhD5/ZA5JkFG2M0d5B9y7tE7vdE U7q7c0J5WqfQ/k4RFmW6oPjpXyeJK6CYz/thl1uIEmyo+UihR0sOgm9GOvnQCIq2hI0L 3u2YzCzaSRXzIDrpEk5b/L7O/W9geLtiAFUCy39InYFAj+2AgMDK7vODv3vqqqTmTyZg g7XtrnErkL9+8c/7Ott8MHdbK3gAnZ8OwQem+3gtRl0AhiXGmfTRAlARgI+t0zwueEPE rARyIDMCX2Pzczi2TOWgU45y7M3nXDRfOdcXV7TnUE1U98fkEYvndRWonQjyBx0xS8mk zLJg== MIME-Version: 1.0 X-Received: by 10.224.74.201 with SMTP id v9mr93137qaj.94.1395970230260; Thu, 27 Mar 2014 18:30:30 -0700 (PDT) Received: by 10.224.50.143 with HTTP; Thu, 27 Mar 2014 18:30:30 -0700 (PDT) In-Reply-To: References: Date: Thu, 27 Mar 2014 18:30:30 -0700 Message-ID: Subject: Re: Jetson TK1 from nVidia ships in April, pre-order started From: Adrian Chadd To: "Lundberg, Johannes" Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" , "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 01:30:32 -0000 I think the best way to get this going is to get a freebsd ARM developer on contract to just knock this stuff out and commit it to FreeBSD-HEAD. -a On 26 March 2014 19:48, Lundberg, Johannes wrote: > Hi > > Just noticed that K1 development board from nVidia has been publicly > announced. > > https://developer.nvidia.com/jetson-tk1 > > It would enable some really cool applications if we could achieve two things > > 1) Get FreeBSD running on TK1 including HDMI graphical output support > 2) Get nVidia to add native CUDA support for FreeBSD > > Think we can make this happen? > > Best regards > -- > Johannes Lundberg > > -- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > $BHkL)J];}$K$D$$$F!'$3$NEE;R%a!<%k$O!"L>08?M$KAw?.$7$?$b$N$G$"$j!"HkF?FC8"$NBP>]$H$J$k>pJs$r4^$s$G$$$^$9!#(B > $B$b$7!"L>08?M0J30$NJ}$,l9g!"$3$N%a!<%k$NGK4~!"$*$h$S$3$N%a!<%k$K4X$9$k0l@Z$N3+<(!"(B > $BJ#$NMxMQ!"$^$?$O5-:\FbMF$K4p$E$/$$$+$J$k9TF0$b$5$l$J$$$h$&$*4j$$?=$7>e$2$^$9!#(B > --- > CONFIDENTIALITY NOTE: The information in this email is confidential > and intended solely for the addressee. > Disclosure, copying, distribution or any other action of use of this > email by person other than intended recipient, is prohibited. > If you are not the intended recipient and have received this email in > error, please destroy the original message. > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-embedded@FreeBSD.ORG Fri Mar 28 12:07:43 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ED5E058A; Fri, 28 Mar 2014 12:07:42 +0000 (UTC) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 903CF2A6; Fri, 28 Mar 2014 12:07:42 +0000 (UTC) Received: by mail-ob0-f171.google.com with SMTP id wn1so5874504obc.30 for ; Fri, 28 Mar 2014 05:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ydhA8mVjtwKMwA5VCqJrFCzR82AXPTcaBE3OyG0A/E8=; b=UwESrqmznh0jR3rE1HDRqEDGmvvCph0Uch6JhT47pozoq3QO9OGSP8g7D0h/Eg9b1x K9SOtgxbE29YVu69yg7quOIz/VmqA++JjF5nvv77ZSQiCZx+TIDl4Liw93Mtd0VgMI/B xPsF8Bk8XqOybTb2OfTQjaoCFCSljfevSjjfUEOaWUD73XMuwviMTQJVMVBPEigCgsHg zP5/tWcYgOQT5QbpcY+ybhAQx7KzeFbFpxAftHPKAOPbA2goxx43cOihjmzpqc3aR0eq 0PSMQpIhrqeWm3l+385KsRLJivv9910Pu73iR7TIuU5C4UhAu7QFCAtSrjrAs3eekW6t 77YQ== MIME-Version: 1.0 X-Received: by 10.60.44.42 with SMTP id b10mr12934oem.70.1396008461868; Fri, 28 Mar 2014 05:07:41 -0700 (PDT) Received: by 10.60.227.194 with HTTP; Fri, 28 Mar 2014 05:07:41 -0700 (PDT) In-Reply-To: <28B91494-CCBB-4050-8E01-7B2BF0C4ABC9@freebsd.org> References: <20140326224443.GN60889@funkthat.com> <28B91494-CCBB-4050-8E01-7B2BF0C4ABC9@freebsd.org> Date: Fri, 28 Mar 2014 09:07:41 -0300 Message-ID: Subject: Re: Cross-compiling a kernel module? From: Martin Galvan To: Stanislav Sedov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-arm@freebsd.org, freebsd-embedded@freebsd.org, freebsd-drivers@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 12:07:43 -0000 Works like a charm. Thanks a lot guys! 2014-03-27 1:52 GMT-03:00 Stanislav Sedov : > > On Mar 26, 2014, at 3:44 PM, John-Mark Gurney wrote: > > > $ cd $SRC > > $ make kernel-toolchain TARGET_ARCH=armXX > > $ make buildenv TARGET_ARCH=armXX BUILDENV_SHELL=/usr/local/bin/shell > > $ cd > > $ make > > > > The buildenv command sets up the new shell with an environment that is > > the same as if you were running under a buildkernel or buildworld > > environment.. You can use this to build one off programs like bin/ls > > too. > > Don't forget to set the KERNBUILDDIR option as well to point to your > kernel object dir so the module will pick up all the right options. > > -- > ST4096-RIPE > > > > From owner-freebsd-embedded@FreeBSD.ORG Mon Mar 31 11:06:42 2014 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D71091D for ; Mon, 31 Mar 2014 11:06:42 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3A6C9B90 for ; Mon, 31 Mar 2014 11:06:42 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s2VB6gbi058644 for ; Mon, 31 Mar 2014 11:06:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s2VB6fE6058642 for freebsd-embedded@FreeBSD.org; Mon, 31 Mar 2014 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 31 Mar 2014 11:06:41 GMT Message-Id: <201403311106.s2VB6fE6058642@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-embedded@FreeBSD.org Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 11:06:42 -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 misc/52256 embedded [picobsd] picobsd build script does not read in user/s o kern/42728 embedded [picobsd] many problems in src/usr.sbin/ppp/* after c 2 problems total. From owner-freebsd-embedded@FreeBSD.ORG Tue Apr 1 17:31:16 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2AE18770 for ; Tue, 1 Apr 2014 17:31:16 +0000 (UTC) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DDEB2291 for ; Tue, 1 Apr 2014 17:31:14 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id ks9so10435441vcb.27 for ; Tue, 01 Apr 2014 10:31:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=iRVElz17ZBbtgXh6uWBB/irAbBHXKIFcmQFBLMyvj3M=; b=VUpHkHctTTih4MWZo3v9Q05c4lAuLi6kENn1PH5TTt3rSQhslFCuW/DHbMw9WmNz9E xoaAIU23WhnZeIoYwNu7jXcRNY9v5DM+AtyhfU7g11VXq+2OIzu8RPh2GdFXdTaFtd1q dwWUraVb66Y7hdnNMYpass8q0IVIhwWbv9ibJa8Ea30Arv+VGK6ypNSLr7h0KXWBg/9Q X+WLQg7Gf8rCWE658oBO6PkaMwHGG3D3Nh1vPCgR3INiC420WDtFZixoNSlvk5TfpfKO sqGy2evqvylnZSU+GN95iPHKrxA3r2Hm/Ks4SqlAEiVDJcRxqOd84qKt/ssTuR+HQ0D4 oWhA== X-Gm-Message-State: ALoCoQnztecDztBx9sDxyXWS0VDnMSRlgo2O3A/LEsGoVKB9GekC806yjtit+4HcjLTgaISl7BNV MIME-Version: 1.0 X-Received: by 10.52.6.162 with SMTP id c2mr24711843vda.6.1396373467366; Tue, 01 Apr 2014 10:31:07 -0700 (PDT) Received: by 10.220.39.133 with HTTP; Tue, 1 Apr 2014 10:31:07 -0700 (PDT) Date: Tue, 1 Apr 2014 14:31:07 -0300 Message-ID: Subject: Support Modem 3g From: Guilherme Ferreira Rosario To: freebsd-arm@freebsd.org, freebsd-embedded@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 17:31:16 -0000 first sorry for bad english, Please 3g modem model which has comptabilidade with the FreeBSD version 10 or 11 arm architecture. thank you graciously From owner-freebsd-embedded@FreeBSD.ORG Tue Apr 1 18:12:11 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E8B958B4; Tue, 1 Apr 2014 18:12:11 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A71CB8FA; Tue, 1 Apr 2014 18:12:11 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 58D861FE027; Tue, 1 Apr 2014 20:12:08 +0200 (CEST) Message-ID: <533B01A7.6040800@selasky.org> Date: Tue, 01 Apr 2014 20:12:55 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Guilherme Ferreira Rosario , freebsd-arm@freebsd.org, freebsd-embedded@freebsd.org Subject: Re: Support Modem 3g References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 18:12:12 -0000 On 04/01/14 19:31, Guilherme Ferreira Rosario wrote: > first sorry for bad english, > > Please 3g modem model which has comptabilidade with the FreeBSD version 10 > or 11 arm architecture. > > thank you > > graciously Hi, The PFSense project has some 3G modem compatibility lists. https://doc.pfsense.org/index.php/Known_Working_3G-4G_Modems --HPS From owner-freebsd-embedded@FreeBSD.ORG Wed Apr 2 02:53:58 2014 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 496E9676; Wed, 2 Apr 2014 02:53:58 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 08BC1C02; Wed, 2 Apr 2014 02:53:57 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WVBJM-000NME-63; Wed, 02 Apr 2014 02:53:56 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s322rsVS085217; Tue, 1 Apr 2014 20:53:54 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18jFnRFxPr+wXkgzpuFi7bY Subject: uftdi driver - new ioctls to support FTDI bitbang and other modes From: Ian Lepore To: freebsd-usb@FreeBSD.org, freebsd-embedded@FreeBSD.org Content-Type: multipart/mixed; boundary="=-aAnWI9pkvoHeukRLaZxf" Date: Tue, 01 Apr 2014 20:53:53 -0600 Message-ID: <1396407233.81853.229.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 02:53:58 -0000 --=-aAnWI9pkvoHeukRLaZxf Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The attached patch, which I hope to commit sometime soon, adds support for bitbang, MPSSE, CPU_FIFO, and other modes supported by the FTDI serial adapter chips, using ioctl() calls. This allows full control of all the FTDI features that embedded folks like, using any language that supports fd-based IO. You can, for example, program an fpga in MPSSE mode just by configuring the mode with a couple ioctl() calls, then writing the bitfile image to the fd as if it were going out a serial port. You can also do jtag work this way. In addition to adding the new ioctls, this change removes all the code that reset the chip at attach and open/close time, and also the code that turned on RTS/CTS flow control on open without any permission to do so (that was just always a bug in the driver). When FTDI chips are configured as GPIO or MPSSE or other special-purpose uses by an attached serial eeprom, the chip will power on with certain pins driven or floating, and it's important that the driver not do anything to the chip to perturb that unless it receives a specific command to do so. When used for "plain old serial comms" the chip powers on into the right mode and never needs to be reset while it's running to operate properly, so this change is transparent to most users. -- Ian --=-aAnWI9pkvoHeukRLaZxf Content-Disposition: inline; filename="uftdi_ioctl.diff" Content-Type: text/x-patch; name="uftdi_ioctl.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: sys/dev/usb/serial/uftdi_reg.h =================================================================== --- sys/dev/usb/serial/uftdi_reg.h (revision 264013) +++ sys/dev/usb/serial/uftdi_reg.h (working copy) @@ -28,6 +28,10 @@ * reg */ #define FTDI_SIO_SET_EVENT_CHAR 6 /* Set the event character */ #define FTDI_SIO_SET_ERROR_CHAR 7 /* Set the error character */ +#define FTDI_SIO_SET_LATENCY 9 /* Set the latency timer */ +#define FTDI_SIO_GET_LATENCY 10 /* Read the latency timer */ +#define FTDI_SIO_SET_BITMODE 11 /* Set the bit bang I/O mode */ +#define FTDI_SIO_GET_BITMODE 12 /* Read pin states in bit bang mode */ /* Port Identifier Table */ #define FTDI_PIT_DEFAULT 0 /* SIOA */ Index: sys/dev/usb/serial/uftdi.c =================================================================== --- sys/dev/usb/serial/uftdi.c (revision 264031) +++ sys/dev/usb/serial/uftdi.c (working copy) @@ -38,7 +38,14 @@ __FBSDID("$FreeBSD$"); */ /* - * FTDI FT2232x, FT8U100AX and FT8U232AM serial adapter driver + * FTDI FT232x, FT2232x, FT4232x, FT8U100AX and FT8U232xM serial adapters. + * + * Note that we specifically do not do a reset or otherwise alter the state of + * the chip during attach, detach, open, and close, because it could be + * pre-initialized (via an attached serial eeprom) to power-on into a mode such + * as bitbang in which the pins are being driven to a specific state which we + * must not perturb. The device gets reset at power-on, and doesn't need to be + * reset again after that to function, except as directed by ioctl() calls. */ #include @@ -64,6 +71,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include "usbdevs.h" #define USB_DEBUG_VAR uftdi_debug @@ -72,6 +80,7 @@ __FBSDID("$FreeBSD$"); #include #include +#include #ifdef USB_DEBUG static int uftdi_debug = 0; @@ -175,6 +184,7 @@ static usb_callback_t uftdi_read_callback; static void uftdi_free(struct ucom_softc *); static void uftdi_cfg_open(struct ucom_softc *); +static void uftdi_cfg_close(struct ucom_softc *); static void uftdi_cfg_set_dtr(struct ucom_softc *, uint8_t); static void uftdi_cfg_set_rts(struct ucom_softc *, uint8_t); static void uftdi_cfg_set_break(struct ucom_softc *, uint8_t); @@ -184,6 +194,15 @@ static int uftdi_pre_param(struct ucom_softc *, st static void uftdi_cfg_param(struct ucom_softc *, struct termios *); static void uftdi_cfg_get_status(struct ucom_softc *, uint8_t *, uint8_t *); +static int uftdi_reset(struct ucom_softc *, int); +static int uftdi_set_bitmode(struct ucom_softc *, uint8_t, uint8_t); +static int uftdi_get_bitmode(struct ucom_softc *, uint8_t *); +static int uftdi_set_latency(struct ucom_softc *, int); +static int uftdi_get_latency(struct ucom_softc *, int *); +static int uftdi_set_event_char(struct ucom_softc *, int); +static int uftdi_set_error_char(struct ucom_softc *, int); +static int uftdi_ioctl(struct ucom_softc *, uint32_t, caddr_t, int, + struct thread *); static void uftdi_start_read(struct ucom_softc *); static void uftdi_stop_read(struct ucom_softc *); static void uftdi_start_write(struct ucom_softc *); @@ -218,7 +237,9 @@ static const struct ucom_callback uftdi_callback = .ucom_cfg_set_break = &uftdi_cfg_set_break, .ucom_cfg_param = &uftdi_cfg_param, .ucom_cfg_open = &uftdi_cfg_open, + .ucom_cfg_close = &uftdi_cfg_close, .ucom_pre_param = &uftdi_pre_param, + .ucom_ioctl = &uftdi_ioctl, .ucom_start_read = &uftdi_start_read, .ucom_stop_read = &uftdi_stop_read, .ucom_start_write = &uftdi_start_write, @@ -1085,37 +1106,25 @@ uftdi_free(struct ucom_softc *ucom) static void uftdi_cfg_open(struct ucom_softc *ucom) { - struct uftdi_softc *sc = ucom->sc_parent; - uint16_t wIndex = ucom->sc_portno; - struct usb_device_request req; + /* + * This do-nothing open routine exists for the sole purpose of this + * DPRINTF() so that you can see the point at which open gets called + * when debugging is enabled. + */ DPRINTF(""); +} - /* perform a full reset on the device */ +static void +uftdi_cfg_close(struct ucom_softc *ucom) +{ - req.bmRequestType = UT_WRITE_VENDOR_DEVICE; - req.bRequest = FTDI_SIO_RESET; - USETW(req.wValue, FTDI_SIO_RESET_SIO); - USETW(req.wIndex, wIndex); - USETW(req.wLength, 0); - ucom_cfg_do_request(sc->sc_udev, &sc->sc_ucom, - &req, NULL, 0, 1000); - - /* turn on RTS/CTS flow control */ - - req.bmRequestType = UT_WRITE_VENDOR_DEVICE; - req.bRequest = FTDI_SIO_SET_FLOW_CTRL; - USETW(req.wValue, 0); - USETW2(req.wIndex, FTDI_SIO_RTS_CTS_HS, wIndex); - USETW(req.wLength, 0); - ucom_cfg_do_request(sc->sc_udev, &sc->sc_ucom, - &req, NULL, 0, 1000); - /* - * NOTE: with the new UCOM layer there will always be a - * "uftdi_cfg_param()" call after "open()", so there is no need for - * "open()" to configure anything + * This do-nothing close routine exists for the sole purpose of this + * DPRINTF() so that you can see the point at which close gets called + * when debugging is enabled. */ + DPRINTF(""); } static void @@ -1582,6 +1591,182 @@ uftdi_cfg_get_status(struct ucom_softc *ucom, uint *lsr = sc->sc_lsr; } +static int +uftdi_reset(struct ucom_softc *ucom, int reset_type) +{ + struct uftdi_softc *sc = ucom->sc_parent; + usb_device_request_t req; + + req.bmRequestType = UT_WRITE_VENDOR_DEVICE; + req.bRequest = FTDI_SIO_RESET; + + USETW(req.wIndex, sc->sc_ucom.sc_portno); + USETW(req.wLength, 0); + USETW(req.wValue, reset_type); + + return (usbd_do_request(sc->sc_udev, &sc->sc_mtx, &req, NULL)); +} + +static int +uftdi_set_bitmode(struct ucom_softc *ucom, uint8_t bitmode, uint8_t iomask) +{ + struct uftdi_softc *sc = ucom->sc_parent; + usb_device_request_t req; + + req.bmRequestType = UT_WRITE_VENDOR_DEVICE; + req.bRequest = FTDI_SIO_SET_BITMODE; + + USETW(req.wIndex, sc->sc_ucom.sc_portno); + USETW(req.wLength, 0); + + if (bitmode == UFTDI_BITMODE_NONE) + USETW2(req.wValue, 0, 0); + else + USETW2(req.wValue, (1 << bitmode), iomask); + + return (usbd_do_request(sc->sc_udev, &sc->sc_mtx, &req, NULL)); +} + +static int +uftdi_get_bitmode(struct ucom_softc *ucom, uint8_t *iomask) +{ + struct uftdi_softc *sc = ucom->sc_parent; + usb_device_request_t req; + + req.bmRequestType = UT_WRITE_VENDOR_DEVICE; + req.bRequest = FTDI_SIO_GET_BITMODE; + + USETW(req.wIndex, sc->sc_ucom.sc_portno); + USETW(req.wLength, 1); + USETW(req.wValue, 0); + + return (usbd_do_request(sc->sc_udev, &sc->sc_mtx, &req, iomask)); +} + +static int +uftdi_set_latency(struct ucom_softc *ucom, int latency) +{ + struct uftdi_softc *sc = ucom->sc_parent; + usb_device_request_t req; + + if (latency < 0 || latency > 255) + return (USB_ERR_INVAL); + + req.bmRequestType = UT_WRITE_VENDOR_DEVICE; + req.bRequest = FTDI_SIO_SET_LATENCY; + + USETW(req.wIndex, sc->sc_ucom.sc_portno); + USETW(req.wLength, 0); + USETW2(req.wValue, 0, latency); + + return (usbd_do_request(sc->sc_udev, &sc->sc_mtx, &req, NULL)); +} + +static int +uftdi_get_latency(struct ucom_softc *ucom, int *latency) +{ + struct uftdi_softc *sc = ucom->sc_parent; + usb_device_request_t req; + usb_error_t err; + uint8_t buf; + + req.bmRequestType = UT_WRITE_VENDOR_DEVICE; + req.bRequest = FTDI_SIO_GET_LATENCY; + + USETW(req.wIndex, sc->sc_ucom.sc_portno); + USETW(req.wLength, 1); + USETW(req.wValue, 0); + + err = usbd_do_request(sc->sc_udev, &sc->sc_mtx, &req, &buf); + *latency = buf; + + return (err); +} + +static int +uftdi_set_event_char(struct ucom_softc *ucom, int echar) +{ + struct uftdi_softc *sc = ucom->sc_parent; + usb_device_request_t req; + uint8_t enable; + + enable = (echar == -1) ? 0 : 1; + + req.bmRequestType = UT_WRITE_VENDOR_DEVICE; + req.bRequest = FTDI_SIO_SET_EVENT_CHAR; + + USETW(req.wIndex, sc->sc_ucom.sc_portno); + USETW(req.wLength, 0); + USETW2(req.wValue, enable, echar & 0xff); + + return (usbd_do_request(sc->sc_udev, &sc->sc_mtx, &req, NULL)); +} + +static int +uftdi_set_error_char(struct ucom_softc *ucom, int echar) +{ + struct uftdi_softc *sc = ucom->sc_parent; + usb_device_request_t req; + uint8_t enable; + + enable = (echar == -1) ? 0 : 1; + + req.bmRequestType = UT_WRITE_VENDOR_DEVICE; + req.bRequest = FTDI_SIO_SET_ERROR_CHAR; + + USETW(req.wIndex, sc->sc_ucom.sc_portno); + USETW(req.wLength, 0); + USETW2(req.wValue, enable, echar & 0xff); + + return (usbd_do_request(sc->sc_udev, &sc->sc_mtx, &req, NULL)); +} + +static int +uftdi_ioctl(struct ucom_softc *ucom, uint32_t cmd, caddr_t data, + int flag, struct thread *td) +{ + int err; + struct uftdi_bitmode * mode; + + DPRINTF("portno: %d cmd: %#x\n", ucom->sc_portno, cmd); + + switch (cmd) { + case UFTDIIOC_RESET_IO: + case UFTDIIOC_RESET_RX: + case UFTDIIOC_RESET_TX: + err = uftdi_reset(ucom, + cmd == UFTDIIOC_RESET_IO ? FTDI_SIO_RESET_SIO : + (cmd == UFTDIIOC_RESET_RX ? FTDI_SIO_RESET_PURGE_RX : + FTDI_SIO_RESET_PURGE_TX)); + break; + case UFTDIIOC_SET_BITMODE: + mode = (struct uftdi_bitmode *)data; + err = uftdi_set_bitmode(ucom, mode->mode, mode->iomask); + break; + case UFTDIIOC_GET_BITMODE: + mode = (struct uftdi_bitmode *)data; + err = uftdi_get_bitmode(ucom, &mode->iomask); + break; + case UFTDIIOC_SET_LATENCY: + err = uftdi_set_latency(ucom, *((int *)data)); + break; + case UFTDIIOC_GET_LATENCY: + err = uftdi_get_latency(ucom, (int *)data); + break; + case UFTDIIOC_SET_ERROR_CHAR: + err = uftdi_set_event_char(ucom, *(int *)data); + break; + case UFTDIIOC_SET_EVENT_CHAR: + err = uftdi_set_error_char(ucom, *(int *)data); + break; + default: + return (ENOIOCTL); + } + if (err != USB_ERR_NORMAL_COMPLETION) + return (EIO); + return (0); +} + static void uftdi_start_read(struct ucom_softc *ucom) { Index: sys/dev/usb/uftdiio.h =================================================================== --- sys/dev/usb/uftdiio.h (revision 0) +++ sys/dev/usb/uftdiio.h (working copy) @@ -0,0 +1,74 @@ +/*- + * Copyright 2008-2012 - Symmetricom, Inc. + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions, and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR + * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +/* + * FTDI USB serial converter chip ioctl commands. + */ + +#ifndef _USB_UFTDIIO_H_ +#define _USB_UFTDIIO_H_ + +#include + +enum uftdi_bitmodes +{ + UFTDI_BITMODE_ASYNC = 0, + UFTDI_BITMODE_MPSSE = 1, + UFTDI_BITMODE_SYNC = 2, + UFTDI_BITMODE_CPU_EMUL = 3, + UFTDI_BITMODE_FAST_SERIAL = 4, + UFTDI_BITMODE_CBUS = 5, + UFTDI_BITMODE_NONE = 0xff, +}; + +/* + * For UFTDIIOC_SET_BITMODE: + * mode = One of the uftdi_bitmodes enum values. + * iomask = Mask of bits enabled for bitbang output. + * + * For UFTDIIOC_GET_BITMODE: + * mode = Unused. + * iomask = Returned snapshot of bitbang pin states at time of call. + */ +struct uftdi_bitmode +{ + uint8_t mode; + uint8_t iomask; +}; + +#define UFTDIIOC_RESET_IO _IO('c', 0) /* Reset config, flush fifos.*/ +#define UFTDIIOC_RESET_RX _IO('c', 1) /* Flush input fifo. */ +#define UFTDIIOC_RESET_TX _IO('c', 2) /* Flush output fifo. */ +#define UFTDIIOC_SET_BITMODE _IOW('c', 3, struct uftdi_bitmode) +#define UFTDIIOC_GET_BITMODE _IOR('c', 4, struct uftdi_bitmode) +#define UFTDIIOC_SET_ERROR_CHAR _IOW('c', 5, int) /* -1 to disable */ +#define UFTDIIOC_SET_EVENT_CHAR _IOW('c', 6, int) /* -1 to disable */ +#define UFTDIIOC_SET_LATENCY _IOW('c', 7, int) /* 1-255 ms */ +#define UFTDIIOC_GET_LATENCY _IOR('c', 8, int) + +#endif Property changes on: sys/dev/usb/uftdiio.h ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +text/plain Added: svn:keywords ## -0,0 +1 ## +FreeBSD=%H Added: svn:eol-style ## -0,0 +1 ## +native --=-aAnWI9pkvoHeukRLaZxf-- From owner-freebsd-embedded@FreeBSD.ORG Sun Apr 6 22:38:26 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AA3CFB9E; Sun, 6 Apr 2014 22:38:26 +0000 (UTC) Received: from mail1.uj.edu.pl (mail1.uj.edu.pl [149.156.89.193]) by mx1.freebsd.org (Postfix) with ESMTP id 663983ED; Sun, 6 Apr 2014 22:38:25 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from mbox.uj.edu.pl ([149.156.89.248]) by mta.uoks.uj.edu.pl (Oracle Communications Messaging Server 7u4-27.01 (7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTP id <0N3M00E0O57INT50@mta.uoks.uj.edu.pl>; Sun, 06 Apr 2014 16:21:18 +0200 (CEST) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.2 X-Antivirus-Code: 0x100000 Received: from mbox.uj.edu.pl by saiph.uoks.uj.edu.pl (Dr.Web (R) milter module ver.6.0.2.2) ; Sun, 06 Apr 2014 16:21:18 +0200 Received: from mbox.uj.edu.pl ([149.156.89.248]) by mta.uoks.uj.edu.pl with ESMTP; Sun, 06 Apr 2014 16:21:18 +0200 (CEST) Date: Sun, 06 Apr 2014 16:21:18 +0200 From: Jakub Klama Message-id: <3e7f866f4bc774975ae3c85e0df78ec2@uj.edu.pl> Subject: [RFC] Refactored interrupt handling on ARM To: freebsd-arm@freebsd.org, freebsd-embedded@freebsd.org User-Agent: Roundcube Webmail/0.5 X-Sender: jakub.klama@uj.edu.pl Cc: wkoszek@freebsd.org, cognet@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Apr 2014 22:38:26 -0000 Hello all, It has been a long time since my SoC 2012 ended. However, I've finally merged refactored interrupt handling framework to head and added SMP support (IPIs). Let's start: What is this and how does it work? It's a refactored interrupt handling code for ARM which supports multiple, stacked interrupt controllers. In particular, it creates a clean way to support IRQ multiplexers such as GPIO controllers with interrupt generation functionality. Approach used in this code is somewhat similar to one used in powerpc port. Every interrupt controller should implement methods from pic_if.m interface - at least pic_config, pic_unmask, pic_mask and pic_eoi. It should also install IRQ handler on parent interrupt controller (specified by interrupt-parent in FDT, defaulting to nexus). The root interrupt controller is nexus - on ARM it has exactly one IRQ line (typically nexus0:0) representing core IRQ signal (on MIPS, there will be probably five of them). SoC interrupt controller, such as GIC then installs handler on nexus0:0 IRQ and exposes itself as interrupt controller by calling arm_register_pic(). When the interrupt arrives, pic driver calls arm_dispatch_irq() function. So, for example, a typical SoC interrupt tree can look like that: nexus0 (provides 1 irq) | \-- gic0 (provides 160 irqs, uses irq nexus0:0) | \-- gpio0 (provides 8 irqs, uses irq gic0:42) | | | \-- mmcsd0 (uses irqs gpio0:1, gpio0:2) | \-- spi0 (uses irq gpio0:3) | ... \-- gpio1 (provides 8 irqs, uses irq gic0:43) \-- ehci0 (uses irq gic0:109) ... Interrupt numbers used in rman are composed of two 8-bit fields: higher 8 bits are the pic index and lower 8 bits are IRQ line number inside particular pic (so there are 256 pics supported with maximum of 256 irq lines on each). These numbers are generated using FDT_MAP_IRQ() macro called from FDT code. As you can see from the provided dmesg logs, irq numbers are printed in form of "pic_name:line_number", i.e: "nexus0:0" or "gic0:109". Of course there's still support for shared interrupt handlers - on LPC3250 there are 3 pics attached to one in-core IRQ line. There's also support for IPIs. Calls to pic_ipi_get(), pic_ipi_clear(), pic_ipi_send() and ..._init_secondary() are redirected to one interrupt controller registered as capable to do IPIs. There can be only one interrupt controller with IPI support registered (and certainly not the root one). Code was tested on following platforms: * EA3250 (arm/lpc) * Pandaboard (arm/ti) (both with SMP enabled and disabled) Merging it would not require any changes in existing ARM ports (unless they will be adopted to new framework and will have ARM_INTRNG option enabled), except for adding arm/arm/intr.c to their file lists (as it's now not compiled-in by default). That was tested too. dmesg outputs can be found there: * http://people.freebsd.org/~jceel/intrng/pandaboard.dmesg.txt * http://people.freebsd.org/~jceel/intrng/ea3250.dmesg.txt diff against head as of r264192: * http://people.freebsd.org/~jceel/intrng/intrng.diff git branch containing the changes: * https://github.com/jceel/freebsd-arm-intrng/tree/intrng What do you think about that? That code probably needs some improvements, especially in IPI/SMP area, but I think it's a step further in interrupt handling on ARM. I really appreciate any comments and opinions. Regards, Jakub From owner-freebsd-embedded@FreeBSD.ORG Mon Apr 7 11:06:41 2014 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE2219D9 for ; Mon, 7 Apr 2014 11:06:41 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BA7B3BE7 for ; Mon, 7 Apr 2014 11:06:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s37B6fOL071003 for ; Mon, 7 Apr 2014 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s37B6ffY071001 for freebsd-embedded@FreeBSD.org; Mon, 7 Apr 2014 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 7 Apr 2014 11:06:41 GMT Message-Id: <201404071106.s37B6ffY071001@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-embedded@FreeBSD.org Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 11:06:41 -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 misc/52256 embedded [picobsd] picobsd build script does not read in user/s o kern/42728 embedded [picobsd] many problems in src/usr.sbin/ppp/* after c 2 problems total. From owner-freebsd-embedded@FreeBSD.ORG Mon Apr 14 11:06:43 2014 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07D75E6F for ; Mon, 14 Apr 2014 11:06:43 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E92891651 for ; Mon, 14 Apr 2014 11:06:42 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3EB6gm8025821 for ; Mon, 14 Apr 2014 11:06:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3EB6gge025819 for freebsd-embedded@FreeBSD.org; Mon, 14 Apr 2014 11:06:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 14 Apr 2014 11:06:42 GMT Message-Id: <201404141106.s3EB6gge025819@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-embedded@FreeBSD.org Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 11:06:43 -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 misc/52256 embedded [picobsd] picobsd build script does not read in user/s o kern/42728 embedded [picobsd] many problems in src/usr.sbin/ppp/* after c 2 problems total. From owner-freebsd-embedded@FreeBSD.ORG Mon Apr 21 11:06:44 2014 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CAC87F30 for ; Mon, 21 Apr 2014 11:06:44 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B72841953 for ; Mon, 21 Apr 2014 11:06:44 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3LB6iSp085666 for ; Mon, 21 Apr 2014 11:06:44 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3LB6irl085664 for freebsd-embedded@FreeBSD.org; Mon, 21 Apr 2014 11:06:44 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 21 Apr 2014 11:06:44 GMT Message-Id: <201404211106.s3LB6irl085664@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-embedded@FreeBSD.org Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 11:06:44 -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 misc/52256 embedded [picobsd] picobsd build script does not read in user/s o kern/42728 embedded [picobsd] many problems in src/usr.sbin/ppp/* after c 2 problems total. From owner-freebsd-embedded@FreeBSD.ORG Wed Apr 23 14:16:10 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3CD209BE; Wed, 23 Apr 2014 14:16:10 +0000 (UTC) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 996FD1B81; Wed, 23 Apr 2014 14:16:09 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id x48so923060wes.35 for ; Wed, 23 Apr 2014 07:16:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=H3vgpG4Y/kL2NTtOMeEBJkasgZ6mrLoJpoCBzcUA40Q=; b=BwMhlnTvHsBbhPwpb/9OajxgA+gq8f8QUpb26zu5Z2vqOrz6F1XncoZx3hknBQ27Rc SHmJO0iDcXukUNIcwv9xHvxB+OeCGv3B6uXNmIsARGN2skklv9V2Ol8lbudHlJcLY1zj AerFPbQNeiXoLV8XNtLzuKGSFL9y/W3AuKCGY+XB+ndknYRmMX6gP6EA40W9qR2vQL3e UP0rNgcZwkDyKdfwq1RUPrpi2t5U+PH4WyBY6E8AOIzURZMMA/QDO2yFaRN0KmssOlVd 6NJIH0XUUdFEYb45fsBGvlh4d6BN6tJhFyaEYrZ3Ygfz5uBjku0+/eM4WhnPdxePAr3Y 6sPA== MIME-Version: 1.0 X-Received: by 10.180.24.72 with SMTP id s8mr2082927wif.20.1398262567895; Wed, 23 Apr 2014 07:16:07 -0700 (PDT) Received: by 10.216.168.194 with HTTP; Wed, 23 Apr 2014 07:16:07 -0700 (PDT) Date: Wed, 23 Apr 2014 11:16:07 -0300 Message-ID: Subject: Fix gpio specifiers decoding (respect #gpio-cells) From: Luiz Otavio O Souza To: "freebsd-embedded@freebsd.org" Content-Type: multipart/mixed; boundary=f46d0438933faa55ca04f7b65f6b Cc: Nathan Whitehorn X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 14:16:10 -0000 --f46d0438933faa55ca04f7b65f6b Content-Type: text/plain; charset=UTF-8 I've been working to reduce the changes we need to decode a linux DTS file (from the GPIO point of view). The attached patch now respects the GPIO controller #gpio-cells (which previously was only able to decode gpio specifiers if #gpio-cells = 3). This now make possible read linux like gpio specifiers (#gpio-cells = 2) without any change to code. Following linux, it also adds a new ofw_bus method that allows the GPIO controller to implement its own mapping to gpio specifier, allowing the specifier to be GPIO controller specific (rk30xx_gpio.c comes to my mind...). This patch also passes the gpio specifier flag as an ivar variable which is visible to child that can now act upon. Thoughts ? Luiz --f46d0438933faa55ca04f7b65f6b Content-Type: text/plain; charset=US-ASCII; name="gpio-cells.diff" Content-Disposition: attachment; filename="gpio-cells.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hucp8oo10 SW5kZXg6IHN5cy9kZXYvZ3Bpby9ncGlvYnVzdmFyLmgKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2Rldi9n cGlvL2dwaW9idXN2YXIuaAkocmV2aXNpb24gMjY0NTUwKQorKysgc3lzL2Rldi9ncGlvL2dwaW9i dXN2YXIuaAkod29ya2luZyBjb3B5KQpAQCAtNjAsMTAgKzYwLDEwIEBACiAJaW50CQkqc2NfcGlu c19tYXBwZWQ7IC8qIG1hcmsgbWFwcGVkIHBpbnMgKi8KIH07CiAKLQogc3RydWN0IGdwaW9idXNf aXZhcgogewogCXVpbnQzMl90CW5waW5zOwkvKiBwaW5zIHRvdGFsICovCisJdWludDMyX3QJKmZs YWdzOwkvKiBwaW5zIGZsYWdzICovCiAJdWludDMyX3QJKnBpbnM7CS8qIHBpbnMgbWFwICovCiB9 OwogCkluZGV4OiBzeXMvZGV2L2dwaW8vb2Z3X2dwaW9idXMuYwo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMv ZGV2L2dwaW8vb2Z3X2dwaW9idXMuYwkocmV2aXNpb24gMjY0NTUwKQorKysgc3lzL2Rldi9ncGlv L29md19ncGlvYnVzLmMJKHdvcmtpbmcgY29weSkKQEAgLTgzLDEwICs4MywzNyBAQAogfQogCiBz dGF0aWMgaW50CitvZndfZ3Bpb2J1c19hbGxvY19pdmFycyhzdHJ1Y3QgZ3Bpb2J1c19pdmFyICpk aW5mbykKK3sKKworCS8qIEFsbG9jYXRlIHBpbnMgYW5kIGZsYWdzIG1lbW9yeS4gKi8KKwlkaW5m by0+cGlucyA9IG1hbGxvYyhzaXplb2YodWludDMyX3QpICogZGluZm8tPm5waW5zLCBNX0RFVkJV RiwKKwkgICAgTV9OT1dBSVQgfCBNX1pFUk8pOworCWlmIChkaW5mby0+cGlucyA9PSBOVUxMKQor CQlyZXR1cm4gKEVOT01FTSk7CisJZGluZm8tPmZsYWdzID0gbWFsbG9jKHNpemVvZih1aW50MzJf dCkgKiBkaW5mby0+bnBpbnMsIE1fREVWQlVGLAorCSAgICBNX05PV0FJVCB8IE1fWkVSTyk7CisJ aWYgKGRpbmZvLT5mbGFncyA9PSBOVUxMKSB7CisJCWZyZWUoZGluZm8tPnBpbnMsIE1fREVWQlVG KTsKKwkJcmV0dXJuIChFTk9NRU0pOworCX0KKworCXJldHVybiAoMCk7Cit9CisKK3N0YXRpYyB2 b2lkCitvZndfZ3Bpb2J1c19mcmVlX2l2YXJzKHN0cnVjdCBncGlvYnVzX2l2YXIgKmRpbmZvKQor eworCisJZnJlZShkaW5mby0+ZmxhZ3MsIE1fREVWQlVGKTsKKwlmcmVlKGRpbmZvLT5waW5zLCBN X0RFVkJVRik7Cit9CisKK3N0YXRpYyBpbnQKIG9md19ncGlvYnVzX3BhcnNlX2dwaW9zKHN0cnVj dCBncGlvYnVzX3NvZnRjICpzYywgc3RydWN0IGdwaW9idXNfaXZhciAqZGluZm8sCiAJcGhhbmRs ZV90IGNoaWxkKQogewotCWludCBpLCBsZW47CisJaW50IGNlbGxzLCBpLCBqLCBsZW47CiAJcGNl bGxfdCAqZ3Bpb3M7CiAJcGhhbmRsZV90IGdwaW87CiAKQEAgLTEwMiw0NCArMTI5LDgxIEBACiAJ fQogCiAJLyoKLQkgKiBFYWNoICdncGlvcycgZW50cnkgbXVzdCBjb250YWluIDQgcGNlbGxzLgot CSAqIFRoZSBmaXJzdCBvbmUgaXMgdGhlIEdQSU8gY29udHJvbGxlciBwaGFuZGxlci4KLQkgKiBU aGVuIHRoZSBsYXN0IHRocmVlIGFyZSB0aGUgR1BJTyBwaW4sIHRoZSBHUElPIHBpbiBkaXJlY3Rp b24gYW5kCi0JICogdGhlIEdQSU8gcGluIGZsYWdzLgorCSAqIFRoZSBncGlvLXNwZWNpZmllciBp cyBjb250cm9sbGVyIGluZGVwZW5kZW50LCBidXQgdGhlIGZpcnN0IHBjZWxsCisJICogaGFzIHRo ZSByZWZlcmVuY2UgdG8gdGhlIEdQSU8gY29udHJvbGxlciBwaGFuZGxlci4KKwkgKiBPbmUgdGhl IGZpcnN0IHBhc3Mgd2UgY291bnQgdGhlIG51bWJlciBvZiBlbmNvZGVkIGdwaW8tc3BlY2lmaWVy cy4KIAkgKi8KLQlpZiAoKGxlbiAvIHNpemVvZihwY2VsbF90KSkgJSA0KSB7CisJaSA9IDA7CisJ bGVuIC89IHNpemVvZihwY2VsbF90KTsKKwl3aGlsZSAoaSA8IGxlbikgeworCQkvKiBBbGxvdyBO VUxMIHNwZWNpZmllcnMuICovCisJCWlmIChncGlvc1tpXSA9PSAwKSB7CisJCQlkaW5mby0+bnBp bnMrKzsKKwkJCWkrKzsKKwkJCWNvbnRpbnVlOworCQl9CisJCWdwaW8gPSBPRl94cmVmX3BoYW5k bGUoZ3Bpb3NbaV0pOworCQkvKiBWZXJpZnkgaWYgd2UncmUgYXR0YWNoaW5nIHRvIHRoZSBjb3Jy ZWN0IEdQSU8gY29udHJvbGxlci4gKi8KKwkJaWYgKCFPRl9oYXNwcm9wKGdwaW8sICJncGlvLWNv bnRyb2xsZXIiKSB8fAorCQkgICAgZ3BpbyAhPSBvZndfYnVzX2dldF9ub2RlKHNjLT5zY19kZXYp KSB7CisJCQlmcmVlKGdwaW9zLCBNX0RFVkJVRik7CisJCQlyZXR1cm4gKEVJTlZBTCk7CisJCX0K KwkJLyogUmVhZCBncGlvLWNlbGxzIHByb3BlcnR5IGZvciB0aGlzIEdQSU8gY29udHJvbGxlci4g Ki8KKwkJaWYgKE9GX2dldGVuY3Byb3AoZ3BpbywgIiNncGlvLWNlbGxzIiwgJmNlbGxzLAorCQkg ICAgc2l6ZW9mKGNlbGxzKSkgPCAwKSB7CisJCQlmcmVlKGdwaW9zLCBNX0RFVkJVRik7CisJCQly ZXR1cm4gKEVJTlZBTCk7CisJCX0KKwkJZGluZm8tPm5waW5zKys7CisJCWkgKz0gY2VsbHMgKyAx OworCX0KKworCWlmIChkaW5mby0+bnBpbnMgPT0gMCkgewogCQlmcmVlKGdwaW9zLCBNX0RFVkJV Rik7CiAJCXJldHVybiAoRUlOVkFMKTsKIAl9Ci0JZGluZm8tPm5waW5zID0gbGVuIC8gKHNpemVv ZihwY2VsbF90KSAqIDQpOwotCWRpbmZvLT5waW5zID0gbWFsbG9jKHNpemVvZih1aW50MzJfdCkg KiBkaW5mby0+bnBpbnMsIE1fREVWQlVGLAotCSAgICBNX05PV0FJVCB8IE1fWkVSTyk7Ci0JaWYg KGRpbmZvLT5waW5zID09IE5VTEwpIHsKKworCS8qIEFsbG9jYXRlIHRoZSBjaGlsZCByZXNvdXJj ZXMuICovCisJaWYgKG9md19ncGlvYnVzX2FsbG9jX2l2YXJzKGRpbmZvKSAhPSAwKSB7CiAJCWZy ZWUoZ3Bpb3MsIE1fREVWQlVGKTsKIAkJcmV0dXJuIChFTk9NRU0pOwogCX0KIAotCWZvciAoaSA9 IDA7IGkgPCBkaW5mby0+bnBpbnM7IGkrKykgeworCS8qIERlY29kZSB0aGUgZ3BpbyBzcGVjaWZp ZXIgb24gdGhlIHNlY29uZCBwYXNzLiAqLworCWkgPSAwOworCWogPSAwOworCXdoaWxlIChpIDwg bGVuKSB7CisJCS8qIEFsbG93IE5VTEwgc3BlY2lmaWVycy4gKi8KKwkJaWYgKGdwaW9zW2ldID09 IDApIHsKKwkJCWkrKzsKKwkJCWorKzsKKwkJCWNvbnRpbnVlOworCQl9CiAKLQkJLyogVmVyaWZ5 IGlmIHdlJ3JlIGF0dGFjaGluZyB0byB0aGUgY29ycmVjdCBncGlvIGNvbnRyb2xsZXIuICovCi0J CWdwaW8gPSBPRl94cmVmX3BoYW5kbGUoZ3Bpb3NbaSAqIDQgKyAwXSk7Ci0JCWlmICghT0ZfaGFz cHJvcChncGlvLCAiZ3Bpby1jb250cm9sbGVyIikgfHwKLQkJICAgIGdwaW8gIT0gb2Z3X2J1c19n ZXRfbm9kZShzYy0+c2NfZGV2KSkgewotCQkJZnJlZShkaW5mby0+cGlucywgTV9ERVZCVUYpOwor CQlncGlvID0gT0ZfeHJlZl9waGFuZGxlKGdwaW9zW2ldKTsKKwkJLyogUmVhZCBncGlvLWNlbGxz IHByb3BlcnR5IGZvciB0aGlzIEdQSU8gY29udHJvbGxlci4gKi8KKwkJaWYgKE9GX2dldGVuY3By b3AoZ3BpbywgIiNncGlvLWNlbGxzIiwgJmNlbGxzLAorCQkgICAgc2l6ZW9mKGNlbGxzKSkgPCAw KSB7CisJCQlvZndfZ3Bpb2J1c19mcmVlX2l2YXJzKGRpbmZvKTsKIAkJCWZyZWUoZ3Bpb3MsIE1f REVWQlVGKTsKIAkJCXJldHVybiAoRUlOVkFMKTsKIAkJfQogCi0JCS8qIEdldCB0aGUgR1BJTyBw aW4gbnVtYmVyLiAqLwotCQlkaW5mby0+cGluc1tpXSA9IGdwaW9zW2kgKiA0ICsgMV07Ci0JCS8q IGdwaW9zW2kgKiA0ICsgMl0gLSBHUElPIHBpbiBkaXJlY3Rpb24gKi8KLQkJLyogZ3Bpb3NbaSAq IDQgKyAzXSAtIEdQSU8gcGluIGZsYWdzICovCisJCS8qIEdldCB0aGUgR1BJTyBwaW4gbnVtYmVy IGFuZCBmbGFncy4gKi8KKwkJaWYgKG9md19idXNfbWFwX2dwaW9zKHNjLT5zY19kZXYsIGNoaWxk LCBncGlvLCBjZWxscywKKwkJICAgICZncGlvc1tpICsgMV0sICZkaW5mby0+cGluc1tqXSwgJmRp bmZvLT5mbGFnc1tqXSkgIT0gMCkgeworCQkJb2Z3X2dwaW9idXNfZnJlZV9pdmFycyhkaW5mbyk7 CisJCQlmcmVlKGdwaW9zLCBNX0RFVkJVRik7CisJCQlyZXR1cm4gKEVJTlZBTCk7CisJCX0KIAot CQlpZiAoZGluZm8tPnBpbnNbaV0gPiBzYy0+c2NfbnBpbnMpIHsKKwkJLyogQ29uc2lzdGVuY3kg Y2hlY2suICovCisJCWlmIChkaW5mby0+cGluc1tqXSA+IHNjLT5zY19ucGlucykgewogCQkJZGV2 aWNlX3ByaW50ZihzYy0+c2NfYnVzZGV2LAogCQkJICAgICJpbnZhbGlkIHBpbiAlZCwgbWF4OiAl ZFxuIiwKLQkJCSAgICBkaW5mby0+cGluc1tpXSwgc2MtPnNjX25waW5zIC0gMSk7Ci0JCQlmcmVl KGRpbmZvLT5waW5zLCBNX0RFVkJVRik7CisJCQkgICAgZGluZm8tPnBpbnNbal0sIHNjLT5zY19u cGlucyAtIDEpOworCQkJb2Z3X2dwaW9idXNfZnJlZV9pdmFycyhkaW5mbyk7CiAJCQlmcmVlKGdw aW9zLCBNX0RFVkJVRik7CiAJCQlyZXR1cm4gKEVJTlZBTCk7CiAJCX0KQEAgLTE0NywxNSArMjEx LDE4IEBACiAJCS8qCiAJCSAqIE1hcmsgcGluIGFzIG1hcHBlZCBhbmQgZ2l2ZSB3YXJuaW5nIGlm IGl0J3MgYWxyZWFkeSBtYXBwZWQuCiAJCSAqLwotCQlpZiAoc2MtPnNjX3BpbnNfbWFwcGVkW2Rp bmZvLT5waW5zW2ldXSkgeworCQlpZiAoc2MtPnNjX3BpbnNfbWFwcGVkW2RpbmZvLT5waW5zW2pd XSkgewogCQkJZGV2aWNlX3ByaW50ZihzYy0+c2NfYnVzZGV2LAogCQkJICAgICJ3YXJuaW5nOiBw aW4gJWQgaXMgYWxyZWFkeSBtYXBwZWRcbiIsCi0JCQkgICAgZGluZm8tPnBpbnNbaV0pOwotCQkJ ZnJlZShkaW5mby0+cGlucywgTV9ERVZCVUYpOworCQkJICAgIGRpbmZvLT5waW5zW2pdKTsKKwkJ CW9md19ncGlvYnVzX2ZyZWVfaXZhcnMoZGluZm8pOwogCQkJZnJlZShncGlvcywgTV9ERVZCVUYp OwogCQkJcmV0dXJuIChFSU5WQUwpOwogCQl9Ci0JCXNjLT5zY19waW5zX21hcHBlZFtkaW5mby0+ cGluc1tpXV0gPSAxOworCQlzYy0+c2NfcGluc19tYXBwZWRbZGluZm8tPnBpbnNbal1dID0gMTsK KworCQlpICs9IGNlbGxzICsgMTsKKwkJaisrOwogCX0KIAogCWZyZWUoZ3Bpb3MsIE1fREVWQlVG KTsKSW5kZXg6IHN5cy9kZXYvb2Z3L29md19idXMuaAo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvZGV2L29m dy9vZndfYnVzLmgJKHJldmlzaW9uIDI2NDU1MCkKKysrIHN5cy9kZXYvb2Z3L29md19idXMuaAko d29ya2luZyBjb3B5KQpAQCAtNzYsNCArNzYsMTIgQEAKIAlyZXR1cm4gKE9GV19CVVNfTUFQX0lO VFIoZGV2LCBkZXYsIGlwYXJlbnQsIGljZWxscywgaW50cikpOwogfQogCitzdGF0aWMgX19pbmxp bmUgaW50CitvZndfYnVzX21hcF9ncGlvcyhkZXZpY2VfdCBidXMsIHBoYW5kbGVfdCBkZXYsIHBo YW5kbGVfdCBncGFyZW50LCBpbnQgZ2NlbGxzLAorICAgIHBjZWxsX3QgKmdwaW9zLCB1aW50MzJf dCAqcGluLCB1aW50MzJfdCAqZmxhZ3MpCit7CisJcmV0dXJuIChPRldfQlVTX01BUF9HUElPUyhi dXMsIGRldiwgZ3BhcmVudCwgZ2NlbGxzLCBncGlvcywgcGluLAorCSAgICBmbGFncykpOworfQor CiAjZW5kaWYgLyogIV9ERVZfT0ZXX09GV19CVVNfSF8gKi8KSW5kZXg6IHN5cy9kZXYvb2Z3L29m d19idXNfaWYubQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvZGV2L29mdy9vZndfYnVzX2lmLm0JKHJldmlz aW9uIDI2NDU1MCkKKysrIHN5cy9kZXYvb2Z3L29md19idXNfaWYubQkod29ya2luZyBjb3B5KQpA QCAtNTgsNiArNTgsNyBAQAogCXN0YXRpYyBvZndfYnVzX2dldF9ub2RlX3Qgb2Z3X2J1c19kZWZh dWx0X2dldF9ub2RlOwogCXN0YXRpYyBvZndfYnVzX2dldF90eXBlX3Qgb2Z3X2J1c19kZWZhdWx0 X2dldF90eXBlOwogCXN0YXRpYyBvZndfYnVzX21hcF9pbnRyX3Qgb2Z3X2J1c19kZWZhdWx0X21h cF9pbnRyOworCXN0YXRpYyBvZndfYnVzX21hcF9ncGlvc190IG9md19idXNfZGVmYXVsdF9tYXBf Z3Bpb3M7CiAKIAlzdGF0aWMgY29uc3Qgc3RydWN0IG9md19idXNfZGV2aW5mbyAqCiAJb2Z3X2J1 c19kZWZhdWx0X2dldF9kZXZpbmZvKGRldmljZV90IGJ1cywgZGV2aWNlX3QgZGV2KQpAQCAtMTEz LDYgKzExNCwyNCBAQAogCQkvKiBJZiB0aGF0IGZhaWxzLCB0aGVuIGFzc3VtZSBhIG9uZS1kb21h aW4gc3lzdGVtICovCiAJCXJldHVybiAoaW50ZXJydXB0WzBdKTsKIAl9CisKKwlpbnQKKwlvZndf YnVzX2RlZmF1bHRfbWFwX2dwaW9zKGRldmljZV90IGJ1cywgcGhhbmRsZV90IGRldiwKKwkgICAg cGhhbmRsZV90IGdwYXJlbnQsIGludCBnY2VsbHMsIHBjZWxsX3QgKmdwaW9zLCB1aW50MzJfdCAq cGluLAorCSAgICB1aW50MzJfdCAqZmxhZ3MpCisJeworCQkvKiBQcm9wYWdhdGUgdXAgdGhlIGJ1 cyBoaWVyYXJjaHkgdW50aWwgc29tZW9uZSBoYW5kbGVzIGl0LiAqLwkKKwkJaWYgKGRldmljZV9n ZXRfcGFyZW50KGJ1cykgIT0gTlVMTCkKKwkJCXJldHVybiBPRldfQlVTX01BUF9HUElPUyhkZXZp Y2VfZ2V0X3BhcmVudChidXMpLCBkZXYsCisJCQkgICAgZ3BhcmVudCwgZ2NlbGxzLCBncGlvcywg cGluLCBmbGFncyk7CisKKwkJLyogSWYgdGhhdCBmYWlscywgdGhlbiBhc3N1bWUgdGhlIEZyZWVC U0QgZGVmYXVsdHMuICovCisJCSpwaW4gPSBncGlvc1swXTsKKwkJaWYgKGdjZWxscyA9PSAyIHx8 IGdjZWxscyA9PSAzKQorCQkJKmZsYWdzID0gZ3Bpb3NbZ2NlbGxzIC0gMV07CisKKwkJcmV0dXJu ICgwKTsKKwl9CiB9OwogCiAjIEdldCB0aGUgb2Z3X2J1c19kZXZpbmZvIHN0cnVjdCBmb3IgdGhl IGRldmljZSBkZXYgb24gdGhlIGJ1cy4gVXNlZCBmb3IgYnVzCkBAIC0xNzAsNCArMTg5LDEzIEBA CiAJcGNlbGxfdCAqaW50ZXJydXB0OwogfSBERUZBVUxUIG9md19idXNfZGVmYXVsdF9tYXBfaW50 cjsKIAotCisjIE1hcCB0aGUgR1BJTyBjb250cm9sbGVyIHNwZWNpZmljIGdwaW8tc3BlY2lmaWVy IHRvIEdQSU8gcGluIGFuZCBmbGFncy4KK01FVEhPRCBpbnQgbWFwX2dwaW9zIHsKKwlkZXZpY2Vf dCBidXM7CisJcGhhbmRsZV90IGRldjsKKwlwaGFuZGxlX3QgZ3BhcmVudDsKKwlpbnQgZ2NlbGxz OworCXBjZWxsX3QgKmdwaW9zOworCXVpbnQzMl90ICpwaW47CisJdWludDMyX3QgKmZsYWdzOwor fSBERUZBVUxUIG9md19idXNfZGVmYXVsdF9tYXBfZ3Bpb3M7Cg== --f46d0438933faa55ca04f7b65f6b-- From owner-freebsd-embedded@FreeBSD.ORG Mon Apr 28 11:06:45 2014 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D5823CC for ; Mon, 28 Apr 2014 11:06:45 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EE3D51A9B for ; Mon, 28 Apr 2014 11:06:44 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3SB6iR6086080 for ; Mon, 28 Apr 2014 11:06:44 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3SB6iad086078 for freebsd-embedded@FreeBSD.org; Mon, 28 Apr 2014 11:06:44 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 28 Apr 2014 11:06:44 GMT Message-Id: <201404281106.s3SB6iad086078@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-embedded@FreeBSD.org Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 11:06:45 -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 misc/52256 embedded [picobsd] picobsd build script does not read in user/s o kern/42728 embedded [picobsd] many problems in src/usr.sbin/ppp/* after c 2 problems total. From owner-freebsd-embedded@FreeBSD.ORG Tue Apr 29 11:50:03 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A7CD659; Tue, 29 Apr 2014 11:50:03 +0000 (UTC) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6526E186E; Tue, 29 Apr 2014 11:50:02 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id hi2so274242wib.1 for ; Tue, 29 Apr 2014 04:50:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=xVvYXPBAhtJPn5BCNMZxLlKpgNI0JVuElDO2jdtq1/s=; b=BT6oy+AJYSdW+48W/bQO0yBmh+9deUptYU6hq2+hJx+IdiUEyIW5C7iTQ6QhABGA/p SglbuH+FaCnz4X4ecv8BG6NzEcAHuPkdy+UNO77ObyuSGS+POxD6htDl0y5lzAHk1qQy ITfK0EKTkh8ivP7s4jEak4JFaDJMKYzWX++DgwsLO2TIje8U+dTSJII4t4tdkoFRRLYO On/3eac5qqA1WGQ9utgn6JEWqxKOHZe2Qo8cUuIjdgdIql+lZ7ZhyfUHoEfHumIprxix 77OzagWjnPvKsHCCGK3Xg1Qvph67ZP5cHRLah1cSFlNiwBYIfP3w18AJZgKL9WkJ21Xx hbsw== MIME-Version: 1.0 X-Received: by 10.180.206.205 with SMTP id lq13mr19985738wic.11.1398772200446; Tue, 29 Apr 2014 04:50:00 -0700 (PDT) Received: by 10.216.40.72 with HTTP; Tue, 29 Apr 2014 04:50:00 -0700 (PDT) Date: Tue, 29 Apr 2014 08:50:00 -0300 Message-ID: Subject: [RFC] geom_uncompress(4) changes From: Luiz Otavio O Souza To: freebsd-geom@freebsd.org, freebsd-embedded Content-Type: multipart/mixed; boundary=001a11c382d422f85004f82d089e X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 11:50:03 -0000 --001a11c382d422f85004f82d089e Content-Type: text/plain; charset=UTF-8 Hi, I've the attached changes to geom_uncompress(4) that modularise the compression support. It can now be built with support to mkuzip(8) or mkulzma(8) (or both) independently. It also make a lot easier to add the support to new compression methods on geom_uncompress. Now, building a kernel with 'options GEOM_UNCOMPRESS' (kept for backward compatibility) adds only the support to read mkulzma images. Building a kernel with 'options GEOM_UNCOMPRESS_UZIP' will add the support to read mkuzip images. The both options can be combined and they will produce a kernel which can read both formats. The geom_uncompress module is built with both compression methods enabled keeping the backward compatibility. I think we could eventually retire geom_uzip(8) as they are doing essentially the same thing (with the same implementation and code...). But this lets a lot of open questions regarding backward compatibility. Regards, Luiz --001a11c382d422f85004f82d089e Content-Type: text/plain; charset=US-ASCII; name="g_uncompress.diff" Content-Disposition: attachment; filename="g_uncompress.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hul4oxbq0 SW5kZXg6IHN5cy9jb25mL2ZpbGVzCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9jb25mL2ZpbGVzCShyZXZp c2lvbiAyNjUwMTMpCisrKyBzeXMvY29uZi9maWxlcwkod29ya2luZyBjb3B5KQpAQCAtMjc0Miw3 ICsyNzQyLDkgQEAKIGdlb20vcmFpZDMvZ19yYWlkM19jdGwuYwlvcHRpb25hbCBnZW9tX3JhaWQz CiBnZW9tL3Noc2VjL2dfc2hzZWMuYwkJb3B0aW9uYWwgZ2VvbV9zaHNlYwogZ2VvbS9zdHJpcGUv Z19zdHJpcGUuYwkJb3B0aW9uYWwgZ2VvbV9zdHJpcGUKLWdlb20vdW5jb21wcmVzcy9nX3VuY29t cHJlc3MuYwlvcHRpb25hbCBnZW9tX3VuY29tcHJlc3MKK2dlb20vdW5jb21wcmVzcy9nX3VuY29t cHJlc3MuYwlvcHRpb25hbCBnZW9tX3VuY29tcHJlc3MgfCBnZW9tX3VuY29tcHJlc3NfdXppcAor Z2VvbS91bmNvbXByZXNzL2dfdW5jb21wcmVzc191bHptYS5jCW9wdGlvbmFsIGdlb21fdW5jb21w cmVzcworZ2VvbS91bmNvbXByZXNzL2dfdW5jb21wcmVzc191emlwLmMJb3B0aW9uYWwgZ2VvbV91 bmNvbXByZXNzX3V6aXAKIGNvbnRyaWIveHotZW1iZWRkZWQvZnJlZWJzZC94el9tYWxsb2MuYwlc CiAJb3B0aW9uYWwgeHpfZW1iZWRkZWQgfCBnZW9tX3VuY29tcHJlc3MgXAogCWNvbXBpbGUtd2l0 aCAiJHtOT1JNQUxfQ30gLUkkUy9jb250cmliL3h6LWVtYmVkZGVkL2ZyZWVic2QvIC1JJFMvY29u dHJpYi94ei1lbWJlZGRlZC9saW51eC9saWIveHovIC1JJFMvY29udHJpYi94ei1lbWJlZGRlZC9s aW51eC9pbmNsdWRlL2xpbnV4LyIKQEAgLTMxMzksNyArMzE0MSw3IEBACiBuZXQvdm5ldC5jCQkJ b3B0aW9uYWwgdmltYWdlCiBuZXQvemxpYi5jCQkJb3B0aW9uYWwgY3J5cHRvIHwgZ2VvbV91emlw IHwgaXBzZWMgfCBcCiAJCQkJCSBteGdlIHwgbmV0Z3JhcGhfZGVmbGF0ZSB8IFwKLQkJCQkJIGRk Yl9jdGYgfCBnemlvIHwgZ2VvbV91bmNvbXByZXNzCisJCQkJCSBkZGJfY3RmIHwgZ3ppbyB8IGdl b21fdW5jb21wcmVzc191emlwCiBuZXQ4MDIxMS9pZWVlODAyMTEuYwkJb3B0aW9uYWwgd2xhbgog bmV0ODAyMTEvaWVlZTgwMjExX2FjbC5jCW9wdGlvbmFsIHdsYW4gd2xhbl9hY2wKIG5ldDgwMjEx L2llZWU4MDIxMV9hY3Rpb24uYwlvcHRpb25hbCB3bGFuCkluZGV4OiBzeXMvY29uZi9vcHRpb25z Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0KLS0tIHN5cy9jb25mL29wdGlvbnMJKHJldmlzaW9uIDI2NTAxMykKKysrIHN5 cy9jb25mL29wdGlvbnMJKHdvcmtpbmcgY29weSkKQEAgLTEyNCw2ICsxMjQsNyBAQAogR0VPTV9T VFJJUEUJb3B0X2dlb20uaAogR0VPTV9TVU5MQUJFTAlvcHRfZ2VvbS5oCiBHRU9NX1VOQ09NUFJF U1MJb3B0X2dlb20uaAorR0VPTV9VTkNPTVBSRVNTX1VaSVAJb3B0X2dlb20uaAogR0VPTV9VWklQ CW9wdF9nZW9tLmgKIEdFT01fVklSU1RPUglvcHRfZ2VvbS5oCiBHRU9NX1ZPTAlvcHRfZ2VvbS5o CkluZGV4OiBzeXMvZ2VvbS91bmNvbXByZXNzL2dfdW5jb21wcmVzcy5jCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0t IHN5cy9nZW9tL3VuY29tcHJlc3MvZ191bmNvbXByZXNzLmMJKHJldmlzaW9uIDI2NTAxMykKKysr IHN5cy9nZW9tL3VuY29tcHJlc3MvZ191bmNvbXByZXNzLmMJKHdvcmtpbmcgY29weSkKQEAgLTI3 LDE1ICsyNywxOSBAQAogCiAvKgogICogR0VPTSBVTkNPTVBSRVNTIG1vZHVsZSAtIHNpbXBsZSBk ZWNvbXByZXNzaW9uIG1vZHVsZSBmb3IgdXNlIHdpdGggcmVhZC1vbmx5Ci0gKiBjb3ByZXNzZWQg aW1hZ2VzIG1ha2VkIGJ5IG1rdXppcCg4KSBvciBta3Vsem1hKDgpIHV0aWxpdGllcy4KKyAqIGNv bXByZXNzZWQgaW1hZ2VzIGNyZWF0ZWQgYnkgbWt1emlwKDgpIG9yIG1rdWx6bWEoOCkgdXRpbGl0 aWVzLgogICoKLSAqIFRvIGVuYWJsZSBtb2R1bGUgaW4ga2VybmVsIGNvbmZpZywgcHV0IHRoaXMg bGluZToKLSAqIGRldmljZQlnZW9tX3VuY29tcHJlc3MKKyAqIFRvIGVuYWJsZSB1bmNvbXByZXNz IHN1cHBvcnQgaW4ga2VybmVsIGNvbmZpZywgYWRkIHRoZXNlIGxpbmVzIChmb3IgdWx6bWEKKyAq IGFuZCB1emlwIHN1cHBvcnQgcmVzcGVjdGl2ZWx5KToKKyAqIG9wdGlvbnMJZ2VvbV91bmNvbXBy ZXNzCisgKiBvcHRpb25zCWdlb21fdW5jb21wcmVzc191emlwCiAgKi8KIAogI2luY2x1ZGUgPHN5 cy9jZGVmcy5oPgogX19GQlNESUQoIiRGcmVlQlNEJCIpOwogCisjaW5jbHVkZSAib3B0X2dlb20u aCIKKwogI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgogI2luY2x1ZGUgPHN5cy9iaW8uaD4KICNpbmNs dWRlIDxzeXMvZW5kaWFuLmg+CkBAIC00NywxMCArNTEsOCBAQAogI2luY2x1ZGUgPHN5cy9zeXN0 bS5oPgogCiAjaW5jbHVkZSA8Z2VvbS9nZW9tLmg+CisjaW5jbHVkZSA8Z2VvbS91bmNvbXByZXNz L2dfdW5jb21wcmVzcy5oPgogCi0jaW5jbHVkZSA8bmV0L3psaWIuaD4KLSNpbmNsdWRlIDxjb250 cmliL3h6LWVtYmVkZGVkL2xpbnV4L2luY2x1ZGUvbGludXgveHouaD4KLQogI2lmZGVmIEdFT01f VU5DT01QUkVTU19ERUJVRwogI2RlZmluZQlEUFJJTlRGKGEpCXByaW50ZiBhCiBleHRlcm4gaW50 IGdfZGVidWdmbGFnczsKQEAgLTU4LDEyICs2MCwxMCBAQAogI2RlZmluZQlEUFJJTlRGKGEpCiAj ZW5kaWYKIAotc3RhdGljIE1BTExPQ19ERUZJTkUoTV9HRU9NX1VOQ09NUFJFU1MsICJnZW9tX3Vu Y29tcHJlc3MiLAorTUFMTE9DX0RFRklORShNX0dFT01fVU5DT01QUkVTUywgImdlb21fdW5jb21w cmVzcyIsCiAgICAgIkdFT00gVU5DT01QUkVTUyBkYXRhIHN0cnVjdHVyZXMiKTsKIAogI2RlZmlu ZQlVTkNPTVBSRVNTX0NMQVNTX05BTUUJIlVOQ09NUFJFU1MiCi0jZGVmaW5lCUdFT01fVVpJUF9N QUpWRVIgJzInCi0jZGVmaW5lCUdFT01fVUxaTUFfTUFKVkVSICczJwogCiAvKgogICogTWF4aW11 bSBhbGxvd2VkIHZhbGlkIGJsb2NrIHNpemUgKHRvIHByZXZlbnQgZm9vdC1zaG9vdGluZykKQEAg LTcxLDI4ICs3MSwxNyBAQAogI2RlZmluZQlNQVhfQkxLU1oJKE1BWFBIWVMpCiAKIC8qCi0gKiBJ bnRlZ2VyIHZhbHVlcyAoYmxvY2sgc2l6ZSwgbnVtYmVyIG9mIGJsb2Nrcywgb2Zmc2V0cykKLSAq IGFyZSBzdG9yZWQgaW4gYmlnLWVuZGlhbiAobmV0d29yaykgb3JkZXIgb24gZGlzayBhbmQgc3Ry dWN0IGNsb29wX2hlYWRlcgotICogYW5kIGluIG5hdGl2ZSBvcmRlciBpbiBzdHJ1Y3QgZ191bmNv bXByZXNzX3NvZnRjCisgKiBJbnRlZ2VyIHZhbHVlcyAoYmxvY2sgc2l6ZSwgbnVtYmVyIG9mIGJs b2Nrcywgb2Zmc2V0cykgYXJlIHN0b3JlZCBpbiBuYXRpdmUKKyAqIG9yZGVyIGluIHN0cnVjdCBn X3VuY29tcHJlc3Nfc29mdGMuCiAgKi8KIAotI2RlZmluZQlDTE9PUF9NQUdJQ19MRU4JMTI4CiBz dGF0aWMgY2hhciBDTE9PUF9NQUdJQ19TVEFSVFtdID0gIiMhL2Jpbi9zaFxuIjsKIAotc3RydWN0 IGNsb29wX2hlYWRlciB7Ci0JY2hhciBtYWdpY1tDTE9PUF9NQUdJQ19MRU5dOwkvKiBjbG9vcCBt YWdpYyAqLwotCXVpbnQzMl90IGJsa3N6OwkJCS8qIGJsb2NrIHNpemUgKi8KLQl1aW50MzJfdCBu YmxvY2tzOwkJLyogbnVtYmVyIG9mIGJsb2NrcyAqLwotfTsKLQogc3RydWN0IGdfdW5jb21wcmVz c19zb2Z0YyB7CiAJdWludDMyX3QgYmxrc3o7CQkJLyogYmxvY2sgc2l6ZSAqLwogCXVpbnQzMl90 IG5ibG9ja3M7CQkvKiBudW1iZXIgb2YgYmxvY2tzICovCiAJdWludDY0X3QgKm9mZnNldHM7Ci0J ZW51bSB7Ci0JCUdFT01fVVpJUCA9IDEsCi0JCUdFT01fVUxaTUEKLQl9IHR5cGU7CisJaW50IHR5 cGU7CiAKIAlzdHJ1Y3QgbXR4IGxhc3RfbXR4OwogCXVpbnQzMl90IGxhc3RfYmxrOwkJLyogbGFz dCBibGsgbm8gKi8KQEAgLTk5LDExICs4OCwxNiBAQAogCWNoYXIgKmxhc3RfYnVmOwkJCS8qIGxh c3QgYmxrIGRhdGEgKi8KIAlpbnQgcmVxX3RvdGFsOwkJCS8qIHRvdGFsIHJlcXVlc3RzICovCiAJ aW50IHJlcV9jYWNoZWQ7CQkJLyogY2FjaGVkIHJlcXVlc3RzICovCit9OwogCi0JLyogWFogZGVj b2RlciBzdHJ1Y3RzICovCi0Jc3RydWN0IHh6X2J1ZiAqYjsKLQlzdHJ1Y3QgeHpfZGVjICpzOwot CXpfc3RyZWFtICp6czsKK3N0YXRpYyBzdHJ1Y3QgZ191bmNvbXByZXNzX2Rlc2MgKmdfdW5jb21w cmVzc1tdID0geworI2lmZGVmIEdFT01fVU5DT01QUkVTUworCSZnX3VuY29tcHJlc3NfdWx6bWEs CisjZW5kaWYKKyNpZmRlZiBHRU9NX1VOQ09NUFJFU1NfVVpJUAorCSZnX3VuY29tcHJlc3NfdXpp cCwKKyNlbmRpZgorCU5VTEwKIH07CiAKIHN0YXRpYyB2b2lkCkBAIC0xMTksMjUgKzExMyw4IEBA CiAJCXNjLT5vZmZzZXRzID0gMDsKIAl9CiAKLQlzd2l0Y2ggKHNjLT50eXBlKSB7Ci0JY2FzZSBH RU9NX1VMWk1BOgotCQlpZiAoc2MtPmIpIHsKLQkJCWZyZWUoc2MtPmIsIE1fR0VPTV9VTkNPTVBS RVNTKTsKLQkJCXNjLT5iID0gMDsKLQkJfQotCQlpZiAoc2MtPnMpIHsKLQkJCXh6X2RlY19lbmQo c2MtPnMpOwotCQkJc2MtPnMgPSAwOwotCQl9Ci0JCWJyZWFrOwotCWNhc2UgR0VPTV9VWklQOgot CQlpZiAoc2MtPnpzKSB7Ci0JCQlpbmZsYXRlRW5kKHNjLT56cyk7Ci0JCQlmcmVlKHNjLT56cywg TV9HRU9NX1VOQ09NUFJFU1MpOwotCQkJc2MtPnpzID0gMDsKLQkJfQotCQlicmVhazsKLQl9CisJ LyogQ2FsbCB0aGUgZnJlZSBtZXRob2QuICovCisJZ191bmNvbXByZXNzW3NjLT50eXBlXS0+ZF9m cmVlKGdfdW5jb21wcmVzc1tzYy0+dHlwZV0pOwogCiAJbXR4X2Rlc3Ryb3koJnNjLT5sYXN0X210 eCk7CiAJZnJlZShzYy0+bGFzdF9idWYsIE1fR0VPTV9VTkNPTVBSRVNTKTsKQEAgLTE0NCwyMyAr MTIxLDcgQEAKIAlmcmVlKHNjLCBNX0dFT01fVU5DT01QUkVTUyk7CiB9CiAKLXN0YXRpYyB2b2lk ICoKLXpfYWxsb2Modm9pZCAqbmlsLCB1X2ludCB0eXBlLCB1X2ludCBzaXplKQotewotCXZvaWQg KnB0cjsKLQotCXB0ciA9IG1hbGxvYyh0eXBlICogc2l6ZSwgTV9HRU9NX1VOQ09NUFJFU1MsIE1f Tk9XQUlUKTsKLQlyZXR1cm4gKHB0cik7Ci19Ci0KIHN0YXRpYyB2b2lkCi16X2ZyZWUodm9pZCAq bmlsLCB2b2lkICpwdHIpCi17Ci0KLQlmcmVlKHB0ciwgTV9HRU9NX1VOQ09NUFJFU1MpOwotfQot Ci1zdGF0aWMgdm9pZAogZ191bmNvbXByZXNzX2RvbmUoc3RydWN0IGJpbyAqYnApCiB7CiAJc3Ry dWN0IGdfdW5jb21wcmVzc19zb2Z0YyAqc2M7CkBAIC0yNTQsMzMgKzIxNSw5IEBACiAJCQloZXhk dW1wKGJwLT5iaW9fZGF0YSArIHBvcywgZGxlbiwgMCwgMCk7CiAjZW5kaWYKIAotCQlzd2l0Y2gg KHNjLT50eXBlKSB7Ci0JCWNhc2UgR0VPTV9VTFpNQToKLQkJCXNjLT5iLT5pbiA9IGJwLT5iaW9f ZGF0YSArIHBvczsKLQkJCXNjLT5iLT5vdXQgPSBzYy0+bGFzdF9idWY7Ci0JCQlzYy0+Yi0+aW5f cG9zID0gc2MtPmItPm91dF9wb3MgPSAwOwotCQkJc2MtPmItPmluX3NpemUgPSBkbGVuOwotCQkJ c2MtPmItPm91dF9zaXplID0gKHNpemVfdCktMTsKLQotCQkJZXJyID0gKHh6X2RlY19ydW4oc2Mt PnMsIHNjLT5iKSAhPSBYWl9TVFJFQU1fRU5EKSA/Ci0JCQkgICAgMSA6IDA7Ci0JCQkvKiBUT0RP IGRlY29kZXIgcmVjb3ZlcnksIGlmIG5lZWRlZCAqLwotCQkJYnJlYWs7Ci0JCWNhc2UgR0VPTV9V WklQOgotCQkJc2MtPnpzLT5uZXh0X2luID0gYnAtPmJpb19kYXRhICsgcG9zOwotCQkJc2MtPnpz LT5hdmFpbF9pbiA9IGRsZW47Ci0JCQlzYy0+enMtPm5leHRfb3V0ID0gc2MtPmxhc3RfYnVmOwot CQkJc2MtPnpzLT5hdmFpbF9vdXQgPSBzYy0+Ymxrc3o7Ci0KLQkJCWVyciA9IChpbmZsYXRlKHNj LT56cywgWl9GSU5JU0gpICE9IFpfU1RSRUFNX0VORCkgPwotCQkJICAgIDEgOiAwOwotCQkJaWYg KChlcnIpIHx8IChpbmZsYXRlUmVzZXQoc2MtPnpzKSAhPSBaX09LKSkKLQkJCQlwcmludGYoIiVz OiBVWklQIGRlY29kZXIgcmVzZXQgZmFpbGVkXG4iLAotCQkJCSAgICAgZ3AtPm5hbWUpOwotCQkJ YnJlYWs7Ci0JCX0KLQotCQlpZiAoZXJyKSB7CisJCWlmIChnX3VuY29tcHJlc3Nbc2MtPnR5cGVd LT5kX2RlY29tKGdfdW5jb21wcmVzc1tzYy0+dHlwZV0sCisJCSAgICBncC0+bmFtZSwgYnAtPmJp b19kYXRhICsgcG9zLCBsZW4sIHNjLT5sYXN0X2J1ZiwKKwkJICAgIHNjLT5ibGtzeikgIT0gMCkg ewogCQkJc2MtPmxhc3RfYmxrID0gLTE7CiAJCQltdHhfdW5sb2NrKCZzYy0+bGFzdF9tdHgpOwog CQkJRFBSSU5URigoIiVzOiBkb25lOiBpbmZsYXRlIGZhaWxlZCwgY29kZT0lZFxuIiwKQEAgLTI5 MSw3ICsyMjgsNyBAQAogCiAjaWZkZWYgR0VPTV9VTkNPTVBSRVNTX0RFQlVHCiAJCWlmIChnX2Rl YnVnZmxhZ3MgJiAzMikKLQkJCWhleGR1bXAoc2MtPmxhc3RfYnVmLCBzYy0+Yi0+b3V0X3NpemUs IDAsIDApOworCQkJaGV4ZHVtcChzYy0+bGFzdF9idWYsIHNjLT5ibGtzeiwgMCwgMCk7CiAjZW5k aWYKIAogCQlzYy0+bGFzdF9ibGsgPSBpOwpAQCAtNTIxLDI0ICs0NTgsMTYgQEAKIAkJZ290byBl cnI7CiAJfQogCi0Jc3dpdGNoIChoZWFkZXItPm1hZ2ljWzB4MGJdKSB7Ci0JY2FzZSAnTCc6Ci0J CXR5cGUgPSBHRU9NX1VMWk1BOwotCQlpZiAoaGVhZGVyLT5tYWdpY1sweDBjXSA8IEdFT01fVUxa TUFfTUFKVkVSKSB7Ci0JCQlEUFJJTlRGKCgiJXM6IGltYWdlIHZlcnNpb24gdG9vIG9sZFxuIiwg Z3AtPm5hbWUpKTsKKwlmb3IgKGkgPSAwOyBnX3VuY29tcHJlc3NbaV0gIT0gTlVMTDsgaSsrKSB7 CisJCWVycm9yID0gZ191bmNvbXByZXNzW2ldLT5kX3Rhc3RlKGhlYWRlciwgZ3AtPm5hbWUpOwor CQlpZiAoZXJyb3IgPT0gMSkgeworCQkJLyogTWF0Y2guICovCisJCQl0eXBlID0gaTsKKwkJCWJy ZWFrOworCQl9IGVsc2UgaWYgKGVycm9yID09IC0xKQogCQkJZ290byBlcnI7Ci0JCX0KLQkJcHJp bnRmKCIlczogR0VPTV9VTFpNQSBpbWFnZSBmb3VuZFxuIiwgZ3AtPm5hbWUpOwotCQlicmVhazsK LQljYXNlICdWJzoKLQkJdHlwZSA9IEdFT01fVVpJUDsKLQkJaWYgKGhlYWRlci0+bWFnaWNbMHgw Y10gPCBHRU9NX1VaSVBfTUFKVkVSKSB7Ci0JCQlEUFJJTlRGKCgiJXM6IGltYWdlIHZlcnNpb24g dG9vIG9sZFxuIiwgZ3AtPm5hbWUpKTsKLQkJCWdvdG8gZXJyOwotCQl9Ci0JCXByaW50ZigiJXM6 IEdFT01fVVpJUCBpbWFnZSBmb3VuZFxuIiwgZ3AtPm5hbWUpOwotCQlicmVhazsKLQlkZWZhdWx0 OgorCX0KKwlpZiAoZ191bmNvbXByZXNzW2ldID09IE5VTEwpIHsKIAkJRFBSSU5URigoIiVzOiB1 bnN1cHBvcnRlZCBpbWFnZSB0eXBlXG4iLCBncC0+bmFtZSkpOwogCQlnb3RvIGVycjsKIAl9CkBA IC01ODgsMjMgKzUxNyw5IEBACiAJc2MtPnJlcV90b3RhbCA9IDA7CiAJc2MtPnJlcV9jYWNoZWQg PSAwOwogCi0Jc3dpdGNoIChzYy0+dHlwZSkgewotCWNhc2UgR0VPTV9VTFpNQToKLQkJeHpfY3Jj MzJfaW5pdCgpOwotCQlzYy0+cyA9IHh6X2RlY19pbml0KFhaX1NJTkdMRSwgMCk7Ci0JCXNjLT5i ID0gKHN0cnVjdCB4el9idWYqKW1hbGxvYyhzaXplb2Yoc3RydWN0IHh6X2J1ZiksCi0JCSAgICBN X0dFT01fVU5DT01QUkVTUywgTV9XQUlUT0spOwotCQlicmVhazsKLQljYXNlIEdFT01fVVpJUDoK LQkJc2MtPnpzID0gKHpfc3RyZWFtICopbWFsbG9jKHNpemVvZih6X3N0cmVhbSksCi0JCSAgICBN X0dFT01fVU5DT01QUkVTUywgTV9XQUlUT0spOwotCQlzYy0+enMtPnphbGxvYyA9IHpfYWxsb2M7 Ci0JCXNjLT56cy0+emZyZWUgPSB6X2ZyZWU7Ci0JCWlmIChpbmZsYXRlSW5pdChzYy0+enMpICE9 IFpfT0spIHsKLQkJCWdvdG8gZXJyOwotCQl9Ci0JCWJyZWFrOwotCX0KKwkvKiBJbml0aWFsaXpl IHRoZSBjb21wcmVzc2lvbiBtZXRob2QuICovCisJaWYgKGdfdW5jb21wcmVzc1tzYy0+dHlwZV0t PmRfaW5pdChnX3VuY29tcHJlc3Nbc2MtPnR5cGVdKSAhPSAwKQorCQlnb3RvIGVycjsKIAogCWdf dG9wb2xvZ3lfbG9jaygpOwogCXBwMiA9IGdfbmV3X3Byb3ZpZGVyZihncCwgIiVzIiwgZ3AtPm5h bWUpOwpJbmRleDogc3lzL21vZHVsZXMvZ2VvbS9nZW9tX3VuY29tcHJlc3MvTWFrZWZpbGUKPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQotLS0gc3lzL21vZHVsZXMvZ2VvbS9nZW9tX3VuY29tcHJlc3MvTWFrZWZpbGUJKHJl dmlzaW9uIDI2NTAxMykKKysrIHN5cy9tb2R1bGVzL2dlb20vZ2VvbV91bmNvbXByZXNzL01ha2Vm aWxlCSh3b3JraW5nIGNvcHkpCkBAIC0xMCw4ICsxMCw5IEBACiBDRkxBR1MrPSAtSSR7LkNVUkRJ Un0vLi4vLi4vLi4vZ2VvbS91bmNvbXByZXNzLyBcCiAJLUkkey5DVVJESVJ9Ly4uLy4uLy4uL2Nv bnRyaWIveHotZW1iZWRkZWQvZnJlZWJzZCBcCiAJLUkkey5DVVJESVJ9Ly4uLy4uLy4uL2NvbnRy aWIveHotZW1iZWRkZWQvbGludXgvbGliL3h6LwotU1JDUz0JZ191bmNvbXByZXNzLmMgeHpfY3Jj MzIuYyB4el9kZWNfYmNqLmMgeHpfZGVjX2x6bWEyLmMgeHpfZGVjX3N0cmVhbS5jIFwKLSAgICB4 el9tYWxsb2MuYworQ0ZMQUdTKz0tREdFT01fVU5DT01QUkVTUyAtREdFT01fVU5DT01QUkVTU19V WklQCitTUkNTPQlnX3VuY29tcHJlc3MuYyBnX3VuY29tcHJlc3NfdWx6bWEuYyBnX3VuY29tcHJl c3NfdXppcC5jIG9wdF9nZW9tLmgKK1NSQ1MrPQl4el9jcmMzMi5jIHh6X2RlY19iY2ouYyB4el9k ZWNfbHptYTIuYyB4el9kZWNfc3RyZWFtLmMgeHpfbWFsbG9jLmMKIFNSQ1MrPQl4ei5oIHh6X2Nv bmZpZy5oIHh6X2x6bWEyLmggeHpfbWFsbG9jLmggeHpfcHJpdmF0ZS5oIHh6X3N0cmVhbS5oCiAK IC5pbmNsdWRlIDxic2Qua21vZC5taz4KLS0tIC9kZXYvbnVsbAkyMDE0LTA0LTI3IDEwOjMzOjAw LjAwMDAwMDAwMCAtMDMwMAorKysgc3lzL2dlb20vdW5jb21wcmVzcy9nX3VuY29tcHJlc3MuaAky MDE0LTA0LTI2IDE2OjE4OjM0LjgyMTU0OTUyNCAtMDMwMApAQCAtMCwwICsxLDcxIEBACisvKi0K KyAqIENvcHlyaWdodCAoYykgMjAxMC0yMDEyIEFsZWtzYW5kciBSeWJhbGtvCisgKiBDb3B5cmln aHQgKGMpIDIwMDQgTWF4IEtob24KKyAqIEFsbCByaWdodHMgcmVzZXJ2ZWQuCisgKgorICogUmVk aXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3 aXRob3V0CisgKiBtb2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUg Zm9sbG93aW5nIGNvbmRpdGlvbnMKKyAqIGFyZSBtZXQ6CisgKiAxLiBSZWRpc3RyaWJ1dGlvbnMg b2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgbm90 aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVy LgorICogMi4gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRo ZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMg YW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBpbiB0aGUKKyAqICAgIGRvY3VtZW50YXRpb24g YW5kL29yIG90aGVyIG1hdGVyaWFscyBwcm92aWRlZCB3aXRoIHRoZSBkaXN0cmlidXRpb24uCisg KgorICogVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgQVVUSE9SIEFORCBDT05UUklC VVRPUlMgYGBBUyBJUycnIEFORAorICogQU5ZIEVYUFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVT LCBJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFCisgKiBJTVBMSUVEIFdBUlJBTlRJ RVMgT0YgTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9T RQorICogQVJFIERJU0NMQUlNRUQuICBJTiBOTyBFVkVOVCBTSEFMTCBUSEUgQVVUSE9SIE9SIENP TlRSSUJVVE9SUyBCRSBMSUFCTEUKKyAqIEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURF TlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMCisgKiBEQU1BR0VTIChJ TkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVURSBH T09EUworICogT1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLCBEQVRBLCBPUiBQUk9GSVRTOyBPUiBC VVNJTkVTUyBJTlRFUlJVUFRJT04pCisgKiBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9S WSBPRiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVAorICogTElBQklMSVRZ LCBPUiBUT1JUIChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0UpIEFSSVNJTkcgSU4g QU5ZIFdBWQorICogT1VUIE9GIFRIRSBVU0UgT0YgVEhJUyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJ U0VEIE9GIFRIRSBQT1NTSUJJTElUWSBPRgorICogU1VDSCBEQU1BR0UuCisgKi8KKworI2lmbmRl ZiBfR19VTkNPTVBSRVNTX0hfCisjZGVmaW5lIF9HX1VOQ09NUFJFU1NfSF8KKworTUFMTE9DX0RF Q0xBUkUoTV9HRU9NX1VOQ09NUFJFU1MpOworCisjZGVmaW5lCUNMT09QX01BR0lDX0xFTgkxMjgK KyNkZWZpbmUJQ0xPT1BfVFlQRQkweDBiCisjZGVmaW5lCUNMT09QX1ZFUlNJT04JMHgwYworCisv KgorICogSW50ZWdlciB2YWx1ZXMgKGJsb2NrIHNpemUsIG51bWJlciBvZiBibG9ja3MsIG9mZnNl dHMpIGFyZSBzdG9yZWQgaW4KKyAqIGJpZy1lbmRpYW4gKG5ldHdvcmspIG9yZGVyIG9uIGRpc2sg YW5kIHN0cnVjdCBjbG9vcF9oZWFkZXIuCisgKi8KK3N0cnVjdCBjbG9vcF9oZWFkZXIgeworCWNo YXIgbWFnaWNbQ0xPT1BfTUFHSUNfTEVOXTsJLyogY2xvb3AgbWFnaWMgKi8KKwl1aW50MzJfdCBi bGtzejsJCQkvKiBibG9jayBzaXplICovCisJdWludDMyX3QgbmJsb2NrczsJCS8qIG51bWJlciBv ZiBibG9ja3MgKi8KK307IAorCitzdHJ1Y3QgZ191bmNvbXByZXNzX2Rlc2M7CisKK3R5cGVkZWYg aW50IGdfdW5jb21wcmVzc19kZWNvbV90IChzdHJ1Y3QgZ191bmNvbXByZXNzX2Rlc2MgKiwgY2hh ciAqLAorCWNhZGRyX3QsIG9mZl90LCBjYWRkcl90LCBvZmZfdCk7Cit0eXBlZGVmIHZvaWQgZ191 bmNvbXByZXNzX2ZyZWVfdCAoc3RydWN0IGdfdW5jb21wcmVzc19kZXNjICopOwordHlwZWRlZiBp bnQgZ191bmNvbXByZXNzX2luaXRfdCAoc3RydWN0IGdfdW5jb21wcmVzc19kZXNjICopOwordHlw ZWRlZiBpbnQgZ191bmNvbXByZXNzX3Rhc3RlX3QgKHN0cnVjdCBjbG9vcF9oZWFkZXIgKiwgY2hh ciAqKTsKKworc3RydWN0IGdfdW5jb21wcmVzc19kZXNjIHsKKwl2b2lkCQkJKmRfZGF0YTsKKwln X3VuY29tcHJlc3NfZGVjb21fdAkqZF9kZWNvbTsKKwlnX3VuY29tcHJlc3NfZnJlZV90CSpkX2Zy ZWU7CisJZ191bmNvbXByZXNzX2luaXRfdAkqZF9pbml0OworCWdfdW5jb21wcmVzc190YXN0ZV90 CSpkX3Rhc3RlOworfTsKKworLyogU3VwcG9ydGVkIGNvbXByZXNzaW9uIG1ldGhvZHMuICovCisj aWZkZWYgR0VPTV9VTkNPTVBSRVNTCitleHRlcm4gc3RydWN0IGdfdW5jb21wcmVzc19kZXNjIGdf dW5jb21wcmVzc191bHptYTsKKyNlbmRpZgorI2lmZGVmIEdFT01fVU5DT01QUkVTU19VWklQCitl eHRlcm4gc3RydWN0IGdfdW5jb21wcmVzc19kZXNjIGdfdW5jb21wcmVzc191emlwOworI2VuZGlm CisKKyNlbmRpZiAvKiBfR19VTkNPTVBSRVNTX0hfICovCi0tLSAvZGV2L251bGwJMjAxNC0wNC0y NyAxMDozMzowMC4wMDAwMDAwMDAgLTAzMDAKKysrIHN5cy9nZW9tL3VuY29tcHJlc3MvZ191bmNv bXByZXNzX3Vsem1hLmMJMjAxNC0wNC0yNiAxNjoxOTowNC4wMDM1NDc3MTAgLTAzMDAKQEAgLTAs MCArMSwxMjkgQEAKKy8qLQorICogQ29weXJpZ2h0IChjKSAyMDEwLTIwMTIgQWxla3NhbmRyIFJ5 YmFsa28KKyAqIENvcHlyaWdodCAoYykgMjAwNCBNYXggS2hvbgorICogQWxsIHJpZ2h0cyByZXNl cnZlZC4KKyAqCisgKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5 IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKKyAqIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBw cm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucworICogYXJlIG1ldDoKKyAqIDEu IFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUgY29w eXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9s bG93aW5nIGRpc2NsYWltZXIuCisgKiAyLiBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5IGZvcm0g bXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgbm90aWNlLCB0aGlzIGxp c3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyIGluIHRoZQorICog ICAgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhl IGRpc3RyaWJ1dGlvbi4KKyAqCisgKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBB VVRIT1IgQU5EIENPTlRSSUJVVE9SUyBgYEFTIElTJycgQU5ECisgKiBBTlkgRVhQUkVTUyBPUiBJ TVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUKKyAq IElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEg UEFSVElDVUxBUiBQVVJQT1NFCisgKiBBUkUgRElTQ0xBSU1FRC4gIElOIE5PIEVWRU5UIFNIQUxM IFRIRSBBVVRIT1IgT1IgQ09OVFJJQlVUT1JTIEJFIExJQUJMRQorICogRk9SIEFOWSBESVJFQ1Qs IElORElSRUNULCBJTkNJREVOVEFMLCBTUEVDSUFMLCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJ QUwKKyAqIERBTUFHRVMgKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVO VCBPRiBTVUJTVElUVVRFIEdPT0RTCisgKiBPUiBTRVJWSUNFUzsgTE9TUyBPRiBVU0UsIERBVEEs IE9SIFBST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVSUlVQVElPTikKKyAqIEhPV0VWRVIgQ0FVU0VE IEFORCBPTiBBTlkgVEhFT1JZIE9GIExJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RS SUNUCisgKiBMSUFCSUxJVFksIE9SIFRPUlQgKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVS V0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZCisgKiBPVVQgT0YgVEhFIFVTRSBPRiBUSElTIFNPRlRX QVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GCisgKiBTVUNIIERBTUFH RS4KKyAqLworCisvKgorICogR0VPTSBVTFpNQSBtb2R1bGUgLSBzaW1wbGUgZGVjb21wcmVzc2lv biBtb2R1bGUgZm9yIHVzZSB3aXRoIHJlYWQtb25seQorICogY29tcHJlc3NlZCBpbWFnZXMgY3Jl YXRlZCBieSBta3Vsem1hKDgpLgorICovCisKKyNpbmNsdWRlIDxzeXMvY2RlZnMuaD4KK19fRkJT RElEKCIkRnJlZUJTRCQiKTsKKworI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgorI2luY2x1ZGUgPHN5 cy9rZXJuZWwuaD4KKyNpbmNsdWRlIDxzeXMvbWFsbG9jLmg+CisjaW5jbHVkZSA8c3lzL3N5c3Rt Lmg+CisKKyNpbmNsdWRlIDxnZW9tL3VuY29tcHJlc3MvZ191bmNvbXByZXNzLmg+CisKKyNpbmNs dWRlIDxjb250cmliL3h6LWVtYmVkZGVkL2xpbnV4L2luY2x1ZGUvbGludXgveHouaD4KKworI2Rl ZmluZQlHRU9NX1VMWk1BX01BSlZFUgknMycKKworc3RydWN0IGdfdW5jb21wcmVzc191bHptYV9z b2Z0YyB7CisJLyogWFogZGVjb2RlciBzdHJ1Y3RzICovCisJc3RydWN0IHh6X2J1ZiAqYjsKKwlz dHJ1Y3QgeHpfZGVjICpzOworfTsKKworc3RhdGljIHZvaWQKK2dfdW5jb21wcmVzc191bHptYV9m cmVlKHN0cnVjdCBnX3VuY29tcHJlc3NfZGVzYyAqdW5jb21wcmVzcykKK3sKKwlzdHJ1Y3QgZ191 bmNvbXByZXNzX3Vsem1hX3NvZnRjICpzYzsKKyAgICAgICAgICAgICAgICAKKwlzYyA9IChzdHJ1 Y3QgZ191bmNvbXByZXNzX3Vsem1hX3NvZnRjICopdW5jb21wcmVzcy0+ZF9kYXRhOworCWlmIChz YykgeworCQlpZiAoc2MtPmIpIHsKKwkJCWZyZWUoc2MtPmIsIE1fR0VPTV9VTkNPTVBSRVNTKTsK KwkJCXNjLT5iID0gTlVMTDsKKwkJfQorCQlpZiAoc2MtPnMpIHsKKwkJCXh6X2RlY19lbmQoc2Mt PnMpOworCQkJc2MtPnMgPSBOVUxMOworCQl9CisJCWZyZWUoc2MsIE1fR0VPTV9VTkNPTVBSRVNT KTsKKwkJdW5jb21wcmVzcy0+ZF9kYXRhID0gTlVMTDsKKwl9Cit9CisKK3N0YXRpYyBpbnQKK2df dW5jb21wcmVzc191bHptYV9pbml0KHN0cnVjdCBnX3VuY29tcHJlc3NfZGVzYyAqdW5jb21wcmVz cykKK3sKKwlzdHJ1Y3QgZ191bmNvbXByZXNzX3Vsem1hX3NvZnRjICpzYzsKKworCXNjID0gKHN0 cnVjdCBnX3VuY29tcHJlc3NfdWx6bWFfc29mdGMgKiltYWxsb2Moc2l6ZW9mKCpzYyksCisJICAg IE1fR0VPTV9VTkNPTVBSRVNTLCBNX1dBSVRPSyB8IE1fWkVSTyk7CisJeHpfY3JjMzJfaW5pdCgp OworCXNjLT5zID0geHpfZGVjX2luaXQoWFpfU0lOR0xFLCAwKTsKKwlzYy0+YiA9IChzdHJ1Y3Qg eHpfYnVmICopbWFsbG9jKHNpemVvZihzdHJ1Y3QgeHpfYnVmKSwKKwkgICAgTV9HRU9NX1VOQ09N UFJFU1MsIE1fV0FJVE9LKTsKKworCXVuY29tcHJlc3MtPmRfZGF0YSA9ICh2b2lkICopc2M7CisK KwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgaW50CitnX3VuY29tcHJlc3NfdWx6bWFfZGVjb20o c3RydWN0IGdfdW5jb21wcmVzc19kZXNjICp1bmNvbXByZXNzLCBjaGFyICpwcm92aWRlciwKKwlj YWRkcl90IGluLCBvZmZfdCBpbmxlbiwgY2FkZHJfdCBvdXQsIG9mZl90IG91dGxlbikKK3sKKwlz dHJ1Y3QgZ191bmNvbXByZXNzX3Vsem1hX3NvZnRjICpzYzsKKworCXNjID0gKHN0cnVjdCBnX3Vu Y29tcHJlc3NfdWx6bWFfc29mdGMgKil1bmNvbXByZXNzLT5kX2RhdGE7CisJc2MtPmItPmluID0g aW47CisJc2MtPmItPm91dCA9IG91dDsKKwlzYy0+Yi0+aW5fcG9zID0gc2MtPmItPm91dF9wb3Mg PSAwOworCXNjLT5iLT5pbl9zaXplID0gaW5sZW47CisJc2MtPmItPm91dF9zaXplID0gKHNpemVf dCktMTsKKworCWlmICh4el9kZWNfcnVuKHNjLT5zLCBzYy0+YikgIT0gWFpfU1RSRUFNX0VORCkK KwkJcmV0dXJuICgtMSk7CisKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgaW50CitnX3VuY29t cHJlc3NfdWx6bWFfdGFzdGUoc3RydWN0IGNsb29wX2hlYWRlciAqaGVhZGVyLCBjaGFyICpwcm92 aWRlcikKK3sgICAgICAgCisKKwlpZiAoaGVhZGVyLT5tYWdpY1tDTE9PUF9UWVBFXSAhPSAnTCcp CisJCXJldHVybiAoMCk7CisJaWYgKGhlYWRlci0+bWFnaWNbQ0xPT1BfVkVSU0lPTl0gPCBHRU9N X1VMWk1BX01BSlZFUikgeworCQlwcmludGYoIiVzOiBpbWFnZSB2ZXJzaW9uIHRvbyBvbGRcbiIs IHByb3ZpZGVyKTsKKwkJcmV0dXJuICgtMSk7CisJfQorCXByaW50ZigiJXM6IEdFT01fVUxaTUEg aW1hZ2UgZm91bmRcbiIsIHByb3ZpZGVyKTsKKworCXJldHVybiAoMSk7Cit9CisKK3N0cnVjdCBn X3VuY29tcHJlc3NfZGVzYyBnX3VuY29tcHJlc3NfdWx6bWEgPSB7CisJLmRfZGVjb20gPSBnX3Vu Y29tcHJlc3NfdWx6bWFfZGVjb20sCisJLmRfZnJlZSA9IGdfdW5jb21wcmVzc191bHptYV9mcmVl LAorCS5kX2luaXQgPSBnX3VuY29tcHJlc3NfdWx6bWFfaW5pdCwKKwkuZF90YXN0ZSA9IGdfdW5j b21wcmVzc191bHptYV90YXN0ZSwKK307Ci0tLSAvZGV2L251bGwJMjAxNC0wNC0yNyAxMDozMzow MC4wMDAwMDAwMDAgLTAzMDAKKysrIHN5cy9nZW9tL3VuY29tcHJlc3MvZ191bmNvbXByZXNzX3V6 aXAuYwkyMDE0LTA0LTI2IDE2OjQwOjExLjQxMzQ2Mjg1NSAtMDMwMApAQCAtMCwwICsxLDE0OCBA QAorLyotCisgKiBDb3B5cmlnaHQgKGMpIDIwMTAtMjAxMiBBbGVrc2FuZHIgUnliYWxrbworICog Q29weXJpZ2h0IChjKSAyMDA0IE1heCBLaG9uCisgKiBBbGwgcmlnaHRzIHJlc2VydmVkLgorICoK KyAqIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdp dGggb3Igd2l0aG91dAorICogbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRo YXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zCisgKiBhcmUgbWV0OgorICogMS4gUmVkaXN0cmli dXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAq ICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlz Y2xhaW1lci4KKyAqIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJlcHJv ZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25k aXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgaW4gdGhlCisgKiAgICBkb2N1bWVu dGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0 aW9uLgorICoKKyAqIFRISVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkgVEhFIEFVVEhPUiBBTkQg Q09OVFJJQlVUT1JTIGBgQVMgSVMnJyBBTkQKKyAqIEFOWSBFWFBSRVNTIE9SIElNUExJRUQgV0FS UkFOVElFUywgSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFRIRQorICogSU1QTElFRCBX QVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFS IFBVUlBPU0UKKyAqIEFSRSBESVNDTEFJTUVELiAgSU4gTk8gRVZFTlQgU0hBTEwgVEhFIEFVVEhP UiBPUiBDT05UUklCVVRPUlMgQkUgTElBQkxFCisgKiBGT1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1Qs IElOQ0lERU5UQUwsIFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09OU0VRVUVOVElBTAorICogREFN QUdFUyAoSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9GIFNVQlNU SVRVVEUgR09PRFMKKyAqIE9SIFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFUQSwgT1IgUFJPRklU UzsgT1IgQlVTSU5FU1MgSU5URVJSVVBUSU9OKQorICogSE9XRVZFUiBDQVVTRUQgQU5EIE9OIEFO WSBUSEVPUlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QKKyAqIExJ QUJJTElUWSwgT1IgVE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBBUklT SU5HIElOIEFOWSBXQVkKKyAqIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUsIEVWRU4g SUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YKKyAqIFNVQ0ggREFNQUdFLgorICovCisK Ky8qCisgKiBHRU9NIFVaSVAgbW9kdWxlIC0gc2ltcGxlIGRlY29tcHJlc3Npb24gbW9kdWxlIGZv ciB1c2Ugd2l0aCByZWFkLW9ubHkKKyAqIGNvbXByZXNzZWQgaW1hZ2VzIGNyZWF0ZWQgYnkgbWt1 emlwKDgpLgorICovCisKKyNpbmNsdWRlIDxzeXMvY2RlZnMuaD4KK19fRkJTRElEKCIkRnJlZUJT RCQiKTsKKworI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgorI2luY2x1ZGUgPHN5cy9rZXJuZWwuaD4K KyNpbmNsdWRlIDxzeXMvbWFsbG9jLmg+CisjaW5jbHVkZSA8c3lzL3N5c3RtLmg+CisKKyNpbmNs dWRlIDxnZW9tL3VuY29tcHJlc3MvZ191bmNvbXByZXNzLmg+CisKKyNpbmNsdWRlIDxuZXQvemxp Yi5oPgorCisjZGVmaW5lCUdFT01fVVpJUF9NQUpWRVIJJzInCisKK3N0cnVjdCBnX3VuY29tcHJl c3NfdXppcF9zb2Z0YyB7CisJel9zdHJlYW0gKnpzOworfTsKKworc3RhdGljIHZvaWQKK2dfdW5j b21wcmVzc191emlwX2ZyZWUoc3RydWN0IGdfdW5jb21wcmVzc19kZXNjICp1bmNvbXByZXNzKQor eworCXN0cnVjdCBnX3VuY29tcHJlc3NfdXppcF9zb2Z0YyAqc2M7CisKKwlzYyA9IChzdHJ1Y3Qg Z191bmNvbXByZXNzX3V6aXBfc29mdGMgKil1bmNvbXByZXNzLT5kX2RhdGE7CisJaWYgKHNjKSB7 CisJCWlmIChzYy0+enMpIHsKKwkJCWluZmxhdGVFbmQoc2MtPnpzKTsKKwkJCWZyZWUoc2MtPnpz LCBNX0dFT01fVU5DT01QUkVTUyk7CisJCQlzYy0+enMgPSBOVUxMOworCQl9CisJCWZyZWUoc2Ms IE1fR0VPTV9VTkNPTVBSRVNTKTsKKwkJdW5jb21wcmVzcy0+ZF9kYXRhID0gTlVMTDsKKwl9Cit9 CisKK3N0YXRpYyB2b2lkICoKK3pfYWxsb2Modm9pZCAqbmlsLCB1X2ludCB0eXBlLCB1X2ludCBz aXplKQoreworCXZvaWQgKnB0cjsKKworCXB0ciA9IG1hbGxvYyh0eXBlICogc2l6ZSwgTV9HRU9N X1VOQ09NUFJFU1MsIE1fTk9XQUlUKTsKKwlyZXR1cm4gKHB0cik7Cit9CisKK3N0YXRpYyB2b2lk Cit6X2ZyZWUodm9pZCAqbmlsLCB2b2lkICpwdHIpCit7CisKKwlmcmVlKHB0ciwgTV9HRU9NX1VO Q09NUFJFU1MpOworfQorCitzdGF0aWMgaW50CitnX3VuY29tcHJlc3NfdXppcF9pbml0KHN0cnVj dCBnX3VuY29tcHJlc3NfZGVzYyAqdW5jb21wcmVzcykKK3sKKwlzdHJ1Y3QgZ191bmNvbXByZXNz X3V6aXBfc29mdGMgKnNjOworCisJc2MgPSAoc3RydWN0IGdfdW5jb21wcmVzc191emlwX3NvZnRj ICopbWFsbG9jKHNpemVvZigqc2MpLAorCSAgICBNX0dFT01fVU5DT01QUkVTUywgTV9XQUlUT0sg fCBNX1pFUk8pOworCXNjLT56cyA9ICh6X3N0cmVhbSAqKW1hbGxvYyhzaXplb2Yoel9zdHJlYW0p LAorCSAgICBNX0dFT01fVU5DT01QUkVTUywgTV9XQUlUT0spOworCXNjLT56cy0+emFsbG9jID0g el9hbGxvYzsKKwlzYy0+enMtPnpmcmVlID0gel9mcmVlOworCWlmIChpbmZsYXRlSW5pdChzYy0+ enMpICE9IFpfT0spIHsKKwkJZnJlZSAoc2MtPnpzLCBNX0dFT01fVU5DT01QUkVTUyk7CisJCWZy ZWUgKHNjLCBNX0dFT01fVU5DT01QUkVTUyk7CisJCXJldHVybiAoLTEpOworCX0KKworCXVuY29t cHJlc3MtPmRfZGF0YSA9ICh2b2lkICopc2M7CisKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMg aW50CitnX3VuY29tcHJlc3NfdXppcF9kZWNvbShzdHJ1Y3QgZ191bmNvbXByZXNzX2Rlc2MgKnVu Y29tcHJlc3MsIGNoYXIgKnByb3ZpZGVyLAorCWNhZGRyX3QgaW4sIG9mZl90IGlubGVuLCBjYWRk cl90IG91dCwgb2ZmX3Qgb3V0bGVuKQoreworCWludCBlcnI7CisJc3RydWN0IGdfdW5jb21wcmVz c191emlwX3NvZnRjICpzYzsKKworCXNjID0gKHN0cnVjdCBnX3VuY29tcHJlc3NfdXppcF9zb2Z0 YyAqKXVuY29tcHJlc3MtPmRfZGF0YTsKKwlzYy0+enMtPm5leHRfaW4gPSBpbjsKKwlzYy0+enMt PmF2YWlsX2luID0gaW5sZW47CisJc2MtPnpzLT5uZXh0X291dCA9IG91dDsKKwlzYy0+enMtPmF2 YWlsX291dCA9IG91dGxlbjsKKworCWVyciA9IChpbmZsYXRlKHNjLT56cywgWl9GSU5JU0gpICE9 IFpfU1RSRUFNX0VORCkgPyAgMSA6IDA7CisJaWYgKGVyciB8fCBpbmZsYXRlUmVzZXQoc2MtPnpz KSAhPSBaX09LKSB7CisJCXByaW50ZigiJXM6IFVaSVAgZGVjb2RlciByZXNldCBmYWlsZWRcbiIs IHByb3ZpZGVyKTsKKwkJcmV0dXJuICgtMSk7CisJfQorCisJcmV0dXJuICgwKTsKK30KKworc3Rh dGljIGludAorZ191bmNvbXByZXNzX3V6aXBfdGFzdGUoc3RydWN0IGNsb29wX2hlYWRlciAqaGVh ZGVyLCBjaGFyICpwcm92aWRlcikKK3sKKworCWlmIChoZWFkZXItPm1hZ2ljW0NMT09QX1RZUEVd ICE9ICdWJykKKwkJcmV0dXJuICgwKTsKKwlpZiAoaGVhZGVyLT5tYWdpY1tDTE9PUF9WRVJTSU9O XSA8IEdFT01fVVpJUF9NQUpWRVIpIHsKKwkJcHJpbnRmKCIlczogaW1hZ2UgdmVyc2lvbiB0b28g b2xkXG4iLCBwcm92aWRlcik7CisJCXJldHVybiAoLTEpOworCX0KKwlwcmludGYoIiVzOiBHRU9N X1VaSVAgaW1hZ2UgZm91bmRcbiIsIHByb3ZpZGVyKTsKKworCXJldHVybiAoMSk7Cit9CisKK3N0 cnVjdCBnX3VuY29tcHJlc3NfZGVzYyBnX3VuY29tcHJlc3NfdXppcCA9IHsKKwkuZF9kZWNvbSA9 IGdfdW5jb21wcmVzc191emlwX2RlY29tLAorCS5kX2ZyZWUgPSBnX3VuY29tcHJlc3NfdXppcF9m cmVlLAorCS5kX2luaXQgPSBnX3VuY29tcHJlc3NfdXppcF9pbml0LAorCS5kX3Rhc3RlID0gZ191 bmNvbXByZXNzX3V6aXBfdGFzdGUsCit9OwpJbmRleDogc2hhcmUvbWFuL21hbjQvZ2VvbV91bmNv bXByZXNzLjQKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQotLS0gc2hhcmUvbWFuL21hbjQvZ2VvbV91bmNvbXByZXNzLjQJ KHJldmlzaW9uIDI2NTAxMykKKysrIHNoYXJlL21hbi9tYW40L2dlb21fdW5jb21wcmVzcy40CSh3 b3JraW5nIGNvcHkpCkBAIC0yNCw3ICsyNCw3IEBACiAuXCIKIC5cIiAkRnJlZUJTRCQKIC5cIgot LkRkIEphbnVhcnkgOSwgMjAxNAorLkRkIEFwcmlsIDI3LCAyMDE0CiAuRHQgR0VPTV9VTkNPTVBS RVNTIDQKIC5PcwogLlNoIE5BTUUKQEAgLTMxLDEwICszMSwxMSBAQAogLk5tIGdlb21fdW5jb21w cmVzcwogLk5kICJHRU9NIGJhc2VkIGNvbXByZXNzZWQgZGlzayBpbWFnZXMiCiAuU2ggU1lOT1BT SVMKLVRvIGNvbXBpbGUgdGhpcyBkcml2ZXIgaW50byB0aGUga2VybmVsLCBwbGFjZSB0aGUgZm9s bG93aW5nIGxpbmUgaW4geW91cgorVG8gY29tcGlsZSB0aGlzIGRyaXZlciBpbnRvIHRoZSBrZXJu ZWwsIHBsYWNlIHRoZSBmb2xsb3dpbmcgbGluZXMgaW4geW91cgoga2VybmVsIGNvbmZpZ3VyYXRp b24gZmlsZToKIC5CZCAtcmFnZ2VkIC1vZmZzZXQgaW5kZW50CiAuQ2QgIm9wdGlvbnMgR0VPTV9V TkNPTVBSRVNTIgorLkNkICJvcHRpb25zIEdFT01fVU5DT01QUkVTU19VWklQIgogLkVkCiAuUHAK IEFsdGVybmF0aXZlbHksIHRvIGxvYWQgdGhlIGRyaXZlciBhcyBhIG1vZHVsZSBhdCBib290IHRp bWUsIHBsYWNlIHRoZQpAQCAtODksNiArOTAsMTggQEAKICAgIFNlY3RvcnNpemU6IDUxMgogICAg TW9kZTogcjF3MGUwCiAuRWQKKy5QcAorVGhlIGNvbXByZXNzaW9uIHN1cHBvcnQgY2FuIGJlIGNo b3NlbiBpbiBrZXJuZWwgY29uZmlndXJhdGlvbjoKKy5CbCAtdGFnIC13aWR0aCAiLlN5IG9wdGlv bnMgR0VPTV9VTkNPTVBSRVNTX1VaSVAiCisuSXQgU3kgb3B0aW9ucyBHRU9NX1VOQ09NUFJFU1MK K0VuYWJsZSB0aGUgc3VwcG9ydCBmb3IgbWt1bHptYSg4KSBpbWFnZXMuCisuSXQgU3kgb3B0aW9u cyBHRU9NX1VOQ09NUFJFU1NfVVpJUAorRW5hYmxlIHRoZSBzdXBwb3J0IGZvciBta3V6aXAoOCkg aW1hZ2VzLgorLkVsCisuUHAKK1RoZQorLk5tCittb2R1bGUgaXMgYnVpbHQgd2l0aCBib3RoIGNv bXByZXNzaW9uIG1ldGhvZHMgZW5hYmxlZC4KIC5TaCBTRUUgQUxTTwogLlhyIEdFT00gNCAsCiAu WHIgbWQgNCAsCg== --001a11c382d422f85004f82d089e-- From owner-freebsd-embedded@FreeBSD.ORG Sun May 4 21:51:44 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6B26E6F8 for ; Sun, 4 May 2014 21:51:44 +0000 (UTC) Received: from server1.weites.net (mail.weites.com [89.188.29.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 304D612D1 for ; Sun, 4 May 2014 21:51:42 +0000 (UTC) Received: from [10.14.92.96] (5ED685D2.cm-7-7c.dynamic.ziggo.nl [94.214.133.210]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: harm@weites.com) by server1.weites.net (Postfix) with ESMTPSA id 5B8E77229A for ; Sun, 4 May 2014 23:44:01 +0200 (CEST) Message-ID: <5366B4A0.7090803@weites.com> Date: Sun, 04 May 2014 23:44:00 +0200 From: Harm Weites User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-embedded@freebsd.org Subject: etherswitchcfg reports no vlan capabilities on rtl8366rb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 21:51:44 -0000 Hi, My 1043ND is running HEAD @ r265004M and it's a bit unhappy when configuring vlans on the RTL8366RB. Only after reverting revisions 253569 253568 and 250382 things went back to running normal. This is from before reverting: # etherswitchcfg -v info etherswitch0: Realtek RTL8366RB with 6 ports and 16 VLAN groups etherswitch0: VLAN capabilities=0<> port0: flags=0<> media: Ethernet autoselect (none) status: no carrier port1: flags=0<> media: Ethernet autoselect (1000baseT ) status: active port2: flags=0<> media: Ethernet autoselect (none) status: no carrier port3: flags=0<> media: Ethernet autoselect (none) status: no carrier port4: flags=0<> media: Ethernet autoselect (none) status: no carrier port5: flags=0<> media: Ethernet 1000baseT status: active vlangroup0: vlan: 4094 members 5t vlangroup1: vlan: 1 members 0,5t vlangroup2: vlan: 2 members 1,2,3,4,5t vlangroup3: vlan: 4 members none [..] # etherswitchcfg config vlan_mode vlan_mode needs an argument This is annoying as well, though setting it to port produces no output and apparently doesn't work out anyway. # etherswitchcfg port1 pvid pvid needs an argument port1: flags=0<> media: Ethernet autoselect (1000baseT ) status: active # etherswitchcfg port1 pvid 2 etherswitchcfg: ioctl(IOETHERSWITCHSETPORT): Device not configured I decided to just leave out those revisions to make it usable again, since those were the most notable changes in the etherswitch area. Regards, Harm From owner-freebsd-embedded@FreeBSD.ORG Mon May 5 00:36:26 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 326C2A2A; Mon, 5 May 2014 00:36:26 +0000 (UTC) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D8F6D131B; Mon, 5 May 2014 00:36:25 +0000 (UTC) Received: by mail-qc0-f171.google.com with SMTP id c9so7089026qcz.16 for ; Sun, 04 May 2014 17:36:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=G1J+LF+Tmt6KRWOVD1rScvP5UfjvXhu9MM3D+JC6Qeg=; b=W/7anG9Zdwi5AD61lhrFhJr//Ze48PkYlyiPh95geg0c8hI0HYqAn53dJ8DhhmVipi I1F+r/XBls8T3dfHkk1LAZGu2G5yP6/1J5/sgNGw3H8pOp0ByDqZW4M2nlybc6D9Jiuk LOYkucktCSZ7vowoYA7ospalC9RxFpFbmVKbYDi0My2UCa13JWd8cr9zHiknmdO7Wng9 kCHFreuBO8hYlWt2PgB223rJS0a/MlgNth4xrxq2oBYM2zjyZDfjtNouxhT0RsGaoCVm trDU/OQ4dzL789DNAiO4TEU5F2ytr0ZYDCD+4sBCTE6zrbiSv1dFYMvcu5VPqf/gG+sI AB8g== MIME-Version: 1.0 X-Received: by 10.140.47.18 with SMTP id l18mr38076666qga.9.1399250184999; Sun, 04 May 2014 17:36:24 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Sun, 4 May 2014 17:36:24 -0700 (PDT) In-Reply-To: <5366B4A0.7090803@weites.com> References: <5366B4A0.7090803@weites.com> Date: Sun, 4 May 2014 17:36:24 -0700 X-Google-Sender-Auth: trFYPqkSuZhxfbxycm123OCeFQ0 Message-ID: Subject: Re: etherswitchcfg reports no vlan capabilities on rtl8366rb From: Adrian Chadd To: Harm Weites , Luiz Otavio O Souza Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 00:36:26 -0000 Hi, Hm, it sounds like the support for vlan configuration from Luiz broke things. Luiz, do you have some time to help Harm figure out why your vlan config stuff broke the rtl8366 switch support? Thanks! -a On 4 May 2014 14:44, Harm Weites wrote: > Hi, > > My 1043ND is running HEAD @ r265004M and it's a bit unhappy when > configuring vlans on the RTL8366RB. Only after reverting revisions > 253569 253568 and 250382 things went back to running normal. > > This is from before reverting: > > # etherswitchcfg -v info > etherswitch0: Realtek RTL8366RB with 6 ports and 16 VLAN groups > etherswitch0: VLAN capabilities=0<> > port0: > flags=0<> > media: Ethernet autoselect (none) > status: no carrier > port1: > flags=0<> > media: Ethernet autoselect (1000baseT ) > status: active > port2: > flags=0<> > media: Ethernet autoselect (none) > status: no carrier > port3: > flags=0<> > media: Ethernet autoselect (none) > status: no carrier > port4: > flags=0<> > media: Ethernet autoselect (none) > status: no carrier > port5: > flags=0<> > media: Ethernet 1000baseT > status: active > vlangroup0: > vlan: 4094 > members 5t > vlangroup1: > vlan: 1 > members 0,5t > vlangroup2: > vlan: 2 > members 1,2,3,4,5t > vlangroup3: > vlan: 4 > members none > [..] > > # etherswitchcfg config vlan_mode > vlan_mode needs an argument > > This is annoying as well, though setting it to port produces no output > and apparently doesn't work out anyway. > > # etherswitchcfg port1 pvid > pvid needs an argument > port1: > flags=0<> > media: Ethernet autoselect (1000baseT ) > status: active > # etherswitchcfg port1 pvid 2 > etherswitchcfg: ioctl(IOETHERSWITCHSETPORT): Device not configured > > I decided to just leave out those revisions to make it usable again, > since those were the most notable changes in the etherswitch area. > > Regards, > Harm > _______________________________________________ > freebsd-embedded@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-embedded > To unsubscribe, send any mail to "freebsd-embedded-unsubscribe@freebsd.org" From owner-freebsd-embedded@FreeBSD.ORG Mon May 5 11:06:42 2014 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 27FF6CE4 for ; Mon, 5 May 2014 11:06:42 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 149F41CE3 for ; Mon, 5 May 2014 11:06:42 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s45B6fpM083068 for ; Mon, 5 May 2014 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s45B6feX083066 for freebsd-embedded@FreeBSD.org; Mon, 5 May 2014 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 5 May 2014 11:06:41 GMT Message-Id: <201405051106.s45B6feX083066@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-embedded@FreeBSD.org Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 11:06:42 -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 misc/52256 embedded [picobsd] picobsd build script does not read in user/s o kern/42728 embedded [picobsd] many problems in src/usr.sbin/ppp/* after c 2 problems total. From owner-freebsd-embedded@FreeBSD.ORG Tue May 6 04:23:16 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D30F1A3; Tue, 6 May 2014 04:23:16 +0000 (UTC) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D49C7D65; Tue, 6 May 2014 04:23:15 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id t60so2730328wes.13 for ; Mon, 05 May 2014 21:23:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qNK9azMTPOzIu5okVPkgGw3C491jyBolQ/dqKR2X9Xs=; b=SFjBxoK/shzqMEiTsnAcKbNEJKIQ+oI47CEwLs2K6yF/cQ70ZADdckZPZ1asHNATBC WS/RyTkrKnv19ugOEnYIEUNSpJLTYbcIRLhTp2LkbRE9i5f8pAMel04kk09ClJB3MpxB IeHdmGJW0omCTb/r43JxxWc5SPuXiNn0dxfXP68oWNSEQyFIK7HyzI3Tmv5bZY/WaPHw Ef7tJjXOgfhj1JNkMxSAji0CQM6MZsZkh5H8jkpVGy7WmD+GYj1YxMfXF8MXdgs2co5k dRJ0WyFSdCdRRNcWwDPk1ydoW0GnFaXdWGCFMoRwQBAPl8CTgE/+jtepQe6GNY/Waz77 sM0A== MIME-Version: 1.0 X-Received: by 10.180.83.196 with SMTP id s4mr467833wiy.24.1399350192796; Mon, 05 May 2014 21:23:12 -0700 (PDT) Received: by 10.216.168.194 with HTTP; Mon, 5 May 2014 21:23:12 -0700 (PDT) In-Reply-To: References: <5366B4A0.7090803@weites.com> Date: Tue, 6 May 2014 01:23:12 -0300 Message-ID: Subject: Re: etherswitchcfg reports no vlan capabilities on rtl8366rb From: Luiz Otavio O Souza To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: Luiz Otavio O Souza , "freebsd-embedded@freebsd.org" , Harm Weites X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 04:23:16 -0000 On Sun, May 4, 2014 at 9:36 PM, Adrian Chadd wrote: > Hi, > > Hm, it sounds like the support for vlan configuration from Luiz broke things. > > Luiz, do you have some time to help Harm figure out why your vlan > config stuff broke the rtl8366 switch support? > Sure, i'll try to fix it before BSDCan, but the clock is ticking fast this week :/ Luiz > > > On 4 May 2014 14:44, Harm Weites wrote: >> Hi, >> >> My 1043ND is running HEAD @ r265004M and it's a bit unhappy when >> configuring vlans on the RTL8366RB. Only after reverting revisions >> 253569 253568 and 250382 things went back to running normal. >> >> This is from before reverting: >> >> # etherswitchcfg -v info >> etherswitch0: Realtek RTL8366RB with 6 ports and 16 VLAN groups >> etherswitch0: VLAN capabilities=0<> >> port0: >> flags=0<> >> media: Ethernet autoselect (none) >> status: no carrier >> port1: >> flags=0<> >> media: Ethernet autoselect (1000baseT ) >> status: active >> port2: >> flags=0<> >> media: Ethernet autoselect (none) >> status: no carrier >> port3: >> flags=0<> >> media: Ethernet autoselect (none) >> status: no carrier >> port4: >> flags=0<> >> media: Ethernet autoselect (none) >> status: no carrier >> port5: >> flags=0<> >> media: Ethernet 1000baseT >> status: active >> vlangroup0: >> vlan: 4094 >> members 5t >> vlangroup1: >> vlan: 1 >> members 0,5t >> vlangroup2: >> vlan: 2 >> members 1,2,3,4,5t >> vlangroup3: >> vlan: 4 >> members none >> [..] >> >> # etherswitchcfg config vlan_mode >> vlan_mode needs an argument >> >> This is annoying as well, though setting it to port produces no output >> and apparently doesn't work out anyway. >> >> # etherswitchcfg port1 pvid >> pvid needs an argument >> port1: >> flags=0<> >> media: Ethernet autoselect (1000baseT ) >> status: active >> # etherswitchcfg port1 pvid 2 >> etherswitchcfg: ioctl(IOETHERSWITCHSETPORT): Device not configured >> >> I decided to just leave out those revisions to make it usable again, >> since those were the most notable changes in the etherswitch area. >> >> Regards, >> Harm From owner-freebsd-embedded@FreeBSD.ORG Wed May 7 14:47:31 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A2CC8EE; Wed, 7 May 2014 14:47:31 +0000 (UTC) Received: from mail.xcllnt.net (mail.xcllnt.net [50.0.150.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 30C6FB5; Wed, 7 May 2014 14:47:30 +0000 (UTC) Received: from meganw-sslvpn-nc.jnpr.net ([66.129.239.13]) (authenticated bits=0) by mail.xcllnt.net (8.14.8/8.14.8) with ESMTP id s47ElRHg018043 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 7 May 2014 07:47:29 -0700 (PDT) (envelope-from marcel@xcllnt.net) Content-Type: multipart/signed; boundary="Apple-Mail=_77C82B65-197C-4B3C-981C-8512893D1E00"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [RFC] geom_uncompress(4) changes From: Marcel Moolenaar In-Reply-To: Date: Wed, 7 May 2014 07:47:21 -0700 Message-Id: References: To: Luiz Otavio O Souza X-Mailer: Apple Mail (2.1874) Cc: freebsd-embedded , freebsd-geom@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 14:47:31 -0000 --Apple-Mail=_77C82B65-197C-4B3C-981C-8512893D1E00 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Apr 29, 2014, at 4:50 AM, Luiz Otavio O Souza wrote: > Hi, > > I've the attached changes to geom_uncompress(4) that modularise the > compression support. > > It can now be built with support to mkuzip(8) or mkulzma(8) (or both) > independently. > > It also make a lot easier to add the support to new compression > methods on geom_uncompress. > > Now, building a kernel with 'options GEOM_UNCOMPRESS' (kept for > backward compatibility) adds only the support to read mkulzma images. You're not quite backward compatible, because GEOM_UNCOMPRESS now includes both lzma and zip. You may want to add GEOM_UNCOMPRESS_ULZMA and document it as the way to add support for lzma. That way you can simply "redefine" GEOM_UNCOMPRESS as meaning any and all compression algorithms. Thus: - GEOM_UNCOMPRESS gives you support for any and all. - GEOM_UNCOMPRESS_FOO gives you support for just FOO. > > I think we could eventually retire geom_uzip(8) as they are doing > essentially the same thing (with the same implementation and code...). > But this lets a lot of open questions regarding backward > compatibility. You can even redefine GEOM_UZIP to do what GEOM_UNCOMPRESS_UZIP does. If the code is effectively the same then compatibility is about the options, not the actual C files underneath... In general: good! -- Marcel Moolenaar marcel@xcllnt.net --Apple-Mail=_77C82B65-197C-4B3C-981C-8512893D1E00 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEUEARECAAYFAlNqR3kACgkQpgWlLWHuifaqAwCYwhmdAEdzD1X9lPFEmzg1BaXM HACeLqcmohEBBhRMNhmT2L8GMEqAOiQ= =J8Zq -----END PGP SIGNATURE----- --Apple-Mail=_77C82B65-197C-4B3C-981C-8512893D1E00-- From owner-freebsd-embedded@FreeBSD.ORG Wed May 7 20:20:18 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25A40935 for ; Wed, 7 May 2014 20:20:18 +0000 (UTC) Received: from mail.fizon.de (mail.fizon.de [85.159.14.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BAEDAA1D for ; Wed, 7 May 2014 20:20:17 +0000 (UTC) Received: from [192.168.2.76] (p54995F74.dip0.t-ipconnect.de [84.153.95.116]) (authenticated bits=0) by mail.fizon.de (8.14.5/8.14.5) with ESMTP id s47JmpgK043464 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 7 May 2014 21:48:52 +0200 (CEST) (envelope-from mail@sezi.eu) From: Sebastian Zietz Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: GPIO interrupts on Carambola2 Date: Wed, 7 May 2014 21:48:52 +0200 Message-Id: <1A78D43F-9406-4DAB-8554-D8802DE8A3E1@sezi.eu> To: freebsd-embedded@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 20:20:18 -0000 Hi all, since I am not much into device driver programming jet I hope you can = help me with my problem. I have a hardware button on GPIO pin 22 and = can=92t generate interrupts on it. In sys/mips/atheros/ar71xx_gpio.c I=92d= like to do something like: 331 static void 332 ar71xx_gpio_intr(void *arg) 333 { 334 struct ar71xx_gpio_softc *sc =3D arg; 335 GPIO_LOCK(sc); 336 /* TODO: something useful */ 337 devctl_notify("GPIO", "pin22", "notify", NULL); 338 GPIO_UNLOCK(sc); 339 } To get it working I tried this without success: 410 /* Configure all pins as input */ 411 /* disable interrupts for all pins */ 412 GPIO_WRITE(sc, AR71XX_GPIO_INT_MASK, 0); 413 GPIO_WRITE(sc, AR71XX_GPIO_INT_MASK, (1 << 22)); I didn=92t managed to come up with pin 22 as input either. I am thankful = for any help!= From owner-freebsd-embedded@FreeBSD.ORG Thu May 8 00:47:38 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D026A2AA for ; Thu, 8 May 2014 00:47:38 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6971531C for ; Thu, 8 May 2014 00:47:38 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id hi2so238197wib.4 for ; Wed, 07 May 2014 17:47:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=09YPA/MRllMMTOXBQs52JhRIQ/q9w9mUdqcpzyyw4c8=; b=XVPfvhIfq3cHb2d0a+wOy6ExZuT/UbmX23PT+DZ2PZretEWLM1ETMBqUI7Tx0yreZq 3UaVk1GYdv8hK7+cw1mLRY4K43pYMoySU4xYG0VioJ0A+w8fM7Ozal6CkeHBhmgsEd6t Rhk8FXzlA/7nqmnKxRnmlU4EN0gzvhMk7eztRG9ceTjauNaDwUEXK5NtwzUBTZFvAnyJ ThTnVqs0YH9QKZ//CGn+5i+BAnC1yQnxWauFNxexoQ9E2jUoprAv+mIrYcLFHxrz/ySs mXIxrLNzUQNZtDgQdKBUnaAeY3Pd+C2jwgMLs6kyS1YJEwJ1elsOW6/xr49Rz1byL6ml EnEg== MIME-Version: 1.0 X-Received: by 10.180.218.35 with SMTP id pd3mr10169716wic.26.1399510056689; Wed, 07 May 2014 17:47:36 -0700 (PDT) Received: by 10.216.40.72 with HTTP; Wed, 7 May 2014 17:47:36 -0700 (PDT) In-Reply-To: <1A78D43F-9406-4DAB-8554-D8802DE8A3E1@sezi.eu> References: <1A78D43F-9406-4DAB-8554-D8802DE8A3E1@sezi.eu> Date: Wed, 7 May 2014 21:47:36 -0300 Message-ID: Subject: Re: GPIO interrupts on Carambola2 From: Luiz Otavio O Souza To: Sebastian Zietz Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-embedded X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 00:47:38 -0000 On 7 May 2014 16:48, Sebastian Zietz wrote: > Hi all, > > since I am not much into device driver programming jet I hope you can hel= p me with my problem. I have a hardware button on GPIO pin 22 and can=E2=80= =99t generate interrupts on it. In sys/mips/atheros/ar71xx_gpio.c I=E2=80= =99d like to do something like: > > 331 static void > 332 ar71xx_gpio_intr(void *arg) > 333 { > 334 struct ar71xx_gpio_softc *sc =3D arg; > 335 GPIO_LOCK(sc); > 336 /* TODO: something useful */ > 337 devctl_notify("GPIO", "pin22", "notify", NULL); > 338 GPIO_UNLOCK(sc); > 339 } > > > To get it working I tried this without success: > > 410 /* Configure all pins as input */ > 411 /* disable interrupts for all pins */ > 412 GPIO_WRITE(sc, AR71XX_GPIO_INT_MASK, 0); > 413 GPIO_WRITE(sc, AR71XX_GPIO_INT_MASK, (1 << 22)); > > > I didn=E2=80=99t managed to come up with pin 22 as input either. I am tha= nkful for any help! Sebastian, I'm adding GPIO interrupt support and ar71xx is one of my reference platforms so this should be working soon. I'm using kqueue to delivery the interrupt notification to userland, but eventually i'll also support devctl_notify(). The patch(es) should be posted soon now. Luiz From owner-freebsd-embedded@FreeBSD.ORG Mon May 12 11:06:42 2014 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3D018A59 for ; Mon, 12 May 2014 11:06:42 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2901026BB for ; Mon, 12 May 2014 11:06:42 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4CB6fBn067765 for ; Mon, 12 May 2014 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4CB6f5I067762 for freebsd-embedded@FreeBSD.org; Mon, 12 May 2014 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 12 May 2014 11:06:41 GMT Message-Id: <201405121106.s4CB6f5I067762@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-embedded@FreeBSD.org Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 11:06:42 -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 misc/52256 embedded [picobsd] picobsd build script does not read in user/s o kern/42728 embedded [picobsd] many problems in src/usr.sbin/ppp/* after c 2 problems total. From owner-freebsd-embedded@FreeBSD.ORG Wed May 14 19:30:59 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 99337BCF for ; Wed, 14 May 2014 19:30:59 +0000 (UTC) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DF0CE222E for ; Wed, 14 May 2014 19:30:58 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id bs8so8616432wib.12 for ; Wed, 14 May 2014 12:30:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=E8JscvFz6e2CX6/quEweGkdCOWssV335kRzIH9ExF5E=; b=AggJV0qZ9Zyk1pwBF1EQs5TkgmP6a3tysGfwEUvdGSU7J2W3x/luE5PtXOdYBFOrqT 4f51qIC64ZUdWvTqqP+82h9k3cQib4TjMvt/Iz0BXqe/0kzU8eXstfekUaX6atSmiyhF pOJEWnVNCafC/igqjDy35EX2OrfNZXHx3jIdQPlV3OZIWs8oRosdMowi+yKGFPZsqIWk ERFvnqmXiW5385zfYoLnSFOECnHdUHEneDR4VwSiR1hxwwR99/S+RZj9mCN1AkynC3nF mQU+LfynQt6FBZNNKEtPEjfu7PNQtQR97WCTRrFhe6vhDl9v5uTO4PPCAWLNQEmgn5jS FKIw== MIME-Version: 1.0 X-Received: by 10.180.211.36 with SMTP id mz4mr8147481wic.20.1400095857215; Wed, 14 May 2014 12:30:57 -0700 (PDT) Received: by 10.216.168.194 with HTTP; Wed, 14 May 2014 12:30:56 -0700 (PDT) Date: Wed, 14 May 2014 16:30:56 -0300 Message-ID: Subject: [RFC] GPIO interrupt support From: Luiz Otavio O Souza To: "freebsd-embedded@freebsd.org" Content-Type: multipart/mixed; boundary=001a11c335ce38a5b404f96138f2 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 19:30:59 -0000 --001a11c335ce38a5b404f96138f2 Content-Type: text/plain; charset=UTF-8 Hi, I've been working on the attached patches which adds the GPIO interrupt support. gpio-intr.diff has the bus changes for FDT and non-FDT systems. ar71xx_gpio-intr.diff has the changes to AR71xx GPIO driver. bcm2835_gpio-intr.diff has the changes to BCM2835 (RPi) GPIO driver. ti_gpio-intr.diff has the changes for AM335x (Beaglebone), OMAP3 and OMAP4 (panda board). The other attached file (gpio-intr-kqueue.c) is an example program i've been using to check for interrupts from userland. Userland is notified about GPIO interrupts by a kqueue event. The changes have been tested on BBB, RPi and RSPRO. The manual page changes are still to be done (but it will surely be done). Comments ? Regards, Luiz --001a11c335ce38a5b404f96138f2 Content-Type: text/plain; charset=US-ASCII; name="ar71xx_gpio-intr.diff" Content-Disposition: attachment; filename="ar71xx_gpio-intr.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hv6zeusf0 SW5kZXg6IHN5cy9taXBzL2F0aGVyb3MvYXI3MXh4X2dwaW8uYwo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMv bWlwcy9hdGhlcm9zL2FyNzF4eF9ncGlvLmMJKHJldmlzaW9uIDI2NTgxNykKKysrIHN5cy9taXBz L2F0aGVyb3MvYXI3MXh4X2dwaW8uYwkod29ya2luZyBjb3B5KQpAQCAtNDQsNiArNDQsNyBAQAog I2luY2x1ZGUgPHN5cy9tYWxsb2MuaD4KICNpbmNsdWRlIDxzeXMvbXV0ZXguaD4KICNpbmNsdWRl IDxzeXMvZ3Bpby5oPgorI2luY2x1ZGUgPHN5cy9pbnRlcnJ1cHQuaD4KIAogI2luY2x1ZGUgPG1h Y2hpbmUvYnVzLmg+CiAjaW5jbHVkZSA8bWFjaGluZS9yZXNvdXJjZS5oPgpAQCAtNzQsNyArNzUs OCBAQAogc3RhdGljIGludCBhcjcxeHhfZ3Bpb19hdHRhY2goZGV2aWNlX3QgZGV2KTsKIHN0YXRp YyBpbnQgYXI3MXh4X2dwaW9fZGV0YWNoKGRldmljZV90IGRldik7CiBzdGF0aWMgaW50IGFyNzF4 eF9ncGlvX2ZpbHRlcih2b2lkICphcmcpOwotc3RhdGljIHZvaWQgYXI3MXh4X2dwaW9faW50cih2 b2lkICphcmcpOworc3RhdGljIGludCBhcjcxeHhfZ3Bpb19jb25maWdfaW50cihkZXZpY2VfdCBk ZXYsIGludCBpcnEsCisgICAgZW51bSBpbnRyX3RyaWdnZXIgdHJpZywgZW51bSBpbnRyX3BvbGFy aXR5IHBvbCk7CiAKIC8qCiAgKiBHUElPIGludGVyZmFjZQpAQCAtODksNiArOTEsOCBAQAogc3Rh dGljIGludCBhcjcxeHhfZ3Bpb19waW5fZ2V0KGRldmljZV90IGRldiwgdWludDMyX3QgcGluLCB1 bnNpZ25lZCBpbnQgKnZhbCk7CiBzdGF0aWMgaW50IGFyNzF4eF9ncGlvX3Bpbl90b2dnbGUoZGV2 aWNlX3QgZGV2LCB1aW50MzJfdCBwaW4pOwogCitzdGF0aWMgc3RydWN0IGFyNzF4eF9ncGlvX3Nv ZnRjICphcjcxeHhfZ3Bpb19zYyA9IE5VTEw7CisKIHN0YXRpYyB2b2lkCiBhcjcxeHhfZ3Bpb19m dW5jdGlvbl9lbmFibGUoc3RydWN0IGFyNzF4eF9ncGlvX3NvZnRjICpzYywgdWludDMyX3QgbWFz aykKIHsKQEAgLTMyMSwyMCArMzI1LDI1IEBACiBzdGF0aWMgaW50CiBhcjcxeHhfZ3Bpb19maWx0 ZXIodm9pZCAqYXJnKQogeworCWludCBpcnE7CisJc3RydWN0IGFyNzF4eF9ncGlvX3NvZnRjICpz YzsKKwlzdHJ1Y3QgaW50cl9ldmVudCAqZXZlbnQ7CisJdWludDMyX3Qgc3RhdHVzOwogCi0JLyog VE9ETzogc29tZXRoaW5nIHVzZWZ1bCAqLwotCXJldHVybiAoRklMVEVSX1NUUkFZKTsKLX0KKwlz YyA9IChzdHJ1Y3QgYXI3MXh4X2dwaW9fc29mdGMgKilhcmc7CiAKKwlzdGF0dXMgPSBHUElPX1JF QUQoc2MsIEFSNzFYWF9HUElPX0lOVF9QRU5ESU5HKTsKKwlmb3IgKGlycSA9IDA7IGlycSA8PSBz Yy0+Z3Bpb19tYXhwaW47IGlycSsrKSB7CisJCWlmIChzdGF0dXMgJiAoMVUgPDwgaXJxKSkgewor CQkJZXZlbnQgPSBzYy0+Z3Bpb19ldmVudHNbaXJxXTsKKwkJCWlmIChldmVudCAhPSBOVUxMICYm ICFUQUlMUV9FTVBUWSgmZXZlbnQtPmllX2hhbmRsZXJzKSkKKwkJCQlpbnRyX2V2ZW50X2hhbmRs ZShldmVudCwgTlVMTCk7CisJCQllbHNlCisJCQkJZGV2aWNlX3ByaW50ZihzYy0+ZGV2LCAiU3Ry YXkgSVJRICVkXG4iLCBpcnEpOworCQl9CisJfQogCi0KLXN0YXRpYyB2b2lkCi1hcjcxeHhfZ3Bp b19pbnRyKHZvaWQgKmFyZykKLXsKLQlzdHJ1Y3QgYXI3MXh4X2dwaW9fc29mdGMgKnNjID0gYXJn OwotCUdQSU9fTE9DSyhzYyk7Ci0JLyogVE9ETzogc29tZXRoaW5nIHVzZWZ1bCAqLwotCUdQSU9f VU5MT0NLKHNjKTsKKwlyZXR1cm4gKEZJTFRFUl9TVFJBWSk7CiB9CiAKIHN0YXRpYyBpbnQKQEAg LTM0OCw5ICszNTcsOSBAQAogc3RhdGljIGludAogYXI3MXh4X2dwaW9fYXR0YWNoKGRldmljZV90 IGRldikKIHsKLQlzdHJ1Y3QgYXI3MXh4X2dwaW9fc29mdGMgKnNjID0gZGV2aWNlX2dldF9zb2Z0 YyhkZXYpOworCXN0cnVjdCBhcjcxeHhfZ3Bpb19zb2Z0YyAqc2M7CiAJaW50IGVycm9yID0gMDsK LQlpbnQgaSwgaiwgbWF4cGluOworCWludCBpLCBqOwogCWludCBtYXNrLCBwaW5vbjsKIAl1aW50 MzJfdCBvZTsKIApAQCAtMzU3LDggKzM2NiwxMyBAQAogCUtBU1NFUlQoKGRldmljZV9nZXRfdW5p dChkZXYpID09IDApLAogCSAgICAoImFyNzF4eF9ncGlvOiBPbmx5IG9uZSBncGlvIG1vZHVsZSBz dXBwb3J0ZWQiKSk7CiAKLQltdHhfaW5pdCgmc2MtPmdwaW9fbXR4LCBkZXZpY2VfZ2V0X25hbWV1 bml0KGRldiksIE5VTEwsIE1UWF9ERUYpOworCWlmIChhcjcxeHhfZ3Bpb19zYyAhPSBOVUxMKQor CQlyZXR1cm4gKEVOWElPKTsKIAorCWFyNzF4eF9ncGlvX3NjID0gc2MgPSBkZXZpY2VfZ2V0X3Nv ZnRjKGRldik7CisKKwltdHhfaW5pdCgmc2MtPmdwaW9fbXR4LCBkZXZpY2VfZ2V0X25hbWV1bml0 KGRldiksIE5VTEwsIE1UWF9TUElOKTsKKwogCS8qIE1hcCBjb250cm9sL3N0YXR1cyByZWdpc3Rl cnMuICovCiAJc2MtPmdwaW9fbWVtX3JpZCA9IDA7CiAJc2MtPmdwaW9fbWVtX3JlcyA9IGJ1c19h bGxvY19yZXNvdXJjZV9hbnkoZGV2LCBTWVNfUkVTX01FTU9SWSwKQEAgLTM3OCw3ICszOTIsNyBA QAogCX0KIAogCWlmICgoYnVzX3NldHVwX2ludHIoZGV2LCBzYy0+Z3Bpb19pcnFfcmVzLCBJTlRS X1RZUEVfTUlTQywgCi0JICAgIGFyNzF4eF9ncGlvX2ZpbHRlciwgYXI3MXh4X2dwaW9faW50ciwg c2MsICZzYy0+Z3Bpb19paCkpKSB7CisJICAgIGFyNzF4eF9ncGlvX2ZpbHRlciwgTlVMTCwgc2Ms ICZzYy0+Z3Bpb19paCkpKSB7CiAJCWRldmljZV9wcmludGYoZGV2LAogCQkgICAgIldBUk5JTkc6 IHVuYWJsZSB0byByZWdpc3RlciBpbnRlcnJ1cHQgaGFuZGxlclxuIik7CiAJCXJldHVybiAoRU5Y SU8pOwpAQCAtNDAwLDEwICs0MTQsMjYgQEAKIAl9CiAKIAkvKiBEaXNhYmxlIGludGVycnVwdHMg Zm9yIGFsbCBwaW5zLiAqLworCUdQSU9fV1JJVEUoc2MsIEFSNzFYWF9HUElPX0lOVCwgMCk7CiAJ R1BJT19XUklURShzYywgQVI3MVhYX0dQSU9fSU5UX01BU0ssIDApOwogCisJLyogSW5pdGlhbGl6 ZSB0aGUgaW50ZXJydXB0IGV2ZW50IGRhdGEuICovCisJKHZvaWQpIGFyNzF4eF9ncGlvX3Bpbl9t YXgoZGV2LCAmc2MtPmdwaW9fbWF4cGluKTsKKwlzYy0+Z3Bpb19ldmVudHMgPSBtYWxsb2Moc2l6 ZW9mKHN0cnVjdCBpbnRyX2V2ZW50ICopICogc2MtPmdwaW9fbWF4cGluLAorCSAgICBNX0RFVkJV RiwgTV9XQUlUT0sgfCBNX1pFUk8pOworCXNjLT5ncGlvX2lycV90cmlnZ2VyID0gbWFsbG9jKHNp emVvZihlbnVtIGludHJfdHJpZ2dlcikgKgorCSAgICBzYy0+Z3Bpb19tYXhwaW4sIE1fREVWQlVG LCBNX1dBSVRPSyB8IE1fWkVSTyk7CisJc2MtPmdwaW9faXJxX3BvbGFyaXR5ID0gbWFsbG9jKHNp emVvZihlbnVtIGludHJfcG9sYXJpdHkpICoKKwkgICAgc2MtPmdwaW9fbWF4cGluLCBNX0RFVkJV RiwgTV9XQUlUT0sgfCBNX1pFUk8pOworCS8qIFRoZSBkZWZhdWx0IGlzIGFjdGl2ZS1sb3cgaW50 ZXJydXB0cy4gKi8KKwlmb3IgKGkgPSAwOyBpIDw9IHNjLT5ncGlvX21heHBpbjsgaSsrKSB7CisJ CXNjLT5ncGlvX2lycV90cmlnZ2VyW2ldID0gSU5UUl9UUklHR0VSX0xFVkVMOworCQlzYy0+Z3Bp b19pcnFfcG9sYXJpdHlbaV0gPSBJTlRSX1BPTEFSSVRZX0xPVzsKKwkJYXI3MXh4X2dwaW9fY29u ZmlnX2ludHIoZGV2LCBpLCBzYy0+Z3Bpb19pcnFfdHJpZ2dlcltpXSwKKwkJICAgIHNjLT5ncGlv X2lycV9wb2xhcml0eVtpXSk7CisJfQorCiAJLyogSW5pdGlhbGlzZSBhbGwgcGlucyBzcGVjaWZp ZWQgaW4gdGhlIG1hc2ssIHVwIHRvIHRoZSBwaW4gY291bnQgKi8KLQkodm9pZCkgYXI3MXh4X2dw aW9fcGluX21heChkZXYsICZtYXhwaW4pOwogCWlmIChyZXNvdXJjZV9pbnRfdmFsdWUoZGV2aWNl X2dldF9uYW1lKGRldiksIGRldmljZV9nZXRfdW5pdChkZXYpLAogCSAgICAicGlubWFzayIsICZt YXNrKSAhPSAwKQogCQltYXNrID0gMDsKQEAgLTQxMSw3ICs0NDEsNyBAQAogCSAgICAicGlub24i LCAmcGlub24pICE9IDApCiAJCXBpbm9uID0gMDsKIAlkZXZpY2VfcHJpbnRmKGRldiwgImdwaW8g cGlubWFzaz0weCV4XG4iLCBtYXNrKTsKLQlmb3IgKGogPSAwOyBqIDw9IG1heHBpbjsgaisrKSB7 CisJZm9yIChqID0gMDsgaiA8PSBzYy0+Z3Bpb19tYXhwaW47IGorKykgewogCQlpZiAoKG1hc2sg JiAoMSA8PCBqKSkgPT0gMCkKIAkJCWNvbnRpbnVlOwogCQlzYy0+Z3Bpb19ucGlucysrOwpAQCAt NDIwLDcgKzQ1MCw3IEBACiAJb2UgPSBHUElPX1JFQUQoc2MsIEFSNzFYWF9HUElPX09FKTsKIAlz Yy0+Z3Bpb19waW5zID0gbWFsbG9jKHNpemVvZigqc2MtPmdwaW9fcGlucykgKiBzYy0+Z3Bpb19u cGlucywKIAkgICAgTV9ERVZCVUYsIE1fV0FJVE9LIHwgTV9aRVJPKTsKLQlmb3IgKGkgPSAwLCBq ID0gMDsgaiA8PSBtYXhwaW47IGorKykgeworCWZvciAoaSA9IDAsIGogPSAwOyBqIDw9IHNjLT5n cGlvX21heHBpbjsgaisrKSB7CiAJCWlmICgobWFzayAmICgxIDw8IGopKSA9PSAwKQogCQkJY29u dGludWU7CiAJCXNucHJpbnRmKHNjLT5ncGlvX3BpbnNbaV0uZ3BfbmFtZSwgR1BJT01BWE5BTUUs CkBAIC00NTksMTIgKzQ4OSwyMDQgQEAKIAkJYnVzX3JlbGVhc2VfcmVzb3VyY2UoZGV2LCBTWVNf UkVTX01FTU9SWSwgc2MtPmdwaW9fbWVtX3JpZCwKIAkJICAgIHNjLT5ncGlvX21lbV9yZXMpOwog Ci0JZnJlZShzYy0+Z3Bpb19waW5zLCBNX0RFVkJVRik7CisJaWYgKHNjLT5ncGlvX2lycV9wb2xh cml0eSAhPSBOVUxMKSB7CisJCWZyZWUoc2MtPmdwaW9faXJxX3BvbGFyaXR5LCBNX0RFVkJVRik7 CisJCXNjLT5ncGlvX2lycV9wb2xhcml0eSA9IE5VTEw7CisJfQorCWlmIChzYy0+Z3Bpb19pcnFf dHJpZ2dlciAhPSBOVUxMKSB7CisJCWZyZWUoc2MtPmdwaW9faXJxX3RyaWdnZXIsIE1fREVWQlVG KTsKKwkJc2MtPmdwaW9faXJxX3RyaWdnZXIgPSBOVUxMOworCX0KKwlpZiAoc2MtPmdwaW9fZXZl bnRzICE9IE5VTEwpIHsKKwkJZnJlZShzYy0+Z3Bpb19ldmVudHMsIE1fREVWQlVGKTsKKwkJc2Mt PmdwaW9fZXZlbnRzID0gTlVMTDsKKwl9CisJaWYgKHNjLT5ncGlvX3BpbnMgIT0gTlVMTCkgewor CQlmcmVlKHNjLT5ncGlvX3BpbnMsIE1fREVWQlVGKTsKKwkJc2MtPmdwaW9fcGlucyA9IE5VTEw7 CisJfQogCW10eF9kZXN0cm95KCZzYy0+Z3Bpb19tdHgpOwogCiAJcmV0dXJuKDApOwogfQogCitz dGF0aWMgdm9pZAorYXI3MXh4X2dwaW9fbWFza19pcnEodm9pZCAqc291cmNlKQoreyAgICAgICAK KwlpbnQgaXJxOworCXVpbnQzMl90IG1hc2s7CisKKwlpcnEgPSAoaW50KXNvdXJjZTsKKwlpZiAo aXJxID4gYXI3MXh4X2dwaW9fc2MtPmdwaW9fbWF4cGluKQorCQlyZXR1cm47CisKKwltYXNrID0g MVUgPDwgaXJxOworCUdQSU9fTE9DSyhhcjcxeHhfZ3Bpb19zYyk7CisJR1BJT19DTEVBUl9CSVRT KGFyNzF4eF9ncGlvX3NjLCBBUjcxWFhfR1BJT19JTlRfTUFTSywgbWFzayk7CisJR1BJT19VTkxP Q0soYXI3MXh4X2dwaW9fc2MpOworfQorCitzdGF0aWMgdm9pZAorYXI3MXh4X2dwaW9fdW5tYXNr X2lycSh2b2lkICpzb3VyY2UpCit7CisJaW50IGlycTsKKwl1aW50MzJfdCBtYXNrOworCisJaXJx ID0gKGludClzb3VyY2U7CisJaWYgKGlycSA+IGFyNzF4eF9ncGlvX3NjLT5ncGlvX21heHBpbikK KwkJcmV0dXJuOworCisJbWFzayA9IDFVIDw8IGlycTsKKwlHUElPX0xPQ0soYXI3MXh4X2dwaW9f c2MpOworCUdQSU9fU0VUX0JJVFMoYXI3MXh4X2dwaW9fc2MsIEFSNzFYWF9HUElPX0lOVF9NQVNL LCBtYXNrKTsKKwlHUElPX1VOTE9DSyhhcjcxeHhfZ3Bpb19zYyk7Cit9CisKK3N0YXRpYyBpbnQK K2FyNzF4eF9ncGlvX2FjdGl2YXRlX3Jlc291cmNlKGRldmljZV90IGRldiwgZGV2aWNlX3QgY2hp bGQsIGludCB0eXBlLCBpbnQgcmlkLAorCXN0cnVjdCByZXNvdXJjZSAqcmVzKQoreworCWludCBw aW47CisJc3RydWN0IGFyNzF4eF9ncGlvX3NvZnRjICpzYzsKKworCWlmICh0eXBlICE9IFNZU19S RVNfSVJRKQorCQlyZXR1cm4gKEVOWElPKTsKKworCXNjID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYp OworCisJLyogRW5hYmxlIHRoZSBpbnRlcnJ1cHQgZm9yIHRoaXMgcGluLiAqLworCXBpbiA9IHJt YW5fZ2V0X3N0YXJ0KHJlcyk7CisJR1BJT19MT0NLKGFyNzF4eF9ncGlvX3NjKTsKKwlHUElPX1NF VF9CSVRTKGFyNzF4eF9ncGlvX3NjLCBBUjcxWFhfR1BJT19JTlQsICgxVSA8PCBwaW4pKTsKKwlH UElPX1VOTE9DSyhhcjcxeHhfZ3Bpb19zYyk7CisKKwkvKiBVbm1hc2sgdGhlIGludGVycnVwdC4g Ki8KKwlhcjcxeHhfZ3Bpb191bm1hc2tfaXJxKCh2b2lkICopKHVpbnRwdHJfdClwaW4pOworCisJ cmV0dXJuICgwKTsKK30KKworc3RhdGljIGludAorYXI3MXh4X2dwaW9fZGVhY3RpdmF0ZV9yZXNv dXJjZShkZXZpY2VfdCBkZXYsIGRldmljZV90IGNoaWxkLCBpbnQgdHlwZSwgaW50IHJpZCwKKwlz dHJ1Y3QgcmVzb3VyY2UgKnJlcykKK3sKKwlpbnQgcGluOworCXN0cnVjdCBhcjcxeHhfZ3Bpb19z b2Z0YyAqc2M7CisKKwlpZiAodHlwZSAhPSBTWVNfUkVTX0lSUSkKKwkJcmV0dXJuIChFTlhJTyk7 CisKKwlzYyA9IGRldmljZV9nZXRfc29mdGMoZGV2KTsKKworCS8qIE1hc2sgdGhlIGludGVycnVw dC4gKi8KKwlwaW4gPSBybWFuX2dldF9zdGFydChyZXMpOworCWFyNzF4eF9ncGlvX21hc2tfaXJx KCh2b2lkICopKHVpbnRwdHJfdClwaW4pOworCisJLyogRGlzYWJsZSB0aGUgaW50ZXJydXB0IGZv ciB0aGlzIHBpbi4gKi8KKwlHUElPX0xPQ0soYXI3MXh4X2dwaW9fc2MpOworCUdQSU9fQ0xFQVJf QklUUyhhcjcxeHhfZ3Bpb19zYywgQVI3MVhYX0dQSU9fSU5ULCAoMVUgPDwgcGluKSk7CisJR1BJ T19VTkxPQ0soYXI3MXh4X2dwaW9fc2MpOworCisJcmV0dXJuICgwKTsKK30KKworc3RhdGljIGlu dAorYXI3MXh4X2dwaW9fY29uZmlnX2ludHIoZGV2aWNlX3QgZGV2LCBpbnQgaXJxLCBlbnVtIGlu dHJfdHJpZ2dlciB0cmlnLAorCWVudW0gaW50cl9wb2xhcml0eSBwb2wpCit7CisJc3RydWN0IGFy NzF4eF9ncGlvX3NvZnRjICpzYzsKKwl1aW50MzJfdCBtYXNrLCByZWc7CisKKwlzYyA9IGRldmlj ZV9nZXRfc29mdGMoZGV2KTsKKwlpZiAoaXJxID4gc2MtPmdwaW9fbWF4cGluKQorCQlyZXR1cm4g KEVJTlZBTCk7CisKKwkvKiBUaGVyZSBpcyBubyBzdGFuZGFyZCB0cmlnZ2VyIG9yIHBvbGFyaXR5 LiAqLworCWlmICh0cmlnID09IElOVFJfVFJJR0dFUl9DT05GT1JNIHx8IHBvbCA9PSBJTlRSX1BP TEFSSVRZX0NPTkZPUk0pCisJCXJldHVybiAoRUlOVkFMKTsKKworCW1hc2sgPSAxVUwgPDwgaXJx OworCisJR1BJT19MT0NLKHNjKTsKKworCS8qIFNldCB0aGUgYXBwcm9wcmlhdGUgaW50ZXJydXB0 IHR5cGUuICovCisJcmVnID0gR1BJT19SRUFEKHNjLCBBUjcxWFhfR1BJT19JTlRfVFlQRSk7CisJ cmVnICY9IH5tYXNrOworCWlmICh0cmlnID09IElOVFJfVFJJR0dFUl9MRVZFTCkKKwkJcmVnIHw9 IG1hc2s7CisJR1BJT19XUklURShzYywgQVI3MVhYX0dQSU9fSU5UX1RZUEUsIHJlZyk7CisKKwkv KiBTZXQgdGhlIGFwcHJvcHJpYXRlIGludGVycnVwdCBwb2xhcml0eS4gKi8KKwlyZWcgPSBHUElP X1JFQUQoc2MsIEFSNzFYWF9HUElPX0lOVF9QT0xBUklUWSk7CisJcmVnICY9IH5tYXNrOworCWlm IChwb2wgPT0gSU5UUl9QT0xBUklUWV9ISUdIKQorCQlyZWcgfD0gbWFzazsKKwlHUElPX1dSSVRF KHNjLCBBUjcxWFhfR1BJT19JTlRfUE9MQVJJVFksIHJlZyk7CisKKwlzYy0+Z3Bpb19pcnFfdHJp Z2dlcltpcnFdID0gdHJpZzsKKwlzYy0+Z3Bpb19pcnFfcG9sYXJpdHlbaXJxXSA9IHBvbDsKKwor CUdQSU9fVU5MT0NLKHNjKTsKKworCXJldHVybiAoMCk7Cit9CisKK3N0YXRpYyBpbnQKK2FyNzF4 eF9ncGlvX3NldHVwX2ludHIoZGV2aWNlX3QgZGV2LCBkZXZpY2VfdCBjaGlsZCwgc3RydWN0IHJl c291cmNlICppcmVzLAorCWludCBmbGFncywgZHJpdmVyX2ZpbHRlcl90ICpmaWx0LCBkcml2ZXJf aW50cl90ICpoYW5kbGVyLAorCXZvaWQgKmFyZywgdm9pZCAqKmNvb2tpZXApCit7CisJc3RydWN0 IGFyNzF4eF9ncGlvX3NvZnRjICpzYzsKKwlzdHJ1Y3QgaW50cl9ldmVudCAqZXZlbnQ7CisJaW50 IHBpbiwgZXJyb3I7CisKKwlzYyA9IGRldmljZV9nZXRfc29mdGMoZGV2KTsKKwlwaW4gPSBybWFu X2dldF9zdGFydChpcmVzKTsKKworCWlmIChwaW4gPiBzYy0+Z3Bpb19tYXhwaW4pCisJCXBhbmlj KCIlczogYmFkIHBpbiAlZCIsIF9fZnVuY19fLCBwaW4pOworCisJZXZlbnQgPSBzYy0+Z3Bpb19l dmVudHNbcGluXTsKKwlpZiAoZXZlbnQgPT0gTlVMTCkgeworCQllcnJvciA9IGludHJfZXZlbnRf Y3JlYXRlKCZldmVudCwgKHZvaWQgKikodWludHB0cl90KXBpbiwgMCwKKwkJICAgIHBpbiwgYXI3 MXh4X2dwaW9fbWFza19pcnEsIGFyNzF4eF9ncGlvX3VubWFza19pcnEsCisJCSAgICBOVUxMLCBO VUxMLCAiZ3BpbyVkIHBpbiVkOiIsIGRldmljZV9nZXRfdW5pdChkZXYpLCBwaW4pOworCisJCWlm IChlcnJvciAhPSAwKQorCQkJcmV0dXJuIChlcnJvcik7CisKKwkJc2MtPmdwaW9fZXZlbnRzW3Bp bl0gPSBldmVudDsKKwl9CisKKwlpbnRyX2V2ZW50X2FkZF9oYW5kbGVyKGV2ZW50LCBkZXZpY2Vf Z2V0X25hbWV1bml0KGNoaWxkKSwgZmlsdCwKKwkgICAgaGFuZGxlciwgYXJnLCBpbnRyX3ByaW9y aXR5KGZsYWdzKSwgZmxhZ3MsIGNvb2tpZXApOworCisJcmV0dXJuICgwKTsKK30KKworc3RhdGlj IGludAorYXI3MXh4X2dwaW9fdGVhcmRvd25faW50cihkZXZpY2VfdCBkZXYsIGRldmljZV90IGNo aWxkLCBzdHJ1Y3QgcmVzb3VyY2UgKmlyZXMsCisJdm9pZCAqY29va2llKQoreworCXN0cnVjdCBh cjcxeHhfZ3Bpb19zb2Z0YyAqc2M7CisJaW50IHBpbiwgZXJyOworCisJc2MgPSBkZXZpY2VfZ2V0 X3NvZnRjKGRldik7CisJcGluID0gcm1hbl9nZXRfc3RhcnQoaXJlcyk7CisKKwlpZiAocGluID4g c2MtPmdwaW9fbWF4cGluKQorCQlwYW5pYygiJXM6IGJhZCBwaW4gJWQiLCBfX2Z1bmNfXywgcGlu KTsKKworCWlmIChzYy0+Z3Bpb19ldmVudHNbcGluXSA9PSBOVUxMKQorCQlwYW5pYygiVHJ5aW5n IHRvIHRlYXJkb3duIHVub2NjdXBpZWQgSVJRIik7CisKKwllcnIgPSBpbnRyX2V2ZW50X3JlbW92 ZV9oYW5kbGVyKGNvb2tpZSk7CisJaWYgKCFlcnIpCisJCXNjLT5ncGlvX2V2ZW50c1twaW5dID0g TlVMTDsKKworCXJldHVybiAoZXJyKTsKK30KKwogc3RhdGljIGRldmljZV9tZXRob2RfdCBhcjcx eHhfZ3Bpb19tZXRob2RzW10gPSB7CiAJREVWTUVUSE9EKGRldmljZV9wcm9iZSwgYXI3MXh4X2dw aW9fcHJvYmUpLAogCURFVk1FVEhPRChkZXZpY2VfYXR0YWNoLCBhcjcxeHhfZ3Bpb19hdHRhY2gp LApAQCAtNDc5LDcgKzcwMSwxNSBAQAogCURFVk1FVEhPRChncGlvX3Bpbl9nZXQsIGFyNzF4eF9n cGlvX3Bpbl9nZXQpLAogCURFVk1FVEhPRChncGlvX3Bpbl9zZXQsIGFyNzF4eF9ncGlvX3Bpbl9z ZXQpLAogCURFVk1FVEhPRChncGlvX3Bpbl90b2dnbGUsIGFyNzF4eF9ncGlvX3Bpbl90b2dnbGUp LAotCXswLCAwfSwKKworCS8qIEJ1cyBpbnRlcmZhY2UgKi8KKwlERVZNRVRIT0QoYnVzX2FjdGl2 YXRlX3Jlc291cmNlLCBhcjcxeHhfZ3Bpb19hY3RpdmF0ZV9yZXNvdXJjZSksCisJREVWTUVUSE9E KGJ1c19kZWFjdGl2YXRlX3Jlc291cmNlLCBhcjcxeHhfZ3Bpb19kZWFjdGl2YXRlX3Jlc291cmNl KSwKKwlERVZNRVRIT0QoYnVzX2NvbmZpZ19pbnRyLCBhcjcxeHhfZ3Bpb19jb25maWdfaW50ciks CisJREVWTUVUSE9EKGJ1c19zZXR1cF9pbnRyLCBhcjcxeHhfZ3Bpb19zZXR1cF9pbnRyKSwKKwlE RVZNRVRIT0QoYnVzX3RlYXJkb3duX2ludHIsIGFyNzF4eF9ncGlvX3RlYXJkb3duX2ludHIpLAor CisJREVWTUVUSE9EX0VORAogfTsKIAogc3RhdGljIGRyaXZlcl90IGFyNzF4eF9ncGlvX2RyaXZl ciA9IHsKSW5kZXg6IHN5cy9taXBzL2F0aGVyb3MvYXI3MXh4X2dwaW92YXIuaAo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 Ci0tLSBzeXMvbWlwcy9hdGhlcm9zL2FyNzF4eF9ncGlvdmFyLmgJKHJldmlzaW9uIDI2NTgxNykK KysrIHN5cy9taXBzL2F0aGVyb3MvYXI3MXh4X2dwaW92YXIuaAkod29ya2luZyBjb3B5KQpAQCAt MzIsOCArMzIsOCBAQAogI2lmbmRlZiBfX0FSNzFYWF9HUElPVkFSX0hfXwogI2RlZmluZSBfX0FS NzFYWF9HUElPVkFSX0hfXwogCi0jZGVmaW5lIEdQSU9fTE9DSyhfc2MpCQltdHhfbG9jaygmKF9z YyktPmdwaW9fbXR4KQotI2RlZmluZSBHUElPX1VOTE9DSyhfc2MpCW10eF91bmxvY2soJihfc2Mp LT5ncGlvX210eCkKKyNkZWZpbmUgR1BJT19MT0NLKF9zYykJCW10eF9sb2NrX3NwaW4oJihfc2Mp LT5ncGlvX210eCkKKyNkZWZpbmUgR1BJT19VTkxPQ0soX3NjKQltdHhfdW5sb2NrX3NwaW4oJihf c2MpLT5ncGlvX210eCkKICNkZWZpbmUgR1BJT19MT0NLX0FTU0VSVChfc2MpCW10eF9hc3NlcnQo Jihfc2MpLT5ncGlvX210eCwgTUFfT1dORUQpCiAKIC8qCkBAIC02NSw2ICs2NSwxMCBAQAogICAg ICAgICB2b2lkCQkJKmdwaW9faWg7CiAJaW50CQkJZ3Bpb19ucGluczsKIAlzdHJ1Y3QgZ3Bpb19w aW4JCSpncGlvX3BpbnM7CisJaW50CQkJZ3Bpb19tYXhwaW47CisJc3RydWN0IGludHJfZXZlbnQJ KipncGlvX2V2ZW50czsKKwllbnVtIGludHJfdHJpZ2dlcgkqZ3Bpb19pcnFfdHJpZ2dlcjsKKwll bnVtIGludHJfcG9sYXJpdHkJKmdwaW9faXJxX3BvbGFyaXR5OwogfTsKIAogI2VuZGlmCS8qIF9f QVI3MVhYX0dQSU9WQVJfSF9fICovCg== --001a11c335ce38a5b404f96138f2 Content-Type: text/plain; charset=US-ASCII; name="bcm2835_gpio-intr.diff" Content-Disposition: attachment; filename="bcm2835_gpio-intr.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hv6zeuta1 SW5kZXg6IHN5cy9hcm0vYnJvYWRjb20vYmNtMjgzNS9iY20yODM1X2dwaW8uYwo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 Ci0tLSBzeXMvYXJtL2Jyb2FkY29tL2JjbTI4MzUvYmNtMjgzNV9ncGlvLmMJKHJldmlzaW9uIDI2 NTg0MikKKysrIHN5cy9hcm0vYnJvYWRjb20vYmNtMjgzNS9iY20yODM1X2dwaW8uYwkod29ya2lu ZyBjb3B5KQpAQCAtMzksNiArMzksNyBAQAogI2luY2x1ZGUgPHN5cy9tdXRleC5oPgogI2luY2x1 ZGUgPHN5cy9ncGlvLmg+CiAjaW5jbHVkZSA8c3lzL3N5c2N0bC5oPgorI2luY2x1ZGUgPHN5cy9p bnRlcnJ1cHQuaD4KIAogI2luY2x1ZGUgPG1hY2hpbmUvYnVzLmg+CiAjaW5jbHVkZSA8bWFjaGlu ZS9jcHUuaD4KQEAgLTYyLDEwICs2MywyMCBAQAogI2RlZmluZSBkcHJpbnRmKGZtdCwgYXJncy4u LikKICNlbmRpZgogCisjZGVmaW5lCUJDTV9HUElPX0lSUVMJCTQKICNkZWZpbmUJQkNNX0dQSU9f UElOUwkJNTQKKyNkZWZpbmUJQkNNX0dQSU9fUElOU19QRVJfQkFOSwkzMgogI2RlZmluZQlCQ01f R1BJT19ERUZBVUxUX0NBUFMJKEdQSU9fUElOX0lOUFVUIHwgR1BJT19QSU5fT1VUUFVUIHwJXAog ICAgIEdQSU9fUElOX1BVTExVUCB8IEdQSU9fUElOX1BVTExET1dOKQogCitzdGF0aWMgc3RydWN0 IHJlc291cmNlX3NwZWMgYmNtX2dwaW9faXJxX3NwZWNbXSA9IHsKKwl7IFNZU19SRVNfSVJRLAkw LAlSRl9BQ1RJVkUgfSwKKwl7IFNZU19SRVNfSVJRLAkxLAlSRl9BQ1RJVkUgfSwKKwl7IFNZU19S RVNfSVJRLAkyLAlSRl9BQ1RJVkUgfSwKKwl7IFNZU19SRVNfSVJRLAkzLAlSRl9BQ1RJVkUgfSwK Kwl7IC0xLAkJMCwJMCB9Cit9OworCiBzdHJ1Y3QgYmNtX2dwaW9fc3lzY3RsIHsKIAlzdHJ1Y3Qg YmNtX2dwaW9fc29mdGMJKnNjOwogCXVpbnQzMl90CQlwaW47CkBAIC03NSwxNSArODYsMTggQEAK IAlkZXZpY2VfdAkJc2NfZGV2OwogCXN0cnVjdCBtdHgJCXNjX210eDsKIAlzdHJ1Y3QgcmVzb3Vy Y2UgKglzY19tZW1fcmVzOwotCXN0cnVjdCByZXNvdXJjZSAqCXNjX2lycV9yZXM7CisJc3RydWN0 IHJlc291cmNlICoJc2NfaXJxX3Jlc1tCQ01fR1BJT19JUlFTXTsKIAlidXNfc3BhY2VfdGFnX3QJ CXNjX2JzdDsKIAlidXNfc3BhY2VfaGFuZGxlX3QJc2NfYnNoOwotCXZvaWQgKgkJCXNjX2ludHJo YW5kOworCXZvaWQgKgkJCXNjX2ludHJoYW5kW0JDTV9HUElPX0lSUVNdOwogCWludAkJCXNjX2dw aW9fbnBpbnM7CiAJaW50CQkJc2Nfcm9fbnBpbnM7CiAJaW50CQkJc2Nfcm9fcGluc1tCQ01fR1BJ T19QSU5TXTsKIAlzdHJ1Y3QgZ3Bpb19waW4JCXNjX2dwaW9fcGluc1tCQ01fR1BJT19QSU5TXTsK KwlzdHJ1Y3QgaW50cl9ldmVudCAqCXNjX2V2ZW50c1tCQ01fR1BJT19QSU5TXTsKIAlzdHJ1Y3Qg YmNtX2dwaW9fc3lzY3RsCXNjX3N5c2N0bFtCQ01fR1BJT19QSU5TXTsKKwllbnVtIGludHJfdHJp Z2dlcglzY19pcnFfdHJpZ2dlcltCQ01fR1BJT19QSU5TXTsKKwllbnVtIGludHJfcG9sYXJpdHkJ c2NfaXJxX3BvbGFyaXR5W0JDTV9HUElPX1BJTlNdOwogfTsKIAogZW51bSBiY21fZ3Bpb19wdWQg ewpAQCAtOTYsMTggKzExMCwzMyBAQAogI2RlZmluZQlCQ01fR1BJT19VTkxPQ0soX3NjKQltdHhf dW5sb2NrKCZfc2MtPnNjX210eCkKICNkZWZpbmUJQkNNX0dQSU9fTE9DS19BU1NFUlQoX3NjKQlt dHhfYXNzZXJ0KCZfc2MtPnNjX210eCwgTUFfT1dORUQpCiAKLSNkZWZpbmUJQkNNX0dQSU9fR1BG U0VMKF9iYW5rKQkweDAwICsgX2JhbmsgKiA0Ci0jZGVmaW5lCUJDTV9HUElPX0dQU0VUKF9iYW5r KQkweDFjICsgX2JhbmsgKiA0Ci0jZGVmaW5lCUJDTV9HUElPX0dQQ0xSKF9iYW5rKQkweDI4ICsg X2JhbmsgKiA0Ci0jZGVmaW5lCUJDTV9HUElPX0dQTEVWKF9iYW5rKQkweDM0ICsgX2JhbmsgKiA0 Ci0jZGVmaW5lCUJDTV9HUElPX0dQUFVEKF9iYW5rKQkweDk0Ci0jZGVmaW5lCUJDTV9HUElPX0dQ UFVEQ0xLKF9iYW5rKQkweDk4ICsgX2JhbmsgKiA0CisjZGVmaW5lCUJDTV9HUElPX0dQRlNFTChf YmFuaykJKDB4MDAgKyBfYmFuayAqIDQpCS8qIEZ1bmN0aW9uIFNlbGVjdCAqLworI2RlZmluZQlC Q01fR1BJT19HUFNFVChfYmFuaykJKDB4MWMgKyBfYmFuayAqIDQpCS8qIFBpbiBPdXQgU2V0ICov CisjZGVmaW5lCUJDTV9HUElPX0dQQ0xSKF9iYW5rKQkoMHgyOCArIF9iYW5rICogNCkJLyogUGlu IE91dCBDbGVhciAqLworI2RlZmluZQlCQ01fR1BJT19HUExFVihfYmFuaykJKDB4MzQgKyBfYmFu ayAqIDQpCS8qIFBpbiBMZXZlbCAqLworI2RlZmluZQlCQ01fR1BJT19HUEVEUyhfYmFuaykJKDB4 NDAgKyBfYmFuayAqIDQpCS8qIEV2ZW50IFN0YXR1cyAqLworI2RlZmluZQlCQ01fR1BJT19HUFJF TihfYmFuaykJKDB4NGMgKyBfYmFuayAqIDQpCS8qIFJpc2luZyBFZGdlIGlzciAqLworI2RlZmlu ZQlCQ01fR1BJT19HUEZFTihfYmFuaykJKDB4NTggKyBfYmFuayAqIDQpCS8qIEZhbGxpbmcgRWRn ZSBpc3IgKi8KKyNkZWZpbmUJQkNNX0dQSU9fR1BIRU4oX2JhbmspCSgweDY0ICsgX2JhbmsgKiA0 KQkvKiBIaWdoIExldmVsIGlzciAqLworI2RlZmluZQlCQ01fR1BJT19HUExFTihfYmFuaykJKDB4 NzAgKyBfYmFuayAqIDQpCS8qIExvdyBMZXZlbCBpc3IgKi8KKyNkZWZpbmUJQkNNX0dQSU9fR1BB UkVOKF9iYW5rKQkoMHg3YyArIF9iYW5rICogNCkJLyogQXN5bmMgUmlzaW5nIEVkZ2UgKi8KKyNk ZWZpbmUJQkNNX0dQSU9fR1BBRkVOKF9iYW5rKQkoMHg4OCArIF9iYW5rICogNCkJLyogQXN5bmMg RmFsbGluZyBFZ2RlICovCisjZGVmaW5lCUJDTV9HUElPX0dQUFVEKF9iYW5rKQkoMHg5NCkJCQkv KiBQaW4gUHVsbCB1cC9kb3duICovCisjZGVmaW5lCUJDTV9HUElPX0dQUFVEQ0xLKF9iYW5rKSAo MHg5OCArIF9iYW5rICogNCkJLyogUGluIFB1bGwgdXAgY2xvY2sgKi8KIAogI2RlZmluZQlCQ01f R1BJT19XUklURShfc2MsIF9vZmYsIF92YWwpCQlcCiAgICAgYnVzX3NwYWNlX3dyaXRlXzQoX3Nj LT5zY19ic3QsIF9zYy0+c2NfYnNoLCBfb2ZmLCBfdmFsKQogI2RlZmluZQlCQ01fR1BJT19SRUFE KF9zYywgX29mZikJCVwKICAgICBidXNfc3BhY2VfcmVhZF80KF9zYy0+c2NfYnN0LCBfc2MtPnNj X2JzaCwgX29mZikKKyNkZWZpbmUJQkNNX0dQSU9fQ0xFQVJfQklUUyhfc2MsIF9vZmYsIF9iaXRz KQlcCisgICAgQkNNX0dQSU9fV1JJVEUoX3NjLCBfb2ZmLCBCQ01fR1BJT19SRUFEKF9zYywgX29m ZikgJiB+KF9iaXRzKSk7CisjZGVmaW5lCUJDTV9HUElPX1NFVF9CSVRTKF9zYywgX29mZiwgX2Jp dHMpCVwKKyAgICBCQ01fR1BJT19XUklURShfc2MsIF9vZmYsIEJDTV9HUElPX1JFQUQoX3NjLCBf b2ZmKSB8IF9iaXRzKTsKIAorc3RhdGljIHN0cnVjdCBiY21fZ3Bpb19zb2Z0YyAqYmNtX2dwaW9f c2MgPSBOVUxMOworCitzdGF0aWMgaW50IGJjbV9ncGlvX2ludHIodm9pZCAqKTsKKwogc3RhdGlj IGludAogYmNtX2dwaW9fcGluX2lzX3JvKHN0cnVjdCBiY21fZ3Bpb19zb2Z0YyAqc2MsIGludCBw aW4pCiB7CkBAIC02ODYsMTUgKzcxNSw1MCBAQAogfQogCiBzdGF0aWMgaW50CitiY21fZ3Bpb19p bnRyX2F0dGFjaChkZXZpY2VfdCBkZXYpCit7CisJc3RydWN0IGJjbV9ncGlvX3NvZnRjICpzYzsK KwlpbnQgaTsKKworCXNjID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOworCWZvciAoaSA9IDA7IGkg PCBCQ01fR1BJT19JUlFTOyBpKyspIHsKKwkJaWYgKGJ1c19zZXR1cF9pbnRyKGRldiwgc2MtPnNj X2lycV9yZXNbaV0sIElOVFJfVFlQRV9NSVNDLAorCQkgICAgYmNtX2dwaW9faW50ciwgTlVMTCwg c2MsICZzYy0+c2NfaW50cmhhbmRbaV0pICE9IDApIHsKKwkJCXJldHVybiAoLTEpOworCQl9CisJ fQorCisJcmV0dXJuICgwKTsKK30KKworc3RhdGljIHZvaWQKK2JjbV9ncGlvX2ludHJfZGV0YWNo KGRldmljZV90IGRldikKK3sKKwlzdHJ1Y3QgYmNtX2dwaW9fc29mdGMgKnNjOworCWludCBpOwor CisJc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisJZm9yIChpID0gMDsgaSA8IEJDTV9HUElP X0lSUVM7IGkrKykgeworCQlpZiAoc2MtPnNjX2ludHJoYW5kW2ldKSB7CisJCQlidXNfdGVhcmRv d25faW50cihkZXYsIHNjLT5zY19pcnFfcmVzW2ldLAorCQkgICAgc2MtPnNjX2ludHJoYW5kW2ld KTsKKwkJfQorCX0KK30KKworc3RhdGljIGludAogYmNtX2dwaW9fYXR0YWNoKGRldmljZV90IGRl dikKIHsKLQlzdHJ1Y3QgYmNtX2dwaW9fc29mdGMgKnNjID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYp OworCXN0cnVjdCBiY21fZ3Bpb19zb2Z0YyAqc2M7CiAJdWludDMyX3QgZnVuYzsKIAlpbnQgaSwg aiwgcmlkOwogCXBoYW5kbGVfdCBncGlvOwogCi0Jc2MtPnNjX2RldiA9IGRldjsKKwlpZiAoYmNt X2dwaW9fc2MgIT0gTlVMTCkKKwkJcmV0dXJuIChFTlhJTyk7CiAKKwliY21fZ3Bpb19zYyA9IHNj ID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOworCiAJbXR4X2luaXQoJnNjLT5zY19tdHgsICJiY20g Z3BpbyIsICJncGlvIiwgTVRYX0RFRik7CiAKIAlyaWQgPSAwOwpAQCAtNzA4LDE1ICs3NzIsMTkg QEAKIAlzYy0+c2NfYnN0ID0gcm1hbl9nZXRfYnVzdGFnKHNjLT5zY19tZW1fcmVzKTsKIAlzYy0+ c2NfYnNoID0gcm1hbl9nZXRfYnVzaGFuZGxlKHNjLT5zY19tZW1fcmVzKTsKIAotCXJpZCA9IDA7 Ci0Jc2MtPnNjX2lycV9yZXMgPSBidXNfYWxsb2NfcmVzb3VyY2VfYW55KGRldiwgU1lTX1JFU19J UlEsICZyaWQsCi0JICAgIFJGX0FDVElWRSk7Ci0JaWYgKCFzYy0+c2NfaXJxX3JlcykgeworCS8q IFJlcXVlc3QgdGhlIElSUSByZXNvdXJjZXMuICovCisJaWYgKGJ1c19hbGxvY19yZXNvdXJjZXMo ZGV2LCBiY21fZ3Bpb19pcnFfc3BlYywgc2MtPnNjX2lycV9yZXMpKSB7CiAJCWJ1c19yZWxlYXNl X3Jlc291cmNlKGRldiwgU1lTX1JFU19NRU1PUlksIDAsIHNjLT5zY19tZW1fcmVzKTsKLQkJZGV2 aWNlX3ByaW50ZihkZXYsICJjYW5ub3QgYWxsb2NhdGUgaW50ZXJydXB0XG4iKTsKKwkJZGV2aWNl X3ByaW50ZihkZXYsICJjYW5ub3QgYWxsb2NhdGUgaXJxIHJlc291cmNlc1xuIik7CiAJCXJldHVy biAoRU5YSU8pOwogCX0KIAorCS8qIFNldHVwIHRoZSBHUElPIGludGVycnVwdCBoYW5kbGVyLiAq LworCWlmIChiY21fZ3Bpb19pbnRyX2F0dGFjaChkZXYpKSB7CisJCWRldmljZV9wcmludGYoZGV2 LCAidW5hYmxlIHRvIHNldHVwIHRoZSBncGlvIGlycSBoYW5kbGVyXG4iKTsKKwkJZ290byBmYWls OworCX0KKyAKIAkvKiBGaW5kIG91ciBub2RlLiAqLwogCWdwaW8gPSBvZndfYnVzX2dldF9ub2Rl KHNjLT5zY19kZXYpOwogCkBAIC03NDEsNiArODA5LDkgQEAKIAkJc2MtPnNjX2dwaW9fcGluc1tp XS5ncF9waW4gPSBqOwogCQlzYy0+c2NfZ3Bpb19waW5zW2ldLmdwX2NhcHMgPSBCQ01fR1BJT19E RUZBVUxUX0NBUFM7CiAJCXNjLT5zY19ncGlvX3BpbnNbaV0uZ3BfZmxhZ3MgPSBiY21fZ3Bpb19m dW5jX2ZsYWcoZnVuYyk7CisJCS8qIFRoZSBkZWZhdWx0IGlzIGFjdGl2ZS1sb3cgaW50ZXJydXB0 cy4gKi8KKwkJc2MtPnNjX2lycV90cmlnZ2VyW2ldID0gSU5UUl9UUklHR0VSX0xFVkVMOworCQlz Yy0+c2NfaXJxX3BvbGFyaXR5W2ldID0gSU5UUl9QT0xBUklUWV9MT1c7CiAJCWkrKzsKIAl9CiAJ c2MtPnNjX2dwaW9fbnBpbnMgPSBpOwpAQCAtNzQ5LDEzICs4MjAsMTUgQEAKIAogCWRldmljZV9h ZGRfY2hpbGQoZGV2LCAiZ3Bpb2MiLCBkZXZpY2VfZ2V0X3VuaXQoZGV2KSk7CiAJZGV2aWNlX2Fk ZF9jaGlsZChkZXYsICJncGlvYnVzIiwgZGV2aWNlX2dldF91bml0KGRldikpOworCiAJcmV0dXJu IChidXNfZ2VuZXJpY19hdHRhY2goZGV2KSk7CiAKIGZhaWw6Ci0JaWYgKHNjLT5zY19pcnFfcmVz KQotCQlidXNfcmVsZWFzZV9yZXNvdXJjZShkZXYsIFNZU19SRVNfSVJRLCAwLCBzYy0+c2NfaXJx X3Jlcyk7CisJYmNtX2dwaW9faW50cl9kZXRhY2goZGV2KTsKKwlidXNfcmVsZWFzZV9yZXNvdXJj ZXMoZGV2LCBiY21fZ3Bpb19pcnFfc3BlYywgc2MtPnNjX2lycV9yZXMpOwogCWlmIChzYy0+c2Nf bWVtX3JlcykKIAkJYnVzX3JlbGVhc2VfcmVzb3VyY2UoZGV2LCBTWVNfUkVTX01FTU9SWSwgMCwg c2MtPnNjX21lbV9yZXMpOworCiAJcmV0dXJuIChFTlhJTyk7CiB9CiAKQEAgLTc2Niw2ICs4Mzks MjMzIEBACiAJcmV0dXJuIChFQlVTWSk7CiB9CiAKK3N0YXRpYyB1aW50MzJfdAorYmNtX2dwaW9f aW50cl9yZWcoc3RydWN0IGJjbV9ncGlvX3NvZnRjICpzYywgdW5zaWduZWQgaW50IGlycSwgdWlu dDMyX3QgYmFuaykKK3sKKworCWlmIChpcnEgPiBCQ01fR1BJT19QSU5TKQorCQlyZXR1cm4gKDAp OworCisJaWYgKHNjLT5zY19pcnFfdHJpZ2dlcltpcnFdID09IElOVFJfVFJJR0dFUl9MRVZFTCkg eworCQlpZiAoc2MtPnNjX2lycV9wb2xhcml0eVtpcnFdID09IElOVFJfUE9MQVJJVFlfTE9XKQor CQkJcmV0dXJuIChCQ01fR1BJT19HUExFTihiYW5rKSk7CisJCWVsc2UgaWYgKHNjLT5zY19pcnFf cG9sYXJpdHlbaXJxXSA9PSBJTlRSX1BPTEFSSVRZX0hJR0gpCisJCQlyZXR1cm4gKEJDTV9HUElP X0dQSEVOKGJhbmspKTsKKwl9IGVsc2UgaWYgKHNjLT5zY19pcnFfdHJpZ2dlcltpcnFdID09IElO VFJfVFJJR0dFUl9FREdFKSB7CisJCWlmIChzYy0+c2NfaXJxX3BvbGFyaXR5W2lycV0gPT0gSU5U Ul9QT0xBUklUWV9MT1cpCisJCQlyZXR1cm4gKEJDTV9HUElPX0dQRkVOKGJhbmspKTsKKwkJZWxz ZSBpZiAoc2MtPnNjX2lycV9wb2xhcml0eVtpcnFdID09IElOVFJfUE9MQVJJVFlfSElHSCkKKwkJ CXJldHVybiAoQkNNX0dQSU9fR1BSRU4oYmFuaykpOworCX0KKworCXJldHVybiAoMCk7Cit9CisK K3N0YXRpYyB2b2lkCitiY21fZ3Bpb19tYXNrX2lycSh2b2lkICpzb3VyY2UpCit7CisJdWludDMy X3QgYmFuaywgbWFzaywgcmVnOworCXVuc2lnbmVkIGludCBpcnE7CisKKwlpcnEgPSAodW5zaWdu ZWQgaW50KXNvdXJjZTsKKwlpZiAoaXJxID4gQkNNX0dQSU9fUElOUykKKwkJcmV0dXJuOworCWlm IChiY21fZ3Bpb19waW5faXNfcm8oYmNtX2dwaW9fc2MsIGlycSkpCisJCXJldHVybjsKKworCWJh bmsgPSBpcnEgLyBCQ01fR1BJT19QSU5TX1BFUl9CQU5LOworCW1hc2sgPSAoMVUgPDwgKGlycSAl IEJDTV9HUElPX1BJTlNfUEVSX0JBTkspKTsKKworCUJDTV9HUElPX0xPQ0soYmNtX2dwaW9fc2Mp OworCXJlZyA9IGJjbV9ncGlvX2ludHJfcmVnKGJjbV9ncGlvX3NjLCBpcnEsIGJhbmspOworCWlm IChyZWcgIT0gMCkKKwkJQkNNX0dQSU9fQ0xFQVJfQklUUyhiY21fZ3Bpb19zYywgcmVnLCBtYXNr KTsKKwlCQ01fR1BJT19VTkxPQ0soYmNtX2dwaW9fc2MpOworfQorCitzdGF0aWMgdm9pZAorYmNt X2dwaW9fdW5tYXNrX2lycSh2b2lkICpzb3VyY2UpCit7CisJdWludDMyX3QgYmFuaywgbWFzaywg cmVnOworCXVuc2lnbmVkIGludCBpcnE7CisKKwlpcnEgPSAodW5zaWduZWQgaW50KXNvdXJjZTsK KwlpZiAoaXJxID4gQkNNX0dQSU9fUElOUykKKwkJcmV0dXJuOworCWlmIChiY21fZ3Bpb19waW5f aXNfcm8oYmNtX2dwaW9fc2MsIGlycSkpCisJCXJldHVybjsKKworCWJhbmsgPSBpcnEgLyBCQ01f R1BJT19QSU5TX1BFUl9CQU5LOworCW1hc2sgPSAoMVUgPDwgKGlycSAlIEJDTV9HUElPX1BJTlNf UEVSX0JBTkspKTsKKworCUJDTV9HUElPX0xPQ0soYmNtX2dwaW9fc2MpOworCXJlZyA9IGJjbV9n cGlvX2ludHJfcmVnKGJjbV9ncGlvX3NjLCBpcnEsIGJhbmspOworCWlmIChyZWcgIT0gMCkKKwkJ QkNNX0dQSU9fU0VUX0JJVFMoYmNtX2dwaW9fc2MsIHJlZywgbWFzayk7CisJQkNNX0dQSU9fVU5M T0NLKGJjbV9ncGlvX3NjKTsKK30KKworc3RhdGljIGludAorYmNtX2dwaW9fYWN0aXZhdGVfcmVz b3VyY2UoZGV2aWNlX3QgYnVzLCBkZXZpY2VfdCBjaGlsZCwgaW50IHR5cGUsIGludCByaWQsCisJ c3RydWN0IHJlc291cmNlICpyZXMpCit7CisJaW50IHBpbjsKKworCWlmICh0eXBlICE9IFNZU19S RVNfSVJRKQorCQlyZXR1cm4gKEVOWElPKTsKKworCS8qIFVubWFzayB0aGUgaW50ZXJydXB0LiAq LworCXBpbiA9IHJtYW5fZ2V0X3N0YXJ0KHJlcyk7CisJYmNtX2dwaW9fdW5tYXNrX2lycSgodm9p ZCAqKXBpbik7CisKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgaW50CitiY21fZ3Bpb19kZWFj dGl2YXRlX3Jlc291cmNlKGRldmljZV90IGJ1cywgZGV2aWNlX3QgY2hpbGQsIGludCB0eXBlLCBp bnQgcmlkLAorCXN0cnVjdCByZXNvdXJjZSAqcmVzKQoreworCWludCBwaW47CisKKwlpZiAodHlw ZSAhPSBTWVNfUkVTX0lSUSkKKwkJcmV0dXJuIChFTlhJTyk7CisKKwkvKiBNYXNrIHRoZSBpbnRl cnJ1cHQuICovCisJcGluID0gcm1hbl9nZXRfc3RhcnQocmVzKTsKKwliY21fZ3Bpb19tYXNrX2ly cSgodm9pZCAqKXBpbik7CisKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgaW50CitiY21fZ3Bp b19jb25maWdfaW50cihkZXZpY2VfdCBkZXYsIGludCBpcnEsIGVudW0gaW50cl90cmlnZ2VyIHRy aWcsCisJZW51bSBpbnRyX3BvbGFyaXR5IHBvbCkKK3sKKwlpbnQgYmFuazsKKwlzdHJ1Y3QgYmNt X2dwaW9fc29mdGMgKnNjOworCXVpbnQzMl90IG1hc2ssIG9sZHJlZywgcmVnOworCisJaWYgKGly cSA+IEJDTV9HUElPX1BJTlMpCisJCXJldHVybiAoRUlOVkFMKTsKKworCS8qIFRoZXJlIGlzIG5v IHN0YW5kYXJkIHRyaWdnZXIgb3IgcG9sYXJpdHkuICovCisJaWYgKHRyaWcgPT0gSU5UUl9UUklH R0VSX0NPTkZPUk0gfHwgcG9sID09IElOVFJfUE9MQVJJVFlfQ09ORk9STSkKKwkJcmV0dXJuIChF SU5WQUwpOworCisJc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisJaWYgKGJjbV9ncGlvX3Bp bl9pc19ybyhzYywgaXJxKSkKKwkJcmV0dXJuIChFSU5WQUwpOworCisJYmFuayA9IGlycSAvIEJD TV9HUElPX1BJTlNfUEVSX0JBTks7CisJbWFzayA9ICgxVUwgPDwgKGlycSAlIEJDTV9HUElPX1BJ TlNfUEVSX0JBTkspKTsKKworCUJDTV9HUElPX0xPQ0soc2MpOworCW9sZHJlZyA9IGJjbV9ncGlv X2ludHJfcmVnKHNjLCBpcnEsIGJhbmspOworCXNjLT5zY19pcnFfdHJpZ2dlcltpcnFdID0gdHJp ZzsKKwlzYy0+c2NfaXJxX3BvbGFyaXR5W2lycV0gPSBwb2w7CisJcmVnID0gYmNtX2dwaW9faW50 cl9yZWcoc2MsIGlycSwgYmFuayk7CisJaWYgKHJlZyAhPSAwKQorCQlCQ01fR1BJT19TRVRfQklU UyhzYywgcmVnLCBtYXNrKTsKKwlpZiAob2xkcmVnICE9IDApCisJCUJDTV9HUElPX0NMRUFSX0JJ VFMoc2MsIG9sZHJlZywgbWFzayk7CisJQkNNX0dQSU9fVU5MT0NLKHNjKTsKKworCXJldHVybiAo MCk7Cit9CisKK3N0YXRpYyBpbnQKK2JjbV9ncGlvX3NldHVwX2ludHIoZGV2aWNlX3QgYnVzLCBk ZXZpY2VfdCBjaGlsZCwgc3RydWN0IHJlc291cmNlICppcmVzLAorCWludCBmbGFncywgZHJpdmVy X2ZpbHRlcl90ICpmaWx0LCBkcml2ZXJfaW50cl90ICpoYW5kbGVyLAorCXZvaWQgKmFyZywgdm9p ZCAqKmNvb2tpZXApCit7CisJc3RydWN0IGJjbV9ncGlvX3NvZnRjICpzYzsKKwlzdHJ1Y3QgaW50 cl9ldmVudCAqZXZlbnQ7CisJaW50IHBpbiwgZXJyb3I7CisKKwlzYyA9IGRldmljZV9nZXRfc29m dGMoYnVzKTsKKwlwaW4gPSBybWFuX2dldF9zdGFydChpcmVzKTsKKworCWlmIChwaW4gPiBCQ01f R1BJT19QSU5TKQorCQlwYW5pYygiJXM6IGJhZCBwaW4gJWQiLCBfX2Z1bmNfXywgcGluKTsKKwor CWV2ZW50ID0gc2MtPnNjX2V2ZW50c1twaW5dOworCWlmIChldmVudCA9PSBOVUxMKSB7CisJCWVy cm9yID0gaW50cl9ldmVudF9jcmVhdGUoJmV2ZW50LCAodm9pZCAqKXBpbiwgMCwgcGluLCAKKwkJ ICAgIGJjbV9ncGlvX21hc2tfaXJxLCBiY21fZ3Bpb191bm1hc2tfaXJxLCBOVUxMLCBOVUxMLAor CQkgICAgImdwaW8lZCBwaW4lZDoiLCBkZXZpY2VfZ2V0X3VuaXQoYnVzKSwgcGluKTsKKworCQlp ZiAoZXJyb3IgIT0gMCkKKwkJCXJldHVybiAoZXJyb3IpOworCisJCXNjLT5zY19ldmVudHNbcGlu XSA9IGV2ZW50OworCX0KKworCWludHJfZXZlbnRfYWRkX2hhbmRsZXIoZXZlbnQsIGRldmljZV9n ZXRfbmFtZXVuaXQoY2hpbGQpLCBmaWx0LAorCSAgICBoYW5kbGVyLCBhcmcsIGludHJfcHJpb3Jp dHkoZmxhZ3MpLCBmbGFncywgY29va2llcCk7CisKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMg aW50CitiY21fZ3Bpb190ZWFyZG93bl9pbnRyKGRldmljZV90IGRldiwgZGV2aWNlX3QgY2hpbGQs IHN0cnVjdCByZXNvdXJjZSAqaXJlcywKKwl2b2lkICpjb29raWUpCit7CisJc3RydWN0IGJjbV9n cGlvX3NvZnRjICpzYzsKKwlpbnQgcGluLCBlcnI7CisKKwlzYyA9IGRldmljZV9nZXRfc29mdGMo ZGV2KTsKKwlwaW4gPSBybWFuX2dldF9zdGFydChpcmVzKTsKKwlpZiAocGluID4gQkNNX0dQSU9f UElOUykKKwkJcGFuaWMoIiVzOiBiYWQgcGluICVkIiwgX19mdW5jX18sIHBpbik7CisKKwlpZiAo c2MtPnNjX2V2ZW50c1twaW5dID09IE5VTEwpCisJCXBhbmljKCJUcnlpbmcgdG8gdGVhcmRvd24g dW5vY2N1cGllZCBJUlEiKTsKKworCWVyciA9IGludHJfZXZlbnRfcmVtb3ZlX2hhbmRsZXIoY29v a2llKTsKKwlpZiAoIWVycikKKwkJc2MtPnNjX2V2ZW50c1twaW5dID0gTlVMTDsKKworCXJldHVy biAoZXJyKTsKK30KKworc3RhdGljIGludAorYmNtX2dwaW9faW50cih2b2lkICphcmcpCit7CisJ c3RydWN0IGJjbV9ncGlvX3NvZnRjICpzYzsKKwlzdHJ1Y3QgaW50cl9ldmVudCAqZXZlbnQ7CisJ dWludDMyX3QgYmFuaywgbWFzaywgcmVnOworCWludCBiYW5rX2xhc3QsIGlycTsKKworCXNjID0g KHN0cnVjdCBiY21fZ3Bpb19zb2Z0YyAqKWFyZzsKKworCWJhbmtfbGFzdCA9IC0xOworCWZvciAo aXJxID0gMDsgaXJxIDwgQkNNX0dQSU9fUElOUzsgaXJxKyspIHsKKworCQliYW5rID0gaXJxIC8g QkNNX0dQSU9fUElOU19QRVJfQkFOSzsKKwkJbWFzayA9ICgxVSA8PCAoaXJxICUgQkNNX0dQSU9f UElOU19QRVJfQkFOSykpOworCisJCWlmIChiYW5rICE9IGJhbmtfbGFzdCkgeworCQkJcmVnID0g QkNNX0dQSU9fUkVBRChzYywgQkNNX0dQSU9fR1BFRFMoYmFuaykpOworCQkJYmFua19sYXN0ID0g YmFuazsKKwkJfQorCisJCWlmIChyZWcgJiBtYXNrKSB7CisJCQlldmVudCA9IHNjLT5zY19ldmVu dHNbaXJxXTsKKwkJCWlmIChldmVudCAhPSBOVUxMICYmICFUQUlMUV9FTVBUWSgmZXZlbnQtPmll X2hhbmRsZXJzKSkKKwkJCQlpbnRyX2V2ZW50X2hhbmRsZShldmVudCwgTlVMTCk7CisJCQllbHNl IHsKKwkJCQlkZXZpY2VfcHJpbnRmKHNjLT5zY19kZXYsICJTdHJheSBJUlEgJWRcbiIsCisJCQkJ ICAgIGlycSk7CisJCQl9CisKKwkJCS8qIENsZWFyIHRoZSBTdGF0dXMgYml0IGJ5IHdyaXRpbmcg JzEnIHRvIGl0LiAqLworCQkJQkNNX0dQSU9fV1JJVEUoc2MsIEJDTV9HUElPX0dQRURTKGJhbmsp LCBtYXNrKTsKKwkJfQorCX0KKworCXJldHVybiAoRklMVEVSX0hBTkRMRUQpOworfQorCiBzdGF0 aWMgcGhhbmRsZV90CiBiY21fZ3Bpb19nZXRfbm9kZShkZXZpY2VfdCBidXMsIGRldmljZV90IGRl dikKIHsKQEAgLTc5MCw2ICsxMDkwLDEzIEBACiAJREVWTUVUSE9EKGdwaW9fcGluX3NldCwJCWJj bV9ncGlvX3Bpbl9zZXQpLAogCURFVk1FVEhPRChncGlvX3Bpbl90b2dnbGUsCWJjbV9ncGlvX3Bp bl90b2dnbGUpLAogCisJLyogQnVzIGludGVyZmFjZSAqLworCURFVk1FVEhPRChidXNfYWN0aXZh dGVfcmVzb3VyY2UsCWJjbV9ncGlvX2FjdGl2YXRlX3Jlc291cmNlKSwKKwlERVZNRVRIT0QoYnVz X2RlYWN0aXZhdGVfcmVzb3VyY2UsCWJjbV9ncGlvX2RlYWN0aXZhdGVfcmVzb3VyY2UpLAorCURF Vk1FVEhPRChidXNfY29uZmlnX2ludHIsCWJjbV9ncGlvX2NvbmZpZ19pbnRyKSwKKwlERVZNRVRI T0QoYnVzX3NldHVwX2ludHIsCWJjbV9ncGlvX3NldHVwX2ludHIpLAorCURFVk1FVEhPRChidXNf dGVhcmRvd25faW50ciwJYmNtX2dwaW9fdGVhcmRvd25faW50ciksCisKIAkvKiBvZndfYnVzIGlu dGVyZmFjZSAqLwogCURFVk1FVEhPRChvZndfYnVzX2dldF9ub2RlLAliY21fZ3Bpb19nZXRfbm9k ZSksCiAK --001a11c335ce38a5b404f96138f2 Content-Type: text/plain; charset=US-ASCII; name="gpio-intr.diff" Content-Disposition: attachment; filename="gpio-intr.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hv6zeuus3 SW5kZXg6IHN5cy9jb25mL2ZpbGVzCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9jb25mL2ZpbGVzCShyZXZp c2lvbiAyNjU4MTcpCisrKyBzeXMvY29uZi9maWxlcwkod29ya2luZyBjb3B5KQpAQCAtMTM5Nyw5 ICsxMzk3LDggQEAKIGRldi9nZW0vaWZfZ2VtX3NidXMuYwkJb3B0aW9uYWwgZ2VtIHNidXMKIGRl di9ncGlvL2dwaW9idXMuYwkJb3B0aW9uYWwgZ3BpbwkJCQlcCiAJZGVwZW5kZW5jeQkiZ3Bpb2J1 c19pZi5oIgotZGV2L2dwaW8vZ3Bpb2MuYwkJb3B0aW9uYWwgZ3BpbwkJCQlcCi0JZGVwZW5kZW5j eQkiZ3Bpb19pZi5oIgogZGV2L2dwaW8vZ3Bpb2lpYy5jCQlvcHRpb25hbCBncGlvaWljCitkZXYv Z3Bpby9ncGlvaW50ci5jCQlvcHRpb25hbCBncGlvaW50cgogZGV2L2dwaW8vZ3Bpb2xlZC5jCQlv cHRpb25hbCBncGlvbGVkCiBkZXYvZ3Bpby9ncGlvX2lmLm0JCW9wdGlvbmFsIGdwaW8KIGRldi9n cGlvL2dwaW9idXNfaWYubQkJb3B0aW9uYWwgZ3BpbwpJbmRleDogc3lzL2Rldi9ncGlvL2dwaW9i dXMuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09Ci0tLSBzeXMvZGV2L2dwaW8vZ3Bpb2J1cy5jCShyZXZpc2lvbiAyNjU4 MTcpCisrKyBzeXMvZGV2L2dwaW8vZ3Bpb2J1cy5jCSh3b3JraW5nIGNvcHkpCkBAIC0zMCw2ICsz MCw4IEBACiAjaW5jbHVkZSA8c3lzL3BhcmFtLmg+CiAjaW5jbHVkZSA8c3lzL3N5c3RtLmg+CiAj aW5jbHVkZSA8c3lzL2J1cy5oPgorI2luY2x1ZGUgPHN5cy9jb25mLmg+CisjaW5jbHVkZSA8c3lz L2dwaW8uaD4KICNpbmNsdWRlIDxzeXMva2VybmVsLmg+CiAjaW5jbHVkZSA8c3lzL21hbGxvYy5o PgogI2luY2x1ZGUgPHN5cy9tb2R1bGUuaD4KQEAgLTM4LDYgKzQwLDEzIEBACiAKICNpbmNsdWRl ICJncGlvYnVzX2lmLmgiCiAKKyN1bmRlZiBHUElPQlVTX0RFQlVHCisjaWZkZWYgR1BJT0JVU19E RUJVRworI2RlZmluZQlkcHJpbnRmIHByaW50ZgorI2Vsc2UKKyNkZWZpbmUJZHByaW50Zih4LCBh cmcuLi4pCisjZW5kaWYKKwogc3RhdGljIGludCBncGlvYnVzX3BhcnNlX3BpbnMoc3RydWN0IGdw aW9idXNfc29mdGMgKiwgZGV2aWNlX3QsIGludCk7CiBzdGF0aWMgaW50IGdwaW9idXNfcHJvYmUo ZGV2aWNlX3QpOwogc3RhdGljIGludCBncGlvYnVzX2F0dGFjaChkZXZpY2VfdCk7CkBAIC02NCw2 ICs3MywyNCBAQAogc3RhdGljIGludCBncGlvYnVzX3Bpbl9nZXQoZGV2aWNlX3QsIGRldmljZV90 LCB1aW50MzJfdCwgdW5zaWduZWQgaW50Kik7CiBzdGF0aWMgaW50IGdwaW9idXNfcGluX3RvZ2ds ZShkZXZpY2VfdCwgZGV2aWNlX3QsIHVpbnQzMl90KTsKIAorc3RhdGljIGRfaW9jdGxfdCBncGlv YnVzX2lvY3RsOworc3RhdGljIGRfa3FmaWx0ZXJfdCBncGlvYnVzX2txZmlsdGVyOworc3RhdGlj IHZvaWQgZ3Bpb2J1c19maWx0X2RldGFjaChzdHJ1Y3Qga25vdGUgKmtuKTsKK3N0YXRpYyBpbnQg Z3Bpb2J1c19maWx0X3JlYWQoc3RydWN0IGtub3RlICprbiwgbG9uZyBoaW50KTsKKworc3RhdGlj IHN0cnVjdCBjZGV2c3cgZ3Bpb2J1c19jZGV2c3cgPSB7CisJLmRfdmVyc2lvbiAgICAgID0gRF9W RVJTSU9OLAorCS5kX2lvY3RsICAgICAgICA9IGdwaW9idXNfaW9jdGwsCisJLmRfa3FmaWx0ZXIJ PSBncGlvYnVzX2txZmlsdGVyLAorCS5kX25hbWUgICAgICAgICA9ICJncGlvYyIsCit9OworCitz dHJ1Y3QgZmlsdGVyb3BzIGdwaW9idXNfcmZpbHRvcHMgPSB7CisJLmZfaXNmZCA9IDEsCisJLmZf ZGV0YWNoID0gZ3Bpb2J1c19maWx0X2RldGFjaCwKKwkuZl9ldmVudCA9IGdwaW9idXNfZmlsdF9y ZWFkLAorfTsKKwogdm9pZAogZ3Bpb2J1c19wcmludF9waW5zKHN0cnVjdCBncGlvYnVzX2l2YXIg KmRldmkpCiB7CkBAIC05OSw2ICsxMjYsNjIgQEAKIAkJcHJpbnRmKCIlZCIsIHJhbmdlX3N0YXJ0 KTsKIH0KIAoraW50CitncGlvYnVzX2luaXRfc29mdGMoZGV2aWNlX3QgZGV2KQoreworCXN0cnVj dCBncGlvYnVzX3NvZnRjICpzYzsKKwlpbnQgaTsKKworIAlzYyA9IEdQSU9CVVNfU09GVEMoZGV2 KTsKKwlzYy0+c2NfYnVzZGV2ID0gZGV2OworCXNjLT5zY19kZXYgPSBkZXZpY2VfZ2V0X3BhcmVu dChkZXYpOworCXNjLT5zY19pbnRyX3JtYW4ucm1fdHlwZSA9IFJNQU5fQVJSQVk7CisJc2MtPnNj X2ludHJfcm1hbi5ybV9kZXNjciA9ICJHUElPIEludGVycnVwdHMiOworCWlmIChybWFuX2luaXQo JnNjLT5zY19pbnRyX3JtYW4pICE9IDAgfHwKKwkgICAgcm1hbl9tYW5hZ2VfcmVnaW9uKCZzYy0+ c2NfaW50cl9ybWFuLCAwLCB+MCkgIT0gMCkKKwkJcGFuaWMoIiVzOiBmYWlsZWQgdG8gc2V0IHVw IHJtYW4uIiwgX19mdW5jX18pOworCisJaWYgKEdQSU9fUElOX01BWChzYy0+c2NfZGV2LCAmc2Mt PnNjX25waW5zKSAhPSAwKQorCQlyZXR1cm4gKEVOWElPKTsKKworCUtBU1NFUlQoc2MtPnNjX25w aW5zICE9IDAsICgiR1BJTyBkZXZpY2Ugd2l0aCBubyBwaW5zIikpOworCisJLyogSW5jcmVhc2Ug dGhlIG51bWJlciBvZiBwaW5zLiAqLworCXNjLT5zY19ucGlucysrOworCisJLyogQWxsb2MgdGhl IHBpbiBkYXRhLiAqLworCXNjLT5zY19waW5zID0gbWFsbG9jKHNpemVvZigqc2MtPnNjX3BpbnMp ICogc2MtPnNjX25waW5zLCBNX0RFVkJVRiwKKwkgICAgTV9OT1dBSVQgfCBNX1pFUk8pOworCWlm IChzYy0+c2NfcGlucyA9PSBOVUxMKQorCQlyZXR1cm4gKEVOT01FTSk7CisJc2MtPnNjX3Bpbl9h cmcgPSBtYWxsb2Moc2l6ZW9mKHN0cnVjdCBncGlvYnVzX3Bpbl9hcmcpICogc2MtPnNjX25waW5z LAorCSAgICBNX0RFVkJVRiwgTV9OT1dBSVQgfCBNX1pFUk8pOworCWlmIChzYy0+c2NfcGluX2Fy ZyA9PSBOVUxMKSB7CisJCWZyZWUoc2MtPnNjX3BpbnMsIE1fREVWQlVGKTsKKwkJcmV0dXJuIChF Tk9NRU0pOworCX0KKworCS8qIENyZWF0ZSB0aGUgZ3Bpb2MlZCBkZXZpY2UuICovCisJc2MtPnNj X2N0bF9kZXYgPSBtYWtlX2RldigmZ3Bpb2J1c19jZGV2c3csIGRldmljZV9nZXRfdW5pdChkZXYp LAorCSAgICBVSURfUk9PVCwgR0lEX1dIRUVMLCAwNjAwLCAiZ3Bpb2MlZCIsIGRldmljZV9nZXRf dW5pdChkZXYpKTsKKwlpZiAoc2MtPnNjX2N0bF9kZXYgPT0gTlVMTCkgeworCQlwcmludGYoIkZh aWxlZCB0byBjcmVhdGUgZ3Bpb2MlZCIsIGRldmljZV9nZXRfdW5pdChkZXYpKTsKKwkJZnJlZShz Yy0+c2NfcGluX2FyZywgTV9ERVZCVUYpOworCQlmcmVlKHNjLT5zY19waW5zLCBNX0RFVkJVRik7 CisJCXJldHVybiAoRU5YSU8pOworCX0KKwlzYy0+c2NfY3RsX2Rldi0+c2lfZHJ2MSA9IHNjOwor CisJLyogSW5pdGlhbGl6ZSB0aGUgYnVzIGxvY2suICovCisJR1BJT0JVU19MT0NLX0lOSVQoc2Mp OworCisJLyogSW5pdGlhbGl6ZSB0aGUgcGlucyBrbmxpc3QuICovCisJZm9yIChpID0gMDsgaSA8 IHNjLT5zY19ucGluczsgaSsrKQorCQlrbmxpc3RfaW5pdF9tdHgoJnNjLT5zY19waW5zW2ldLnNl bC5zaV9ub3RlLCAmc2MtPnNjX210eCk7CisKKwlyZXR1cm4gKDApOworfQorCiBzdGF0aWMgaW50 CiBncGlvYnVzX3BhcnNlX3BpbnMoc3RydWN0IGdwaW9idXNfc29mdGMgKnNjLCBkZXZpY2VfdCBj aGlsZCwgaW50IG1hc2spCiB7CkBAIC0xNDAsMTMgKzIyMywxMyBAQAogCQkvKgogCQkgKiBNYXJr IHBpbiBhcyBtYXBwZWQgYW5kIGdpdmUgd2FybmluZyBpZiBpdCdzIGFscmVhZHkgbWFwcGVkCiAJ CSAqLwotCQlpZiAoc2MtPnNjX3BpbnNfbWFwcGVkW2ldKSB7CisJCWlmIChzYy0+c2NfcGluc1tp XS5tYXBwZWQpIHsKIAkJCWRldmljZV9wcmludGYoY2hpbGQsIAogCQkJICAgICJ3YXJuaW5nOiBw aW4gJWQgaXMgYWxyZWFkeSBtYXBwZWRcbiIsIGkpOwogCQkJZnJlZShkZXZpLT5waW5zLCBNX0RF VkJVRik7CiAJCQlyZXR1cm4gKEVJTlZBTCk7CiAJCX0KLQkJc2MtPnNjX3BpbnNfbWFwcGVkW2ld ID0gMTsKKwkJc2MtPnNjX3BpbnNbaV0ubWFwcGVkID0gMTsKIAl9CiAKIAlyZXR1cm4gKDApOwpA QCAtMTUzLDQxICsyMzYsMTQ3IEBACiB9CiAKIHN0YXRpYyBpbnQKLWdwaW9idXNfcHJvYmUoZGV2 aWNlX3QgZGV2KQorZ3Bpb2J1c19rcWZpbHRlcihzdHJ1Y3QgY2RldiAqY2Rldiwgc3RydWN0IGtu b3RlICprbikKIHsKLQlkZXZpY2Vfc2V0X2Rlc2MoZGV2LCAiR1BJTyBidXMiKTsKKwlpbnQgcGlu OworCXN0cnVjdCBncGlvYnVzX3NvZnRjICpzYzsKIAotCXJldHVybiAoQlVTX1BST0JFX0dFTkVS SUMpOworCXNjID0gKHN0cnVjdCBncGlvYnVzX3NvZnRjICopY2Rldi0+c2lfZHJ2MTsKKwlwaW4g PSBrbi0+a25fc2RhdGE7CisKKwkvKiBDaGVjayBpZiB3ZSBhcmUgbW9uaXRvcmluZyBhIHZhbGlk IGludGVycnVwdC4gKi8KKwlpZiAoc2MtPnNjX3Bpbl9hcmdbcGluXS5zYyAhPSBzYykKKwkJcmV0 dXJuIChFSU5WQUwpOworCisJc3dpdGNoIChrbi0+a25fZmlsdGVyKSB7CisJY2FzZSBFVkZJTFRf UkVBRDoKKwkJa24tPmtuX2hvb2sgPSAmc2MtPnNjX3Bpbl9hcmdbcGluXTsKKwkJa24tPmtuX2Zv cCA9ICZncGlvYnVzX3JmaWx0b3BzOworCQlrbmxpc3RfYWRkKCZzYy0+c2NfcGluc1twaW5dLnNl bC5zaV9ub3RlLCBrbiwgMCk7CisJCWJyZWFrOworCWRlZmF1bHQ6CisJCXJldHVybiAoRUlOVkFM KTsKKwl9CisKKwlyZXR1cm4gKDApOwogfQogCitzdGF0aWMgdm9pZAorZ3Bpb2J1c19maWx0X2Rl dGFjaChzdHJ1Y3Qga25vdGUgKmtuKQoreworCWludCBwaW47CisJc3RydWN0IGdwaW9idXNfc29m dGMgKnNjOworCXN0cnVjdCBncGlvYnVzX3Bpbl9hcmcgKmFyZzsKKworCWFyZyA9IChzdHJ1Y3Qg Z3Bpb2J1c19waW5fYXJnICopa24tPmtuX2hvb2s7CisJc2MgPSBhcmctPnNjOworCXBpbiA9IGFy Zy0+cGluOworCWtubGlzdF9yZW1vdmUoJnNjLT5zY19waW5zW3Bpbl0uc2VsLnNpX25vdGUsIGtu LCAwKTsKK30KKwogc3RhdGljIGludAotZ3Bpb2J1c19hdHRhY2goZGV2aWNlX3QgZGV2KQorZ3Bp b2J1c19maWx0X3JlYWQoc3RydWN0IGtub3RlICprbiwgbG9uZyBoaW50KQogewotCXN0cnVjdCBn cGlvYnVzX3NvZnRjICpzYyA9IEdQSU9CVVNfU09GVEMoZGV2KTsKLQlpbnQgcmVzOworCXN0YXRp YyBsb25nIGxhc3QgPSAtMTsKKwlpbnQgbm90aWZ5OwogCi0Jc2MtPnNjX2J1c2RldiA9IGRldjsK LQlzYy0+c2NfZGV2ID0gZGV2aWNlX2dldF9wYXJlbnQoZGV2KTsKLQlyZXMgPSBHUElPX1BJTl9N QVgoc2MtPnNjX2RldiwgJnNjLT5zY19ucGlucyk7Ci0JaWYgKHJlcykKLQkJcmV0dXJuIChFTlhJ Tyk7CisJaWYgKGhpbnQgPiAwKQorCQkvKiBSZXR1cm4gdGhlIG9yaWdpbmFsIHBpbiB2YWx1ZS4g Ki8KKwkJa24tPmtuX2RhdGEgPSBoaW50IC0gMTsKIAotCUtBU1NFUlQoc2MtPnNjX25waW5zICE9 IDAsICgiR1BJTyBkZXZpY2Ugd2l0aCBubyBwaW5zIikpOworCWlmIChoaW50ID4gMCB8fCBsYXN0 ID4gMCkKKwkJbm90aWZ5ID0gMTsKKwllbHNlCisJCW5vdGlmeSA9IDA7CiAKLQkvKgotCSAqIElu Y3JlYXNlIHRvIGdldCBudW1iZXIgb2YgcGlucwotCSAqLwotCXNjLT5zY19ucGlucysrOworCWxh c3QgPSBoaW50OwogCi0Jc2MtPnNjX3BpbnNfbWFwcGVkID0gbWFsbG9jKHNpemVvZihpbnQpICog c2MtPnNjX25waW5zLCBNX0RFVkJVRiwgCi0JICAgIE1fTk9XQUlUIHwgTV9aRVJPKTsKKwlyZXR1 cm4gKG5vdGlmeSk7Cit9CiAKLQlpZiAoIXNjLT5zY19waW5zX21hcHBlZCkKLQkJcmV0dXJuIChF Tk9NRU0pOworc3RhdGljIGludCAKK2dwaW9idXNfaW9jdGwoc3RydWN0IGNkZXYgKmNkZXYsIHVf bG9uZyBjbWQsIGNhZGRyX3QgYXJnLCBpbnQgZmZsYWcsIAorICAgIHN0cnVjdCB0aHJlYWQgKnRk KQoreworCWludCBtYXhfcGluLCByZXM7CisJc3RydWN0IGdwaW9idXNfc29mdGMgKnNjOworCXN0 cnVjdCBncGlvX3BpbiBwaW47CisJc3RydWN0IGdwaW9fcmVxIHJlcTsKIAotCS8qIGluaXQgYnVz IGxvY2sgKi8KLQlHUElPQlVTX0xPQ0tfSU5JVChzYyk7CisJc2MgPSBjZGV2LT5zaV9kcnYxOwor CUdQSU9CVVNfTE9DSyhzYyk7CisJc3dpdGNoIChjbWQpIHsKKwkJY2FzZSBHUElPTUFYUElOOgor CQkJbWF4X3BpbiA9IC0xOworCQkJcmVzID0gR1BJT19QSU5fTUFYKHNjLT5zY19kZXYsICZtYXhf cGluKTsKKwkJCWJjb3B5KCZtYXhfcGluLCBhcmcsIHNpemVvZihtYXhfcGluKSk7CisJCQlicmVh azsKKwkJY2FzZSBHUElPR0VUQ09ORklHOgorCQkJYmNvcHkoYXJnLCAmcGluLCBzaXplb2YocGlu KSk7CisJCQlkcHJpbnRmKCJnZXQgY29uZmlnIHBpbiAlZFxuIiwgcGluLmdwX3Bpbik7CisJCQly ZXMgPSBHUElPX1BJTl9HRVRGTEFHUyhzYy0+c2NfZGV2LCBwaW4uZ3BfcGluLAorCQkJICAgICZw aW4uZ3BfZmxhZ3MpOworCQkJLyogRmFpbCBlYXJseSAqLworCQkJaWYgKHJlcykKKwkJCQlicmVh azsKKwkJCUdQSU9fUElOX0dFVENBUFMoc2MtPnNjX2RldiwgcGluLmdwX3BpbiwgJnBpbi5ncF9j YXBzKTsKKwkJCUdQSU9fUElOX0dFVE5BTUUoc2MtPnNjX2RldiwgcGluLmdwX3BpbiwgcGluLmdw X25hbWUpOworCQkJYmNvcHkoJnBpbiwgYXJnLCBzaXplb2YocGluKSk7CisJCQlicmVhazsKKwkJ Y2FzZSBHUElPU0VUQ09ORklHOgorCQkJYmNvcHkoYXJnLCAmcGluLCBzaXplb2YocGluKSk7CisJ CQlkcHJpbnRmKCJzZXQgY29uZmlnIHBpbiAlZFxuIiwgcGluLmdwX3Bpbik7CisJCQlyZXMgPSBH UElPX1BJTl9TRVRGTEFHUyhzYy0+c2NfZGV2LCBwaW4uZ3BfcGluLAorCQkJICAgIHBpbi5ncF9m bGFncyk7CisJCQlicmVhazsKKwkJY2FzZSBHUElPR0VUOgorCQkJYmNvcHkoYXJnLCAmcmVxLCBz aXplb2YocmVxKSk7CisJCQlyZXMgPSBHUElPX1BJTl9HRVQoc2MtPnNjX2RldiwgcmVxLmdwX3Bp biwKKwkJCSAgICAmcmVxLmdwX3ZhbHVlKTsKKwkJICAgICAgICBkcHJpbnRmKCJyZWFkIHBpbiAl ZCAtPiAlZFxuIiwgCisJCQkgICAgcmVxLmdwX3BpbiwgcmVxLmdwX3ZhbHVlKTsKKwkJCWJjb3B5 KCZyZXEsIGFyZywgc2l6ZW9mKHJlcSkpOworCQkJYnJlYWs7CisJCWNhc2UgR1BJT1NFVDoKKwkJ CWJjb3B5KGFyZywgJnJlcSwgc2l6ZW9mKHJlcSkpOworCQkJcmVzID0gR1BJT19QSU5fU0VUKHNj LT5zY19kZXYsIHJlcS5ncF9waW4sIAorCQkJICAgIHJlcS5ncF92YWx1ZSk7CisJCQlkcHJpbnRm KCJ3cml0ZSBwaW4gJWQgLT4gJWRcbiIsIAorCQkJICAgIHJlcS5ncF9waW4sIHJlcS5ncF92YWx1 ZSk7CisJCQlicmVhazsKKwkJY2FzZSBHUElPVE9HR0xFOgorCQkJYmNvcHkoYXJnLCAmcmVxLCBz aXplb2YocmVxKSk7CisJCQlkcHJpbnRmKCJ0b2dnbGUgcGluICVkXG4iLCAKKwkJCSAgICByZXEu Z3BfcGluKTsKKwkJCXJlcyA9IEdQSU9fUElOX1RPR0dMRShzYy0+c2NfZGV2LCByZXEuZ3BfcGlu KTsKKwkJCWJyZWFrOworCQlkZWZhdWx0OgorCQkJR1BJT0JVU19VTkxPQ0soc2MpOworCQkJcmV0 dXJuIChFTk9UVFkpOworCQkJYnJlYWs7CisJfQorCUdQSU9CVVNfVU5MT0NLKHNjKTsKIAorCXJl dHVybiAocmVzKTsKK30KKworc3RhdGljIGludAorZ3Bpb2J1c19wcm9iZShkZXZpY2VfdCBkZXYp Cit7CisJZGV2aWNlX3NldF9kZXNjKGRldiwgIkdQSU8gYnVzIik7CisKKwlyZXR1cm4gKEJVU19Q Uk9CRV9HRU5FUklDKTsKK30KKworc3RhdGljIGludAorZ3Bpb2J1c19hdHRhY2goZGV2aWNlX3Qg ZGV2KQoreworCWludCBlcnI7CisKKwllcnIgPSBncGlvYnVzX2luaXRfc29mdGMoZGV2KTsKKwlp ZiAoZXJyICE9IDApCisJCXJldHVybiAoZXJyKTsKKwogCS8qCiAJICogR2V0IHBhcmVudCdzIHBp bnMgYW5kIG1hcmsgdGhlbSBhcyB1bm1hcHBlZAogCSAqLwpAQCAtMjE0LDYgKzQwMyw5IEBACiAJ ICAgICgiZ3Bpb2J1cyBtdXRleCBub3QgaW5pdGlhbGl6ZWQiKSk7CiAJR1BJT0JVU19MT0NLX0RF U1RST1koc2MpOwogCisJaWYgKHNjLT5zY19jdGxfZGV2KQorCQlkZXN0cm95X2RldihzYy0+c2Nf Y3RsX2Rldik7CisKIAlpZiAoKGVyciA9IGJ1c19nZW5lcmljX2RldGFjaChkZXYpKSAhPSAwKQog CQlyZXR1cm4gKGVycik7CiAKQEAgLTIyOSwxMCArNDIxLDE0IEBACiAJfQogCWZyZWUoZGV2bGlz dCwgTV9URU1QKTsKIAotCWlmIChzYy0+c2NfcGluc19tYXBwZWQpIHsKLQkJZnJlZShzYy0+c2Nf cGluc19tYXBwZWQsIE1fREVWQlVGKTsKLQkJc2MtPnNjX3BpbnNfbWFwcGVkID0gTlVMTDsKKwlp ZiAoc2MtPnNjX3Bpbl9hcmcpIHsKKwkJZnJlZShzYy0+c2NfcGluX2FyZywgTV9ERVZCVUYpOwor CQlzYy0+c2NfcGluX2FyZyA9IE5VTEw7CiAJfQorCWlmIChzYy0+c2NfcGlucykgeworCQlmcmVl KHNjLT5zY19waW5zLCBNX0RFVkJVRik7CisJCXNjLT5zY19waW5zID0gTlVMTDsKKwl9CiAKIAly ZXR1cm4gKDApOwogfQpAQCAtMjYwLDYgKzQ1Niw3IEBACiAJcmV0dmFsICs9IGJ1c19wcmludF9j aGlsZF9oZWFkZXIoZGV2LCBjaGlsZCk7CiAJcmV0dmFsICs9IHByaW50ZigiIGF0IHBpbihzKSAi KTsKIAlncGlvYnVzX3ByaW50X3BpbnMoZGV2aSk7CisJcmVzb3VyY2VfbGlzdF9wcmludF90eXBl KCZkZXZpLT5ybCwgImlycSIsIFNZU19SRVNfSVJRLCAiJWxkIik7CiAJcmV0dmFsICs9IGJ1c19w cmludF9jaGlsZF9mb290ZXIoZGV2LCBjaGlsZCk7CiAKIAlyZXR1cm4gKHJldHZhbCk7CkBAIC0y OTcsNiArNDk0LDcgQEAKIAkJZGV2aWNlX2RlbGV0ZV9jaGlsZChkZXYsIGNoaWxkKTsKIAkJcmV0 dXJuICgwKTsKIAl9CisJcmVzb3VyY2VfbGlzdF9pbml0KCZkZXZpLT5ybCk7CiAJZGV2aWNlX3Nl dF9pdmFycyhjaGlsZCwgZGV2aSk7CiAJcmV0dXJuIChjaGlsZCk7CiB9CkBAIC0zMDcsMTYgKzUw NSw0MiBAQAogCXN0cnVjdCBncGlvYnVzX3NvZnRjICpzYyA9IEdQSU9CVVNfU09GVEMoYnVzKTsK IAlzdHJ1Y3QgZ3Bpb2J1c19pdmFyICpkZXZpOwogCWRldmljZV90IGNoaWxkOwotCWludCBwaW5z OworCWludCBpcnEsIHBpbnM7CiAKLQogCWNoaWxkID0gQlVTX0FERF9DSElMRChidXMsIDAsIGRu YW1lLCBkdW5pdCk7CiAJZGV2aSA9IEdQSU9CVVNfSVZBUihjaGlsZCk7CiAJcmVzb3VyY2VfaW50 X3ZhbHVlKGRuYW1lLCBkdW5pdCwgInBpbnMiLCAmcGlucyk7CiAJaWYgKGdwaW9idXNfcGFyc2Vf cGlucyhzYywgY2hpbGQsIHBpbnMpKQogCQlkZXZpY2VfZGVsZXRlX2NoaWxkKGJ1cywgY2hpbGQp OworCWlmIChyZXNvdXJjZV9pbnRfdmFsdWUoZG5hbWUsIGR1bml0LCAiaXJxIiwgJmlycSkgPT0g MCkgeworCQlpZiAoYnVzX3NldF9yZXNvdXJjZShjaGlsZCwgU1lTX1JFU19JUlEsIDAsIGlycSwg MSkgIT0gMCkKKwkJCWRldmljZV9wcmludGYoYnVzLAorCQkJICAgICJ3YXJuaW5nOiBidXNfc2V0 X3Jlc291cmNlKCkgZmFpbGVkXG4iKTsKKwl9CiB9CiAKK3N0YXRpYyBpbnQKK2dwaW9idXNfc2V0 X3Jlc291cmNlKGRldmljZV90IGRldiwgZGV2aWNlX3QgY2hpbGQsIGludCB0eXBlLCBpbnQgcmlk LAorICAgIHVfbG9uZyBzdGFydCwgdV9sb25nIGNvdW50KQoreworCXN0cnVjdCBncGlvYnVzX2l2 YXIgKmRldmk7CisJc3RydWN0IHJlc291cmNlX2xpc3QgKnJsOworCXN0cnVjdCByZXNvdXJjZV9s aXN0X2VudHJ5ICpybGU7CisKKwlkZXZpID0gR1BJT0JVU19JVkFSKGNoaWxkKTsKKwlybCA9ICZk ZXZpLT5ybDsKKworCWRwcmludGYoIiVzOiBlbnRyeSAoJXAsICVwLCAlZCwgJWQsICVwLCAlbGQp XG4iLAorCSAgICBfX2Z1bmNfXywgZGV2LCBjaGlsZCwgdHlwZSwgcmlkLCAodm9pZCAqKShpbnRw dHJfdClzdGFydCwgY291bnQpOworCisJcmxlID0gcmVzb3VyY2VfbGlzdF9hZGQocmwsIHR5cGUs IHJpZCwgc3RhcnQsIHN0YXJ0ICsgY291bnQgLSAxLAorCSAgICBjb3VudCk7CisJaWYgKHJsZSA9 PSBOVUxMKQorCQlyZXR1cm4gKEVOWElPKTsKKworCXJldHVybiAoMCk7Cit9CisKIHN0YXRpYyB2 b2lkCiBncGlvYnVzX2xvY2tfYnVzKGRldmljZV90IGJ1c2RldikKIHsKQEAgLTQ0Myw2ICs2Njcs MTgwIEBACiAJcmV0dXJuIEdQSU9fUElOX1RPR0dMRShzYy0+c2NfZGV2LCBkZXZpLT5waW5zW3Bp bl0pOwogfQogCitzdGF0aWMgaW50CitncGlvYnVzX2ludHJfZmlsdGVyKHZvaWQgKmFyZykKK3sK KwlpbnQgcGluOworCXN0cnVjdCBncGlvYnVzX3Bpbl9hcmcgKmludHI7CisJc3RydWN0IGdwaW9i dXNfc29mdGMgKnNjOworCXN0cnVjdCBpbnRyX2V2ZW50ICpldmVudDsKKworCWludHIgPSAoc3Ry dWN0IGdwaW9idXNfcGluX2FyZyAqKWFyZzsKKwlzYyA9IGludHItPnNjOworCXBpbiA9IGludHIt PnBpbjsKKworCWV2ZW50ID0gc2MtPnNjX3BpbnNbcGluXS5ldmVudDsKKwlpZiAoZXZlbnQgPT0g TlVMTCB8fCBUQUlMUV9FTVBUWSgmZXZlbnQtPmllX2hhbmRsZXJzKSkgeworCQlkZXZpY2VfcHJp bnRmKHNjLT5zY19kZXYsICJTdHJheSBJUlEgJWRcbiIsIHBpbik7CisJCXJldHVybiAoRklMVEVS X0hBTkRMRUQpOworCX0KKworCWludHJfZXZlbnRfaGFuZGxlKGV2ZW50LCBOVUxMKTsKKworCXJl dHVybiAoRklMVEVSX1NDSEVEVUxFX1RIUkVBRCk7Cit9CisKK3N0YXRpYyB2b2lkCitncGlvYnVz X2ludHJfaXRocmVhZCh2b2lkICphcmcpCit7CisJaW50IHBpbjsKKwlzdHJ1Y3QgZ3Bpb2J1c19w aW5fYXJnICppbnRyOworCXN0cnVjdCBncGlvYnVzX3NvZnRjICpzYzsKKworCWludHIgPSAoc3Ry dWN0IGdwaW9idXNfcGluX2FyZyAqKWFyZzsKKwlzYyA9IGludHItPnNjOworCXBpbiA9IGludHIt PnBpbjsKKworCS8qIEFkZCAxIHRvIEdQSU8gcGluLCBhbGxvd2luZyB0aGUgdXNlIG9mIHBpbiAw LiAqLworCUtOT1RFX1VOTE9DS0VEKCZzYy0+c2NfcGluc1twaW5dLnNlbC5zaV9ub3RlLCBwaW4g KyAxKTsKK30KKworc3RhdGljIGludAorZ3Bpb2J1c19zZXR1cF9pbnRyKGRldmljZV90IGRldiwg ZGV2aWNlX3QgY2hpbGQsIHN0cnVjdCByZXNvdXJjZSAqaXJlcywKKwlpbnQgZmxhZ3MsIGRyaXZl cl9maWx0ZXJfdCAqZmlsdCwgZHJpdmVyX2ludHJfdCAqaGFuZGxlciwKKwl2b2lkICphcmcsIHZv aWQgKipjb29raWVwKQoreworCXN0cnVjdCBncGlvYnVzX3NvZnRjICpzYzsKKwlzdHJ1Y3QgaW50 cl9ldmVudCAqZXZlbnQ7CisJaW50IHBpbiwgZXJyb3I7CisKKwlzYyA9IEdQSU9CVVNfU09GVEMo ZGV2KTsKKwlwaW4gPSBybWFuX2dldF9zdGFydChpcmVzKTsKKworCWlmIChwaW4gPiBzYy0+c2Nf bnBpbnMpCisJCXBhbmljKCIlczogYmFkIHBpbiAlZCAobWF4OiAlZCkiLCBfX2Z1bmNfXywgcGlu LCBzYy0+c2NfbnBpbnMpOworCisJLyogU2V0dXAgdGhlIGNoaWxkIGludGVycnVwdCBmaWx0ZXIv aGFuZGxlci4gKi8KKwlldmVudCA9IHNjLT5zY19waW5zW3Bpbl0uZXZlbnQ7CisJaWYgKGV2ZW50 ID09IE5VTEwpIHsKKwkJZXJyb3IgPSBpbnRyX2V2ZW50X2NyZWF0ZSgmZXZlbnQsICh2b2lkICop KHVpbnRwdHJfdClwaW4sIDAsCisJCSAgICBwaW4sIE5VTEwsIE5VTEwsIE5VTEwsIE5VTEwsICJn cGlvYnVzJWQgcGluJWQ6IiwKKwkJICAgIGRldmljZV9nZXRfdW5pdChkZXYpLCBwaW4pOworCisJ CWlmIChlcnJvciAhPSAwKQorCQkJcmV0dXJuIChlcnJvcik7CisKKwkJc2MtPnNjX3BpbnNbcGlu XS5ldmVudCA9IGV2ZW50OworCX0KKworCWludHJfZXZlbnRfYWRkX2hhbmRsZXIoZXZlbnQsIGRl dmljZV9nZXRfbmFtZXVuaXQoY2hpbGQpLCBmaWx0LAorCSAgICBoYW5kbGVyLCBhcmcsIGludHJf cHJpb3JpdHkoZmxhZ3MpLCBmbGFncywgY29va2llcCk7CisKKwlzYy0+c2NfcGluX2FyZ1twaW5d LnNjID0gc2M7CisJc2MtPnNjX3Bpbl9hcmdbcGluXS5waW4gPSBwaW47CisKKwkvKiBBbmQgbm93 IHJlZ2lzdGVyIG91ciBpbnRlcnJ1cHQgZmlsdGVyLiAqLworCXJldHVybiAoQlVTX1NFVFVQX0lO VFIoZGV2aWNlX2dldF9wYXJlbnQoZGV2KSwgY2hpbGQsIGlyZXMsIGZsYWdzLAorCSAgICBncGlv YnVzX2ludHJfZmlsdGVyLCBncGlvYnVzX2ludHJfaXRocmVhZCwgJnNjLT5zY19waW5fYXJnW3Bp bl0sCisJICAgICZzYy0+c2NfcGluc1twaW5dLmlycV9oZGwpKTsKK30KKworc3RhdGljIGludAor Z3Bpb2J1c190ZWFyZG93bl9pbnRyKGRldmljZV90IGRldiwgZGV2aWNlX3QgY2hpbGQsIHN0cnVj dCByZXNvdXJjZSAqaXJlcywKKwl2b2lkICpjb29raWUpCit7CisJc3RydWN0IGdwaW9idXNfc29m dGMgKnNjOworCWludCBwaW4sIGVycjsKKworCXNjID0gR1BJT0JVU19TT0ZUQyhkZXYpOworCXBp biA9IHJtYW5fZ2V0X3N0YXJ0KGlyZXMpOworCisJaWYgKHBpbiA+IHNjLT5zY19ucGlucykKKwkJ cGFuaWMoIiVzOiBiYWQgcGluICVkIChtYXggJWQpIiwgX19mdW5jX18sIHBpbiwgc2MtPnNjX25w aW5zKTsKKworCWlmIChzYy0+c2NfcGluc1twaW5dLmV2ZW50ID09IE5VTEwpCisJCXBhbmljKCJU cnlpbmcgdG8gdGVhcmRvd24gdW5vY2N1cGllZCBJUlEiKTsKKworCWVyciA9IGludHJfZXZlbnRf cmVtb3ZlX2hhbmRsZXIoY29va2llKTsKKwlpZiAoZXJyKQorCQlyZXR1cm4gKGVycik7CisJc2Mt PnNjX3BpbnNbcGluXS5ldmVudCA9IE5VTEw7CisKKwlyZXR1cm4gKEJVU19URUFSRE9XTl9JTlRS KGRldmljZV9nZXRfcGFyZW50KGRldiksIGNoaWxkLCBpcmVzLAorCSAgICAmc2MtPnNjX3BpbnNb cGluXS5pcnFfaGRsKSk7Cit9CisKK3N0YXRpYyBzdHJ1Y3QgcmVzb3VyY2UgKgorZ3Bpb2J1c19h bGxvY19yZXNvdXJjZShkZXZpY2VfdCBidXMsIGRldmljZV90IGNoaWxkLCBpbnQgdHlwZSwgaW50 ICpyaWQsCisgICAgdV9sb25nIHN0YXJ0LCB1X2xvbmcgZW5kLCB1X2xvbmcgY291bnQsIHVfaW50 IGZsYWdzKQoreworCXN0cnVjdCBncGlvYnVzX3NvZnRjICpzYzsKKwlzdHJ1Y3QgcmVzb3VyY2Ug KnJ2OworCXN0cnVjdCByZXNvdXJjZV9saXN0ICpybDsKKwlzdHJ1Y3QgcmVzb3VyY2VfbGlzdF9l bnRyeSAqcmxlOworCWludCBpc2RlZmF1bHQ7CisKKwlpZiAodHlwZSAhPSBTWVNfUkVTX0lSUSkK KwkJcmV0dXJuIChOVUxMKTsKKworCWlzZGVmYXVsdCA9IChzdGFydCA9PSAwVUwgJiYgZW5kID09 IH4wVUwgJiYgY291bnQgPT0gMSk7CisJcmxlID0gTlVMTDsKKworCWlmIChpc2RlZmF1bHQpIHsK KwkJcmwgPSBCVVNfR0VUX1JFU09VUkNFX0xJU1QoYnVzLCBjaGlsZCk7CisJCWlmIChybCA9PSBO VUxMKQorCQkJcmV0dXJuIChOVUxMKTsKKwkJcmxlID0gcmVzb3VyY2VfbGlzdF9maW5kKHJsLCB0 eXBlLCAqcmlkKTsKKwkJaWYgKHJsZSA9PSBOVUxMKQorCQkJcmV0dXJuIChOVUxMKTsKKwkJaWYg KHJsZS0+cmVzICE9IE5VTEwpCisJCQlwYW5pYygiJXM6IHJlc291cmNlIGVudHJ5IGlzIGJ1c3ki LCBfX2Z1bmNfXyk7CisJCXN0YXJ0ID0gcmxlLT5zdGFydDsKKwkJY291bnQgPSBybGUtPmNvdW50 OworCQllbmQgPSBybGUtPmVuZDsKKwl9CisKKwlzYyA9IGRldmljZV9nZXRfc29mdGMoYnVzKTsK KwlydiA9IHJtYW5fcmVzZXJ2ZV9yZXNvdXJjZSgmc2MtPnNjX2ludHJfcm1hbiwgc3RhcnQsIGVu ZCwgY291bnQsIGZsYWdzLAorCSAgICBjaGlsZCk7CisJaWYgKHJ2ID09IE5VTEwpCisJCXJldHVy biAoTlVMTCk7CisJcm1hbl9zZXRfcmlkKHJ2LCAqcmlkKTsKKworCWlmICgoZmxhZ3MgJiBSRl9B Q1RJVkUpICE9IDAgJiYKKwkgICAgYnVzX2FjdGl2YXRlX3Jlc291cmNlKGNoaWxkLCB0eXBlLCAq cmlkLCBydikgIT0gMCkgeworCQlybWFuX3JlbGVhc2VfcmVzb3VyY2UocnYpOworCQlyZXR1cm4g KE5VTEwpOworCX0KKworCXJldHVybiAocnYpOworfQorCitzdGF0aWMgaW50CitncGlvYnVzX3Jl bGVhc2VfcmVzb3VyY2UoZGV2aWNlX3QgYnVzIF9fdW51c2VkLCBkZXZpY2VfdCBjaGlsZCwgaW50 IHR5cGUsCisgICAgaW50IHJpZCwgc3RydWN0IHJlc291cmNlICpyKQoreworCWludCBlcnJvcjsK KworCWlmICgocm1hbl9nZXRfZmxhZ3MocikgJiBSRl9BQ1RJVkUpICE9IDApIHsKKwkJZXJyb3Ig PSBidXNfZGVhY3RpdmF0ZV9yZXNvdXJjZShjaGlsZCwgdHlwZSwgcmlkLCByKTsKKwkJaWYgKGVy cm9yKQorCQkJcmV0dXJuIChlcnJvcik7CisJfQorCisJcmV0dXJuIChybWFuX3JlbGVhc2VfcmVz b3VyY2UocikpOworfQorCitzdGF0aWMgc3RydWN0IHJlc291cmNlX2xpc3QgKgorZ3Bpb2J1c19n ZXRfcmVzb3VyY2VfbGlzdChkZXZpY2VfdCBidXMgX191bnVzZWQsIGRldmljZV90IGNoaWxkKQor eworCXN0cnVjdCBncGlvYnVzX2l2YXIgKml2YXI7CisKKwlpdmFyID0gR1BJT0JVU19JVkFSKGNo aWxkKTsKKworCXJldHVybiAoJml2YXItPnJsKTsKK30KKwogc3RhdGljIGRldmljZV9tZXRob2Rf dCBncGlvYnVzX21ldGhvZHNbXSA9IHsKIAkvKiBEZXZpY2UgaW50ZXJmYWNlICovCiAJREVWTUVU SE9EKGRldmljZV9wcm9iZSwJCWdwaW9idXNfcHJvYmUpLApAQCAtNDUzLDYgKzg1MSwxNSBAQAog CURFVk1FVEhPRChkZXZpY2VfcmVzdW1lLAlncGlvYnVzX3Jlc3VtZSksCiAKIAkvKiBCdXMgaW50 ZXJmYWNlICovCisJREVWTUVUSE9EKGJ1c19zZXR1cF9pbnRyLAlncGlvYnVzX3NldHVwX2ludHIp LAorCURFVk1FVEhPRChidXNfY29uZmlnX2ludHIsCWJ1c19nZW5lcmljX2NvbmZpZ19pbnRyKSwK KwlERVZNRVRIT0QoYnVzX3RlYXJkb3duX2ludHIsCWdwaW9idXNfdGVhcmRvd25faW50ciksCisJ REVWTUVUSE9EKGJ1c19zZXRfcmVzb3VyY2UsCWdwaW9idXNfc2V0X3Jlc291cmNlKSwKKwlERVZN RVRIT0QoYnVzX2FsbG9jX3Jlc291cmNlLAlncGlvYnVzX2FsbG9jX3Jlc291cmNlKSwKKwlERVZN RVRIT0QoYnVzX3JlbGVhc2VfcmVzb3VyY2UsCWdwaW9idXNfcmVsZWFzZV9yZXNvdXJjZSksCisJ REVWTUVUSE9EKGJ1c19hY3RpdmF0ZV9yZXNvdXJjZSwJYnVzX2dlbmVyaWNfYWN0aXZhdGVfcmVz b3VyY2UpLAorCURFVk1FVEhPRChidXNfZGVhY3RpdmF0ZV9yZXNvdXJjZSwJYnVzX2dlbmVyaWNf ZGVhY3RpdmF0ZV9yZXNvdXJjZSksCisJREVWTUVUSE9EKGJ1c19nZXRfcmVzb3VyY2VfbGlzdCwJ Z3Bpb2J1c19nZXRfcmVzb3VyY2VfbGlzdCksCiAJREVWTUVUSE9EKGJ1c19hZGRfY2hpbGQsCWdw aW9idXNfYWRkX2NoaWxkKSwKIAlERVZNRVRIT0QoYnVzX3ByaW50X2NoaWxkLAlncGlvYnVzX3By aW50X2NoaWxkKSwKIAlERVZNRVRIT0QoYnVzX2NoaWxkX3BucGluZm9fc3RyLCBncGlvYnVzX2No aWxkX3BucGluZm9fc3RyKSwKSW5kZXg6IHN5cy9kZXYvZ3Bpby9ncGlvYnVzdmFyLmgKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQotLS0gc3lzL2Rldi9ncGlvL2dwaW9idXN2YXIuaAkocmV2aXNpb24gMjY1ODE3KQorKysg c3lzL2Rldi9ncGlvL2dwaW9idXN2YXIuaAkod29ya2luZyBjb3B5KQpAQCAtMzIsOCArMzIsMTEg QEAKIAogI2luY2x1ZGUgIm9wdF9wbGF0Zm9ybS5oIgogCisjaW5jbHVkZSA8c3lzL2ludGVycnVw dC5oPgogI2luY2x1ZGUgPHN5cy9sb2NrLmg+CiAjaW5jbHVkZSA8c3lzL211dGV4Lmg+CisjaW5j bHVkZSA8c3lzL3JtYW4uaD4KKyNpbmNsdWRlIDxzeXMvc2VsaW5mby5oPgogCiAjaWZkZWYgRkRU CiAjaW5jbHVkZSA8ZGV2L29mdy9vZndfYnVzX3N1YnIuaD4KQEAgLTQxLDcgKzQ0LDEyIEBACiAK ICNpbmNsdWRlICJncGlvX2lmLmgiCiAKKyNpZmRlZiBGRFQKKyNkZWZpbmUJR1BJT0JVU19JVkFS KGQpIChzdHJ1Y3QgZ3Bpb2J1c19pdmFyICopCQkJCVwKKwkmKChzdHJ1Y3Qgb2Z3X2dwaW9idXNf ZGV2aW5mbyAqKWRldmljZV9nZXRfaXZhcnMoZCkpLT5vcGRfZGluZm8KKyNlbHNlCiAjZGVmaW5l CUdQSU9CVVNfSVZBUihkKSAoc3RydWN0IGdwaW9idXNfaXZhciAqKSBkZXZpY2VfZ2V0X2l2YXJz KGQpCisjZW5kaWYKICNkZWZpbmUJR1BJT0JVU19TT0ZUQyhkKSAoc3RydWN0IGdwaW9idXNfc29m dGMgKikgZGV2aWNlX2dldF9zb2Z0YyhkKQogI2RlZmluZQlHUElPQlVTX0xPQ0soX3NjKSBtdHhf bG9jaygmKF9zYyktPnNjX210eCkKICNkZWZpbmUJR1BJT0JVU19VTkxPQ0soX3NjKSBtdHhfdW5s b2NrKCYoX3NjKS0+c2NfbXR4KQpAQCAtNTEsMTggKzU5LDM4IEBACiAjZGVmaW5lCUdQSU9CVVNf QVNTRVJUX0xPQ0tFRChfc2MpIG10eF9hc3NlcnQoJl9zYy0+c2NfbXR4LCBNQV9PV05FRCkKICNk ZWZpbmUJR1BJT0JVU19BU1NFUlRfVU5MT0NLRUQoX3NjKSBtdHhfYXNzZXJ0KCZfc2MtPnNjX210 eCwgTUFfTk9UT1dORUQpCiAKK3N0cnVjdCBncGlvYnVzX3NvZnRjOworCitzdHJ1Y3QgZ3Bpb2J1 c19waW5fYXJnCit7CisJc3RydWN0IGdwaW9idXNfc29mdGMgKnNjOworCWludCBwaW47Cit9Owor CitzdHJ1Y3QgZ3Bpb2J1c19waW4KK3sKKwlzdHJ1Y3QgaW50cl9ldmVudAkqZXZlbnQ7CS8qIGlz ciBldmVudCAqLworCXN0cnVjdCBzZWxpbmZvCXNlbDsJCS8qIGtubGlzdCBkYXRhICovCisJaW50 CQltYXBwZWQ7CQkvKiBwaW4gaXMgbWFwcGVkID8gKi8KKwl2b2lkCQkqaXJxX2hkbDsJLyogaXNy IGhhbmRsZXIgY29va2llICovCit9OworCiBzdHJ1Y3QgZ3Bpb2J1c19zb2Z0YwogeworCXN0cnVj dCBjZGV2CSpzY19jdGxfZGV2OwkvKiBjb250cm9sbGVyIGRldmljZSAqLwogCXN0cnVjdCBtdHgJ c2NfbXR4OwkJLyogYnVzIG11dGV4ICovCisJc3RydWN0IGdwaW9idXNfcGluCSpzY19waW5zOyAv KiBncGlvYnVzIHBpbnMgKi8KKwlzdHJ1Y3QgZ3Bpb2J1c19waW5fYXJnCSpzY19waW5fYXJnOyAv KiBpc3IgYXJnICovCisJc3RydWN0IHJtYW4Jc2NfaW50cl9ybWFuOwkvKiBpc3IgcmVzb3VyY2Vz ICovCiAJZGV2aWNlX3QJc2NfYnVzZGV2OwkvKiBidXMgZGV2aWNlICovCiAJZGV2aWNlX3QJc2Nf b3duZXI7CS8qIGJ1cyBvd25lciAqLwogCWRldmljZV90CXNjX2RldjsJCS8qIGRyaXZlciBkZXZp Y2UgKi8KIAlpbnQJCXNjX25waW5zOwkvKiB0b3RhbCBwaW5zIG9uIGJ1cyAqLwotCWludAkJKnNj X3BpbnNfbWFwcGVkOyAvKiBtYXJrIG1hcHBlZCBwaW5zICovCiB9OwogCiBzdHJ1Y3QgZ3Bpb2J1 c19pdmFyCiB7CisJc3RydWN0IHJlc291cmNlX2xpc3QJcmw7CS8qIGlzciByZXNvdXJjZSBsaXN0 ICovCiAJdWludDMyX3QJbnBpbnM7CS8qIHBpbnMgdG90YWwgKi8KIAl1aW50MzJfdAkqZmxhZ3M7 CS8qIHBpbnMgZmxhZ3MgKi8KIAl1aW50MzJfdAkqcGluczsJLyogcGlucyBtYXAgKi8KQEAgLTg0 LDYgKzExMiw3IEBACiBkZXZpY2VfdCBvZndfZ3Bpb2J1c19hZGRfZmR0X2NoaWxkKGRldmljZV90 LCBwaGFuZGxlX3QpOwogI2VuZGlmCiB2b2lkIGdwaW9idXNfcHJpbnRfcGlucyhzdHJ1Y3QgZ3Bp b2J1c19pdmFyICopOworaW50IGdwaW9idXNfaW5pdF9zb2Z0YyhkZXZpY2VfdCk7CiAKIGV4dGVy biBkcml2ZXJfdCBncGlvYnVzX2RyaXZlcjsKIApJbmRleDogc3lzL2Rldi9ncGlvL29md19ncGlv YnVzLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQotLS0gc3lzL2Rldi9ncGlvL29md19ncGlvYnVzLmMJKHJldmlzaW9u IDI2NTgxNykKKysrIHN5cy9kZXYvZ3Bpby9vZndfZ3Bpb2J1cy5jCSh3b3JraW5nIGNvcHkpCkBA IC0xMDMsNiArMTAzLDcgQEAKIAlpbnQgY2VsbHMsIGksIGosIGxlbjsKIAlwY2VsbF90ICpncGlv czsKIAlwaGFuZGxlX3QgZ3BpbzsKKwlzdHJ1Y3QgZ3Bpb2J1c19waW4gKnBpbjsKIAogCS8qIFJl dHJpZXZlIHRoZSBncGlvcyBwcm9wZXJ0eS4gKi8KIAlpZiAoKGxlbiA9IE9GX2dldHByb3BsZW4o Y2hpbGQsICJncGlvcyIpKSA8IDApCkBAIC0xOTUsMTAgKzE5NiwxMiBAQAogCQkJcmV0dXJuIChF SU5WQUwpOwogCQl9CiAKKwkJcGluID0gJnNjLT5zY19waW5zW2RpbmZvLT5waW5zW2pdXTsKKwog CQkvKgogCQkgKiBNYXJrIHBpbiBhcyBtYXBwZWQgYW5kIGdpdmUgd2FybmluZyBpZiBpdCdzIGFs cmVhZHkgbWFwcGVkLgogCQkgKi8KLQkJaWYgKHNjLT5zY19waW5zX21hcHBlZFtkaW5mby0+cGlu c1tqXV0pIHsKKwkJaWYgKHBpbi0+bWFwcGVkKSB7CiAJCQlkZXZpY2VfcHJpbnRmKHNjLT5zY19i dXNkZXYsCiAJCQkgICAgIndhcm5pbmc6IHBpbiAlZCBpcyBhbHJlYWR5IG1hcHBlZFxuIiwKIAkJ CSAgICBkaW5mby0+cGluc1tqXSk7CkBAIC0yMDYsNyArMjA5LDcgQEAKIAkJCWZyZWUoZ3Bpb3Ms IE1fREVWQlVGKTsKIAkJCXJldHVybiAoRUlOVkFMKTsKIAkJfQotCQlzYy0+c2NfcGluc19tYXBw ZWRbZGluZm8tPnBpbnNbal1dID0gMTsKKwkJcGluLT5tYXBwZWQgPSAxOwogCiAJCWkgKz0gY2Vs bHMgKyAxOwogCQlqKys7CkBAIC0yMjIsNiArMjI1LDkgQEAKIHsKIAlzdHJ1Y3QgZ3Bpb2J1c19z b2Z0YyAqc2M7CiAJc3RydWN0IG9md19ncGlvYnVzX2RldmluZm8gKmRpbmZvOworCXVpbnQzMl90 ICppbnRyLCBpY2VsbHM7CisJcGhhbmRsZV90IGlwYXJlbnQ7CisJaW50IGksIG5pbnRyOwogCiAJ c2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CiAJZGluZm8gPSBtYWxsb2Moc2l6ZW9mKCpkaW5m byksIE1fREVWQlVGLCBNX05PV0FJVCB8IE1fWkVSTyk7CkBAIC0yMzksNiArMjQ1LDI0IEBACiAJ CXJldHVybiAoTlVMTCk7CiAJfQogCisJcmVzb3VyY2VfbGlzdF9pbml0KCZkaW5mby0+b3BkX2Rp bmZvLnJsKTsKKwluaW50ciA9IE9GX2dldGVuY3Byb3BfYWxsb2Mobm9kZSwgImludGVycnVwdHMi LCAgc2l6ZW9mKCppbnRyKSwKKwkgICAgKHZvaWQgKiopJmludHIpOworCWlmIChuaW50ciA+IDAp IHsKKwkJaXBhcmVudCA9IDA7CisJCU9GX3NlYXJjaGVuY3Byb3Aobm9kZSwgImludGVycnVwdC1w YXJlbnQiLCAmaXBhcmVudCwKKwkJICAgIHNpemVvZihpcGFyZW50KSk7CisJCU9GX3NlYXJjaGVu Y3Byb3AoT0ZfeHJlZl9waGFuZGxlKGlwYXJlbnQpLCAiI2ludGVycnVwdC1jZWxscyIsCisJCSAg ICAmaWNlbGxzLCBzaXplb2YoaWNlbGxzKSk7CisJCWZvciAoaSA9IDA7IGkgPCBuaW50cjsgaSs9 IGljZWxscykgeworCQkJaW50cltpXSA9IG9md19idXNfbWFwX2ludHIoZGV2LCBpcGFyZW50LCBp Y2VsbHMsCisJCQkgICAgJmludHJbaV0pOworCQkJcmVzb3VyY2VfbGlzdF9hZGQoJmRpbmZvLT5v cGRfZGluZm8ucmwsIFNZU19SRVNfSVJRLAorCQkJICAgIGksIGludHJbaV0sIGludHJbaV0sIDEp OworCQl9CisJCWZyZWUoaW50ciwgTV9PRldQUk9QKTsKKwl9CisKIAlyZXR1cm4gKGRpbmZvKTsK IH0KIApAQCAtMjQ2LDYgKzI3MCw3IEBACiBvZndfZ3Bpb2J1c19kZXN0cm95X2RldmluZm8oc3Ry dWN0IG9md19ncGlvYnVzX2RldmluZm8gKmRpbmZvKQogewogCisJcmVzb3VyY2VfbGlzdF9mcmVl KCZkaW5mby0+b3BkX2RpbmZvLnJsKTsKIAlvZndfYnVzX2dlbl9kZXN0cm95X2RldmluZm8oJmRp bmZvLT5vcGRfb2JkaW5mbyk7CiAJZnJlZShkaW5mbywgTV9ERVZCVUYpOwogfQpAQCAtMjY0LDMz ICsyODksMTMgQEAKIHN0YXRpYyBpbnQKIG9md19ncGlvYnVzX2F0dGFjaChkZXZpY2VfdCBkZXYp CiB7Ci0Jc3RydWN0IGdwaW9idXNfc29mdGMgKnNjOworCWludCBlcnI7CiAJcGhhbmRsZV90IGNo aWxkOwogCi0Jc2MgPSBHUElPQlVTX1NPRlRDKGRldik7Ci0Jc2MtPnNjX2J1c2RldiA9IGRldjsK LQlzYy0+c2NfZGV2ID0gZGV2aWNlX2dldF9wYXJlbnQoZGV2KTsKKwllcnIgPSBncGlvYnVzX2lu aXRfc29mdGMoZGV2KTsKKwlpZiAoZXJyICE9IDApCisJCXJldHVybiAoZXJyKTsKIAotCS8qIFJl YWQgdGhlIHBpbiBtYXguIHZhbHVlICovCi0JaWYgKEdQSU9fUElOX01BWChzYy0+c2NfZGV2LCAm c2MtPnNjX25waW5zKSAhPSAwKQotCQlyZXR1cm4gKEVOWElPKTsKLQotCUtBU1NFUlQoc2MtPnNj X25waW5zICE9IDAsICgiR1BJTyBkZXZpY2Ugd2l0aCBubyBwaW5zIikpOwotCi0JLyoKLQkgKiBJ bmNyZWFzZSB0byBnZXQgbnVtYmVyIG9mIHBpbnMuCi0JICovCi0Jc2MtPnNjX25waW5zKys7Ci0K LQlzYy0+c2NfcGluc19tYXBwZWQgPSBtYWxsb2Moc2l6ZW9mKGludCkgKiBzYy0+c2NfbnBpbnMs IE1fREVWQlVGLCAKLQkgICAgTV9OT1dBSVQgfCBNX1pFUk8pOwotCi0JaWYgKCFzYy0+c2NfcGlu c19tYXBwZWQpCi0JCXJldHVybiAoRU5PTUVNKTsKLQotCS8qIEluaXQgdGhlIGJ1cyBsb2NrLiAq LwotCUdQSU9CVVNfTE9DS19JTklUKHNjKTsKLQogCWJ1c19nZW5lcmljX3Byb2JlKGRldik7CiAJ YnVzX2VudW1lcmF0ZV9oaW50ZWRfY2hpbGRyZW4oZGV2KTsKIApAQCAtMzQ2LDYgKzM1MSw4IEBA CiAJcmV0dmFsICs9IGJ1c19wcmludF9jaGlsZF9oZWFkZXIoZGV2LCBjaGlsZCk7CiAJcmV0dmFs ICs9IHByaW50ZigiIGF0IHBpbihzKSAiKTsKIAlncGlvYnVzX3ByaW50X3BpbnMoJmRldmktPm9w ZF9kaW5mbyk7CisJcmVzb3VyY2VfbGlzdF9wcmludF90eXBlKCZkZXZpLT5vcGRfZGluZm8ucmws ICJpcnEiLCBTWVNfUkVTX0lSUSwKKwkgICAgIiVsZCIpOwogCXJldHZhbCArPSBidXNfcHJpbnRf Y2hpbGRfZm9vdGVyKGRldiwgY2hpbGQpOwogCiAJcmV0dXJuIChyZXR2YWwpOwo= --001a11c335ce38a5b404f96138f2 Content-Type: text/plain; charset=US-ASCII; name="ti_gpio-intr.diff" Content-Disposition: attachment; filename="ti_gpio-intr.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hv6zeuvh4 SW5kZXg6IHN5cy9hcm0vdGkvdGlfZ3Bpby5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9hcm0vdGkvdGlf Z3Bpby5jCShyZXZpc2lvbiAyNjU4NDIpCisrKyBzeXMvYXJtL3RpL3RpX2dwaW8uYwkod29ya2lu ZyBjb3B5KQpAQCAtNTIsNiArNTIsNyBAQAogI2luY2x1ZGUgPHN5cy9sb2NrLmg+CiAjaW5jbHVk ZSA8c3lzL211dGV4Lmg+CiAjaW5jbHVkZSA8c3lzL2dwaW8uaD4KKyNpbmNsdWRlIDxzeXMvaW50 ZXJydXB0Lmg+CiAKICNpbmNsdWRlIDxtYWNoaW5lL2J1cy5oPgogI2luY2x1ZGUgPG1hY2hpbmUv cmVzb3VyY2UuaD4KQEAgLTE0OCw2ICsxNDksNyBAQAogI2VuZGlmCiAjZGVmaW5lCVBJTlNfUEVS X0JBTksJCQkzMgogI2RlZmluZQlNQVhfR1BJT19JTlRSUwkJCU1BWF9HUElPX0JBTktTICogSU5U Ul9QRVJfQkFOSworI2RlZmluZQlNQVhfR1BJT19QSU5TCQkJTUFYX0dQSU9fQkFOS1MgKiBQSU5T X1BFUl9CQU5LCiAKIC8qKgogICoJdGlfZ3Bpb19tZW1fc3BlYyAtIFJlc291cmNlIHNwZWNpZmlj YXRpb24gdXNlZCB3aGVuIGFsbG9jYXRpbmcgcmVzb3VyY2VzCkBAIC0xOTgsNiArMjAwLDEwIEBA CiBzdHJ1Y3QgdGlfZ3Bpb19zb2Z0YyB7CiAJZGV2aWNlX3QJCXNjX2RldjsKIAorCS8qIEludGVy cnVwdCB0cmlnZ2VyIHR5cGUgYW5kIGxldmVsLiAqLworCWVudW0gaW50cl90cmlnZ2VyCXNjX2ly cV90cmlnZ2VyW01BWF9HUElPX1BJTlNdOworCWVudW0gaW50cl9wb2xhcml0eQlzY19pcnFfcG9s YXJpdHlbTUFYX0dQSU9fUElOU107CisKIAkvKgogCSAqIFRoZSBtZW1vcnkgcmVzb3VyY2Uocykg Zm9yIHRoZSBQUkNNIHJlZ2lzdGVyIHNldCwgd2hlbiB0aGUgZGV2aWNlIGlzCiAJICogY3JlYXRl ZCB0aGUgY2FsbGVyIGNhbiBhc3NpZ24gdXAgdG8gNiBtZW1vcnkgcmVnaW9ucyBkZXBlbmRpbmcg b24KQEAgLTIwNiw2ICsyMTIsOSBAQAogCXN0cnVjdCByZXNvdXJjZQkJKnNjX21lbV9yZXNbTUFY X0dQSU9fQkFOS1NdOwogCXN0cnVjdCByZXNvdXJjZQkJKnNjX2lycV9yZXNbTUFYX0dQSU9fSU5U UlNdOwogCisJLyogSW50ZXJydXB0IGV2ZW50cy4gKi8KKwlzdHJ1Y3QgaW50cl9ldmVudAkqc2Nf ZXZlbnRzW01BWF9HUElPX1BJTlNdOworCiAJLyogVGhlIGhhbmRsZSBmb3IgdGhlIHJlZ2lzdGVy IElSUSBoYW5kbGVycy4gKi8KIAl2b2lkCQkJKnNjX2lycV9oZGxbTUFYX0dQSU9fSU5UUlNdOwog CkBAIC0yMjAsMTUgKzIyOSwxNyBAQAogLyoqCiAgKglNYWNyb3MgZm9yIGRyaXZlciBtdXRleCBs b2NraW5nCiAgKi8KLSNkZWZpbmUJVElfR1BJT19MT0NLKF9zYykJCW10eF9sb2NrKCYoX3NjKS0+ c2NfbXR4KQotI2RlZmluZQlUSV9HUElPX1VOTE9DSyhfc2MpCQltdHhfdW5sb2NrKCYoX3NjKS0+ c2NfbXR4KQorI2RlZmluZQlUSV9HUElPX0xPQ0soX3NjKQkJbXR4X2xvY2tfc3BpbigmKF9zYykt PnNjX210eCkKKyNkZWZpbmUJVElfR1BJT19VTkxPQ0soX3NjKQkJbXR4X3VubG9ja19zcGluKCYo X3NjKS0+c2NfbXR4KQogI2RlZmluZQlUSV9HUElPX0xPQ0tfSU5JVChfc2MpCQlcCiAJbXR4X2lu aXQoJl9zYy0+c2NfbXR4LCBkZXZpY2VfZ2V0X25hbWV1bml0KF9zYy0+c2NfZGV2KSwgXAotCSAg ICAidGlfZ3BpbyIsIE1UWF9ERUYpCisJICAgICJ0aV9ncGlvIiwgTVRYX1NQSU4pCiAjZGVmaW5l CVRJX0dQSU9fTE9DS19ERVNUUk9ZKF9zYykJbXR4X2Rlc3Ryb3koJl9zYy0+c2NfbXR4KQogI2Rl ZmluZQlUSV9HUElPX0FTU0VSVF9MT0NLRUQoX3NjKQltdHhfYXNzZXJ0KCZfc2MtPnNjX210eCwg TUFfT1dORUQpCiAjZGVmaW5lCVRJX0dQSU9fQVNTRVJUX1VOTE9DS0VEKF9zYykJbXR4X2Fzc2Vy dCgmX3NjLT5zY19tdHgsIE1BX05PVE9XTkVEKQogCitzdGF0aWMgc3RydWN0IHRpX2dwaW9fc29m dGMgKnRpX2dwaW9fc2MgPSBOVUxMOworCiAvKioKICAqCXRpX2dwaW9fcmVhZF80IC0gcmVhZHMg YSAxNi1iaXQgdmFsdWUgZnJvbSBvbmUgb2YgdGhlIFBBRENPTkZTIHJlZ2lzdGVycwogICoJQHNj OiBHUElPIGRldmljZSBjb250ZXh0CkBAIC0yNzYsNiArMjg3LDUwIEBACiAjZW5kaWYKIH0KIAor c3RhdGljIGlubGluZSB2b2lkCit0aV9ncGlvX2ludHJfc2V0KHN0cnVjdCB0aV9ncGlvX3NvZnRj ICpzYywgdW5zaWduZWQgaW50IGJhbmssIHVpbnQzMl90IG1hc2spCit7CisKKwkvKgorCSAqIE9u IE9NQVAzIGFuZCBPTUFQNCB3ZSB1bm1hc2sgb25seSB0aGUgTVBVIGludGVycnVwdCBhbmQgb24g QU0zMzV4CisJICogd2UgYWxzbyBhY3RpdmF0ZSBvbmx5IHRoZSBmaXJzdCBpbnRlcnJ1cHQuCisJ ICovCisjaWYgZGVmaW5lZChTT0NfT01BUDQpIHx8IGRlZmluZWQoU09DX1RJX0FNMzM1WCkKKwl0 aV9ncGlvX3dyaXRlXzQoc2MsIGJhbmssIFRJX0dQSU9fSVJRU1RBVFVTX1NFVF8wLCBtYXNrKTsK KyNlbHNlCisJdGlfZ3Bpb193cml0ZV80KHNjLCBiYW5rLCBUSV9HUElPX0NMRUFSSVJRRU5BQkxF MSwgbWFzayk7CisjZW5kaWYKK30KKworc3RhdGljIGlubGluZSB2b2lkCit0aV9ncGlvX2ludHJf YWNrKHN0cnVjdCB0aV9ncGlvX3NvZnRjICpzYywgdW5zaWduZWQgaW50IGJhbmssIHVpbnQzMl90 IG1hc2spCit7CisKKyNpZiBkZWZpbmVkKFNPQ19PTUFQNCkgfHwgZGVmaW5lZChTT0NfVElfQU0z MzVYKQorCXRpX2dwaW9fd3JpdGVfNChzYywgYmFuaywgVElfR1BJT19JUlFTVEFUVVNfMCwgbWFz ayk7CisJdGlfZ3Bpb193cml0ZV80KHNjLCBiYW5rLCBUSV9HUElPX0lSUVNUQVRVU18xLCBtYXNr KTsKKyNlbHNlCisJdGlfZ3Bpb193cml0ZV80KHNjLCBiYW5rLCBUSV9HUElPX0lSUVNUQVRVUzEs IG1hc2spOworCXRpX2dwaW9fd3JpdGVfNChzYywgYmFuaywgVElfR1BJT19JUlFTVEFUVVMyLCBt YXNrKTsKKyNlbmRpZgorfQorCitzdGF0aWMgaW5saW5lIHVpbnQzMl90Cit0aV9ncGlvX2ludHJf c3RhdHVzKHN0cnVjdCB0aV9ncGlvX3NvZnRjICpzYywgdW5zaWduZWQgaW50IGJhbmspCit7CisJ dWludDMyX3QgcmVnOworCisjaWYgZGVmaW5lZChTT0NfT01BUDQpIHx8IGRlZmluZWQoU09DX1RJ X0FNMzM1WCkKKwlyZWcgPSB0aV9ncGlvX3JlYWRfNChzYywgYmFuaywgVElfR1BJT19JUlFTVEFU VVNfMCk7CisJcmVnIHw9IHRpX2dwaW9fcmVhZF80KHNjLCBiYW5rLCBUSV9HUElPX0lSUVNUQVRV U18xKTsKKyNlbHNlCisJcmVnID0gdGlfZ3Bpb19yZWFkXzQoc2MsIGJhbmssIFRJX0dQSU9fSVJR U1RBVFVTMSk7CisJcmVnIHw9IHRpX2dwaW9fcmVhZF80KHNjLCBiYW5rLCBUSV9HUElPX0lSUVNU QVRVUzIpOworI2VuZGlmCisKKwlyZXR1cm4gKHJlZyk7Cit9CisKIC8qKgogICoJdGlfZ3Bpb19w aW5fbWF4IC0gUmV0dXJucyB0aGUgbWF4aW11bSBudW1iZXIgb2YgR1BJTyBwaW5zCiAgKglAZGV2 OiBncGlvIGRldmljZSBoYW5kbGUKQEAgLTYyNSwxNCArNjgwLDQyIEBACiAgKglJbnRlcm5hbGx5 IGxvY2tzIHRoZSBjb250ZXh0CiAgKgogICovCi1zdGF0aWMgdm9pZAorc3RhdGljIGludAogdGlf Z3Bpb19pbnRyKHZvaWQgKmFyZykKIHsKLQlzdHJ1Y3QgdGlfZ3Bpb19zb2Z0YyAqc2MgPSBhcmc7 CisJaW50IGJhbmssIGJhbmtfbGFzdCwgaXJxOworCXN0cnVjdCBpbnRyX2V2ZW50ICpldmVudDsK KwlzdHJ1Y3QgdGlfZ3Bpb19zb2Z0YyAqc2M7CisJdWludDMyX3QgbWFzaywgcmVnOwogCi0JVElf R1BJT19MT0NLKHNjKTsKLQkvKiBUT0RPOiBzb21ldGhpbmcgdXNlZnVsICovCi0JVElfR1BJT19V TkxPQ0soc2MpOworCXNjID0gKHN0cnVjdCB0aV9ncGlvX3NvZnRjICopYXJnOworCisJYmFua19s YXN0ID0gLTE7CisJZm9yIChpcnEgPSAwOyBpcnEgPCBNQVhfR1BJT19QSU5TOyBpcnErKykgewor CisJCWJhbmsgPSBpcnEgLyBQSU5TX1BFUl9CQU5LOworCQltYXNrID0gKDFVTCA8PCAoaXJxICUg UElOU19QRVJfQkFOSykpOworCisJCWlmIChiYW5rICE9IGJhbmtfbGFzdCkgeworCQkJcmVnID0g dGlfZ3Bpb19pbnRyX3N0YXR1cyhzYywgYmFuayk7CisJCQliYW5rX2xhc3QgPSBiYW5rOworCQl9 CisKKwkJaWYgKHJlZyAmIG1hc2spIHsKKwkJCWV2ZW50ID0gc2MtPnNjX2V2ZW50c1tpcnFdOwor CQkJaWYgKGV2ZW50ICE9IE5VTEwgJiYgIVRBSUxRX0VNUFRZKCZldmVudC0+aWVfaGFuZGxlcnMp KQorCQkJCWludHJfZXZlbnRfaGFuZGxlKGV2ZW50LCBOVUxMKTsKKwkJCWVsc2UgeworCQkJCWRl dmljZV9wcmludGYoc2MtPnNjX2RldiwgIlN0cmF5IElSUSAlZFxuIiwKKwkJCQkgICAgaXJxKTsK KwkJCX0KKworCQkJLyogQWNrIHRoZSBJUlEgU3RhdHVzIGJpdC4gKi8KKwkJCXRpX2dwaW9faW50 cl9hY2soc2MsIGJhbmssIG1hc2spOworCQl9CisJfQorCisJcmV0dXJuIChGSUxURVJfSEFORExF RCk7CiB9CiAKIC8qKgpAQCAtNjc0LDEzICs3NTcsMTMgQEAKIAkJCWJyZWFrOwogCiAJCS8qCi0J CSAqIFJlZ2lzdGVyIG91ciBpbnRlcnJ1cHQgaGFuZGxlciBmb3IgZWFjaCBvZiB0aGUgSVJRIHJl c291cmNlcy4KKwkJICogUmVnaXN0ZXIgb3VyIGludGVycnVwdCBmaWx0ZXIgZm9yIGVhY2ggb2Yg dGhlIElSUSByZXNvdXJjZXMuCiAJCSAqLwogCQlpZiAoYnVzX3NldHVwX2ludHIoZGV2LCBzYy0+ c2NfaXJxX3Jlc1tpXSwKLQkJICAgIElOVFJfVFlQRV9NSVNDIHwgSU5UUl9NUFNBRkUsIE5VTEws IHRpX2dwaW9faW50ciwgc2MsCisJCSAgICBJTlRSX1RZUEVfTUlTQyB8IElOVFJfTVBTQUZFLCB0 aV9ncGlvX2ludHIsIE5VTEwsIHNjLAogCQkgICAgJnNjLT5zY19pcnFfaGRsW2ldKSAhPSAwKSB7 CiAJCQlkZXZpY2VfcHJpbnRmKGRldiwKLQkJCSAgICAiV0FSTklORzogdW5hYmxlIHRvIHJlZ2lz dGVyIGludGVycnVwdCBoYW5kbGVyXG4iKTsKKwkJCSAgICAiV0FSTklORzogdW5hYmxlIHRvIHJl Z2lzdGVyIGludGVycnVwdCBmaWx0ZXJcbiIpOwogCQkJcmV0dXJuICgtMSk7CiAJCX0KIAl9CkBA IC02OTQsNyArNzc3LDcgQEAKIAlpbnQgaTsKIAlzdHJ1Y3QgdGlfZ3Bpb19zb2Z0YyAqc2M7CiAK LQkvKiBUZWFyZG93biBvdXIgaW50ZXJydXB0IGhhbmRsZXJzLiAqLworCS8qIFRlYXJkb3duIG91 ciBpbnRlcnJ1cHQgZmlsdGVycy4gKi8KIAlzYyA9IGRldmljZV9nZXRfc29mdGMoZGV2KTsKIAlm b3IgKGkgPSAwOyBpIDwgTUFYX0dQSU9fSU5UUlM7IGkrKykgewogCQlpZiAoc2MtPnNjX2lycV9y ZXNbaV0gPT0gTlVMTCkKQEAgLTc3Miw3ICs4NTUsMTAgQEAKIAl1bnNpZ25lZCBpbnQgaTsKIAlp bnQgZXJyOwogCi0gCXNjID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOworCWlmICh0aV9ncGlvX3Nj ICE9IE5VTEwpCisJCXJldHVybiAoRU5YSU8pOworCisJdGlfZ3Bpb19zYyA9IHNjID0gZGV2aWNl X2dldF9zb2Z0YyhkZXYpOwogCXNjLT5zY19kZXYgPSBkZXY7CiAKIAlUSV9HUElPX0xPQ0tfSU5J VChzYyk7CkBAIC04MjEsNiArOTA3LDEyIEBACiAJCX0KIAl9CiAKKwkvKiBUaGUgZGVmYXVsdCBp cyBhY3RpdmUtbG93IGludGVycnVwdHMuICovCisJZm9yIChpID0gMDsgaSA8IE1BWF9HUElPX1BJ TlM7IGkrKykgeworCQlzYy0+c2NfaXJxX3RyaWdnZXJbaV0gPSBJTlRSX1RSSUdHRVJfTEVWRUw7 CisJCXNjLT5zY19pcnFfcG9sYXJpdHlbaV0gPSBJTlRSX1BPTEFSSVRZX0xPVzsKKwl9CisKIAkv KiBGaW5pc2ggb2YgdGhlIHByb2JlIGNhbGwgKi8KIAlkZXZpY2VfYWRkX2NoaWxkKGRldiwgImdw aW9jIiwgZGV2aWNlX2dldF91bml0KGRldikpOwogCWRldmljZV9hZGRfY2hpbGQoZGV2LCAiZ3Bp b2J1cyIsIGRldmljZV9nZXRfdW5pdChkZXYpKTsKQEAgLTg2Nyw2ICs5NTksMjExIEBACiAJcmV0 dXJuICgwKTsKIH0KIAorc3RhdGljIHVpbnQzMl90Cit0aV9ncGlvX2ludHJfcmVnKHN0cnVjdCB0 aV9ncGlvX3NvZnRjICpzYywgaW50IGlycSkKK3sKKworCWlmIChpcnEgPiBNQVhfR1BJT19QSU5T KQorCQlyZXR1cm4gKDApOworCisJaWYgKHNjLT5zY19pcnFfdHJpZ2dlcltpcnFdID09IElOVFJf VFJJR0dFUl9MRVZFTCkgeworCQlpZiAoc2MtPnNjX2lycV9wb2xhcml0eVtpcnFdID09IElOVFJf UE9MQVJJVFlfTE9XKQorCQkJcmV0dXJuIChUSV9HUElPX0xFVkVMREVURUNUMCk7CisJCWVsc2Ug aWYgKHNjLT5zY19pcnFfcG9sYXJpdHlbaXJxXSA9PSBJTlRSX1BPTEFSSVRZX0hJR0gpCisJCQly ZXR1cm4gKFRJX0dQSU9fTEVWRUxERVRFQ1QxKTsKKwl9IGVsc2UgaWYgKHNjLT5zY19pcnFfdHJp Z2dlcltpcnFdID09IElOVFJfVFJJR0dFUl9FREdFKSB7CisJCWlmIChzYy0+c2NfaXJxX3BvbGFy aXR5W2lycV0gPT0gSU5UUl9QT0xBUklUWV9MT1cpCisJCQlyZXR1cm4gKFRJX0dQSU9fRkFMTElO R0RFVEVDVCk7CisJCWVsc2UgaWYgKHNjLT5zY19pcnFfcG9sYXJpdHlbaXJxXSA9PSBJTlRSX1BP TEFSSVRZX0hJR0gpCisJCQlyZXR1cm4gKFRJX0dQSU9fUklTSU5HREVURUNUKTsKKwl9CisKKwly ZXR1cm4gKDApOworfQorCitzdGF0aWMgdm9pZAordGlfZ3Bpb19tYXNrX2lycSh2b2lkICpzb3Vy Y2UpCit7CisJaW50IGJhbmssIGlycTsKKwl1aW50MzJfdCBtYXNrLCByZWcsIHZhbDsKKworCWly cSA9IChpbnQpc291cmNlOworCWlmIChpcnEgPiBNQVhfR1BJT19QSU5TKQorCQlyZXR1cm47CisK KwliYW5rID0gaXJxIC8gUElOU19QRVJfQkFOSzsKKwltYXNrID0gKDFVTCA8PCAoaXJxICUgUElO U19QRVJfQkFOSykpOworCisJVElfR1BJT19MT0NLKHRpX2dwaW9fc2MpOworCXRpX2dwaW9faW50 cl9jbHIodGlfZ3Bpb19zYywgYmFuaywgbWFzayk7CisJcmVnID0gdGlfZ3Bpb19pbnRyX3JlZyh0 aV9ncGlvX3NjLCBpcnEpOworCWlmIChyZWcgIT0gMCkgeworCQl2YWwgPSB0aV9ncGlvX3JlYWRf NCh0aV9ncGlvX3NjLCBiYW5rLCByZWcpOworCQl0aV9ncGlvX3dyaXRlXzQodGlfZ3Bpb19zYywg YmFuaywgcmVnLCB2YWwgJiB+bWFzayk7CisJfQorCVRJX0dQSU9fVU5MT0NLKHRpX2dwaW9fc2Mp OworfQorCitzdGF0aWMgdm9pZAordGlfZ3Bpb191bm1hc2tfaXJxKHZvaWQgKnNvdXJjZSkKK3sK KwlpbnQgYmFuaywgaXJxOworCXVpbnQzMl90IG1hc2ssIHJlZywgdmFsOworCisJaXJxID0gKGlu dClzb3VyY2U7CisJaWYgKGlycSA+IE1BWF9HUElPX1BJTlMpCisJCXJldHVybjsKKworCWJhbmsg PSBpcnEgLyBQSU5TX1BFUl9CQU5LOworCW1hc2sgPSAoMVVMIDw8IChpcnEgJSBQSU5TX1BFUl9C QU5LKSk7CisKKwlUSV9HUElPX0xPQ0sodGlfZ3Bpb19zYyk7CisJcmVnID0gdGlfZ3Bpb19pbnRy X3JlZyh0aV9ncGlvX3NjLCBpcnEpOworCWlmIChyZWcgIT0gMCkgeworCQl2YWwgPSB0aV9ncGlv X3JlYWRfNCh0aV9ncGlvX3NjLCBiYW5rLCByZWcpOworCQl0aV9ncGlvX3dyaXRlXzQodGlfZ3Bp b19zYywgYmFuaywgcmVnLCB2YWwgfCBtYXNrKTsKKwl9CisJdGlfZ3Bpb19pbnRyX3NldCh0aV9n cGlvX3NjLCBiYW5rLCBtYXNrKTsKKwlUSV9HUElPX1VOTE9DSyh0aV9ncGlvX3NjKTsKK30KKwor c3RhdGljIGludAordGlfZ3Bpb19hY3RpdmF0ZV9yZXNvdXJjZShkZXZpY2VfdCBkZXYsIGRldmlj ZV90IGNoaWxkLCBpbnQgdHlwZSwgaW50IHJpZCwKKwlzdHJ1Y3QgcmVzb3VyY2UgKnJlcykKK3sK KwlpbnQgcGluOworCXN0cnVjdCB0aV9ncGlvX3NvZnRjICpzYzsKKworCWlmICh0eXBlICE9IFNZ U19SRVNfSVJRKQorCQlyZXR1cm4gKEVOWElPKTsKKworCXNjID0gZGV2aWNlX2dldF9zb2Z0Yyhk ZXYpOworCisJLyogVW5tYXNrIHRoZSBpbnRlcnJ1cHQuICovCisJcGluID0gcm1hbl9nZXRfc3Rh cnQocmVzKTsKKwl0aV9ncGlvX3VubWFza19pcnEoKHZvaWQgKikodWludHB0cl90KXBpbik7CisK KwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgaW50Cit0aV9ncGlvX2RlYWN0aXZhdGVfcmVzb3Vy Y2UoZGV2aWNlX3QgZGV2LCBkZXZpY2VfdCBjaGlsZCwgaW50IHR5cGUsIGludCByaWQsCisJc3Ry dWN0IHJlc291cmNlICpyZXMpCit7CisJaW50IHBpbjsKKwlzdHJ1Y3QgdGlfZ3Bpb19zb2Z0YyAq c2M7CisKKwlpZiAodHlwZSAhPSBTWVNfUkVTX0lSUSkKKwkJcmV0dXJuIChFTlhJTyk7CisKKwlz YyA9IGRldmljZV9nZXRfc29mdGMoZGV2KTsKKworCS8qIE1hc2sgdGhlIGludGVycnVwdC4gKi8K KwlwaW4gPSBybWFuX2dldF9zdGFydChyZXMpOworCXRpX2dwaW9fbWFza19pcnEoKHZvaWQgKiko dWludHB0cl90KXBpbik7CisKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgaW50Cit0aV9ncGlv X2NvbmZpZ19pbnRyKGRldmljZV90IGRldiwgaW50IGlycSwgZW51bSBpbnRyX3RyaWdnZXIgdHJp ZywKKwllbnVtIGludHJfcG9sYXJpdHkgcG9sKQoreworCWludCBiYW5rOworCXN0cnVjdCB0aV9n cGlvX3NvZnRjICpzYzsKKwl1aW50MzJfdCBtYXNrLCBvbGRyZWcsIHJlZywgdmFsOworCisJaWYg KGlycSA+IE1BWF9HUElPX1BJTlMpCisJCXJldHVybiAoRUlOVkFMKTsKKworCS8qIFRoZXJlIGlz IG5vIHN0YW5kYXJkIHRyaWdnZXIgb3IgcG9sYXJpdHkuICovCisJaWYgKHRyaWcgPT0gSU5UUl9U UklHR0VSX0NPTkZPUk0gfHwgcG9sID09IElOVFJfUE9MQVJJVFlfQ09ORk9STSkKKwkJcmV0dXJu IChFSU5WQUwpOworCisJc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisJYmFuayA9IGlycSAv IFBJTlNfUEVSX0JBTks7CisJbWFzayA9ICgxVUwgPDwgKGlycSAlIFBJTlNfUEVSX0JBTkspKTsK KworCVRJX0dQSU9fTE9DSyh0aV9ncGlvX3NjKTsKKwkvKgorCSAqIFRSTSByZWNvbW1lbmRzIGFk ZCB0aGUgbmV3IGV2ZW50IGJlZm9yZSByZW1vdmUgdGhlIG9sZCBvbmUgdG8KKwkgKiBhdm9pZCBs b3NpbmcgaW50ZXJydXB0cy4KKwkgKi8KKwlvbGRyZWcgPSB0aV9ncGlvX2ludHJfcmVnKHNjLCBp cnEpOworCXNjLT5zY19pcnFfdHJpZ2dlcltpcnFdID0gdHJpZzsKKwlzYy0+c2NfaXJxX3BvbGFy aXR5W2lycV0gPSBwb2w7CisJcmVnID0gdGlfZ3Bpb19pbnRyX3JlZyhzYywgaXJxKTsKKwlpZiAo cmVnICE9IDApIHsKKwkJLyogQXBwbHkgdGhlIG5ldyBzZXR0aW5ncy4gKi8KKwkJdmFsID0gdGlf Z3Bpb19yZWFkXzQoc2MsIGJhbmssIHJlZyk7CisJCXRpX2dwaW9fd3JpdGVfNChzYywgYmFuaywg cmVnLCB2YWwgfCBtYXNrKTsKKwl9CisJaWYgKG9sZHJlZyAhPSAwKSB7CisJCS8qIFJlbW92ZSB0 aGUgb2xkIHNldHRpbmdzLiAqLworCQl2YWwgPSB0aV9ncGlvX3JlYWRfNChzYywgYmFuaywgb2xk cmVnKTsKKwkJdGlfZ3Bpb193cml0ZV80KHNjLCBiYW5rLCBvbGRyZWcsIHZhbCAmIH5tYXNrKTsK Kwl9CisJVElfR1BJT19VTkxPQ0sodGlfZ3Bpb19zYyk7CisKKwlyZXR1cm4gKDApOworfQorCitz dGF0aWMgaW50Cit0aV9ncGlvX3NldHVwX2ludHIoZGV2aWNlX3QgZGV2LCBkZXZpY2VfdCBjaGls ZCwgc3RydWN0IHJlc291cmNlICppcmVzLAorCWludCBmbGFncywgZHJpdmVyX2ZpbHRlcl90ICpm aWx0LCBkcml2ZXJfaW50cl90ICpoYW5kbGVyLAorCXZvaWQgKmFyZywgdm9pZCAqKmNvb2tpZXAp Cit7CisJc3RydWN0IHRpX2dwaW9fc29mdGMgKnNjOworCXN0cnVjdCBpbnRyX2V2ZW50ICpldmVu dDsKKwlpbnQgcGluLCBlcnJvcjsKKworCXNjID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOworCXBp biA9IHJtYW5fZ2V0X3N0YXJ0KGlyZXMpOworCisJaWYgKHBpbiA+IE1BWF9HUElPX1BJTlMpCisJ CXBhbmljKCIlczogYmFkIHBpbiAlZCIsIF9fZnVuY19fLCBwaW4pOworCisJZXZlbnQgPSBzYy0+ c2NfZXZlbnRzW3Bpbl07CisJaWYgKGV2ZW50ID09IE5VTEwpIHsKKwkJZXJyb3IgPSBpbnRyX2V2 ZW50X2NyZWF0ZSgmZXZlbnQsICh2b2lkICopKHVpbnRwdHJfdClwaW4sIDAsCisJCSAgICBwaW4s IHRpX2dwaW9fbWFza19pcnEsIHRpX2dwaW9fdW5tYXNrX2lycSwgTlVMTCwgTlVMTCwKKwkJICAg ICJncGlvJWQgcGluJWQ6IiwgZGV2aWNlX2dldF91bml0KGRldiksIHBpbik7CisKKwkJaWYgKGVy cm9yICE9IDApCisJCQlyZXR1cm4gKGVycm9yKTsKKworCQlzYy0+c2NfZXZlbnRzW3Bpbl0gPSBl dmVudDsKKwl9CisKKwlpbnRyX2V2ZW50X2FkZF9oYW5kbGVyKGV2ZW50LCBkZXZpY2VfZ2V0X25h bWV1bml0KGNoaWxkKSwgZmlsdCwKKwkgICAgaGFuZGxlciwgYXJnLCBpbnRyX3ByaW9yaXR5KGZs YWdzKSwgZmxhZ3MsIGNvb2tpZXApOworCisJcmV0dXJuICgwKTsKK30KKworc3RhdGljIGludAor dGlfZ3Bpb190ZWFyZG93bl9pbnRyKGRldmljZV90IGRldiwgZGV2aWNlX3QgY2hpbGQsIHN0cnVj dCByZXNvdXJjZSAqaXJlcywKKwl2b2lkICpjb29raWUpCit7CisJc3RydWN0IHRpX2dwaW9fc29m dGMgKnNjOworCWludCBwaW4sIGVycjsKKworCXNjID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOwor CXBpbiA9IHJtYW5fZ2V0X3N0YXJ0KGlyZXMpOworCisJaWYgKHBpbiA+IE1BWF9HUElPX1BJTlMp CisJCXBhbmljKCIlczogYmFkIHBpbiAlZCIsIF9fZnVuY19fLCBwaW4pOworCisJaWYgKHNjLT5z Y19ldmVudHNbcGluXSA9PSBOVUxMKQorCQlwYW5pYygiVHJ5aW5nIHRvIHRlYXJkb3duIHVub2Nj dXBpZWQgSVJRIik7CisKKwllcnIgPSBpbnRyX2V2ZW50X3JlbW92ZV9oYW5kbGVyKGNvb2tpZSk7 CisJaWYgKCFlcnIpCisJCXNjLT5zY19ldmVudHNbcGluXSA9IE5VTEw7CisKKwlyZXR1cm4gKGVy cik7Cit9CisKIHN0YXRpYyBwaGFuZGxlX3QKIHRpX2dwaW9fZ2V0X25vZGUoZGV2aWNlX3QgYnVz LCBkZXZpY2VfdCBkZXYpCiB7CkBAIC04OTAsNiArMTE4NywxMyBAQAogCURFVk1FVEhPRChncGlv X3Bpbl9zZXQsIHRpX2dwaW9fcGluX3NldCksCiAJREVWTUVUSE9EKGdwaW9fcGluX3RvZ2dsZSwg dGlfZ3Bpb19waW5fdG9nZ2xlKSwKIAorCS8qIEJ1cyBpbnRlcmZhY2UgKi8KKwlERVZNRVRIT0Qo YnVzX2FjdGl2YXRlX3Jlc291cmNlLCB0aV9ncGlvX2FjdGl2YXRlX3Jlc291cmNlKSwKKwlERVZN RVRIT0QoYnVzX2RlYWN0aXZhdGVfcmVzb3VyY2UsIHRpX2dwaW9fZGVhY3RpdmF0ZV9yZXNvdXJj ZSksCisJREVWTUVUSE9EKGJ1c19jb25maWdfaW50ciwgdGlfZ3Bpb19jb25maWdfaW50ciksCisJ REVWTUVUSE9EKGJ1c19zZXR1cF9pbnRyLCB0aV9ncGlvX3NldHVwX2ludHIpLAorCURFVk1FVEhP RChidXNfdGVhcmRvd25faW50ciwgdGlfZ3Bpb190ZWFyZG93bl9pbnRyKSwKKwogCS8qIG9md19i dXMgaW50ZXJmYWNlICovCiAJREVWTUVUSE9EKG9md19idXNfZ2V0X25vZGUsIHRpX2dwaW9fZ2V0 X25vZGUpLAogCg== --001a11c335ce38a5b404f96138f2-- From owner-freebsd-embedded@FreeBSD.ORG Wed May 14 21:42:58 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EE3131FF for ; Wed, 14 May 2014 21:42:58 +0000 (UTC) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AF7002DA3 for ; Wed, 14 May 2014 21:42:58 +0000 (UTC) Received: by mail-qc0-f173.google.com with SMTP id i8so318382qcq.32 for ; Wed, 14 May 2014 14:42:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=/cJd4N7XA7Lz+Lf9CDY/m3hT9twY7+IWLo9KYMULuVc=; b=ePCjX8aB/XE+oBB/4jEE11uae/Oea5oFdMp6F/9YHuAOyck/wMK6+7S8H7WBZaVDWv HHB253fKwLH6Ff09UBR0aG3bWQQI4K9aAB/W6F18VF+tVcKPWzi1z8kos+c6lxehxjuF aiF80TLNEcW4gMuAo4lL1TXqgw+vIj0iacMYYVbtN3LwHfE1RUb0HjjpmqxecN/+sOE4 sS0AI7b7AJsXTxF2KclED4NM1fcJLq44Fdc8NQGwWa8cpl5NM6SEa7I7X07pXaBy3knu 0YRURdUMav/323VnSCXPz2qBnlkbmHORnyZBEuJrXb0da7E+vj+2UxbvDDEfZu0I1zjE Jaqg== MIME-Version: 1.0 X-Received: by 10.140.91.5 with SMTP id y5mr9675282qgd.12.1400103777909; Wed, 14 May 2014 14:42:57 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Wed, 14 May 2014 14:42:56 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 May 2014 14:42:56 -0700 X-Google-Sender-Auth: -4KuuaJ0JTbZjolmNUBT8UeZUK4 Message-ID: Subject: Re: [RFC] GPIO interrupt support From: Adrian Chadd To: Luiz Otavio O Souza Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 21:42:59 -0000 Hi! Cool! Which ATheros chips did you test this on? -a On 14 May 2014 12:30, Luiz Otavio O Souza wrote: > Hi, > > I've been working on the attached patches which adds the GPIO interrupt support. > > gpio-intr.diff has the bus changes for FDT and non-FDT systems. > > ar71xx_gpio-intr.diff has the changes to AR71xx GPIO driver. > > bcm2835_gpio-intr.diff has the changes to BCM2835 (RPi) GPIO driver. > > ti_gpio-intr.diff has the changes for AM335x (Beaglebone), OMAP3 and > OMAP4 (panda board). > > The other attached file (gpio-intr-kqueue.c) is an example program > i've been using to check for interrupts from userland. > > Userland is notified about GPIO interrupts by a kqueue event. > > The changes have been tested on BBB, RPi and RSPRO. > > The manual page changes are still to be done (but it will surely be done). > > Comments ? > > Regards, > Luiz > > _______________________________________________ > freebsd-embedded@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-embedded > To unsubscribe, send any mail to "freebsd-embedded-unsubscribe@freebsd.org" From owner-freebsd-embedded@FreeBSD.ORG Wed May 14 23:10:01 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55202368; Wed, 14 May 2014 23:10:01 +0000 (UTC) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C265C2447; Wed, 14 May 2014 23:10:00 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id q59so247110wes.35 for ; Wed, 14 May 2014 16:09:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JseKE4GPKkL4HRXGqea64cBVGQKU0DG1DJsX46Teq5E=; b=Cj0OAgfxRqKJ1DZvsBd/lyWTupDVDraqZRp48sCQ6fl8dflSO2RqDjTuEjG9Zb2fGu O83KvNb2itm0Y1HkE3bmfK5MD/I9KLLTIMhLERhhjWMKzMJVg05HAbA3YOTQbZa2+sOX 2/No9nkWW4WsicJNvOpbyp9JDaEvCV5Qj/hvb2koHJiqHVcvHVsAnM4XbVF7l+c32M+l vtPmsLg1qOptSRbPc8clo2lP3KANXI0gCyOcY+e8/slq3bsIICtg1sulkeMglLyeWahn mGBMrYMdoWdQk+BSodqoyYXxAkPw8V8z95/xCSLdtaptYZ3kOK+hAQim2pNkx4qQB+W6 B0vw== MIME-Version: 1.0 X-Received: by 10.194.19.161 with SMTP id g1mr5387444wje.20.1400108998569; Wed, 14 May 2014 16:09:58 -0700 (PDT) Received: by 10.216.168.194 with HTTP; Wed, 14 May 2014 16:09:58 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 May 2014 20:09:58 -0300 Message-ID: Subject: Re: [RFC] GPIO interrupt support From: Luiz Otavio O Souza To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 23:10:01 -0000 On Wed, May 14, 2014 at 6:42 PM, Adrian Chadd wrote: > Hi! > > Cool! Which ATheros chips did you test this on? > > > -a (replying to all now... :/) For now only on ar7161 (RSPRO), i would like to test it on the newer SoCs (ar93xx) but i don't have any hardware to do it. I would appreciate any help with the tests. Luiz From owner-freebsd-embedded@FreeBSD.ORG Thu May 15 12:59:41 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 867ABDB for ; Thu, 15 May 2014 12:59:41 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1F71C256E for ; Thu, 15 May 2014 12:59:40 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id f8so4126792wiw.16 for ; Thu, 15 May 2014 05:59:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=kdhspRlUKpOhNuc31HyBGFG+isBpQydn+ybwJTDA81Q=; b=lzz/QqoxGoOEBgF6HHjwNWTdjGdZlRnYEElCEYMU0KjavkOpqkSlrvEzPUWNMZvVtW tw7lY5mE7HT2mEIBqhcMlWsQonQSQhm08ZTGXJ3C8E63ZBIgk1Z1GfOvmJwatr306/l/ J+zDeirDMC4sFhMNqlLqSHYLbHtQFAWnvKLYmh70nrPpKNLqNKykalVXu0O5+duJWyR2 76CLtL4PP3z0ph2iqrFwXTrsJhikC4LBjc5Cfq8h3oZ4eAH9lDDfPOHFOPuX365KNT5A WNMkg0joBuz30uf5NketzhfGR0OR9mj23qBnjP0W2iz216OstZWSXWuXARI7YddGb6dr l6Ag== MIME-Version: 1.0 X-Received: by 10.194.71.66 with SMTP id s2mr8557984wju.23.1400158779387; Thu, 15 May 2014 05:59:39 -0700 (PDT) Received: by 10.216.168.194 with HTTP; Thu, 15 May 2014 05:59:39 -0700 (PDT) In-Reply-To: References: Date: Thu, 15 May 2014 09:59:39 -0300 Message-ID: Subject: Re: [RFC] GPIO interrupt support From: Luiz Otavio O Souza To: "freebsd-embedded@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 12:59:41 -0000 And looks like i forgot to attach the gpio-intr-kqueue.c... On Wed, May 14, 2014 at 4:30 PM, Luiz Otavio O Souza wrote: > Hi, > > I've been working on the attached patches which adds the GPIO interrupt support. > > gpio-intr.diff has the bus changes for FDT and non-FDT systems. > > ar71xx_gpio-intr.diff has the changes to AR71xx GPIO driver. > > bcm2835_gpio-intr.diff has the changes to BCM2835 (RPi) GPIO driver. > > ti_gpio-intr.diff has the changes for AM335x (Beaglebone), OMAP3 and > OMAP4 (panda board). > > The other attached file (gpio-intr-kqueue.c) is an example program > i've been using to check for interrupts from userland. > > Userland is notified about GPIO interrupts by a kqueue event. > > The changes have been tested on BBB, RPi and RSPRO. > > The manual page changes are still to be done (but it will surely be done). > > Comments ? > > Regards, > Luiz From owner-freebsd-embedded@FreeBSD.ORG Thu May 15 15:46:15 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B004FC74 for ; Thu, 15 May 2014 15:46:15 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 900A22531 for ; Thu, 15 May 2014 15:46:15 +0000 (UTC) Received: from [10.69.210.132] (unknown [137.122.64.45]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 1B5731940D7; Thu, 15 May 2014 15:46:14 +0000 (UTC) Subject: Re: [RFC] GPIO interrupt support From: Sean Bruno Reply-To: sbruno@freebsd.org To: Luiz Otavio O Souza In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 May 2014 11:46:13 -0400 Message-ID: <1400168773.1025.1.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 15:46:15 -0000 On Thu, 2014-05-15 at 09:59 -0300, Luiz Otavio O Souza wrote: > And looks like i forgot to attach the gpio-intr-kqueue.c... > > On Wed, May 14, 2014 at 4:30 PM, Luiz Otavio O Souza wrote: > > Hi, > > > > I've been working on the attached patches which adds the GPIO interrupt support. > > > > gpio-intr.diff has the bus changes for FDT and non-FDT systems. > > > > ar71xx_gpio-intr.diff has the changes to AR71xx GPIO driver. > > > > bcm2835_gpio-intr.diff has the changes to BCM2835 (RPi) GPIO driver. > > > > ti_gpio-intr.diff has the changes for AM335x (Beaglebone), OMAP3 and > > OMAP4 (panda board). > > > > The other attached file (gpio-intr-kqueue.c) is an example program > > i've been using to check for interrupts from userland. > > > > Userland is notified about GPIO interrupts by a kqueue event. > > > > The changes have been tested on BBB, RPi and RSPRO. > > > > The manual page changes are still to be done (but it will surely be done). > > > > Comments ? > > > > Regards, > > Luiz > _______________________________________________ > freebsd-embedded@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-embedded > To unsubscribe, send any mail to "freebsd-embedded-unsubscribe@freebsd.org" Luiz: I have a bunch of 24k/74k atheros mips gear with me this week, what should I test? sean From owner-freebsd-embedded@FreeBSD.ORG Mon May 19 11:06:43 2014 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 63E0F2C1 for ; Mon, 19 May 2014 11:06:43 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 50B722DA9 for ; Mon, 19 May 2014 11:06:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4JB6ha7079966 for ; Mon, 19 May 2014 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4JB6gv2079964 for freebsd-embedded@FreeBSD.org; Mon, 19 May 2014 11:06:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 19 May 2014 11:06:42 GMT Message-Id: <201405191106.s4JB6gv2079964@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-embedded@FreeBSD.org Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 11:06:43 -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 misc/52256 embedded [picobsd] picobsd build script does not read in user/s o kern/42728 embedded [picobsd] many problems in src/usr.sbin/ppp/* after c 2 problems total. From owner-freebsd-embedded@FreeBSD.ORG Thu May 22 03:46:02 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B2D3E131; Thu, 22 May 2014 03:46:02 +0000 (UTC) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F8012F26; Thu, 22 May 2014 03:46:02 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id hi2so3709408wib.1 for ; Wed, 21 May 2014 20:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=DZpGfpkVl5kI015gzesISXCZWNDnBiL4ukWTynPENZg=; b=BCN/kfj/KHc4NqDwpZMhPx2O0Xsidhc0GYf/wIVumC76twddtYdc2xt8+8Gpum6NKc OlJ1WZ0ZgoCMsCK9r0/o1bsQTfS6PDpT+1rqIDZY7YuEZvjAfJuWVPh3N6Q2kcxg648o R84nmQbRJsAC4WQ4UlWyhMuFFvNRlaj831f6Ss9OSVBwNg4HO7/PLYF7qsPn9NkJG+Hm ahX3kFWj9rIfPBmd1CtLzwKDCM65Vi2+tDqnOnw/gUWRhGI+6SHpyRY+vJddRD4gv/VQ cjiFld5WMVAw8rPRvSm9nY4c64nwqg7o4HU3zKQwJ8QlMznrR+hWF3cvq3mnjflyKBOK oTxQ== MIME-Version: 1.0 X-Received: by 10.194.6.166 with SMTP id c6mr149756wja.64.1400730359569; Wed, 21 May 2014 20:45:59 -0700 (PDT) Received: by 10.217.153.193 with HTTP; Wed, 21 May 2014 20:45:59 -0700 (PDT) Date: Thu, 22 May 2014 00:45:59 -0300 Message-ID: Subject: BeagleBone-black GPIO pins use on FreeBSD From: Luiz Otavio O Souza To: freebsd-arm@freebsd.org, "freebsd-embedded@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 03:46:02 -0000 Hi, I've updated the BeagleBone-black Wiki page (https://wiki.freebsd.org/FreeBSD/arm/BeagleBoneBlack) with the default settings for the GPIO expansion headers on FreeBSD. It has all the pins used for ADC (AIN), I2C, PWMs and MMC1. Please let me know if i have missed something. I hope this saves some time for people who is going to work with GPIO. Regards, Luiz From owner-freebsd-embedded@FreeBSD.ORG Thu May 22 04:32:09 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F3985B28; Thu, 22 May 2014 04:32:08 +0000 (UTC) Received: from felyko.com (felyko.com [IPv6:2001:470:1:2d5:26:3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id D4FA9230A; Thu, 22 May 2014 04:32:08 +0000 (UTC) Received: from [IPv6:2601:9:8280:426:4442:e054:8003:6e68] (unknown [IPv6:2601:9:8280:426:4442:e054:8003:6e68]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id 236B634A9E7; Wed, 21 May 2014 21:32:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=felyko.com; s=mail; t=1400733128; bh=YJ1XMiIGqTOjnwDslVUZWOPkSzMfRZaIgYOrIOFT2XU=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=dkVYSHsajD7kAJnZlYdxUlgJtb12Ph8CvnQl96xxhbI68jYbFQci6cloXrtTjD0Yc pa53ZjwVFECRipSw/dCcqQg6QUtFGTIO/yAHa+p1wvdUb8WiZTen7g3k7mnn6cF/H+ YtBx1n71yH5oSBAkZ0eZEWppzWdxx1HG5Xsg4Yfw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: BeagleBone-black GPIO pins use on FreeBSD From: Rui Paulo In-Reply-To: Date: Wed, 21 May 2014 21:32:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5C8FC523-0FB1-4C84-8276-D297373874BB@felyko.com> References: To: Luiz Otavio O Souza X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-arm@freebsd.org, "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 04:32:09 -0000 On May 21, 2014, at 20:45, Luiz Otavio O Souza = wrote: > Hi, >=20 > I've updated the BeagleBone-black Wiki page > (https://wiki.freebsd.org/FreeBSD/arm/BeagleBoneBlack) with the > default settings for the GPIO expansion headers on FreeBSD. >=20 > It has all the pins used for ADC (AIN), I2C, PWMs and MMC1. >=20 > Please let me know if i have missed something. >=20 > I hope this saves some time for people who is going to work with GPIO. This is good, but I always wished some information was present on dmesg. = This could be added to the FDT and printed automatically, e.g.: i2c1 {=20 location =3D "SDA header P9 pin 18, SCL header P9 pin 17"; }; That would print: ti_i2c1: SDA header P9 pin 18, SCL header P9 pin 17 If we don't want to put this in the kernel, we could at least put it in = a man page. However, a lot of embedded systems don't even have man = pages... -- Rui Paulo From owner-freebsd-embedded@FreeBSD.ORG Thu May 22 05:00:29 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3EA0C575 for ; Thu, 22 May 2014 05:00:29 +0000 (UTC) Received: from mail-pb0-f52.google.com (mail-pb0-f52.google.com [209.85.160.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0C9C824AE for ; Thu, 22 May 2014 05:00:28 +0000 (UTC) Received: by mail-pb0-f52.google.com with SMTP id rr13so2136292pbb.11 for ; Wed, 21 May 2014 22:00:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=hzGz3Vujp9ugJ7QfSPfrZqRXUuXY1atOBdIRjrW00nI=; b=GLuvFLIo23kXTYf+mPx+qqM1z1Qh1/+QqAUeq94ooHzw9al2ALQQOTxrUE4IB20ISR AviSi08buKeNmFJGobCOofbWC8zqXXjm+fgTurJIBvpcDzedr/ICHpp6DqoT3MoSfq3i oy/ztZj0+l/ORYpLRya0d4MooHF4tklV8AUOLGGURmYrgQhA4ezS5Mk7krkaL8j8MYn7 pwQYjjj8IJA4gW/Y+38CoyEtFltp+RTiPS68TB6EXv0hzfwxGOK4ZsP1kiSihVuYKrX7 zKCZeputkPx0+Z3d13gOujOtoC7pu3ZEvtAppFesJIgzE5AdB2iUg57cRtN8AioeBB60 Aufg== X-Gm-Message-State: ALoCoQldLApxbyDKg684vDkdVuhek3zyMH4oZ1hFkYa1XbJqhgZhetZ3jjGyI/03csjhNSdtDugu X-Received: by 10.67.14.69 with SMTP id fe5mr65341054pad.120.1400734827764; Wed, 21 May 2014 22:00:27 -0700 (PDT) Received: from [10.64.24.150] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id gr10sm10783416pbc.84.2014.05.21.22.00.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 May 2014 22:00:26 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_09466805-1F4B-4B40-95DE-D9A1BF02154B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: BeagleBone-black GPIO pins use on FreeBSD From: Warner Losh In-Reply-To: <5C8FC523-0FB1-4C84-8276-D297373874BB@felyko.com> Date: Wed, 21 May 2014 23:00:28 -0600 Message-Id: <88BF1D4E-001B-44F9-BEEB-7846BDF6A2E7@bsdimp.com> References: <5C8FC523-0FB1-4C84-8276-D297373874BB@felyko.com> To: Rui Paulo X-Mailer: Apple Mail (2.1878.2) Cc: freebsd-arm@freebsd.org, "freebsd-embedded@freebsd.org" , Luiz Otavio O Souza X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 05:00:29 -0000 --Apple-Mail=_09466805-1F4B-4B40-95DE-D9A1BF02154B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 21, 2014, at 10:32 PM, Rui Paulo wrote: > On May 21, 2014, at 20:45, Luiz Otavio O Souza = wrote: >=20 >> Hi, >>=20 >> I've updated the BeagleBone-black Wiki page >> (https://wiki.freebsd.org/FreeBSD/arm/BeagleBoneBlack) with the >> default settings for the GPIO expansion headers on FreeBSD. >>=20 >> It has all the pins used for ADC (AIN), I2C, PWMs and MMC1. >>=20 >> Please let me know if i have missed something. >>=20 >> I hope this saves some time for people who is going to work with = GPIO. >=20 > This is good, but I always wished some information was present on = dmesg. This could be added to the FDT and printed automatically, e.g.: >=20 > i2c1 {=20 > location =3D "SDA header P9 pin 18, SCL header P9 pin 17"; > }; >=20 > That would print: >=20 > ti_i2c1: SDA header P9 pin 18, SCL header P9 pin 17 >=20 > If we don't want to put this in the kernel, we could at least put it = in a man page. However, a lot of embedded systems don't even have man = pages... This information can be derived mostly from the pinmux stuff that = (should be) in our .dts files. However, there=92s no standard way to = communicate these things. So the strongest we could do for this = non-standard property is =93freebsd,location=94, even though it is a = strong candidate for having it without since that describes hardware. = I=92d squirrel this away in the dev sysctl tree though, since otherwise = the boot will get rather uncomfortably chatty. Warner --Apple-Mail=_09466805-1F4B-4B40-95DE-D9A1BF02154B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTfYRsAAoJEGwc0Sh9sBEASm4P+QHO4jhLgnfFn/QMoXnxEZ0G AlkR3UYwXdO7y6SMCjYbei/5AE05CfExlrWEnBgF/+UNRlOzIdqFDq2b3SDtc5oB d8lNNZ39xQblGYNcyHPgGZak1j9dzGmSpCOVNLZHQr4CZnAVTDx1IUghZ22uySUF +CAAKj/qGGGX9DE3hyRF/oSKDwyfN8ZsKw7t4tBHmaE5Z4GfgCBPWU8MXqJaWmsd uDoGkfhtCkAfpMhtmVleA2u9zNDAQWZ8wV0ro++8ExH8Ps7X/b2szvFH0I0YvOaq 7/olJlz/fmkZb7G1lI5vmG1KVrlJGhp1H4pHxcrzUaB7HdEnT2O/wNaZJKlb1kgK WWk+kMpyYzRRnJfuPPXXBP8xoSuJhOVs10NuEzjuMHG/Nmz5TCJpfe49budzJUcW ur+cfgGCcuZahEisFCI6dRYXlYxdd9KRCBoG+QI1ThBhqc3nKXI0Uxo9H6XIltsC L1P6l9v6m44Hg3JYCLxAfkQjGbOwpH6xIQk51ZFpKJtVuuN7OS7dcB4lmzV0MaGo n4a9USPXJO7D3NgtnBvdk/AsbbPx4LKRLOeY45OQqPLXulh4ILXRrL3VHbMUpog/ 2RLZkQUuMfOO8nCSBRVe5qPAsB42TQLh/O6zR8Err9mccDh0krFF0UUl6vY3bTjW ng+W2AalKDTgCbsE72tA =xASl -----END PGP SIGNATURE----- --Apple-Mail=_09466805-1F4B-4B40-95DE-D9A1BF02154B-- From owner-freebsd-embedded@FreeBSD.ORG Mon May 26 11:06:44 2014 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0AFFED6C for ; Mon, 26 May 2014 11:06:44 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EB31524D5 for ; Mon, 26 May 2014 11:06:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4QB6hn0031971 for ; Mon, 26 May 2014 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4QB6hGE031969 for freebsd-embedded@FreeBSD.org; Mon, 26 May 2014 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 26 May 2014 11:06:43 GMT Message-Id: <201405261106.s4QB6hGE031969@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-embedded@FreeBSD.org Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 11:06:44 -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 misc/52256 embedded [picobsd] picobsd build script does not read in user/s o kern/42728 embedded [picobsd] many problems in src/usr.sbin/ppp/* after c 2 problems total. From owner-freebsd-embedded@FreeBSD.ORG Mon May 26 17:27:00 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4404659C for ; Mon, 26 May 2014 17:27:00 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2609A2986 for ; Mon, 26 May 2014 17:26:59 +0000 (UTC) Received: from [192.168.200.102] (c-50-131-4-11.hsd1.ca.comcast.net [50.131.4.11]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 84309194139 for ; Mon, 26 May 2014 17:26:58 +0000 (UTC) Subject: Dlink DIR-825B1 From: Sean Bruno Reply-To: sbruno@freebsd.org To: "freebsd-embedded@freebsd.org" Content-Type: text/plain; charset="us-ascii" Date: Mon, 26 May 2014 10:26:57 -0700 Message-ID: <1401125217.1107.6.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 17:27:00 -0000 Does anyone have their calibration partition handy for this unit? I seem to have destroyed mine at the moment and need to restore something so I have a test unit. sean From owner-freebsd-embedded@FreeBSD.ORG Tue May 27 00:05:40 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 82ABFA0D for ; Tue, 27 May 2014 00:05:40 +0000 (UTC) Received: from phoenix.eternamente.info (phoenix.arroway.org [109.169.80.17]) by mx1.freebsd.org (Postfix) with ESMTP id 5F4A128AF for ; Tue, 27 May 2014 00:05:39 +0000 (UTC) Received: by phoenix.eternamente.info (Postfix, from userid 80) id 9C3611CC8F; Mon, 26 May 2014 20:59:03 -0300 (BRT) Received: from 187.61.223.198 (SquirrelMail authenticated user matheus) by arroway.org with HTTP; Mon, 26 May 2014 20:59:03 -0300 Message-ID: <49c60fb02024eef0845c34e0acd8ec0f.squirrel@arroway.org> In-Reply-To: <1401125217.1107.6.camel@bruno> References: <1401125217.1107.6.camel@bruno> Date: Mon, 26 May 2014 20:59:03 -0300 Subject: Re: Dlink DIR-825B1 From: "Nenhum_de_Nos" To: freebsd-embedded@freebsd.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 00:05:40 -0000 On Mon, May 26, 2014 14:26, Sean Bruno wrote: > Does anyone have their calibration partition handy for this unit? I > seem to have destroyed mine at the moment and need to restore something > so I have a test unit. > > sean Sean, how can I get it ? I have one here running an old version of FreeBSD for it. Does this help ? matheus -- We will call you Cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-embedded@FreeBSD.ORG Tue May 27 00:54:16 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B4190CD9 for ; Tue, 27 May 2014 00:54:16 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 94A372BC3 for ; Tue, 27 May 2014 00:54:16 +0000 (UTC) Received: from [192.168.200.102] (c-50-131-4-11.hsd1.ca.comcast.net [50.131.4.11]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 93841194139; Tue, 27 May 2014 00:54:14 +0000 (UTC) Subject: Re: Dlink DIR-825B1 From: Sean Bruno Reply-To: sbruno@freebsd.org To: Nenhum_de_Nos In-Reply-To: <49c60fb02024eef0845c34e0acd8ec0f.squirrel@arroway.org> References: <1401125217.1107.6.camel@bruno> <49c60fb02024eef0845c34e0acd8ec0f.squirrel@arroway.org> Content-Type: text/plain; charset="us-ascii" Date: Mon, 26 May 2014 17:54:12 -0700 Message-ID: <1401152052.1107.10.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 00:54:16 -0000 On Mon, 2014-05-26 at 20:59 -0300, Nenhum_de_Nos wrote: > On Mon, May 26, 2014 14:26, Sean Bruno wrote: > > Does anyone have their calibration partition handy for this unit? I > > seem to have destroyed mine at the moment and need to restore something > > so I have a test unit. > > > > sean > > Sean, > > how can I get it ? > > I have one here running an old version of FreeBSD for it. Does this help ? > > matheus > Yes, something like: dd if=/dev/art bs=64k count=1 | nc :10000 with another computer listening nc -l 10000 > art.bin sean From owner-freebsd-embedded@FreeBSD.ORG Tue May 27 02:00:44 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BE316A62 for ; Tue, 27 May 2014 02:00:44 +0000 (UTC) Received: from phoenix.eternamente.info (phoenix.arroway.org [109.169.80.17]) by mx1.freebsd.org (Postfix) with ESMTP id 993B1207D for ; Tue, 27 May 2014 02:00:43 +0000 (UTC) Received: by phoenix.eternamente.info (Postfix, from userid 80) id CCB611CC8F; Mon, 26 May 2014 23:00:32 -0300 (BRT) Received: from 187.61.223.198 (SquirrelMail authenticated user matheus) by arroway.org with HTTP; Mon, 26 May 2014 23:00:32 -0300 Message-ID: <4df61b554c55f7e4c39e5f132e14c226.squirrel@arroway.org> In-Reply-To: <1401152052.1107.10.camel@bruno> References: <1401125217.1107.6.camel@bruno> <49c60fb02024eef0845c34e0acd8ec0f.squirrel@arroway.org> <1401152052.1107.10.camel@bruno> Date: Mon, 26 May 2014 23:00:32 -0300 Subject: Re: Dlink DIR-825B1 From: "Nenhum_de_Nos" Cc: freebsd-embedded@freebsd.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 02:00:44 -0000 On Mon, May 26, 2014 21:54, Sean Bruno wrote: > On Mon, 2014-05-26 at 20:59 -0300, Nenhum_de_Nos wrote: >> On Mon, May 26, 2014 14:26, Sean Bruno wrote: >> > Does anyone have their calibration partition handy for this unit? I >> > seem to have destroyed mine at the moment and need to restore something >> > so I have a test unit. >> > >> > sean >> >> Sean, >> >> how can I get it ? >> >> I have one here running an old version of FreeBSD for it. Does this help ? >> >> matheus >> > > > Yes, something like: > > dd if=/dev/art bs=64k count=1 | nc :10000 > > with another computer listening > > nc -l 10000 > art.bin > > sean Houston, we have.... # dd if=/dev/art bs=64k count=1 | nc 10.1.1.10:10000 usage: nc [-46DdEhklNnrStUuvz] [-e policy] [-I length] [-i interval] [-O length] [-P proxy_username] [-p source_port] [-s source] [-T ToS] [-V rtable] [-w timeout] [-X proxy_protocol] [-x proxy_address[:port]] [destination] [port] dd: /dev/art: No such file or directory # ls /dev bpf devctl kmem null ttyu0.init bpf0 devstat map pci ttyu0.lock console fd md0 random ufssuspend ctty fido md1 stderr urandom cuau0 flash md2 stdin xpt0 cuau0.init geom.ctl mdctl stdout zero cuau0.lock klog mem ttyu0 # uname -a FreeBSD freebsd-wifi-build 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r254983M: Wed Sep 25 08:18:28 BRT 2013 root@dev:/root/work/freebsd/head/obj/mipseb/mips.mips/root/work/freebsd/head/src/sys/DIR-825_Matheus mips I changed the kernel, but that much. And I don't know exactly where is the kernel conf file. may be it ? matheus -- We will call you Cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-embedded@FreeBSD.ORG Tue May 27 02:29:31 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 720FC130 for ; Tue, 27 May 2014 02:29:31 +0000 (UTC) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 32A8F222B for ; Tue, 27 May 2014 02:29:31 +0000 (UTC) Received: by mail-qg0-f48.google.com with SMTP id i50so12817956qgf.21 for ; Mon, 26 May 2014 19:29:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=F2cmY810f/obrdqyfRrnzYPNOoH2Sokg/UKF4jCB0qY=; b=LOZd1LaHHrfCsj7OaIP3yWph1u7EuOFEpSrVflgJe5wOUHEC1tzyoYn5xS9Ai1GZxu U5qfvvN1frHatq3q8E6w5mng3k/ALCns3T83B8Xg34WgxLqPbqz1OafA0pDtNlaJRtI/ GmBcH91qqm9eEBHCLujcUu7xK6HTLm8R8SgjMsRdU9nvucYZXwkRLl6Iw6EjGW2MnWJK 4c1JA3aRl7tkdyMtBkGF5RX0BXt+4oUh3s4EAGargnct1boPLpBuuspPoBqQkBqqS8cR PhGkHT7vOcPA2b+Cj4DTp+5FUiMDk/dRlVpomEdghjuABZRLbHG6RH8XjRTgEyh9FcXV hAHw== MIME-Version: 1.0 X-Received: by 10.140.91.5 with SMTP id y5mr36019602qgd.12.1401157770347; Mon, 26 May 2014 19:29:30 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Mon, 26 May 2014 19:29:30 -0700 (PDT) In-Reply-To: <4df61b554c55f7e4c39e5f132e14c226.squirrel@arroway.org> References: <1401125217.1107.6.camel@bruno> <49c60fb02024eef0845c34e0acd8ec0f.squirrel@arroway.org> <1401152052.1107.10.camel@bruno> <4df61b554c55f7e4c39e5f132e14c226.squirrel@arroway.org> Date: Mon, 26 May 2014 19:29:30 -0700 X-Google-Sender-Auth: jP8eFiSXijuwJvIz-QJZOUsnGjc Message-ID: Subject: Re: Dlink DIR-825B1 From: Adrian Chadd To: Nenhum_de_Nos Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 02:29:31 -0000 look in /dev/map -a On 26 May 2014 19:00, Nenhum_de_Nos wrote: > > On Mon, May 26, 2014 21:54, Sean Bruno wrote: >> On Mon, 2014-05-26 at 20:59 -0300, Nenhum_de_Nos wrote: >>> On Mon, May 26, 2014 14:26, Sean Bruno wrote: >>> > Does anyone have their calibration partition handy for this unit? I >>> > seem to have destroyed mine at the moment and need to restore something >>> > so I have a test unit. >>> > >>> > sean >>> >>> Sean, >>> >>> how can I get it ? >>> >>> I have one here running an old version of FreeBSD for it. Does this help ? >>> >>> matheus >>> >> >> >> Yes, something like: >> >> dd if=/dev/art bs=64k count=1 | nc :10000 >> >> with another computer listening >> >> nc -l 10000 > art.bin >> >> sean > > Houston, we have.... > > # dd if=/dev/art bs=64k count=1 | nc 10.1.1.10:10000 > usage: nc [-46DdEhklNnrStUuvz] [-e policy] [-I length] [-i interval] [-O length] > [-P proxy_username] [-p source_port] [-s source] [-T ToS] > [-V rtable] [-w timeout] [-X proxy_protocol] > [-x proxy_address[:port]] [destination] [port] > dd: /dev/art: No such file or directory > # ls /dev > bpf devctl kmem null ttyu0.init > bpf0 devstat map pci ttyu0.lock > console fd md0 random ufssuspend > ctty fido md1 stderr urandom > cuau0 flash md2 stdin xpt0 > cuau0.init geom.ctl mdctl stdout zero > cuau0.lock klog mem ttyu0 > # uname -a > FreeBSD freebsd-wifi-build 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r254983M: Wed Sep 25 08:18:28 BRT > 2013 > root@dev:/root/work/freebsd/head/obj/mipseb/mips.mips/root/work/freebsd/head/src/sys/DIR-825_Matheus > mips > > I changed the kernel, but that much. And I don't know exactly where is the kernel conf file. > > may be it ? > > matheus > > > -- > We will call you Cygnus, > The God of balance you shall be > > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > > http://en.wikipedia.org/wiki/Posting_style > _______________________________________________ > freebsd-embedded@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-embedded > To unsubscribe, send any mail to "freebsd-embedded-unsubscribe@freebsd.org" From owner-freebsd-embedded@FreeBSD.ORG Tue May 27 18:50:12 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E5144E9B for ; Tue, 27 May 2014 18:50:11 +0000 (UTC) Received: from phoenix.eternamente.info (phoenix.arroway.org [109.169.80.17]) by mx1.freebsd.org (Postfix) with ESMTP id A16A7290F for ; Tue, 27 May 2014 18:50:11 +0000 (UTC) Received: by phoenix.eternamente.info (Postfix, from userid 80) id 0B8071CC90; Tue, 27 May 2014 15:50:02 -0300 (BRT) Received: from 187.61.223.198 (SquirrelMail authenticated user matheus) by arroway.org with HTTP; Tue, 27 May 2014 15:50:02 -0300 Message-ID: <5c476b41ca8a336899b39ea8314ec0df.squirrel@arroway.org> In-Reply-To: References: <1401125217.1107.6.camel@bruno> <49c60fb02024eef0845c34e0acd8ec0f.squirrel@arroway.org> <1401152052.1107.10.camel@bruno> <4df61b554c55f7e4c39e5f132e14c226.squirrel@arroway.org> Date: Tue, 27 May 2014 15:50:02 -0300 Subject: Re: Dlink DIR-825B1 From: "Nenhum_de_Nos" Cc: "freebsd-embedded@freebsd.org" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20140527155001_84584" X-Priority: 3 (Normal) Importance: Normal X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 18:50:12 -0000 ------=_20140527155001_84584 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit On Mon, May 26, 2014 23:29, Adrian Chadd wrote: > look in /dev/map > > > -a # dd if=/dev/map bs=64k count=1 | nc 10.1.1.10 10000 0+1 records in 0+1 records out 124 bytes transferred in 0.000467 secs (265625 bytes/sec) # dd if=/dev/map bs=64k count=1 | nc 10.1.1.10 10000 0+1 records in 0+1 records out 124 bytes transferred in 0.000505 secs (245559 bytes/sec) the map.bin has 124 bytes and is attached. matheus > On 26 May 2014 19:00, Nenhum_de_Nos wrote: >> >> On Mon, May 26, 2014 21:54, Sean Bruno wrote: >>> On Mon, 2014-05-26 at 20:59 -0300, Nenhum_de_Nos wrote: >>>> On Mon, May 26, 2014 14:26, Sean Bruno wrote: >>>> > Does anyone have their calibration partition handy for this unit? I >>>> > seem to have destroyed mine at the moment and need to restore something >>>> > so I have a test unit. >>>> > >>>> > sean >>>> >>>> Sean, >>>> >>>> how can I get it ? >>>> >>>> I have one here running an old version of FreeBSD for it. Does this help ? >>>> >>>> matheus >>>> >>> >>> >>> Yes, something like: >>> >>> dd if=/dev/art bs=64k count=1 | nc :10000 >>> >>> with another computer listening >>> >>> nc -l 10000 > art.bin >>> >>> sean >> >> Houston, we have.... >> >> # dd if=/dev/art bs=64k count=1 | nc 10.1.1.10:10000 >> usage: nc [-46DdEhklNnrStUuvz] [-e policy] [-I length] [-i interval] [-O length] >> [-P proxy_username] [-p source_port] [-s source] [-T ToS] >> [-V rtable] [-w timeout] [-X proxy_protocol] >> [-x proxy_address[:port]] [destination] [port] >> dd: /dev/art: No such file or directory >> # ls /dev >> bpf devctl kmem null ttyu0.init >> bpf0 devstat map pci ttyu0.lock >> console fd md0 random ufssuspend >> ctty fido md1 stderr urandom >> cuau0 flash md2 stdin xpt0 >> cuau0.init geom.ctl mdctl stdout zero >> cuau0.lock klog mem ttyu0 >> # uname -a >> FreeBSD freebsd-wifi-build 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r254983M: Wed Sep 25 08:18:28 >> BRT >> 2013 >> root@dev:/root/work/freebsd/head/obj/mipseb/mips.mips/root/work/freebsd/head/src/sys/DIR-825_Matheus >> mips >> >> I changed the kernel, but that much. And I don't know exactly where is the kernel conf file. >> >> may be it ? >> >> matheus >> >> >> -- >> We will call you Cygnus, >> The God of balance you shall be >> >> A: Because it messes up the order in which people normally read text. >> Q: Why is top-posting such a bad thing? >> >> http://en.wikipedia.org/wiki/Posting_style >> _______________________________________________ >> freebsd-embedded@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-embedded >> To unsubscribe, send any mail to "freebsd-embedded-unsubscribe@freebsd.org" > -- We will call you Cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style ------=_20140527155001_84584 Content-Type: application/octet-stream; name="map.bin" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="map.bin" AAAAKgAMBAEuAAAAAAAAAgAMBAIuLgAAAAAAIgAQAgV1Ym9vdAAAAAAAACMADAIDY2ZnAAAAACQA EAIGa2VybmVsAAAAAAAlABACBnJvb3RmcwAAAAAAJgAMAgNhcnQAAAAAJwAcAhFyb290ZnMudW5j b21wcmVzcwAAAA== ------=_20140527155001_84584-- From owner-freebsd-embedded@FreeBSD.ORG Tue May 27 19:17:31 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0906EEDA for ; Tue, 27 May 2014 19:17:31 +0000 (UTC) Received: from phoenix.eternamente.info (phoenix.arroway.org [109.169.80.17]) by mx1.freebsd.org (Postfix) with ESMTP id 5EE0D2BE6 for ; Tue, 27 May 2014 19:17:29 +0000 (UTC) Received: by phoenix.eternamente.info (Postfix, from userid 80) id C5E5B1CC90; Tue, 27 May 2014 16:17:21 -0300 (BRT) Received: from 187.61.223.198 (SquirrelMail authenticated user matheus) by arroway.org with HTTP; Tue, 27 May 2014 16:17:21 -0300 Message-ID: In-Reply-To: <5c476b41ca8a336899b39ea8314ec0df.squirrel@arroway.org> References: <1401125217.1107.6.camel@bruno> <49c60fb02024eef0845c34e0acd8ec0f.squirrel@arroway.org> <1401152052.1107.10.camel@bruno> <4df61b554c55f7e4c39e5f132e14c226.squirrel@arroway.org> <5c476b41ca8a336899b39ea8314ec0df.squirrel@arroway.org> Date: Tue, 27 May 2014 16:17:21 -0300 Subject: Re: Dlink DIR-825B1 From: "Nenhum_de_Nos" Cc: "freebsd-embedded@freebsd.org" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20140527161721_72334" X-Priority: 3 (Normal) Importance: Normal X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 19:17:31 -0000 ------=_20140527161721_72334 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit On Tue, May 27, 2014 15:50, Nenhum_de_Nos wrote: > On Mon, May 26, 2014 23:29, Adrian Chadd wrote: >> look in /dev/map >> >> >> -a > > # dd if=/dev/map bs=64k count=1 | nc 10.1.1.10 10000 > 0+1 records in > 0+1 records out > 124 bytes transferred in 0.000467 secs (265625 bytes/sec) > # dd if=/dev/map bs=64k count=1 | nc 10.1.1.10 10000 > 0+1 records in > 0+1 records out > 124 bytes transferred in 0.000505 secs (245559 bytes/sec) > > the map.bin has 124 bytes and is attached. > > matheus # dd if=/dev/map/art bs=64k count=1 | nc 10.1.1.10 10000 1+0 records in 1+0 records out 65536 bytes transferred in 0.123917 secs (528870 bytes/sec) now the right one, thanks Luiz ! matheus >> On 26 May 2014 19:00, Nenhum_de_Nos wrote: >>> >>> On Mon, May 26, 2014 21:54, Sean Bruno wrote: >>>> On Mon, 2014-05-26 at 20:59 -0300, Nenhum_de_Nos wrote: >>>>> On Mon, May 26, 2014 14:26, Sean Bruno wrote: >>>>> > Does anyone have their calibration partition handy for this unit? I >>>>> > seem to have destroyed mine at the moment and need to restore something >>>>> > so I have a test unit. >>>>> > >>>>> > sean >>>>> >>>>> Sean, >>>>> >>>>> how can I get it ? >>>>> >>>>> I have one here running an old version of FreeBSD for it. Does this help ? >>>>> >>>>> matheus >>>>> >>>> >>>> >>>> Yes, something like: >>>> >>>> dd if=/dev/art bs=64k count=1 | nc :10000 >>>> >>>> with another computer listening >>>> >>>> nc -l 10000 > art.bin >>>> >>>> sean >>> >>> Houston, we have.... >>> >>> # dd if=/dev/art bs=64k count=1 | nc 10.1.1.10:10000 >>> usage: nc [-46DdEhklNnrStUuvz] [-e policy] [-I length] [-i interval] [-O length] >>> [-P proxy_username] [-p source_port] [-s source] [-T ToS] >>> [-V rtable] [-w timeout] [-X proxy_protocol] >>> [-x proxy_address[:port]] [destination] [port] >>> dd: /dev/art: No such file or directory >>> # ls /dev >>> bpf devctl kmem null ttyu0.init >>> bpf0 devstat map pci ttyu0.lock >>> console fd md0 random ufssuspend >>> ctty fido md1 stderr urandom >>> cuau0 flash md2 stdin xpt0 >>> cuau0.init geom.ctl mdctl stdout zero >>> cuau0.lock klog mem ttyu0 >>> # uname -a >>> FreeBSD freebsd-wifi-build 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r254983M: Wed Sep 25 08:18:28 >>> BRT >>> 2013 >>> root@dev:/root/work/freebsd/head/obj/mipseb/mips.mips/root/work/freebsd/head/src/sys/DIR-825_Matheus >>> mips >>> >>> I changed the kernel, but that much. And I don't know exactly where is the kernel conf file. >>> >>> may be it ? >>> >>> matheus >>> >>> >>> -- >>> We will call you Cygnus, >>> The God of balance you shall be >>> >>> A: Because it messes up the order in which people normally read text. >>> Q: Why is top-posting such a bad thing? >>> >>> http://en.wikipedia.org/wiki/Posting_style >>> _______________________________________________ >>> freebsd-embedded@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-embedded >>> To unsubscribe, send any mail to "freebsd-embedded-unsubscribe@freebsd.org" >> > > > -- > We will call you Cygnus, > The God of balance you shall be > > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > > http://en.wikipedia.org/wiki/Posting_style_______________________________________________ > freebsd-embedded@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-embedded > To unsubscribe, send any mail to "freebsd-embedded-unsubscribe@freebsd.org" -- We will call you Cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style ------=_20140527161721_72334 Content-Type: application/octet-stream; name="art.bin" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="art.bin" //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////6VaAAAAA2AA FowAKWAIAAECgGAsFoyglVAAFowAKlAIAAECgFAsFoyglVBkDMAFBFBsOBEAA0AEBzsAQEB0AAMA AEAAAAABwmA0AEQAAP////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////DLiG+uASAgEA AAAfIBGRU1lEAwMAAAAAAAAABxMABAEA/wIAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALQsLCwsLC+AADg4OAAIOAMrKygkBAAAAAAAABgICAAAA Dg4CAAAAAAAALAAAAAAAAAICDQEAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAA AAAQAAAAAAAAASAAAAAtICALAAAQ4gANDQ0AAg4c////BgEAAAAAAAAGAwMCAAAODgIAAAAAAAAt AAAAAAAAAwMNAQAAAAAAAJIAAJIAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwjqz/AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABxovQlBFVGFrbAAA AAAAAAAAAAACBQ4gNRQfNVddAAAAAAAAAAAAAAYZLEJPRVJfaWsAAAAAAAAAAAAAAgQNITQTHjFR WwAAAAAAAAAAAAAHGSxCTUVRXWdpAAAAAAAAAAAAAAMGDh8tEhsrSlQAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMVKz1QRVFjbm4AAAAAAAAAAAAABw4f MFUgLExqagAAAAAAAAAAAAADFixBTkRSYGxtAAAAAAAAAAAAAAMOHDdSIC9IZWcAAAAAAAAAAAAA BBcsOktCS11paQAAAAAAAAAAAAAIDx81ViEqSWRjAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAATBwaGBZoHBoYFrQcGhgWzRwaGBb/AAAAAP8AAAAA/wAAAAD/AAAAAEwcHBwc HBoUElgcHBwcHBoUEmgcHBwcHBoUEowcHBwcHBoUDrQcHBwcHBoUDr0cHBwcHBoUCs0cHBwcHBoU Cv8AAAAAAAAAAE4cHBwcHBoUElYcHBwcHBoUEl4cHBwcHBoUEo4cHBwcHBoUDq4cHBwcHBoUDr8c HBwcHBoUCsccHBwcHBoUCv8AAAAAAAAAAHAgICAguCAgICD/AAAAAHAeHBoYiR4cGhisHhwaGP8A AAAAcB4eHh4cHBQSiR4eHh4cHBQSrB4eHh4cHBQS/wAAAAAAAAAAcB4eHh4cHBQSiR4eHh4cHBQS rB4eHh4cHBQS/wAAAAAAAAAAEBYYERIVF0BGQUJFMDY4MTI1NwAAAAAATBFQXmgejF6gXrRevWHN IUwRUF5oHoxeoF60Xr1hzSEAAAAAAAAAAAAAAAAAAAAATBRQYGgijGKgYrRivWDNIEwUUGBoIoxi oGK0Yr1gzSAAAAAAAAAAAAAAAAAAAAAAThlWYWYijmKeYq4iv2DHYE4ZVmFmIo5inmKuIr9gx2AA AAAAAAAAAAAAAAAAAAAAcCJ1ZqIjAAAAAAAAAAAAAHAidWaiIwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAcB51ZKIcAAAAAAAAAAAAAHAedWSiHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcB51 ZKIZAAAAAAAAAAAAAHAedWSiGQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAehh/ZJNkmBUAAAAA AAAAAHoYf2STZJgVAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASlpQWlxaaFoAAAAAAAAAAEpaUFpc WmhaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASltQW1xbaFsAAAAAAAAAAEpbUFtcW2hbAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAcB51XqweuB4AAAAAAAAAAHAedV6sHrgeAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAcCF1YawhAAAAAAAAAAAAAHAhdWGsIQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA cCJ1YpgiAAAAAAAAAAAAAHAidWKYIgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATB1cXWgdjGGg YbRhvWHNIUwdXF1oHYxhoGG0Yb1hzSEAAAAAAAAAAAAAAAAAAAAATB1QXWgdjGGgYbRhvWHNIUwd UF1oHYxhoGG0Yb1hzSEAAAAAAAAAAAAAAAAAAAAATh1WXWYdjmGeYa4hAAAAAE4dVl1mHY5hnmGu IQAAAAAAAAAAAAAAAAAAAAAAAAAAcBx1XKwcAAAAAAAAAAAAAHAcdVysHAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAcBx1XKwcAAAAAAAAAAAAAHAcdVysHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAcBx1XKwcAAAAAAAAAAAAAHAcdVysHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAehx/XJNc mBwAAAAAAAAAAHocf1yTXJgcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////+lWgAAAANgABaMAClgCAABAoBgLBaMoJRQABaMACpQCAABAoBQLBaM oJRQZAzABQRQbDgRAANABAc7AEBAdAADAABAAAAAAcJgNABEAAD///////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////wy4IOLgEgEBAAAAH1lEkVMgEQMDAAAAAAAAAAcTAAQAAf8CAAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABWAAAAVgAAAAAAAAB4AAAACwgIAsAAAvi AA4ODgACDhzKysoDAQAAAAAAAAYEBAAAAA4OAhUVAB8fACwAAAAAAAAEBF0BAAAAAAAAjoyIjoyI gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAEAAAAAAAAAEgAAAALSAgCwAAEOIADQ0NAAIOHP// /wYBAAAAAAAABgMDAQAADg4CGRkAHx8ALQAAAAAAAAMDHQEAAAAAAACSAACSAACAAAAAAAAAAAAA AAAAAAAAAAAAAExWZHiMqrnNAAAAAC5GYG11SV1tdHYAAAAAAAAAAAAACx5IgqQRIkFaYAAAAAAA AAAAAAArQ1xsdEhcbHJ1AAAAAAAAAAAAAAwcQ4K0ESNCWF4AAAAAAAAAAAAAKUFaanNIW2txdAAA AAAAAAAAAAALG0SBthMkRVlfAAAAAAAAAAAAAClAWmt0SFtsc3YAAAAAAAAAAAAADR9Kh78VKEhd ZgAAAAAAAAAAAAAkO1RlcUhaaXBzAAAAAAAAAAAAAA0fSYPAGixPX2UAAAAAAAAAAAAAFy5HX2tI XWhvcAAAAAAAAAAAAAAJFS9okBkyRE9RAAAAAAAAAAAAAA4kPFVmSlxpbW0AAAAAAAAAAAAABQwf SG4ZKj1EQwAAAAAAAAAAAAACFy5HW0dXZGRkAAAAAAAAAAAAAAIFESpLFiExMTIAAAAAAAAAAAAA J0BbbnZIXG51eAAAAAAAAAAAAAALG0GAqBIjQVNYAAAAAAAAAAAAACc/WWx1R1psc3YAAAAAAAAA AAAACxtAf6kSIkJSWAAAAAAAAAAAAAAnP1lsdEdabHN2AAAAAAAAAAAAAAoaPXuqESFAUloAAAAA AAAAAAAAKUBZa3RIWmxydgAAAAAAAAAAAAAKGT17rhIgP1NeAAAAAAAAAAAAAClBW292SVxudHgA AAAAAAAAAAAACBY1c6AOHDdNWQAAAAAAAAAAAAAiOVJocUlaaXF0AAAAAAAAAAAAAAMMG0RxCxIl OkYAAAAAAAAAAAAAFi1FXWlHW2ZtbgAAAAAAAAAAAAADBxIvVAoVJDc4AAAAAAAAAAAAAAcdNExc SFhiY2MAAAAAAAAAAAAAAQQKHDULFSIlJQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEwcGhgWaBwaGBa0HBoYFs0cGhgW /wAAAAD/AAAAAP8AAAAA/wAAAABMHBwcHBwaFBJYHBwcHBwaFBJoHBwcHBwaFBKMHBwcHBwaFA60 HBwcHBwaFA69HBwcHBwaFArNHBwcHBwaFAr/AAAAAAAAAABOHBwcHBwaFBJWHBwcHBwaFBJeHBwc HBwaFBKOHBwcHBwaFA6uHBwcHBwaFA6/HBwcHBwaFArHHBwcHBwaFAr/AAAAAAAAAABwICAgILgg ICAg/wAAAABwHhwaGIkeHBoYrB4cGhj/AAAAAHAeHh4eHBwUEokeHh4eHBwUEqweHh4eHBwUEv8A AAAAAAAAAHAeHh4eHBwUEokeHh4eHBwUEqweHh4eHBwUEv8AAAAAAAAAABAWGBESFRdARkFCRTA2 ODEyNTcAAAAAAEwRUF5oHoxeoF60Xr1hzSFMEVBeaB6MXqBetF69Yc0hAAAAAAAAAAAAAAAAAAAA AEwUUGBoIoxioGK0Yr1gzSBMFFBgaCKMYqBitGK9YM0gAAAAAAAAAAAAAAAAAAAAAE4ZVmFmIo5i nmKuIr9gx2BOGVZhZiKOYp5iriK/YMdgAAAAAAAAAAAAAAAAAAAAAHAidWaiIwAAAAAAAAAAAABw InVmoiMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAedWSiHAAAAAAAAAAAAABwHnVkohwAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAedWSiGQAAAAAAAAAAAABwHnVkohkAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAHoYf2STZJgVAAAAAAAAAAB6GH9kk2SYFQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAEpaUFpcWmhaAAAAAAAAAABKWlBaXFpoWgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEpbUFtc W2hbAAAAAAAAAABKW1BbXFtoWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAedV6sHrgeAAAAAAAA AABwHnVerB64HgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAhdWGsIQAAAAAAAAAAAABwIXVhrCEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAidWKYIgAAAAAAAAAAAABwInVimCIAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAEwdXF1oHYxhoGG0Yb1hzSFMHVxdaB2MYaBhtGG9Yc0hAAAAAAAAAAAA AAAAAAAAAEwdUF1oHYxhoGG0Yb1hzSFMHVBdaB2MYaBhtGG9Yc0hAAAAAAAAAAAAAAAAAAAAAE4d Vl1mHY5hnmGuIQAAAABOHVZdZh2OYZ5hriEAAAAAAAAAAAAAAAAAAAAAAAAAAHAcdVysHAAAAAAA AAAAAABwHHVcrBwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAcdVysHAAAAAAAAAAAAABwHHVc rBwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAcdVysHAAAAAAAAAAAAABwHHVcrBwAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAHocf1yTXJgcAAAAAAAAAAB6HH9ck1yYHAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////zg0OmM5OmIyOjVjOmM2OmJjAP//ODQ6Yzk6YjI6NWM6YzY6YmQA//8weDNhAP////////// /////////////////////////////////////////////////////////w== ------=_20140527161721_72334-- From owner-freebsd-embedded@FreeBSD.ORG Thu Jun 19 15:44:07 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 066539EC for ; Thu, 19 Jun 2014 15:44:07 +0000 (UTC) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 988C52D77 for ; Thu, 19 Jun 2014 15:44:06 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id u56so2493781wes.7 for ; Thu, 19 Jun 2014 08:44:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=/l8LV1sJ191TZlJ/3hTaK7BcbxlxenFMgmfoUpoNK+g=; b=PbNFOrhONc0r/vmheq2gXkt0FytSl4tyUD9a0oKDgIvuOLCENLq0hCEryORoYVRI4o 6nm9+jnusd8FJItqUWGLO+E0bVvnrEpPAA2WRyCXKtDTMwrOVkg6/csnApkjr0FHz0Tc Pb2//Ebie5hT2Sv2oabM0PEvddCGvTMUbC0Rus91pmsAF240vXSV2PU8S3fnzrJfNVM+ AuwmO+hkzXjFzgm2mvep6MvCOaC752C9TqS8fh8ckOM2Q2kDiPzXgPsfgo3AblE1mBlJ wRzfNinUn/0rpnTgQboSBzug7OaQstzLvnMETVX296RkEt9l+LVGF24diLcVNyJ3Ctvp TotA== MIME-Version: 1.0 X-Received: by 10.194.91.144 with SMTP id ce16mr5788803wjb.18.1403192644858; Thu, 19 Jun 2014 08:44:04 -0700 (PDT) Received: by 10.216.23.1 with HTTP; Thu, 19 Jun 2014 08:44:04 -0700 (PDT) Date: Thu, 19 Jun 2014 17:44:04 +0200 Message-ID: Subject: Strange slowdown of zlib. From: Magnus Nilsson To: freebsd-embedded@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 15:44:07 -0000 I have the strangest behaviour of zlib on FreeBSD 8.2 (ARM, but I don't think it's necessarily an ARM specific issue). Doing # md5 /lib/libz.so.5 or # cp /lib/libz.so.5 /tmp/ # export LD_LIBRARY_PATH=/tmp/ slows down applications (I've tested bsdtar and gzip) using zlib to a crawl on my system. In the later case, doing # unset LD_LIBRARY_PATH reverts the issue. However, I haven't found any way to recover from the first case, apart from rebooting - then the execution time is back to normal. Here is a log of what I describe above (first moving zlib, then doing the md5): # cp some2MBfile /tmp/ # time gzip /tmp/some2MBfile real 0m0.325s user 0m0.284s sys 0m0.037s # rm /tmp/some2MBfile.gz # cp /lib/libz.so.5 /tmp/ # export LD_LIBRARY_PATH=/tmp/ # cp some2MBfile /tmp/ # time gzip /tmp/some2MBfile real 0m11.949s user 0m11.635s sys 0m0.035s # rm /tmp/some2MBfile.gz # unset LD_LIBRARY_PATH # cp some2MBfile /tmp/ # time gzip /tmp/some2MBfile real 0m0.325s user 0m0.288s sys 0m0.035s # rm /tmp/some2MBfile.gz # md5 /lib/libz.so.5 # cp some2MBfile /tmp/ # time gzip /tmp/some2MBfile real 0m11.919s user 0m11.608s sys 0m0.031s # rm /tmp/some2MBfile.gz Do you have any idea what could be going on? Any clues are welcome. Kind regards/Magnus From owner-freebsd-embedded@FreeBSD.ORG Thu Jun 19 15:59:06 2014 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4AE6F363; Thu, 19 Jun 2014 15:59:06 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 144FC2E9F; Thu, 19 Jun 2014 15:59:02 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Wxejm-000NP0-QI; Thu, 19 Jun 2014 15:58:54 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s5JFwqjx001259; Thu, 19 Jun 2014 09:58:52 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+DgdKx4U94WaNu8MaykbGV Subject: Re: Strange slowdown of zlib. From: Ian Lepore To: Magnus Nilsson In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Jun 2014 09:58:51 -0600 Message-ID: <1403193531.20883.269.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm , freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 15:59:06 -0000 On Thu, 2014-06-19 at 17:44 +0200, Magnus Nilsson wrote: > I have the strangest behaviour of zlib on FreeBSD 8.2 (ARM, but I don't > think it's necessarily an ARM specific issue). > Doing > # md5 /lib/libz.so.5 > or > # cp /lib/libz.so.5 /tmp/ > # export LD_LIBRARY_PATH=/tmp/ > slows down applications (I've tested bsdtar and gzip) using zlib to a crawl > on my system. > > In the later case, doing > # unset LD_LIBRARY_PATH > reverts the issue. > However, I haven't found any way to recover from the first case, apart from > rebooting - then the execution time is back to normal. > > Here is a log of what I describe above (first moving zlib, then doing the > md5): > # cp some2MBfile /tmp/ > # time gzip /tmp/some2MBfile > real 0m0.325s > user 0m0.284s > sys 0m0.037s > # rm /tmp/some2MBfile.gz > # cp /lib/libz.so.5 /tmp/ > # export LD_LIBRARY_PATH=/tmp/ > # cp some2MBfile /tmp/ > # time gzip /tmp/some2MBfile > real 0m11.949s > user 0m11.635s > sys 0m0.035s > # rm /tmp/some2MBfile.gz > # unset LD_LIBRARY_PATH > # cp some2MBfile /tmp/ > # time gzip /tmp/some2MBfile > real 0m0.325s > user 0m0.288s > sys 0m0.035s > # rm /tmp/some2MBfile.gz > # md5 /lib/libz.so.5 > # cp some2MBfile /tmp/ > # time gzip /tmp/some2MBfile > real 0m11.919s > user 0m11.608s > sys 0m0.031s > # rm /tmp/some2MBfile.gz > > Do you have any idea what could be going on? > Any clues are welcome. > > Kind regards/Magnus This is a known problem on armv4/v5 in freebsd 8. Here is some archived info on it including patches that work around the problem (rather crudely, but good enough for our needs at $work). http://lists.freebsd.org/pipermail/freebsd-arm/2012-January/003288.html -- Ian From owner-freebsd-embedded@FreeBSD.ORG Sat Jun 21 12:13:05 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A22C782C; Sat, 21 Jun 2014 12:13:05 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E89CC2D85; Sat, 21 Jun 2014 12:13:04 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id hi2so2111177wib.4 for ; Sat, 21 Jun 2014 05:13:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yHZR7G/LNwP1SKVPisnbW1QpvfnGA1D4zMWOs2DiV8o=; b=0OfSmqqkopMGqr/GBGl8CXwmg/hQo6/U33XVqbDlN1d0+bDDPrsvcq+s9tz1nEVB0D vr7qbd51AeE9xFe136+TAn6jmQA014fDRtfcomQccdqgtvhKJxiI93sQgIWGocpy8dwH BIeoRGXZXQwqNOirnFFPXyWklhWfrUKLQpzV84n1hfjwEyhlgOaz9L/xX+CTO7oSG7+e D6dzbYpG9PuKohL/WuJERVdbXffCqN6OXorpqXyceZCi7tMXsCRfvSBs3vKuzuxy096b UwsXNL+x5j87pspg9Ho47nF7Z+PfS1V9mpqHlSPiz755aexZ/dhdPdbKLU/ijpb+KCet LsQg== MIME-Version: 1.0 X-Received: by 10.194.91.144 with SMTP id ce16mr11446868wjb.18.1403352782359; Sat, 21 Jun 2014 05:13:02 -0700 (PDT) Received: by 10.216.23.1 with HTTP; Sat, 21 Jun 2014 05:13:01 -0700 (PDT) In-Reply-To: <1403193531.20883.269.camel@revolution.hippie.lan> References: <1403193531.20883.269.camel@revolution.hippie.lan> Date: Sat, 21 Jun 2014 14:13:01 +0200 Message-ID: Subject: Re: Strange slowdown of zlib. From: Magnus Nilsson To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arm , freebsd-embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2014 12:13:05 -0000 On Thu, Jun 19, 2014 at 5:58 PM, Ian Lepore wrote: > On Thu, 2014-06-19 at 17:44 +0200, Magnus Nilsson wrote: >> I have the strangest behaviour of zlib on FreeBSD 8.2 (ARM, but I don't >> think it's necessarily an ARM specific issue). >> Doing >> # md5 /lib/libz.so.5 >> or >> # cp /lib/libz.so.5 /tmp/ >> # export LD_LIBRARY_PATH=/tmp/ >> slows down applications (I've tested bsdtar and gzip) using zlib to a crawl >> on my system. >> >> In the later case, doing >> # unset LD_LIBRARY_PATH >> reverts the issue. >> However, I haven't found any way to recover from the first case, apart from >> rebooting - then the execution time is back to normal. >> >> Here is a log of what I describe above (first moving zlib, then doing the >> md5): >> # cp some2MBfile /tmp/ >> # time gzip /tmp/some2MBfile >> real 0m0.325s >> user 0m0.284s >> sys 0m0.037s >> # rm /tmp/some2MBfile.gz >> # cp /lib/libz.so.5 /tmp/ >> # export LD_LIBRARY_PATH=/tmp/ >> # cp some2MBfile /tmp/ >> # time gzip /tmp/some2MBfile >> real 0m11.949s >> user 0m11.635s >> sys 0m0.035s >> # rm /tmp/some2MBfile.gz >> # unset LD_LIBRARY_PATH >> # cp some2MBfile /tmp/ >> # time gzip /tmp/some2MBfile >> real 0m0.325s >> user 0m0.288s >> sys 0m0.035s >> # rm /tmp/some2MBfile.gz >> # md5 /lib/libz.so.5 >> # cp some2MBfile /tmp/ >> # time gzip /tmp/some2MBfile >> real 0m11.919s >> user 0m11.608s >> sys 0m0.031s >> # rm /tmp/some2MBfile.gz >> >> Do you have any idea what could be going on? >> Any clues are welcome. >> >> Kind regards/Magnus > > This is a known problem on armv4/v5 in freebsd 8. Here is some archived > info on it including patches that work around the problem (rather > crudely, but good enough for our needs at $work). > > http://lists.freebsd.org/pipermail/freebsd-arm/2012-January/003288.html > > -- Ian > > Unfortunately, both your patches from http://lists.freebsd.org/pipermail/freebsd-arm/2012-January/003288.html were already in. Enabling O_DIRECT in ffs_read() in ffs_vnops_icache_hack.bin makes no difference either. I have patched r224049, r221844, r212507 and r209223 (r205028 and r203637 were already in) mentioned by Warner Losh in http://lists.freebsd.org/pipermail/freebsd-arm/2012-January/003292.html in case they'd make any difference, but no. If I run Maks Verver's simple testcase from http://lists.freebsd.org/pipermail/freebsd-arm/2010-March/002243.html , it consistently runs ~15s on my 1GHz CPU. After 'cat testcase > /dev/null', it takes ~14min of course. While e.g. cat or md5 of an executable affects its speed, e.g. cp does not. Could there be some read access that's unaffected by your patches? (As I said privately, thank you very much for setting me on the right track!) KR/Magnus From owner-freebsd-embedded@FreeBSD.ORG Sat Jun 21 14:03:02 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03F17E69; Sat, 21 Jun 2014 14:03:02 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CEB9F2559; Sat, 21 Jun 2014 14:03:01 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s5LE30gk098315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Jun 2014 07:03:00 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s5LE30CV098314; Sat, 21 Jun 2014 07:03:00 -0700 (PDT) (envelope-from jmg) Date: Sat, 21 Jun 2014 07:03:00 -0700 From: John-Mark Gurney To: Magnus Nilsson Subject: Re: Strange slowdown of zlib. Message-ID: <20140621140300.GO31367@funkthat.com> Mail-Followup-To: Magnus Nilsson , Ian Lepore , freebsd-arm , freebsd-embedded@freebsd.org References: <1403193531.20883.269.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 21 Jun 2014 07:03:00 -0700 (PDT) Cc: freebsd-arm , freebsd-embedded@freebsd.org, Ian Lepore X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2014 14:03:02 -0000 Magnus Nilsson wrote this message on Sat, Jun 21, 2014 at 14:13 +0200: > While e.g. cat or md5 of an executable affects its speed, e.g. cp does not. > Could there be some read access that's unaffected by your patches? I believe that cp uses mmap instead of the read syscall like cat and md5... So this may be the case... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-embedded@FreeBSD.ORG Mon Jun 23 22:44:29 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E7AF7C75; Mon, 23 Jun 2014 22:44:29 +0000 (UTC) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3A05E2DAE; Mon, 23 Jun 2014 22:44:29 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id q59so7751174wes.40 for ; Mon, 23 Jun 2014 15:44:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2PzU+UREL0fw6riva/9Ox7FINRm8T6mQLb2BoVjwLRY=; b=OAPtKOmpHPOEiaaa5bbsGQMP/iznyP2JsRIkEgOA9aTYGTPYTQCx0EgqlhFvcF/bX1 GMfJSWFvZ+kBirnelVg1f1yN+bPoJeg4j0QUpEbL8jCjWgz2EcSfvEvRl27T/bXNpwbf U0bgWRQRV1h6bs81R3ijn4Df8aBfdX2b1txPWiFwSYq1HInR23rs4tEbv3xfvKU+CJ2A BdvGAIfYhfIwY8YHRGAImV3cjK+fxb5A2G0kw59gRcrc38Zi+1dcDJG7Nt1/7UqhMBxH 3rFBvfF93/zLK6UQ2MRJDk31JzxuSLY7QoUbhT0/q4L7rAdAKc5vksQnqdHuKF0mIpsf 1wiw== MIME-Version: 1.0 X-Received: by 10.194.92.177 with SMTP id cn17mr18585857wjb.71.1403563467495; Mon, 23 Jun 2014 15:44:27 -0700 (PDT) Received: by 10.216.23.1 with HTTP; Mon, 23 Jun 2014 15:44:27 -0700 (PDT) In-Reply-To: <20140621140300.GO31367@funkthat.com> References: <1403193531.20883.269.camel@revolution.hippie.lan> <20140621140300.GO31367@funkthat.com> Date: Tue, 24 Jun 2014 00:44:27 +0200 Message-ID: Subject: Re: Strange slowdown of zlib. From: Magnus Nilsson To: John-Mark Gurney , freebsd-embedded@freebsd.org, freebsd-arm Content-Type: text/plain; charset=UTF-8 Cc: Ian Lepore X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 22:44:30 -0000 On Sat, Jun 21, 2014 at 4:03 PM, John-Mark Gurney wrote: > Magnus Nilsson wrote this message on Sat, Jun 21, 2014 at 14:13 +0200: >> While e.g. cat or md5 of an executable affects its speed, e.g. cp does not. >> Could there be some read access that's unaffected by your patches? > > I believe that cp uses mmap instead of the read syscall like cat and > md5... So this may be the case... > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." mmap() seems unaffected, well spotted. Not sure if it would be reasonable to use that fact for a workaround? I've done more patching and testing. Mark Tinguely's conservative, unofficial patch http://lists.freebsd.org/pipermail/freebsd-arm/2010-November/002635.html does not fix the issue. Grzegorz Bernacki's proof-of-concept patch http://lists.freebsd.org/pipermail/freebsd-arm/2010-March/002270.html /does/ fix the issue! But what's the potential downside? Debugging issues, as suggested in http://lists.freebsd.org/pipermail/freebsd-arm/2010-March/002290.html ? Performance issues? Something worse? I've looked at later releases (9.3) for backporting, but can't find anything that that handles PVF_EXEC as a special case like Mark and Grzegorz. From owner-freebsd-embedded@FreeBSD.ORG Mon Jul 7 14:25:43 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9241713D for ; Mon, 7 Jul 2014 14:25:43 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9AD8E2B23 for ; Mon, 7 Jul 2014 14:25:42 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id EDE08B843; Mon, 7 Jul 2014 16:25:38 +0200 (SAST) Date: Mon, 7 Jul 2014 16:25:38 +0200 From: John Hay To: freebsd-embedded@freebsd.org Subject: CAMBRIA and more than one atheros card Message-ID: <20140707142538.GA43661@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 14:25:43 -0000 Hi Guys, I'm further with getting my stuff working on the CAMBRIA xscale boards, but now see this ath1: ath_legacy_rxbuf_init: bus_dmamap_load_mbuf_sg failed; error 12 error when trying to configure a second or third atheros board. Below is the script run with -x with its output. The same is working fine on an Avila board. The Avila has 64M RAM and the CAMBRIA 128M. The userlevel code is the same for both and in trying to see if it is something missing in the kernel config, I have made a common kernel config file with all the common AVILA and CAMBRIA configs and then included that in a new AVILA and CAMBRIA config file. That gave the same result. The output is from a 2 week old -current/head. ############################## ~ # uname -a FreeBSD 11.0-CURRENT FreeBSD 11.0-CURRENT #5 r267954M: Fri Jun 27 14:49:04 SAST 2014 jhay@dolphin.meraka.csir.co.za:/usr/obj/arm.armeb/snaps/arm/11-tst/src/sys/SMALL-CAMBRIA arm ~ # /root/do-wlans + crflags='wlanmode adhoc' + dbgval=0x20000500c + ifconfig wlan0 create wlandev ath0 wlanmode adhoc wlan0: Ethernet address: 00:80:48:4f:24:ea + ifconfig wlan0 inet 10.0.1.1/24 channel 36 ssid ptabb bssid 05:05:ca:fe:ba:be + sysctl dev.ath.1.debug=0x20000500c dev.ath.1.debug: 0 -> 8589955084 + ifconfig wlan1 create wlandev ath1 wlanmode adhoc wlan1: Ethernet address: 00:80:48:4f:24:da + ifconfig wlan1 inet 10.0.2.1/24 channel 40 ssid ptabb bssid 05:06:ca:fe:ba:be ath1: ath_init: if_flags 0x8803 ath1: ath_stop_locked: invalid 0 if_flags 0x8803 ath1: ath_legacy_rxbuf_init: bus_dmamap_load_mbuf_sg failed; error 12 ath1: ath_legacy_startrecv: ath_rxbuf_init failed 12 ath1: unable to start recv logic + sysctl dev.ath.1.debug=0 dev.ath.1.debug: 8589955084 -> 0 + sysctl dev.ath.2.debug=0x20000500c dev.ath.2.debug: 0 -> 8589955084 + ifconfig wlan2 create wlandev ath2 wlanmode adhoc wlan2: Ethernet address: 00:21:a4:32:38:c2 + ifconfig wlan2 inet 10.0.3.1/24 channel 1 ssid ptabb bssid 05:07:ca:fe:ba:be ath2: ath_init: if_flags 0x8803 ath2: ath_stop_locked: invalid 0 if_flags 0x8803 ath2: ath_legacy_rxbuf_init: bus_dmamap_load_mbuf_sg failed; error 12 ath2: ath_legacy_startrecv: ath_rxbuf_init failed 12 ath2: unable to start recv logic + sysctl dev.ath.2.debug=0 dev.ath.2.debug: 8589955084 -> 0 :~ # netstat -m 182/328/510 mbufs in use (current/cache/total) 64/192/256/2552 mbuf clusters in use (current/cache/total/max) 64/189 mbuf+clusters out of packet secondary zone in use (current/cache) 0/0/0/1275 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/378 9k jumbo clusters in use (current/cache/total/max) 0/0/0/212 16k jumbo clusters in use (current/cache/total/max) 173K/466K/639K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/3/1488 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile ############################## CAMBRIA config file ############################## include XSCALE-ARM ident SMALL-CAMBRIA include "../xscale/ixp425/std.ixp435" hints "CAMBRIA.hints" options IXP4XX_FLASH_SIZE=0x02000000 # stock 2358 comes w/ 32M device cambria_fled # Font Panel LED on I2C bus device cambria_led # 8-LED latch device cambria_gpio # GPIO pins on J11 env "SMALL-AVILA.env" ############################## AVILA config file ############################## include XSCALE-ARM ident SMALL-AVILA include "../xscale/ixp425/std.ixp425" hints "AVILA.hints" # Default places to look for devices. device avila_led device avila_gpio # GPIO pins on J8 env "SMALL-AVILA.env" ############################## XSCALE-ARM config file ############################## include "../xscale/ixp425/std.avila" options XSCALE_CACHE_READ_WRITE_ALLOCATE makeoptions MODULES_OVERRIDE="" makeoptions CONF_CFLAGS=-mcpu=xscale options HZ=100 options DEVICE_POLLING options ROOTDEVNAME=\"ufs:ad0s1a\" options SCHED_4BSD # 4BSD scheduler options INET # Legacy InterNETworking options INET6 # InterNETworking options GEOM_PART_BSD # BSD partition scheme options GEOM_PART_MBR # MBR partition scheme options TMPFS # Efficient memory filesystem options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options HWPMC_HOOKS device hwpmc device pci device uart device ixpwdog # watchdog timer device cfi # flash support device cfid # flash disk support device geom_redboot # redboot fis parser device iicbus device iicbb device iic device ixpiic # I2C bus glue device ds1672 # DS1672 on I2C bus device ad7418 # AD7418 on I2C bus device gpio device gpioled device ata device avila_ata # Gateworks CF/IDE support device npe # Network Processing Engine device npe_fw device firmware device qmgr # Q Manager (required by npe) device mii # NB: required by npe device ether device bpf device loop device if_bridge device md device random # Entropy device device wlan # 802.11 support options IEEE80211_DEBUG options IEEE80211_SUPPORT_TDMA options IEEE80211_SUPPORT_MESH device wlan_wep # 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device wlan_xauth device wlan_acl device ath # Atheros NICs device ath_pci # Atheros pci/cardbus glue options ATH_DEBUG options ATH_DIAGAPI device ath_rate_sample # SampleRate tx rate control for ath options AH_DEBUG options AH_PRIVATE_DIAG device ath_ar5212 device ath_rf2413 device ath_rf2417 device ath_rf2425 device ath_rf5111 device ath_rf5112 device ath_rf5413 device ath_ar5416 options AH_SUPPORT_AR5416 device ath_ar9160 device ath_ar9280 device usb options USB_EHCI_BIG_ENDIAN_DESC device ohci device ehci device umass device scbus # SCSI bus (required for ATA/SCSI) device da # Direct Access (disks) device pass # Passthrough device (direct ATA/SCSI access) device gif device tun ############################## Regards John -- John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za From owner-freebsd-embedded@FreeBSD.ORG Mon Jul 7 16:25:36 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F02B36F3; Mon, 7 Jul 2014 16:25:35 +0000 (UTC) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A0E2A2694; Mon, 7 Jul 2014 16:25:35 +0000 (UTC) Received: by mail-qa0-f43.google.com with SMTP id k15so3846903qaq.30 for ; Mon, 07 Jul 2014 09:25:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=9IrPuMrMy+xqvMnhTZ+RvMG3GTpVjYfrG+cBjkSpsPc=; b=ATSgpl9CAXdalH3ZZiRR9+YbOp/lN+vxPL7oflmM4HBcnhFaXFzVQOPzDiQnRbfAAx 9Z5L/71cHbTHYGihHjweCvvOyWi0e6zpqhrsmmlDGMm20T2bCEUvf9OmhhMFMDvVM0n/ A/MiK8dSoECxS/xzGOqh5hHumUmnPZcZkikeUYxHGCiTLWTEDnQg9SZaVDZJG0fH8Zjo 4IpuEmpm/dDzw38GmkOZzkPElnabQMPPVpyAt1d3b4mmXAFj6lx+Wq+lDFmp1XpTX6+v hKVC/1y8elhdfhg6YYLKmcLImDlQrjHoRtkEER69cCwVGMmfcNb3IVHV8AnpSaJ/g7XG kPVA== MIME-Version: 1.0 X-Received: by 10.224.171.197 with SMTP id i5mr4892844qaz.55.1404750334800; Mon, 07 Jul 2014 09:25:34 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.202.193 with HTTP; Mon, 7 Jul 2014 09:25:34 -0700 (PDT) In-Reply-To: <20140707142538.GA43661@zibbi.meraka.csir.co.za> References: <20140707142538.GA43661@zibbi.meraka.csir.co.za> Date: Mon, 7 Jul 2014 09:25:34 -0700 X-Google-Sender-Auth: kOwey5S_-7DboajiEihuCL2Wk9Q Message-ID: Subject: Re: CAMBRIA and more than one atheros card From: Adrian Chadd To: John Hay , "freebsd-wireless@freebsd.org" Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 16:25:36 -0000 hi, That call is returning ENOMEM. I'm not sure why. It allocated an mbuf fine, but it couldn't allocate the DMA map. What's the output of "vmstat -z" ? I wonder if it's failing an allocation. -a On 7 July 2014 07:25, John Hay wrote: > Hi Guys, > > I'm further with getting my stuff working on the CAMBRIA xscale boards, > but now see this > > ath1: ath_legacy_rxbuf_init: bus_dmamap_load_mbuf_sg failed; error 12 > > error when trying to configure a second or third atheros board. Below > is the script run with -x with its output. The same is working fine > on an Avila board. The Avila has 64M RAM and the CAMBRIA 128M. The > userlevel code is the same for both and in trying to see if it is > something missing in the kernel config, I have made a common kernel > config file with all the common AVILA and CAMBRIA configs and then > included that in a new AVILA and CAMBRIA config file. That gave the > same result. The output is from a 2 week old -current/head. > > ############################## > ~ # uname -a > FreeBSD 11.0-CURRENT FreeBSD 11.0-CURRENT #5 r267954M: Fri Jun 27 14:49:04 SAST 2014 jhay@dolphin.meraka.csir.co.za:/usr/obj/arm.armeb/snaps/arm/11-tst/src/sys/SMALL-CAMBRIA arm > ~ # /root/do-wlans > + crflags='wlanmode adhoc' > + dbgval=0x20000500c > + ifconfig wlan0 create wlandev ath0 wlanmode adhoc > wlan0: Ethernet address: 00:80:48:4f:24:ea > + ifconfig wlan0 inet 10.0.1.1/24 channel 36 ssid ptabb bssid 05:05:ca:fe:ba:be > + sysctl dev.ath.1.debug=0x20000500c > dev.ath.1.debug: 0 -> 8589955084 > + ifconfig wlan1 create wlandev ath1 wlanmode adhoc > wlan1: Ethernet address: 00:80:48:4f:24:da > + ifconfig wlan1 inet 10.0.2.1/24 channel 40 ssid ptabb bssid 05:06:ca:fe:ba:be > ath1: ath_init: if_flags 0x8803 > ath1: ath_stop_locked: invalid 0 if_flags 0x8803 > ath1: ath_legacy_rxbuf_init: bus_dmamap_load_mbuf_sg failed; error 12 > ath1: ath_legacy_startrecv: ath_rxbuf_init failed 12 > ath1: unable to start recv logic > + sysctl dev.ath.1.debug=0 > dev.ath.1.debug: 8589955084 -> 0 > + sysctl dev.ath.2.debug=0x20000500c > dev.ath.2.debug: 0 -> 8589955084 > + ifconfig wlan2 create wlandev ath2 wlanmode adhoc > wlan2: Ethernet address: 00:21:a4:32:38:c2 > + ifconfig wlan2 inet 10.0.3.1/24 channel 1 ssid ptabb bssid 05:07:ca:fe:ba:be > ath2: ath_init: if_flags 0x8803 > ath2: ath_stop_locked: invalid 0 if_flags 0x8803 > ath2: ath_legacy_rxbuf_init: bus_dmamap_load_mbuf_sg failed; error 12 > ath2: ath_legacy_startrecv: ath_rxbuf_init failed 12 > ath2: unable to start recv logic > + sysctl dev.ath.2.debug=0 > dev.ath.2.debug: 8589955084 -> 0 > :~ # netstat -m > 182/328/510 mbufs in use (current/cache/total) > 64/192/256/2552 mbuf clusters in use (current/cache/total/max) > 64/189 mbuf+clusters out of packet secondary zone in use (current/cache) > 0/0/0/1275 4k (page size) jumbo clusters in use (current/cache/total/max) > 0/0/0/378 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/212 16k jumbo clusters in use (current/cache/total/max) > 173K/466K/639K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/3/1488 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > ############################## > > CAMBRIA config file > ############################## > include XSCALE-ARM > > ident SMALL-CAMBRIA > > include "../xscale/ixp425/std.ixp435" > > hints "CAMBRIA.hints" > > options IXP4XX_FLASH_SIZE=0x02000000 # stock 2358 comes w/ 32M > > device cambria_fled # Font Panel LED on I2C bus > device cambria_led # 8-LED latch > > device cambria_gpio # GPIO pins on J11 > > env "SMALL-AVILA.env" > ############################## > > AVILA config file > ############################## > include XSCALE-ARM > > ident SMALL-AVILA > > include "../xscale/ixp425/std.ixp425" > > hints "AVILA.hints" # Default places to look for devices. > > device avila_led > > device avila_gpio # GPIO pins on J8 > > env "SMALL-AVILA.env" > ############################## > > XSCALE-ARM config file > ############################## > include "../xscale/ixp425/std.avila" > options XSCALE_CACHE_READ_WRITE_ALLOCATE > makeoptions MODULES_OVERRIDE="" > > makeoptions CONF_CFLAGS=-mcpu=xscale > options HZ=100 > options DEVICE_POLLING > > options ROOTDEVNAME=\"ufs:ad0s1a\" > > options SCHED_4BSD # 4BSD scheduler > options INET # Legacy InterNETworking > options INET6 # InterNETworking > options GEOM_PART_BSD # BSD partition scheme > options GEOM_PART_MBR # MBR partition scheme > options TMPFS # Efficient memory filesystem > options FFS # Berkeley Fast Filesystem > options SOFTUPDATES # Enable FFS soft updates support > > options HWPMC_HOOKS > device hwpmc > > > device pci > device uart > > device ixpwdog # watchdog timer > device cfi # flash support > device cfid # flash disk support > device geom_redboot # redboot fis parser > > device iicbus > device iicbb > device iic > > device ixpiic # I2C bus glue > device ds1672 # DS1672 on I2C bus > device ad7418 # AD7418 on I2C bus > > > device gpio > device gpioled > > device ata > device avila_ata # Gateworks CF/IDE support > > device npe # Network Processing Engine > device npe_fw > device firmware > device qmgr # Q Manager (required by npe) > device mii # NB: required by npe > device ether > device bpf > > device loop > device if_bridge > > device md > device random # Entropy device > > device wlan # 802.11 support > options IEEE80211_DEBUG > options IEEE80211_SUPPORT_TDMA > options IEEE80211_SUPPORT_MESH > device wlan_wep # 802.11 WEP support > device wlan_ccmp # 802.11 CCMP support > device wlan_tkip # 802.11 TKIP support > device wlan_xauth > device wlan_acl > > device ath # Atheros NICs > device ath_pci # Atheros pci/cardbus glue > options ATH_DEBUG > options ATH_DIAGAPI > device ath_rate_sample # SampleRate tx rate control for ath > > options AH_DEBUG > options AH_PRIVATE_DIAG > device ath_ar5212 > device ath_rf2413 > device ath_rf2417 > device ath_rf2425 > device ath_rf5111 > device ath_rf5112 > device ath_rf5413 > device ath_ar5416 > options AH_SUPPORT_AR5416 > device ath_ar9160 > device ath_ar9280 > > device usb > options USB_EHCI_BIG_ENDIAN_DESC > device ohci > device ehci > device umass > device scbus # SCSI bus (required for ATA/SCSI) > device da # Direct Access (disks) > device pass # Passthrough device (direct ATA/SCSI access) > > > device gif > device tun > ############################## > > > Regards > > John > -- > John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za > _______________________________________________ > freebsd-embedded@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-embedded > To unsubscribe, send any mail to "freebsd-embedded-unsubscribe@freebsd.org" From owner-freebsd-embedded@FreeBSD.ORG Mon Jul 7 16:48:18 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88D2BF02; Mon, 7 Jul 2014 16:48:18 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.freebsd.org (Postfix) with ESMTP id D414C28B5; Mon, 7 Jul 2014 16:48:16 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 6FA68B84A; Mon, 7 Jul 2014 18:48:07 +0200 (SAST) Date: Mon, 7 Jul 2014 18:48:07 +0200 From: John Hay To: Adrian Chadd Subject: Re: CAMBRIA and more than one atheros card Message-ID: <20140707164807.GA57227@zibbi.meraka.csir.co.za> References: <20140707142538.GA43661@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-wireless@freebsd.org" , "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 16:48:18 -0000 On Mon, Jul 07, 2014 at 09:25:34AM -0700, Adrian Chadd wrote: > hi, > > That call is returning ENOMEM. I'm not sure why. It allocated an mbuf > fine, but it couldn't allocate the DMA map. > > What's the output of "vmstat -z" ? I wonder if it's failing an allocation. :~ # vmstat -z ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 192, 0, 107, 19, 107, 0, 0 UMA Zones: 280, 0, 107, 5, 107, 0, 0 UMA Slabs: 56, 0, 1798, 2, 19024, 0, 0 UMA RCntSlabs: 64, 0, 128, 61, 128, 0, 0 UMA Hash: 128, 0, 11, 20, 12, 0, 0 4 Bucket: 16, 0, 10, 494, 2039, 0, 0 6 Bucket: 24, 0, 0, 0, 0, 0, 0 8 Bucket: 32, 0, 4, 374, 161, 0, 0 12 Bucket: 48, 0, 2, 334, 4, 0, 0 16 Bucket: 64, 0, 16, 299, 924, 17, 0 32 Bucket: 128, 0, 7, 148, 197, 0, 0 64 Bucket: 256, 0, 19, 56, 76, 0, 0 128 Bucket: 512, 0, 15, 17, 49, 0, 0 256 Bucket: 1024, 0, 39, 9, 2671, 996, 0 vmem btag: 28, 0, 4521, 231, 4521, 32, 0 VM OBJECT: 160, 0, 1492, 108, 34553, 0, 0 RADIX NODE: 48, 30324, 2145, 459, 124628, 0, 0 MAP: 152, 0, 3, 75, 3, 0, 0 KMAP ENTRY: 80, 0, 4, 146, 4, 0, 0 MAP ENTRY: 80, 0, 412, 238, 102729, 0, 0 VMSPACE: 1264, 0, 16, 11, 2373, 0, 0 L2 Table: 1024, 0, 106, 65, 23026, 0, 0 L2 Table: 196, 0, 48, 92, 10774, 0, 0 PV ENTRY: 28, 229824, 7771, 3749, 1285591, 0, 0 fakepg: 80, 0, 0, 0, 0, 0, 0 mt_zone: 80, 0, 191, 59, 191, 0, 0 16: 16, 0, 4016, 268, 8966, 0, 0 32: 32, 0, 1946, 196, 36992, 0, 0 64: 64, 0, 3150, 189, 37458, 0, 0 128: 128, 0, 1186, 85, 12522, 0, 0 256: 256, 0, 307, 68, 839, 0, 0 512: 512, 0, 84, 4, 3756, 0, 0 1024: 1024, 0, 53, 15, 4190, 0, 0 2048: 2048, 0, 130, 10, 3500, 0, 0 4096: 4096, 0, 1094, 9, 3455, 0, 0 dma maps: 56, 0, 2004, 84, 2004, 0, 0 dma buffer 32: 32, 0, 0, 0, 0, 0, 0 dma buffer 64: 64, 0, 0, 0, 0, 0, 0 dma buffer 128: 128, 0, 2, 153, 2, 0, 0 dma buffer 256: 256, 0, 0, 0, 0, 0, 0 dma buffer 512: 512, 0, 0, 0, 0, 0, 0 dma buffer 1024: 1024, 0, 0, 0, 0, 0, 0 dma buffer 2048: 2048, 0, 0, 0, 0, 0, 0 dma buffer 4096: 4096, 0, 0, 0, 0, 0, 0 dma coherent 32: 32, 0, 0, 0, 0, 0, 0 dma coherent 64: 64, 0, 0, 0, 0, 0, 0 dma coherent 128: 128, 0, 0, 0, 0, 0, 0 dma coherent 256: 256, 0, 0, 0, 0, 0, 0 dma coherent 512: 512, 0, 0, 0, 0, 0, 0 dma coherent 1024: 1024, 0, 0, 0, 0, 0, 0 dma coherent 2048: 2048, 0, 0, 0, 0, 0, 0 dma coherent 4096: 4096, 0, 0, 0, 0, 0, 0 SLEEPQUEUE: 44, 0, 96, 219, 96, 0, 0 64 pcpu: 8, 0, 1883, 385, 1883, 0, 0 ptr pcpu: 4, 0, 0, 0, 0, 0, 0 Files: 64, 0, 74, 241, 16140, 0, 0 TURNSTILE: 72, 0, 96, 30, 96, 0, 0 rl_entry: 32, 0, 33, 345, 33, 0, 0 umtx pi: 52, 0, 0, 0, 0, 0, 0 PROC: 800, 0, 33, 22, 2390, 0, 0 THREAD: 800, 0, 87, 8, 87, 0, 0 cpuset: 40, 0, 56, 247, 56, 0, 0 mbuf_packet: 256, 16335, 64, 189, 175, 0, 0 mbuf: 256, 16335, 118, 139, 4155, 0, 0 mbuf_cluster: 2048, 2552, 253, 3, 253, 0, 0 mbuf_jumbo_page: 4096, 1275, 0, 0, 0, 0, 0 mbuf_jumbo_9k: 9216, 378, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 212, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 sendfile_sync: 80, 0, 0, 0, 0, 0, 0 g_bio: 168, 0, 0, 144, 7360, 0, 0 ttyinq: 152, 0, 180, 28, 540, 0, 0 ttyoutq: 256, 0, 92, 43, 276, 0, 0 ata_request: 240, 0, 0, 64, 957, 0, 0 VNODE: 288, 0, 1224, 36, 1424, 0, 0 VNODEPOLL: 60, 0, 0, 0, 0, 0, 0 BUF TRIE: 48, 0, 36, 1476, 2371, 0, 0 NAMEI: 1024, 0, 0, 16, 54528, 0, 0 S VFS Cache: 72, 0, 1250, 150, 2945, 0, 0 STS VFS Cache: 116, 0, 0, 0, 0, 0, 0 L VFS Cache: 292, 0, 0, 0, 0, 0, 0 LTS VFS Cache: 336, 0, 0, 0, 0, 0, 0 procdesc: 76, 0, 0, 0, 0, 0, 0 pipe: 456, 0, 0, 32, 1349, 0, 0 Mountpoints: 688, 0, 4, 11, 4, 0, 0 ksiginfo: 80, 0, 43, 1007, 669, 0, 0 itimer: 256, 0, 1, 74, 1, 0, 0 bridge_rtnode: 36, 0, 0, 0, 0, 0, 0 KNOTE: 72, 0, 0, 0, 0, 0, 0 socket: 448, 3915, 50, 13, 1551, 0, 0 unpcb: 176, 3916, 10, 56, 170, 0, 0 ipq: 32, 126, 0, 0, 0, 0, 0 udp_inpcb: 256, 3915, 29, 46, 1128, 0, 0 udpcb: 12, 4032, 29, 475, 1128, 0, 0 tcp_inpcb: 256, 3915, 6, 69, 127, 0, 0 tcpcb: 776, 3915, 6, 9, 127, 0, 0 tcptw: 56, 792, 0, 288, 39, 0, 0 syncache: 124, 15360, 0, 128, 39, 0, 0 hostcache: 76, 15370, 0, 0, 0, 0, 0 sackhole: 20, 0, 0, 0, 0, 0, 0 udplite_inpcb: 256, 3915, 0, 0, 0, 0, 0 ripcb: 256, 3915, 1, 74, 118, 0, 0 rtentry: 108, 0, 28, 120, 28, 0, 0 selfd: 28, 0, 58, 230, 540800, 0, 0 SWAPMETA: 280, 15316, 0, 0, 0, 0, 0 FFS inode: 128, 0, 1203, 68, 1402, 0, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 1203, 27, 1402, 0, 0 md0: 512, 0, 4211, 29, 4211, 0, 0 :~ # John > > > > -a > > > On 7 July 2014 07:25, John Hay wrote: > > Hi Guys, > > > > I'm further with getting my stuff working on the CAMBRIA xscale boards, > > but now see this > > > > ath1: ath_legacy_rxbuf_init: bus_dmamap_load_mbuf_sg failed; error 12 > > > > error when trying to configure a second or third atheros board. Below > > is the script run with -x with its output. The same is working fine > > on an Avila board. The Avila has 64M RAM and the CAMBRIA 128M. The > > userlevel code is the same for both and in trying to see if it is > > something missing in the kernel config, I have made a common kernel > > config file with all the common AVILA and CAMBRIA configs and then > > included that in a new AVILA and CAMBRIA config file. That gave the > > same result. The output is from a 2 week old -current/head. > > > > ############################## > > ~ # uname -a > > FreeBSD 11.0-CURRENT FreeBSD 11.0-CURRENT #5 r267954M: Fri Jun 27 14:49:04 SAST 2014 jhay@dolphin.meraka.csir.co.za:/usr/obj/arm.armeb/snaps/arm/11-tst/src/sys/SMALL-CAMBRIA arm > > ~ # /root/do-wlans > > + crflags='wlanmode adhoc' > > + dbgval=0x20000500c > > + ifconfig wlan0 create wlandev ath0 wlanmode adhoc > > wlan0: Ethernet address: 00:80:48:4f:24:ea > > + ifconfig wlan0 inet 10.0.1.1/24 channel 36 ssid ptabb bssid 05:05:ca:fe:ba:be > > + sysctl dev.ath.1.debug=0x20000500c > > dev.ath.1.debug: 0 -> 8589955084 > > + ifconfig wlan1 create wlandev ath1 wlanmode adhoc > > wlan1: Ethernet address: 00:80:48:4f:24:da > > + ifconfig wlan1 inet 10.0.2.1/24 channel 40 ssid ptabb bssid 05:06:ca:fe:ba:be > > ath1: ath_init: if_flags 0x8803 > > ath1: ath_stop_locked: invalid 0 if_flags 0x8803 > > ath1: ath_legacy_rxbuf_init: bus_dmamap_load_mbuf_sg failed; error 12 > > ath1: ath_legacy_startrecv: ath_rxbuf_init failed 12 > > ath1: unable to start recv logic > > + sysctl dev.ath.1.debug=0 > > dev.ath.1.debug: 8589955084 -> 0 > > + sysctl dev.ath.2.debug=0x20000500c > > dev.ath.2.debug: 0 -> 8589955084 > > + ifconfig wlan2 create wlandev ath2 wlanmode adhoc > > wlan2: Ethernet address: 00:21:a4:32:38:c2 > > + ifconfig wlan2 inet 10.0.3.1/24 channel 1 ssid ptabb bssid 05:07:ca:fe:ba:be > > ath2: ath_init: if_flags 0x8803 > > ath2: ath_stop_locked: invalid 0 if_flags 0x8803 > > ath2: ath_legacy_rxbuf_init: bus_dmamap_load_mbuf_sg failed; error 12 > > ath2: ath_legacy_startrecv: ath_rxbuf_init failed 12 > > ath2: unable to start recv logic > > + sysctl dev.ath.2.debug=0 > > dev.ath.2.debug: 8589955084 -> 0 > > :~ # netstat -m > > 182/328/510 mbufs in use (current/cache/total) > > 64/192/256/2552 mbuf clusters in use (current/cache/total/max) > > 64/189 mbuf+clusters out of packet secondary zone in use (current/cache) > > 0/0/0/1275 4k (page size) jumbo clusters in use (current/cache/total/max) > > 0/0/0/378 9k jumbo clusters in use (current/cache/total/max) > > 0/0/0/212 16k jumbo clusters in use (current/cache/total/max) > > 173K/466K/639K bytes allocated to network (current/cache/total) > > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > > 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) > > 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) > > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > > 0/3/1488 sfbufs in use (current/peak/max) > > 0 requests for sfbufs denied > > 0 requests for sfbufs delayed > > 0 requests for I/O initiated by sendfile > > ############################## > > > > CAMBRIA config file > > ############################## > > include XSCALE-ARM > > > > ident SMALL-CAMBRIA > > > > include "../xscale/ixp425/std.ixp435" > > > > hints "CAMBRIA.hints" > > > > options IXP4XX_FLASH_SIZE=0x02000000 # stock 2358 comes w/ 32M > > > > device cambria_fled # Font Panel LED on I2C bus > > device cambria_led # 8-LED latch > > > > device cambria_gpio # GPIO pins on J11 > > > > env "SMALL-AVILA.env" > > ############################## > > > > AVILA config file > > ############################## > > include XSCALE-ARM > > > > ident SMALL-AVILA > > > > include "../xscale/ixp425/std.ixp425" > > > > hints "AVILA.hints" # Default places to look for devices. > > > > device avila_led > > > > device avila_gpio # GPIO pins on J8 > > > > env "SMALL-AVILA.env" > > ############################## > > > > XSCALE-ARM config file > > ############################## > > include "../xscale/ixp425/std.avila" > > options XSCALE_CACHE_READ_WRITE_ALLOCATE > > makeoptions MODULES_OVERRIDE="" > > > > makeoptions CONF_CFLAGS=-mcpu=xscale > > options HZ=100 > > options DEVICE_POLLING > > > > options ROOTDEVNAME=\"ufs:ad0s1a\" > > > > options SCHED_4BSD # 4BSD scheduler > > options INET # Legacy InterNETworking > > options INET6 # InterNETworking > > options GEOM_PART_BSD # BSD partition scheme > > options GEOM_PART_MBR # MBR partition scheme > > options TMPFS # Efficient memory filesystem > > options FFS # Berkeley Fast Filesystem > > options SOFTUPDATES # Enable FFS soft updates support > > > > options HWPMC_HOOKS > > device hwpmc > > > > > > device pci > > device uart > > > > device ixpwdog # watchdog timer > > device cfi # flash support > > device cfid # flash disk support > > device geom_redboot # redboot fis parser > > > > device iicbus > > device iicbb > > device iic > > > > device ixpiic # I2C bus glue > > device ds1672 # DS1672 on I2C bus > > device ad7418 # AD7418 on I2C bus > > > > > > device gpio > > device gpioled > > > > device ata > > device avila_ata # Gateworks CF/IDE support > > > > device npe # Network Processing Engine > > device npe_fw > > device firmware > > device qmgr # Q Manager (required by npe) > > device mii # NB: required by npe > > device ether > > device bpf > > > > device loop > > device if_bridge > > > > device md > > device random # Entropy device > > > > device wlan # 802.11 support > > options IEEE80211_DEBUG > > options IEEE80211_SUPPORT_TDMA > > options IEEE80211_SUPPORT_MESH > > device wlan_wep # 802.11 WEP support > > device wlan_ccmp # 802.11 CCMP support > > device wlan_tkip # 802.11 TKIP support > > device wlan_xauth > > device wlan_acl > > > > device ath # Atheros NICs > > device ath_pci # Atheros pci/cardbus glue > > options ATH_DEBUG > > options ATH_DIAGAPI > > device ath_rate_sample # SampleRate tx rate control for ath > > > > options AH_DEBUG > > options AH_PRIVATE_DIAG > > device ath_ar5212 > > device ath_rf2413 > > device ath_rf2417 > > device ath_rf2425 > > device ath_rf5111 > > device ath_rf5112 > > device ath_rf5413 > > device ath_ar5416 > > options AH_SUPPORT_AR5416 > > device ath_ar9160 > > device ath_ar9280 > > > > device usb > > options USB_EHCI_BIG_ENDIAN_DESC > > device ohci > > device ehci > > device umass > > device scbus # SCSI bus (required for ATA/SCSI) > > device da # Direct Access (disks) > > device pass # Passthrough device (direct ATA/SCSI access) > > > > > > device gif > > device tun > > ############################## > > > > > > Regards > > > > John > > -- > > John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za > > _______________________________________________ > > freebsd-embedded@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-embedded > > To unsubscribe, send any mail to "freebsd-embedded-unsubscribe@freebsd.org" From owner-freebsd-embedded@FreeBSD.ORG Mon Jul 7 17:13:00 2014 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD6F87D7; Mon, 7 Jul 2014 17:13:00 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 995322B39; Mon, 7 Jul 2014 17:12:56 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1X4CTB-000Nwi-Ot; Mon, 07 Jul 2014 17:12:50 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s67HCkBT001210; Mon, 7 Jul 2014 11:12:46 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19kbGmYTrXdfK7dlbccaBrO Subject: Re: CAMBRIA and more than one atheros card From: Ian Lepore To: Adrian Chadd In-Reply-To: References: <20140707142538.GA43661@zibbi.meraka.csir.co.za> Content-Type: text/plain; charset="us-ascii" Date: Mon, 07 Jul 2014 11:12:46 -0600 Message-ID: <1404753166.65432.10.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-wireless@freebsd.org" , "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 17:13:01 -0000 On Mon, 2014-07-07 at 09:25 -0700, Adrian Chadd wrote: > hi, > > That call is returning ENOMEM. I'm not sure why. It allocated an mbuf > fine, but it couldn't allocate the DMA map. > > What's the output of "vmstat -z" ? I wonder if it's failing an allocation. > > > > -a Lack of bounce buffers is a posibility that won't show up in vmstat output. -- Ian > On 7 July 2014 07:25, John Hay wrote: > > Hi Guys, > > > > I'm further with getting my stuff working on the CAMBRIA xscale boards, > > but now see this > > > > ath1: ath_legacy_rxbuf_init: bus_dmamap_load_mbuf_sg failed; error 12 > > > > error when trying to configure a second or third atheros board. Below > > is the script run with -x with its output. The same is working fine > > on an Avila board. The Avila has 64M RAM and the CAMBRIA 128M. The > > userlevel code is the same for both and in trying to see if it is > > something missing in the kernel config, I have made a common kernel > > config file with all the common AVILA and CAMBRIA configs and then > > included that in a new AVILA and CAMBRIA config file. That gave the > > same result. The output is from a 2 week old -current/head. > > > > ############################## > > ~ # uname -a > > FreeBSD 11.0-CURRENT FreeBSD 11.0-CURRENT #5 r267954M: Fri Jun 27 14:49:04 SAST 2014 jhay@dolphin.meraka.csir.co.za:/usr/obj/arm.armeb/snaps/arm/11-tst/src/sys/SMALL-CAMBRIA arm > > ~ # /root/do-wlans > > + crflags='wlanmode adhoc' > > + dbgval=0x20000500c > > + ifconfig wlan0 create wlandev ath0 wlanmode adhoc > > wlan0: Ethernet address: 00:80:48:4f:24:ea > > + ifconfig wlan0 inet 10.0.1.1/24 channel 36 ssid ptabb bssid 05:05:ca:fe:ba:be > > + sysctl dev.ath.1.debug=0x20000500c > > dev.ath.1.debug: 0 -> 8589955084 > > + ifconfig wlan1 create wlandev ath1 wlanmode adhoc > > wlan1: Ethernet address: 00:80:48:4f:24:da > > + ifconfig wlan1 inet 10.0.2.1/24 channel 40 ssid ptabb bssid 05:06:ca:fe:ba:be > > ath1: ath_init: if_flags 0x8803 > > ath1: ath_stop_locked: invalid 0 if_flags 0x8803 > > ath1: ath_legacy_rxbuf_init: bus_dmamap_load_mbuf_sg failed; error 12 > > ath1: ath_legacy_startrecv: ath_rxbuf_init failed 12 > > ath1: unable to start recv logic > > + sysctl dev.ath.1.debug=0 > > dev.ath.1.debug: 8589955084 -> 0 > > + sysctl dev.ath.2.debug=0x20000500c > > dev.ath.2.debug: 0 -> 8589955084 > > + ifconfig wlan2 create wlandev ath2 wlanmode adhoc > > wlan2: Ethernet address: 00:21:a4:32:38:c2 > > + ifconfig wlan2 inet 10.0.3.1/24 channel 1 ssid ptabb bssid 05:07:ca:fe:ba:be > > ath2: ath_init: if_flags 0x8803 > > ath2: ath_stop_locked: invalid 0 if_flags 0x8803 > > ath2: ath_legacy_rxbuf_init: bus_dmamap_load_mbuf_sg failed; error 12 > > ath2: ath_legacy_startrecv: ath_rxbuf_init failed 12 > > ath2: unable to start recv logic > > + sysctl dev.ath.2.debug=0 > > dev.ath.2.debug: 8589955084 -> 0 > > :~ # netstat -m > > 182/328/510 mbufs in use (current/cache/total) > > 64/192/256/2552 mbuf clusters in use (current/cache/total/max) > > 64/189 mbuf+clusters out of packet secondary zone in use (current/cache) > > 0/0/0/1275 4k (page size) jumbo clusters in use (current/cache/total/max) > > 0/0/0/378 9k jumbo clusters in use (current/cache/total/max) > > 0/0/0/212 16k jumbo clusters in use (current/cache/total/max) > > 173K/466K/639K bytes allocated to network (current/cache/total) > > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > > 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) > > 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) > > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > > 0/3/1488 sfbufs in use (current/peak/max) > > 0 requests for sfbufs denied > > 0 requests for sfbufs delayed > > 0 requests for I/O initiated by sendfile > > ############################## > > > > CAMBRIA config file > > ############################## > > include XSCALE-ARM > > > > ident SMALL-CAMBRIA > > > > include "../xscale/ixp425/std.ixp435" > > > > hints "CAMBRIA.hints" > > > > options IXP4XX_FLASH_SIZE=0x02000000 # stock 2358 comes w/ 32M > > > > device cambria_fled # Font Panel LED on I2C bus > > device cambria_led # 8-LED latch > > > > device cambria_gpio # GPIO pins on J11 > > > > env "SMALL-AVILA.env" > > ############################## > > > > AVILA config file > > ############################## > > include XSCALE-ARM > > > > ident SMALL-AVILA > > > > include "../xscale/ixp425/std.ixp425" > > > > hints "AVILA.hints" # Default places to look for devices. > > > > device avila_led > > > > device avila_gpio # GPIO pins on J8 > > > > env "SMALL-AVILA.env" > > ############################## > > > > XSCALE-ARM config file > > ############################## > > include "../xscale/ixp425/std.avila" > > options XSCALE_CACHE_READ_WRITE_ALLOCATE > > makeoptions MODULES_OVERRIDE="" > > > > makeoptions CONF_CFLAGS=-mcpu=xscale > > options HZ=100 > > options DEVICE_POLLING > > > > options ROOTDEVNAME=\"ufs:ad0s1a\" > > > > options SCHED_4BSD # 4BSD scheduler > > options INET # Legacy InterNETworking > > options INET6 # InterNETworking > > options GEOM_PART_BSD # BSD partition scheme > > options GEOM_PART_MBR # MBR partition scheme > > options TMPFS # Efficient memory filesystem > > options FFS # Berkeley Fast Filesystem > > options SOFTUPDATES # Enable FFS soft updates support > > > > options HWPMC_HOOKS > > device hwpmc > > > > > > device pci > > device uart > > > > device ixpwdog # watchdog timer > > device cfi # flash support > > device cfid # flash disk support > > device geom_redboot # redboot fis parser > > > > device iicbus > > device iicbb > > device iic > > > > device ixpiic # I2C bus glue > > device ds1672 # DS1672 on I2C bus > > device ad7418 # AD7418 on I2C bus > > > > > > device gpio > > device gpioled > > > > device ata > > device avila_ata # Gateworks CF/IDE support > > > > device npe # Network Processing Engine > > device npe_fw > > device firmware > > device qmgr # Q Manager (required by npe) > > device mii # NB: required by npe > > device ether > > device bpf > > > > device loop > > device if_bridge > > > > device md > > device random # Entropy device > > > > device wlan # 802.11 support > > options IEEE80211_DEBUG > > options IEEE80211_SUPPORT_TDMA > > options IEEE80211_SUPPORT_MESH > > device wlan_wep # 802.11 WEP support > > device wlan_ccmp # 802.11 CCMP support > > device wlan_tkip # 802.11 TKIP support > > device wlan_xauth > > device wlan_acl > > > > device ath # Atheros NICs > > device ath_pci # Atheros pci/cardbus glue > > options ATH_DEBUG > > options ATH_DIAGAPI > > device ath_rate_sample # SampleRate tx rate control for ath > > > > options AH_DEBUG > > options AH_PRIVATE_DIAG > > device ath_ar5212 > > device ath_rf2413 > > device ath_rf2417 > > device ath_rf2425 > > device ath_rf5111 > > device ath_rf5112 > > device ath_rf5413 > > device ath_ar5416 > > options AH_SUPPORT_AR5416 > > device ath_ar9160 > > device ath_ar9280 > > > > device usb > > options USB_EHCI_BIG_ENDIAN_DESC > > device ohci > > device ehci > > device umass > > device scbus # SCSI bus (required for ATA/SCSI) > > device da # Direct Access (disks) > > device pass # Passthrough device (direct ATA/SCSI access) > > > > > > device gif > > device tun > > ############################## > > > > > > Regards > > > > John > > -- > > John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za > > _______________________________________________ > > freebsd-embedded@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-embedded > > To unsubscribe, send any mail to "freebsd-embedded-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-embedded@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-embedded > To unsubscribe, send any mail to "freebsd-embedded-unsubscribe@freebsd.org" From owner-freebsd-embedded@FreeBSD.ORG Mon Jul 7 18:22:56 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B5CE8DE5; Mon, 7 Jul 2014 18:22:56 +0000 (UTC) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 549642212; Mon, 7 Jul 2014 18:22:56 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id hw13so3883400qab.17 for ; Mon, 07 Jul 2014 11:22:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=VFFzDAyccKE9VmMpgijzjHE/xU8+pF6Yw36tyaLuIBM=; b=LQ9rnRQI4xF0rLvPHsW4QnG+2XIq/fF9ipaJWQfkHs8sX1OGCnIXO/pYmqGmyw0ABb FOuhbAHV4yW+279G4cq7Pf32ptD/VDodj9Bk/owds3tIzWvaSoB7Fmy/1hqZGPNqFhp+ G/z/MG6J61P2zlmN0LsxbHFc47bc7CFZA1eZ/BNX8ara9rMaKplJ468WM0r+4Np+55G9 fzxHdFybpAMQQer01yHzxHAKWasaZsC7/cN9GoVue+ySsGGqAjHkH6WHMhuJdWX1yDKd Di4wuLpbISvJNK8PmGIi1qm0Bw8XZ4uILl6KXnxDZVv45Sb6m3mq/cf+U2a2Ll/1Amih zBTw== MIME-Version: 1.0 X-Received: by 10.224.16.200 with SMTP id p8mr51770950qaa.76.1404757366305; Mon, 07 Jul 2014 11:22:46 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.202.193 with HTTP; Mon, 7 Jul 2014 11:22:46 -0700 (PDT) In-Reply-To: <1404753166.65432.10.camel@revolution.hippie.lan> References: <20140707142538.GA43661@zibbi.meraka.csir.co.za> <1404753166.65432.10.camel@revolution.hippie.lan> Date: Mon, 7 Jul 2014 11:22:46 -0700 X-Google-Sender-Auth: FRKgz7hVrOu2YAfyuJ8wcvtCLbc Message-ID: Subject: Re: CAMBRIA and more than one atheros card From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-wireless@freebsd.org" , "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 18:22:56 -0000 On 7 July 2014 10:12, Ian Lepore wrote: > On Mon, 2014-07-07 at 09:25 -0700, Adrian Chadd wrote: >> hi, >> >> That call is returning ENOMEM. I'm not sure why. It allocated an mbuf >> fine, but it couldn't allocate the DMA map. >> >> What's the output of "vmstat -z" ? I wonder if it's failing an allocation. >> >> >> >> -a > > Lack of bounce buffers is a posibility that won't show up in vmstat > output. right, but there's a bunch of already failing vmstat entries. John - there's a vmscale parameter somewhere. Hiren had to drop it down for his APs to work in 64MB of RAM. I think it's vm.kmem_size_scale . What's it say for you? -a From owner-freebsd-embedded@FreeBSD.ORG Mon Jul 7 18:28:17 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E92291C3; Mon, 7 Jul 2014 18:28:17 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.freebsd.org (Postfix) with ESMTP id 76890226E; Mon, 7 Jul 2014 18:28:17 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id CA011B843; Mon, 7 Jul 2014 20:28:14 +0200 (SAST) Date: Mon, 7 Jul 2014 20:28:14 +0200 From: John Hay To: Adrian Chadd Subject: Re: CAMBRIA and more than one atheros card Message-ID: <20140707182814.GA75629@zibbi.meraka.csir.co.za> References: <20140707142538.GA43661@zibbi.meraka.csir.co.za> <1404753166.65432.10.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-wireless@freebsd.org" , "freebsd-embedded@freebsd.org" , Ian Lepore X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 18:28:18 -0000 On Mon, Jul 07, 2014 at 11:22:46AM -0700, Adrian Chadd wrote: > On 7 July 2014 10:12, Ian Lepore wrote: > > On Mon, 2014-07-07 at 09:25 -0700, Adrian Chadd wrote: > >> hi, > >> > >> That call is returning ENOMEM. I'm not sure why. It allocated an mbuf > >> fine, but it couldn't allocate the DMA map. > >> > >> What's the output of "vmstat -z" ? I wonder if it's failing an allocation. > >> > >> > >> > >> -a > > > > Lack of bounce buffers is a posibility that won't show up in vmstat > > output. > > right, but there's a bunch of already failing vmstat entries. > > > John - there's a vmscale parameter somewhere. Hiren had to drop it > down for his APs to work in 64MB of RAM. I think it's > vm.kmem_size_scale . What's it say for you? > :~ # sysctl vm.kmem_size_scale vm.kmem_size_scale: 3 John -- John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za From owner-freebsd-embedded@FreeBSD.ORG Mon Jul 7 18:31:05 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 584EC341; Mon, 7 Jul 2014 18:31:05 +0000 (UTC) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EA2A322A8; Mon, 7 Jul 2014 18:31:04 +0000 (UTC) Received: by mail-qa0-f49.google.com with SMTP id w8so3878962qac.36 for ; Mon, 07 Jul 2014 11:31:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=a5Djti8u6LpcWgz70K8P88vmU32CS9SerJD0ELfHsbM=; b=sVyMf8aQSNwV5CW+UvWaN6z6Sbsj4H2SmoqVl2DrpMQWtgJVE7N29XS67ycriFz+na dU6oTAKSy2YGn3uw46mp/s5V71NqF3IfDm3qI/CjDpe1vIZy3op5Xzk2wC+gtTIAwzc7 WF/FlhaABdl855VkztpdSHo7Rcxnzf4pomXPiA6DxEM/TD1Z6MKtjRxekwmSDf5hCeR6 wT2pHB8OA6fAyHyibpq562ZKSzT8JwMyDwQxagKys/fU/X+3FZaPotSYhlfLUA5RkUIQ kNY6/d5FQRvTqAY8IHOlTbiuJlPfFKA08vQomUqwCt0UuyOoGtLAFqNMqRyrp+FXYhVt cxlQ== MIME-Version: 1.0 X-Received: by 10.140.80.49 with SMTP id b46mr46919556qgd.102.1404757864164; Mon, 07 Jul 2014 11:31:04 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.202.193 with HTTP; Mon, 7 Jul 2014 11:31:04 -0700 (PDT) In-Reply-To: <20140707182814.GA75629@zibbi.meraka.csir.co.za> References: <20140707142538.GA43661@zibbi.meraka.csir.co.za> <1404753166.65432.10.camel@revolution.hippie.lan> <20140707182814.GA75629@zibbi.meraka.csir.co.za> Date: Mon, 7 Jul 2014 11:31:04 -0700 X-Google-Sender-Auth: 1Rfsn0QtDVdof5grrqu6X4ssjFA Message-ID: Subject: Re: CAMBRIA and more than one atheros card From: Adrian Chadd To: John Hay Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-wireless@freebsd.org" , "freebsd-embedded@freebsd.org" , Ian Lepore X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 18:31:05 -0000 On 7 July 2014 11:28, John Hay wrote: > On Mon, Jul 07, 2014 at 11:22:46AM -0700, Adrian Chadd wrote: >> On 7 July 2014 10:12, Ian Lepore wrote: >> > On Mon, 2014-07-07 at 09:25 -0700, Adrian Chadd wrote: >> >> hi, >> >> >> >> That call is returning ENOMEM. I'm not sure why. It allocated an mbuf >> >> fine, but it couldn't allocate the DMA map. >> >> >> >> What's the output of "vmstat -z" ? I wonder if it's failing an allocation. >> >> >> >> >> >> >> >> -a >> > >> > Lack of bounce buffers is a posibility that won't show up in vmstat >> > output. >> >> right, but there's a bunch of already failing vmstat entries. >> >> >> John - there's a vmscale parameter somewhere. Hiren had to drop it >> down for his APs to work in 64MB of RAM. I think it's >> vm.kmem_size_scale . What's it say for you? >> > > :~ # sysctl vm.kmem_size_scale > vm.kmem_size_scale: 3 Ok. Search the archives for an email from Hiren titled "mbuf autotuning effect". TL;DR - set it to 1 and recompile. There's a kernel option somewhere to do exactly that. -a From owner-freebsd-embedded@FreeBSD.ORG Mon Jul 7 18:59:04 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B23A7C31; Mon, 7 Jul 2014 18:59:04 +0000 (UTC) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3E01E2556; Mon, 7 Jul 2014 18:59:04 +0000 (UTC) Received: by mail-qg0-f43.google.com with SMTP id z60so4184105qgd.30 for ; Mon, 07 Jul 2014 11:59:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kacfo9qopojflT/zL+Jj89/QFL5ZFj6JZorZFUtVm/o=; b=0vrXRZcQpxVbFqh/df1pHa2heqwnJ0eqK3bWn6YFsyEX9hXUmWaH48MvJlClXl4G/v 99Vn2BLtvGBpTeNNbiPkQZFSGGSsE1VHABTcz70EiRE2P7qrFI/wJKlTAYAXhHzNyxTD Fy4vG8ss5/+QyzX72FcWVUoP13bngPlv6KgBew4AnOYYCku94EmzdJoWLinGQFWwIXPD +xo3ZDahCfqkttdK2wSxlMeNukoW7gcCrA8jU/YKKhXJNnixOTlu6BYstG5mjhGMUG/J +Jno32AZFx9lWpdbHIvr6mzo925F5RXa4DlsjQazPdoW/39CQ6Co8Xuip4vlzo/9dyCT rGbQ== MIME-Version: 1.0 X-Received: by 10.229.252.130 with SMTP id mw2mr49590856qcb.12.1404759543392; Mon, 07 Jul 2014 11:59:03 -0700 (PDT) Received: by 10.96.73.39 with HTTP; Mon, 7 Jul 2014 11:59:03 -0700 (PDT) In-Reply-To: References: <20140707142538.GA43661@zibbi.meraka.csir.co.za> <1404753166.65432.10.camel@revolution.hippie.lan> <20140707182814.GA75629@zibbi.meraka.csir.co.za> Date: Mon, 7 Jul 2014 11:59:03 -0700 Message-ID: Subject: Re: CAMBRIA and more than one atheros card From: hiren panchasara To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-wireless@freebsd.org" , "freebsd-embedded@freebsd.org" , Ian Lepore X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 18:59:04 -0000 On Mon, Jul 7, 2014 at 11:31 AM, Adrian Chadd wrote: > On 7 July 2014 11:28, John Hay wrote: >> On Mon, Jul 07, 2014 at 11:22:46AM -0700, Adrian Chadd wrote: >>> On 7 July 2014 10:12, Ian Lepore wrote: >>> > On Mon, 2014-07-07 at 09:25 -0700, Adrian Chadd wrote: >>> >> hi, >>> >> >>> >> That call is returning ENOMEM. I'm not sure why. It allocated an mbuf >>> >> fine, but it couldn't allocate the DMA map. >>> >> >>> >> What's the output of "vmstat -z" ? I wonder if it's failing an allocation. >>> >> >>> >> >>> >> >>> >> -a >>> > >>> > Lack of bounce buffers is a posibility that won't show up in vmstat >>> > output. >>> >>> right, but there's a bunch of already failing vmstat entries. >>> >>> >>> John - there's a vmscale parameter somewhere. Hiren had to drop it >>> down for his APs to work in 64MB of RAM. I think it's >>> vm.kmem_size_scale . What's it say for you? >>> >> >> :~ # sysctl vm.kmem_size_scale >> vm.kmem_size_scale: 3 > > Ok. Search the archives for an email from Hiren titled "mbuf autotuning effect". > > TL;DR - set it to 1 and recompile. There's a kernel option somewhere > to do exactly that. Yes. http://lists.freebsd.org/pipermail/freebsd-mips/2013-September/003081.html I went through this for my tplink. John, can you show o/p of: sysctl -a | grep hw | grep mem and sysctl -a | grep maxmbuf Cheers, Hiren From owner-freebsd-embedded@FreeBSD.ORG Mon Jul 7 19:19:51 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D3C45C2; Mon, 7 Jul 2014 19:19:51 +0000 (UTC) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AEE0B2740; Mon, 7 Jul 2014 19:19:50 +0000 (UTC) Received: by mail-qg0-f44.google.com with SMTP id j107so4096422qga.17 for ; Mon, 07 Jul 2014 12:19:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bUKLuJKbZlleuyOyFBozprJVsxsfI3BA5EdOUEwRwWA=; b=bJJ3/Q0ovirU1Xhv2VZWe62/uVPnNDsYxSAQQVKWes01dU9G+1x6NvGLe6mNYvw+DX 52JJDbDsgmV16QqAsjHGMPwhXTneWHTRGkUrHP+f1veA9pvAR5zwr9z1eDxwdeHJNV9f PJlHaB4qoNPenWcBOSeBn3st5M8Zlo3t9gws1exr9xRjTkABaTtLi9jVteD3IZaKqNI8 EdCo/e4nyNzN/+xzJSigiIopjItcKn/dMP9PG6GqIcmsLwHrCzm5xsUDeX6xr/DJCDDD chVFjCy9PUJhopbDf4WWC7yHrEg2ZhhneexESC+XR+7/e9vkc+asGcUTTSbP/WNfBWkE 5I0A== MIME-Version: 1.0 X-Received: by 10.140.89.18 with SMTP id u18mr7155616qgd.87.1404760789737; Mon, 07 Jul 2014 12:19:49 -0700 (PDT) Received: by 10.96.73.39 with HTTP; Mon, 7 Jul 2014 12:19:49 -0700 (PDT) In-Reply-To: References: <9CBFAD35-D651-4E28-BEBB-DC3717F38567@bsdimp.com> <1378583762.1111.512.camel@revolution.hippie.lan> Date: Mon, 7 Jul 2014 12:19:49 -0700 Message-ID: Subject: Re: mbuf autotuning effect From: hiren panchasara To: "freebsd-mips@freebsd.org" Content-Type: text/plain; charset=UTF-8 Cc: freebsd-embedded X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 19:19:51 -0000 Trimming the cc list. On Wed, Sep 18, 2013 at 9:39 PM, hiren panchasara > > I am proposing following change for tplink TP-WN1043ND. This will get > maxmbufmem *up* from 6mb to 14mb out of total 32mb. > > Index: sys/mips/conf/TP-WN1043ND > =================================================================== > --- sys/mips/conf/TP-WN1043ND (revision 255680) > +++ sys/mips/conf/TP-WN1043ND (working copy) > @@ -15,6 +15,8 @@ > # Force the board memory - 32mb > options AR71XX_REALMEM=32*1024*1024 > > +options VM_KMEM_SIZE_SCALE=1 > + > # i2c GPIO bus > device gpioiic > device iicbb > > I do not see any other side-effects of it. Please correct me if I am wrong. I have this local modification for months now and I'd like to see what others with TP-WN1043ND think about it. cheers, Hiren From owner-freebsd-embedded@FreeBSD.ORG Mon Jul 7 19:32:55 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46294AF3; Mon, 7 Jul 2014 19:32:55 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.freebsd.org (Postfix) with ESMTP id C49AA28B0; Mon, 7 Jul 2014 19:32:54 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 52868B843; Mon, 7 Jul 2014 21:32:52 +0200 (SAST) Date: Mon, 7 Jul 2014 21:32:52 +0200 From: John Hay To: hiren panchasara Subject: Re: CAMBRIA and more than one atheros card Message-ID: <20140707193252.GA79553@zibbi.meraka.csir.co.za> References: <20140707142538.GA43661@zibbi.meraka.csir.co.za> <1404753166.65432.10.camel@revolution.hippie.lan> <20140707182814.GA75629@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-wireless@freebsd.org" , "freebsd-embedded@freebsd.org" , Ian Lepore X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 19:32:55 -0000 On Mon, Jul 07, 2014 at 11:59:03AM -0700, hiren panchasara wrote: > On Mon, Jul 7, 2014 at 11:31 AM, Adrian Chadd wrote: > > On 7 July 2014 11:28, John Hay wrote: > >> On Mon, Jul 07, 2014 at 11:22:46AM -0700, Adrian Chadd wrote: > >>> On 7 July 2014 10:12, Ian Lepore wrote: > >>> > On Mon, 2014-07-07 at 09:25 -0700, Adrian Chadd wrote: > >>> >> hi, > >>> >> > >>> >> That call is returning ENOMEM. I'm not sure why. It allocated an mbuf > >>> >> fine, but it couldn't allocate the DMA map. > >>> >> > >>> >> What's the output of "vmstat -z" ? I wonder if it's failing an allocation. > >>> >> > >>> >> > >>> >> > >>> >> -a > >>> > > >>> > Lack of bounce buffers is a posibility that won't show up in vmstat > >>> > output. > >>> > >>> right, but there's a bunch of already failing vmstat entries. > >>> > >>> > >>> John - there's a vmscale parameter somewhere. Hiren had to drop it > >>> down for his APs to work in 64MB of RAM. I think it's > >>> vm.kmem_size_scale . What's it say for you? > >>> > >> > >> :~ # sysctl vm.kmem_size_scale > >> vm.kmem_size_scale: 3 > > > > Ok. Search the archives for an email from Hiren titled "mbuf autotuning effect". > > > > TL;DR - set it to 1 and recompile. There's a kernel option somewhere > > to do exactly that. > > Yes. http://lists.freebsd.org/pipermail/freebsd-mips/2013-September/003081.html > > I went through this for my tplink. > > John, can you show o/p of: > > sysctl -a | grep hw | grep mem > and > sysctl -a | grep maxmbuf I already compiled a new kernel with "options VM_KMEM_SIZE_SCALE=1" and the problems went away. :-) On the new kernel the output is: ########################## :~ # sysctl -a | grep hw | grep mem hw.physmem: 128196608 hw.usermem: 103845888 hw.realmem: 134213632 :~ # sysctl -a | grep maxmbuf kern.ipc.maxmbufmem: 62705664 ########################## I rebooted with the old kernel and its output is: ########################## :~ # sysctl -a | grep hw | grep mem hw.physmem: 128196608 hw.usermem: 104124416 hw.realmem: 134213632 :~ # sysctl -a | grep maxmbuf kern.ipc.maxmbufmem: 20901888 ########################## So for the heck of it, I ran my script again and this time it successfully configured the 3 atheros interfaces. ? How can that be? One other thing I also do not understand. I have an Avila (with 64M RAM, half of the CAMBRIA), also with 3 atheros cards and there it always works. But if "options VM_KMEM_SIZE_SCALE=1" keeps the problem away, then I'll leave that in my kernel. :-) Thanks for everyone that helped. John -- John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za From owner-freebsd-embedded@FreeBSD.ORG Mon Jul 7 19:43:19 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0E6BCF9D; Mon, 7 Jul 2014 19:43:19 +0000 (UTC) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D58029AE; Mon, 7 Jul 2014 19:43:18 +0000 (UTC) Received: by mail-qa0-f45.google.com with SMTP id s7so11151qap.32 for ; Mon, 07 Jul 2014 12:43:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Yf4etpaldGJyOg8kaS3wjl0sFACCt3/DCs6pYZYHH0Q=; b=WZFKxU6wfqcSse0DJahb5smr6rdVdoXhgiXxeHR4hA7l4+MtjXb/ub6F3fLrOcfQC8 g8WxQdJUvqzy3+95B+aeUPHj+dNhO28GWUQf5ChSAowYze+XjVqE+CM2iqv2fO/R04Pt hhjoZ6I1EOTVyAfs/aT31DBFJFQBKeFFQeNZ/fjDbAkc+r7PupaTujC8Th+FK83cizL8 2Oh1vTWBAV7SdNd2UmgrdgUEHCg6QHGjxJFY1Ybm5n+Qh/rP5LFL3OXktPJ4ysZWIe+3 rEO7cbBItPOWffMHhQZUrKJN6zYHHUrFFu/8zQjEufx5fxHFTjqXkLXuiv2ta/+7czuq DTOw== MIME-Version: 1.0 X-Received: by 10.140.47.48 with SMTP id l45mr48216555qga.24.1404762197753; Mon, 07 Jul 2014 12:43:17 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.202.193 with HTTP; Mon, 7 Jul 2014 12:43:17 -0700 (PDT) In-Reply-To: <20140707193252.GA79553@zibbi.meraka.csir.co.za> References: <20140707142538.GA43661@zibbi.meraka.csir.co.za> <1404753166.65432.10.camel@revolution.hippie.lan> <20140707182814.GA75629@zibbi.meraka.csir.co.za> <20140707193252.GA79553@zibbi.meraka.csir.co.za> Date: Mon, 7 Jul 2014 12:43:17 -0700 X-Google-Sender-Auth: DIMKQaCgAkMLktJoTFB5qjIMUwo Message-ID: Subject: Re: CAMBRIA and more than one atheros card From: Adrian Chadd To: John Hay Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-wireless@freebsd.org" , Ian Lepore , "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 19:43:19 -0000 Sweet! Can you run the same commands above on the Avila board? Would you mind filing a PR to ensure we get that option into the relevant kernel(s) ? (I'm kinda tempted to suggest we auto-select the scaling factor at startup depending upon physical RAM .. ) -a On 7 July 2014 12:32, John Hay wrote: > On Mon, Jul 07, 2014 at 11:59:03AM -0700, hiren panchasara wrote: >> On Mon, Jul 7, 2014 at 11:31 AM, Adrian Chadd wrote: >> > On 7 July 2014 11:28, John Hay wrote: >> >> On Mon, Jul 07, 2014 at 11:22:46AM -0700, Adrian Chadd wrote: >> >>> On 7 July 2014 10:12, Ian Lepore wrote: >> >>> > On Mon, 2014-07-07 at 09:25 -0700, Adrian Chadd wrote: >> >>> >> hi, >> >>> >> >> >>> >> That call is returning ENOMEM. I'm not sure why. It allocated an mbuf >> >>> >> fine, but it couldn't allocate the DMA map. >> >>> >> >> >>> >> What's the output of "vmstat -z" ? I wonder if it's failing an allocation. >> >>> >> >> >>> >> >> >>> >> >> >>> >> -a >> >>> > >> >>> > Lack of bounce buffers is a posibility that won't show up in vmstat >> >>> > output. >> >>> >> >>> right, but there's a bunch of already failing vmstat entries. >> >>> >> >>> >> >>> John - there's a vmscale parameter somewhere. Hiren had to drop it >> >>> down for his APs to work in 64MB of RAM. I think it's >> >>> vm.kmem_size_scale . What's it say for you? >> >>> >> >> >> >> :~ # sysctl vm.kmem_size_scale >> >> vm.kmem_size_scale: 3 >> > >> > Ok. Search the archives for an email from Hiren titled "mbuf autotuning effect". >> > >> > TL;DR - set it to 1 and recompile. There's a kernel option somewhere >> > to do exactly that. >> >> Yes. http://lists.freebsd.org/pipermail/freebsd-mips/2013-September/003081.html >> >> I went through this for my tplink. >> >> John, can you show o/p of: >> >> sysctl -a | grep hw | grep mem >> and >> sysctl -a | grep maxmbuf > > I already compiled a new kernel with "options VM_KMEM_SIZE_SCALE=1" and > the problems went away. :-) On the new kernel the output is: > > ########################## > :~ # sysctl -a | grep hw | grep mem > hw.physmem: 128196608 > hw.usermem: 103845888 > hw.realmem: 134213632 > :~ # sysctl -a | grep maxmbuf > kern.ipc.maxmbufmem: 62705664 > ########################## > > I rebooted with the old kernel and its output is: > > ########################## > :~ # sysctl -a | grep hw | grep mem > hw.physmem: 128196608 > hw.usermem: 104124416 > hw.realmem: 134213632 > :~ # sysctl -a | grep maxmbuf > kern.ipc.maxmbufmem: 20901888 > ########################## > > So for the heck of it, I ran my script again and this time it successfully > configured the 3 atheros interfaces. ? How can that be? One other thing I > also do not understand. I have an Avila (with 64M RAM, half of the CAMBRIA), > also with 3 atheros cards and there it always works. > > But if "options VM_KMEM_SIZE_SCALE=1" keeps the problem away, then I'll > leave that in my kernel. :-) > > Thanks for everyone that helped. > > John > -- > John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za From owner-freebsd-embedded@FreeBSD.ORG Mon Jul 7 19:44:28 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4C3DCFF6 for ; Mon, 7 Jul 2014 19:44:28 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id E66AF29BA for ; Mon, 7 Jul 2014 19:44:27 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 99EC3B84A; Mon, 7 Jul 2014 21:44:25 +0200 (SAST) Date: Mon, 7 Jul 2014 21:44:25 +0200 From: John Hay To: freebsd-embedded@freebsd.org Subject: vmstat -i and systat -vm interrupt reporting on CAMBRIA and AVILA Message-ID: <20140707194425.GB79553@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 19:44:28 -0000 Hi Guys, While looking for my atheros problems, I noticed that there seems to be some reporting problem with interrupts on CAMBRIA and AVILA or maybe my expectations are wrong. I see: :~ # vmstat -i interrupt total rate Total 67723 130 :~ # And for systat -vm on the righthand side I see: Interrupts 126 total 100 6 20 For vmstat -i I would have expected a breakdown of the interrupts with their names, totoal and rate. Not just a Total. Systat seems to find a little more with the 3 numbers, but also cannot find the names? Regards John -- John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za From owner-freebsd-embedded@FreeBSD.ORG Mon Jul 7 20:04:40 2014 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 19837A80 for ; Mon, 7 Jul 2014 20:04:40 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E2F5D2B86 for ; Mon, 7 Jul 2014 20:04:39 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1X4F9R-000EPc-Uh; Mon, 07 Jul 2014 20:04:38 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s67K4Y3F001399; Mon, 7 Jul 2014 14:04:34 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/KARRUOcF1aGyrPo5HpkHe Subject: Re: vmstat -i and systat -vm interrupt reporting on CAMBRIA and AVILA From: Ian Lepore To: John Hay In-Reply-To: <20140707194425.GB79553@zibbi.meraka.csir.co.za> References: <20140707194425.GB79553@zibbi.meraka.csir.co.za> Content-Type: text/plain; charset="us-ascii" Date: Mon, 07 Jul 2014 14:04:34 -0600 Message-ID: <1404763474.65432.39.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 20:04:40 -0000 On Mon, 2014-07-07 at 21:44 +0200, John Hay wrote: > Hi Guys, > > While looking for my atheros problems, I noticed that there seems to > be some reporting problem with interrupts on CAMBRIA and AVILA or > maybe my expectations are wrong. I see: > > :~ # vmstat -i > interrupt total rate > Total 67723 130 > :~ # > > And for systat -vm on the righthand side I see: > > Interrupts > 126 total > 100 > 6 > 20 > > For vmstat -i I would have expected a breakdown of the interrupts with > their names, totoal and rate. Not just a Total. Systat seems to find > a little more with the 3 numbers, but also cannot find the names? > > Regards > > John I wonder if this could be related to the changes HPS made recently to sysctl? vmstat -i gets its info through sysctl, and it's a particularly perverse conspiracy of agreement between kernel and userland on how to interpret a binary blob of sysctl data that contains a variable length table of variable length strings, as I vaguely recall it. -- Ian From owner-freebsd-embedded@FreeBSD.ORG Tue Jul 8 16:54:42 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C7A931E; Tue, 8 Jul 2014 16:54:42 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id C9CC128AA; Tue, 8 Jul 2014 16:54:41 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id B3790B84A; Tue, 8 Jul 2014 18:54:38 +0200 (SAST) Date: Tue, 8 Jul 2014 18:54:38 +0200 From: John Hay To: Adrian Chadd Subject: Re: CAMBRIA and more than one atheros card Message-ID: <20140708165438.GA83704@zibbi.meraka.csir.co.za> References: <20140707142538.GA43661@zibbi.meraka.csir.co.za> <1404753166.65432.10.camel@revolution.hippie.lan> <20140707182814.GA75629@zibbi.meraka.csir.co.za> <20140707193252.GA79553@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-wireless@freebsd.org" , Ian Lepore , "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 16:54:42 -0000 On Mon, Jul 07, 2014 at 12:43:17PM -0700, Adrian Chadd wrote: > Sweet! > > Can you run the same commands above on the Avila board? :~ # uname -a FreeBSD broken-2 11.0-CURRENT FreeBSD 11.0-CURRENT #74 r267954M: Fri Jun 27 14:40:34 SAST 2014 jhay@dolphin.meraka.csir.co.za:/usr/obj/arm.armeb/snaps/arm/11-tst/src/sys/SMALL-AVILA arm :~ # sysctl -a | grep hw | grep mem hw.physmem: 61087744 hw.usermem: 41558016 hw.realmem: 67104768 :~ # sysctl -a | grep maxmbuf kern.ipc.maxmbufmem: 9934848 I'm still confused that the Avila with half the RAM does not exhibit the same problem. > > Would you mind filing a PR to ensure we get that option into the > relevant kernel(s) ? Sure, give me a day or two. John > > (I'm kinda tempted to suggest we auto-select the scaling factor at > startup depending upon physical RAM .. ) > > > -a > > > On 7 July 2014 12:32, John Hay wrote: > > On Mon, Jul 07, 2014 at 11:59:03AM -0700, hiren panchasara wrote: > >> On Mon, Jul 7, 2014 at 11:31 AM, Adrian Chadd wrote: > >> > On 7 July 2014 11:28, John Hay wrote: > >> >> On Mon, Jul 07, 2014 at 11:22:46AM -0700, Adrian Chadd wrote: > >> >>> On 7 July 2014 10:12, Ian Lepore wrote: > >> >>> > On Mon, 2014-07-07 at 09:25 -0700, Adrian Chadd wrote: > >> >>> >> hi, > >> >>> >> > >> >>> >> That call is returning ENOMEM. I'm not sure why. It allocated an mbuf > >> >>> >> fine, but it couldn't allocate the DMA map. > >> >>> >> > >> >>> >> What's the output of "vmstat -z" ? I wonder if it's failing an allocation. > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> -a > >> >>> > > >> >>> > Lack of bounce buffers is a posibility that won't show up in vmstat > >> >>> > output. > >> >>> > >> >>> right, but there's a bunch of already failing vmstat entries. > >> >>> > >> >>> > >> >>> John - there's a vmscale parameter somewhere. Hiren had to drop it > >> >>> down for his APs to work in 64MB of RAM. I think it's > >> >>> vm.kmem_size_scale . What's it say for you? > >> >>> > >> >> > >> >> :~ # sysctl vm.kmem_size_scale > >> >> vm.kmem_size_scale: 3 > >> > > >> > Ok. Search the archives for an email from Hiren titled "mbuf autotuning effect". > >> > > >> > TL;DR - set it to 1 and recompile. There's a kernel option somewhere > >> > to do exactly that. > >> > >> Yes. http://lists.freebsd.org/pipermail/freebsd-mips/2013-September/003081.html > >> > >> I went through this for my tplink. > >> > >> John, can you show o/p of: > >> > >> sysctl -a | grep hw | grep mem > >> and > >> sysctl -a | grep maxmbuf > > > > I already compiled a new kernel with "options VM_KMEM_SIZE_SCALE=1" and > > the problems went away. :-) On the new kernel the output is: > > > > ########################## > > :~ # sysctl -a | grep hw | grep mem > > hw.physmem: 128196608 > > hw.usermem: 103845888 > > hw.realmem: 134213632 > > :~ # sysctl -a | grep maxmbuf > > kern.ipc.maxmbufmem: 62705664 > > ########################## > > > > I rebooted with the old kernel and its output is: > > > > ########################## > > :~ # sysctl -a | grep hw | grep mem > > hw.physmem: 128196608 > > hw.usermem: 104124416 > > hw.realmem: 134213632 > > :~ # sysctl -a | grep maxmbuf > > kern.ipc.maxmbufmem: 20901888 > > ########################## > > > > So for the heck of it, I ran my script again and this time it successfully > > configured the 3 atheros interfaces. ? How can that be? One other thing I > > also do not understand. I have an Avila (with 64M RAM, half of the CAMBRIA), > > also with 3 atheros cards and there it always works. > > > > But if "options VM_KMEM_SIZE_SCALE=1" keeps the problem away, then I'll > > leave that in my kernel. :-) > > > > Thanks for everyone that helped. > > > > John > > -- > > John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za From owner-freebsd-embedded@FreeBSD.ORG Tue Jul 8 17:06:55 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E84B748; Tue, 8 Jul 2014 17:06:55 +0000 (UTC) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BC8A829BA; Tue, 8 Jul 2014 17:06:54 +0000 (UTC) Received: by mail-qg0-f50.google.com with SMTP id j5so5223882qga.37 for ; Tue, 08 Jul 2014 10:06:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mWJ3cQ+VW5dE/0zm2GWbmaJK4Ol7uAY+0BjkBqDhbSA=; b=uz7mdUK/JXPz5L5UNOJlI0zm3nJ34qgpoyl03WYZG/ULdZjpNEIkTJMjVLCjHn5Usn xIHxaavv2omXNtuGgW1NX4dgNR3PjE5Wsw9iqzNVrf1yqz2pJEmYG7HpC0ecfoGBHS4F AMdiTqlldIfyOWy0RjII3PyOOUsWaQO2NEUAFEJq45ZCUKMbBekuyQpt6mE0cz2esZav zSvFTPxIvyyH8sDz/mzJVLQtN6w9JC9RI7A58kvYkZBUHyMduicZ7HSlhortB4CTcpA0 f1qzAep8YGihLs4xAF5LFt2j6lNtFbGeGC0LfdJTZNONe+O7p0drJ9kb0cd1QqpXelHf geqA== MIME-Version: 1.0 X-Received: by 10.140.19.109 with SMTP id 100mr59080926qgg.80.1404839213829; Tue, 08 Jul 2014 10:06:53 -0700 (PDT) Received: by 10.96.73.39 with HTTP; Tue, 8 Jul 2014 10:06:53 -0700 (PDT) In-Reply-To: <20140708165438.GA83704@zibbi.meraka.csir.co.za> References: <20140707142538.GA43661@zibbi.meraka.csir.co.za> <1404753166.65432.10.camel@revolution.hippie.lan> <20140707182814.GA75629@zibbi.meraka.csir.co.za> <20140707193252.GA79553@zibbi.meraka.csir.co.za> <20140708165438.GA83704@zibbi.meraka.csir.co.za> Date: Tue, 8 Jul 2014 10:06:53 -0700 Message-ID: Subject: Re: CAMBRIA and more than one atheros card From: hiren panchasara To: John Hay Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-wireless@freebsd.org" , "freebsd-embedded@freebsd.org" , Ian Lepore X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 17:06:55 -0000 On Tue, Jul 8, 2014 at 9:54 AM, John Hay wrote: > On Mon, Jul 07, 2014 at 12:43:17PM -0700, Adrian Chadd wrote: >> Sweet! >> >> Can you run the same commands above on the Avila board? > > :~ # uname -a > FreeBSD broken-2 11.0-CURRENT FreeBSD 11.0-CURRENT #74 r267954M: Fri Jun 27 14:40:34 SAST 2014 jhay@dolphin.meraka.csir.co.za:/usr/obj/arm.armeb/snaps/arm/11-tst/src/sys/SMALL-AVILA arm > :~ # sysctl -a | grep hw | grep mem > hw.physmem: 61087744 > hw.usermem: 41558016 > hw.realmem: 67104768 > :~ # sysctl -a | grep maxmbuf > kern.ipc.maxmbufmem: 9934848 > > I'm still confused that the Avila with half the RAM does not exhibit the > same problem. Try to compare both KERNCONFs to see if you've anything special for Avila. (I assume that you are doing same things with both boards wrt your experimentation.) cheers, Hiren > >> >> Would you mind filing a PR to ensure we get that option into the >> relevant kernel(s) ? > > Sure, give me a day or two. > > John > From owner-freebsd-embedded@FreeBSD.ORG Wed Jul 9 04:46:17 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E37160D; Wed, 9 Jul 2014 04:46:17 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id CF88B2EAF; Wed, 9 Jul 2014 04:46:16 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 71B86B84A; Wed, 9 Jul 2014 06:46:12 +0200 (SAST) Date: Wed, 9 Jul 2014 06:46:12 +0200 From: John Hay To: Adrian Chadd Subject: Re: CAMBRIA and more than one atheros card Message-ID: <20140709044612.GA51378@zibbi.meraka.csir.co.za> References: <20140707142538.GA43661@zibbi.meraka.csir.co.za> <1404753166.65432.10.camel@revolution.hippie.lan> <20140707182814.GA75629@zibbi.meraka.csir.co.za> <20140707193252.GA79553@zibbi.meraka.csir.co.za> <20140708165438.GA83704@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140708165438.GA83704@zibbi.meraka.csir.co.za> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-wireless@freebsd.org" , "freebsd-embedded@freebsd.org" , Ian Lepore X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 04:46:17 -0000 Hi Guys, The problem is back / still there. I initially saw the problem during boot, with the interface configs in rc.conf, but because it is so mixed with the rest, I took it out and put it in the script, then after multi-user boot was finished, I did a login and ran the script, with the output I showed in the initial post. So I put the interface configs back into rc.conf and I'm seeing the same problem, here is a cut during boot: ############### Starting file system checks: /dev/ad0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s1a: clean, 93385 free (33 frags, 11669 blocks, 0.0% fragmentation) Mounting local file systems:. Writing entropy file:. Setting hostname: tst-cambria-11. wlan0: Ethernet address: 00:21:a4:35:70:42 wlan1: Ethernet address: 00:21:a4:35:6c:96 ath1: unable to start recv logic wlan2: Ethernet address: 00:21:a4:32:38:c2 ath2: unable to start recv logic ############### Looking at the vmstat -z output the 256 Bucket fail is much higher than if I let it boot to multiuser and then configured the interfaces. It was in the 6000, while now it is much higher: Without wlan configs in rc.conf, but configured afterwards: 16 Bucket: 64, 0, 15, 300, 3139, 16, 0 256 Bucket: 1024, 0, 31, 1, 592,6062, 0 vmem btag: 28, 0, 4496, 256, 4496, 32, 0 With wlan configs in rc.conf: 16 Bucket: 64, 0, 16, 299, 8611, 16, 0 256 Bucket: 1024, 0, 26, 6, 773,16928, 0 vmem btag: 28, 0, 4405, 59, 4405, 30, 0 Both of them boot from a ro compact-flash with md /etc and /var, but they are small 4.3M and 2.1M. I have hacked in the use of tmpfs, but that did not make a difference. So where do I look from here? Regards John -- John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za / jhay@FreeBSD.org From owner-freebsd-embedded@FreeBSD.ORG Wed Jul 9 11:31:38 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB9B9F3B for ; Wed, 9 Jul 2014 11:31:38 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 8E6332106 for ; Wed, 9 Jul 2014 11:31:38 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:8cc3:e5a9:fcf2:1e1c]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id BCD764AC0F for ; Wed, 9 Jul 2014 15:31:37 +0400 (MSK) Date: Wed, 9 Jul 2014 15:31:30 +0400 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <1762259217.20140709153130@serebryakov.spb.ru> To: freebsd-embedded@freebsd.org Subject: Any chances to have FreeBSD on TP-Link TL-MR3420 v2 (white one)? In-Reply-To: <1457767975.20140709141043@serebryakov.spb.ru> References: <1457767975.20140709141043@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 11:31:38 -0000 Hello, Freebsd-embedded. You wrote 9 =D0=B8=D1=8E=D0=BB=D1=8F 2014 =D0=B3., 14:10:43: $subj? Or is it too small for FreeBSD AP + DHCPD + 3G Modem driver? Native firmware works not so well :( --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-embedded@FreeBSD.ORG Wed Jul 9 12:05:42 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 86B12D74; Wed, 9 Jul 2014 12:05:42 +0000 (UTC) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 274E524CC; Wed, 9 Jul 2014 12:05:42 +0000 (UTC) Received: by mail-qa0-f45.google.com with SMTP id s7so1968652qap.32 for ; Wed, 09 Jul 2014 05:05:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=uMO/0Hb7j0gfb0Sd1IOg6gMtkQC5BH8rqjW5zhxVYxQ=; b=09Sx8RjDdPO8K7tQmEyguEax/vGVdZj3WBxms5k3qr1lUXdkfsEAGK616iRV4c+KVU Sa173g27w/mTjDJEwVS6IhSIVDWV934StN2EOahVmoErvdyACbG/eNoQ1oshsHsu1XJP IdJ0uIZppFgpah5PG9We0E6n5f3+npFM5pLp7jdAz9bl4+/rX9u4gzqA7Ls4/W/MHdkI Iz+Q1yCc+iMNVVwspwoGVDuhiQ6zE6RHMjhpLFIGVaI9O8jEVpTMHYgBggGbbpHtmJv0 ImSdUoTZjlwuBiodZcQic3/re0QwxS8f/rVfOQwMZtwYPIdMAnKWr32x1rvrgJ1Gz7dL 4Y3g== X-Received: by 10.140.36.149 with SMTP id p21mr65326710qgp.54.1404907541209; Wed, 09 Jul 2014 05:05:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.31.68 with HTTP; Wed, 9 Jul 2014 05:05:01 -0700 (PDT) In-Reply-To: <1762259217.20140709153130@serebryakov.spb.ru> References: <1457767975.20140709141043@serebryakov.spb.ru> <1762259217.20140709153130@serebryakov.spb.ru> From: Irfan Zia Date: Wed, 9 Jul 2014 17:05:01 +0500 Message-ID: Subject: Re: Any chances to have FreeBSD on TP-Link TL-MR3420 v2 (white one)? To: Lev Serebryakov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-embedded@freebsd.org, freebsd-mips@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 12:05:42 -0000 hi Lev, from various past messages on freebsd-mips I believe that FreeBSD on MR3420 is supported. Not sure about v2 though. I've copied the list here= . thanks! -Irfan On Wed, Jul 9, 2014 at 4:31 PM, Lev Serebryakov wrote: > Hello, Freebsd-embedded. > You wrote 9 =D0=B8=D1=8E=D0=BB=D1=8F 2014 =D0=B3., 14:10:43: > > $subj? Or is it too small for FreeBSD AP + DHCPD + 3G Modem driver? > Native firmware works not so well :( > > -- > // Black Lion AKA Lev Serebryakov > > _______________________________________________ > freebsd-embedded@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-embedded > To unsubscribe, send any mail to "freebsd-embedded-unsubscribe@freebsd.or= g > " From owner-freebsd-embedded@FreeBSD.ORG Wed Jul 9 16:04:49 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D97611BE; Wed, 9 Jul 2014 16:04:49 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 985892DDE; Wed, 9 Jul 2014 16:04:49 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:8cc3:e5a9:fcf2:1e1c]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 3330F4AC0F; Wed, 9 Jul 2014 20:04:41 +0400 (MSK) Date: Wed, 9 Jul 2014 20:04:33 +0400 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1415010372.20140709200433@serebryakov.spb.ru> To: Sean Bruno Subject: Re: Any chances to have FreeBSD on TP-Link TL-MR3420 v2 (white one)? In-Reply-To: <1404920385.7725.2.camel@bruno> References: <1457767975.20140709141043@serebryakov.spb.ru> <1404920385.7725.2.camel@bruno> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 16:04:49 -0000 Hello, Sean. You wrote 9 =D0=B8=D1=8E=D0=BB=D1=8F 2014 =D0=B3., 19:39:45: >> $subj? Or is it too small for FreeBSD AP + DHCPD + 3G Modem driver? >> Native firmware works not so well :( SB> Looking at what wikidevi says, there's a good chance that you can get it SB> working. SB> https://wikidevi.com/wiki/TP-LINK_TL-MR3420_v2 SB> Its atheros mips, AR9341 which means it can likely be made to boot. SB> The 4M of flash however is super small, I haven't been able to squash a SB> kernel/ramdisk to that size. (worked on the mr3020 a bit, and had to SB> resort to a 4G usb disk for root). USB disk for root looks Ok, I need it only as 3G <-> WiFi gateway, so USB is not used anyway. With "native" firmware (the latest one) wifi is very unstable, it looks like "working" (clients are associated, but after 3-5 minutes no traffic pass till new disconnect/connect cycle). P.S. I've changed mailing list to embedded, as wireless was my mistake, actually. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-embedded@FreeBSD.ORG Wed Jul 9 16:11:52 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A9CB455; Wed, 9 Jul 2014 16:11:52 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 092C92EA4; Wed, 9 Jul 2014 16:11:51 +0000 (UTC) Received: from [192.168.200.204] (c-50-131-5-126.hsd1.ca.comcast.net [50.131.5.126]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 3BF6E193DD9; Wed, 9 Jul 2014 16:11:50 +0000 (UTC) Subject: Re: Any chances to have FreeBSD on TP-Link TL-MR3420 v2 (white one)? From: Sean Bruno Reply-To: sbruno@freebsd.org To: lev@FreeBSD.org In-Reply-To: <1415010372.20140709200433@serebryakov.spb.ru> References: <1457767975.20140709141043@serebryakov.spb.ru> <1404920385.7725.2.camel@bruno> <1415010372.20140709200433@serebryakov.spb.ru> Content-Type: text/plain; charset="koi8-r" Date: Wed, 09 Jul 2014 09:11:48 -0700 Message-ID: <1404922308.7725.6.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: freebsd-embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 16:11:52 -0000 On Wed, 2014-07-09 at 20:04 +0400, Lev Serebryakov wrote: > Hello, Sean. > You wrote 9 ÉÀÌÑ 2014 Ç., 19:39:45: > > >> $subj? Or is it too small for FreeBSD AP + DHCPD + 3G Modem driver? > >> Native firmware works not so well :( > > SB> Looking at what wikidevi says, there's a good chance that you can get it > SB> working. > > SB> https://wikidevi.com/wiki/TP-LINK_TL-MR3420_v2 > > SB> Its atheros mips, AR9341 which means it can likely be made to boot. > > SB> The 4M of flash however is super small, I haven't been able to squash a > SB> kernel/ramdisk to that size. (worked on the mr3020 a bit, and had to > SB> resort to a 4G usb disk for root). > USB disk for root looks Ok, I need it only as 3G <-> WiFi gateway, so USB > is not used anyway. > With "native" firmware (the latest one) wifi is very unstable, it looks > like "working" (clients are associated, but after 3-5 minutes no traffic > pass till new disconnect/connect cycle). > > > P.S. I've changed mailing list to embedded, as wireless was my mistake, > actually. > If you can, try getting it to netboot using the wifi build scripts and whatnot. Its a bit of work, but rewarding. https://github.com/freebsd/freebsd-wifi-build I had to bootstrap mine with a serial console and whatnot. http://wiki.openwrt.org/toh/tp-link/tl-mr3020 Then I was able to build images and netboot with these configs. http://people.freebsd.org/~sbruno/TP-MR3020 http://people.freebsd.org/~sbruno/TP-MR3020.hints So, you'll want to mess around and try a different type. sean From owner-freebsd-embedded@FreeBSD.ORG Wed Jul 9 18:10:27 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD412B35; Wed, 9 Jul 2014 18:10:27 +0000 (UTC) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8E89D296E; Wed, 9 Jul 2014 18:10:27 +0000 (UTC) Received: by mail-qa0-f53.google.com with SMTP id v10so1049993qac.40 for ; Wed, 09 Jul 2014 11:10:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e1jaBZ2qJkWSXKjol458TeyoWNKATQsovjsDFx20VHk=; b=Ki+8gKdEASzgUR8NWNmcqy5gVZd5J5n30VjWBczc94C9bD7hS0WeHsCx0xIDB7ouv+ pgLrcQq01PD56UzsAmg93D2XNBApEpbqc4bEHEe6bL++Uk1rV8aBdKJw/5HEx6CcZ8Ua D4b8leAhBIxrVPTHjYECXC1VAdo395eU7qUcJ/cXd7iuOVrvrlRBBKKDlLDJ09NaI8H5 kVbxChUY2erIalyegPJLXIK6vzpZEbdNXkVzR6t8KkTHnQx+tYDpZ0r49dL4PmhFgc/E yfB4gP6Oikhvlordl/oBaVEEq3Ig18XgSHpbCqYCrRM1NUaCj8gJUCXg9l7R82Bj4CFo pGAQ== MIME-Version: 1.0 X-Received: by 10.140.106.73 with SMTP id d67mr69121177qgf.103.1404929426738; Wed, 09 Jul 2014 11:10:26 -0700 (PDT) Received: by 10.96.73.39 with HTTP; Wed, 9 Jul 2014 11:10:26 -0700 (PDT) In-Reply-To: <201407091757.s69HvHsv044282@pdx.rh.CN85.ChatUSA.com> References: <201407091757.s69HvHsv044282@pdx.rh.CN85.ChatUSA.com> Date: Wed, 9 Jul 2014 11:10:26 -0700 Message-ID: Subject: Re: mbuf autotuning effect From: hiren panchasara To: "Rodney W. Grimes" Content-Type: text/plain; charset=UTF-8 Cc: freebsd-embedded , "freebsd-mips@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 18:10:27 -0000 On Wed, Jul 9, 2014 at 10:57 AM, Rodney W. Grimes wrote: > Actually didnt VM_KMEM_SIZE_SCALE default value get changed to 1 in the x86/amd64 > kernel tree some time in 8.x's life time? Yes, Just for amd64: % grep -r SCALE */include/vmparam.h | grep define amd64/include/vmparam.h:#define VM_KMEM_SIZE_SCALE (1) arm/include/vmparam.h:#define VM_KMEM_SIZE_SCALE (3) i386/include/vmparam.h:#define VM_KMEM_SIZE_SCALE (3) ia64/include/vmparam.h:#define VM_KMEM_SIZE_SCALE (4) mips/include/vmparam.h:#define VM_KMEM_SIZE_SCALE (3) powerpc/include/vmparam.h:#define VM_KMEM_SIZE_SCALE (3) sparc64/include/vmparam.h:#define VM_KMEM_SIZE_SCALE (tsb_kernel_ldd_phys == 0 ? 3 : 2) cheers, Hiren From owner-freebsd-embedded@FreeBSD.ORG Thu Jul 10 02:22:16 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 73E6EF29; Thu, 10 Jul 2014 02:22:16 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2C4F92410; Thu, 10 Jul 2014 02:22:15 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s6A2M92F020015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jul 2014 19:22:09 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s6A2M6X6020014; Wed, 9 Jul 2014 19:22:06 -0700 (PDT) (envelope-from jmg) Date: Wed, 9 Jul 2014 19:22:06 -0700 From: John-Mark Gurney To: Ian Lepore Subject: Re: vmstat -i and systat -vm interrupt reporting on CAMBRIA and AVILA Message-ID: <20140710022206.GR45513@funkthat.com> Mail-Followup-To: Ian Lepore , John Hay , freebsd-embedded@freebsd.org References: <20140707194425.GB79553@zibbi.meraka.csir.co.za> <1404763474.65432.39.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1404763474.65432.39.camel@revolution.hippie.lan> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 09 Jul 2014 19:22:09 -0700 (PDT) Cc: freebsd-embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 02:22:16 -0000 Ian Lepore wrote this message on Mon, Jul 07, 2014 at 14:04 -0600: > On Mon, 2014-07-07 at 21:44 +0200, John Hay wrote: > > Hi Guys, > > > > While looking for my atheros problems, I noticed that there seems to > > be some reporting problem with interrupts on CAMBRIA and AVILA or > > maybe my expectations are wrong. I see: > > > > :~ # vmstat -i > > interrupt total rate > > Total 67723 130 > > :~ # > > > > And for systat -vm on the righthand side I see: > > > > Interrupts > > 126 total > > 100 > > 6 > > 20 > > > > For vmstat -i I would have expected a breakdown of the interrupts with > > their names, totoal and rate. Not just a Total. Systat seems to find > > a little more with the 3 numbers, but also cannot find the names? > > > > Regards > > > > John > > I wonder if this could be related to the changes HPS made recently to > sysctl? vmstat -i gets its info through sysctl, and it's a particularly > perverse conspiracy of agreement between kernel and userland on how to > interpret a binary blob of sysctl data that contains a variable length > table of variable length strings, as I vaguely recall it. I'm pretty sure this isn't because of HPS's changes.. I have a kernel running from Jun 18th that shows similar behavior: # vmstat -i interrupt total rate Total 150211606 105 # uname -a FreeBSD avila.funkthat.com 11.0-CURRENT FreeBSD 11.0-CURRENT #28 r267333:267349M: Wed Jun 18 16:49:41 PDT 2014 jmg@carbon.funkthat.com:/usr/obj/arm.armeb/usr/src.avila/sys/AVILA arm systat -vm: Interrupts 103 total 3 100 I'll try to take a look at it, but it'll be a bit before I can really dig in as I'm still traveling.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-embedded@FreeBSD.ORG Thu Jul 10 04:02:36 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C2991DB3; Thu, 10 Jul 2014 04:02:36 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.freebsd.org (Postfix) with ESMTP id ED4C32C50; Thu, 10 Jul 2014 04:02:35 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 8E9E6B842; Thu, 10 Jul 2014 06:02:27 +0200 (SAST) Date: Thu, 10 Jul 2014 06:02:27 +0200 From: John Hay To: Adrian Chadd Subject: Re: CAMBRIA and more than one atheros card Message-ID: <20140710040227.GA73872@zibbi.meraka.csir.co.za> References: <1404753166.65432.10.camel@revolution.hippie.lan> <20140707182814.GA75629@zibbi.meraka.csir.co.za> <20140707193252.GA79553@zibbi.meraka.csir.co.za> <20140708165438.GA83704@zibbi.meraka.csir.co.za> <20140709044612.GA51378@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140709044612.GA51378@zibbi.meraka.csir.co.za> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-wireless@freebsd.org" , "freebsd-embedded@freebsd.org" , Ian Lepore X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 04:02:37 -0000 On Wed, Jul 09, 2014 at 06:46:12AM +0200, John Hay wrote: > Hi Guys, > > The problem is back / still there. I initially saw the problem during > boot, with the interface configs in rc.conf, but because it is so > mixed with the rest, I took it out and put it in the script, then > after multi-user boot was finished, I did a login and ran the script, > with the output I showed in the initial post. > > So I put the interface configs back into rc.conf and I'm seeing the > same problem, here is a cut during boot: > > ############### > Starting file system checks: > /dev/ad0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/ad0s1a: clean, 93385 free (33 frags, 11669 blocks, 0.0% fragmentation) > Mounting local file systems:. > Writing entropy file:. > Setting hostname: tst-cambria-11. > wlan0: Ethernet address: 00:21:a4:35:70:42 > wlan1: Ethernet address: 00:21:a4:35:6c:96 > ath1: unable to start recv logic > wlan2: Ethernet address: 00:21:a4:32:38:c2 > ath2: unable to start recv logic > ############### > > Looking at the vmstat -z output the 256 Bucket fail is much higher than > if I let it boot to multiuser and then configured the interfaces. It > was in the 6000, while now it is much higher: > > Without wlan configs in rc.conf, but configured afterwards: > 16 Bucket: 64, 0, 15, 300, 3139, 16, 0 > 256 Bucket: 1024, 0, 31, 1, 592,6062, 0 > vmem btag: 28, 0, 4496, 256, 4496, 32, 0 > > With wlan configs in rc.conf: > 16 Bucket: 64, 0, 16, 299, 8611, 16, 0 > 256 Bucket: 1024, 0, 26, 6, 773,16928, 0 > vmem btag: 28, 0, 4405, 59, 4405, 30, 0 > > Both of them boot from a ro compact-flash with md /etc and /var, but > they are small 4.3M and 2.1M. I have hacked in the use of tmpfs, but > that did not make a difference. > I forgot to add my rc.conf. Maybe that will give a clue? ############## hostname="tst-cambria-11" wlans_ath0="wlan0" create_args_wlan0="wlanmode adhoc country ZA" ifconfig_wlan0_ipv6="inet6 auto_linklocal" wlans_ath1="wlan1" create_args_wlan1="wlanmode adhoc country ZA" ifconfig_wlan1_ipv6="inet6 auto_linklocal" wlans_ath2="wlan2" create_args_wlan2="wlanmode adhoc country ZA" ifconfig_wlan2_ipv6="inet6 auto_linklocal" ifconfig_npe0_ipv6="inet6 auto_linklocal" ifconfig_wlan0="-bgscan channel 140 ssid mesh bssid 02:8c:ca:fe:ca:00" ifconfig_wlan1="-bgscan channel 136 ssid mesh bssid 02:88:ca:fe:ca:00" ifconfig_wlan2="-bgscan channel 13 ssid hotspot bssid 02:0d:ca:fe:ca:00" ipv6_prefix_wlan0="fd35:ac5b:b116:10" ipv6_prefix_wlan1="fd35:ac5b:b116:10" ipv6_prefix_wlan2="fd35:ac5b:b116:38f4" ipv4_addrs_wlan2="10.56.244.1/24" ipv6_prefix_npe0="fd35:ac5b:b116:ee99" ipv4_addrs_npe0="10.238.153.1/24" varsize=5120 olsr_enable="NO" sendmail_enable="NO" sendmail_submit_enable="NO" sendmail_outbound_enable="NO" sendmail_msp_queue_enable="NO" devd_enable="NO" hostid_enable="NO" mixer_enable="NO" casperd_enable="NO" ######################## I checked booting with the above rc.conf that fails the second and third wlan, even if I then login and ifconfig destroy the wlans and run my script to configure them, they still fail. So why would the creation and configuration of the wlan interfaces work if it is not done during the boot, but after multi-user is reached? Regards John -- John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za / jhay@FreeBSD.org From owner-freebsd-embedded@FreeBSD.ORG Mon Jul 14 08:07:13 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D3DB1FB; Mon, 14 Jul 2014 08:07:13 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7A0202B46; Mon, 14 Jul 2014 08:07:12 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 7C057B842; Mon, 14 Jul 2014 10:07:08 +0200 (SAST) Date: Mon, 14 Jul 2014 10:07:08 +0200 From: John Hay To: Adrian Chadd Subject: Re: CAMBRIA and more than one atheros card Message-ID: <20140714080708.GA88464@zibbi.meraka.csir.co.za> References: <1404753166.65432.10.camel@revolution.hippie.lan> <20140707182814.GA75629@zibbi.meraka.csir.co.za> <20140707193252.GA79553@zibbi.meraka.csir.co.za> <20140708165438.GA83704@zibbi.meraka.csir.co.za> <20140709044612.GA51378@zibbi.meraka.csir.co.za> <20140710040227.GA73872@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140710040227.GA73872@zibbi.meraka.csir.co.za> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-wireless@freebsd.org" , "freebsd-embedded@freebsd.org" , Ian Lepore X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 08:07:13 -0000 On Thu, Jul 10, 2014 at 06:02:27AM +0200, John Hay wrote: > On Wed, Jul 09, 2014 at 06:46:12AM +0200, John Hay wrote: > > Hi Guys, > > > > The problem is back / still there. I initially saw the problem during > > boot, with the interface configs in rc.conf, but because it is so > > mixed with the rest, I took it out and put it in the script, then > > after multi-user boot was finished, I did a login and ran the script, > > with the output I showed in the initial post. > > > > So I put the interface configs back into rc.conf and I'm seeing the > > same problem, here is a cut during boot: > > > > ############### > > Starting file system checks: > > /dev/ad0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS > > /dev/ad0s1a: clean, 93385 free (33 frags, 11669 blocks, 0.0% fragmentation) > > Mounting local file systems:. > > Writing entropy file:. > > Setting hostname: tst-cambria-11. > > wlan0: Ethernet address: 00:21:a4:35:70:42 > > wlan1: Ethernet address: 00:21:a4:35:6c:96 > > ath1: unable to start recv logic > > wlan2: Ethernet address: 00:21:a4:32:38:c2 > > ath2: unable to start recv logic > > ############### > > > > Looking at the vmstat -z output the 256 Bucket fail is much higher than > > if I let it boot to multiuser and then configured the interfaces. It > > was in the 6000, while now it is much higher: > > > > Without wlan configs in rc.conf, but configured afterwards: > > 16 Bucket: 64, 0, 15, 300, 3139, 16, 0 > > 256 Bucket: 1024, 0, 31, 1, 592,6062, 0 > > vmem btag: 28, 0, 4496, 256, 4496, 32, 0 > > > > With wlan configs in rc.conf: > > 16 Bucket: 64, 0, 16, 299, 8611, 16, 0 > > 256 Bucket: 1024, 0, 26, 6, 773,16928, 0 > > vmem btag: 28, 0, 4405, 59, 4405, 30, 0 > > > > Both of them boot from a ro compact-flash with md /etc and /var, but > > they are small 4.3M and 2.1M. I have hacked in the use of tmpfs, but > > that did not make a difference. > > Friday I power cycled the board and it came up without an error. All 3 atheros cards configured in rc.conf. So I left it on for the weekend and by this morning there was still no errors, so I rebooted it and again saw the "ath1: unable to start recv logic" message for ath1 and ath2. I power cycled it, but still get the error, so Friday was just lucky with some timing thing, maybe if the card receive while it is still configuring? Also if I leave the board booted in this state, ath0 also start to give problems: ################# ath0: ath_rx_proc: no mbuf! ath0: ath_rx_proc: no mbuf! ... ath0: device timeout ath0: ath_reset: unable to start recv logic ... ################# In anycase it seems that memory allocation problem. How do I figure out where it is? "netstat -m" does not seem to point to an error. The mbuf info in vmstat -z also look ok. It is only "256 Bucket" in vmstat -z that point to an alloc failure. How do I figure out where that is and how do I fix it or work around it? ################### tst-11-arm:~ # netstat -m 128/382/510 mbufs in use (current/cache/total) 127/129/256/7654 mbuf clusters in use (current/cache/total/max) 127/126 mbuf+clusters out of packet secondary zone in use (current/cache) 0/0/0/3827 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/1134 9k jumbo clusters in use (current/cache/total/max) 0/0/0/637 16k jumbo clusters in use (current/cache/total/max) 286K/353K/639K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/3/1488 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile tst-11-arm:~ # vmstat -z | grep mbuf mbuf_packet: 256, 48990, 127, 126, 2294, 0, 0 mbuf: 256, 48990, 1, 256, 920, 0, 0 mbuf_cluster: 2048, 7654, 253, 3, 253, 0, 0 mbuf_jumbo_page: 4096, 3827, 0, 0, 0, 0, 0 mbuf_jumbo_9k: 9216, 1134, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 637, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 504, 1, 0, 0 tst-11-arm:~ # vmstat -z | grep Bucket 4 Bucket: 16, 0, 7, 497, 1565, 0, 0 6 Bucket: 24, 0, 0, 0, 0, 0, 0 8 Bucket: 32, 0, 3, 375, 83, 0, 0 12 Bucket: 48, 0, 2, 334, 5, 0, 0 16 Bucket: 64, 0, 14, 301, 43687, 16, 0 32 Bucket: 128, 0, 7, 148, 196, 0, 0 64 Bucket: 256, 0, 19, 56, 77, 0, 0 128 Bucket: 512, 0, 16, 16, 48, 0, 0 256 Bucket: 1024, 0, 29, 3, 1521,86738, 0 tst-11-arm:~ # ################### Regards John -- John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za / jhay@FreeBSD.org From owner-freebsd-embedded@FreeBSD.ORG Mon Jul 14 16:48:58 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4E85E536; Mon, 14 Jul 2014 16:48:58 +0000 (UTC) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D9FFC2B42; Mon, 14 Jul 2014 16:48:57 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id f12so3340137qad.17 for ; Mon, 14 Jul 2014 09:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Q4qqEWyB1SqUeUDPNnhWvHGrSccGQya7Le6zhkO/dvw=; b=da1mnTEvS8IzkYp/RmBgTX7f93VBUcmcxhPs4YgLUnqXnvaB1rZdK2QdPufpOWThUu wSMqdnM35rj53dkprVHqxoXRNx/nLP6lw2LcBi+iXm2kwyB0KBeH/HYpN5b98d+qlOTl 4GT9QVmy1+cRDVolPqSHpzuvrl1UKX/YL806fbY7GVNpGiugd7FbyXaZiJV6suX3Qzuu KmBU2HpSXxnbw5jSY8IizLqHItpJ8wxm4F+pJcq3sDwny/YDNrCEb3ZrGGjgK2Nb+mRr GQM2h6dqbL7PSbnpl3EYMGoGUfjIuQ3N3j2lzPhmAQtEgYUgBAdL/qpIbRY5NCxN9pms m5/A== MIME-Version: 1.0 X-Received: by 10.140.88.243 with SMTP id t106mr10457799qgd.12.1405356536961; Mon, 14 Jul 2014 09:48:56 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.202.193 with HTTP; Mon, 14 Jul 2014 09:48:56 -0700 (PDT) In-Reply-To: <20140714080708.GA88464@zibbi.meraka.csir.co.za> References: <1404753166.65432.10.camel@revolution.hippie.lan> <20140707182814.GA75629@zibbi.meraka.csir.co.za> <20140707193252.GA79553@zibbi.meraka.csir.co.za> <20140708165438.GA83704@zibbi.meraka.csir.co.za> <20140709044612.GA51378@zibbi.meraka.csir.co.za> <20140710040227.GA73872@zibbi.meraka.csir.co.za> <20140714080708.GA88464@zibbi.meraka.csir.co.za> Date: Mon, 14 Jul 2014 09:48:56 -0700 X-Google-Sender-Auth: oPmwykdbe53Z8kaZtKSrkB2pc4c Message-ID: Subject: Re: CAMBRIA and more than one atheros card From: Adrian Chadd To: John Hay Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-wireless@freebsd.org" , "freebsd-embedded@freebsd.org" , Ian Lepore X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 16:48:58 -0000 Hm, it could be some bus related stupidity. It's allocating 2k or 4k mbufs for the receive path because wifi frames are bigger than ethernet frames. If you're not seeing failures in 4k mbuf allocations then I'm not sure what it could be. I'll see about firing it up locally and checking. -a On 14 July 2014 01:07, John Hay wrote: > On Thu, Jul 10, 2014 at 06:02:27AM +0200, John Hay wrote: >> On Wed, Jul 09, 2014 at 06:46:12AM +0200, John Hay wrote: >> > Hi Guys, >> > >> > The problem is back / still there. I initially saw the problem during >> > boot, with the interface configs in rc.conf, but because it is so >> > mixed with the rest, I took it out and put it in the script, then >> > after multi-user boot was finished, I did a login and ran the script, >> > with the output I showed in the initial post. >> > >> > So I put the interface configs back into rc.conf and I'm seeing the >> > same problem, here is a cut during boot: >> > >> > ############### >> > Starting file system checks: >> > /dev/ad0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS >> > /dev/ad0s1a: clean, 93385 free (33 frags, 11669 blocks, 0.0% fragmentation) >> > Mounting local file systems:. >> > Writing entropy file:. >> > Setting hostname: tst-cambria-11. >> > wlan0: Ethernet address: 00:21:a4:35:70:42 >> > wlan1: Ethernet address: 00:21:a4:35:6c:96 >> > ath1: unable to start recv logic >> > wlan2: Ethernet address: 00:21:a4:32:38:c2 >> > ath2: unable to start recv logic >> > ############### >> > >> > Looking at the vmstat -z output the 256 Bucket fail is much higher than >> > if I let it boot to multiuser and then configured the interfaces. It >> > was in the 6000, while now it is much higher: >> > >> > Without wlan configs in rc.conf, but configured afterwards: >> > 16 Bucket: 64, 0, 15, 300, 3139, 16, 0 >> > 256 Bucket: 1024, 0, 31, 1, 592,6062, 0 >> > vmem btag: 28, 0, 4496, 256, 4496, 32, 0 >> > >> > With wlan configs in rc.conf: >> > 16 Bucket: 64, 0, 16, 299, 8611, 16, 0 >> > 256 Bucket: 1024, 0, 26, 6, 773,16928, 0 >> > vmem btag: 28, 0, 4405, 59, 4405, 30, 0 >> > >> > Both of them boot from a ro compact-flash with md /etc and /var, but >> > they are small 4.3M and 2.1M. I have hacked in the use of tmpfs, but >> > that did not make a difference. >> > > > Friday I power cycled the board and it came up without an error. All 3 > atheros cards configured in rc.conf. So I left it on for the weekend > and by this morning there was still no errors, so I rebooted it and > again saw the "ath1: unable to start recv logic" message for ath1 and > ath2. I power cycled it, but still get the error, so Friday was just > lucky with some timing thing, maybe if the card receive while it is > still configuring? Also if I leave the board booted in this state, > ath0 also start to give problems: > > ################# > ath0: ath_rx_proc: no mbuf! > ath0: ath_rx_proc: no mbuf! > ... > ath0: device timeout > ath0: ath_reset: unable to start recv logic > ... > ################# > > In anycase it seems that memory allocation problem. How do I figure out > where it is? "netstat -m" does not seem to point to an error. The mbuf > info in vmstat -z also look ok. It is only "256 Bucket" in vmstat -z > that point to an alloc failure. How do I figure out where that is and > how do I fix it or work around it? > > ################### > tst-11-arm:~ # netstat -m > 128/382/510 mbufs in use (current/cache/total) > 127/129/256/7654 mbuf clusters in use (current/cache/total/max) > 127/126 mbuf+clusters out of packet secondary zone in use (current/cache) > 0/0/0/3827 4k (page size) jumbo clusters in use (current/cache/total/max) > 0/0/0/1134 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/637 16k jumbo clusters in use (current/cache/total/max) > 286K/353K/639K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/3/1488 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > tst-11-arm:~ # vmstat -z | grep mbuf > mbuf_packet: 256, 48990, 127, 126, 2294, 0, 0 > mbuf: 256, 48990, 1, 256, 920, 0, 0 > mbuf_cluster: 2048, 7654, 253, 3, 253, 0, 0 > mbuf_jumbo_page: 4096, 3827, 0, 0, 0, 0, 0 > mbuf_jumbo_9k: 9216, 1134, 0, 0, 0, 0, 0 > mbuf_jumbo_16k: 16384, 637, 0, 0, 0, 0, 0 > mbuf_ext_refcnt: 4, 0, 0, 504, 1, 0, 0 > tst-11-arm:~ # vmstat -z | grep Bucket > 4 Bucket: 16, 0, 7, 497, 1565, 0, 0 > 6 Bucket: 24, 0, 0, 0, 0, 0, 0 > 8 Bucket: 32, 0, 3, 375, 83, 0, 0 > 12 Bucket: 48, 0, 2, 334, 5, 0, 0 > 16 Bucket: 64, 0, 14, 301, 43687, 16, 0 > 32 Bucket: 128, 0, 7, 148, 196, 0, 0 > 64 Bucket: 256, 0, 19, 56, 77, 0, 0 > 128 Bucket: 512, 0, 16, 16, 48, 0, 0 > 256 Bucket: 1024, 0, 29, 3, 1521,86738, 0 > tst-11-arm:~ # > ################### > > Regards > > John > -- > John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za / jhay@FreeBSD.org From owner-freebsd-embedded@FreeBSD.ORG Mon Jul 14 18:42:11 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EEBDCA1F; Mon, 14 Jul 2014 18:42:11 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id F0675261F; Mon, 14 Jul 2014 18:42:10 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 2CA00B84A; Mon, 14 Jul 2014 20:42:09 +0200 (SAST) Date: Mon, 14 Jul 2014 20:42:09 +0200 From: John Hay To: Adrian Chadd Subject: Re: CAMBRIA and more than one atheros card Message-ID: <20140714184209.GA21922@zibbi.meraka.csir.co.za> References: <20140707182814.GA75629@zibbi.meraka.csir.co.za> <20140707193252.GA79553@zibbi.meraka.csir.co.za> <20140708165438.GA83704@zibbi.meraka.csir.co.za> <20140709044612.GA51378@zibbi.meraka.csir.co.za> <20140710040227.GA73872@zibbi.meraka.csir.co.za> <20140714080708.GA88464@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-wireless@freebsd.org" , "freebsd-embedded@freebsd.org" , Ian Lepore X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 18:42:12 -0000 On Mon, Jul 14, 2014 at 09:48:56AM -0700, Adrian Chadd wrote: > Hm, it could be some bus related stupidity. It's allocating 2k or 4k > mbufs for the receive path because wifi frames are bigger than > ethernet frames. If you're not seeing failures in 4k mbuf allocations > then I'm not sure what it could be. > > I'll see about firing it up locally and checking. I'm hunting a bit more and it looks like the fail is in the bounce pages. It looks like the calls look like this: ath_legacy_rxbuf_init() bus_dmamap_load_mbuf_sg() _bus_dmamap_load_buffer() _bus_dmamap_reserve_pages() reserve_bounce_pages() I have added a printf at the start of alloc_bounce_pages() and it seems that it is only called (twice) when ath0 is probed. Is bus_dma_tag_t dmat, the first argument to alloc_bounce_pages(), common for the whole pci bus? The start of the boot, with my printf looks like this: #################### FreeBSD ARM (Gateworks Cambria) boot2 v0.4 - Default: /boot/kernel/kernel boot: Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #9 r268502M: Mon Jul 14 15:30:15 SAST 2014 jhay@dolphin.meraka.csir.co.za:/usr/obj/arm.armeb/snaps/arm/11-tst/src/sys/S MALL-CAMBRIA arm gcc version 4.2.1 20070831 patched [FreeBSD] CPU: IXP435 rev 1 (ARMv5TE) (XScale core) Big-endian DC enabled IC enabled WB enabled LABT branch prediction enabled 32KB/32B 32-way instruction cache 32KB/32B 32-way write-back-locking data cache real memory = 134213632 (127 MB) avail memory = 124440576 (118 MB) random device not loaded; using insecure entropy wlan: mac acl policy registered random: initialized ixp0: ixp0: 37e7f pcib0: on ixp0 pci0: on pcib0 ath0: irq 28 at device 1.0 on pci0 alloc_bounce_pages: numpages 63 [ath] enabling AN_TOP2_FIXUP alloc_bounce_pages: numpages 1 ath0: AR9220 mac 128.2 RF5133 phy 13.0 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 ath1: irq 27 at device 2.0 on pci0 [ath] enabling AN_TOP2_FIXUP ath1: AR9220 mac 128.2 RF5133 phy 13.0 ath1: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 ath2: irq 26 at device 3.0 on pci0 ath2: AR5413 mac 10.5 RF5413 phy 6.1 ath2: 2GHz radio: 0x0000; 5GHz radio: 0x0063 ixpclk0: on ixp0 #################### Interesting, with this boot, with the new kernel, the aths did not fail. Could the printf have changed something or was it just coincidence? With a reboot ath1 and ath2 failed again during configuration and a little while later ath0 started to complain: ath0: ath_rx_proc: no mbuf! John > > > > > -a > > On 14 July 2014 01:07, John Hay wrote: > > On Thu, Jul 10, 2014 at 06:02:27AM +0200, John Hay wrote: > >> On Wed, Jul 09, 2014 at 06:46:12AM +0200, John Hay wrote: > >> > Hi Guys, > >> > > >> > The problem is back / still there. I initially saw the problem during > >> > boot, with the interface configs in rc.conf, but because it is so > >> > mixed with the rest, I took it out and put it in the script, then > >> > after multi-user boot was finished, I did a login and ran the script, > >> > with the output I showed in the initial post. > >> > > >> > So I put the interface configs back into rc.conf and I'm seeing the > >> > same problem, here is a cut during boot: > >> > > >> > ############### > >> > Starting file system checks: > >> > /dev/ad0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS > >> > /dev/ad0s1a: clean, 93385 free (33 frags, 11669 blocks, 0.0% fragmentation) > >> > Mounting local file systems:. > >> > Writing entropy file:. > >> > Setting hostname: tst-cambria-11. > >> > wlan0: Ethernet address: 00:21:a4:35:70:42 > >> > wlan1: Ethernet address: 00:21:a4:35:6c:96 > >> > ath1: unable to start recv logic > >> > wlan2: Ethernet address: 00:21:a4:32:38:c2 > >> > ath2: unable to start recv logic > >> > ############### > >> > > >> > Looking at the vmstat -z output the 256 Bucket fail is much higher than > >> > if I let it boot to multiuser and then configured the interfaces. It > >> > was in the 6000, while now it is much higher: > >> > > >> > Without wlan configs in rc.conf, but configured afterwards: > >> > 16 Bucket: 64, 0, 15, 300, 3139, 16, 0 > >> > 256 Bucket: 1024, 0, 31, 1, 592,6062, 0 > >> > vmem btag: 28, 0, 4496, 256, 4496, 32, 0 > >> > > >> > With wlan configs in rc.conf: > >> > 16 Bucket: 64, 0, 16, 299, 8611, 16, 0 > >> > 256 Bucket: 1024, 0, 26, 6, 773,16928, 0 > >> > vmem btag: 28, 0, 4405, 59, 4405, 30, 0 > >> > > >> > Both of them boot from a ro compact-flash with md /etc and /var, but > >> > they are small 4.3M and 2.1M. I have hacked in the use of tmpfs, but > >> > that did not make a difference. > >> > > > > > Friday I power cycled the board and it came up without an error. All 3 > > atheros cards configured in rc.conf. So I left it on for the weekend > > and by this morning there was still no errors, so I rebooted it and > > again saw the "ath1: unable to start recv logic" message for ath1 and > > ath2. I power cycled it, but still get the error, so Friday was just > > lucky with some timing thing, maybe if the card receive while it is > > still configuring? Also if I leave the board booted in this state, > > ath0 also start to give problems: > > > > ################# > > ath0: ath_rx_proc: no mbuf! > > ath0: ath_rx_proc: no mbuf! > > ... > > ath0: device timeout > > ath0: ath_reset: unable to start recv logic > > ... > > ################# > > > > In anycase it seems that memory allocation problem. How do I figure out > > where it is? "netstat -m" does not seem to point to an error. The mbuf > > info in vmstat -z also look ok. It is only "256 Bucket" in vmstat -z > > that point to an alloc failure. How do I figure out where that is and > > how do I fix it or work around it? > > > > ################### > > tst-11-arm:~ # netstat -m > > 128/382/510 mbufs in use (current/cache/total) > > 127/129/256/7654 mbuf clusters in use (current/cache/total/max) > > 127/126 mbuf+clusters out of packet secondary zone in use (current/cache) > > 0/0/0/3827 4k (page size) jumbo clusters in use (current/cache/total/max) > > 0/0/0/1134 9k jumbo clusters in use (current/cache/total/max) > > 0/0/0/637 16k jumbo clusters in use (current/cache/total/max) > > 286K/353K/639K bytes allocated to network (current/cache/total) > > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > > 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) > > 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) > > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > > 0/3/1488 sfbufs in use (current/peak/max) > > 0 requests for sfbufs denied > > 0 requests for sfbufs delayed > > 0 requests for I/O initiated by sendfile > > tst-11-arm:~ # vmstat -z | grep mbuf > > mbuf_packet: 256, 48990, 127, 126, 2294, 0, 0 > > mbuf: 256, 48990, 1, 256, 920, 0, 0 > > mbuf_cluster: 2048, 7654, 253, 3, 253, 0, 0 > > mbuf_jumbo_page: 4096, 3827, 0, 0, 0, 0, 0 > > mbuf_jumbo_9k: 9216, 1134, 0, 0, 0, 0, 0 > > mbuf_jumbo_16k: 16384, 637, 0, 0, 0, 0, 0 > > mbuf_ext_refcnt: 4, 0, 0, 504, 1, 0, 0 > > tst-11-arm:~ # vmstat -z | grep Bucket > > 4 Bucket: 16, 0, 7, 497, 1565, 0, 0 > > 6 Bucket: 24, 0, 0, 0, 0, 0, 0 > > 8 Bucket: 32, 0, 3, 375, 83, 0, 0 > > 12 Bucket: 48, 0, 2, 334, 5, 0, 0 > > 16 Bucket: 64, 0, 14, 301, 43687, 16, 0 > > 32 Bucket: 128, 0, 7, 148, 196, 0, 0 > > 64 Bucket: 256, 0, 19, 56, 77, 0, 0 > > 128 Bucket: 512, 0, 16, 16, 48, 0, 0 > > 256 Bucket: 1024, 0, 29, 3, 1521,86738, 0 > > tst-11-arm:~ # > > ################### > > > > Regards > > > > John > > -- > > John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za / jhay@FreeBSD.org From owner-freebsd-embedded@FreeBSD.ORG Mon Jul 14 19:06:35 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CCB02AF5; Mon, 14 Jul 2014 19:06:35 +0000 (UTC) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 65C002848; Mon, 14 Jul 2014 19:06:35 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id j7so2993646qaq.14 for ; Mon, 14 Jul 2014 12:06:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=IUwaGjgsJCeZsMZFQTolpfnHG3K7fqyt0zLcPDwFNhc=; b=nTSBS4u7amBmARTbxm9s9qrj3UGqOsRpq5Lybq1e6e6OsV95A6Ky+PIDEYdECEXYYp SyiCdTvFqAcMNEbgpA4vuCMIWaU1v7S1mNu8/MzXQH4HZug0Fyu/tpFFNFHVTZ1nzws9 04/hkyGRaFYjhoyTld4z2BBWajSMwiKhpy6z6nxstqKkvMqZpyWQMxm782+qRTQTAmSa kxkr1XljbYoL2ahRALe3x5Nrfck3wZN/FfF8TEKPo0OZ88qE/CxIEnb+ogYiVz5YUgr5 1z4wCY+dIgFEKy/qa3kOr89/hNPk5WF0gMLR1wLH9Pz/ESDGcX7NtlvIZaY8ue0Z4hP8 C9Kw== MIME-Version: 1.0 X-Received: by 10.224.156.145 with SMTP id x17mr26850685qaw.49.1405364794585; Mon, 14 Jul 2014 12:06:34 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.202.193 with HTTP; Mon, 14 Jul 2014 12:06:34 -0700 (PDT) In-Reply-To: <20140714184209.GA21922@zibbi.meraka.csir.co.za> References: <20140707182814.GA75629@zibbi.meraka.csir.co.za> <20140707193252.GA79553@zibbi.meraka.csir.co.za> <20140708165438.GA83704@zibbi.meraka.csir.co.za> <20140709044612.GA51378@zibbi.meraka.csir.co.za> <20140710040227.GA73872@zibbi.meraka.csir.co.za> <20140714080708.GA88464@zibbi.meraka.csir.co.za> <20140714184209.GA21922@zibbi.meraka.csir.co.za> Date: Mon, 14 Jul 2014 12:06:34 -0700 X-Google-Sender-Auth: OfNwvasoQli-DBDn7C37kBdYGrU Message-ID: Subject: Re: CAMBRIA and more than one atheros card From: Adrian Chadd To: John Hay Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-wireless@freebsd.org" , "freebsd-embedded@freebsd.org" , Ian Lepore X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 19:06:35 -0000 .. why's it need bounce buffers? -a On 14 July 2014 11:42, John Hay wrote: > On Mon, Jul 14, 2014 at 09:48:56AM -0700, Adrian Chadd wrote: >> Hm, it could be some bus related stupidity. It's allocating 2k or 4k >> mbufs for the receive path because wifi frames are bigger than >> ethernet frames. If you're not seeing failures in 4k mbuf allocations >> then I'm not sure what it could be. >> >> I'll see about firing it up locally and checking. > > I'm hunting a bit more and it looks like the fail is in the bounce pages. > It looks like the calls look like this: > > ath_legacy_rxbuf_init() > bus_dmamap_load_mbuf_sg() > _bus_dmamap_load_buffer() > _bus_dmamap_reserve_pages() > reserve_bounce_pages() > > I have added a printf at the start of alloc_bounce_pages() and it seems > that it is only called (twice) when ath0 is probed. Is bus_dma_tag_t dmat, > the first argument to alloc_bounce_pages(), common for the whole pci bus? > > The start of the boot, with my printf looks like this: > > #################### > FreeBSD ARM (Gateworks Cambria) boot2 v0.4 > - > Default: /boot/kernel/kernel > boot: > Copyright (c) 1992-2014 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 11.0-CURRENT #9 r268502M: Mon Jul 14 15:30:15 SAST 2014 > jhay@dolphin.meraka.csir.co.za:/usr/obj/arm.armeb/snaps/arm/11-tst/src/sys/S > MALL-CAMBRIA arm > gcc version 4.2.1 20070831 patched [FreeBSD] > CPU: IXP435 rev 1 (ARMv5TE) (XScale core) > Big-endian DC enabled IC enabled WB enabled LABT branch prediction enabled > 32KB/32B 32-way instruction cache > 32KB/32B 32-way write-back-locking data cache > real memory = 134213632 (127 MB) > avail memory = 124440576 (118 MB) > random device not loaded; using insecure entropy > wlan: mac acl policy registered > random: initialized > ixp0: > ixp0: 37e7f > pcib0: on ixp0 > pci0: on pcib0 > ath0: irq 28 at device 1.0 on pci0 > alloc_bounce_pages: numpages 63 > [ath] enabling AN_TOP2_FIXUP > alloc_bounce_pages: numpages 1 > ath0: AR9220 mac 128.2 RF5133 phy 13.0 > ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 > ath1: irq 27 at device 2.0 on pci0 > [ath] enabling AN_TOP2_FIXUP > ath1: AR9220 mac 128.2 RF5133 phy 13.0 > ath1: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 > ath2: irq 26 at device 3.0 on pci0 > ath2: AR5413 mac 10.5 RF5413 phy 6.1 > ath2: 2GHz radio: 0x0000; 5GHz radio: 0x0063 > ixpclk0: on ixp0 > #################### > > Interesting, with this boot, with the new kernel, the aths did not fail. > Could the printf have changed something or was it just coincidence? With > a reboot ath1 and ath2 failed again during configuration and a little > while later ath0 started to complain: > > ath0: ath_rx_proc: no mbuf! > > John > >> >> >> >> >> -a >> >> On 14 July 2014 01:07, John Hay wrote: >> > On Thu, Jul 10, 2014 at 06:02:27AM +0200, John Hay wrote: >> >> On Wed, Jul 09, 2014 at 06:46:12AM +0200, John Hay wrote: >> >> > Hi Guys, >> >> > >> >> > The problem is back / still there. I initially saw the problem during >> >> > boot, with the interface configs in rc.conf, but because it is so >> >> > mixed with the rest, I took it out and put it in the script, then >> >> > after multi-user boot was finished, I did a login and ran the script, >> >> > with the output I showed in the initial post. >> >> > >> >> > So I put the interface configs back into rc.conf and I'm seeing the >> >> > same problem, here is a cut during boot: >> >> > >> >> > ############### >> >> > Starting file system checks: >> >> > /dev/ad0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS >> >> > /dev/ad0s1a: clean, 93385 free (33 frags, 11669 blocks, 0.0% fragmentation) >> >> > Mounting local file systems:. >> >> > Writing entropy file:. >> >> > Setting hostname: tst-cambria-11. >> >> > wlan0: Ethernet address: 00:21:a4:35:70:42 >> >> > wlan1: Ethernet address: 00:21:a4:35:6c:96 >> >> > ath1: unable to start recv logic >> >> > wlan2: Ethernet address: 00:21:a4:32:38:c2 >> >> > ath2: unable to start recv logic >> >> > ############### >> >> > >> >> > Looking at the vmstat -z output the 256 Bucket fail is much higher than >> >> > if I let it boot to multiuser and then configured the interfaces. It >> >> > was in the 6000, while now it is much higher: >> >> > >> >> > Without wlan configs in rc.conf, but configured afterwards: >> >> > 16 Bucket: 64, 0, 15, 300, 3139, 16, 0 >> >> > 256 Bucket: 1024, 0, 31, 1, 592,6062, 0 >> >> > vmem btag: 28, 0, 4496, 256, 4496, 32, 0 >> >> > >> >> > With wlan configs in rc.conf: >> >> > 16 Bucket: 64, 0, 16, 299, 8611, 16, 0 >> >> > 256 Bucket: 1024, 0, 26, 6, 773,16928, 0 >> >> > vmem btag: 28, 0, 4405, 59, 4405, 30, 0 >> >> > >> >> > Both of them boot from a ro compact-flash with md /etc and /var, but >> >> > they are small 4.3M and 2.1M. I have hacked in the use of tmpfs, but >> >> > that did not make a difference. >> >> > >> > >> > Friday I power cycled the board and it came up without an error. All 3 >> > atheros cards configured in rc.conf. So I left it on for the weekend >> > and by this morning there was still no errors, so I rebooted it and >> > again saw the "ath1: unable to start recv logic" message for ath1 and >> > ath2. I power cycled it, but still get the error, so Friday was just >> > lucky with some timing thing, maybe if the card receive while it is >> > still configuring? Also if I leave the board booted in this state, >> > ath0 also start to give problems: >> > >> > ################# >> > ath0: ath_rx_proc: no mbuf! >> > ath0: ath_rx_proc: no mbuf! >> > ... >> > ath0: device timeout >> > ath0: ath_reset: unable to start recv logic >> > ... >> > ################# >> > >> > In anycase it seems that memory allocation problem. How do I figure out >> > where it is? "netstat -m" does not seem to point to an error. The mbuf >> > info in vmstat -z also look ok. It is only "256 Bucket" in vmstat -z >> > that point to an alloc failure. How do I figure out where that is and >> > how do I fix it or work around it? >> > >> > ################### >> > tst-11-arm:~ # netstat -m >> > 128/382/510 mbufs in use (current/cache/total) >> > 127/129/256/7654 mbuf clusters in use (current/cache/total/max) >> > 127/126 mbuf+clusters out of packet secondary zone in use (current/cache) >> > 0/0/0/3827 4k (page size) jumbo clusters in use (current/cache/total/max) >> > 0/0/0/1134 9k jumbo clusters in use (current/cache/total/max) >> > 0/0/0/637 16k jumbo clusters in use (current/cache/total/max) >> > 286K/353K/639K bytes allocated to network (current/cache/total) >> > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) >> > 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) >> > 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) >> > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) >> > 0/3/1488 sfbufs in use (current/peak/max) >> > 0 requests for sfbufs denied >> > 0 requests for sfbufs delayed >> > 0 requests for I/O initiated by sendfile >> > tst-11-arm:~ # vmstat -z | grep mbuf >> > mbuf_packet: 256, 48990, 127, 126, 2294, 0, 0 >> > mbuf: 256, 48990, 1, 256, 920, 0, 0 >> > mbuf_cluster: 2048, 7654, 253, 3, 253, 0, 0 >> > mbuf_jumbo_page: 4096, 3827, 0, 0, 0, 0, 0 >> > mbuf_jumbo_9k: 9216, 1134, 0, 0, 0, 0, 0 >> > mbuf_jumbo_16k: 16384, 637, 0, 0, 0, 0, 0 >> > mbuf_ext_refcnt: 4, 0, 0, 504, 1, 0, 0 >> > tst-11-arm:~ # vmstat -z | grep Bucket >> > 4 Bucket: 16, 0, 7, 497, 1565, 0, 0 >> > 6 Bucket: 24, 0, 0, 0, 0, 0, 0 >> > 8 Bucket: 32, 0, 3, 375, 83, 0, 0 >> > 12 Bucket: 48, 0, 2, 334, 5, 0, 0 >> > 16 Bucket: 64, 0, 14, 301, 43687, 16, 0 >> > 32 Bucket: 128, 0, 7, 148, 196, 0, 0 >> > 64 Bucket: 256, 0, 19, 56, 77, 0, 0 >> > 128 Bucket: 512, 0, 16, 16, 48, 0, 0 >> > 256 Bucket: 1024, 0, 29, 3, 1521,86738, 0 >> > tst-11-arm:~ # >> > ################### >> > >> > Regards >> > >> > John >> > -- >> > John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za / jhay@FreeBSD.org From owner-freebsd-embedded@FreeBSD.ORG Mon Jul 14 19:09:49 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A745BBD; Mon, 14 Jul 2014 19:09:49 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2DF9C286D; Mon, 14 Jul 2014 19:09:48 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id EACF3B842; Mon, 14 Jul 2014 21:09:46 +0200 (SAST) Date: Mon, 14 Jul 2014 21:09:46 +0200 From: John Hay To: Adrian Chadd Subject: Re: CAMBRIA and more than one atheros card Message-ID: <20140714190946.GA49930@zibbi.meraka.csir.co.za> References: <20140707193252.GA79553@zibbi.meraka.csir.co.za> <20140708165438.GA83704@zibbi.meraka.csir.co.za> <20140709044612.GA51378@zibbi.meraka.csir.co.za> <20140710040227.GA73872@zibbi.meraka.csir.co.za> <20140714080708.GA88464@zibbi.meraka.csir.co.za> <20140714184209.GA21922@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-wireless@freebsd.org" , "freebsd-embedded@freebsd.org" , Ian Lepore X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 19:09:49 -0000 On Mon, Jul 14, 2014 at 12:06:34PM -0700, Adrian Chadd wrote: > .. why's it need bounce buffers? I found this: arm/xscale/ixp425/ixp425_pci.c: /* NB: PCI dma window is 64M so anything above must be bounced */ John > > > -a > > > On 14 July 2014 11:42, John Hay wrote: > > On Mon, Jul 14, 2014 at 09:48:56AM -0700, Adrian Chadd wrote: > >> Hm, it could be some bus related stupidity. It's allocating 2k or 4k > >> mbufs for the receive path because wifi frames are bigger than > >> ethernet frames. If you're not seeing failures in 4k mbuf allocations > >> then I'm not sure what it could be. > >> > >> I'll see about firing it up locally and checking. > > > > I'm hunting a bit more and it looks like the fail is in the bounce pages. > > It looks like the calls look like this: > > > > ath_legacy_rxbuf_init() > > bus_dmamap_load_mbuf_sg() > > _bus_dmamap_load_buffer() > > _bus_dmamap_reserve_pages() > > reserve_bounce_pages() > > > > I have added a printf at the start of alloc_bounce_pages() and it seems > > that it is only called (twice) when ath0 is probed. Is bus_dma_tag_t dmat, > > the first argument to alloc_bounce_pages(), common for the whole pci bus? > > > > The start of the boot, with my printf looks like this: > > > > #################### > > FreeBSD ARM (Gateworks Cambria) boot2 v0.4 > > - > > Default: /boot/kernel/kernel > > boot: > > Copyright (c) 1992-2014 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > The Regents of the University of California. All rights reserved. > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > FreeBSD 11.0-CURRENT #9 r268502M: Mon Jul 14 15:30:15 SAST 2014 > > jhay@dolphin.meraka.csir.co.za:/usr/obj/arm.armeb/snaps/arm/11-tst/src/sys/S > > MALL-CAMBRIA arm > > gcc version 4.2.1 20070831 patched [FreeBSD] > > CPU: IXP435 rev 1 (ARMv5TE) (XScale core) > > Big-endian DC enabled IC enabled WB enabled LABT branch prediction enabled > > 32KB/32B 32-way instruction cache > > 32KB/32B 32-way write-back-locking data cache > > real memory = 134213632 (127 MB) > > avail memory = 124440576 (118 MB) > > random device not loaded; using insecure entropy > > wlan: mac acl policy registered > > random: initialized > > ixp0: > > ixp0: 37e7f > > pcib0: on ixp0 > > pci0: on pcib0 > > ath0: irq 28 at device 1.0 on pci0 > > alloc_bounce_pages: numpages 63 > > [ath] enabling AN_TOP2_FIXUP > > alloc_bounce_pages: numpages 1 > > ath0: AR9220 mac 128.2 RF5133 phy 13.0 > > ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 > > ath1: irq 27 at device 2.0 on pci0 > > [ath] enabling AN_TOP2_FIXUP > > ath1: AR9220 mac 128.2 RF5133 phy 13.0 > > ath1: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 > > ath2: irq 26 at device 3.0 on pci0 > > ath2: AR5413 mac 10.5 RF5413 phy 6.1 > > ath2: 2GHz radio: 0x0000; 5GHz radio: 0x0063 > > ixpclk0: on ixp0 > > #################### > > > > Interesting, with this boot, with the new kernel, the aths did not fail. > > Could the printf have changed something or was it just coincidence? With > > a reboot ath1 and ath2 failed again during configuration and a little > > while later ath0 started to complain: > > > > ath0: ath_rx_proc: no mbuf! > > > > John > > > >> > >> > >> > >> > >> -a > >> > >> On 14 July 2014 01:07, John Hay wrote: > >> > On Thu, Jul 10, 2014 at 06:02:27AM +0200, John Hay wrote: > >> >> On Wed, Jul 09, 2014 at 06:46:12AM +0200, John Hay wrote: > >> >> > Hi Guys, > >> >> > > >> >> > The problem is back / still there. I initially saw the problem during > >> >> > boot, with the interface configs in rc.conf, but because it is so > >> >> > mixed with the rest, I took it out and put it in the script, then > >> >> > after multi-user boot was finished, I did a login and ran the script, > >> >> > with the output I showed in the initial post. > >> >> > > >> >> > So I put the interface configs back into rc.conf and I'm seeing the > >> >> > same problem, here is a cut during boot: > >> >> > > >> >> > ############### > >> >> > Starting file system checks: > >> >> > /dev/ad0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS > >> >> > /dev/ad0s1a: clean, 93385 free (33 frags, 11669 blocks, 0.0% fragmentation) > >> >> > Mounting local file systems:. > >> >> > Writing entropy file:. > >> >> > Setting hostname: tst-cambria-11. > >> >> > wlan0: Ethernet address: 00:21:a4:35:70:42 > >> >> > wlan1: Ethernet address: 00:21:a4:35:6c:96 > >> >> > ath1: unable to start recv logic > >> >> > wlan2: Ethernet address: 00:21:a4:32:38:c2 > >> >> > ath2: unable to start recv logic > >> >> > ############### > >> >> > > >> >> > Looking at the vmstat -z output the 256 Bucket fail is much higher than > >> >> > if I let it boot to multiuser and then configured the interfaces. It > >> >> > was in the 6000, while now it is much higher: > >> >> > > >> >> > Without wlan configs in rc.conf, but configured afterwards: > >> >> > 16 Bucket: 64, 0, 15, 300, 3139, 16, 0 > >> >> > 256 Bucket: 1024, 0, 31, 1, 592,6062, 0 > >> >> > vmem btag: 28, 0, 4496, 256, 4496, 32, 0 > >> >> > > >> >> > With wlan configs in rc.conf: > >> >> > 16 Bucket: 64, 0, 16, 299, 8611, 16, 0 > >> >> > 256 Bucket: 1024, 0, 26, 6, 773,16928, 0 > >> >> > vmem btag: 28, 0, 4405, 59, 4405, 30, 0 > >> >> > > >> >> > Both of them boot from a ro compact-flash with md /etc and /var, but > >> >> > they are small 4.3M and 2.1M. I have hacked in the use of tmpfs, but > >> >> > that did not make a difference. > >> >> > > >> > > >> > Friday I power cycled the board and it came up without an error. All 3 > >> > atheros cards configured in rc.conf. So I left it on for the weekend > >> > and by this morning there was still no errors, so I rebooted it and > >> > again saw the "ath1: unable to start recv logic" message for ath1 and > >> > ath2. I power cycled it, but still get the error, so Friday was just > >> > lucky with some timing thing, maybe if the card receive while it is > >> > still configuring? Also if I leave the board booted in this state, > >> > ath0 also start to give problems: > >> > > >> > ################# > >> > ath0: ath_rx_proc: no mbuf! > >> > ath0: ath_rx_proc: no mbuf! > >> > ... > >> > ath0: device timeout > >> > ath0: ath_reset: unable to start recv logic > >> > ... > >> > ################# > >> > > >> > In anycase it seems that memory allocation problem. How do I figure out > >> > where it is? "netstat -m" does not seem to point to an error. The mbuf > >> > info in vmstat -z also look ok. It is only "256 Bucket" in vmstat -z > >> > that point to an alloc failure. How do I figure out where that is and > >> > how do I fix it or work around it? > >> > > >> > ################### > >> > tst-11-arm:~ # netstat -m > >> > 128/382/510 mbufs in use (current/cache/total) > >> > 127/129/256/7654 mbuf clusters in use (current/cache/total/max) > >> > 127/126 mbuf+clusters out of packet secondary zone in use (current/cache) > >> > 0/0/0/3827 4k (page size) jumbo clusters in use (current/cache/total/max) > >> > 0/0/0/1134 9k jumbo clusters in use (current/cache/total/max) > >> > 0/0/0/637 16k jumbo clusters in use (current/cache/total/max) > >> > 286K/353K/639K bytes allocated to network (current/cache/total) > >> > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > >> > 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) > >> > 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) > >> > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > >> > 0/3/1488 sfbufs in use (current/peak/max) > >> > 0 requests for sfbufs denied > >> > 0 requests for sfbufs delayed > >> > 0 requests for I/O initiated by sendfile > >> > tst-11-arm:~ # vmstat -z | grep mbuf > >> > mbuf_packet: 256, 48990, 127, 126, 2294, 0, 0 > >> > mbuf: 256, 48990, 1, 256, 920, 0, 0 > >> > mbuf_cluster: 2048, 7654, 253, 3, 253, 0, 0 > >> > mbuf_jumbo_page: 4096, 3827, 0, 0, 0, 0, 0 > >> > mbuf_jumbo_9k: 9216, 1134, 0, 0, 0, 0, 0 > >> > mbuf_jumbo_16k: 16384, 637, 0, 0, 0, 0, 0 > >> > mbuf_ext_refcnt: 4, 0, 0, 504, 1, 0, 0 > >> > tst-11-arm:~ # vmstat -z | grep Bucket > >> > 4 Bucket: 16, 0, 7, 497, 1565, 0, 0 > >> > 6 Bucket: 24, 0, 0, 0, 0, 0, 0 > >> > 8 Bucket: 32, 0, 3, 375, 83, 0, 0 > >> > 12 Bucket: 48, 0, 2, 334, 5, 0, 0 > >> > 16 Bucket: 64, 0, 14, 301, 43687, 16, 0 > >> > 32 Bucket: 128, 0, 7, 148, 196, 0, 0 > >> > 64 Bucket: 256, 0, 19, 56, 77, 0, 0 > >> > 128 Bucket: 512, 0, 16, 16, 48, 0, 0 > >> > 256 Bucket: 1024, 0, 29, 3, 1521,86738, 0 > >> > tst-11-arm:~ # > >> > ################### > >> > > >> > Regards > >> > > >> > John > >> > -- > >> > John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za / jhay@FreeBSD.org From owner-freebsd-embedded@FreeBSD.ORG Mon Jul 14 19:14:19 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD665D9D; Mon, 14 Jul 2014 19:14:18 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id CB5E5290E; Mon, 14 Jul 2014 19:14:17 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 99205B84A; Mon, 14 Jul 2014 21:14:16 +0200 (SAST) Date: Mon, 14 Jul 2014 21:14:16 +0200 From: John Hay To: Adrian Chadd Subject: Re: CAMBRIA and more than one atheros card Message-ID: <20140714191416.GB49930@zibbi.meraka.csir.co.za> References: <20140707193252.GA79553@zibbi.meraka.csir.co.za> <20140708165438.GA83704@zibbi.meraka.csir.co.za> <20140709044612.GA51378@zibbi.meraka.csir.co.za> <20140710040227.GA73872@zibbi.meraka.csir.co.za> <20140714080708.GA88464@zibbi.meraka.csir.co.za> <20140714184209.GA21922@zibbi.meraka.csir.co.za> <20140714190946.GA49930@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140714190946.GA49930@zibbi.meraka.csir.co.za> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-wireless@freebsd.org" , "freebsd-embedded@freebsd.org" , Ian Lepore X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 19:14:19 -0000 On Mon, Jul 14, 2014 at 09:09:46PM +0200, John Hay wrote: > On Mon, Jul 14, 2014 at 12:06:34PM -0700, Adrian Chadd wrote: > > .. why's it need bounce buffers? > > I found this: > arm/xscale/ixp425/ixp425_pci.c: /* NB: PCI dma window is 64M so anything above must be bounced */ I found a sysctl to show some bounce info. :-) On the boot that ath1 and ath2 failed during ifconfig and ath0 started to complain after a while: ##################### tst-11-arm:~ # sysctl hw.busdma hw.busdma.total_bpages: 64 hw.busdma.zone0.total_bpages: 64 hw.busdma.zone0.free_bpages: 0 hw.busdma.zone0.reserved_bpages: 0 hw.busdma.zone0.active_bpages: 64 hw.busdma.zone0.total_bounced: 1191 hw.busdma.zone0.total_deferred: 0 hw.busdma.zone0.lowaddr: 0x4000fff hw.busdma.zone0.alignment: 4096 ##################### I then thought to down wlan0 to see if the page count changed, but do not know. :-) ##################### tst-11-arm:~ # ifconfig wlan0 down dev.ath.0.debug: 0 -> 8 /sbin/ifconfig.bin wlan0 down ath0: ath_stop_locked: invalid 0 if_flags 0x8802 Sleeping thread (tid 100019, pid 0) owns a non-sleepable lock panic: sleeping thread Uptime: 32m46s Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... ##################### John > > John > > > > > > -a > > > > > > On 14 July 2014 11:42, John Hay wrote: > > > On Mon, Jul 14, 2014 at 09:48:56AM -0700, Adrian Chadd wrote: > > >> Hm, it could be some bus related stupidity. It's allocating 2k or 4k > > >> mbufs for the receive path because wifi frames are bigger than > > >> ethernet frames. If you're not seeing failures in 4k mbuf allocations > > >> then I'm not sure what it could be. > > >> > > >> I'll see about firing it up locally and checking. > > > > > > I'm hunting a bit more and it looks like the fail is in the bounce pages. > > > It looks like the calls look like this: > > > > > > ath_legacy_rxbuf_init() > > > bus_dmamap_load_mbuf_sg() > > > _bus_dmamap_load_buffer() > > > _bus_dmamap_reserve_pages() > > > reserve_bounce_pages() > > > > > > I have added a printf at the start of alloc_bounce_pages() and it seems > > > that it is only called (twice) when ath0 is probed. Is bus_dma_tag_t dmat, > > > the first argument to alloc_bounce_pages(), common for the whole pci bus? > > > > > > The start of the boot, with my printf looks like this: > > > > > > #################### > > > FreeBSD ARM (Gateworks Cambria) boot2 v0.4 > > > - > > > Default: /boot/kernel/kernel > > > boot: > > > Copyright (c) 1992-2014 The FreeBSD Project. > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > > The Regents of the University of California. All rights reserved. > > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > > FreeBSD 11.0-CURRENT #9 r268502M: Mon Jul 14 15:30:15 SAST 2014 > > > jhay@dolphin.meraka.csir.co.za:/usr/obj/arm.armeb/snaps/arm/11-tst/src/sys/S > > > MALL-CAMBRIA arm > > > gcc version 4.2.1 20070831 patched [FreeBSD] > > > CPU: IXP435 rev 1 (ARMv5TE) (XScale core) > > > Big-endian DC enabled IC enabled WB enabled LABT branch prediction enabled > > > 32KB/32B 32-way instruction cache > > > 32KB/32B 32-way write-back-locking data cache > > > real memory = 134213632 (127 MB) > > > avail memory = 124440576 (118 MB) > > > random device not loaded; using insecure entropy > > > wlan: mac acl policy registered > > > random: initialized > > > ixp0: > > > ixp0: 37e7f > > > pcib0: on ixp0 > > > pci0: on pcib0 > > > ath0: irq 28 at device 1.0 on pci0 > > > alloc_bounce_pages: numpages 63 > > > [ath] enabling AN_TOP2_FIXUP > > > alloc_bounce_pages: numpages 1 > > > ath0: AR9220 mac 128.2 RF5133 phy 13.0 > > > ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 > > > ath1: irq 27 at device 2.0 on pci0 > > > [ath] enabling AN_TOP2_FIXUP > > > ath1: AR9220 mac 128.2 RF5133 phy 13.0 > > > ath1: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 > > > ath2: irq 26 at device 3.0 on pci0 > > > ath2: AR5413 mac 10.5 RF5413 phy 6.1 > > > ath2: 2GHz radio: 0x0000; 5GHz radio: 0x0063 > > > ixpclk0: on ixp0 > > > #################### > > > > > > Interesting, with this boot, with the new kernel, the aths did not fail. > > > Could the printf have changed something or was it just coincidence? With > > > a reboot ath1 and ath2 failed again during configuration and a little > > > while later ath0 started to complain: > > > > > > ath0: ath_rx_proc: no mbuf! > > > > > > John > > > > > >> > > >> > > >> > > >> > > >> -a > > >> > > >> On 14 July 2014 01:07, John Hay wrote: > > >> > On Thu, Jul 10, 2014 at 06:02:27AM +0200, John Hay wrote: > > >> >> On Wed, Jul 09, 2014 at 06:46:12AM +0200, John Hay wrote: > > >> >> > Hi Guys, > > >> >> > > > >> >> > The problem is back / still there. I initially saw the problem during > > >> >> > boot, with the interface configs in rc.conf, but because it is so > > >> >> > mixed with the rest, I took it out and put it in the script, then > > >> >> > after multi-user boot was finished, I did a login and ran the script, > > >> >> > with the output I showed in the initial post. > > >> >> > > > >> >> > So I put the interface configs back into rc.conf and I'm seeing the > > >> >> > same problem, here is a cut during boot: > > >> >> > > > >> >> > ############### > > >> >> > Starting file system checks: > > >> >> > /dev/ad0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS > > >> >> > /dev/ad0s1a: clean, 93385 free (33 frags, 11669 blocks, 0.0% fragmentation) > > >> >> > Mounting local file systems:. > > >> >> > Writing entropy file:. > > >> >> > Setting hostname: tst-cambria-11. > > >> >> > wlan0: Ethernet address: 00:21:a4:35:70:42 > > >> >> > wlan1: Ethernet address: 00:21:a4:35:6c:96 > > >> >> > ath1: unable to start recv logic > > >> >> > wlan2: Ethernet address: 00:21:a4:32:38:c2 > > >> >> > ath2: unable to start recv logic > > >> >> > ############### > > >> >> > > > >> >> > Looking at the vmstat -z output the 256 Bucket fail is much higher than > > >> >> > if I let it boot to multiuser and then configured the interfaces. It > > >> >> > was in the 6000, while now it is much higher: > > >> >> > > > >> >> > Without wlan configs in rc.conf, but configured afterwards: > > >> >> > 16 Bucket: 64, 0, 15, 300, 3139, 16, 0 > > >> >> > 256 Bucket: 1024, 0, 31, 1, 592,6062, 0 > > >> >> > vmem btag: 28, 0, 4496, 256, 4496, 32, 0 > > >> >> > > > >> >> > With wlan configs in rc.conf: > > >> >> > 16 Bucket: 64, 0, 16, 299, 8611, 16, 0 > > >> >> > 256 Bucket: 1024, 0, 26, 6, 773,16928, 0 > > >> >> > vmem btag: 28, 0, 4405, 59, 4405, 30, 0 > > >> >> > > > >> >> > Both of them boot from a ro compact-flash with md /etc and /var, but > > >> >> > they are small 4.3M and 2.1M. I have hacked in the use of tmpfs, but > > >> >> > that did not make a difference. > > >> >> > > > >> > > > >> > Friday I power cycled the board and it came up without an error. All 3 > > >> > atheros cards configured in rc.conf. So I left it on for the weekend > > >> > and by this morning there was still no errors, so I rebooted it and > > >> > again saw the "ath1: unable to start recv logic" message for ath1 and > > >> > ath2. I power cycled it, but still get the error, so Friday was just > > >> > lucky with some timing thing, maybe if the card receive while it is > > >> > still configuring? Also if I leave the board booted in this state, > > >> > ath0 also start to give problems: > > >> > > > >> > ################# > > >> > ath0: ath_rx_proc: no mbuf! > > >> > ath0: ath_rx_proc: no mbuf! > > >> > ... > > >> > ath0: device timeout > > >> > ath0: ath_reset: unable to start recv logic > > >> > ... > > >> > ################# > > >> > > > >> > In anycase it seems that memory allocation problem. How do I figure out > > >> > where it is? "netstat -m" does not seem to point to an error. The mbuf > > >> > info in vmstat -z also look ok. It is only "256 Bucket" in vmstat -z > > >> > that point to an alloc failure. How do I figure out where that is and > > >> > how do I fix it or work around it? > > >> > > > >> > ################### > > >> > tst-11-arm:~ # netstat -m > > >> > 128/382/510 mbufs in use (current/cache/total) > > >> > 127/129/256/7654 mbuf clusters in use (current/cache/total/max) > > >> > 127/126 mbuf+clusters out of packet secondary zone in use (current/cache) > > >> > 0/0/0/3827 4k (page size) jumbo clusters in use (current/cache/total/max) > > >> > 0/0/0/1134 9k jumbo clusters in use (current/cache/total/max) > > >> > 0/0/0/637 16k jumbo clusters in use (current/cache/total/max) > > >> > 286K/353K/639K bytes allocated to network (current/cache/total) > > >> > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > > >> > 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) > > >> > 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) > > >> > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > > >> > 0/3/1488 sfbufs in use (current/peak/max) > > >> > 0 requests for sfbufs denied > > >> > 0 requests for sfbufs delayed > > >> > 0 requests for I/O initiated by sendfile > > >> > tst-11-arm:~ # vmstat -z | grep mbuf > > >> > mbuf_packet: 256, 48990, 127, 126, 2294, 0, 0 > > >> > mbuf: 256, 48990, 1, 256, 920, 0, 0 > > >> > mbuf_cluster: 2048, 7654, 253, 3, 253, 0, 0 > > >> > mbuf_jumbo_page: 4096, 3827, 0, 0, 0, 0, 0 > > >> > mbuf_jumbo_9k: 9216, 1134, 0, 0, 0, 0, 0 > > >> > mbuf_jumbo_16k: 16384, 637, 0, 0, 0, 0, 0 > > >> > mbuf_ext_refcnt: 4, 0, 0, 504, 1, 0, 0 > > >> > tst-11-arm:~ # vmstat -z | grep Bucket > > >> > 4 Bucket: 16, 0, 7, 497, 1565, 0, 0 > > >> > 6 Bucket: 24, 0, 0, 0, 0, 0, 0 > > >> > 8 Bucket: 32, 0, 3, 375, 83, 0, 0 > > >> > 12 Bucket: 48, 0, 2, 334, 5, 0, 0 > > >> > 16 Bucket: 64, 0, 14, 301, 43687, 16, 0 > > >> > 32 Bucket: 128, 0, 7, 148, 196, 0, 0 > > >> > 64 Bucket: 256, 0, 19, 56, 77, 0, 0 > > >> > 128 Bucket: 512, 0, 16, 16, 48, 0, 0 > > >> > 256 Bucket: 1024, 0, 29, 3, 1521,86738, 0 > > >> > tst-11-arm:~ # > > >> > ################### > > >> > > > >> > Regards > > >> > > > >> > John > > >> > -- > > >> > John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za / jhay@FreeBSD.org > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" From owner-freebsd-embedded@FreeBSD.ORG Mon Jul 14 19:23:49 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03D762FE; Mon, 14 Jul 2014 19:23:49 +0000 (UTC) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 909A52A0D; Mon, 14 Jul 2014 19:23:48 +0000 (UTC) Received: by mail-qg0-f45.google.com with SMTP id f51so3796384qge.4 for ; Mon, 14 Jul 2014 12:23:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=YCfhQ9+wcjnPl4MpcAv82V3mB94IHXnMUAdNCqjYzR0=; b=GR71SibUitfzu1ahGiH8PvFOvyOMT3gx94oPxJFqWriWmVQtzrDymS0Q5YNBcuwoP3 WMlQsgNJGwJOkCNJb+DJ8aIh5cgmHrsNkSpiE9nbGbOuiU2IPLTONQf2aTQ03H1FAll+ jfQtZ7vnt329LFSsL9s5EWMuQ5h8oF9jOWxJxE6xB4+v5qrceWP2Ak1+QewfOW7n/3ZQ 4WuGeTb5rpFt6xWAtNRNKZ+guw8lkN71vRs/BX5a9Z5WlEGpE3U5SBwH3C56pfRhlZGD SY6Gpk3SbbQzuXcJ0jtKT6A/7Z6WgtH3kcV9rTvOztZ0n+Ql19BQyCfFrF8AxyFaD8Bf JG5g== MIME-Version: 1.0 X-Received: by 10.224.71.198 with SMTP id i6mr25281287qaj.76.1405365827595; Mon, 14 Jul 2014 12:23:47 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.202.193 with HTTP; Mon, 14 Jul 2014 12:23:47 -0700 (PDT) In-Reply-To: <20140714191416.GB49930@zibbi.meraka.csir.co.za> References: <20140707193252.GA79553@zibbi.meraka.csir.co.za> <20140708165438.GA83704@zibbi.meraka.csir.co.za> <20140709044612.GA51378@zibbi.meraka.csir.co.za> <20140710040227.GA73872@zibbi.meraka.csir.co.za> <20140714080708.GA88464@zibbi.meraka.csir.co.za> <20140714184209.GA21922@zibbi.meraka.csir.co.za> <20140714190946.GA49930@zibbi.meraka.csir.co.za> <20140714191416.GB49930@zibbi.meraka.csir.co.za> Date: Mon, 14 Jul 2014 12:23:47 -0700 X-Google-Sender-Auth: DcSgoqDXjEoZRrWU9gZ3ew9JFJA Message-ID: Subject: Re: CAMBRIA and more than one atheros card From: Adrian Chadd To: John Hay Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-wireless@freebsd.org" , "freebsd-embedded@freebsd.org" , Ian Lepore X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 19:23:49 -0000 Ah, you're going to need more than 64 bounce pages. That's just not enough for all the mbufs the 11n support requires. It likely didn't show up in previous incarnations of this because pre-11n support had a much smaller pool of buffers in use. For doing 11n, there's hm, 256 TX and 256 RX buffers for each NIC? Or is it 512 and 512? It's something large like that. So assuming 512, that's 1024 * 4096 bytes each, so 4mbyte per NIC needed of bounce buffers. You could tweak ATH_TXBUF and ATH_RXBUF down to something like 128 TX and 128 RX, but you can't go much lower than that per NIC as an A-MPDU aggregate requires up to 64 buffers to transmit and/or receive and if you're not careful you'll actually overrun the RX FIFO and/or starve the TX code from having mbufs available to transmit with. -a On 14 July 2014 12:14, John Hay wrote: > On Mon, Jul 14, 2014 at 09:09:46PM +0200, John Hay wrote: >> On Mon, Jul 14, 2014 at 12:06:34PM -0700, Adrian Chadd wrote: >> > .. why's it need bounce buffers? >> >> I found this: >> arm/xscale/ixp425/ixp425_pci.c: /* NB: PCI dma window is 64M so anything above must be bounced */ > > I found a sysctl to show some bounce info. :-) > > On the boot that ath1 and ath2 failed during ifconfig and ath0 started > to complain after a while: > > ##################### > tst-11-arm:~ # sysctl hw.busdma > hw.busdma.total_bpages: 64 > hw.busdma.zone0.total_bpages: 64 > hw.busdma.zone0.free_bpages: 0 > hw.busdma.zone0.reserved_bpages: 0 > hw.busdma.zone0.active_bpages: 64 > hw.busdma.zone0.total_bounced: 1191 > hw.busdma.zone0.total_deferred: 0 > hw.busdma.zone0.lowaddr: 0x4000fff > hw.busdma.zone0.alignment: 4096 > ##################### > > I then thought to down wlan0 to see if the page count changed, but > do not know. :-) > > ##################### > tst-11-arm:~ # ifconfig wlan0 down > dev.ath.0.debug: 0 -> 8 > /sbin/ifconfig.bin wlan0 down > ath0: ath_stop_locked: invalid 0 if_flags 0x8802 > Sleeping thread (tid 100019, pid 0) owns a non-sleepable lock > panic: sleeping thread > Uptime: 32m46s > Automatic reboot in 15 seconds - press a key on the console to abort > Rebooting... > ##################### > > John > >> >> John >> > >> > >> > -a >> > >> > >> > On 14 July 2014 11:42, John Hay wrote: >> > > On Mon, Jul 14, 2014 at 09:48:56AM -0700, Adrian Chadd wrote: >> > >> Hm, it could be some bus related stupidity. It's allocating 2k or 4k >> > >> mbufs for the receive path because wifi frames are bigger than >> > >> ethernet frames. If you're not seeing failures in 4k mbuf allocations >> > >> then I'm not sure what it could be. >> > >> >> > >> I'll see about firing it up locally and checking. >> > > >> > > I'm hunting a bit more and it looks like the fail is in the bounce pages. >> > > It looks like the calls look like this: >> > > >> > > ath_legacy_rxbuf_init() >> > > bus_dmamap_load_mbuf_sg() >> > > _bus_dmamap_load_buffer() >> > > _bus_dmamap_reserve_pages() >> > > reserve_bounce_pages() >> > > >> > > I have added a printf at the start of alloc_bounce_pages() and it seems >> > > that it is only called (twice) when ath0 is probed. Is bus_dma_tag_t dmat, >> > > the first argument to alloc_bounce_pages(), common for the whole pci bus? >> > > >> > > The start of the boot, with my printf looks like this: >> > > >> > > #################### >> > > FreeBSD ARM (Gateworks Cambria) boot2 v0.4 >> > > - >> > > Default: /boot/kernel/kernel >> > > boot: >> > > Copyright (c) 1992-2014 The FreeBSD Project. >> > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >> > > The Regents of the University of California. All rights reserved. >> > > FreeBSD is a registered trademark of The FreeBSD Foundation. >> > > FreeBSD 11.0-CURRENT #9 r268502M: Mon Jul 14 15:30:15 SAST 2014 >> > > jhay@dolphin.meraka.csir.co.za:/usr/obj/arm.armeb/snaps/arm/11-tst/src/sys/S >> > > MALL-CAMBRIA arm >> > > gcc version 4.2.1 20070831 patched [FreeBSD] >> > > CPU: IXP435 rev 1 (ARMv5TE) (XScale core) >> > > Big-endian DC enabled IC enabled WB enabled LABT branch prediction enabled >> > > 32KB/32B 32-way instruction cache >> > > 32KB/32B 32-way write-back-locking data cache >> > > real memory = 134213632 (127 MB) >> > > avail memory = 124440576 (118 MB) >> > > random device not loaded; using insecure entropy >> > > wlan: mac acl policy registered >> > > random: initialized >> > > ixp0: >> > > ixp0: 37e7f >> > > pcib0: on ixp0 >> > > pci0: on pcib0 >> > > ath0: irq 28 at device 1.0 on pci0 >> > > alloc_bounce_pages: numpages 63 >> > > [ath] enabling AN_TOP2_FIXUP >> > > alloc_bounce_pages: numpages 1 >> > > ath0: AR9220 mac 128.2 RF5133 phy 13.0 >> > > ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 >> > > ath1: irq 27 at device 2.0 on pci0 >> > > [ath] enabling AN_TOP2_FIXUP >> > > ath1: AR9220 mac 128.2 RF5133 phy 13.0 >> > > ath1: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 >> > > ath2: irq 26 at device 3.0 on pci0 >> > > ath2: AR5413 mac 10.5 RF5413 phy 6.1 >> > > ath2: 2GHz radio: 0x0000; 5GHz radio: 0x0063 >> > > ixpclk0: on ixp0 >> > > #################### >> > > >> > > Interesting, with this boot, with the new kernel, the aths did not fail. >> > > Could the printf have changed something or was it just coincidence? With >> > > a reboot ath1 and ath2 failed again during configuration and a little >> > > while later ath0 started to complain: >> > > >> > > ath0: ath_rx_proc: no mbuf! >> > > >> > > John >> > > >> > >> >> > >> >> > >> >> > >> >> > >> -a >> > >> >> > >> On 14 July 2014 01:07, John Hay wrote: >> > >> > On Thu, Jul 10, 2014 at 06:02:27AM +0200, John Hay wrote: >> > >> >> On Wed, Jul 09, 2014 at 06:46:12AM +0200, John Hay wrote: >> > >> >> > Hi Guys, >> > >> >> > >> > >> >> > The problem is back / still there. I initially saw the problem during >> > >> >> > boot, with the interface configs in rc.conf, but because it is so >> > >> >> > mixed with the rest, I took it out and put it in the script, then >> > >> >> > after multi-user boot was finished, I did a login and ran the script, >> > >> >> > with the output I showed in the initial post. >> > >> >> > >> > >> >> > So I put the interface configs back into rc.conf and I'm seeing the >> > >> >> > same problem, here is a cut during boot: >> > >> >> > >> > >> >> > ############### >> > >> >> > Starting file system checks: >> > >> >> > /dev/ad0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS >> > >> >> > /dev/ad0s1a: clean, 93385 free (33 frags, 11669 blocks, 0.0% fragmentation) >> > >> >> > Mounting local file systems:. >> > >> >> > Writing entropy file:. >> > >> >> > Setting hostname: tst-cambria-11. >> > >> >> > wlan0: Ethernet address: 00:21:a4:35:70:42 >> > >> >> > wlan1: Ethernet address: 00:21:a4:35:6c:96 >> > >> >> > ath1: unable to start recv logic >> > >> >> > wlan2: Ethernet address: 00:21:a4:32:38:c2 >> > >> >> > ath2: unable to start recv logic >> > >> >> > ############### >> > >> >> > >> > >> >> > Looking at the vmstat -z output the 256 Bucket fail is much higher than >> > >> >> > if I let it boot to multiuser and then configured the interfaces. It >> > >> >> > was in the 6000, while now it is much higher: >> > >> >> > >> > >> >> > Without wlan configs in rc.conf, but configured afterwards: >> > >> >> > 16 Bucket: 64, 0, 15, 300, 3139, 16, 0 >> > >> >> > 256 Bucket: 1024, 0, 31, 1, 592,6062, 0 >> > >> >> > vmem btag: 28, 0, 4496, 256, 4496, 32, 0 >> > >> >> > >> > >> >> > With wlan configs in rc.conf: >> > >> >> > 16 Bucket: 64, 0, 16, 299, 8611, 16, 0 >> > >> >> > 256 Bucket: 1024, 0, 26, 6, 773,16928, 0 >> > >> >> > vmem btag: 28, 0, 4405, 59, 4405, 30, 0 >> > >> >> > >> > >> >> > Both of them boot from a ro compact-flash with md /etc and /var, but >> > >> >> > they are small 4.3M and 2.1M. I have hacked in the use of tmpfs, but >> > >> >> > that did not make a difference. >> > >> >> > >> > >> > >> > >> > Friday I power cycled the board and it came up without an error. All 3 >> > >> > atheros cards configured in rc.conf. So I left it on for the weekend >> > >> > and by this morning there was still no errors, so I rebooted it and >> > >> > again saw the "ath1: unable to start recv logic" message for ath1 and >> > >> > ath2. I power cycled it, but still get the error, so Friday was just >> > >> > lucky with some timing thing, maybe if the card receive while it is >> > >> > still configuring? Also if I leave the board booted in this state, >> > >> > ath0 also start to give problems: >> > >> > >> > >> > ################# >> > >> > ath0: ath_rx_proc: no mbuf! >> > >> > ath0: ath_rx_proc: no mbuf! >> > >> > ... >> > >> > ath0: device timeout >> > >> > ath0: ath_reset: unable to start recv logic >> > >> > ... >> > >> > ################# >> > >> > >> > >> > In anycase it seems that memory allocation problem. How do I figure out >> > >> > where it is? "netstat -m" does not seem to point to an error. The mbuf >> > >> > info in vmstat -z also look ok. It is only "256 Bucket" in vmstat -z >> > >> > that point to an alloc failure. How do I figure out where that is and >> > >> > how do I fix it or work around it? >> > >> > >> > >> > ################### >> > >> > tst-11-arm:~ # netstat -m >> > >> > 128/382/510 mbufs in use (current/cache/total) >> > >> > 127/129/256/7654 mbuf clusters in use (current/cache/total/max) >> > >> > 127/126 mbuf+clusters out of packet secondary zone in use (current/cache) >> > >> > 0/0/0/3827 4k (page size) jumbo clusters in use (current/cache/total/max) >> > >> > 0/0/0/1134 9k jumbo clusters in use (current/cache/total/max) >> > >> > 0/0/0/637 16k jumbo clusters in use (current/cache/total/max) >> > >> > 286K/353K/639K bytes allocated to network (current/cache/total) >> > >> > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) >> > >> > 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) >> > >> > 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) >> > >> > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) >> > >> > 0/3/1488 sfbufs in use (current/peak/max) >> > >> > 0 requests for sfbufs denied >> > >> > 0 requests for sfbufs delayed >> > >> > 0 requests for I/O initiated by sendfile >> > >> > tst-11-arm:~ # vmstat -z | grep mbuf >> > >> > mbuf_packet: 256, 48990, 127, 126, 2294, 0, 0 >> > >> > mbuf: 256, 48990, 1, 256, 920, 0, 0 >> > >> > mbuf_cluster: 2048, 7654, 253, 3, 253, 0, 0 >> > >> > mbuf_jumbo_page: 4096, 3827, 0, 0, 0, 0, 0 >> > >> > mbuf_jumbo_9k: 9216, 1134, 0, 0, 0, 0, 0 >> > >> > mbuf_jumbo_16k: 16384, 637, 0, 0, 0, 0, 0 >> > >> > mbuf_ext_refcnt: 4, 0, 0, 504, 1, 0, 0 >> > >> > tst-11-arm:~ # vmstat -z | grep Bucket >> > >> > 4 Bucket: 16, 0, 7, 497, 1565, 0, 0 >> > >> > 6 Bucket: 24, 0, 0, 0, 0, 0, 0 >> > >> > 8 Bucket: 32, 0, 3, 375, 83, 0, 0 >> > >> > 12 Bucket: 48, 0, 2, 334, 5, 0, 0 >> > >> > 16 Bucket: 64, 0, 14, 301, 43687, 16, 0 >> > >> > 32 Bucket: 128, 0, 7, 148, 196, 0, 0 >> > >> > 64 Bucket: 256, 0, 19, 56, 77, 0, 0 >> > >> > 128 Bucket: 512, 0, 16, 16, 48, 0, 0 >> > >> > 256 Bucket: 1024, 0, 29, 3, 1521,86738, 0 >> > >> > tst-11-arm:~ # >> > >> > ################### >> > >> > >> > >> > Regards >> > >> > >> > >> > John >> > >> > -- >> > >> > John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za / jhay@FreeBSD.org >> _______________________________________________ >> freebsd-wireless@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-wireless >> To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" From owner-freebsd-embedded@FreeBSD.ORG Mon Jul 14 19:49:35 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C5932A1D; Mon, 14 Jul 2014 19:49:35 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7C4A62BFC; Mon, 14 Jul 2014 19:49:34 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id E5EADB842; Mon, 14 Jul 2014 21:49:32 +0200 (SAST) Date: Mon, 14 Jul 2014 21:49:32 +0200 From: John Hay To: Adrian Chadd Subject: Re: CAMBRIA and more than one atheros card Message-ID: <20140714194932.GA51947@zibbi.meraka.csir.co.za> References: <20140708165438.GA83704@zibbi.meraka.csir.co.za> <20140709044612.GA51378@zibbi.meraka.csir.co.za> <20140710040227.GA73872@zibbi.meraka.csir.co.za> <20140714080708.GA88464@zibbi.meraka.csir.co.za> <20140714184209.GA21922@zibbi.meraka.csir.co.za> <20140714190946.GA49930@zibbi.meraka.csir.co.za> <20140714191416.GB49930@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-wireless@freebsd.org" , "freebsd-embedded@freebsd.org" , Ian Lepore X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 19:49:36 -0000 On Mon, Jul 14, 2014 at 12:23:47PM -0700, Adrian Chadd wrote: > Ah, you're going to need more than 64 bounce pages. That's just not > enough for all the mbufs the 11n support requires. > > It likely didn't show up in previous incarnations of this because > pre-11n support had a much smaller pool of buffers in use. > > For doing 11n, there's hm, 256 TX and 256 RX buffers for each NIC? Or > is it 512 and 512? It's something large like that. So assuming 512, > that's 1024 * 4096 bytes each, so 4mbyte per NIC needed of bounce > buffers. > > You could tweak ATH_TXBUF and ATH_RXBUF down to something like 128 TX > and 128 RX, but you can't go much lower than that per NIC as an A-MPDU > aggregate requires up to 64 buffers to transmit and/or receive and if > you're not careful you'll actually overrun the RX FIFO and/or starve > the TX code from having mbufs available to transmit with. I don't mind up the bounce buffers, if that will help. I'll see how high I can go before it explode. :-) I guess one cannot easily use the RAM above 64M for ram disks and code and then not bouncing at all. :-/ I just had an ok boot, ie. all 3 aths came up without an error. So just after a login, the bounce stats looked like this: tst-11-arm:~ # sysctl hw.busdma hw.busdma.total_bpages: 64 hw.busdma.zone0.total_bpages: 64 hw.busdma.zone0.free_bpages: 57 hw.busdma.zone0.reserved_bpages: 0 hw.busdma.zone0.active_bpages: 7 hw.busdma.zone0.total_bounced: 525 hw.busdma.zone0.total_deferred: 0 hw.busdma.zone0.lowaddr: 0x4000fff hw.busdma.zone0.alignment: 4096 The usage seems to slowly climb though. After 30 minutes it looks like this: tst-11-arm:~ # sysctl hw.busdma hw.busdma.total_bpages: 64 hw.busdma.zone0.total_bpages: 64 hw.busdma.zone0.free_bpages: 43 hw.busdma.zone0.reserved_bpages: 0 hw.busdma.zone0.active_bpages: 21 hw.busdma.zone0.total_bounced: 4713 hw.busdma.zone0.total_deferred: 0 hw.busdma.zone0.lowaddr: 0x4000fff hw.busdma.zone0.alignment: 4096 The board is pretty idle, with no routing daemon or traffic except for the occasional broadcast and multicasts that arrive. John > > > -a > > > On 14 July 2014 12:14, John Hay wrote: > > On Mon, Jul 14, 2014 at 09:09:46PM +0200, John Hay wrote: > >> On Mon, Jul 14, 2014 at 12:06:34PM -0700, Adrian Chadd wrote: > >> > .. why's it need bounce buffers? > >> > >> I found this: > >> arm/xscale/ixp425/ixp425_pci.c: /* NB: PCI dma window is 64M so anything above must be bounced */ > > > > I found a sysctl to show some bounce info. :-) > > > > On the boot that ath1 and ath2 failed during ifconfig and ath0 started > > to complain after a while: > > > > ##################### > > tst-11-arm:~ # sysctl hw.busdma > > hw.busdma.total_bpages: 64 > > hw.busdma.zone0.total_bpages: 64 > > hw.busdma.zone0.free_bpages: 0 > > hw.busdma.zone0.reserved_bpages: 0 > > hw.busdma.zone0.active_bpages: 64 > > hw.busdma.zone0.total_bounced: 1191 > > hw.busdma.zone0.total_deferred: 0 > > hw.busdma.zone0.lowaddr: 0x4000fff > > hw.busdma.zone0.alignment: 4096 > > ##################### > > > > I then thought to down wlan0 to see if the page count changed, but > > do not know. :-) > > > > ##################### > > tst-11-arm:~ # ifconfig wlan0 down > > dev.ath.0.debug: 0 -> 8 > > /sbin/ifconfig.bin wlan0 down > > ath0: ath_stop_locked: invalid 0 if_flags 0x8802 > > Sleeping thread (tid 100019, pid 0) owns a non-sleepable lock > > panic: sleeping thread > > Uptime: 32m46s > > Automatic reboot in 15 seconds - press a key on the console to abort > > Rebooting... > > ##################### > > > > John > > > >> > >> John > >> > > >> > > >> > -a > >> > > >> > > >> > On 14 July 2014 11:42, John Hay wrote: > >> > > On Mon, Jul 14, 2014 at 09:48:56AM -0700, Adrian Chadd wrote: > >> > >> Hm, it could be some bus related stupidity. It's allocating 2k or 4k > >> > >> mbufs for the receive path because wifi frames are bigger than > >> > >> ethernet frames. If you're not seeing failures in 4k mbuf allocations > >> > >> then I'm not sure what it could be. > >> > >> > >> > >> I'll see about firing it up locally and checking. > >> > > > >> > > I'm hunting a bit more and it looks like the fail is in the bounce pages. > >> > > It looks like the calls look like this: > >> > > > >> > > ath_legacy_rxbuf_init() > >> > > bus_dmamap_load_mbuf_sg() > >> > > _bus_dmamap_load_buffer() > >> > > _bus_dmamap_reserve_pages() > >> > > reserve_bounce_pages() > >> > > > >> > > I have added a printf at the start of alloc_bounce_pages() and it seems > >> > > that it is only called (twice) when ath0 is probed. Is bus_dma_tag_t dmat, > >> > > the first argument to alloc_bounce_pages(), common for the whole pci bus? > >> > > > >> > > The start of the boot, with my printf looks like this: > >> > > > >> > > #################### > >> > > FreeBSD ARM (Gateworks Cambria) boot2 v0.4 > >> > > - > >> > > Default: /boot/kernel/kernel > >> > > boot: > >> > > Copyright (c) 1992-2014 The FreeBSD Project. > >> > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > >> > > The Regents of the University of California. All rights reserved. > >> > > FreeBSD is a registered trademark of The FreeBSD Foundation. > >> > > FreeBSD 11.0-CURRENT #9 r268502M: Mon Jul 14 15:30:15 SAST 2014 > >> > > jhay@dolphin.meraka.csir.co.za:/usr/obj/arm.armeb/snaps/arm/11-tst/src/sys/S > >> > > MALL-CAMBRIA arm > >> > > gcc version 4.2.1 20070831 patched [FreeBSD] > >> > > CPU: IXP435 rev 1 (ARMv5TE) (XScale core) > >> > > Big-endian DC enabled IC enabled WB enabled LABT branch prediction enabled > >> > > 32KB/32B 32-way instruction cache > >> > > 32KB/32B 32-way write-back-locking data cache > >> > > real memory = 134213632 (127 MB) > >> > > avail memory = 124440576 (118 MB) > >> > > random device not loaded; using insecure entropy > >> > > wlan: mac acl policy registered > >> > > random: initialized > >> > > ixp0: > >> > > ixp0: 37e7f > >> > > pcib0: on ixp0 > >> > > pci0: on pcib0 > >> > > ath0: irq 28 at device 1.0 on pci0 > >> > > alloc_bounce_pages: numpages 63 > >> > > [ath] enabling AN_TOP2_FIXUP > >> > > alloc_bounce_pages: numpages 1 > >> > > ath0: AR9220 mac 128.2 RF5133 phy 13.0 > >> > > ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 > >> > > ath1: irq 27 at device 2.0 on pci0 > >> > > [ath] enabling AN_TOP2_FIXUP > >> > > ath1: AR9220 mac 128.2 RF5133 phy 13.0 > >> > > ath1: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 > >> > > ath2: irq 26 at device 3.0 on pci0 > >> > > ath2: AR5413 mac 10.5 RF5413 phy 6.1 > >> > > ath2: 2GHz radio: 0x0000; 5GHz radio: 0x0063 > >> > > ixpclk0: on ixp0 > >> > > #################### > >> > > > >> > > Interesting, with this boot, with the new kernel, the aths did not fail. > >> > > Could the printf have changed something or was it just coincidence? With > >> > > a reboot ath1 and ath2 failed again during configuration and a little > >> > > while later ath0 started to complain: > >> > > > >> > > ath0: ath_rx_proc: no mbuf! > >> > > > >> > > John > >> > > > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> -a > >> > >> > >> > >> On 14 July 2014 01:07, John Hay wrote: > >> > >> > On Thu, Jul 10, 2014 at 06:02:27AM +0200, John Hay wrote: > >> > >> >> On Wed, Jul 09, 2014 at 06:46:12AM +0200, John Hay wrote: > >> > >> >> > Hi Guys, > >> > >> >> > > >> > >> >> > The problem is back / still there. I initially saw the problem during > >> > >> >> > boot, with the interface configs in rc.conf, but because it is so > >> > >> >> > mixed with the rest, I took it out and put it in the script, then > >> > >> >> > after multi-user boot was finished, I did a login and ran the script, > >> > >> >> > with the output I showed in the initial post. > >> > >> >> > > >> > >> >> > So I put the interface configs back into rc.conf and I'm seeing the > >> > >> >> > same problem, here is a cut during boot: > >> > >> >> > > >> > >> >> > ############### > >> > >> >> > Starting file system checks: > >> > >> >> > /dev/ad0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS > >> > >> >> > /dev/ad0s1a: clean, 93385 free (33 frags, 11669 blocks, 0.0% fragmentation) > >> > >> >> > Mounting local file systems:. > >> > >> >> > Writing entropy file:. > >> > >> >> > Setting hostname: tst-cambria-11. > >> > >> >> > wlan0: Ethernet address: 00:21:a4:35:70:42 > >> > >> >> > wlan1: Ethernet address: 00:21:a4:35:6c:96 > >> > >> >> > ath1: unable to start recv logic > >> > >> >> > wlan2: Ethernet address: 00:21:a4:32:38:c2 > >> > >> >> > ath2: unable to start recv logic > >> > >> >> > ############### > >> > >> >> > > >> > >> >> > Looking at the vmstat -z output the 256 Bucket fail is much higher than > >> > >> >> > if I let it boot to multiuser and then configured the interfaces. It > >> > >> >> > was in the 6000, while now it is much higher: > >> > >> >> > > >> > >> >> > Without wlan configs in rc.conf, but configured afterwards: > >> > >> >> > 16 Bucket: 64, 0, 15, 300, 3139, 16, 0 > >> > >> >> > 256 Bucket: 1024, 0, 31, 1, 592,6062, 0 > >> > >> >> > vmem btag: 28, 0, 4496, 256, 4496, 32, 0 > >> > >> >> > > >> > >> >> > With wlan configs in rc.conf: > >> > >> >> > 16 Bucket: 64, 0, 16, 299, 8611, 16, 0 > >> > >> >> > 256 Bucket: 1024, 0, 26, 6, 773,16928, 0 > >> > >> >> > vmem btag: 28, 0, 4405, 59, 4405, 30, 0 > >> > >> >> > > >> > >> >> > Both of them boot from a ro compact-flash with md /etc and /var, but > >> > >> >> > they are small 4.3M and 2.1M. I have hacked in the use of tmpfs, but > >> > >> >> > that did not make a difference. > >> > >> >> > > >> > >> > > >> > >> > Friday I power cycled the board and it came up without an error. All 3 > >> > >> > atheros cards configured in rc.conf. So I left it on for the weekend > >> > >> > and by this morning there was still no errors, so I rebooted it and > >> > >> > again saw the "ath1: unable to start recv logic" message for ath1 and > >> > >> > ath2. I power cycled it, but still get the error, so Friday was just > >> > >> > lucky with some timing thing, maybe if the card receive while it is > >> > >> > still configuring? Also if I leave the board booted in this state, > >> > >> > ath0 also start to give problems: > >> > >> > > >> > >> > ################# > >> > >> > ath0: ath_rx_proc: no mbuf! > >> > >> > ath0: ath_rx_proc: no mbuf! > >> > >> > ... > >> > >> > ath0: device timeout > >> > >> > ath0: ath_reset: unable to start recv logic > >> > >> > ... > >> > >> > ################# > >> > >> > > >> > >> > In anycase it seems that memory allocation problem. How do I figure out > >> > >> > where it is? "netstat -m" does not seem to point to an error. The mbuf > >> > >> > info in vmstat -z also look ok. It is only "256 Bucket" in vmstat -z > >> > >> > that point to an alloc failure. How do I figure out where that is and > >> > >> > how do I fix it or work around it? > >> > >> > > >> > >> > ################### > >> > >> > tst-11-arm:~ # netstat -m > >> > >> > 128/382/510 mbufs in use (current/cache/total) > >> > >> > 127/129/256/7654 mbuf clusters in use (current/cache/total/max) > >> > >> > 127/126 mbuf+clusters out of packet secondary zone in use (current/cache) > >> > >> > 0/0/0/3827 4k (page size) jumbo clusters in use (current/cache/total/max) > >> > >> > 0/0/0/1134 9k jumbo clusters in use (current/cache/total/max) > >> > >> > 0/0/0/637 16k jumbo clusters in use (current/cache/total/max) > >> > >> > 286K/353K/639K bytes allocated to network (current/cache/total) > >> > >> > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > >> > >> > 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) > >> > >> > 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) > >> > >> > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > >> > >> > 0/3/1488 sfbufs in use (current/peak/max) > >> > >> > 0 requests for sfbufs denied > >> > >> > 0 requests for sfbufs delayed > >> > >> > 0 requests for I/O initiated by sendfile > >> > >> > tst-11-arm:~ # vmstat -z | grep mbuf > >> > >> > mbuf_packet: 256, 48990, 127, 126, 2294, 0, 0 > >> > >> > mbuf: 256, 48990, 1, 256, 920, 0, 0 > >> > >> > mbuf_cluster: 2048, 7654, 253, 3, 253, 0, 0 > >> > >> > mbuf_jumbo_page: 4096, 3827, 0, 0, 0, 0, 0 > >> > >> > mbuf_jumbo_9k: 9216, 1134, 0, 0, 0, 0, 0 > >> > >> > mbuf_jumbo_16k: 16384, 637, 0, 0, 0, 0, 0 > >> > >> > mbuf_ext_refcnt: 4, 0, 0, 504, 1, 0, 0 > >> > >> > tst-11-arm:~ # vmstat -z | grep Bucket > >> > >> > 4 Bucket: 16, 0, 7, 497, 1565, 0, 0 > >> > >> > 6 Bucket: 24, 0, 0, 0, 0, 0, 0 > >> > >> > 8 Bucket: 32, 0, 3, 375, 83, 0, 0 > >> > >> > 12 Bucket: 48, 0, 2, 334, 5, 0, 0 > >> > >> > 16 Bucket: 64, 0, 14, 301, 43687, 16, 0 > >> > >> > 32 Bucket: 128, 0, 7, 148, 196, 0, 0 > >> > >> > 64 Bucket: 256, 0, 19, 56, 77, 0, 0 > >> > >> > 128 Bucket: 512, 0, 16, 16, 48, 0, 0 > >> > >> > 256 Bucket: 1024, 0, 29, 3, 1521,86738, 0 > >> > >> > tst-11-arm:~ # > >> > >> > ################### > >> > >> > > >> > >> > Regards > >> > >> > > >> > >> > John > >> > >> > -- > >> > >> > John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za / jhay@FreeBSD.org > >> _______________________________________________ > >> freebsd-wireless@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-wireless > >> To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" From owner-freebsd-embedded@FreeBSD.ORG Mon Jul 14 19:55:20 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 78BA7AB8; Mon, 14 Jul 2014 19:55:20 +0000 (UTC) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 112FF2C94; Mon, 14 Jul 2014 19:55:20 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id j7so3046579qaq.14 for ; Mon, 14 Jul 2014 12:55:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Twoig2LCFUVsGqc/gfRFb7hex0qgBtuQIt9AMUprsFI=; b=l/ZIF+ftwjDzWdSJdaAtrCFLhKQorsT7K9xK0ZRlU25OxHu7+fZ+nryaUvGY9vGZ/q zeo4erKcD/EDlV0SMmiOVOArcAkirRwQ0QJVG19KHyomTXa9WK5Li9OaniIkx0pVcPJM c8H9+rp8y8L8ctmQRzUFQy+jKLLLDg0axwJwmBrUK1wK2uPtY0Wol6n4QKStzZWpcykp e8MmpUlrV84u87hi60H0ekAnra/DxLRqKbvCCYm+gtEDeiMtZdVqM+RJlC3J8r4E9BEi MR87TAxx4J1Q8GLnw00fMhyvQJMN09mKS9YFp39VifLmeX44ftuNT2nGNahI0nzY/tsG /xmw== MIME-Version: 1.0 X-Received: by 10.140.80.19 with SMTP id b19mr26900617qgd.102.1405367719244; Mon, 14 Jul 2014 12:55:19 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.202.193 with HTTP; Mon, 14 Jul 2014 12:55:19 -0700 (PDT) In-Reply-To: <20140714194932.GA51947@zibbi.meraka.csir.co.za> References: <20140708165438.GA83704@zibbi.meraka.csir.co.za> <20140709044612.GA51378@zibbi.meraka.csir.co.za> <20140710040227.GA73872@zibbi.meraka.csir.co.za> <20140714080708.GA88464@zibbi.meraka.csir.co.za> <20140714184209.GA21922@zibbi.meraka.csir.co.za> <20140714190946.GA49930@zibbi.meraka.csir.co.za> <20140714191416.GB49930@zibbi.meraka.csir.co.za> <20140714194932.GA51947@zibbi.meraka.csir.co.za> Date: Mon, 14 Jul 2014 12:55:19 -0700 X-Google-Sender-Auth: gyHjRAXOSsMZ7UJwmRvEyu8VhBk Message-ID: Subject: Re: CAMBRIA and more than one atheros card From: Adrian Chadd To: John Hay Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-wireless@freebsd.org" , "freebsd-embedded@freebsd.org" , Ian Lepore X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 19:55:20 -0000 Right. What's the output of hw.ath ? -a On 14 July 2014 12:49, John Hay wrote: > On Mon, Jul 14, 2014 at 12:23:47PM -0700, Adrian Chadd wrote: >> Ah, you're going to need more than 64 bounce pages. That's just not >> enough for all the mbufs the 11n support requires. >> >> It likely didn't show up in previous incarnations of this because >> pre-11n support had a much smaller pool of buffers in use. >> >> For doing 11n, there's hm, 256 TX and 256 RX buffers for each NIC? Or >> is it 512 and 512? It's something large like that. So assuming 512, >> that's 1024 * 4096 bytes each, so 4mbyte per NIC needed of bounce >> buffers. >> >> You could tweak ATH_TXBUF and ATH_RXBUF down to something like 128 TX >> and 128 RX, but you can't go much lower than that per NIC as an A-MPDU >> aggregate requires up to 64 buffers to transmit and/or receive and if >> you're not careful you'll actually overrun the RX FIFO and/or starve >> the TX code from having mbufs available to transmit with. > > I don't mind up the bounce buffers, if that will help. I'll see how > high I can go before it explode. :-) I guess one cannot easily use > the RAM above 64M for ram disks and code and then not bouncing at > all. :-/ > > I just had an ok boot, ie. all 3 aths came up without an error. So > just after a login, the bounce stats looked like this: > > tst-11-arm:~ # sysctl hw.busdma > hw.busdma.total_bpages: 64 > hw.busdma.zone0.total_bpages: 64 > hw.busdma.zone0.free_bpages: 57 > hw.busdma.zone0.reserved_bpages: 0 > hw.busdma.zone0.active_bpages: 7 > hw.busdma.zone0.total_bounced: 525 > hw.busdma.zone0.total_deferred: 0 > hw.busdma.zone0.lowaddr: 0x4000fff > hw.busdma.zone0.alignment: 4096 > > The usage seems to slowly climb though. After 30 minutes it looks like > this: > > tst-11-arm:~ # sysctl hw.busdma > hw.busdma.total_bpages: 64 > hw.busdma.zone0.total_bpages: 64 > hw.busdma.zone0.free_bpages: 43 > hw.busdma.zone0.reserved_bpages: 0 > hw.busdma.zone0.active_bpages: 21 > hw.busdma.zone0.total_bounced: 4713 > hw.busdma.zone0.total_deferred: 0 > hw.busdma.zone0.lowaddr: 0x4000fff > hw.busdma.zone0.alignment: 4096 > > The board is pretty idle, with no routing daemon or traffic except for > the occasional broadcast and multicasts that arrive. > > John > >> >> >> -a >> >> >> On 14 July 2014 12:14, John Hay wrote: >> > On Mon, Jul 14, 2014 at 09:09:46PM +0200, John Hay wrote: >> >> On Mon, Jul 14, 2014 at 12:06:34PM -0700, Adrian Chadd wrote: >> >> > .. why's it need bounce buffers? >> >> >> >> I found this: >> >> arm/xscale/ixp425/ixp425_pci.c: /* NB: PCI dma window is 64M so anything above must be bounced */ >> > >> > I found a sysctl to show some bounce info. :-) >> > >> > On the boot that ath1 and ath2 failed during ifconfig and ath0 started >> > to complain after a while: >> > >> > ##################### >> > tst-11-arm:~ # sysctl hw.busdma >> > hw.busdma.total_bpages: 64 >> > hw.busdma.zone0.total_bpages: 64 >> > hw.busdma.zone0.free_bpages: 0 >> > hw.busdma.zone0.reserved_bpages: 0 >> > hw.busdma.zone0.active_bpages: 64 >> > hw.busdma.zone0.total_bounced: 1191 >> > hw.busdma.zone0.total_deferred: 0 >> > hw.busdma.zone0.lowaddr: 0x4000fff >> > hw.busdma.zone0.alignment: 4096 >> > ##################### >> > >> > I then thought to down wlan0 to see if the page count changed, but >> > do not know. :-) >> > >> > ##################### >> > tst-11-arm:~ # ifconfig wlan0 down >> > dev.ath.0.debug: 0 -> 8 >> > /sbin/ifconfig.bin wlan0 down >> > ath0: ath_stop_locked: invalid 0 if_flags 0x8802 >> > Sleeping thread (tid 100019, pid 0) owns a non-sleepable lock >> > panic: sleeping thread >> > Uptime: 32m46s >> > Automatic reboot in 15 seconds - press a key on the console to abort >> > Rebooting... >> > ##################### >> > >> > John >> > >> >> >> >> John >> >> > >> >> > >> >> > -a >> >> > >> >> > >> >> > On 14 July 2014 11:42, John Hay wrote: >> >> > > On Mon, Jul 14, 2014 at 09:48:56AM -0700, Adrian Chadd wrote: >> >> > >> Hm, it could be some bus related stupidity. It's allocating 2k or 4k >> >> > >> mbufs for the receive path because wifi frames are bigger than >> >> > >> ethernet frames. If you're not seeing failures in 4k mbuf allocations >> >> > >> then I'm not sure what it could be. >> >> > >> >> >> > >> I'll see about firing it up locally and checking. >> >> > > >> >> > > I'm hunting a bit more and it looks like the fail is in the bounce pages. >> >> > > It looks like the calls look like this: >> >> > > >> >> > > ath_legacy_rxbuf_init() >> >> > > bus_dmamap_load_mbuf_sg() >> >> > > _bus_dmamap_load_buffer() >> >> > > _bus_dmamap_reserve_pages() >> >> > > reserve_bounce_pages() >> >> > > >> >> > > I have added a printf at the start of alloc_bounce_pages() and it seems >> >> > > that it is only called (twice) when ath0 is probed. Is bus_dma_tag_t dmat, >> >> > > the first argument to alloc_bounce_pages(), common for the whole pci bus? >> >> > > >> >> > > The start of the boot, with my printf looks like this: >> >> > > >> >> > > #################### >> >> > > FreeBSD ARM (Gateworks Cambria) boot2 v0.4 >> >> > > - >> >> > > Default: /boot/kernel/kernel >> >> > > boot: >> >> > > Copyright (c) 1992-2014 The FreeBSD Project. >> >> > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >> >> > > The Regents of the University of California. All rights reserved. >> >> > > FreeBSD is a registered trademark of The FreeBSD Foundation. >> >> > > FreeBSD 11.0-CURRENT #9 r268502M: Mon Jul 14 15:30:15 SAST 2014 >> >> > > jhay@dolphin.meraka.csir.co.za:/usr/obj/arm.armeb/snaps/arm/11-tst/src/sys/S >> >> > > MALL-CAMBRIA arm >> >> > > gcc version 4.2.1 20070831 patched [FreeBSD] >> >> > > CPU: IXP435 rev 1 (ARMv5TE) (XScale core) >> >> > > Big-endian DC enabled IC enabled WB enabled LABT branch prediction enabled >> >> > > 32KB/32B 32-way instruction cache >> >> > > 32KB/32B 32-way write-back-locking data cache >> >> > > real memory = 134213632 (127 MB) >> >> > > avail memory = 124440576 (118 MB) >> >> > > random device not loaded; using insecure entropy >> >> > > wlan: mac acl policy registered >> >> > > random: initialized >> >> > > ixp0: >> >> > > ixp0: 37e7f >> >> > > pcib0: on ixp0 >> >> > > pci0: on pcib0 >> >> > > ath0: irq 28 at device 1.0 on pci0 >> >> > > alloc_bounce_pages: numpages 63 >> >> > > [ath] enabling AN_TOP2_FIXUP >> >> > > alloc_bounce_pages: numpages 1 >> >> > > ath0: AR9220 mac 128.2 RF5133 phy 13.0 >> >> > > ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 >> >> > > ath1: irq 27 at device 2.0 on pci0 >> >> > > [ath] enabling AN_TOP2_FIXUP >> >> > > ath1: AR9220 mac 128.2 RF5133 phy 13.0 >> >> > > ath1: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 >> >> > > ath2: irq 26 at device 3.0 on pci0 >> >> > > ath2: AR5413 mac 10.5 RF5413 phy 6.1 >> >> > > ath2: 2GHz radio: 0x0000; 5GHz radio: 0x0063 >> >> > > ixpclk0: on ixp0 >> >> > > #################### >> >> > > >> >> > > Interesting, with this boot, with the new kernel, the aths did not fail. >> >> > > Could the printf have changed something or was it just coincidence? With >> >> > > a reboot ath1 and ath2 failed again during configuration and a little >> >> > > while later ath0 started to complain: >> >> > > >> >> > > ath0: ath_rx_proc: no mbuf! >> >> > > >> >> > > John >> >> > > >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> -a >> >> > >> >> >> > >> On 14 July 2014 01:07, John Hay wrote: >> >> > >> > On Thu, Jul 10, 2014 at 06:02:27AM +0200, John Hay wrote: >> >> > >> >> On Wed, Jul 09, 2014 at 06:46:12AM +0200, John Hay wrote: >> >> > >> >> > Hi Guys, >> >> > >> >> > >> >> > >> >> > The problem is back / still there. I initially saw the problem during >> >> > >> >> > boot, with the interface configs in rc.conf, but because it is so >> >> > >> >> > mixed with the rest, I took it out and put it in the script, then >> >> > >> >> > after multi-user boot was finished, I did a login and ran the script, >> >> > >> >> > with the output I showed in the initial post. >> >> > >> >> > >> >> > >> >> > So I put the interface configs back into rc.conf and I'm seeing the >> >> > >> >> > same problem, here is a cut during boot: >> >> > >> >> > >> >> > >> >> > ############### >> >> > >> >> > Starting file system checks: >> >> > >> >> > /dev/ad0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS >> >> > >> >> > /dev/ad0s1a: clean, 93385 free (33 frags, 11669 blocks, 0.0% fragmentation) >> >> > >> >> > Mounting local file systems:. >> >> > >> >> > Writing entropy file:. >> >> > >> >> > Setting hostname: tst-cambria-11. >> >> > >> >> > wlan0: Ethernet address: 00:21:a4:35:70:42 >> >> > >> >> > wlan1: Ethernet address: 00:21:a4:35:6c:96 >> >> > >> >> > ath1: unable to start recv logic >> >> > >> >> > wlan2: Ethernet address: 00:21:a4:32:38:c2 >> >> > >> >> > ath2: unable to start recv logic >> >> > >> >> > ############### >> >> > >> >> > >> >> > >> >> > Looking at the vmstat -z output the 256 Bucket fail is much higher than >> >> > >> >> > if I let it boot to multiuser and then configured the interfaces. It >> >> > >> >> > was in the 6000, while now it is much higher: >> >> > >> >> > >> >> > >> >> > Without wlan configs in rc.conf, but configured afterwards: >> >> > >> >> > 16 Bucket: 64, 0, 15, 300, 3139, 16, 0 >> >> > >> >> > 256 Bucket: 1024, 0, 31, 1, 592,6062, 0 >> >> > >> >> > vmem btag: 28, 0, 4496, 256, 4496, 32, 0 >> >> > >> >> > >> >> > >> >> > With wlan configs in rc.conf: >> >> > >> >> > 16 Bucket: 64, 0, 16, 299, 8611, 16, 0 >> >> > >> >> > 256 Bucket: 1024, 0, 26, 6, 773,16928, 0 >> >> > >> >> > vmem btag: 28, 0, 4405, 59, 4405, 30, 0 >> >> > >> >> > >> >> > >> >> > Both of them boot from a ro compact-flash with md /etc and /var, but >> >> > >> >> > they are small 4.3M and 2.1M. I have hacked in the use of tmpfs, but >> >> > >> >> > that did not make a difference. >> >> > >> >> > >> >> > >> > >> >> > >> > Friday I power cycled the board and it came up without an error. All 3 >> >> > >> > atheros cards configured in rc.conf. So I left it on for the weekend >> >> > >> > and by this morning there was still no errors, so I rebooted it and >> >> > >> > again saw the "ath1: unable to start recv logic" message for ath1 and >> >> > >> > ath2. I power cycled it, but still get the error, so Friday was just >> >> > >> > lucky with some timing thing, maybe if the card receive while it is >> >> > >> > still configuring? Also if I leave the board booted in this state, >> >> > >> > ath0 also start to give problems: >> >> > >> > >> >> > >> > ################# >> >> > >> > ath0: ath_rx_proc: no mbuf! >> >> > >> > ath0: ath_rx_proc: no mbuf! >> >> > >> > ... >> >> > >> > ath0: device timeout >> >> > >> > ath0: ath_reset: unable to start recv logic >> >> > >> > ... >> >> > >> > ################# >> >> > >> > >> >> > >> > In anycase it seems that memory allocation problem. How do I figure out >> >> > >> > where it is? "netstat -m" does not seem to point to an error. The mbuf >> >> > >> > info in vmstat -z also look ok. It is only "256 Bucket" in vmstat -z >> >> > >> > that point to an alloc failure. How do I figure out where that is and >> >> > >> > how do I fix it or work around it? >> >> > >> > >> >> > >> > ################### >> >> > >> > tst-11-arm:~ # netstat -m >> >> > >> > 128/382/510 mbufs in use (current/cache/total) >> >> > >> > 127/129/256/7654 mbuf clusters in use (current/cache/total/max) >> >> > >> > 127/126 mbuf+clusters out of packet secondary zone in use (current/cache) >> >> > >> > 0/0/0/3827 4k (page size) jumbo clusters in use (current/cache/total/max) >> >> > >> > 0/0/0/1134 9k jumbo clusters in use (current/cache/total/max) >> >> > >> > 0/0/0/637 16k jumbo clusters in use (current/cache/total/max) >> >> > >> > 286K/353K/639K bytes allocated to network (current/cache/total) >> >> > >> > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) >> >> > >> > 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) >> >> > >> > 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) >> >> > >> > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) >> >> > >> > 0/3/1488 sfbufs in use (current/peak/max) >> >> > >> > 0 requests for sfbufs denied >> >> > >> > 0 requests for sfbufs delayed >> >> > >> > 0 requests for I/O initiated by sendfile >> >> > >> > tst-11-arm:~ # vmstat -z | grep mbuf >> >> > >> > mbuf_packet: 256, 48990, 127, 126, 2294, 0, 0 >> >> > >> > mbuf: 256, 48990, 1, 256, 920, 0, 0 >> >> > >> > mbuf_cluster: 2048, 7654, 253, 3, 253, 0, 0 >> >> > >> > mbuf_jumbo_page: 4096, 3827, 0, 0, 0, 0, 0 >> >> > >> > mbuf_jumbo_9k: 9216, 1134, 0, 0, 0, 0, 0 >> >> > >> > mbuf_jumbo_16k: 16384, 637, 0, 0, 0, 0, 0 >> >> > >> > mbuf_ext_refcnt: 4, 0, 0, 504, 1, 0, 0 >> >> > >> > tst-11-arm:~ # vmstat -z | grep Bucket >> >> > >> > 4 Bucket: 16, 0, 7, 497, 1565, 0, 0 >> >> > >> > 6 Bucket: 24, 0, 0, 0, 0, 0, 0 >> >> > >> > 8 Bucket: 32, 0, 3, 375, 83, 0, 0 >> >> > >> > 12 Bucket: 48, 0, 2, 334, 5, 0, 0 >> >> > >> > 16 Bucket: 64, 0, 14, 301, 43687, 16, 0 >> >> > >> > 32 Bucket: 128, 0, 7, 148, 196, 0, 0 >> >> > >> > 64 Bucket: 256, 0, 19, 56, 77, 0, 0 >> >> > >> > 128 Bucket: 512, 0, 16, 16, 48, 0, 0 >> >> > >> > 256 Bucket: 1024, 0, 29, 3, 1521,86738, 0 >> >> > >> > tst-11-arm:~ # >> >> > >> > ################### >> >> > >> > >> >> > >> > Regards >> >> > >> > >> >> > >> > John >> >> > >> > -- >> >> > >> > John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za / jhay@FreeBSD.org >> >> _______________________________________________ >> >> freebsd-wireless@freebsd.org mailing list >> >> http://lists.freebsd.org/mailman/listinfo/freebsd-wireless >> >> To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" From owner-freebsd-embedded@FreeBSD.ORG Mon Jul 14 20:00:18 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C7CAC11; Mon, 14 Jul 2014 20:00:18 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 1DB4A2CED; Mon, 14 Jul 2014 20:00:17 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id E5772B842; Mon, 14 Jul 2014 22:00:15 +0200 (SAST) Date: Mon, 14 Jul 2014 22:00:15 +0200 From: John Hay To: Adrian Chadd Subject: Re: CAMBRIA and more than one atheros card Message-ID: <20140714200015.GA54311@zibbi.meraka.csir.co.za> References: <20140710040227.GA73872@zibbi.meraka.csir.co.za> <20140714080708.GA88464@zibbi.meraka.csir.co.za> <20140714184209.GA21922@zibbi.meraka.csir.co.za> <20140714190946.GA49930@zibbi.meraka.csir.co.za> <20140714191416.GB49930@zibbi.meraka.csir.co.za> <20140714194932.GA51947@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-wireless@freebsd.org" , "freebsd-embedded@freebsd.org" , Ian Lepore X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 20:00:18 -0000 On Mon, Jul 14, 2014 at 12:55:19PM -0700, Adrian Chadd wrote: > Right. What's the output of hw.ath ? tst-11-arm:~ # sysctl hw.ath hw.ath.bstuck: 4 hw.ath.txbuf_mgmt: 32 hw.ath.txbuf: 200 hw.ath.rxbuf: 40 hw.ath.anical: 100 hw.ath.resetcal: 1200 hw.ath.shortcal: 100 hw.ath.longcal: 30 hw.ath.debug: 0 hw.ath.hal.debug: 0 All 3 interfaces are in adhoc mode if it makes a difference. John > > > -a > > > On 14 July 2014 12:49, John Hay wrote: > > On Mon, Jul 14, 2014 at 12:23:47PM -0700, Adrian Chadd wrote: > >> Ah, you're going to need more than 64 bounce pages. That's just not > >> enough for all the mbufs the 11n support requires. > >> > >> It likely didn't show up in previous incarnations of this because > >> pre-11n support had a much smaller pool of buffers in use. > >> > >> For doing 11n, there's hm, 256 TX and 256 RX buffers for each NIC? Or > >> is it 512 and 512? It's something large like that. So assuming 512, > >> that's 1024 * 4096 bytes each, so 4mbyte per NIC needed of bounce > >> buffers. > >> > >> You could tweak ATH_TXBUF and ATH_RXBUF down to something like 128 TX > >> and 128 RX, but you can't go much lower than that per NIC as an A-MPDU > >> aggregate requires up to 64 buffers to transmit and/or receive and if > >> you're not careful you'll actually overrun the RX FIFO and/or starve > >> the TX code from having mbufs available to transmit with. > > > > I don't mind up the bounce buffers, if that will help. I'll see how > > high I can go before it explode. :-) I guess one cannot easily use > > the RAM above 64M for ram disks and code and then not bouncing at > > all. :-/ > > > > I just had an ok boot, ie. all 3 aths came up without an error. So > > just after a login, the bounce stats looked like this: > > > > tst-11-arm:~ # sysctl hw.busdma > > hw.busdma.total_bpages: 64 > > hw.busdma.zone0.total_bpages: 64 > > hw.busdma.zone0.free_bpages: 57 > > hw.busdma.zone0.reserved_bpages: 0 > > hw.busdma.zone0.active_bpages: 7 > > hw.busdma.zone0.total_bounced: 525 > > hw.busdma.zone0.total_deferred: 0 > > hw.busdma.zone0.lowaddr: 0x4000fff > > hw.busdma.zone0.alignment: 4096 > > > > The usage seems to slowly climb though. After 30 minutes it looks like > > this: > > > > tst-11-arm:~ # sysctl hw.busdma > > hw.busdma.total_bpages: 64 > > hw.busdma.zone0.total_bpages: 64 > > hw.busdma.zone0.free_bpages: 43 > > hw.busdma.zone0.reserved_bpages: 0 > > hw.busdma.zone0.active_bpages: 21 > > hw.busdma.zone0.total_bounced: 4713 > > hw.busdma.zone0.total_deferred: 0 > > hw.busdma.zone0.lowaddr: 0x4000fff > > hw.busdma.zone0.alignment: 4096 > > > > The board is pretty idle, with no routing daemon or traffic except for > > the occasional broadcast and multicasts that arrive. > > > > John > > > >> > >> > >> -a > >> > >> > >> On 14 July 2014 12:14, John Hay wrote: > >> > On Mon, Jul 14, 2014 at 09:09:46PM +0200, John Hay wrote: > >> >> On Mon, Jul 14, 2014 at 12:06:34PM -0700, Adrian Chadd wrote: > >> >> > .. why's it need bounce buffers? > >> >> > >> >> I found this: > >> >> arm/xscale/ixp425/ixp425_pci.c: /* NB: PCI dma window is 64M so anything above must be bounced */ > >> > > >> > I found a sysctl to show some bounce info. :-) > >> > > >> > On the boot that ath1 and ath2 failed during ifconfig and ath0 started > >> > to complain after a while: > >> > > >> > ##################### > >> > tst-11-arm:~ # sysctl hw.busdma > >> > hw.busdma.total_bpages: 64 > >> > hw.busdma.zone0.total_bpages: 64 > >> > hw.busdma.zone0.free_bpages: 0 > >> > hw.busdma.zone0.reserved_bpages: 0 > >> > hw.busdma.zone0.active_bpages: 64 > >> > hw.busdma.zone0.total_bounced: 1191 > >> > hw.busdma.zone0.total_deferred: 0 > >> > hw.busdma.zone0.lowaddr: 0x4000fff > >> > hw.busdma.zone0.alignment: 4096 > >> > ##################### > >> > > >> > I then thought to down wlan0 to see if the page count changed, but > >> > do not know. :-) > >> > > >> > ##################### > >> > tst-11-arm:~ # ifconfig wlan0 down > >> > dev.ath.0.debug: 0 -> 8 > >> > /sbin/ifconfig.bin wlan0 down > >> > ath0: ath_stop_locked: invalid 0 if_flags 0x8802 > >> > Sleeping thread (tid 100019, pid 0) owns a non-sleepable lock > >> > panic: sleeping thread > >> > Uptime: 32m46s > >> > Automatic reboot in 15 seconds - press a key on the console to abort > >> > Rebooting... > >> > ##################### > >> > > >> > John > >> > > >> >> > >> >> John > >> >> > > >> >> > > >> >> > -a > >> >> > > >> >> > > >> >> > On 14 July 2014 11:42, John Hay wrote: > >> >> > > On Mon, Jul 14, 2014 at 09:48:56AM -0700, Adrian Chadd wrote: > >> >> > >> Hm, it could be some bus related stupidity. It's allocating 2k or 4k > >> >> > >> mbufs for the receive path because wifi frames are bigger than > >> >> > >> ethernet frames. If you're not seeing failures in 4k mbuf allocations > >> >> > >> then I'm not sure what it could be. > >> >> > >> > >> >> > >> I'll see about firing it up locally and checking. > >> >> > > > >> >> > > I'm hunting a bit more and it looks like the fail is in the bounce pages. > >> >> > > It looks like the calls look like this: > >> >> > > > >> >> > > ath_legacy_rxbuf_init() > >> >> > > bus_dmamap_load_mbuf_sg() > >> >> > > _bus_dmamap_load_buffer() > >> >> > > _bus_dmamap_reserve_pages() > >> >> > > reserve_bounce_pages() > >> >> > > > >> >> > > I have added a printf at the start of alloc_bounce_pages() and it seems > >> >> > > that it is only called (twice) when ath0 is probed. Is bus_dma_tag_t dmat, > >> >> > > the first argument to alloc_bounce_pages(), common for the whole pci bus? > >> >> > > > >> >> > > The start of the boot, with my printf looks like this: > >> >> > > > >> >> > > #################### > >> >> > > FreeBSD ARM (Gateworks Cambria) boot2 v0.4 > >> >> > > - > >> >> > > Default: /boot/kernel/kernel > >> >> > > boot: > >> >> > > Copyright (c) 1992-2014 The FreeBSD Project. > >> >> > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > >> >> > > The Regents of the University of California. All rights reserved. > >> >> > > FreeBSD is a registered trademark of The FreeBSD Foundation. > >> >> > > FreeBSD 11.0-CURRENT #9 r268502M: Mon Jul 14 15:30:15 SAST 2014 > >> >> > > jhay@dolphin.meraka.csir.co.za:/usr/obj/arm.armeb/snaps/arm/11-tst/src/sys/S > >> >> > > MALL-CAMBRIA arm > >> >> > > gcc version 4.2.1 20070831 patched [FreeBSD] > >> >> > > CPU: IXP435 rev 1 (ARMv5TE) (XScale core) > >> >> > > Big-endian DC enabled IC enabled WB enabled LABT branch prediction enabled > >> >> > > 32KB/32B 32-way instruction cache > >> >> > > 32KB/32B 32-way write-back-locking data cache > >> >> > > real memory = 134213632 (127 MB) > >> >> > > avail memory = 124440576 (118 MB) > >> >> > > random device not loaded; using insecure entropy > >> >> > > wlan: mac acl policy registered > >> >> > > random: initialized > >> >> > > ixp0: > >> >> > > ixp0: 37e7f > >> >> > > pcib0: on ixp0 > >> >> > > pci0: on pcib0 > >> >> > > ath0: irq 28 at device 1.0 on pci0 > >> >> > > alloc_bounce_pages: numpages 63 > >> >> > > [ath] enabling AN_TOP2_FIXUP > >> >> > > alloc_bounce_pages: numpages 1 > >> >> > > ath0: AR9220 mac 128.2 RF5133 phy 13.0 > >> >> > > ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 > >> >> > > ath1: irq 27 at device 2.0 on pci0 > >> >> > > [ath] enabling AN_TOP2_FIXUP > >> >> > > ath1: AR9220 mac 128.2 RF5133 phy 13.0 > >> >> > > ath1: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 > >> >> > > ath2: irq 26 at device 3.0 on pci0 > >> >> > > ath2: AR5413 mac 10.5 RF5413 phy 6.1 > >> >> > > ath2: 2GHz radio: 0x0000; 5GHz radio: 0x0063 > >> >> > > ixpclk0: on ixp0 > >> >> > > #################### > >> >> > > > >> >> > > Interesting, with this boot, with the new kernel, the aths did not fail. > >> >> > > Could the printf have changed something or was it just coincidence? With > >> >> > > a reboot ath1 and ath2 failed again during configuration and a little > >> >> > > while later ath0 started to complain: > >> >> > > > >> >> > > ath0: ath_rx_proc: no mbuf! > >> >> > > > >> >> > > John > >> >> > > > >> >> > >> > >> >> > >> > >> >> > >> > >> >> > >> > >> >> > >> -a > >> >> > >> > >> >> > >> On 14 July 2014 01:07, John Hay wrote: > >> >> > >> > On Thu, Jul 10, 2014 at 06:02:27AM +0200, John Hay wrote: > >> >> > >> >> On Wed, Jul 09, 2014 at 06:46:12AM +0200, John Hay wrote: > >> >> > >> >> > Hi Guys, > >> >> > >> >> > > >> >> > >> >> > The problem is back / still there. I initially saw the problem during > >> >> > >> >> > boot, with the interface configs in rc.conf, but because it is so > >> >> > >> >> > mixed with the rest, I took it out and put it in the script, then > >> >> > >> >> > after multi-user boot was finished, I did a login and ran the script, > >> >> > >> >> > with the output I showed in the initial post. > >> >> > >> >> > > >> >> > >> >> > So I put the interface configs back into rc.conf and I'm seeing the > >> >> > >> >> > same problem, here is a cut during boot: > >> >> > >> >> > > >> >> > >> >> > ############### > >> >> > >> >> > Starting file system checks: > >> >> > >> >> > /dev/ad0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS > >> >> > >> >> > /dev/ad0s1a: clean, 93385 free (33 frags, 11669 blocks, 0.0% fragmentation) > >> >> > >> >> > Mounting local file systems:. > >> >> > >> >> > Writing entropy file:. > >> >> > >> >> > Setting hostname: tst-cambria-11. > >> >> > >> >> > wlan0: Ethernet address: 00:21:a4:35:70:42 > >> >> > >> >> > wlan1: Ethernet address: 00:21:a4:35:6c:96 > >> >> > >> >> > ath1: unable to start recv logic > >> >> > >> >> > wlan2: Ethernet address: 00:21:a4:32:38:c2 > >> >> > >> >> > ath2: unable to start recv logic > >> >> > >> >> > ############### > >> >> > >> >> > > >> >> > >> >> > Looking at the vmstat -z output the 256 Bucket fail is much higher than > >> >> > >> >> > if I let it boot to multiuser and then configured the interfaces. It > >> >> > >> >> > was in the 6000, while now it is much higher: > >> >> > >> >> > > >> >> > >> >> > Without wlan configs in rc.conf, but configured afterwards: > >> >> > >> >> > 16 Bucket: 64, 0, 15, 300, 3139, 16, 0 > >> >> > >> >> > 256 Bucket: 1024, 0, 31, 1, 592,6062, 0 > >> >> > >> >> > vmem btag: 28, 0, 4496, 256, 4496, 32, 0 > >> >> > >> >> > > >> >> > >> >> > With wlan configs in rc.conf: > >> >> > >> >> > 16 Bucket: 64, 0, 16, 299, 8611, 16, 0 > >> >> > >> >> > 256 Bucket: 1024, 0, 26, 6, 773,16928, 0 > >> >> > >> >> > vmem btag: 28, 0, 4405, 59, 4405, 30, 0 > >> >> > >> >> > > >> >> > >> >> > Both of them boot from a ro compact-flash with md /etc and /var, but > >> >> > >> >> > they are small 4.3M and 2.1M. I have hacked in the use of tmpfs, but > >> >> > >> >> > that did not make a difference. > >> >> > >> >> > > >> >> > >> > > >> >> > >> > Friday I power cycled the board and it came up without an error. All 3 > >> >> > >> > atheros cards configured in rc.conf. So I left it on for the weekend > >> >> > >> > and by this morning there was still no errors, so I rebooted it and > >> >> > >> > again saw the "ath1: unable to start recv logic" message for ath1 and > >> >> > >> > ath2. I power cycled it, but still get the error, so Friday was just > >> >> > >> > lucky with some timing thing, maybe if the card receive while it is > >> >> > >> > still configuring? Also if I leave the board booted in this state, > >> >> > >> > ath0 also start to give problems: > >> >> > >> > > >> >> > >> > ################# > >> >> > >> > ath0: ath_rx_proc: no mbuf! > >> >> > >> > ath0: ath_rx_proc: no mbuf! > >> >> > >> > ... > >> >> > >> > ath0: device timeout > >> >> > >> > ath0: ath_reset: unable to start recv logic > >> >> > >> > ... > >> >> > >> > ################# > >> >> > >> > > >> >> > >> > In anycase it seems that memory allocation problem. How do I figure out > >> >> > >> > where it is? "netstat -m" does not seem to point to an error. The mbuf > >> >> > >> > info in vmstat -z also look ok. It is only "256 Bucket" in vmstat -z > >> >> > >> > that point to an alloc failure. How do I figure out where that is and > >> >> > >> > how do I fix it or work around it? > >> >> > >> > > >> >> > >> > ################### > >> >> > >> > tst-11-arm:~ # netstat -m > >> >> > >> > 128/382/510 mbufs in use (current/cache/total) > >> >> > >> > 127/129/256/7654 mbuf clusters in use (current/cache/total/max) > >> >> > >> > 127/126 mbuf+clusters out of packet secondary zone in use (current/cache) > >> >> > >> > 0/0/0/3827 4k (page size) jumbo clusters in use (current/cache/total/max) > >> >> > >> > 0/0/0/1134 9k jumbo clusters in use (current/cache/total/max) > >> >> > >> > 0/0/0/637 16k jumbo clusters in use (current/cache/total/max) > >> >> > >> > 286K/353K/639K bytes allocated to network (current/cache/total) > >> >> > >> > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > >> >> > >> > 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) > >> >> > >> > 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) > >> >> > >> > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > >> >> > >> > 0/3/1488 sfbufs in use (current/peak/max) > >> >> > >> > 0 requests for sfbufs denied > >> >> > >> > 0 requests for sfbufs delayed > >> >> > >> > 0 requests for I/O initiated by sendfile > >> >> > >> > tst-11-arm:~ # vmstat -z | grep mbuf > >> >> > >> > mbuf_packet: 256, 48990, 127, 126, 2294, 0, 0 > >> >> > >> > mbuf: 256, 48990, 1, 256, 920, 0, 0 > >> >> > >> > mbuf_cluster: 2048, 7654, 253, 3, 253, 0, 0 > >> >> > >> > mbuf_jumbo_page: 4096, 3827, 0, 0, 0, 0, 0 > >> >> > >> > mbuf_jumbo_9k: 9216, 1134, 0, 0, 0, 0, 0 > >> >> > >> > mbuf_jumbo_16k: 16384, 637, 0, 0, 0, 0, 0 > >> >> > >> > mbuf_ext_refcnt: 4, 0, 0, 504, 1, 0, 0 > >> >> > >> > tst-11-arm:~ # vmstat -z | grep Bucket > >> >> > >> > 4 Bucket: 16, 0, 7, 497, 1565, 0, 0 > >> >> > >> > 6 Bucket: 24, 0, 0, 0, 0, 0, 0 > >> >> > >> > 8 Bucket: 32, 0, 3, 375, 83, 0, 0 > >> >> > >> > 12 Bucket: 48, 0, 2, 334, 5, 0, 0 > >> >> > >> > 16 Bucket: 64, 0, 14, 301, 43687, 16, 0 > >> >> > >> > 32 Bucket: 128, 0, 7, 148, 196, 0, 0 > >> >> > >> > 64 Bucket: 256, 0, 19, 56, 77, 0, 0 > >> >> > >> > 128 Bucket: 512, 0, 16, 16, 48, 0, 0 > >> >> > >> > 256 Bucket: 1024, 0, 29, 3, 1521,86738, 0 > >> >> > >> > tst-11-arm:~ # > >> >> > >> > ################### > >> >> > >> > > >> >> > >> > Regards > >> >> > >> > > >> >> > >> > John > >> >> > >> > -- > >> >> > >> > John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za / jhay@FreeBSD.org > >> >> _______________________________________________ > >> >> freebsd-wireless@freebsd.org mailing list > >> >> http://lists.freebsd.org/mailman/listinfo/freebsd-wireless > >> >> To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" From owner-freebsd-embedded@FreeBSD.ORG Mon Jul 14 20:02:04 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB880C83; Mon, 14 Jul 2014 20:02:04 +0000 (UTC) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 53AF92D6C; Mon, 14 Jul 2014 20:02:04 +0000 (UTC) Received: by mail-qc0-f170.google.com with SMTP id c9so4179694qcz.1 for ; Mon, 14 Jul 2014 13:02:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=DFUSNSjql9mNhPSJOYoJdhGf3esdmJDBc+NYWi9bwwE=; b=rtLEe53ONSBhydrwK6Mu5X5B+kljynuyFYGbR78zIaMKV+Fi/ZA/aZtImhCOy/lsV/ caQzVvIissdsyvffXa3562VlKTJZjoDjE4k6+xJLhg1uMyeR9fNb2g3DJoaNTBE2y6Zx KaB1JcljK3pAUASQHAGtGO1RFRshWfCJp8qSlIVFvcxoZo/lFnyS+kp63sd9a1kOjHvo /vZEODlrJ197rSTa2oZVyXpExhqZJ8+Y3tkA0lEFEUM5A3kF7WUzqPUB1soRcALfXeWn kkFomLrAMLcK/0XyRKUDiV7sJOylkVnfn+bXEqbLBq5xC9dmhrs+n2RpDAkW2w9Tcdm0 PakA== MIME-Version: 1.0 X-Received: by 10.224.156.145 with SMTP id x17mr27345963qaw.49.1405368123517; Mon, 14 Jul 2014 13:02:03 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.202.193 with HTTP; Mon, 14 Jul 2014 13:02:03 -0700 (PDT) In-Reply-To: <20140714200015.GA54311@zibbi.meraka.csir.co.za> References: <20140710040227.GA73872@zibbi.meraka.csir.co.za> <20140714080708.GA88464@zibbi.meraka.csir.co.za> <20140714184209.GA21922@zibbi.meraka.csir.co.za> <20140714190946.GA49930@zibbi.meraka.csir.co.za> <20140714191416.GB49930@zibbi.meraka.csir.co.za> <20140714194932.GA51947@zibbi.meraka.csir.co.za> <20140714200015.GA54311@zibbi.meraka.csir.co.za> Date: Mon, 14 Jul 2014 13:02:03 -0700 X-Google-Sender-Auth: OUHqmVDJ6wF7oM0YhWnEZZzOWJ0 Message-ID: Subject: Re: CAMBRIA and more than one atheros card From: Adrian Chadd To: John Hay Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-wireless@freebsd.org" , "freebsd-embedded@freebsd.org" , Ian Lepore X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 20:02:04 -0000 On 14 July 2014 13:00, John Hay wrote: > On Mon, Jul 14, 2014 at 12:55:19PM -0700, Adrian Chadd wrote: >> Right. What's the output of hw.ath ? > > tst-11-arm:~ # sysctl hw.ath > hw.ath.bstuck: 4 > hw.ath.txbuf_mgmt: 32 > hw.ath.txbuf: 200 > hw.ath.rxbuf: 40 > hw.ath.anical: 100 > hw.ath.resetcal: 1200 > hw.ath.shortcal: 100 > hw.ath.longcal: 30 > hw.ath.debug: 0 > hw.ath.hal.debug: 0 > > All 3 interfaces are in adhoc mode if it makes a difference. Ah, you're not even using it in 11n mode. Ok. Well, that's 72 mbufs allocated, and up to 200 more being allocated during transmit. Then there's the handful of pages being used for DMA descriptors. So yeah, over time that may become a problem. Try doubling the number of bounce buffers available and see what happens. -a From owner-freebsd-embedded@FreeBSD.ORG Mon Jul 14 20:37:16 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC665EB6; Mon, 14 Jul 2014 20:37:16 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.freebsd.org (Postfix) with ESMTP id 033882107; Mon, 14 Jul 2014 20:37:15 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id E3C3CB842; Mon, 14 Jul 2014 22:37:07 +0200 (SAST) Date: Mon, 14 Jul 2014 22:37:07 +0200 From: John Hay To: Adrian Chadd Subject: Re: CAMBRIA and more than one atheros card Message-ID: <20140714203707.GB54311@zibbi.meraka.csir.co.za> References: <20140714184209.GA21922@zibbi.meraka.csir.co.za> <20140714190946.GA49930@zibbi.meraka.csir.co.za> <20140714191416.GB49930@zibbi.meraka.csir.co.za> <20140714194932.GA51947@zibbi.meraka.csir.co.za> <20140714200015.GA54311@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-wireless@freebsd.org" , "freebsd-embedded@freebsd.org" , Ian Lepore X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 20:37:17 -0000 On Mon, Jul 14, 2014 at 01:02:03PM -0700, Adrian Chadd wrote: > On 14 July 2014 13:00, John Hay wrote: > > On Mon, Jul 14, 2014 at 12:55:19PM -0700, Adrian Chadd wrote: > >> Right. What's the output of hw.ath ? > > > > tst-11-arm:~ # sysctl hw.ath > > hw.ath.bstuck: 4 > > hw.ath.txbuf_mgmt: 32 > > hw.ath.txbuf: 200 > > hw.ath.rxbuf: 40 > > hw.ath.anical: 100 > > hw.ath.resetcal: 1200 > > hw.ath.shortcal: 100 > > hw.ath.longcal: 30 > > hw.ath.debug: 0 > > hw.ath.hal.debug: 0 > > > > All 3 interfaces are in adhoc mode if it makes a difference. > > Ah, you're not even using it in 11n mode. Ok. > > Well, that's 72 mbufs allocated, and up to 200 more being allocated > during transmit. Then there's the handful of pages being used for DMA > descriptors. So yeah, over time that may become a problem. > > Try doubling the number of bounce buffers available and see what happens. The first boot looks good, all 3 aths came up. Bounce buffers just after login: tst-11-arm:~ # sysctl hw.busdma hw.busdma.total_bpages: 128 hw.busdma.zone0.total_bpages: 128 hw.busdma.zone0.free_bpages: 128 hw.busdma.zone0.reserved_bpages: 0 hw.busdma.zone0.active_bpages: 0 hw.busdma.zone0.total_bounced: 0 hw.busdma.zone0.total_deferred: 0 hw.busdma.zone0.lowaddr: 0x4000fff hw.busdma.zone0.alignment: 4096 It stayed like that for about 6-7 minutes, then looked like this: tst-11-arm:~ # sysctl hw.busdma hw.busdma.total_bpages: 128 hw.busdma.zone0.total_bpages: 128 hw.busdma.zone0.free_bpages: 126 hw.busdma.zone0.reserved_bpages: 0 hw.busdma.zone0.active_bpages: 2 hw.busdma.zone0.total_bounced: 208 hw.busdma.zone0.total_deferred: 0 hw.busdma.zone0.lowaddr: 0x4000fff hw.busdma.zone0.alignment: 4096 After 13 minutes: tst-11-arm:~ # sysctl hw.busdma hw.busdma.total_bpages: 128 hw.busdma.zone0.total_bpages: 128 hw.busdma.zone0.free_bpages: 124 hw.busdma.zone0.reserved_bpages: 0 hw.busdma.zone0.active_bpages: 4 hw.busdma.zone0.total_bounced: 667 hw.busdma.zone0.total_deferred: 0 hw.busdma.zone0.lowaddr: 0x4000fff hw.busdma.zone0.alignment: 4096 After 26 minutes: tst-11-arm:~ # sysctl hw.busdma hw.busdma.total_bpages: 128 hw.busdma.zone0.total_bpages: 128 hw.busdma.zone0.free_bpages: 121 hw.busdma.zone0.reserved_bpages: 0 hw.busdma.zone0.active_bpages: 7 hw.busdma.zone0.total_bounced: 2433 hw.busdma.zone0.total_deferred: 0 hw.busdma.zone0.lowaddr: 0x4000fff hw.busdma.zone0.alignment: 4096 Great! At last it seems like we are making progress. I'll leave it till the morning and then do a few reboots and then some traffic. One question, should the active bounce pages keep growing or stabilize somewhere? How do I know if I have to few or if there is a leak? Thanks Adrian for your help. John -- John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za