Date: Fri, 16 Aug 2019 07:28:59 +0200 From: =?utf-8?Q?S=C3=B8ren_Schmidt?= <soren.schmidt@gmail.com> To: Emmanuel Vadot <manu@bidouilliste.com> Cc: Mit Matelske <mit@pt.net>, freebsd-arm <freebsd-arm@freebsd.org>, Marcin Wojtas <mw@semihalf.com> Subject: Re: Espressobin anyone ? Message-ID: <78F5029D-A0F5-42F2-8191-07EB3A68C87B@gmail.com> In-Reply-To: <20190815233755.893e485f40ccacd79cdb3d96@bidouilliste.com> References: <E73AFF5D-43CA-41A7-BDBA-ADEF2D342479@deepcore.dk> <45CD194B-8533-42B7-9FE8-B2C8C03F4422@gmail.com> <1021311926.304550.1565731831094.JavaMail.zimbra@perftech.com> <4AE7C7A2-0BFB-4093-AE19-6AAC8F44FF25@gmail.com> <917479365.631712.1565792953255.JavaMail.zimbra@perftech.com> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi
Very simple, reverting sys/gnu/dts to what was before 350595 (actually 35059=
2).
Thats what we have svn for =F0=9F=98=80
That does make my bananapi work again, no other changes just a recompiled ke=
rnel.
However it does not bring the Espressobin back to life, thats something in o=
ne of the ~30 other files that changed between those two revisions.
-S=C3=B8ren
> On 15 Aug 2019, at 23.37, Emmanuel Vadot <manu@bidouilliste.com> wrote:
>=20
> On Thu, 15 Aug 2019 21:56:23 +0200
> S=C3=B8ren 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 breaks, if r=
evert 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'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.
>=20
>> The r351099 fix is already like that in -stable, and not part of the prob=
lem.
>>=20
>> -S=C3=B8ren
>=20
>>> On 15 Aug 2019, at 21.03, Emmanuel Vadot <manu@bidouilliste.com> wrote:
>>>=20
>>> On Thu, 15 Aug 2019 19:48:54 +0200
>>> S=C3=B8ren Schmidt <soren.schmidt@gmail.com> wrote:
>>>=20
>>>> Hi Mit!
>>>>=20
>>>> Right, I suspected that, 12-stable broke many embedded systems between r=
350592 and r350595 where all the latest and greatest DTS files was pulled in=
, I guess the same holds for -current.
>>>>=20
>>>> -S=C3=B8ren
>>>=20
>>> 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 :
>>>=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 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.
>>>=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 have 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 everything wor=
ked out of the box.
>>>>>=20
>>>>> Thanks again for the hand holding!
>>>>>=20
>>>>> Mit
>>>>>=20
>>>>> From: "S=C3=B8ren Schmidt" <soren.schmidt@gmail.com <mailto:soren.schm=
idt@gmail.com>>
>>>>> To: "Mit Matelske" <mit@pt.net <mailto:mit@pt.net>>
>>>>> Cc: "Marcin Wojtas" <mw@semihalf.com <mailto:mw@semihalf.com>>, "freeb=
sd-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 files for jus=
t about anything?
>>>>>=20
>>>>> Needless to say, it broke the Espressobin?s SD support, it now fails j=
ust like yours..
>>>>>=20
>>>>> It also broke allwinner builds and what not, so I?m just going back in=
time again :)
>>>>>=20
>>>>> I wonder why there is this overwhelming need to import stuff that brea=
ks things right, left and center in a -stable branch ?
>>>>> That would have earned you the pointy hat back when?.
>>>>>=20
>>>>> -S=C3=B8ren
>>>>>=20
>>>>>=20
>>>>> On 14 Aug 2019, at 18.01, Mit Matelske <mit@pt.net <mailto:mit@pt.net>=
> wrote:
>>>>>=20
>>>>> Marcin-
>>>>>=20
>>>>> Sorry I didn't reply yesterday. I didn't have any luck with that eith=
er. I tried a lot of permutations.
>>>>>=20
>>>>> Not saying for 100% it doesn't work, but I couldn't get it to work!
>>>>>=20
>>>>> Mit
>>>>>=20
>>>>> 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.schmid=
t@gmail.com>>, "freebsd-arm" <freebsd-arm@freebsd.org <mailto:freebsd-arm@fr=
eebsd.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 pas=
sing rootdev via u-boot bootargs (please see my previous email) works for yo=
u without the loader modification?
>>>>>=20
>>>>> Best regards,
>>>>> Marcin
>>>>>=20
>>>>> ?r., 14 sie 2019 o 16:29 Mit Matelske <mit@pt.net <mailto:mit@pt.net>>=
napisa?(a):
>>>>> Soren-
>>>>>=20
>>>>> 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 s=
ee if that helps. I'm using the latest 13-current.
>>>>>=20
>>>>> Again, appreciate the hand holding!
>>>>>=20
>>>>> Mit
>>>>>=20
>>>>> From: "S=C3=B8ren Schmidt" <soren.schmidt@gmail.com <mailto:soren.schm=
idt@gmail.com>>
>>>>> To: "Mit Matelske" <mit@pt.net <mailto:mit@pt.net>>
>>>>> Cc: "Marcin Wojtas" <mw@semihalf.com <mailto:mw@semihalf.com>>, "freeb=
sd-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 card is not g=
etting detected properly..
>>>>>=20
>>>>> I get this output:
>>>>>=20
>>>>> sdhci_xenon0: <Armada Xenon SDHCI controller> mem 0xd0000-0xd02ff,0x1e=
808-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
>>>>>=20
>>>>> The problem you see was fixed for me by r348882, maybe it got broken l=
ater, I havn?t backported the later changes..
>>>>>=20
>>>>> Have you tried another SD card ? I have found 2 of mine that the espre=
ssobin doesn?t like, but works fine with bananapi and friends...
>>>>>=20
>>>>> -S=C3=B8ren
>>>>>=20
>>>>> On 13 Aug 2019, at 23.30, Mit Matelske <mit@pt.net <mailto:mit@pt.net>=
> wrote:
>>>>>=20
>>>>> Soren-
>>>>>=20
>>>>> Thanks for the code snippet! That will fix one of the problems.
>>>>>=20
>>>>> I still can't mount my filesystem, though. I think I'm doing somethin=
g really simple, wrong. I believe I'm running the latest code and added som=
e 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-0xd02ff,0x1e=
808-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 filesystem? I've=
tried both freebsd-ufs and freebsd as the type, with no luck. A gpart listi=
ng 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,0x14003,0x3b8=
bff5)
>>>>> 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=C3=B8ren Schmidt" <soren.schmidt@gmail.com <mailto:soren.schm=
idt@gmail.com>>
>>>>> To: "Marcin Wojtas" <mw@semihalf.com <mailto:mw@semihalf.com>>
>>>>> Cc: "Mit Matelske" <mit@pt.net <mailto:mit@pt.net>>, "freebsd-arm" <fr=
eebsd-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 t=
o 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 b=
ootargs aren?t passed / won?t stick, probably something I havn?t backported t=
o my -stable12 sources yet...
>>>>>=20
>>>>> -S=C3=B8ren
>>>>>=20
>>>>> On 13 Aug 2019, at 01.38, Marcin Wojtas <mw@semihalf.com <mailto:mw@se=
mihalf.com>> wrote:
>>>>>=20
>>>>> Hi,
>>>>>=20
>>>>> 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 examp=
le from
>>>>> A3720-DB (same should work on EspressoBin):
>>>>>=20
>>>>> 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
>>>>>=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, 19=
94
>>>>> 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 arm6=
4
>>>>> FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on L=
LVM
>>>>> 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:mit@pt.net>=
> napisa?(a):
>>>>>=20
>>>>>=20
>>>>> Soren-
>>>>>=20
>>>>> Thanks for the quick response. I built this kernel with revision 3509=
24.
>>>>> 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=C3=B8ren Schmidt" <soren.schmidt@gmail.com <mailto:soren.schm=
idt@gmail.com>>
>>>>> To: "Mit Matelske" <mit@pt.net <mailto:mit@pt.net>>
>>>>> Cc: "tscho" <johannes@t-beutel.com <mailto:johannes@t-beutel.com>>, "f=
reebsd-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 least at r34=
8882
>>>>> 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=C3=B8ren
>>>>>=20
>>>>>=20
>>>>> On 12 Aug 2019, at 21.06, Mit Matelske <mit@pt.net <mailto:mit@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 automaticall=
y
>>>>> 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 and kernel f=
rom
>>>>> 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,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 m=
mc
>>>>> 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 m=
mc
>>>>> 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
>>>>>=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 argument.
>>>>>=20
>>>>> can't load 'kernel'
>>>>>=20
>>>>> Type '?' for a list of commands, 'help' for more detailed help.
>>>>> 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, 19=
94
>>>>> 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_seedi=
ng'
>>>>> 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,3=
9 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 100=
0
>>>>> 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,3=
9 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,3=
9 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,3=
9 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,3=
9 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,3=
9 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 FB=
S
>>>>> 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>
>>>>>=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, 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.
>>>>>=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> 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>"
>>>>>=20
>>>>> _______________________________________________
>>>>> 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>"
>>>>=20
>>>=20
>>>=20
>>> --
>>> Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
>>=20
>=20
>=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?78F5029D-A0F5-42F2-8191-07EB3A68C87B>