svn timeout - Re: Espressobin anyone ?

[Russell Haley]

On Mon, Aug 26, 2019 at 2:15 PM Ronald Klop <ronald-lists at klop.ws> wrote:

> On Fri, 23 Aug 2019 00:27:00 +0200, Jeffrey Bowers <khantroll at gmail.com>
> wrote:
>
> > No, unfortunately it still ends in an E000060: Operation timed out.
> > However, there are files and directories in my local ports directory,
> > >so it's downloading at least some things.
>
>
> One more option I can think of.
>   svn checkout svn://svn.freebsd.org/ports/head


I reverted to using the svn protocol many moons ago because http wouldn't
work at all. The svn protocol still fails a few times on any given
checkout, but re-starting the checkout picks up where it left off. I always
build on a PC so it's not a slow SD card problem, it seems to be a long
standing issue retrieving source code.

Just my observation,
Russ

>
>
> So not svn+ssh://, but only svn://. I just noticed my RPI3 uses that for
> sources.
>
> Something else I have seen in the past is that the local disk (like a
> cheap SD-card) can be too slow and causes timeouts because SVN can't
> write
> fast enough to keep the network busy. Which might happen earlier if you
> checkout using https compared to the svn-protocol.
>
> Ronald.
>
>
>
> >
> > On Tue, Aug 20, 2019 at 2:01 PM Ronald Klop <ronald-lists at klop.ws>
> wrote:
> >> On Wed, 21 Aug 2019 01:03:37 +0200, Jeffrey Bowers
> >> <khantroll at gmail.com> wrote:
> >>
> >>> Yes sir, I can ping  svn.freebsd.org. Any idea why the checkout fails?
> >>
> >> I don't know. What ip address do you get when pinging?
> >>
> >> Does this work for you? Does it work using the ip address you get?
> >>
> >> svn checkout https://213.138.116.72/ports/head
> >>
> >> Regards,
> >> Ronald.
> >>
> >>
> >>
> >>>
> >>> On Tue, Aug 20, 2019 at 7:46 AM Ronald Klop <ronald-lists at klop.ws>
> >>> wrote:
> >>>> It is not possible to 'ping https://svn.freebsd.org/ports/head'.
> >>>> You can 'ping svn.freebsd.org'.
> >>>>
> >>>> Ronald.
> >>>>
> >>>> Van: Jeffrey Bowers <khantroll at gmail.com>
> >>>> Datum: dinsdag, 20 augustus 2019 14:36
> >>>> Aan: "Søren Schmidt" <soren.schmidt at gmail.com>, freebsd-arm
> >>>> <freebsd-arm at freebsd.org>
> >>>> Onderwerp: Re: Espressobin anyone ?
> >>>>> I just tried to ping  https://svn.freebsd.org/ports/head, and even
> >>>>> though
> >>>>> it scrolsl through all that text I get an error saying "could not
> >>>>> resolve
> >>>>> https://svn.freebsd.org/ports/head ; unknown server error" . I can
> >>>>> ping
> >>>>> google just fine. Is it a DNS issue?
> >>>>>
> >>>>> On Tue, Aug 20, 2019 at 7:33 AM Jeffrey Bowers <khantroll at gmail.com>
>
> >>>>> wrote:
> >>>>>
> >>>>>> I'm still getting:  svn: E000060: Operation timed out
> >>>>>> It goes for several minutes scrolling through text, and I feel
> like
> >>>>>> using
> >>>>>> your link got further.
> >>>>>>
> >>>>>> Thanks!
> >>>>>>
> >>>>>> On Tue, Aug 20, 2019 at 2:49 AM Søren Schmidt
> >>>>>> <soren.schmidt at gmail.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hmm, I use this URL
> >>>>>>>
> >>>>>>> Repository Root: https://svn.freebsd.org/ports/head
> >>>>>>>
> >>>>>>> Not sure the svn+ssh thing works…
> >>>>>>>
> >>>>>>> -Søren
> >>>>>>>
> >>>>>>>
> >>>>>>> On 20 Aug 2019, at 02.38, Jeffrey Bowers <khantroll at 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
> >>>>>>> option
> >>>>>>> from 'ssh' in the [tunnels] section of your Subversion
> >>>>>>> configuration file.
> >>>>>>>
> >>>>>>> Any ideas?
> >>>>>>>
> >>>>>>> Thanks in advance!
> >>>>>>>
> >>>>>>> On Mon, Aug 19, 2019 at 8:51 PM Jeffrey Bowers
> >>>>>>> <khantroll at gmail.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>> I didn't think it remounting. Thank you!
> >>>>>>>
> >>>>>>> On Mon, Aug 19, 2019 at 11:39 AM Søren Schmidt
> >>>>>>> <soren.schmidt at gmail.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>> Hi Jeffrey
> >>>>>>>
> >>>>>>> You need to unmount the /tmp filesystem :)
> >>>>>>> You can do that permanently by commenting it out in /etc/fstab
> >>>>>>>
> >>>>>>>
> >>>>>>> On 19 Aug 2019, at 21.45, Jeffrey Bowers <khantroll at gmail.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>> Hi Soren,
> >>>>>>>
> >>>>>>> I'm getting the same error message. Any other ideas what it might
> >>>>>>> be?
> >>>>>>> It's got to be something in the partition scheme or the file
> >>>>>>> permissions,
> >>>>>>> but I'm just not sure what.
> >>>>>>> <image.png>
> >>>>>>>
> >>>>>>> On Sun, Aug 18, 2019 at 10:03 AM Jeffrey Bowers
> >>>>>>> <khantroll at gmail.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>> D’Oh! I thought I too care of that with gpart. I literally missed
> >>>>>>> growfs
> >>>>>>> part of the instructions..
> >>>>>>>
> >>>>>>> On Sun, Aug 18, 2019 at 10:00 AM Søren Schmidt
> >>>>>>> <soren.schmidt at gmail.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>> Hi
> >>>>>>>
> >>>>>>> You are out of space :)
> >>>>>>>
> >>>>>>> Boot the board into singleuser mode, and do “service growfs start”,
> >>>>>>> that will expand you / filesystem to the entire SD card…
> >>>>>>>
> >>>>>>> -Søren
> >>>>>>>
> >>>>>>> On 18 Aug 2019, at 14.50, Jeffrey Bowers <khantroll at gmail.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>> Sure thing! Here's the screenshot!
> >>>>>>> <image.png>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Sun, Aug 18, 2019 at 7:35 AM Søren Schmidt
> >>>>>>> <soren.schmidt at gmail.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>> Hi
> >>>>>>>
> >>>>>>> Can I have you paste the output from df -h ?
> >>>>>>>
> >>>>>>> You should be able to utilise the full SD card…
> >>>>>>>
> >>>>>>> -Søren
> >>>>>>>
> >>>>>>> On 18 Aug 2019, at 14.29, Jeffrey Bowers <khantroll at 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’t mount to another director
> >>>>>>> on the
> >>>>>>> hard drive?
> >>>>>>>
> >>>>>>> On Sun, Aug 18, 2019 at 5:11 AM Søren Schmidt
> >>>>>>> <soren.schmidt at 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’s 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…
> >>>>>>>
> >>>>>>> -Søren
> >>>>>>>
> >>>>>>> On 18 Aug 2019, at 00.22, Jeffrey Bowers <khantroll at 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 at bidouilliste.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>> On Sat, 17 Aug 2019 17:14:36 +0200
> >>>>>>> Søren Schmidt <soren.schmidt at 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øren
> >>>>>>>
> >>>>>>> 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 at bidouilliste.com>
> >>>>>>>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> On Sat, 17 Aug 2019 11:07:22 +0200
> >>>>>>> Søren Schmidt <soren.schmidt at gmail.com <mailto:
> >>>>>>>
> >>>>>>> soren.schmidt at 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øren
> >>>>>>>
> >>>>>>>
> >>>>>>> P.S. Please stop top posting, it's really hard to read the
> >>>>>>>
> >>>>>>> conversation
> >>>>>>>
> >>>>>>>
> >>>>>>> On 16 Aug 2019, at 22.58, Emmanuel Vadot <
> >>>>>>>
> >>>>>>> manu at bidouilliste.com> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> On Fri, 16 Aug 2019 19:12:30 +0200
> >>>>>>> Emmanuel Vadot <manu at bidouilliste.com <mailto:
> >>>>>>>
> >>>>>>> manu at bidouilliste.com>> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> On Fri, 16 Aug 2019 17:10:37 +0200
> >>>>>>> Emmanuel Vadot <manu at bidouilliste.com> wrote:
> >>>>>>>
> >>>>>>> On Fri, 16 Aug 2019 15:24:54 +0200
> >>>>>>> Emmanuel Vadot <manu at bidouilliste.com> wrote:
> >>>>>>>
> >>>>>>> On Fri, 16 Aug 2019 07:28:59 +0200
> >>>>>>> Søren Schmidt <soren.schmidt at gmail.com> wrote:
> >>>>>>>
> >>>>>>> Hi
> >>>>>>>
> >>>>>>> Very simple, reverting sys/gnu/dts to what was before
> >>>>>>>
> >>>>>>> 350595 (actually 350592).
> >>>>>>>
> >>>>>>> Thats what we have svn for ?
> >>>>>>>
> >>>>>>>
> >>>>>>> If I asked how it was to have the svn command that you
> >>>>>>>
> >>>>>>> used, I want to
> >>>>>>>
> >>>>>>> make sure that you didn't revert anything else, like do you
> >>>>>>>
> >>>>>>> have
> >>>>>>>
> >>>>>>> r350596 and r350628 ?
> >>>>>>>
> >>>>>>> That does make my bananapi work again, no other changes
> >>>>>>>
> >>>>>>> just a recompiled kernel.
> >>>>>>>
> >>>>>>>
> >>>>>>> That + copying the dtb to the fat32 partition ?
> >>>>>>>
> >>>>>>> Can you post the dtb somewhere.
> >>>>>>>
> >>>>>>> However it does not bring the Espressobin back to life,
> >>>>>>>
> >>>>>>> thats something in one of the ~30 other files that changed
> between
> >>>>>>> those
> >>>>>>> two revisions.
> >>>>>>>
> >>>>>>>
> >>>>>>> What Linux version of DTS are you using then ? The ones
> >>>>>>>
> >>>>>>> that were in
> >>>>>>>
> >>>>>>> stable/12 when it was branched (4.18) or a later revision ?
> >>>>>>>
> >>>>>>>
> >>>>>>> So I think that I've found the problem on the Espressobin.
> >>>>>>> I think that the problem comes from the simple-mfd driver
> >>>>>>>
> >>>>>>> that I've
> >>>>>>>
> >>>>>>> mfc in r350600.
> >>>>>>> The pinctrl/gpio controller compatible is
> >>>>>>> "marvell,armada3710-nb-pinctrl", "syscon", "simple-mfd" and
> >>>>>>>
> >>>>>>> it attaches
> >>>>>>>
> >>>>>>> at BUS_PASS_INTERRUPT while the simple_mfd driver attaches at
> >>>>>>> BUS_PASS_BUS (so earlier) which means that no gpio
> >>>>>>>
> >>>>>>> controller will be
> >>>>>>>
> >>>>>>> available for sdhci to detect the card.
> >>>>>>>
> >>>>>>> If someone with a non-working espressobin could post a full
> >>>>>>>
> >>>>>>> verbose
> >>>>>>>
> >>>>>>> boot log that would help me confirming that this is the case.
> >>>>>>> I'll try to find a solution on how to solve this problem.
> >>>>>>>
> >>>>>>>
> >>>>>>> So this wasn't the problem but I've found it, see r351129 and
> >>>>>>>
> >>>>>>> r351130
> >>>>>>>
> >>>>>>>
> >>>>>>> SD card now work again in HEAD, I'll have a look at stable
> >>>>>>>
> >>>>>>> later next
> >>>>>>>
> >>>>>>> week.
> >>>>>>>
> >>>>>>>
> >>>>>>> I've did a quick test and I've MFC r348880, r348882 and
> >>>>>>>
> >>>>>>> r349596, the
> >>>>>>>
> >>>>>>> two other commits needed to be mfc'ed are the one I did today
> >>>>>>>
> >>>>>>> on head,
> >>>>>>>
> >>>>>>> I'll do that next week.
> >>>>>>> With them sdcard is working again on stable/12
> >>>>>>>
> >>>>>>> -Søren
> >>>>>>>
> >>>>>>> On 15 Aug 2019, at 23.37, Emmanuel Vadot <
> >>>>>>>
> >>>>>>> manu at bidouilliste.com> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> On Thu, 15 Aug 2019 21:56:23 +0200
> >>>>>>> Søren Schmidt <soren.schmidt at 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=0 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øren
> >>>>>>>
> >>>>>>>
> >>>>>>> On 15 Aug 2019, at 21.03, Emmanuel Vadot <
> >>>>>>>
> >>>>>>> manu at bidouilliste.com> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> On Thu, 15 Aug 2019 19:48:54 +0200
> >>>>>>> Søren Schmidt <soren.schmidt at 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øren
> >>>>>>>
> >>>>>>>
> >>>>>>> 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=0
> >>>>>>> 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 at 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øren Schmidt" <soren.schmidt at gmail.com
> >>>>>>>
> >>>>>>> <mailto:soren.schmidt at gmail.com>>
> >>>>>>>
> >>>>>>> To: "Mit Matelske" <mit at pt.net <mailto:mit at pt.net>>
> >>>>>>> Cc: "Marcin Wojtas" <mw at semihalf.com <mailto:
> >>>>>>>
> >>>>>>> mw at semihalf.com>>, "freebsd-arm" <freebsd-arm at freebsd.org <mailto:
> >>>>>>> freebsd-arm at 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øren
> >>>>>>>
> >>>>>>>
> >>>>>>> On 14 Aug 2019, at 18.01, Mit Matelske <mit at pt.net
> >>>>>>>
> >>>>>>> <mailto:mit at 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 at semihalf.com <mailto:
> >>>>>>>
> >>>>>>> mw at semihalf.com>>
> >>>>>>>
> >>>>>>> To: "Mit Matelske" <mit at pt.net <mailto:mit at pt.net>>
> >>>>>>> Cc: "Søren Schmidt" <soren.schmidt at gmail.com <mailto:
> >>>>>>>
> >>>>>>> soren.schmidt at gmail.com>>, "freebsd-arm" <freebsd-arm at freebsd.org
> >>>>>>> <mailto:freebsd-arm at freebsd.org>>
> >>>>>>>
> >>>>>>> Sent: Wednesday, August 14, 2019 10:41:04 AM
> >>>>>>> Subject: Re: Espressobin anyone ?
> >>>>>>>
> >>>>>>> Hi Mit,
> >>>>>>> Since you are using the latest 13-current, could you
> >>>>>>>
> >>>>>>> please try if passing rootdev via u-boot bootargs (please see my
> >>>>>>> previous
> >>>>>>> email) works for you without the loader modification?
> >>>>>>>
> >>>>>>>
> >>>>>>> Best regards,
> >>>>>>> Marcin
> >>>>>>>
> >>>>>>> ?r., 14 sie 2019 o 16:29 Mit Matelske <mit at pt.net
> >>>>>>>
> >>>>>>> <mailto:mit at 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øren Schmidt" <soren.schmidt at gmail.com
> >>>>>>>
> >>>>>>> <mailto:soren.schmidt at gmail.com>>
> >>>>>>>
> >>>>>>> To: "Mit Matelske" <mit at pt.net <mailto:mit at pt.net>>
> >>>>>>> Cc: "Marcin Wojtas" <mw at semihalf.com <mailto:
> >>>>>>>
> >>>>>>> mw at semihalf.com>>, "freebsd-arm" <freebsd-arm at freebsd.org <mailto:
> >>>>>>> freebsd-arm at freebsd.org>>
> >>>>>>>
> >>>>>>> Sent: Wednesday, August 14, 2019 2:30:31 AM
> >>>>>>> Subject: Re: Espressobin anyone ?
> >>>>>>>
> >>>>>>> Hi Mit
> >>>>>>> Hmm, from your earlier posted dmesgs it looks like
> >>>>>>>
> >>>>>>> the SD card is not getting detected properly..
> >>>>>>>
> >>>>>>>
> >>>>>>> I get this output:
> >>>>>>>
> >>>>>>> sdhci_xenon0: <Armada Xenon SDHCI controller> mem
> >>>>>>>
> >>>>>>> 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1
> >>>>>>>
> >>>>>>> mmc0: <MMC/SD bus> on sdhci_xenon0
> >>>>>>> ?snip?
> >>>>>>> mmcsd0: 16GB <SDHC SD16G 3.0 SN 01E28E67 MFG 07/2017
> >>>>>>>
> >>>>>>> by 39 PH> at mmc0 50.0MHz/4bit/65535-block
> >>>>>>>
> >>>>>>>
> >>>>>>> The problem you see was fixed for me by r348882,
> >>>>>>>
> >>>>>>> maybe it got broken later, I havn?t backported the later changes..
> >>>>>>>
> >>>>>>>
> >>>>>>> Have you tried another SD card ? I have found 2 of
> >>>>>>>
> >>>>>>> mine that the espressobin doesn?t like, but works fine with
> >>>>>>> bananapi and
> >>>>>>> friends...
> >>>>>>>
> >>>>>>>
> >>>>>>> -Søren
> >>>>>>>
> >>>>>>> On 13 Aug 2019, at 23.30, Mit Matelske <mit at pt.net
> >>>>>>>
> >>>>>>> <mailto:mit at 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) = 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 at 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øren Schmidt" <soren.schmidt at gmail.com
> >>>>>>>
> >>>>>>> <mailto:soren.schmidt at gmail.com>>
> >>>>>>>
> >>>>>>> To: "Marcin Wojtas" <mw at semihalf.com <mailto:
> >>>>>>>
> >>>>>>> mw at semihalf.com>>
> >>>>>>>
> >>>>>>> Cc: "Mit Matelske" <mit at pt.net <mailto:mit at pt.net>>,
> >>>>>>>
> >>>>>>> "freebsd-arm" <freebsd-arm at freebsd.org <mailto:
> >>>>>>> freebsd-arm at 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
> >>>>>>>
> >>>>>>> ===================================================================
> >>>>>>>
> >>>>>>> --- main.c    (revision 350496)
> >>>>>>> +++ main.c    (working copy)
> >>>>>>> @@ -463,6 +462,13 @@
> >>>>>>> int rv;
> >>>>>>> char *rootdev;
> >>>>>>>
> >>>>>>> +#if defined(__aarch64__)
> >>>>>>> +    /* SOS HACK in rootdev, at least Espressobin
> >>>>>>>
> >>>>>>> gets this wrong */
> >>>>>>>
> >>>>>>> +    printf("Setting currdev hack\n");
> >>>>>>> +           set_currdev("disk0p2");
> >>>>>>> +           return (0);
> >>>>>>> +#endif
> >>>>>>> +
> >>>>>>> /*
> >>>>>>>  * First choice: if rootdev is already set, use
> >>>>>>>
> >>>>>>> that, even if
> >>>>>>>
> >>>>>>>  * it's wrong.
> >>>>>>>
> >>>>>>> Its not pretty but it does the job until I get time
> >>>>>>>
> >>>>>>> to look into why bootargs aren?t passed / won?t stick, probably
> >>>>>>> something
> >>>>>>> I
> >>>>>>> havn?t backported to my -stable12 sources yet...
> >>>>>>>
> >>>>>>>
> >>>>>>> -Søren
> >>>>>>>
> >>>>>>> On 13 Aug 2019, at 01.38, Marcin Wojtas <
> >>>>>>>
> >>>>>>> mw at semihalf.com <mailto:mw at semihalf.com>> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> Not sure if it's what you are looking for, but in
> >>>>>>>
> >>>>>>> order to autoboot, I
> >>>>>>>
> >>>>>>> simply pass 'rootdev=diskXpY' in the bootargs
> >>>>>>>
> >>>>>>> variable. Here's example from
> >>>>>>>
> >>>>>>> A3720-DB (same should work on EspressoBin):
> >>>>>>>
> >>>>>>> Marvell>> set bootargs "rootdev=disk1p1";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=0x95047c
> >>>>>>>
> >>>>>>> data=0x1919d0+0x84aa94
> >>>>>>>
> >>>>>>> syms=[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 at pt.net
> >>>>>>>
> >>>>>>> <mailto:mit at 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øren Schmidt" <soren.schmidt at gmail.com
> >>>>>>>
> >>>>>>> <mailto:soren.schmidt at gmail.com>>
> >>>>>>>
> >>>>>>> To: "Mit Matelske" <mit at pt.net <mailto:mit at pt.net>>
> >>>>>>> Cc: "tscho" <johannes at t-beutel.com <mailto:
> >>>>>>>
> >>>>>>> johannes at t-beutel.com>>, "freebsd-arm" <
> >>>>>>>
> >>>>>>> freebsd-arm at freebsd.org <mailto:
> >>>>>>>
> >>>>>>> freebsd-arm at 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øren
> >>>>>>>
> >>>>>>>
> >>>>>>> On 12 Aug 2019, at 21.06, Mit Matelske <mit at pt.net
> >>>>>>>
> >>>>>>> <mailto:mit at 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=115200
> >>>>>>> bootargs=console=ttyMV0,115200
> >>>>>>>
> >>>>>>> earlycon=ar3700_uart,0xd0012000
> >>>>>>>
> >>>>>>> root=/dev/mmcblk0p1 rw rootwait net.ifnames=0
> >>>>>>>
> >>>>>>> biosdevname=0
> >>>>>>>
> >>>>>>> bootcmd=mmc dev 0; fatload mmc 0:1 $kernel_addr
> >>>>>>>
> >>>>>>> $image_name;fatload mmc
> >>>>>>>
> >>>>>>> 0:1 $fdt_addr $fdt_name; bootefi $kernel_addr
> >>>>>>>
> >>>>>>> $fdt_addr
> >>>>>>>
> >>>>>>> bootdelay=2
> >>>>>>> bootmmc=mmc dev 0; fatload mmc 0:1 $kernel_addr
> >>>>>>>
> >>>>>>> $image_name;fatload mmc
> >>>>>>>
> >>>>>>> 0:1 $fdt_addr $fdt_name; bootefi $kernel_addr
> >>>>>>>
> >>>>>>> $fdt_addr
> >>>>>>>
> >>>>>>> console=console=ttyMV0,115200
> >>>>>>>
> >>>>>>> earlycon=ar3700_uart,0xd0012000
> >>>>>>>
> >>>>>>> eth1addr=00:51:82:11:22:01
> >>>>>>> eth2addr=00:51:82:11:22:02
> >>>>>>> eth3addr=00:51:82:11:22:03
> >>>>>>> ethact=neta at 30000
> >>>>>>> ethaddr=F0:AD:4E:09:6B:8F
> >>>>>>> ethprime=eth0
> >>>>>>> fdt_addr=0x4f00000
> >>>>>>> fdt_high=0xffffffffffffffff
> >>>>>>> fdt_name=efi/boot/armada-3720-espressobin.dtb
> >>>>>>> fdtcontroladdr=3f7161b8
> >>>>>>> gatewayip=10.4.50.254
> >>>>>>> get_images=tftpboot $kernel_addr $image_name;
> >>>>>>>
> >>>>>>> tftpboot $fdt_addr
> >>>>>>>
> >>>>>>> $fdt_name; run get_ramfs
> >>>>>>> get_ramfs=if test "${ramfs_name}" != "-"; then setenv
> >>>>>>>
> >>>>>>> ramfs_addr
> >>>>>>>
> >>>>>>> 0x8000000; tftpboot $ramfs_addr $ramfs_name; else
> >>>>>>>
> >>>>>>> setenv ramfs_addr -;fi
> >>>>>>>
> >>>>>>> hostname=marvell
> >>>>>>> image_name=efi/freebsd/loader.efi
> >>>>>>> initrd_addr=0xa00000
> >>>>>>> initrd_size=0x2000000
> >>>>>>> ipaddr=0.0.0.0
> >>>>>>> kernel_addr=0x5000000
> >>>>>>> loadaddr=0x5000000
> >>>>>>> netdev=eth0
> >>>>>>> netmask=255.255.255.0
> >>>>>>> ramfs_addr=0x8000000
> >>>>>>> ramfs_name=-
> >>>>>>> root=root=/dev/nfs rw
> >>>>>>> rootpath=/srv/nfs/
> >>>>>>> serverip=0.0.0.0
> >>>>>>> set_bootargs=setenv bootargs $console $root
> >>>>>>>
> >>>>>>> ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:none
> >>>>>>>
> >>>>>>> nfsroot=$serverip:$rootpath $extra_params
> >>>>>>> stderr=serial at 12000
> >>>>>>> stdin=serial at 12000
> >>>>>>> stdout=serial at 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 at d0000: 0, sdhci at d8000: 1
> >>>>>>> SF: Detected mx25u3235f with page size 256 Bytes,
> >>>>>>>
> >>>>>>> erase size 64 KiB,
> >>>>>>>
> >>>>>>> total 4 MiB
> >>>>>>> Net:   eth0: neta at 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 at d0000.blk <mailto:sdhci at 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=disk0p2
> >>>>>>> OK boot
> >>>>>>>
> >>>>>>> /boot/kernel/kernel text=0x97d6a0
> >>>>>>>
> >>>>>>> data=0x191b50+0x84ae94
> >>>>>>>
> >>>>>>> syms=[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 =
> >>>>>>>
> >>>>>>> <CRC32,SHA2,SHA1,AES+PMULL>
> >>>>>>>
> >>>>>>> Trying to mount root from
> >>>>>>>
> >>>>>>> ufs:/dev/ufs/FreeBSD_Install [ro,noatime]...
> >>>>>>>
> >>>>>>> Instruction Set Attributes 1 = <>
> >>>>>>> Root mount waiting for:         Processor Features 0 =
> >>>>>>> <GIC,AdvSIMD,Float,EL3 32,EL2 32,EL1 32,EL0 32>
> >>>>>>> usbus1         Processor Features 1 = <0>
> >>>>>>> usbus0      Memory Model Features 0 = <4k Granule,64k
> >>>>>>>
> >>>>>>> Granule,S/NS
> >>>>>>>
> >>>>>>> Mem,MixedEndian,16bit ASID,1TB PA>
> >>>>>>>
> >>>>>>> Memory Model Features 1 = <>
> >>>>>>> Memory Model Features 2 = <32b CCIDX,48b VA>
> >>>>>>>       Debug Features 0 = <2 CTX Breakpoints,4
> >>>>>>>
> >>>>>>> Watchpoints,6
> >>>>>>>
> >>>>>>> Breakpoints,PMUv3,Debug v8>
> >>>>>>>       Debug Features 1 = <0>
> >>>>>>>   Auxiliary Features 0 = <0>
> >>>>>>>   Auxiliary Features 1 = <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=ufs:/dev/ufs/FreeBSD_Install
> >>>>>>> vfs.root.mountfrom.options=ro,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 at freebsd.org <mailto:
> >>>>>>>
> >>>>>>> freebsd-arm at 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 at freebsd.org <mailto:
> >>>>>>> freebsd-arm-unsubscribe at freebsd.org>"
> >>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> freebsd-arm at freebsd.org <mailto:
> >>>>>>>
> >>>>>>> freebsd-arm at 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 at freebsd.org <mailto:
> >>>>>>> freebsd-arm-unsubscribe at freebsd.org>"
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Emmanuel Vadot <manu at bidouilliste.com> <
> >>>>>>>
> >>>>>>> manu at freebsd.org>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Emmanuel Vadot <manu at bidouilliste.com> <manu at freebsd.org>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Emmanuel Vadot <manu at bidouilliste.com> <manu at freebsd.org>
> >>>>>>> _______________________________________________
> >>>>>>> freebsd-arm at freebsd.org mailing list
> >>>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> >>>>>>> To unsubscribe, send any mail to "
> >>>>>>>
> >>>>>>> freebsd-arm-unsubscribe at freebsd.org"
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Emmanuel Vadot <manu at bidouilliste.com> <manu at freebsd.org>
> >>>>>>> _______________________________________________
> >>>>>>> freebsd-arm at freebsd.org mailing list
> >>>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> >>>>>>> To unsubscribe, send any mail to "
> >>>>>>>
> >>>>>>> freebsd-arm-unsubscribe at freebsd.org"
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Emmanuel Vadot <manu at bidouilliste.com> <manu at freebsd.org>
> >>>>>>> _______________________________________________
> >>>>>>> freebsd-arm at freebsd.org mailing list
> >>>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> >>>>>>> To unsubscribe, send any mail to "
> >>>>>>>
> >>>>>>> freebsd-arm-unsubscribe at freebsd.org"
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Emmanuel Vadot <manu at bidouilliste.com <mailto:
> >>>>>>>
> >>>>>>> manu at bidouilliste.com>> <manu at freebsd.org
> >>>>>>> <mailto:manu at freebsd.org>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Emmanuel Vadot <manu at bidouilliste.com <mailto:
> >>>>>>>
> >>>>>>> manu at bidouilliste.com>> <manu at freebsd.org
> >>>>>>> <mailto:manu at freebsd.org>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Emmanuel Vadot <manu at bidouilliste.com> <manu at freebsd.org>
> >>>>>>> _______________________________________________
> >>>>>>> freebsd-arm at freebsd.org mailing list
> >>>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> >>>>>>> To unsubscribe, send any mail to "
> >>>>>>> freebsd-arm-unsubscribe at freebsd.org"
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> freebsd-arm at freebsd.org mailing list
> >>>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> >>>>>>> To unsubscribe, send any mail to
> >>>>>>> "freebsd-arm-unsubscribe at freebsd.org"
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>> _______________________________________________
> >>>>> freebsd-arm at freebsd.org mailing list
> >>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> >>>>> To unsubscribe, send any mail to
> >>>>> "freebsd-arm-unsubscribe at freebsd.org"
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>