From owner-freebsd-arm@FreeBSD.ORG Sun Oct 24 11:25:10 2010 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB8BF106564A for ; Sun, 24 Oct 2010 11:25:10 +0000 (UTC) (envelope-from kristof@sigsegv.be) Received: from winston.telenet-ops.be (winston.telenet-ops.be [195.130.137.75]) by mx1.freebsd.org (Postfix) with ESMTP id 58F7D8FC1A for ; Sun, 24 Oct 2010 11:25:10 +0000 (UTC) Received: from juliette.telenet-ops.be (unknown [195.130.137.74]) by winston.telenet-ops.be (Postfix) with ESMTP id 51F6E31201 for ; Sun, 24 Oct 2010 13:14:43 +0200 (CEST) Received: from triton.sigsegv.be ([81.165.77.237]) by juliette.telenet-ops.be with bizsmtp id NbEh1f00357BtZ506bEhMW; Sun, 24 Oct 2010 13:14:41 +0200 Received: from nereid (nereid.neptune.sigsegv.be [IPv6:2001:470:c8f4:0:200:ff:fe00:8]) by triton.sigsegv.be (Postfix) with SMTP id 1C27D1C170; Sun, 24 Oct 2010 13:14:40 +0200 (CEST) Received: by nereid (sSMTP sendmail emulation); Sun, 24 Oct 2010 13:14:39 +0200 Date: Sun, 24 Oct 2010 13:14:38 +0200 From: Kristof Provost To: Milan Obuch Message-ID: <20101024111438.GA24690@nereid> References: <201010202309.40148.freebsd-arm@dino.sk> <20101021104352.588c6a5f@ernst.jennejohn.org> <201010211119.26731.freebsd-arm@dino.sk> <201010212313.23283.freebsd-arm@dino.sk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201010212313.23283.freebsd-arm@dino.sk> X-PGP-Fingerprint: 6B6E 5EED 8ECF FAE7 1F61 7458 5046 7D0E 11B0 0EE8 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-arm@freebsd.org Subject: Re: Guruplug Server Plus working to some extent... X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 11:25:10 -0000 On 2010-10-21 23:13:21 (+0200), Milan Obuch wrote: > Also, when I put mge1's ethernet link address (MAC) into .dts file, it is > initialised with this value, as expected. But nothing else changed - receiving > frames works, sending does not. > > Maybe it's time for some mge's source tweaking, but I have absolutelly no idea > where to begin. > I suspect the PHY asignment. The current code tries to retrieve the PHY number from the dts but then probes for PHYs and uses the first one. Can you try the following patch? I unfortunately don't have hardware with two PHYs. Make sure you have the correct phy number set for mge1 (probably just 0x1) in your dts. It's probably not a final solution though as it relies on the dts for information which can be probed automatically. Index: dev/mge/if_mge.c =================================================================== --- dev/mge/if_mge.c (revision 214256) +++ dev/mge/if_mge.c (working copy) @@ -626,7 +626,6 @@ mge_attach(device_t dev) { struct mge_softc *sc; - struct mii_softc *miisc; struct ifnet *ifp; uint8_t hwaddr[ETHER_ADDR_LEN]; int i, error, phy; @@ -717,8 +716,7 @@ sc->mii = device_get_softc(sc->miibus); /* Tell the MAC where to find the PHY so autoneg works */ - miisc = LIST_FIRST(&sc->mii->mii_phys); - MGE_WRITE(sc, MGE_REG_PHYDEV, miisc->mii_phy); + MGE_WRITE(sc, MGE_REG_PHYDEV, phy); /* Attach interrupt handlers */ for (i = 0; i < 2; ++i) { Regards, Kristof From owner-freebsd-arm@FreeBSD.ORG Sun Oct 24 21:22:44 2010 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46471106566C for ; Sun, 24 Oct 2010 21:22:44 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from loki.netlab.sk (ns3.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 090418FC21 for ; Sun, 24 Oct 2010 21:22:43 +0000 (UTC) Received: from door.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Sun, 24 Oct 2010 23:23:47 +0200 id 00033C0A.4CC4A3E3.0000BA41 From: Milan Obuch To: Kristof Provost Date: Sun, 24 Oct 2010 23:22:34 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.5.2; i386; ; ) References: <201010202309.40148.freebsd-arm@dino.sk> <201010212313.23283.freebsd-arm@dino.sk> <20101024111438.GA24690@nereid> In-Reply-To: <20101024111438.GA24690@nereid> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010242322.35909.freebsd-arm@dino.sk> Cc: freebsd-arm@freebsd.org Subject: Re: Guruplug Server Plus working to some extent... X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 21:22:44 -0000 On Sunday 24 October 2010 13:14:38 Kristof Provost wrote: > On 2010-10-21 23:13:21 (+0200), Milan Obuch wrote: > > Also, when I put mge1's ethernet link address (MAC) into .dts file, it is > > initialised with this value, as expected. But nothing else changed - > > receiving frames works, sending does not. > > > > Maybe it's time for some mge's source tweaking, but I have absolutelly no > > idea where to begin. > > I suspect the PHY asignment. The current code tries to retrieve the PHY > number from the dts but then probes for PHYs and uses the first one. > Well, it may be. I am no expert in this area, but what I do not understand is how bad PHY assignment could affect sending frames but nor receiving. I would expect with wrong assignment failing both, but, again, I am no expert here... > Can you try the following patch? I unfortunately don't have hardware > with two PHYs. > Make sure you have the correct phy number set for mge1 (probably just > 0x1) in your dts. > > It's probably not a final solution though as it relies on the dts for > information which can be probed automatically. > > Index: dev/mge/if_mge.c > =================================================================== > --- dev/mge/if_mge.c (revision 214256) > +++ dev/mge/if_mge.c (working copy) > @@ -626,7 +626,6 @@ > mge_attach(device_t dev) > { > struct mge_softc *sc; > - struct mii_softc *miisc; > struct ifnet *ifp; > uint8_t hwaddr[ETHER_ADDR_LEN]; > int i, error, phy; > @@ -717,8 +716,7 @@ > sc->mii = device_get_softc(sc->miibus); > > /* Tell the MAC where to find the PHY so autoneg works */ > - miisc = LIST_FIRST(&sc->mii->mii_phys); > - MGE_WRITE(sc, MGE_REG_PHYDEV, miisc->mii_phy); > + MGE_WRITE(sc, MGE_REG_PHYDEV, phy); > > /* Attach interrupt handlers */ > for (i = 0; i < 2; ++i) { > Thanks for patch, but behavior did not changed. I played with .dts definition for second port a bit, but it was a bit guesswork, and everytime receiving frames worked and sending frames did not. I did not found good description of .dts or the one I really understand details there :( Milan From owner-freebsd-arm@FreeBSD.ORG Mon Oct 25 11:06:56 2010 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06674106566C for ; Mon, 25 Oct 2010 11:06:56 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E7A6B8FC15 for ; Mon, 25 Oct 2010 11:06:55 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9PB6tLk088707 for ; Mon, 25 Oct 2010 11:06:55 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o9PB6tiw088705 for freebsd-arm@FreeBSD.org; Mon, 25 Oct 2010 11:06:55 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 25 Oct 2010 11:06:55 GMT Message-Id: <201010251106.o9PB6tiw088705@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arm@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 11:06:56 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/150581 arm [irq] Unknown error generates IRQ address decoding err o arm/149288 arm mail/dovecot causes panic during configure on Sheevapl o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 o arm/134338 arm [patch] Lock GPIO accesses on ixp425 4 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Oct 25 20:17:32 2010 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31CA6106566C for ; Mon, 25 Oct 2010 20:17:32 +0000 (UTC) (envelope-from kristof@sigsegv.be) Received: from gerard.telenet-ops.be (gerard.telenet-ops.be [195.130.132.48]) by mx1.freebsd.org (Postfix) with ESMTP id 969398FC08 for ; Mon, 25 Oct 2010 20:17:31 +0000 (UTC) Received: from triton.sigsegv.be ([81.165.77.237]) by gerard.telenet-ops.be with bizsmtp id P8HV1f00j57BtZ50H8HVqB; Mon, 25 Oct 2010 22:17:30 +0200 Received: from nereid (nereid.neptune.sigsegv.be [IPv6:2001:470:c8f4:0:200:ff:fe00:8]) by triton.sigsegv.be (Postfix) with SMTP id C515C1C1EC; Mon, 25 Oct 2010 22:17:28 +0200 (CEST) Received: by nereid (sSMTP sendmail emulation); Mon, 25 Oct 2010 22:17:28 +0200 Date: Mon, 25 Oct 2010 22:17:27 +0200 From: Kristof Provost To: Milan Obuch Message-ID: <20101025201726.GB24690@nereid> References: <201010202309.40148.freebsd-arm@dino.sk> <201010212313.23283.freebsd-arm@dino.sk> <20101024111438.GA24690@nereid> <201010242322.35909.freebsd-arm@dino.sk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201010242322.35909.freebsd-arm@dino.sk> X-PGP-Fingerprint: 6B6E 5EED 8ECF FAE7 1F61 7458 5046 7D0E 11B0 0EE8 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-arm@freebsd.org Subject: Re: Guruplug Server Plus working to some extent... X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 20:17:32 -0000 On 2010-10-24 23:22:34 (+0200), Milan Obuch wrote: > Well, it may be. I am no expert in this area, but what I do not understand is > how bad PHY assignment could affect sending frames but nor receiving. I would > expect with wrong assignment failing both, but, again, I am no expert here... > I'm not exactly an expert myself, I could be mistaken. I suspected the PHY because that's the bit which caused trouble on my board. Looking deeper the fact it's unable to probe the MAC address for the second interface is quite suspicious too. Was there anything suspicious in the boot log? Perhaps something related to simplebus? It might also be a good idea to rebuild your kernel with 'DEBUG' set and to take another look at the boot output then. I don't think I can say more without a device to play around with. Regards, Kristof From owner-freebsd-arm@FreeBSD.ORG Tue Oct 26 19:59:59 2010 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 967A81065670 for ; Tue, 26 Oct 2010 19:59:59 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from loki.netlab.sk (loki.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 3E3C18FC15 for ; Tue, 26 Oct 2010 19:59:58 +0000 (UTC) Received: from door.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Tue, 26 Oct 2010 22:00:51 +0200 id 00033C0A.4CC73373.00015C03 From: Milan Obuch To: Kristof Provost Date: Tue, 26 Oct 2010 22:00:07 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.5.2; i386; ; ) References: <201010202309.40148.freebsd-arm@dino.sk> <201010242322.35909.freebsd-arm@dino.sk> <20101025201726.GB24690@nereid> In-Reply-To: <20101025201726.GB24690@nereid> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_INzxMKkblRKi0p8" Message-Id: <201010262200.09364.freebsd-arm@dino.sk> Cc: freebsd-arm@freebsd.org Subject: Re: Guruplug Server Plus working to some extent... X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 19:59:59 -0000 --Boundary-00=_INzxMKkblRKi0p8 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit On Monday 25 October 2010 22:17:27 Kristof Provost wrote: > On 2010-10-24 23:22:34 (+0200), Milan Obuch wrote: > > Well, it may be. I am no expert in this area, but what I do not > > understand is how bad PHY assignment could affect sending frames but nor > > receiving. I would expect with wrong assignment failing both, but, > > again, I am no expert here... > > I'm not exactly an expert myself, I could be mistaken. > I suspected the PHY because that's the bit which caused trouble on my > board. Looking deeper the fact it's unable to probe the MAC address for > the second interface is quite suspicious too. > > Was there anything suspicious in the boot log? Perhaps something related > to simplebus? > It might also be a good idea to rebuild your kernel with 'DEBUG' set and > to take another look at the boot output then. > > I don't think I can say more without a device to play around with. > > Regards, > Kristof Well, 'makeoptions DEBUG' just creates kernel.symbols, nothing else... there must be some other way to create more debug output, but I did not find it. If I could convert elf-structured ubldr to binary ubldr.bin, maybe I can boot kernel with verbose output... but I did not find the way to do it. (Any hint on this?) There is absolutely nothing suspicious in boot log - see attached dmesg... Regards, Milan --Boundary-00=_INzxMKkblRKi0p8 Content-Type: text/plain; charset="ISO-8859-1"; name="dmesg" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dmesg" KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2010 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 9.0-CURRENT #3: Tue Oct 26 21:49:55 CEST 2010 root@wind.dino.sk:/tmp/guruplug/obj/arm.arm/data/src9/sys/GURUPLUGPLUS2 arm WARNING: DIAGNOSTIC option enabled, expect reduced performance. CPU: Feroceon 88FR131 rev 1 (Marvell core) DC enabled IC enabled WB enabled EABT branch prediction enabled 16KB/32B 4-way Instruction cache 16KB/32B 4-way write-back-locking-C Data cache real memory = 536870912 (512 MB) avail memory = 520613888 (496 MB) SOC: Marvell 88F6281 rev A0, TClock 200MHz simplebus0: on fdtbus0 ic0: mem 0xf1020200-0xf102023b on simplebus0 timer0: mem 0xf1020300-0xf102032f irq 1 on simplebus0 Event timer "CPUTimer0" frequency 200000000 Hz quality 1000 Timecounter "CPUTimer1" frequency 200000000 Hz quality 1000 gpio0: mem 0xf1010100-0xf101011f irq 35,36,37,38,39,40,41 on simplebus0 rtc0: mem 0xf1010300-0xf1010307 on simplebus0 mge0: mem 0xf1072000-0xf1073fff irq 12,13,14,11,46 on simplebus0 mge0: Ethernet address: f0:ad:4e:00:16:33 miibus0: on mge0 e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto mge1: mem 0xf1076000-0xf1077fff irq 16,17,18,15,47 on simplebus0 mge1: Ethernet address: f0:ad:4e:00:16:34 miibus1: on mge1 e1000phy1: PHY 1 on miibus1 e1000phy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto uart0: <16550 or compatible> mem 0xf1012000-0xf101201f irq 33 on simplebus0 uart0: console (1056,n,8,1) uart1: <16550 or compatible> mem 0xf1012100-0xf101211f irq 34 on simplebus0 ehci0: mem 0xf1050000-0xf1050fff irq 48,19 on simplebus0 usbus0: EHCI version 1.0 usbus0: stop timeout usbus0: set host controller mode usbus0: on ehci0 sata0: mem 0xf1080000-0xf1085fff irq 21 on simplebus0 ata0: on sata0 ata1: on sata0 Timecounters tick every 1.000 msec usbus0: 480Mbps High Speed USB v2.0 WARNING: DIAGNOSTIC option enabled, expect reduced performance. Root mount waiting for: usbus0 ugen0.1: at usbus0 uhub0: on usbus0 uhub0: 1 port with 1 removable, self powered Root mount waiting for: usbus0 ugen0.2: at usbus0 uhub1: on usbus0 Root mount waiting for: usbus0 uhub1: 4 ports with 4 removable, self powered ugen0.3: at usbus0 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x0000 Root mount waiting for: usbus0 Root mount waiting for: usbus0 umass0:0:0:-1: Attached to scbus0 (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI status: Check Condition (probe0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from ufs:/dev/ufs/ARMroot []... mountroot: waiting for device /dev/ufs/ARMroot ... (probe0:umass-sim0:0:0:1): TEST UNIT READY. CDB: 0 20 0 0 0 0 (probe0:umass-sim0:0:0:1): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:1): SCSI status: Check Condition (probe0:umass-sim0:0:0:1): SCSI sense: UNIT ATTENTION asc:28,0 (Not ready to ready change, medium may have changed) da1 at umass-sim0 bus 0 scbus0 target 0 lun 1 da1: Removable Direct Access SCSI-0 device da1: 40.000MB/s transfers da1: 974MB (1995776 512 byte sectors: 64H 32S/T 974C) --Boundary-00=_INzxMKkblRKi0p8-- From owner-freebsd-arm@FreeBSD.ORG Tue Oct 26 21:20:04 2010 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E6EF1065673 for ; Tue, 26 Oct 2010 21:20:04 +0000 (UTC) (envelope-from kristof@sigsegv.be) Received: from juliette.telenet-ops.be (juliette.telenet-ops.be [195.130.137.74]) by mx1.freebsd.org (Postfix) with ESMTP id 8E2678FC12 for ; Tue, 26 Oct 2010 21:20:02 +0000 (UTC) Received: from triton.sigsegv.be ([81.165.77.237]) by juliette.telenet-ops.be with bizsmtp id PZL11f00957BtZ506ZL1hB; Tue, 26 Oct 2010 23:20:01 +0200 Received: from nereid (nereid.neptune.sigsegv.be [IPv6:2001:470:c8f4:0:200:ff:fe00:8]) by triton.sigsegv.be (Postfix) with SMTP id 5444C1C1EC; Tue, 26 Oct 2010 23:20:00 +0200 (CEST) Received: by nereid (sSMTP sendmail emulation); Tue, 26 Oct 2010 23:19:59 +0200 Date: Tue, 26 Oct 2010 23:19:59 +0200 From: Kristof Provost To: Milan Obuch Message-ID: <20101026211958.GC24690@nereid> References: <201010202309.40148.freebsd-arm@dino.sk> <201010242322.35909.freebsd-arm@dino.sk> <20101025201726.GB24690@nereid> <201010262200.09364.freebsd-arm@dino.sk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201010262200.09364.freebsd-arm@dino.sk> X-PGP-Fingerprint: 6B6E 5EED 8ECF FAE7 1F61 7458 5046 7D0E 11B0 0EE8 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-arm@freebsd.org Subject: Re: Guruplug Server Plus working to some extent... X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 21:20:04 -0000 On 2010-10-26 22:00:07 (+0200), Milan Obuch wrote: > Well, 'makeoptions DEBUG' just creates kernel.symbols, nothing else... there > must be some other way to create more debug output, but I did not find it. If > I could convert elf-structured ubldr to binary ubldr.bin, maybe I can boot > kernel with verbose output... but I did not find the way to do it. (Any hint > on this?) > I mostly wanted to see the debug print statements in the simplebus code. I think you need to set 'options DEBUG=1' in the config file to get them. I seem to remember making a few changes in other parts of the code to get that to build though. In any case, what I wanted to see is already printed in the boot log. Both mge interfaces are using the correct memory locatins (0xf1076000 for mge1) and the correct PHY numbers. Did you statically configure the mac addresses in the DTS for this boot? Regards, Kristof From owner-freebsd-arm@FreeBSD.ORG Wed Oct 27 14:56:35 2010 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A88F106566C for ; Wed, 27 Oct 2010 14:56:35 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from loki.netlab.sk (ns3.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 034488FC16 for ; Wed, 27 Oct 2010 14:56:33 +0000 (UTC) Received: from door.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Wed, 27 Oct 2010 16:57:22 +0200 id 00033C0A.4CC83DD2.00002115 From: Milan Obuch To: Kristof Provost Date: Wed, 27 Oct 2010 16:56:51 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.5.2; i386; ; ) References: <201010202309.40148.freebsd-arm@dino.sk> <201010262200.09364.freebsd-arm@dino.sk> <20101026211958.GC24690@nereid> In-Reply-To: <20101026211958.GC24690@nereid> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010271656.53245.freebsd-arm@dino.sk> Cc: freebsd-arm@freebsd.org Subject: Re: Guruplug Server Plus working to some extent... X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 14:56:35 -0000 On Tuesday 26 October 2010 23:19:59 Kristof Provost wrote: > On 2010-10-26 22:00:07 (+0200), Milan Obuch wrote: > > Well, 'makeoptions DEBUG' just creates kernel.symbols, nothing else... > > there must be some other way to create more debug output, but I did not > > find it. If I could convert elf-structured ubldr to binary ubldr.bin, > > maybe I can boot kernel with verbose output... but I did not find the > > way to do it. (Any hint on this?) > > I mostly wanted to see the debug print statements in the simplebus code. > I think you need to set 'options DEBUG=1' in the config file to get > them. I seem to remember making a few changes in other parts of the code > to get that to build though. > OK, I am trying... but there is something a bit strange in sys/dev/fdt/fdtbus.c, lines 49 and 50: #define DEBUG #undef DEBUG I commented #undef out for now, rebuild kernel, but all I get from this new is newbus_device_from_fdt_node(): skipping instantiating FDT device='aliases' newbus_device_create(): added child name='cpus', node=0xc0a790c0 newbus_device_from_fdt_node(): skipping instantiating FDT device='memory' newbus_device_create(): added child name='localbus@f1000000', node=0xc0a791e0 newbus_device_create(): added child name='soc88f6281@f1000000', node=0xc0a79444 newbus_device_create(): added child name='sram@fd000000', node=0xc0a79d90 newbus_device_from_fdt_node(): skipping instantiating FDT device='chosen' simplebus0: on fdtbus0 at the beginning of the boot instead of just the last line. Nothing new telling anything about mge1... > In any case, what I wanted to see is already printed in the boot log. > Both mge interfaces are using the correct memory locatins (0xf1076000 > for mge1) and the correct PHY numbers. > > Did you statically configure the mac addresses in the DTS for this boot? > Yes. Without that, ether addres did not initialize and needs to be set manually. However, after looking over older mails again and trying to look at it from the other side, I found the reason. I am going to write a follow-up explaining the whole issue and how succesfully solved the problem... please wait a bit, something unrelated needs to be done now... Regards, Milan From owner-freebsd-arm@FreeBSD.ORG Wed Oct 27 16:44:28 2010 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F8FD106564A for ; Wed, 27 Oct 2010 16:44:28 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id B364F8FC13 for ; Wed, 27 Oct 2010 16:44:27 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 399EBC3BDB; Wed, 27 Oct 2010 18:44:25 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id G1RMiPdBfXQz; Wed, 27 Oct 2010 18:44:24 +0200 (CEST) Received: from [10.0.0.79] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 6B13FC3BAF; Wed, 27 Oct 2010 18:44:24 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Rafal Jaworowski In-Reply-To: <201010271656.53245.freebsd-arm@dino.sk> Date: Wed, 27 Oct 2010 18:44:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7C9980A5-1812-4162-82E0-2374EACFA24A@semihalf.com> References: <201010202309.40148.freebsd-arm@dino.sk> <201010262200.09364.freebsd-arm@dino.sk> <20101026211958.GC24690@nereid> <201010271656.53245.freebsd-arm@dino.sk> To: Milan Obuch X-Mailer: Apple Mail (2.1081) Cc: freebsd-arm@freebsd.org Subject: Re: Guruplug Server Plus working to some extent... X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 16:44:28 -0000 On 2010-10-27, at 16:56, Milan Obuch wrote: > On Tuesday 26 October 2010 23:19:59 Kristof Provost wrote: >> On 2010-10-26 22:00:07 (+0200), Milan Obuch = wrote: >>> Well, 'makeoptions DEBUG' just creates kernel.symbols, nothing = else... >>> there must be some other way to create more debug output, but I did = not >>> find it. If I could convert elf-structured ubldr to binary = ubldr.bin, >>> maybe I can boot kernel with verbose output... but I did not find = the >>> way to do it. (Any hint on this?) >>=20 >> I mostly wanted to see the debug print statements in the simplebus = code. >> I think you need to set 'options DEBUG=3D1' in the config file to get >> them. I seem to remember making a few changes in other parts of the = code >> to get that to build though. >>=20 >=20 > OK, I am trying... but there is something a bit strange in=20 > sys/dev/fdt/fdtbus.c, lines 49 and 50: >=20 > #define DEBUG > #undef DEBUG >=20 > I commented #undef out for now, rebuild kernel, but all I get from = this new is >=20 > newbus_device_from_fdt_node(): skipping instantiating FDT = device=3D'aliases' > newbus_device_create(): added child name=3D'cpus', node=3D0xc0a790c0 > newbus_device_from_fdt_node(): skipping instantiating FDT = device=3D'memory' > newbus_device_create(): added child name=3D'localbus@f1000000', = node=3D0xc0a791e0 > newbus_device_create(): added child name=3D'soc88f6281@f1000000',=20 > node=3D0xc0a79444 > newbus_device_create(): added child name=3D'sram@fd000000', = node=3D0xc0a79d90 > newbus_device_from_fdt_node(): skipping instantiating FDT = device=3D'chosen' > simplebus0: on fdtbus0 >=20 > at the beginning of the boot instead of just the last line. Nothing = new=20 > telling anything about mge1... >=20 >> In any case, what I wanted to see is already printed in the boot log. >> Both mge interfaces are using the correct memory locatins (0xf1076000 >> for mge1) and the correct PHY numbers. >>=20 >> Did you statically configure the mac addresses in the DTS for this = boot? >>=20 >=20 > Yes. Without that, ether addres did not initialize and needs to be set=20= > manually. >=20 > However, after looking over older mails again and trying to look at it = from=20 > the other side, I found the reason. I am going to write a follow-up = explaining=20 > the whole issue and how succesfully solved the problem... please wait = a bit,=20 > something unrelated needs to be done now... Have you got your MPP settings sorted out correctly? The second GE unit = connections are multiplexed with other functions of the SOC and won't = work without proper set-up, see the hardware spec and the description of = MPP bindings in the DTS sys/boot/fdt/dts/bindings-mpp.txt Rafal From owner-freebsd-arm@FreeBSD.ORG Wed Oct 27 20:59:27 2010 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 993BF106564A for ; Wed, 27 Oct 2010 20:59:27 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from loki.netlab.sk (ns3.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id C5C1B8FC14 for ; Wed, 27 Oct 2010 20:59:26 +0000 (UTC) Received: from door.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Wed, 27 Oct 2010 23:00:12 +0200 id 00033C0A.4CC892DC.000038CD From: Milan Obuch To: Rafal Jaworowski Date: Wed, 27 Oct 2010 22:59:34 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.5.2; i386; ; ) References: <201010202309.40148.freebsd-arm@dino.sk> <201010271656.53245.freebsd-arm@dino.sk> <7C9980A5-1812-4162-82E0-2374EACFA24A@semihalf.com> In-Reply-To: <7C9980A5-1812-4162-82E0-2374EACFA24A@semihalf.com> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_3KJyMswB+YCmZAJ" Message-Id: <201010272259.36319.freebsd-arm@dino.sk> Cc: freebsd-arm@freebsd.org Subject: Re: Guruplug Server Plus working to some extent... [mge1 problem SOLVED] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 20:59:27 -0000 --Boundary-00=_3KJyMswB+YCmZAJ Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit On Wednesday 27 October 2010 18:44:23 Rafal Jaworowski wrote: > On 2010-10-27, at 16:56, Milan Obuch wrote: > > On Tuesday 26 October 2010 23:19:59 Kristof Provost wrote: [snip] > >> In any case, what I wanted to see is already printed in the boot log. > >> Both mge interfaces are using the correct memory locatins (0xf1076000 > >> for mge1) and the correct PHY numbers. > >> > >> Did you statically configure the mac addresses in the DTS for this boot? > > > > Yes. Without that, ether addres did not initialize and needs to be set > > manually. > > > > However, after looking over older mails again and trying to look at it > > from the other side, I found the reason. I am going to write a follow-up > > explaining the whole issue and how succesfully solved the problem... > > please wait a bit, something unrelated needs to be done now... > > Have you got your MPP settings sorted out correctly? The second GE unit > connections are multiplexed with other functions of the SOC and won't work > without proper set-up, see the hardware spec and the description of MPP > bindings in the DTS sys/boot/fdt/dts/bindings-mpp.txt > Exactly this was the reason, however file you mentioned was not that helpfull for me... but looking at dts for OpenRD client and hardware spec for 88F6281 I got the idea and after looking a bit at linux sources for guruplug server I modified my dts and this also explain why frames could be received before and not sent - all pins set as gpio are inputs in a way, thus reading worked, but controller output was not connected to phy, so in effect tcpdump saw input and frames to be sent, but tha's on chip, and they did not get out of chip. That's it for theory, and now some summary - I am attaching patches I used for Guruplug to work, collected from older mails. Patch for mvwin.h and ehci_mv.c are necessary for USB to work correctly. I mentioned them in my first mail dated October 20, 2010, original source is mail from Johny Mattsson dated September 18, 2010. Patch for if_mge.c makes it unnecessary to specify phy handle in dts and probes them automatically, originally in mail from Norikatsu Shigemura dated June 20, 2010. I modified it a bit to account for changes in sources in between. For kernel config see my first mail. New dts is attached here. One issue still remains - mge1 has no unique ether address, all-zero is set upon reboot unless explicitly set in dts. This is small issue for me, need not be resolved urgently. A bit more important problem is gpio - I have line gpio0: mem 0xf1010100-0xf101011f irq 35,36,37,38,39,40,41 on simplebus0 in boot log/dmesg output, yet there is no /dev/gpio file of similar usable with gpioctl. Some LEDs are connected to gpio pins, some pins are accessible through u-snap connector and thus are interesting for I/O... Any hint here? Regards, Milan --Boundary-00=_3KJyMswB+YCmZAJ Content-Type: text/plain; charset="iso-8859-1"; name="patch-sys::arm::mv::mvwin.h" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="patch-sys::arm::mv::mvwin.h" --- sys/arm/mv/mvwin.h.orig 2010-06-13 15:28:53.000000000 +0200 +++ sys/arm/mv/mvwin.h 2010-10-18 23:20:27.000000000 +0200 @@ -138,8 +138,8 @@ #define MV_WIN_CESA_ATTR 0 #endif -#define MV_WIN_USB_CTRL(n) (0x10 * (n) + 0x0) -#define MV_WIN_USB_BASE(n) (0x10 * (n) + 0x4) +#define MV_WIN_USB_CTRL(n) (0x10 * (n) + 0x320) +#define MV_WIN_USB_BASE(n) (0x10 * (n) + 0x324) #define MV_WIN_USB_MAX 4 #define MV_WIN_ETH_BASE(n) (0x8 * (n) + 0x200) --Boundary-00=_3KJyMswB+YCmZAJ Content-Type: text/plain; charset="iso-8859-1"; name="patch-sys::dev::usb::controller::ehci_mv.c" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="patch-sys::dev::usb::controller::ehci_mv.c" --- sys/dev/usb/controller/ehci_mv.c.orig 2010-06-13 15:28:53.000000000 +0200 +++ sys/dev/usb/controller/ehci_mv.c 2010-10-18 23:23:08.000000000 +0200 @@ -96,6 +96,7 @@ #define USB_BRIDGE_INTR_CAUSE 0x210 #define USB_BRIDGE_INTR_MASK 0x214 +#define USB_BRIDGE_ERR_ADDR 0x21C #define MV_USB_ADDR_DECODE_ERR (1 << 0) #define MV_USB_HOST_UNDERFLOW (1 << 1) @@ -360,6 +361,21 @@ printf("IRQ ERR: Unknown error\n"); EWRITE4(sc, USB_BRIDGE_INTR_CAUSE, 0); + + /* + * In case of an address decode error, we must read from + * the USB_BRIDGE_ERR_ADDR register to clear it to allow + * the controller to latch a new address in next time this + * error occurs. If we don't read it, we get the interrupt + * reissued ad infinitum, even though we have cleared the + * interrupt cause. + */ + if (cause & MV_USB_ADDR_DECODE_ERR) + { + unsigned erraddr = EREAD4(sc, USB_BRIDGE_ERR_ADDR); + printf("IRQ ERR: USB Bridge Error Address: 0x%08x\n", + erraddr); + } } return (FILTER_HANDLED); } --Boundary-00=_3KJyMswB+YCmZAJ Content-Type: text/plain; charset="iso-8859-1"; name="patch-sys::dev::mge::if_mge.c" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="patch-sys::dev::mge::if_mge.c" --- sys/dev/mge/if_mge.c.orig 2010-10-15 16:52:11.000000000 +0200 +++ sys/dev/mge/if_mge.c 2010-10-27 08:53:31.000000000 +0200 @@ -626,7 +626,6 @@ mge_attach(device_t dev) { struct mge_softc *sc; - struct mii_softc *miisc; struct ifnet *ifp; uint8_t hwaddr[ETHER_ADDR_LEN]; int i, error, phy; @@ -643,7 +642,7 @@ /* Get phy address from fdt */ if (fdt_get_phyaddr(sc->node, &phy) != 0) - return (ENXIO); + phy = -1; /* Initialize mutexes */ mtx_init(&sc->transmit_lock, device_get_nameunit(dev), "mge TX lock", MTX_DEF); @@ -674,6 +673,9 @@ sc->tx_ic_time = 768; mge_add_sysctls(sc); + if (phy == -1) + phy = MGE_READ(sc, MGE_REG_PHYDEV); + /* Allocate network interface */ ifp = sc->ifp = if_alloc(IFT_ETHER); if (ifp == NULL) { @@ -717,8 +719,7 @@ sc->mii = device_get_softc(sc->miibus); /* Tell the MAC where to find the PHY so autoneg works */ - miisc = LIST_FIRST(&sc->mii->mii_phys); - MGE_WRITE(sc, MGE_REG_PHYDEV, miisc->mii_phy); + MGE_WRITE(sc, MGE_REG_PHYDEV, phy); /* Attach interrupt handlers */ for (i = 0; i < 2; ++i) { @@ -868,7 +869,7 @@ struct mge_softc *sc = arg; struct mge_desc_wrapper *dw; volatile uint32_t reg_val; - int i, count; + int i; MGE_GLOBAL_LOCK_ASSERT(sc); @@ -949,17 +950,6 @@ reg_val = MGE_READ(sc, MGE_PORT_SERIAL_CTRL); reg_val |= PORT_SERIAL_ENABLE; MGE_WRITE(sc, MGE_PORT_SERIAL_CTRL, reg_val); - count = 0x100000; - for (;;) { - reg_val = MGE_READ(sc, MGE_PORT_STATUS); - if (reg_val & MGE_STATUS_LINKUP) - break; - DELAY(100); - if (--count == 0) { - if_printf(sc->ifp, "Timeout on link-up\n"); - break; - } - } /* Setup interrupts coalescing */ mge_set_rxic(sc); @@ -1484,8 +1474,8 @@ MGE_TRANSMIT_LOCK_ASSERT(sc); - if ((ifp->if_drv_flags & (IFF_DRV_RUNNING | IFF_DRV_OACTIVE)) != - IFF_DRV_RUNNING) + if (IFM_SUBTYPE(sc->mii->mii_media_active) == IFM_NONE || + (ifp->if_drv_flags & (IFF_DRV_RUNNING | IFF_DRV_OACTIVE)) != IFF_DRV_RUNNING) return; for (;;) { --Boundary-00=_3KJyMswB+YCmZAJ Content-Type: text/plain; charset="iso-8859-1"; name="guruplugplus.dts" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="guruplugplus.dts" /* * Copyright (c) 2010 The FreeBSD Foundation * All rights reserved. * * This software was developed by Semihalf under sponsorship from * the FreeBSD Foundation. * * 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. * * Marvell SheevaPlug Device Tree Source. * *** modified for Guruplug server plus *** * * $FreeBSD$ */ /dts-v1/; / { model = "mrvl,GuruPlugPlus"; compatible = "GuruPlugPlus"; #address-cells = <1>; #size-cells = <1>; aliases { ethernet0 = &enet0; ethernet1 = &enet1; mpp = &MPP; serial0 = &serial0; serial1 = &serial1; soc = &SOC; sram = &SRAM; }; cpus { #address-cells = <1>; #size-cells = <0>; cpu@0 { device_type = "cpu"; compatible = "ARM,88FR131"; reg = <0x0>; d-cache-line-size = <32>; // 32 bytes i-cache-line-size = <32>; // 32 bytes d-cache-size = <0x4000>; // L1, 16K i-cache-size = <0x4000>; // L1, 16K timebase-frequency = <0>; bus-frequency = <0>; clock-frequency = <0>; }; }; memory { device_type = "memory"; reg = <0x0 0x20000000>; // 512M at 0x0 }; localbus@f1000000 { #address-cells = <2>; #size-cells = <1>; compatible = "mrvl,lbc"; /* This reflects CPU decode windows setup. */ ranges = <0x0 0x0f 0xf9300000 0x00100000 0x1 0x1e 0xfa000000 0x00100000 0x2 0x1d 0xfa100000 0x02000000 0x3 0x1b 0xfc100000 0x00000400>; nor@0,0 { #address-cells = <1>; #size-cells = <1>; compatible = "cfi-flash"; reg = <0x0 0x0 0x00100000>; bank-width = <2>; device-width = <1>; }; led@1,0 { #address-cells = <1>; #size-cells = <1>; compatible = "led"; reg = <0x1 0x0 0x00100000>; }; nor@2,0 { #address-cells = <1>; #size-cells = <1>; compatible = "cfi-flash"; reg = <0x2 0x0 0x02000000>; bank-width = <2>; device-width = <1>; }; nand@3,0 { #address-cells = <1>; #size-cells = <1>; reg = <0x3 0x0 0x00100000>; bank-width = <2>; device-width = <1>; }; }; SOC: soc88f6281@f1000000 { #address-cells = <1>; #size-cells = <1>; compatible = "simple-bus"; ranges = <0x0 0xf1000000 0x00100000>; bus-frequency = <0>; PIC: pic@20200 { interrupt-controller; #address-cells = <0>; #interrupt-cells = <1>; reg = <0x20200 0x3c>; compatible = "mrvl,pic"; }; timer@20300 { compatible = "mrvl,timer"; reg = <0x20300 0x30>; interrupts = <1>; interrupt-parent = <&PIC>; mrvl,has-wdt; }; MPP: mpp@10000 { #pin-cells = <2>; compatible = "mrvl,mpp"; reg = <0x10000 0x34>; pin-count = <50>; pin-map = < 0 1 /* MPP[0]: NF_IO[2] */ 1 1 /* MPP[1]: NF_IO[3] */ 2 1 /* MPP[2]: NF_IO[4] */ 3 1 /* MPP[3]: NF_IO[5] */ 4 1 /* MPP[4]: NF_IO[6] */ 5 1 /* MPP[5]: NF_IO[7] */ 6 1 /* MPP[6]: SYSRST_OUTn */ 7 0 /* MPP[7]: GPO[7] */ 8 1 /* MPP[8]: TW_SDA */ 9 1 /* MPP[9]: TW_SCK */ 10 3 /* MPP[10]: UA0_TXD */ 11 3 /* MPP[11]: UA0_RXD */ 12 1 /* MPP[12]: SD_CLK */ 13 1 /* MPP[13]: SD_CMD */ 14 1 /* MPP[14]: SD_D[0] */ 15 1 /* MPP[15]: SD_D[1] */ 16 1 /* MPP[16]: SD_D[2] */ 17 1 /* MPP[17]: SD_D[3] */ 18 1 /* MPP[18]: NF_IO[0] */ 19 1 /* MPP[19]: NF_IO[1] */ 20 3 /* MPP[20]: GE1[0] */ 21 3 /* MPP[21]: GE1[1] */ 22 3 /* MPP[22]: GE1[2] */ 23 3 /* MPP[23]: GE1[3] */ 24 3 /* MPP[24]: GE1[4] */ 25 3 /* MPP[25]: GE1[5] */ 26 3 /* MPP[26]: GE1[6] */ 27 3 /* MPP[27]: GE1[7] */ 28 0 /* MPP[28]: GPIO[28] */ 29 1 /* MPP[29]: TSMP[9] */ 30 3 /* MPP[30]: GE1[10] */ 31 3 /* MPP[31]: GE1[11] */ 32 3 /* MPP[32]: GE1[12] */ 33 3 /* MPP[33]: GE1[13] */ 34 0 /* MPP[34]: GPIO[34] */ 35 2 /* MPP[35]: TDM_CH0_TX_QL */ 36 2 /* MPP[36]: TDM_SPI_CS1 */ 37 2 /* MPP[37]: TDM_CH2_TX_QL */ 38 0 /* MPP[38]: GPIO[38] */ 39 0 /* MPP[39]: GPIO[39] */ 40 0 /* MPP[40]: GPIO[40] */ 41 0 /* MPP[41]: GPIO[41] */ 42 0 /* MPP[42]: GPIO[42] */ 43 0 /* MPP[43]: GPIO[43] */ 44 4 /* MPP[44]: AU_EXTCLK */ 45 2 /* MPP[45]: TDM_PCLK */ 46 0 /* MPP[46]: GPIO[46] */ 47 0 /* MPP[47]: GPIO[47] */ 48 0 /* MPP[48]: GPIO[48] */ 49 0 /* MPP[49]: GPIO[49] */ >; }; GPIO: gpio@10100 { #gpio-cells = <3>; compatible = "mrvl,gpio"; reg = <0x10100 0x20>; gpio-controller; interrupts = <35 36 37 38 39 40 41>; interrupt-parent = <&PIC>; }; rtc@10300 { compatible = "mrvl,rtc"; reg = <0x10300 0x08>; }; twsi@11000 { #address-cells = <1>; #size-cells = <0>; compatible = "mrvl,twsi"; reg = <0x11000 0x20>; interrupts = <43>; interrupt-parent = <&PIC>; }; enet0: ethernet@72000 { #address-cells = <1>; #size-cells = <1>; model = "V2"; compatible = "mrvl,ge"; reg = <0x72000 0x2000>; ranges = <0x0 0x72000 0x2000>; local-mac-address = [ 00 00 00 00 00 00 ]; interrupts = <12 13 14 11 46>; interrupt-parent = <&PIC>; mdio@0 { #address-cells = <1>; #size-cells = <0>; compatible = "mrvl,mdio"; }; }; enet1: ethernet@76000 { #address-cells = <1>; #size-cells = <1>; model = "V2"; compatible = "mrvl,ge"; reg = <0x76000 0x2000>; ranges = <0x0 0x76000 0x2000>; local-mac-address = [ 00 00 00 00 00 00 ]; interrupts = <16 17 18 15 47>; interrupt-parent = <&PIC>; mdio@1 { #address-cells = <1>; #size-cells = <0>; compatible = "mrvl,mdio"; }; }; serial0: serial@12000 { compatible = "ns16550"; reg = <0x12000 0x20>; reg-shift = <2>; clock-frequency = <0>; interrupts = <33>; interrupt-parent = <&PIC>; }; serial1: serial@12100 { compatible = "ns16550"; reg = <0x12100 0x20>; reg-shift = <2>; clock-frequency = <0>; interrupts = <34>; interrupt-parent = <&PIC>; }; crypto@30000 { compatible = "mrvl,cesa"; reg = <0x30000 0x10000>; interrupts = <22>; interrupt-parent = <&PIC>; }; usb@50000 { compatible = "mrvl,usb-ehci", "usb-ehci"; reg = <0x50000 0x1000>; interrupts = <48 19>; interrupt-parent = <&PIC>; }; xor@60000 { compatible = "mrvl,xor"; reg = <0x60000 0x1000>; interrupts = <5 6 7 8>; interrupt-parent = <&PIC>; }; sata@80000 { compatible = "mrvl,sata"; reg = <0x80000 0x6000>; interrupts = <21>; interrupt-parent = <&PIC>; }; }; SRAM: sram@fd000000 { compatible = "mrvl,cesa-sram"; reg = <0xfd000000 0x00100000>; }; chosen { stdin = "serial0"; stdout = "serial0"; }; }; --Boundary-00=_3KJyMswB+YCmZAJ-- From owner-freebsd-arm@FreeBSD.ORG Fri Oct 29 22:36:57 2010 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95F351065695 for ; Fri, 29 Oct 2010 22:36:57 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from loki.netlab.sk (ns3.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 2950A8FC39 for ; Fri, 29 Oct 2010 22:36:56 +0000 (UTC) Received: from door.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Sat, 30 Oct 2010 00:37:31 +0200 id 00033C0A.4CCB4CAB.0000F3B7 From: Milan Obuch To: freebsd-arm@freebsd.org Date: Sat, 30 Oct 2010 00:37:01 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.5.2; i386; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201010300037.03374.freebsd-arm@dino.sk> Subject: Guruplug gpio X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 22:36:57 -0000 Hi, after solving mge1 problem I decided to work a bit with Guruplug's gpio. There are some of them accessible via u-snap connector and some of them are used to controll status LEDs. there is some description in file bindings-gpio.txt, but I did not find something used in dts files, so I only guessed gpios could be defined the following way: GPIO: gpio@10100 {#gpio-cells = <3>; compatible = "mrvl,gpio"; reg = <0x10100 0x20>; gpio-controller; interrupts = <35 36 37 38 39 40 41>; interrupt-parent = <&PIC>; gpios = <&GPIO 46 2 0x00000000 /* GPIO[46]: OUT */ &GPIO 47 2 0x00000000 /* GPIO[47]: OUT */ &GPIO 48 2 0x00000000 /* GPIO[48]: OUT */ &GPIO 49 2 0x00000000 /* GPIO[49]: OUT */ >; }; However, if I add this definition to dts and rebuild kernel, it does not work and hangs with no sign of beginning to run. With some investigation I found function platform_gpio_init does something bad and loops. There is nothing written to console even. So either I did not understand the way how gpios should be defined (possible, since I did not find complete example) or platform_gpio_init does something unintended... If I delete gpios definition, everything is back to normal and kernel boots and works as before. If I comment out platform_gpio_init call, then again everything works. Anybody out there who could tell me what I did wrong? Any hint appreciated... Regards, Milan From owner-freebsd-arm@FreeBSD.ORG Sat Oct 30 01:37:55 2010 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CEEB1065673 for ; Sat, 30 Oct 2010 01:37:55 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id F40D88FC15 for ; Sat, 30 Oct 2010 01:37:54 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o9U1J2Lr084654; Fri, 29 Oct 2010 21:19:02 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o9U1J2cE084653; Sat, 30 Oct 2010 01:19:02 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 30 Oct 2010 01:19:02 GMT Message-Id: <201010300119.o9U1J2cE084653@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 01:37:55 -0000 TB --- 2010-10-29 21:15:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-10-29 21:15:00 - starting HEAD tinderbox run for arm/arm TB --- 2010-10-29 21:15:00 - cleaning the object tree TB --- 2010-10-29 21:17:10 - cvsupping the source tree TB --- 2010-10-29 21:17:10 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2010-10-29 21:23:03 - building world TB --- 2010-10-29 21:23:03 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-29 21:23:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-29 21:23:03 - TARGET=arm TB --- 2010-10-29 21:23:03 - TARGET_ARCH=arm TB --- 2010-10-29 21:23:03 - TZ=UTC TB --- 2010-10-29 21:23:03 - __MAKE_CONF=/dev/null TB --- 2010-10-29 21:23:03 - cd /src TB --- 2010-10-29 21:23:03 - /usr/bin/make -B buildworld >>> World build started on Fri Oct 29 21:23:05 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] ===> sbin/ipf/ipf (all) cc -O -pipe -I. -DIPFILTER_BPF -I/src/sbin/ipf/ipf/../../../contrib/ipfilter -I/src/sbin/ipf/ipf/../../../contrib/ipfilter/tools -I/src/sbin/ipf/ipf/../../../sys -I/src/sbin/ipf/ipf/../../../sys/contrib/ipfilter -DSTATETOP -D__UIO_EXPOSE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/ipf/ipf/../../../contrib/ipfilter/tools/ipf.c cc -O -pipe -I. -DIPFILTER_BPF -I/src/sbin/ipf/ipf/../../../contrib/ipfilter -I/src/sbin/ipf/ipf/../../../contrib/ipfilter/tools -I/src/sbin/ipf/ipf/../../../sys -I/src/sbin/ipf/ipf/../../../sys/contrib/ipfilter -DSTATETOP -D__UIO_EXPOSE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/ipf/ipf/../../../contrib/ipfilter/tools/ipfcomp.c cc -O -pipe -I. -DIPFILTER_BPF -I/src/sbin/ipf/ipf/../../../contrib/ipfilter -I/src/sbin/ipf/ipf/../../../contrib/ipfilter/tools -I/src/sbin/ipf/ipf/../../../sys -I/src/sbin/ipf/ipf/../../../sys/contrib/ipfilter -DSTATETOP -D__UIO_EXPOSE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c ipf_y.c In file included from /obj/arm.arm/src/tmp/usr/include/pcap.h:45, from /src/sbin/ipf/ipf/../../../contrib/ipfilter/tools/ipf_y.y:15: /obj/arm.arm/src/tmp/usr/include/pcap/pcap.h:351: error: conflicting types for 'bpf_validate' /src/sbin/ipf/ipf/../../../contrib/ipfilter/pcap-bpf.h:671: error: previous declaration of 'bpf_validate' was here *** Error code 1 Stop in /src/sbin/ipf/ipf. *** Error code 1 Stop in /src/sbin/ipf. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-10-30 01:19:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-10-30 01:19:02 - ERROR: failed to build world TB --- 2010-10-30 01:19:02 - 2099.44 user 8061.75 system 14641.39 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Oct 30 13:02:50 2010 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58F25106566C for ; Sat, 30 Oct 2010 13:02:50 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 7CACF8FC1B for ; Sat, 30 Oct 2010 13:02:49 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id E84F9C3BD9; Sat, 30 Oct 2010 15:02:44 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id Gf5hQhMRoJPI; Sat, 30 Oct 2010 15:02:44 +0200 (CEST) Received: from [192.168.133.14] (nat3-133.ghnet.pl [91.150.222.133]) by smtp.semihalf.com (Postfix) with ESMTPSA id ECF91C3BB6; Sat, 30 Oct 2010 15:02:43 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Rafal Jaworowski In-Reply-To: <201010272259.36319.freebsd-arm@dino.sk> Date: Sat, 30 Oct 2010 15:02:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201010202309.40148.freebsd-arm@dino.sk> <201010271656.53245.freebsd-arm@dino.sk> <7C9980A5-1812-4162-82E0-2374EACFA24A@semihalf.com> <201010272259.36319.freebsd-arm@dino.sk> To: Milan Obuch X-Mailer: Apple Mail (2.1081) Cc: freebsd-arm@freebsd.org Subject: Re: Guruplug Server Plus working to some extent... [mge1 problem SOLVED] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 13:02:50 -0000 On 2010-10-27, at 22:59, Milan Obuch wrote: > On Wednesday 27 October 2010 18:44:23 Rafal Jaworowski wrote: >> On 2010-10-27, at 16:56, Milan Obuch wrote: >>> On Tuesday 26 October 2010 23:19:59 Kristof Provost wrote: >=20 > [snip] >=20 >>>> In any case, what I wanted to see is already printed in the boot = log. >>>> Both mge interfaces are using the correct memory locatins = (0xf1076000 >>>> for mge1) and the correct PHY numbers. >>>>=20 >>>> Did you statically configure the mac addresses in the DTS for this = boot? >>>=20 >>> Yes. Without that, ether addres did not initialize and needs to be = set >>> manually. >>>=20 >>> However, after looking over older mails again and trying to look at = it >>> from the other side, I found the reason. I am going to write a = follow-up >>> explaining the whole issue and how succesfully solved the problem... >>> please wait a bit, something unrelated needs to be done now... >>=20 >> Have you got your MPP settings sorted out correctly? The second GE = unit >> connections are multiplexed with other functions of the SOC and won't = work >> without proper set-up, see the hardware spec and the description of = MPP >> bindings in the DTS sys/boot/fdt/dts/bindings-mpp.txt >>=20 >=20 > Exactly this was the reason, however file you mentioned was not that = helpfull=20 > for me... but looking at dts for OpenRD client and hardware spec for = 88F6281 I=20 > got the idea and after looking a bit at linux sources for guruplug = server I=20 > modified my dts and this also explain why frames could be received = before and=20 > not sent - all pins set as gpio are inputs in a way, thus reading = worked, but=20 > controller output was not connected to phy, so in effect tcpdump saw = input and=20 > frames to be sent, but tha's on chip, and they did not get out of = chip. >=20 > That's it for theory, and now some summary - I am attaching patches I = used for=20 > Guruplug to work, collected from older mails. Patch for mvwin.h and = ehci_mv.c=20 > are necessary for USB to work correctly. I mentioned them in my first = mail=20 > dated October 20, 2010, original source is mail from Johny Mattsson = dated=20 > September 18, 2010. Patch for if_mge.c makes it unnecessary to specify = phy=20 > handle in dts and probes them automatically, originally in mail from = Norikatsu=20 > Shigemura dated June 20, 2010. I modified it a bit to account for = changes in=20 > sources in between. >=20 > For kernel config see my first mail. New dts is attached here. >=20 > One issue still remains - mge1 has no unique ether address, all-zero = is set=20 > upon reboot unless explicitly set in dts. This is small issue for me, = need not=20 > be resolved urgently. This issue is not easily resolved in general. U-Boot would only = initialize MAC address in registers of an Ethernet controller, which was = used at least once. If an Ethernet controller unit is not used at the = U-Boot stage its MAC address registers remain uninitialized. Now, in our = case the OS can only learn about MAC address either from DT or (in case = there are all 0's) fall back to whatever was set by the firmware. The situation can be handled in a bit more robust way when FreeBSD = loader(8) is used as the last stage bootloader: it is able to retrieve = MAC address from U-Boot env variables and could adjust in run time = appropriate DTS nodes with values read out from the env vars regardless = if a given Ethernet unit was ever used by U-Boot and its MAC address = regs got set. Such a feature is not implemented yet and requires some = small extension to the loader(8). Note however that in order to run = loader(8) you need an API-enabled U-Boot underneath (built with = CONFIG_API). > A bit more important problem is gpio - I have line >=20 > gpio0: mem 0xf1010100-0xf101011f = irq=20 > 35,36,37,38,39,40,41 on simplebus0 >=20 > in boot log/dmesg output, yet there is no /dev/gpio file of similar = usable=20 > with gpioctl. Some LEDs are connected to gpio pins, some pins are = accessible=20 > through u-snap connector and thus are interesting for I/O... Any hint = here? This will not work at the moment: the gpio driver for Marvell SOC does = not yet have a back-end plug in for the GPIO framework, which was = recently introduced, so you won't see /dev/gpio and the gpioctl(8) isn't = going to work.=20 Rafal From owner-freebsd-arm@FreeBSD.ORG Sat Oct 30 13:18:57 2010 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C70DD1065695 for ; Sat, 30 Oct 2010 13:18:57 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 6BB6F8FC17 for ; Sat, 30 Oct 2010 13:18:57 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 37821C3BD9; Sat, 30 Oct 2010 15:18:56 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id qctIGZLjBrbZ; Sat, 30 Oct 2010 15:18:55 +0200 (CEST) Received: from [192.168.133.14] (nat3-133.ghnet.pl [91.150.222.133]) by smtp.semihalf.com (Postfix) with ESMTPSA id 7F05CC3BB6; Sat, 30 Oct 2010 15:18:55 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Rafal Jaworowski In-Reply-To: <201010300037.03374.freebsd-arm@dino.sk> Date: Sat, 30 Oct 2010 15:18:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <90B83E3E-C1CF-4233-8813-1C652ACEF252@semihalf.com> References: <201010300037.03374.freebsd-arm@dino.sk> To: Milan Obuch X-Mailer: Apple Mail (2.1081) Cc: freebsd-arm@freebsd.org Subject: Re: Guruplug gpio X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 13:18:57 -0000 On 2010-10-30, at 00:37, Milan Obuch wrote: > Hi, >=20 > after solving mge1 problem I decided to work a bit with Guruplug's = gpio. There=20 > are some of them accessible via u-snap connector and some of them are = used to=20 > controll status LEDs. As mentioned in another email, Marvell GPIO driver does not get hooks = for the new framework, so this needs to be provided first before you'd = be able to controll LEDs from userspace etc. > there is some description in file bindings-gpio.txt, but I did not = find=20 > something used in dts files, so I only guessed gpios could be defined = the=20 > following way: >=20 > GPIO: gpio@10100 = = =20 > {#gpio-cells =3D <3>; > compatible =3D "mrvl,gpio"; > reg =3D <0x10100 0x20>; > gpio-controller; > interrupts =3D <35 36 37 38 39 40 41>; > interrupt-parent =3D <&PIC>; > gpios =3D > <&GPIO 46 2 0x00000000 /* GPIO[46]: OUT */ = =20= > &GPIO 47 2 0x00000000 /* GPIO[47]: OUT */ = =20= > &GPIO 48 2 0x00000000 /* GPIO[48]: OUT */ = =20= > &GPIO 49 2 0x00000000 /* GPIO[49]: OUT */ = =20= >> ; > }; The "gpios" property cannot be part of the GPIO controller node -- it = belongs to the node, which is a consumer of GPIO lines which belong to = some GPIO controller. For example, when PCI IRQs are routed through GPIO = lines: it is the PCI node that should contain the "gpios" prop = referencing their parent GPIO controller and specifying which GPIO lines = are used and how they are configured (polarity, trigger and other = attributes). Rafal From owner-freebsd-arm@FreeBSD.ORG Sat Oct 30 17:00:44 2010 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62F5B106566B for ; Sat, 30 Oct 2010 17:00:44 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from loki.netlab.sk (ns3.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 25C1E8FC17 for ; Sat, 30 Oct 2010 17:00:43 +0000 (UTC) Received: from door.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Sat, 30 Oct 2010 19:01:13 +0200 id 00033C07.4CCC4F59.000127C2 From: Milan Obuch To: Rafal Jaworowski Date: Sat, 30 Oct 2010 19:00:35 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.5.2; i386; ; ) References: <201010300037.03374.freebsd-arm@dino.sk> <90B83E3E-C1CF-4233-8813-1C652ACEF252@semihalf.com> In-Reply-To: <90B83E3E-C1CF-4233-8813-1C652ACEF252@semihalf.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010301900.36922.freebsd-arm@dino.sk> Cc: freebsd-arm@freebsd.org Subject: Re: Guruplug gpio X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 17:00:44 -0000 On Saturday 30 October 2010 15:18:54 Rafal Jaworowski wrote: > On 2010-10-30, at 00:37, Milan Obuch wrote: > > Hi, > > > > after solving mge1 problem I decided to work a bit with Guruplug's gpio. > > There are some of them accessible via u-snap connector and some of them > > are used to controll status LEDs. > > As mentioned in another email, Marvell GPIO driver does not get hooks for > the new framework, so this needs to be provided first before you'd be able > to controll LEDs from userspace etc. > I see. I am going to investigate how this could be done. I did some work with GPIO based on some older work, so I just need to check the infrastructure for GPIO (gpiobus, gpio properties etc). > > there is some description in file bindings-gpio.txt, but I did not find > > something used in dts files, so I only guessed gpios could be defined the > > following way: > > > > GPIO: gpio@10100 > > {#gpio-cells = <3>; > > > > compatible = "mrvl,gpio"; > > reg = <0x10100 0x20>; > > gpio-controller; > > interrupts = <35 36 37 38 39 40 41>; > > interrupt-parent = <&PIC>; > > gpios = > > > > <&GPIO 46 2 0x00000000 /* GPIO[46]: OUT */ > > > > &GPIO 47 2 0x00000000 /* GPIO[47]: OUT */ > > &GPIO 48 2 0x00000000 /* GPIO[48]: OUT */ > > &GPIO 49 2 0x00000000 /* GPIO[49]: OUT */ > >> > >> ; > > > > }; > > The "gpios" property cannot be part of the GPIO controller node -- it > belongs to the node, which is a consumer of GPIO lines which belong to > some GPIO controller. For example, when PCI IRQs are routed through GPIO > lines: it is the PCI node that should contain the "gpios" prop referencing > their parent GPIO controller and specifying which GPIO lines are used and > how they are configured (polarity, trigger and other attributes). > Could you provide an example dts? I did not find any with gpios, so this was basically a guesswork. Regards, Milan From owner-freebsd-arm@FreeBSD.ORG Sat Oct 30 23:00:43 2010 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5207106564A for ; Sat, 30 Oct 2010 23:00:43 +0000 (UTC) (envelope-from gonzo@launchpad.bluezbox.com) Received: from launchpad.bluezbox.com (hq.bluezbox.com [70.38.37.145]) by mx1.freebsd.org (Postfix) with ESMTP id 336C78FC12 for ; Sat, 30 Oct 2010 23:00:43 +0000 (UTC) Received: from [24.87.55.58] (helo=[192.168.10.184]) by launchpad.bluezbox.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PCJkX-000OHR-9Q; Sat, 30 Oct 2010 15:18:09 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Oleksandr Tymoshenko In-Reply-To: <201010301900.36922.freebsd-arm@dino.sk> Date: Sat, 30 Oct 2010 15:17:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <04048D7D-DF99-4CC6-A4D0-C59C6BBE0DF8@bluezbox.com> References: <201010300037.03374.freebsd-arm@dino.sk> <90B83E3E-C1CF-4233-8813-1C652ACEF252@semihalf.com> <201010301900.36922.freebsd-arm@dino.sk> To: Milan Obuch X-Mailer: Apple Mail (2.1081) Sender: gonzo@launchpad.bluezbox.com X-Spam-Level: ---- X-Spam-Report: Spam detection software, running on the system "hq.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 2010-10-30, at 10:00 AM, Milan Obuch wrote: > On Saturday 30 October 2010 15:18:54 Rafal Jaworowski wrote: >> On 2010-10-30, at 00:37, Milan Obuch wrote: >>> Hi, >>> >>> after solving mge1 problem I decided to work a bit with Guruplug's gpio. >>> There are some of them accessible via u-snap connector and some of them >>> are used to controll status LEDs. >> >> As mentioned in another email, Marvell GPIO driver does not get hooks for >> the new framework, so this needs to be provided first before you'd be able >> to controll LEDs from userspace etc. >> > > I see. I am going to investigate how this could be done. I did some work with > GPIO based on some older work, so I just need to check the infrastructure for > GPIO (gpiobus, gpio properties etc). Bear in mind that GPIO framework is work ing progress and its abilities are very limited at the moment. Feel free to send patches or feature requests [...] Content analysis details: (-4.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Cc: freebsd-arm@freebsd.org Subject: Re: Guruplug gpio X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 23:00:43 -0000 On 2010-10-30, at 10:00 AM, Milan Obuch wrote: > On Saturday 30 October 2010 15:18:54 Rafal Jaworowski wrote: >> On 2010-10-30, at 00:37, Milan Obuch wrote: >>> Hi, >>>=20 >>> after solving mge1 problem I decided to work a bit with Guruplug's = gpio. >>> There are some of them accessible via u-snap connector and some of = them >>> are used to controll status LEDs. >>=20 >> As mentioned in another email, Marvell GPIO driver does not get hooks = for >> the new framework, so this needs to be provided first before you'd be = able >> to controll LEDs from userspace etc. >>=20 >=20 > I see. I am going to investigate how this could be done. I did some = work with=20 > GPIO based on some older work, so I just need to check the = infrastructure for=20 > GPIO (gpiobus, gpio properties etc). Bear in mind that GPIO framework is work ing progress and its = abilities=20 are very limited at the moment. Feel free to send patches or feature = requests=20 --=20 gonzo