Date: Wed, 21 Aug 2019 14:15:02 +0200 (CEST) From: Ronald Klop <ronald-lists@klop.ws> To: Ricky Zhang <zhangchaowang@gmail.com> Cc: freebsd-arm@freebsd.org Subject: Re: How to change rootfs from official RPI3 image Message-ID: <61580006.14.1566389702495@localhost> In-Reply-To: <C5D66D8B-05F2-445A-92A5-CD463B393EEA@gmail.com> References: <0FC8815E-58D7-4196-BF7E-0D6B127B314D@gmail.com> <1668312327.7.1566381369480@localhost> <C5D66D8B-05F2-445A-92A5-CD463B393EEA@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks. I will not take the credits for the idea though. :-) The FreeBSD wiki has some more examples of similar setups: https://wiki.freebsd.org/ZFSOnRoot describes how to do /boot on UFS and the= rest on ZFS, which is similar to /boot on SD-card and the rest on SSD. https://wiki.freebsd.org/RootOnZFS/UFSBoot Nice that you made a write up also. More exposure for FreeBSD is always a g= ood thing. :-) Good luck and keep hacking. Ronald. =20 Van: Ricky Zhang <zhangchaowang@gmail.com> Datum: woensdag, 21 augustus 2019 13:16 Aan: Ronald Klop <ronald-lists@klop.ws> CC: freebsd-arm@freebsd.org Onderwerp: Re: How to change rootfs from official RPI3 image >=20 > Your idea is brilliant. It solved the dilemma.=20 > >>=20 >> Ricky@router ~ $ sudo cat /etc/fstab >> # Custom /etc/fstab for FreeBSD embedded images >> /dev/ufs/rootfs /bootdir ufs rw 1 1 >> /dev/label/gpt/ssdrootfs / ufs rw 1 1 >> /dev/msdosfs/MSDOSBOOT /boot/msdos msdosfs rw,noatime 0 0 >> tmpfs /tmp tmpfs rw,mode=3D1777,size=3D50m 0 0 >> =20 >> Ricky@router ~ $ mount >> /dev/label/gpt/ssdrootfs on / (ufs, local, soft-updates) >> devfs on /dev (devfs, local, multilabel) >> /dev/ufs/rootfs on /bootdir (ufs, local, soft-updates) >> /dev/msdosfs/MSDOSBOOT on /bootdir/boot/msdos (msdosfs, local, noatime) >> tmpfs on /tmp (tmpfs, local) >=20 > =20 > I wrote the whole thing down in my wiki: https://github.com/rickyzhang82/= FreeBSDWiki/wiki/1.-Migrate-SD-card-rootfs-to-SSD-for-RPI3 > =20 > Thanks > =20 > Ricky > >>=20 >> On Aug 21, 2019, at 5:56 AM, Ronald Klop <ronald-lists@klop.ws> wrote: >> =20 >> Sorry, I did only reply to the mailinglist. I will use reply-all now. >>=20 >> You are right about uboot finding /boot/kernel and /boot/loader.conf. >>=20 >> What you need to do is mount the SD-card on /bootdir; in fstab: >> /dev/yoursdcard /bootdir ufs rw,noatime 1 2 >>=20 >> And a symlink from /boot -> /bootdir/boot on your SSD. >>=20 >> Then installworld/installkernel will do the proper thing. >> So the complete /boot stays on the SD-card. >>=20 >> Regards, >>=20 >> Ronald. >> =20 >> Van: Ricky Zhang <zhangchaowang@gmail.com> >> Datum: woensdag, 21 augustus 2019 04:58 >> Aan: freebsd-arm@freebsd.org >> Onderwerp: Re: How to change rootfs from official RPI3 image >>>=20 >>> > BTW: Yes, u-boot is opensource: /usr/ports/sysutils/u-boot-rpi3 >>> > There are sysutils/u-boot-* ports for different system. With sysutils= /u-boot-master as the main part of it. >>> > >>> > https://www.freshports.org/sysutils/u-boot-rpi3 <https://www.freshpor= ts.org/sysutils/u-boot-rpi3> >>> > http://www.denx.de/wiki/U-Boot <http://www.denx.de/wiki/U-Boot>; >>> > >>> > Regards, >>> > Ronald. >>>=20 >>>=20 >>> Hi Ronald, >>>=20 >>> Sorry, if I messed up the mailing list thread. I didn=E2=80=99t receive= your email directly. Instead, I got your reply from daily digest. I have t= o copy subject and quote your reply manually in my email client. I have no = idea how to fix it after reading all FAQ (https://www.freebsd.org/doc/en_US= .ISO8859-1/articles/mailing-list-faq/article.html#etiquette <https://www.fr= eebsd.org/doc/en_US.ISO8859-1/articles/mailing-list-faq/article.html#etique= tte>). Any other mailing list I subscribed didn=E2=80=99t work this way... >>>=20 >>> In any case, the magic works. I did rsync: >>>=20 >>> rsync -aAXvr --progress --delete /* /mnt/USB \ >>> --exclude=3D'/boot/msdos/*' \ >>> --exclude=3D'/dev/*' \ >>> --exclude=3D'/proc/*' \ >>> --exclude=3D'/net/*' \ >>> --exclude=3D'/tmp/*' \ >>> --exclude=3D'/mnt/*' \ >>> --exclude=3D'/media/*' >>>=20 >>> I confirmed that it mount ssd as rootfs: >>>=20 >>> Ricky@router ~ $ df -h >>> Filesystem Size Used Avail Capacity Mounted on >>> /dev/label/gpt/ssdrootfs 407G 5.5G 369G 1% / >>> devfs 1.0K 1.0K 0B 100% /dev >>> /dev/msdosfs/MSDOSBOOT 50M 13M 37M 26% /boot/msdos >>> tmpfs 50M 4.0K 50M 0% /tmp >>>=20 >>> As you said, kernel still comes from SD card. I don=E2=80=99t fully und= erstand the FreeBSD boot process. Neither am I familiar with UEFI. >>>=20 >>> - I guess /boot/msdos/uboot.bin finds the SD card roofs system. Load th= e kernel from /boot/kernel in SD card and scan /boot/loader.conf to find th= e rootfs. Please correct me if I=E2=80=99m wrong. >>> - Should I remove /boot folder from SSD to avoid confusion? >>> - Are there any guide how to compile and deploy kernel? >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> 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" >>>=20 >>>=20 >>>=20 >>=20 >=20 From owner-freebsd-arm@freebsd.org Thu Aug 22 17:27:09 2019 Return-Path: <owner-freebsd-arm@freebsd.org> 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 66B71CDA6A for <freebsd-arm@mailman.nyi.freebsd.org>; Thu, 22 Aug 2019 17:27:09 +0000 (UTC) (envelope-from khantroll@gmail.com) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 46Ds0X3RTgz3CN2 for <freebsd-arm@freebsd.org>; Thu, 22 Aug 2019 17:27:08 +0000 (UTC) (envelope-from khantroll@gmail.com) Received: by mail-ot1-x334.google.com with SMTP id m24so6161835otp.12 for <freebsd-arm@freebsd.org>; Thu, 22 Aug 2019 10:27:08 -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=GSKftrR5eXMmtV8Ql4zIutvZQ78Vmm0N25yVXzXwDeI=; b=Os0M9G91D8oW9tbIu2qLoaCe+un4Hau+3OFmILGD/jlTDFykXaODTDsD0aDFMlhSWD 8GZzcYZDX5WDxvV4y0+bsIldYhM+yCr8OIWHPoM4oghMGAgLlhWKQ70f8AT8tMWJKUPY 5JnPGeg7pMlLr22uGJ7lULHU2VYy0x9PCPFsvbBBSSHTdwOozY422v+cRo/CSFALU/2H foKcNK0LLCGYB/Wxs9fB6CZj6iDyj11FvyLZjPTe4QEFerKeYTL0uq90LaI0nStofwdf O7cTMZ8+zsjHOrQPhl2oZ3BvODBNNve6Dyc0QhI69ED5nZPo6J3jQJ/ZTyALVmt9p/hR +MlQ== 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=GSKftrR5eXMmtV8Ql4zIutvZQ78Vmm0N25yVXzXwDeI=; b=cHC9J3m+W3dFMehNK4+yVJcpkl7Td2tJdSEerlk1vbOeuDifSIYt/MXDTJOYyb5act ip50pQeOmnjHfVaSHibdbkj0nx5GDsMjJLrq9Nces1whsS+R2fEhiiQa6ZkAq2b2WjyE G8Cf8C/wQRvPl2nvY7agLOGi+9Zaayfrt7S4XhJ0pCYPZ4h70+7GOiUTUxiOxmrkGdmo fFDIZslwSU2v+nCLj76RVSpYyjMjJZMdadfg8ZNcZT6jKct8QGo+2RkKVuf4YFcad9h0 r7d8lu6Au8DkcDLfM43hwOMKUSV4+Z+G5szkhJ14Omq2d87i9RrV6uuHpUy8lBEbl7IC FbeQ== X-Gm-Message-State: APjAAAUOd4/Hlpy54H1py+VWYQgD4gZ3EeyRKFYlhZ+fADmiGqff453X bzfiIpklFBc1MHx7UOF8aP1NXWXHW5grd6r473Pr8aVC X-Google-Smtp-Source: APXvYqyNu4yUzl8DdfAp4jNJmROvMabqkBrVPZAN5Yw68WQKEaw2dmI6aaxADjYdw6dek3HX5qlSEgsu+Jpr7mIWAsw= X-Received: by 2002:a9d:1288:: with SMTP id g8mr598198otg.306.1566494826358; Thu, 22 Aug 2019 10:27:06 -0700 (PDT) MIME-Version: 1.0 References: <E73AFF5D-43CA-41A7-BDBA-ADEF2D342479@deepcore.dk> <20190817153053.5592b15b8a42982fda0fc123@bidouilliste.com> <9749945A-FDAD-47E0-947A-FA62138C2F83@gmail.com> <20190817210822.8920656bad0855b554883cf2@bidouilliste.com> <CAAkMUSXsgxP_fOJdfks+d35MnyoXf1GfPO+C-YmTK3TpKDH7gA@mail.gmail.com> <2D6D4BDA-75EC-403F-B5E2-52A468369DE2@gmail.com> <CAAkMUSUM8bWT0Q-90jrvWjGOJopEka_LgP8sMshuS4Y7YQ29vw@mail.gmail.com> <627099DD-804B-412F-A083-768CEFCF955C@gmail.com> <CAAkMUSXd2zQQcYWDZnmibTQzLe+UV8rH6pk5fr=oZvevAY+HOQ@mail.gmail.com> <6DA8E736-8031-4BF7-8B20-CF8B0E8A7FEF@gmail.com> <CAAkMUSVRxbDBYtX0g7xbu4kLtiYQiZhjh0bdSwbCahF+jmTUXg@mail.gmail.com> <CAAkMUSVWWjYviHbOUXuHPxJYoahUnitdNazyusH=zGvbW1RAnw@mail.gmail.com> <ABB6B2F0-7771-49CD-84CF-B00D061EEF60@gmail.com> <CAAkMUSUfKN8Jqe7U40z9O1ypb=WuMWfgGtbnq7jLFPjp5qQfqQ@mail.gmail.com> <CAAkMUSV4p1uQOi+t7b-z0uG8kjVY3qZhFd4B7fP1BjOWVRYqTA@mail.gmail.com> <BC161A1F-DC68-4AD3-BD28-1028E4BF7CCD@gmail.com> <CAAkMUSVGZCxgoTc+fBgsuR-DKiwUm8gKe49W-2+hH2PqRc+g2A@mail.gmail.com> <CAAkMUSW6Oa-RE4MFMKghn3XfMN5tL0MQE=z1h5jO8H7=XS8+XA@mail.gmail.com> <2002575095.53.1566305166664@localhost> <CAAkMUSWv+0m29Epy0ZA1rnbLTJ2XkNTG2aSN7e11eGxE-3tYXw@mail.gmail.com> <op.z6t4g5ajkndu52@sjakie> In-Reply-To: <op.z6t4g5ajkndu52@sjakie> From: Jeffrey Bowers <khantroll@gmail.com> Date: Thu, 22 Aug 2019 17:27:00 -0500 Message-ID: <CAAkMUSUr56Dv8S6syPtf=yfUkiiykJxoVNexaVv5KHwRvJ29yg@mail.gmail.com> Subject: Re: Espressobin anyone ? To: Ronald Klop <ronald-lists@klop.ws>, freebsd-arm <freebsd-arm@freebsd.org> X-Rspamd-Queue-Id: 46Ds0X3RTgz3CN2 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=Os0M9G91; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of khantroll@gmail.com designates 2607:f8b0:4864:20::334 as permitted sender) smtp.mailfrom=khantroll@gmail.com X-Spamd-Result: default: False [2.00 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; DATE_IN_FUTURE(4.00)[]; 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(-1.00)[-0.998,0]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (-6.87), ipnet: 2607:f8b0::/32(-2.90), asn: 15169(-2.35), country: US(-0.05)]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; 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]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[4.3.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]; HTTP_TO_IP(1.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; 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." <freebsd-arm.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>, <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>; List-Post: <mailto:freebsd-arm@freebsd.org> List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>, <mailto:freebsd-arm-request@freebsd.org?subject=subscribe> X-List-Received-Date: Thu, 22 Aug 2019 17:27:09 -0000 No, unfortunately it still ends in an E000060: Operation timed out. However, there are files and directories in my local ports directory, so it's downloading at least some things. On Tue, Aug 20, 2019 at 2:01 PM Ronald Klop <ronald-lists@klop.ws> wrote: > On Wed, 21 Aug 2019 01:03:37 +0200, Jeffrey Bowers <khantroll@gmail.com> > wrote: > > Yes sir, I can ping svn.freebsd.org. Any idea why the checkout fails? > > > I don't know. What ip address do you get when pinging? > > Does this work for you? Does it work using the ip address you get? > > svn checkout https://213.138.116.72/ports/head > > Regards, > Ronald. > > > > > On Tue, Aug 20, 2019 at 7:46 AM Ronald Klop <ronald-lists@klop.ws> wrote: > >> It is not possible to 'ping https://svn.freebsd.org/ports/head'. >> You can 'ping svn.freebsd.org'. >> >> Ronald. >> >> >> *Van:* Jeffrey Bowers <khantroll@gmail.com> >> *Datum:* dinsdag, 20 augustus 2019 14:36 >> *Aan:* "S=C3=B8ren Schmidt" <soren.schmidt@gmail.com>, freebsd-arm < >> freebsd-arm@freebsd.org> >> *Onderwerp:* Re: Espressobin anyone ? >> >> I just tried to ping https://svn.freebsd.org/ports/head, and even thoug= h >> it scrolsl through all that text I get an error saying "could not resolv= e >> https://svn.freebsd.org/ports/head ; unknown server error" . I can ping >> google just fine. Is it a DNS issue? >> >> On Tue, Aug 20, 2019 at 7:33 AM Jeffrey Bowers <khantroll@gmail.com> >> wrote: >> >> > 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 <soren.schmidt@gmai= l.com> >> > 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 <khantroll@gmail.com> 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, a= nd >> >> asks me to confirm that I want to connect. I say yes, and then it say= s: >> >> >> >> 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 >> >> option >> >> 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 <khantroll@gmail.com> >> >> wrote: >> >> >> >> I didn't think it remounting. Thank you! >> >> >> >> On Mon, Aug 19, 2019 at 11:39 AM S=C3=B8ren Schmidt < >> soren.schmidt@gmail.com> >> >> 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 <khantroll@gmail.com> 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. >> >> <image.png> >> >> >> >> On Sun, Aug 18, 2019 at 10:03 AM Jeffrey Bowers <khantroll@gmail.com> >> >> wrote: >> >> >> >> D=E2=80=99Oh! I thought I too care of that with gpart. I literally mi= ssed >> growfs >> >> part of the instructions.. >> >> >> >> On Sun, Aug 18, 2019 at 10:00 AM S=C3=B8ren Schmidt < >> soren.schmidt@gmail.com> >> >> wrote: >> >> >> >> Hi >> >> >> >> You are out of space :) >> >> >> >> Boot the board into singleuser mode, and do =E2=80=9Cservice growfs s= tart=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 <khantroll@gmail.com> wrote: >> >> >> >> Sure thing! Here's the screenshot! >> >> <image.png> >> >> >> >> >> >> On Sun, Aug 18, 2019 at 7:35 AM S=C3=B8ren Schmidt <soren.schmidt@gma= il.com >> > >> >> 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 <khantroll@gmail.com> 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/port= s >> was >> >> out of space )which I guess I shouldn=E2=80=99t mount to another dire= ctor on >> the >> >> hard drive? >> >> >> >> On Sun, Aug 18, 2019 at 5:11 AM S=C3=B8ren Schmidt <soren.schmidt@gma= il.com >> > >> >> 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 <khantroll@gmail.com> 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 >> >> issue, >> >> along with the output of gpart: >> >> >> >> <image.png> >> >> >> >> Any ideas? >> >> >> >> Thanks! >> >> >> >> >> >> On Sat, Aug 17, 2019 at 2:08 PM Emmanuel Vadot <manu@bidouilliste.com= > >> >> wrote: >> >> >> >> On Sat, 17 Aug 2019 17:14:36 +0200 >> >> S=C3=B8ren Schmidt <soren.schmidt@gmail.com> 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 <manu@bidouilliste.com> >> >> >> >> wrote: >> >> >> >> >> >> On Sat, 17 Aug 2019 11:07:22 +0200 >> >> S=C3=B8ren Schmidt <soren.schmidt@gmail.com <mailto: >> >> >> >> 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 <mailto: >> >> >> >> manu@bidouilliste.com>> wrote: >> >> >> >> >> >> On Fri, 16 Aug 2019 17:10:37 +0200 >> >> Emmanuel Vadot <manu@bidouilliste.com> wrote: >> >> >> >> On Fri, 16 Aug 2019 15:24:54 +0200 >> >> Emmanuel Vadot <manu@bidouilliste.com> wrote: >> >> >> >> On Fri, 16 Aug 2019 07:28:59 +0200 >> >> S=C3=B8ren Schmidt <soren.schmidt@gmail.com> 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 <soren.schmidt@gmail.com> 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 <soren.schmidt@gmail.com> 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 <mit@pt.net> >> >> >> >> 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" <soren.schmidt@gmail.com >> >> >> >> <mailto:soren.schmidt@gmail.com>> >> >> >> >> To: "Mit Matelske" <mit@pt.net <mailto:mit@pt.net>> >> >> Cc: "Marcin Wojtas" <mw@semihalf.com <mailto: >> >> >> >> mw@semihalf.com>>, "freebsd-arm" <freebsd-arm@freebsd.org <mailto: >> >> 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 >> >> branch ? >> >> >> >> That would have earned you the pointy hat back when?. >> >> >> >> -S=C3=B8ren >> >> >> >> >> >> On 14 Aug 2019, at 18.01, Mit Matelske <mit@pt.net >> >> >> >> <mailto:mit@pt.net>> 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 <mailto: >> >> >> >> mw@semihalf.com>> >> >> >> >> To: "Mit Matelske" <mit@pt.net <mailto:mit@pt.net>> >> >> Cc: "S=C3=B8ren Schmidt" <soren.schmidt@gmail.com <mailto: >> >> >> >> soren.schmidt@gmail.com>>, "freebsd-arm" <freebsd-arm@freebsd.org >> >> <mailto:freebsd-arm@freebsd.org>> >> >> >> >> 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 <mit@pt.net >> >> >> >> <mailto:mit@pt.net>> 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 putti= ng >> >> the >> >> 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" <soren.schmidt@gmail.com >> >> >> >> <mailto:soren.schmidt@gmail.com>> >> >> >> >> To: "Mit Matelske" <mit@pt.net <mailto:mit@pt.net>> >> >> Cc: "Marcin Wojtas" <mw@semihalf.com <mailto: >> >> >> >> mw@semihalf.com>>, "freebsd-arm" <freebsd-arm@freebsd.org <mailto: >> >> 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: <Armada Xenon SDHCI controller> mem >> >> >> >> 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 >> >> >> >> mmc0: <MMC/SD bus> on sdhci_xenon0 >> >> ?snip? >> >> mmcsd0: 16GB <SDHC SD16G 3.0 SN 01E28E67 MFG 07/2017 >> >> >> >> 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 <mit@pt.net >> >> >> >> <mailto:mit@pt.net>> 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 >> >> latest >> >> code and added some printfs to show the kernel setting the regulator: >> >> >> >> >> >> >> >> usbus1 on ehci0 >> >> syscon_generic4: <syscon> mem 0x5f800-0x5ffff on >> >> >> >> simplebus1 >> >> >> >> sdhci_xenon0: >> >> >> >> regulator_get_by_ofw_property(vqmmc-supply) =3D 19 >> >> >> >> sdhci_xenon0: vqmmc-supply regulator found >> >> sdhci_xenon0: <Armada Xenon SDHCI controller> mem >> >> >> >> 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 >> >> >> >> ahci0: <AHCI SATA controller> 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, wit= h >> 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" <soren.schmidt@gmail.com >> >> >> >> <mailto:soren.schmidt@gmail.com>> >> >> >> >> To: "Marcin Wojtas" <mw@semihalf.com <mailto: >> >> >> >> mw@semihalf.com>> >> >> >> >> Cc: "Mit Matelske" <mit@pt.net <mailto:mit@pt.net>>, >> >> >> >> "freebsd-arm" <freebsd-arm@freebsd.org <mailto: >> >> 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 <mailto: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. >> >> ---<<BOOT>>--- >> >> 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 <mit@pt.net >> >> >> >> <mailto:mit@pt.net>> 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" <soren.schmidt@gmail.com >> >> >> >> <mailto:soren.schmidt@gmail.com>> >> >> >> >> To: "Mit Matelske" <mit@pt.net <mailto:mit@pt.net>> >> >> Cc: "tscho" <johannes@t-beutel.com <mailto: >> >> >> >> johannes@t-beutel.com>>, "freebsd-arm" < >> >> >> >> freebsd-arm@freebsd.org <mailto: >> >> >> >> 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 <mit@pt.net >> >> >> >> <mailto:mit@pt.net>> 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 <mailto: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. >> >> ---<<BOOT>>--- >> >> 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: <Open Firmware Device Tree> >> >> simplebus0: <Flattened device tree simple bus> on >> >> >> >> ofwbus0 >> >> >> >> simplebus1: <Flattened device tree simple bus> on >> >> >> >> simplebus0 >> >> >> >> simple_mfd0: <Simple MFD (Multi-Functions Device)> mem >> >> 0x13800-0x138ff,0x13c00-0x13c1f on simplebus1 >> >> simple_mfd1: <Simple MFD (Multi-Functions Device)> mem >> >> 0x18800-0x188ff,0x18c00-0x18c1f on simplebus1 >> >> psci0: <ARM Power State Co-ordination Interface >> >> >> >> Driver> on ofwbus0 >> >> >> >> gic0: <ARM Generic Interrupt Controller v3.0> mem >> >> >> >> >> >> >> 0x1d00000-0x1d0ffff,0x1d40000-0x1d7ffff,0x1d80000-0x1d81fff,0x1d90000-0x= 1d91fff,0x1da0000-0x1dbffff >> >> >> >> irq 27 on simplebus1 >> >> gpio0: <Armada 37x0 North Bridge GPIO Controller> 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: <Armada 37x0 South Bridge GPIO Controller> 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: <GPIO controlled regulator> on ofwbus0 >> >> gpioregulator0: cannot get pin 0 >> >> gpioregulator0: cannot parse parameters >> >> device_attach: gpioregulator0 attach returned 6 >> >> generic_timer0: <ARMv8 Generic Timer> 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: <Armada 37x0 North Bridge GPIO Controller> 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: <Armada 37x0 South Bridge GPIO Controller> 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: <GPIO controlled regulator> on ofwbus0 >> >> gpioregulator0: cannot get pin 0 >> >> gpioregulator0: cannot parse parameters >> >> device_attach: gpioregulator0 attach returned 6 >> >> gpio0: <Armada 37x0 North Bridge GPIO Controller> 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: <Armada 37x0 South Bridge GPIO Controller> 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: <GPIO controlled regulator> on ofwbus0 >> >> gpioregulator0: cannot get pin 0 >> >> gpioregulator0: cannot parse parameters >> >> device_attach: gpioregulator0 attach returned 6 >> >> gpio0: <Armada 37x0 North Bridge GPIO Controller> 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: <Armada 37x0 South Bridge GPIO Controller> 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: <GPIO controlled regulator> on ofwbus0 >> >> gpioregulator0: cannot get pin 0 >> >> gpioregulator0: cannot parse parameters >> >> device_attach: gpioregulator0 attach returned 6 >> >> gpio0: <Armada 37x0 North Bridge GPIO Controller> 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: <Armada 37x0 South Bridge GPIO Controller> 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: <GPIO controlled regulator> on ofwbus0 >> >> gpioregulator0: cannot get pin 0 >> >> gpioregulator0: cannot parse parameters >> >> device_attach: gpioregulator0 attach returned 6 >> >> cpulist0: <Open Firmware CPU Group> on ofwbus0 >> >> cpu0: <Open Firmware CPU> on cpulist0 >> >> cpu1: <Open Firmware CPU> on cpulist0 >> >> pmu0: <Performance Monitoring Unit> irq 4 on ofwbus0 >> >> syscon_generic0: <syscon> mem 0xd000-0xdfff on >> >> >> >> simplebus1 >> >> >> >> syscon_generic1: <syscon> mem 0x11500-0x1153f on >> >> >> >> simplebus1 >> >> >> >> uart0: <Marvell Armada 3700 UART> mem 0x12000-0x121ff >> >> >> >> irq 9,10,11 on >> >> >> >> simplebus1 >> >> uart0: console (115200,n,8,1) >> >> gpio0: <Armada 37x0 North Bridge GPIO Controller> 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: <syscon> mem 0x14000-0x1405f on >> >> >> >> simplebus1 >> >> >> >> gpio0: <Armada 37x0 South Bridge GPIO Controller> 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: <NETA controller> mem 0x30000-0x33fff irq 14 >> >> >> >> on simplebus1 >> >> >> >> mvneta0: version is 10 >> >> mvneta0: Ethernet address: 00:a6:39:ca:e8:00 >> >> mdio0: <MDIO> on mvneta0 >> >> mdioproxy0: <MII/MDIO proxy, MDIO side> on mdio0 >> >> e6000sw0: <Marvell 88E6341> on mdio0 >> >> e6000sw0: multi-chip addressing mode (0x1) >> >> e6000sw0: CPU port at 0 >> >> e6000sw0: fixed port at 0 >> >> e6000sw0: PHY at port 1 >> >> miibus0: <MII bus> on e6000sw0 >> >> e1000phy0: <Marvell 88E1000 Gigabit PHY> 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: <MII bus> on e6000sw0 >> >> e1000phy1: <Marvell 88E1000 Gigabit PHY> 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: <MII bus> on e6000sw0 >> >> e1000phy2: <Marvell 88E1000 Gigabit PHY> 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: <Switch controller> on e6000sw0 >> >> xhci0: <Generic USB 3.0 controller> mem >> >> >> >> 0x58000-0x5bfff irq 16 on >> >> >> >> simplebus1 >> >> xhci0: 32 bytes context size, 32-bit DMA >> >> usbus0 on xhci0 >> >> syscon_generic3: <syscon> mem 0x5d800-0x5dfff on >> >> >> >> simplebus1 >> >> >> >> ehci0: <Marvell Integrated USB 2.0 controller> mem >> >> >> >> 0x5e000-0x5efff irq >> >> >> >> 17 on simplebus1 >> >> usbus1: EHCI version 1.0 >> >> usbus1 on ehci0 >> >> syscon_generic4: <syscon> mem 0x5f800-0x5ffff on >> >> >> >> simplebus1 >> >> >> >> sdhci_xenon0: <Armada Xenon SDHCI controller> mem >> >> 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 >> >> ahci0: <AHCI SATA controller> mem 0xe0000-0xe0177 irq >> >> >> >> 26 on simplebus1 >> >> >> >> ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier >> >> >> >> supported with FBS >> >> >> >> ahcich0: <AHCI channel> at channel 0 on ahci0 >> >> device_attach: ahcich0 attach returned 6 >> >> gpioregulator0: <GPIO controlled regulator> on ofwbus0 >> >> gpioregulator0: cannot get pin 0 >> >> gpioregulator0: cannot parse parameters >> >> device_attach: gpioregulator0 attach returned 6 >> >> cryptosoft0: <software crypto> >> >> 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 >> >> >> >> <CRC32,SHA2,SHA1,AES+PMULL> >> >> >> >> 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 >> >> <GIC,AdvSIMD,Float,EL3 32,EL2 32,EL1 32,EL0 32> >> >> 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: <Generic XHCI root HUB> at usbus0 >> >> ugen1.1: <Marvell EHCI root HUB> at usbus1 >> >> uhub0 on usbus0 >> >> uhub1 on usbus1 >> >> uhub0: <Generic XHCI root HUB, class 9/0, rev >> >> >> >> 3.00/1.00, addr 1> on >> >> >> >> usbus0 >> >> uhub1: <Marvell EHCI root HUB, class 9/0, rev >> >> >> >> 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: >> >> <fstype>:<device> [options] >> >> Mount <device> using filesystem <fstype> >> >> 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) >> >> <empty line> Abort manual input >> >> >> >> mountroot> ? >> >> >> >> List of GEOM managed disk devices: >> >> >> >> >> >> mountroot> >> >> _______________________________________________ >> >> freebsd-arm@freebsd.org <mailto: >> >> >> >> 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 <mailto: >> >> freebsd-arm-unsubscribe@freebsd.org>" >> >> >> >> >> >> _______________________________________________ >> >> freebsd-arm@freebsd.org <mailto: >> >> >> >> 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 <mailto: >> >> freebsd-arm-unsubscribe@freebsd.org>" >> >> >> >> >> >> >> >> >> >> -- >> >> Emmanuel Vadot <manu@bidouilliste.com> < >> >> >> >> manu@freebsd.org> >> >> >> >> >> >> >> >> >> >> -- >> >> Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org> >> >> >> >> >> >> >> >> -- >> >> Emmanuel Vadot <manu@bidouilliste.com> <manu@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" >> >> >> >> >> >> >> >> -- >> >> Emmanuel Vadot <manu@bidouilliste.com> <manu@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" >> >> >> >> >> >> >> >> -- >> >> Emmanuel Vadot <manu@bidouilliste.com> <manu@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" >> >> >> >> >> >> >> >> -- >> >> Emmanuel Vadot <manu@bidouilliste.com <mailto: >> >> >> >> manu@bidouilliste.com>> <manu@freebsd.org <mailto:manu@freebsd.org>> >> >> >> >> >> >> >> >> >> >> -- >> >> Emmanuel Vadot <manu@bidouilliste.com <mailto: >> >> >> >> manu@bidouilliste.com>> <manu@freebsd.org <mailto:manu@freebsd.org>> >> >> >> >> >> >> >> >> >> >> -- >> >> Emmanuel Vadot <manu@bidouilliste.com> <manu@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" >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> 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" >> ------------------------------ >> >> > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?61580006.14.1566389702495>