From owner-freebsd-arm@freebsd.org Mon Aug 26 21:15:01 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 C0F8FE5687 for ; Mon, 26 Aug 2019 21:15:01 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46HPsc0WPmz3RGr for ; Mon, 26 Aug 2019 21:14:59 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i2MJk-0007JY-L6; Mon, 26 Aug 2019 23:14:57 +0200 To: freebsd-arm , "Jeffrey Bowers" Subject: svn timeout - Re: Espressobin anyone ? References: <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> <2002575095.53.1566305166664@localhost> Date: Mon, 26 Aug 2019 23:14:24 +0200 MIME-Version: 1.0 From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: + X-Spam-Score: 1.0 X-Spam-Status: No, score=1.0 required=5.0 tests=ALL_TRUSTED, BAYES_50, HTML_MESSAGE, NORMAL_HTTP_TO_IP, NUMERIC_HTTP_ADDR autolearn=disabled version=3.4.2 X-Scan-Signature: ebb945cc479a1e91b1cea211b46a8de8 X-Rspamd-Queue-Id: 46HPsc0WPmz3RGr X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 195.190.28.88 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws X-Spamd-Result: default: False [-1.42 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.46.224,0.0.117.48]; R_SPF_ALLOW(-0.20)[+ip4:195.190.28.64/27]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain,multipart/related]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; DMARC_NA(0.00)[klop.ws]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.92)[-0.922,0]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[88.28.190.195.list.dnswl.org : 127.0.10.0]; HTTP_TO_IP(1.00)[]; IP_SCORE(-0.70)[ip: (-1.11), ipnet: 195.190.28.0/24(-0.38), asn: 47172(-2.02), country: NL(0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:47172, ipnet:195.190.28.0/24, country:NL]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes 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: Mon, 26 Aug 2019 21:15:01 -0000 On Fri, 23 Aug 2019 00:27:00 +0200, Jeffrey Bowers = = wrote: > 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. One more option I can think of. svn checkout svn://svn.freebsd.org/ports/head So not svn+ssh://, but only svn://. I just noticed my RPI3 uses that for= = sources. Something else I have seen in the past is that the local disk (like a = cheap SD-card) can be too slow and causes timeouts because SVN can't wri= te = fast enough to keep the network busy. Which might happen earlier if you = = checkout using https compared to the svn-protocol. Ronald. > > On Tue, Aug 20, 2019 at 2:01 PM Ronald Klop wro= te: >> On Wed, 21 Aug 2019 01:03:37 +0200, Jeffrey Bowers = >> wrote: >> >>> Yes sir, I can ping svn.freebsd.org. Any idea why the checkout fail= s? >> >> 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 = >>> wrote: >>>> It is not possible to 'ping https://svn.freebsd.org/ports/head'. >>>> You can 'ping svn.freebsd.org'. >>>> >>>> Ronald. >>>> = >>>> Van: Jeffrey Bowers >>>> Datum: dinsdag, 20 augustus 2019 14:36 >>>> Aan: "S=C3=B8ren Schmidt" , freebsd-arm = >>>> >>>> Onderwerp: Re: Espressobin anyone ? >>>>> I just tried to ping https://svn.freebsd.org/ports/head, and even= = >>>>> though >>>>> it scrolsl through all that text I get an error saying "could not = = >>>>> resolve >>>>> 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 = >>>>> wrote: >>>>> >>>>>> I'm still getting: svn: E000060: Operation timed out >>>>>> It goes for several minutes scrolling through text, and I feel li= ke = >>>>>> 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 i= t = >>>>>>> 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 th= e = >>>>>>> -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 = >>>>>>> >>>>>>> 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 migh= t = >>>>>>> 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 literal= ly 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 gro= wfs 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 err= or >>>>>>> once, and then the next time I ran it I got an error saying = >>>>>>> /usr/ports was >>>>>>> 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 t= he = >>>>>>> SD >>>>>>> card. >>>>>>> >>>>>>> It is however not recommend to use the AD card for random storag= e, = >>>>>>> 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 >>>>>>> issue, >>>>>>> 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 poste= d >>>>>>> >>>>>>> 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 bette= r >>>>>>> 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 wor= k >>>>>>> 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 betwe= en = >>>>>>> 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 -sta= ble >>>>>>> branch ? >>>>>>> >>>>>>> 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 >>>>>>> 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" >>>>>> >>>>>>> > >>>>>>> >>>>>>> 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 >>>>>>> latest >>>>>>> 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:non= e >>>>>>> >>>>>>> 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,0x1d= 90000-0x1d91fff,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" >>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> 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" From owner-freebsd-arm@freebsd.org Mon Aug 26 21:59:01 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 82CFCE6310 for ; Mon, 26 Aug 2019 21:59:01 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 46HQrN3nghz3yF4 for ; Mon, 26 Aug 2019 21:59:00 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-io1-xd34.google.com with SMTP id b10so32192678ioj.2 for ; Mon, 26 Aug 2019 14:59:00 -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 :cc; bh=7i2Db91Rthik1BNdRrC6NBhRZvQZZVCqz50mUqvSyD4=; b=j3JhnkVFab3oGkgWQNTae8x8w75FMyq/9KkAyspHl0sxLXbmTySHb0LaX93SYueqEf oSx7Ol48R8AdGU9yraREoiKfoKpXb2AFTZoSiQZcfSNSz4eycIArj7t+gLQ0wuF0fdqv W8eE2lqt65Y12SjuSrL6DxJvfYf1MmdhruApqdajrZDTmhbiwM+e48ZgKQwiMsba2rdr GMqDyvBgUlpLrBE0f1fiIiSgtDATvE0kCf3I40cCL/sDPSClydc6hYMbLd02CT/AxtS7 /Ocayvh4jxRn8QvR+BqXzUSk3QUQuP8sck4wMkwrcEHV61vpdknjqPtOZD9pd962MG7m huUg== 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:cc; bh=7i2Db91Rthik1BNdRrC6NBhRZvQZZVCqz50mUqvSyD4=; b=K0m2tUkjDkUI2O5PFA3h1cjZLvY2E/EZbTwdViOPWl6yaLhuWETRyMRls/o2/qpTeI DEEPFkEKTL98zkhs1Yaj6x9Dj6VeJxgMQpueaDBax5dSPodomCrDzyeXeFCryQq5jyAb xHzWEF71NqXsWTDBRW5ZrpsJ4wy67e7y3BEm7D0bLAmAoVAW89M7YkRbOJGRtPhdJFSx l/ZEIeoDYfnE+sOTMxFBQh9kg1LxQuTOx6fkyVt/T2uj7wUlxEzc5ZoF/CVkpr404nnb foWLomNJCrPZxBRSUkh8FcFfMAuGu4x6QWehwQbNnKNFdsMCx/UYNcSNpvExkgIcG+b+ ZdZQ== X-Gm-Message-State: APjAAAWERwN8iVkDq4UYvi9NabM89k8BbicB7cyr89zuMrwNde6nWSSs /TH/06hFxjKmvJFOi6ijF47W1EQTUuUT0C0HhCo= X-Google-Smtp-Source: APXvYqxADsm9OWRWqk4TSWI5p7qIK5KKO7LoaAZ2jxY3bLeJS6LEejM1v9kqeHlBJzeOZrlmO+/svCprRQFkvE8ZH8Y= X-Received: by 2002:a5e:c301:: with SMTP id a1mr4078764iok.1.1566856738928; Mon, 26 Aug 2019 14:58:58 -0700 (PDT) MIME-Version: 1.0 References: <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> <2002575095.53.1566305166664@localhost> In-Reply-To: From: Russell Haley Date: Mon, 26 Aug 2019 14:58:47 -0700 Message-ID: Subject: Re: svn timeout - Re: Espressobin anyone ? To: Ronald Klop Cc: freebsd-arm , Jeffrey Bowers X-Rspamd-Queue-Id: 46HQrN3nghz3yF4 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=j3JhnkVF; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of russhaley@gmail.com designates 2607:f8b0:4864:20::d34 as permitted sender) smtp.mailfrom=russhaley@gmail.com X-Spamd-Result: default: False [-0.99 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; URI_COUNT_ODD(1.00)[59]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.99)[-0.993,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; 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.46.224,0.0.117.48]; RCPT_COUNT_THREE(0.00)[3]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[4.3.d.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)[]; IP_SCORE(0.00)[ip: (-3.31), ipnet: 2607:f8b0::/32(-2.86), asn: 15169(-2.33), 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: Mon, 26 Aug 2019 21:59:01 -0000 On Mon, Aug 26, 2019 at 2:15 PM Ronald Klop wrote: > On Fri, 23 Aug 2019 00:27:00 +0200, Jeffrey Bowers > wrote: > > > 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. > > > One more option I can think of. > svn checkout svn://svn.freebsd.org/ports/head I reverted to using the svn protocol many moons ago because http wouldn't work at all. The svn protocol still fails a few times on any given checkout, but re-starting the checkout picks up where it left off. I always build on a PC so it's not a slow SD card problem, it seems to be a long standing issue retrieving source code. Just my observation, Russ > > > So not svn+ssh://, but only svn://. I just noticed my RPI3 uses that for > sources. > > Something else I have seen in the past is that the local disk (like a > cheap SD-card) can be too slow and causes timeouts because SVN can't > write > fast enough to keep the network busy. Which might happen earlier if you > checkout using https compared to the svn-protocol. > > Ronald. > > > > > > > On Tue, Aug 20, 2019 at 2:01 PM Ronald Klop > wrote: > >> On Wed, 21 Aug 2019 01:03:37 +0200, Jeffrey Bowers > >> 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 > >>> wrote: > >>>> It is not possible to 'ping https://svn.freebsd.org/ports/head'. > >>>> You can 'ping svn.freebsd.org'. > >>>> > >>>> Ronald. > >>>> > >>>> Van: Jeffrey Bowers > >>>> Datum: dinsdag, 20 augustus 2019 14:36 > >>>> Aan: "S=C3=B8ren Schmidt" , freebsd-arm > >>>> > >>>> Onderwerp: Re: Espressobin anyone ? > >>>>> I just tried to ping https://svn.freebsd.org/ports/head, and even > >>>>> though > >>>>> it scrolsl through all that text I get an error saying "could not > >>>>> resolve > >>>>> 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 > > >>>>> 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 > >>>>>> > >>>>>> 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 > >>>>>>> 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 > >>>>>>> > >>>>>>> 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 literall= y 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 grow= fs 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 erro= r > >>>>>>> once, and then the next time I ran it I got an error saying > >>>>>>> /usr/ports was > >>>>>>> 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 > >>>>>>> issue, > >>>>>>> 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 -stab= le > >>>>>>> branch ? > >>>>>>> > >>>>>>> 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 > >>>>>>> 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" >>>>>>> > >>>>>>> > > >>>>>>> > >>>>>>> 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 > >>>>>>> latest > >>>>>>> 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" > >>>>>>> > >>>>>>> > >>>>>>> > >>>>> _______________________________________________ > >>>>> 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" >