From owner-freebsd-arm@freebsd.org Tue Aug 20 12:33:24 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 14072D1175 for ; Tue, 20 Aug 2019 12:33:24 +0000 (UTC) (envelope-from khantroll@gmail.com) Received: from mail-ot1-x343.google.com (mail-ot1-x343.google.com [IPv6:2607:f8b0:4864:20::343]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46CVZW0m3Pz4JWT for ; Tue, 20 Aug 2019 12:33:22 +0000 (UTC) (envelope-from khantroll@gmail.com) Received: by mail-ot1-x343.google.com with SMTP id m24so4824292otp.12 for ; Tue, 20 Aug 2019 05:33:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=WbDSBpCqm6rRyI+33J2vG7wtfcuvuclbXKQ2AjyED4g=; b=i7KG6eAL38rm+rqPsWHxFZxkKV4+blhLp60xJtj/AYT6Zdv6eiaponU9VtMYHxO2C1 YgfL4s35b/9muaBQToJX6Y5neC8rMI9HhWSt3RePoUWux76Oeb04U4OKylwPfa75l+/t WlZj6BcLw6BCyGF/em63g/wD7kBTLYi1aN9TGPI7dkg4XvL/4bR6DUv0gHFJK1vt9OsI rjX7Q9USpGzhrkkV3RWiSSFxUmsyFoH5M/EBGyfeKAI/rCK18wB+4ASQVAJm7EzxCRZB FFFj+MjbMacV8cIRvwDTcQiakuKlofRrT0jzmZnFRAi4KTj9mC5WkYH779G7HXcnO2o5 vrPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=WbDSBpCqm6rRyI+33J2vG7wtfcuvuclbXKQ2AjyED4g=; b=C7WY83MF7zVH30R6PG0on8iXI+yWGb7N7Zw36oW8zhHWE7whQLcyaFzaUGFsQ+YMnS oPBEefK70Z5GRY82Y1DeXt5jCG7up5kh7/t49kt3+fXFOtdewmy2z1ktTmQ7PFiZASDR 4XID1eEdjH+gxYeTazW2BaIlyWGOnp5fbsfDFJWr5V9bB92dTOn0eMUFLVVqhjRgwaNO 5nTSrSN1Xw7Rmdy2QazzCrdwmdK7gi9SIizuLT0NCMKOMba4oej0m+7SF3TtYmGmjv91 gipxkyje+FaZycFWuDsRGxWukjsHok/M9fe9mOolJJcYSCFw2ilTWvnXrmrE8JA2uT9z n+VA== X-Gm-Message-State: APjAAAXTC4EoaFKdko163mq+byCIuMLP0ybuOekySP1uBXH5tPlm97bg b7Utw16cFVTPF7XTsuHwd67t9dt7Z6C+J122txo= X-Google-Smtp-Source: APXvYqxbWer3ml0sEVCpT0K+8CupTRxgwwDz6U2dTQ6dQ3y2jkBERkMj96f6wH7Xcdv+VDq0kSVoqxB4UOMilM0UcZw= X-Received: by 2002:a05:6830:51:: with SMTP id d17mr13833467otp.358.1566304401463; Tue, 20 Aug 2019 05:33:21 -0700 (PDT) MIME-Version: 1.0 References: <1547777156.662147.1565798461515.JavaMail.zimbra@perftech.com> <0E42E605-477E-4E65-810E-BD3A8CDE2C80@gmail.com> <973015183.1067498.1565890674099.JavaMail.zimbra@perftech.com> <20190815210311.1035f64b003e2bc85fa47ca8@bidouilliste.com> <20190815233755.893e485f40ccacd79cdb3d96@bidouilliste.com> <78F5029D-A0F5-42F2-8191-07EB3A68C87B@gmail.com> <20190816152454.4e54ab5c276a543c120d909a@bidouilliste.com> <20190816171037.f808fbaba2369f179de36397@bidouilliste.com> <20190816191230.508f07f27fac21479a6716d9@bidouilliste.com> <20190816225826.ce31e8f968021944f64cb67c@bidouilliste.com> <20190817153053.5592b15b8a42982fda0fc123@bidouilliste.com> <9749945A-FDAD-47E0-947A-FA62138C2F83@gmail.com> <20190817210822.8920656bad0855b554883cf2@bidouilliste.com> <2D6D4BDA-75EC-403F-B5E2-52A468369DE2@gmail.com> <627099DD-804B-412F-A083-768CEFCF955C@gmail.com> <6DA8E736-8031-4BF7-8B20-CF8B0E8A7FEF@gmail.com> In-Reply-To: From: Jeffrey Bowers Date: Tue, 20 Aug 2019 07:33:07 -0500 Message-ID: Subject: Re: Espressobin anyone ? To: =?UTF-8?Q?S=C3=B8ren_Schmidt?= , freebsd-arm X-Rspamd-Queue-Id: 46CVZW0m3Pz4JWT X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=i7KG6eAL; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of khantroll@gmail.com designates 2607:f8b0:4864:20::343 as permitted sender) smtp.mailfrom=khantroll@gmail.com X-Spamd-Result: default: False [-2.99 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.99)[-0.989,0]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; SH_EMAIL_ZRD(0.00)[0.0.46.224,0.0.117.48]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.117.48,0.0.46.224]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE_FREEMAIL(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[3.4.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(0.00)[ip: (2.93), ipnet: 2607:f8b0::/32(-2.93), asn: 15169(-2.37), country: US(-0.05)]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 12:33:24 -0000 I'm still getting: svn: E000060: Operation timed out It goes for several minutes scrolling through text, and I feel like using your link got further. Thanks! On Tue, Aug 20, 2019 at 2:49 AM S=C3=B8ren Schmidt wrote: > Hmm, I use this URL > > Repository Root: https://svn.freebsd.org/ports/head > > Not sure the svn+ssh thing works=E2=80=A6 > > -S=C3=B8ren > > > On 20 Aug 2019, at 02.38, Jeffrey Bowers wrote: > > Hi all, > > I'm having trouble getting subversion to work. When I run: > > svn checkout https://svn.FreeBSD.org/ports/head /usr/ports > > It scrolls through many lines of text before stating: svn: E000060: > Operation timed out > > When I run: > > svn checkout svn+ssh://repo.freebsd.org/ports/head /usr/ports > > It tells me that the authenticity of the host cannot be identified, and > asks me to confirm that I want to connect. I say yes, and then it says: > > svn: E170013: Unable to connect to a repository at URL 'svn+ssh:// > repo.freebsd.org/ports/head' > svn: E210002: To better debug SSH connection problems, remove the -q opti= on > from 'ssh' in the [tunnels] section of your Subversion configuration file= . > > Any ideas? > > Thanks in advance! > > On Mon, Aug 19, 2019 at 8:51 PM Jeffrey Bowers > wrote: > > I didn't think it remounting. Thank you! > > On Mon, Aug 19, 2019 at 11:39 AM S=C3=B8ren Schmidt > wrote: > > Hi Jeffrey > > You need to unmount the /tmp filesystem :) > You can do that permanently by commenting it out in /etc/fstab > > > On 19 Aug 2019, at 21.45, Jeffrey Bowers wrote: > > Hi Soren, > > I'm getting the same error message. Any other ideas what it might be? > It's got to be something in the partition scheme or the file permissions, > but I'm just not sure what. > > > On Sun, Aug 18, 2019 at 10:03 AM Jeffrey Bowers > wrote: > > D=E2=80=99Oh! I thought I too care of that with gpart. I literally missed= growfs > part of the instructions.. > > On Sun, Aug 18, 2019 at 10:00 AM S=C3=B8ren Schmidt > wrote: > > Hi > > You are out of space :) > > Boot the board into singleuser mode, and do =E2=80=9Cservice growfs start= =E2=80=9D, > that will expand you / filesystem to the entire SD card=E2=80=A6 > > -S=C3=B8ren > > On 18 Aug 2019, at 14.50, Jeffrey Bowers wrote: > > Sure thing! Here's the screenshot! > > > > On Sun, Aug 18, 2019 at 7:35 AM S=C3=B8ren Schmidt > wrote: > > Hi > > Can I have you paste the output from df -h ? > > You should be able to utilise the full SD card=E2=80=A6 > > -S=C3=B8ren > > On 18 Aug 2019, at 14.29, Jeffrey Bowers wrote: > > Hi, > > Just make sure I understand the process, I should hook up a hard disk > and map it to to /TMP ? > > I already tried just unmapping /tmp, and it gave me the same error > once, and then the next time I ran it I got an error saying /usr/ports wa= s > out of space )which I guess I shouldn=E2=80=99t mount to another director= on the > hard drive? > > On Sun, Aug 18, 2019 at 5:11 AM S=C3=B8ren Schmidt > wrote: > > Hi Jeffrey > > You can unmount the memory disk on /tmp to get at the space on the SD > card. > > It is however not recommend to use the AD card for random storage, it > will wear out fast, that=E2=80=99s why the memory disk is setup. > > You could connect a SSD og laptop disk to the SATA interface and use > that for the workload. > > However compiling is slow, its much much faster to cross compile on a > PC=E2=80=A6 > > -S=C3=B8ren > > On 18 Aug 2019, at 00.22, Jeffrey Bowers wrote: > > Hi! I've got a new one :) > I'm trying to do an svn checkout to fix the pkg problem, but it tells > me it can't write to a to a temp folder because there is no room left on > the device. However, FreeBSD partition is 29GB. It's never also never the > same file in TMP that it can't write to. Here is a screenshot of the issu= e, > along with the output of gpart: > > > > Any ideas? > > Thanks! > > > On Sat, Aug 17, 2019 at 2:08 PM Emmanuel Vadot > wrote: > > On Sat, 17 Aug 2019 17:14:36 +0200 > S=C3=B8ren Schmidt wrote: > > HI > > Well, I have a whole forrest of tree?s here, but the error posted > > here was on a clean checkout. > > > Anyhow, with the latest changes to -stable and the two > > RF_SHAREABLE patches from -current all works. > > I've reverted the commits, see > https://github.com/evadot/freebsd/commits/a37x0_gpio for a better > way > to deal with this issue. > I'm waiting for mmel@ as he wrote the syscon_get_default_handle > part. > > It would be nice with the etherswitch changes as well so VLAN > > tagging etc was standard. > > > -S=C3=B8ren > > PS: given up on bottom & inline popsting, top posting is all the > > rage now (yeah I miss elm etc :) ) > > > On 17 Aug 2019, at 15.30, Emmanuel Vadot > > wrote: > > > On Sat, 17 Aug 2019 11:07:22 +0200 > S=C3=B8ren Schmidt > soren.schmidt@gmail.com>> wrote: > > > Hi Emmunuel > > Yes the 3720 gpio driver I already back ported long ago, its > > needed, I?m happy its now part of std stable 12! > > > Would have been nice of you to say that you were not running a > > clean > > tree. > > My issue seems to be the inclusion of the phy_usb driver, if I > > leave that out, I?m back to normal.. > > > What make you think this is this driver ? What works/doesn't work > with it ? could you provide logs. > > I?ll have have another go at the latest -stable sources during > > the weekend and see how it goes. > > > Thanks for looking into this, with a little cooperation we?ll > > get this solved for the greater good.. > > > -S=C3=B8ren > > > P.S. Please stop top posting, it's really hard to read the > > conversation > > > On 16 Aug 2019, at 22.58, Emmanuel Vadot < > > manu@bidouilliste.com> wrote: > > > On Fri, 16 Aug 2019 19:12:30 +0200 > Emmanuel Vadot > manu@bidouilliste.com>> wrote: > > > On Fri, 16 Aug 2019 17:10:37 +0200 > Emmanuel Vadot wrote: > > On Fri, 16 Aug 2019 15:24:54 +0200 > Emmanuel Vadot wrote: > > On Fri, 16 Aug 2019 07:28:59 +0200 > S=C3=B8ren Schmidt wrote: > > Hi > > Very simple, reverting sys/gnu/dts to what was before > > 350595 (actually 350592). > > Thats what we have svn for ? > > > If I asked how it was to have the svn command that you > > used, I want to > > make sure that you didn't revert anything else, like do you > > have > > r350596 and r350628 ? > > That does make my bananapi work again, no other changes > > just a recompiled kernel. > > > That + copying the dtb to the fat32 partition ? > > Can you post the dtb somewhere. > > However it does not bring the Espressobin back to life, > > thats something in one of the ~30 other files that changed between those > two revisions. > > > What Linux version of DTS are you using then ? The ones > > that were in > > stable/12 when it was branched (4.18) or a later revision ? > > > So I think that I've found the problem on the Espressobin. > I think that the problem comes from the simple-mfd driver > > that I've > > mfc in r350600. > The pinctrl/gpio controller compatible is > "marvell,armada3710-nb-pinctrl", "syscon", "simple-mfd" and > > it attaches > > at BUS_PASS_INTERRUPT while the simple_mfd driver attaches at > BUS_PASS_BUS (so earlier) which means that no gpio > > controller will be > > available for sdhci to detect the card. > > If someone with a non-working espressobin could post a full > > verbose > > boot log that would help me confirming that this is the case. > I'll try to find a solution on how to solve this problem. > > > So this wasn't the problem but I've found it, see r351129 and > > r351130 > > > SD card now work again in HEAD, I'll have a look at stable > > later next > > week. > > > I've did a quick test and I've MFC r348880, r348882 and > > r349596, the > > two other commits needed to be mfc'ed are the one I did today > > on head, > > I'll do that next week. > With them sdcard is working again on stable/12 > > -S=C3=B8ren > > On 15 Aug 2019, at 23.37, Emmanuel Vadot < > > manu@bidouilliste.com> wrote: > > > On Thu, 15 Aug 2019 21:56:23 +0200 > S=C3=B8ren Schmidt wrote: > > > Well, I don?t care where you are from and what color you > > have :) > > > Now, if I update my stable12 sources to r350595 the > > bananapi breaks, if revert sys/gnu/dts it works again, go figure.. > > > Reverting to what ? and how ? > > Because I've just test 12-stable and I have the problem > > that I've said > > in my previous mail so setting > > hw.regulator.disable_unused=3D0 is the > > work around. > The problem is in twsi not in the DTS so I'm curious how > > reverting > > only the dts fixes this problem. > > The r351099 fix is already like that in -stable, and not > > part of the problem. > > > -S=C3=B8ren > > > On 15 Aug 2019, at 21.03, Emmanuel Vadot < > > manu@bidouilliste.com> wrote: > > > On Thu, 15 Aug 2019 19:48:54 +0200 > S=C3=B8ren Schmidt wrote: > > Hi Mit! > > Right, I suspected that, 12-stable broke many embedded > > systems between r350592 and r350595 where all the latest and greatest DTS > files was pulled in, I guess the same holds for -current. > > > -S=C3=B8ren > > > Mhm it's fun that you think that DTS import is the > > source of all your > > problems, I get it, it's easy to blame the French guy > > that bulk import > > the DTS, he surely don't know what he is doing. > Anyway, two problems were raised in this thread : > > 1) BananaPi (A20) doesn't boot > 2) Espressobin sd support is broken > > I've just looked at the BananaPi problem today, I've > > fixed a first > > problem in r351099. > The main problem is that when we disable the unused > > regulators we hang > > when trying to disabling ldo3. It's weird because the > > board doesn't use > > LDO3 (which is why we are disabling it, it's unused). > > The problem is in > > twsi I think as only leaving the part in axp209 that > > read the > > voltage register value make FreeBSD hang. > I'll have a proper look later, in the meantime you can > > set > > hw.regulator.disable_unused=3D0 > in /boot/loader.conf > This isn't a DTS problem. > > For Espressobin I haven't found any thing related to SD > > in the DTS > > updates since the import, the only things slighly > > related are mmc and > > sdio. > So if someone could find which DTS import broke this I > > can have a look. > > > > On 15 Aug 2019, at 19.37, Mit Matelske > > wrote: > > > Yeah, that was the problem. I went back to r348882 > > and everything worked out of the box. > > > Thanks again for the hand holding! > > Mit > > From: "S=C3=B8ren Schmidt" > > > > To: "Mit Matelske" > > Cc: "Marcin Wojtas" > mw@semihalf.com>>, "freebsd-arm" freebsd-arm@freebsd.org>> > > Sent: Wednesday, August 14, 2019 1:33:04 PM > Subject: Re: Espressobin anyone ? > > > It might simply be broken in -current (again). > > I just updated my stable12 tree and I pulled in new > > .dts files for just about anything? > > > Needless to say, it broke the Espressobin?s SD > > support, it now fails just like yours.. > > > It also broke allwinner builds and what not, so I?m > > just going back in time again :) > > > I wonder why there is this overwhelming need to > > import stuff that breaks things right, left and center in a -stable branc= h > ? > > That would have earned you the pointy hat back when?. > > -S=C3=B8ren > > > On 14 Aug 2019, at 18.01, Mit Matelske > > wrote: > > > Marcin- > > Sorry I didn't reply yesterday. I didn't have any > > luck with that either. I tried a lot of permutations. > > > Not saying for 100% it doesn't work, but I couldn't > > get it to work! > > > Mit > > From: "Marcin Wojtas" > mw@semihalf.com>> > > To: "Mit Matelske" > > Cc: "S=C3=B8ren Schmidt" > soren.schmidt@gmail.com>>, "freebsd-arm" > > > Sent: Wednesday, August 14, 2019 10:41:04 AM > Subject: Re: Espressobin anyone ? > > Hi Mit, > Since you are using the latest 13-current, could you > > please try if passing rootdev via u-boot bootargs (please see my previous > email) works for you without the loader modification? > > > Best regards, > Marcin > > ?r., 14 sie 2019 o 16:29 Mit Matelske > > napisa?(a): > > Soren- > > Thanks for the info. I'll grab a couple more SD > > cards at lunch. This one is a new Samsung 32GB. I'll also try putting t= he > changes into 12 and see if that helps. I'm using the latest 13-current. > > > Again, appreciate the hand holding! > > Mit > > From: "S=C3=B8ren Schmidt" > > > > To: "Mit Matelske" > > Cc: "Marcin Wojtas" > mw@semihalf.com>>, "freebsd-arm" freebsd-arm@freebsd.org>> > > Sent: Wednesday, August 14, 2019 2:30:31 AM > Subject: Re: Espressobin anyone ? > > Hi Mit > Hmm, from your earlier posted dmesgs it looks like > > the SD card is not getting detected properly.. > > > I get this output: > > sdhci_xenon0: mem > > 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 > > mmc0: on sdhci_xenon0 > ?snip? > mmcsd0: 16GB > by 39 PH> at mmc0 50.0MHz/4bit/65535-block > > > The problem you see was fixed for me by r348882, > > maybe it got broken later, I havn?t backported the later changes.. > > > Have you tried another SD card ? I have found 2 of > > mine that the espressobin doesn?t like, but works fine with bananapi and > friends... > > > -S=C3=B8ren > > On 13 Aug 2019, at 23.30, Mit Matelske > > wrote: > > > Soren- > > Thanks for the code snippet! That will fix one of > > the problems. > > > I still can't mount my filesystem, though. I think > > I'm doing something really simple, wrong. I believe I'm running the late= st > code and added some printfs to show the kernel setting the regulator: > > > > usbus1 on ehci0 > syscon_generic4: mem 0x5f800-0x5ffff on > > simplebus1 > > sdhci_xenon0: > > regulator_get_by_ofw_property(vqmmc-supply) =3D 19 > > sdhci_xenon0: vqmmc-supply regulator found > sdhci_xenon0: mem > > 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 > > ahci0: mem 0xe0000-0xe0177 irq > > 26 on simplebus1 > > > > Could there be a problem with how I am setting up my > > filesystem? I've tried both freebsd-ufs and freebsd as the type, with no > luck. A gpart listing of my SD card: > > > root@fbl:~ # gpart list da3 > Geom name: da3 > modified: false > state: OK > fwheads: 255 > fwsectors: 63 > last: 62521335 > first: 3 > entries: 4 > scheme: GPT > Providers: > 1. Name: da3p1 > Mediasize: 41943040 (40M) > Sectorsize: 512 > Stripesize: 0 > Stripeoffset: 1536 > Mode: r0w0e0 > efimedia: > > HD(1,GPT,19894dc5-b8b2-11e9-871f-08008a0010e0,0x3,0x14000) > > rawuuid: 19894dc5-b8b2-11e9-871f-08008a0010e0 > rawtype: c12a7328-f81f-11d2-ba4b-00a0c93ec93b > label: (null) > length: 41943040 > offset: 1536 > type: efi > index: 1 > end: 81922 > start: 3 > 2. Name: da3p2 > Mediasize: 31968979456 (30G) > Sectorsize: 512 > Stripesize: 0 > Stripeoffset: 41944576 > Mode: r0w0e0 > efimedia: > > HD(2,GPT,98786462-be30-11e9-ae6e-08008a0010e0,0x14003,0x3b8bff5) > > rawuuid: 98786462-be30-11e9-ae6e-08008a0010e0 > rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b > label: (null) > length: 31968979456 > offset: 41944576 > type: freebsd-ufs > index: 2 > end: 62521335 > start: 81923 > Consumers: > 1. Name: da3 > Mediasize: 32010928128 (30G) > Sectorsize: 512 > Mode: r0w0e0 > > Thanks!! > > Mit > > From: "S=C3=B8ren Schmidt" > > > > To: "Marcin Wojtas" > mw@semihalf.com>> > > Cc: "Mit Matelske" >, > > "freebsd-arm" freebsd-arm@freebsd.org>> > > Sent: Tuesday, August 13, 2019 12:55:09 PM > Subject: Re: Espressobin anyone ? > > Hi > That doesn?t seen to work on the espressobin, or > > least I can?t get it to pick it up. > > > I use this patch as a workaround: > > Index: main.c > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --- main.c (revision 350496) > +++ main.c (working copy) > @@ -463,6 +462,13 @@ > int rv; > char *rootdev; > > +#if defined(__aarch64__) > + /* SOS HACK in rootdev, at least Espressobin > > gets this wrong */ > > + printf("Setting currdev hack\n"); > + set_currdev("disk0p2"); > + return (0); > +#endif > + > /* > * First choice: if rootdev is already set, use > > that, even if > > * it's wrong. > > Its not pretty but it does the job until I get time > > to look into why bootargs aren?t passed / won?t stick, probably something= I > havn?t backported to my -stable12 sources yet... > > > -S=C3=B8ren > > On 13 Aug 2019, at 01.38, Marcin Wojtas < > > mw@semihalf.com > wrote: > > > Hi, > > Not sure if it's what you are looking for, but in > > order to autoboot, I > > simply pass 'rootdev=3DdiskXpY' in the bootargs > > variable. Here's example from > > A3720-DB (same should work on EspressoBin): > > Marvell>> set bootargs "rootdev=3Ddisk1p1";usb reset; > > fatload usb 0:1 > > ${fdt_addr} armada-3720-db.dtb; fatload usb 0:1 > > ${kernel_addr} > > boot/loader.efi; bootefi ${kernel_addr} ${fdt_addr} > resetting USB... > USB0: Register 2000104 NbrPorts 2 > Starting the controller > USB XHCI 1.00 > USB1: USB EHCI 1.00 > - ______ ____ _____ _____ > | ____| | _ \ / ____| __ \ > | |___ _ __ ___ ___ | |_) | (___ | | | | > | ___| '__/ _ \/ _ \| _ < \___ \| | | | > | | | | | __/ __/| |_) |____) | |__| | > | | | | | | || | | | > |_| |_| \___|\___||____/|_____/|_____/ > ``` > ` > ????????????Welcome to FreeBSD????????????? s` > > `.....---.......--.``` > > -/ > ? ? +o > > .--` /y:` > > +. > ? 1. Boot Multi user [Enter] ? > > yo`:. :o > > `+- > ? 2. Boot Single user ? y/ > > -/` -o/ > > ? 3. Escape to loader prompt ? .- > ::/sy+:. > ? 4. Reboot ? / > > `-- > > / > ? ? `: > :` > ? Options: ? `: > :` > ? 5. Kernel: default/kernel (1 of 1) ? / > / > ? 6. Boot Options ? .- > -. > ? ? -- > > -. > > ? ? > > `:` `:` > > ? ? > > .-- `--. > > ??????????????????????????????????????????? > > .---.....----. > > Autoboot in 9 seconds, hit [Enter] to boot or any > > other key to stop > > > Loading kernel... > /boot/kernel/kernel text=3D0x95047c > > data=3D0x1919d0+0x84aa94 > > syms=3D[0x8+0x13aaa8+0x8+0x12610d] > Loading configured modules... > can't find '/boot/entropy' > Using DTB provided by EFI at 0x8000000. > ---<>--- > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2019 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, > > 1991, 1992, 1993, 1994 > > The Regents of the University of California. All > > rights reserved. > > FreeBSD is a registered trademark of The FreeBSD > > Foundation. > > FreeBSD 13.0-CURRENT > > 17a1fc80d57-c261519(upstream_master) GENERIC arm64 > > FreeBSD clang version 8.0.0 (tags/RELEASE_800/final > > 356365) (based on LLVM > > 8.0.0) > WARNING: WITNESS option enabled, expect reduced > > performance. > > VT: init without driver. > Starting CPU 1 (1) > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > [...] > > Best regards, > Marcin > > pon., 12 sie 2019 o 23:14 Mit Matelske > > napisa?(a): > > > > Soren- > > Thanks for the quick response. I built this kernel > > with revision 350924. > > I'll dig into whats going on in the morning. > > Mind posting your diff for your loader.efi? > > Thanks again! > > Mit > > > ----- Original Message ----- > From: "S=C3=B8ren Schmidt" > > > > To: "Mit Matelske" > > Cc: "tscho" > johannes@t-beutel.com>>, "freebsd-arm" < > > freebsd-arm@freebsd.org > freebsd-arm@freebsd.org>> > > Sent: Monday, August 12, 2019 3:49:48 PM > Subject: Re: Espressobin anyone ? > > Hi > > Looks like your sources may be too old, you need to > > be at least at r348882 > > to get the fix for the SD card VCC regulator. > > That change fixed it for me backported to 12-stable... > > The currdev problem still exists, I have it hardwired > > in my loader for > > aarch64 :) > > -S=C3=B8ren > > > On 12 Aug 2019, at 21.06, Mit Matelske > > wrote: > > > I'm having a couple little hiccups booting this board > > also. One has > > been commented on already, that I can't get the > > loader to automatically > > start loading the kernel on "disk0p2"... > > The second, is that the kernel can't find the SD card > > after booting so > > it can't mount the root filesystem. I'm using the > > dts/dtb and kernel from > > the 13-current branch. > > Thanks for any and all help. I haven't used u-boot > > in about decade. > > Spoiled by the x86 platform. > > Mit Matelske > > > ***U-boot environment:*** > > > Marvell>> printenv > baudrate=3D115200 > bootargs=3Dconsole=3DttyMV0,115200 > > earlycon=3Dar3700_uart,0xd0012000 > > root=3D/dev/mmcblk0p1 rw rootwait net.ifnames=3D0 > > biosdevname=3D0 > > bootcmd=3Dmmc dev 0; fatload mmc 0:1 $kernel_addr > > $image_name;fatload mmc > > 0:1 $fdt_addr $fdt_name; bootefi $kernel_addr > > $fdt_addr > > bootdelay=3D2 > bootmmc=3Dmmc dev 0; fatload mmc 0:1 $kernel_addr > > $image_name;fatload mmc > > 0:1 $fdt_addr $fdt_name; bootefi $kernel_addr > > $fdt_addr > > console=3Dconsole=3DttyMV0,115200 > > earlycon=3Dar3700_uart,0xd0012000 > > eth1addr=3D00:51:82:11:22:01 > eth2addr=3D00:51:82:11:22:02 > eth3addr=3D00:51:82:11:22:03 > ethact=3Dneta@30000 > ethaddr=3DF0:AD:4E:09:6B:8F > ethprime=3Deth0 > fdt_addr=3D0x4f00000 > fdt_high=3D0xffffffffffffffff > fdt_name=3Defi/boot/armada-3720-espressobin.dtb > fdtcontroladdr=3D3f7161b8 > gatewayip=3D10.4.50.254 > get_images=3Dtftpboot $kernel_addr $image_name; > > tftpboot $fdt_addr > > $fdt_name; run get_ramfs > get_ramfs=3Dif test "${ramfs_name}" !=3D "-"; then setenv > > ramfs_addr > > 0x8000000; tftpboot $ramfs_addr $ramfs_name; else > > setenv ramfs_addr -;fi > > hostname=3Dmarvell > image_name=3Defi/freebsd/loader.efi > initrd_addr=3D0xa00000 > initrd_size=3D0x2000000 > ipaddr=3D0.0.0.0 > kernel_addr=3D0x5000000 > loadaddr=3D0x5000000 > netdev=3Deth0 > netmask=3D255.255.255.0 > ramfs_addr=3D0x8000000 > ramfs_name=3D- > root=3Droot=3D/dev/nfs rw > rootpath=3D/srv/nfs/ > serverip=3D0.0.0.0 > set_bootargs=3Dsetenv bootargs $console $root > > ip=3D$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:none > > nfsroot=3D$serverip:$rootpath $extra_params > stderr=3Dserial@12000 > stdin=3Dserial@12000 > stdout=3Dserial@12000 > > > ***Full boot logs:*** > > > U-Boot 2017.03-armada-17.10.2-g14aeedc (Jun 01 2018 - > > 15:39:10 +0800) > > > Model: Marvell Armada 3720 Community Board ESPRESSOBin > CPU @ 1000 [MHz] > L2 @ 800 [MHz] > TClock @ 200 [MHz] > DDR @ 800 [MHz] > DRAM: 1 GiB > U-Boot DT blob at : 000000003f7161b8 > Comphy-0: USB3 5 Gbps > Comphy-1: PEX0 2.5 Gbps > Comphy-2: SATA0 6 Gbps > SATA link 0 timeout. > AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA > > mode > > flags: ncq led only pmp fbss pio slum part sxs > PCIE-0: Link down > MMC: sdhci@d0000: 0, sdhci@d8000: 1 > SF: Detected mx25u3235f with page size 256 Bytes, > > erase size 64 KiB, > > total 4 MiB > Net: eth0: neta@30000 [PRIME] > Hit any key to stop autoboot: 0 > switch to partitions #0, OK > mmc0 is current device > reading efi/freebsd/loader.efi > 603872 bytes read in 49 ms (11.8 MiB/s) > reading efi/boot/armada-3720-espressobin.dtb > 15946 bytes read in 17 ms (916 KiB/s) > ## Starting EFI application at 05000000 ... > Scanning disk sdhci@d0000.blk > ... > > Card did not respond to voltage select! > mmc_init: -95, time 50 > Found 1 disks > Consoles: EFI console > FreeBSD/arm64 EFI loader, Revision 1.1 > > Command line arguments: loader.efi > EFI version: 2.05 > EFI Firmware: Das U-boot (rev 0.00) > Console: efi (0) > Failed to find bootable partition > Startup error in /boot/lua/loader.lua: seconds > LUA ERROR: cannot open /boot/lua/loader.lua: invalid > > argument. > > > can't load 'kernel' > > Type '?' for a list of commands, 'help' for more > > detailed help. > > OK > OK set currdev=3Ddisk0p2 > OK boot > > /boot/kernel/kernel text=3D0x97d6a0 > > data=3D0x191b50+0x84ae94 > > syms=3D[0x8+0x137dd8+0x8+0x126260] > Using DTB provided by EFI at 0x8000000. > ---<>--- > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2019 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, > > 1991, 1992, 1993, 1994 > > The Regents of the University of California. All > > rights reserved. > > FreeBSD is a registered trademark of The FreeBSD > > Foundation. > > FreeBSD 13.0-CURRENT GENERIC arm64 > FreeBSD clang version 6.0.1 (tags/RELEASE_601/final > > 335540) (based on > > LLVM 6.0.1) > WARNING: WITNESS option enabled, expect reduced > > performance. > > VT: init without driver. > Starting CPU 1 (1) > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > arc4random: WARNING: initial seeding bypassed the > > cryptographic random > > device because it was not yet seeded and the knob > > 'bypass_before_seeding' > > was enabled. > random: entropy device external interface > MAP 3e681000 mode 2 pages 1 > MAP 3ffa6000 mode 2 pages 1 > kbd0 at kbdmux0 > ofwbus0: > simplebus0: on > > ofwbus0 > > simplebus1: on > > simplebus0 > > simple_mfd0: mem > 0x13800-0x138ff,0x13c00-0x13c1f on simplebus1 > simple_mfd1: mem > 0x18800-0x188ff,0x18c00-0x18c1f on simplebus1 > psci0: > Driver> on ofwbus0 > > gic0: mem > > > 0x1d00000-0x1d0ffff,0x1d40000-0x1d7ffff,0x1d80000-0x1d81fff,0x1d90000-0x1= d91fff,0x1da0000-0x1dbffff > > irq 27 on simplebus1 > gpio0: mem > 0x13800-0x138ff,0x13c00-0x13c1f irq > > 28,29,30,31,32,33,34,35,36,37,38,39 on > > simple_mfd0 > gpio0: cannot allocate memory window > device_attach: gpio0 attach returned 6 > gpio0: mem > 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 on > > simple_mfd1 > > gpio0: cannot allocate memory window > device_attach: gpio0 attach returned 6 > gpioregulator0: on ofwbus0 > gpioregulator0: cannot get pin 0 > gpioregulator0: cannot parse parameters > device_attach: gpioregulator0 attach returned 6 > generic_timer0: irq 0,1,2,3 on > > ofwbus0 > > Timecounter "ARM MPCore Timecounter" frequency > > 12500000 Hz quality 1000 > > Event timer "ARM MPCore Eventtimer" frequency > > 12500000 Hz quality 1000 > > gpio0: mem > 0x13800-0x138ff,0x13c00-0x13c1f irq > > 28,29,30,31,32,33,34,35,36,37,38,39 on > > simple_mfd0 > gpio0: cannot allocate memory window > device_attach: gpio0 attach returned 6 > gpio0: mem > 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 on > > simple_mfd1 > > gpio0: cannot allocate memory window > device_attach: gpio0 attach returned 6 > gpioregulator0: on ofwbus0 > gpioregulator0: cannot get pin 0 > gpioregulator0: cannot parse parameters > device_attach: gpioregulator0 attach returned 6 > gpio0: mem > 0x13800-0x138ff,0x13c00-0x13c1f irq > > 28,29,30,31,32,33,34,35,36,37,38,39 on > > simple_mfd0 > gpio0: cannot allocate memory window > device_attach: gpio0 attach returned 6 > gpio0: mem > 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 on > > simple_mfd1 > > gpio0: cannot allocate memory window > device_attach: gpio0 attach returned 6 > gpioregulator0: on ofwbus0 > gpioregulator0: cannot get pin 0 > gpioregulator0: cannot parse parameters > device_attach: gpioregulator0 attach returned 6 > gpio0: mem > 0x13800-0x138ff,0x13c00-0x13c1f irq > > 28,29,30,31,32,33,34,35,36,37,38,39 on > > simple_mfd0 > gpio0: cannot allocate memory window > device_attach: gpio0 attach returned 6 > gpio0: mem > 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 on > > simple_mfd1 > > gpio0: cannot allocate memory window > device_attach: gpio0 attach returned 6 > gpioregulator0: on ofwbus0 > gpioregulator0: cannot get pin 0 > gpioregulator0: cannot parse parameters > device_attach: gpioregulator0 attach returned 6 > gpio0: mem > 0x13800-0x138ff,0x13c00-0x13c1f irq > > 28,29,30,31,32,33,34,35,36,37,38,39 on > > simple_mfd0 > gpio0: cannot allocate memory window > device_attach: gpio0 attach returned 6 > gpio0: mem > 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 on > > simple_mfd1 > > gpio0: cannot allocate memory window > device_attach: gpio0 attach returned 6 > gpioregulator0: on ofwbus0 > gpioregulator0: cannot get pin 0 > gpioregulator0: cannot parse parameters > device_attach: gpioregulator0 attach returned 6 > cpulist0: on ofwbus0 > cpu0: on cpulist0 > cpu1: on cpulist0 > pmu0: irq 4 on ofwbus0 > syscon_generic0: mem 0xd000-0xdfff on > > simplebus1 > > syscon_generic1: mem 0x11500-0x1153f on > > simplebus1 > > uart0: mem 0x12000-0x121ff > > irq 9,10,11 on > > simplebus1 > uart0: console (115200,n,8,1) > gpio0: mem > 0x13800-0x138ff,0x13c00-0x13c1f irq > > 28,29,30,31,32,33,34,35,36,37,38,39 on > > simple_mfd0 > gpio0: cannot allocate memory window > device_attach: gpio0 attach returned 6 > syscon_generic2: mem 0x14000-0x1405f on > > simplebus1 > > gpio0: mem > 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 on > > simple_mfd1 > > gpio0: cannot allocate memory window > device_attach: gpio0 attach returned 6 > mvneta0: mem 0x30000-0x33fff irq 14 > > on simplebus1 > > mvneta0: version is 10 > mvneta0: Ethernet address: 00:a6:39:ca:e8:00 > mdio0: on mvneta0 > mdioproxy0: on mdio0 > e6000sw0: on mdio0 > e6000sw0: multi-chip addressing mode (0x1) > e6000sw0: CPU port at 0 > e6000sw0: fixed port at 0 > e6000sw0: PHY at port 1 > miibus0: on e6000sw0 > e1000phy0: PHY 17 on > > miibus0 > > e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, > > 100baseTX-FDX, > > 1000baseT, 1000baseT-master, 1000baseT-FDX, > > 1000baseT-FDX-master, auto > > e6000sw0: PHY at port 2 > miibus1: on e6000sw0 > e1000phy1: PHY 18 on > > miibus1 > > e1000phy1: none, 10baseT, 10baseT-FDX, 100baseTX, > > 100baseTX-FDX, > > 1000baseT, 1000baseT-master, 1000baseT-FDX, > > 1000baseT-FDX-master, auto > > e6000sw0: PHY at port 3 > miibus2: on e6000sw0 > e1000phy2: PHY 19 on > > miibus2 > > e1000phy2: none, 10baseT, 10baseT-FDX, 100baseTX, > > 100baseTX-FDX, > > 1000baseT, 1000baseT-master, 1000baseT-FDX, > > 1000baseT-FDX-master, auto > > e6000sw0: switch is ready. > etherswitch0: on e6000sw0 > xhci0: mem > > 0x58000-0x5bfff irq 16 on > > simplebus1 > xhci0: 32 bytes context size, 32-bit DMA > usbus0 on xhci0 > syscon_generic3: mem 0x5d800-0x5dfff on > > simplebus1 > > ehci0: mem > > 0x5e000-0x5efff irq > > 17 on simplebus1 > usbus1: EHCI version 1.0 > usbus1 on ehci0 > syscon_generic4: mem 0x5f800-0x5ffff on > > simplebus1 > > sdhci_xenon0: mem > 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 > ahci0: mem 0xe0000-0xe0177 irq > > 26 on simplebus1 > > ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier > > supported with FBS > > ahcich0: at channel 0 on ahci0 > device_attach: ahcich0 attach returned 6 > gpioregulator0: on ofwbus0 > gpioregulator0: cannot get pin 0 > gpioregulator0: cannot parse parameters > device_attach: gpioregulator0 attach returned 6 > cryptosoft0: > Timecounters tick every 1.000 msec > mvneta0: link state changed to UP > e6000sw0port1: link state changed to DOWN > e6000sw0port2: link state changed to DOWN > e6000sw0port3: link state changed to DOWN > usbus0: 5.0Gbps Super Speed USB v3.0 > usbus1: 480Mbps High Speed USB v2.0 > Release APs...done > CPU 0: ARM Cortex-A53 r0p4 affinity: 0 > Instruction Set Attributes 0 =3D > > > > Trying to mount root from > > ufs:/dev/ufs/FreeBSD_Install [ro,noatime]... > > Instruction Set Attributes 1 =3D <> > Root mount waiting for: Processor Features 0 =3D > > usbus1 Processor Features 1 =3D <0> > usbus0 Memory Model Features 0 =3D <4k Granule,64k > > Granule,S/NS > > Mem,MixedEndian,16bit ASID,1TB PA> > > Memory Model Features 1 =3D <> > Memory Model Features 2 =3D <32b CCIDX,48b VA> > Debug Features 0 =3D <2 CTX Breakpoints,4 > > Watchpoints,6 > > Breakpoints,PMUv3,Debug v8> > Debug Features 1 =3D <0> > Auxiliary Features 0 =3D <0> > Auxiliary Features 1 =3D <0> > CPU 1: ARM Cortex-A53 r0p4 affinity: 1 > WARNING: WITNESS option enabled, expect reduced > > performance. > > ugen0.1: at usbus0 > ugen1.1: at usbus1 > uhub0 on usbus0 > uhub1 on usbus1 > uhub0: > 3.00/1.00, addr 1> on > > usbus0 > uhub1: > 2.00/1.00, addr 1> on > > usbus1 > uhub0: 2 ports with 2 removable, self powered > uhub1: 1 port with 1 removable, self powered > mountroot: waiting for device > > /dev/ufs/FreeBSD_Install... > > Mounting from ufs:/dev/ufs/FreeBSD_Install failed > > with error 19. > > > Loader variables: > vfs.root.mountfrom=3Dufs:/dev/ufs/FreeBSD_Install > vfs.root.mountfrom.options=3Dro,noatime > > Manual root filesystem specification: > : [options] > Mount using filesystem > and with the specified (optional) option list. > > eg. ufs:/dev/da0s1a > zfs:zroot/ROOT/default > cd9660:/dev/cd0 ro > (which is equivalent to: mount -t cd9660 -o ro > > /dev/cd0 /) > > > ? List valid disk boot devices > . Yield 1 second (for background tasks) > Abort manual input > > mountroot> ? > > List of GEOM managed disk devices: > > > mountroot> > _______________________________________________ > freebsd-arm@freebsd.org > freebsd-arm@freebsd.org> mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm < > https://lists.freebsd.org/mailman/listinfo/freebsd-arm> > > To unsubscribe, send any mail to " > > freebsd-arm-unsubscribe@freebsd.org freebsd-arm-unsubscribe@freebsd.org>" > > > _______________________________________________ > freebsd-arm@freebsd.org > freebsd-arm@freebsd.org> mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm < > https://lists.freebsd.org/mailman/listinfo/freebsd-arm> > > To unsubscribe, send any mail to " > > freebsd-arm-unsubscribe@freebsd.org freebsd-arm-unsubscribe@freebsd.org>" > > > > > -- > Emmanuel Vadot < > > manu@freebsd.org> > > > > > -- > Emmanuel Vadot > > > > -- > Emmanuel Vadot > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to " > > freebsd-arm-unsubscribe@freebsd.org" > > > > -- > Emmanuel Vadot > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to " > > freebsd-arm-unsubscribe@freebsd.org" > > > > -- > Emmanuel Vadot > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to " > > freebsd-arm-unsubscribe@freebsd.org" > > > > -- > Emmanuel Vadot > manu@bidouilliste.com>> > > > > > > -- > Emmanuel Vadot > manu@bidouilliste.com>> > > > > > > -- > Emmanuel Vadot > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to " > freebsd-arm-unsubscribe@freebsd.org" > > > > > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > >