Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 20 Aug 2019 21:01:43 +0200
From:      "Ronald Klop" <ronald-lists@klop.ws>
To:        "Jeffrey Bowers" <khantroll@gmail.com>
Cc:        freebsd-arm <freebsd-arm@freebsd.org>
Subject:   Re: Espressobin anyone ?
Message-ID:  <op.z6t4g5ajkndu52@sjakie>
In-Reply-To: <CAAkMUSWv%2B0m29Epy0ZA1rnbLTJ2XkNTG2aSN7e11eGxE-3tYXw@mail.gmail.com>
References:  <E73AFF5D-43CA-41A7-BDBA-ADEF2D342479@deepcore.dk> <20190817153053.5592b15b8a42982fda0fc123@bidouilliste.com> <9749945A-FDAD-47E0-947A-FA62138C2F83@gmail.com> <20190817210822.8920656bad0855b554883cf2@bidouilliste.com> <CAAkMUSXsgxP_fOJdfks%2Bd35MnyoXf1GfPO%2BC-YmTK3TpKDH7gA@mail.gmail.com> <2D6D4BDA-75EC-403F-B5E2-52A468369DE2@gmail.com> <CAAkMUSUM8bWT0Q-90jrvWjGOJopEka_LgP8sMshuS4Y7YQ29vw@mail.gmail.com> <627099DD-804B-412F-A083-768CEFCF955C@gmail.com> <CAAkMUSXd2zQQcYWDZnmibTQzLe%2BUV8rH6pk5fr=oZvevAY%2BHOQ@mail.gmail.com> <6DA8E736-8031-4BF7-8B20-CF8B0E8A7FEF@gmail.com> <CAAkMUSVRxbDBYtX0g7xbu4kLtiYQiZhjh0bdSwbCahF%2BjmTUXg@mail.gmail.com> <CAAkMUSVWWjYviHbOUXuHPxJYoahUnitdNazyusH=zGvbW1RAnw@mail.gmail.com> <ABB6B2F0-7771-49CD-84CF-B00D061EEF60@gmail.com> <CAAkMUSUfKN8Jqe7U40z9O1ypb=WuMWfgGtbnq7jLFPjp5qQfqQ@mail.gmail.com> <CAAkMUSV4p1uQOi%2Bt7b-z0uG8kjVY3qZhFd4B7fP1BjOWVRYqTA@mail.gmail.com> <BC161A1F-DC68-4AD3-BD28-1028E4BF7CCD@gmail.com> <CAAkMUSVGZCxgoTc%2BfBgsuR-DKiwUm8gKe49W-2%2BhH2PqRc%2Bg2A@mail.gmail.com> <CAAkMUSW6Oa-RE4MFMKghn3XfMN5tL0MQE=z1h5jO8H7=XS8%2BXA@mail.gmail.com> <2002575095.53.1566305166664@localhost> <CAAkMUSWv%2B0m29Epy0ZA1rnbLTJ2XkNTG2aSN7e11eGxE-3tYXw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 21 Aug 2019 01:03:37 +0200, Jeffrey Bowers <khantroll@gmail.com>=
  =

wrote:

> Yes sir, I can ping  svn.freebsd.org. Any idea why the checkout fails?=


I don't know. What ip address do you get when pinging?

Does this work for you? Does it work using the ip address you get?

svn checkout https://213.138.116.72/ports/head

Regards,
Ronald.



>
> On Tue, Aug 20, 2019 at 7:46 AM Ronald Klop <ronald-lists@klop.ws> wro=
te:
>> It is not possible to 'ping https://svn.freebsd.org/ports/head'.
>> You can 'ping svn.freebsd.org'.
>>
>> Ronald.
>>   =

>> Van: Jeffrey Bowers <khantroll@gmail.com>
>> Datum: dinsdag, 20 augustus 2019 14:36
>> Aan: "S=C3=B8ren Schmidt" <soren.schmidt@gmail.com>, freebsd-arm  =

>> <freebsd-arm@freebsd.org>
>> Onderwerp: Re: Espressobin anyone ?
>>> I just tried to ping  https://svn.freebsd.org/ports/head, and even  =

>>> 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 p=
ing
>>> google just fine. Is it a DNS issue?
>>>
>>> On Tue, Aug 20, 2019 at 7:33 AM Jeffrey Bowers <khantroll@gmail.com>=
  =

>>> wrote:
>>>
>>>> I'm still getting:  svn: E000060: Operation timed out
>>>> It goes for several minutes scrolling through text, and I feel like=
  =

>>>> using
>>>> your link got further.
>>>>
>>>> Thanks!
>>>>
>>>> On Tue, Aug 20, 2019 at 2:49 AM S=C3=B8ren Schmidt  =

>>>> <soren.schmidt@gmail.com>
>>>> wrote:
>>>>
>>>>> Hmm, I use this URL
>>>>>
>>>>> Repository Root: https://svn.freebsd.org/ports/head
>>>>>
>>>>> Not sure the svn+ssh thing works=E2=80=A6
>>>>>
>>>>> -S=C3=B8ren
>>>>>
>>>>>
>>>>> On 20 Aug 2019, at 02.38, Jeffrey Bowers <khantroll@gmail.com> wro=
te:
>>>>>
>>>>> 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: E00006=
0:
>>>>> 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 configurati=
on  =

>>>>> file.
>>>>>
>>>>> Any ideas?
>>>>>
>>>>> Thanks in advance!
>>>>>
>>>>> On Mon, Aug 19, 2019 at 8:51 PM Jeffrey Bowers <khantroll@gmail.co=
m>
>>>>> wrote:
>>>>>
>>>>> I didn't think it remounting. Thank you!
>>>>>
>>>>> On Mon, Aug 19, 2019 at 11:39 AM S=C3=B8ren Schmidt  =

>>>>> <soren.schmidt@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Hi Jeffrey
>>>>>
>>>>> You need to unmount the /tmp filesystem :)
>>>>> You can do that permanently by commenting it out in /etc/fstab
>>>>>
>>>>>
>>>>> On 19 Aug 2019, at 21.45, Jeffrey Bowers <khantroll@gmail.com> wro=
te:
>>>>>
>>>>> Hi Soren,
>>>>>
>>>>> I'm getting the same error message. Any other ideas what it might =
be?
>>>>> It's got to be something in the partition scheme or the file  =

>>>>> permissions,
>>>>> but I'm just not sure what.
>>>>> <image.png>
>>>>>
>>>>> On Sun, Aug 18, 2019 at 10:03 AM Jeffrey Bowers <khantroll@gmail.c=
om>
>>>>> wrote:
>>>>>
>>>>> D=E2=80=99Oh! 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=C3=B8ren Schmidt  =

>>>>> <soren.schmidt@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Hi
>>>>>
>>>>> You are out of space :)
>>>>>
>>>>> Boot the board into singleuser mode, and do =E2=80=9Cservice growf=
s start=E2=80=9D,
>>>>> that will expand you / filesystem to the entire SD card=E2=80=A6
>>>>>
>>>>> -S=C3=B8ren
>>>>>
>>>>> On 18 Aug 2019, at 14.50, Jeffrey Bowers <khantroll@gmail.com> wro=
te:
>>>>>
>>>>> Sure thing! Here's the screenshot!
>>>>> <image.png>
>>>>>
>>>>>
>>>>> On Sun, Aug 18, 2019 at 7:35 AM S=C3=B8ren Schmidt  =

>>>>> <soren.schmidt@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Hi
>>>>>
>>>>> Can I have you paste the output from df -h ?
>>>>>
>>>>> You should be able to utilise the full SD card=E2=80=A6
>>>>>
>>>>> -S=C3=B8ren
>>>>>
>>>>> On 18 Aug 2019, at 14.29, Jeffrey Bowers <khantroll@gmail.com> wro=
te:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Just make sure I understand the process, I should hook up a hard d=
isk
>>>>> and map it to to /TMP ?
>>>>>
>>>>> I already tried just unmapping /tmp, and it gave me the same error=

>>>>> once, and then the next time I ran it I got an error saying  =

>>>>> /usr/ports was
>>>>> out of space )which I guess I shouldn=E2=80=99t mount to another d=
irector on  =

>>>>> the
>>>>> hard drive?
>>>>>
>>>>> On Sun, Aug 18, 2019 at 5:11 AM S=C3=B8ren Schmidt  =

>>>>> <soren.schmidt@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Hi Jeffrey
>>>>>
>>>>> You can unmount the memory disk on /tmp to get at the space on the=
 SD
>>>>> card.
>>>>>
>>>>> It is however not recommend to use the AD card for random storage,=
 it
>>>>> will wear out fast, that=E2=80=99s why the memory disk is setup.
>>>>>
>>>>> You could connect a SSD og laptop disk to the SATA interface and u=
se
>>>>> that for the workload.
>>>>>
>>>>> However compiling is slow, its much much faster to cross compile o=
n a
>>>>> PC=E2=80=A6
>>>>>
>>>>> -S=C3=B8ren
>>>>>
>>>>> On 18 Aug 2019, at 00.22, Jeffrey Bowers <khantroll@gmail.com> wro=
te:
>>>>>
>>>>> Hi! I've got a new one :)
>>>>> I'm trying to do an svn checkout to fix the pkg problem, but it te=
lls
>>>>> 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 t=
he
>>>>> issue,
>>>>> along with the output of gpart:
>>>>>
>>>>> <image.png>
>>>>>
>>>>> Any ideas?
>>>>>
>>>>> Thanks!
>>>>>
>>>>>
>>>>> On Sat, Aug 17, 2019 at 2:08 PM Emmanuel Vadot  =

>>>>> <manu@bidouilliste.com>
>>>>> wrote:
>>>>>
>>>>> On Sat, 17 Aug 2019 17:14:36 +0200
>>>>> S=C3=B8ren Schmidt <soren.schmidt@gmail.com> wrote:
>>>>>
>>>>> HI
>>>>>
>>>>> Well, I have a whole forrest of tree?s here, but the error posted
>>>>>
>>>>> here was on a clean checkout.
>>>>>
>>>>>
>>>>> Anyhow, with the latest changes to -stable and the two
>>>>>
>>>>> RF_SHAREABLE patches from -current all works.
>>>>>
>>>>> I've reverted the commits, see
>>>>> https://github.com/evadot/freebsd/commits/a37x0_gpio for a better
>>>>> way
>>>>> to deal with this issue.
>>>>> I'm waiting for mmel@ as he wrote the syscon_get_default_handle
>>>>> part.
>>>>>
>>>>> It would be nice with the etherswitch changes as well so VLAN
>>>>>
>>>>> tagging etc was standard.
>>>>>
>>>>>
>>>>> -S=C3=B8ren
>>>>>
>>>>> PS: given up on bottom & inline popsting, top posting is all the
>>>>>
>>>>> rage now (yeah I miss elm etc :) )
>>>>>
>>>>>
>>>>> On 17 Aug 2019, at 15.30, Emmanuel Vadot <manu@bidouilliste.com>
>>>>>
>>>>> wrote:
>>>>>
>>>>>
>>>>> On Sat, 17 Aug 2019 11:07:22 +0200
>>>>> S=C3=B8ren Schmidt <soren.schmidt@gmail.com <mailto:
>>>>>
>>>>> soren.schmidt@gmail.com>> wrote:
>>>>>
>>>>>
>>>>> Hi Emmunuel
>>>>>
>>>>> Yes the 3720 gpio driver I already back ported long ago, its
>>>>>
>>>>> needed, I?m happy its now part of std stable 12!
>>>>>
>>>>>
>>>>> Would have been nice of you to say that you were not running a
>>>>>
>>>>> clean
>>>>>
>>>>> tree.
>>>>>
>>>>> My issue seems to be the inclusion of the phy_usb driver, if I
>>>>>
>>>>> leave that out, I?m back to normal..
>>>>>
>>>>>
>>>>> What make you think this is this driver ? What works/doesn't work
>>>>> with it ? could you provide logs.
>>>>>
>>>>> I?ll have have another go at the latest -stable sources during
>>>>>
>>>>> the weekend and see how it goes.
>>>>>
>>>>>
>>>>> Thanks for looking into this, with a little cooperation we?ll
>>>>>
>>>>> get this solved for the greater good..
>>>>>
>>>>>
>>>>> -S=C3=B8ren
>>>>>
>>>>>
>>>>> P.S. Please stop top posting, it's really hard to read the
>>>>>
>>>>> conversation
>>>>>
>>>>>
>>>>> On 16 Aug 2019, at 22.58, Emmanuel Vadot <
>>>>>
>>>>> manu@bidouilliste.com> wrote:
>>>>>
>>>>>
>>>>> On Fri, 16 Aug 2019 19:12:30 +0200
>>>>> Emmanuel Vadot <manu@bidouilliste.com <mailto:
>>>>>
>>>>> manu@bidouilliste.com>> wrote:
>>>>>
>>>>>
>>>>> On Fri, 16 Aug 2019 17:10:37 +0200
>>>>> Emmanuel Vadot <manu@bidouilliste.com> wrote:
>>>>>
>>>>> On Fri, 16 Aug 2019 15:24:54 +0200
>>>>> Emmanuel Vadot <manu@bidouilliste.com> wrote:
>>>>>
>>>>> On Fri, 16 Aug 2019 07:28:59 +0200
>>>>> S=C3=B8ren Schmidt <soren.schmidt@gmail.com> wrote:
>>>>>
>>>>> Hi
>>>>>
>>>>> Very simple, reverting sys/gnu/dts to what was before
>>>>>
>>>>> 350595 (actually 350592).
>>>>>
>>>>> Thats what we have svn for ?
>>>>>
>>>>>
>>>>> If I asked how it was to have the svn command that you
>>>>>
>>>>> used, I want to
>>>>>
>>>>> make sure that you didn't revert anything else, like do you
>>>>>
>>>>> have
>>>>>
>>>>> r350596 and r350628 ?
>>>>>
>>>>> That does make my bananapi work again, no other changes
>>>>>
>>>>> just a recompiled kernel.
>>>>>
>>>>>
>>>>> That + copying the dtb to the fat32 partition ?
>>>>>
>>>>> Can you post the dtb somewhere.
>>>>>
>>>>> However it does not bring the Espressobin back to life,
>>>>>
>>>>> thats something in one of the ~30 other files that changed between=
  =

>>>>> those
>>>>> two revisions.
>>>>>
>>>>>
>>>>> What Linux version of DTS are you using then ? The ones
>>>>>
>>>>> that were in
>>>>>
>>>>> stable/12 when it was branched (4.18) or a later revision ?
>>>>>
>>>>>
>>>>> So I think that I've found the problem on the Espressobin.
>>>>> I think that the problem comes from the simple-mfd driver
>>>>>
>>>>> that I've
>>>>>
>>>>> mfc in r350600.
>>>>> The pinctrl/gpio controller compatible is
>>>>> "marvell,armada3710-nb-pinctrl", "syscon", "simple-mfd" and
>>>>>
>>>>> it attaches
>>>>>
>>>>> at BUS_PASS_INTERRUPT while the simple_mfd driver attaches at
>>>>> BUS_PASS_BUS (so earlier) which means that no gpio
>>>>>
>>>>> controller will be
>>>>>
>>>>> available for sdhci to detect the card.
>>>>>
>>>>> If someone with a non-working espressobin could post a full
>>>>>
>>>>> verbose
>>>>>
>>>>> boot log that would help me confirming that this is the case.
>>>>> I'll try to find a solution on how to solve this problem.
>>>>>
>>>>>
>>>>> So this wasn't the problem but I've found it, see r351129 and
>>>>>
>>>>> r351130
>>>>>
>>>>>
>>>>> SD card now work again in HEAD, I'll have a look at stable
>>>>>
>>>>> later next
>>>>>
>>>>> week.
>>>>>
>>>>>
>>>>> I've did a quick test and I've MFC r348880, r348882 and
>>>>>
>>>>> r349596, the
>>>>>
>>>>> two other commits needed to be mfc'ed are the one I did today
>>>>>
>>>>> on head,
>>>>>
>>>>> I'll do that next week.
>>>>> With them sdcard is working again on stable/12
>>>>>
>>>>> -S=C3=B8ren
>>>>>
>>>>> On 15 Aug 2019, at 23.37, Emmanuel Vadot <
>>>>>
>>>>> manu@bidouilliste.com> wrote:
>>>>>
>>>>>
>>>>> On Thu, 15 Aug 2019 21:56:23 +0200
>>>>> S=C3=B8ren Schmidt <soren.schmidt@gmail.com> wrote:
>>>>>
>>>>>
>>>>> Well, I don?t care where you are from and what color you
>>>>>
>>>>> have :)
>>>>>
>>>>>
>>>>> Now, if I update my stable12 sources to r350595 the
>>>>>
>>>>> bananapi breaks, if revert sys/gnu/dts it works again, go figure..=

>>>>>
>>>>>
>>>>> Reverting to what ? and how ?
>>>>>
>>>>> Because I've just test 12-stable and I have the problem
>>>>>
>>>>> that I've said
>>>>>
>>>>> in my previous mail so setting
>>>>>
>>>>> hw.regulator.disable_unused=3D0 is the
>>>>>
>>>>> work around.
>>>>> The problem is in twsi not in the DTS so I'm curious how
>>>>>
>>>>> reverting
>>>>>
>>>>> only the dts fixes this problem.
>>>>>
>>>>> The r351099 fix is already like that in -stable, and not
>>>>>
>>>>> part of the problem.
>>>>>
>>>>>
>>>>> -S=C3=B8ren
>>>>>
>>>>>
>>>>> On 15 Aug 2019, at 21.03, Emmanuel Vadot <
>>>>>
>>>>> manu@bidouilliste.com> wrote:
>>>>>
>>>>>
>>>>> On Thu, 15 Aug 2019 19:48:54 +0200
>>>>> S=C3=B8ren Schmidt <soren.schmidt@gmail.com> wrote:
>>>>>
>>>>> Hi Mit!
>>>>>
>>>>> Right, I suspected that, 12-stable broke many embedded
>>>>>
>>>>> systems between r350592 and r350595 where all the latest and  =

>>>>> greatest DTS
>>>>> files was pulled in, I guess the same holds for -current.
>>>>>
>>>>>
>>>>> -S=C3=B8ren
>>>>>
>>>>>
>>>>> Mhm it's fun that you think that DTS import is the
>>>>>
>>>>> source of all your
>>>>>
>>>>> problems, I get it, it's easy to blame the French guy
>>>>>
>>>>> that bulk import
>>>>>
>>>>> the DTS, he surely don't know what he is doing.
>>>>> Anyway, two problems were raised in this thread :
>>>>>
>>>>> 1) BananaPi (A20) doesn't boot
>>>>> 2) Espressobin sd support is broken
>>>>>
>>>>> I've just looked at the BananaPi problem today, I've
>>>>>
>>>>> fixed a first
>>>>>
>>>>> problem in r351099.
>>>>> The main problem is that when we disable the unused
>>>>>
>>>>> regulators we hang
>>>>>
>>>>> when trying to disabling ldo3. It's weird because the
>>>>>
>>>>> board doesn't use
>>>>>
>>>>> LDO3 (which is why we are disabling it, it's unused).
>>>>>
>>>>> The problem is in
>>>>>
>>>>> twsi I think as only leaving the part in axp209 that
>>>>>
>>>>> read the
>>>>>
>>>>> voltage register value make FreeBSD hang.
>>>>> I'll have a proper look later, in the meantime you can
>>>>>
>>>>> set
>>>>>
>>>>> hw.regulator.disable_unused=3D0
>>>>> in /boot/loader.conf
>>>>> This isn't a DTS problem.
>>>>>
>>>>> For Espressobin I haven't found any thing related to SD
>>>>>
>>>>> in the DTS
>>>>>
>>>>> updates since the import, the only things slighly
>>>>>
>>>>> related are mmc and
>>>>>
>>>>> sdio.
>>>>> So if someone could find which DTS import broke this I
>>>>>
>>>>> can have a look.
>>>>>
>>>>>
>>>>>
>>>>> On 15 Aug 2019, at 19.37, Mit Matelske <mit@pt.net>
>>>>>
>>>>> wrote:
>>>>>
>>>>>
>>>>> Yeah, that was the problem.  I went back to r348882
>>>>>
>>>>> and everything worked out of the box.
>>>>>
>>>>>
>>>>> Thanks again for the hand holding!
>>>>>
>>>>> Mit
>>>>>
>>>>> From: "S=C3=B8ren Schmidt" <soren.schmidt@gmail.com
>>>>>
>>>>> <mailto:soren.schmidt@gmail.com>>
>>>>>
>>>>> To: "Mit Matelske" <mit@pt.net <mailto:mit@pt.net>>
>>>>> Cc: "Marcin Wojtas" <mw@semihalf.com <mailto:
>>>>>
>>>>> mw@semihalf.com>>, "freebsd-arm" <freebsd-arm@freebsd.org <mailto:=

>>>>> freebsd-arm@freebsd.org>>
>>>>>
>>>>> Sent: Wednesday, August 14, 2019 1:33:04 PM
>>>>> Subject: Re: Espressobin anyone ?
>>>>>
>>>>>
>>>>> It might simply be broken in -current (again).
>>>>>
>>>>> I just updated my stable12 tree and I pulled in new
>>>>>
>>>>> .dts files for just about anything?
>>>>>
>>>>>
>>>>> Needless to say, it broke the Espressobin?s SD
>>>>>
>>>>> support, it now fails just like yours..
>>>>>
>>>>>
>>>>> It also broke allwinner builds and what not, so I?m
>>>>>
>>>>> just going back in time again :)
>>>>>
>>>>>
>>>>> I wonder why there is this overwhelming need to
>>>>>
>>>>> import stuff that breaks things right, left and center in a -stabl=
e
>>>>> branch ?
>>>>>
>>>>> That would have earned you the pointy hat back when?.
>>>>>
>>>>> -S=C3=B8ren
>>>>>
>>>>>
>>>>> On 14 Aug 2019, at 18.01, Mit Matelske <mit@pt.net
>>>>>
>>>>> <mailto:mit@pt.net>> wrote:
>>>>>
>>>>>
>>>>> Marcin-
>>>>>
>>>>> Sorry I didn't reply yesterday.  I didn't have any
>>>>>
>>>>> luck with that either.  I tried a lot of permutations.
>>>>>
>>>>>
>>>>> Not saying for 100% it doesn't work, but I couldn't
>>>>>
>>>>> get it to work!
>>>>>
>>>>>
>>>>> Mit
>>>>>
>>>>> From: "Marcin Wojtas" <mw@semihalf.com <mailto:
>>>>>
>>>>> mw@semihalf.com>>
>>>>>
>>>>> To: "Mit Matelske" <mit@pt.net <mailto:mit@pt.net>>
>>>>> Cc: "S=C3=B8ren Schmidt" <soren.schmidt@gmail.com <mailto:
>>>>>
>>>>> soren.schmidt@gmail.com>>, "freebsd-arm" <freebsd-arm@freebsd.org
>>>>> <mailto:freebsd-arm@freebsd.org>>
>>>>>
>>>>> Sent: Wednesday, August 14, 2019 10:41:04 AM
>>>>> Subject: Re: Espressobin anyone ?
>>>>>
>>>>> Hi Mit,
>>>>> Since you are using the latest 13-current, could you
>>>>>
>>>>> please try if passing rootdev via u-boot bootargs (please see my  =

>>>>> previous
>>>>> email) works for you without the loader modification?
>>>>>
>>>>>
>>>>> Best regards,
>>>>> Marcin
>>>>>
>>>>> ?r., 14 sie 2019 o 16:29 Mit Matelske <mit@pt.net
>>>>>
>>>>> <mailto:mit@pt.net>> napisa?(a):
>>>>>
>>>>> Soren-
>>>>>
>>>>> Thanks for the info.  I'll grab a couple more SD
>>>>>
>>>>> cards at lunch.  This one is a new Samsung 32GB.  I'll also try  =

>>>>> putting
>>>>> the
>>>>> changes into 12 and see if that helps.  I'm using the latest  =

>>>>> 13-current.
>>>>>
>>>>>
>>>>> Again, appreciate the hand holding!
>>>>>
>>>>> Mit
>>>>>
>>>>> From: "S=C3=B8ren Schmidt" <soren.schmidt@gmail.com
>>>>>
>>>>> <mailto:soren.schmidt@gmail.com>>
>>>>>
>>>>> To: "Mit Matelske" <mit@pt.net <mailto:mit@pt.net>>
>>>>> Cc: "Marcin Wojtas" <mw@semihalf.com <mailto:
>>>>>
>>>>> mw@semihalf.com>>, "freebsd-arm" <freebsd-arm@freebsd.org <mailto:=

>>>>> freebsd-arm@freebsd.org>>
>>>>>
>>>>> Sent: Wednesday, August 14, 2019 2:30:31 AM
>>>>> Subject: Re: Espressobin anyone ?
>>>>>
>>>>> Hi Mit
>>>>> Hmm, from your earlier posted dmesgs it looks like
>>>>>
>>>>> the SD card is not getting detected properly..
>>>>>
>>>>>
>>>>> I get this output:
>>>>>
>>>>> sdhci_xenon0: <Armada Xenon SDHCI controller> mem
>>>>>
>>>>> 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1
>>>>>
>>>>> mmc0: <MMC/SD bus> on sdhci_xenon0
>>>>> ?snip?
>>>>> mmcsd0: 16GB <SDHC SD16G 3.0 SN 01E28E67 MFG 07/2017
>>>>>
>>>>> by 39 PH> at mmc0 50.0MHz/4bit/65535-block
>>>>>
>>>>>
>>>>> The problem you see was fixed for me by r348882,
>>>>>
>>>>> maybe it got broken later, I havn?t backported the later changes..=

>>>>>
>>>>>
>>>>> Have you tried another SD card ? I have found 2 of
>>>>>
>>>>> mine that the espressobin doesn?t like, but works fine with banana=
pi  =

>>>>> and
>>>>> friends...
>>>>>
>>>>>
>>>>> -S=C3=B8ren
>>>>>
>>>>> On 13 Aug 2019, at 23.30, Mit Matelske <mit@pt.net
>>>>>
>>>>> <mailto:mit@pt.net>> wrote:
>>>>>
>>>>>
>>>>> Soren-
>>>>>
>>>>> Thanks for the code snippet!  That will fix one of
>>>>>
>>>>> the problems.
>>>>>
>>>>>
>>>>> I still can't mount my filesystem, though.  I think
>>>>>
>>>>> I'm doing something really simple, wrong.  I believe I'm running t=
he
>>>>> latest
>>>>> code and added some printfs to show the kernel setting the regulat=
or:
>>>>>
>>>>>
>>>>>
>>>>> usbus1 on ehci0
>>>>> syscon_generic4: <syscon> mem 0x5f800-0x5ffff on
>>>>>
>>>>> simplebus1
>>>>>
>>>>> sdhci_xenon0:
>>>>>
>>>>> regulator_get_by_ofw_property(vqmmc-supply) =3D 19
>>>>>
>>>>> sdhci_xenon0: vqmmc-supply regulator found
>>>>> sdhci_xenon0: <Armada Xenon SDHCI controller> mem
>>>>>
>>>>> 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1
>>>>>
>>>>> ahci0: <AHCI SATA controller> mem 0xe0000-0xe0177 irq
>>>>>
>>>>> 26 on simplebus1
>>>>>
>>>>>
>>>>>
>>>>> Could there be a problem with how I am setting up my
>>>>>
>>>>> filesystem?  I've tried both freebsd-ufs and freebsd as the type, =
 =

>>>>> with no
>>>>> luck. A gpart listing of my SD card:
>>>>>
>>>>>
>>>>> root@fbl:~ # gpart list da3
>>>>> Geom name: da3
>>>>> modified: false
>>>>> state: OK
>>>>> fwheads: 255
>>>>> fwsectors: 63
>>>>> last: 62521335
>>>>> first: 3
>>>>> entries: 4
>>>>> scheme: GPT
>>>>> Providers:
>>>>> 1. Name: da3p1
>>>>> Mediasize: 41943040 (40M)
>>>>> Sectorsize: 512
>>>>> Stripesize: 0
>>>>> Stripeoffset: 1536
>>>>> Mode: r0w0e0
>>>>> efimedia:
>>>>>
>>>>> HD(1,GPT,19894dc5-b8b2-11e9-871f-08008a0010e0,0x3,0x14000)
>>>>>
>>>>> rawuuid: 19894dc5-b8b2-11e9-871f-08008a0010e0
>>>>> rawtype: c12a7328-f81f-11d2-ba4b-00a0c93ec93b
>>>>> label: (null)
>>>>> length: 41943040
>>>>> offset: 1536
>>>>> type: efi
>>>>> index: 1
>>>>> end: 81922
>>>>> start: 3
>>>>> 2. Name: da3p2
>>>>> Mediasize: 31968979456 (30G)
>>>>> Sectorsize: 512
>>>>> Stripesize: 0
>>>>> Stripeoffset: 41944576
>>>>> Mode: r0w0e0
>>>>> efimedia:
>>>>>
>>>>> HD(2,GPT,98786462-be30-11e9-ae6e-08008a0010e0,0x14003,0x3b8bff5)
>>>>>
>>>>> rawuuid: 98786462-be30-11e9-ae6e-08008a0010e0
>>>>> rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b
>>>>> label: (null)
>>>>> length: 31968979456
>>>>> offset: 41944576
>>>>> type: freebsd-ufs
>>>>> index: 2
>>>>> end: 62521335
>>>>> start: 81923
>>>>> Consumers:
>>>>> 1. Name: da3
>>>>> Mediasize: 32010928128 (30G)
>>>>> Sectorsize: 512
>>>>> Mode: r0w0e0
>>>>>
>>>>> Thanks!!
>>>>>
>>>>> Mit
>>>>>
>>>>> From: "S=C3=B8ren Schmidt" <soren.schmidt@gmail.com
>>>>>
>>>>> <mailto:soren.schmidt@gmail.com>>
>>>>>
>>>>> To: "Marcin Wojtas" <mw@semihalf.com <mailto:
>>>>>
>>>>> mw@semihalf.com>>
>>>>>
>>>>> Cc: "Mit Matelske" <mit@pt.net <mailto:mit@pt.net>>,
>>>>>
>>>>> "freebsd-arm" <freebsd-arm@freebsd.org <mailto:
>>>>> freebsd-arm@freebsd.org>>
>>>>>
>>>>> Sent: Tuesday, August 13, 2019 12:55:09 PM
>>>>> Subject: Re: Espressobin anyone ?
>>>>>
>>>>> Hi
>>>>> That doesn?t seen to work on the espressobin, or
>>>>>
>>>>> least I can?t get it to pick it up.
>>>>>
>>>>>
>>>>> I use this patch as a workaround:
>>>>>
>>>>> Index: main.c
>>>>>
>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>>
>>>>> --- main.c    (revision 350496)
>>>>> +++ main.c    (working copy)
>>>>> @@ -463,6 +462,13 @@
>>>>> int rv;
>>>>> char *rootdev;
>>>>>
>>>>> +#if defined(__aarch64__)
>>>>> +    /* SOS HACK in rootdev, at least Espressobin
>>>>>
>>>>> gets this wrong */
>>>>>
>>>>> +    printf("Setting currdev hack\n");
>>>>> +           set_currdev("disk0p2");
>>>>> +           return (0);
>>>>> +#endif
>>>>> +
>>>>> /*
>>>>>  * First choice: if rootdev is already set, use
>>>>>
>>>>> that, even if
>>>>>
>>>>>  * it's wrong.
>>>>>
>>>>> Its not pretty but it does the job until I get time
>>>>>
>>>>> to look into why bootargs aren?t passed / won?t stick, probably  =

>>>>> something
>>>>> I
>>>>> havn?t backported to my -stable12 sources yet...
>>>>>
>>>>>
>>>>> -S=C3=B8ren
>>>>>
>>>>> On 13 Aug 2019, at 01.38, Marcin Wojtas <
>>>>>
>>>>> mw@semihalf.com <mailto:mw@semihalf.com>> wrote:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> Not sure if it's what you are looking for, but in
>>>>>
>>>>> order to autoboot, I
>>>>>
>>>>> simply pass 'rootdev=3DdiskXpY' in the bootargs
>>>>>
>>>>> variable. Here's example from
>>>>>
>>>>> A3720-DB (same should work on EspressoBin):
>>>>>
>>>>> Marvell>> set bootargs "rootdev=3Ddisk1p1";usb reset;
>>>>>
>>>>> fatload usb 0:1
>>>>>
>>>>> ${fdt_addr} armada-3720-db.dtb; fatload usb 0:1
>>>>>
>>>>> ${kernel_addr}
>>>>>
>>>>> boot/loader.efi; bootefi ${kernel_addr} ${fdt_addr}
>>>>> resetting USB...
>>>>> USB0:   Register 2000104 NbrPorts 2
>>>>> Starting the controller
>>>>> USB XHCI 1.00
>>>>> USB1:   USB EHCI 1.00
>>>>> -  ______               ____   _____ _____
>>>>> |  ____|             |  _ \ / ____|  __ \
>>>>> | |___ _ __ ___  ___ | |_) | (___ | |  | |
>>>>> |  ___| '__/ _ \/ _ \|  _ < \___ \| |  | |
>>>>> | |   | | |  __/  __/| |_) |____) | |__| |
>>>>> | |   | | |    |    ||     |      |      |
>>>>> |_|   |_|  \___|\___||____/|_____/|_____/
>>>>>                                            ```
>>>>> `
>>>>> ????????????Welcome to FreeBSD?????????????    s`
>>>>>
>>>>> `.....---.......--.```
>>>>>
>>>>> -/
>>>>> ?                                         ?    +o
>>>>>
>>>>> .--`         /y:`
>>>>>
>>>>> +.
>>>>> ?  1. Boot Multi user [Enter]             ?
>>>>>
>>>>> yo`:.            :o
>>>>>
>>>>> `+-
>>>>> ?  2. Boot Single user                    ?      y/
>>>>>
>>>>>             -/`   -o/
>>>>>
>>>>> ?  3. Escape to loader prompt             ?     .-
>>>>> ::/sy+:.
>>>>> ?  4. Reboot                              ?     /
>>>>>
>>>>>                 `--
>>>>>
>>>>> /
>>>>> ?                                         ?    `:
>>>>> :`
>>>>> ?  Options:                               ?    `:
>>>>> :`
>>>>> ?  5. Kernel: default/kernel (1 of 1)     ?     /
>>>>> /
>>>>> ?  6. Boot Options                        ?     .-
>>>>> -.
>>>>> ?                                         ?      --
>>>>>
>>>>>                    -.
>>>>>
>>>>> ?                                         ?
>>>>>
>>>>> `:`                  `:`
>>>>>
>>>>> ?                                         ?
>>>>>
>>>>> .--             `--.
>>>>>
>>>>> ???????????????????????????????????????????
>>>>>
>>>>>  .---.....----.
>>>>>
>>>>> Autoboot in 9 seconds, hit [Enter] to boot or any
>>>>>
>>>>> other key to stop
>>>>>
>>>>>
>>>>> Loading kernel...
>>>>> /boot/kernel/kernel text=3D0x95047c
>>>>>
>>>>> data=3D0x1919d0+0x84aa94
>>>>>
>>>>> syms=3D[0x8+0x13aaa8+0x8+0x12610d]
>>>>> Loading configured modules...
>>>>> can't find '/boot/entropy'
>>>>> Using DTB provided by EFI at 0x8000000.
>>>>> ---<<BOOT>>---
>>>>> KDB: debugger backends: ddb
>>>>> KDB: current backend: ddb
>>>>> Copyright (c) 1992-2019 The FreeBSD Project.
>>>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989,
>>>>>
>>>>> 1991, 1992, 1993, 1994
>>>>>
>>>>> The Regents of the University of California. All
>>>>>
>>>>> rights reserved.
>>>>>
>>>>> FreeBSD is a registered trademark of The FreeBSD
>>>>>
>>>>> Foundation.
>>>>>
>>>>> FreeBSD 13.0-CURRENT
>>>>>
>>>>> 17a1fc80d57-c261519(upstream_master) GENERIC arm64
>>>>>
>>>>> FreeBSD clang version 8.0.0 (tags/RELEASE_800/final
>>>>>
>>>>> 356365) (based on LLVM
>>>>>
>>>>> 8.0.0)
>>>>> WARNING: WITNESS option enabled, expect reduced
>>>>>
>>>>> performance.
>>>>>
>>>>> VT: init without driver.
>>>>> Starting CPU 1 (1)
>>>>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
>>>>> [...]
>>>>>
>>>>> Best regards,
>>>>> Marcin
>>>>>
>>>>> pon., 12 sie 2019 o 23:14 Mit Matelske <mit@pt.net
>>>>>
>>>>> <mailto:mit@pt.net>> napisa?(a):
>>>>>
>>>>>
>>>>>
>>>>> Soren-
>>>>>
>>>>> Thanks for the quick response.  I built this kernel
>>>>>
>>>>> with revision 350924.
>>>>>
>>>>> I'll dig into whats going on in the morning.
>>>>>
>>>>> Mind posting your diff for your loader.efi?
>>>>>
>>>>> Thanks again!
>>>>>
>>>>> Mit
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>> From: "S=C3=B8ren Schmidt" <soren.schmidt@gmail.com
>>>>>
>>>>> <mailto:soren.schmidt@gmail.com>>
>>>>>
>>>>> To: "Mit Matelske" <mit@pt.net <mailto:mit@pt.net>>
>>>>> Cc: "tscho" <johannes@t-beutel.com <mailto:
>>>>>
>>>>> johannes@t-beutel.com>>, "freebsd-arm" <
>>>>>
>>>>> freebsd-arm@freebsd.org <mailto:
>>>>>
>>>>> freebsd-arm@freebsd.org>>
>>>>>
>>>>> Sent: Monday, August 12, 2019 3:49:48 PM
>>>>> Subject: Re: Espressobin anyone ?
>>>>>
>>>>> Hi
>>>>>
>>>>> Looks like your sources may be too old, you need to
>>>>>
>>>>> be at least at r348882
>>>>>
>>>>> to get the fix for the SD card VCC regulator.
>>>>>
>>>>> That change fixed it for me backported to 12-stable...
>>>>>
>>>>> The currdev problem still exists, I have it hardwired
>>>>>
>>>>> in my loader for
>>>>>
>>>>> aarch64 :)
>>>>>
>>>>> -S=C3=B8ren
>>>>>
>>>>>
>>>>> On 12 Aug 2019, at 21.06, Mit Matelske <mit@pt.net
>>>>>
>>>>> <mailto:mit@pt.net>> wrote:
>>>>>
>>>>>
>>>>> I'm having a couple little hiccups booting this board
>>>>>
>>>>> also.  One has
>>>>>
>>>>> been commented on already, that I can't get the
>>>>>
>>>>> loader to automatically
>>>>>
>>>>> start loading the kernel on "disk0p2"...
>>>>>
>>>>> The second, is that the kernel can't find the SD card
>>>>>
>>>>> after booting so
>>>>>
>>>>> it can't mount the root filesystem.  I'm using the
>>>>>
>>>>> dts/dtb and kernel from
>>>>>
>>>>> the 13-current branch.
>>>>>
>>>>> Thanks for any and all help.  I haven't used u-boot
>>>>>
>>>>> in about decade.
>>>>>
>>>>> Spoiled by the x86 platform.
>>>>>
>>>>> Mit Matelske
>>>>>
>>>>>
>>>>> ***U-boot environment:***
>>>>>
>>>>>
>>>>> Marvell>> printenv
>>>>> baudrate=3D115200
>>>>> bootargs=3Dconsole=3DttyMV0,115200
>>>>>
>>>>> earlycon=3Dar3700_uart,0xd0012000
>>>>>
>>>>> root=3D/dev/mmcblk0p1 rw rootwait net.ifnames=3D0
>>>>>
>>>>> biosdevname=3D0
>>>>>
>>>>> bootcmd=3Dmmc dev 0; fatload mmc 0:1 $kernel_addr
>>>>>
>>>>> $image_name;fatload mmc
>>>>>
>>>>> 0:1 $fdt_addr $fdt_name; bootefi $kernel_addr
>>>>>
>>>>> $fdt_addr
>>>>>
>>>>> bootdelay=3D2
>>>>> bootmmc=3Dmmc dev 0; fatload mmc 0:1 $kernel_addr
>>>>>
>>>>> $image_name;fatload mmc
>>>>>
>>>>> 0:1 $fdt_addr $fdt_name; bootefi $kernel_addr
>>>>>
>>>>> $fdt_addr
>>>>>
>>>>> console=3Dconsole=3DttyMV0,115200
>>>>>
>>>>> earlycon=3Dar3700_uart,0xd0012000
>>>>>
>>>>> eth1addr=3D00:51:82:11:22:01
>>>>> eth2addr=3D00:51:82:11:22:02
>>>>> eth3addr=3D00:51:82:11:22:03
>>>>> ethact=3Dneta@30000
>>>>> ethaddr=3DF0:AD:4E:09:6B:8F
>>>>> ethprime=3Deth0
>>>>> fdt_addr=3D0x4f00000
>>>>> fdt_high=3D0xffffffffffffffff
>>>>> fdt_name=3Defi/boot/armada-3720-espressobin.dtb
>>>>> fdtcontroladdr=3D3f7161b8
>>>>> gatewayip=3D10.4.50.254
>>>>> get_images=3Dtftpboot $kernel_addr $image_name;
>>>>>
>>>>> tftpboot $fdt_addr
>>>>>
>>>>> $fdt_name; run get_ramfs
>>>>> get_ramfs=3Dif test "${ramfs_name}" !=3D "-"; then setenv
>>>>>
>>>>> ramfs_addr
>>>>>
>>>>> 0x8000000; tftpboot $ramfs_addr $ramfs_name; else
>>>>>
>>>>> setenv ramfs_addr -;fi
>>>>>
>>>>> hostname=3Dmarvell
>>>>> image_name=3Defi/freebsd/loader.efi
>>>>> initrd_addr=3D0xa00000
>>>>> initrd_size=3D0x2000000
>>>>> ipaddr=3D0.0.0.0
>>>>> kernel_addr=3D0x5000000
>>>>> loadaddr=3D0x5000000
>>>>> netdev=3Deth0
>>>>> netmask=3D255.255.255.0
>>>>> ramfs_addr=3D0x8000000
>>>>> ramfs_name=3D-
>>>>> root=3Droot=3D/dev/nfs rw
>>>>> rootpath=3D/srv/nfs/
>>>>> serverip=3D0.0.0.0
>>>>> set_bootargs=3Dsetenv bootargs $console $root
>>>>>
>>>>> ip=3D$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:none
>>>>>
>>>>> nfsroot=3D$serverip:$rootpath $extra_params
>>>>> stderr=3Dserial@12000
>>>>> stdin=3Dserial@12000
>>>>> stdout=3Dserial@12000
>>>>>
>>>>>
>>>>> ***Full boot logs:***
>>>>>
>>>>>
>>>>> U-Boot 2017.03-armada-17.10.2-g14aeedc (Jun 01 2018 -
>>>>>
>>>>> 15:39:10 +0800)
>>>>>
>>>>>
>>>>> Model: Marvell Armada 3720 Community Board ESPRESSOBin
>>>>> CPU    @ 1000 [MHz]
>>>>> L2     @ 800 [MHz]
>>>>> TClock @ 200 [MHz]
>>>>> DDR    @ 800 [MHz]
>>>>> DRAM:  1 GiB
>>>>> U-Boot DT blob at : 000000003f7161b8
>>>>> Comphy-0: USB3          5 Gbps
>>>>> Comphy-1: PEX0          2.5 Gbps
>>>>> Comphy-2: SATA0         6 Gbps
>>>>> SATA link 0 timeout.
>>>>> AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA
>>>>>
>>>>> mode
>>>>>
>>>>> flags: ncq led only pmp fbss pio slum part sxs
>>>>> PCIE-0: Link down
>>>>> MMC:   sdhci@d0000: 0, sdhci@d8000: 1
>>>>> SF: Detected mx25u3235f with page size 256 Bytes,
>>>>>
>>>>> erase size 64 KiB,
>>>>>
>>>>> total 4 MiB
>>>>> Net:   eth0: neta@30000 [PRIME]
>>>>> Hit any key to stop autoboot:  0
>>>>> switch to partitions #0, OK
>>>>> mmc0 is current device
>>>>> reading efi/freebsd/loader.efi
>>>>> 603872 bytes read in 49 ms (11.8 MiB/s)
>>>>> reading efi/boot/armada-3720-espressobin.dtb
>>>>> 15946 bytes read in 17 ms (916 KiB/s)
>>>>> ## Starting EFI application at 05000000 ...
>>>>> Scanning disk sdhci@d0000.blk <mailto:sdhci@d0000.blk
>>>>>
>>>>> ...
>>>>>
>>>>> Card did not respond to voltage select!
>>>>> mmc_init: -95, time 50
>>>>> Found 1 disks
>>>>> Consoles: EFI console
>>>>> FreeBSD/arm64 EFI loader, Revision 1.1
>>>>>
>>>>> Command line arguments: loader.efi
>>>>> EFI version: 2.05
>>>>> EFI Firmware: Das U-boot (rev 0.00)
>>>>> Console: efi (0)
>>>>> Failed to find bootable partition
>>>>> Startup error in /boot/lua/loader.lua: seconds
>>>>> LUA ERROR: cannot open /boot/lua/loader.lua: invalid
>>>>>
>>>>> argument.
>>>>>
>>>>>
>>>>> can't load 'kernel'
>>>>>
>>>>> Type '?' for a list of commands, 'help' for more
>>>>>
>>>>> detailed help.
>>>>>
>>>>> OK
>>>>> OK set currdev=3Ddisk0p2
>>>>> OK boot
>>>>>
>>>>> /boot/kernel/kernel text=3D0x97d6a0
>>>>>
>>>>> data=3D0x191b50+0x84ae94
>>>>>
>>>>> syms=3D[0x8+0x137dd8+0x8+0x126260]
>>>>> Using DTB provided by EFI at 0x8000000.
>>>>> ---<<BOOT>>---
>>>>> KDB: debugger backends: ddb
>>>>> KDB: current backend: ddb
>>>>> Copyright (c) 1992-2019 The FreeBSD Project.
>>>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989,
>>>>>
>>>>> 1991, 1992, 1993, 1994
>>>>>
>>>>>  The Regents of the University of California. All
>>>>>
>>>>> rights reserved.
>>>>>
>>>>> FreeBSD is a registered trademark of The FreeBSD
>>>>>
>>>>> Foundation.
>>>>>
>>>>> FreeBSD 13.0-CURRENT GENERIC arm64
>>>>> FreeBSD clang version 6.0.1 (tags/RELEASE_601/final
>>>>>
>>>>> 335540) (based on
>>>>>
>>>>> LLVM 6.0.1)
>>>>> WARNING: WITNESS option enabled, expect reduced
>>>>>
>>>>> performance.
>>>>>
>>>>> VT: init without driver.
>>>>> Starting CPU 1 (1)
>>>>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
>>>>> arc4random: WARNING: initial seeding bypassed the
>>>>>
>>>>> cryptographic random
>>>>>
>>>>> device because it was not yet seeded and the knob
>>>>>
>>>>> 'bypass_before_seeding'
>>>>>
>>>>> was enabled.
>>>>> random: entropy device external interface
>>>>> MAP 3e681000 mode 2 pages 1
>>>>> MAP 3ffa6000 mode 2 pages 1
>>>>> kbd0 at kbdmux0
>>>>> ofwbus0: <Open Firmware Device Tree>
>>>>> simplebus0: <Flattened device tree simple bus> on
>>>>>
>>>>> ofwbus0
>>>>>
>>>>> simplebus1: <Flattened device tree simple bus> on
>>>>>
>>>>> simplebus0
>>>>>
>>>>> simple_mfd0: <Simple MFD (Multi-Functions Device)> mem
>>>>> 0x13800-0x138ff,0x13c00-0x13c1f on simplebus1
>>>>> simple_mfd1: <Simple MFD (Multi-Functions Device)> mem
>>>>> 0x18800-0x188ff,0x18c00-0x18c1f on simplebus1
>>>>> psci0: <ARM Power State Co-ordination Interface
>>>>>
>>>>> Driver> on ofwbus0
>>>>>
>>>>> gic0: <ARM Generic Interrupt Controller v3.0> mem
>>>>>
>>>>>
>>>>> 0x1d00000-0x1d0ffff,0x1d40000-0x1d7ffff,0x1d80000-0x1d81fff,0x1d90=
000-0x1d91fff,0x1da0000-0x1dbffff
>>>>>
>>>>> irq 27 on simplebus1
>>>>> gpio0: <Armada 37x0 North Bridge GPIO Controller> mem
>>>>> 0x13800-0x138ff,0x13c00-0x13c1f irq
>>>>>
>>>>> 28,29,30,31,32,33,34,35,36,37,38,39 on
>>>>>
>>>>> simple_mfd0
>>>>> gpio0: cannot allocate memory window
>>>>> device_attach: gpio0 attach returned 6
>>>>> gpio0: <Armada 37x0 South Bridge GPIO Controller> mem
>>>>> 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 on
>>>>>
>>>>> simple_mfd1
>>>>>
>>>>> gpio0: cannot allocate memory window
>>>>> device_attach: gpio0 attach returned 6
>>>>> gpioregulator0: <GPIO controlled regulator> on ofwbus0
>>>>> gpioregulator0: cannot get pin 0
>>>>> gpioregulator0: cannot parse parameters
>>>>> device_attach: gpioregulator0 attach returned 6
>>>>> generic_timer0: <ARMv8 Generic Timer> irq 0,1,2,3 on
>>>>>
>>>>> ofwbus0
>>>>>
>>>>> Timecounter "ARM MPCore Timecounter" frequency
>>>>>
>>>>> 12500000 Hz quality 1000
>>>>>
>>>>> Event timer "ARM MPCore Eventtimer" frequency
>>>>>
>>>>> 12500000 Hz quality 1000
>>>>>
>>>>> gpio0: <Armada 37x0 North Bridge GPIO Controller> mem
>>>>> 0x13800-0x138ff,0x13c00-0x13c1f irq
>>>>>
>>>>> 28,29,30,31,32,33,34,35,36,37,38,39 on
>>>>>
>>>>> simple_mfd0
>>>>> gpio0: cannot allocate memory window
>>>>> device_attach: gpio0 attach returned 6
>>>>> gpio0: <Armada 37x0 South Bridge GPIO Controller> mem
>>>>> 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 on
>>>>>
>>>>> simple_mfd1
>>>>>
>>>>> gpio0: cannot allocate memory window
>>>>> device_attach: gpio0 attach returned 6
>>>>> gpioregulator0: <GPIO controlled regulator> on ofwbus0
>>>>> gpioregulator0: cannot get pin 0
>>>>> gpioregulator0: cannot parse parameters
>>>>> device_attach: gpioregulator0 attach returned 6
>>>>> gpio0: <Armada 37x0 North Bridge GPIO Controller> mem
>>>>> 0x13800-0x138ff,0x13c00-0x13c1f irq
>>>>>
>>>>> 28,29,30,31,32,33,34,35,36,37,38,39 on
>>>>>
>>>>> simple_mfd0
>>>>> gpio0: cannot allocate memory window
>>>>> device_attach: gpio0 attach returned 6
>>>>> gpio0: <Armada 37x0 South Bridge GPIO Controller> mem
>>>>> 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 on
>>>>>
>>>>> simple_mfd1
>>>>>
>>>>> gpio0: cannot allocate memory window
>>>>> device_attach: gpio0 attach returned 6
>>>>> gpioregulator0: <GPIO controlled regulator> on ofwbus0
>>>>> gpioregulator0: cannot get pin 0
>>>>> gpioregulator0: cannot parse parameters
>>>>> device_attach: gpioregulator0 attach returned 6
>>>>> gpio0: <Armada 37x0 North Bridge GPIO Controller> mem
>>>>> 0x13800-0x138ff,0x13c00-0x13c1f irq
>>>>>
>>>>> 28,29,30,31,32,33,34,35,36,37,38,39 on
>>>>>
>>>>> simple_mfd0
>>>>> gpio0: cannot allocate memory window
>>>>> device_attach: gpio0 attach returned 6
>>>>> gpio0: <Armada 37x0 South Bridge GPIO Controller> mem
>>>>> 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 on
>>>>>
>>>>> simple_mfd1
>>>>>
>>>>> gpio0: cannot allocate memory window
>>>>> device_attach: gpio0 attach returned 6
>>>>> gpioregulator0: <GPIO controlled regulator> on ofwbus0
>>>>> gpioregulator0: cannot get pin 0
>>>>> gpioregulator0: cannot parse parameters
>>>>> device_attach: gpioregulator0 attach returned 6
>>>>> gpio0: <Armada 37x0 North Bridge GPIO Controller> mem
>>>>> 0x13800-0x138ff,0x13c00-0x13c1f irq
>>>>>
>>>>> 28,29,30,31,32,33,34,35,36,37,38,39 on
>>>>>
>>>>> simple_mfd0
>>>>> gpio0: cannot allocate memory window
>>>>> device_attach: gpio0 attach returned 6
>>>>> gpio0: <Armada 37x0 South Bridge GPIO Controller> mem
>>>>> 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 on
>>>>>
>>>>> simple_mfd1
>>>>>
>>>>> gpio0: cannot allocate memory window
>>>>> device_attach: gpio0 attach returned 6
>>>>> gpioregulator0: <GPIO controlled regulator> on ofwbus0
>>>>> gpioregulator0: cannot get pin 0
>>>>> gpioregulator0: cannot parse parameters
>>>>> device_attach: gpioregulator0 attach returned 6
>>>>> cpulist0: <Open Firmware CPU Group> on ofwbus0
>>>>> cpu0: <Open Firmware CPU> on cpulist0
>>>>> cpu1: <Open Firmware CPU> on cpulist0
>>>>> pmu0: <Performance Monitoring Unit> irq 4 on ofwbus0
>>>>> syscon_generic0: <syscon> mem 0xd000-0xdfff on
>>>>>
>>>>> simplebus1
>>>>>
>>>>> syscon_generic1: <syscon> mem 0x11500-0x1153f on
>>>>>
>>>>> simplebus1
>>>>>
>>>>> uart0: <Marvell Armada 3700 UART> mem 0x12000-0x121ff
>>>>>
>>>>> irq 9,10,11 on
>>>>>
>>>>> simplebus1
>>>>> uart0: console (115200,n,8,1)
>>>>> gpio0: <Armada 37x0 North Bridge GPIO Controller> mem
>>>>> 0x13800-0x138ff,0x13c00-0x13c1f irq
>>>>>
>>>>> 28,29,30,31,32,33,34,35,36,37,38,39 on
>>>>>
>>>>> simple_mfd0
>>>>> gpio0: cannot allocate memory window
>>>>> device_attach: gpio0 attach returned 6
>>>>> syscon_generic2: <syscon> mem 0x14000-0x1405f on
>>>>>
>>>>> simplebus1
>>>>>
>>>>> gpio0: <Armada 37x0 South Bridge GPIO Controller> mem
>>>>> 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 on
>>>>>
>>>>> simple_mfd1
>>>>>
>>>>> gpio0: cannot allocate memory window
>>>>> device_attach: gpio0 attach returned 6
>>>>> mvneta0: <NETA controller> mem 0x30000-0x33fff irq 14
>>>>>
>>>>> on simplebus1
>>>>>
>>>>> mvneta0: version is 10
>>>>> mvneta0: Ethernet address: 00:a6:39:ca:e8:00
>>>>> mdio0: <MDIO> on mvneta0
>>>>> mdioproxy0: <MII/MDIO proxy, MDIO side> on mdio0
>>>>> e6000sw0: <Marvell 88E6341> on mdio0
>>>>> e6000sw0: multi-chip addressing mode (0x1)
>>>>> e6000sw0: CPU port at 0
>>>>> e6000sw0: fixed port at 0
>>>>> e6000sw0: PHY at port 1
>>>>> miibus0: <MII bus> on e6000sw0
>>>>> e1000phy0: <Marvell 88E1000 Gigabit PHY> PHY 17 on
>>>>>
>>>>> miibus0
>>>>>
>>>>> e1000phy0:  none, 10baseT, 10baseT-FDX, 100baseTX,
>>>>>
>>>>> 100baseTX-FDX,
>>>>>
>>>>> 1000baseT, 1000baseT-master, 1000baseT-FDX,
>>>>>
>>>>> 1000baseT-FDX-master, auto
>>>>>
>>>>> e6000sw0: PHY at port 2
>>>>> miibus1: <MII bus> on e6000sw0
>>>>> e1000phy1: <Marvell 88E1000 Gigabit PHY> PHY 18 on
>>>>>
>>>>> miibus1
>>>>>
>>>>> e1000phy1:  none, 10baseT, 10baseT-FDX, 100baseTX,
>>>>>
>>>>> 100baseTX-FDX,
>>>>>
>>>>> 1000baseT, 1000baseT-master, 1000baseT-FDX,
>>>>>
>>>>> 1000baseT-FDX-master, auto
>>>>>
>>>>> e6000sw0: PHY at port 3
>>>>> miibus2: <MII bus> on e6000sw0
>>>>> e1000phy2: <Marvell 88E1000 Gigabit PHY> PHY 19 on
>>>>>
>>>>> miibus2
>>>>>
>>>>> e1000phy2:  none, 10baseT, 10baseT-FDX, 100baseTX,
>>>>>
>>>>> 100baseTX-FDX,
>>>>>
>>>>> 1000baseT, 1000baseT-master, 1000baseT-FDX,
>>>>>
>>>>> 1000baseT-FDX-master, auto
>>>>>
>>>>> e6000sw0: switch is ready.
>>>>> etherswitch0: <Switch controller> on e6000sw0
>>>>> xhci0: <Generic USB 3.0 controller> mem
>>>>>
>>>>> 0x58000-0x5bfff irq 16 on
>>>>>
>>>>> simplebus1
>>>>> xhci0: 32 bytes context size, 32-bit DMA
>>>>> usbus0 on xhci0
>>>>> syscon_generic3: <syscon> mem 0x5d800-0x5dfff on
>>>>>
>>>>> simplebus1
>>>>>
>>>>> ehci0: <Marvell Integrated USB 2.0 controller> mem
>>>>>
>>>>> 0x5e000-0x5efff irq
>>>>>
>>>>> 17 on simplebus1
>>>>> usbus1: EHCI version 1.0
>>>>> usbus1 on ehci0
>>>>> syscon_generic4: <syscon> mem 0x5f800-0x5ffff on
>>>>>
>>>>> simplebus1
>>>>>
>>>>> sdhci_xenon0: <Armada Xenon SDHCI controller> mem
>>>>> 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1
>>>>> ahci0: <AHCI SATA controller> mem 0xe0000-0xe0177 irq
>>>>>
>>>>> 26 on simplebus1
>>>>>
>>>>> ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier
>>>>>
>>>>> supported with FBS
>>>>>
>>>>> ahcich0: <AHCI channel> at channel 0 on ahci0
>>>>> device_attach: ahcich0 attach returned 6
>>>>> gpioregulator0: <GPIO controlled regulator> on ofwbus0
>>>>> gpioregulator0: cannot get pin 0
>>>>> gpioregulator0: cannot parse parameters
>>>>> device_attach: gpioregulator0 attach returned 6
>>>>> cryptosoft0: <software crypto>
>>>>> Timecounters tick every 1.000 msec
>>>>> mvneta0: link state changed to UP
>>>>> e6000sw0port1: link state changed to DOWN
>>>>> e6000sw0port2: link state changed to DOWN
>>>>> e6000sw0port3: link state changed to DOWN
>>>>> usbus0: 5.0Gbps Super Speed USB v3.0
>>>>> usbus1: 480Mbps High Speed USB v2.0
>>>>> Release APs...done
>>>>> CPU  0: ARM Cortex-A53 r0p4 affinity:  0
>>>>> Instruction Set Attributes 0 =3D
>>>>>
>>>>> <CRC32,SHA2,SHA1,AES+PMULL>
>>>>>
>>>>> Trying to mount root from
>>>>>
>>>>> ufs:/dev/ufs/FreeBSD_Install [ro,noatime]...
>>>>>
>>>>> Instruction Set Attributes 1 =3D <>
>>>>> Root mount waiting for:         Processor Features 0 =3D
>>>>> <GIC,AdvSIMD,Float,EL3 32,EL2 32,EL1 32,EL0 32>
>>>>> usbus1         Processor Features 1 =3D <0>
>>>>> usbus0      Memory Model Features 0 =3D <4k Granule,64k
>>>>>
>>>>> Granule,S/NS
>>>>>
>>>>> Mem,MixedEndian,16bit ASID,1TB PA>
>>>>>
>>>>> Memory Model Features 1 =3D <>
>>>>> Memory Model Features 2 =3D <32b CCIDX,48b VA>
>>>>>       Debug Features 0 =3D <2 CTX Breakpoints,4
>>>>>
>>>>> Watchpoints,6
>>>>>
>>>>> Breakpoints,PMUv3,Debug v8>
>>>>>       Debug Features 1 =3D <0>
>>>>>   Auxiliary Features 0 =3D <0>
>>>>>   Auxiliary Features 1 =3D <0>
>>>>> CPU  1: ARM Cortex-A53 r0p4 affinity:  1
>>>>> WARNING: WITNESS option enabled, expect reduced
>>>>>
>>>>> performance.
>>>>>
>>>>> ugen0.1: <Generic XHCI root HUB> at usbus0
>>>>> ugen1.1: <Marvell EHCI root HUB> at usbus1
>>>>> uhub0 on usbus0
>>>>> uhub1 on usbus1
>>>>> uhub0: <Generic XHCI root HUB, class 9/0, rev
>>>>>
>>>>> 3.00/1.00, addr 1> on
>>>>>
>>>>> usbus0
>>>>> uhub1: <Marvell EHCI root HUB, class 9/0, rev
>>>>>
>>>>> 2.00/1.00, addr 1> on
>>>>>
>>>>> usbus1
>>>>> uhub0: 2 ports with 2 removable, self powered
>>>>> uhub1: 1 port with 1 removable, self powered
>>>>> mountroot: waiting for device
>>>>>
>>>>> /dev/ufs/FreeBSD_Install...
>>>>>
>>>>> Mounting from ufs:/dev/ufs/FreeBSD_Install failed
>>>>>
>>>>> with error 19.
>>>>>
>>>>>
>>>>> Loader variables:
>>>>> vfs.root.mountfrom=3Dufs:/dev/ufs/FreeBSD_Install
>>>>> vfs.root.mountfrom.options=3Dro,noatime
>>>>>
>>>>> Manual root filesystem specification:
>>>>> <fstype>:<device> [options]
>>>>> Mount <device> using filesystem <fstype>
>>>>> and with the specified (optional) option list.
>>>>>
>>>>> eg. ufs:/dev/da0s1a
>>>>>  zfs:zroot/ROOT/default
>>>>>  cd9660:/dev/cd0 ro
>>>>>    (which is equivalent to: mount -t cd9660 -o ro
>>>>>
>>>>> /dev/cd0 /)
>>>>>
>>>>>
>>>>> ?               List valid disk boot devices
>>>>> .               Yield 1 second (for background tasks)
>>>>> <empty line>    Abort manual input
>>>>>
>>>>> mountroot> ?
>>>>>
>>>>> List of GEOM managed disk devices:
>>>>>
>>>>>
>>>>> mountroot>
>>>>> _______________________________________________
>>>>> freebsd-arm@freebsd.org <mailto:
>>>>>
>>>>> freebsd-arm@freebsd.org> mailing list
>>>>>
>>>>>
>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm <
>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm>;
>>>>>
>>>>> To unsubscribe, send any mail to "
>>>>>
>>>>> freebsd-arm-unsubscribe@freebsd.org <mailto:
>>>>> freebsd-arm-unsubscribe@freebsd.org>"
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> freebsd-arm@freebsd.org <mailto:
>>>>>
>>>>> freebsd-arm@freebsd.org> mailing list
>>>>>
>>>>>
>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm <
>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm>;
>>>>>
>>>>> To unsubscribe, send any mail to "
>>>>>
>>>>> freebsd-arm-unsubscribe@freebsd.org <mailto:
>>>>> freebsd-arm-unsubscribe@freebsd.org>"
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Emmanuel Vadot <manu@bidouilliste.com> <
>>>>>
>>>>> manu@freebsd.org>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
>>>>> _______________________________________________
>>>>> freebsd-arm@freebsd.org mailing list
>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
>>>>> To unsubscribe, send any mail to "
>>>>>
>>>>> freebsd-arm-unsubscribe@freebsd.org"
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
>>>>> _______________________________________________
>>>>> freebsd-arm@freebsd.org mailing list
>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
>>>>> To unsubscribe, send any mail to "
>>>>>
>>>>> freebsd-arm-unsubscribe@freebsd.org"
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
>>>>> _______________________________________________
>>>>> freebsd-arm@freebsd.org mailing list
>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
>>>>> To unsubscribe, send any mail to "
>>>>>
>>>>> freebsd-arm-unsubscribe@freebsd.org"
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Emmanuel Vadot <manu@bidouilliste.com <mailto:
>>>>>
>>>>> manu@bidouilliste.com>> <manu@freebsd.org <mailto:manu@freebsd.org=
>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Emmanuel Vadot <manu@bidouilliste.com <mailto:
>>>>>
>>>>> manu@bidouilliste.com>> <manu@freebsd.org <mailto:manu@freebsd.org=
>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
>>>>> _______________________________________________
>>>>> freebsd-arm@freebsd.org mailing list
>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
>>>>> To unsubscribe, send any mail to "
>>>>> freebsd-arm-unsubscribe@freebsd.org"
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> freebsd-arm@freebsd.org mailing list
>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
>>>>> To unsubscribe, send any mail to  =

>>>>> "freebsd-arm-unsubscribe@freebsd.org"
>>>>>
>>>>>
>>>>>
>>> _______________________________________________
>>> freebsd-arm@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
>>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.or=
g"
From owner-freebsd-arm@freebsd.org  Wed Aug 21 02:58:53 2019
Return-Path: <owner-freebsd-arm@freebsd.org>
Delivered-To: freebsd-arm@mailman.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
 by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7778EE7A54
 for <freebsd-arm@mailman.nyi.freebsd.org>;
 Wed, 21 Aug 2019 02:58:53 +0000 (UTC)
 (envelope-from zhangchaowang@gmail.com)
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com
 [IPv6:2607:f8b0:4864:20::734])
 (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
 server-signature RSA-PSS (4096 bits)
 client-signature RSA-PSS (2048 bits) client-digest SHA256)
 (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK))
 by mx1.freebsd.org (Postfix) with ESMTPS id 46Csn81fNNz4NmL
 for <freebsd-arm@freebsd.org>; Wed, 21 Aug 2019 02:58:51 +0000 (UTC)
 (envelope-from zhangchaowang@gmail.com)
Received: by mail-qk1-x734.google.com with SMTP id 125so597910qkl.6
 for <freebsd-arm@freebsd.org>; Tue, 20 Aug 2019 19:58:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:mime-version:subject:message-id:date:to;
 bh=8YXS7BoFVTrc+BHX1Tji5lhGa8Kh+AuA0UXVgQKoB9w=;
 b=e1eID4L47JU9s7PUHMwfXwZXaWO5H2aRGHa2nHvAOeDjmBdDcxW583O4yXy3PpLyox
 oqNkklsYmhaf9BPb3sMWvnSW6gYEYRwwgkngVOy/Grd2MEAie81/uIAozcy+7F5C01MW
 qBFdb+W+kQZQSKrig/jLNp40UNnRR8H5vA2ZvpN34yBhcxSUpSe/ACda0S2e0DJeV11r
 hDOV/nnNmthgmWbiu4zELMqtunoJ81fcHgLz4FwFHxT+tCpzo1WAxB33Qe1Jhvv7WTBM
 0ukbuu7ax6+9MCpwVQxLu9vkIzN0g+1od8PsNUVIQvX9NOT29sPmPMm6V7FJ81H8WdFE
 eUwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:mime-version:subject:message-id:date:to;
 bh=8YXS7BoFVTrc+BHX1Tji5lhGa8Kh+AuA0UXVgQKoB9w=;
 b=RLl+ENmrhnFugWylLZR83AspMI8FEjtY9FyHhIWzCJmZSBR5mfLqZNcODRXROZXDNq
 Jsrp3ULMPbICDPrGDtg693Q4s4qzlhGIO6th7oDof3a/RRVGEGURMdIvQ2oGLwL2kbDj
 idj3WxGa+6tzQdgjgTS+3/J+XeiVXdgBOzKJam5RfWMFnkjf0/KvMPlHPaDf10aPioec
 SpPm0nQMC9ZTqqg3hF776ncp5wkrw2rikU/P7dFs84tF3T44NBwBTRD9vVg1852iiyIP
 eykXxCTgoviilQ5RUbhdwk9QtLthoxsz3vSwGB0NAQHLlDMKU0RtqJ1R6ZniX+qilFyT
 JczA==
X-Gm-Message-State: APjAAAW6zQKyaD+XvRgsEaTLhv43JrWD6bs+l2r4ebIkVKAHJPvDbRy5
 jxnf1G42xtchdPUbRb6SAAzOKJK5pcA=
X-Google-Smtp-Source: APXvYqw1XzG/UqogoofVW07JZg0ng750z3qEflRpNrgzeQVzH07ST1zgb8hoiNOvi0AiLQYxVARFhg==
X-Received: by 2002:a37:6715:: with SMTP id b21mr1384251qkc.397.1566356330432; 
 Tue, 20 Aug 2019 19:58:50 -0700 (PDT)
Received: from [192.168.2.15] (cpe-76-182-13-165.nc.res.rr.com.
 [76.182.13.165])
 by smtp.gmail.com with ESMTPSA id u13sm10592591qkm.97.2019.08.20.19.58.49
 for <freebsd-arm@freebsd.org>
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 20 Aug 2019 19:58:49 -0700 (PDT)
From: Ricky Zhang <zhangchaowang@gmail.com>
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Re: How to change rootfs from official RPI3 image
Message-Id: <0FC8815E-58D7-4196-BF7E-0D6B127B314D@gmail.com>
Date: Tue, 20 Aug 2019 22:58:47 -0400
To: freebsd-arm@freebsd.org
X-Mailer: Apple Mail (2.3445.104.11)
X-Rspamd-Queue-Id: 46Csn81fNNz4NmL
X-Spamd-Bar: --
Authentication-Results: mx1.freebsd.org;
 dkim=pass header.d=gmail.com header.s=20161025 header.b=e1eID4L4;
 dmarc=pass (policy=none) header.from=gmail.com;
 spf=pass (mx1.freebsd.org: domain of zhangchaowang@gmail.com designates
 2607:f8b0:4864:20::734 as permitted sender)
 smtp.mailfrom=zhangchaowang@gmail.com
X-Spamd-Result: default: False [-2.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[];
 R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36];
 FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[];
 MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[3];
 DKIM_TRACE(0.00)[gmail.com:+];
 DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
 NEURAL_HAM_SHORT(-1.00)[-0.997,0];
 RECEIVED_SPAMHAUS_PBL(0.00)[165.13.182.76.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net
 : 127.0.0.10]; FROM_EQ_ENVFROM(0.00)[];
 MIME_TRACE(0.00)[0:+,1:+,2:~];
 FREEMAIL_ENVFROM(0.00)[gmail.com];
 ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
 MID_RHS_MATCH_FROM(0.00)[];
 DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0];
 ARC_NA(0.00)[]; FAKE_REPLY(1.00)[];
 R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025];
 NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[];
 TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0];
 MIME_GOOD(-0.10)[multipart/alternative,text/plain];
 PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org];
 IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1];
 IP_SCORE(0.00)[ip: (-9.44), ipnet: 2607:f8b0::/32(-2.92), asn: 15169(-2.36),
 country: US(-0.05)]; 
 RCVD_IN_DNSWL_NONE(0.00)[4.3.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org
 : 127.0.5.0]; RCVD_TLS_ALL(0.00)[]
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Content-Filtered-By: Mailman/MimeDel 2.1.29
X-BeenThere: freebsd-arm@freebsd.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>;
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Aug 2019 02:58:53 -0000

> BTW: Yes, u-boot is opensource: /usr/ports/sysutils/u-boot-rpi3
> There are sysutils/u-boot-* ports for different system. With =
sysutils/u-boot-master as the main part of it.
>=20
> https://www.freshports.org/sysutils/u-boot-rpi3 =
<https://www.freshports.org/sysutils/u-boot-rpi3>;
> http://www.denx.de/wiki/U-Boot <http://www.denx.de/wiki/U-Boot>;
>=20
> Regards,
> Ronald.


Hi Ronald,

Sorry, if I messed up the mailing list thread. I didn=E2=80=99t receive =
your email directly. Instead, I got your reply from daily digest. I have =
to copy subject and quote your reply manually in my email client. I have =
no idea how to fix it after reading all FAQ =
(https://www.freebsd.org/doc/en_US.ISO8859-1/articles/mailing-list-faq/art=
icle.html#etiquette =
<https://www.freebsd.org/doc/en_US.ISO8859-1/articles/mailing-list-faq/art=
icle.html#etiquette>). Any other mailing list I subscribed didn=E2=80=99t =
work this way...

In any case, the magic works. I did rsync:

rsync -aAXvr --progress --delete /* /mnt/USB \
    --exclude=3D'/boot/msdos/*' \
    --exclude=3D'/dev/*' \
    --exclude=3D'/proc/*' \
    --exclude=3D'/net/*' \
    --exclude=3D'/tmp/*' \
    --exclude=3D'/mnt/*' \
    --exclude=3D'/media/*'

I confirmed that it mount ssd as rootfs:

Ricky@router ~ $ df -h
Filesystem                  Size    Used   Avail Capacity  Mounted on
/dev/label/gpt/ssdrootfs    407G    5.5G    369G     1%    /
devfs                       1.0K    1.0K      0B   100%    /dev
/dev/msdosfs/MSDOSBOOT       50M     13M     37M    26%    /boot/msdos
tmpfs                        50M    4.0K     50M     0%    /tmp

As you said, kernel still comes from SD card. I don=E2=80=99t fully =
understand the FreeBSD boot process. Neither am I familiar with UEFI.

- I guess /boot/msdos/uboot.bin finds the SD card roofs system. Load the =
kernel from /boot/kernel in SD card and scan /boot/loader.conf to find =
the rootfs. Please correct me if I=E2=80=99m wrong.
- Should I remove /boot folder from SSD to avoid confusion?=20
- Are there any guide how to compile and deploy kernel?







Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?op.z6t4g5ajkndu52>