From owner-freebsd-embedded@FreeBSD.ORG Sun Oct 6 18:19:56 2013 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 41B3315C; Sun, 6 Oct 2013 18:19:56 +0000 (UTC) (envelope-from ilya@bakulin.de) Received: from olymp.kibab.com (olymp.kibab.com [5.9.14.202]) by mx1.freebsd.org (Postfix) with ESMTP id B8DD72848; Sun, 6 Oct 2013 18:19:54 +0000 (UTC) X-DKIM: OpenDKIM Filter v2.5.2 olymp.kibab.com D0D9D3F447 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bakulin.de; s=default; t=1381083587; bh=ilu33trIiXzOoa7e7n1atkD2kUcPDnQrePzuIwOYvm8=; h=Date:From:To:CC:Subject; b=z8zLOxaNAv2nsi97VWW8hjzfpDuU3GNuOIo7LaCnK9TfgTF7v7XLPUHIw32o6pgNA SSXZhGDFh71zBoowGKmA1D7TvlyzYK2o/Qq3m6fK5qyIqpUVirTf9MwjNAkeSfPfND EV7yIsEQUY9/OyIMM/Z9wA+6vAsJYfFa+fWg/qBc= Message-ID: <5251A9D3.1080803@bakulin.de> Date: Sun, 06 Oct 2013 20:20:03 +0200 From: Ilya Bakulin MIME-Version: 1.0 To: Warner Losh , Alexander Motin , Adrian Chadd Subject: SDIO for FreeBSD X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GDMAeSsRCntmpIADPiVqHTMKix2lmq8EV" Cc: "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 18:19:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GDMAeSsRCntmpIADPiVqHTMKix2lmq8EV Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just a quick status update. I have managed to make interrupts work. Was rather silly copy&paste mista= ke. So now I'm able to issue a command to the WiFi card and actually get an interrupt from the controller. I have added several bus methods for setting up interrupt handlers and allocating resources, both to the MMC stack and to my WiFi driver, as well as mv_sdio SDIO controller driver for DreamPlug. The code is kept under [1], as usual. I have the fully working stack now and I'd like to discuss the locking model for SDIO. So, the SDIO controller detects an interrupt. SDIO controller driver handles it its own interrupt thread (I assume that we use ITHREAD ISRs). All the controller can do at this stage is: 1. read device registers to get the interrupt cause; 2. clear/set some bits in device registers; 3. If there was a command- or data-related interrupt, call req->done() method of struct mmc_request, which sets MMC_REQ_DONE flag in the request structure and then calls wakeup() on mmc_request. This is what actually happens now. MMC stack which is doing msleep() waiting for MMC_REQ_DONE flag detects this flag and continues with request processing, returning a result to the upper layer. See mmc_wakeup() and mmc_wait_for_req() in sys/dev/mmc/mmc.c Everything is syncronous at this point, no complications. Now the SDIO case. The controller can detect an interrupt at any time, then it notifies the MMC stack about it. This happens in the ITHREAD of SDIO controller's ISR. In MMC stack, we now want to read the "Penging interrupts" register to figure out which function has raised the interrupt. We cannot, however, issue another request to SDIO controller since that inhibits sleeping and we cannot sleep in ISR. We will also need to call ISRs of our child devices that can possibly do another weird stuff. So I propose adding a dedicated thread in MMC layer that will just process the interrupts from the card. It can be started on MMC stack attach, grab MMC lock and then just sleep on condition variable (which will be per-bus, ie for each SDIO card since there can only be one SD[IO] card on the bus), giving the lock back. When the MMC stack's ISR is called by SDIO controller, it will just cv_signal() that variable and do nothing more than that. The MMC interrupt servicing thread will then wakeup (and grab the MMC lock!), it will be able to do another MMC request to read "pending interrupts" register and call the ISRs of respective child drivers. We expect them to be quick and probably do the similar stuff -- just signaling CVs and/or taskqueue_enqueue()-ing interrupt processing tasks. Sorry if I totally misunderstand the concept here, please tell your opinions. [1] https://github.com/kibab/freebsd/compare/master...kibab-dplug Note that I have made a rebase and pushed the rebased branch back to GitH= ub. This is an epic fuckup and it requires everyone to delete the local branch and pull it once again, as the IDs have changed. Sorry for that, I will do merges next time. -- Regards, Ilya Bakulin --GDMAeSsRCntmpIADPiVqHTMKix2lmq8EV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlJRqdcACgkQo9vlj1oadwgR+wCghJ8m+uzm7xi7e9hy7IZSV1sQ BQEAn27H8ajw6DEFcMhuyQ/R3pVw2V3s =Tlri -----END PGP SIGNATURE----- --GDMAeSsRCntmpIADPiVqHTMKix2lmq8EV-- From owner-freebsd-embedded@FreeBSD.ORG Sun Oct 6 19:21:36 2013 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F171B877 for ; Sun, 6 Oct 2013 19:21:36 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C33AB2B29 for ; Sun, 6 Oct 2013 19:21:36 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id e14so13573049iej.20 for ; Sun, 06 Oct 2013 12:21:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version; bh=JUE0X5JddP9+A67Ko4uwkfnM1GdfsL5KjI2Jt069uhk=; b=cx+QHFjY1K52H4iQS08FaWJ6uyws0VfSffwwpTM0KKtDYYJQUWQn3VLHVPT4JxVpjd CBsulOtISinWUkgtvUbyTxMk8PdP/AHE7cogcObNUPw7DJklE2TGB7HIRLkOlBEN1uX5 vZuaY9vpNEw78gb3YO0QbY8BXtt4KVka52Fc/84TM4shZ4Z1uzwLl0ZTgUCTSFAZWTUg F8xBiSWp0ssuD1I5V2eqLjrwFHoCJc+sQJ2Hre8PwAiN3AkRYhajuN7U22onCAwsAld1 ANSHwyL0o1TdW02yhfDya1BhNH4NEWt7Yo89jL565Ia9Tv6MkKOc9FgHrvGhjkm8xLlv 121A== X-Gm-Message-State: ALoCoQlyOcYblwCVjU2cnDi5ggUa50celrXyJTTZXgKj6/MMsP8dPfj+4eSWr2gYD2nBp5I8qT79 X-Received: by 10.50.87.4 with SMTP id t4mr14452042igz.18.1381087295501; Sun, 06 Oct 2013 12:21:35 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id oq3sm22003879igb.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 06 Oct 2013 12:21:35 -0700 (PDT) Sender: Warner Losh From: Warner Losh Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: And experiment: Publishing my mercurial patch queue Date: Sun, 6 Oct 2013 13:21:34 -0600 Message-Id: To: embedded@freebsd.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 19:21:37 -0000 Greetings, With the code freeze, I'm starting to accumulate a few patches in my = tree. I've started using mercurial to manage my patch queue after the = utter fail of svn-stash to do what I want. Patch queues are a thing that = hg has optimized for upstream submission, so publishing it seems a = reasonable thing. If you don't have mercurial, or don't want to, you can look at the raw = patch queue at this URL: http://people.freebsd.org/~imp/embedded-patch-queue/patches/ and brows the patches. All the files in this directory are patches, = except series which lists the order. If you want to replicate what I have with mercurial: svn co cd hg init hg add hg forget .svn cd .hg hg clone http://people.freebsd.org/~imp/embedded-patch-queue/patches cd .. hg qpush, etc Anyway, thought I'd mention it here, since this may be a good way to get = more involvement on my patches, some of which take months to fully bake = due to the large range of mips and arm platforms we have. Comments? Warner From owner-freebsd-embedded@FreeBSD.ORG Sun Oct 6 20:31:02 2013 Return-Path: Delivered-To: embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9AF8A989 for ; Sun, 6 Oct 2013 20:31:02 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7185A2E10 for ; Sun, 6 Oct 2013 20:30:58 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VSuyf-000Fcl-Rt; Sun, 06 Oct 2013 20:30:58 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r96KUtFP016566; Sun, 6 Oct 2013 14:30:55 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19QBWGOUlNpbnDa8O8Kf6eP Subject: Re: And experiment: Publishing my mercurial patch queue From: Ian Lepore To: Warner Losh In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Sun, 06 Oct 2013 14:30:55 -0600 Message-ID: <1381091455.1152.58.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 20:31:02 -0000 On Sun, 2013-10-06 at 13:21 -0600, Warner Losh wrote: > Greetings, > > With the code freeze, I'm starting to accumulate a few patches in my tree. I've started using mercurial to manage my patch queue after the utter fail of svn-stash to do what I want. Patch queues are a thing that hg has optimized for upstream submission, so publishing it seems a reasonable thing. > > If you don't have mercurial, or don't want to, you can look at the raw patch queue at this URL: > > http://people.freebsd.org/~imp/embedded-patch-queue/patches/ > > and brows the patches. All the files in this directory are patches, except series which lists the order. > > If you want to replicate what I have with mercurial: > > svn co > cd > hg init > hg add > hg forget .svn > cd .hg > hg clone http://people.freebsd.org/~imp/embedded-patch-queue/patches > cd .. > hg qpush, etc > > Anyway, thought I'd mention it here, since this may be a good way to get more involvement on my patches, some of which take months to fully bake due to the large range of mips and arm platforms we have. > > Comments? > You can speed up things like creating a new sandbox if you exclude .svn by default rather than adding it then forgetting it. I have in my .hgrc: [defaults] add = --exclude=.svn --exclude="glob:**.orig" status = --exclude=.svn and conversely in my .subversion/config I have: [Miscellany] global-ignores=.hg *.orig If you want to re-sync a svn+hg sandbox with -current, the incantations I've been using go like this... * hg commit any outstanding changes, or if they're not commitable yet use something like the hg attic extension to set them aside. In general, you want hg status to show a clean sandbox, including "unknown" files like .orig or ~ backups. * svn up * Now find everything svn up deleted and tell hg to delete it as well: hg status | grep "^!" | cut2 | xargs hg delete * Now tell hg to add new files added by svn up: hg status -u | grep "^?" | cut2 | xargs hg add * hg commit -m "Sync with svn rNNNNNNN" The "cut2" in those command sequences is this script: #!/bin/sh tr -s '\t ' ' ' | cut -d' ' -f2 -- Ian From owner-freebsd-embedded@FreeBSD.ORG Sun Oct 6 20:33:26 2013 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 521C69DB; Sun, 6 Oct 2013 20:33:26 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ee0-x231.google.com (mail-ee0-x231.google.com [IPv6:2a00:1450:4013:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B8F132E25; Sun, 6 Oct 2013 20:33:25 +0000 (UTC) Received: by mail-ee0-f49.google.com with SMTP id d41so2783396eek.22 for ; Sun, 06 Oct 2013 13:33:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=YiWKo+3mjGy4oLkmZgo25NkeeTWslnj8Xx21dCq+Lew=; b=NMKax8ugYiuv8XznrZj3+yoR4260dp7aR+E8ioayCNTqrJndmCDOrnAxLhghWZ9USe dsJSKRgV9+PPlnkZWeVDctxpmaATiyA+9Pxe2YbqEm05oLDDG3MtBsWVSC1q5R0GX1/1 roOw+soVJ3yGhgHF25XPvv0V1kXFEPJ3apy6YTuy149pOJRI9LFFfUj0eBRs4+vWlclJ d965d6k7BdL7d5qL/wf/tOOqbE3CBc3W1GCj+5J8yAC8AwLAP7NU0m+j3uYN0igfXPho 140iecP1twQKnQiLVtEmsXv10gy+hR3UWYrYlPRzL5K4kjuG2KYJkMKcPrbEQHEG5BYj eZXw== X-Received: by 10.15.94.201 with SMTP id bb49mr43380738eeb.23.1381091604178; Sun, 06 Oct 2013 13:33:24 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([46.211.77.102]) by mx.google.com with ESMTPSA id bn13sm54861981eeb.11.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 06 Oct 2013 13:33:23 -0700 (PDT) Sender: Alexander Motin Message-ID: <5251C911.6020003@FreeBSD.org> Date: Sun, 06 Oct 2013 23:33:21 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130616 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ilya Bakulin Subject: Re: SDIO for FreeBSD References: <5251A9D3.1080803@bakulin.de> In-Reply-To: <5251A9D3.1080803@bakulin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 20:33:26 -0000 On 06.10.2013 21:20, Ilya Bakulin wrote: > Just a quick status update. > I have managed to make interrupts work. Was rather silly copy&paste mistake. > > So now I'm able to issue a command to the WiFi card and actually get an > interrupt from > the controller. > > I have added several bus methods for setting up interrupt handlers and > allocating resources, > both to the MMC stack and to my WiFi driver, as well as mv_sdio SDIO > controller driver for DreamPlug. > The code is kept under [1], as usual. > > I have the fully working stack now and I'd like to discuss the locking > model for SDIO. > > So, the SDIO controller detects an interrupt. > SDIO controller driver handles it its own interrupt thread (I assume > that we use ITHREAD ISRs). > All the controller can do at this stage is: > 1. read device registers to get the interrupt cause; > 2. clear/set some bits in device registers; > 3. If there was a command- or data-related interrupt, call req->done() > method of struct mmc_request, > which sets MMC_REQ_DONE flag in the request structure and then calls > wakeup() on mmc_request. > This is what actually happens now. MMC stack which is doing msleep() > waiting for MMC_REQ_DONE > flag detects this flag and continues with request processing, returning > a result to the upper layer. > See mmc_wakeup() and mmc_wait_for_req() in sys/dev/mmc/mmc.c > > Everything is syncronous at this point, no complications. > > Now the SDIO case. The controller can detect an interrupt at any time, > then it notifies the MMC stack > about it. This happens in the ITHREAD of SDIO controller's ISR. > In MMC stack, we now want to read the "Penging interrupts" register to > figure out which function has > raised the interrupt. We cannot, however, issue another request to SDIO > controller since that inhibits > sleeping and we cannot sleep in ISR. We will also need to call ISRs of > our child devices that can possibly > do another weird stuff. > > So I propose adding a dedicated thread in MMC layer that will just > process the interrupts from the card. > It can be started on MMC stack attach, grab MMC lock and then just sleep > on condition variable > (which will be per-bus, ie for each SDIO card since there can only be > one SD[IO] card on the bus), giving the lock back. > When the MMC stack's ISR is called by SDIO controller, it will just > cv_signal() that variable and do nothing more than that. > The MMC interrupt servicing thread will then wakeup (and grab the MMC > lock!), > it will be able to do another MMC request to read "pending interrupts" > register > and call the ISRs of respective child drivers. > We expect them to be quick and probably do the similar stuff -- just > signaling CVs > and/or taskqueue_enqueue()-ing interrupt processing tasks. I am sorry, can't hold from rephrasing the joke: how many threads does it take to handle an interrupt? ;) IMHO 3 threads used to handle single hardware interrupt is a good point to invent something better. That would be easy if controller and MMC layers used the same lock and MMC could send interrupt status request asynchronously just from the ISR, but they don't. May be things could be much more simple if if would be controller driver obligation to read interrupt status from the card instead of jumping up and down over the stack and having to use additional threads to decouple the locks? That is like in CAM for both ATA and SCSI now it is controller driver duty to fetch errors details from the device, even sending additional commands if needed. > Sorry if I totally misunderstand the concept here, please tell your > opinions. > > [1] https://github.com/kibab/freebsd/compare/master...kibab-dplug > Note that I have made a rebase and pushed the rebased branch back to GitHub. > This is an epic fuckup and it requires everyone to delete the local > branch and pull it once again, > as the IDs have changed. Sorry for that, I will do merges next time. -- Alexander Motin From owner-freebsd-embedded@FreeBSD.ORG Sun Oct 6 21:05:02 2013 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3D703FDD; Sun, 6 Oct 2013 21:05:02 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CFBF02F84; Sun, 6 Oct 2013 21:05:01 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id j7so2494293qaq.10 for ; Sun, 06 Oct 2013 14:05:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=k1kn5Sq3qJ/o9SY/v6ah0uW5Z1BMhkqvYgknArVqlME=; b=oVKjOivd4gmm86em58sIgz2qpE83e8UNH+j6AqeLyiZ/WoZZ2DMhpqhD8puA4SiTD3 p5AgWe5VPTuT9jhzOyT/bgYthUZ4pZwbY+QqVAvSSODjJ5oUrNlfI5K0GipGAJT0iG+N xzKGMzwGK/qUQfc10+nB/8LQ6z2yKPU2W1dioyJulHcRkVRSAi5fg5lXQYK5vZdT73ua VPbaAMjrAoUkIex29W97iizRhE/XQ0YNoYrqJlY6L9biXXl45z1aRorbek31CGnJHGIW DhTN2RGs5ciSRcbU8/140CZpLXwW2i5hqHAskTtGJAOOLYNEuZBsCTXyP6B54i+uOG4W zZUA== MIME-Version: 1.0 X-Received: by 10.224.4.70 with SMTP id 6mr4672070qaq.86.1381093500935; Sun, 06 Oct 2013 14:05:00 -0700 (PDT) Received: by 10.224.207.66 with HTTP; Sun, 6 Oct 2013 14:05:00 -0700 (PDT) In-Reply-To: <5251C911.6020003@FreeBSD.org> References: <5251A9D3.1080803@bakulin.de> <5251C911.6020003@FreeBSD.org> Date: Sun, 6 Oct 2013 14:05:00 -0700 Message-ID: Subject: Re: SDIO for FreeBSD From: Adrian Chadd To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Ilya Bakulin , "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 21:05:02 -0000 Hi, (Sorry, top-posting from a mobile device. Sorry.) Yes, i agree with mav. If we need so many threads, I think it's a good sign that the design needs some more thought. What's USB do? I think here we can get away with doing it via taskqueues. Ie, we post interrupts in the same context(s) that we post SDIO command completions. I'd really prefer this to be slightly more thought out. I've no idea how you're currently implementing it and as I'm knee deep in the AR9344/MIPS74K stuff, I'd like to focus on that until it's up to a point that others can jump in and help with the testing and bringup. But I think modelling it after USB would be good - have driver methods that get called to drive the command transmit/receive and then have the interrupt handling be called from the same taskqueue. That way your interrupt code would just be something like: driver_intr() { set_flag_that_states_an_interrupt_occured(); submit_some_register_read_command_to_the_transmit_queue(); sdio_start_xfer(); } .. then sdio_start_xfer() would tell your stack to start a transfer if the queue wasn't already running. It would then call the driver method to queue another command(s) to the SDIO stack. The SDIO stack can then post them to the hardware when it has time. Thanks, -adrian On Sunday, October 6, 2013, Alexander Motin wrote: > On 06.10.2013 21:20, Ilya Bakulin wrote: > >> Just a quick status update. >> I have managed to make interrupts work. Was rather silly copy&paste >> mistake. >> >> So now I'm able to issue a command to the WiFi card and actually get an >> interrupt from >> the controller. >> >> I have added several bus methods for setting up interrupt handlers and >> allocating resources, >> both to the MMC stack and to my WiFi driver, as well as mv_sdio SDIO >> controller driver for DreamPlug. >> The code is kept under [1], as usual. >> >> I have the fully working stack now and I'd like to discuss the locking >> model for SDIO. >> >> So, the SDIO controller detects an interrupt. >> SDIO controller driver handles it its own interrupt thread (I assume >> that we use ITHREAD ISRs). >> All the controller can do at this stage is: >> 1. read device registers to get the interrupt cause; >> 2. clear/set some bits in device registers; >> 3. If there was a command- or data-related interrupt, call req->done() >> method of struct mmc_request, >> which sets MMC_REQ_DONE flag in the request structure and then >> calls >> wakeup() on mmc_request. >> This is what actually happens now. MMC stack which is doing >> msleep() >> waiting for MMC_REQ_DONE >> flag detects this flag and continues with request processing, >> returning >> a result to the upper layer. >> See mmc_wakeup() and mmc_wait_for_req() in sys/dev/mmc/mmc.c >> >> Everything is syncronous at this point, no complications. >> >> Now the SDIO case. The controller can detect an interrupt at any time, >> then it notifies the MMC stack >> about it. This happens in the ITHREAD of SDIO controller's ISR. >> In MMC stack, we now want to read the "Penging interrupts" register to >> figure out which function has >> raised the interrupt. We cannot, however, issue another request to SDIO >> controller since that inhibits >> sleeping and we cannot sleep in ISR. We will also need to call ISRs of >> our child devices that can possibly >> do another weird stuff. >> >> So I propose adding a dedicated thread in MMC layer that will just >> process the interrupts from the card. >> It can be started on MMC stack attach, grab MMC lock and then just sleep >> on condition variable >> (which will be per-bus, ie for each SDIO card since there can only be >> one SD[IO] card on the bus), giving the lock back. >> When the MMC stack's ISR is called by SDIO controller, it will just >> cv_signal() that variable and do nothing more than that. >> The MMC interrupt servicing thread will then wakeup (and grab the MMC >> lock!), >> it will be able to do another MMC request to read "pending interrupts" >> register >> and call the ISRs of respective child drivers. >> We expect them to be quick and probably do the similar stuff -- just >> signaling CVs >> and/or taskqueue_enqueue()-ing interrupt processing tasks. >> > > I am sorry, can't hold from rephrasing the joke: how many threads does it > take to handle an interrupt? ;) > > IMHO 3 threads used to handle single hardware interrupt is a good point to > invent something better. That would be easy if controller and MMC layers > used the same lock and MMC could send interrupt status request > asynchronously just from the ISR, but they don't. May be things could be > much more simple if if would be controller driver obligation to read > interrupt status from the card instead of jumping up and down over the > stack and having to use additional threads to decouple the locks? That is > like in CAM for both ATA and SCSI now it is controller driver duty to fetch > errors details from the device, even sending additional commands if needed. > > Sorry if I totally misunderstand the concept here, please tell your >> opinions. >> >> [1] https://github.com/kibab/**freebsd/compare/master...**kibab-dplug >> Note that I have made a rebase and pushed the rebased branch back to >> GitHub. >> This is an epic fuckup and it requires everyone to delete the local >> branch and pull it once again, >> as the IDs have changed. Sorry for that, I will do merges next time. >> > > > -- > Alexander Motin > From owner-freebsd-embedded@FreeBSD.ORG Sun Oct 6 23:19:45 2013 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1F2C1A19 for ; Sun, 6 Oct 2013 23:19:45 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E049B2474 for ; Sun, 6 Oct 2013 23:19:44 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id x13so14280660ief.1 for ; Sun, 06 Oct 2013 16:19:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=DxjBncSGm3Zir/C3O0QdWjqCWJTfm9pIM4x49j5Iw6g=; b=TJuFpdYT0agU02T8GdLt/qY8IUJmmzETLgU+HuLHc+ZxOwQOTmlHDRlXrHnHq1VuEQ qaKXCAVI2TxH4HrHfpqeUxwa8TWrlXkfixT9XTF5ZBLmL6PNKJagR5P5IuX83fDhr83B uxeUsTuVJKQ42uFunIAt28pxpf+v3oOMxczzwmKa4eFivlvJTSrH9UJPXnte8UwIlx/z 4clAu9Zu6rQCMeEcKwu9lUqHLIxDt1y76wceYdos1+WfF+pbUBjEBMalVBL7MWDxOhqP 4tBmAswvegjz0GeiFbfDbo5R9GUY7WB+7oEc0TdsRZFyd6h/Zh3puzrMQ17VNwSWSzzk 8p2A== X-Gm-Message-State: ALoCoQmZncXm4/1wBCgM8d43gGyAjly/mLOTiyFIo+B8mXEfEfdjJHKDEGoWvOxBynvYLSqD+Lcy X-Received: by 10.43.10.198 with SMTP id pb6mr1891282icb.40.1381101578139; Sun, 06 Oct 2013 16:19:38 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id ri1sm23211189igc.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 06 Oct 2013 16:19:37 -0700 (PDT) Sender: Warner Losh Subject: Re: SDIO for FreeBSD Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 6 Oct 2013 17:19:36 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <4FB11076-DD88-43F2-A449-E41D2088A4DD@bsdimp.com> References: <5251A9D3.1080803@bakulin.de> <5251C911.6020003@FreeBSD.org> To: Adrian Chadd X-Mailer: Apple Mail (2.1085) Cc: Alexander Motin , Ilya Bakulin , "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 23:19:45 -0000 I've often thought that having an SDIO protocol for CAM would be where = we'd wind up because once you start adding in GPIO pin interrupt = signalling, message "interrupt" signaling, message completion, etc, it = looks a lot like many of the mechanisms we have in CAM... I'm not at = all sure that USB is the right model to use, frankly... But it does = have some superficial similarities... Warner On Oct 6, 2013, at 3:05 PM, Adrian Chadd wrote: > Hi, >=20 > (Sorry, top-posting from a mobile device. Sorry.) >=20 > Yes, i agree with mav. If we need so many threads, I think it's a good = sign that the design needs some more thought. >=20 > What's USB do? >=20 > I think here we can get away with doing it via taskqueues. Ie, we post = interrupts in the same context(s) that we post SDIO command completions. >=20 > I'd really prefer this to be slightly more thought out. I've no idea = how you're currently implementing it and as I'm knee deep in the = AR9344/MIPS74K stuff, I'd like to focus on that until it's up to a point = that others can jump in and help with the testing and bringup. But I = think modelling it after USB would be good - have driver methods that = get called to drive the command transmit/receive and then have the = interrupt handling be called from the same taskqueue. That way your = interrupt code would just be something like: >=20 > driver_intr() > { > set_flag_that_states_an_interrupt_occured(); > submit_some_register_read_command_to_the_transmit_queue(); > sdio_start_xfer(); > } >=20 > .. then sdio_start_xfer() would tell your stack to start a transfer if = the queue wasn't already running. It would then call the driver method = to queue another command(s) to the SDIO stack. The SDIO stack can then = post them to the hardware when it has time. >=20 > Thanks, >=20 >=20 >=20 > -adrian >=20 > On Sunday, October 6, 2013, Alexander Motin wrote: > On 06.10.2013 21:20, Ilya Bakulin wrote: > Just a quick status update. > I have managed to make interrupts work. Was rather silly copy&paste = mistake. >=20 > So now I'm able to issue a command to the WiFi card and actually get = an > interrupt from > the controller. >=20 > I have added several bus methods for setting up interrupt handlers and > allocating resources, > both to the MMC stack and to my WiFi driver, as well as mv_sdio SDIO > controller driver for DreamPlug. > The code is kept under [1], as usual. >=20 > I have the fully working stack now and I'd like to discuss the locking > model for SDIO. >=20 > So, the SDIO controller detects an interrupt. > SDIO controller driver handles it its own interrupt thread (I assume > that we use ITHREAD ISRs). > All the controller can do at this stage is: > 1. read device registers to get the interrupt cause; > 2. clear/set some bits in device registers; > 3. If there was a command- or data-related interrupt, call req->done() > method of struct mmc_request, > which sets MMC_REQ_DONE flag in the request structure and then = calls > wakeup() on mmc_request. > This is what actually happens now. MMC stack which is doing = msleep() > waiting for MMC_REQ_DONE > flag detects this flag and continues with request processing, = returning > a result to the upper layer. > See mmc_wakeup() and mmc_wait_for_req() in sys/dev/mmc/mmc.c >=20 > Everything is syncronous at this point, no complications. >=20 > Now the SDIO case. The controller can detect an interrupt at any time, > then it notifies the MMC stack > about it. This happens in the ITHREAD of SDIO controller's ISR. > In MMC stack, we now want to read the "Penging interrupts" register to > figure out which function has > raised the interrupt. We cannot, however, issue another request to = SDIO > controller since that inhibits > sleeping and we cannot sleep in ISR. We will also need to call ISRs of > our child devices that can possibly > do another weird stuff. >=20 > So I propose adding a dedicated thread in MMC layer that will just > process the interrupts from the card. > It can be started on MMC stack attach, grab MMC lock and then just = sleep > on condition variable > (which will be per-bus, ie for each SDIO card since there can only be > one SD[IO] card on the bus), giving the lock back. > When the MMC stack's ISR is called by SDIO controller, it will just > cv_signal() that variable and do nothing more than that. > The MMC interrupt servicing thread will then wakeup (and grab the MMC > lock!), > it will be able to do another MMC request to read "pending interrupts" > register > and call the ISRs of respective child drivers. > We expect them to be quick and probably do the similar stuff -- just > signaling CVs > and/or taskqueue_enqueue()-ing interrupt processing tasks. >=20 > I am sorry, can't hold from rephrasing the joke: how many threads does = it take to handle an interrupt? ;) >=20 > IMHO 3 threads used to handle single hardware interrupt is a good = point to invent something better. That would be easy if controller and = MMC layers used the same lock and MMC could send interrupt status = request asynchronously just from the ISR, but they don't. May be things = could be much more simple if if would be controller driver obligation to = read interrupt status from the card instead of jumping up and down over = the stack and having to use additional threads to decouple the locks? = That is like in CAM for both ATA and SCSI now it is controller driver = duty to fetch errors details from the device, even sending additional = commands if needed. >=20 > Sorry if I totally misunderstand the concept here, please tell your > opinions. >=20 > [1] https://github.com/kibab/freebsd/compare/master...kibab-dplug > Note that I have made a rebase and pushed the rebased branch back to = GitHub. > This is an epic fuckup and it requires everyone to delete the local > branch and pull it once again, > as the IDs have changed. Sorry for that, I will do merges next time. >=20 >=20 > --=20 > Alexander Motin From owner-freebsd-embedded@FreeBSD.ORG Mon Oct 7 11:06:43 2013 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 145D6836 for ; Mon, 7 Oct 2013 11:06:43 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 01F0B282F for ; Mon, 7 Oct 2013 11:06:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r97B6g0A077662 for ; Mon, 7 Oct 2013 11:06:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r97B6g9Y077660 for freebsd-embedded@FreeBSD.org; Mon, 7 Oct 2013 11:06:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 7 Oct 2013 11:06:42 GMT Message-Id: <201310071106.r97B6g9Y077660@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-embedded@FreeBSD.org Subject: Current problem reports assigned to freebsd-embedded@FreeBSD.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 11:06:43 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o misc/52256 embedded [picobsd] picobsd build script does not read in user/s o kern/42728 embedded [picobsd] many problems in src/usr.sbin/ppp/* after c 2 problems total. From owner-freebsd-embedded@FreeBSD.ORG Mon Oct 7 19:54:18 2013 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2219D335; Mon, 7 Oct 2013 19:54:18 +0000 (UTC) (envelope-from zbodek@gmail.com) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 56C9C2D87; Mon, 7 Oct 2013 19:54:17 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id hj3so5421977wib.7 for ; Mon, 07 Oct 2013 12:54:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=1StacpTJvA4GeZgXVaL3iLFSyZ3I1jQdD/4aJcwuA6I=; b=Z7QBpD4XVC3NvCFpvzFauX1A05qH56NYm32TullTQ+pAR29tssByVmYR6m31e4DlDY M7ooJIleB+ogdRUUSBW6Efyi/uJPo+ZcoRJY/o+5vK+klYYt7WBNUEUW6BbWGCPtP9in nKnTbIJsiD/uUwTXpl8J5ZLtVZF9naO+mX5h/e8GvX/uZoX9XXzreIrA+1d8yPPOt0Pw KMS71P57nYy7P5xsbeZdC3y4FVuxlbEGAE4aXRCduOlsHi6IWAaExo6lXyR4i/4TlLMN F80eYPF99tuIBkXSlMKUdUDspU+j6HQ0K4huB3MFz4MkWqsgHSLzWs6M4qsa7izRfAR0 Gxzg== MIME-Version: 1.0 X-Received: by 10.180.189.205 with SMTP id gk13mr20307097wic.12.1381175655522; Mon, 07 Oct 2013 12:54:15 -0700 (PDT) Sender: zbodek@gmail.com Received: by 10.216.160.70 with HTTP; Mon, 7 Oct 2013 12:54:15 -0700 (PDT) Date: Mon, 7 Oct 2013 21:54:15 +0200 X-Google-Sender-Auth: UT-vnNHObIgX6J0X5BA0I4Qvxn8 Message-ID: Subject: Changes to UART ns8250 From: Zbigniew Bodek To: freebsd-embedded@freebsd.org Content-Type: multipart/mixed; boundary=001a11c366d052011d04e82c04a8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 19:54:18 -0000 --001a11c366d052011d04e82c04a8 Content-Type: text/plain; charset=ISO-8859-1 Hello. I would like to present a patch for ns8250 serial that I would like to commit in the near future (if there are no objections). The patch is fixing newest DesignWare UART with busy detection. During frequency divisors configuration when UART is busy transferring or receiving data, line control register manipulation will not take effect. Therefore, we will not set divisor latch access bit and we will corrupt LCR instead of configuring divisors. It is necessary to wait until UART finishes all transfers to proceed with the configuration. This was detected on Armada XP as UART fails on this issue 100/100 attempts. The patch was tested by kevlo@ and me and it works on our Armada XP - based systems. Please send your comment or remarks if there are any. Best regards Zbigniew Bodek --001a11c366d052011d04e82c04a8 Content-Type: application/octet-stream; name="0001-Wait-for-DesignWare-UART-transfers-completion-before.patch" Content-Disposition: attachment; filename="0001-Wait-for-DesignWare-UART-transfers-completion-before.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hmi48egp0 RnJvbSBiMWU0Nzc5OGFlMjY5OGY0MjI3N2YwOTFlODQxZGZiNzEyNTY2MzA0IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBaYmlnbmlldyBCb2RlayA8emJiQHNlbWloYWxmLmNvbT4KRGF0 ZTogU2F0LCA1IE9jdCAyMDEzIDAyOjI1OjIzICswMjAwClN1YmplY3Q6IFtQQVRDSCAxLzNdIFdh aXQgZm9yIERlc2lnbldhcmUgVUFSVCB0cmFuc2ZlcnMgY29tcGxldGlvbiBiZWZvcmUKIGFjY2Vz c2luZyBsaW5lIGNvbnRyb2wKCldoZW4gdXNpbmcgRFcgVUFSVCB3aXRoIEJVU1kgZGV0ZWN0aW9u IGl0IGlzIG5lY2Vzc2FyeSB0byB3YWl0CnVudGlsIGFsbCBzZXJpYWwgdHJhbnNmZXJzIGFyZSBm aW5pc2hlZCBiZWZvcmUgbWFuaXB1bGF0aW5nIHRoZQpsaW5lIGNvbnRyb2wuIExDUiB3aWxsIG5v dCBiZSBhZmZlY3RlZCB3aGVuIFVBUlQgaXMgYnVzeS4KSW4gYWRkaXRpb24sIGlmIERpdmlzb3Ig TGF0Y2ggQWNjZXNzIEJpdCBpcyBiZWluZyBzZXQgaW4gb3JkZXIgdG8KbW9kaWZ5IFVBUlQgZGl2 aXNvcnM6CjEuIFdlIHdpbGwgZ2V0IEJVU1kgaW50ZXJydXB0IGlmIGludGVycnVwdHMgYXJlIGVu YWJsZWQuCjIuIEJlY2F1c2UgTENSIHdpbGwgbm90IGJlIGFmZmVjdGVkIHRoZSBUSFIgYW5kIChl dmVuIHdvcnNlKSBJRVIKICAgY29udGVudHMgd2lsbCBiZSBjb3JydXB0ZWQuIFRoaXMgd2lsbCBs ZWFkIHRvIGNvbnNvbGUgaGFuZy4KClRlc3RlZCBieToJa2V2bG8KQXBwcm92ZWQgYnk6CWNvZ25l dCAobWVudG9yKQotLS0KIHN5cy9kZXYvaWMvbnMxNjU1MC5oICAgICAgICAgICB8ICAxICsKIHN5 cy9kZXYvdWFydC91YXJ0X2Rldl9uczgyNTAuYyB8IDEwICsrKysrKysrKysKIDIgZmlsZXMgY2hh bmdlZCwgMTEgaW5zZXJ0aW9ucygrKQoKZGlmZiAtLWdpdCBhL3N5cy9kZXYvaWMvbnMxNjU1MC5o IGIvc3lzL2Rldi9pYy9uczE2NTUwLmgKaW5kZXggNjU5ZjU5MS4uMzNhN2RkMSAxMDA2NDQKLS0t IGEvc3lzL2Rldi9pYy9uczE2NTUwLmgKKysrIGIvc3lzL2Rldi9pYy9uczE2NTUwLmgKQEAgLTE4 NSw2ICsxODUsNyBAQAogI2RlZmluZSBEV19SRUdfVVNSCTMxCS8qIERlc2lnbldhcmUgZGVyaXZl ZCBVYXJ0IFN0YXR1cyBSZWcgKi8KICNkZWZpbmUgY29tX3VzcgkJMzkJLyogT2N0ZW9uIDE2NzUw LzE2NTUwIFVhcnQgU3RhdHVzIFJlZyAqLwogI2RlZmluZSBSRUdfVVNSCQljb21fdXNyCisjZGVm aW5lIFVTUl9CVVNZCTEJLyogVWFydCBCdXN5LiBTZXJpYWwgdHJhbnNmZXIgaW4gcHJvZ3Jlc3Mg Ki8KICNkZWZpbmUgVVNSX1RYRklGT19OT1RGVUxMIDIgICAgLyogVWFydCBUWCBGSUZPIE5vdCBm dWxsICovCiAKIC8qIDE2OTUwIHJlZ2lzdGVyICMxLiAgQWNjZXNzIGVuYWJsZWQgYnkgQUNSWzdd LiAgQWxzbyByZXF1aXJlcyAhTENSWzddLiAqLwpkaWZmIC0tZ2l0IGEvc3lzL2Rldi91YXJ0L3Vh cnRfZGV2X25zODI1MC5jIGIvc3lzL2Rldi91YXJ0L3VhcnRfZGV2X25zODI1MC5jCmluZGV4IDIx MWQxMTMuLjVjOTM5Y2UgMTAwNjQ0Ci0tLSBhL3N5cy9kZXYvdWFydC91YXJ0X2Rldl9uczgyNTAu YworKysgYi9zeXMvZGV2L3VhcnQvdWFydF9kZXZfbnM4MjUwLmMKQEAgLTY0NywxMSArNjQ3LDIx IEBAIGludAogbnM4MjUwX2J1c19wYXJhbShzdHJ1Y3QgdWFydF9zb2Z0YyAqc2MsIGludCBiYXVk cmF0ZSwgaW50IGRhdGFiaXRzLAogICAgIGludCBzdG9wYml0cywgaW50IHBhcml0eSkKIHsKKwlz dHJ1Y3QgbnM4MjUwX3NvZnRjICpuczgyNTA7CiAJc3RydWN0IHVhcnRfYmFzICpiYXM7CiAJaW50 IGVycm9yOwogCisJbnM4MjUwID0gKHN0cnVjdCBuczgyNTBfc29mdGMqKXNjOwogCWJhcyA9ICZz Yy0+c2NfYmFzOwogCXVhcnRfbG9jayhzYy0+c2NfaHdtdHgpOworCS8qCisJICogV2hlbiB1c2lu ZyBEVyBVQVJUIHdpdGggQlVTWSBkZXRlY3Rpb24gaXQgaXMgbmVjZXNzYXJ5IHRvIHdhaXQKKwkg KiB1bnRpbCBhbGwgc2VyaWFsIHRyYW5zZmVycyBhcmUgZmluaXNoZWQgYmVmb3JlIG1hbmlwdWxh dGluZyB0aGUKKwkgKiBsaW5lIGNvbnRyb2wuIExDUiB3aWxsIG5vdCBiZSBhZmZlY3RlZCB3aGVu IFVBUlQgaXMgYnVzeS4KKwkgKi8KKwl3aGlsZSAobnM4MjUwLT5idXN5X2RldGVjdCAhPSAwICYm CisJICAgICh1YXJ0X2dldHJlZyhiYXMsIERXX1JFR19VU1IpICYgVVNSX0JVU1kpICE9IDApCisJ CTsKIAllcnJvciA9IG5zODI1MF9wYXJhbShiYXMsIGJhdWRyYXRlLCBkYXRhYml0cywgc3RvcGJp dHMsIHBhcml0eSk7CiAJdWFydF91bmxvY2soc2MtPnNjX2h3bXR4KTsKIAlyZXR1cm4gKGVycm9y KTsKLS0gCjEuOC40Cgo= --001a11c366d052011d04e82c04a8-- From owner-freebsd-embedded@FreeBSD.ORG Mon Oct 7 20:15:17 2013 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 714EF9EE; Mon, 7 Oct 2013 20:15:17 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x22c.google.com (mail-qe0-x22c.google.com [IPv6:2607:f8b0:400d:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F02642F5C; Mon, 7 Oct 2013 20:15:16 +0000 (UTC) Received: by mail-qe0-f44.google.com with SMTP id 6so2989873qeb.31 for ; Mon, 07 Oct 2013 13:15:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=GBi01RdvJa/jwavzBSnrAgiK0r5Pe0/Yd32ZEQ1tCaY=; b=EQ0J3ofsKVb1ZY3Ic6c+NjMShUYPzdNjIRcZCjac15iWxDdq9Jikldf+Ih0rJ3xJCX x07aPl+P6H8k3tcv2SGsFAIS+yF5PqOV6BuHe7YBmCYyJ2svUwNg8nt2zLRxRWgW95Mu AsKFvkawrDvx3UJ/qCpmEdNbeRQ++a5CSYhPH4ipC3KXuYE40Z9Gj0onnqcpjZpCZVts bJb5VvASZwtVhn5oUnIl8Cdio+KNy8rwDHoSwF+mULxy5jl9n7ourKYCEG9uQipR1Uvi YGGMK5qaTfJrVvjVUF068j9NxvsQfOIMxSjsPONb0+D8RvaMnb9kzEdvNxzkrKlF4AjA 1PMg== MIME-Version: 1.0 X-Received: by 10.224.157.14 with SMTP id z14mr5169015qaw.90.1381176916112; Mon, 07 Oct 2013 13:15:16 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Mon, 7 Oct 2013 13:15:16 -0700 (PDT) In-Reply-To: References: Date: Mon, 7 Oct 2013 13:15:16 -0700 X-Google-Sender-Auth: NNgCXYLGRSNjy6J5wKblc7oqS8I Message-ID: Subject: Re: Changes to UART ns8250 From: Adrian Chadd To: Zbigniew Bodek Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arm@freebsd.org" , freebsd-current , "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 20:15:17 -0000 Hi, You should add: * a loop counter, to break out after a while; * a DELAY(1) or something. -adrian On 7 October 2013 12:54, Zbigniew Bodek wrote: > Hello. > > I would like to present a patch for ns8250 serial that I would like to > commit in the near future (if there are no objections). > > The patch is fixing newest DesignWare UART with busy detection. > During frequency divisors configuration when UART is busy transferring or > receiving data, line control register manipulation will not take effect. > Therefore, we will not set divisor latch access bit and we will corrupt LCR > instead of configuring divisors. > It is necessary to wait until UART finishes all transfers to proceed with > the configuration. > > This was detected on Armada XP as UART fails on this issue 100/100 > attempts. > The patch was tested by kevlo@ and me and it works on our Armada XP - > based > systems. > > Please send your comment or remarks if there are any. > > Best regards > Zbigniew Bodek > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-embedded@FreeBSD.ORG Mon Oct 7 20:26:34 2013 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4E109362; Mon, 7 Oct 2013 20:26:34 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 21C04207A; Mon, 7 Oct 2013 20:26:33 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VTHNr-000457-0O; Mon, 07 Oct 2013 20:26:27 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r97KQNcE017584; Mon, 7 Oct 2013 14:26:23 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+SL+29gBFrnv96HWTdirAU Subject: Re: Changes to UART ns8250 From: Ian Lepore To: Adrian Chadd In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Mon, 07 Oct 2013 14:26:23 -0600 Message-ID: <1381177583.1130.17.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Zbigniew Bodek , "freebsd-arm@freebsd.org" , freebsd-current , "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 20:26:34 -0000 On Mon, 2013-10-07 at 13:15 -0700, Adrian Chadd wrote: > Hi, > > You should add: > > *[snip] > * a DELAY(1) or something. > Why? Why oh why do people write while (!read_some_status_register()) DELAY(n); when DELAY() is implemented as, roughly: while (read_some_counter_register() < something) continue; The whole point of DELAY() is to busy-wait. What might be nice is some function that we can call in such a loop such as cpu_busywait(), so that when running in an emulated or virtualized environment the emulator or hypervisor could use that as a hint to do something smart. -- Ian From owner-freebsd-embedded@FreeBSD.ORG Mon Oct 7 20:35:17 2013 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D4AA1A53; Mon, 7 Oct 2013 20:35:17 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x229.google.com (mail-qe0-x229.google.com [IPv6:2607:f8b0:400d:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4D9A72125; Mon, 7 Oct 2013 20:35:17 +0000 (UTC) Received: by mail-qe0-f41.google.com with SMTP id 1so5886348qee.28 for ; Mon, 07 Oct 2013 13:35:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=C0bVkeqCeSIkBzP0hQRakNb4vw/Kr+rxE1as5CfGiOc=; b=r56pKS6hicCewTo1XG904txIP9Pt1WNzvJlFRnFliYTSWEOZ0lpEfHzTD7fL20uld9 qqmwkeoK+t7a5yKtqybYEXAXhRPPjJT1cJ+pqniMRh9OHzdCz8HnzyZpUwA9x2IRvk4B vKwsxi9GaQIer1ib88HQFdS7Lm0mH2C+Od7fqQTXaiTxH2D6na7YU0gKOwPMxPUmayOE B0YkrgUMf8P/TkbLSGgkWfaUFxnnzHIMp63028LNRkbs/7yc36CASrbchz1fyF9uyf4j FDSGUyVrTe4/azmGoHP+QdcgnUlgADWv9mbOlNkF6HJTqUjT+/USJwk+UlVe1QonkYp5 1dBw== MIME-Version: 1.0 X-Received: by 10.224.114.201 with SMTP id f9mr40013910qaq.4.1381178116392; Mon, 07 Oct 2013 13:35:16 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Mon, 7 Oct 2013 13:35:16 -0700 (PDT) In-Reply-To: <1381177583.1130.17.camel@revolution.hippie.lan> References: <1381177583.1130.17.camel@revolution.hippie.lan> Date: Mon, 7 Oct 2013 13:35:16 -0700 X-Google-Sender-Auth: KqZl9pJp_NdYLenJ5mi2a7PL3GM Message-ID: Subject: Re: Changes to UART ns8250 From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Zbigniew Bodek , "freebsd-arm@freebsd.org" , freebsd-current , "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 20:35:18 -0000 I'd love to see a linux style way of saying "I'd like to sleep from roughly this time interval to this time interval; feel free to do what you need." Then yes, it could be implemented as a sleep wakeup from a timer, or as a call to a hypervisor to do the same, or .. or... -adrian On 7 October 2013 13:26, Ian Lepore wrote: > On Mon, 2013-10-07 at 13:15 -0700, Adrian Chadd wrote: > > Hi, > > > > You should add: > > > > *[snip] > > * a DELAY(1) or something. > > > > Why? Why oh why do people write > > while (!read_some_status_register()) > DELAY(n); > > when DELAY() is implemented as, roughly: > > while (read_some_counter_register() < something) > continue; > > The whole point of DELAY() is to busy-wait. > > What might be nice is some function that we can call in such a loop such > as cpu_busywait(), so that when running in an emulated or virtualized > environment the emulator or hypervisor could use that as a hint to do > something smart. > > -- Ian > > > From owner-freebsd-embedded@FreeBSD.ORG Mon Oct 7 20:36:19 2013 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4EFAECD9; Mon, 7 Oct 2013 20:36:19 +0000 (UTC) (envelope-from zbodek@gmail.com) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 61A242147; Mon, 7 Oct 2013 20:36:18 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id c11so7890971wgh.30 for ; Mon, 07 Oct 2013 13:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=FlVYaZZeloUadN3cx21BoJN+DCt5HL06Hb6/609+ZF0=; b=09dRTNBY66t4wKCEi1AVSB2jlEz1lSd5pkQ3TG0zTRzSvJdOjWEOS8X3sOrggJgLcg r4Ab1G4aDFzZOR0ZGh6gUvXu9+szEUqO7YSOBtPpiVVUyTxP5RAYNDnv4TndhilJLfmN xtVgRrIzUYs6uyR6mtiCPa2l7reOtTH1c1jsCo2UF1pRmnQrj48vIuHxauzuqk/ALFj6 +diljGJAvPRrp/fNHTUpKbGdM/PLbeeIFoOOgDtkp8GiS1P5XYxIFSKHbBiIX88hAnnN C0gYxiwBPGLXvaxYfjnMO26cpS+rk3jHtBneu0a+CjUxapTNuSR0Qu3Ko1oby+Lv3uWm 6U6g== MIME-Version: 1.0 X-Received: by 10.194.63.228 with SMTP id j4mr7512079wjs.34.1381178176735; Mon, 07 Oct 2013 13:36:16 -0700 (PDT) Sender: zbodek@gmail.com Received: by 10.216.160.70 with HTTP; Mon, 7 Oct 2013 13:36:16 -0700 (PDT) In-Reply-To: References: Date: Mon, 7 Oct 2013 22:36:16 +0200 X-Google-Sender-Auth: uyj11NzTjbvpMumKmM39MjLoboc Message-ID: Subject: Re: Changes to UART ns8250 From: Zbigniew Bodek To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arm@freebsd.org" , freebsd-current , "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 20:36:19 -0000 Hello Adrian, Thank you for your remarks. Please check my answers in-line. Best regards Zbigniew Bodek 2013/10/7 Adrian Chadd > Hi, > > You should add: > > * a loop counter, to break out after a while; > [ZBB] In general as long as UART is busy we cannot proceed but if the timeout occurs we could return an error. Do you agree? > * a DELAY(1) or something. > [ZBB] DELAY is also a busy wait after all. The reasonable solution might be to use ns8250_delay() to get the transmission time and use it for timeout from the first point. I would DELAY(1) in each loop and decrement value acquired from ns8250_delay(). The loop should break during that time or we return an error. What do you think? > > > > -adrian > > > > On 7 October 2013 12:54, Zbigniew Bodek wrote: > >> Hello. >> >> I would like to present a patch for ns8250 serial that I would like to >> commit in the near future (if there are no objections). >> >> The patch is fixing newest DesignWare UART with busy detection. >> During frequency divisors configuration when UART is busy transferring or >> receiving data, line control register manipulation will not take effect. >> Therefore, we will not set divisor latch access bit and we will corrupt >> LCR >> instead of configuring divisors. >> It is necessary to wait until UART finishes all transfers to proceed with >> the configuration. >> >> This was detected on Armada XP as UART fails on this issue 100/100 >> attempts. >> The patch was tested by kevlo@ and me and it works on our Armada XP - >> based >> systems. >> >> Please send your comment or remarks if there are any. >> >> Best regards >> Zbigniew Bodek >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org >> " >> > > From owner-freebsd-embedded@FreeBSD.ORG Mon Oct 7 20:56:35 2013 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 078A0917; Mon, 7 Oct 2013 20:56:35 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CC08B22CC; Mon, 7 Oct 2013 20:56:34 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VTHqu-000Bea-BJ; Mon, 07 Oct 2013 20:56:28 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r97KuPpa017656; Mon, 7 Oct 2013 14:56:25 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19BSbxbcp5aiKIGKTOX+AWR Subject: Re: Changes to UART ns8250 From: Ian Lepore To: Zbigniew Bodek In-Reply-To: References: Content-Type: multipart/mixed; boundary="=-Kqv6EfxlCQV1TR9DVG7S" Date: Mon, 07 Oct 2013 14:56:25 -0600 Message-ID: <1381179385.1130.18.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-current , "freebsd-arm@freebsd.org" , "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 20:56:35 -0000 --=-Kqv6EfxlCQV1TR9DVG7S Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Mon, 2013-10-07 at 22:36 +0200, Zbigniew Bodek wrote: > Hello Adrian, > > Thank you for your remarks. > Please check my answers in-line. > > Best regards > Zbigniew Bodek > > > 2013/10/7 Adrian Chadd > > > Hi, > > > > You should add: > > > > * a loop counter, to break out after a while; > > > [ZBB] In general as long as UART is busy we cannot proceed but if the > timeout occurs we could return an error. Do you agree? > > > * a DELAY(1) or something. > > > [ZBB] DELAY is also a busy wait after all. The reasonable solution might be > to use ns8250_delay() to get the transmission time and use it for timeout > from the first point. I would DELAY(1) in each loop and decrement value > acquired from ns8250_delay(). The loop should break during that time or we > return an error. What do you think? > Is it possible to not busy-wait at all? Something like the attached? -- Ian --=-Kqv6EfxlCQV1TR9DVG7S Content-Disposition: inline; filename="temp.diff" Content-Type: text/x-patch; name="temp.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: sys/dev/uart/uart_dev_ns8250.c =================================================================== --- sys/dev/uart/uart_dev_ns8250.c (revision 255916) +++ sys/dev/uart/uart_dev_ns8250.c (working copy) @@ -614,6 +614,7 @@ ns8250_bus_ipend(struct uart_softc *sc) if (ns8250->busy_detect && (iir & IIR_BUSY) == IIR_BUSY) { (void)uart_getreg(bas, DW_REG_USR); + wakeup(&ns8250->busy_detect); uart_unlock(sc->sc_hwmtx); return (0); } @@ -652,6 +653,16 @@ ns8250_bus_param(struct uart_softc *sc, int baudra bas = &sc->sc_bas; uart_lock(sc->sc_hwmtx); + /* + * When using DW UART with BUSY detection it is necessary to wait + * until all serial transfers are finished before manipulating the + * line control. LCR will not be affected when UART is busy. + */ + while (ns8250->busy_detect && + (uart_getreg(bas, DW_REG_USR) & USR_BUSY) == 0) { + msleep(&ns8250->busy_detect, sc->sc_hwmtx, "dwbusy", 10); + } + error = ns8250_param(bas, baudrate, databits, stopbits, parity); uart_unlock(sc->sc_hwmtx); return (error); --=-Kqv6EfxlCQV1TR9DVG7S-- From owner-freebsd-embedded@FreeBSD.ORG Mon Oct 7 21:03:23 2013 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7ADA7177; Mon, 7 Oct 2013 21:03:23 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4DBE9237D; Mon, 7 Oct 2013 21:03:23 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VTHxa-0004Up-FU; Mon, 07 Oct 2013 21:03:22 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r97L3K0w017687; Mon, 7 Oct 2013 15:03:20 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18yUum+GocSwAgbUtIwc8cE Subject: Re: Changes to UART ns8250 From: Ian Lepore To: Zbigniew Bodek In-Reply-To: <1381179385.1130.18.camel@revolution.hippie.lan> References: <1381179385.1130.18.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Mon, 07 Oct 2013 15:03:20 -0600 Message-ID: <1381179800.1130.21.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" , freebsd-current , "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 21:03:23 -0000 On Mon, 2013-10-07 at 14:56 -0600, Ian Lepore wrote: > On Mon, 2013-10-07 at 22:36 +0200, Zbigniew Bodek wrote: > > Hello Adrian, > > > > Thank you for your remarks. > > Please check my answers in-line. > > > > Best regards > > Zbigniew Bodek > > > > > > 2013/10/7 Adrian Chadd > > > > > Hi, > > > > > > You should add: > > > > > > * a loop counter, to break out after a while; > > > > > [ZBB] In general as long as UART is busy we cannot proceed but if the > > timeout occurs we could return an error. Do you agree? > > > > > * a DELAY(1) or something. > > > > > [ZBB] DELAY is also a busy wait after all. The reasonable solution might be > > to use ns8250_delay() to get the transmission time and use it for timeout > > from the first point. I would DELAY(1) in each loop and decrement value > > acquired from ns8250_delay(). The loop should break during that time or we > > return an error. What do you think? > > > > Is it possible to not busy-wait at all? Something like the attached? > > -- Ian > > differences between files attachment (temp.diff) > Index: sys/dev/uart/uart_dev_ns8250.c > =================================================================== > --- sys/dev/uart/uart_dev_ns8250.c (revision 255916) > +++ sys/dev/uart/uart_dev_ns8250.c (working copy) > @@ -614,6 +614,7 @@ ns8250_bus_ipend(struct uart_softc *sc) > > if (ns8250->busy_detect && (iir & IIR_BUSY) == IIR_BUSY) { > (void)uart_getreg(bas, DW_REG_USR); > + wakeup(&ns8250->busy_detect); > uart_unlock(sc->sc_hwmtx); > return (0); > } > @@ -652,6 +653,16 @@ ns8250_bus_param(struct uart_softc *sc, int baudra > > bas = &sc->sc_bas; > uart_lock(sc->sc_hwmtx); > + /* > + * When using DW UART with BUSY detection it is necessary to wait > + * until all serial transfers are finished before manipulating the > + * line control. LCR will not be affected when UART is busy. > + */ > + while (ns8250->busy_detect && > + (uart_getreg(bas, DW_REG_USR) & USR_BUSY) == 0) { > + msleep(&ns8250->busy_detect, sc->sc_hwmtx, "dwbusy", 10); > + } > + > error = ns8250_param(bas, baudrate, databits, stopbits, parity); > uart_unlock(sc->sc_hwmtx); > return (error); Ooops, that should be != 0 in that USR_BUSY test. Also, I haven't tested this at all because I don't I have any boards that use DW uarts. -- Ian From owner-freebsd-embedded@FreeBSD.ORG Mon Oct 7 21:20:45 2013 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 09EDABFB; Mon, 7 Oct 2013 21:20:45 +0000 (UTC) (envelope-from zbodek@gmail.com) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1D58024F5; Mon, 7 Oct 2013 21:20:43 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id hq15so5539069wib.12 for ; Mon, 07 Oct 2013 14:20:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=HkVwl181jzxkRBOQX0mJoFpolErA49EzP70seO12wfA=; b=daUyBm7fbigZehpVk2hPCGXI46B+tZIfVTJyAPhq+tLmPP7ppU3pvS5rJgMUv+ASKW Dn1C8d8ovdYK3tGdrxA6R82gGY9aQOpg7l/c7r0MgLpF5upDiW6XgU9XsHlKv0RzIVEU uWnu4qKQB2mU19XHr51DgBnThxN0LScYmMlZxLvcqHAe3fmsNhaDk7eZCyOYseU2sI5T 039j1FBpbPi/3m6j24FwCYbhB+uSHMIuZqLSA/WnWC76Q6BOB4ebzHT9g/R8V1nCs7Zt A1Dmk9PVkykNkFLtL7hla927HV/fptiwDiR1cGGH4M/MR+9/i1v2aUrENoRX5sZBTu3R b/rQ== MIME-Version: 1.0 X-Received: by 10.180.81.71 with SMTP id y7mr20587288wix.63.1381180842515; Mon, 07 Oct 2013 14:20:42 -0700 (PDT) Sender: zbodek@gmail.com Received: by 10.216.160.70 with HTTP; Mon, 7 Oct 2013 14:20:42 -0700 (PDT) In-Reply-To: <1381179800.1130.21.camel@revolution.hippie.lan> References: <1381179385.1130.18.camel@revolution.hippie.lan> <1381179800.1130.21.camel@revolution.hippie.lan> Date: Mon, 7 Oct 2013 23:20:42 +0200 X-Google-Sender-Auth: -5ze0Vq-CNFksmlSBW2M3ilboD0 Message-ID: Subject: Re: Changes to UART ns8250 From: Zbigniew Bodek To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arm@freebsd.org" , freebsd-current , "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 21:20:45 -0000 Hello Ian. Well you can't really perform wake event basing on busy interrupt because we are busy waiting/sleeping i.a. to avoid that interrupt to occur. I tried to use pause() that should switch to another task for the declared amount of time and I got: "panic: mi_switch: switch in a critical section" Best regards Zbigniew Bodek 2013/10/7 Ian Lepore > On Mon, 2013-10-07 at 14:56 -0600, Ian Lepore wrote: > > On Mon, 2013-10-07 at 22:36 +0200, Zbigniew Bodek wrote: > > > Hello Adrian, > > > > > > Thank you for your remarks. > > > Please check my answers in-line. > > > > > > Best regards > > > Zbigniew Bodek > > > > > > > > > 2013/10/7 Adrian Chadd > > > > > > > Hi, > > > > > > > > You should add: > > > > > > > > * a loop counter, to break out after a while; > > > > > > > [ZBB] In general as long as UART is busy we cannot proceed but if the > > > timeout occurs we could return an error. Do you agree? > > > > > > > * a DELAY(1) or something. > > > > > > > [ZBB] DELAY is also a busy wait after all. The reasonable solution > might be > > > to use ns8250_delay() to get the transmission time and use it for > timeout > > > from the first point. I would DELAY(1) in each loop and decrement value > > > acquired from ns8250_delay(). The loop should break during that time > or we > > > return an error. What do you think? > > > > > > > Is it possible to not busy-wait at all? Something like the attached? > > > > -- Ian > > > > differences between files attachment (temp.diff) > > Index: sys/dev/uart/uart_dev_ns8250.c > > =================================================================== > > --- sys/dev/uart/uart_dev_ns8250.c (revision 255916) > > +++ sys/dev/uart/uart_dev_ns8250.c (working copy) > > @@ -614,6 +614,7 @@ ns8250_bus_ipend(struct uart_softc *sc) > > > > if (ns8250->busy_detect && (iir & IIR_BUSY) == IIR_BUSY) { > > (void)uart_getreg(bas, DW_REG_USR); > > + wakeup(&ns8250->busy_detect); > > uart_unlock(sc->sc_hwmtx); > > return (0); > > } > > @@ -652,6 +653,16 @@ ns8250_bus_param(struct uart_softc *sc, int baudra > > > > bas = &sc->sc_bas; > > uart_lock(sc->sc_hwmtx); > > + /* > > + * When using DW UART with BUSY detection it is necessary to wait > > + * until all serial transfers are finished before manipulating the > > + * line control. LCR will not be affected when UART is busy. > > + */ > > + while (ns8250->busy_detect && > > + (uart_getreg(bas, DW_REG_USR) & USR_BUSY) == 0) { > > + msleep(&ns8250->busy_detect, sc->sc_hwmtx, "dwbusy", 10); > > + } > > + > > error = ns8250_param(bas, baudrate, databits, stopbits, parity); > > uart_unlock(sc->sc_hwmtx); > > return (error); > > Ooops, that should be != 0 in that USR_BUSY test. Also, I haven't > tested this at all because I don't I have any boards that use DW uarts. > > -- Ian > > > From owner-freebsd-embedded@FreeBSD.ORG Tue Oct 8 01:58:48 2013 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5043E8DC; Tue, 8 Oct 2013 01:58:48 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 04872270F; Tue, 8 Oct 2013 01:58:47 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id aq17so18237126iec.27 for ; Mon, 07 Oct 2013 18:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kWH4GdJb+ZdwhDxl2PYsTGVFhxMbroOQ0jREJprwDn0=; b=jMfh3sPzsDHJf1LYgPMsTee1FVm2znvYnTSgqBHHwzRkrMDcvguJbI7WisXdHi8803 +k8Ofy7vVAaQWZ2sEVkz20iYQBz+tabsPx6RQVuDn6m2Kz8W9Dnei2FV2i7X7ru+v5rh 8LNFW84g28zakTkc40WLeX5mTN53V9WmzzGDSkODcrJRAi1JqiKozq0ZUqX9oFzT/l2g eihiaQnGDI+U90pE72YibdoFfr1Vi+miRh7N4XQi8joA1Sg4HL0kpc72bFzZfEYtsKja NGCKoZKUWZ8TL2x9MvCK+gxtz7ImfBAudLdsQ8tklqGRYz5KGQ2W3E0XR0Cpz6UcdeBm Qs/A== MIME-Version: 1.0 X-Received: by 10.50.30.42 with SMTP id p10mr19339045igh.5.1381197527427; Mon, 07 Oct 2013 18:58:47 -0700 (PDT) Received: by 10.65.14.133 with HTTP; Mon, 7 Oct 2013 18:58:47 -0700 (PDT) In-Reply-To: References: Date: Tue, 8 Oct 2013 09:58:47 +0800 Message-ID: Subject: Re: Changes to UART ns8250 From: Ganbold Tsagaankhuu To: Zbigniew Bodek Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arm@freebsd.org" , freebsd-current@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 01:58:48 -0000 Zbigniew, On Tue, Oct 8, 2013 at 3:54 AM, Zbigniew Bodek wrote: > Hello. > > I would like to present a patch for ns8250 serial that I would like to > commit in the near future (if there are no objections). > > The patch is fixing newest DesignWare UART with busy detection. > During frequency divisors configuration when UART is busy transferring or > receiving data, line control register manipulation will not take effect. > Therefore, we will not set divisor latch access bit and we will corrupt LCR > instead of configuring divisors. > It is necessary to wait until UART finishes all transfers to proceed with > the configuration. > > This was detected on Armada XP as UART fails on this issue 100/100 > attempts. > The patch was tested by kevlo@ and me and it works on our Armada XP - > based > systems. > > Please send your comment or remarks if there are any. > I'm trying your patch on r254983. Tried on 2 boards (Cubieboard2 (Allwinner A20 SoC - dual Cortex A7) and Radxa Rock (Rockchip RK3188 - Quad Cortex A9)). Both seem to have some sort of DesignWare uart. 1. It works fine on Cubieboard2. Uart dmesg is like: uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 33 on simplebus0 uart0: console (115200,n,8,1) 2. No any printing on screen in case of Radxa Rock. Without your patch uart dmesg is like: uart0: <16650 or compatible> mem 0x20064000-0x200643ff irq 68 on simplebus0 uart0: console (115200,n,8,1) In case of RK3188 SoC, it seems booting FreeBSD kernel seems very fragile, not sure yet what is causing the problem. Even with stock ns8250 some version later than r254983 didn't show/print anything on serial console few days ago. Only thing so far I know is this r254983 (with some patch) works in my case on RK3188 SoC based board. thanks, Ganbold > > Best regards > Zbigniew Bodek > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-embedded@FreeBSD.ORG Tue Oct 8 22:37:38 2013 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 81AB43AF; Tue, 8 Oct 2013 22:37:38 +0000 (UTC) (envelope-from ilya@bakulin.de) Received: from olymp.kibab.com (olymp6.kibab.com [IPv6:2a01:4f8:160:84c1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4090D27A2; Tue, 8 Oct 2013 22:37:37 +0000 (UTC) X-DKIM: OpenDKIM Filter v2.5.2 olymp.kibab.com DD94C3F458 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bakulin.de; s=default; t=1381271853; bh=NC1JHDM2thtfcYgbo+GcEbi7/WUatYgJJpL7oSm25+w=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=jYtSFSS2DFYNLM7QTLwtoQ56DFcEs32i2/tk3LgQ1v4MT5lK/L9k4A+WHhl1VF6LD 3XMLsOofRfr2x5vMR54lXZXYuY+7EaS3BNALeb+ABD898fGjw1kUos3JMjje7DMiFG VIcX4/q8mviJzUHD1HTnzCYFMGQy1uPZPp5ogYqE= Message-ID: <5254892B.3050507@bakulin.de> Date: Wed, 09 Oct 2013 00:37:31 +0200 From: Ilya Bakulin MIME-Version: 1.0 To: Warner Losh Subject: Re: SDIO for FreeBSD References: <5251A9D3.1080803@bakulin.de> <5251C911.6020003@FreeBSD.org> <4FB11076-DD88-43F2-A449-E41D2088A4DD@bsdimp.com> In-Reply-To: <4FB11076-DD88-43F2-A449-E41D2088A4DD@bsdimp.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , Alexander Motin , "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 22:37:38 -0000 On 07.10.13 01:19, Warner Losh wrote: > I've often thought that having an SDIO protocol for CAM would be where we'd wind up because once you start adding in GPIO pin interrupt signalling, message "interrupt" signaling, message completion, etc, it looks a lot like many of the mechanisms we have in CAM... I'm not at all sure that USB is the right model to use, frankly... But it does have some superficial similarities... > > Warner The idea seems to be interesting -- at least we can reuse the CAM queues and interrupt handling algorithms... One thing that I'd like to ask after initial reading about CAM in FreeBSD: is it possible for SIM devices to initiate data transfer? the CAM subsystem is primarily used for storage devices, where the host issues a SCSI command, schedules it to the SIM, and then SIM receives an interrupt from the h/w and updates the existing CCB, signaling command completion. In SDIO case we can have the interrupts from the card that are not associated with any previous command. Is it possible to handle such situation using CAM framework? -- Regards, Ilya Bakulin From owner-freebsd-embedded@FreeBSD.ORG Tue Oct 8 22:57:27 2013 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B145AE1B; Tue, 8 Oct 2013 22:57:27 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7D0FC28E5; Tue, 8 Oct 2013 22:57:27 +0000 (UTC) Received: by mail-pa0-f51.google.com with SMTP id kp14so128155pab.38 for ; Tue, 08 Oct 2013 15:57:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Jx/RfDvgZu71XhXiOPRD/Sz29TZa6hz0HdrPTaefD9M=; b=PE0u59pi3ik/gwVR0IoKpFgA3RDMLkiAszffQJGVEIzdjbFTntihXP6ick1cSSQORq v/goJ3sX1lmJEv9DVa/6KmiK+khcSNzg3aDiYzreh7MRAcKZvLKFwN60J2roMDWK9qQT pmjj9hK3xWC8/uelcnrW6oRXIe/tsuPb/BiVT5JWooRSriH4IPkcpVt8T7x9dV7k07h1 nKVhEDKH6A++Ik8m+jlo8GtWotSyRXkskq/GzyrMBhiHwquMdGKDQNrlYW1hKgrEosjs Y7bhdPIWZo8WWjlEoFdB6MLdH4DKo8L6CjH0lWVU6x2OZGH/wRSqgDe3a63S5oZ/kHUp QQQw== MIME-Version: 1.0 X-Received: by 10.66.163.164 with SMTP id yj4mr6178208pab.91.1381273047076; Tue, 08 Oct 2013 15:57:27 -0700 (PDT) Sender: mavbsd@gmail.com Received: by 10.68.149.68 with HTTP; Tue, 8 Oct 2013 15:57:26 -0700 (PDT) Received: by 10.68.149.68 with HTTP; Tue, 8 Oct 2013 15:57:26 -0700 (PDT) In-Reply-To: <5254892B.3050507@bakulin.de> References: <5251A9D3.1080803@bakulin.de> <5251C911.6020003@FreeBSD.org> <4FB11076-DD88-43F2-A449-E41D2088A4DD@bsdimp.com> <5254892B.3050507@bakulin.de> Date: Wed, 9 Oct 2013 01:57:26 +0300 X-Google-Sender-Auth: BQQVgM0c8tsIgbsFVBUjDC6-N44 Message-ID: Subject: Re: SDIO for FreeBSD From: Alexander Motin To: Ilya Bakulin X-Mailman-Approved-At: Tue, 08 Oct 2013 23:52:54 +0000 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Adrian Chadd , Alexander Motin , freebsd-embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 22:57:27 -0000 09.10.2013 1:37 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 "Ilya Bakulin" =CE=C1=D0=C9=D3=C1=CC: > > On 07.10.13 01:19, Warner Losh wrote: > > I've often thought that having an SDIO protocol for CAM would be where we'd wind up because once you start adding in GPIO pin interrupt signalling, message "interrupt" signaling, message completion, etc, it looks a lot like many of the mechanisms we have in CAM... I'm not at all sure that USB is the right model to use, frankly... But it does have some superficial similarities... > > > > Warner > > The idea seems to be interesting -- at least we can reuse the CAM queues > and interrupt handling algorithms... > One thing that I'd like to ask after initial reading about CAM in FreeBSD= : > is it possible for SIM devices to initiate data transfer? > the CAM subsystem is primarily used for storage devices, > where the host issues a SCSI command, schedules it to the SIM, > and then SIM receives an interrupt from the h/w and updates the existing > CCB, > signaling command completion. > > In SDIO case we can have the interrupts from the card > that are not associated with any previous command. > Is it possible to handle such situation using CAM framework? CAM has mechanism of asynchronous notifications, that is quite alike to interupts. On the other side, target mode drivers in CAM are using different concept with requests that just wait inside the controller or its driver to be completed on next incoming request, carying requst data inside. From owner-freebsd-embedded@FreeBSD.ORG Wed Oct 9 03:46:06 2013 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9E5CAFFF; Wed, 9 Oct 2013 03:46:06 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 514A82691; Wed, 9 Oct 2013 03:46:06 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id x13so601922ief.3 for ; Tue, 08 Oct 2013 20:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XtPZjy/1Kwi1+I8ftpQBlTONEY+W3VhrfZUhref5kuQ=; b=FFBMfBWMWGvwMn2N9AI8c0husmATBnDS/SBcR7X13cddLZayBKLCHvS6JO77VZZbQg yZ4T5p68EirtdDmLOIudABIAyEpugh43Fu+qXGZjAbt/VPhJNCiAyJEXeDoPJEU/ruHt wiTwp+8VhV/wk/eQVQm+EvU+BZ1OunJOHvhuy0IvgcUxTLYTiY3FtrFMN3laXQLw+7Zp kMdjRg7lng2WRouuhNbsID82+oAR+OQEA8vJEan7DAR8GUaxpwXntQJX9gD3wFc8Pef1 P2yJdNfxyeK1VRrh5kEEOdLp40vedc08Oi3V2FAn/CN9iyhAsc2fvhW6G66tfpsOVLWQ gLVQ== MIME-Version: 1.0 X-Received: by 10.50.147.65 with SMTP id ti1mr690562igb.12.1381290365554; Tue, 08 Oct 2013 20:46:05 -0700 (PDT) Received: by 10.64.18.14 with HTTP; Tue, 8 Oct 2013 20:46:05 -0700 (PDT) In-Reply-To: References: Date: Wed, 9 Oct 2013 11:46:05 +0800 Message-ID: Subject: Re: Changes to UART ns8250 From: Ganbold Tsagaankhuu To: Zbigniew Bodek Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arm@freebsd.org" , freebsd-current@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 03:46:06 -0000 On Tue, Oct 8, 2013 at 9:58 AM, Ganbold Tsagaankhuu wrote: > Zbigniew, > > > On Tue, Oct 8, 2013 at 3:54 AM, Zbigniew Bodek wrote: > >> Hello. >> >> I would like to present a patch for ns8250 serial that I would like to >> commit in the near future (if there are no objections). >> >> The patch is fixing newest DesignWare UART with busy detection. >> During frequency divisors configuration when UART is busy transferring or >> receiving data, line control register manipulation will not take effect. >> Therefore, we will not set divisor latch access bit and we will corrupt >> LCR >> instead of configuring divisors. >> It is necessary to wait until UART finishes all transfers to proceed with >> the configuration. >> >> This was detected on Armada XP as UART fails on this issue 100/100 >> attempts. >> The patch was tested by kevlo@ and me and it works on our Armada XP - >> based >> systems. >> >> Please send your comment or remarks if there are any. >> > > I'm trying your patch on r254983. > Tried on 2 boards (Cubieboard2 (Allwinner A20 SoC - dual Cortex A7) and > Radxa Rock (Rockchip RK3188 - Quad Cortex A9)). Both seem to have some sort > of DesignWare uart. > > 1. It works fine on Cubieboard2. Uart dmesg is like: > > uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 33 on simplebus0 > > uart0: console (115200,n,8,1) > > 2. No any printing on screen in case of Radxa Rock. Without your patch > uart dmesg is like: > > uart0: <16650 or compatible> mem 0x20064000-0x200643ff irq 68 on > simplebus0 > uart0: console (115200,n,8,1) > > In case of RK3188 SoC, it seems booting FreeBSD kernel seems very fragile, > not sure yet what is causing the problem. > Even with stock ns8250 some version later than r254983 didn't show/print > anything on serial console few days ago. > Only thing so far I know is this r254983 (with some patch) works in my > case on RK3188 SoC based board. > Zbigniew, Just tried again your patch on RK30xx board. I was able to see boot messages on screen. This uart detected as: ... uart0: <16650 or compatible> mem 0x20064000-0x200643ff irq 68 on simplebus0 uart0: console (115200,n,8,1) uart0: fast interrupt ... Can you show me your uart detection log? It seems this DW uart of RK30xx is different than DW uart of A10/A20. Boot simply stops printing "start_init: trying /sbin/init". thanks, Ganbold > > thanks, > > Ganbold > > > > >> >> Best regards >> Zbigniew Bodek >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org >> " >> > > From owner-freebsd-embedded@FreeBSD.ORG Wed Oct 9 17:35:48 2013 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2C4912B4 for ; Wed, 9 Oct 2013 17:35:48 +0000 (UTC) (envelope-from jeclark2006@aim.com) Received: from omr-d09.mx.aol.com (omr-d09.mx.aol.com [205.188.108.133]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DAA3C2853 for ; Wed, 9 Oct 2013 17:35:47 +0000 (UTC) Received: from mtaout-mb06.r1000.mx.aol.com (mtaout-mb06.r1000.mx.aol.com [172.29.41.70]) by omr-d09.mx.aol.com (Outbound Mail Relay) with ESMTP id 0AFEF7015325A; Wed, 9 Oct 2013 13:35:41 -0400 (EDT) Received: from [10.0.0.205] (wsip-68-105-252-106.sd.sd.cox.net [68.105.252.106]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-mb06.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 4948FE000092; Wed, 9 Oct 2013 13:35:40 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Routerboard RB800 From: John Clark In-Reply-To: Date: Wed, 9 Oct 2013 10:35:37 -0700 Message-Id: References: <2A185DB2-09B3-4D5B-9C63-1CBC542A570D@gmail.com> <0A2EBEC9-DE86-4B74-AD31-84A74516F5A2@gmail.com> <30933434-4F94-466A-8952-FE5675210AA2@gmail.com> <523DA66C.6090204@freebsd.org> To: Adrian Chadd X-Mailer: Apple Mail (2.1510) x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1381340140; bh=IENlajpiKcOkhlshJAwNivpgjvmr1eP8lrfNAMIUlX8=; h=From:To:Subject:Message-Id:Date:Mime-Version:Content-Type; b=jEuOzIXmCL+6Cl+8HJxzhFR7AdTDMuYXSYWgjQldc4bIEcuMi6ph7uuwLXrQNkvvT rnqLImajX6U1YS8vVE8mHyePDx+9WI4eSYNGOWeMVrEDN0NA1AL35bDxZDUaLjQPP3 /wCklU6EPbREwO73WXaPFKqN7rOfP1/v3r/YHZ18= x-aol-sid: 3039ac1d2946525593ec7a5e X-AOL-IP: 68.105.252.106 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Benjamin Perrault , "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 17:35:48 -0000 On Oct 1, 2013, at 1:31 AM, Adrian Chadd wrote: > Make sure you're building the right base kernel config before = tweaking. >=20 > http://wiki.openwrt.org/toh/tp-link/tl-wr842nd >=20 > This indicates it's an AR7241. So, start with the AP91 or AP99 kernel = configs. Try building that and tftpload/boot'ing it. Thanks for the hint=85 with a bit of hook and crook, I was able to build = a bootable kernel, a compressed mfsroot, and it appears that the kernel does find the compressed image, but then when it attempts to = run 'init', it gives a list of attempted paths=85 and finally death. Anyone have any further debug suggestions=85 Thanks, John Clark. From owner-freebsd-embedded@FreeBSD.ORG Wed Oct 9 21:33:08 2013 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 60DCFB24; Wed, 9 Oct 2013 21:33:08 +0000 (UTC) (envelope-from zbodek@gmail.com) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9737527C4; Wed, 9 Oct 2013 21:33:07 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id l18so1472513wgh.4 for ; Wed, 09 Oct 2013 14:33:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5gx+w6vLlfeF2eTNwp/7o4G4j3c1PDBJNfpvuuBY7Pg=; b=fD7qF8AQEaYesTEjXBqz61waitJHz5omNrRW08+8+guw0ytEUy9dTWD1JuMlAmTaCz LSA4rl9HiFWSECElNh3W3Xg5asKU1aPqcUIXXTCAmIkliE7AKf+JR/+FV5a2S/+gp5Aa sNYnNKEkpSyY65SrfZsk67vUr5irjP2a7ZkbbMDgJfz9crzPV+p/zFVR09yfD6eJ1ikh EoUGsreK/5MWqkLQBm6Suw/hB5COqMxqo0T3HBjYq4o/SjHNF6j0ePZx9bm82e0FNFtA cF6RgQ5/sa6gRkqVErwJ1g3CtgfNnVmboJpV6/sr1dqa+31eRei5bdICuAwoPsFVm/Oz cTdg== MIME-Version: 1.0 X-Received: by 10.180.83.228 with SMTP id t4mr4619854wiy.12.1381354386070; Wed, 09 Oct 2013 14:33:06 -0700 (PDT) Sender: zbodek@gmail.com Received: by 10.216.160.70 with HTTP; Wed, 9 Oct 2013 14:33:05 -0700 (PDT) In-Reply-To: References: Date: Wed, 9 Oct 2013 23:33:06 +0200 X-Google-Sender-Auth: 3Wv6EEbVnFYOlE8lEdO1cXD-qdI Message-ID: Subject: Re: Changes to UART ns8250 From: Zbigniew Bodek To: Ganbold Tsagaankhuu Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arm@freebsd.org" , freebsd-current , "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 21:33:08 -0000 Hello Ganbold. Thank you for testing the patch and pointing those issue out. My detection log from Armada XP: uart0: <16550 or compatible> mem 0xd0012000-0xd001201f irq 41 on simplebus0 uart0: console (115200,n,8,1) uart1: <16550 or compatible> mem 0xd0012100-0xd001211f irq 42 on simplebus0 uart2: <16550 or compatible> mem 0xd0012200-0xd001221f irq 43 on simplebus0 uart3: <16550 or compatible> mem 0xd0012300-0xd001231f irq 44 on simplebus0 Is there a possibility to download a datasheet for RK30xx so that I could verify what is required for it's UART? The patch is causing that we only wait until UART is not busy anymore. I can't find why would that cause problems if your UART requires busy detection anyway. Best regards Zbigniew Bodek 2013/10/9 Ganbold Tsagaankhuu > > > > On Tue, Oct 8, 2013 at 9:58 AM, Ganbold Tsagaankhuu wrote: > >> Zbigniew, >> >> >> On Tue, Oct 8, 2013 at 3:54 AM, Zbigniew Bodek wrote: >> >>> Hello. >>> >>> I would like to present a patch for ns8250 serial that I would like to >>> commit in the near future (if there are no objections). >>> >>> The patch is fixing newest DesignWare UART with busy detection. >>> During frequency divisors configuration when UART is busy transferring or >>> receiving data, line control register manipulation will not take effect. >>> Therefore, we will not set divisor latch access bit and we will corrupt >>> LCR >>> instead of configuring divisors. >>> It is necessary to wait until UART finishes all transfers to proceed with >>> the configuration. >>> >>> This was detected on Armada XP as UART fails on this issue 100/100 >>> attempts. >>> The patch was tested by kevlo@ and me and it works on our Armada XP - >>> based >>> systems. >>> >>> Please send your comment or remarks if there are any. >>> >> >> I'm trying your patch on r254983. >> Tried on 2 boards (Cubieboard2 (Allwinner A20 SoC - dual Cortex A7) and >> Radxa Rock (Rockchip RK3188 - Quad Cortex A9)). Both seem to have some sort >> of DesignWare uart. >> >> 1. It works fine on Cubieboard2. Uart dmesg is like: >> >> uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 33 on simplebus0 >> >> uart0: console (115200,n,8,1) >> >> 2. No any printing on screen in case of Radxa Rock. Without your patch >> uart dmesg is like: >> >> uart0: <16650 or compatible> mem 0x20064000-0x200643ff irq 68 on >> simplebus0 >> uart0: console (115200,n,8,1) >> >> In case of RK3188 SoC, it seems booting FreeBSD kernel seems very >> fragile, not sure yet what is causing the problem. >> Even with stock ns8250 some version later than r254983 didn't show/print >> anything on serial console few days ago. >> Only thing so far I know is this r254983 (with some patch) works in my >> case on RK3188 SoC based board. >> > > > Zbigniew, > > Just tried again your patch on RK30xx board. I was able to see boot > messages on screen. > This uart detected as: > ... > uart0: <16650 or compatible> mem 0x20064000-0x200643ff irq 68 on > simplebus0 > uart0: console (115200,n,8,1) > > uart0: fast interrupt > ... > Can you show me your uart detection log? > It seems this DW uart of RK30xx is different than DW uart of A10/A20. > Boot simply stops printing "start_init: trying /sbin/init". > > thanks, > > Ganbold > > > >> >> thanks, >> >> Ganbold >> >> >> >> >>> >>> Best regards >>> Zbigniew Bodek >>> >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to " >>> freebsd-current-unsubscribe@freebsd.org" >>> >> >> > From owner-freebsd-embedded@FreeBSD.ORG Wed Oct 9 21:51:17 2013 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3B6F7582; Wed, 9 Oct 2013 21:51:17 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9F8A02929; Wed, 9 Oct 2013 21:51:16 +0000 (UTC) Received: by mail-ea0-f177.google.com with SMTP id f15so717708eak.36 for ; Wed, 09 Oct 2013 14:51:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lWD7QLghRWaTMxropt9y/70GG7/UYRf3Tmz3LlPrWXk=; b=F6CZaNvYJPA+JCWc9ovO+cpPJX8xnlTX11jT/LGLDn8iARD1LZ7+iDsg209ZkjK6QH HwWty3F2mAOLF76AQDizj+cOq33TW4WN4uPlYcpKykIOIpALPwxfi0j0Kv5S5r8Aq9JZ nRMPsBKr+e4jk/8D96ZuaLt5DrLj/wx4lDtd9hqC1U4l+JmGdt+llR4UvosnTJ0z+k7f AIXnY+vK/1hvHw47J4DfAXro/Tn+gvGxpliLVwKsWTjWzLudRllffUp/igtGkvl3KMa5 qj+M6yn4Y+66zAPqR4o3k5DnzLAYS5kez/fD+jASptUIH61uoTLgzMPSBXD86BG2MNCy dXzw== MIME-Version: 1.0 X-Received: by 10.14.203.70 with SMTP id e46mr11218295eeo.33.1381355475108; Wed, 09 Oct 2013 14:51:15 -0700 (PDT) Received: by 10.14.105.137 with HTTP; Wed, 9 Oct 2013 14:51:14 -0700 (PDT) In-Reply-To: References: <2A185DB2-09B3-4D5B-9C63-1CBC542A570D@gmail.com> <0A2EBEC9-DE86-4B74-AD31-84A74516F5A2@gmail.com> <30933434-4F94-466A-8952-FE5675210AA2@gmail.com> <523DA66C.6090204@freebsd.org> Date: Wed, 9 Oct 2013 14:51:14 -0700 Message-ID: Subject: Re: Routerboard RB800 From: hiren panchasara To: John Clark Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Benjamin Perrault , "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 21:51:17 -0000 On Wed, Oct 9, 2013 at 10:35 AM, John Clark wrote: > > On Oct 1, 2013, at 1:31 AM, Adrian Chadd wrote: > > Make sure you're building the right base kernel config before tweaking. > > http://wiki.openwrt.org/toh/tp-link/tl-wr842nd > > This indicates it's an AR7241. So, start with the AP91 or AP99 kernel > configs. Try building that and tftpload/boot'ing it. > > > Thanks for the hint=E2=80=A6 with a bit of hook and crook, I was able to = build a > bootable kernel, a compressed mfsroot, and it appears that > the kernel does find the compressed image, but then when it attempts to r= un > 'init', it gives a list of attempted paths=E2=80=A6 and finally death. If you've used Adrian's wifi build scripts, your diffs against it and boot-up logs might be a good start. cheers, Hiren From owner-freebsd-embedded@FreeBSD.ORG Wed Oct 9 22:51:13 2013 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D0BD37C9 for ; Wed, 9 Oct 2013 22:51:13 +0000 (UTC) (envelope-from jeclark2006@aim.com) Received: from omr-d04.mx.aol.com (omr-d04.mx.aol.com [205.188.109.201]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8A8962C76 for ; Wed, 9 Oct 2013 22:51:13 +0000 (UTC) Received: from mtaout-db01.r1000.mx.aol.com (mtaout-db01.r1000.mx.aol.com [172.29.51.193]) by omr-d04.mx.aol.com (Outbound Mail Relay) with ESMTP id 76D87700043B6; Wed, 9 Oct 2013 18:51:12 -0400 (EDT) Received: from [10.0.0.205] (wsip-68-105-252-106.sd.sd.cox.net [68.105.252.106]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-db01.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id D5DBAE0000B3; Wed, 9 Oct 2013 18:51:11 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Routerboard RB800 From: John Clark In-Reply-To: Date: Wed, 9 Oct 2013 15:51:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <32181B72-E69D-41AB-B5B9-EEDC6B71F042@aim.com> References: <2A185DB2-09B3-4D5B-9C63-1CBC542A570D@gmail.com> <0A2EBEC9-DE86-4B74-AD31-84A74516F5A2@gmail.com> <30933434-4F94-466A-8952-FE5675210AA2@gmail.com> <523DA66C.6090204@freebsd.org> To: hiren panchasara X-Mailer: Apple Mail (2.1510) x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1381359072; bh=1djDBU7ofJv9z62pCO9PqYBZOx7bdozZ4qIZeVH1rww=; h=From:To:Subject:Message-Id:Date:Mime-Version:Content-Type; b=fAX2r1jjZP0a0i7QjKuEuOM+aaJqPZy4IsNSnXc5F4LKhDipDcrb3ZMzR36eqXuhX soA6cMekbuHd+Rs9BUC6disjZSLxGGlwF6ml36qeCJPfOS27BgVvHbXEbpMm8fJSyU 3fRycJyesnIk6IPt7YZ9F/gehjrXk2PxMdLShSQU= x-aol-sid: 3039ac1d33c15255dddf5ff4 X-AOL-IP: 68.105.252.106 Cc: Benjamin Perrault , "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 22:51:13 -0000 On Oct 9, 2013, at 2:51 PM, hiren panchasara = wrote: > On Wed, Oct 9, 2013 at 10:35 AM, John Clark = wrote: >>=20 >> On Oct 1, 2013, at 1:31 AM, Adrian Chadd wrote: >>=20 >> Make sure you're building the right base kernel config before = tweaking. >>=20 >> http://wiki.openwrt.org/toh/tp-link/tl-wr842nd >>=20 >> This indicates it's an AR7241. So, start with the AP91 or AP99 kernel >> configs. Try building that and tftpload/boot'ing it. >>=20 >>=20 >> Thanks for the hint=85 with a bit of hook and crook, I was able to = build a >> bootable kernel, a compressed mfsroot, and it appears that >> the kernel does find the compressed image, but then when it attempts = to run >> 'init', it gives a list of attempted paths=85 and finally death. >=20 > If you've used Adrian's wifi build scripts, your diffs against it and > boot-up logs might be a good start. I had to add the FSIMAGE flags in my cfg/TL-WR842ND, which I had cribbed = from the TL-WR1043ND file. config file to make a ulzma image. Previously = it was uzip. That allowed the init to start up and I was able to get to = a login prompt. I also based my kernel config off the AP91, as I didn't find an AP99 = config file in sys/mips/conf. John Clark. From owner-freebsd-embedded@FreeBSD.ORG Thu Oct 10 21:04:04 2013 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A8BFEC54; Thu, 10 Oct 2013 21:04:04 +0000 (UTC) (envelope-from ilya@bakulin.de) Received: from olymp.kibab.com (olymp.kibab.com [5.9.14.202]) by mx1.freebsd.org (Postfix) with ESMTP id 637AB2DD0; Thu, 10 Oct 2013 21:04:02 +0000 (UTC) X-DKIM: OpenDKIM Filter v2.5.2 olymp.kibab.com 964183F461 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bakulin.de; s=default; t=1381439033; bh=NNOJeBpSBw2HFC5cdZ5uHihs56/1nILPwHCUqKof05k=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=mJHqy9cfH4dbtPzkix6UtL4yAtBD9zHD9bo6hJRkZz0PW4X+sIh3IbWqy+klxhpKg AXVQG0PJ2uAlMHflclS3e7ciEnPRkDly0CEeFfpSBVGGVlnBWNRis0iB6TrY96T9PA hJoUaZLuX5mD/MDqKKP0sGYarJDuGVmEszzrs72w= Message-ID: <52571635.6080708@bakulin.de> Date: Thu, 10 Oct 2013 23:03:49 +0200 From: Ilya Bakulin MIME-Version: 1.0 To: Alexander Motin Subject: Re: SDIO for FreeBSD: CAM integration References: <5251A9D3.1080803@bakulin.de> <5251C911.6020003@FreeBSD.org> <4FB11076-DD88-43F2-A449-E41D2088A4DD@bsdimp.com> <5254892B.3050507@bakulin.de> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dGuvnXLtI7SRnJgV7ajN4vCbl5XAaM2n0" Cc: freebsd-embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 21:04:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dGuvnXLtI7SRnJgV7ajN4vCbl5XAaM2n0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 09.10.13 00:57, Alexander Motin wrote: > CAM has mechanism of asynchronous notifications, that is quite alike to= > interupts. That's good to know! So, after reading a bit more about CAM I have some kind of design proposa= l. In CAM world, we have peripheral modules (da, cd, pt, ses) and software interface modules, SIMs (USB, ATA, ATAPI, Firewire). The current implementation of MMC stack has three layers: 1. mmcsd(4) driver, later also SDIO device drivers {mv_sdiowl, ar6xxx,...= } 2. mmc(4) stack 3. SD controller {sdhci(4), mvsdio, ti_mmc,...} As far as I understand, it makes sense to convert the mmcsd driver to "peripheral module" and mmc stack will be then SIM. The relation of mmc stack and SD controller is then... well, essentially, those are just two parts of the SIM. They will still find each other using the NewBus. We can then drop that msleep() in MMC stack waiting for the SD controller to signal the completion of our request and just return, setting CAM_REQ_INPROG status in the CCB. When the controller receives an interrupt, its ISR calls into the MMC stack directly, the MMC stack then calls xpt_done() and the CCB is returned to the peripheral driver. In the SDIO case, when there is no active CCB, the MMC stack issues an asynchronous notification. So, based on this proposal, the first thing I will do is adding a CAM layer between mmcsd(4) and mmc(4) so this will still work as before :-) Does this all make sense to you? --=20 Regards, Ilya Bakulin --dGuvnXLtI7SRnJgV7ajN4vCbl5XAaM2n0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlJXFjkACgkQo9vlj1oadwjjgACgxdiGH32Smr+kLf3ltOWPPHH8 UFcAmgPeRJMFmMfNEYjS0cPac+dztR9s =ZW2m -----END PGP SIGNATURE----- --dGuvnXLtI7SRnJgV7ajN4vCbl5XAaM2n0-- From owner-freebsd-embedded@FreeBSD.ORG Fri Oct 11 20:10:41 2013 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8197FE02 for ; Fri, 11 Oct 2013 20:10:41 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1881B2011 for ; Fri, 11 Oct 2013 20:10:40 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id t60so4576856wes.26 for ; Fri, 11 Oct 2013 13:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u+YwMiokc2agFzlshAcR/BNT9g82xS6RVX+9Bw+ikG4=; b=OgbmtiwbnArOV9VcAmhChAYYtAQjuDX+LHz6rkMVIIrfaQ8GsX0OOK2ahUs/RqzZm/ NNYXd9qBBJHJJ9iwGLrxcq5wxfq9/VVgjqWlsq9b4RqjdpVgL/4YFTgJoWWg0+SIHRNo LTYdii+9LZ6kcp/fJ8I5tcsxoqOAM0qr+w4s+UXTftEQ0io+TsK5UqtMud2XJRm14mWr LZHi14m8dxEu4PHmAEZEeeUVbSGOzA8KPuTbiKxBveaSHj8Q+fUdBeTAosYeQ+tcWCsX 0OROPWrWvTsbkv4B/0paCGfSEGIUhh7dF59kvFYyMaIZeNV5rsKksSjS0sp1Yq2qZSnw VjCQ== MIME-Version: 1.0 X-Received: by 10.180.187.41 with SMTP id fp9mr4574054wic.33.1381522239522; Fri, 11 Oct 2013 13:10:39 -0700 (PDT) Received: by 10.216.75.140 with HTTP; Fri, 11 Oct 2013 13:10:39 -0700 (PDT) In-Reply-To: <32181B72-E69D-41AB-B5B9-EEDC6B71F042@aim.com> References: <2A185DB2-09B3-4D5B-9C63-1CBC542A570D@gmail.com> <0A2EBEC9-DE86-4B74-AD31-84A74516F5A2@gmail.com> <30933434-4F94-466A-8952-FE5675210AA2@gmail.com> <523DA66C.6090204@freebsd.org> <32181B72-E69D-41AB-B5B9-EEDC6B71F042@aim.com> Date: Fri, 11 Oct 2013 17:10:39 -0300 Message-ID: Subject: Re: Routerboard RB800 From: Luiz Otavio O Souza To: John Clark Content-Type: text/plain; charset=ISO-8859-1 Cc: Benjamin Perrault , "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 20:10:41 -0000 On 9 October 2013 19:51, John Clark wrote: > > On Oct 9, 2013, at 2:51 PM, hiren panchasara wrote: >> >> If you've used Adrian's wifi build scripts, your diffs against it and >> boot-up logs might be a good start. > > I had to add the FSIMAGE flags in my cfg/TL-WR842ND, which I had cribbed from the TL-WR1043ND file. config file to make a ulzma image. Previously it was uzip. That allowed the init to start up and I was able to get to a login prompt. > > I also based my kernel config off the AP91, as I didn't find an AP99 config file in sys/mips/conf. Nice! if you need help to fix the details (switch, leds, wifi and whatever is missing) just let me know. But it would also be nice if we start a new thread to talk about it (so it don't get lost under the RB800 topic). Thanks! Luiz From owner-freebsd-embedded@FreeBSD.ORG Sat Oct 12 16:04:48 2013 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2A3A8CAE for ; Sat, 12 Oct 2013 16:04:48 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ACA0D2443 for ; Sat, 12 Oct 2013 16:04:47 +0000 (UTC) Received: by mail-qc0-f171.google.com with SMTP id i7so1965466qcq.16 for ; Sat, 12 Oct 2013 09:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=PpI+jnki7+JW8Cv2vtBBNvVDFBZNMxTBS6N+5zCJ5DE=; b=YQ+l4qTa0Ov5sbvn8IMwi+NxNCN/HVCpdnBLaP0EHaKJPSSOeiNZsWII/MZxrQkThr V69k94eDYVjCv9BTm69fFgp+42FBt6oSczrIQuEg9Pc+oiopN4lAuZmR6a4iuLmmgbyq uL6RWFmEsxug7xBbmRGwKcYIQCPQ90rKboN8O1n2bX9/Rw3p3guHMHJ9+WJw4SeE//ao c4z6+jPohrNSrzxZqqSe/Jc6lH2K3LNY/oomVkguRKtKbB8IKfdJlPSUaV7mn12ZCBQ+ xhH5FYweV7dNUTyOGBXvJ6ssvFLA1aeIW+RoamNGntou5NUrYwvIrhI7+ayRTbditDwC 0EJQ== MIME-Version: 1.0 X-Received: by 10.49.103.161 with SMTP id fx1mr15299598qeb.68.1381593886815; Sat, 12 Oct 2013 09:04:46 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Sat, 12 Oct 2013 09:04:46 -0700 (PDT) In-Reply-To: <201310121257.r9CCvvjO006546@svn.freebsd.org> References: <201310121257.r9CCvvjO006546@svn.freebsd.org> Date: Sat, 12 Oct 2013 09:04:46 -0700 X-Google-Sender-Auth: RNbcO_DzMfuNvM-oaNv50DokD8M Message-ID: Subject: Fwd: svn commit: r256377 - in head: etc/defaults etc/rc.d share/examples/kld/random_adaptor share/man/man4 sys/boot/forth sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe ... From: Adrian Chadd To: "freebsd-embedded@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 16:04:48 -0000 Hi all, We should all test out the latest random changes in -HEAD ASAP before 10.0 is released, just in case Mark's work has messed up entropy on our platforms. Thanks! -a ---------- Forwarded message ---------- From: Mark Murray Date: 12 October 2013 05:57 Subject: svn commit: r256377 - in head: etc/defaults etc/rc.d share/examples/kld/random_adaptor share/man/man4 sys/boot/forth sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe ... To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Author: markm Date: Sat Oct 12 12:57:57 2013 New Revision: 256377 URL: http://svnweb.freebsd.org/changeset/base/256377 Log: Merge from project branch. Uninteresting commits are trimmed. Refactor of /dev/random device. Main points include: * Userland seeding is no longer used. This auto-seeds at boot time on PC/Desktop setups; this may need some tweeking and intelligence from those folks setting up embedded boxes, but the work is believed to be minimal. * An entropy cache is written to /entropy (even during installation) and the kernel uses this at next boot. * An entropy file written to /boot/entropy can be loaded by loader(8) * Hardware sources such as rdrand are fed into Yarrow, and are no longer available raw. ------------------------------------------------------------------------ r256240 | des | 2013-10-09 21:14:16 +0100 (Wed, 09 Oct 2013) | 4 lines Add a RANDOM_RWFILE option and hide the entropy cache code behind it. Rename YARROW_RNG and FORTUNA_RNG to RANDOM_YARROW and RANDOM_FORTUNA. Add the RANDOM_* options to LINT. ------------------------------------------------------------------------ r256239 | des | 2013-10-09 21:12:59 +0100 (Wed, 09 Oct 2013) | 2 lines Define RANDOM_PURE_RNDTEST for rndtest(4). ------------------------------------------------------------------------ r256204 | des | 2013-10-09 18:51:38 +0100 (Wed, 09 Oct 2013) | 2 lines staticize struct random_hardware_source ------------------------------------------------------------------------ r256203 | markm | 2013-10-09 18:50:36 +0100 (Wed, 09 Oct 2013) | 2 lines Wrap some policy-rich code in 'if NOTYET' until we can thresh out what it really needs to do. ------------------------------------------------------------------------ r256184 | des | 2013-10-09 10:13:12 +0100 (Wed, 09 Oct 2013) | 2 lines Re-add /dev/urandom for compatibility purposes. ------------------------------------------------------------------------ r256182 | des | 2013-10-09 10:11:14 +0100 (Wed, 09 Oct 2013) | 3 lines Add missing include guards and move the existing ones out of the implementation namespace. ------------------------------------------------------------------------ r256168 | markm | 2013-10-08 23:14:07 +0100 (Tue, 08 Oct 2013) | 10 lines Fix some just-noticed problems: o Allow this to work with "nodevice random" by fixing where the MALLOC pool is defined. o Fix the explicit reseed code. This was correct as submitted, but in the project branch doesn't need to set the "seeded" bit as this is done correctly in the "unblock" function. o Remove some debug ifdeffing. o Adjust comments. ------------------------------------------------------------------------ r256159 | markm | 2013-10-08 19:48:11 +0100 (Tue, 08 Oct 2013) | 6 lines Time to eat crow for me. I replaced the sx_* locks that Arthur used with regular mutexes; this turned out the be the wrong thing to do as the locks need to be sleepable. Revert this folly. # Submitted by: Arthur Mesh (In original diff) ------------------------------------------------------------------------ r256138 | des | 2013-10-08 12:05:26 +0100 (Tue, 08 Oct 2013) | 10 lines Add YARROW_RNG and FORTUNA_RNG to sys/conf/options. Add a SYSINIT that forces a reseed during proc0 setup, which happens fairly late in the boot process. Add a RANDOM_DEBUG option which enables some debugging printf()s. Add a new RANDOM_ATTACH entropy source which harvests entropy from the get_cyclecount() delta across each call to a device attach method. ------------------------------------------------------------------------ r256135 | markm | 2013-10-08 07:54:52 +0100 (Tue, 08 Oct 2013) | 8 lines Debugging. My attempt at EVENTHANDLER(multiuser) was a failure; use EVENTHANDLER(mountroot) instead. This means we can't count on /var being present, so something will need to be done about harvesting /var/db/entropy/... . Some policy now needs to be sorted out, and a pre-sync cache needs to be written, but apart from that we are now ready to go. Over to review. ------------------------------------------------------------------------ r256094 | markm | 2013-10-06 23:45:02 +0100 (Sun, 06 Oct 2013) | 8 lines Snapshot. Looking pretty good; this mostly works now. New code includes: * Read cached entropy at startup, both from files and from loader(8) preloaded entropy. Failures are soft, but announced. Untested. * Use EVENTHANDLER to do above just before we go multiuser. Untested. ------------------------------------------------------------------------ r256088 | markm | 2013-10-06 14:01:42 +0100 (Sun, 06 Oct 2013) | 2 lines Fix up the man page for random(4). This mainly removes no-longer-relevant details about HW RNGs, reseeding explicitly and user-supplied entropy. ------------------------------------------------------------------------ r256087 | markm | 2013-10-06 13:43:42 +0100 (Sun, 06 Oct 2013) | 6 lines As userland writing to /dev/random is no more, remove the "better than nothing" bootstrap mode. Add SWI harvesting to the mix. My box seeds Yarrow by itself in a few seconds! YMMV; more to follow. ------------------------------------------------------------------------ r256086 | markm | 2013-10-06 13:40:32 +0100 (Sun, 06 Oct 2013) | 11 lines Debug run. This now works, except that the "live" sources haven't been tested. With all sources turned on, this unlocks itself in a couple of seconds! That is no my box, and there is no guarantee that this will be the case everywhere. * Cut debug prints. * Use the same locks/mutexes all the way through. * Be a tad more conservative about entropy estimates. ------------------------------------------------------------------------ r256084 | markm | 2013-10-06 13:35:29 +0100 (Sun, 06 Oct 2013) | 5 lines Don't use the "real" assembler mnemonics; older compilers may not understand them (like when building CURRENT on 9.x). # Submitted by: Konstantin Belousov ------------------------------------------------------------------------ r256081 | markm | 2013-10-06 10:55:28 +0100 (Sun, 06 Oct 2013) | 12 lines SNAPSHOT. Simplify the malloc pools; We only need one for this device. Simplify the harvest queue. Marginally improve the entropy pool hashing, making it a bit faster in the process. Connect up the hardware "live" source harvesting. This is simplistic for now, and will need to be made rate-adaptive. All of the above passes a compile test but needs to be debugged. ------------------------------------------------------------------------ r256042 | markm | 2013-10-04 07:55:06 +0100 (Fri, 04 Oct 2013) | 25 lines Snapshot. This passes the build test, but has not yet been finished or debugged. Contains: * Refactor the hardware RNG CPU instruction sources to feed into the software mixer. This is unfinished. The actual harvesting needs to be sorted out. Modified by me (see below). * Remove 'frac' parameter from random_harvest(). This was never used and adds extra code for no good reason. * Remove device write entropy harvesting. This provided a weak attack vector, was not very good at bootstrapping the device. To follow will be a replacement explicit reseed knob. * Separate out all the RANDOM_PURE sources into separate harvest entities. This adds some secuity in the case where more than one is present. * Review all the code and fix anything obviously messy or inconsistent. Address som review concerns while I'm here, like rename the pseudo-rng to 'dummy'. # Submitted by: Arthur Mesh (the first item) ------------------------------------------------------------------------ r255319 | markm | 2013-09-06 18:51:52 +0100 (Fri, 06 Sep 2013) | 4 lines Yarrow wants entropy estimations to be conservative; the usual idea is that if you are certain you have N bits of entropy, you declare N/2. ------------------------------------------------------------------------ r255075 | markm | 2013-08-30 18:47:53 +0100 (Fri, 30 Aug 2013) | 4 lines Remove short-lived idea; thread to harvest (eg) RDRAND enropy into the usual harvest queues. It was a nifty idea, but too heavyweight. # Submitted by: Arthur Mesh ------------------------------------------------------------------------ r255071 | markm | 2013-08-30 12:42:57 +0100 (Fri, 30 Aug 2013) | 4 lines Separate out the Software RNG entropy harvesting queue and thread into its own files. # Submitted by: Arthur Mesh ------------------------------------------------------------------------ r254934 | markm | 2013-08-26 20:07:03 +0100 (Mon, 26 Aug 2013) | 2 lines Remove the short-lived namei experiment. ------------------------------------------------------------------------ r254928 | markm | 2013-08-26 19:35:21 +0100 (Mon, 26 Aug 2013) | 2 lines Snapshot; Do some running repairs on entropy harvesting. More needs to follow. ------------------------------------------------------------------------ r254927 | markm | 2013-08-26 19:29:51 +0100 (Mon, 26 Aug 2013) | 15 lines Snapshot of current work; 1) Clean up namespace; only use "Yarrow" where it is Yarrow-specific or close enough to the Yarrow algorithm. For the rest use a neutral name. 2) Tidy up headers; put private stuff in private places. More could be done here. 3) Streamline the hashing/encryption; no need for a 256-bit counter; 128 bits will last for long enough. There are bits of debug code lying around; these will be removed at a later stage. ------------------------------------------------------------------------ r254784 | markm | 2013-08-24 14:54:56 +0100 (Sat, 24 Aug 2013) | 39 lines 1) example (partially humorous random_adaptor, that I call "EXAMPLE") * It's not meant to be used in a real system, it's there to show how the basics of how to create interfaces for random_adaptors. Perhaps it should belong in a manual page 2) Move probe.c's functionality in to random_adaptors.c * rename random_ident_hardware() to random_adaptor_choose() 3) Introduce a new way to choose (or select) random_adaptors via tunable "rngs_want" It's a list of comma separated names of adaptors, ordered by preferences. I.e.: rngs_want=3D"yarrow,rdrand" Such setting would cause yarrow to be preferred to rdrand. If neither of them are available (or registered), then system will default to something reasonable (currently yarrow). If yarrow is not present, then we fall back to the adaptor that's first on the list of registered adaptors. 4) Introduce a way where RNGs can play a role of entropy source. This is mostly useful for HW rngs. The way I envision this is that every HW RNG will use this functionality by default. Functionality to disable this is also present. I have an example of how to use this in random_adaptor_example.c (see modload event, and init function) 5) fix kern.random.adaptors from kern.random.adaptors: yarrowpanicblock to kern.random.adaptors: yarrow,panic,block 6) add kern.random.active_adaptor to indicate currently selected adaptor: root@freebsd04:~ # sysctl kern.random.active_adaptor kern.random.active_adaptor: yarrow # Submitted by: Arthur Mesh Submitted by: Dag-Erling Sm=F8rgrav , Arthur Mesh < arthurmesh@gmail.com> Reviewed by: des@FreeBSD.org Approved by: re (delphij) Approved by: secteam (des,delphij) Added: head/sys/dev/random/dummy_rng.c - copied unchanged from r256243, projects/random_number_generator/sys/dev/random/dummy_rng.c head/sys/dev/random/live_entropy_sources.c - copied unchanged from r256243, projects/random_number_generator/sys/dev/random/live_entropy_sources.c head/sys/dev/random/live_entropy_sources.h - copied unchanged from r256243, projects/random_number_generator/sys/dev/random/live_entropy_sources.h head/sys/dev/random/rwfile.c - copied unchanged from r256243, projects/random_number_generator/sys/dev/random/rwfile.c head/sys/dev/random/rwfile.h - copied unchanged from r256243, projects/random_number_generator/sys/dev/random/rwfile.h Deleted: head/sys/dev/random/pseudo_rng.c Modified: head/etc/defaults/rc.conf head/etc/rc.d/initrandom head/share/examples/kld/random_adaptor/random_adaptor_example.c (contents, props changed) head/share/man/man4/random.4 head/sys/boot/forth/loader.conf head/sys/conf/NOTES head/sys/conf/files head/sys/conf/files.amd64 head/sys/conf/files.i386 head/sys/conf/options head/sys/dev/glxsb/glxsb.c head/sys/dev/hifn/hifn7751.c head/sys/dev/random/harvest.c head/sys/dev/random/hash.h head/sys/dev/random/ivy.c head/sys/dev/random/nehemiah.c head/sys/dev/random/random_adaptors.c head/sys/dev/random/random_adaptors.h head/sys/dev/random/random_harvestq.c head/sys/dev/random/random_harvestq.h head/sys/dev/random/randomdev.c head/sys/dev/random/randomdev.h head/sys/dev/random/randomdev_soft.c head/sys/dev/random/randomdev_soft.h head/sys/dev/random/yarrow.c head/sys/dev/random/yarrow.h head/sys/dev/rndtest/rndtest.c head/sys/dev/safe/safe.c head/sys/dev/syscons/scmouse.c head/sys/dev/syscons/syscons.c head/sys/dev/ubsec/ubsec.c head/sys/kern/kern_intr.c head/sys/kern/subr_bus.c head/sys/mips/cavium/octeon_rnd.c head/sys/modules/random/Makefile head/sys/net/if_ethersubr.c head/sys/net/if_tun.c head/sys/netgraph/ng_iface.c head/sys/sys/random.h Directory Properties: head/ (props changed) Modified: head/etc/defaults/rc.conf =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/etc/defaults/rc.conf Sat Oct 12 12:34:19 2013 (r256376) +++ head/etc/defaults/rc.conf Sat Oct 12 12:57:57 2013 (r256377) @@ -651,6 +651,7 @@ entropy_save_num=3D"8" # Number of entropy harvest_interrupt=3D"YES" # Entropy device harvests interrupt randomness harvest_ethernet=3D"YES" # Entropy device harvests ethernet randomness harvest_p_to_p=3D"YES" # Entropy device harvests point-to-point randomne= ss +harvest_swi=3D"YES" # Entropy device harvests internal SWI randomness dmesg_enable=3D"YES" # Save dmesg(8) to /var/run/dmesg.boot watchdogd_enable=3D"NO" # Start the software watchdog daemon watchdogd_flags=3D"" # Flags to watchdogd (if enabled) Modified: head/etc/rc.d/initrandom =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/etc/rc.d/initrandom Sat Oct 12 12:34:19 2013 (r256376) +++ head/etc/rc.d/initrandom Sat Oct 12 12:57:57 2013 (r256377) @@ -14,26 +14,6 @@ name=3D"initrandom" start_cmd=3D"initrandom_start" stop_cmd=3D":" -feed_dev_random() -{ - if [ -f "${1}" -a -r "${1}" -a -s "${1}" ]; then - cat "${1}" | dd of=3D/dev/random bs=3D8k 2>/dev/null - fi -} - -better_than_nothing() -{ - # XXX temporary until we can improve the entropy - # harvesting rate. - # Entropy below is not great, but better than nothing. - # This unblocks the generator at startup - # Note: commands are ordered to cause the most variance across reboots. - ( kenv; dmesg; df -ib; ps -fauxww; date; sysctl -a ) \ - | dd of=3D/dev/random bs=3D8k 2>/dev/null - /sbin/sha256 -q `sysctl -n kern.bootfile` \ - | dd of=3D/dev/random bs=3D8k 2>/dev/null -} - initrandom_start() { soft_random_generator=3D`sysctl kern.random 2>/dev/null` @@ -63,23 +43,15 @@ initrandom_start() else ${SYSCTL} kern.random.sys.harvest.point_to_point=3D0 >/dev/null fi - fi - # First pass at reseeding /dev/random. - # - case ${entropy_file} in - [Nn][Oo] | '') - ;; - *) - if [ -w /dev/random ]; then - feed_dev_random "${entropy_file}" + if checkyesno harvest_swi; then + ${SYSCTL} kern.random.sys.harvest.swi=3D1 >/dev/null + echo -n ' swi' + else + ${SYSCTL} kern.random.sys.harvest.swi=3D0 >/dev/null fi - ;; - esac - - better_than_nothing + fi - echo -n ' kickstart' fi echo '.' Modified: head/share/examples/kld/random_adaptor/random_adaptor_example.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/share/examples/kld/random_adaptor/random_adaptor_example.c Sat Oct 12 12:34:19 2013 (r256376) +++ head/share/examples/kld/random_adaptor/random_adaptor_example.c Sat Oct 12 12:57:57 2013 (r256377) @@ -30,32 +30,29 @@ __FBSDID("$FreeBSD$"); #include #include +#include #include -#include +#include #include +#include #include #include -#define RNG_NAME "example" - static int random_example_read(void *, int); struct random_adaptor random_example =3D { .ident =3D "Example RNG", - .init =3D (random_init_func_t *)random_null_func, - .deinit =3D (random_deinit_func_t *)random_null_func, + .source =3D RANDOM_PURE_BOGUS, /* Make sure this is in + * sys/random.h and is unique */ .read =3D random_example_read, - .write =3D (random_write_func_t *)random_null_func, - .reseed =3D (random_reseed_func_t *)random_null_func, - .seeded =3D 1, }; /* * Used under the license provided @ http://xkcd.com/221/ * http://creativecommons.org/licenses/by-nc/2.5/ */ -static u_char +static uint8_t getRandomNumber(void) { return 4; /* chosen by fair dice roll, guaranteed to be random */ @@ -64,14 +61,13 @@ getRandomNumber(void) static int random_example_read(void *buf, int c) { - u_char *b; + uint8_t *b; int count; b =3D buf; - for (count =3D 0; count < c; count++) { + for (count =3D 0; count < c; count++) b[count] =3D getRandomNumber(); - } printf("returning %d bytes of pure randomness\n", c); return (c); @@ -80,15 +76,26 @@ random_example_read(void *buf, int c) static int random_example_modevent(module_t mod, int type, void *unused) { + int error =3D 0; switch (type) { case MOD_LOAD: - random_adaptor_register(RNG_NAME, &random_example); - EVENTHANDLER_INVOKE(random_adaptor_attach, &random_example)= ; - return (0); + live_entropy_source_register(&random_example); + break; + + case MOD_UNLOAD: + live_entropy_source_deregister(&random_example); + break; + + case MOD_SHUTDOWN: + break; + + default: + error =3D EOPNOTSUPP; + break; } - return (EINVAL); + return (error); } -RANDOM_ADAPTOR_MODULE(random_example, random_example_modevent, 1); +LIVE_ENTROPY_SRC_MODULE(live_entropy_source_example, random_example_modevent, 1); Modified: head/share/man/man4/random.4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/share/man/man4/random.4 Sat Oct 12 12:34:19 2013 (r256376) +++ head/share/man/man4/random.4 Sat Oct 12 12:57:57 2013 (r256377) @@ -1,4 +1,4 @@ -.\" Copyright (c) 2001 Mark R V Murray. All rights reserved. +.\" Copyright (c) 2001-2013 Mark R V Murray. All rights reserved. .\" .\" Redistribution and use in source and binary forms, with or without .\" modification, are permitted provided that the following conditions @@ -23,7 +23,7 @@ .\" .\" $FreeBSD$ .\" -.Dd August 7, 2013 +.Dd October 12, 2013 .Dt RANDOM 4 .Os .Sh NAME @@ -43,35 +43,48 @@ The device will probe for certain hardware entropy sources, and use these in preference to the fallback, which is a generator implemented in software. -If the kernel environment MIB's -.Va hw.nehemiah_rng_enable -or -.Va hw.ivy_rng_enable -are set to -.Dq Li 0 , -the associated hardware entropy source will be ignored. -.Pp -If the device is using -the software generator, -writing data to -.Nm -would perturb the internal state. -This perturbation of the internal state -is the only userland method of introducing -extra entropy into the device. -If the writer has superuser privilege, -then closing the device after writing -will make the software generator reseed itself. -This can be used for extra security, -as it immediately introduces any/all new entropy -into the PRNG. -The hardware generators will generate -sufficient quantities of entropy, -and will therefore ignore user-supplied input. -The software -.Nm -device may be controlled with -.Xr sysctl 8 . +.Pp +The software generator will start in an +.Em unseeded +state, and will block reads until +it is (re)seeded. +This may cause trouble at system boot +when keys and the like +are generated from +/dev/random +so steps should be taken to ensure a +reseed as soon as possible. +The +.Xr sysctl 8 +controlling the +.Em seeded +status (see below) may be used +if security is not an issue +or for convenience +during setup or development. +.Pp +This initial seeding +of random number generators +is a bootstrapping problem +that needs very careful attention. +In some cases, +it may be difficult +to find enough randomness +to seed a random number generator +until a system is fully operational, +but the system requires random numbers +to become fully operational. +It is (or more accurately should be) +critically important that the +.Nm +device is seeded +before the first time it is used. +In the case where a dummy or "blocking-only" +device is used, +it is the responsibility +of the system architect +to ensure that no blocking reads +hold up critical processes. .Pp To see the current settings of the software .Nm @@ -81,22 +94,20 @@ device, use the command line: .Pp which results in something like: .Bd -literal -offset indent -kern.random.adaptors: yarrow +kern.random.adaptors: yarrow,dummy +kern.random.active_adaptor: yarrow +kern.random.yarrow.gengateinterval: 10 +kern.random.yarrow.bins: 10 +kern.random.yarrow.fastthresh: 96 +kern.random.yarrow.slowthresh: 128 +kern.random.yarrow.slowoverthresh: 2 kern.random.sys.seeded: 1 kern.random.sys.harvest.ethernet: 1 kern.random.sys.harvest.point_to_point: 1 kern.random.sys.harvest.interrupt: 1 -kern.random.sys.harvest.swi: 0 -kern.random.yarrow.gengateinterval: 10 -kern.random.yarrow.bins: 10 -kern.random.yarrow.fastthresh: 192 -kern.random.yarrow.slowthresh: 256 -kern.random.yarrow.slowoverthresh: 2 +kern.random.sys.harvest.swi: 1 .Ed .Pp -(These would not be seen if a -hardware generator is present.) -.Pp Other than .Dl kern.random.adaptors all settings are read/write. @@ -107,9 +118,10 @@ variable indicates whether or not the .Nm device is in an acceptably secure state as a result of reseeding. -If set to 0, the device will block (on read) until the next reseed -(which can be from an explicit write, -or as a result of entropy harvesting). +If set to 0, +the device will block (on read) +until the next reseed +as a result of entropy harvesting. A reseed will set the value to 1 (non-blocking). .Pp The @@ -276,19 +288,6 @@ the generator produce independent sequen However, the guessability or reproducibility of the sequence is unimportant, unlike the previous cases. .Pp -One final consideration for the seeding of random number generators -is a bootstrapping problem. -In some cases, it may be difficult to find enough randomness to -seed a random number generator until a system is fully operational, -but the system requires random numbers to become fully operational. -There is no substitute for careful thought here, -but the -.Fx -.Nm -device, -which is based on the Yarrow system, -should be of some help in this area. -.Pp .Fx does also provide the traditional .Xr rand 3 @@ -325,17 +324,7 @@ and is an implementation of the .Em Yarrow algorithm by Bruce Schneier, .Em et al . -The only hardware implementations -currently are for the -.Tn VIA C3 Nehemiah -(stepping 3 or greater) -CPU -and the -.Tn Intel -.Dq Bull Mountain -.Em RdRand -instruction and underlying random number generator (RNG). -More will be added in the future. +Significant infrastructure work was done by Arthur Mesh. .Pp The author gratefully acknowledges significant assistance from VIA Technologies, Inc. Modified: head/sys/boot/forth/loader.conf =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/boot/forth/loader.conf Sat Oct 12 12:34:19 2013 (r256376) +++ head/sys/boot/forth/loader.conf Sat Oct 12 12:57:57 2013 (r256377) @@ -39,6 +39,17 @@ bitmap_type=3D"splash_image_data" # and pl ############################################################## +### Random number generator configuration ################### +############################################################## + +entropy_cache_load=3D"NO" # Set this to YES to load entropy at boot time +entropy_cache_name=3D"/boot/entropy" # Set this to the name of the fil= e +entropy_cache_type=3D"/boot/entropy" +#kern.random.sys.seeded=3D"0" # Set this to 1 to start /dev/ran= dom + # without waiting for a (re)seed. + + +############################################################## ### Loader settings ######################################## ############################################################## Modified: head/sys/conf/NOTES =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/conf/NOTES Sat Oct 12 12:34:19 2013 (r256376) +++ head/sys/conf/NOTES Sat Oct 12 12:57:57 2013 (r256377) @@ -2962,3 +2962,8 @@ options RCTL options BROOKTREE_ALLOC_PAGES=3D(217*4+1) options MAXFILES=3D999 +# Random number generator +options RANDOM_YARROW # Yarrow RNG +##options RANDOM_FORTUNA # Fortuna RNG - not yet implemented +options RANDOM_DEBUG # Debugging messages +options RANDOM_RWFILE # Read and write entropy cache Modified: head/sys/conf/files =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/conf/files Sat Oct 12 12:34:19 2013 (r256376) +++ head/sys/conf/files Sat Oct 12 12:57:57 2013 (r256377) @@ -2043,13 +2043,15 @@ rt2860.fw optional rt2860fw | ralfw \ no-obj no-implicit-rule \ clean "rt2860.fw" dev/random/harvest.c standard -dev/random/hash.c optional random -dev/random/pseudo_rng.c standard +dev/random/dummy_rng.c standard dev/random/random_adaptors.c standard -dev/random/random_harvestq.c standard +dev/random/live_entropy_sources.c optional random +dev/random/random_harvestq.c optional random dev/random/randomdev.c optional random dev/random/randomdev_soft.c optional random dev/random/yarrow.c optional random +dev/random/hash.c optional random +dev/random/rwfile.c optional random dev/rc/rc.c optional rc dev/re/if_re.c optional re dev/rndtest/rndtest.c optional rndtest Modified: head/sys/conf/files.amd64 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/conf/files.amd64 Sat Oct 12 12:34:19 2013 (r256376) +++ head/sys/conf/files.amd64 Sat Oct 12 12:57:57 2013 (r256377) @@ -259,8 +259,8 @@ dev/nvme/nvme_sysctl.c optional nvm= e dev/nvme/nvme_test.c optional nvme dev/nvme/nvme_util.c optional nvme dev/nvram/nvram.c optional nvram isa -dev/random/ivy.c optional random rdrand_rng -dev/random/nehemiah.c optional random padlock_rng +dev/random/ivy.c optional rdrand_rng +dev/random/nehemiah.c optional padlock_rng dev/qlxge/qls_dbg.c optional qlxge pci dev/qlxge/qls_dump.c optional qlxge pci dev/qlxge/qls_hw.c optional qlxge pci Modified: head/sys/conf/files.i386 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/conf/files.i386 Sat Oct 12 12:34:19 2013 (r256376) +++ head/sys/conf/files.i386 Sat Oct 12 12:57:57 2013 (r256377) @@ -257,8 +257,8 @@ dev/nvme/nvme_test.c optional nvme dev/nvme/nvme_util.c optional nvme dev/nvram/nvram.c optional nvram isa dev/pcf/pcf_isa.c optional pcf -dev/random/ivy.c optional random rdrand_rng -dev/random/nehemiah.c optional random padlock_rng +dev/random/ivy.c optional rdrand_rng +dev/random/nehemiah.c optional padlock_rng dev/sbni/if_sbni.c optional sbni dev/sbni/if_sbni_isa.c optional sbni isa dev/sbni/if_sbni_pci.c optional sbni pci Modified: head/sys/conf/options =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/conf/options Sat Oct 12 12:34:19 2013 (r256376) +++ head/sys/conf/options Sat Oct 12 12:57:57 2013 (r256377) @@ -904,3 +904,9 @@ RACCT opt_global.h # Resource Limits RCTL opt_global.h + +# Random number generator(s) +RANDOM_YARROW opt_random.h +RANDOM_FORTUNA opt_random.h +RANDOM_DEBUG opt_random.h +RANDOM_RWFILE opt_random.h Modified: head/sys/dev/glxsb/glxsb.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/dev/glxsb/glxsb.c Sat Oct 12 12:34:19 2013 (r256376) +++ head/sys/dev/glxsb/glxsb.c Sat Oct 12 12:57:57 2013 (r256377) @@ -476,7 +476,7 @@ glxsb_rnd(void *v) if (status & SB_RNS_TRNG_VALID) { value =3D bus_read_4(sc->sc_sr, SB_RANDOM_NUM); /* feed with one uint32 */ - random_harvest(&value, 4, 32/2, 0, RANDOM_PURE); + random_harvest(&value, 4, 32/2, RANDOM_PURE_GLXSB); } callout_reset(&sc->sc_rngco, sc->sc_rnghz, glxsb_rnd, sc); Modified: head/sys/dev/hifn/hifn7751.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/dev/hifn/hifn7751.c Sat Oct 12 12:34:19 2013 (r256376) +++ head/sys/dev/hifn/hifn7751.c Sat Oct 12 12:57:57 2013 (r256377) @@ -258,7 +258,7 @@ hifn_partname(struct hifn_softc *sc) static void default_harvest(struct rndtest_state *rsp, void *buf, u_int count) { - random_harvest(buf, count, count*NBBY/2, 0, RANDOM_PURE); + random_harvest(buf, count, count*NBBY/2, RANDOM_PURE_HIFN); } static u_int Copied: head/sys/dev/random/dummy_rng.c (from r256243, projects/random_number_generator/sys/dev/random/dummy_rng.c) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/sys/dev/random/dummy_rng.c Sat Oct 12 12:57:57 2013 (r256377, copy of r256243, projects/random_number_generator/sys/dev/random/dummy_rng.c) @@ -0,0 +1,123 @@ +/*- + * Copyright (c) 2013 Arthur Mesh + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer + * in this position and unchanged. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BU= T + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE O= F + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * + */ +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +static struct mtx dummy_random_mtx; + +/* Used to fake out unused random calls in random_adaptor */ +static void +random_null_func(void) +{ +} + +static int +dummy_random_poll(int events __unused, struct thread *td __unused) +{ + + return (0); +} + +static int +dummy_random_block(int flag) +{ + int error =3D 0; + + mtx_lock(&dummy_random_mtx); + + /* Blocking logic */ + while (!error) { + if (flag & O_NONBLOCK) + error =3D EWOULDBLOCK; + else { + printf("random: dummy device blocking on read.\n"); + error =3D msleep(&dummy_random_block, + &dummy_random_mtx, + PUSER | PCATCH, "block", 0); + } + } + mtx_unlock(&dummy_random_mtx); + + return (error); +} + +static void +dummy_random_init(void) +{ + + mtx_init(&dummy_random_mtx, "sleep mtx for dummy_random", + NULL, MTX_DEF); +} + +static void +dummy_random_deinit(void) +{ + + mtx_destroy(&dummy_random_mtx); +} + +struct random_adaptor dummy_random =3D { + .ident =3D "Dummy entropy device that always blocks", + .init =3D dummy_random_init, + .deinit =3D dummy_random_deinit, + .block =3D dummy_random_block, + .poll =3D dummy_random_poll, + .read =3D (random_read_func_t *)random_null_func, + .reseed =3D (random_reseed_func_t *)random_null_func, + .seeded =3D 0, /* This device can never be seeded */ +}; + +static int +dummy_random_modevent(module_t mod __unused, int type, void *unused __unused) +{ + + switch (type) { + case MOD_LOAD: + random_adaptor_register("dummy", &dummy_random); + EVENTHANDLER_INVOKE(random_adaptor_attach, + &dummy_random); + + return (0); + } + + return (EINVAL); +} + +RANDOM_ADAPTOR_MODULE(dummy, dummy_random_modevent, 1); Modified: head/sys/dev/random/harvest.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/dev/random/harvest.c Sat Oct 12 12:34:19 2013 (r256376) +++ head/sys/dev/random/harvest.c Sat Oct 12 12:57:57 2013 (r256377) @@ -48,20 +48,20 @@ __FBSDID("$FreeBSD$"); static int read_random_phony(void *, int); /* Structure holding the desired entropy sources */ -struct harvest_select harvest =3D { 1, 1, 1, 0 }; +struct harvest_select harvest =3D { 1, 1, 1, 1 }; static int warned =3D 0; /* hold the address of the routine which is actually called if * the randomdev is loaded */ -static void (*reap_func)(u_int64_t, const void *, u_int, u_int, u_int, +static void (*reap_func)(u_int64_t, const void *, u_int, u_int, enum esource) =3D NULL; static int (*read_func)(void *, int) =3D read_random_phony; /* Initialise the harvester at load time */ void randomdev_init_harvester(void (*reaper)(u_int64_t, const void *, u_int, - u_int, u_int, enum esource), int (*reader)(void *, int)) + u_int, enum esource), int (*reader)(void *, int)) { reap_func =3D reaper; read_func =3D reader; @@ -86,12 +86,10 @@ randomdev_deinit_harvester(void) * read which can be quite expensive. */ void -random_harvest(void *entropy, u_int count, u_int bits, u_int frac, - enum esource origin) +random_harvest(void *entropy, u_int count, u_int bits, enum esource origin= ) { if (reap_func) - (*reap_func)(get_cyclecount(), entropy, count, bits, frac, - origin); + (*reap_func)(get_cyclecount(), entropy, count, bits, origin); } /* Userland-visible version of read_random */ Modified: head/sys/dev/random/hash.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/dev/random/hash.h Sat Oct 12 12:34:19 2013 (r256376) +++ head/sys/dev/random/hash.h Sat Oct 12 12:57:57 2013 (r256377) @@ -26,6 +26,9 @@ * $FreeBSD$ */ +#ifndef SYS_DEV_RANDOM_HASH_H_INCLUDED +#define SYS_DEV_RANDOM_HASH_H_INCLUDED + #define KEYSIZE 32 /* (in bytes) =3D=3D 256 bits */ #define BLOCKSIZE 16 /* (in bytes) =3D=3D 128 bits */ @@ -43,3 +46,5 @@ void randomdev_hash_iterate(struct rando void randomdev_hash_finish(struct randomdev_hash *, void *); void randomdev_encrypt_init(struct randomdev_key *, void *); void randomdev_encrypt(struct randomdev_key *context, void *, void *, unsigned); + +#endif Modified: head/sys/dev/random/ivy.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/dev/random/ivy.c Sat Oct 12 12:34:19 2013 (r256376) +++ head/sys/dev/random/ivy.c Sat Oct 12 12:57:57 2013 (r256377) @@ -30,38 +30,35 @@ __FBSDID("$FreeBSD$"); #include -#include #include #include +#include #include -#include +#include #include #include #include #include -#include #include +#include +#include +#include +#include #define RETRY_COUNT 10 -static void random_ivy_init(void); -static void random_ivy_deinit(void); static int random_ivy_read(void *, int); -struct random_adaptor random_ivy =3D { +static struct random_hardware_source random_ivy =3D { .ident =3D "Hardware, Intel IvyBridge+ RNG", - .init =3D random_ivy_init, - .deinit =3D random_ivy_deinit, - .read =3D random_ivy_read, - .write =3D (random_write_func_t *)random_null_func, - .reseed =3D (random_reseed_func_t *)random_null_func, - .seeded =3D 1, + .source =3D RANDOM_PURE_RDRAND, + .read =3D random_ivy_read }; static inline int -ivy_rng_store(long *tmp) +ivy_rng_store(uint64_t *tmp) { #ifdef __GNUCLIKE_ASM uint32_t count; @@ -86,34 +83,26 @@ ivy_rng_store(long *tmp) #endif } -static void -random_ivy_init(void) -{ -} - -void -random_ivy_deinit(void) -{ -} - static int random_ivy_read(void *buf, int c) { - char *b; - long tmp; - int count, res, retry; + uint8_t *b; + int count, ret, retry; + uint64_t tmp; - for (count =3D c, b =3D buf; count > 0; count -=3D res, b +=3D res)= { + b =3D buf; + for (count =3D c; count > 0; count -=3D ret) { for (retry =3D 0; retry < RETRY_COUNT; retry++) { - res =3D ivy_rng_store(&tmp); - if (res !=3D 0) + ret =3D ivy_rng_store(&tmp); + if (ret !=3D 0) break; } - if (res =3D=3D 0) + if (ret =3D=3D 0) break; - if (res > count) - res =3D count; - memcpy(b, &tmp, res); + if (ret > count) + ret =3D count; + memcpy(b, &tmp, ret); + b +=3D ret; } return (c - count); } @@ -121,25 +110,35 @@ random_ivy_read(void *buf, int c) static int rdrand_modevent(module_t mod, int type, void *unused) { + int error =3D 0; switch (type) { case MOD_LOAD: - if (cpu_feature2 & CPUID2_RDRAND) { - random_adaptor_register("rdrand", &random_ivy); - EVENTHANDLER_INVOKE(random_adaptor_attach, &random_ivy); - return (0); - } else { + if (cpu_feature2 & CPUID2_RDRAND) + live_entropy_source_register(&random_ivy); + else #ifndef KLD_MODULE if (bootverbose) #endif - printf( - "%s: RDRAND feature is not present on this CPU\n", + printf("%s: RDRAND is not present\n", random_ivy.ident); - return (0); - } + break; + + case MOD_UNLOAD: + if (cpu_feature2 & CPUID2_RDRAND) + live_entropy_source_deregister(&random_ivy); + break; + + case MOD_SHUTDOWN: + break; + + default: + error =3D EOPNOTSUPP; + break; + } - return (EINVAL); + return (error); } -RANDOM_ADAPTOR_MODULE(random_rdrand, rdrand_modevent, 1); +LIVE_ENTROPY_SRC_MODULE(random_rdrand, rdrand_modevent, 1); Copied: head/sys/dev/random/live_entropy_sources.c (from r256243, projects/random_number_generator/sys/dev/random/live_entropy_sources.c) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/sys/dev/random/live_entropy_sources.c Sat Oct 12 12:57:57 2013 (r256377, copy of r256243, projects/random_number_generator/sys/dev/random/live_entropy_sources.c) @@ -0,0 +1,195 @@ +/*- + * Copyright (c) 2013 Arthur Mesh + * Copyright (c) 2013 Mark R V Murray + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer + * in this position and unchanged. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BU= T + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE O= F + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include +#include +#include +#include + +#include "live_entropy_sources.h" + +LIST_HEAD(les_head, live_entropy_sources); +static struct les_head sources =3D LIST_HEAD_INITIALIZER(sources); + +/* + * The live_lock protects the consistency of the "struct les_head sources" + */ +static struct sx les_lock; /* need a sleepable lock */ + +void +live_entropy_source_register(struct random_hardware_source *rsource) +{ + struct live_entropy_sources *les; + + KASSERT(rsource !=3D NULL, ("invalid input to %s", __func__)); + + les =3D malloc(sizeof(struct live_entropy_sources), M_ENTROPY, M_WAITOK); + les->rsource =3D rsource; + + sx_xlock(&les_lock); + LIST_INSERT_HEAD(&sources, les, entries); + sx_xunlock(&les_lock); +} + +void +live_entropy_source_deregister(struct random_hardware_source *rsource) +{ + struct live_entropy_sources *les =3D NULL; + + KASSERT(rsource !=3D NULL, ("invalid input to %s", __func__)); + + sx_xlock(&les_lock); + LIST_FOREACH(les, &sources, entries) + if (les->rsource =3D=3D rsource) { + LIST_REMOVE(les, entries); + break; + } + sx_xunlock(&les_lock); + if (les !=3D NULL) + free(les, M_ENTROPY); +} + +static int +live_entropy_source_handler(SYSCTL_HANDLER_ARGS) +{ + struct live_entropy_sources *les; + int error, count; + + count =3D error =3D 0; + + sx_slock(&les_lock); + + if (LIST_EMPTY(&sources)) + error =3D SYSCTL_OUT(req, "", 0); + else { + LIST_FOREACH(les, &sources, entries) { + + error =3D SYSCTL_OUT(req, ",", count++ ? 1 : 0); + if (error) + break; + + error =3D SYSCTL_OUT(req, les->rsource->ident, strlen(les->rsource->ident)); + if (error) + break; + } + } + + sx_sunlock(&les_lock); + + return (error); +} + +static void +live_entropy_sources_init(void *unused) +{ + + SYSCTL_PROC(_kern_random, OID_AUTO, live_entropy_sources, + CTLTYPE_STRING | CTLFLAG_RD | CTLFLAG_MPSAFE, + NULL, 0, live_entropy_source_handler, "", + "List of Active Live Entropy Sources"); + + sx_init(&les_lock, "live_entropy_sources"); +} + +/* + * Run through all "live" sources reading entropy for the given + * number of rounds, which should be a multiple of the number + * of entropy accumulation pools in use; 2 for Yarrow and 32 + * for Fortuna. + * + * BEWARE!!! + * This function runs inside the RNG thread! Don't do anything silly! + * Remember that we are NOT holding harvest_mtx on entry! + */ +void +live_entropy_sources_feed(int rounds, event_proc_f entropy_processor) +{ + static struct harvest event; + static uint8_t buf[HARVESTSIZE]; + struct live_entropy_sources *les; + int i, n; + + sx_slock(&les_lock); + + /* + * Walk over all of live entropy sources, and feed their output + * to the system-wide RNG. + */ + LIST_FOREACH(les, &sources, entries) { + + for (i =3D 0; i < rounds; i++) { + /* + * This should be quick, since it's a live entropy + * source. + */ + /* FIXME: Whine loudly if this didn't work. */ + n =3D les->rsource->read(buf, sizeof(buf)); + n =3D MIN(n, HARVESTSIZE); + + event.somecounter =3D get_cyclecount(); + event.size =3D n; + event.bits =3D (n*8)/2; + event.source =3D les->rsource->source; + memcpy(event.entropy, buf, n); + + /* Do the actual entropy insertion */ + entropy_processor(&event); + } + + } + + sx_sunlock(&les_lock); +} + +static void +live_entropy_sources_deinit(void *unused) +{ + + sx_destroy(&les_lock); +} + +SYSINIT(random_adaptors, SI_SUB_DRIVERS, SI_ORDER_FIRST, + live_entropy_sources_init, NULL); +SYSUNINIT(random_adaptors, SI_SUB_DRIVERS, SI_ORDER_FIRST, + live_entropy_sources_deinit, NULL); Copied: head/sys/dev/random/live_entropy_sources.h (from r256243, projects/random_number_generator/sys/dev/random/live_entropy_sources.h) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/sys/dev/random/live_entropy_sources.h Sat Oct 12 12:57:57 2013 (r256377, copy of r256243, projects/random_number_generator/sys/dev/random/live_entropy_sources.h) @@ -0,0 +1,60 @@ +/*- + * Copyright (c) 2013 Arthur Mesh + * Copyright (c) 2013 Mark R V Murray + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer + * in this position and unchanged. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***