Espressobin anyone ? (svn https timeout)
Ronald Klop
ronald-lists at klop.ws
Tue Aug 20 12:44:00 UTC 2019
#: 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 geo-location on DNS level.
Regards,
Ronald.
Van: Jeffrey Bowers <khantroll at gmail.com>
Datum: dinsdag, 20 augustus 2019 14:33
Aan: "Søren Schmidt" <soren.schmidt at gmail.com>, freebsd-arm <freebsd-arm at freebsd.org>
Onderwerp: Re: Espressobin anyone ?
>
> 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"
>
>
>
More information about the freebsd-arm
mailing list