Date: Sat, 17 Aug 2019 21:08:22 +0200 From: Emmanuel Vadot <manu@bidouilliste.com> To: =?ISO-8859-1?Q?S=F8ren?= Schmidt <soren.schmidt@gmail.com> Cc: freebsd-arm <freebsd-arm@freebsd.org>, Marcin Wojtas <mw@semihalf.com> Subject: Re: Espressobin anyone ? Message-ID: <20190817210822.8920656bad0855b554883cf2@bidouilliste.com> In-Reply-To: <9749945A-FDAD-47E0-947A-FA62138C2F83@gmail.com> References: <E73AFF5D-43CA-41A7-BDBA-ADEF2D342479@deepcore.dk> <CAPv3WKeCRWy65LPeeJiisPtaz=LePpVYLDAi2cj%2B2TQR=r09YA@mail.gmail.com> <1547777156.662147.1565798461515.JavaMail.zimbra@perftech.com> <0E42E605-477E-4E65-810E-BD3A8CDE2C80@gmail.com> <973015183.1067498.1565890674099.JavaMail.zimbra@perftech.com> <BD3710D7-EB87-4BD0-9CDE-E55B9412ED87@gmail.com> <20190815210311.1035f64b003e2bc85fa47ca8@bidouilliste.com> <B3AFA483-4BE4-4BC6-BCC1-4BD58A8E554C@gmail.com> <20190815233755.893e485f40ccacd79cdb3d96@bidouilliste.com> <78F5029D-A0F5-42F2-8191-07EB3A68C87B@gmail.com> <20190816152454.4e54ab5c276a543c120d909a@bidouilliste.com> <20190816171037.f808fbaba2369f179de36397@bidouilliste.com> <20190816191230.508f07f27fac21479a6716d9@bidouilliste.com> <20190816225826.ce31e8f968021944f64cb67c@bidouilliste.com> <AB07E67F-5A5E-4B5A-9D2C-6EDD4E9B478A@gmail.com> <20190817153053.5592b15b8a42982fda0fc123@bidouilliste.com> <9749945A-FDAD-47E0-947A-FA62138C2F83@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 17 Aug 2019 17:14:36 +0200 S=F8ren Schmidt <soren.schmidt@gmail.com> wrote: > HI >=20 > Well, I have a whole forrest of tree?s here, but the error posted here wa= s on a clean checkout. >=20 > Anyhow, with the latest changes to -stable and the two RF_SHAREABLE patch= es 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. >=20 > -S=F8ren >=20 > PS: given up on bottom & inline popsting, top posting is all the rage now= (yeah I miss elm etc :) ) >=20 > > On 17 Aug 2019, at 15.30, Emmanuel Vadot <manu@bidouilliste.com> wrote: > >=20 > > On Sat, 17 Aug 2019 11:07:22 +0200 > > S=F8ren Schmidt <soren.schmidt@gmail.com <mailto:soren.schmidt@gmail.co= m>> wrote: > >=20 > >> Hi Emmunuel > >>=20 > >> Yes the 3720 gpio driver I already back ported long ago, its needed, I= ?m happy its now part of std stable 12! > >=20 > > Would have been nice of you to say that you were not running a clean > > tree. > >=20 > >> My issue seems to be the inclusion of the phy_usb driver, if I leave t= hat out, I?m back to normal.. > >=20 > > What make you think this is this driver ? What works/doesn't work > > with it ? could you provide logs. > >=20 > >> I?ll have have another go at the latest -stable sources during the wee= kend and see how it goes. > >>=20 > >> Thanks for looking into this, with a little cooperation we?ll get this= solved for the greater good.. > >>=20 > >> -S=F8ren > >=20 > > P.S. Please stop top posting, it's really hard to read the conversation > >=20 > >>> On 16 Aug 2019, at 22.58, Emmanuel Vadot <manu@bidouilliste.com> wrot= e: > >>>=20 > >>> On Fri, 16 Aug 2019 19:12:30 +0200 > >>> Emmanuel Vadot <manu@bidouilliste.com <mailto:manu@bidouilliste.com>>= wrote: > >>>=20 > >>>> On Fri, 16 Aug 2019 17:10:37 +0200 > >>>> Emmanuel Vadot <manu@bidouilliste.com> wrote: > >>>>=20 > >>>>> On Fri, 16 Aug 2019 15:24:54 +0200 > >>>>> Emmanuel Vadot <manu@bidouilliste.com> wrote: > >>>>>=20 > >>>>>> On Fri, 16 Aug 2019 07:28:59 +0200 > >>>>>> S=F8ren Schmidt <soren.schmidt@gmail.com> wrote: > >>>>>>=20 > >>>>>>> Hi > >>>>>>>=20 > >>>>>>> Very simple, reverting sys/gnu/dts to what was before 350595 (act= ually 350592). > >>>>>>> Thats what we have svn for ? > >>>>>>=20 > >>>>>> If I asked how it was to have the svn command that you used, I wan= t to > >>>>>> make sure that you didn't revert anything else, like do you have > >>>>>> r350596 and r350628 ? > >>>>>>=20 > >>>>>>> That does make my bananapi work again, no other changes just a re= compiled kernel. > >>>>>>=20 > >>>>>> That + copying the dtb to the fat32 partition ? > >>>>>>=20 > >>>>>> Can you post the dtb somewhere. > >>>>>>=20 > >>>>>>> However it does not bring the Espressobin back to life, thats som= ething in one of the ~30 other files that changed between those two revisio= ns. > >>>>>>=20 > >>>>>> 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 ? > >>>>>=20 > >>>>> 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 atta= ches > >>>>> 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. > >>>>>=20 > >>>>> 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. > >>>>=20 > >>>> So this wasn't the problem but I've found it, see r351129 and r351130 > >>>>=20 > >>>> SD card now work again in HEAD, I'll have a look at stable later next > >>>> week. > >>>=20 > >>> 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 > >>>=20 > >>>>>>> -S=F8ren > >>>>>>>=20 > >>>>>>>> On 15 Aug 2019, at 23.37, Emmanuel Vadot <manu@bidouilliste.com>= wrote: > >>>>>>>>=20 > >>>>>>>> On Thu, 15 Aug 2019 21:56:23 +0200 > >>>>>>>> S=F8ren Schmidt <soren.schmidt@gmail.com> wrote: > >>>>>>>>=20 > >>>>>>>>>=20 > >>>>>>>>> Well, I don?t care where you are from and what color you have :) > >>>>>>>>>=20 > >>>>>>>>> Now, if I update my stable12 sources to r350595 the bananapi br= eaks, if revert sys/gnu/dts it works again, go figure.. > >>>>>>>>=20 > >>>>>>>> Reverting to what ? and how ? > >>>>>>>>=20 > >>>>>>>> Because I've just test 12-stable and I have the problem that I'v= e said > >>>>>>>> in my previous mail so setting hw.regulator.disable_unused=3D0 i= s the > >>>>>>>> work around. > >>>>>>>> The problem is in twsi not in the DTS so I'm curious how reverti= ng > >>>>>>>> only the dts fixes this problem. > >>>>>>>>=20 > >>>>>>>>> The r351099 fix is already like that in -stable, and not part o= f the problem. > >>>>>>>>>=20 > >>>>>>>>> -S=F8ren > >>>>>>>>=20 > >>>>>>>>>> On 15 Aug 2019, at 21.03, Emmanuel Vadot <manu@bidouilliste.co= m> wrote: > >>>>>>>>>>=20 > >>>>>>>>>> On Thu, 15 Aug 2019 19:48:54 +0200 > >>>>>>>>>> S=F8ren Schmidt <soren.schmidt@gmail.com> wrote: > >>>>>>>>>>=20 > >>>>>>>>>>> Hi Mit! > >>>>>>>>>>>=20 > >>>>>>>>>>> Right, I suspected that, 12-stable broke many embedded system= s between r350592 and r350595 where all the latest and greatest DTS files w= as pulled in, I guess the same holds for -current. > >>>>>>>>>>>=20 > >>>>>>>>>>> -S=F8ren > >>>>>>>>>>=20 > >>>>>>>>>> Mhm it's fun that you think that DTS import is the source of a= ll your > >>>>>>>>>> problems, I get it, it's easy to blame the French guy that bul= k import > >>>>>>>>>> the DTS, he surely don't know what he is doing. > >>>>>>>>>> Anyway, two problems were raised in this thread : > >>>>>>>>>>=20 > >>>>>>>>>> 1) BananaPi (A20) doesn't boot > >>>>>>>>>> 2) Espressobin sd support is broken > >>>>>>>>>>=20 > >>>>>>>>>> I've just looked at the BananaPi problem today, I've fixed a f= irst > >>>>>>>>>> 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 do= esn't use > >>>>>>>>>> LDO3 (which is why we are disabling it, it's unused). The prob= lem 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. > >>>>>>>>>>=20 > >>>>>>>>>> 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 hav= e a look. > >>>>>>>>>>=20 > >>>>>>>>>>>=20 > >>>>>>>>>>>> On 15 Aug 2019, at 19.37, Mit Matelske <mit@pt.net> wrote: > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Yeah, that was the problem. I went back to r348882 and ever= ything worked out of the box. > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Thanks again for the hand holding! > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Mit > >>>>>>>>>>>>=20 > >>>>>>>>>>>> From: "S=F8ren Schmidt" <soren.schmidt@gmail.com <mailto:sor= en.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 ? > >>>>>>>>>>>>=20 > >>>>>>>>>>>>=20 > >>>>>>>>>>>> It might simply be broken in -current (again). > >>>>>>>>>>>>=20 > >>>>>>>>>>>> I just updated my stable12 tree and I pulled in new .dts fil= es for just about anything? > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Needless to say, it broke the Espressobin?s SD support, it n= ow fails just like yours.. > >>>>>>>>>>>>=20 > >>>>>>>>>>>> It also broke allwinner builds and what not, so I?m just goi= ng back in time again :) > >>>>>>>>>>>>=20 > >>>>>>>>>>>> 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?. > >>>>>>>>>>>>=20 > >>>>>>>>>>>> -S=F8ren > >>>>>>>>>>>>=20 > >>>>>>>>>>>>=20 > >>>>>>>>>>>> On 14 Aug 2019, at 18.01, Mit Matelske <mit@pt.net <mailto:m= it@pt.net>> wrote: > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Marcin- > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Sorry I didn't reply yesterday. I didn't have any luck with= that either. I tried a lot of permutations. > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Not saying for 100% it doesn't work, but I couldn't get it t= o work! > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Mit > >>>>>>>>>>>>=20 > >>>>>>>>>>>> From: "Marcin Wojtas" <mw@semihalf.com <mailto:mw@semihalf.c= om>> > >>>>>>>>>>>> To: "Mit Matelske" <mit@pt.net <mailto:mit@pt.net>> > >>>>>>>>>>>> Cc: "S=F8ren Schmidt" <soren.schmidt@gmail.com <mailto:soren= .schmidt@gmail.com>>, "freebsd-arm" <freebsd-arm@freebsd.org <mailto:freebs= d-arm@freebsd.org>> > >>>>>>>>>>>> Sent: Wednesday, August 14, 2019 10:41:04 AM > >>>>>>>>>>>> Subject: Re: Espressobin anyone ? > >>>>>>>>>>>>=20 > >>>>>>>>>>>> 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) w= orks for you without the loader modification? > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Best regards, > >>>>>>>>>>>> Marcin > >>>>>>>>>>>>=20 > >>>>>>>>>>>> ?r., 14 sie 2019 o 16:29 Mit Matelske <mit@pt.net <mailto:mi= t@pt.net>> napisa?(a): > >>>>>>>>>>>> Soren- > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Thanks for the info. I'll grab a couple more SD cards at lu= nch. This one is a new Samsung 32GB. I'll also try putting the changes in= to 12 and see if that helps. I'm using the latest 13-current. > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Again, appreciate the hand holding! > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Mit > >>>>>>>>>>>>=20 > >>>>>>>>>>>> From: "S=F8ren Schmidt" <soren.schmidt@gmail.com <mailto:sor= en.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 ? > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Hi Mit > >>>>>>>>>>>> Hmm, from your earlier posted dmesgs it looks like the SD ca= rd is not getting detected properly.. > >>>>>>>>>>>>=20 > >>>>>>>>>>>> I get this output: > >>>>>>>>>>>>=20 > >>>>>>>>>>>> sdhci_xenon0: <Armada Xenon SDHCI controller> mem 0xd0000-0x= d02ff,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 P= H> at mmc0 50.0MHz/4bit/65535-block > >>>>>>>>>>>>=20 > >>>>>>>>>>>> The problem you see was fixed for me by r348882, maybe it go= t broken later, I havn?t backported the later changes.. > >>>>>>>>>>>>=20 > >>>>>>>>>>>> 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... > >>>>>>>>>>>>=20 > >>>>>>>>>>>> -S=F8ren > >>>>>>>>>>>>=20 > >>>>>>>>>>>> On 13 Aug 2019, at 23.30, Mit Matelske <mit@pt.net <mailto:m= it@pt.net>> wrote: > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Soren- > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Thanks for the code snippet! That will fix one of the probl= ems. > >>>>>>>>>>>>=20 > >>>>>>>>>>>> I still can't mount my filesystem, though. I think I'm doin= g something really simple, wrong. I believe I'm running the latest code an= d added some printfs to show the kernel setting the regulator: > >>>>>>>>>>>>=20 > >>>>>>>>>>>>=20 > >>>>>>>>>>>> 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-0x= d02ff,0x1e808-0x1e80b irq 24 on simplebus1 > >>>>>>>>>>>> ahci0: <AHCI SATA controller> mem 0xe0000-0xe0177 irq 26 on = simplebus1 > >>>>>>>>>>>>=20 > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Could there be a problem with how I am setting up my filesys= tem? I've tried both freebsd-ufs and freebsd as the type, with no luck. A = gpart listing of my SD card: > >>>>>>>>>>>>=20 > >>>>>>>>>>>> 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,0x14= 003,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 > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Thanks!! > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Mit > >>>>>>>>>>>>=20 > >>>>>>>>>>>> From: "S=F8ren Schmidt" <soren.schmidt@gmail.com <mailto:sor= en.schmidt@gmail.com>> > >>>>>>>>>>>> To: "Marcin Wojtas" <mw@semihalf.com <mailto:mw@semihalf.com= >> > >>>>>>>>>>>> Cc: "Mit Matelske" <mit@pt.net <mailto:mit@pt.net>>, "freebs= d-arm" <freebsd-arm@freebsd.org <mailto:freebsd-arm@freebsd.org>> > >>>>>>>>>>>> Sent: Tuesday, August 13, 2019 12:55:09 PM > >>>>>>>>>>>> Subject: Re: Espressobin anyone ? > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Hi > >>>>>>>>>>>> That doesn?t seen to work on the espressobin, or least I can= ?t get it to pick it up. > >>>>>>>>>>>>=20 > >>>>>>>>>>>> I use this patch as a workaround: > >>>>>>>>>>>>=20 > >>>>>>>>>>>> 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; > >>>>>>>>>>>>=20 > >>>>>>>>>>>> +#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. > >>>>>>>>>>>>=20 > >>>>>>>>>>>> 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... > >>>>>>>>>>>>=20 > >>>>>>>>>>>> -S=F8ren > >>>>>>>>>>>>=20 > >>>>>>>>>>>> On 13 Aug 2019, at 01.38, Marcin Wojtas <mw@semihalf.com <ma= ilto:mw@semihalf.com>> wrote: > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Hi, > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Not sure if it's what you are looking for, but in order to a= utoboot, I > >>>>>>>>>>>> simply pass 'rootdev=3DdiskXpY' in the bootargs variable. He= re's example from > >>>>>>>>>>>> A3720-DB (same should work on EspressoBin): > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Marvell>> set bootargs "rootdev=3Ddisk1p1";usb reset; fatloa= d usb 0:1 > >>>>>>>>>>>> ${fdt_addr} armada-3720-db.dtb; fatload usb 0:1 ${kernel_add= r} > >>>>>>>>>>>> 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 > >>>>>>>>>>>>=20 > >>>>>>>>>>>> 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 rese= rved. > >>>>>>>>>>>> FreeBSD is a registered trademark of The FreeBSD Foundation. > >>>>>>>>>>>> FreeBSD 13.0-CURRENT 17a1fc80d57-c261519(upstream_master) GE= NERIC 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 > >>>>>>>>>>>> [...] > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Best regards, > >>>>>>>>>>>> Marcin > >>>>>>>>>>>>=20 > >>>>>>>>>>>> pon., 12 sie 2019 o 23:14 Mit Matelske <mit@pt.net <mailto:m= it@pt.net>> napisa?(a): > >>>>>>>>>>>>=20 > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Soren- > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Thanks for the quick response. I built this kernel with rev= ision 350924. > >>>>>>>>>>>> I'll dig into whats going on in the morning. > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Mind posting your diff for your loader.efi? > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Thanks again! > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Mit > >>>>>>>>>>>>=20 > >>>>>>>>>>>>=20 > >>>>>>>>>>>> ----- Original Message ----- > >>>>>>>>>>>> From: "S=F8ren Schmidt" <soren.schmidt@gmail.com <mailto:sor= en.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 ? > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Hi > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Looks like your sources may be too old, you need to be at le= ast at r348882 > >>>>>>>>>>>> to get the fix for the SD card VCC regulator. > >>>>>>>>>>>>=20 > >>>>>>>>>>>> That change fixed it for me backported to 12-stable... > >>>>>>>>>>>>=20 > >>>>>>>>>>>> The currdev problem still exists, I have it hardwired in my = loader for > >>>>>>>>>>>> aarch64 :) > >>>>>>>>>>>>=20 > >>>>>>>>>>>> -S=F8ren > >>>>>>>>>>>>=20 > >>>>>>>>>>>>=20 > >>>>>>>>>>>> On 12 Aug 2019, at 21.06, Mit Matelske <mit@pt.net <mailto:m= it@pt.net>> wrote: > >>>>>>>>>>>>=20 > >>>>>>>>>>>> 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 au= tomatically > >>>>>>>>>>>> start loading the kernel on "disk0p2"... > >>>>>>>>>>>>=20 > >>>>>>>>>>>> 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 a= nd kernel from > >>>>>>>>>>>> the 13-current branch. > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Thanks for any and all help. I haven't used u-boot in about= decade. > >>>>>>>>>>>> Spoiled by the x86 platform. > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Mit Matelske > >>>>>>>>>>>>=20 > >>>>>>>>>>>>=20 > >>>>>>>>>>>> ***U-boot environment:*** > >>>>>>>>>>>>=20 > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Marvell>> printenv > >>>>>>>>>>>> baudrate=3D115200 > >>>>>>>>>>>> bootargs=3Dconsole=3DttyMV0,115200 earlycon=3Dar3700_uart,0x= d0012000 > >>>>>>>>>>>> root=3D/dev/mmcblk0p1 rw rootwait net.ifnames=3D0 biosdevnam= e=3D0 > >>>>>>>>>>>> bootcmd=3Dmmc dev 0; fatload mmc 0:1 $kernel_addr $image_nam= e;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_nam= e;fatload mmc > >>>>>>>>>>>> 0:1 $fdt_addr $fdt_name; bootefi $kernel_addr $fdt_addr > >>>>>>>>>>>> console=3Dconsole=3DttyMV0,115200 earlycon=3Dar3700_uart,0xd= 0012000 > >>>>>>>>>>>> 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 $fd= t_addr > >>>>>>>>>>>> $fdt_name; run get_ramfs > >>>>>>>>>>>> get_ramfs=3Dif test "${ramfs_name}" !=3D "-"; then setenv ra= mfs_addr > >>>>>>>>>>>> 0x8000000; tftpboot $ramfs_addr $ramfs_name; else setenv ram= fs_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 > >>>>>>>>>>>>=20 > >>>>>>>>>>>>=20 > >>>>>>>>>>>> ***Full boot logs:*** > >>>>>>>>>>>>=20 > >>>>>>>>>>>>=20 > >>>>>>>>>>>> U-Boot 2017.03-armada-17.10.2-g14aeedc (Jun 01 2018 - 15:39:= 10 +0800) > >>>>>>>>>>>>=20 > >>>>>>>>>>>> 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 > >>>>>>>>>>>>=20 > >>>>>>>>>>>> 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 argumen= t. > >>>>>>>>>>>>=20 > >>>>>>>>>>>> can't load 'kernel' > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Type '?' for a list of commands, 'help' for more detailed he= lp. > >>>>>>>>>>>> OK > >>>>>>>>>>>> OK set currdev=3Ddisk0p2 > >>>>>>>>>>>> OK boot > >>>>>>>>>>>>=20 > >>>>>>>>>>>> /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 re= served. > >>>>>>>>>>>> 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 cryptograp= hic random > >>>>>>>>>>>> device because it was not yet seeded and the knob 'bypass_be= fore_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 o= fwbus0 > >>>>>>>>>>>> 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 q= uality 1000 > >>>>>>>>>>>> Event timer "ARM MPCore Eventtimer" frequency 12500000 Hz qu= ality 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 sim= plebus1 > >>>>>>>>>>>> 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-ma= ster, 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-ma= ster, 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-ma= ster, 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-0= x5efff 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 suppor= ted 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,n= oatime]... > >>>>>>>>>>>> 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 Gran= ule,S/NS > >>>>>>>>>>>> Mem,MixedEndian,16bit ASID,1TB PA> > >>>>>>>>>>>>=20 > >>>>>>>>>>>> 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, add= r 1> on > >>>>>>>>>>>> usbus0 > >>>>>>>>>>>> uhub1: <Marvell EHCI root HUB, class 9/0, rev 2.00/1.00, add= r 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. > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Loader variables: > >>>>>>>>>>>> vfs.root.mountfrom=3Dufs:/dev/ufs/FreeBSD_Install > >>>>>>>>>>>> vfs.root.mountfrom.options=3Dro,noatime > >>>>>>>>>>>>=20 > >>>>>>>>>>>> Manual root filesystem specification: > >>>>>>>>>>>> <fstype>:<device> [options] > >>>>>>>>>>>> Mount <device> using filesystem <fstype> > >>>>>>>>>>>> and with the specified (optional) option list. > >>>>>>>>>>>>=20 > >>>>>>>>>>>> eg. ufs:/dev/da0s1a > >>>>>>>>>>>> zfs:zroot/ROOT/default > >>>>>>>>>>>> cd9660:/dev/cd0 ro > >>>>>>>>>>>> (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 = /) > >>>>>>>>>>>>=20 > >>>>>>>>>>>> ? List valid disk boot devices > >>>>>>>>>>>> . Yield 1 second (for background tasks) > >>>>>>>>>>>> <empty line> Abort manual input > >>>>>>>>>>>>=20 > >>>>>>>>>>>> mountroot> ? > >>>>>>>>>>>>=20 > >>>>>>>>>>>> List of GEOM managed disk devices: > >>>>>>>>>>>>=20 > >>>>>>>>>>>>=20 > >>>>>>>>>>>> mountroot> > >>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>> freebsd-arm@freebsd.org <mailto:freebsd-arm@freebsd.org> mai= ling list > >>>>>>>>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm <http= s://lists.freebsd.org/mailman/listinfo/freebsd-arm> > >>>>>>>>>>>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@fr= eebsd.org <mailto:freebsd-arm-unsubscribe@freebsd.org>" > >>>>>>>>>>>>=20 > >>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>> freebsd-arm@freebsd.org <mailto:freebsd-arm@freebsd.org> mai= ling list > >>>>>>>>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm <http= s://lists.freebsd.org/mailman/listinfo/freebsd-arm> > >>>>>>>>>>>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@fr= eebsd.org <mailto:freebsd-arm-unsubscribe@freebsd.org>" > >>>>>>>>>>>=20 > >>>>>>>>>>=20 > >>>>>>>>>>=20 > >>>>>>>>>> -- > >>>>>>>>>> Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org> > >>>>>>>>>=20 > >>>>>>>>=20 > >>>>>>>>=20 > >>>>>>>> -- > >>>>>>>> Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org> > >>>>>>=20 > >>>>>>=20 > >>>>>> -- > >>>>>> 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" > >>>>>=20 > >>>>>=20 > >>>>> -- > >>>>> 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.o= rg" > >>>>=20 > >>>>=20 > >>>> -- > >>>> 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.or= g" > >>>=20 > >>>=20 > >>> -- > >>> Emmanuel Vadot <manu@bidouilliste.com <mailto:manu@bidouilliste.com>>= <manu@freebsd.org <mailto:manu@freebsd.org>> > >>=20 > >=20 > >=20 > > -- > > Emmanuel Vadot <manu@bidouilliste.com <mailto:manu@bidouilliste.com>> <= manu@freebsd.org <mailto:manu@freebsd.org>> >=20 --=20 Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190817210822.8920656bad0855b554883cf2>