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>