From owner-freebsd-embedded@freebsd.org Thu Dec 22 21:15:53 2016 Return-Path: Delivered-To: freebsd-embedded@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 4F7BCC8DD42 for ; Thu, 22 Dec 2016 21:15:53 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AC8ED1D87 for ; Thu, 22 Dec 2016 21:15:52 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.walstatt.dynvpn.de ([92.225.37.90]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MJBRC-1cIWp53mtG-002ll6 for ; Thu, 22 Dec 2016 22:15:49 +0100 Date: Thu, 22 Dec 2016 22:15:38 +0100 From: "O. Hartmann" To: =?ISO-8859-1?Q?=3FFreeBSD?= Embedded Mailing =?ISO-8859-1?Q?List=3F?= Subject: FreeBSD 12-CURRENT and ODROID-C2? Message-ID: <20161222221538.00402db7@thor.walstatt.dynvpn.de> In-Reply-To: <9424D7FD-C4B6-43D5-A0C5-76D5BE9ED1DE@ip-knowhow.com> References: <9424D7FD-C4B6-43D5-A0C5-76D5BE9ED1DE@ip-knowhow.com> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/qtQK4jJ3Rgff6RlOS1SVPkg"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:s57wpi4vaBkxI+GsD4luNcis8VFjXzsHtolIIV80ofCl0axyEwt bAjKMxf3uwiKvd3yAuHFpIcgfyetI1Z+u+8bG++p1B2juTcDYl6+txJkAZS3ko8Pk0w6azs HeoS0f/dafCuEyEUKpkzZJXj2RHJlMyDlDYjLpPc32Z0KELsQY9igY4WRXztGkWCFfa1YJZ SGPSUDg6vzNGtBkcZ6b3A== X-UI-Out-Filterresults: notjunk:1;V01:K0:zpAiJ8WXQRI=:GSJarcjpqKdQWcQlm7cz4x dhfU3n4NMfA8W3Kf2+CanqS0Q115yO1+KxYj7HBBQQuEjmCyvpIhPrmlJRJkZ89IqYPAkhzr4 Qn/E231ubbvFnYTNJakNOwY/EteyrlAbbv85nRBuLCqNpQ/KaNZscjJdI8C9UiGc0hqBNEUFt ETH7jPjjjv3EDI0WvsNbNzDteQ2/UsJChmhT533F5d0FAfiQXtgOfNLZ5kwyPVcpoPlldDaj2 GD8sKdqgQ6NZCWQIEKbqOg9SaYVAfh+UCO2v7PeixGcXojxC3xeFbh2ClFIJjuYeymxwyngK1 vO+cSNPXSjPxa2Yp9KLoqYhbw6J1qY9VzWDuox5EoN30whhos+AnfEgZZnq8qqCGdBjE8m6As 0PY2whwl1V4u58tGsXuDrEgRR1HszlAff/6JdYmYAT+6P/RuD8zgF8Jb8sOPLslTMtr7Sxg/h hRmIxylq6UC0je6H9Xr0sJVC1843yCM+5k1RG6kZ+eAFrQohvwJ5wN4oBMxqHReBnDOKxwv6H McnB1/KxBSORvNRBrTcfWWSyLC91C2SF7mh1vuDXtm2AiY6D6ldQqRimAvegUGenRVyw2CC+C ObTVVU/3SWh5UDDAZW2gB+DzlU+Zk90sDQcK8sTjehglEe6hLxlPAXuH8iPUphMJ13v7G9Tho sF7lYTtDODUqm8EEzMR31Z0e3SXf/yqb3qvKCRK5mUrrrsbtl7+eEcIhov+aEXTwVydO9fArh MN8fcKG8sCDHMmFu86eJiID1/8XHR4yKwA3A0f52yg/MLB1tcr2e8TcZA0w= X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 21:15:53 -0000 --Sig_/qtQK4jJ3Rgff6RlOS1SVPkg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I just got an ODROID-C2 SoC, an ARM v8 based AARCH64 architecture based upo= n the Cortex A53 CPU. I try to boot off the most recent AARCH64 image found at www.freeb= sd.org, FreeBSD-12.0-CURRENT-arm64-aarch64-20161130-r309302-memstick.img. I tried to dd this image to an SD card and did the same to an USB flash. Bu= t both won't boot off. I found some notes about this specific ARM SoC, but it seemed that there is= works in progress and the image is capable of booting off. Well, I tried the image just from scratch and was wondering whether FreeBSD= 12-CURRENT is at all capable of running on Odroid-c2 hardware. I have some smaller projects running with NanoBSD (GPT/UEFI as well as MBR = based, but all amd64) and I was wondering if there isn't a way to have a customized image = booting the Odroid-c2. It would be nice if someone could shed some light on this. Thank you in advance, Oliver --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/qtQK4jJ3Rgff6RlOS1SVPkg Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLQEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWFxCegAKCRDS528fyFhY lMNfAfjpVo/DshMglHaHq6lLthCDFhDpTmu9kKWBTOe0jQfCFC3TQY1YAOHu0po4 WkE2YLFlvQ/JQm5m+AOJajXBb9oB/it7pCRM7vhxHQs/lUOA+xvceXuBh7r+SpUu MgO7z01lr2jycxO1Q1p9zW7MnMEcGD7u1nZLxBKDbSusJ5zBzfE= =djwy -----END PGP SIGNATURE----- --Sig_/qtQK4jJ3Rgff6RlOS1SVPkg-- From owner-freebsd-embedded@freebsd.org Fri Dec 23 10:29:03 2016 Return-Path: Delivered-To: freebsd-embedded@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 AD08AC8D2B8 for ; Fri, 23 Dec 2016 10:29:03 +0000 (UTC) (envelope-from sfauction@comcast.net) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "resqmta-po-01v.sys.comcast.net", Issuer "COMODO RSA Organization Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7B10D1D5 for ; Fri, 23 Dec 2016 10:29:03 +0000 (UTC) (envelope-from sfauction@comcast.net) Received: from resomta-po-17v.sys.comcast.net ([96.114.154.241]) by resqmta-po-12v.sys.comcast.net with SMTP id KN5xc8ePdn2TRKN5xcJ7TU; Fri, 23 Dec 2016 10:29:01 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1482488941; bh=cilgDwRidFoljr1uKYpEG9glrYiooBFRcX9/Dl9X3dc=; h=Received:Received:From:To:Subject:Date:Message-ID:Content-Type; b=O5QKlzZ4BmIBOUDRKm2LQ/+lB/aVibFu84W7h4jPeynSiWXOek0O13YdXI2TW+p9F DeodIBUM2OZ7ZoP3KhA6pRXSPJaDgvtseyTSop7imo0skcMpkkMoOQCiaGbKLoset/ sADydfMyChDhGIhBI11XCiSX980EyIhM95anku7Qfq6h+/J8MRAJCq1Upn4C5GUvPY ny2NCb2twZwLPGw/jYobo4dgTRAVT3DTJuR5bJ9mrFqXueNm2ElPa51xGWY1iUMg+L SLGjl1QCzas4jTXzliVTARbcP7Elb3swUbE6NFcaxZTM3GCjmLtj0lK2J8HIEiJydj OgfFtTnHP6Q8A== Received: from ozhes-PC ([202.188.67.227]) by resomta-po-17v.sys.comcast.net with SMTP id KN4HccY9stSzeKN5fcxAIW; Fri, 23 Dec 2016 10:28:56 +0000 From: prt To: "freebsd-embedded" Subject: RE: better than ever Date: Fri, 23 Dec 2016 15:28:42 +0500 Message-ID: <1937593926.20161223132842@prt.org> Content-Language: ru X-CMAE-Envelope: MS4wfGXIX1jhYNYOHlHqET6rYgPE1iCQ+uJtsYHeyGGuElZ/zbqp7z+mDSZAuoUBMf6gCDazsFR1Jhm5gMQ+149bjk5YanuFR4OKPydIliLIHJ7cH8W+I7dX 7cM9OO4Qf5Pj0+N52lsKXRub6CDr7n9WEZdINFOAcWYbW7HtFBOUJIjrNdlseZsfC80L6eZzHnDRHg== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2016 10:29:03 -0000 SGksIA0KDQpJIHdhbnRlZCAgdG8gIHRlbGwgeW91IHRoYXQgSSdtIGRvaW5nIGZpbmUsIGV2ZW4gYmV0 dGVyIHRoYXQgZXZlciwgeW91ICBtYXkgZmluZCB0aGUgcmVhc29ucyBvZiAgaXQgaGVyZSAgPGh0dHA6 Ly9kZXZpcy5vbGRyaXZlcmxhbmRpbmcuY29tLzEwMTE+DQoNCg0KQmUgd2VsbCwgcHJ0DQoNCg== From owner-freebsd-embedded@freebsd.org Fri Dec 23 21:40:01 2016 Return-Path: Delivered-To: freebsd-embedded@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 F071FC8E713 for ; Fri, 23 Dec 2016 21:40:01 +0000 (UTC) (envelope-from xmoseby@yahoo.se) Received: from nm1-vm5.bullet.mail.ir2.yahoo.com (nm1-vm5.bullet.mail.ir2.yahoo.com [212.82.96.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5EA32178D for ; Fri, 23 Dec 2016 21:40:01 +0000 (UTC) (envelope-from xmoseby@yahoo.se) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.se; s=s2048; t=1482528344; bh=UvuXK33YA2oV8vYfNxBArMTHb1zH7AYbDX9tj6DfJCM=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=AspO/xGaWUJ7w40vzGLqeqXrxYvczt2OWStoraLhsykquVc0feUQCXTJSmv51PRWG09VBlG1u9txiwQ91zb78q1GFgsSYXJ4hmFBZW8RjtvgLbwGldqNYwqAVFzPZclQCf0iUSnbyGNpTby6zl9kA6TMMiIRtvWxOun64M9pFAXn9eQrzdaGfLcJ4NfSt59sFDpIkJVNQiLYqP+Snv0l+alD4O88S3oJ6wJOz69o8B6rzmqB+JQ7+8DL3R3paKXPdso4g+w8Iql2by1t0NGOgceKIT+6aWMciJbFSXZj0+N9Y4w8WO0dqxFbNfQ8FoY73eo5npCQ9z4cdIFf476yjQ== Received: from [212.82.98.124] by nm1.bullet.mail.ir2.yahoo.com with NNFMP; 23 Dec 2016 21:25:44 -0000 Received: from [212.82.98.79] by tm17.bullet.mail.ir2.yahoo.com with NNFMP; 23 Dec 2016 21:25:44 -0000 Received: from [127.0.0.1] by omp1016.mail.ir2.yahoo.com with NNFMP; 23 Dec 2016 21:25:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 297022.40722.bm@omp1016.mail.ir2.yahoo.com X-YMail-OSG: IzX0bjQVM1mRTeDdGNRLzJon0GiXFbx0We4oVZszI4Jbyai4Tp7KnP4S1IgBNwp y2R8w0MTYFMkzQi_sfgfljva3xzPJetC.IdNMudd4IsyScFNWIlT4uyQxGtCAFE2ZgtWay_YejU4 4ikzRDIoaSVi4lJqS69XSsle2ptmCLAMAacMbTPGvIUiGXLVO8lpTGDrzdlkdhC_hoxxQHzu5uKo gC2ewCZJC5uipndU8mlNbHqLTvRW2inlu3u9LhLRVoD5daIKsh7hLIh7iog..tPf8AcZl7sadvVi .Zfdt5Uf4FHwBGwzsX3WL1V6rQSJeLTB81OeZerjMtudppGVJONRD5Ij_kMQdd6k_Ia5xTgj6q4O cPDYxRz7FxMnyx0_zRE4LpzVGixv71UUu0r4x9zISwn0SBI1A6V4WW5uC5RpYztIw_VY12kEW3Pl wCCK7wxM7SSIsxbvLVhbFQDuBHLDvO4xVb5cnZfLRBbn1kq5iszBGWe7eW.Nfow.MTQE.G3duG6F y8svMehIxvR89Njrh96w1CaxS5uA- Received: from jws700061.mail.ir2.yahoo.com by sendmailws164.mail.ir2.yahoo.com; Fri, 23 Dec 2016 21:25:43 +0000; 1482528343.745 Date: Fri, 23 Dec 2016 21:25:43 +0000 (UTC) From: tony moseby Reply-To: tony moseby To: Warner Losh , Martin Galvan Cc: "freebsd-drivers@freebsd.org" , Ian Lepore , "freebsd-embedded@freebsd.org" Message-ID: <2053136483.1957700.1482528343527@mail.yahoo.com> Subject: SV: A few questions about SD/MMC drivers MIME-Version: 1.0 References: <2053136483.1957700.1482528343527.ref@mail.yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2016 21:40:02 -0000 Hello Ian, I can read that you have been involved in a similar problem that I am facin= g now.I am running FreeBSD 8.2 and a armv5TE (marvel mv78100), I have an ss= d disk(4Giga).While running the system and doing disk acesses=C2=A0 after s= ometime (can be days or at least several hours)the system total freezes.Ser= ial port freezes and=C2=A0 ethernet freezes.(just internal connections, no = public). If I do not use the disk, this(the freeze) do not occur.My watchdog is disa= bled , so I am suspecting that the kernel crashes and that is the cause of = the freeze.I connected an emulator to=C2=A0 the board, but whenever the fre= eze occur,the emulator looses also contactwith the CPU.I have tested to do = a lot of read/write towards the ssd,often this also causes freeze, but for = a coupleof times I can see the kernel crashing with alignment fault 1.Do yo= u have any ideas?ThanksBR/T =20 Den tisdag, 14 oktober 2014 2:29 skrev Warner Losh : =20 The buffer is always contiguous in virtual space, but maybe not necessaril= y in physical space, hence the need for SG list. For buffers smaller than one page, the difference doesn=E2=80=99t matter :) But with multi-block support= , you=E2=80=99ll 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 wr= ote: >>>>> 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 drive= r >>>>> allocates a scatterlist with each entry being a buffer corresponding >>>>> to a descriptor; it then loops through the descriptor list setting th= e >>>>> "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 b= it >>>> 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.=C2=A0 You are g'teed not to get mor= e >> 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).=C2=A0= 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 =20