From owner-freebsd-embedded@FreeBSD.ORG Sun Dec 18 02:43:46 2011 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBD77106566C for ; Sun, 18 Dec 2011 02:43:46 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 82D168FC0C for ; Sun, 18 Dec 2011 02:43:46 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so5732870vcb.13 for ; Sat, 17 Dec 2011 18:43:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+mcryZA9e7RkZN5O7ySBszXia1MOe8j/J4tOpbedA2w=; b=KpLyhm0lx7QxFtiRO5uXSEjBMiASOQQxu4XiFVtIA1IZboRSTtRHSja3n8OajHidmd wghedJY4EI3dK8caDIoN1stPZIByNdK17wctzz5btAbJ0e88SZ7kL/MHnIfkJ4igoPtY aj6sesma5MazN1+mOsPdPXan9qAGbBzMbjRDU= MIME-Version: 1.0 Received: by 10.52.67.111 with SMTP id m15mr8989301vdt.96.1324176226036; Sat, 17 Dec 2011 18:43:46 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.26.50 with HTTP; Sat, 17 Dec 2011 18:43:45 -0800 (PST) In-Reply-To: References: <0F6CC18F-6973-42A2-AC03-F01BF59458AE@lassitu.de> <1100F70E-9DA9-4163-AC9A-423ECE5AA9A3@lassitu.de> Date: Sat, 17 Dec 2011 18:43:45 -0800 X-Google-Sender-Auth: MNcaKKGqdyJxpjQaRADExhvsGCM Message-ID: From: Adrian Chadd To: Stefan Bethke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-embedded@freebsd.org" Subject: Re: Updated switch/glue patch? X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 02:43:46 -0000 On 16 December 2011 00:03, Stefan Bethke wrote: > There is one more problem which is not immediately apparent: the register= access is slooooow. =A0The rtl_tick callback that runs once a second needs= .8 seconds to complete, see sysctl debug.rtl8366rb. =A0Most of this time i= s spent in DELAY() in iicbb.c, making the system rather unresponsive. > > rtl_tick() runs mii_tick() and mii_pollstat() for all five PHYs. =A0We ca= n likely leave out mii_tick() since the built-in PHYs don't need ticks for = autonegotiation to work correctly. =A0Leaving out mii_pollstat() means that= link state changes won't be detected and reported automatically but only w= hen you run e.g. etherswitchcfg port0. > > I'm currently looking into iicbb.c, since I believe it is DELAY()ing way = too much (running at effectively 20kHz instead of 100kZh for I2C). =A0I'll = try to speed it up, since the RTL8366RB can go at least at 100kHz. I'm looking at it now. Which particular part of it is delaying too much? Each delay is only 10 microseconds, but there's a handful of these for each _bit_ being sent. This seems a bit ridiculous. What the heck should it be? There are delays for different parts of i2c - setting the data output bit, toggling the clock bit, waiting for an ACK. Should these all be tunable for each device that's on the bus? Or just set the i2c bus speed for all devices on the bus? Or both? Or neither? :) (Someone with i2c clue, please stand up! :) Adrian From owner-freebsd-embedded@FreeBSD.ORG Sun Dec 18 06:19:25 2011 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05350106566C for ; Sun, 18 Dec 2011 06:19:25 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id AB2768FC14 for ; Sun, 18 Dec 2011 06:19:24 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so5806084vcb.13 for ; Sat, 17 Dec 2011 22:19:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=dmjG5CF1MZV/QDGhOefqA71yhlUI9gVjsyt8C6tHqAY=; b=wbdst800Jbaq43bHgS8faOTgsABSgk81LzBhED00oj9en3kremkUkawJXIeeNcHgh5 GVCkH+dDdJ5/yaAvROt1SlJHwCgmvfTokGk9M/Awbi3Rp9wksMEPy2Q4TWUFxs6Zp6sB aLqaVrMy0Zgs1NrLP0dewzDwBVRDmfNq4X7B0= MIME-Version: 1.0 Received: by 10.220.230.67 with SMTP id jl3mr7136015vcb.60.1324189163869; Sat, 17 Dec 2011 22:19:23 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.26.50 with HTTP; Sat, 17 Dec 2011 22:19:23 -0800 (PST) In-Reply-To: References: <0F6CC18F-6973-42A2-AC03-F01BF59458AE@lassitu.de> <1100F70E-9DA9-4163-AC9A-423ECE5AA9A3@lassitu.de> Date: Sat, 17 Dec 2011 22:19:23 -0800 X-Google-Sender-Auth: 6tYYpk416dzUpwDaNAa_eXRtqew Message-ID: From: Adrian Chadd To: Stefan Bethke Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-embedded@freebsd.org" Subject: Re: Updated switch/glue patch? X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 06:19:25 -0000 .. also, keep in mind these configs don't currently have preemption enabled. I think that means that during DELAY(), the kernel thread doing our bitbanging is going to be spinning and not be preempted by any other process that may wish to be scheduled. Using up CPU in a busyloop is fine here (well it isn't, as it's power wasting, but that aside) but the fact that the CPU is not able to do any other real work in the meantime is annoying. Anyway, I'm fiddling with extending iicbb to have configurable bitbanging and ACK delays. The other thing you could try is to change the DELAY(10) in iicbb_ack to DELAY(1) and only increment k by one at a time. It would be nice if time-keeping was active at boot probe/attach time, so we could just use pause() and hope that is enough. But yes, time-keeping doesn't seem to be active that early. Adrian From owner-freebsd-embedded@FreeBSD.ORG Sun Dec 18 09:54:03 2011 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F999106564A for ; Sun, 18 Dec 2011 09:54:03 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id CCACA8FC0C for ; Sun, 18 Dec 2011 09:54:02 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so5881752vcb.13 for ; Sun, 18 Dec 2011 01:54:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=oCGYONzh3PzSsmXxLekN2SvCkYgYtPFGFSMuAo5rQ0k=; b=Wvt2Fv7eySqbgqcL5eAlQYIuWTAwrIBI+QPqzqHnQHggI5KK9+Eqj8HFU+ASiLSLH3 Ru1sK0RFdqkPnKEmcsFTD8JvUaloeQyY6QPsoH88FQXlnvvX4Un2urHbCBZTVjC2VxP8 DWNEIB4sGxfacEGjKfMOh8Ad54doTA40Q29gw= MIME-Version: 1.0 Received: by 10.220.151.204 with SMTP id d12mr7370444vcw.40.1324202042129; Sun, 18 Dec 2011 01:54:02 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.26.50 with HTTP; Sun, 18 Dec 2011 01:54:02 -0800 (PST) In-Reply-To: References: <0F6CC18F-6973-42A2-AC03-F01BF59458AE@lassitu.de> <1100F70E-9DA9-4163-AC9A-423ECE5AA9A3@lassitu.de> Date: Sun, 18 Dec 2011 01:54:02 -0800 X-Google-Sender-Auth: loz5k9LYg7GSy2TL-H7hoGLlQo8 Message-ID: From: Adrian Chadd To: Stefan Bethke Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-embedded@freebsd.org" Subject: Re: Updated switch/glue patch? X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 09:54:03 -0000 .. and some further digging - I've flipped on the i2c_debug value and slightly modified the debug printing so each _stop call prints a newline. It makes it very clear how transactions are being handled. Anyway, there's plenty of instances (even with the transaction DELAY being 10uS) of the last byte being not acked, ie: .. all of those read transactions that aren't acked, are they ok? Just as a side note - reducing the udelay value from 10 to 1 in my git tree doesn't stop the huge CPU use. I'm going to next try removing the locking, as I note that each GPIO access involves a mutex lock and I bet the witness code is taking a freaking beating here. adrian From owner-freebsd-embedded@FreeBSD.ORG Sun Dec 18 10:11:56 2011 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32E6A106564A; Sun, 18 Dec 2011 10:11:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id C855E8FC14; Sun, 18 Dec 2011 10:11:55 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so5922588vbb.13 for ; Sun, 18 Dec 2011 02:11:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=kF1qU4trrf85/UFdhf9Y0cwkCtZ/2CUzrF/+VRkxonk=; b=cDl3IQ8Uv0DKdeq2s2VsM0L/cLzLo+lBa9iMy0GW+7UFjHyp96b8U2wlxxrll8+9MY o/yGBFCdpOUMMCmpsIRqWH6gQMzyzhlwpx38jHm3M9Qv7vVDl9KppfjQHlKk9voMzl+O PpOEIHZdLHyat4wjJNVW/JGyV6RjEA3V25hKk= MIME-Version: 1.0 Received: by 10.52.67.111 with SMTP id m15mr9314664vdt.96.1324203115054; Sun, 18 Dec 2011 02:11:55 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.26.50 with HTTP; Sun, 18 Dec 2011 02:11:55 -0800 (PST) In-Reply-To: References: <0F6CC18F-6973-42A2-AC03-F01BF59458AE@lassitu.de> <1100F70E-9DA9-4163-AC9A-423ECE5AA9A3@lassitu.de> Date: Sun, 18 Dec 2011 02:11:55 -0800 X-Google-Sender-Auth: tcB9fISVbYyE_cUjoDW5xhr1yPk Message-ID: From: Adrian Chadd To: Stefan Bethke , Oleksandr Tymoshenko Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-embedded@freebsd.org" Subject: Re: Updated switch/glue patch? X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 10:11:56 -0000 On 18 December 2011 01:54, Adrian Chadd wrote: > Just as a side note - reducing the udelay value from 10 to 1 in my git > tree doesn't stop the huge CPU use. I'm going to next try removing the > locking, as I note that each GPIO access involves a mutex lock and I > bet the witness code is taking a freaking beating here. .. yup. Not compiling in witness helps hugely. I wish I had PMC working at this point - I bet lots of lock overhead would creep up. Basically, a lock is acquired for each GPIO pin set, clear and reconfigure. The gpiobus code itself doesn't do this - that's what gpiobus_lock_bus and gpiobus_unlock_bus is for - but the ar71xx gpio code however does. And so does the gpioiic code - it's locking and unlocking the bus for each scl/sda line operation. Erm, surely that's a bit ridiculous.. surely the locking doesn't need to be that fine grained _and_ multi-levelled. There has to be a better way to do this. :) Adrian From owner-freebsd-embedded@FreeBSD.ORG Sun Dec 18 10:17:52 2011 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B330A106566C; Sun, 18 Dec 2011 10:17:52 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 7016F8FC0A; Sun, 18 Dec 2011 10:17:52 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 0A7B8108BD7; Sun, 18 Dec 2011 11:17:51 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Stefan Bethke In-Reply-To: Date: Sun, 18 Dec 2011 11:17:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <18CABB46-9B9A-41CB-8742-6723C5FF4D67@lassitu.de> References: <0F6CC18F-6973-42A2-AC03-F01BF59458AE@lassitu.de> <1100F70E-9DA9-4163-AC9A-423ECE5AA9A3@lassitu.de> To: Adrian Chadd X-Mailer: Apple Mail (2.1251.1) Cc: Oleksandr Tymoshenko , "freebsd-embedded@freebsd.org" Subject: Re: Updated switch/glue patch? X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 10:17:52 -0000 Am 18.12.2011 um 11:11 schrieb Adrian Chadd: > On 18 December 2011 01:54, Adrian Chadd wrote: >=20 >> Just as a side note - reducing the udelay value from 10 to 1 in my = git >> tree doesn't stop the huge CPU use. I'm going to next try removing = the >> locking, as I note that each GPIO access involves a mutex lock and I >> bet the witness code is taking a freaking beating here. >=20 > .. yup. Not compiling in witness helps hugely. I wish I had PMC > working at this point - I bet lots of lock overhead would creep up. >=20 > Basically, a lock is acquired for each GPIO pin set, clear and > reconfigure. The gpiobus code itself doesn't do this - that's what > gpiobus_lock_bus and gpiobus_unlock_bus is for - but the ar71xx gpio > code however does. And so does the gpioiic code - it's locking and > unlocking the bus for each scl/sda line operation. >=20 > Erm, surely that's a bit ridiculous.. surely the locking doesn't need > to be that fine grained _and_ multi-levelled. There has to be a better > way to do this. :) Exactly. I've reimplemented iicbb.c to be slightly more protocol compliant, and = to be able to tune transfer speeds to the actual hardware capabilities. = I've timed a single GETSCL (with WITNESS) to 8.7 microseconds, clearly = that won't do. I think I'll look at gpio next, as you have, and see if the overhead can = be reduced. Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-embedded@FreeBSD.ORG Sun Dec 18 10:29:41 2011 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C057106566B; Sun, 18 Dec 2011 10:29:41 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2DC598FC1B; Sun, 18 Dec 2011 10:29:41 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so5929747vbb.13 for ; Sun, 18 Dec 2011 02:29:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KtAoOXB6Yn9UudWa+Y1ZWjK8Wydd+d2RBtmGV0f+O+M=; b=A48WUEIV/RNHgubAQlhgnJeymxn+1BQEcV1j93++sZmnI0A3J7g4T0/whLwdVFRN3e olRrl6gXhx+p8LNbTQwOPi3aJnF1r2/LYDGLkCOiF2kpMKjUFj2bSRaKlCqR6YTVhXLk Sca88N42Wj5BCmL4AVXO3yt28Ltpi5YjMHlg0= MIME-Version: 1.0 Received: by 10.52.20.165 with SMTP id o5mr9443186vde.79.1324204180622; Sun, 18 Dec 2011 02:29:40 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.26.50 with HTTP; Sun, 18 Dec 2011 02:29:40 -0800 (PST) In-Reply-To: <18CABB46-9B9A-41CB-8742-6723C5FF4D67@lassitu.de> References: <0F6CC18F-6973-42A2-AC03-F01BF59458AE@lassitu.de> <1100F70E-9DA9-4163-AC9A-423ECE5AA9A3@lassitu.de> <18CABB46-9B9A-41CB-8742-6723C5FF4D67@lassitu.de> Date: Sun, 18 Dec 2011 02:29:40 -0800 X-Google-Sender-Auth: QFFXWjflRfx4fP9SvggBTV7uig0 Message-ID: From: Adrian Chadd To: Stefan Bethke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Oleksandr Tymoshenko , "freebsd-embedded@freebsd.org" Subject: Re: Updated switch/glue patch? X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 10:29:41 -0000 On 18 December 2011 02:17, Stefan Bethke wrote: >> Erm, surely that's a bit ridiculous.. surely the locking doesn't need >> to be that fine grained _and_ multi-levelled. There has to be a better >> way to do this. :) > > Exactly. > > I've reimplemented iicbb.c to be slightly more protocol compliant, and to= be able to tune transfer speeds to the actual hardware capabilities. =A0I'= ve timed a single GETSCL (with WITNESS) to 8.7 microseconds, clearly that w= on't do. > > I think I'll look at gpio next, as you have, and see if the overhead can = be reduced. I'm just hacking up gpio and gpioiic at the moment. gpiobus already _has_ locks for access to the bus, so as long as gpioiic actually grabs the gpio bus for the duration of the transfer, the individual GPIO operations shouldn't require locks. Same deal with gpioiic and the gpioiic locks being used for each sda/scl operation. The bus should already be acquired. With those locks removed (and I haven't committed that to my git tree, I have no idea what the implications are), things certainly look like they're behaving better. There are still the occasional spike in CPU time: this is a vmstat 0.1: # vmstat 0.1 procs memory page disks faults cp= u r b w avm fre flt re pi po fr sr fl0 md0 in sy cs us sy id 0 0 0 62832k 7536k 212 1 2 0 137 0 0 0 0 182 265 2 21 77 0 0 0 62832k 7536k 0 0 0 0 0 0 0 0 0 1070 640 0 0 100 0 0 0 62832k 7536k 0 0 0 0 0 0 0 0 0 1070 430 0 0 100 0 0 0 62832k 7536k 0 0 0 0 0 0 0 0 0 1070 350 0 0 100 0 0 0 62832k 7536k 0 0 0 0 0 0 0 0 0 1070 410 0 0 100 0 0 0 62832k 7536k 0 0 0 0 0 0 0 0 0 1070 440 0 0 100 0 0 0 62832k 7536k 0 0 0 0 0 0 0 0 0 1070 350 0 0 100 0 0 0 62832k 7536k 0 0 0 0 0 0 0 0 0 1070 410 0 0 100 0 0 0 62832k 7536k 0 0 0 0 0 0 0 0 0 1070 450 0 58 42 0 0 0 62832k 7536k 0 0 0 0 0 0 0 0 0 1070 460 0 0 100 0 0 0 62832k 7536k 0 0 0 0 0 0 0 0 0 1070 400 0 0 100 0 0 0 62832k 7536k 0 0 0 0 0 0 0 0 0 1070 370 0 0 100 0 0 0 62832k 7536k 0 0 0 0 0 0 0 0 0 1070 370 0 8 92 0 0 0 62832k 7536k 0 0 0 0 0 0 0 0 0 1070 400 0 0 100 0 0 0 62832k 7536k 0 0 0 0 0 0 0 0 0 1070 470 8 0 92 0 0 0 62832k 7536k 0 0 0 0 0 0 0 0 0 1070 460 0 8 92 0 0 0 62832k 7536k 0 0 0 0 0 0 0 0 0 1070 460 0 8 92 0 0 0 62832k 7536k 0 0 0 0 0 0 0 0 0 1070 510 0 14 86 0 0 0 62832k 7536k 0 0 0 0 0 0 0 0 0 1070 450 0 61 39 0 0 0 62832k 7536k 0 0 0 0 0 0 0 0 0 1070 500 0 8 92 .. but notice that it uses a lot of CPU in a short burst, rather than actually tying up the CPU for almost a second. I still don't like it (it's only doing a couple hundred register accesses a second over the gpio bus, surely it shouldn't take that much CPU..) but at least now it's behaving correctly. So now - why are the gpioiic and ar71xx_gpio locks even required? If all consumers of the gpio bus code actually use the gpiobus lock/unlock device methods correctly, surely that should be enough? I may actually add a couple of debug device methods to allow a driver to effectively call BLAH_LOCK_ASSERT() and BLAH_UNLOCK_ASSERT(). That way the GPIO driver code can ensure that the gpio bus is actually locked whenever an operation is done. Similarly, the i2c bus code can ensure that the gpio bus it's hanging off is also locked. That should capture any stupid crap from occuring. G'night, and thanks very much for looking into this. :) Adrian From owner-freebsd-embedded@FreeBSD.ORG Mon Dec 19 00:33:54 2011 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CBF3106566B; Mon, 19 Dec 2011 00:33:54 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id B17D98FC15; Mon, 19 Dec 2011 00:33:53 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id pBJ0TZLB039354 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sun, 18 Dec 2011 17:29:35 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <18CABB46-9B9A-41CB-8742-6723C5FF4D67@lassitu.de> Date: Sun, 18 Dec 2011 17:29:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0F6CC18F-6973-42A2-AC03-F01BF59458AE@lassitu.de> <1100F70E-9DA9-4163-AC9A-423ECE5AA9A3@lassitu.de> <18CABB46-9B9A-41CB-8742-6723C5FF4D67@lassitu.de> To: Stefan Bethke X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sun, 18 Dec 2011 17:29:36 -0700 (MST) Cc: Oleksandr Tymoshenko , Adrian Chadd , "freebsd-embedded@freebsd.org" Subject: Re: Updated switch/glue patch? X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 00:33:54 -0000 On Dec 18, 2011, at 3:17 AM, Stefan Bethke wrote: > I've reimplemented iicbb.c to be slightly more protocol compliant, and = to be able to tune transfer speeds to the actual hardware capabilities. = I've timed a single GETSCL (with WITNESS) to 8.7 microseconds, clearly = that won't do. What is it without WITNESS? The performance numbers with WITNESS are = generally uninteresting for a deployed system. Warner From owner-freebsd-embedded@FreeBSD.ORG Mon Dec 19 04:20:27 2011 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1496D106566C; Mon, 19 Dec 2011 04:20:27 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id A32378FC08; Mon, 19 Dec 2011 04:20:26 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so6411210vcb.13 for ; Sun, 18 Dec 2011 20:20:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=z7Ppr4/Mleh7TOrRaTVH/dC6djcnKvbdDBvEu+sovgk=; b=RqaEB04kt1qTlJOrGMQLhRBH7Uz/FLMgwDZh9B4XSXTE7PlL7GlUqMX21VmSRHEpLq c1Tc+FPlt/t8/QGyUx+RbHXiDC50AKyLUZlf4WygHnCMAC+S+Yne1iXOgZz1lksKORiN 1e2oTPxDUNz0msVOUenjBsbKlZ3YCCMMKzEEM= MIME-Version: 1.0 Received: by 10.220.151.204 with SMTP id d12mr8638214vcw.40.1324268426055; Sun, 18 Dec 2011 20:20:26 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.26.50 with HTTP; Sun, 18 Dec 2011 20:20:25 -0800 (PST) In-Reply-To: References: <0F6CC18F-6973-42A2-AC03-F01BF59458AE@lassitu.de> <1100F70E-9DA9-4163-AC9A-423ECE5AA9A3@lassitu.de> <18CABB46-9B9A-41CB-8742-6723C5FF4D67@lassitu.de> Date: Sun, 18 Dec 2011 20:20:25 -0800 X-Google-Sender-Auth: mLbDvqV8tmuuXh4iFslJs3G7xnA Message-ID: From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Oleksandr Tymoshenko , "freebsd-embedded@freebsd.org" Subject: Re: Updated switch/glue patch? X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 04:20:27 -0000 On 18 December 2011 16:29, Warner Losh wrote: > What is it without WITNESS? =A0The performance numbers with WITNESS are g= enerally uninteresting for a deployed system. It's still ridiculously CPU intensive. :( It turns out trying to do those locks three times one each GPIO IO line fiddle is a bit over the top. Adrian From owner-freebsd-embedded@FreeBSD.ORG Mon Dec 19 04:58:41 2011 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EA1A1065672; Mon, 19 Dec 2011 04:58:41 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 296068FC12; Mon, 19 Dec 2011 04:58:40 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so6436865vcb.13 for ; Sun, 18 Dec 2011 20:58:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=07gJWKpIGmd78i+nn6OrCOwksm8iuvXFMh3u+ShzE7c=; b=rJcm43kTUHfhurfAp6fbq1aGyTQLpxsqHW4fXz9kBa1mIsBgWchXX+1hgKpi4ixCis BqKbm+hnEWgAMA1M/JU9gKtAg/8ExUAf1wT9pLMpBwb12Dy2lH86a2nJz5Ylxw+wd+ZN 8JWVgROl8reR1wi1GwXWZTd31f7nYQNYzIY2w= MIME-Version: 1.0 Received: by 10.220.231.73 with SMTP id jp9mr8687005vcb.50.1324270719128; Sun, 18 Dec 2011 20:58:39 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.26.50 with HTTP; Sun, 18 Dec 2011 20:58:39 -0800 (PST) In-Reply-To: <18CABB46-9B9A-41CB-8742-6723C5FF4D67@lassitu.de> References: <0F6CC18F-6973-42A2-AC03-F01BF59458AE@lassitu.de> <1100F70E-9DA9-4163-AC9A-423ECE5AA9A3@lassitu.de> <18CABB46-9B9A-41CB-8742-6723C5FF4D67@lassitu.de> Date: Sun, 18 Dec 2011 20:58:39 -0800 X-Google-Sender-Auth: 1In3YsmN4000bAR1JqRk0XAAxOA Message-ID: From: Adrian Chadd To: Stefan Bethke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Oleksandr Tymoshenko , "freebsd-embedded@freebsd.org" Subject: Re: Updated switch/glue patch? X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 04:58:41 -0000 On 18 December 2011 02:17, Stefan Bethke wrote: >> Erm, surely that's a bit ridiculous.. surely the locking doesn't need >> to be that fine grained _and_ multi-levelled. There has to be a better >> way to do this. :) > > Exactly. > > I've reimplemented iicbb.c to be slightly more protocol compliant, and to= be able to tune transfer speeds to the actual hardware capabilities. =A0I'= ve timed a single GETSCL (with WITNESS) to 8.7 microseconds, clearly that w= on't do. Ok. I'll check it out soon. > I think I'll look at gpio next, as you have, and see if the overhead can = be reduced. In the meantime, would you mind grabbing the latest code from my git tree (in the work/ath branch) and basing your work off of that? Even with delay=3D10 (the current hardcoded default), it takes up significantly less CPU than before. If we can debug and test this locking hacking and my iicbb changes (which are less intrusive than yours, which I'll review soon and we can merge in later), I'll push this into -HEAD so we can continue shaving off cycles and fixing things up. Thanks again Stefan! Adrian From owner-freebsd-embedded@FreeBSD.ORG Mon Dec 19 06:44:51 2011 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65A721065675; Mon, 19 Dec 2011 06:44:51 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 1382F8FC13; Mon, 19 Dec 2011 06:44:50 +0000 (UTC) Received: from [10.0.0.63] (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id pBJ6gLj5041873 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sun, 18 Dec 2011 23:42:23 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 18 Dec 2011 23:42:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2CBD8651-E132-49DC-A082-37A8F5C626EA@bsdimp.com> References: <0F6CC18F-6973-42A2-AC03-F01BF59458AE@lassitu.de> <1100F70E-9DA9-4163-AC9A-423ECE5AA9A3@lassitu.de> <18CABB46-9B9A-41CB-8742-6723C5FF4D67@lassitu.de> To: Adrian Chadd X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sun, 18 Dec 2011 23:42:23 -0700 (MST) Cc: Oleksandr Tymoshenko , "freebsd-embedded@freebsd.org" Subject: Re: Updated switch/glue patch? X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 06:44:51 -0000 On Dec 18, 2011, at 9:20 PM, Adrian Chadd wrote: > On 18 December 2011 16:29, Warner Losh wrote: >=20 >> What is it without WITNESS? The performance numbers with WITNESS are = generally uninteresting for a deployed system. >=20 > It's still ridiculously CPU intensive. :( It turns out trying to do > those locks three times one each GPIO IO line fiddle is a bit over the > top. That's the real problem. WITNESS is a known pigdog on low-end systems, = so measurements with it tend to skew the results a tad too much. On the = other hand, it did magnify the problem to the point it was fixed :) The insane locking should be fixed. Warner From owner-freebsd-embedded@FreeBSD.ORG Mon Dec 19 06:56:23 2011 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8D64106564A; Mon, 19 Dec 2011 06:56:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 574C78FC08; Mon, 19 Dec 2011 06:56:23 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so6562606vbb.13 for ; Sun, 18 Dec 2011 22:56:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0S/Poq/nqvu/9cXW+c2nl2L9Rm9BEfNd/7/AbjgyxhM=; b=Pu1/asW2mET3thosdsNBH8KOH6FwiKg66FCG7FnMNw+glIFz1WdHA6u9+NQvyd69bk hzZUuYx6jUkb9ap9fVkWSksv1JnXZjGpNev/S652wEopJxMq+Vhz+dmpj266+puVLm6k /CiSn61gyTf0XHZLai0+bmLwi5kgIyt3sP4Qk= MIME-Version: 1.0 Received: by 10.52.90.80 with SMTP id bu16mr10456206vdb.113.1324277782737; Sun, 18 Dec 2011 22:56:22 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.26.50 with HTTP; Sun, 18 Dec 2011 22:56:22 -0800 (PST) In-Reply-To: <2CBD8651-E132-49DC-A082-37A8F5C626EA@bsdimp.com> References: <0F6CC18F-6973-42A2-AC03-F01BF59458AE@lassitu.de> <1100F70E-9DA9-4163-AC9A-423ECE5AA9A3@lassitu.de> <18CABB46-9B9A-41CB-8742-6723C5FF4D67@lassitu.de> <2CBD8651-E132-49DC-A082-37A8F5C626EA@bsdimp.com> Date: Sun, 18 Dec 2011 22:56:22 -0800 X-Google-Sender-Auth: 9F-Jiv5pCLjp7keAHojSTst-M4w Message-ID: From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Oleksandr Tymoshenko , "freebsd-embedded@freebsd.org" Subject: Re: Updated switch/glue patch? X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 06:56:23 -0000 On 18 December 2011 22:42, Warner Losh wrote: >> It's still ridiculously CPU intensive. :( It turns out trying to do >> those locks three times one each GPIO IO line fiddle is a bit over the >> top. > > That's the real problem. =A0WITNESS is a known pigdog on low-end systems,= so measurements with it tend to skew the results a tad too much. =A0On the= other hand, it did magnify the problem to the point it was fixed :) > > The insane locking should be fixed. Yeah. I've done it in my local branch. Hopefully Stefan/I can thrash this out a bit more and get it into the tree soon. I wonder if I can fix up witness a little more. I already found some insane string operations in the witness debugging code, which I've since fixed. Adrian From owner-freebsd-embedded@FreeBSD.ORG Mon Dec 19 11:07:03 2011 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D3A51065676 for ; Mon, 19 Dec 2011 11:07:03 +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 EEAC38FC1E for ; Mon, 19 Dec 2011 11:07:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pBJB72MK010904 for ; Mon, 19 Dec 2011 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pBJB72CG010902 for freebsd-embedded@FreeBSD.org; Mon, 19 Dec 2011 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 19 Dec 2011 11:07:02 GMT Message-Id: <201112191107.pBJB72CG010902@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 Cc: Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 11:07:03 -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 Dec 20 03:53:53 2011 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19F781065676; Tue, 20 Dec 2011 03:53:53 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id AAE078FC0C; Tue, 20 Dec 2011 03:53:52 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so7892655vbb.13 for ; Mon, 19 Dec 2011 19:53:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=qIX5h4guBPOCBGL641U2/6me1tOsfDZyh8fzYNAcqnY=; b=LhHC/uXw89HYCsubjG1FMLzXTnhPZu+flfEnvAj/pXNXayMbvbEts0AtmcE62/hv1K sEBiBQVc6VXkSYxQ40aY7SRxQf3l87oFCindowQ9/N0aJ+g++R5hm0Pty36fxzQqZ45K tzzN5UwDzHgH+/eDUzg4tbP957HY/ShHUKQQY= MIME-Version: 1.0 Received: by 10.52.114.232 with SMTP id jj8mr168413vdb.94.1324353232002; Mon, 19 Dec 2011 19:53:52 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.158.104 with HTTP; Mon, 19 Dec 2011 19:53:51 -0800 (PST) In-Reply-To: References: <0F6CC18F-6973-42A2-AC03-F01BF59458AE@lassitu.de> <1100F70E-9DA9-4163-AC9A-423ECE5AA9A3@lassitu.de> <18CABB46-9B9A-41CB-8742-6723C5FF4D67@lassitu.de> <2CBD8651-E132-49DC-A082-37A8F5C626EA@bsdimp.com> Date: Mon, 19 Dec 2011 19:53:51 -0800 X-Google-Sender-Auth: UlTlye0IkZe43S6P-KMfhbQBjlk Message-ID: From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: Oleksandr Tymoshenko , Stefan Bethke , "freebsd-embedded@freebsd.org" Subject: Re: Updated switch/glue patch? X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 03:53:53 -0000 Hi, I've just dumped some more locking fixes into -HEAD. I've also changed iicbb.c a little so it has a configurable udelay. Sorry Stefan, you're going to have to rebase your iicbb changes. :) With the default per-bit sleep of 10uS, a rough calculation is: * 3 sleeps per bit: 30uS per bit * 8 bits per byte * 1 bit for ACK * == 12 bits per byte: 360uS a byte Each transaction is what, 5 bytes or 6 btyes total? I'll say 6 bytes, to be conservative. That's 2.1ms a transaction. Say thirty register accesses a second (for 5 switch PHY ports) - 63mS. I still think that's a bit low. But that's minimum 63mS of DELAY(), each second. Nothing else occurs during that. I've dropped the udelay parameter from 10 to 2 and had things work successfully. It still wastes a significant fraction of 100mS of CPU time each second. Sorry, but there has to be a better way to do this. Is it possible to just only poll a minimal set of PHY registers each second, rather than polling them all? Adrian From owner-freebsd-embedded@FreeBSD.ORG Tue Dec 20 04:34:52 2011 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46BCD106568A; Tue, 20 Dec 2011 04:34:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id D71968FC1B; Tue, 20 Dec 2011 04:34:51 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so7925701vbb.13 for ; Mon, 19 Dec 2011 20:34:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=FAlCgw/hubQoSYcHmiqMSnDOvw+xdTmsryMhMwmfNWA=; b=VfLqOEiV74RIGO9wgRm70LEgAEidPD9Nnfcpza4iT/nPK5dbKjAbLRYugpJrZjrG7R HRHibwiK8gIDfC8ZQ+xqq2B8dbjrVHRwzocJ0NFzzKt7uh/0DIqnFPyBSXpmsepa+2pd rG3NujpXA6AEDsrHzeAOgk3LHByVXSre8+WNo= MIME-Version: 1.0 Received: by 10.52.90.164 with SMTP id bx4mr195425vdb.128.1324355691085; Mon, 19 Dec 2011 20:34:51 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.158.104 with HTTP; Mon, 19 Dec 2011 20:34:51 -0800 (PST) In-Reply-To: References: <0F6CC18F-6973-42A2-AC03-F01BF59458AE@lassitu.de> <1100F70E-9DA9-4163-AC9A-423ECE5AA9A3@lassitu.de> <18CABB46-9B9A-41CB-8742-6723C5FF4D67@lassitu.de> <2CBD8651-E132-49DC-A082-37A8F5C626EA@bsdimp.com> Date: Mon, 19 Dec 2011 20:34:51 -0800 X-Google-Sender-Auth: AP_tnXAkFzBkBF16ZEBJgJOb5c4 Message-ID: From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: Oleksandr Tymoshenko , Stefan Bethke , "freebsd-embedded@freebsd.org" Subject: Re: Updated switch/glue patch? X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 04:34:52 -0000 On 19 December 2011 19:53, Adrian Chadd wrote: > Hi, > > I've just dumped some more locking fixes into -HEAD. I've also changed > iicbb.c a little so it has a configurable udelay. Sorry Stefan, you're > going to have to rebase your iicbb changes. :) .. and I've just fixed a locking bug, and I've introduced a new iicbb hint which overrides udelay. Next is adding some more twiddles to enable/disable iicbb debugging, iicbus debugging and log transaction failures, ACK times, etc. The read transactions all seem to fail ACK btw, so I wonder if that's the majority of the CPU time being wasted.. Adrian From owner-freebsd-embedded@FreeBSD.ORG Tue Dec 20 07:39:22 2011 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A239106566B; Tue, 20 Dec 2011 07:39:22 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id ECEB18FC0A; Tue, 20 Dec 2011 07:39:21 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id BFD4210CC4C; Tue, 20 Dec 2011 08:39:20 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Stefan Bethke In-Reply-To: Date: Tue, 20 Dec 2011 08:39:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0F6CC18F-6973-42A2-AC03-F01BF59458AE@lassitu.de> <1100F70E-9DA9-4163-AC9A-423ECE5AA9A3@lassitu.de> <18CABB46-9B9A-41CB-8742-6723C5FF4D67@lassitu.de> <2CBD8651-E132-49DC-A082-37A8F5C626EA@bsdimp.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1251.1) Cc: Oleksandr Tymoshenko , "freebsd-embedded@freebsd.org" Subject: Re: Updated switch/glue patch? X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 07:39:22 -0000 Am 20.12.2011 um 04:53 schrieb Adrian Chadd: > Hi, >=20 > I've just dumped some more locking fixes into -HEAD. I've also changed > iicbb.c a little so it has a configurable udelay. Sorry Stefan, you're > going to have to rebase your iicbb changes. :) >=20 > With the default per-bit sleep of 10uS, a rough calculation is: >=20 > * 3 sleeps per bit: 30uS per bit > * 8 bits per byte > * 1 bit for ACK > * =3D=3D 12 bits per byte: 360uS a byte >=20 > Each transaction is what, 5 bytes or 6 btyes total? I'll say 6 bytes, > to be conservative. That's 2.1ms a transaction. Say thirty register > accesses a second (for 5 switch PHY ports) - 63mS. I still think > that's a bit low. But that's minimum 63mS of DELAY(), each second. > Nothing else occurs during that. >=20 > I've dropped the udelay parameter from 10 to 2 and had things work > successfully. It still wastes a significant fraction of 100mS of CPU > time each second. I2C runs at 100kHz, so a total delay per bit of 10 microseconds should = always work. The datasheet for the RTL8366S shows that 4 microseconds = for SCL high and low, respectively, are the minimum, so it's even a bit = faster. Register access transfers 5 bytes (command, address*2, data*2) plus the = ack bits, plus start and stop, for a total of 5*(8+1) + 2 =3D 47 clock = cycles. At 100 kHz, that's 470 microseconds, with a delay of 8 ms per = cycle it's 376 microseconds. We could try and see how much quicker we can make the transaction, but I = think even at an order of magnitude faster, polling 2*5 PHY registers, = it's taking up too much CPU. And looking at the MIB stats registers, = we're facing the same question. > Sorry, but there has to be a better way to do this. Is it possible to > just only poll a minimal set of PHY registers each second, rather than > polling them all? There is RTL8366RB_PLSR_BASE which has a byte per port, giving link = status and speed. We could either forgo the generic PHY code = completely, or do just the status check ourselves. I'm of two minds whether reusing the miibus code really is a good idea. = The problem I have with it is mainly that it assumes that there is a = struct ifnet that the miibus is attached to, and that that ifnet has = exactly one running phy. So in my current implementation, I've simply = created one ifnet for each of the five ports that have PHYs on them. On the other hand, I would hate to duplicate media handling code from = ukphy and that infrastrucure inside the switch driver. At any rate, we should make PHY status polling and the MIB stats polling = optional (e.g. off, on demand, periodic), so users can decide if and = when they need it. I'll try and catch up with your git branch today. Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-embedded@FreeBSD.ORG Tue Dec 20 07:45:03 2011 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C88A61065675; Tue, 20 Dec 2011 07:45:03 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 794748FC17; Tue, 20 Dec 2011 07:45:03 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 3273B10CCBC; Tue, 20 Dec 2011 08:45:02 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Stefan Bethke In-Reply-To: Date: Tue, 20 Dec 2011 08:45:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1EC329E1-261E-478A-9EEB-A9FB02E893FD@lassitu.de> References: <0F6CC18F-6973-42A2-AC03-F01BF59458AE@lassitu.de> <1100F70E-9DA9-4163-AC9A-423ECE5AA9A3@lassitu.de> <18CABB46-9B9A-41CB-8742-6723C5FF4D67@lassitu.de> <2CBD8651-E132-49DC-A082-37A8F5C626EA@bsdimp.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1251.1) Cc: Oleksandr Tymoshenko , "freebsd-embedded@freebsd.org" Subject: Re: Updated switch/glue patch? X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 07:45:03 -0000 Am 20.12.2011 um 05:34 schrieb Adrian Chadd: > On 19 December 2011 19:53, Adrian Chadd wrote: >> Hi, >>=20 >> I've just dumped some more locking fixes into -HEAD. I've also = changed >> iicbb.c a little so it has a configurable udelay. Sorry Stefan, = you're >> going to have to rebase your iicbb changes. :) >=20 > .. and I've just fixed a locking bug, and I've introduced a new iicbb > hint which overrides udelay. >=20 > Next is adding some more twiddles to enable/disable iicbb debugging, > iicbus debugging and log transaction failures, ACK times, etc. The > read transactions all seem to fail ACK btw, so I wonder if that's the > majority of the CPU time being wasted.. iicbb.c::iicbb_ack() is broken, I believe. Would you mind trying my = version, which should be a drop-in replacement? You'll have to adjust = the iicdelay initialition in iicbb_attach(), but otherwise it should = just work. Note that in the existing iicbb_write(), the code wrongly waits for an = ack on the last byte transferred, which is incorrect; on the last byte = of the transfer, the ack bit is always 1. Stefan=20 --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-embedded@FreeBSD.ORG Tue Dec 20 15:25:47 2011 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A82711065670; Tue, 20 Dec 2011 15:25:47 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 347EE8FC08; Tue, 20 Dec 2011 15:25:46 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so8579501vcb.13 for ; Tue, 20 Dec 2011 07:25:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zB7FpXwh0kk9a4ymZHdJqh5roze1gsiaH0ufUBKjdeI=; b=hRnyys6RADyl7EY2/xaKsZ0VoxuaJH2gh0NwbT4WAzWdZdb2Rn49Lbr7cdm6Nf46xO WaUzSMGBk3FlAH5zRD3qfEuVIDxh9qsY+jiuHyu++03XhFa1f65EXg3WdVRgfRDm407X ANAmbIJ++Qu/CE41LA0fas5Az6ZPFHoQ0QO3I= MIME-Version: 1.0 Received: by 10.52.90.164 with SMTP id bx4mr1241699vdb.128.1324394746485; Tue, 20 Dec 2011 07:25:46 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.158.104 with HTTP; Tue, 20 Dec 2011 07:25:46 -0800 (PST) In-Reply-To: References: <0F6CC18F-6973-42A2-AC03-F01BF59458AE@lassitu.de> <1100F70E-9DA9-4163-AC9A-423ECE5AA9A3@lassitu.de> <18CABB46-9B9A-41CB-8742-6723C5FF4D67@lassitu.de> <2CBD8651-E132-49DC-A082-37A8F5C626EA@bsdimp.com> Date: Tue, 20 Dec 2011 07:25:46 -0800 X-Google-Sender-Auth: IWOQRproBKH5_gPwRP9XMa3s8h0 Message-ID: From: Adrian Chadd To: Stefan Bethke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Oleksandr Tymoshenko , "freebsd-embedded@freebsd.org" Subject: Re: Updated switch/glue patch? X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 15:25:47 -0000 On 19 December 2011 23:39, Stefan Bethke wrote: > I2C runs at 100kHz, so a total delay per bit of 10 microseconds should al= ways work. =A0The datasheet for the RTL8366S shows that 4 microseconds for = SCL high and low, respectively, are the minimum, so it's even a bit faster. So that's "set SDA and toggle SCA" total? > Register access transfers 5 bytes (command, address*2, data*2) plus the a= ck bits, plus start and stop, for a total of 5*(8+1) + 2 =3D 47 clock cycle= s. At 100 kHz, that's 470 microseconds, with a delay of 8 ms per cycle it's= 376 microseconds. Right. > We could try and see how much quicker we can make the transaction, but I = think even at an order of magnitude faster, polling 2*5 PHY registers, it's= taking up too much CPU. =A0And looking at the MIB stats registers, we're f= acing the same question. Again, right. At this point we likely should just require preemption if we're going to try tinkering with this stuff. >> Sorry, but there has to be a better way to do this. Is it possible to >> just only poll a minimal set of PHY registers each second, rather than >> polling them all? > There is RTL8366RB_PLSR_BASE which has a byte per port, giving link statu= s and speed. =A0We could either forgo the generic PHY code completely, or d= o just the status check ourselves. It wouldn't be the first time that a custom PHY is used, right? :) One byte per port for link status and speed is going to be a lot nicer to deal with. The delay is still insanely long, but it's better than polling all of those status registers. So yes, it may be worthwhile just implementing a custom PHY interface in that file and using that, rather than using ukphy. Although ukphy works, it takes a long, long time to do anything. Re: MIB stats. That's going to have the same problem, but we can likely deal with it by simply doing it from userspace where the kernel _can_ interrupt. :) > I'm of two minds whether reusing the miibus code really is a good idea. = =A0The problem I have with it is mainly that it assumes that there is a str= uct ifnet that the miibus is attached to, and that that ifnet has exactly o= ne running phy. =A0So in my current implementation, I've simply created one= ifnet for each of the five ports that have PHYs on them. I personally think your current method of doing it is fine. The switch driver is small, it's reusing the media handling infrastructure; it doesn't look like you'll have to do much to write a custom PHY to replace ukphy. > On the other hand, I would hate to duplicate media handling code from ukp= hy and that infrastrucure inside the switch driver. > > At any rate, we should make PHY status polling and the MIB stats polling = optional (e.g. off, on demand, periodic), so users can decide if and when t= hey need it. > > I'll try and catch up with your git branch today. Thanks. I'll look at your subsequent email (iicbb_ack()) in a moment. I think the short-term way to move forward is to include a bare-bones replacement PHY just for that switch and disable MIB stats polling. That should be enough for the short term. I'd like to try and wrap this up so we can move onto other areas of the switch stuff - the management tool, the switch bus backend (ie, having a switch driver sit on either i2c, spi, miibus, which physical port does it hang off of, etc.) and looking at including other switch devices (ar8216/ar8316 at least to begin with.) Hm, and I also need to see whether it's worthwhile keeping the vlangroup config method, or whether the ar8216/ar8316 (and the others supported in zrouter) really want to support a set of VLANs per port. The AR8316 datasheet describes how it works - there's a table of known VLANs and a bitmap in each VLAN entry describing which ports are able to be used. There's also a way to configure port isolation, and the ingres/egres port is configured by a magic 2 byte header added to each ethernet frame. I don't know what the other switches offer. It's possible we need to support both - so we'll need a capability bit, identifying which API is to be used. So there's still lots to do. :) Adrian From owner-freebsd-embedded@FreeBSD.ORG Wed Dec 21 12:22:04 2011 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41A38106564A; Wed, 21 Dec 2011 12:22:04 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id EC1A78FC14; Wed, 21 Dec 2011 12:22:03 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 26F0D112A35; Wed, 21 Dec 2011 13:22:03 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Stefan Bethke In-Reply-To: Date: Wed, 21 Dec 2011 13:22:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0F6CC18F-6973-42A2-AC03-F01BF59458AE@lassitu.de> <1100F70E-9DA9-4163-AC9A-423ECE5AA9A3@lassitu.de> <18CABB46-9B9A-41CB-8742-6723C5FF4D67@lassitu.de> <2CBD8651-E132-49DC-A082-37A8F5C626EA@bsdimp.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1251.1) Cc: Oleksandr Tymoshenko , "freebsd-embedded@freebsd.org" Subject: Re: Updated switch/glue patch? X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 12:22:04 -0000 Am 20.12.2011 um 16:25 schrieb Adrian Chadd: > Hm, and I also need to see whether it's worthwhile keeping the > vlangroup config method, or whether the ar8216/ar8316 (and the others > supported in zrouter) really want to support a set of VLANs per port. > The AR8316 datasheet describes how it works - there's a table of known > VLANs and a bitmap in each VLAN entry describing which ports are able > to be used. There's also a way to configure port isolation, and the > ingres/egres port is configured by a magic 2 byte header added to each > ethernet frame. You're describing it as if it were different from the RTL8366RB. I'm open to replace "vlangroup" with a better term. I picked it to = distinguish it from ifconfig's use of "vlan" to configure the .1q VLAN = ID (VID). In the switch chips, as you correctly explain, there is a = VLAN configuration table (usually 16 entries), where each entry has the = VID, the member ports and potentially a number of additional parameters = (PCP, etc.) This entry I'm calling "vlangroup" (that's what the = datasheet for the RTL8306S calls it). I'd be happy if we could find a = better term. The Linux switch api ignores the VLAN configuration table and presents = the switch as if you had an entry for each possible VID. It's slightly = more complicated in the switch driver, but we could go down the same = route. Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-embedded@FreeBSD.ORG Wed Dec 21 15:13:49 2011 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E7A81065670; Wed, 21 Dec 2011 15:13:49 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 54D7C8FC14; Wed, 21 Dec 2011 15:13:49 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 273DF112F0D; Wed, 21 Dec 2011 16:13:48 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Stefan Bethke In-Reply-To: Date: Wed, 21 Dec 2011 16:13:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <09670C34-0D30-46BC-BA7E-4AAA22193B61@lassitu.de> References: <0F6CC18F-6973-42A2-AC03-F01BF59458AE@lassitu.de> <1100F70E-9DA9-4163-AC9A-423ECE5AA9A3@lassitu.de> <18CABB46-9B9A-41CB-8742-6723C5FF4D67@lassitu.de> <2CBD8651-E132-49DC-A082-37A8F5C626EA@bsdimp.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1251.1) Cc: Oleksandr Tymoshenko , "freebsd-embedded@freebsd.org" Subject: Re: Updated switch/glue patch? X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 15:13:49 -0000 Am 20.12.2011 um 16:25 schrieb Adrian Chadd: >> I'm of two minds whether reusing the miibus code really is a good = idea. The problem I have with it is mainly that it assumes that there = is a struct ifnet that the miibus is attached to, and that that ifnet = has exactly one running phy. So in my current implementation, I've = simply created one ifnet for each of the five ports that have PHYs on = them. >=20 > I personally think your current method of doing it is fine. The switch > driver is small, it's reusing the media handling infrastructure; it > doesn't look like you'll have to do much to write a custom PHY to > replace ukphy. I've replaced the generic PHY status poll with a custom one that uses = the switch registers instead of the PHYs. I've cloned your git and have = started adding my changes to it (branch also named work/ath): http://gitorious.org/~stb/freebsd/stb-adrianchadd-freebsd-work I tried a merge request, but gitorious didn't like it (at least at the = top level). Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-embedded@FreeBSD.ORG Thu Dec 22 05:41:44 2011 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C0BA1065672; Thu, 22 Dec 2011 05:41:44 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id CCD908FC0C; Thu, 22 Dec 2011 05:41:43 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so11185341vbb.13 for ; Wed, 21 Dec 2011 21:41:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/y+TcdX37YsqSiOJJ6v51DIV8Ist4u1NnI3TbE9WHoI=; b=vWvh8G1MUf5mduVGteBJnZVDuWl/aQtMFAMxIgHzjZqpfO1+8FteC9NforZLnzlVBi ROMjApmUYJG5l2uPg7OeGN9ofPNa7BAKv7MrxrKQM5uw2VnjEcUOyO7BniHA89MPxw+q RvHYCfxVdAbO26zUtd8BFdA1WxdgNPJLbjMlw= MIME-Version: 1.0 Received: by 10.52.114.232 with SMTP id jj8mr5279105vdb.94.1324532501528; Wed, 21 Dec 2011 21:41:41 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.158.104 with HTTP; Wed, 21 Dec 2011 21:41:41 -0800 (PST) In-Reply-To: <09670C34-0D30-46BC-BA7E-4AAA22193B61@lassitu.de> References: <0F6CC18F-6973-42A2-AC03-F01BF59458AE@lassitu.de> <1100F70E-9DA9-4163-AC9A-423ECE5AA9A3@lassitu.de> <18CABB46-9B9A-41CB-8742-6723C5FF4D67@lassitu.de> <2CBD8651-E132-49DC-A082-37A8F5C626EA@bsdimp.com> <09670C34-0D30-46BC-BA7E-4AAA22193B61@lassitu.de> Date: Wed, 21 Dec 2011 21:41:41 -0800 X-Google-Sender-Auth: WSLHJHU6Uv_C3qx-IFGITOFOf-Y Message-ID: From: Adrian Chadd To: Stefan Bethke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Oleksandr Tymoshenko , "freebsd-embedded@freebsd.org" Subject: Re: Updated switch/glue patch? X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 05:41:44 -0000 On 21 December 2011 07:13, Stefan Bethke wrote: > I've replaced the generic PHY status poll with a custom one that uses the= switch registers instead of the PHYs. =A0I've cloned your git and have sta= rted adding my changes to it (branch also named work/ath): > http://gitorious.org/~stb/freebsd/stb-adrianchadd-freebsd-work > > I tried a merge request, but gitorious didn't like it (at least at the to= p level). Cool! Can you please either figure out why that's the case, or just throw me some diffs? We should figure out how to merge stuff back into your tree to mine (and then propagate the changes back to you) so we don't have to face this when the changes are bigger. After that's done, I'll work on you to tidy up the management utility. Then we can start merging in whatever's needed from zrouter, and start pushing this into -HEAD. I don't mind if it's a work in progress - at least something will be in the tree. Adrian From owner-freebsd-embedded@FreeBSD.ORG Thu Dec 22 11:55:17 2011 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25BF0106564A; Thu, 22 Dec 2011 11:55:17 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 1DECD8FC13; Thu, 22 Dec 2011 11:55:16 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id D692F47D71; Thu, 22 Dec 2011 12:55:14 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/mixed; boundary="Apple-Mail=_554C24B4-3E45-41F2-A1D1-A95DF5DD36A5" From: Stefan Bethke In-Reply-To: Date: Thu, 22 Dec 2011 12:55:13 +0100 Message-Id: <45529EC2-73BE-4F69-A9BE-E22D9FEAADD7@lassitu.de> References: <0F6CC18F-6973-42A2-AC03-F01BF59458AE@lassitu.de> <1100F70E-9DA9-4163-AC9A-423ECE5AA9A3@lassitu.de> <18CABB46-9B9A-41CB-8742-6723C5FF4D67@lassitu.de> <2CBD8651-E132-49DC-A082-37A8F5C626EA@bsdimp.com> <09670C34-0D30-46BC-BA7E-4AAA22193B61@lassitu.de> To: Adrian Chadd X-Mailer: Apple Mail (2.1251.1) Cc: Oleksandr Tymoshenko , "freebsd-embedded@freebsd.org" Subject: Re: Updated switch/glue patch? X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 11:55:17 -0000 --Apple-Mail=_554C24B4-3E45-41F2-A1D1-A95DF5DD36A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Am 22.12.2011 um 06:41 schrieb Adrian Chadd: > On 21 December 2011 07:13, Stefan Bethke wrote: >=20 >> I've replaced the generic PHY status poll with a custom one that uses = the switch registers instead of the PHYs. I've cloned your git and have = started adding my changes to it (branch also named work/ath): >> http://gitorious.org/~stb/freebsd/stb-adrianchadd-freebsd-work >>=20 >> I tried a merge request, but gitorious didn't like it (at least at = the top level). >=20 > Cool! Can you please either figure out why that's the case, or just > throw me some diffs? It complains about the merge being too big to display in a browser? Anyway, here's two diffs. I believe you can track my tree by adding it = to your local repository, and then merge it locally. That should be = easier and less error prone than applying diffs. > We should figure out how to merge stuff back into your tree to mine > (and then propagate the changes back to you) so we don't have to face > this when the changes are bigger. I'm tracking your tree and merging changes into mine. One option could = be to allow me write access to your repo and let me stuff my changes = into a branch there. > After that's done, I'll work on you to tidy up the management utility. > Then we can start merging in whatever's needed from zrouter, and start > pushing this into -HEAD. I don't mind if it's a work in progress - at > least something will be in the tree. Cool! I've got a WRT160NL here with an RTL8306S which I could write a driver = for. I started bringing FreeBSD up on that last night, but accidentally = overwrote half my uboot. Waiting for the JTAG adapter to ship... Stefan --=20 Stefan Bethke Fon +49 151 14070811 --Apple-Mail=_554C24B4-3E45-41F2-A1D1-A95DF5DD36A5 Content-Disposition: attachment; filename=rtl8366rb.patch Content-Type: application/octet-stream; name="rtl8366rb.patch" Content-Transfer-Encoding: 7bit diff --git a/sys/dev/etherswitch/rtl8366rb.c b/sys/dev/etherswitch/rtl8366rb.c index f41a425..6f3e378 100644 --- a/sys/dev/etherswitch/rtl8366rb.c +++ b/sys/dev/etherswitch/rtl8366rb.c @@ -139,7 +139,7 @@ rtl8366rb_attach(device_t dev) sc = device_get_softc(dev); sc->dev = dev; - mtx_init(&sc->sc_mtx, device_get_nameunit(dev), MTX_NETWORK_LOCK, + mtx_init(&sc->sc_mtx, device_get_nameunit(dev), "rtl8366rb", MTX_DEF); rtl8366rb_init(dev); smi_read(dev, RTL8366RB_CVCR, &rev); @@ -201,16 +201,60 @@ rtl8366rb_detach(device_t dev) } static void +rtl833rb_miipollstat(struct rtl8366rb_softc *sc) +{ + int i; + struct mii_data *mii; + struct mii_softc *child; + uint16_t value; + int portstatus; + + for (i = 0; i < RTL8366RB_NUM_PORTS-1; i++) { + mii = device_get_softc(sc->miibus[i]); + if ((i % 2) == 0) { + smi_read(sc->dev, RTL8366RB_PLSR_BASE + i/2, &value); + portstatus = value & 0xff; + } else { + portstatus = (value >> 8) & 0xff; + } + mii->mii_media_status = IFM_AVALID; + mii->mii_media_active = IFM_ETHER; + if ((portstatus & RTL8366RB_PLSR_LINK) != 0) { + switch (portstatus & RTL8366RB_PLSR_SPEED_MASK) { + case RTL8366RB_PLSR_SPEED_10: + mii->mii_media_active |= IFM_10_T; + break; + case RTL8366RB_PLSR_SPEED_100: + mii->mii_media_active |= IFM_100_TX; + break; + case RTL8366RB_PLSR_SPEED_1000: + mii->mii_media_active |= IFM_1000_T; + break; + } + if ((portstatus & RTL8366RB_PLSR_FULLDUPLEX) != 0) + mii->mii_media_active |= IFM_FDX; + else + mii->mii_media_active |= IFM_HDX; + if ((portstatus & RTL8366RB_PLSR_TXPAUSE) != 0) + mii->mii_media_active |= IFM_ETH_TXPAUSE; + if ((portstatus & RTL8366RB_PLSR_RXPAUSE) != 0) + mii->mii_media_active |= IFM_ETH_RXPAUSE; + } else + mii->mii_media_active |= IFM_NONE; + LIST_FOREACH(child, &mii->mii_phys, mii_list) { + if (IFM_INST(mii->mii_media.ifm_cur->ifm_media) != child->mii_inst) + continue; + (void)PHY_SERVICE(child, mii, MII_POLLSTAT); + } + } +} + +static void rtl8366rb_tick(void *arg) { struct rtl8366rb_softc *sc = arg; - int i; - for (i=0; i < RTL8366RB_NUM_PORTS-1; i++) { - if (sc->miibus[i] != NULL) - mii_tick(device_get_softc(sc->miibus[i])); - mii_pollstat(device_get_softc(sc->miibus[i])); - } + rtl833rb_miipollstat(sc); callout_reset(&sc->callout_tick, hz, rtl8366rb_tick, sc); } @@ -435,10 +479,7 @@ rtl8366rb_ifmedia_upd(struct ifnet *ifp) { struct rtl8366rb_softc *sc = ifp->if_softc; struct mii_data *mii = device_get_softc(sc->miibus[ifp->if_dunit]); - struct mii_softc *miisc; - LIST_FOREACH(miisc, &mii->mii_phys, mii_list) - PHY_RESET(miisc); mii_mediachg(mii); return (0); } diff --git a/sys/dev/etherswitch/rtl8366rbvar.h b/sys/dev/etherswitch/rtl8366rbvar.h index f14373a..df17cb6 100644 --- a/sys/dev/etherswitch/rtl8366rbvar.h +++ b/sys/dev/etherswitch/rtl8366rbvar.h @@ -65,7 +65,8 @@ #define RTL8366RB_PLSR_SPEED_10 0x00 #define RTL8366RB_PLSR_SPEED_100 0x01 #define RTL8366RB_PLSR_SPEED_1000 0x02 -#define RTL8366RB_PLSR_FULLDUPLEX 0x10 +#define RTL8366RB_PLSR_FULLDUPLEX 0x08 +#define RTL8366RB_PLSR_LINK 0x10 #define RTL8366RB_PLSR_TXPAUSE 0x20 #define RTL8366RB_PLSR_RXPAUSE 0x40 #define RTL8366RB_PLSR_NO_AUTO 0x80 --Apple-Mail=_554C24B4-3E45-41F2-A1D1-A95DF5DD36A5 Content-Disposition: attachment; filename=iicbb.patch Content-Type: application/octet-stream; x-unix-mode=0644; name="iicbb.patch" Content-Transfer-Encoding: 7bit diff --git a/sys/dev/iicbus/iicbb.c b/sys/dev/iicbus/iicbb.c index fed203c..e060a75 100644 --- a/sys/dev/iicbus/iicbb.c +++ b/sys/dev/iicbus/iicbb.c @@ -25,7 +25,7 @@ */ #include -__FBSDID("$FreeBSD$"); +__FBSDID("$FreeBSD: head/sys/dev/iicbus/iicbb.c 188461 2009-02-10 22:50:23Z imp $"); /* * Generic I2C bit-banging code @@ -48,9 +48,9 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include - #include #include @@ -59,9 +59,31 @@ __FBSDID("$FreeBSD$"); #include "iicbus_if.h" #include "iicbb_if.h" +#define IIC_DELAY_100KHZ 3 /* 3 microseconds per quarter cycle, should be 2.5 */ + +#if defined(DEBUG) +static int i2c_debug = 0; +#define I2C_DEBUG(x) \ + do { \ + if (i2c_debug) (x); \ + } while (0) + +#define I2C_LOG(args...) \ + do { \ + if (i2c_debug) printf(args); \ + } while (0) +static SYSCTL_NODE(_debug, OID_AUTO, iicbb, CTLFLAG_RD, 0, "iicbb"); +SYSCTL_INT(_debug_iicbb, OID_AUTO, debug, CTLFLAG_RW, &i2c_debug, 0, + "print bus transactions"); +#else +#define I2C_DEBUG(x) +#define I2C_LOG(args...) +#endif + struct iicbb_softc { device_t iicbus; - int udelay; /* signal toggle delay in usec */ + int iicdelay; + int iictimeout; }; static int iicbb_attach(device_t); @@ -126,11 +148,11 @@ iicbb_attach(device_t dev) if (!sc->iicbus) return (ENXIO); - sc->udelay = 10; /* 10 uS default */ + sc->udelay = IIC_DELAY_100KHZ; if (resource_int_value(device_get_name(dev), device_get_unit(dev), "udelay", &udelay) == 0) - sc->udelay = udelay; - device_printf(dev, "udelay=%d microseconds\n", sc->udelay); + sc->iicdelay = udelay; + device_printf(dev, "udelay=%d microseconds\n", sc->iicdelay); bus_generic_attach(dev); @@ -193,149 +215,191 @@ iicbb_print_child(device_t bus, device_t dev) return (retval); } -#define I2C_SETSDA(sc,dev,val) do { \ - IICBB_SETSDA(device_get_parent(dev), val); \ - DELAY(sc->udelay); \ - } while (0) - -#define I2C_SETSCL(dev,val) do { \ - iicbb_setscl(dev, val, 100); \ - } while (0) - -#define I2C_SET(sc,dev,ctrl,data) do { \ - I2C_SETSCL(dev, ctrl); \ - I2C_SETSDA(sc, dev, data); \ - } while (0) - -#define I2C_GETSDA(dev) (IICBB_GETSDA(device_get_parent(dev))) - -#define I2C_GETSCL(dev) (IICBB_GETSCL(device_get_parent(dev))) - -static int i2c_debug = 0; -#define I2C_DEBUG(x) do { \ - if (i2c_debug) (x); \ - } while (0) -#define I2C_LOG(format,args...) do { \ - printf(format, args); \ - } while (0) +/* + * Low-level bus state functions. The following functions implement the + * basic bus states for I2C. We divide the full clock cycle into four + * phases. Transitions of SCL and SDA occur between these phases. The + * nominal duration of each phase is 100 kHz/4, or 2.5 us. Implementations + * for busses and devices can choose a lower delay for faster operation. + * + * Each of the functions returns -1 if the operation could not be completed. + */ -static void -iicbb_setscl(device_t dev, int val, int timeout) +/* + * I2C start (S) and repeated start (Sr) condition + * 0 1 2 3 + * __.__ + * SCL XXXX \__. + * __ + * SDA XXXX \__.__. + * + */ +static __inline int +i2c_start(device_t dev) { - struct iicbb_softc *sc = device_get_softc(dev); - int k = 0; - - IICBB_SETSCL(device_get_parent(dev), val); - DELAY(sc->udelay); - - while (val && !I2C_GETSCL(dev) && k++ < timeout) { - IICBB_SETSCL(device_get_parent(dev), val); - DELAY(sc->udelay); + struct iicbb_softc *sc = (struct iicbb_softc *)device_get_softc(dev); + int timeout = sc->iictimeout; + + /* 0 */ + IICBB_SETSDA(device_get_parent(dev), 1); + IICBB_SETSCL(device_get_parent(dev), 1); + /* wait for the bus to become idle */ + while(1) { + DELAY(sc->iicdelay); + if (IICBB_GETSDA(device_get_parent(dev)) != 0 && + IICBB_GETSCL(device_get_parent(dev)) != 0) + break; + if (timeout <= 0) + return (-1); + timeout -= sc->iicdelay; } - - return; + /* 1 */ + DELAY(sc->iicdelay); + /* 2 */ + IICBB_SETSDA(device_get_parent(dev), 0); + DELAY(sc->iicdelay); + /* 3 */ + IICBB_SETSCL(device_get_parent(dev), 0); + DELAY(sc->iicdelay); + return (0); } -static void -iicbb_one(device_t dev, int timeout) +/* + * I2C stop (P) condition + * 0 1 2 3 + * __.__.__. + * SCL .__/ + * _____. + * SDA XXXX__/ + */ +static __inline int +i2c_stop(device_t dev) { - struct iicbb_softc *sc = device_get_softc(dev); + struct iicbb_softc *sc = (struct iicbb_softc *)device_get_softc(dev); - I2C_SET(sc,dev,0,1); - I2C_SET(sc,dev,1,1); - I2C_SET(sc,dev,0,1); - return; + /* 0 */ + IICBB_SETSDA(device_get_parent(dev), 0); + DELAY(sc->iicdelay); + /* 1 */ + IICBB_SETSCL(device_get_parent(dev), 1); + DELAY(sc->iicdelay); + /* 2 */ + IICBB_SETSDA(device_get_parent(dev), 1); + DELAY(sc->iicdelay); + /* + * we can skip the last delay since the bus will either be idle, + * or the next S will wait long enough to keep the timing correct. + */ + return (0); } -static void -iicbb_zero(device_t dev, int timeout) +/* + * I2C transmit one bit + * 0 1 2 3 + * __.__ + * SCL .__/ \__. + * __.__ + * SDA .XXX__.__XXX. + */ +static __inline int +i2c_xmitbit(device_t dev, int value) { - struct iicbb_softc *sc = device_get_softc(dev); - - I2C_SET(sc,dev,0,0); - I2C_SET(sc,dev,1,0); - I2C_SET(sc,dev,0,0); - return; + struct iicbb_softc *sc = (struct iicbb_softc *)device_get_softc(dev); + int timeout = sc->iictimeout; + + /* 0 */ + IICBB_SETSDA(device_get_parent(dev), value); + DELAY(sc->iicdelay); + /* 1 */ + IICBB_SETSCL(device_get_parent(dev), 1); + while (1) { + DELAY(sc->iicdelay); + if (IICBB_GETSCL(device_get_parent(dev)) != 0) + break; + if (timeout <= 0) + return (-1); + timeout -= sc->iicdelay; + } + /* 2 */ + if (value != 0 && IICBB_GETSDA(device_get_parent(dev)) == 0) + return (-1); /* another master is pulling down SDA */ + DELAY(sc->iicdelay); + /* 3 */ + IICBB_SETSCL(device_get_parent(dev), 0); + DELAY(sc->iicdelay); + return (0); } /* - * Waiting for ACKNOWLEDGE. - * - * When a chip is being addressed or has received data it will issue an - * ACKNOWLEDGE pulse. Therefore the MASTER must release the DATA line - * (set it to high level) and then release the CLOCK line. - * Now it must wait for the SLAVE to pull the DATA line low. - * Actually on the bus this looks like a START condition so nothing happens - * because of the fact that the IC's that have not been addressed are doing - * nothing. - * - * When the SLAVE has pulled this line low the MASTER will take the CLOCK - * line low and then the SLAVE will release the SDA (data) line. + * I2C receive one bit + * 0 1 2 3 + * __.__ + * SCL .__/ \__. + * __.__ + * SDA .XXX__.__XXX. */ -static int -iicbb_ack(device_t dev, int timeout) +static __inline int +i2c_recvbit(device_t dev) { - struct iicbb_softc *sc = device_get_softc(dev); - int noack; - int k = 0; - - I2C_SET(sc,dev,0,1); - I2C_SET(sc,dev,1,1); - do { - noack = I2C_GETSDA(dev); - if (!noack) + struct iicbb_softc *sc = (struct iicbb_softc *)device_get_softc(dev); + int timeout = sc->iictimeout; + int value; + + /* 0 */ + IICBB_SETSDA(device_get_parent(dev), 1); + DELAY(sc->iicdelay); + IICBB_SETSCL(device_get_parent(dev), 1); + while (1) { + DELAY(sc->iicdelay); + if (IICBB_GETSCL(device_get_parent(dev)) != 0) break; - DELAY(1); - k++; - } while (k < timeout); - - I2C_SET(sc,dev,0,1); - I2C_DEBUG(printf("%c ",noack?'-':'+')); - - return (noack); + if (timeout <= 0) + return (-1); + timeout -= sc->iicdelay; + } + value = IICBB_GETSDA(device_get_parent(dev)); + DELAY(sc->iicdelay); + IICBB_SETSCL(device_get_parent(dev), 0); + DELAY(sc->iicdelay); + return (value != 0 ? 1 : 0); } -static void -iicbb_sendbyte(device_t dev, u_char data, int timeout) +/* + * Transmit a byte. Returns -1 on error. + */ +static int +i2c_xmitbyte(device_t dev, int value) { - int i; - - for (i=7; i>=0; i--) { - if (data&(1<= 0; i--) { + error = i2c_xmitbit(dev, (value >> i) & 0x01); + if (error < 0) + return (error); } - I2C_DEBUG(printf("w%02x",(int)data)); - return; + return (error); } -static u_char -iicbb_readbyte(device_t dev, int last, int timeout) +/* + * Receive a byte. Returns the byte value (0..255), or -1 on error. + */ +static int +i2c_recvbyte(device_t dev) { - struct iicbb_softc *sc = device_get_softc(dev); - int i; - unsigned char data=0; - - I2C_SET(sc,dev,0,1); - for (i=7; i>=0; i--) - { - I2C_SET(sc,dev,1,1); - if (I2C_GETSDA(dev)) - data |= (1<= 0; i--) { + error = i2c_recvbit(dev); + if (error < 0) + return (error); + value |= error << i; } - I2C_DEBUG(printf("r%02x%c ",(int)data,last?'-':'+')); - return data; + return (value); } + static int iicbb_callback(device_t dev, int index, caddr_t data) { @@ -351,34 +415,32 @@ iicbb_reset(device_t dev, u_char speed, u_char addr, u_char *oldaddr) static int iicbb_start(device_t dev, u_char slave, int timeout) { - struct iicbb_softc *sc = device_get_softc(dev); int error; + struct iicbb_softc *sc = (struct iicbb_softc *)device_get_softc(dev); - I2C_DEBUG(printf("<")); - - I2C_SET(sc,dev,1,1); - I2C_SET(sc,dev,1,0); - I2C_SET(sc,dev,0,0); - - /* send address */ - iicbb_sendbyte(dev, slave, timeout); - - /* check for ack */ - if (iicbb_ack(dev, timeout)) { - error = IIC_ENOACK; - goto error; - } - - return(0); - -error: - iicbb_stop(dev); - return (error); + I2C_LOG("<"); + + sc->iictimeout = timeout; + if (i2c_start(dev) < 0) + return (IIC_ENOACK); + error = i2c_xmitbyte(dev, slave); + if (error < 0) + return (IIC_EBUSERR); /* lost arbitration */ + I2C_LOG("%02x", slave); + error = i2c_recvbit(dev); + if (error < 0) + return (IIC_EBUSERR); /* lost arbitration */ + I2C_LOG("%c", error != 0 ? '-' : '+'); + return(error != 0 ? IIC_ENOACK : 0); } static int iicbb_stop(device_t dev) { +<<<<<<< HEAD + i2c_stop(dev); + I2C_LOG(">\n"); +======= struct iicbb_softc *sc = device_get_softc(dev); I2C_SET(sc,dev,0,0); @@ -386,26 +448,30 @@ iicbb_stop(device_t dev) I2C_SET(sc,dev,1,1); I2C_DEBUG(printf(">")); I2C_DEBUG(printf("\n")); +>>>>>>> adrian/work/ath return (0); } static int iicbb_write(device_t dev, const char *buf, int len, int *sent, int timeout) { - int bytes, error = 0; + int bytes, ack, error = 0; + I2C_LOG(" W%d:", len); bytes = 0; while (len) { - /* send byte */ - iicbb_sendbyte(dev,(u_char)*buf++, timeout); - - /* check for ack */ - if (iicbb_ack(dev, timeout)) { + I2C_LOG(" %02x", (u_char)*buf); + i2c_xmitbyte(dev,(u_char)*buf++); + ack = i2c_recvbit(dev); + if (ack < 0) + return (IIC_EBUSERR); + I2C_LOG("%c", ack != 0 ? '-' : '+'); + if (len != 1 && ack != 0) { error = IIC_ENOACK; goto error; } - bytes ++; - len --; + bytes++; + len--; } error: @@ -416,19 +482,31 @@ error: static int iicbb_read(device_t dev, char * buf, int len, int *read, int last, int delay) { - int bytes; + int bytes, value, error = 0; + I2C_LOG(" R%d:", len); bytes = 0; while (len) { - /* XXX should insert delay here */ - *buf++ = (char)iicbb_readbyte(dev, (len == 1) ? last : 0, delay); - - bytes ++; - len --; + value = i2c_recvbyte(dev); + if (value < 0) { + error = IIC_EBUSERR; + goto error; + } + I2C_LOG(" %02x", value); + error = i2c_xmitbit(dev, len == 1 && last ? 1 : 0); + if (value < 0) { + error = IIC_EBUSERR; + goto error; + } + I2C_LOG("%c", len == 1 && last ? '-' : '+'); + *buf++ = value; + bytes++; + len--; } +error: *read = bytes; - return (0); + return (error); } DRIVER_MODULE(iicbus, iicbb, iicbus_driver, iicbus_devclass, 0, 0); --Apple-Mail=_554C24B4-3E45-41F2-A1D1-A95DF5DD36A5-- From owner-freebsd-embedded@FreeBSD.ORG Thu Dec 22 12:08:58 2011 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E27E106566B; Thu, 22 Dec 2011 12:08:58 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 86F658FC13; Thu, 22 Dec 2011 12:08:57 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 52AB147DAA; Thu, 22 Dec 2011 13:08:56 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/mixed; boundary="Apple-Mail=_80F6A1CE-E774-4603-B510-783FDD6677E0" From: Stefan Bethke In-Reply-To: <45529EC2-73BE-4F69-A9BE-E22D9FEAADD7@lassitu.de> Date: Thu, 22 Dec 2011 13:08:55 +0100 Message-Id: <7FDE5802-B680-464F-8765-9353D9DDD043@lassitu.de> References: <0F6CC18F-6973-42A2-AC03-F01BF59458AE@lassitu.de> <1100F70E-9DA9-4163-AC9A-423ECE5AA9A3@lassitu.de> <18CABB46-9B9A-41CB-8742-6723C5FF4D67@lassitu.de> <2CBD8651-E132-49DC-A082-37A8F5C626EA@bsdimp.com> <09670C34-0D30-46BC-BA7E-4AAA22193B61@lassitu.de> <45529EC2-73BE-4F69-A9BE-E22D9FEAADD7@lassitu.de> To: Adrian Chadd X-Mailer: Apple Mail (2.1251.1) Cc: Oleksandr Tymoshenko , "freebsd-embedded@freebsd.org" Subject: Re: Updated switch/glue patch? X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 12:08:58 -0000 --Apple-Mail=_80F6A1CE-E774-4603-B510-783FDD6677E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Am 22.12.2011 um 12:55 schrieb Stefan Bethke: >=20 > Am 22.12.2011 um 06:41 schrieb Adrian Chadd: >=20 >> On 21 December 2011 07:13, Stefan Bethke wrote: >>=20 >>> I've replaced the generic PHY status poll with a custom one that = uses the switch registers instead of the PHYs. I've cloned your git and = have started adding my changes to it (branch also named work/ath): >>> http://gitorious.org/~stb/freebsd/stb-adrianchadd-freebsd-work >>>=20 >>> I tried a merge request, but gitorious didn't like it (at least at = the top level). >>=20 >> Cool! Can you please either figure out why that's the case, or just >> throw me some diffs? >=20 > It complains about the merge being too big to display in a browser? >=20 > Anyway, here's two diffs. I believe you can track my tree by adding = it to your local repository, and then merge it locally. That should be = easier and less error prone than applying diffs. >=20 >> We should figure out how to merge stuff back into your tree to mine >> (and then propagate the changes back to you) so we don't have to face >> this when the changes are bigger. >=20 > I'm tracking your tree and merging changes into mine. One option = could be to allow me write access to your repo and let me stuff my = changes into a branch there. >=20 >> After that's done, I'll work on you to tidy up the management = utility. >> Then we can start merging in whatever's needed from zrouter, and = start >> pushing this into -HEAD. I don't mind if it's a work in progress - at >> least something will be in the tree. >=20 > Cool! >=20 > I've got a WRT160NL here with an RTL8306S which I could write a driver = for. I started bringing FreeBSD up on that last night, but accidentally = overwrote half my uboot. Waiting for the JTAG adapter to ship=85 Updated and corrected patch: --Apple-Mail=_80F6A1CE-E774-4603-B510-783FDD6677E0 Content-Disposition: attachment; filename=iicbb.patch Content-Type: application/octet-stream; x-unix-mode=0644; name="iicbb.patch" Content-Transfer-Encoding: 7bit diff --git a/sys/dev/iicbus/iicbb.c b/sys/dev/iicbus/iicbb.c index fed203c..cdb65e5 100644 --- a/sys/dev/iicbus/iicbb.c +++ b/sys/dev/iicbus/iicbb.c @@ -25,7 +25,7 @@ */ #include -__FBSDID("$FreeBSD$"); +__FBSDID("$FreeBSD: head/sys/dev/iicbus/iicbb.c 188461 2009-02-10 22:50:23Z imp $"); /* * Generic I2C bit-banging code @@ -48,9 +48,9 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include - #include #include @@ -59,9 +59,31 @@ __FBSDID("$FreeBSD$"); #include "iicbus_if.h" #include "iicbb_if.h" +#define IIC_DELAY_100KHZ 3 /* 3 microseconds per quarter cycle, should be 2.5 */ + +#if defined(DEBUG) +static int i2c_debug = 0; +#define I2C_DEBUG(x) \ + do { \ + if (i2c_debug) (x); \ + } while (0) + +#define I2C_LOG(args...) \ + do { \ + if (i2c_debug) printf(args); \ + } while (0) +static SYSCTL_NODE(_debug, OID_AUTO, iicbb, CTLFLAG_RD, 0, "iicbb"); +SYSCTL_INT(_debug_iicbb, OID_AUTO, debug, CTLFLAG_RW, &i2c_debug, 0, + "print bus transactions"); +#else +#define I2C_DEBUG(x) +#define I2C_LOG(args...) +#endif + struct iicbb_softc { device_t iicbus; - int udelay; /* signal toggle delay in usec */ + int iicdelay; + int iictimeout; }; static int iicbb_attach(device_t); @@ -126,11 +148,11 @@ iicbb_attach(device_t dev) if (!sc->iicbus) return (ENXIO); - sc->udelay = 10; /* 10 uS default */ + sc->iicdelay = IIC_DELAY_100KHZ; if (resource_int_value(device_get_name(dev), device_get_unit(dev), "udelay", &udelay) == 0) - sc->udelay = udelay; - device_printf(dev, "udelay=%d microseconds\n", sc->udelay); + sc->iicdelay = udelay; + device_printf(dev, "udelay=%d microseconds\n", sc->iicdelay); bus_generic_attach(dev); @@ -193,149 +215,191 @@ iicbb_print_child(device_t bus, device_t dev) return (retval); } -#define I2C_SETSDA(sc,dev,val) do { \ - IICBB_SETSDA(device_get_parent(dev), val); \ - DELAY(sc->udelay); \ - } while (0) -#define I2C_SETSCL(dev,val) do { \ - iicbb_setscl(dev, val, 100); \ - } while (0) - -#define I2C_SET(sc,dev,ctrl,data) do { \ - I2C_SETSCL(dev, ctrl); \ - I2C_SETSDA(sc, dev, data); \ - } while (0) - -#define I2C_GETSDA(dev) (IICBB_GETSDA(device_get_parent(dev))) - -#define I2C_GETSCL(dev) (IICBB_GETSCL(device_get_parent(dev))) - -static int i2c_debug = 0; -#define I2C_DEBUG(x) do { \ - if (i2c_debug) (x); \ - } while (0) - -#define I2C_LOG(format,args...) do { \ - printf(format, args); \ - } while (0) +/* + * Low-level bus state functions. The following functions implement the + * basic bus states for I2C. We divide the full clock cycle into four + * phases. Transitions of SCL and SDA occur between these phases. The + * nominal duration of each phase is 100 kHz/4, or 2.5 us. Implementations + * for busses and devices can choose a lower delay for faster operation. + * + * Each of the functions returns -1 if the operation could not be completed. + */ -static void -iicbb_setscl(device_t dev, int val, int timeout) +/* + * I2C start (S) and repeated start (Sr) condition + * 0 1 2 3 + * __.__ + * SCL XXXX \__. + * __ + * SDA XXXX \__.__. + * + */ +static __inline int +i2c_start(device_t dev) { - struct iicbb_softc *sc = device_get_softc(dev); - int k = 0; - - IICBB_SETSCL(device_get_parent(dev), val); - DELAY(sc->udelay); - - while (val && !I2C_GETSCL(dev) && k++ < timeout) { - IICBB_SETSCL(device_get_parent(dev), val); - DELAY(sc->udelay); + struct iicbb_softc *sc = (struct iicbb_softc *)device_get_softc(dev); + int timeout = sc->iictimeout; + + /* 0 */ + IICBB_SETSDA(device_get_parent(dev), 1); + IICBB_SETSCL(device_get_parent(dev), 1); + /* wait for the bus to become idle */ + while(1) { + DELAY(sc->iicdelay); + if (IICBB_GETSDA(device_get_parent(dev)) != 0 && + IICBB_GETSCL(device_get_parent(dev)) != 0) + break; + if (timeout <= 0) + return (-1); + timeout -= sc->iicdelay; } - - return; + /* 1 */ + DELAY(sc->iicdelay); + /* 2 */ + IICBB_SETSDA(device_get_parent(dev), 0); + DELAY(sc->iicdelay); + /* 3 */ + IICBB_SETSCL(device_get_parent(dev), 0); + DELAY(sc->iicdelay); + return (0); } -static void -iicbb_one(device_t dev, int timeout) +/* + * I2C stop (P) condition + * 0 1 2 3 + * __.__.__. + * SCL .__/ + * _____. + * SDA XXXX__/ + */ +static __inline int +i2c_stop(device_t dev) { - struct iicbb_softc *sc = device_get_softc(dev); + struct iicbb_softc *sc = (struct iicbb_softc *)device_get_softc(dev); - I2C_SET(sc,dev,0,1); - I2C_SET(sc,dev,1,1); - I2C_SET(sc,dev,0,1); - return; + /* 0 */ + IICBB_SETSDA(device_get_parent(dev), 0); + DELAY(sc->iicdelay); + /* 1 */ + IICBB_SETSCL(device_get_parent(dev), 1); + DELAY(sc->iicdelay); + /* 2 */ + IICBB_SETSDA(device_get_parent(dev), 1); + DELAY(sc->iicdelay); + /* + * we can skip the last delay since the bus will either be idle, + * or the next S will wait long enough to keep the timing correct. + */ + return (0); } -static void -iicbb_zero(device_t dev, int timeout) +/* + * I2C transmit one bit + * 0 1 2 3 + * __.__ + * SCL .__/ \__. + * __.__ + * SDA .XXX__.__XXX. + */ +static __inline int +i2c_xmitbit(device_t dev, int value) { - struct iicbb_softc *sc = device_get_softc(dev); - - I2C_SET(sc,dev,0,0); - I2C_SET(sc,dev,1,0); - I2C_SET(sc,dev,0,0); - return; + struct iicbb_softc *sc = (struct iicbb_softc *)device_get_softc(dev); + int timeout = sc->iictimeout; + + /* 0 */ + IICBB_SETSDA(device_get_parent(dev), value); + DELAY(sc->iicdelay); + /* 1 */ + IICBB_SETSCL(device_get_parent(dev), 1); + while (1) { + DELAY(sc->iicdelay); + if (IICBB_GETSCL(device_get_parent(dev)) != 0) + break; + if (timeout <= 0) + return (-1); + timeout -= sc->iicdelay; + } + /* 2 */ + if (value != 0 && IICBB_GETSDA(device_get_parent(dev)) == 0) + return (-1); /* another master is pulling down SDA */ + DELAY(sc->iicdelay); + /* 3 */ + IICBB_SETSCL(device_get_parent(dev), 0); + DELAY(sc->iicdelay); + return (0); } /* - * Waiting for ACKNOWLEDGE. - * - * When a chip is being addressed or has received data it will issue an - * ACKNOWLEDGE pulse. Therefore the MASTER must release the DATA line - * (set it to high level) and then release the CLOCK line. - * Now it must wait for the SLAVE to pull the DATA line low. - * Actually on the bus this looks like a START condition so nothing happens - * because of the fact that the IC's that have not been addressed are doing - * nothing. - * - * When the SLAVE has pulled this line low the MASTER will take the CLOCK - * line low and then the SLAVE will release the SDA (data) line. + * I2C receive one bit + * 0 1 2 3 + * __.__ + * SCL .__/ \__. + * __.__ + * SDA .XXX__.__XXX. */ -static int -iicbb_ack(device_t dev, int timeout) +static __inline int +i2c_recvbit(device_t dev) { - struct iicbb_softc *sc = device_get_softc(dev); - int noack; - int k = 0; - - I2C_SET(sc,dev,0,1); - I2C_SET(sc,dev,1,1); - do { - noack = I2C_GETSDA(dev); - if (!noack) + struct iicbb_softc *sc = (struct iicbb_softc *)device_get_softc(dev); + int timeout = sc->iictimeout; + int value; + + /* 0 */ + IICBB_SETSDA(device_get_parent(dev), 1); + DELAY(sc->iicdelay); + IICBB_SETSCL(device_get_parent(dev), 1); + while (1) { + DELAY(sc->iicdelay); + if (IICBB_GETSCL(device_get_parent(dev)) != 0) break; - DELAY(1); - k++; - } while (k < timeout); - - I2C_SET(sc,dev,0,1); - I2C_DEBUG(printf("%c ",noack?'-':'+')); - - return (noack); + if (timeout <= 0) + return (-1); + timeout -= sc->iicdelay; + } + value = IICBB_GETSDA(device_get_parent(dev)); + DELAY(sc->iicdelay); + IICBB_SETSCL(device_get_parent(dev), 0); + DELAY(sc->iicdelay); + return (value != 0 ? 1 : 0); } -static void -iicbb_sendbyte(device_t dev, u_char data, int timeout) +/* + * Transmit a byte. Returns -1 on error. + */ +static int +i2c_xmitbyte(device_t dev, int value) { - int i; - - for (i=7; i>=0; i--) { - if (data&(1<= 0; i--) { + error = i2c_xmitbit(dev, (value >> i) & 0x01); + if (error < 0) + return (error); } - I2C_DEBUG(printf("w%02x",(int)data)); - return; + return (error); } -static u_char -iicbb_readbyte(device_t dev, int last, int timeout) +/* + * Receive a byte. Returns the byte value (0..255), or -1 on error. + */ +static int +i2c_recvbyte(device_t dev) { - struct iicbb_softc *sc = device_get_softc(dev); - int i; - unsigned char data=0; - - I2C_SET(sc,dev,0,1); - for (i=7; i>=0; i--) - { - I2C_SET(sc,dev,1,1); - if (I2C_GETSDA(dev)) - data |= (1<= 0; i--) { + error = i2c_recvbit(dev); + if (error < 0) + return (error); + value |= error << i; } - I2C_DEBUG(printf("r%02x%c ",(int)data,last?'-':'+')); - return data; + return (value); } + static int iicbb_callback(device_t dev, int index, caddr_t data) { @@ -351,61 +415,53 @@ iicbb_reset(device_t dev, u_char speed, u_char addr, u_char *oldaddr) static int iicbb_start(device_t dev, u_char slave, int timeout) { - struct iicbb_softc *sc = device_get_softc(dev); int error; + struct iicbb_softc *sc = (struct iicbb_softc *)device_get_softc(dev); - I2C_DEBUG(printf("<")); - - I2C_SET(sc,dev,1,1); - I2C_SET(sc,dev,1,0); - I2C_SET(sc,dev,0,0); - - /* send address */ - iicbb_sendbyte(dev, slave, timeout); - - /* check for ack */ - if (iicbb_ack(dev, timeout)) { - error = IIC_ENOACK; - goto error; - } - - return(0); - -error: - iicbb_stop(dev); - return (error); + I2C_LOG("<"); + + sc->iictimeout = timeout; + if (i2c_start(dev) < 0) + return (IIC_ENOACK); + error = i2c_xmitbyte(dev, slave); + if (error < 0) + return (IIC_EBUSERR); /* lost arbitration */ + I2C_LOG("%02x", slave); + error = i2c_recvbit(dev); + if (error < 0) + return (IIC_EBUSERR); /* lost arbitration */ + I2C_LOG("%c", error != 0 ? '-' : '+'); + return(error != 0 ? IIC_ENOACK : 0); } static int iicbb_stop(device_t dev) { - struct iicbb_softc *sc = device_get_softc(dev); - - I2C_SET(sc,dev,0,0); - I2C_SET(sc,dev,1,0); - I2C_SET(sc,dev,1,1); - I2C_DEBUG(printf(">")); - I2C_DEBUG(printf("\n")); + i2c_stop(dev); + I2C_LOG(">\n"); return (0); } static int iicbb_write(device_t dev, const char *buf, int len, int *sent, int timeout) { - int bytes, error = 0; + int bytes, ack, error = 0; + I2C_LOG(" W%d:", len); bytes = 0; while (len) { - /* send byte */ - iicbb_sendbyte(dev,(u_char)*buf++, timeout); - - /* check for ack */ - if (iicbb_ack(dev, timeout)) { + I2C_LOG(" %02x", (u_char)*buf); + i2c_xmitbyte(dev,(u_char)*buf++); + ack = i2c_recvbit(dev); + if (ack < 0) + return (IIC_EBUSERR); + I2C_LOG("%c", ack != 0 ? '-' : '+'); + if (len != 1 && ack != 0) { error = IIC_ENOACK; goto error; } - bytes ++; - len --; + bytes++; + len--; } error: @@ -416,19 +472,31 @@ error: static int iicbb_read(device_t dev, char * buf, int len, int *read, int last, int delay) { - int bytes; + int bytes, value, error = 0; + I2C_LOG(" R%d:", len); bytes = 0; while (len) { - /* XXX should insert delay here */ - *buf++ = (char)iicbb_readbyte(dev, (len == 1) ? last : 0, delay); - - bytes ++; - len --; + value = i2c_recvbyte(dev); + if (value < 0) { + error = IIC_EBUSERR; + goto error; + } + I2C_LOG(" %02x", value); + error = i2c_xmitbit(dev, len == 1 && last ? 1 : 0); + if (value < 0) { + error = IIC_EBUSERR; + goto error; + } + I2C_LOG("%c", len == 1 && last ? '-' : '+'); + *buf++ = value; + bytes++; + len--; } +error: *read = bytes; - return (0); + return (error); } DRIVER_MODULE(iicbus, iicbb, iicbus_driver, iicbus_devclass, 0, 0); --Apple-Mail=_80F6A1CE-E774-4603-B510-783FDD6677E0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 -- Stefan Bethke Fon +49 151 14070811 --Apple-Mail=_80F6A1CE-E774-4603-B510-783FDD6677E0-- From owner-freebsd-embedded@FreeBSD.ORG Thu Dec 22 15:06:50 2011 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6FEE106566C for ; Thu, 22 Dec 2011 15:06:50 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 70C548FC19 for ; Thu, 22 Dec 2011 15:06:50 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id BDEE170202 for ; Thu, 22 Dec 2011 16:06:48 +0100 (CET) From: Stefan Bethke Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Dec 2011 16:06:47 +0100 Message-Id: To: freebsd-embedded@freebsd.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: New port: firmware-utils X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 15:06:50 -0000 Maybe one of the committers could take a look at this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D163537 A collection of utilities to create firmware images for embedded = devices, including many wireless routers from many vendors. The utilities are collected and maintained by the OpenWrt router = project. This reduces the amount of custom infrastructure for building images = another step. Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-embedded@FreeBSD.ORG Thu Dec 22 21:55:54 2011 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BB85106566B for ; Thu, 22 Dec 2011 21:55:54 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2978D8FC08 for ; Thu, 22 Dec 2011 21:55:53 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so12328814vbb.13 for ; Thu, 22 Dec 2011 13:55:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UJhPFfQiQO8Uy41MCabdGwlXL770jiTZNGL2vvMGCKE=; b=o0FCTmApLcpUgWKVUH9c7PH7ZYNYSirts7mPte+z3IBTYVKrtEuPXHv3JnuooGkY+g JFG21fzOjOndh7ssI22x4ZV3h7SdMcG74L+gcHY3AQZnYfAqHmTmdXMZ1gcC7n3pSAMt RkbsfufVAk4rOkdJCkJbpHga/uFKOeI+j2WGM= MIME-Version: 1.0 Received: by 10.52.24.11 with SMTP id q11mr6626992vdf.83.1324590953519; Thu, 22 Dec 2011 13:55:53 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Thu, 22 Dec 2011 13:55:53 -0800 (PST) In-Reply-To: References: Date: Thu, 22 Dec 2011 13:55:53 -0800 X-Google-Sender-Auth: lOJ_Zg-UkZkiFr498ls7Fx-EUng Message-ID: From: Adrian Chadd To: Stefan Bethke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-embedded@freebsd.org Subject: Re: New port: firmware-utils X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 21:55:54 -0000 Cool, I'll take a look. My local tools have some patches (the stuff in freebsd-wifi-build) which adds configuration partition bits to the Ubiquiti redboot image generator. I'll try to push those upstream. Adrian On 22 December 2011 07:06, Stefan Bethke wrote: > Maybe one of the committers could take a look at this PR: > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D163537 > > A collection of utilities to create firmware images for embedded devices, > including many wireless routers from many vendors. > > The utilities are collected and maintained by the OpenWrt router project. > > This reduces the amount of custom infrastructure for building images anot= her step. > > > Stefan > > -- > Stefan Bethke =A0 Fon +49 151 14070811 > > > > _______________________________________________ > 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 Fri Dec 23 00:54:48 2011 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 669BD106564A for ; Fri, 23 Dec 2011 00:54:48 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 07D6E8FC14 for ; Fri, 23 Dec 2011 00:54:47 +0000 (UTC) Received: by eekc50 with SMTP id c50so10569283eek.13 for ; Thu, 22 Dec 2011 16:54:47 -0800 (PST) Received: by 10.213.23.6 with SMTP id p6mr383878ebb.61.1324600300489; Thu, 22 Dec 2011 16:31:40 -0800 (PST) Received: from rnote.ddteam.net (11-119-133-95.pool.ukrtel.net. [95.133.119.11]) by mx.google.com with ESMTPS id t59sm41021566eeh.10.2011.12.22.16.31.38 (version=SSLv3 cipher=OTHER); Thu, 22 Dec 2011 16:31:39 -0800 (PST) Date: Fri, 23 Dec 2011 02:31:37 +0200 From: Aleksandr Rybalko To: embedded@freebsd.org Message-Id: <20111223023137.fd9a7560.ray@ddteam.net> X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: geom_uncompress X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 00:54:48 -0000 Hi everybody, some time ago i already introduce geom_uncompress, that must replace geom_uzip with additional ability to use lzma for fs compression. IIRC, if we have 11MB ISO with MIPS32 rootfs, then we will have ~5MB uzip or ~3MB of ulzma. So i post it again, and hope to see more interest to it :) Patch located here: http://my.ddteam.net/files/geom_uncompress_2011-12-23.patch one note: correct please sys/conf/files diff by hands, since i have many things in it. :) -- Aleksandr Rybalko From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 23 10:41:15 2011 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 013B6106566B; Fri, 23 Dec 2011 10:41:15 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id B818E8FC1A; Fri, 23 Dec 2011 10:41:14 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 923E1836C1; Fri, 23 Dec 2011 11:41:13 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Stefan Bethke In-Reply-To: Date: Fri, 23 Dec 2011 11:41:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Adrian Chadd X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-embedded@freebsd.org Subject: Re: New port: firmware-utils X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 10:41:15 -0000 Am 22.12.2011 um 22:55 schrieb Adrian Chadd: > On 22 December 2011 07:06, Stefan Bethke wrote: >> Maybe one of the committers could take a look at this PR: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D163537 >>=20 >> A collection of utilities to create firmware images for embedded = devices, >> including many wireless routers from many vendors. >>=20 >> The utilities are collected and maintained by the OpenWrt router = project. >>=20 >> This reduces the amount of custom infrastructure for building images = another step. >=20 > Cool, I'll take a look. >=20 > My local tools have some patches (the stuff in freebsd-wifi-build) > which adds configuration partition bits to the Ubiquiti redboot image > generator. > I'll try to push those upstream. It's not unheard of to have such patches in the port until they're = accepted upstream. Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 23 10:47:38 2011 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79A2D106564A for ; Fri, 23 Dec 2011 10:47:38 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 36BC28FC15 for ; Fri, 23 Dec 2011 10:47:38 +0000 (UTC) Received: from terran.dlink.ua (unknown [192.168.10.90]) by smtp.dlink.ua (Postfix) with SMTP id A19C7C4934 for ; Fri, 23 Dec 2011 12:28:28 +0200 (EET) Date: Fri, 23 Dec 2011 12:29:47 +0200 From: Aleksandr Rybalko To: embedded@freebsd.org Message-Id: <20111223122947.4235c390.ray@freebsd.org> Organization: FreeBSD Project X-Mailer: Sylpheed 2.7.1 (GTK+ 2.20.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: geom_uncompress X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 10:47:38 -0000 Hi embedded, Update patch with some tidy: http://my.ddteam.net/files/geom_uncompress_2011-12-23_2.patch WBW -- Aleksandr Rybalko From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 23 12:05:11 2011 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F691106566C; Fri, 23 Dec 2011 12:05:11 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 149348FC17; Fri, 23 Dec 2011 12:05:11 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 52C0F83908; Fri, 23 Dec 2011 13:05:10 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: <20111223122947.4235c390.ray@freebsd.org> Date: Fri, 23 Dec 2011 13:05:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1C7BEB2A-E3DE-4AB0-BC57-AC0025116EF0@lassitu.de> References: <20111223122947.4235c390.ray@freebsd.org> To: Aleksandr Rybalko X-Mailer: Apple Mail (2.1251.1) Cc: embedded@freebsd.org Subject: Re: geom_uncompress X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 12:05:11 -0000 Very cool! Am 23.12.2011 um 11:29 schrieb Aleksandr Rybalko: > http://my.ddteam.net/files/geom_uncompress_2011-12-23_2.patch In your original patch in February 2010, you supported only lzma. In = this version, your module supports both zlib and lzma compression. = Wouldn't it make more sense to replace geom_uzip, and integrate mkuzip = and mklzma into a single utility? I also faintly remember some bike shed about the original geom_uzip = name. The magic header definition should likely be in a common file, shared = between the utility(s) and the geom module(s). And a final nitpick: we really don't have a suitable crc32 function in = the kernel already? Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 23 15:31:41 2011 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0696106564A for ; Fri, 23 Dec 2011 15:31:41 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 6AAFC8FC0C for ; Fri, 23 Dec 2011 15:31:41 +0000 (UTC) Received: from rnote.ddteam.net (11-119-133-95.pool.ukrtel.net [95.133.119.11]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id 4BFBAC4930; Fri, 23 Dec 2011 17:31:40 +0200 (EET) Date: Fri, 23 Dec 2011 17:31:39 +0200 From: Aleksandr Rybalko To: Stefan Bethke Message-Id: <20111223173139.dd31e9cb.ray@freebsd.org> In-Reply-To: <1C7BEB2A-E3DE-4AB0-BC57-AC0025116EF0@lassitu.de> References: <20111223122947.4235c390.ray@freebsd.org> <1C7BEB2A-E3DE-4AB0-BC57-AC0025116EF0@lassitu.de> Organization: FreeBSD.ORG X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) X-Operating-System: FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: embedded@freebsd.org Subject: Re: geom_uncompress X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 15:31:41 -0000 On Fri, 23 Dec 2011 13:05:09 +0100 Stefan Bethke wrote: > Very cool! > > Am 23.12.2011 um 11:29 schrieb Aleksandr Rybalko: > > > http://my.ddteam.net/files/geom_uncompress_2011-12-23_2.patch > > In your original patch in February 2010, you supported only lzma. In > this version, your module supports both zlib and lzma compression. > Wouldn't it make more sense to replace geom_uzip, and integrate > mkuzip and mklzma into a single utility? Agree, but this is for future. > > I also faintly remember some bike shed about the original geom_uzip > name. Yes, I also remember that, finally we decide to use short but unambiguous name. geom_uncompress from that point. :) > > The magic header definition should likely be in a common file, shared > between the utility(s) and the geom module(s). As you mentioning first, better to have both in one utility. Even better to include bzip2 in same utility. > > And a final nitpick: we really don't have a suitable crc32 function > in the kernel already? I don't have a plans to rewrite and embed lzma code to base. There is the way to use external crc32 in xz-embedded, but it also take some time. And crc code not so big even for embedded purposes. Anyway I agree with you in that question too. > > > Stefan > > -- > Stefan Bethke Fon +49 151 14070811 > > > Thank you for comments/questions Stefan. WBW -- Aleksandr Rybalko From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 23 22:18:35 2011 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 985B11065677 for ; Fri, 23 Dec 2011 22:18:35 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4D8B68FC1B for ; Fri, 23 Dec 2011 22:18:34 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so13495914vbb.13 for ; Fri, 23 Dec 2011 14:18:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=1elQSGkEH4UxuDYF7nEHwhdj7zkaTnaLNcXFlt5GHdg=; b=haN2EdnWIwDfGlrhGHx8ue8tPr4PhbwSxdqsuf06h/YsYKm0j2wdwvnq8Kn8LL9YZa /D8+YxC2K2LqhCWwyqRPiKjlnanwpjwHpijPL3liWpSOCttdNnOlYtH3AIGr7k10Cpx4 v2j5diNc37Qu49LC9Fi/brVfha65c9gex97hs= MIME-Version: 1.0 Received: by 10.52.33.99 with SMTP id q3mr8348442vdi.100.1324677314785; Fri, 23 Dec 2011 13:55:14 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Fri, 23 Dec 2011 13:55:14 -0800 (PST) In-Reply-To: <20111223173139.dd31e9cb.ray@freebsd.org> References: <20111223122947.4235c390.ray@freebsd.org> <1C7BEB2A-E3DE-4AB0-BC57-AC0025116EF0@lassitu.de> <20111223173139.dd31e9cb.ray@freebsd.org> Date: Fri, 23 Dec 2011 13:55:14 -0800 X-Google-Sender-Auth: bOg2KeK1Blo6icQ8Ssseprgvap0 Message-ID: From: Adrian Chadd To: Aleksandr Rybalko Content-Type: text/plain; charset=ISO-8859-1 Cc: embedded@freebsd.org, Stefan Bethke Subject: Re: geom_uncompress X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 22:18:35 -0000 Hi, Some more of my comments: * We can do a pass later on to integrate this stuff into the kernel better, including using a single crc32 function. * The style seems quite fine, except the '?0:1' bits - can you please expand that out with spaces and put them on a new line (as they're already pushing up against 78 characters) I really don't like the cute hack of "sh image.uzlma". :) The main problem I have with it is it really is only appropriate if you're mounting things as a R/O cd9660 format, and totally silly otherwise. Can we possibly remove that for now, and maybe you can add that as a "vendor customisation" in zrouter somehow? (eg creating another flag in the magic header or something?) Other than that, I'm happy to commit this whole thing to FreeBSD and sort out the mess after that. Adrian From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 23 23:14:58 2011 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A0151065673 for ; Fri, 23 Dec 2011 23:14:58 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id C76518FC0C for ; Fri, 23 Dec 2011 23:14:57 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id A1E8F9CDE6; Sat, 24 Dec 2011 00:14:56 +0100 (CET) From: Stefan Bethke Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 24 Dec 2011 00:14:55 +0100 Message-Id: To: Warner Losh Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-embedded@freebsd.org Subject: SD-Card over SPI? X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 23:14:58 -0000 Hi Warner, I was hopeful that there would be a driver in the tree already bridging = between an SPI and mmc(4), but I can't seem to find it. Where would it = be if it exists? Thanks, Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-embedded@FreeBSD.ORG Sat Dec 24 02:29:11 2011 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 942781065670 for ; Sat, 24 Dec 2011 02:29:10 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 3A0C48FC0C for ; Sat, 24 Dec 2011 02:29:10 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id pBO2Sr5s006193 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Fri, 23 Dec 2011 19:28:54 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Fri, 23 Dec 2011 19:28:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <27489519-A37A-4DAE-902F-DA33164EF756@bsdimp.com> References: To: Stefan Bethke X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Fri, 23 Dec 2011 19:28:54 -0700 (MST) Cc: freebsd-embedded@freebsd.org Subject: Re: SD-Card over SPI? X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 02:29:11 -0000 On Dec 23, 2011, at 4:14 PM, Stefan Bethke wrote: > Hi Warner, >=20 > I was hopeful that there would be a driver in the tree already = bridging between an SPI and mmc(4), but I can't seem to find it. Where = would it be if it exists? Not that I'm aware of. The commands are a little different between = MMC/SD interface and SPI. Warner From owner-freebsd-embedded@FreeBSD.ORG Sat Dec 24 03:02:19 2011 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 048BC1065673 for ; Sat, 24 Dec 2011 03:02:19 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 796788FC0A for ; Sat, 24 Dec 2011 03:02:18 +0000 (UTC) Received: by lahl5 with SMTP id l5so5495890lah.13 for ; Fri, 23 Dec 2011 19:02:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Sf2UGaG8h+vwb1XzrSbblwi1glgWMhqa45ywz/tcuw8=; b=p/ZRhMdXhzHqKAlX/+YDKhiB2Yf91zaOZfCutzHf52ZddJotko6s94XSsakMo0aNtR f0ZrFuT4lchZsM3X2sM79qCpA7jaEMS5RTemJemoMjeD/6uSIhAGs9qOY8b/wnfPJTne EKIKJ+oiLg6XgAxVPJiCOYn10tQZ3OsnZ1eb0= Received: by 10.152.128.196 with SMTP id nq4mr14482770lab.35.1324694127703; Fri, 23 Dec 2011 18:35:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.129.8 with HTTP; Fri, 23 Dec 2011 18:34:56 -0800 (PST) In-Reply-To: References: From: Eitan Adler Date: Fri, 23 Dec 2011 21:34:56 -0500 Message-ID: To: Stefan Bethke Content-Type: text/plain; charset=UTF-8 Cc: freebsd-embedded@freebsd.org Subject: Re: New port: firmware-utils X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 03:02:19 -0000 On Thu, Dec 22, 2011 at 10:06 AM, Stefan Bethke wrote: > Maybe one of the committers could take a look at this PR: > http://www.freebsd.org/cgi/query-pr.cgi?pr=163537 I'll take a look into adding it to the ports tree. Other people here may want to take a look into it on a more functional level ;) -- Eitan Adler