Date: Tue, 20 Aug 2019 14:43:55 +0200 (CEST) From: Ronald Klop <ronald-lists@klop.ws> To: Jeffrey Bowers <khantroll@gmail.com> Cc: =?utf-8?Q?S=C3=B8ren_Schmidt?= <soren.schmidt@gmail.com>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Espressobin anyone ? (svn https timeout) Message-ID: <912587110.50.1566305035850@localhost> In-Reply-To: <CAAkMUSVGZCxgoTc%2BfBgsuR-DKiwUm8gKe49W-2%2BhH2PqRc%2Bg2A@mail.gmail.com> References: <E73AFF5D-43CA-41A7-BDBA-ADEF2D342479@deepcore.dk> <CAPv3WKeCRWy65LPeeJiisPtaz=LePpVYLDAi2cj%2B2TQR=r09YA@mail.gmail.com> <1547777156.662147.1565798461515.JavaMail.zimbra@perftech.com> <0E42E605-477E-4E65-810E-BD3A8CDE2C80@gmail.com> <973015183.1067498.1565890674099.JavaMail.zimbra@perftech.com> <BD3710D7-EB87-4BD0-9CDE-E55B9412ED87@gmail.com> <20190815210311.1035f64b003e2bc85fa47ca8@bidouilliste.com> <B3AFA483-4BE4-4BC6-BCC1-4BD58A8E554C@gmail.com> <20190815233755.893e485f40ccacd79cdb3d96@bidouilliste.com> <78F5029D-A0F5-42F2-8191-07EB3A68C87B@gmail.com> <20190816152454.4e54ab5c276a543c120d909a@bidouilliste.com> <20190816171037.f808fbaba2369f179de36397@bidouilliste.com> <20190816191230.508f07f27fac21479a6716d9@bidouilliste.com> <20190816225826.ce31e8f968021944f64cb67c@bidouilliste.com> <AB07E67F-5A5E-4B5A-9D2C-6EDD4E9B478A@gmail.com> <20190817153053.5592b15b8a42982fda0fc123@bidouilliste.com> <9749945A-FDAD-47E0-947A-FA62138C2F83@gmail.com> <20190817210822.8920656bad0855b554883cf2@bidouilliste.com> <CAAkMUSXsgxP_fOJdfks%2Bd35MnyoXf1GfPO%2BC-YmTK3TpKDH7gA@mail.gmail.com> <2D6D4BDA-75EC-403F-B5E2-52A468369DE2@gmail.com> <CAAkMUSUM8bWT0Q-90jrvWjGOJopEka_LgP8sMshuS4Y7YQ29vw@mail.gmail.com> <627099DD-804B-412F-A083-768CEFCF955C@gmail.com> <CAAkMUSXd2zQQcYWDZnmibTQzLe%2BUV8rH6pk5fr=oZvevAY%2BHOQ@mail.gmail.com> <6DA8E736-8031-4BF7-8B20-CF8B0E8A7FEF@gmail.com> <CAAkMUSVRxbDBYtX0g7xbu4kLtiYQiZhjh0bdSwbCahF%2BjmTUXg@mail.gmail.com> <CAAkMUSVWWjYviHbOUXuHPxJYoahUnitdNazyusH=zGvbW1RAnw@mail.gmail.com> <ABB6B2F0-7771-49CD-84CF-B00D061EEF60@gmail.com> <CAAkMUSUfKN8Jqe7U40z9O1ypb=WuMWfgGtbnq7jLFPjp5qQfqQ@mail.gmail.com> <CAAkMUSV4p1uQOi%2Bt7b-z0uG8kjVY3qZhFd4B7fP1BjOWVRYqTA@mail.gmail.com> <BC161A1F-DC68-4AD3-BD28-1028E4BF7CCD@gmail.com> <CAAkMUSVGZCxgoTc%2BfBgsuR-DKiwUm8gKe49W-2%2BhH2PqRc%2Bg2A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
#: host svn.freebsd.org svn.freebsd.org is an alias for svnmir.geo.freebsd.org. svnmir.geo.freebsd.org has address 213.138.116.72 svnmir.geo.freebsd.org has IPv6 address 2001:41c8:112:8300::e6a:0 It might be possible that you are directed to a different server. It uses g= eo-location on DNS level. Regards, Ronald. =20 Van: Jeffrey Bowers <khantroll@gmail.com> Datum: dinsdag, 20 augustus 2019 14:33 Aan: "S=C3=B8ren Schmidt" <soren.schmidt@gmail.com>, freebsd-arm <freebsd-a= rm@freebsd.org> Onderwerp: Re: Espressobin anyone ? >=20 > 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. >=20 > Thanks! >=20 > On Tue, Aug 20, 2019 at 2:49 AM S=C3=B8ren Schmidt <soren.schmidt@gmail.c= om> > wrote: >=20 > > Hmm, I use this URL > > > > Repository Root: https://svn.freebsd.org/ports/head > > > > Not sure the svn+ssh thing works=E2=80=A6 > > > > -S=C3=B8ren > > > > > > On 20 Aug 2019, at 02.38, Jeffrey Bowers <khantroll@gmail.com> wrote: > > > > Hi all, > > > > I'm having trouble getting subversion to work. When I run: > > > > svn checkout https://svn.FreeBSD.org/ports/head /usr/ports > > > > It scrolls through many lines of text before stating: svn: E000060: > > Operation timed out > > > > When I run: > > > > svn checkout svn+ssh://repo.freebsd.org/ports/head /usr/ports > > > > It tells me that the authenticity of the host cannot be identified, 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 op= tion > > from 'ssh' in the [tunnels] section of your Subversion configuration fi= le. > > > > Any ideas? > > > > Thanks in advance! > > > > On Mon, Aug 19, 2019 at 8:51 PM Jeffrey Bowers <khantroll@gmail.com> > > wrote: > > > > I didn't think it remounting. Thank you! > > > > On Mon, Aug 19, 2019 at 11:39 AM S=C3=B8ren Schmidt <soren.schmidt@gmai= l.com> > > wrote: > > > > Hi Jeffrey > > > > You need to unmount the /tmp filesystem :) > > You can do that permanently by commenting it out in /etc/fstab > > > > > > On 19 Aug 2019, at 21.45, Jeffrey Bowers <khantroll@gmail.com> wrote: > > > > Hi Soren, > > > > I'm getting the same error message. Any other ideas what it might be? > > It's got to be something in the partition scheme or the file permission= s, > > but I'm just not sure what. > > <image.png> > > > > On Sun, Aug 18, 2019 at 10:03 AM Jeffrey Bowers <khantroll@gmail.com> > > wrote: > > > > D=E2=80=99Oh! I thought I too care of that with gpart. I literally miss= ed growfs > > part of the instructions.. > > > > On Sun, Aug 18, 2019 at 10:00 AM S=C3=B8ren Schmidt <soren.schmidt@gmai= l.com> > > wrote: > > > > Hi > > > > You are out of space :) > > > > Boot the board into singleuser mode, and do =E2=80=9Cservice growfs sta= rt=E2=80=9D, > > that will expand you / filesystem to the entire SD card=E2=80=A6 > > > > -S=C3=B8ren > > > > On 18 Aug 2019, at 14.50, Jeffrey Bowers <khantroll@gmail.com> wrote: > > > > Sure thing! Here's the screenshot! > > <image.png> > > > > > > On Sun, Aug 18, 2019 at 7:35 AM S=C3=B8ren Schmidt <soren.schmidt@gmail= .com> > > wrote: > > > > Hi > > > > Can I have you paste the output from df -h ? > > > > You should be able to utilise the full SD card=E2=80=A6 > > > > -S=C3=B8ren > > > > On 18 Aug 2019, at 14.29, Jeffrey Bowers <khantroll@gmail.com> wrote: > > > > Hi, > > > > Just make sure I understand the process, I should hook up a hard disk > > and map it to to /TMP ? > > > > I already tried just unmapping /tmp, and it gave me the same error > > once, and then the next time I ran it I got an error saying /usr/ports = was > > out of space )which I guess I shouldn=E2=80=99t mount to another direct= or on the > > hard drive? > > > > On Sun, Aug 18, 2019 at 5:11 AM S=C3=B8ren Schmidt <soren.schmidt@gmail= .com> > > wrote: > > > > Hi Jeffrey > > > > You can unmount the memory disk on /tmp to get at the space on the SD > > card. > > > > It is however not recommend to use the AD card for random storage, it > > will wear out fast, that=E2=80=99s why the memory disk is setup. > > > > You could connect a SSD og laptop disk to the SATA interface and use > > that for the workload. > > > > However compiling is slow, its much much faster to cross compile on a > > PC=E2=80=A6 > > > > -S=C3=B8ren > > > > On 18 Aug 2019, at 00.22, Jeffrey Bowers <khantroll@gmail.com> wrote: > > > > Hi! I've got a new one :) > > I'm trying to do an svn checkout to fix the pkg problem, but it tells > > me it can't write to a to a temp folder because there is no room left o= n > > the device. However, FreeBSD partition is 29GB. It's never also never t= he > > same file in TMP that it can't write to. Here is a screenshot of the is= sue, > > along with the output of gpart: > > > > <image.png> > > > > Any ideas? > > > > Thanks! > > > > > > On Sat, Aug 17, 2019 at 2:08 PM Emmanuel Vadot <manu@bidouilliste.com> > > wrote: > > > > On Sat, 17 Aug 2019 17:14:36 +0200 > > S=C3=B8ren Schmidt <soren.schmidt@gmail.com> wrote: > > > > HI > > > > Well, I have a whole forrest of tree?s here, but the error posted > > > > here was on a clean checkout. > > > > > > Anyhow, with the latest changes to -stable and the two > > > > RF_SHAREABLE patches from -current all works. > > > > I've reverted the commits, see > > https://github.com/evadot/freebsd/commits/a37x0_gpio for a better > > way > > to deal with this issue. > > I'm waiting for mmel@ as he wrote the syscon_get_default_handle > > part. > > > > It would be nice with the etherswitch changes as well so VLAN > > > > tagging etc was standard. > > > > > > -S=C3=B8ren > > > > PS: given up on bottom & inline popsting, top posting is all the > > > > rage now (yeah I miss elm etc :) ) > > > > > > On 17 Aug 2019, at 15.30, Emmanuel Vadot <manu@bidouilliste.com> > > > > wrote: > > > > > > On Sat, 17 Aug 2019 11:07:22 +0200 > > S=C3=B8ren Schmidt <soren.schmidt@gmail.com <mailto: > > > > soren.schmidt@gmail.com>> wrote: > > > > > > Hi Emmunuel > > > > Yes the 3720 gpio driver I already back ported long ago, its > > > > needed, I?m happy its now part of std stable 12! > > > > > > Would have been nice of you to say that you were not running a > > > > clean > > > > tree. > > > > My issue seems to be the inclusion of the phy_usb driver, if I > > > > leave that out, I?m back to normal.. > > > > > > What make you think this is this driver ? What works/doesn't work > > with it ? could you provide logs. > > > > I?ll have have another go at the latest -stable sources during > > > > the weekend and see how it goes. > > > > > > Thanks for looking into this, with a little cooperation we?ll > > > > get this solved for the greater good.. > > > > > > -S=C3=B8ren > > > > > > P.S. Please stop top posting, it's really hard to read the > > > > conversation > > > > > > On 16 Aug 2019, at 22.58, Emmanuel Vadot < > > > > manu@bidouilliste.com> wrote: > > > > > > On Fri, 16 Aug 2019 19:12:30 +0200 > > Emmanuel Vadot <manu@bidouilliste.com <mailto: > > > > manu@bidouilliste.com>> wrote: > > > > > > On Fri, 16 Aug 2019 17:10:37 +0200 > > Emmanuel Vadot <manu@bidouilliste.com> wrote: > > > > On Fri, 16 Aug 2019 15:24:54 +0200 > > Emmanuel Vadot <manu@bidouilliste.com> wrote: > > > > On Fri, 16 Aug 2019 07:28:59 +0200 > > S=C3=B8ren Schmidt <soren.schmidt@gmail.com> wrote: > > > > Hi > > > > Very simple, reverting sys/gnu/dts to what was before > > > > 350595 (actually 350592). > > > > Thats what we have svn for ? > > > > > > If I asked how it was to have the svn command that you > > > > used, I want to > > > > make sure that you didn't revert anything else, like do you > > > > have > > > > r350596 and r350628 ? > > > > That does make my bananapi work again, no other changes > > > > just a recompiled kernel. > > > > > > That + copying the dtb to the fat32 partition ? > > > > Can you post the dtb somewhere. > > > > However it does not bring the Espressobin back to life, > > > > thats something in one of the ~30 other files that changed between thos= e > > two revisions. > > > > > > What Linux version of DTS are you using then ? The ones > > > > that were in > > > > stable/12 when it was branched (4.18) or a later revision ? > > > > > > So I think that I've found the problem on the Espressobin. > > I think that the problem comes from the simple-mfd driver > > > > that I've > > > > mfc in r350600. > > The pinctrl/gpio controller compatible is > > "marvell,armada3710-nb-pinctrl", "syscon", "simple-mfd" and > > > > it attaches > > > > at BUS_PASS_INTERRUPT while the simple_mfd driver attaches at > > BUS_PASS_BUS (so earlier) which means that no gpio > > > > controller will be > > > > available for sdhci to detect the card. > > > > If someone with a non-working espressobin could post a full > > > > verbose > > > > boot log that would help me confirming that this is the case. > > I'll try to find a solution on how to solve this problem. > > > > > > So this wasn't the problem but I've found it, see r351129 and > > > > r351130 > > > > > > SD card now work again in HEAD, I'll have a look at stable > > > > later next > > > > week. > > > > > > I've did a quick test and I've MFC r348880, r348882 and > > > > r349596, the > > > > two other commits needed to be mfc'ed are the one I did today > > > > on head, > > > > I'll do that next week. > > With them sdcard is working again on stable/12 > > > > -S=C3=B8ren > > > > On 15 Aug 2019, at 23.37, Emmanuel Vadot < > > > > manu@bidouilliste.com> wrote: > > > > > > On Thu, 15 Aug 2019 21:56:23 +0200 > > S=C3=B8ren Schmidt <soren.schmidt@gmail.com> wrote: > > > > > > Well, I don?t care where you are from and what color you > > > > have :) > > > > > > Now, if I update my stable12 sources to r350595 the > > > > bananapi breaks, if revert sys/gnu/dts it works again, go figure.. > > > > > > Reverting to what ? and how ? > > > > Because I've just test 12-stable and I have the problem > > > > that I've said > > > > in my previous mail so setting > > > > hw.regulator.disable_unused=3D0 is the > > > > work around. > > The problem is in twsi not in the DTS so I'm curious how > > > > reverting > > > > only the dts fixes this problem. > > > > The r351099 fix is already like that in -stable, and not > > > > part of the problem. > > > > > > -S=C3=B8ren > > > > > > On 15 Aug 2019, at 21.03, Emmanuel Vadot < > > > > manu@bidouilliste.com> wrote: > > > > > > On Thu, 15 Aug 2019 19:48:54 +0200 > > S=C3=B8ren Schmidt <soren.schmidt@gmail.com> wrote: > > > > Hi Mit! > > > > Right, I suspected that, 12-stable broke many embedded > > > > systems between r350592 and r350595 where all the latest and greatest D= TS > > files was pulled in, I guess the same holds for -current. > > > > > > -S=C3=B8ren > > > > > > Mhm it's fun that you think that DTS import is the > > > > source of all your > > > > problems, I get it, it's easy to blame the French guy > > > > that bulk import > > > > the DTS, he surely don't know what he is doing. > > Anyway, two problems were raised in this thread : > > > > 1) BananaPi (A20) doesn't boot > > 2) Espressobin sd support is broken > > > > I've just looked at the BananaPi problem today, I've > > > > fixed a first > > > > problem in r351099. > > The main problem is that when we disable the unused > > > > regulators we hang > > > > when trying to disabling ldo3. It's weird because the > > > > board doesn't use > > > > LDO3 (which is why we are disabling it, it's unused). > > > > The problem is in > > > > twsi I think as only leaving the part in axp209 that > > > > read the > > > > voltage register value make FreeBSD hang. > > I'll have a proper look later, in the meantime you can > > > > set > > > > hw.regulator.disable_unused=3D0 > > in /boot/loader.conf > > This isn't a DTS problem. > > > > For Espressobin I haven't found any thing related to SD > > > > in the DTS > > > > updates since the import, the only things slighly > > > > related are mmc and > > > > sdio. > > So if someone could find which DTS import broke this I > > > > can have a look. > > > > > > > > On 15 Aug 2019, at 19.37, Mit Matelske <mit@pt.net> > > > > wrote: > > > > > > Yeah, that was the problem. I went back to r348882 > > > > and everything worked out of the box. > > > > > > Thanks again for the hand holding! > > > > Mit > > > > From: "S=C3=B8ren Schmidt" <soren.schmidt@gmail.com > > > > <mailto:soren.schmidt@gmail.com>> > > > > To: "Mit Matelske" <mit@pt.net <mailto:mit@pt.net>> > > Cc: "Marcin Wojtas" <mw@semihalf.com <mailto: > > > > mw@semihalf.com>>, "freebsd-arm" <freebsd-arm@freebsd.org <mailto: > > freebsd-arm@freebsd.org>> > > > > Sent: Wednesday, August 14, 2019 1:33:04 PM > > Subject: Re: Espressobin anyone ? > > > > > > It might simply be broken in -current (again). > > > > I just updated my stable12 tree and I pulled in new > > > > .dts files for just about anything? > > > > > > Needless to say, it broke the Espressobin?s SD > > > > support, it now fails just like yours.. > > > > > > It also broke allwinner builds and what not, so I?m > > > > just going back in time again :) > > > > > > I wonder why there is this overwhelming need to > > > > import stuff that breaks things right, left and center in a -stable bra= nch > > ? > > > > That would have earned you the pointy hat back when?. > > > > -S=C3=B8ren > > > > > > On 14 Aug 2019, at 18.01, Mit Matelske <mit@pt.net > > > > <mailto:mit@pt.net>> wrote: > > > > > > Marcin- > > > > Sorry I didn't reply yesterday. I didn't have any > > > > luck with that either. I tried a lot of permutations. > > > > > > Not saying for 100% it doesn't work, but I couldn't > > > > get it to work! > > > > > > Mit > > > > From: "Marcin Wojtas" <mw@semihalf.com <mailto: > > > > mw@semihalf.com>> > > > > To: "Mit Matelske" <mit@pt.net <mailto:mit@pt.net>> > > Cc: "S=C3=B8ren Schmidt" <soren.schmidt@gmail.com <mailto: > > > > soren.schmidt@gmail.com>>, "freebsd-arm" <freebsd-arm@freebsd.org > > <mailto:freebsd-arm@freebsd.org>> > > > > Sent: Wednesday, August 14, 2019 10:41:04 AM > > Subject: Re: Espressobin anyone ? > > > > Hi Mit, > > Since you are using the latest 13-current, could you > > > > please try if passing rootdev via u-boot bootargs (please see my previo= us > > email) works for you without the loader modification? > > > > > > Best regards, > > Marcin > > > > ?r., 14 sie 2019 o 16:29 Mit Matelske <mit@pt.net > > > > <mailto:mit@pt.net>> napisa?(a): > > > > Soren- > > > > Thanks for the info. I'll grab a couple more SD > > > > cards at lunch. This one is a new Samsung 32GB. I'll also try 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" <soren.schmidt@gmail.com > > > > <mailto:soren.schmidt@gmail.com>> > > > > To: "Mit Matelske" <mit@pt.net <mailto:mit@pt.net>> > > Cc: "Marcin Wojtas" <mw@semihalf.com <mailto: > > > > mw@semihalf.com>>, "freebsd-arm" <freebsd-arm@freebsd.org <mailto: > > freebsd-arm@freebsd.org>> > > > > Sent: Wednesday, August 14, 2019 2:30:31 AM > > Subject: Re: Espressobin anyone ? > > > > Hi Mit > > Hmm, from your earlier posted dmesgs it looks like > > > > the SD card is not getting detected properly.. > > > > > > I get this output: > > > > sdhci_xenon0: <Armada Xenon SDHCI controller> mem > > > > 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 > > > > mmc0: <MMC/SD bus> on sdhci_xenon0 > > ?snip? > > mmcsd0: 16GB <SDHC SD16G 3.0 SN 01E28E67 MFG 07/2017 > > > > by 39 PH> at mmc0 50.0MHz/4bit/65535-block > > > > > > The problem you see was fixed for me by r348882, > > > > maybe it got broken later, I havn?t backported the later changes.. > > > > > > Have you tried another SD card ? I have found 2 of > > > > mine that the espressobin doesn?t like, but works fine with bananapi an= d > > friends... > > > > > > -S=C3=B8ren > > > > On 13 Aug 2019, at 23.30, Mit Matelske <mit@pt.net > > > > <mailto:mit@pt.net>> wrote: > > > > > > Soren- > > > > Thanks for the code snippet! That will fix one of > > > > the problems. > > > > > > I still can't mount my filesystem, though. I think > > > > I'm doing something really simple, wrong. I believe I'm running the la= test > > code and added some printfs to show the kernel setting the regulator: > > > > > > > > usbus1 on ehci0 > > syscon_generic4: <syscon> mem 0x5f800-0x5ffff on > > > > simplebus1 > > > > sdhci_xenon0: > > > > regulator_get_by_ofw_property(vqmmc-supply) =3D 19 > > > > sdhci_xenon0: vqmmc-supply regulator found > > sdhci_xenon0: <Armada Xenon SDHCI controller> mem > > > > 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 > > > > ahci0: <AHCI SATA controller> mem 0xe0000-0xe0177 irq > > > > 26 on simplebus1 > > > > > > > > Could there be a problem with how I am setting up my > > > > filesystem? I've tried both freebsd-ufs and freebsd as the type, 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" <soren.schmidt@gmail.com > > > > <mailto:soren.schmidt@gmail.com>> > > > > To: "Marcin Wojtas" <mw@semihalf.com <mailto: > > > > mw@semihalf.com>> > > > > Cc: "Mit Matelske" <mit@pt.net <mailto:mit@pt.net>>, > > > > "freebsd-arm" <freebsd-arm@freebsd.org <mailto: > > freebsd-arm@freebsd.org>> > > > > Sent: Tuesday, August 13, 2019 12:55:09 PM > > Subject: Re: Espressobin anyone ? > > > > Hi > > That doesn?t seen to work on the espressobin, or > > > > least I can?t get it to pick it up. > > > > > > I use this patch as a workaround: > > > > Index: main.c > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > --- main.c (revision 350496) > > +++ main.c (working copy) > > @@ -463,6 +462,13 @@ > > int rv; > > char *rootdev; > > > > +#if defined(__aarch64__) > > + /* SOS HACK in rootdev, at least Espressobin > > > > gets this wrong */ > > > > + printf("Setting currdev hack\n"); > > + set_currdev("disk0p2"); > > + return (0); > > +#endif > > + > > /* > > * First choice: if rootdev is already set, use > > > > that, even if > > > > * it's wrong. > > > > Its not pretty but it does the job until I get time > > > > to look into why bootargs aren?t passed / won?t stick, probably somethi= ng I > > havn?t backported to my -stable12 sources yet... > > > > > > -S=C3=B8ren > > > > On 13 Aug 2019, at 01.38, Marcin Wojtas < > > > > mw@semihalf.com <mailto:mw@semihalf.com>> wrote: > > > > > > Hi, > > > > Not sure if it's what you are looking for, but in > > > > order to autoboot, I > > > > simply pass 'rootdev=3DdiskXpY' in the bootargs > > > > variable. Here's example from > > > > A3720-DB (same should work on EspressoBin): > > > > Marvell>> set bootargs "rootdev=3Ddisk1p1";usb reset; > > > > fatload usb 0:1 > > > > ${fdt_addr} armada-3720-db.dtb; fatload usb 0:1 > > > > ${kernel_addr} > > > > boot/loader.efi; bootefi ${kernel_addr} ${fdt_addr} > > resetting USB... > > USB0: Register 2000104 NbrPorts 2 > > Starting the controller > > USB XHCI 1.00 > > USB1: USB EHCI 1.00 > > - ______ ____ _____ _____ > > | ____| | _ \ / ____| __ \ > > | |___ _ __ ___ ___ | |_) | (___ | | | | > > | ___| '__/ _ \/ _ \| _ < \___ \| | | | > > | | | | | __/ __/| |_) |____) | |__| | > > | | | | | | || | | | > > |_| |_| \___|\___||____/|_____/|_____/ > > ``` > > ` > > ????????????Welcome to FreeBSD????????????? s` > > > > `.....---.......--.``` > > > > -/ > > ? ? +o > > > > .--` /y:` > > > > +. > > ? 1. Boot Multi user [Enter] ? > > > > yo`:. :o > > > > `+- > > ? 2. Boot Single user ? y/ > > > > -/` -o/ > > > > ? 3. Escape to loader prompt ? .- > > ::/sy+:. > > ? 4. Reboot ? / > > > > `-- > > > > / > > ? ? `: > > :` > > ? Options: ? `: > > :` > > ? 5. Kernel: default/kernel (1 of 1) ? / > > / > > ? 6. Boot Options ? .- > > -. > > ? ? -- > > > > -. > > > > ? ? > > > > `:` `:` > > > > ? ? > > > > .-- `--. > > > > ??????????????????????????????????????????? > > > > .---.....----. > > > > Autoboot in 9 seconds, hit [Enter] to boot or any > > > > other key to stop > > > > > > Loading kernel... > > /boot/kernel/kernel text=3D0x95047c > > > > data=3D0x1919d0+0x84aa94 > > > > syms=3D[0x8+0x13aaa8+0x8+0x12610d] > > Loading configured modules... > > can't find '/boot/entropy' > > Using DTB provided by EFI at 0x8000000. > > ---<<BOOT>>--- > > KDB: debugger backends: ddb > > KDB: current backend: ddb > > Copyright (c) 1992-2019 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, > > > > 1991, 1992, 1993, 1994 > > > > The Regents of the University of California. All > > > > rights reserved. > > > > FreeBSD is a registered trademark of The FreeBSD > > > > Foundation. > > > > FreeBSD 13.0-CURRENT > > > > 17a1fc80d57-c261519(upstream_master) GENERIC arm64 > > > > FreeBSD clang version 8.0.0 (tags/RELEASE_800/final > > > > 356365) (based on LLVM > > > > 8.0.0) > > WARNING: WITNESS option enabled, expect reduced > > > > performance. > > > > VT: init without driver. > > Starting CPU 1 (1) > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > [...] > > > > Best regards, > > Marcin > > > > pon., 12 sie 2019 o 23:14 Mit Matelske <mit@pt.net > > > > <mailto:mit@pt.net>> napisa?(a): > > > > > > > > Soren- > > > > Thanks for the quick response. I built this kernel > > > > with revision 350924. > > > > I'll dig into whats going on in the morning. > > > > Mind posting your diff for your loader.efi? > > > > Thanks again! > > > > Mit > > > > > > ----- Original Message ----- > > From: "S=C3=B8ren Schmidt" <soren.schmidt@gmail.com > > > > <mailto:soren.schmidt@gmail.com>> > > > > To: "Mit Matelske" <mit@pt.net <mailto:mit@pt.net>> > > Cc: "tscho" <johannes@t-beutel.com <mailto: > > > > johannes@t-beutel.com>>, "freebsd-arm" < > > > > freebsd-arm@freebsd.org <mailto: > > > > freebsd-arm@freebsd.org>> > > > > Sent: Monday, August 12, 2019 3:49:48 PM > > Subject: Re: Espressobin anyone ? > > > > Hi > > > > Looks like your sources may be too old, you need to > > > > be at least at r348882 > > > > to get the fix for the SD card VCC regulator. > > > > That change fixed it for me backported to 12-stable... > > > > The currdev problem still exists, I have it hardwired > > > > in my loader for > > > > aarch64 :) > > > > -S=C3=B8ren > > > > > > On 12 Aug 2019, at 21.06, Mit Matelske <mit@pt.net > > > > <mailto:mit@pt.net>> wrote: > > > > > > I'm having a couple little hiccups booting this board > > > > also. One has > > > > been commented on already, that I can't get the > > > > loader to automatically > > > > start loading the kernel on "disk0p2"... > > > > The second, is that the kernel can't find the SD card > > > > after booting so > > > > it can't mount the root filesystem. I'm using the > > > > dts/dtb and kernel from > > > > the 13-current branch. > > > > Thanks for any and all help. I haven't used u-boot > > > > in about decade. > > > > Spoiled by the x86 platform. > > > > Mit Matelske > > > > > > ***U-boot environment:*** > > > > > > Marvell>> printenv > > baudrate=3D115200 > > bootargs=3Dconsole=3DttyMV0,115200 > > > > earlycon=3Dar3700_uart,0xd0012000 > > > > root=3D/dev/mmcblk0p1 rw rootwait net.ifnames=3D0 > > > > biosdevname=3D0 > > > > bootcmd=3Dmmc dev 0; fatload mmc 0:1 $kernel_addr > > > > $image_name;fatload mmc > > > > 0:1 $fdt_addr $fdt_name; bootefi $kernel_addr > > > > $fdt_addr > > > > bootdelay=3D2 > > bootmmc=3Dmmc dev 0; fatload mmc 0:1 $kernel_addr > > > > $image_name;fatload mmc > > > > 0:1 $fdt_addr $fdt_name; bootefi $kernel_addr > > > > $fdt_addr > > > > console=3Dconsole=3DttyMV0,115200 > > > > earlycon=3Dar3700_uart,0xd0012000 > > > > eth1addr=3D00:51:82:11:22:01 > > eth2addr=3D00:51:82:11:22:02 > > eth3addr=3D00:51:82:11:22:03 > > ethact=3Dneta@30000 > > ethaddr=3DF0:AD:4E:09:6B:8F > > ethprime=3Deth0 > > fdt_addr=3D0x4f00000 > > fdt_high=3D0xffffffffffffffff > > fdt_name=3Defi/boot/armada-3720-espressobin.dtb > > fdtcontroladdr=3D3f7161b8 > > gatewayip=3D10.4.50.254 > > get_images=3Dtftpboot $kernel_addr $image_name; > > > > tftpboot $fdt_addr > > > > $fdt_name; run get_ramfs > > get_ramfs=3Dif test "${ramfs_name}" !=3D "-"; then setenv > > > > ramfs_addr > > > > 0x8000000; tftpboot $ramfs_addr $ramfs_name; else > > > > setenv ramfs_addr -;fi > > > > hostname=3Dmarvell > > image_name=3Defi/freebsd/loader.efi > > initrd_addr=3D0xa00000 > > initrd_size=3D0x2000000 > > ipaddr=3D0.0.0.0 > > kernel_addr=3D0x5000000 > > loadaddr=3D0x5000000 > > netdev=3Deth0 > > netmask=3D255.255.255.0 > > ramfs_addr=3D0x8000000 > > ramfs_name=3D- > > root=3Droot=3D/dev/nfs rw > > rootpath=3D/srv/nfs/ > > serverip=3D0.0.0.0 > > set_bootargs=3Dsetenv bootargs $console $root > > > > ip=3D$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:none > > > > nfsroot=3D$serverip:$rootpath $extra_params > > stderr=3Dserial@12000 > > stdin=3Dserial@12000 > > stdout=3Dserial@12000 > > > > > > ***Full boot logs:*** > > > > > > U-Boot 2017.03-armada-17.10.2-g14aeedc (Jun 01 2018 - > > > > 15:39:10 +0800) > > > > > > Model: Marvell Armada 3720 Community Board ESPRESSOBin > > CPU @ 1000 [MHz] > > L2 @ 800 [MHz] > > TClock @ 200 [MHz] > > DDR @ 800 [MHz] > > DRAM: 1 GiB > > U-Boot DT blob at : 000000003f7161b8 > > Comphy-0: USB3 5 Gbps > > Comphy-1: PEX0 2.5 Gbps > > Comphy-2: SATA0 6 Gbps > > SATA link 0 timeout. > > AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA > > > > mode > > > > flags: ncq led only pmp fbss pio slum part sxs > > PCIE-0: Link down > > MMC: sdhci@d0000: 0, sdhci@d8000: 1 > > SF: Detected mx25u3235f with page size 256 Bytes, > > > > erase size 64 KiB, > > > > total 4 MiB > > Net: eth0: neta@30000 [PRIME] > > Hit any key to stop autoboot: 0 > > switch to partitions #0, OK > > mmc0 is current device > > reading efi/freebsd/loader.efi > > 603872 bytes read in 49 ms (11.8 MiB/s) > > reading efi/boot/armada-3720-espressobin.dtb > > 15946 bytes read in 17 ms (916 KiB/s) > > ## Starting EFI application at 05000000 ... > > Scanning disk sdhci@d0000.blk <mailto:sdhci@d0000.blk > > > > ... > > > > Card did not respond to voltage select! > > mmc_init: -95, time 50 > > Found 1 disks > > Consoles: EFI console > > FreeBSD/arm64 EFI loader, Revision 1.1 > > > > Command line arguments: loader.efi > > EFI version: 2.05 > > EFI Firmware: Das U-boot (rev 0.00) > > Console: efi (0) > > Failed to find bootable partition > > Startup error in /boot/lua/loader.lua: seconds > > LUA ERROR: cannot open /boot/lua/loader.lua: invalid > > > > argument. > > > > > > can't load 'kernel' > > > > Type '?' for a list of commands, 'help' for more > > > > detailed help. > > > > OK > > OK set currdev=3Ddisk0p2 > > OK boot > > > > /boot/kernel/kernel text=3D0x97d6a0 > > > > data=3D0x191b50+0x84ae94 > > > > syms=3D[0x8+0x137dd8+0x8+0x126260] > > Using DTB provided by EFI at 0x8000000. > > ---<<BOOT>>--- > > KDB: debugger backends: ddb > > KDB: current backend: ddb > > Copyright (c) 1992-2019 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, > > > > 1991, 1992, 1993, 1994 > > > > The Regents of the University of California. All > > > > rights reserved. > > > > FreeBSD is a registered trademark of The FreeBSD > > > > Foundation. > > > > FreeBSD 13.0-CURRENT GENERIC arm64 > > FreeBSD clang version 6.0.1 (tags/RELEASE_601/final > > > > 335540) (based on > > > > LLVM 6.0.1) > > WARNING: WITNESS option enabled, expect reduced > > > > performance. > > > > VT: init without driver. > > Starting CPU 1 (1) > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > arc4random: WARNING: initial seeding bypassed the > > > > cryptographic random > > > > device because it was not yet seeded and the knob > > > > 'bypass_before_seeding' > > > > was enabled. > > random: entropy device external interface > > MAP 3e681000 mode 2 pages 1 > > MAP 3ffa6000 mode 2 pages 1 > > kbd0 at kbdmux0 > > ofwbus0: <Open Firmware Device Tree> > > simplebus0: <Flattened device tree simple bus> on > > > > ofwbus0 > > > > simplebus1: <Flattened device tree simple bus> on > > > > simplebus0 > > > > simple_mfd0: <Simple MFD (Multi-Functions Device)> mem > > 0x13800-0x138ff,0x13c00-0x13c1f on simplebus1 > > simple_mfd1: <Simple MFD (Multi-Functions Device)> mem > > 0x18800-0x188ff,0x18c00-0x18c1f on simplebus1 > > psci0: <ARM Power State Co-ordination Interface > > > > Driver> on ofwbus0 > > > > gic0: <ARM Generic Interrupt Controller v3.0> mem > > > > > > 0x1d00000-0x1d0ffff,0x1d40000-0x1d7ffff,0x1d80000-0x1d81fff,0x1d90000-0= x1d91fff,0x1da0000-0x1dbffff > > > > irq 27 on simplebus1 > > gpio0: <Armada 37x0 North Bridge GPIO Controller> mem > > 0x13800-0x138ff,0x13c00-0x13c1f irq > > > > 28,29,30,31,32,33,34,35,36,37,38,39 on > > > > simple_mfd0 > > gpio0: cannot allocate memory window > > device_attach: gpio0 attach returned 6 > > gpio0: <Armada 37x0 South Bridge GPIO Controller> mem > > 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 on > > > > simple_mfd1 > > > > gpio0: cannot allocate memory window > > device_attach: gpio0 attach returned 6 > > gpioregulator0: <GPIO controlled regulator> on ofwbus0 > > gpioregulator0: cannot get pin 0 > > gpioregulator0: cannot parse parameters > > device_attach: gpioregulator0 attach returned 6 > > generic_timer0: <ARMv8 Generic Timer> irq 0,1,2,3 on > > > > ofwbus0 > > > > Timecounter "ARM MPCore Timecounter" frequency > > > > 12500000 Hz quality 1000 > > > > Event timer "ARM MPCore Eventtimer" frequency > > > > 12500000 Hz quality 1000 > > > > gpio0: <Armada 37x0 North Bridge GPIO Controller> mem > > 0x13800-0x138ff,0x13c00-0x13c1f irq > > > > 28,29,30,31,32,33,34,35,36,37,38,39 on > > > > simple_mfd0 > > gpio0: cannot allocate memory window > > device_attach: gpio0 attach returned 6 > > gpio0: <Armada 37x0 South Bridge GPIO Controller> mem > > 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 on > > > > simple_mfd1 > > > > gpio0: cannot allocate memory window > > device_attach: gpio0 attach returned 6 > > gpioregulator0: <GPIO controlled regulator> on ofwbus0 > > gpioregulator0: cannot get pin 0 > > gpioregulator0: cannot parse parameters > > device_attach: gpioregulator0 attach returned 6 > > gpio0: <Armada 37x0 North Bridge GPIO Controller> mem > > 0x13800-0x138ff,0x13c00-0x13c1f irq > > > > 28,29,30,31,32,33,34,35,36,37,38,39 on > > > > simple_mfd0 > > gpio0: cannot allocate memory window > > device_attach: gpio0 attach returned 6 > > gpio0: <Armada 37x0 South Bridge GPIO Controller> mem > > 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 on > > > > simple_mfd1 > > > > gpio0: cannot allocate memory window > > device_attach: gpio0 attach returned 6 > > gpioregulator0: <GPIO controlled regulator> on ofwbus0 > > gpioregulator0: cannot get pin 0 > > gpioregulator0: cannot parse parameters > > device_attach: gpioregulator0 attach returned 6 > > gpio0: <Armada 37x0 North Bridge GPIO Controller> mem > > 0x13800-0x138ff,0x13c00-0x13c1f irq > > > > 28,29,30,31,32,33,34,35,36,37,38,39 on > > > > simple_mfd0 > > gpio0: cannot allocate memory window > > device_attach: gpio0 attach returned 6 > > gpio0: <Armada 37x0 South Bridge GPIO Controller> mem > > 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 on > > > > simple_mfd1 > > > > gpio0: cannot allocate memory window > > device_attach: gpio0 attach returned 6 > > gpioregulator0: <GPIO controlled regulator> on ofwbus0 > > gpioregulator0: cannot get pin 0 > > gpioregulator0: cannot parse parameters > > device_attach: gpioregulator0 attach returned 6 > > gpio0: <Armada 37x0 North Bridge GPIO Controller> mem > > 0x13800-0x138ff,0x13c00-0x13c1f irq > > > > 28,29,30,31,32,33,34,35,36,37,38,39 on > > > > simple_mfd0 > > gpio0: cannot allocate memory window > > device_attach: gpio0 attach returned 6 > > gpio0: <Armada 37x0 South Bridge GPIO Controller> mem > > 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 on > > > > simple_mfd1 > > > > gpio0: cannot allocate memory window > > device_attach: gpio0 attach returned 6 > > gpioregulator0: <GPIO controlled regulator> on ofwbus0 > > gpioregulator0: cannot get pin 0 > > gpioregulator0: cannot parse parameters > > device_attach: gpioregulator0 attach returned 6 > > cpulist0: <Open Firmware CPU Group> on ofwbus0 > > cpu0: <Open Firmware CPU> on cpulist0 > > cpu1: <Open Firmware CPU> on cpulist0 > > pmu0: <Performance Monitoring Unit> irq 4 on ofwbus0 > > syscon_generic0: <syscon> mem 0xd000-0xdfff on > > > > simplebus1 > > > > syscon_generic1: <syscon> mem 0x11500-0x1153f on > > > > simplebus1 > > > > uart0: <Marvell Armada 3700 UART> mem 0x12000-0x121ff > > > > irq 9,10,11 on > > > > simplebus1 > > uart0: console (115200,n,8,1) > > gpio0: <Armada 37x0 North Bridge GPIO Controller> mem > > 0x13800-0x138ff,0x13c00-0x13c1f irq > > > > 28,29,30,31,32,33,34,35,36,37,38,39 on > > > > simple_mfd0 > > gpio0: cannot allocate memory window > > device_attach: gpio0 attach returned 6 > > syscon_generic2: <syscon> mem 0x14000-0x1405f on > > > > simplebus1 > > > > gpio0: <Armada 37x0 South Bridge GPIO Controller> mem > > 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 on > > > > simple_mfd1 > > > > gpio0: cannot allocate memory window > > device_attach: gpio0 attach returned 6 > > mvneta0: <NETA controller> mem 0x30000-0x33fff irq 14 > > > > on simplebus1 > > > > mvneta0: version is 10 > > mvneta0: Ethernet address: 00:a6:39:ca:e8:00 > > mdio0: <MDIO> on mvneta0 > > mdioproxy0: <MII/MDIO proxy, MDIO side> on mdio0 > > e6000sw0: <Marvell 88E6341> on mdio0 > > e6000sw0: multi-chip addressing mode (0x1) > > e6000sw0: CPU port at 0 > > e6000sw0: fixed port at 0 > > e6000sw0: PHY at port 1 > > miibus0: <MII bus> on e6000sw0 > > e1000phy0: <Marvell 88E1000 Gigabit PHY> PHY 17 on > > > > miibus0 > > > > e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, > > > > 100baseTX-FDX, > > > > 1000baseT, 1000baseT-master, 1000baseT-FDX, > > > > 1000baseT-FDX-master, auto > > > > e6000sw0: PHY at port 2 > > miibus1: <MII bus> on e6000sw0 > > e1000phy1: <Marvell 88E1000 Gigabit PHY> PHY 18 on > > > > miibus1 > > > > e1000phy1: none, 10baseT, 10baseT-FDX, 100baseTX, > > > > 100baseTX-FDX, > > > > 1000baseT, 1000baseT-master, 1000baseT-FDX, > > > > 1000baseT-FDX-master, auto > > > > e6000sw0: PHY at port 3 > > miibus2: <MII bus> on e6000sw0 > > e1000phy2: <Marvell 88E1000 Gigabit PHY> PHY 19 on > > > > miibus2 > > > > e1000phy2: none, 10baseT, 10baseT-FDX, 100baseTX, > > > > 100baseTX-FDX, > > > > 1000baseT, 1000baseT-master, 1000baseT-FDX, > > > > 1000baseT-FDX-master, auto > > > > e6000sw0: switch is ready. > > etherswitch0: <Switch controller> on e6000sw0 > > xhci0: <Generic USB 3.0 controller> mem > > > > 0x58000-0x5bfff irq 16 on > > > > simplebus1 > > xhci0: 32 bytes context size, 32-bit DMA > > usbus0 on xhci0 > > syscon_generic3: <syscon> mem 0x5d800-0x5dfff on > > > > simplebus1 > > > > ehci0: <Marvell Integrated USB 2.0 controller> mem > > > > 0x5e000-0x5efff irq > > > > 17 on simplebus1 > > usbus1: EHCI version 1.0 > > usbus1 on ehci0 > > syscon_generic4: <syscon> mem 0x5f800-0x5ffff on > > > > simplebus1 > > > > sdhci_xenon0: <Armada Xenon SDHCI controller> mem > > 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 > > ahci0: <AHCI SATA controller> mem 0xe0000-0xe0177 irq > > > > 26 on simplebus1 > > > > ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier > > > > supported with FBS > > > > ahcich0: <AHCI channel> at channel 0 on ahci0 > > device_attach: ahcich0 attach returned 6 > > gpioregulator0: <GPIO controlled regulator> on ofwbus0 > > gpioregulator0: cannot get pin 0 > > gpioregulator0: cannot parse parameters > > device_attach: gpioregulator0 attach returned 6 > > cryptosoft0: <software crypto> > > Timecounters tick every 1.000 msec > > mvneta0: link state changed to UP > > e6000sw0port1: link state changed to DOWN > > e6000sw0port2: link state changed to DOWN > > e6000sw0port3: link state changed to DOWN > > usbus0: 5.0Gbps Super Speed USB v3.0 > > usbus1: 480Mbps High Speed USB v2.0 > > Release APs...done > > CPU 0: ARM Cortex-A53 r0p4 affinity: 0 > > Instruction Set Attributes 0 =3D > > > > <CRC32,SHA2,SHA1,AES+PMULL> > > > > Trying to mount root from > > > > ufs:/dev/ufs/FreeBSD_Install [ro,noatime]... > > > > Instruction Set Attributes 1 =3D <> > > Root mount waiting for: Processor Features 0 =3D > > <GIC,AdvSIMD,Float,EL3 32,EL2 32,EL1 32,EL0 32> > > usbus1 Processor Features 1 =3D <0> > > usbus0 Memory Model Features 0 =3D <4k Granule,64k > > > > Granule,S/NS > > > > Mem,MixedEndian,16bit ASID,1TB PA> > > > > Memory Model Features 1 =3D <> > > Memory Model Features 2 =3D <32b CCIDX,48b VA> > > Debug Features 0 =3D <2 CTX Breakpoints,4 > > > > Watchpoints,6 > > > > Breakpoints,PMUv3,Debug v8> > > Debug Features 1 =3D <0> > > Auxiliary Features 0 =3D <0> > > Auxiliary Features 1 =3D <0> > > CPU 1: ARM Cortex-A53 r0p4 affinity: 1 > > WARNING: WITNESS option enabled, expect reduced > > > > performance. > > > > ugen0.1: <Generic XHCI root HUB> at usbus0 > > ugen1.1: <Marvell EHCI root HUB> at usbus1 > > uhub0 on usbus0 > > uhub1 on usbus1 > > uhub0: <Generic XHCI root HUB, class 9/0, rev > > > > 3.00/1.00, addr 1> on > > > > usbus0 > > uhub1: <Marvell EHCI root HUB, class 9/0, rev > > > > 2.00/1.00, addr 1> on > > > > usbus1 > > uhub0: 2 ports with 2 removable, self powered > > uhub1: 1 port with 1 removable, self powered > > mountroot: waiting for device > > > > /dev/ufs/FreeBSD_Install... > > > > Mounting from ufs:/dev/ufs/FreeBSD_Install failed > > > > with error 19. > > > > > > Loader variables: > > vfs.root.mountfrom=3Dufs:/dev/ufs/FreeBSD_Install > > vfs.root.mountfrom.options=3Dro,noatime > > > > Manual root filesystem specification: > > <fstype>:<device> [options] > > Mount <device> using filesystem <fstype> > > and with the specified (optional) option list. > > > > eg. ufs:/dev/da0s1a > > zfs:zroot/ROOT/default > > cd9660:/dev/cd0 ro > > (which is equivalent to: mount -t cd9660 -o ro > > > > /dev/cd0 /) > > > > > > ? List valid disk boot devices > > . Yield 1 second (for background tasks) > > <empty line> Abort manual input > > > > mountroot> ? > > > > List of GEOM managed disk devices: > > > > > > mountroot> > > _______________________________________________ > > freebsd-arm@freebsd.org <mailto: > > > > freebsd-arm@freebsd.org> mailing list > > > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm < > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm>; > > > > To unsubscribe, send any mail to " > > > > freebsd-arm-unsubscribe@freebsd.org <mailto: > > freebsd-arm-unsubscribe@freebsd.org>" > > > > > > _______________________________________________ > > freebsd-arm@freebsd.org <mailto: > > > > freebsd-arm@freebsd.org> mailing list > > > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm < > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm>; > > > > To unsubscribe, send any mail to " > > > > freebsd-arm-unsubscribe@freebsd.org <mailto: > > freebsd-arm-unsubscribe@freebsd.org>" > > > > > > > > > > -- > > Emmanuel Vadot <manu@bidouilliste.com> < > > > > manu@freebsd.org> > > > > > > > > > > -- > > Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org> > > > > > > > > -- > > Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org> > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to " > > > > freebsd-arm-unsubscribe@freebsd.org" > > > > > > > > -- > > Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org> > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to " > > > > freebsd-arm-unsubscribe@freebsd.org" > > > > > > > > -- > > Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org> > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to " > > > > freebsd-arm-unsubscribe@freebsd.org" > > > > > > > > -- > > Emmanuel Vadot <manu@bidouilliste.com <mailto: > > > > manu@bidouilliste.com>> <manu@freebsd.org <mailto:manu@freebsd.org>> > > > > > > > > > > -- > > Emmanuel Vadot <manu@bidouilliste.com <mailto: > > > > manu@bidouilliste.com>> <manu@freebsd.org <mailto:manu@freebsd.org>> > > > > > > > > > > -- > > Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org> > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to " > > freebsd-arm-unsubscribe@freebsd.org" > > > > > > > > > > > > > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > > > > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >=20 >=20 >=20 From owner-freebsd-arm@freebsd.org Tue Aug 20 12:46:09 2019 Return-Path: <owner-freebsd-arm@freebsd.org> Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 51FAED178C for <freebsd-arm@mailman.nyi.freebsd.org>; Tue, 20 Aug 2019 12:46:09 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (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 46CVsD2LT6z4KJT for <freebsd-arm@freebsd.org>; Tue, 20 Aug 2019 12:46:07 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Date: Tue, 20 Aug 2019 14:46:06 +0200 (CEST) From: Ronald Klop <ronald-lists@klop.ws> To: Jeffrey Bowers <khantroll@gmail.com> Cc: =?utf-8?Q?S=C3=B8ren_Schmidt?= <soren.schmidt@gmail.com>, freebsd-arm <freebsd-arm@freebsd.org> Message-ID: <2002575095.53.1566305166664@localhost> In-Reply-To: <CAAkMUSW6Oa-RE4MFMKghn3XfMN5tL0MQE=z1h5jO8H7=XS8+XA@mail.gmail.com> References: <E73AFF5D-43CA-41A7-BDBA-ADEF2D342479@deepcore.dk> <CAPv3WKeCRWy65LPeeJiisPtaz=LePpVYLDAi2cj+2TQR=r09YA@mail.gmail.com> <1547777156.662147.1565798461515.JavaMail.zimbra@perftech.com> <0E42E605-477E-4E65-810E-BD3A8CDE2C80@gmail.com> <973015183.1067498.1565890674099.JavaMail.zimbra@perftech.com> <BD3710D7-EB87-4BD0-9CDE-E55B9412ED87@gmail.com> <20190815210311.1035f64b003e2bc85fa47ca8@bidouilliste.com> <B3AFA483-4BE4-4BC6-BCC1-4BD58A8E554C@gmail.com> <20190815233755.893e485f40ccacd79cdb3d96@bidouilliste.com> <78F5029D-A0F5-42F2-8191-07EB3A68C87B@gmail.com> <20190816152454.4e54ab5c276a543c120d909a@bidouilliste.com> <20190816171037.f808fbaba2369f179de36397@bidouilliste.com> <20190816191230.508f07f27fac21479a6716d9@bidouilliste.com> <20190816225826.ce31e8f968021944f64cb67c@bidouilliste.com> <AB07E67F-5A5E-4B5A-9D2C-6EDD4E9B478A@gmail.com> <20190817153053.5592b15b8a42982fda0fc123@bidouilliste.com> <9749945A-FDAD-47E0-947A-FA62138C2F83@gmail.com> <20190817210822.8920656bad0855b554883cf2@bidouilliste.com> <CAAkMUSXsgxP_fOJdfks+d35MnyoXf1GfPO+C-YmTK3TpKDH7gA@mail.gmail.com> <2D6D4BDA-75EC-403F-B5E2-52A468369DE2@gmail.com> <CAAkMUSUM8bWT0Q-90jrvWjGOJopEka_LgP8sMshuS4Y7YQ29vw@mail.gmail.com> <627099DD-804B-412F-A083-768CEFCF955C@gmail.com> <CAAkMUSXd2zQQcYWDZnmibTQzLe+UV8rH6pk5fr=oZvevAY+HOQ@mail.gmail.com> <6DA8E736-8031-4BF7-8B20-CF8B0E8A7FEF@gmail.com> <CAAkMUSVRxbDBYtX0g7xbu4kLtiYQiZhjh0bdSwbCahF+jmTUXg@mail.gmail.com> <CAAkMUSVWWjYviHbOUXuHPxJYoahUnitdNazyusH=zGvbW1RAnw@mail.gmail.com> <ABB6B2F0-7771-49CD-84CF-B00D061EEF60@gmail.com> <CAAkMUSUfKN8Jqe7U40z9O1ypb=WuMWfgGtbnq7jLFPjp5qQfqQ@mail.gmail.com> <CAAkMUSV4p1uQOi+t7b-z0uG8kjVY3qZhFd4B7fP1BjOWVRYqTA@mail.gmail.com> <BC161A1F-DC68-4AD3-BD28-1028E4BF7CCD@gmail.com> <CAAkMUSVGZCxgoTc+fBgsuR-DKiwUm8gKe49W-2+hH2PqRc+g2A@mail.gmail.com> <CAAkMUSW6Oa-RE4MFMKghn3XfMN5tL0MQE=z1h5jO8H7=XS8+XA@mail.gmail.com> Subject: Re: Espressobin anyone ? MIME-Version: 1.0 X-Mailer: Realworks (471.1011.ce02e15a2ad) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 46CVsD2LT6z4KJT X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 194.109.157.24 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws X-Spamd-Result: default: False [-1.61 / 15.00]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.79)[-0.792,0]; HAS_X_PRIO_THREE(0.00)[3]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; SUBJECT_ENDS_QUESTION(1.00)[]; SH_EMAIL_ZRD(0.00)[0.0.46.224,0.0.117.48]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.981,0]; FROM_HAS_DN(0.00)[]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.117.48,0.0.46.224]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-0.98)[-0.982,0]; TAGGED_RCPT(0.00)[]; DMARC_NA(0.00)[klop.ws]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[24.157.109.194.list.dnswl.org : 127.0.15.0]; IP_SCORE(-0.06)[ipnet: 194.109.0.0/16(-0.16), asn: 3265(-0.13), country: NL(0.01)]; MID_RHS_NOT_FQDN(0.50)[]; FREEMAIL_CC(0.00)[gmail.com] Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>, <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>; List-Post: <mailto:freebsd-arm@freebsd.org> List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>, <mailto:freebsd-arm-request@freebsd.org?subject=subscribe> X-List-Received-Date: Tue, 20 Aug 2019 12:46:09 -0000 It is not possible to 'ping https://svn.freebsd.org/ports/head'. You can 'ping svn.freebsd.org'. Ronald. =20 Van: Jeffrey Bowers <khantroll@gmail.com> Datum: dinsdag, 20 augustus 2019 14:36 Aan: "S=C3=B8ren Schmidt" <soren.schmidt@gmail.com>, freebsd-arm <freebsd-a= rm@freebsd.org> Onderwerp: Re: Espressobin anyone ? >=20 > 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? >=20 > On Tue, Aug 20, 2019 at 7:33 AM Jeffrey Bowers <khantroll@gmail.com> wrot= e: >=20 > > I'm still getting: svn: E000060: Operation timed out > > It goes for several minutes scrolling through text, and I feel like usi= ng > > your link got further. > > > > Thanks! > > > > On Tue, Aug 20, 2019 at 2:49 AM S=C3=B8ren Schmidt <soren.schmidt@gmail= .com> > > wrote: > > > >> Hmm, I use this URL > >> > >> Repository Root: https://svn.freebsd.org/ports/head > >> > >> Not sure the svn+ssh thing works=E2=80=A6 > >> > >> -S=C3=B8ren > >> > >> > >> On 20 Aug 2019, at 02.38, Jeffrey Bowers <khantroll@gmail.com> wrote: > >> > >> Hi all, > >> > >> I'm having trouble getting subversion to work. When I run: > >> > >> svn checkout https://svn.FreeBSD.org/ports/head /usr/ports > >> > >> It scrolls through many lines of text before stating: svn: E000060: > >> Operation timed out > >> > >> When I run: > >> > >> svn checkout svn+ssh://repo.freebsd.org/ports/head /usr/ports > >> > >> It tells me that the authenticity of the host cannot be identified, an= d > >> 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 f= ile. > >> > >> Any ideas? > >> > >> Thanks in advance! > >> > >> On Mon, Aug 19, 2019 at 8:51 PM Jeffrey Bowers <khantroll@gmail.com> > >> wrote: > >> > >> I didn't think it remounting. Thank you! > >> > >> On Mon, Aug 19, 2019 at 11:39 AM S=C3=B8ren Schmidt <soren.schmidt@gma= il.com> > >> wrote: > >> > >> Hi Jeffrey > >> > >> You need to unmount the /tmp filesystem :) > >> You can do that permanently by commenting it out in /etc/fstab > >> > >> > >> On 19 Aug 2019, at 21.45, Jeffrey Bowers <khantroll@gmail.com> wrote: > >> > >> Hi Soren, > >> > >> I'm getting the same error message. Any other ideas what it might be? > >> It's got to be something in the partition scheme or the file permissio= ns, > >> but I'm just not sure what. > >> <image.png> > >> > >> On Sun, Aug 18, 2019 at 10:03 AM Jeffrey Bowers <khantroll@gmail.com> > >> wrote: > >> > >> D=E2=80=99Oh! I thought I too care of that with gpart. I literally mis= sed growfs > >> part of the instructions.. > >> > >> On Sun, Aug 18, 2019 at 10:00 AM S=C3=B8ren Schmidt <soren.schmidt@gma= il.com> > >> wrote: > >> > >> Hi > >> > >> You are out of space :) > >> > >> Boot the board into singleuser mode, and do =E2=80=9Cservice growfs st= art=E2=80=9D, > >> that will expand you / filesystem to the entire SD card=E2=80=A6 > >> > >> -S=C3=B8ren > >> > >> On 18 Aug 2019, at 14.50, Jeffrey Bowers <khantroll@gmail.com> wrote: > >> > >> Sure thing! Here's the screenshot! > >> <image.png> > >> > >> > >> On Sun, Aug 18, 2019 at 7:35 AM S=C3=B8ren Schmidt <soren.schmidt@gmai= l.com> > >> wrote: > >> > >> Hi > >> > >> Can I have you paste the output from df -h ? > >> > >> You should be able to utilise the full SD card=E2=80=A6 > >> > >> -S=C3=B8ren > >> > >> On 18 Aug 2019, at 14.29, Jeffrey Bowers <khantroll@gmail.com> wrote: > >> > >> Hi, > >> > >> Just make sure I understand the process, I should hook up a hard disk > >> and map it to to /TMP ? > >> > >> I already tried just unmapping /tmp, and it gave me the same error > >> once, and then the next time I ran it I got an error saying /usr/ports= was > >> out of space )which I guess I shouldn=E2=80=99t mount to another direc= tor on the > >> hard drive? > >> > >> On Sun, Aug 18, 2019 at 5:11 AM S=C3=B8ren Schmidt <soren.schmidt@gmai= l.com> > >> wrote: > >> > >> Hi Jeffrey > >> > >> You can unmount the memory disk on /tmp to get at the space on the SD > >> card. > >> > >> It is however not recommend to use the AD card for random storage, it > >> will wear out fast, that=E2=80=99s why the memory disk is setup. > >> > >> You could connect a SSD og laptop disk to the SATA interface and use > >> that for the workload. > >> > >> However compiling is slow, its much much faster to cross compile on a > >> PC=E2=80=A6 > >> > >> -S=C3=B8ren > >> > >> On 18 Aug 2019, at 00.22, Jeffrey Bowers <khantroll@gmail.com> wrote: > >> > >> Hi! I've got a new one :) > >> I'm trying to do an svn checkout to fix the pkg problem, but it tells > >> me it can't write to a to a temp folder because there is no room left = on > >> the device. However, FreeBSD partition is 29GB. It's never also never = the > >> same file in TMP that it can't write to. Here is a screenshot of the > >> issue, > >> along with the output of gpart: > >> > >> <image.png> > >> > >> Any ideas? > >> > >> Thanks! > >> > >> > >> On Sat, Aug 17, 2019 at 2:08 PM Emmanuel Vadot <manu@bidouilliste.com> > >> wrote: > >> > >> On Sat, 17 Aug 2019 17:14:36 +0200 > >> S=C3=B8ren Schmidt <soren.schmidt@gmail.com> wrote: > >> > >> HI > >> > >> Well, I have a whole forrest of tree?s here, but the error posted > >> > >> here was on a clean checkout. > >> > >> > >> Anyhow, with the latest changes to -stable and the two > >> > >> RF_SHAREABLE patches from -current all works. > >> > >> I've reverted the commits, see > >> https://github.com/evadot/freebsd/commits/a37x0_gpio for a better > >> way > >> to deal with this issue. > >> I'm waiting for mmel@ as he wrote the syscon_get_default_handle > >> part. > >> > >> It would be nice with the etherswitch changes as well so VLAN > >> > >> tagging etc was standard. > >> > >> > >> -S=C3=B8ren > >> > >> PS: given up on bottom & inline popsting, top posting is all the > >> > >> rage now (yeah I miss elm etc :) ) > >> > >> > >> On 17 Aug 2019, at 15.30, Emmanuel Vadot <manu@bidouilliste.com> > >> > >> wrote: > >> > >> > >> On Sat, 17 Aug 2019 11:07:22 +0200 > >> S=C3=B8ren Schmidt <soren.schmidt@gmail.com <mailto: > >> > >> soren.schmidt@gmail.com>> wrote: > >> > >> > >> Hi Emmunuel > >> > >> Yes the 3720 gpio driver I already back ported long ago, its > >> > >> needed, I?m happy its now part of std stable 12! > >> > >> > >> Would have been nice of you to say that you were not running a > >> > >> clean > >> > >> tree. > >> > >> My issue seems to be the inclusion of the phy_usb driver, if I > >> > >> leave that out, I?m back to normal.. > >> > >> > >> What make you think this is this driver ? What works/doesn't work > >> with it ? could you provide logs. > >> > >> I?ll have have another go at the latest -stable sources during > >> > >> the weekend and see how it goes. > >> > >> > >> Thanks for looking into this, with a little cooperation we?ll > >> > >> get this solved for the greater good.. > >> > >> > >> -S=C3=B8ren > >> > >> > >> P.S. Please stop top posting, it's really hard to read the > >> > >> conversation > >> > >> > >> On 16 Aug 2019, at 22.58, Emmanuel Vadot < > >> > >> manu@bidouilliste.com> wrote: > >> > >> > >> On Fri, 16 Aug 2019 19:12:30 +0200 > >> Emmanuel Vadot <manu@bidouilliste.com <mailto: > >> > >> manu@bidouilliste.com>> wrote: > >> > >> > >> On Fri, 16 Aug 2019 17:10:37 +0200 > >> Emmanuel Vadot <manu@bidouilliste.com> wrote: > >> > >> On Fri, 16 Aug 2019 15:24:54 +0200 > >> Emmanuel Vadot <manu@bidouilliste.com> wrote: > >> > >> On Fri, 16 Aug 2019 07:28:59 +0200 > >> S=C3=B8ren Schmidt <soren.schmidt@gmail.com> wrote: > >> > >> Hi > >> > >> Very simple, reverting sys/gnu/dts to what was before > >> > >> 350595 (actually 350592). > >> > >> Thats what we have svn for ? > >> > >> > >> If I asked how it was to have the svn command that you > >> > >> used, I want to > >> > >> make sure that you didn't revert anything else, like do you > >> > >> have > >> > >> r350596 and r350628 ? > >> > >> That does make my bananapi work again, no other changes > >> > >> just a recompiled kernel. > >> > >> > >> That + copying the dtb to the fat32 partition ? > >> > >> Can you post the dtb somewhere. > >> > >> However it does not bring the Espressobin back to life, > >> > >> thats something in one of the ~30 other files that changed between tho= se > >> two revisions. > >> > >> > >> What Linux version of DTS are you using then ? The ones > >> > >> that were in > >> > >> stable/12 when it was branched (4.18) or a later revision ? > >> > >> > >> So I think that I've found the problem on the Espressobin. > >> I think that the problem comes from the simple-mfd driver > >> > >> that I've > >> > >> mfc in r350600. > >> The pinctrl/gpio controller compatible is > >> "marvell,armada3710-nb-pinctrl", "syscon", "simple-mfd" and > >> > >> it attaches > >> > >> at BUS_PASS_INTERRUPT while the simple_mfd driver attaches at > >> BUS_PASS_BUS (so earlier) which means that no gpio > >> > >> controller will be > >> > >> available for sdhci to detect the card. > >> > >> If someone with a non-working espressobin could post a full > >> > >> verbose > >> > >> boot log that would help me confirming that this is the case. > >> I'll try to find a solution on how to solve this problem. > >> > >> > >> So this wasn't the problem but I've found it, see r351129 and > >> > >> r351130 > >> > >> > >> SD card now work again in HEAD, I'll have a look at stable > >> > >> later next > >> > >> week. > >> > >> > >> I've did a quick test and I've MFC r348880, r348882 and > >> > >> r349596, the > >> > >> two other commits needed to be mfc'ed are the one I did today > >> > >> on head, > >> > >> I'll do that next week. > >> With them sdcard is working again on stable/12 > >> > >> -S=C3=B8ren > >> > >> On 15 Aug 2019, at 23.37, Emmanuel Vadot < > >> > >> manu@bidouilliste.com> wrote: > >> > >> > >> On Thu, 15 Aug 2019 21:56:23 +0200 > >> S=C3=B8ren Schmidt <soren.schmidt@gmail.com> wrote: > >> > >> > >> Well, I don?t care where you are from and what color you > >> > >> have :) > >> > >> > >> Now, if I update my stable12 sources to r350595 the > >> > >> bananapi breaks, if revert sys/gnu/dts it works again, go figure.. > >> > >> > >> Reverting to what ? and how ? > >> > >> Because I've just test 12-stable and I have the problem > >> > >> that I've said > >> > >> in my previous mail so setting > >> > >> hw.regulator.disable_unused=3D0 is the > >> > >> work around. > >> The problem is in twsi not in the DTS so I'm curious how > >> > >> reverting > >> > >> only the dts fixes this problem. > >> > >> The r351099 fix is already like that in -stable, and not > >> > >> part of the problem. > >> > >> > >> -S=C3=B8ren > >> > >> > >> On 15 Aug 2019, at 21.03, Emmanuel Vadot < > >> > >> manu@bidouilliste.com> wrote: > >> > >> > >> On Thu, 15 Aug 2019 19:48:54 +0200 > >> S=C3=B8ren Schmidt <soren.schmidt@gmail.com> wrote: > >> > >> Hi Mit! > >> > >> Right, I suspected that, 12-stable broke many embedded > >> > >> systems between r350592 and r350595 where all the latest and greatest = DTS > >> files was pulled in, I guess the same holds for -current. > >> > >> > >> -S=C3=B8ren > >> > >> > >> Mhm it's fun that you think that DTS import is the > >> > >> source of all your > >> > >> problems, I get it, it's easy to blame the French guy > >> > >> that bulk import > >> > >> the DTS, he surely don't know what he is doing. > >> Anyway, two problems were raised in this thread : > >> > >> 1) BananaPi (A20) doesn't boot > >> 2) Espressobin sd support is broken > >> > >> I've just looked at the BananaPi problem today, I've > >> > >> fixed a first > >> > >> problem in r351099. > >> The main problem is that when we disable the unused > >> > >> regulators we hang > >> > >> when trying to disabling ldo3. It's weird because the > >> > >> board doesn't use > >> > >> LDO3 (which is why we are disabling it, it's unused). > >> > >> The problem is in > >> > >> twsi I think as only leaving the part in axp209 that > >> > >> read the > >> > >> voltage register value make FreeBSD hang. > >> I'll have a proper look later, in the meantime you can > >> > >> set > >> > >> hw.regulator.disable_unused=3D0 > >> in /boot/loader.conf > >> This isn't a DTS problem. > >> > >> For Espressobin I haven't found any thing related to SD > >> > >> in the DTS > >> > >> updates since the import, the only things slighly > >> > >> related are mmc and > >> > >> sdio. > >> So if someone could find which DTS import broke this I > >> > >> can have a look. > >> > >> > >> > >> On 15 Aug 2019, at 19.37, Mit Matelske <mit@pt.net> > >> > >> wrote: > >> > >> > >> Yeah, that was the problem. I went back to r348882 > >> > >> and everything worked out of the box. > >> > >> > >> Thanks again for the hand holding! > >> > >> Mit > >> > >> From: "S=C3=B8ren Schmidt" <soren.schmidt@gmail.com > >> > >> <mailto:soren.schmidt@gmail.com>> > >> > >> To: "Mit Matelske" <mit@pt.net <mailto:mit@pt.net>> > >> Cc: "Marcin Wojtas" <mw@semihalf.com <mailto: > >> > >> mw@semihalf.com>>, "freebsd-arm" <freebsd-arm@freebsd.org <mailto: > >> freebsd-arm@freebsd.org>> > >> > >> Sent: Wednesday, August 14, 2019 1:33:04 PM > >> Subject: Re: Espressobin anyone ? > >> > >> > >> It might simply be broken in -current (again). > >> > >> I just updated my stable12 tree and I pulled in new > >> > >> .dts files for just about anything? > >> > >> > >> Needless to say, it broke the Espressobin?s SD > >> > >> support, it now fails just like yours.. > >> > >> > >> It also broke allwinner builds and what not, so I?m > >> > >> just going back in time again :) > >> > >> > >> I wonder why there is this overwhelming need to > >> > >> import stuff that breaks things right, left and center in a -stable > >> branch ? > >> > >> That would have earned you the pointy hat back when?. > >> > >> -S=C3=B8ren > >> > >> > >> On 14 Aug 2019, at 18.01, Mit Matelske <mit@pt.net > >> > >> <mailto:mit@pt.net>> wrote: > >> > >> > >> Marcin- > >> > >> Sorry I didn't reply yesterday. I didn't have any > >> > >> luck with that either. I tried a lot of permutations. > >> > >> > >> Not saying for 100% it doesn't work, but I couldn't > >> > >> get it to work! > >> > >> > >> Mit > >> > >> From: "Marcin Wojtas" <mw@semihalf.com <mailto: > >> > >> mw@semihalf.com>> > >> > >> To: "Mit Matelske" <mit@pt.net <mailto:mit@pt.net>> > >> Cc: "S=C3=B8ren Schmidt" <soren.schmidt@gmail.com <mailto: > >> > >> soren.schmidt@gmail.com>>, "freebsd-arm" <freebsd-arm@freebsd.org > >> <mailto:freebsd-arm@freebsd.org>> > >> > >> Sent: Wednesday, August 14, 2019 10:41:04 AM > >> Subject: Re: Espressobin anyone ? > >> > >> Hi Mit, > >> Since you are using the latest 13-current, could you > >> > >> please try if passing rootdev via u-boot bootargs (please see my previ= ous > >> email) works for you without the loader modification? > >> > >> > >> Best regards, > >> Marcin > >> > >> ?r., 14 sie 2019 o 16:29 Mit Matelske <mit@pt.net > >> > >> <mailto:mit@pt.net>> napisa?(a): > >> > >> Soren- > >> > >> Thanks for the info. I'll grab a couple more SD > >> > >> cards at lunch. This one is a new Samsung 32GB. I'll also try puttin= g > >> the > >> changes into 12 and see if that helps. I'm using the latest 13-curren= t. > >> > >> > >> Again, appreciate the hand holding! > >> > >> Mit > >> > >> From: "S=C3=B8ren Schmidt" <soren.schmidt@gmail.com > >> > >> <mailto:soren.schmidt@gmail.com>> > >> > >> To: "Mit Matelske" <mit@pt.net <mailto:mit@pt.net>> > >> Cc: "Marcin Wojtas" <mw@semihalf.com <mailto: > >> > >> mw@semihalf.com>>, "freebsd-arm" <freebsd-arm@freebsd.org <mailto: > >> freebsd-arm@freebsd.org>> > >> > >> Sent: Wednesday, August 14, 2019 2:30:31 AM > >> Subject: Re: Espressobin anyone ? > >> > >> Hi Mit > >> Hmm, from your earlier posted dmesgs it looks like > >> > >> the SD card is not getting detected properly.. > >> > >> > >> I get this output: > >> > >> sdhci_xenon0: <Armada Xenon SDHCI controller> mem > >> > >> 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 > >> > >> mmc0: <MMC/SD bus> on sdhci_xenon0 > >> ?snip? > >> mmcsd0: 16GB <SDHC SD16G 3.0 SN 01E28E67 MFG 07/2017 > >> > >> by 39 PH> at mmc0 50.0MHz/4bit/65535-block > >> > >> > >> The problem you see was fixed for me by r348882, > >> > >> maybe it got broken later, I havn?t backported the later changes.. > >> > >> > >> Have you tried another SD card ? I have found 2 of > >> > >> mine that the espressobin doesn?t like, but works fine with bananapi a= nd > >> friends... > >> > >> > >> -S=C3=B8ren > >> > >> On 13 Aug 2019, at 23.30, Mit Matelske <mit@pt.net > >> > >> <mailto:mit@pt.net>> wrote: > >> > >> > >> Soren- > >> > >> Thanks for the code snippet! That will fix one of > >> > >> the problems. > >> > >> > >> I still can't mount my filesystem, though. I think > >> > >> I'm doing something really simple, wrong. I believe I'm running the > >> latest > >> code and added some printfs to show the kernel setting the regulator: > >> > >> > >> > >> usbus1 on ehci0 > >> syscon_generic4: <syscon> mem 0x5f800-0x5ffff on > >> > >> simplebus1 > >> > >> sdhci_xenon0: > >> > >> regulator_get_by_ofw_property(vqmmc-supply) =3D 19 > >> > >> sdhci_xenon0: vqmmc-supply regulator found > >> sdhci_xenon0: <Armada Xenon SDHCI controller> mem > >> > >> 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 > >> > >> ahci0: <AHCI SATA controller> mem 0xe0000-0xe0177 irq > >> > >> 26 on simplebus1 > >> > >> > >> > >> Could there be a problem with how I am setting up my > >> > >> filesystem? I've tried both freebsd-ufs and freebsd as the type, 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" <soren.schmidt@gmail.com > >> > >> <mailto:soren.schmidt@gmail.com>> > >> > >> To: "Marcin Wojtas" <mw@semihalf.com <mailto: > >> > >> mw@semihalf.com>> > >> > >> Cc: "Mit Matelske" <mit@pt.net <mailto:mit@pt.net>>, > >> > >> "freebsd-arm" <freebsd-arm@freebsd.org <mailto: > >> freebsd-arm@freebsd.org>> > >> > >> Sent: Tuesday, August 13, 2019 12:55:09 PM > >> Subject: Re: Espressobin anyone ? > >> > >> Hi > >> That doesn?t seen to work on the espressobin, or > >> > >> least I can?t get it to pick it up. > >> > >> > >> I use this patch as a workaround: > >> > >> Index: main.c > >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > >> --- main.c (revision 350496) > >> +++ main.c (working copy) > >> @@ -463,6 +462,13 @@ > >> int rv; > >> char *rootdev; > >> > >> +#if defined(__aarch64__) > >> + /* SOS HACK in rootdev, at least Espressobin > >> > >> gets this wrong */ > >> > >> + printf("Setting currdev hack\n"); > >> + set_currdev("disk0p2"); > >> + return (0); > >> +#endif > >> + > >> /* > >> * First choice: if rootdev is already set, use > >> > >> that, even if > >> > >> * it's wrong. > >> > >> Its not pretty but it does the job until I get time > >> > >> to look into why bootargs aren?t passed / won?t stick, probably someth= ing > >> I > >> havn?t backported to my -stable12 sources yet... > >> > >> > >> -S=C3=B8ren > >> > >> On 13 Aug 2019, at 01.38, Marcin Wojtas < > >> > >> mw@semihalf.com <mailto:mw@semihalf.com>> wrote: > >> > >> > >> Hi, > >> > >> Not sure if it's what you are looking for, but in > >> > >> order to autoboot, I > >> > >> simply pass 'rootdev=3DdiskXpY' in the bootargs > >> > >> variable. Here's example from > >> > >> A3720-DB (same should work on EspressoBin): > >> > >> Marvell>> set bootargs "rootdev=3Ddisk1p1";usb reset; > >> > >> fatload usb 0:1 > >> > >> ${fdt_addr} armada-3720-db.dtb; fatload usb 0:1 > >> > >> ${kernel_addr} > >> > >> boot/loader.efi; bootefi ${kernel_addr} ${fdt_addr} > >> resetting USB... > >> USB0: Register 2000104 NbrPorts 2 > >> Starting the controller > >> USB XHCI 1.00 > >> USB1: USB EHCI 1.00 > >> - ______ ____ _____ _____ > >> | ____| | _ \ / ____| __ \ > >> | |___ _ __ ___ ___ | |_) | (___ | | | | > >> | ___| '__/ _ \/ _ \| _ < \___ \| | | | > >> | | | | | __/ __/| |_) |____) | |__| | > >> | | | | | | || | | | > >> |_| |_| \___|\___||____/|_____/|_____/ > >> ``` > >> ` > >> ????????????Welcome to FreeBSD????????????? s` > >> > >> `.....---.......--.``` > >> > >> -/ > >> ? ? +o > >> > >> .--` /y:` > >> > >> +. > >> ? 1. Boot Multi user [Enter] ? > >> > >> yo`:. :o > >> > >> `+- > >> ? 2. Boot Single user ? y/ > >> > >> -/` -o/ > >> > >> ? 3. Escape to loader prompt ? .- > >> ::/sy+:. > >> ? 4. Reboot ? / > >> > >> `-- > >> > >> / > >> ? ? `: > >> :` > >> ? Options: ? `: > >> :` > >> ? 5. Kernel: default/kernel (1 of 1) ? / > >> / > >> ? 6. Boot Options ? .- > >> -. > >> ? ? -- > >> > >> -. > >> > >> ? ? > >> > >> `:` `:` > >> > >> ? ? > >> > >> .-- `--. > >> > >> ??????????????????????????????????????????? > >> > >> .---.....----. > >> > >> Autoboot in 9 seconds, hit [Enter] to boot or any > >> > >> other key to stop > >> > >> > >> Loading kernel... > >> /boot/kernel/kernel text=3D0x95047c > >> > >> data=3D0x1919d0+0x84aa94 > >> > >> syms=3D[0x8+0x13aaa8+0x8+0x12610d] > >> Loading configured modules... > >> can't find '/boot/entropy' > >> Using DTB provided by EFI at 0x8000000. > >> ---<<BOOT>>--- > >> KDB: debugger backends: ddb > >> KDB: current backend: ddb > >> Copyright (c) 1992-2019 The FreeBSD Project. > >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, > >> > >> 1991, 1992, 1993, 1994 > >> > >> The Regents of the University of California. All > >> > >> rights reserved. > >> > >> FreeBSD is a registered trademark of The FreeBSD > >> > >> Foundation. > >> > >> FreeBSD 13.0-CURRENT > >> > >> 17a1fc80d57-c261519(upstream_master) GENERIC arm64 > >> > >> FreeBSD clang version 8.0.0 (tags/RELEASE_800/final > >> > >> 356365) (based on LLVM > >> > >> 8.0.0) > >> WARNING: WITNESS option enabled, expect reduced > >> > >> performance. > >> > >> VT: init without driver. > >> Starting CPU 1 (1) > >> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > >> [...] > >> > >> Best regards, > >> Marcin > >> > >> pon., 12 sie 2019 o 23:14 Mit Matelske <mit@pt.net > >> > >> <mailto:mit@pt.net>> napisa?(a): > >> > >> > >> > >> Soren- > >> > >> Thanks for the quick response. I built this kernel > >> > >> with revision 350924. > >> > >> I'll dig into whats going on in the morning. > >> > >> Mind posting your diff for your loader.efi? > >> > >> Thanks again! > >> > >> Mit > >> > >> > >> ----- Original Message ----- > >> From: "S=C3=B8ren Schmidt" <soren.schmidt@gmail.com > >> > >> <mailto:soren.schmidt@gmail.com>> > >> > >> To: "Mit Matelske" <mit@pt.net <mailto:mit@pt.net>> > >> Cc: "tscho" <johannes@t-beutel.com <mailto: > >> > >> johannes@t-beutel.com>>, "freebsd-arm" < > >> > >> freebsd-arm@freebsd.org <mailto: > >> > >> freebsd-arm@freebsd.org>> > >> > >> Sent: Monday, August 12, 2019 3:49:48 PM > >> Subject: Re: Espressobin anyone ? > >> > >> Hi > >> > >> Looks like your sources may be too old, you need to > >> > >> be at least at r348882 > >> > >> to get the fix for the SD card VCC regulator. > >> > >> That change fixed it for me backported to 12-stable... > >> > >> The currdev problem still exists, I have it hardwired > >> > >> in my loader for > >> > >> aarch64 :) > >> > >> -S=C3=B8ren > >> > >> > >> On 12 Aug 2019, at 21.06, Mit Matelske <mit@pt.net > >> > >> <mailto:mit@pt.net>> wrote: > >> > >> > >> I'm having a couple little hiccups booting this board > >> > >> also. One has > >> > >> been commented on already, that I can't get the > >> > >> loader to automatically > >> > >> start loading the kernel on "disk0p2"... > >> > >> The second, is that the kernel can't find the SD card > >> > >> after booting so > >> > >> it can't mount the root filesystem. I'm using the > >> > >> dts/dtb and kernel from > >> > >> the 13-current branch. > >> > >> Thanks for any and all help. I haven't used u-boot > >> > >> in about decade. > >> > >> Spoiled by the x86 platform. > >> > >> Mit Matelske > >> > >> > >> ***U-boot environment:*** > >> > >> > >> Marvell>> printenv > >> baudrate=3D115200 > >> bootargs=3Dconsole=3DttyMV0,115200 > >> > >> earlycon=3Dar3700_uart,0xd0012000 > >> > >> root=3D/dev/mmcblk0p1 rw rootwait net.ifnames=3D0 > >> > >> biosdevname=3D0 > >> > >> bootcmd=3Dmmc dev 0; fatload mmc 0:1 $kernel_addr > >> > >> $image_name;fatload mmc > >> > >> 0:1 $fdt_addr $fdt_name; bootefi $kernel_addr > >> > >> $fdt_addr > >> > >> bootdelay=3D2 > >> bootmmc=3Dmmc dev 0; fatload mmc 0:1 $kernel_addr > >> > >> $image_name;fatload mmc > >> > >> 0:1 $fdt_addr $fdt_name; bootefi $kernel_addr > >> > >> $fdt_addr > >> > >> console=3Dconsole=3DttyMV0,115200 > >> > >> earlycon=3Dar3700_uart,0xd0012000 > >> > >> eth1addr=3D00:51:82:11:22:01 > >> eth2addr=3D00:51:82:11:22:02 > >> eth3addr=3D00:51:82:11:22:03 > >> ethact=3Dneta@30000 > >> ethaddr=3DF0:AD:4E:09:6B:8F > >> ethprime=3Deth0 > >> fdt_addr=3D0x4f00000 > >> fdt_high=3D0xffffffffffffffff > >> fdt_name=3Defi/boot/armada-3720-espressobin.dtb > >> fdtcontroladdr=3D3f7161b8 > >> gatewayip=3D10.4.50.254 > >> get_images=3Dtftpboot $kernel_addr $image_name; > >> > >> tftpboot $fdt_addr > >> > >> $fdt_name; run get_ramfs > >> get_ramfs=3Dif test "${ramfs_name}" !=3D "-"; then setenv > >> > >> ramfs_addr > >> > >> 0x8000000; tftpboot $ramfs_addr $ramfs_name; else > >> > >> setenv ramfs_addr -;fi > >> > >> hostname=3Dmarvell > >> image_name=3Defi/freebsd/loader.efi > >> initrd_addr=3D0xa00000 > >> initrd_size=3D0x2000000 > >> ipaddr=3D0.0.0.0 > >> kernel_addr=3D0x5000000 > >> loadaddr=3D0x5000000 > >> netdev=3Deth0 > >> netmask=3D255.255.255.0 > >> ramfs_addr=3D0x8000000 > >> ramfs_name=3D- > >> root=3Droot=3D/dev/nfs rw > >> rootpath=3D/srv/nfs/ > >> serverip=3D0.0.0.0 > >> set_bootargs=3Dsetenv bootargs $console $root > >> > >> ip=3D$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:none > >> > >> nfsroot=3D$serverip:$rootpath $extra_params > >> stderr=3Dserial@12000 > >> stdin=3Dserial@12000 > >> stdout=3Dserial@12000 > >> > >> > >> ***Full boot logs:*** > >> > >> > >> U-Boot 2017.03-armada-17.10.2-g14aeedc (Jun 01 2018 - > >> > >> 15:39:10 +0800) > >> > >> > >> Model: Marvell Armada 3720 Community Board ESPRESSOBin > >> CPU @ 1000 [MHz] > >> L2 @ 800 [MHz] > >> TClock @ 200 [MHz] > >> DDR @ 800 [MHz] > >> DRAM: 1 GiB > >> U-Boot DT blob at : 000000003f7161b8 > >> Comphy-0: USB3 5 Gbps > >> Comphy-1: PEX0 2.5 Gbps > >> Comphy-2: SATA0 6 Gbps > >> SATA link 0 timeout. > >> AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA > >> > >> mode > >> > >> flags: ncq led only pmp fbss pio slum part sxs > >> PCIE-0: Link down > >> MMC: sdhci@d0000: 0, sdhci@d8000: 1 > >> SF: Detected mx25u3235f with page size 256 Bytes, > >> > >> erase size 64 KiB, > >> > >> total 4 MiB > >> Net: eth0: neta@30000 [PRIME] > >> Hit any key to stop autoboot: 0 > >> switch to partitions #0, OK > >> mmc0 is current device > >> reading efi/freebsd/loader.efi > >> 603872 bytes read in 49 ms (11.8 MiB/s) > >> reading efi/boot/armada-3720-espressobin.dtb > >> 15946 bytes read in 17 ms (916 KiB/s) > >> ## Starting EFI application at 05000000 ... > >> Scanning disk sdhci@d0000.blk <mailto:sdhci@d0000.blk > >> > >> ... > >> > >> Card did not respond to voltage select! > >> mmc_init: -95, time 50 > >> Found 1 disks > >> Consoles: EFI console > >> FreeBSD/arm64 EFI loader, Revision 1.1 > >> > >> Command line arguments: loader.efi > >> EFI version: 2.05 > >> EFI Firmware: Das U-boot (rev 0.00) > >> Console: efi (0) > >> Failed to find bootable partition > >> Startup error in /boot/lua/loader.lua: seconds > >> LUA ERROR: cannot open /boot/lua/loader.lua: invalid > >> > >> argument. > >> > >> > >> can't load 'kernel' > >> > >> Type '?' for a list of commands, 'help' for more > >> > >> detailed help. > >> > >> OK > >> OK set currdev=3Ddisk0p2 > >> OK boot > >> > >> /boot/kernel/kernel text=3D0x97d6a0 > >> > >> data=3D0x191b50+0x84ae94 > >> > >> syms=3D[0x8+0x137dd8+0x8+0x126260] > >> Using DTB provided by EFI at 0x8000000. > >> ---<<BOOT>>--- > >> KDB: debugger backends: ddb > >> KDB: current backend: ddb > >> Copyright (c) 1992-2019 The FreeBSD Project. > >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, > >> > >> 1991, 1992, 1993, 1994 > >> > >> The Regents of the University of California. All > >> > >> rights reserved. > >> > >> FreeBSD is a registered trademark of The FreeBSD > >> > >> Foundation. > >> > >> FreeBSD 13.0-CURRENT GENERIC arm64 > >> FreeBSD clang version 6.0.1 (tags/RELEASE_601/final > >> > >> 335540) (based on > >> > >> LLVM 6.0.1) > >> WARNING: WITNESS option enabled, expect reduced > >> > >> performance. > >> > >> VT: init without driver. > >> Starting CPU 1 (1) > >> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > >> arc4random: WARNING: initial seeding bypassed the > >> > >> cryptographic random > >> > >> device because it was not yet seeded and the knob > >> > >> 'bypass_before_seeding' > >> > >> was enabled. > >> random: entropy device external interface > >> MAP 3e681000 mode 2 pages 1 > >> MAP 3ffa6000 mode 2 pages 1 > >> kbd0 at kbdmux0 > >> ofwbus0: <Open Firmware Device Tree> > >> simplebus0: <Flattened device tree simple bus> on > >> > >> ofwbus0 > >> > >> simplebus1: <Flattened device tree simple bus> on > >> > >> simplebus0 > >> > >> simple_mfd0: <Simple MFD (Multi-Functions Device)> mem > >> 0x13800-0x138ff,0x13c00-0x13c1f on simplebus1 > >> simple_mfd1: <Simple MFD (Multi-Functions Device)> mem > >> 0x18800-0x188ff,0x18c00-0x18c1f on simplebus1 > >> psci0: <ARM Power State Co-ordination Interface > >> > >> Driver> on ofwbus0 > >> > >> gic0: <ARM Generic Interrupt Controller v3.0> mem > >> > >> > >> 0x1d00000-0x1d0ffff,0x1d40000-0x1d7ffff,0x1d80000-0x1d81fff,0x1d90000-= 0x1d91fff,0x1da0000-0x1dbffff > >> > >> irq 27 on simplebus1 > >> gpio0: <Armada 37x0 North Bridge GPIO Controller> mem > >> 0x13800-0x138ff,0x13c00-0x13c1f irq > >> > >> 28,29,30,31,32,33,34,35,36,37,38,39 on > >> > >> simple_mfd0 > >> gpio0: cannot allocate memory window > >> device_attach: gpio0 attach returned 6 > >> gpio0: <Armada 37x0 South Bridge GPIO Controller> mem > >> 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 on > >> > >> simple_mfd1 > >> > >> gpio0: cannot allocate memory window > >> device_attach: gpio0 attach returned 6 > >> gpioregulator0: <GPIO controlled regulator> on ofwbus0 > >> gpioregulator0: cannot get pin 0 > >> gpioregulator0: cannot parse parameters > >> device_attach: gpioregulator0 attach returned 6 > >> generic_timer0: <ARMv8 Generic Timer> irq 0,1,2,3 on > >> > >> ofwbus0 > >> > >> Timecounter "ARM MPCore Timecounter" frequency > >> > >> 12500000 Hz quality 1000 > >> > >> Event timer "ARM MPCore Eventtimer" frequency > >> > >> 12500000 Hz quality 1000 > >> > >> gpio0: <Armada 37x0 North Bridge GPIO Controller> mem > >> 0x13800-0x138ff,0x13c00-0x13c1f irq > >> > >> 28,29,30,31,32,33,34,35,36,37,38,39 on > >> > >> simple_mfd0 > >> gpio0: cannot allocate memory window > >> device_attach: gpio0 attach returned 6 > >> gpio0: <Armada 37x0 South Bridge GPIO Controller> mem > >> 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 on > >> > >> simple_mfd1 > >> > >> gpio0: cannot allocate memory window > >> device_attach: gpio0 attach returned 6 > >> gpioregulator0: <GPIO controlled regulator> on ofwbus0 > >> gpioregulator0: cannot get pin 0 > >> gpioregulator0: cannot parse parameters > >> device_attach: gpioregulator0 attach returned 6 > >> gpio0: <Armada 37x0 North Bridge GPIO Controller> mem > >> 0x13800-0x138ff,0x13c00-0x13c1f irq > >> > >> 28,29,30,31,32,33,34,35,36,37,38,39 on > >> > >> simple_mfd0 > >> gpio0: cannot allocate memory window > >> device_attach: gpio0 attach returned 6 > >> gpio0: <Armada 37x0 South Bridge GPIO Controller> mem > >> 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 on > >> > >> simple_mfd1 > >> > >> gpio0: cannot allocate memory window > >> device_attach: gpio0 attach returned 6 > >> gpioregulator0: <GPIO controlled regulator> on ofwbus0 > >> gpioregulator0: cannot get pin 0 > >> gpioregulator0: cannot parse parameters > >> device_attach: gpioregulator0 attach returned 6 > >> gpio0: <Armada 37x0 North Bridge GPIO Controller> mem > >> 0x13800-0x138ff,0x13c00-0x13c1f irq > >> > >> 28,29,30,31,32,33,34,35,36,37,38,39 on > >> > >> simple_mfd0 > >> gpio0: cannot allocate memory window > >> device_attach: gpio0 attach returned 6 > >> gpio0: <Armada 37x0 South Bridge GPIO Controller> mem > >> 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 on > >> > >> simple_mfd1 > >> > >> gpio0: cannot allocate memory window > >> device_attach: gpio0 attach returned 6 > >> gpioregulator0: <GPIO controlled regulator> on ofwbus0 > >> gpioregulator0: cannot get pin 0 > >> gpioregulator0: cannot parse parameters > >> device_attach: gpioregulator0 attach returned 6 > >> gpio0: <Armada 37x0 North Bridge GPIO Controller> mem > >> 0x13800-0x138ff,0x13c00-0x13c1f irq > >> > >> 28,29,30,31,32,33,34,35,36,37,38,39 on > >> > >> simple_mfd0 > >> gpio0: cannot allocate memory window > >> device_attach: gpio0 attach returned 6 > >> gpio0: <Armada 37x0 South Bridge GPIO Controller> mem > >> 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 on > >> > >> simple_mfd1 > >> > >> gpio0: cannot allocate memory window > >> device_attach: gpio0 attach returned 6 > >> gpioregulator0: <GPIO controlled regulator> on ofwbus0 > >> gpioregulator0: cannot get pin 0 > >> gpioregulator0: cannot parse parameters > >> device_attach: gpioregulator0 attach returned 6 > >> cpulist0: <Open Firmware CPU Group> on ofwbus0 > >> cpu0: <Open Firmware CPU> on cpulist0 > >> cpu1: <Open Firmware CPU> on cpulist0 > >> pmu0: <Performance Monitoring Unit> irq 4 on ofwbus0 > >> syscon_generic0: <syscon> mem 0xd000-0xdfff on > >> > >> simplebus1 > >> > >> syscon_generic1: <syscon> mem 0x11500-0x1153f on > >> > >> simplebus1 > >> > >> uart0: <Marvell Armada 3700 UART> mem 0x12000-0x121ff > >> > >> irq 9,10,11 on > >> > >> simplebus1 > >> uart0: console (115200,n,8,1) > >> gpio0: <Armada 37x0 North Bridge GPIO Controller> mem > >> 0x13800-0x138ff,0x13c00-0x13c1f irq > >> > >> 28,29,30,31,32,33,34,35,36,37,38,39 on > >> > >> simple_mfd0 > >> gpio0: cannot allocate memory window > >> device_attach: gpio0 attach returned 6 > >> syscon_generic2: <syscon> mem 0x14000-0x1405f on > >> > >> simplebus1 > >> > >> gpio0: <Armada 37x0 South Bridge GPIO Controller> mem > >> 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 on > >> > >> simple_mfd1 > >> > >> gpio0: cannot allocate memory window > >> device_attach: gpio0 attach returned 6 > >> mvneta0: <NETA controller> mem 0x30000-0x33fff irq 14 > >> > >> on simplebus1 > >> > >> mvneta0: version is 10 > >> mvneta0: Ethernet address: 00:a6:39:ca:e8:00 > >> mdio0: <MDIO> on mvneta0 > >> mdioproxy0: <MII/MDIO proxy, MDIO side> on mdio0 > >> e6000sw0: <Marvell 88E6341> on mdio0 > >> e6000sw0: multi-chip addressing mode (0x1) > >> e6000sw0: CPU port at 0 > >> e6000sw0: fixed port at 0 > >> e6000sw0: PHY at port 1 > >> miibus0: <MII bus> on e6000sw0 > >> e1000phy0: <Marvell 88E1000 Gigabit PHY> PHY 17 on > >> > >> miibus0 > >> > >> e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, > >> > >> 100baseTX-FDX, > >> > >> 1000baseT, 1000baseT-master, 1000baseT-FDX, > >> > >> 1000baseT-FDX-master, auto > >> > >> e6000sw0: PHY at port 2 > >> miibus1: <MII bus> on e6000sw0 > >> e1000phy1: <Marvell 88E1000 Gigabit PHY> PHY 18 on > >> > >> miibus1 > >> > >> e1000phy1: none, 10baseT, 10baseT-FDX, 100baseTX, > >> > >> 100baseTX-FDX, > >> > >> 1000baseT, 1000baseT-master, 1000baseT-FDX, > >> > >> 1000baseT-FDX-master, auto > >> > >> e6000sw0: PHY at port 3 > >> miibus2: <MII bus> on e6000sw0 > >> e1000phy2: <Marvell 88E1000 Gigabit PHY> PHY 19 on > >> > >> miibus2 > >> > >> e1000phy2: none, 10baseT, 10baseT-FDX, 100baseTX, > >> > >> 100baseTX-FDX, > >> > >> 1000baseT, 1000baseT-master, 1000baseT-FDX, > >> > >> 1000baseT-FDX-master, auto > >> > >> e6000sw0: switch is ready. > >> etherswitch0: <Switch controller> on e6000sw0 > >> xhci0: <Generic USB 3.0 controller> mem > >> > >> 0x58000-0x5bfff irq 16 on > >> > >> simplebus1 > >> xhci0: 32 bytes context size, 32-bit DMA > >> usbus0 on xhci0 > >> syscon_generic3: <syscon> mem 0x5d800-0x5dfff on > >> > >> simplebus1 > >> > >> ehci0: <Marvell Integrated USB 2.0 controller> mem > >> > >> 0x5e000-0x5efff irq > >> > >> 17 on simplebus1 > >> usbus1: EHCI version 1.0 > >> usbus1 on ehci0 > >> syscon_generic4: <syscon> mem 0x5f800-0x5ffff on > >> > >> simplebus1 > >> > >> sdhci_xenon0: <Armada Xenon SDHCI controller> mem > >> 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 > >> ahci0: <AHCI SATA controller> mem 0xe0000-0xe0177 irq > >> > >> 26 on simplebus1 > >> > >> ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier > >> > >> supported with FBS > >> > >> ahcich0: <AHCI channel> at channel 0 on ahci0 > >> device_attach: ahcich0 attach returned 6 > >> gpioregulator0: <GPIO controlled regulator> on ofwbus0 > >> gpioregulator0: cannot get pin 0 > >> gpioregulator0: cannot parse parameters > >> device_attach: gpioregulator0 attach returned 6 > >> cryptosoft0: <software crypto> > >> Timecounters tick every 1.000 msec > >> mvneta0: link state changed to UP > >> e6000sw0port1: link state changed to DOWN > >> e6000sw0port2: link state changed to DOWN > >> e6000sw0port3: link state changed to DOWN > >> usbus0: 5.0Gbps Super Speed USB v3.0 > >> usbus1: 480Mbps High Speed USB v2.0 > >> Release APs...done > >> CPU 0: ARM Cortex-A53 r0p4 affinity: 0 > >> Instruction Set Attributes 0 =3D > >> > >> <CRC32,SHA2,SHA1,AES+PMULL> > >> > >> Trying to mount root from > >> > >> ufs:/dev/ufs/FreeBSD_Install [ro,noatime]... > >> > >> Instruction Set Attributes 1 =3D <> > >> Root mount waiting for: Processor Features 0 =3D > >> <GIC,AdvSIMD,Float,EL3 32,EL2 32,EL1 32,EL0 32> > >> usbus1 Processor Features 1 =3D <0> > >> usbus0 Memory Model Features 0 =3D <4k Granule,64k > >> > >> Granule,S/NS > >> > >> Mem,MixedEndian,16bit ASID,1TB PA> > >> > >> Memory Model Features 1 =3D <> > >> Memory Model Features 2 =3D <32b CCIDX,48b VA> > >> Debug Features 0 =3D <2 CTX Breakpoints,4 > >> > >> Watchpoints,6 > >> > >> Breakpoints,PMUv3,Debug v8> > >> Debug Features 1 =3D <0> > >> Auxiliary Features 0 =3D <0> > >> Auxiliary Features 1 =3D <0> > >> CPU 1: ARM Cortex-A53 r0p4 affinity: 1 > >> WARNING: WITNESS option enabled, expect reduced > >> > >> performance. > >> > >> ugen0.1: <Generic XHCI root HUB> at usbus0 > >> ugen1.1: <Marvell EHCI root HUB> at usbus1 > >> uhub0 on usbus0 > >> uhub1 on usbus1 > >> uhub0: <Generic XHCI root HUB, class 9/0, rev > >> > >> 3.00/1.00, addr 1> on > >> > >> usbus0 > >> uhub1: <Marvell EHCI root HUB, class 9/0, rev > >> > >> 2.00/1.00, addr 1> on > >> > >> usbus1 > >> uhub0: 2 ports with 2 removable, self powered > >> uhub1: 1 port with 1 removable, self powered > >> mountroot: waiting for device > >> > >> /dev/ufs/FreeBSD_Install... > >> > >> Mounting from ufs:/dev/ufs/FreeBSD_Install failed > >> > >> with error 19. > >> > >> > >> Loader variables: > >> vfs.root.mountfrom=3Dufs:/dev/ufs/FreeBSD_Install > >> vfs.root.mountfrom.options=3Dro,noatime > >> > >> Manual root filesystem specification: > >> <fstype>:<device> [options] > >> Mount <device> using filesystem <fstype> > >> and with the specified (optional) option list. > >> > >> eg. ufs:/dev/da0s1a > >> zfs:zroot/ROOT/default > >> cd9660:/dev/cd0 ro > >> (which is equivalent to: mount -t cd9660 -o ro > >> > >> /dev/cd0 /) > >> > >> > >> ? List valid disk boot devices > >> . Yield 1 second (for background tasks) > >> <empty line> Abort manual input > >> > >> mountroot> ? > >> > >> List of GEOM managed disk devices: > >> > >> > >> mountroot> > >> _______________________________________________ > >> freebsd-arm@freebsd.org <mailto: > >> > >> freebsd-arm@freebsd.org> mailing list > >> > >> > >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm < > >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm>; > >> > >> To unsubscribe, send any mail to " > >> > >> freebsd-arm-unsubscribe@freebsd.org <mailto: > >> freebsd-arm-unsubscribe@freebsd.org>" > >> > >> > >> _______________________________________________ > >> freebsd-arm@freebsd.org <mailto: > >> > >> freebsd-arm@freebsd.org> mailing list > >> > >> > >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm < > >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm>; > >> > >> To unsubscribe, send any mail to " > >> > >> freebsd-arm-unsubscribe@freebsd.org <mailto: > >> freebsd-arm-unsubscribe@freebsd.org>" > >> > >> > >> > >> > >> -- > >> Emmanuel Vadot <manu@bidouilliste.com> < > >> > >> manu@freebsd.org> > >> > >> > >> > >> > >> -- > >> Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org> > >> > >> > >> > >> -- > >> Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org> > >> _______________________________________________ > >> freebsd-arm@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm > >> To unsubscribe, send any mail to " > >> > >> freebsd-arm-unsubscribe@freebsd.org" > >> > >> > >> > >> -- > >> Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org> > >> _______________________________________________ > >> freebsd-arm@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm > >> To unsubscribe, send any mail to " > >> > >> freebsd-arm-unsubscribe@freebsd.org" > >> > >> > >> > >> -- > >> Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org> > >> _______________________________________________ > >> freebsd-arm@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm > >> To unsubscribe, send any mail to " > >> > >> freebsd-arm-unsubscribe@freebsd.org" > >> > >> > >> > >> -- > >> Emmanuel Vadot <manu@bidouilliste.com <mailto: > >> > >> manu@bidouilliste.com>> <manu@freebsd.org <mailto:manu@freebsd.org>> > >> > >> > >> > >> > >> -- > >> Emmanuel Vadot <manu@bidouilliste.com <mailto: > >> > >> manu@bidouilliste.com>> <manu@freebsd.org <mailto:manu@freebsd.org>> > >> > >> > >> > >> > >> -- > >> Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org> > >> _______________________________________________ > >> freebsd-arm@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm > >> To unsubscribe, send any mail to " > >> freebsd-arm-unsubscribe@freebsd.org" > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> freebsd-arm@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm > >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > >> > >> > >> > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >=20 >=20 >=20 From owner-freebsd-arm@freebsd.org Tue Aug 20 13:22:35 2019 Return-Path: <owner-freebsd-arm@freebsd.org> Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 777D2D22DD for <freebsd-arm@mailman.nyi.freebsd.org>; Tue, 20 Aug 2019 13:22:35 +0000 (UTC) (envelope-from per@hedeland.org) Received: from outbound1f.eu.mailhop.org (outbound1f.eu.mailhop.org [52.28.59.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46CWgG1CxXz4M0p for <freebsd-arm@freebsd.org>; Tue, 20 Aug 2019 13:22:33 +0000 (UTC) (envelope-from per@hedeland.org) ARC-Seal: i=1; a=rsa-sha256; t=1566307352; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=SHceF4ooCP1wBUjX+N6GsfKYUNU7k1p5onPa3PGoXuuxw2HdRgMeOPaX086bs+F/8BknkGvrmZQOs 6oeShy6ydMi1i1Qhzs8VxYvQP13o8GYflR6rtVDpeWJpxcdguciqhSCD8JQ1s85rI7YYs/LIg1eJSk lHXTQ1TelDx5/leKtJw1EZjcd3zNywVXsqOyuNMFJSlJKV/p7gyqU0GfuX9Moo/eAxJEEnoQbTltBt 2rA1XUKsBdPNupgFsrEYfH+3hBCkdzDfzz2F72tfRqJxNzY6NI6Vu6etNmyY0lbYAmQWKVaZYpbLJL EcN902tVPZ9xqMksXmP2h6ajjHotw3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:references:cc:to:subject:dkim-signature:from; bh=735sxqa4xDD7yfG3BbIGsPiZ9NkUDQrVKwXQpbr5VGU=; b=SuECPvZCNoXxy/E5bIGjqf06wJ1l78p5jgh2mkRZWLvDLEGf8kqDj4FX/UldUwJXXGZptQlyJAknc efw5JlPiSNzzpNTokIaO8fdqSbTh8nxzZp9bfjW+1EB8QakNGb2mx/frfVw6sTmq+5AAZYx3FvGYVv kh7r3RLsLMTyNuihn7juysYrZok1waDyx4fM0h3rThaZAUxoY+p+4xUI+/tTMYL0DY7AWgX7fjVl4+ rxqq5m95QccsF0Zh45vVkSTT8et8RTw8io3IU90J0kjLB5N5p4ZwYlD22ERNcMxrTsUgSl/7YokT8O mrmVNHjfJmlArByPluStqytJW/PPezg== ARC-Authentication-Results: i=1; outbound2.eu.mailhop.org; spf=none smtp.mailfrom=hedeland.org smtp.remote-ip=81.228.157.209; dmarc=none header.from=hedeland.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:references:cc:to:subject:from; bh=735sxqa4xDD7yfG3BbIGsPiZ9NkUDQrVKwXQpbr5VGU=; b=ZpgPGJ4LfD96Mhk/Vdk7lQvh6M2JdK0nklrdgOSnUC/A7JpZ9yJIFqCv0Bsz0norJfjRk7XycFYkx DZmzMZ8z3hplivzNH22ZALYOfcq4cGrU1BmR2uvPeV09f+T5Exi9lr0BjBWjhueT68GPUOQP1SIIhL BQUQNbP8iGYbUfXVl3LPqJ/ozF/ukrLEVHYOmfv+PrP/2omXBKAuc/UwpG0ZABM2Ue080DPvtt00sg REcQ/3OMYQ6vMHQJATDleoJhOPVvvuieUNKfzIFxnuAhzyEjPYXnlR0MLER04zuKot+MGincr+hGDY 9DCeumVT78TnRNE+2l9CZzp/Wg+eZeA== X-MHO-RoutePath: cGVyaGVkZWxhbmQ= X-MHO-User: 8e8d1f77-c34d-11e9-a204-f5e3bb5d0a28 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 81.228.157.209 X-Mail-Handler: DuoCircle Outbound SMTP Received: from hedeland.org (unknown [81.228.157.209]) by outbound2.eu.mailhop.org (Halon) with ESMTPSA id 8e8d1f77-c34d-11e9-a204-f5e3bb5d0a28; Tue, 20 Aug 2019 13:22:29 +0000 (UTC) Received: from plutt.hedeland.org (82-209-140-38.cust.bredband2.com [82.209.140.38]) (authenticated bits=0) by tellus.hedeland.org (8.15.2/8.15.2) with ESMTPSA id x7KDMR3Z062393 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 20 Aug 2019 15:22:28 +0200 (CEST) (envelope-from per@hedeland.org) X-Authentication-Warning: tellus.hedeland.org: Host 82-209-140-38.cust.bredband2.com [82.209.140.38] claimed to be plutt.hedeland.org Subject: Re: Is it a good idea to use a usb-serial adapter for PPS? Yes, it is. To: Hans Petter Selasky <hps@selasky.org>, Ian Lepore <ian@freebsd.org> Cc: freebsd-arm@freebsd.org References: <alpine.BSF.2.21.99999.352.1908071046410.98975@autopsy.pc.athabascau.ca> <69a9bed3-4d0a-f8f6-91af-a8f7d84ee307@hedeland.org> <345bae77417c2495f55799b4c7ca2784f4ece9ed.camel@freebsd.org> <7312032d-2908-9414-0445-6b442c3a02e5@hedeland.org> <523b6f0a0fa5f2aeec298fa74df25d3c4af66acc.camel@freebsd.org> <0426fc8b-5398-d8ab-561e-7823c24403a5@hedeland.org> <24b0eaf25b64d6098b390df092866c69e352d859.camel@freebsd.org> <16c91be1-6f2a-b26d-22c7-be8e4ba8eec0@hedeland.org> <72a964c78cbfc36be2345919633ca2196f0783e3.camel@freebsd.org> <fe2c2d77-3030-6734-e1d8-c1375f231a24@hedeland.org> <cd1b38bb0b8873af96a41bce1b03676f735ae3f9.camel@freebsd.org> <540c8b5f-5e81-b67b-4a00-49b86044efe0@selasky.org> <8e28c96e-92c6-5beb-277f-0876a5aba272@hedeland.org> <ce77ae35-40dc-1f97-110f-74e354cf3725@selasky.org> From: Per Hedeland <per@hedeland.org> Message-ID: <a1665b75-cba6-6cd6-b68b-a1a1b0ea7392@hedeland.org> Date: Tue, 20 Aug 2019 15:22:22 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: <ce77ae35-40dc-1f97-110f-74e354cf3725@selasky.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46CWgG1CxXz4M0p X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=outbound.mailhop.org header.s=dkim-high header.b=ZpgPGJ4L; dmarc=none; spf=none (mx1.freebsd.org: domain of per@hedeland.org has no SPF policy when checking 52.28.59.28) smtp.mailfrom=per@hedeland.org X-Spamd-Result: default: False [-5.54 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_XOIP(0.00)[]; TO_DN_SOME(0.00)[]; HAS_XAW(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[outbound.mailhop.org:+]; NEURAL_HAM_SHORT(-0.98)[-0.976,0]; RECEIVED_SPAMHAUS_PBL(0.00)[209.157.228.81.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11,38.140.209.82.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_ALLOW(-1.00)[i=1]; IP_SCORE(-1.26)[ipnet: 52.28.0.0/16(-4.89), asn: 16509(-1.35), country: US(-0.05)]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[outbound.mailhop.org:s=dkim-high]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:16509, ipnet:52.28.0.0/16, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[hedeland.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[28.59.28.52.list.dnswl.org : 127.0.20.0]; R_SPF_NA(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>, <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>; List-Post: <mailto:freebsd-arm@freebsd.org> List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>, <mailto:freebsd-arm-request@freebsd.org?subject=subscribe> X-List-Received-Date: Tue, 20 Aug 2019 13:22:35 -0000 On 2019-08-20 13:50, Hans Petter Selasky wrote: > On 2019-08-20 13:38, Per Hedeland wrote: >> >> I'm sorry, I'm afraid I still don't really understand... The question, >> at least in my mind, was whether polling was done in a "strictly >> periodic" fashion, at most once per 125 us for USB 2.0 - or whether >> the host controller would poll "as fast as it could", which could >> result in a *much* higher polling rate. > > That depends on the endpoint type. INTERRUPT endpoints poll regularly, one time, every 125 us for example, when a job is queued. BULK endpoints poll all the time, depending a bit on the HC in use. OK, Ian reported earlier that the FTDI usb-serial adapter he used was using BULK transfers, so far so good... > Anyways, the computer is not notified of the completion before the HC is generating an interrupt. This usually happens at some fixed point in time. I.E. multiple completions can be joined into one HC interrupt. It is the completion interrupt which > notifies the software about the PPS event. ...but this sounds like we might be back to square one... Is there a fixed interval between those fixed points in time, and what would the length of that interval be? And, what is the source for the generation of the intervals? On 2019-08-20 13:53, Hans Petter Selasky wrote: > On 2019-08-20 13:38, Per Hedeland wrote: >> >> This sounds like a method to determine a fixed latency - or am I >> misunderstanding? > > The HC sends out a timestamp, called SOF, to all USB devices every 1ms or 125us. This SOF mark is usually the beginning of the polling schedule. All USB endpoints are polled by the HC. The USB device can predict the time of the SOF and also > completion on the HC and so I believe adjust the timestamp, so that it would appear to be received instantaneously. Hm, but this doesn't sound like something an off-the-shelf usb-serial adapter could or would do, I think? --Per
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?912587110.50.1566305035850>