Date: Thu, 11 Feb 2016 19:42:57 +0100 From: Ilya Bakulin <ilya@bakulin.de> To: "Lundberg, Johannes" <johannes@brilliantservice.co.jp> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, Adrian Chadd <adrian.chadd@gmail.com>, Alexander Motin <mav@freebsd.org>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: MMC/SDIO stack under CAM Message-ID: <DD0089CC-19BF-4179-9A05-6B920B1DF7F9@bakulin.de> In-Reply-To: <CAASDrVkHKzt4LKnLEFbwZ0gWRpwEOcpjaCFaOTg%2Bs2DACebopA@mail.gmail.com> References: <20140216111153.GA74858@olymp.kibab.com> <5C2CF572-360D-4CA0-81C7-18A5C455AED5@bsdimp.com> <20140224142642.GA32538@olymp.kibab.com> <CAJ-VmomNzCMc1T=0jAnyd_uGXbvgeTzZTtmhUPSvZ0DKUEjtKg@mail.gmail.com> <53120EE8.1080600@bakulin.de> <CAJ-VmonPkdVVq7nC3FdopcgzmSTsj3gTO=Cghx-62XS5K25YQg@mail.gmail.com> <5688F015.4090002@bakulin.de> <CAASDrVkHKzt4LKnLEFbwZ0gWRpwEOcpjaCFaOTg%2Bs2DACebopA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Johannes, My work doesn't include writing drivers for SDHCI controllers. But if the controller on your new boards is supported by FreeBSD, then you can really test the new stack! Especially if the controller driver for your board is based on dev/sdhci, adapting it to work with the new stack is trivial. For example, iMX6 SDHCI needed only a couple of lines: https://github.com/kibab/freebsd/commit/df6d8d534740aa3633979da0a9d0ca00b60db0e9 Please let me know when you get the new boards and we will figure out what we need. On February 11, 2016 3:17:22 AM GMT+01:00, "Lundberg, Johannes" <johannes@brilliantservice.co.jp> wrote: >Hi Ilya > >This is great! > >I've got a Tronsmart ARA X5 and just purchased a few UP ><http://up-shop.org/up-boards/2-up-board-2gb-16-gb-emmc-memory.html>; >boards >and it would be really nice if I could utilize the onboard eMMC. These >are >all Intel Cherrytrail platforms. > >Please let me know if there's anything (testing?) I can do to speed up >the >process. > > > >-- >Name: Johannes Lundberg >Position: Mirama project leader >Phone: +1-408-636-2161 >Skype: brilliantjohannes >Online: LinkedIn <http://jp.linkedin.com/in/lundbergjohannes>; >Facebook ><https://www.facebook.com/miramaone>; Reddit ><https://www.reddit.com/user/yohanesu75/>; Twitter ><https://twitter.com/Yohanesu75Tweet>; GitHub ><https://github.com/yohanesu75>; >GitLab <https://gitlab.com/u/johannes_lundberg>; >Company: Mirama <http://mira.ma>; Brilliantservice US ><http://www.brilliantserviceusa.com>; Brilliantservice JP ><http://www.brilliantservice.co.jp>; > >On Sun, Jan 3, 2016 at 1:55 AM, Ilya Bakulin <ilya@bakulin.de> wrote: > >> So, more than one year has passed, and I'd like to resurrect this >work >> and move forward. >> >> I have uploaded a new diff and created a completely new revision to >> track the development: https://reviews.freebsd.org/D4761 >> >> What it is able to do now: >> >> * Read/write on SD/SDHC/MMC cards! >> * Detect SDIO cards and create devices that correspond to SDIO >functions >> >> This all works only on BeagleBone currently, because some changes >need >> to be done in each SDHCI-compliant driver to make it interact with >CAM. >> I have purchased a Wandboard Quad that has an integrated SDIO WiFi >chip, >> so I hope to tweak its SDHCI driver as well. >> >> I haven't profiled the stack because: >> * Now we have only SD/MMC cards that are slow anyway; >> * I don't know how to do it in FreeBSD :-) >> >> Please review this diff and tell what you think! >> >> On 01/03/14 18:05, Adrian Chadd wrote: >> > On 1 March 2014 08:46, Ilya Bakulin <ilya@bakulin.de> wrote: >> >> Hi Adrian, >> >> >> >> On 24.02.14, 16:59, Adrian Chadd wrote: >> >>> hi, >> >>> >> >>> Let me just reiterate some .. well, experience doing this stuff >at QCA. >> >>> >> >>> You really, absolutely don't want too much overhead in the >MMC/SDIO >> >>> path between whatever is issuing things and the network driver. >> >>> >> >>> There was significant performance work done at QCA on a local >MMC/SDIO >> >>> driver and bus to get extremely low latency and CPU utilisation >when >> >>> pushing around small transactions. The current CAM locking model >is >> >>> not geared towards getting to high transaction rates. >> >> So here you mean some work done on Linux MMC/SDIO stack by QCA >> >> which made it far better than current Linux MMC stack in terms of >> >> high SDIO I/O rates? >> > Yup. The stock MMC stack/driver in Linux wasn't "fast" enough at >small >> > transactions to sustain the wifi speeds customers required. >> > >> >>> You may think this is a very architecturally pretty solution and >it >> >>> indeed may be. But if it doesn't perform as well as the existing >local >> >>> hacks that vendors have done, no company deploying this hardware >is >> >>> going to want to use it. They'll end up realising there's this >massive >> >>> CAM storage layer in between and either have to sit down to rip >it up >> >>> and replace it with something lightweight, or they'll say "screw >it" >> >>> and go back to the vendor supplied hacked up Linux solution. >> >> I think that if the "architecturally pretty solution" behaves >worse than >> >> some ugly hacks, then it may be not so pretty or the architecture >is >> >> just broken >> >> by design. >> >> >> >>> So I highly recommend you profile things - and profile things >with >> >>> lots of small transactions. If the CAM overhead is more than a >tiny, >> >>> tiny fraction of CPU at 25,000 pps, your solution won't scale. >:-) >> >> I don't really know what to compare with. For MMC/SD cards it is >pretty >> >> obvious, but then these cards will be likely the bottleneck, not >the >> stack. >> >> And the only goal would be to not make the stack slower than it is >now. >> >> But, as ATA devices are much faster than MMC/SD, I don't think >this will >> >> be a problem. >> >> >> >> For SDIO things are different. But we don't have any drivers >(yet), >> except >> >> mv_sdiowl that I'm writing, to test on. So I have to bring the >SDIO >> >> stack on CAM, >> >> than bring mv_sdiowl to the state when it can actually transmit >the >> >> data, and then >> >> compare performance with the vendor-supplied Linux driver. >> >> We'll see then if there is a room for improvement... >> > That sounds like a plan. >> > >> > Just note that although storage looks like it's doing much more >> > throughput, the IO size also matters. As I said above, it's not >> > uncommon to have > 1000 receive frames a second on 802.11n; and >that >> > can peak much higher than that. That's not the kind of IO rate you >see >> > on SD cards. :-) >> > >> > >> > >> > -a >> > _______________________________________________ >> > freebsd-hackers@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> > To unsubscribe, send any mail to " >> freebsd-hackers-unsubscribe@freebsd.org" >> > >> >> >> -- >> Regards, >> Ilya Bakulin >> >> >> > >-- >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。 >もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、 >複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。 >--- >CONFIDENTIALITY NOTE: The information in this email is confidential >and intended solely for the addressee. >Disclosure, copying, distribution or any other action of use of this >email by person other than intended recipient, is prohibited. >If you are not the intended recipient and have received this email in >error, please destroy the original message. -- Простите за краткость, создано в K-9 Mail. From owner-freebsd-arm@freebsd.org Thu Feb 11 18:47:27 2016 Return-Path: <owner-freebsd-arm@freebsd.org> Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 04C16AA63D6; Thu, 11 Feb 2016 18:47:27 +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 67BB7BC7; Thu, 11 Feb 2016 18:47:25 +0000 (UTC) (envelope-from ilya@bakulin.de) DKIM-Filter: OpenDKIM Filter v2.10.3 olymp.kibab.com 957324E674 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bakulin.de; s=default; t=1455216445; bh=tRMeB9fG5vJN/yPGo7dqSSA4P1vEcY/rDAYmT+8+LtQ=; h=In-Reply-To:References:Subject:From:Date:To:CC; b=pOW+ovNQ3aNiRD7U0ZG0lNWj3Pc6o6fFlMGUIPBynsJjBX/X9r3HnWZm1L5jV8nDU o7UeNUKeEUZ3D8UWYSXRPIECV6BbfNVQloI6YdEUiQaJZtR3Bv84ywb2C7L8eqwGcY wDhC7ELzEtkjTLG/1/DgzHqF7QAriJRaYhPKq0sc= In-Reply-To: <CAASDrVkHKzt4LKnLEFbwZ0gWRpwEOcpjaCFaOTg+s2DACebopA@mail.gmail.com> References: <20140216111153.GA74858@olymp.kibab.com> <5C2CF572-360D-4CA0-81C7-18A5C455AED5@bsdimp.com> <20140224142642.GA32538@olymp.kibab.com> <CAJ-VmomNzCMc1T=0jAnyd_uGXbvgeTzZTtmhUPSvZ0DKUEjtKg@mail.gmail.com> <53120EE8.1080600@bakulin.de> <CAJ-VmonPkdVVq7nC3FdopcgzmSTsj3gTO=Cghx-62XS5K25YQg@mail.gmail.com> <5688F015.4090002@bakulin.de> <CAASDrVkHKzt4LKnLEFbwZ0gWRpwEOcpjaCFaOTg+s2DACebopA@mail.gmail.com> MIME-Version: 1.0 Subject: Re: MMC/SDIO stack under CAM From: Ilya Bakulin <ilya@bakulin.de> Date: Thu, 11 Feb 2016 19:47:09 +0100 To: "Lundberg, Johannes" <johannes@brilliantservice.co.jp> CC: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, Adrian Chadd <adrian.chadd@gmail.com>, Alexander Motin <mav@freebsd.org>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Message-ID: <E0EFD24D-B888-4025-AC41-C3D21E5536E9@bakulin.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>, <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>; List-Post: <mailto:freebsd-arm@freebsd.org> List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>, <mailto:freebsd-arm-request@freebsd.org?subject=subscribe> X-List-Received-Date: Thu, 11 Feb 2016 18:47:27 -0000 I'll use an excellent opportunity to post a small status update about my work :-) * SDHC controller on Wandboard now works with the new stack; * SDIO block read now works! * camcontrol userland app is extended to support "mmcsdcmd" command that allows to send MMC commands from userland apps directly to the card via pass(4) device -- now we can write WLAN driver in userland :-D On February 11, 2016 3:17:22 AM GMT+01:00, "Lundberg, Johannes" <johannes@brilliantservice.co.jp> wrote: >Hi Ilya > >This is great! > >I've got a Tronsmart ARA X5 and just purchased a few UP ><http://up-shop.org/up-boards/2-up-board-2gb-16-gb-emmc-memory.html>; >boards >and it would be really nice if I could utilize the onboard eMMC. These >are >all Intel Cherrytrail platforms. > >Please let me know if there's anything (testing?) I can do to speed up >the >process. > > > >-- >Name: Johannes Lundberg >Position: Mirama project leader >Phone: +1-408-636-2161 >Skype: brilliantjohannes >Online: LinkedIn <http://jp.linkedin.com/in/lundbergjohannes>; >Facebook ><https://www.facebook.com/miramaone>; Reddit ><https://www.reddit.com/user/yohanesu75/>; Twitter ><https://twitter.com/Yohanesu75Tweet>; GitHub ><https://github.com/yohanesu75>; >GitLab <https://gitlab.com/u/johannes_lundberg>; >Company: Mirama <http://mira.ma>; Brilliantservice US ><http://www.brilliantserviceusa.com>; Brilliantservice JP ><http://www.brilliantservice.co.jp>; > >On Sun, Jan 3, 2016 at 1:55 AM, Ilya Bakulin <ilya@bakulin.de> wrote: > >> So, more than one year has passed, and I'd like to resurrect this >work >> and move forward. >> >> I have uploaded a new diff and created a completely new revision to >> track the development: https://reviews.freebsd.org/D4761 >> >> What it is able to do now: >> >> * Read/write on SD/SDHC/MMC cards! >> * Detect SDIO cards and create devices that correspond to SDIO >functions >> >> This all works only on BeagleBone currently, because some changes >need >> to be done in each SDHCI-compliant driver to make it interact with >CAM. >> I have purchased a Wandboard Quad that has an integrated SDIO WiFi >chip, >> so I hope to tweak its SDHCI driver as well. >> >> I haven't profiled the stack because: >> * Now we have only SD/MMC cards that are slow anyway; >> * I don't know how to do it in FreeBSD :-) >> >> Please review this diff and tell what you think! >> >> On 01/03/14 18:05, Adrian Chadd wrote: >> > On 1 March 2014 08:46, Ilya Bakulin <ilya@bakulin.de> wrote: >> >> Hi Adrian, >> >> >> >> On 24.02.14, 16:59, Adrian Chadd wrote: >> >>> hi, >> >>> >> >>> Let me just reiterate some .. well, experience doing this stuff >at QCA. >> >>> >> >>> You really, absolutely don't want too much overhead in the >MMC/SDIO >> >>> path between whatever is issuing things and the network driver. >> >>> >> >>> There was significant performance work done at QCA on a local >MMC/SDIO >> >>> driver and bus to get extremely low latency and CPU utilisation >when >> >>> pushing around small transactions. The current CAM locking model >is >> >>> not geared towards getting to high transaction rates. >> >> So here you mean some work done on Linux MMC/SDIO stack by QCA >> >> which made it far better than current Linux MMC stack in terms of >> >> high SDIO I/O rates? >> > Yup. The stock MMC stack/driver in Linux wasn't "fast" enough at >small >> > transactions to sustain the wifi speeds customers required. >> > >> >>> You may think this is a very architecturally pretty solution and >it >> >>> indeed may be. But if it doesn't perform as well as the existing >local >> >>> hacks that vendors have done, no company deploying this hardware >is >> >>> going to want to use it. They'll end up realising there's this >massive >> >>> CAM storage layer in between and either have to sit down to rip >it up >> >>> and replace it with something lightweight, or they'll say "screw >it" >> >>> and go back to the vendor supplied hacked up Linux solution. >> >> I think that if the "architecturally pretty solution" behaves >worse than >> >> some ugly hacks, then it may be not so pretty or the architecture >is >> >> just broken >> >> by design. >> >> >> >>> So I highly recommend you profile things - and profile things >with >> >>> lots of small transactions. If the CAM overhead is more than a >tiny, >> >>> tiny fraction of CPU at 25,000 pps, your solution won't scale. >:-) >> >> I don't really know what to compare with. For MMC/SD cards it is >pretty >> >> obvious, but then these cards will be likely the bottleneck, not >the >> stack. >> >> And the only goal would be to not make the stack slower than it is >now. >> >> But, as ATA devices are much faster than MMC/SD, I don't think >this will >> >> be a problem. >> >> >> >> For SDIO things are different. But we don't have any drivers >(yet), >> except >> >> mv_sdiowl that I'm writing, to test on. So I have to bring the >SDIO >> >> stack on CAM, >> >> than bring mv_sdiowl to the state when it can actually transmit >the >> >> data, and then >> >> compare performance with the vendor-supplied Linux driver. >> >> We'll see then if there is a room for improvement... >> > That sounds like a plan. >> > >> > Just note that although storage looks like it's doing much more >> > throughput, the IO size also matters. As I said above, it's not >> > uncommon to have > 1000 receive frames a second on 802.11n; and >that >> > can peak much higher than that. That's not the kind of IO rate you >see >> > on SD cards. :-) >> > >> > >> > >> > -a >> > _______________________________________________ >> > freebsd-hackers@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> > To unsubscribe, send any mail to " >> freebsd-hackers-unsubscribe@freebsd.org" >> > >> >> >> -- >> Regards, >> Ilya Bakulin >> >> >> > >-- >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。 >もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、 >複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。 >--- >CONFIDENTIALITY NOTE: The information in this email is confidential >and intended solely for the addressee. >Disclosure, copying, distribution or any other action of use of this >email by person other than intended recipient, is prohibited. >If you are not the intended recipient and have received this email in >error, please destroy the original message. -- Простите за краткость, создано в K-9 Mail. From owner-freebsd-arm@freebsd.org Thu Feb 11 18:54:21 2016 Return-Path: <owner-freebsd-arm@freebsd.org> Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 97764AA68A4; Thu, 11 Feb 2016 18:54:21 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (mx0.deglitch.com [IPv6:2a00:13c0:63:7194:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 5B967119E; Thu, 11 Feb 2016 18:54:21 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from [192.168.11.14] (unknown [98.248.95.7]) by mx0.deglitch.com (Postfix) with ESMTPSA id 0DF598FC0A; Thu, 11 Feb 2016 10:54:15 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: MMC/SDIO stack under CAM From: Stanislav Sedov <stas@FreeBSD.org> In-Reply-To: <E0EFD24D-B888-4025-AC41-C3D21E5536E9@bakulin.de> Date: Thu, 11 Feb 2016 10:54:12 -0800 Cc: "Lundberg, Johannes" <johannes@brilliantservice.co.jp>, Adrian Chadd <adrian.chadd@gmail.com>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, Alexander Motin <mav@freebsd.org>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Content-Transfer-Encoding: quoted-printable Message-Id: <6942A46B-110B-4E1F-9DA1-F965009E8E92@FreeBSD.org> References: <20140216111153.GA74858@olymp.kibab.com> <5C2CF572-360D-4CA0-81C7-18A5C455AED5@bsdimp.com> <20140224142642.GA32538@olymp.kibab.com> <CAJ-VmomNzCMc1T=0jAnyd_uGXbvgeTzZTtmhUPSvZ0DKUEjtKg@mail.gmail.com> <53120EE8.1080600@bakulin.de> <CAJ-VmonPkdVVq7nC3FdopcgzmSTsj3gTO=Cghx-62XS5K25YQg@mail.gmail.com> <5688F015.4090002@bakulin.de> <CAASDrVkHKzt4LKnLEFbwZ0gWRpwEOcpjaCFaOTg+s2DACebopA@mail.gmail.com> <E0EFD24D-B888-4025-AC41-C3D21E5536E9@bakulin.de> To: Ilya Bakulin <ilya@bakulin.de> X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>, <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>; List-Post: <mailto:freebsd-arm@freebsd.org> List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>, <mailto:freebsd-arm-request@freebsd.org?subject=subscribe> X-List-Received-Date: Thu, 11 Feb 2016 18:54:21 -0000 > On Feb 11, 2016, at 10:47 AM, Ilya Bakulin <ilya@bakulin.de> wrote: >=20 > I'll use an excellent opportunity to post a small status update about = my work :-) > * SDHC controller on Wandboard now works with the new stack; > * SDIO block read now works! > * camcontrol userland app is extended to support "mmcsdcmd" command = that allows to send MMC commands from userland apps directly to the card = via pass(4) device -- now we can write WLAN driver in userland :-D Great news, userspace drivers are the best!:) So what are the remaining pieces that prevent this work from hitting the = HEAD? -- Stanislav Sedov ST4096-RIPE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DD0089CC-19BF-4179-9A05-6B920B1DF7F9>