From owner-freebsd-embedded@FreeBSD.ORG Mon Oct 13 05:24:53 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 69117BC0; Mon, 13 Oct 2014 05:24:53 +0000 (UTC) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 23DA2D81; Mon, 13 Oct 2014 05:24:53 +0000 (UTC) Received: by mail-oi0-f51.google.com with SMTP id h136so12050714oig.38 for ; Sun, 12 Oct 2014 22:24:52 -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=Ie0enbV1ysSU/HpnrfpfRd5Y+nDGoR47eliYz6/mQ7E=; b=pAt8lk20HOrIQYCWbs4tVOgTYG6m9C09ObmX5Skaglox9DV2DccJh1MUOZU/hrs/tA MIdWjYuJCbT9H5gp2AQhR3AlryjPWOt28Oi+v6SG1hFHoZi9CVpH0HxrWtDwKOgOYOlm dfM9UWO6s60xrGDfm/pkrHmz8nBbUW9Su0fDCLYp+wgSIwEXkHlOfz1Nt+2HQ7ckvyw2 ypCegCHmS5KEqPt5WnifhJ6nan1M4+iwvoxx6YbGLCoExO9zxXs5ju3jSHe2Fr9qr/pI Uy7kRWb3Imd5NCm1KwhbcRDDGcanYbSoS7j1sbXaJzTVvPiilMH7qs/XcE7F5DloRqjf 0s7w== MIME-Version: 1.0 X-Received: by 10.202.196.214 with SMTP id u205mr5847391oif.48.1413177892130; Sun, 12 Oct 2014 22:24:52 -0700 (PDT) Received: by 10.60.118.196 with HTTP; Sun, 12 Oct 2014 22:24:52 -0700 (PDT) In-Reply-To: <20141006171521.GD26076@kib.kiev.ua> References: <20141006171521.GD26076@kib.kiev.ua> Date: Mon, 13 Oct 2014 02:24:52 -0300 Message-ID: Subject: Re: A few questions about SD/MMC drivers From: Martin Galvan To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Cc: freebsd-drivers@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 05:24:53 -0000 Hi again! I'm in the middle of implementing DMA support for the Allwinner driver, and I was surprised to see that BSD doesn't have a simple DMA API as Linux does. Namely, I didn't see anything like the scatterlists used in Linux. The host found in Allwinner SoCs uses a DMA controller which works with a linked list of descriptors, each having info on a data buffer. In the Linux driver they allocate a coherent DMA buffer using dma_alloc_coherent to get both the virtual and bus addresses of the descriptor list. When it's time to do a DMA transfer, the Linux driver allocates a scatterlist with each entry being a buffer corresponding to a descriptor; it then loops through the descriptor list setting the "buffer pointer" field of each one to the bus address of the corresponding scatterlist entry, and the "next descriptor" to the bus address of the following descriptor. It's pretty neat, though it's worth mentioning the scatterlist that the MMC request handler maps already contains the virtual addresses of the requested buffers. Do we have anything like that on BSD? If not, what would be a simple algorithm to make this work? Again, thanks a lot! From owner-freebsd-embedded@FreeBSD.ORG Mon Oct 13 14:21:42 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9327EC1B; Mon, 13 Oct 2014 14:21:42 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F01A0B13; Mon, 13 Oct 2014 14:21:41 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s9DELWlq051238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2014 17:21:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s9DELWlq051238 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s9DELWYi051237; Mon, 13 Oct 2014 17:21:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 13 Oct 2014 17:21:32 +0300 From: Konstantin Belousov To: Martin Galvan Subject: Re: A few questions about SD/MMC drivers Message-ID: <20141013142132.GN2153@kib.kiev.ua> References: <20141006171521.GD26076@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-drivers@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 14:21:42 -0000 On Mon, Oct 13, 2014 at 02:24:52AM -0300, Martin Galvan wrote: > Hi again! I'm in the middle of implementing DMA support for the > Allwinner driver, and I was surprised to see that BSD doesn't have a > simple DMA API as Linux does. Namely, I didn't see anything like the > scatterlists used in Linux. > > The host found in Allwinner SoCs uses a DMA controller which works > with a linked list of descriptors, each having info on a data buffer. > In the Linux driver they allocate a coherent DMA buffer using > dma_alloc_coherent to get both the virtual and bus addresses of the > descriptor list. When it's time to do a DMA transfer, the Linux driver > allocates a scatterlist with each entry being a buffer corresponding > to a descriptor; it then loops through the descriptor list setting the > "buffer pointer" field of each one to the bus address of the > corresponding scatterlist entry, and the "next descriptor" to the bus > address of the following descriptor. It's pretty neat, though it's > worth mentioning the scatterlist that the MMC request handler maps > already contains the virtual addresses of the requested buffers. > > Do we have anything like that on BSD? If not, what would be a simple > algorithm to make this work? I am not sure about the scope of your question. Are you aware of busdma(9) ? This is the KPI to use for DMA programming on *BSD, and it is typically enough for most hardware. If you do know about busdma(9) and do not consider it not suitable for the task, this is completely different situation, and you should describe why. From owner-freebsd-embedded@FreeBSD.ORG Mon Oct 13 14:57:35 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 16D725C8 for ; Mon, 13 Oct 2014 14:57:35 +0000 (UTC) Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D5D96E4B for ; Mon, 13 Oct 2014 14:57:34 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id p10so5813825pdj.1 for ; Mon, 13 Oct 2014 07:57:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=hThUuOmJBfqCnnFUFdGJ8k1qBQERv+rOtd6RBfsZdvE=; b=TbWnYfRp/TGLeIIN07RoSYgNin9S7uvMUeoEDaATWggrMnqJUHiA6zjnKY+Yopd+Sc Rd8LO7jFaFfGaib0Iuvj+yqGyDbfwDAO7sVhxmLBDH4H2qgLOfsw0lAD00cyM5ygFWyV poQkZXyHJe8bf5Nra08pix+njaFHFAfSSZ3dETFuGC2js91oURwzHmCZoxLT3+1M+vXS /JqsLhg5oizkSzdu7A8qTcgk9PwudQP9zhEp+tJaUQRenq/yh/pJcLJJGlNQNGYOLcgn TQxly+utYDt/oK8i8IKVc+0knJ5y1O9ObZmg//Syyl9j11yKeBEbwyjMdAlFzQbIVtWR jLmw== X-Gm-Message-State: ALoCoQlG+D6oFciRcMnAU5tErB5bCvUdebfYj5EXv7fCdF2bmvW3eyXJboD3MXWGEdERanRcHJCP X-Received: by 10.70.130.136 with SMTP id oe8mr24063394pdb.18.1413212248404; Mon, 13 Oct 2014 07:57:28 -0700 (PDT) Received: from [10.64.26.87] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id z13sm11417281pbt.74.2014.10.13.07.57.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 Oct 2014 07:57:27 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_5C375B95-34D5-468C-8AAB-B190D7984D7E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: A few questions about SD/MMC drivers From: Warner Losh In-Reply-To: Date: Mon, 13 Oct 2014 08:57:25 -0600 Message-Id: <0B7F1C7B-7E38-48FD-B3CF-A4512A45E4C0@bsdimp.com> References: <20141006171521.GD26076@kib.kiev.ua> To: Martin Galvan X-Mailer: Apple Mail (2.1878.6) Cc: Konstantin Belousov , freebsd-drivers@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 14:57:35 -0000 --Apple-Mail=_5C375B95-34D5-468C-8AAB-B190D7984D7E Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Oct 12, 2014, at 11:24 PM, Martin Galvan wrote: > Hi again! I'm in the middle of implementing DMA support for the > Allwinner driver, and I was surprised to see that BSD doesn't have a > simple DMA API as Linux does. Namely, I didn't see anything like the > scatterlists used in Linux. see busdma(8) for all your DMA needs. It also takes care of situations where bounce buffers are needed, returning properly aligned memory, etc. > The host found in Allwinner SoCs uses a DMA controller which works > with a linked list of descriptors, each having info on a data buffer. > In the Linux driver they allocate a coherent DMA buffer using > dma_alloc_coherent to get both the virtual and bus addresses of the > descriptor list. When it's time to do a DMA transfer, the Linux driver > allocates a scatterlist with each entry being a buffer corresponding > to a descriptor; it then loops through the descriptor list setting the > "buffer pointer" field of each one to the bus address of the > corresponding scatterlist entry, and the "next descriptor" to the bus > address of the following descriptor. It's pretty neat, though it's > worth mentioning the scatterlist that the MMC request handler maps > already contains the virtual addresses of the requested buffers. > > Do we have anything like that on BSD? If not, what would be a simple > algorithm to make this work? Pretty much all of that is covered in busdma(8). The mechanics are a bit different than Linux, sure, but all that functionality is there. Warner --Apple-Mail=_5C375B95-34D5-468C-8AAB-B190D7984D7E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUO+hVAAoJEGwc0Sh9sBEAxK8QAKrCbArDptS8Zd70zY3wah/L mmii/TgD2aOE/lcB1weJB57lK/2uyRD9EKUOXI4v/TN13mPcUQ9Fo8uaSHSxY8wg NVjiaCmvKHHwB9eQG12SbGnXbcc/ZwY5s8IU58wEC662OEkXShXyUfIOxc+hl1GJ wtIzjS1GQ33WfsgCjhYYMzOIgD04thAhomdrowzo+deWHD7QtOjsiPqn12+OhJdG QDjcSy1+0Z1TA4KtB7hvZR5uDBaSlksGabYzPfPY96yZnfK4ybJSkGRMmKLWpT69 NEgSJ19Fju8egG5tF04Oj2JMV7Retwff5nhA84YFaL0nswY1VxGsT9CdEmyAZq9N 1+l4cMxI01YS2fZRkYdFCzWYO5J42vMqPXoI7+iNfe2QUPIT5fp8XLJdkoyE8Jpo fLg9tGrI+yH8qQq5I31FHG//htSibgG9uUiX57UL6PbVixHANhmkiA3l77/1CpnD 896fs/Den3o1lUSk/eQEa4sJ9ioiyXuOhvykfU2Obpl7IoQ6KwFgLvBOmjgXdNs/ OMXre0F/w7RRFfZ0z8tfEbl7A1gEIox6+oQyTNUP62xit2hrrdizarqy7hPDHdye DGWmgcjLbMGhu3mmOyralyCguJifm+Tuvpr8c6EIFllQrjWcxvP41qalKB+hoM2p xJDJC03VUTUM01kD5GSl =dF3R -----END PGP SIGNATURE----- --Apple-Mail=_5C375B95-34D5-468C-8AAB-B190D7984D7E-- From owner-freebsd-embedded@FreeBSD.ORG Mon Oct 13 23:25:36 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96040593; Mon, 13 Oct 2014 23:25:36 +0000 (UTC) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5576EFD6; Mon, 13 Oct 2014 23:25:36 +0000 (UTC) Received: by mail-oi0-f49.google.com with SMTP id a3so14424594oib.8 for ; Mon, 13 Oct 2014 16:25:35 -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=0R+2P5F54HpR/to7EogwN75vk1D5W2Gquxuanq4K+XE=; b=lSHl6J9vyDiASkeMHfKi4tibdwQBu01LniS40mzT72/nrB5LAOFG4Ho1bAO0geiuCn rDK/1cwGe2qEHzppktXIM6RXmkPoeVMX46GosBQxNmHpECYHP4A0M5hlDMYM3f/Rir8c POTEJKg/pqWubaibxSv68RMcmoTcmvDvtBJkRrfzBXxz0Zdu/r42eF3n67Eo9K8BvFgb 859Bce3OSG+c2F987FVUkNVv0XpD7+3kR6XHMRsiUR1rypBeLsF6fy0xHGN4Nmap4NU5 aNGG/JKxJLapIfvdL0XrOjYGVavrAynVamKBvzzDcnyiByQAUzglnyapkJYN6fo8gvBn GTjA== MIME-Version: 1.0 X-Received: by 10.202.194.67 with SMTP id s64mr1308404oif.22.1413242735697; Mon, 13 Oct 2014 16:25:35 -0700 (PDT) Received: by 10.60.118.196 with HTTP; Mon, 13 Oct 2014 16:25:35 -0700 (PDT) In-Reply-To: <0B7F1C7B-7E38-48FD-B3CF-A4512A45E4C0@bsdimp.com> References: <20141006171521.GD26076@kib.kiev.ua> <0B7F1C7B-7E38-48FD-B3CF-A4512A45E4C0@bsdimp.com> Date: Mon, 13 Oct 2014 20:25:35 -0300 Message-ID: Subject: Re: A few questions about SD/MMC drivers From: Martin Galvan To: Warner Losh Content-Type: text/plain; charset=UTF-8 Cc: Konstantin Belousov , freebsd-drivers@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 23:25:36 -0000 2014-10-13 11:57 GMT-03:00 Warner Losh : > On Oct 12, 2014, at 11:24 PM, Martin Galvan wrote: >> The host found in Allwinner SoCs uses a DMA controller which works >> with a linked list of descriptors, each having info on a data buffer. >> In the Linux driver they allocate a coherent DMA buffer using >> dma_alloc_coherent to get both the virtual and bus addresses of the >> descriptor list. When it's time to do a DMA transfer, the Linux driver >> allocates a scatterlist with each entry being a buffer corresponding >> to a descriptor; it then loops through the descriptor list setting the >> "buffer pointer" field of each one to the bus address of the >> corresponding scatterlist entry, and the "next descriptor" to the bus >> address of the following descriptor. It's pretty neat, though it's >> worth mentioning the scatterlist that the MMC request handler maps >> already contains the virtual addresses of the requested buffers. >> >> Do we have anything like that on BSD? If not, what would be a simple >> algorithm to make this work? > > Pretty much all of that is covered in busdma(8). The mechanics are a bit > different than Linux, sure, but all that functionality is there. Actually, other than being able to alloc DMA buffers and get their bus addresses I didn't see anything like the Linux scatterlists. The main problem here is that the Linux mmc_data struct comes with an already-filled scatterlist. In that case, all I have to do is build the descriptor chain with the buffer addresses from the scatterlist entries. The only thing that's similar to that in the BSD API is mbuf_sg, which is used for network stuff. I didn't see anything that could allow me to build a descriptor chain-- all I saw was that the BSD mmc_data type has a buffer instead of a scatterlist. I'm thinking of telling the DMA controller to work with a single descriptor whose buffer is the one that comes inside mmc_data, but I'm not sure if this would be right. Again thanks a lot for your answers. From owner-freebsd-embedded@FreeBSD.ORG Mon Oct 13 23:41:23 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46721A2E; Mon, 13 Oct 2014 23:41:23 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1826F325; Mon, 13 Oct 2014 23:41:22 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XdpEu-0008oE-OR; Mon, 13 Oct 2014 23:41:20 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s9DNfJVK045407; Mon, 13 Oct 2014 17:41:19 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18fkrUclnmMr+S3aLX8nn1H X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: A few questions about SD/MMC drivers From: Ian Lepore To: Martin Galvan In-Reply-To: References: <20141006171521.GD26076@kib.kiev.ua> <0B7F1C7B-7E38-48FD-B3CF-A4512A45E4C0@bsdimp.com> Content-Type: text/plain; charset="us-ascii" Date: Mon, 13 Oct 2014 17:41:18 -0600 Message-ID: <1413243678.12052.376.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , freebsd-drivers@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 23:41:23 -0000 On Mon, 2014-10-13 at 20:25 -0300, Martin Galvan wrote: > 2014-10-13 11:57 GMT-03:00 Warner Losh : > > On Oct 12, 2014, at 11:24 PM, Martin Galvan wrote: > >> The host found in Allwinner SoCs uses a DMA controller which works > >> with a linked list of descriptors, each having info on a data buffer. > >> In the Linux driver they allocate a coherent DMA buffer using > >> dma_alloc_coherent to get both the virtual and bus addresses of the > >> descriptor list. When it's time to do a DMA transfer, the Linux driver > >> allocates a scatterlist with each entry being a buffer corresponding > >> to a descriptor; it then loops through the descriptor list setting the > >> "buffer pointer" field of each one to the bus address of the > >> corresponding scatterlist entry, and the "next descriptor" to the bus > >> address of the following descriptor. It's pretty neat, though it's > >> worth mentioning the scatterlist that the MMC request handler maps > >> already contains the virtual addresses of the requested buffers. > >> > >> Do we have anything like that on BSD? If not, what would be a simple > >> algorithm to make this work? > > > > Pretty much all of that is covered in busdma(8). The mechanics are a bit > > different than Linux, sure, but all that functionality is there. > > Actually, other than being able to alloc DMA buffers and get their bus > addresses I didn't see anything like the Linux scatterlists. > > The main problem here is that the Linux mmc_data struct comes with an > already-filled scatterlist. In that case, all I have to do is build > the descriptor chain with the buffer addresses from the scatterlist > entries. The only thing that's similar to that in the BSD API is > mbuf_sg, which is used for network stuff. I didn't see anything that > could allow me to build a descriptor chain-- all I saw was that the > BSD mmc_data type has a buffer instead of a scatterlist. > > I'm thinking of telling the DMA controller to work with a single > descriptor whose buffer is the one that comes inside mmc_data, but I'm > not sure if this would be right. > > Again thanks a lot for your answers. When you map the buffer with bus_dmamap_load() your callback function is passed an array of bus_dma_segment structures, each element of the array is the physical address and size of a contiguous physical segment that makes up part of the overall buffer. You are g'teed not to get more segments than the limit specified in the dma tag used for the map (but that just means the map function fails if there are too many segments, not that some sort of automatic copy/consolidate is done for you). In general you won't have a problem if you handle (512 * MAX_DATA + PAGE_SIZE - 1) / PAGE_SIZE segments (MAX_DATA is a horrible ivar name but I guess we're stuck with it now). If you need a linked list rather than an array of physical addr/size tuples, you'll have to write a callback function that creates the list from the array. -- Ian From owner-freebsd-embedded@FreeBSD.ORG Tue Oct 14 00:19:35 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E2BDE25A; Tue, 14 Oct 2014 00:19:35 +0000 (UTC) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 94A168E2; Tue, 14 Oct 2014 00:19:35 +0000 (UTC) Received: by mail-oi0-f46.google.com with SMTP id h136so14801957oig.33 for ; Mon, 13 Oct 2014 17:19:34 -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=pf7re/j17h8+BUnecOmsnAEO46Zh8eGhei3dlvg7CxI=; b=iHWu9QOkiuUgwYff/vEFbMDduMlnTC31eB/oLNrX2VPOON8gUPOsz6m67mAUWN6KSj TiaTnMOickPrJAaq2f2M3c4FMFNAcALoHMhtmLXQ7XhwVfQyqiGDsNMbnZIy0irJd+i2 cMt6GMzHnGlM+Z/Yt3grnHxkqfgWETJdQKI8P/Vg4GflNzHKDudZQiv33S7RxJZ7eS3n W23mEg8an5NQmGyvsR0/vja3TXyd6YOn49mHNJxLyDsjlqgwT1pf59hWVtkwQnvCpQe3 YdI/iNw+93rclnClPqaaZEE6AkH0GEuvU1+cuvU5H36lRTIz966l2LsQvGopUgW9v+Z9 T2Zw== MIME-Version: 1.0 X-Received: by 10.182.105.135 with SMTP id gm7mr1483230obb.3.1413245974918; Mon, 13 Oct 2014 17:19:34 -0700 (PDT) Received: by 10.60.118.196 with HTTP; Mon, 13 Oct 2014 17:19:34 -0700 (PDT) In-Reply-To: <1413243678.12052.376.camel@revolution.hippie.lan> References: <20141006171521.GD26076@kib.kiev.ua> <0B7F1C7B-7E38-48FD-B3CF-A4512A45E4C0@bsdimp.com> <1413243678.12052.376.camel@revolution.hippie.lan> Date: Mon, 13 Oct 2014 21:19:34 -0300 Message-ID: Subject: Re: A few questions about SD/MMC drivers From: Martin Galvan To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: Konstantin Belousov , freebsd-drivers@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 00:19:36 -0000 Well, that makes sense now. I'll try it out and let you know if it worked, thanks a ton! Just to be clear, though (and forgive me for my ignorance on this matter): is the "buffer" referenced in mmc_data always contiguous in memory? If so, why use segments/scatterlists at all? I thought the whole point of using descriptor lists in DMA transfers was to work with portions of memory that weren't next to each other. If the data we want to transfer is all in a single contiguous region, wouldn't a single descriptor with the required bus address and buffer length be enough? 2014-10-13 20:41 GMT-03:00 Ian Lepore : > On Mon, 2014-10-13 at 20:25 -0300, Martin Galvan wrote: >> 2014-10-13 11:57 GMT-03:00 Warner Losh : >> > On Oct 12, 2014, at 11:24 PM, Martin Galvan wrote: >> >> The host found in Allwinner SoCs uses a DMA controller which works >> >> with a linked list of descriptors, each having info on a data buffer. >> >> In the Linux driver they allocate a coherent DMA buffer using >> >> dma_alloc_coherent to get both the virtual and bus addresses of the >> >> descriptor list. When it's time to do a DMA transfer, the Linux driver >> >> allocates a scatterlist with each entry being a buffer corresponding >> >> to a descriptor; it then loops through the descriptor list setting the >> >> "buffer pointer" field of each one to the bus address of the >> >> corresponding scatterlist entry, and the "next descriptor" to the bus >> >> address of the following descriptor. It's pretty neat, though it's >> >> worth mentioning the scatterlist that the MMC request handler maps >> >> already contains the virtual addresses of the requested buffers. >> >> >> >> Do we have anything like that on BSD? If not, what would be a simple >> >> algorithm to make this work? >> > >> > Pretty much all of that is covered in busdma(8). The mechanics are a bit >> > different than Linux, sure, but all that functionality is there. >> >> Actually, other than being able to alloc DMA buffers and get their bus >> addresses I didn't see anything like the Linux scatterlists. >> >> The main problem here is that the Linux mmc_data struct comes with an >> already-filled scatterlist. In that case, all I have to do is build >> the descriptor chain with the buffer addresses from the scatterlist >> entries. The only thing that's similar to that in the BSD API is >> mbuf_sg, which is used for network stuff. I didn't see anything that >> could allow me to build a descriptor chain-- all I saw was that the >> BSD mmc_data type has a buffer instead of a scatterlist. >> >> I'm thinking of telling the DMA controller to work with a single >> descriptor whose buffer is the one that comes inside mmc_data, but I'm >> not sure if this would be right. >> >> Again thanks a lot for your answers. > > When you map the buffer with bus_dmamap_load() your callback function is > passed an array of bus_dma_segment structures, each element of the array > is the physical address and size of a contiguous physical segment that > makes up part of the overall buffer. You are g'teed not to get more > segments than the limit specified in the dma tag used for the map (but > that just means the map function fails if there are too many segments, > not that some sort of automatic copy/consolidate is done for you). In > general you won't have a problem if you handle (512 * MAX_DATA + > PAGE_SIZE - 1) / PAGE_SIZE segments (MAX_DATA is a horrible ivar name > but I guess we're stuck with it now). > > If you need a linked list rather than an array of physical addr/size > tuples, you'll have to write a callback function that creates the list > from the array. > > -- Ian > > From owner-freebsd-embedded@FreeBSD.ORG Tue Oct 14 00:28:34 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 13771358 for ; Tue, 14 Oct 2014 00:28:34 +0000 (UTC) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D000099F for ; Tue, 14 Oct 2014 00:28:33 +0000 (UTC) Received: by mail-pd0-f172.google.com with SMTP id ft15so6437844pdb.17 for ; Mon, 13 Oct 2014 17:28:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=p+UVolV+nM2NvT9Y521GxFjKDtagQgiDCDtL7pAuKEM=; b=FW9zE4WD3mRAdqNGV0R5oaKeJUoZUyQE/KV8FZhVgTjStD76+TSS9vHsjisZO6IVZB hqAQ2vrIycB0Aa9qlAu2hXeDZKsvDleWdEnGAbMFHqkmQ5A5OZR1/Lxi98BJzL3Xbc/+ +yshkiYCH5CRrYzc0MA5YX024+SFmm/3Yljq6aGe92hgDX47Ntxcjsm4BJwRERcj21iY ij4fZzbNcq+6iMgIjkj2ww/28beSiKRoYj5C2xjizB4LK2itMyoh0eCKSzd02inpobFB oFbCRD6W8UFwIyqi0Lunu5Pt4wuN9TkMKLvnAS4KdbMrmwQGIv8+b4O0KgMgMhHKnDMn 4+WQ== X-Gm-Message-State: ALoCoQlx8lDZfzpqvOAvLdoeQtL39gkbWlOKFvYvhB9Lp17ey4sQNcU3wiMxrpGf6G4haOOeHVEx X-Received: by 10.66.254.136 with SMTP id ai8mr1389031pad.76.1413246134465; Mon, 13 Oct 2014 17:22:14 -0700 (PDT) Received: from [10.64.26.87] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id ne9sm134636pbc.87.2014.10.13.17.22.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 Oct 2014 17:22:13 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_574CE74E-C0F1-494A-A67D-359860E4B1C7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: A few questions about SD/MMC drivers From: Warner Losh In-Reply-To: Date: Mon, 13 Oct 2014 18:22:10 -0600 Message-Id: References: <20141006171521.GD26076@kib.kiev.ua> <0B7F1C7B-7E38-48FD-B3CF-A4512A45E4C0@bsdimp.com> <1413243678.12052.376.camel@revolution.hippie.lan> To: Martin Galvan X-Mailer: Apple Mail (2.1878.6) Cc: Konstantin Belousov , freebsd-drivers@freebsd.org, Ian Lepore , freebsd-embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 00:28:34 -0000 --Apple-Mail=_574CE74E-C0F1-494A-A67D-359860E4B1C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The buffer is always contiguous in virtual space, but maybe not = necessarily in physical space, hence the need for SG list. For buffers smaller than = one page, the difference doesn=92t matter :) But with multi-block support, = you=92ll need to cope with the difference. Warner On Oct 13, 2014, at 6:19 PM, Martin Galvan = wrote: > Well, that makes sense now. I'll try it out and let you know if it > worked, thanks a ton! >=20 > Just to be clear, though (and forgive me for my ignorance on this > matter): is the "buffer" referenced in mmc_data always contiguous in > memory? If so, why use segments/scatterlists at all? I thought the > whole point of using descriptor lists in DMA transfers was to work > with portions of memory that weren't next to each other. If the data > we want to transfer is all in a single contiguous region, wouldn't a > single descriptor with the required bus address and buffer length be > enough? >=20 > 2014-10-13 20:41 GMT-03:00 Ian Lepore : >> On Mon, 2014-10-13 at 20:25 -0300, Martin Galvan wrote: >>> 2014-10-13 11:57 GMT-03:00 Warner Losh : >>>> On Oct 12, 2014, at 11:24 PM, Martin Galvan = wrote: >>>>> The host found in Allwinner SoCs uses a DMA controller which works >>>>> with a linked list of descriptors, each having info on a data = buffer. >>>>> In the Linux driver they allocate a coherent DMA buffer using >>>>> dma_alloc_coherent to get both the virtual and bus addresses of = the >>>>> descriptor list. When it's time to do a DMA transfer, the Linux = driver >>>>> allocates a scatterlist with each entry being a buffer = corresponding >>>>> to a descriptor; it then loops through the descriptor list setting = the >>>>> "buffer pointer" field of each one to the bus address of the >>>>> corresponding scatterlist entry, and the "next descriptor" to the = bus >>>>> address of the following descriptor. It's pretty neat, though it's >>>>> worth mentioning the scatterlist that the MMC request handler maps >>>>> already contains the virtual addresses of the requested buffers. >>>>>=20 >>>>> Do we have anything like that on BSD? If not, what would be a = simple >>>>> algorithm to make this work? >>>>=20 >>>> Pretty much all of that is covered in busdma(8). The mechanics are = a bit >>>> different than Linux, sure, but all that functionality is there. >>>=20 >>> Actually, other than being able to alloc DMA buffers and get their = bus >>> addresses I didn't see anything like the Linux scatterlists. >>>=20 >>> The main problem here is that the Linux mmc_data struct comes with = an >>> already-filled scatterlist. In that case, all I have to do is build >>> the descriptor chain with the buffer addresses from the scatterlist >>> entries. The only thing that's similar to that in the BSD API is >>> mbuf_sg, which is used for network stuff. I didn't see anything that >>> could allow me to build a descriptor chain-- all I saw was that the >>> BSD mmc_data type has a buffer instead of a scatterlist. >>>=20 >>> I'm thinking of telling the DMA controller to work with a single >>> descriptor whose buffer is the one that comes inside mmc_data, but = I'm >>> not sure if this would be right. >>>=20 >>> Again thanks a lot for your answers. >>=20 >> When you map the buffer with bus_dmamap_load() your callback function = is >> passed an array of bus_dma_segment structures, each element of the = array >> is the physical address and size of a contiguous physical segment = that >> makes up part of the overall buffer. You are g'teed not to get more >> segments than the limit specified in the dma tag used for the map = (but >> that just means the map function fails if there are too many = segments, >> not that some sort of automatic copy/consolidate is done for you). = In >> general you won't have a problem if you handle (512 * MAX_DATA + >> PAGE_SIZE - 1) / PAGE_SIZE segments (MAX_DATA is a horrible ivar name >> but I guess we're stuck with it now). >>=20 >> If you need a linked list rather than an array of physical addr/size >> tuples, you'll have to write a callback function that creates the = list >> from the array. >>=20 >> -- Ian >>=20 >>=20 --Apple-Mail=_574CE74E-C0F1-494A-A67D-359860E4B1C7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUPGyyAAoJEGwc0Sh9sBEAuQEQALg1smhHq8LbE8b+SOrzhsKP qPjakDbn8lUk+hF8k7dXEoqNrPzFmLNt7OSXX1GI5CgiAYsUrZAjNeJJc3xpaUoQ g4q6EHpNhJCcJlc9NgiJXTRCQh1NeKdt4BHl4C0eIP0CqKywI5EMTBqMl4RW6yjG vSDaKu66FD5YfHkpi0m1R0eWOVExDSv6W5r/s7BeJAGG/mrOPRFO2RQKwbSIQl2a X7NCTsAYOGklrqZ0MaEhWfvLfZ5YnBL0eZrmjUOxidkyNXN/yp9qaKqGXlsdBp7C trpGgXsHeIl3DdWS17wzm4xjg0owbIOyMFgr7NixOxR2I/IDlpcMEHXxhCdQcXZT 3p+ScbFHI/XlF2yAK+v9NnQGDlinw74LKYD5HiXEkzLGtgTI6SlN8WlA6fjY3bNU BLEDyFDuvH4lzsdITknxwLmUGI7rmXRXzDMRq0Z2lXHpI99mJdO4KCt8dXXXs+9J M9xU28C+hJ/wJYF8zqjleN91LH6a4cPhk0KKD9c76JLyPYun6zPC2dEZpCOOAeSi 1Q6dQCIqMei3fmE15NQA48BEKPX66JleDF51oCyYdFoUhXJjCYPzERMSmsWZs8/r CEjEQkAssaoqD5Qmg7ackCsAhbjqU/WLQ7X5iu0FIJwk53nU1FU1Jbnp0LR0/oIu D7hqPzufhWAQcmIm8P1v =r/BK -----END PGP SIGNATURE----- --Apple-Mail=_574CE74E-C0F1-494A-A67D-359860E4B1C7-- From owner-freebsd-embedded@FreeBSD.ORG Tue Oct 14 20:52:14 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 91193FDF; Tue, 14 Oct 2014 20:52:14 +0000 (UTC) Received: from keltia.net (cl-90.mrs-01.fr.sixxs.net [IPv6:2a01:240:fe00:59::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2137F3DF; Tue, 14 Oct 2014 20:52:13 +0000 (UTC) Received: from lonrach.local (foret.keltia.net [78.232.116.160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix) with ESMTPSA id 7637852A9; Tue, 14 Oct 2014 22:52:10 +0200 (CEST) Date: Tue, 14 Oct 2014 22:52:03 +0200 From: Ollivier Robert To: freebsd-arm@freebsd.org Subject: Online.net new offer featuring ARMv7 based servers [LONG] Message-ID: <20141014205203.GA78703@lonrach.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: MacOS X / MBP 4,1 - FreeBSD 8.0 / T3500-E5520 Nehalem User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 20:52:14 -0000 [not subscribed to -embedded please keep in Cc] Hello, My main hosting company here in France (online.net) just started a new "cloud" offer, based on ARMv7 machines. They are running Marvell Armada XP SOC with 4 cores (MV78460). They are currently supporting only Ubuntu & Gentoo on these machines so I have offered to see how hard it would be to put FreeBSD there. I have access to the support forums and have found a small thread about BSD support with things line that: -=-=- Concerning the support of other OSs there are two BSDs (net & free) that have partial support of the SoC. Booting on the SoC might be possible at the moment, but there are some features that are still missing to have network. The design of the hardware requires support of integrated GiE interface and MDIO bus support/PHY Emulation (called fixed-phy in linux) to be able to have network. Also an equivalent of a linux "device tree" description has to be created. Related information : - http://blog.netbsd.org/tnf/entry/support_for_marvell_armada_xp - https://www.freebsd.org/news/status/report-2011-10-2011-12.html#FreeBSD/arm-on-Marvell-Armada-XP - https://origin-www.marvell.com/embedded-processors/armada-xp/1 (MV78460) -=-=- and this -=-=- We only support the linux kernel for now If you have any recommendations/links about running BSD on custom hardware with arm architecture, your help will be greatly appreciated Today, you can only boot your instance using NBD, but you can imagine to: - boot a linux server on a NBD volume - install a NFS/iSCSI/Samba/S3/TFTP server - export a volume/disk/... - (bonus: you can do raid, encryption, compression) - boot a new server on the exported NFS/iSCSI root volume It is unoptimized, and gives you constraints (i.e. to have the ISCSI host's ip in your boot cmdline) to boot your new servers, but it lets you bypass current limitations We are currently focused on getting a solution for the most common needs: recent kernel, working modules, standard public distributions; But we are also interested about other needs and appreciate help from experts -=-=- A few other things I gathered: - We do not have I believe any "nbd" driver (apparently what goes as "disks" around here). - they use uboot for booting - they want to know whether we have an equivalent to "initrd" which is IIRC the ramdisk-based boot linux has. They use initrd to mount volumes from the nas (and IP/port change with each reboot). - console is through a 9000 bauds serial port More detailed information there: http://philippe.lewin.me/2014/10/14/benchs-specs-online-cloud-preview/ Prices are not yet fixed and they will not start charging till 2 or 3 weeks. Even then, there might be some possibilities that I could keep some machines for free (I'll see about that). In any case, I can get a few of these machines and make them available to anyone interested and server as intermediary. Anyone? They have sent me by mail one of the files (so called c1.dts) (see below) c1.dts (headers in https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts?id=refs/tags /v3.17). -=-=- /* * Device Tree file for Marvell Armada XP evaluation board * (DB-78460-BP) * * Copyright (C) 2012 Marvell * * Lior Amsalem * Gregory CLEMENT * Thomas Petazzoni * * This file is licensed under the terms of the GNU General Public * License version 2. This program is licensed "as is" without any * warranty of any kind, whether express or implied. */ /dts-v1/; #include "armada-xp-mv78460.dtsi" / { model = "C1 Online Computing"; compatible = "marvell,axp-db", "marvell,armadaxp-mv78460", "marvell,armadaxp", "marvell,armada-370-xp"; chosen { bootargs = "console=ttyS0,9600 earlyprintk"; }; memory { device_type = "memory"; reg = <0 0x00000000 0 0x80000000>; /* 2 GB */ }; soc { ranges = ; devbus-bootcs { status = "okay"; /* Device Bus parameters are required */ /* Read parameters */ devbus,bus-width = <16>; devbus,turn-off-ps = <60000>; devbus,badr-skew-ps = <0>; devbus,acc-first-ps = <124000>; devbus,acc-next-ps = <248000>; devbus,rd-setup-ps = <0>; devbus,rd-hold-ps = <0>; /* Write parameters */ devbus,sync-enable = <0>; devbus,wr-high-ps = <60000>; devbus,wr-low-ps = <60000>; devbus,ale-wr-ps = <60000>; }; internal-regs { uart0: serial@12000 { status = "okay"; }; eth0: ethernet@70000 { status = "okay"; fixed-link = <1 1 1000 0 0>; phy-mode = "sgmii"; }; mvsdio@d4000 { pinctrl-0 = <&sdio_pins>; pinctrl-names = "default"; status = "okay"; /* No CD or WP GPIOs */ broken-cd; }; }; }; aliases { ethernet0 = ð0; serial0 = &uart0; }; };-=-=- -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From owner-freebsd-embedded@FreeBSD.ORG Tue Oct 14 21:44:14 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F76BD94; Tue, 14 Oct 2014 21:44:14 +0000 (UTC) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CBA06B88; Tue, 14 Oct 2014 21:44:13 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id d1so294372wiv.6 for ; Tue, 14 Oct 2014 14:44:12 -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:content-transfer-encoding; bh=6thxyPWuvrnGGKRxjNilduoNUq0IlsNYmQSwAWFgWI0=; b=RMxZPEDfdxi+OuA3wUlz2brQZBU1hrIemdkWjlsM/DHk6lW/2nnK3CxMUQWyiXhcED mOkZ7y30zdAyvfavzo7UeIPTPFwXAMFvDt/Ac0wgGe8fMnhDsXTrhPzob3BciAiLJTPR VEyF+XtlbSp6JW9X7p2lmPghOKYYjqVesHjXI34MOZgTmGDoceLqFxV8HWKgEq7+cEJh +FY/lAigAYtYrPaWX6rDgB3GSrCMD4CrNZx+2jwhV/atBPHW1wNaN+V+M8VMe2aQYTWg hgK+89bsBMJBaW0/oQCjtv6pUAMiMhynJ8BuYgSC2HJtJnfHH4BPuhe5UYqufytAqm+g enXg== MIME-Version: 1.0 X-Received: by 10.180.78.100 with SMTP id a4mr7760179wix.23.1413323051991; Tue, 14 Oct 2014 14:44:11 -0700 (PDT) Sender: zbodek@gmail.com Received: by 10.216.123.1 with HTTP; Tue, 14 Oct 2014 14:44:11 -0700 (PDT) In-Reply-To: <20141014205203.GA78703@lonrach.local> References: <20141014205203.GA78703@lonrach.local> Date: Tue, 14 Oct 2014 23:44:11 +0200 X-Google-Sender-Auth: wxtTxpdiqLKCokrp6m8ey3ddfFA Message-ID: Subject: Re: Online.net new offer featuring ARMv7 based servers [LONG] From: Zbigniew Bodek To: Ollivier Robert Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-arm@freebsd.org" , "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 21:44:14 -0000 Hello Ollivier, There is a working support for Armada XP in FreeBSD. You can boot the DB board in SMP although (afaik) there may be some problems with SMP on GP boards with different u-boot versions. Kernel works stable but the peripheral interfaces support and power-management looks poor in comparison to Linux (also we have no LPAE support for ARM so no more than ~4GB of memory). Most common interfaces like SATA, USB or PCIe work OK but as you wrote - there is no networking support. Networking interface works on NetBSD, however I have no idea how efficient is it there. AXP's network is not exactly the simplest one so even with NBSD reference I don't expect it to be a trivial copy-paste port to FreeBSD. Also, there is FDT support in FreeBSD but the DTS file is different for FreeBSD and Linux (you can check out sys/boot/fdt/dts/arm/db78460.dts). In theory Linux DTS file will not work with our kernel but with very little work one can tune FreeBSD's DTS as desired (I know that this isn't exactly how FDT should work since DTS is supposed to be OS-independent). I hope that you find these information useful. Please notice that AXP has received much more effort and engineering work on Linux than on FreeBSD so someone would need to focus on FreeBSD now to reduce the distance between those two. Best regards zbb 2014-10-14 22:52 GMT+02:00 Ollivier Robert : > [not subscribed to -embedded please keep in Cc] > > Hello, > > My main hosting company here in France (online.net) just started a new "c= loud" offer, based on ARMv7 machines. They are running Marvell Armada XP S= OC with 4 cores (MV78460). They are currently supporting only Ubuntu & Gen= too on these machines so I have offered to see how hard it would be to put = FreeBSD there. > > I have access to the support forums and have found a small thread about B= SD support with things line that: > > -=3D-=3D- > Concerning the support of other OSs there are two BSDs (net & free) that = have partial support of the SoC. Booting on the SoC might be possible at th= e moment, but there are some features that are still missing to have networ= k. > > The design of the hardware requires support of integrated GiE interface a= nd MDIO bus support/PHY Emulation (called fixed-phy in linux) to be able to= have network. Also an equivalent of a linux "device tree" description has = to be created. > > Related information : > - http://blog.netbsd.org/tnf/entry/support_for_marvell_armada_xp > - https://www.freebsd.org/news/status/report-2011-10-2011-12.html#FreeBSD= /arm-on-Marvell-Armada-XP > - https://origin-www.marvell.com/embedded-processors/armada-xp/1 (MV78460= ) > -=3D-=3D- > > and this > > -=3D-=3D- > We only support the linux kernel for now > If you have any recommendations/links about running BSD on custom hardwar= e with arm architecture, your help will be greatly appreciated > > Today, you can only boot your instance using NBD, but you can imagine to: > - boot a linux server on a NBD volume > - install a NFS/iSCSI/Samba/S3/TFTP server > - export a volume/disk/... > - (bonus: you can do raid, encryption, compression) > - boot a new server on the exported NFS/iSCSI root volume > > It is unoptimized, and gives you constraints (i.e. to have the ISCSI host= 's ip in your boot cmdline) to boot your new servers, but it lets you bypas= s current limitations > > We are currently focused on getting a solution for the most common needs:= recent kernel, working modules, standard public distributions; But we are = also interested about other needs and appreciate help from experts > -=3D-=3D- > > A few other things I gathered: > > - We do not have I believe any "nbd" driver (apparently what goes as "dis= ks" around here). > - they use uboot for booting > - they want to know whether we have an equivalent to "initrd" which is II= RC the ramdisk-based boot linux has. They use initrd to mount volumes from= the nas (and IP/port change with each reboot). > - console is through a 9000 bauds serial port > > More detailed information there: > http://philippe.lewin.me/2014/10/14/benchs-specs-online-cloud-preview/ > > Prices are not yet fixed and they will not start charging till 2 or 3 wee= ks. Even then, there might be some possibilities that I could keep some ma= chines for free (I'll see about that). > > In any case, I can get a few of these machines and make them available to= anyone interested and server as intermediary. > > Anyone? > > They have sent me by mail one of the files (so called c1.dts) (see below) > > c1.dts (headers in https://git.kernel.org/cgit/linux/kernel/git/torvalds/= linux.git/tree/arch/arm/boot/dts?id=3Drefs/tags > /v3.17). > > -=3D-=3D- > /* > * Device Tree file for Marvell Armada XP evaluation board > * (DB-78460-BP) > * > * Copyright (C) 2012 Marvell > * > * Lior Amsalem > * Gregory CLEMENT > * Thomas Petazzoni > * > * This file is licensed under the terms of the GNU General Public > * License version 2. This program is licensed "as is" without any > * warranty of any kind, whether express or implied. > */ > > /dts-v1/; > #include "armada-xp-mv78460.dtsi" > > / { > model =3D "C1 Online Computing"; > compatible =3D "marvell,axp-db", "marvell,armadaxp-mv78460", "mar= vell,armadaxp", "marvell,armada-370-xp"; > > chosen { > bootargs =3D "console=3DttyS0,9600 earlyprintk"; > }; > > memory { > device_type =3D "memory"; > reg =3D <0 0x00000000 0 0x80000000>; /* 2 GB */ > }; > > soc { > ranges =3D MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000 > MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000>; > > devbus-bootcs { > status =3D "okay"; > > /* Device Bus parameters are required */ > > /* Read parameters */ > devbus,bus-width =3D <16>; > devbus,turn-off-ps =3D <60000>; > devbus,badr-skew-ps =3D <0>; > devbus,acc-first-ps =3D <124000>; > devbus,acc-next-ps =3D <248000>; > devbus,rd-setup-ps =3D <0>; > devbus,rd-hold-ps =3D <0>; > > /* Write parameters */ > devbus,sync-enable =3D <0>; > devbus,wr-high-ps =3D <60000>; > devbus,wr-low-ps =3D <60000>; > devbus,ale-wr-ps =3D <60000>; > > }; > > internal-regs { > uart0: serial@12000 { > status =3D "okay"; > }; > > eth0: ethernet@70000 { > status =3D "okay"; > fixed-link =3D <1 1 1000 0 0>; > phy-mode =3D "sgmii"; > }; > > mvsdio@d4000 { > pinctrl-0 =3D <&sdio_pins>; > pinctrl-names =3D "default"; > status =3D "okay"; > /* No CD or WP GPIOs */ > broken-cd; > }; > > }; > }; > aliases { > ethernet0 =3D ð0; > serial0 =3D &uart0; > }; > };-=3D-=3D- > > > -- > Ollivier ROBERT -=3D- FreeBSD: The Power to Serve! -=3D- roberto@keltia.f= reenix.fr > In memoriam to Ondine : http://ondine.keltia.net/ > _______________________________________________ > freebsd-embedded@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-embedded > To unsubscribe, send any mail to "freebsd-embedded-unsubscribe@freebsd.or= g" From owner-freebsd-embedded@FreeBSD.ORG Wed Oct 15 02:03:36 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F3C899EA for ; Wed, 15 Oct 2014 02:03:35 +0000 (UTC) Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BF9D0897 for ; Wed, 15 Oct 2014 02:03:35 +0000 (UTC) Received: by mail-pd0-f182.google.com with SMTP id y10so322689pdj.27 for ; Tue, 14 Oct 2014 19:03:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=wuwrglzphPuCpGeXyB8524ZTx8grx2pyg90wHfb3VDI=; b=GZHHug+F54D3CZXgi7Yq/kDsgT8o5HlHTpIad+afZMuJsiZ3l3dHa2Iet3noYEiPav zySMKxou6e4anGAOkSL2CnX8w3rryEZHY3LA/MdFIBHcp1hhtNvJRyOvgxpsCkItzByo NElhCxYqStOrV6ixWyiKYvbYcosRQJx9L3DmKwjdml31IsL+nn7r1D8GVcCsZ+bGbmUy S2vZehwiOopWybYKpGU3eMgt6wKZxcfHaEt7uRgV1s9jyYZE2ZMK2u9y0v6U/7h9hfd4 LNXJr9SiEciz4GBWzzmHtjymaHNo0cwyRlJ8P1POUwKC1NV6iIA4LtKG3ioBmIK7wHTz pqcA== X-Gm-Message-State: ALoCoQnJHOUj3zsOBOF/9m2RF4TQ9toJ6T3Hk29zTXw6qZ0/IFkb1m31/wtfLd/metUeklFRTm29 X-Received: by 10.70.65.37 with SMTP id u5mr9167836pds.93.1413338160050; Tue, 14 Oct 2014 18:56:00 -0700 (PDT) Received: from [10.64.26.87] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id gz1sm15438703pbb.8.2014.10.14.18.55.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 14 Oct 2014 18:55:59 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_9C2397BB-9D3F-462C-8ABF-2408CD299D9F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Online.net new offer featuring ARMv7 based servers [LONG] From: Warner Losh In-Reply-To: Date: Tue, 14 Oct 2014 19:55:56 -0600 Message-Id: References: <20141014205203.GA78703@lonrach.local> To: Zbigniew Bodek X-Mailer: Apple Mail (2.1878.6) Cc: Ollivier Robert , "freebsd-arm@freebsd.org" , "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 02:03:36 -0000 --Apple-Mail=_9C2397BB-9D3F-462C-8ABF-2408CD299D9F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 14, 2014, at 3:44 PM, Zbigniew Bodek wrote: > Also, there is FDT support in FreeBSD but the DTS file is different > for FreeBSD and Linux (you can check out > sys/boot/fdt/dts/arm/db78460.dts). In theory Linux DTS file will not > work with our kernel but with very little work one can tune FreeBSD's > DTS as desired (I know that this isn't exactly how FDT should work > since DTS is supposed to be OS-independent). The ideal we=92re striving for is to be able to use unmodified vendor = DTS files. We=92re not there yet, and there=92s some issues that need to be = overcome in specific cases before we will be there. If you or anybody else is = doing work in this area, please consider improving the compatibility. We=92ll = gain more in the long run, imho. Warner --Apple-Mail=_9C2397BB-9D3F-462C-8ABF-2408CD299D9F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUPdQsAAoJEGwc0Sh9sBEABI0QAIsbYDWixXI2+pgDAfyQhFF/ C7WjH33mmTXuEviGRwy7JrKmJsSi9TKFQXFfL1PcZEC/zV2K2STdmaXp6iYPA4wV 2LI/Kt6vHu8Du0QCI95IxU6CyvmeBwX25CyF4V+0esSknwcndTV92f5t5FjcZUgI yscO8YA9+nLA9lBYfa+4UJAQBk3MUhwJYo8wzeerS1+1g5HdUacqWkbTtA7ovf29 AxI/ULGd9nZyibVGPS6mpjOuUqjj043jxGjKShN7VPj7RsjuID1Fua060BIkI2iK b7rrcevrfAfCji8HhUE2lByNSF8VGmG5OMp6wT/sCFROrAAkC7F6TByxeUvHTDgm u8ve2aq8Ew1LE1Z22hHKDyKwPIjWGJcjz8nqtQV84uSrEflzhMm7UwaisihhT8mX DOMl/sQSCZQ6d1TT6B/AINDGGRdNarOZN8wNPpxhmAr/dWRcZwfc99Xzeeg3m2nP 5wvW/h8s+CF6Y9J75DKWynbWkIzbFMDCMKx1fC/eJegeZYZ9QNjPyzcoG6AdFG7B oCU/Wk0ZdwrRpvxmlJbm8U/u6kNxcav063FlSqscTiBWFDmUN2p+geayP1LAic/9 IjX2gU+2ide4LmNg8dUC9V6ex0Y9PJgXSydIo9aC2iMWOgaK99/keoJooJbZRcvW fIDn1ZUddGUTBwQzRqo9 =Csh+ -----END PGP SIGNATURE----- --Apple-Mail=_9C2397BB-9D3F-462C-8ABF-2408CD299D9F-- From owner-freebsd-embedded@FreeBSD.ORG Wed Oct 15 10:11:54 2014 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7A2E81B4; Wed, 15 Oct 2014 10:11:54 +0000 (UTC) Received: from keltia.net (cl-90.mrs-01.fr.sixxs.net [IPv6:2a01:240:fe00:59::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 38848E72; Wed, 15 Oct 2014 10:11:53 +0000 (UTC) Received: from lonrach.local (foret.keltia.net [78.232.116.160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix) with ESMTPSA id CBFF0529E; Wed, 15 Oct 2014 12:11:50 +0200 (CEST) Date: Wed, 15 Oct 2014 12:11:49 +0200 From: Ollivier Robert To: Warner Losh Subject: Re: Online.net new offer featuring ARMv7 based servers [LONG] Message-ID: <20141015101148.GB78787@lonrach.local> References: <20141014205203.GA78703@lonrach.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: MacOS X / MBP 4,1 - FreeBSD 8.0 / T3500-E5520 Nehalem User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-arm@freebsd.org" , "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 10:11:54 -0000 According to Warner Losh: > The ideal we’re striving for is to be able to use unmodified vendor DTS > files. We’re not there yet, and there’s some issues that need to be overcome > in specific cases before we will be there. If you or anybody else is doing > work in this area, please consider improving the compatibility. We’ll gain > more in the long run, imho. The thing is that I know next to nothing with respect to ARM stuff. I can make machines available through online.net incl. serial console access and do liaison with them though. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/