Espressobin anyone ?
Jeffrey Bowers
khantroll at gmail.com
Thu Aug 22 17:27:09 UTC 2019
No, unfortunately it still ends in an E000060: Operation timed out.
However, there are files and directories in my local ports directory, so
it's downloading at least some things.
On Tue, Aug 20, 2019 at 2:01 PM Ronald Klop <ronald-lists at klop.ws> wrote:
> On Wed, 21 Aug 2019 01:03:37 +0200, Jeffrey Bowers <khantroll at gmail.com>
> wrote:
>
> Yes sir, I can ping svn.freebsd.org. Any idea why the checkout fails?
>
>
> I don't know. What ip address do you get when pinging?
>
> Does this work for you? Does it work using the ip address you get?
>
> svn checkout https://213.138.116.72/ports/head
>
> Regards,
> Ronald.
>
>
>
>
> On Tue, Aug 20, 2019 at 7:46 AM Ronald Klop <ronald-lists at klop.ws> wrote:
>
>> It is not possible to 'ping https://svn.freebsd.org/ports/head'.
>> You can 'ping svn.freebsd.org'.
>>
>> Ronald.
>>
>>
>> *Van:* Jeffrey Bowers <khantroll at gmail.com>
>> *Datum:* dinsdag, 20 augustus 2019 14:36
>> *Aan:* "Søren Schmidt" <soren.schmidt at gmail.com>, freebsd-arm <
>> freebsd-arm at freebsd.org>
>> *Onderwerp:* Re: Espressobin anyone ?
>>
>> I just tried to ping https://svn.freebsd.org/ports/head, and even though
>> it scrolsl through all that text I get an error saying "could not resolve
>> https://svn.freebsd.org/ports/head ; unknown server error" . I can ping
>> google just fine. Is it a DNS issue?
>>
>> On Tue, Aug 20, 2019 at 7:33 AM Jeffrey Bowers <khantroll at gmail.com>
>> wrote:
>>
>> > I'm still getting: svn: E000060: Operation timed out
>> > It goes for several minutes scrolling through text, and I feel like
>> using
>> > your link got further.
>> >
>> > Thanks!
>> >
>> > On Tue, Aug 20, 2019 at 2:49 AM Søren Schmidt <soren.schmidt at gmail.com>
>> > wrote:
>> >
>> >> Hmm, I use this URL
>> >>
>> >> Repository Root: https://svn.freebsd.org/ports/head
>> >>
>> >> Not sure the svn+ssh thing works…
>> >>
>> >> -Søren
>> >>
>> >>
>> >> On 20 Aug 2019, at 02.38, Jeffrey Bowers <khantroll at gmail.com> wrote:
>> >>
>> >> Hi all,
>> >>
>> >> I'm having trouble getting subversion to work. When I run:
>> >>
>> >> svn checkout https://svn.FreeBSD.org/ports/head /usr/ports
>> >>
>> >> It scrolls through many lines of text before stating: svn: E000060:
>> >> Operation timed out
>> >>
>> >> When I run:
>> >>
>> >> svn checkout svn+ssh://repo.freebsd.org/ports/head /usr/ports
>> >>
>> >> It tells me that the authenticity of the host cannot be identified, and
>> >> asks me to confirm that I want to connect. I say yes, and then it says:
>> >>
>> >> svn: E170013: Unable to connect to a repository at URL 'svn+ssh://
>> >> repo.freebsd.org/ports/head'
>> >> svn: E210002: To better debug SSH connection problems, remove the -q
>> >> option
>> >> from 'ssh' in the [tunnels] section of your Subversion configuration
>> file.
>> >>
>> >> Any ideas?
>> >>
>> >> Thanks in advance!
>> >>
>> >> On Mon, Aug 19, 2019 at 8:51 PM Jeffrey Bowers <khantroll at gmail.com>
>> >> wrote:
>> >>
>> >> I didn't think it remounting. Thank you!
>> >>
>> >> On Mon, Aug 19, 2019 at 11:39 AM Søren Schmidt <
>> soren.schmidt at gmail.com>
>> >> wrote:
>> >>
>> >> Hi Jeffrey
>> >>
>> >> You need to unmount the /tmp filesystem :)
>> >> You can do that permanently by commenting it out in /etc/fstab
>> >>
>> >>
>> >> On 19 Aug 2019, at 21.45, Jeffrey Bowers <khantroll at gmail.com> wrote:
>> >>
>> >> Hi Soren,
>> >>
>> >> I'm getting the same error message. Any other ideas what it might be?
>> >> It's got to be something in the partition scheme or the file
>> permissions,
>> >> but I'm just not sure what.
>> >> <image.png>
>> >>
>> >> On Sun, Aug 18, 2019 at 10:03 AM Jeffrey Bowers <khantroll at gmail.com>
>> >> wrote:
>> >>
>> >> D’Oh! I thought I too care of that with gpart. I literally missed
>> growfs
>> >> part of the instructions..
>> >>
>> >> On Sun, Aug 18, 2019 at 10:00 AM Søren Schmidt <
>> soren.schmidt at gmail.com>
>> >> wrote:
>> >>
>> >> Hi
>> >>
>> >> You are out of space :)
>> >>
>> >> Boot the board into singleuser mode, and do “service growfs start”,
>> >> that will expand you / filesystem to the entire SD card…
>> >>
>> >> -Søren
>> >>
>> >> On 18 Aug 2019, at 14.50, Jeffrey Bowers <khantroll at gmail.com> wrote:
>> >>
>> >> Sure thing! Here's the screenshot!
>> >> <image.png>
>> >>
>> >>
>> >> On Sun, Aug 18, 2019 at 7:35 AM Søren Schmidt <soren.schmidt at gmail.com
>> >
>> >> wrote:
>> >>
>> >> Hi
>> >>
>> >> Can I have you paste the output from df -h ?
>> >>
>> >> You should be able to utilise the full SD card…
>> >>
>> >> -Søren
>> >>
>> >> On 18 Aug 2019, at 14.29, Jeffrey Bowers <khantroll at gmail.com> wrote:
>> >>
>> >> Hi,
>> >>
>> >> Just make sure I understand the process, I should hook up a hard disk
>> >> and map it to to /TMP ?
>> >>
>> >> I already tried just unmapping /tmp, and it gave me the same error
>> >> once, and then the next time I ran it I got an error saying /usr/ports
>> was
>> >> out of space )which I guess I shouldn’t mount to another director on
>> the
>> >> hard drive?
>> >>
>> >> On Sun, Aug 18, 2019 at 5:11 AM Søren Schmidt <soren.schmidt at gmail.com
>> >
>> >> wrote:
>> >>
>> >> Hi Jeffrey
>> >>
>> >> You can unmount the memory disk on /tmp to get at the space on the SD
>> >> card.
>> >>
>> >> It is however not recommend to use the AD card for random storage, it
>> >> will wear out fast, that’s why the memory disk is setup.
>> >>
>> >> You could connect a SSD og laptop disk to the SATA interface and use
>> >> that for the workload.
>> >>
>> >> However compiling is slow, its much much faster to cross compile on a
>> >> PC…
>> >>
>> >> -Søren
>> >>
>> >> On 18 Aug 2019, at 00.22, Jeffrey Bowers <khantroll at gmail.com> wrote:
>> >>
>> >> Hi! I've got a new one :)
>> >> I'm trying to do an svn checkout to fix the pkg problem, but it tells
>> >> me it can't write to a to a temp folder because there is no room left
>> on
>> >> the device. However, FreeBSD partition is 29GB. It's never also never
>> the
>> >> same file in TMP that it can't write to. Here is a screenshot of the
>> >> issue,
>> >> along with the output of gpart:
>> >>
>> >> <image.png>
>> >>
>> >> Any ideas?
>> >>
>> >> Thanks!
>> >>
>> >>
>> >> On Sat, Aug 17, 2019 at 2:08 PM Emmanuel Vadot <manu at bidouilliste.com>
>> >> wrote:
>> >>
>> >> On Sat, 17 Aug 2019 17:14:36 +0200
>> >> Søren Schmidt <soren.schmidt at gmail.com> wrote:
>> >>
>> >> HI
>> >>
>> >> Well, I have a whole forrest of tree?s here, but the error posted
>> >>
>> >> here was on a clean checkout.
>> >>
>> >>
>> >> Anyhow, with the latest changes to -stable and the two
>> >>
>> >> RF_SHAREABLE patches from -current all works.
>> >>
>> >> I've reverted the commits, see
>> >> https://github.com/evadot/freebsd/commits/a37x0_gpio for a better
>> >> way
>> >> to deal with this issue.
>> >> I'm waiting for mmel@ as he wrote the syscon_get_default_handle
>> >> part.
>> >>
>> >> It would be nice with the etherswitch changes as well so VLAN
>> >>
>> >> tagging etc was standard.
>> >>
>> >>
>> >> -Søren
>> >>
>> >> PS: given up on bottom & inline popsting, top posting is all the
>> >>
>> >> rage now (yeah I miss elm etc :) )
>> >>
>> >>
>> >> On 17 Aug 2019, at 15.30, Emmanuel Vadot <manu at bidouilliste.com>
>> >>
>> >> wrote:
>> >>
>> >>
>> >> On Sat, 17 Aug 2019 11:07:22 +0200
>> >> Søren Schmidt <soren.schmidt at gmail.com <mailto:
>> >>
>> >> soren.schmidt at gmail.com>> wrote:
>> >>
>> >>
>> >> Hi Emmunuel
>> >>
>> >> Yes the 3720 gpio driver I already back ported long ago, its
>> >>
>> >> needed, I?m happy its now part of std stable 12!
>> >>
>> >>
>> >> Would have been nice of you to say that you were not running a
>> >>
>> >> clean
>> >>
>> >> tree.
>> >>
>> >> My issue seems to be the inclusion of the phy_usb driver, if I
>> >>
>> >> leave that out, I?m back to normal..
>> >>
>> >>
>> >> What make you think this is this driver ? What works/doesn't work
>> >> with it ? could you provide logs.
>> >>
>> >> I?ll have have another go at the latest -stable sources during
>> >>
>> >> the weekend and see how it goes.
>> >>
>> >>
>> >> Thanks for looking into this, with a little cooperation we?ll
>> >>
>> >> get this solved for the greater good..
>> >>
>> >>
>> >> -Søren
>> >>
>> >>
>> >> P.S. Please stop top posting, it's really hard to read the
>> >>
>> >> conversation
>> >>
>> >>
>> >> On 16 Aug 2019, at 22.58, Emmanuel Vadot <
>> >>
>> >> manu at bidouilliste.com> wrote:
>> >>
>> >>
>> >> On Fri, 16 Aug 2019 19:12:30 +0200
>> >> Emmanuel Vadot <manu at bidouilliste.com <mailto:
>> >>
>> >> manu at bidouilliste.com>> wrote:
>> >>
>> >>
>> >> On Fri, 16 Aug 2019 17:10:37 +0200
>> >> Emmanuel Vadot <manu at bidouilliste.com> wrote:
>> >>
>> >> On Fri, 16 Aug 2019 15:24:54 +0200
>> >> Emmanuel Vadot <manu at bidouilliste.com> wrote:
>> >>
>> >> On Fri, 16 Aug 2019 07:28:59 +0200
>> >> Søren Schmidt <soren.schmidt at gmail.com> wrote:
>> >>
>> >> Hi
>> >>
>> >> Very simple, reverting sys/gnu/dts to what was before
>> >>
>> >> 350595 (actually 350592).
>> >>
>> >> Thats what we have svn for ?
>> >>
>> >>
>> >> If I asked how it was to have the svn command that you
>> >>
>> >> used, I want to
>> >>
>> >> make sure that you didn't revert anything else, like do you
>> >>
>> >> have
>> >>
>> >> r350596 and r350628 ?
>> >>
>> >> That does make my bananapi work again, no other changes
>> >>
>> >> just a recompiled kernel.
>> >>
>> >>
>> >> That + copying the dtb to the fat32 partition ?
>> >>
>> >> Can you post the dtb somewhere.
>> >>
>> >> However it does not bring the Espressobin back to life,
>> >>
>> >> thats something in one of the ~30 other files that changed between
>> those
>> >> two revisions.
>> >>
>> >>
>> >> What Linux version of DTS are you using then ? The ones
>> >>
>> >> that were in
>> >>
>> >> stable/12 when it was branched (4.18) or a later revision ?
>> >>
>> >>
>> >> So I think that I've found the problem on the Espressobin.
>> >> I think that the problem comes from the simple-mfd driver
>> >>
>> >> that I've
>> >>
>> >> mfc in r350600.
>> >> The pinctrl/gpio controller compatible is
>> >> "marvell,armada3710-nb-pinctrl", "syscon", "simple-mfd" and
>> >>
>> >> it attaches
>> >>
>> >> at BUS_PASS_INTERRUPT while the simple_mfd driver attaches at
>> >> BUS_PASS_BUS (so earlier) which means that no gpio
>> >>
>> >> controller will be
>> >>
>> >> available for sdhci to detect the card.
>> >>
>> >> If someone with a non-working espressobin could post a full
>> >>
>> >> verbose
>> >>
>> >> boot log that would help me confirming that this is the case.
>> >> I'll try to find a solution on how to solve this problem.
>> >>
>> >>
>> >> So this wasn't the problem but I've found it, see r351129 and
>> >>
>> >> r351130
>> >>
>> >>
>> >> SD card now work again in HEAD, I'll have a look at stable
>> >>
>> >> later next
>> >>
>> >> week.
>> >>
>> >>
>> >> I've did a quick test and I've MFC r348880, r348882 and
>> >>
>> >> r349596, the
>> >>
>> >> two other commits needed to be mfc'ed are the one I did today
>> >>
>> >> on head,
>> >>
>> >> I'll do that next week.
>> >> With them sdcard is working again on stable/12
>> >>
>> >> -Søren
>> >>
>> >> On 15 Aug 2019, at 23.37, Emmanuel Vadot <
>> >>
>> >> manu at bidouilliste.com> wrote:
>> >>
>> >>
>> >> On Thu, 15 Aug 2019 21:56:23 +0200
>> >> Søren Schmidt <soren.schmidt at gmail.com> wrote:
>> >>
>> >>
>> >> Well, I don?t care where you are from and what color you
>> >>
>> >> have :)
>> >>
>> >>
>> >> Now, if I update my stable12 sources to r350595 the
>> >>
>> >> bananapi breaks, if revert sys/gnu/dts it works again, go figure..
>> >>
>> >>
>> >> Reverting to what ? and how ?
>> >>
>> >> Because I've just test 12-stable and I have the problem
>> >>
>> >> that I've said
>> >>
>> >> in my previous mail so setting
>> >>
>> >> hw.regulator.disable_unused=0 is the
>> >>
>> >> work around.
>> >> The problem is in twsi not in the DTS so I'm curious how
>> >>
>> >> reverting
>> >>
>> >> only the dts fixes this problem.
>> >>
>> >> The r351099 fix is already like that in -stable, and not
>> >>
>> >> part of the problem.
>> >>
>> >>
>> >> -Søren
>> >>
>> >>
>> >> On 15 Aug 2019, at 21.03, Emmanuel Vadot <
>> >>
>> >> manu at bidouilliste.com> wrote:
>> >>
>> >>
>> >> On Thu, 15 Aug 2019 19:48:54 +0200
>> >> Søren Schmidt <soren.schmidt at gmail.com> wrote:
>> >>
>> >> Hi Mit!
>> >>
>> >> Right, I suspected that, 12-stable broke many embedded
>> >>
>> >> systems between r350592 and r350595 where all the latest and greatest
>> DTS
>> >> files was pulled in, I guess the same holds for -current.
>> >>
>> >>
>> >> -Søren
>> >>
>> >>
>> >> Mhm it's fun that you think that DTS import is the
>> >>
>> >> source of all your
>> >>
>> >> problems, I get it, it's easy to blame the French guy
>> >>
>> >> that bulk import
>> >>
>> >> the DTS, he surely don't know what he is doing.
>> >> Anyway, two problems were raised in this thread :
>> >>
>> >> 1) BananaPi (A20) doesn't boot
>> >> 2) Espressobin sd support is broken
>> >>
>> >> I've just looked at the BananaPi problem today, I've
>> >>
>> >> fixed a first
>> >>
>> >> problem in r351099.
>> >> The main problem is that when we disable the unused
>> >>
>> >> regulators we hang
>> >>
>> >> when trying to disabling ldo3. It's weird because the
>> >>
>> >> board doesn't use
>> >>
>> >> LDO3 (which is why we are disabling it, it's unused).
>> >>
>> >> The problem is in
>> >>
>> >> twsi I think as only leaving the part in axp209 that
>> >>
>> >> read the
>> >>
>> >> voltage register value make FreeBSD hang.
>> >> I'll have a proper look later, in the meantime you can
>> >>
>> >> set
>> >>
>> >> hw.regulator.disable_unused=0
>> >> in /boot/loader.conf
>> >> This isn't a DTS problem.
>> >>
>> >> For Espressobin I haven't found any thing related to SD
>> >>
>> >> in the DTS
>> >>
>> >> updates since the import, the only things slighly
>> >>
>> >> related are mmc and
>> >>
>> >> sdio.
>> >> So if someone could find which DTS import broke this I
>> >>
>> >> can have a look.
>> >>
>> >>
>> >>
>> >> On 15 Aug 2019, at 19.37, Mit Matelske <mit at pt.net>
>> >>
>> >> wrote:
>> >>
>> >>
>> >> Yeah, that was the problem. I went back to r348882
>> >>
>> >> and everything worked out of the box.
>> >>
>> >>
>> >> Thanks again for the hand holding!
>> >>
>> >> Mit
>> >>
>> >> From: "Søren Schmidt" <soren.schmidt at gmail.com
>> >>
>> >> <mailto:soren.schmidt at gmail.com>>
>> >>
>> >> To: "Mit Matelske" <mit at pt.net <mailto:mit at pt.net>>
>> >> Cc: "Marcin Wojtas" <mw at semihalf.com <mailto:
>> >>
>> >> mw at semihalf.com>>, "freebsd-arm" <freebsd-arm at freebsd.org <mailto:
>> >> freebsd-arm at freebsd.org>>
>> >>
>> >> Sent: Wednesday, August 14, 2019 1:33:04 PM
>> >> Subject: Re: Espressobin anyone ?
>> >>
>> >>
>> >> It might simply be broken in -current (again).
>> >>
>> >> I just updated my stable12 tree and I pulled in new
>> >>
>> >> .dts files for just about anything?
>> >>
>> >>
>> >> Needless to say, it broke the Espressobin?s SD
>> >>
>> >> support, it now fails just like yours..
>> >>
>> >>
>> >> It also broke allwinner builds and what not, so I?m
>> >>
>> >> just going back in time again :)
>> >>
>> >>
>> >> I wonder why there is this overwhelming need to
>> >>
>> >> import stuff that breaks things right, left and center in a -stable
>> >> branch ?
>> >>
>> >> That would have earned you the pointy hat back when?.
>> >>
>> >> -Søren
>> >>
>> >>
>> >> On 14 Aug 2019, at 18.01, Mit Matelske <mit at pt.net
>> >>
>> >> <mailto:mit at pt.net>> wrote:
>> >>
>> >>
>> >> Marcin-
>> >>
>> >> Sorry I didn't reply yesterday. I didn't have any
>> >>
>> >> luck with that either. I tried a lot of permutations.
>> >>
>> >>
>> >> Not saying for 100% it doesn't work, but I couldn't
>> >>
>> >> get it to work!
>> >>
>> >>
>> >> Mit
>> >>
>> >> From: "Marcin Wojtas" <mw at semihalf.com <mailto:
>> >>
>> >> mw at semihalf.com>>
>> >>
>> >> To: "Mit Matelske" <mit at pt.net <mailto:mit at pt.net>>
>> >> Cc: "Søren Schmidt" <soren.schmidt at gmail.com <mailto:
>> >>
>> >> soren.schmidt at gmail.com>>, "freebsd-arm" <freebsd-arm at freebsd.org
>> >> <mailto:freebsd-arm at freebsd.org>>
>> >>
>> >> Sent: Wednesday, August 14, 2019 10:41:04 AM
>> >> Subject: Re: Espressobin anyone ?
>> >>
>> >> Hi Mit,
>> >> Since you are using the latest 13-current, could you
>> >>
>> >> please try if passing rootdev via u-boot bootargs (please see my
>> previous
>> >> email) works for you without the loader modification?
>> >>
>> >>
>> >> Best regards,
>> >> Marcin
>> >>
>> >> ?r., 14 sie 2019 o 16:29 Mit Matelske <mit at pt.net
>> >>
>> >> <mailto:mit at pt.net>> napisa?(a):
>> >>
>> >> Soren-
>> >>
>> >> Thanks for the info. I'll grab a couple more SD
>> >>
>> >> cards at lunch. This one is a new Samsung 32GB. I'll also try putting
>> >> the
>> >> changes into 12 and see if that helps. I'm using the latest
>> 13-current.
>> >>
>> >>
>> >> Again, appreciate the hand holding!
>> >>
>> >> Mit
>> >>
>> >> From: "Søren Schmidt" <soren.schmidt at gmail.com
>> >>
>> >> <mailto:soren.schmidt at gmail.com>>
>> >>
>> >> To: "Mit Matelske" <mit at pt.net <mailto:mit at pt.net>>
>> >> Cc: "Marcin Wojtas" <mw at semihalf.com <mailto:
>> >>
>> >> mw at semihalf.com>>, "freebsd-arm" <freebsd-arm at freebsd.org <mailto:
>> >> freebsd-arm at freebsd.org>>
>> >>
>> >> Sent: Wednesday, August 14, 2019 2:30:31 AM
>> >> Subject: Re: Espressobin anyone ?
>> >>
>> >> Hi Mit
>> >> Hmm, from your earlier posted dmesgs it looks like
>> >>
>> >> the SD card is not getting detected properly..
>> >>
>> >>
>> >> I get this output:
>> >>
>> >> sdhci_xenon0: <Armada Xenon SDHCI controller> mem
>> >>
>> >> 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1
>> >>
>> >> mmc0: <MMC/SD bus> on sdhci_xenon0
>> >> ?snip?
>> >> mmcsd0: 16GB <SDHC SD16G 3.0 SN 01E28E67 MFG 07/2017
>> >>
>> >> by 39 PH> at mmc0 50.0MHz/4bit/65535-block
>> >>
>> >>
>> >> The problem you see was fixed for me by r348882,
>> >>
>> >> maybe it got broken later, I havn?t backported the later changes..
>> >>
>> >>
>> >> Have you tried another SD card ? I have found 2 of
>> >>
>> >> mine that the espressobin doesn?t like, but works fine with bananapi
>> and
>> >> friends...
>> >>
>> >>
>> >> -Søren
>> >>
>> >> On 13 Aug 2019, at 23.30, Mit Matelske <mit at pt.net
>> >>
>> >> <mailto:mit at pt.net>> wrote:
>> >>
>> >>
>> >> Soren-
>> >>
>> >> Thanks for the code snippet! That will fix one of
>> >>
>> >> the problems.
>> >>
>> >>
>> >> I still can't mount my filesystem, though. I think
>> >>
>> >> I'm doing something really simple, wrong. I believe I'm running the
>> >> latest
>> >> code and added some printfs to show the kernel setting the regulator:
>> >>
>> >>
>> >>
>> >> usbus1 on ehci0
>> >> syscon_generic4: <syscon> mem 0x5f800-0x5ffff on
>> >>
>> >> simplebus1
>> >>
>> >> sdhci_xenon0:
>> >>
>> >> regulator_get_by_ofw_property(vqmmc-supply) = 19
>> >>
>> >> sdhci_xenon0: vqmmc-supply regulator found
>> >> sdhci_xenon0: <Armada Xenon SDHCI controller> mem
>> >>
>> >> 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1
>> >>
>> >> ahci0: <AHCI SATA controller> mem 0xe0000-0xe0177 irq
>> >>
>> >> 26 on simplebus1
>> >>
>> >>
>> >>
>> >> Could there be a problem with how I am setting up my
>> >>
>> >> filesystem? I've tried both freebsd-ufs and freebsd as the type, with
>> no
>> >> luck. A gpart listing of my SD card:
>> >>
>> >>
>> >> root at fbl:~ # gpart list da3
>> >> Geom name: da3
>> >> modified: false
>> >> state: OK
>> >> fwheads: 255
>> >> fwsectors: 63
>> >> last: 62521335
>> >> first: 3
>> >> entries: 4
>> >> scheme: GPT
>> >> Providers:
>> >> 1. Name: da3p1
>> >> Mediasize: 41943040 (40M)
>> >> Sectorsize: 512
>> >> Stripesize: 0
>> >> Stripeoffset: 1536
>> >> Mode: r0w0e0
>> >> efimedia:
>> >>
>> >> HD(1,GPT,19894dc5-b8b2-11e9-871f-08008a0010e0,0x3,0x14000)
>> >>
>> >> rawuuid: 19894dc5-b8b2-11e9-871f-08008a0010e0
>> >> rawtype: c12a7328-f81f-11d2-ba4b-00a0c93ec93b
>> >> label: (null)
>> >> length: 41943040
>> >> offset: 1536
>> >> type: efi
>> >> index: 1
>> >> end: 81922
>> >> start: 3
>> >> 2. Name: da3p2
>> >> Mediasize: 31968979456 (30G)
>> >> Sectorsize: 512
>> >> Stripesize: 0
>> >> Stripeoffset: 41944576
>> >> Mode: r0w0e0
>> >> efimedia:
>> >>
>> >> HD(2,GPT,98786462-be30-11e9-ae6e-08008a0010e0,0x14003,0x3b8bff5)
>> >>
>> >> rawuuid: 98786462-be30-11e9-ae6e-08008a0010e0
>> >> rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b
>> >> label: (null)
>> >> length: 31968979456
>> >> offset: 41944576
>> >> type: freebsd-ufs
>> >> index: 2
>> >> end: 62521335
>> >> start: 81923
>> >> Consumers:
>> >> 1. Name: da3
>> >> Mediasize: 32010928128 (30G)
>> >> Sectorsize: 512
>> >> Mode: r0w0e0
>> >>
>> >> Thanks!!
>> >>
>> >> Mit
>> >>
>> >> From: "Søren Schmidt" <soren.schmidt at gmail.com
>> >>
>> >> <mailto:soren.schmidt at gmail.com>>
>> >>
>> >> To: "Marcin Wojtas" <mw at semihalf.com <mailto:
>> >>
>> >> mw at semihalf.com>>
>> >>
>> >> Cc: "Mit Matelske" <mit at pt.net <mailto:mit at pt.net>>,
>> >>
>> >> "freebsd-arm" <freebsd-arm at freebsd.org <mailto:
>> >> freebsd-arm at freebsd.org>>
>> >>
>> >> Sent: Tuesday, August 13, 2019 12:55:09 PM
>> >> Subject: Re: Espressobin anyone ?
>> >>
>> >> Hi
>> >> That doesn?t seen to work on the espressobin, or
>> >>
>> >> least I can?t get it to pick it up.
>> >>
>> >>
>> >> I use this patch as a workaround:
>> >>
>> >> Index: main.c
>> >>
>> >> ===================================================================
>> >>
>> >> --- main.c (revision 350496)
>> >> +++ main.c (working copy)
>> >> @@ -463,6 +462,13 @@
>> >> int rv;
>> >> char *rootdev;
>> >>
>> >> +#if defined(__aarch64__)
>> >> + /* SOS HACK in rootdev, at least Espressobin
>> >>
>> >> gets this wrong */
>> >>
>> >> + printf("Setting currdev hack\n");
>> >> + set_currdev("disk0p2");
>> >> + return (0);
>> >> +#endif
>> >> +
>> >> /*
>> >> * First choice: if rootdev is already set, use
>> >>
>> >> that, even if
>> >>
>> >> * it's wrong.
>> >>
>> >> Its not pretty but it does the job until I get time
>> >>
>> >> to look into why bootargs aren?t passed / won?t stick, probably
>> something
>> >> I
>> >> havn?t backported to my -stable12 sources yet...
>> >>
>> >>
>> >> -Søren
>> >>
>> >> On 13 Aug 2019, at 01.38, Marcin Wojtas <
>> >>
>> >> mw at semihalf.com <mailto:mw at semihalf.com>> wrote:
>> >>
>> >>
>> >> Hi,
>> >>
>> >> Not sure if it's what you are looking for, but in
>> >>
>> >> order to autoboot, I
>> >>
>> >> simply pass 'rootdev=diskXpY' in the bootargs
>> >>
>> >> variable. Here's example from
>> >>
>> >> A3720-DB (same should work on EspressoBin):
>> >>
>> >> Marvell>> set bootargs "rootdev=disk1p1";usb reset;
>> >>
>> >> fatload usb 0:1
>> >>
>> >> ${fdt_addr} armada-3720-db.dtb; fatload usb 0:1
>> >>
>> >> ${kernel_addr}
>> >>
>> >> boot/loader.efi; bootefi ${kernel_addr} ${fdt_addr}
>> >> resetting USB...
>> >> USB0: Register 2000104 NbrPorts 2
>> >> Starting the controller
>> >> USB XHCI 1.00
>> >> USB1: USB EHCI 1.00
>> >> - ______ ____ _____ _____
>> >> | ____| | _ \ / ____| __ \
>> >> | |___ _ __ ___ ___ | |_) | (___ | | | |
>> >> | ___| '__/ _ \/ _ \| _ < \___ \| | | |
>> >> | | | | | __/ __/| |_) |____) | |__| |
>> >> | | | | | | || | | |
>> >> |_| |_| \___|\___||____/|_____/|_____/
>> >> ```
>> >> `
>> >> ????????????Welcome to FreeBSD????????????? s`
>> >>
>> >> `.....---.......--.```
>> >>
>> >> -/
>> >> ? ? +o
>> >>
>> >> .--` /y:`
>> >>
>> >> +.
>> >> ? 1. Boot Multi user [Enter] ?
>> >>
>> >> yo`:. :o
>> >>
>> >> `+-
>> >> ? 2. Boot Single user ? y/
>> >>
>> >> -/` -o/
>> >>
>> >> ? 3. Escape to loader prompt ? .-
>> >> ::/sy+:.
>> >> ? 4. Reboot ? /
>> >>
>> >> `--
>> >>
>> >> /
>> >> ? ? `:
>> >> :`
>> >> ? Options: ? `:
>> >> :`
>> >> ? 5. Kernel: default/kernel (1 of 1) ? /
>> >> /
>> >> ? 6. Boot Options ? .-
>> >> -.
>> >> ? ? --
>> >>
>> >> -.
>> >>
>> >> ? ?
>> >>
>> >> `:` `:`
>> >>
>> >> ? ?
>> >>
>> >> .-- `--.
>> >>
>> >> ???????????????????????????????????????????
>> >>
>> >> .---.....----.
>> >>
>> >> Autoboot in 9 seconds, hit [Enter] to boot or any
>> >>
>> >> other key to stop
>> >>
>> >>
>> >> Loading kernel...
>> >> /boot/kernel/kernel text=0x95047c
>> >>
>> >> data=0x1919d0+0x84aa94
>> >>
>> >> syms=[0x8+0x13aaa8+0x8+0x12610d]
>> >> Loading configured modules...
>> >> can't find '/boot/entropy'
>> >> Using DTB provided by EFI at 0x8000000.
>> >> ---<<BOOT>>---
>> >> KDB: debugger backends: ddb
>> >> KDB: current backend: ddb
>> >> Copyright (c) 1992-2019 The FreeBSD Project.
>> >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989,
>> >>
>> >> 1991, 1992, 1993, 1994
>> >>
>> >> The Regents of the University of California. All
>> >>
>> >> rights reserved.
>> >>
>> >> FreeBSD is a registered trademark of The FreeBSD
>> >>
>> >> Foundation.
>> >>
>> >> FreeBSD 13.0-CURRENT
>> >>
>> >> 17a1fc80d57-c261519(upstream_master) GENERIC arm64
>> >>
>> >> FreeBSD clang version 8.0.0 (tags/RELEASE_800/final
>> >>
>> >> 356365) (based on LLVM
>> >>
>> >> 8.0.0)
>> >> WARNING: WITNESS option enabled, expect reduced
>> >>
>> >> performance.
>> >>
>> >> VT: init without driver.
>> >> Starting CPU 1 (1)
>> >> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
>> >> [...]
>> >>
>> >> Best regards,
>> >> Marcin
>> >>
>> >> pon., 12 sie 2019 o 23:14 Mit Matelske <mit at pt.net
>> >>
>> >> <mailto:mit at pt.net>> napisa?(a):
>> >>
>> >>
>> >>
>> >> Soren-
>> >>
>> >> Thanks for the quick response. I built this kernel
>> >>
>> >> with revision 350924.
>> >>
>> >> I'll dig into whats going on in the morning.
>> >>
>> >> Mind posting your diff for your loader.efi?
>> >>
>> >> Thanks again!
>> >>
>> >> Mit
>> >>
>> >>
>> >> ----- Original Message -----
>> >> From: "Søren Schmidt" <soren.schmidt at gmail.com
>> >>
>> >> <mailto:soren.schmidt at gmail.com>>
>> >>
>> >> To: "Mit Matelske" <mit at pt.net <mailto:mit at pt.net>>
>> >> Cc: "tscho" <johannes at t-beutel.com <mailto:
>> >>
>> >> johannes at t-beutel.com>>, "freebsd-arm" <
>> >>
>> >> freebsd-arm at freebsd.org <mailto:
>> >>
>> >> freebsd-arm at freebsd.org>>
>> >>
>> >> Sent: Monday, August 12, 2019 3:49:48 PM
>> >> Subject: Re: Espressobin anyone ?
>> >>
>> >> Hi
>> >>
>> >> Looks like your sources may be too old, you need to
>> >>
>> >> be at least at r348882
>> >>
>> >> to get the fix for the SD card VCC regulator.
>> >>
>> >> That change fixed it for me backported to 12-stable...
>> >>
>> >> The currdev problem still exists, I have it hardwired
>> >>
>> >> in my loader for
>> >>
>> >> aarch64 :)
>> >>
>> >> -Søren
>> >>
>> >>
>> >> On 12 Aug 2019, at 21.06, Mit Matelske <mit at pt.net
>> >>
>> >> <mailto:mit at pt.net>> wrote:
>> >>
>> >>
>> >> I'm having a couple little hiccups booting this board
>> >>
>> >> also. One has
>> >>
>> >> been commented on already, that I can't get the
>> >>
>> >> loader to automatically
>> >>
>> >> start loading the kernel on "disk0p2"...
>> >>
>> >> The second, is that the kernel can't find the SD card
>> >>
>> >> after booting so
>> >>
>> >> it can't mount the root filesystem. I'm using the
>> >>
>> >> dts/dtb and kernel from
>> >>
>> >> the 13-current branch.
>> >>
>> >> Thanks for any and all help. I haven't used u-boot
>> >>
>> >> in about decade.
>> >>
>> >> Spoiled by the x86 platform.
>> >>
>> >> Mit Matelske
>> >>
>> >>
>> >> ***U-boot environment:***
>> >>
>> >>
>> >> Marvell>> printenv
>> >> baudrate=115200
>> >> bootargs=console=ttyMV0,115200
>> >>
>> >> earlycon=ar3700_uart,0xd0012000
>> >>
>> >> root=/dev/mmcblk0p1 rw rootwait net.ifnames=0
>> >>
>> >> biosdevname=0
>> >>
>> >> bootcmd=mmc dev 0; fatload mmc 0:1 $kernel_addr
>> >>
>> >> $image_name;fatload mmc
>> >>
>> >> 0:1 $fdt_addr $fdt_name; bootefi $kernel_addr
>> >>
>> >> $fdt_addr
>> >>
>> >> bootdelay=2
>> >> bootmmc=mmc dev 0; fatload mmc 0:1 $kernel_addr
>> >>
>> >> $image_name;fatload mmc
>> >>
>> >> 0:1 $fdt_addr $fdt_name; bootefi $kernel_addr
>> >>
>> >> $fdt_addr
>> >>
>> >> console=console=ttyMV0,115200
>> >>
>> >> earlycon=ar3700_uart,0xd0012000
>> >>
>> >> eth1addr=00:51:82:11:22:01
>> >> eth2addr=00:51:82:11:22:02
>> >> eth3addr=00:51:82:11:22:03
>> >> ethact=neta at 30000
>> >> ethaddr=F0:AD:4E:09:6B:8F
>> >> ethprime=eth0
>> >> fdt_addr=0x4f00000
>> >> fdt_high=0xffffffffffffffff
>> >> fdt_name=efi/boot/armada-3720-espressobin.dtb
>> >> fdtcontroladdr=3f7161b8
>> >> gatewayip=10.4.50.254
>> >> get_images=tftpboot $kernel_addr $image_name;
>> >>
>> >> tftpboot $fdt_addr
>> >>
>> >> $fdt_name; run get_ramfs
>> >> get_ramfs=if test "${ramfs_name}" != "-"; then setenv
>> >>
>> >> ramfs_addr
>> >>
>> >> 0x8000000; tftpboot $ramfs_addr $ramfs_name; else
>> >>
>> >> setenv ramfs_addr -;fi
>> >>
>> >> hostname=marvell
>> >> image_name=efi/freebsd/loader.efi
>> >> initrd_addr=0xa00000
>> >> initrd_size=0x2000000
>> >> ipaddr=0.0.0.0
>> >> kernel_addr=0x5000000
>> >> loadaddr=0x5000000
>> >> netdev=eth0
>> >> netmask=255.255.255.0
>> >> ramfs_addr=0x8000000
>> >> ramfs_name=-
>> >> root=root=/dev/nfs rw
>> >> rootpath=/srv/nfs/
>> >> serverip=0.0.0.0
>> >> set_bootargs=setenv bootargs $console $root
>> >>
>> >> ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:none
>> >>
>> >> nfsroot=$serverip:$rootpath $extra_params
>> >> stderr=serial at 12000
>> >> stdin=serial at 12000
>> >> stdout=serial at 12000
>> >>
>> >>
>> >> ***Full boot logs:***
>> >>
>> >>
>> >> U-Boot 2017.03-armada-17.10.2-g14aeedc (Jun 01 2018 -
>> >>
>> >> 15:39:10 +0800)
>> >>
>> >>
>> >> Model: Marvell Armada 3720 Community Board ESPRESSOBin
>> >> CPU @ 1000 [MHz]
>> >> L2 @ 800 [MHz]
>> >> TClock @ 200 [MHz]
>> >> DDR @ 800 [MHz]
>> >> DRAM: 1 GiB
>> >> U-Boot DT blob at : 000000003f7161b8
>> >> Comphy-0: USB3 5 Gbps
>> >> Comphy-1: PEX0 2.5 Gbps
>> >> Comphy-2: SATA0 6 Gbps
>> >> SATA link 0 timeout.
>> >> AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA
>> >>
>> >> mode
>> >>
>> >> flags: ncq led only pmp fbss pio slum part sxs
>> >> PCIE-0: Link down
>> >> MMC: sdhci at d0000: 0, sdhci at d8000: 1
>> >> SF: Detected mx25u3235f with page size 256 Bytes,
>> >>
>> >> erase size 64 KiB,
>> >>
>> >> total 4 MiB
>> >> Net: eth0: neta at 30000 [PRIME]
>> >> Hit any key to stop autoboot: 0
>> >> switch to partitions #0, OK
>> >> mmc0 is current device
>> >> reading efi/freebsd/loader.efi
>> >> 603872 bytes read in 49 ms (11.8 MiB/s)
>> >> reading efi/boot/armada-3720-espressobin.dtb
>> >> 15946 bytes read in 17 ms (916 KiB/s)
>> >> ## Starting EFI application at 05000000 ...
>> >> Scanning disk sdhci at d0000.blk <mailto:sdhci at d0000.blk
>> >>
>> >> ...
>> >>
>> >> Card did not respond to voltage select!
>> >> mmc_init: -95, time 50
>> >> Found 1 disks
>> >> Consoles: EFI console
>> >> FreeBSD/arm64 EFI loader, Revision 1.1
>> >>
>> >> Command line arguments: loader.efi
>> >> EFI version: 2.05
>> >> EFI Firmware: Das U-boot (rev 0.00)
>> >> Console: efi (0)
>> >> Failed to find bootable partition
>> >> Startup error in /boot/lua/loader.lua: seconds
>> >> LUA ERROR: cannot open /boot/lua/loader.lua: invalid
>> >>
>> >> argument.
>> >>
>> >>
>> >> can't load 'kernel'
>> >>
>> >> Type '?' for a list of commands, 'help' for more
>> >>
>> >> detailed help.
>> >>
>> >> OK
>> >> OK set currdev=disk0p2
>> >> OK boot
>> >>
>> >> /boot/kernel/kernel text=0x97d6a0
>> >>
>> >> data=0x191b50+0x84ae94
>> >>
>> >> syms=[0x8+0x137dd8+0x8+0x126260]
>> >> Using DTB provided by EFI at 0x8000000.
>> >> ---<<BOOT>>---
>> >> KDB: debugger backends: ddb
>> >> KDB: current backend: ddb
>> >> Copyright (c) 1992-2019 The FreeBSD Project.
>> >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989,
>> >>
>> >> 1991, 1992, 1993, 1994
>> >>
>> >> The Regents of the University of California. All
>> >>
>> >> rights reserved.
>> >>
>> >> FreeBSD is a registered trademark of The FreeBSD
>> >>
>> >> Foundation.
>> >>
>> >> FreeBSD 13.0-CURRENT GENERIC arm64
>> >> FreeBSD clang version 6.0.1 (tags/RELEASE_601/final
>> >>
>> >> 335540) (based on
>> >>
>> >> LLVM 6.0.1)
>> >> WARNING: WITNESS option enabled, expect reduced
>> >>
>> >> performance.
>> >>
>> >> VT: init without driver.
>> >> Starting CPU 1 (1)
>> >> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
>> >> arc4random: WARNING: initial seeding bypassed the
>> >>
>> >> cryptographic random
>> >>
>> >> device because it was not yet seeded and the knob
>> >>
>> >> 'bypass_before_seeding'
>> >>
>> >> was enabled.
>> >> random: entropy device external interface
>> >> MAP 3e681000 mode 2 pages 1
>> >> MAP 3ffa6000 mode 2 pages 1
>> >> kbd0 at kbdmux0
>> >> ofwbus0: <Open Firmware Device Tree>
>> >> simplebus0: <Flattened device tree simple bus> on
>> >>
>> >> ofwbus0
>> >>
>> >> simplebus1: <Flattened device tree simple bus> on
>> >>
>> >> simplebus0
>> >>
>> >> simple_mfd0: <Simple MFD (Multi-Functions Device)> mem
>> >> 0x13800-0x138ff,0x13c00-0x13c1f on simplebus1
>> >> simple_mfd1: <Simple MFD (Multi-Functions Device)> mem
>> >> 0x18800-0x188ff,0x18c00-0x18c1f on simplebus1
>> >> psci0: <ARM Power State Co-ordination Interface
>> >>
>> >> Driver> on ofwbus0
>> >>
>> >> gic0: <ARM Generic Interrupt Controller v3.0> mem
>> >>
>> >>
>> >>
>> 0x1d00000-0x1d0ffff,0x1d40000-0x1d7ffff,0x1d80000-0x1d81fff,0x1d90000-0x1d91fff,0x1da0000-0x1dbffff
>> >>
>> >> irq 27 on simplebus1
>> >> gpio0: <Armada 37x0 North Bridge GPIO Controller> mem
>> >> 0x13800-0x138ff,0x13c00-0x13c1f irq
>> >>
>> >> 28,29,30,31,32,33,34,35,36,37,38,39 on
>> >>
>> >> simple_mfd0
>> >> gpio0: cannot allocate memory window
>> >> device_attach: gpio0 attach returned 6
>> >> gpio0: <Armada 37x0 South Bridge GPIO Controller> mem
>> >> 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 on
>> >>
>> >> simple_mfd1
>> >>
>> >> gpio0: cannot allocate memory window
>> >> device_attach: gpio0 attach returned 6
>> >> gpioregulator0: <GPIO controlled regulator> on ofwbus0
>> >> gpioregulator0: cannot get pin 0
>> >> gpioregulator0: cannot parse parameters
>> >> device_attach: gpioregulator0 attach returned 6
>> >> generic_timer0: <ARMv8 Generic Timer> irq 0,1,2,3 on
>> >>
>> >> ofwbus0
>> >>
>> >> Timecounter "ARM MPCore Timecounter" frequency
>> >>
>> >> 12500000 Hz quality 1000
>> >>
>> >> Event timer "ARM MPCore Eventtimer" frequency
>> >>
>> >> 12500000 Hz quality 1000
>> >>
>> >> gpio0: <Armada 37x0 North Bridge GPIO Controller> mem
>> >> 0x13800-0x138ff,0x13c00-0x13c1f irq
>> >>
>> >> 28,29,30,31,32,33,34,35,36,37,38,39 on
>> >>
>> >> simple_mfd0
>> >> gpio0: cannot allocate memory window
>> >> device_attach: gpio0 attach returned 6
>> >> gpio0: <Armada 37x0 South Bridge GPIO Controller> mem
>> >> 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 on
>> >>
>> >> simple_mfd1
>> >>
>> >> gpio0: cannot allocate memory window
>> >> device_attach: gpio0 attach returned 6
>> >> gpioregulator0: <GPIO controlled regulator> on ofwbus0
>> >> gpioregulator0: cannot get pin 0
>> >> gpioregulator0: cannot parse parameters
>> >> device_attach: gpioregulator0 attach returned 6
>> >> gpio0: <Armada 37x0 North Bridge GPIO Controller> mem
>> >> 0x13800-0x138ff,0x13c00-0x13c1f irq
>> >>
>> >> 28,29,30,31,32,33,34,35,36,37,38,39 on
>> >>
>> >> simple_mfd0
>> >> gpio0: cannot allocate memory window
>> >> device_attach: gpio0 attach returned 6
>> >> gpio0: <Armada 37x0 South Bridge GPIO Controller> mem
>> >> 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 on
>> >>
>> >> simple_mfd1
>> >>
>> >> gpio0: cannot allocate memory window
>> >> device_attach: gpio0 attach returned 6
>> >> gpioregulator0: <GPIO controlled regulator> on ofwbus0
>> >> gpioregulator0: cannot get pin 0
>> >> gpioregulator0: cannot parse parameters
>> >> device_attach: gpioregulator0 attach returned 6
>> >> gpio0: <Armada 37x0 North Bridge GPIO Controller> mem
>> >> 0x13800-0x138ff,0x13c00-0x13c1f irq
>> >>
>> >> 28,29,30,31,32,33,34,35,36,37,38,39 on
>> >>
>> >> simple_mfd0
>> >> gpio0: cannot allocate memory window
>> >> device_attach: gpio0 attach returned 6
>> >> gpio0: <Armada 37x0 South Bridge GPIO Controller> mem
>> >> 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 on
>> >>
>> >> simple_mfd1
>> >>
>> >> gpio0: cannot allocate memory window
>> >> device_attach: gpio0 attach returned 6
>> >> gpioregulator0: <GPIO controlled regulator> on ofwbus0
>> >> gpioregulator0: cannot get pin 0
>> >> gpioregulator0: cannot parse parameters
>> >> device_attach: gpioregulator0 attach returned 6
>> >> gpio0: <Armada 37x0 North Bridge GPIO Controller> mem
>> >> 0x13800-0x138ff,0x13c00-0x13c1f irq
>> >>
>> >> 28,29,30,31,32,33,34,35,36,37,38,39 on
>> >>
>> >> simple_mfd0
>> >> gpio0: cannot allocate memory window
>> >> device_attach: gpio0 attach returned 6
>> >> gpio0: <Armada 37x0 South Bridge GPIO Controller> mem
>> >> 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 on
>> >>
>> >> simple_mfd1
>> >>
>> >> gpio0: cannot allocate memory window
>> >> device_attach: gpio0 attach returned 6
>> >> gpioregulator0: <GPIO controlled regulator> on ofwbus0
>> >> gpioregulator0: cannot get pin 0
>> >> gpioregulator0: cannot parse parameters
>> >> device_attach: gpioregulator0 attach returned 6
>> >> cpulist0: <Open Firmware CPU Group> on ofwbus0
>> >> cpu0: <Open Firmware CPU> on cpulist0
>> >> cpu1: <Open Firmware CPU> on cpulist0
>> >> pmu0: <Performance Monitoring Unit> irq 4 on ofwbus0
>> >> syscon_generic0: <syscon> mem 0xd000-0xdfff on
>> >>
>> >> simplebus1
>> >>
>> >> syscon_generic1: <syscon> mem 0x11500-0x1153f on
>> >>
>> >> simplebus1
>> >>
>> >> uart0: <Marvell Armada 3700 UART> mem 0x12000-0x121ff
>> >>
>> >> irq 9,10,11 on
>> >>
>> >> simplebus1
>> >> uart0: console (115200,n,8,1)
>> >> gpio0: <Armada 37x0 North Bridge GPIO Controller> mem
>> >> 0x13800-0x138ff,0x13c00-0x13c1f irq
>> >>
>> >> 28,29,30,31,32,33,34,35,36,37,38,39 on
>> >>
>> >> simple_mfd0
>> >> gpio0: cannot allocate memory window
>> >> device_attach: gpio0 attach returned 6
>> >> syscon_generic2: <syscon> mem 0x14000-0x1405f on
>> >>
>> >> simplebus1
>> >>
>> >> gpio0: <Armada 37x0 South Bridge GPIO Controller> mem
>> >> 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 on
>> >>
>> >> simple_mfd1
>> >>
>> >> gpio0: cannot allocate memory window
>> >> device_attach: gpio0 attach returned 6
>> >> mvneta0: <NETA controller> mem 0x30000-0x33fff irq 14
>> >>
>> >> on simplebus1
>> >>
>> >> mvneta0: version is 10
>> >> mvneta0: Ethernet address: 00:a6:39:ca:e8:00
>> >> mdio0: <MDIO> on mvneta0
>> >> mdioproxy0: <MII/MDIO proxy, MDIO side> on mdio0
>> >> e6000sw0: <Marvell 88E6341> on mdio0
>> >> e6000sw0: multi-chip addressing mode (0x1)
>> >> e6000sw0: CPU port at 0
>> >> e6000sw0: fixed port at 0
>> >> e6000sw0: PHY at port 1
>> >> miibus0: <MII bus> on e6000sw0
>> >> e1000phy0: <Marvell 88E1000 Gigabit PHY> PHY 17 on
>> >>
>> >> miibus0
>> >>
>> >> e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX,
>> >>
>> >> 100baseTX-FDX,
>> >>
>> >> 1000baseT, 1000baseT-master, 1000baseT-FDX,
>> >>
>> >> 1000baseT-FDX-master, auto
>> >>
>> >> e6000sw0: PHY at port 2
>> >> miibus1: <MII bus> on e6000sw0
>> >> e1000phy1: <Marvell 88E1000 Gigabit PHY> PHY 18 on
>> >>
>> >> miibus1
>> >>
>> >> e1000phy1: none, 10baseT, 10baseT-FDX, 100baseTX,
>> >>
>> >> 100baseTX-FDX,
>> >>
>> >> 1000baseT, 1000baseT-master, 1000baseT-FDX,
>> >>
>> >> 1000baseT-FDX-master, auto
>> >>
>> >> e6000sw0: PHY at port 3
>> >> miibus2: <MII bus> on e6000sw0
>> >> e1000phy2: <Marvell 88E1000 Gigabit PHY> PHY 19 on
>> >>
>> >> miibus2
>> >>
>> >> e1000phy2: none, 10baseT, 10baseT-FDX, 100baseTX,
>> >>
>> >> 100baseTX-FDX,
>> >>
>> >> 1000baseT, 1000baseT-master, 1000baseT-FDX,
>> >>
>> >> 1000baseT-FDX-master, auto
>> >>
>> >> e6000sw0: switch is ready.
>> >> etherswitch0: <Switch controller> on e6000sw0
>> >> xhci0: <Generic USB 3.0 controller> mem
>> >>
>> >> 0x58000-0x5bfff irq 16 on
>> >>
>> >> simplebus1
>> >> xhci0: 32 bytes context size, 32-bit DMA
>> >> usbus0 on xhci0
>> >> syscon_generic3: <syscon> mem 0x5d800-0x5dfff on
>> >>
>> >> simplebus1
>> >>
>> >> ehci0: <Marvell Integrated USB 2.0 controller> mem
>> >>
>> >> 0x5e000-0x5efff irq
>> >>
>> >> 17 on simplebus1
>> >> usbus1: EHCI version 1.0
>> >> usbus1 on ehci0
>> >> syscon_generic4: <syscon> mem 0x5f800-0x5ffff on
>> >>
>> >> simplebus1
>> >>
>> >> sdhci_xenon0: <Armada Xenon SDHCI controller> mem
>> >> 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1
>> >> ahci0: <AHCI SATA controller> mem 0xe0000-0xe0177 irq
>> >>
>> >> 26 on simplebus1
>> >>
>> >> ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier
>> >>
>> >> supported with FBS
>> >>
>> >> ahcich0: <AHCI channel> at channel 0 on ahci0
>> >> device_attach: ahcich0 attach returned 6
>> >> gpioregulator0: <GPIO controlled regulator> on ofwbus0
>> >> gpioregulator0: cannot get pin 0
>> >> gpioregulator0: cannot parse parameters
>> >> device_attach: gpioregulator0 attach returned 6
>> >> cryptosoft0: <software crypto>
>> >> Timecounters tick every 1.000 msec
>> >> mvneta0: link state changed to UP
>> >> e6000sw0port1: link state changed to DOWN
>> >> e6000sw0port2: link state changed to DOWN
>> >> e6000sw0port3: link state changed to DOWN
>> >> usbus0: 5.0Gbps Super Speed USB v3.0
>> >> usbus1: 480Mbps High Speed USB v2.0
>> >> Release APs...done
>> >> CPU 0: ARM Cortex-A53 r0p4 affinity: 0
>> >> Instruction Set Attributes 0 =
>> >>
>> >> <CRC32,SHA2,SHA1,AES+PMULL>
>> >>
>> >> Trying to mount root from
>> >>
>> >> ufs:/dev/ufs/FreeBSD_Install [ro,noatime]...
>> >>
>> >> Instruction Set Attributes 1 = <>
>> >> Root mount waiting for: Processor Features 0 =
>> >> <GIC,AdvSIMD,Float,EL3 32,EL2 32,EL1 32,EL0 32>
>> >> usbus1 Processor Features 1 = <0>
>> >> usbus0 Memory Model Features 0 = <4k Granule,64k
>> >>
>> >> Granule,S/NS
>> >>
>> >> Mem,MixedEndian,16bit ASID,1TB PA>
>> >>
>> >> Memory Model Features 1 = <>
>> >> Memory Model Features 2 = <32b CCIDX,48b VA>
>> >> Debug Features 0 = <2 CTX Breakpoints,4
>> >>
>> >> Watchpoints,6
>> >>
>> >> Breakpoints,PMUv3,Debug v8>
>> >> Debug Features 1 = <0>
>> >> Auxiliary Features 0 = <0>
>> >> Auxiliary Features 1 = <0>
>> >> CPU 1: ARM Cortex-A53 r0p4 affinity: 1
>> >> WARNING: WITNESS option enabled, expect reduced
>> >>
>> >> performance.
>> >>
>> >> ugen0.1: <Generic XHCI root HUB> at usbus0
>> >> ugen1.1: <Marvell EHCI root HUB> at usbus1
>> >> uhub0 on usbus0
>> >> uhub1 on usbus1
>> >> uhub0: <Generic XHCI root HUB, class 9/0, rev
>> >>
>> >> 3.00/1.00, addr 1> on
>> >>
>> >> usbus0
>> >> uhub1: <Marvell EHCI root HUB, class 9/0, rev
>> >>
>> >> 2.00/1.00, addr 1> on
>> >>
>> >> usbus1
>> >> uhub0: 2 ports with 2 removable, self powered
>> >> uhub1: 1 port with 1 removable, self powered
>> >> mountroot: waiting for device
>> >>
>> >> /dev/ufs/FreeBSD_Install...
>> >>
>> >> Mounting from ufs:/dev/ufs/FreeBSD_Install failed
>> >>
>> >> with error 19.
>> >>
>> >>
>> >> Loader variables:
>> >> vfs.root.mountfrom=ufs:/dev/ufs/FreeBSD_Install
>> >> vfs.root.mountfrom.options=ro,noatime
>> >>
>> >> Manual root filesystem specification:
>> >> <fstype>:<device> [options]
>> >> Mount <device> using filesystem <fstype>
>> >> and with the specified (optional) option list.
>> >>
>> >> eg. ufs:/dev/da0s1a
>> >> zfs:zroot/ROOT/default
>> >> cd9660:/dev/cd0 ro
>> >> (which is equivalent to: mount -t cd9660 -o ro
>> >>
>> >> /dev/cd0 /)
>> >>
>> >>
>> >> ? List valid disk boot devices
>> >> . Yield 1 second (for background tasks)
>> >> <empty line> Abort manual input
>> >>
>> >> mountroot> ?
>> >>
>> >> List of GEOM managed disk devices:
>> >>
>> >>
>> >> mountroot>
>> >> _______________________________________________
>> >> freebsd-arm at freebsd.org <mailto:
>> >>
>> >> freebsd-arm at freebsd.org> mailing list
>> >>
>> >>
>> >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm <
>> >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm>
>> >>
>> >> To unsubscribe, send any mail to "
>> >>
>> >> freebsd-arm-unsubscribe at freebsd.org <mailto:
>> >> freebsd-arm-unsubscribe at freebsd.org>"
>> >>
>> >>
>> >> _______________________________________________
>> >> freebsd-arm at freebsd.org <mailto:
>> >>
>> >> freebsd-arm at freebsd.org> mailing list
>> >>
>> >>
>> >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm <
>> >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm>
>> >>
>> >> To unsubscribe, send any mail to "
>> >>
>> >> freebsd-arm-unsubscribe at freebsd.org <mailto:
>> >> freebsd-arm-unsubscribe at freebsd.org>"
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Emmanuel Vadot <manu at bidouilliste.com> <
>> >>
>> >> manu at freebsd.org>
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Emmanuel Vadot <manu at bidouilliste.com> <manu at freebsd.org>
>> >>
>> >>
>> >>
>> >> --
>> >> Emmanuel Vadot <manu at bidouilliste.com> <manu at freebsd.org>
>> >> _______________________________________________
>> >> freebsd-arm at freebsd.org mailing list
>> >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
>> >> To unsubscribe, send any mail to "
>> >>
>> >> freebsd-arm-unsubscribe at freebsd.org"
>> >>
>> >>
>> >>
>> >> --
>> >> Emmanuel Vadot <manu at bidouilliste.com> <manu at freebsd.org>
>> >> _______________________________________________
>> >> freebsd-arm at freebsd.org mailing list
>> >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
>> >> To unsubscribe, send any mail to "
>> >>
>> >> freebsd-arm-unsubscribe at freebsd.org"
>> >>
>> >>
>> >>
>> >> --
>> >> Emmanuel Vadot <manu at bidouilliste.com> <manu at freebsd.org>
>> >> _______________________________________________
>> >> freebsd-arm at freebsd.org mailing list
>> >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
>> >> To unsubscribe, send any mail to "
>> >>
>> >> freebsd-arm-unsubscribe at freebsd.org"
>> >>
>> >>
>> >>
>> >> --
>> >> Emmanuel Vadot <manu at bidouilliste.com <mailto:
>> >>
>> >> manu at bidouilliste.com>> <manu at freebsd.org <mailto:manu at freebsd.org>>
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Emmanuel Vadot <manu at bidouilliste.com <mailto:
>> >>
>> >> manu at bidouilliste.com>> <manu at freebsd.org <mailto:manu at freebsd.org>>
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Emmanuel Vadot <manu at bidouilliste.com> <manu at freebsd.org>
>> >> _______________________________________________
>> >> freebsd-arm at freebsd.org mailing list
>> >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
>> >> To unsubscribe, send any mail to "
>> >> freebsd-arm-unsubscribe at freebsd.org"
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> freebsd-arm at freebsd.org mailing list
>> >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
>> >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>> >>
>> >>
>> >>
>> _______________________________________________
>> freebsd-arm at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>> ------------------------------
>>
>>
>
>
>
More information about the freebsd-arm
mailing list