Date: Wed, 5 Aug 2020 13:26:25 +0200 (CEST) From: Ronald Klop <ronald-lists@klop.ws> To: freebsd-arm@freebsd.org, Denis Polygalov <dpolyg@gmail.com> Subject: Re: FreeBSD network boot on Raspberry Pi 4 Message-ID: <19322774.3413.1596626785313@localhost> In-Reply-To: <1555afc0-b014-ccf7-5c4c-05115a8facc1@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Oh I misread your example. Mixed the nanopi and rpi4 output. You have trouble that EFI can't see the network?=20 I don't know about that. Most people on this list boot from SD or USB AFAIK= . So I hope others will chime in. Running 13 instead of 12 will help you after you fix the EFIboot problem th= ough. Regards, Ronald. Van: Denis Polygalov <dpolyg@gmail.com> Datum: 5 augustus 2020 12:45 Aan: freebsd-arm@freebsd.org Onderwerp: Re: FreeBSD network boot on Raspberry Pi 4 >=20 >=20 > Thank you for your suggestions. > I switched my FreeBSD source code tree to the head: > $ svn info > Path: . > Working Copy Root Path: /usr/home/denis/freebsd/base/head/src > URL: svn://svn.freebsd.org/base/head > Relative URL: ^/head > Repository Root: svn://svn.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 363886 > Node Kind: directory > Schedule: normal > Last Changed Author: mjg > Last Changed Rev: 363886 > Last Changed Date: 2020-08-05 16:34:45 +0900 (Wed, 05 Aug 2020) >=20 > then rebuild everything. Result is exactly the same, no boot, > here is serial console output: >=20 > >>Start PXE over IPv4. > Station IP address is 192.168.10.201 >=20 > Server IP address is 192.168.10.10 > NBP filename is boot/loader.efi > NBP filesize is 695808 Bytes > Downloading NBP file... >=20 > NBP file downloaded successfully. > Consoles: serial port > Reading loader env vars from /efi/freebsd/loader.env > FreeBSD/arm64 EFI loader, Revision 1.1 > (Wed Aug 5 18:14:26 JST 2020 denis@buildarm) >=20 > Command line arguments: loader.efi > Image base: 0x33841000 > EFI version: 2.70 > EFI Firmware: https://github.com/pftf/RPi4 (rev 1.00) > Console: comconsole (0) > Load Path: > Load Device: MAC(DCA632932BAB,0x1)/IPv4(0.0.0.0) > BootCurrent: 0003 > BootOrder: 0000 0001 0002 0003[*] 0004 0005 0006 > BootInfo Path: MAC(DCA632932BAB,0x1)/IPv4(0.0.0.0) > Ignoring Boot0003: Only one DP found > Setting currdev to net0: > bootp: no reply > No response for RARP request > net_open: RARP failed > Unable to open network interface 0 for exclusive access: 15 > netboot: couldn't probe efinet0 > net_open: netif_open() failed > Failed to find bootable partition >=20 > <-- here UEFI restarts if I understand correctly. >=20 > Initialising SDRAM 'Micron' 16Gb x2 total-size: 32 Gbit > Loading recovery.elf hnd: 0x00000000 > Failed to read recovery.elf error: 3 > Loading start4.elf hnd: 0x00000104 > Loading fixup4.dat hnd: 0x00000103 > MEM GPU: 76 ARM: 948 TOTAL: 1024 > FIXUP src: 128 256 dst: 948 1024 > Starting start4.elf @ 0xfec00200 >=20 > NOTICE: BL31: v2.3():v2.3 > NOTICE: BL31: Built : 10:40:51, Apr 21 2020 > UEFI firmware (version UEFI Firmware v1.17 built at 16:07:05 on Jul 14 20= 20) >=20 > Regards, > Denis. >=20 >=20 > On 5/08/2020 2:12 am, Robert Crowston wrote: > > You=E2=80=99ll need 13-CURRENT. Things are gradually coming together. I= think the only show stopper is a serious bug in the way we handle PCI-E DM= A on models with >=3D 4 GB of RAM. > >=20 > > =E2=80=94 RHC. > >=20 > > On Tue, Aug 4, 2020 at 15:27, Ronald Klop <ronald-lists@klop.ws> wrote: > >=20 > >> On Tue, 04 Aug 2020 15:57:29 +0200, Denis Polygalov <dpolyg@gmail.com> > >> wrote: > >> > >>> Hi, > >>> > >>> I'm trying to boot FreeBSD 12.1-RELEASE over network > >>> on Raspberry Pi 4 Model B. > >>> Well, the '12.1-RELEASE' doesn't matter here because > >>> seems like loader.efi cannot find and load kernel yet. > >> > >> Other people know more details than I do. But... RPI4 is very new. All > >> development to get it up and running is in 13-CURRENT. > >> You can try a snapshot build. > >> > >> More information can be found here: > >> https://wiki.freebsd.org/arm/Raspberry%20Pi > >> Latest snapshot can be found here: > >> https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/13= .0/ > >> > >> Regards, > >> Ronald. > >> > >>> > >>> I'm using RPi4 UEFI v 1.17: > >>> https://github.com/pftf/RPi4/releases/tag/v1.17 > >>> > >>> and here is what I see on a serial console: > >>> > >>> ESC (setup), F1 (shell), ENTER (boot).. > >>>>> Start PXE over IPv4. > >>> Station IP address is 192.168.10.201 > >>> > >>> Server IP address is 192.168.10.10 > >>> NBP filename is boot/loader.efi > >>> NBP filesize is 610056 Bytes > >>> Downloading NBP file... > >>> > >>> NBP file downloaded successfully. > >>> Consoles: EFI console > >>> FreeBSD/arm64 EFI loader, Revision 1.1 > >>> > >>> Command line arguments: loader.efi > >>> EFI version: 2.70 > >>> EFI Firmware: https://github.com/pftf/RPi4 (rev 1.00) > >>> Console: efi (0) > >>> Load Path: > >>> (few minutes time delay here) > >>> bootp: no reply > >>> No response for RARP request > >>> net_open: RARP failed > >>> bootp: no reply > >>> > >>> Seems like the loader.efi is get executed but not all > >>> necessary parameters are passed to it... > >>> > >>> The host machine I'm using for testing is designated for > >>> network boot of various ARM based boards and I'm quite > >>> sure tftpd/dhcpd/nfsd configuration is correct. > >>> Here is relevant output of Nanopi-NEO2 board > >>> network boot performed on the same host machine: > >>> > >>> ... skipped ... > >>> ## Starting EFI application at 40080000 ... > >>> Consoles: EFI console > >>> Reading loader env vars from /efi/freebsd/loader.env > >>> FreeBSD/arm64 EFI loader, Revision 1.1 > >>> > >>> Command line arguments: loader.efi > >>> EFI version: 2.70 > >>> EFI Firmware: Das U-Boot (rev 8217.1024) > >>> Console: efi (0) > >>> Load Path: /dtballwinnersun50i-h5-nanopi- > >>> Load Device: > >>> /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/MAC(0201579f3216,0x1) > >>> Setting currdev to net0: > >>> net0: cannot set rx. filters (status=3D3) > >>> Loading /boot/defaults/loader.conf > >>> Loading /boot/device.hints > >>> Loading /boot/loader.conf > >>> Loading /boot/loader.conf.local > >>> Autoboot in 8 seconds, hit [Enter] to boot or any other key to stop > >>> Loading kernel... > >>> /boot/kernel/kernel text=3D0x93a61c data=3D0x1914c8+0x84ab1c > >>> syms=3D[0x8+0x138810+0x8+0x124a28] > >>> Loading configured modules... > >>> ... skipped ... > >>> > >>> is there anything I can do in order to get my RPi 4 booted over netwo= rk? > >>> > >>> Best Regards, > >>> Denis. > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> freebsd-arm@freebsd.org mailing list > >>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm > >>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org= " > >> _______________________________________________ > >> freebsd-arm@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm > >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >=20 >=20 >=20 >=20 From owner-freebsd-arm@freebsd.org Wed Aug 5 23:45:56 2020 Return-Path: <owner-freebsd-arm@freebsd.org> Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 21F9C3AC14F for <freebsd-arm@mailman.nyi.freebsd.org>; Wed, 5 Aug 2020 23:45:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BMStT50fqz4NZT for <freebsd-arm@freebsd.org>; Wed, 5 Aug 2020 23:45:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 5Ndex1cVM1mykYp7Mxoa1XAJRm4A5iA6OMieRUp7OVDiSSwaxA9sT6mrY1hfePw RkWc3BvD7jgwOPoR364Yy.FWWnRFJOWjEC3qBYXBGM18httI4tHazs8AmqDSh4LIkT3f.5O3Inxs pHQJ7hd_Er84cYKne9vPmB33gMoNnteh3OF6c8aa2YpoJPUB9m131DCuqW7gulu4D7xobWGaaGW2 Sgfq.grOEWTtp1mAbjZpaMKEZrz.QoVBccmAswpGbnO9AVzOr9knsSTyXEMYajdOEURqnplXf8rG cDJ2zrMO9qdLjLIbvJPxT3cp3JWDfhu2vw06qft8GXQEixnr.RYjcfqrR6W3ijRBhWsEdj0llk01 4ySZbPIKerkFk3rQ2v0GVrgt0W9XJiNqug6UFCx53OjTR0MQZjiQpE3sC._KNKxbQ3vCsV4kLshl NAdru3JugzkVtsT8cStuQhsDq8ZB8nZU8N9FV8BKqMS.mCz2mxSBQ9Zg.Pb51MyNq2gTB_8NC9T5 u43jOWcNqj.GgHJULD3.y3ICaMsTumQVn6Lg_FFiXvB.qvWNtHm.iLNyKXr.ZMuZXha1iBzQuACr AKehLr3MrMy79l3n.lBC2goICOwW_DETu7BLDTpnUeSLBA9RM3HgqscFWiKkowN5epD_ZeFBsyFi OCjH495Pj9cVIXuWoeOEEC9AdK7fmS1TKa2Dj_3Q6D1MwsSh4wB4hq8iWeVz15Ae1gQ1NOvzZ3qN u_kXYL4YclYuDP_YjO0vP_B_Uv_oHVXHUq0n4jvKqgOSylzBED1kKTaZjmtGbvcAYL9.0TimfQI3 wQa.OKhDWZXYCed3AQ6iOOrzAJGKjBxqUXo0fmyEVL.Izr.NwNMWrV7.g.XQ9_htq0Ab2qaNp2fX pIp8duMJT1Xqvayw_H5jUDPVbImEbLXkdPIIGjrc7U.tMz39FBDQTThWiilqvKwbQM2m41sza8XZ jOLqbAaFSleQ9hGHY9pOB0lnR6o1JRLwc889hXKqWqSjTLLqCpzC58m9HeW4e5f.nyoydiaG3jUa ahORTUsK8F_RDvX0lBaaSlUVtkHNXHo5a5MMZXim5EqhpXFDL9lcukIdUDe0RNGev0DYFNvtlXlg 5aP_j5OuQlwEtHElp.09sczFPHV__Has2cqG7GfzijeEVfXjcQbaTB88wmP1YH4wV0u7Syjx_n98 yoRkAFRa0t7jobkYh19Tka84OECrP7WPwOVE3QwE_GR5P6C5I0uAhYgs3orgBvwJLKe7BnCY7t9u ZJK6rkPydC47Y2x9Qk8gDaEEu7eg8pBk0RIUlNq5ev5yRqdn3o6R_ZvoXrFVIoaL1KKb2inoplmU fyVkc49Ufr7nF_7sVjQxNj_HpHNzxWKcuu5l8suAigU7.xpfiv9r5NADotbw- Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Wed, 5 Aug 2020 23:45:52 +0000 Received: by smtp413.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 386af578cca6f4a34951f0d104327f8c; Wed, 05 Aug 2020 23:45:47 +0000 (UTC) From: Mark Millard <marklmi@yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: aarch64: unable to use lang/gcc10 to use system libc++ . . . [ unless I use -mno-outline-atomics for gcc10's 10.1 and later] Date: Wed, 5 Aug 2020 16:45:46 -0700 References: <E65995FF-2C48-41B3-96B6-93B6C67E7103@yahoo.com> <94FBD6B8-87E7-45E9-84F7-3F17D42F4BED@yahoo.com> To: freebsd-arm <freebsd-arm@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org> In-Reply-To: <94FBD6B8-87E7-45E9-84F7-3F17D42F4BED@yahoo.com> Message-Id: <1E88269B-C277-4543-BDB5-19CE71F5B93B@yahoo.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4BMStT50fqz4NZT X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.22 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.83:from]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-0.996]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from]; NEURAL_HAM_SHORT(-0.72)[-0.724]; NEURAL_HAM_MEDIUM(-1.00)[-0.995]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>, <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>; List-Post: <mailto:freebsd-arm@freebsd.org> List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>, <mailto:freebsd-arm-request@freebsd.org?subject=subscribe> X-List-Received-Date: Wed, 05 Aug 2020 23:45:56 -0000 On 2020-Aug-4, at 16:52, Mark Millard <marklmi at yahoo.com> wrote: > On 2020-Aug-4, at 14:27, Mark Millard <marklmi at yahoo.com> wrote: >>=20 >> Historically I've been able to use lang/gcc9 to build personal >> aarch64 c++17 applications that used head's libc++ and the >> like (other than some floating point support code for aarch64). >> The redirection of g++9 to system libraries and such looks >> like: >>=20 >> . . . >> CXX+=3D -Wno-psabi -nostdinc -nostdinc++ = -I/usr/include/c++/v1 -I/usr/include >> . . . >> LDCXX=3D -nodefaultlibs -lc++ -lcxxrt -lthr -lm -lc -lgcc_s = \ >> -Wl,-rpath=3D/usr/local/lib/gcc9 >> . . . >> # Note: FreeBSD's libgcc_s were missing at least a floating point = routine. >> # The -Wl,-rpath=3D/usr/local/lib/gcc9 causes use of gcc9's = libgcc_s . >> # So far I've only had the issue for targeting aarch64 and = armv7. >> . . . >>=20 >> I do not know if there is an intention to allow such things vs. if >> I was just lucky that it worked at the time. Historically I've done >> the same on powerpc64, 32-bit powerpc, and amd64 as well. On those no >> -Wl,-rpath=3D... was required. Targeting armv7 did require use of >> -Wl,-rpath=3D/usr/local/lib/gcc9 . >>=20 >>=20 >>=20 >> I've just tried the same sort of thing for using lang/gcc10 and >> targeting aarch64 and it fails to build: >>=20 >> CXX+=3D -Wno-psabi -nostdinc -nostdinc++ = -I/usr/include/c++/v1 -I/usr/include >> . . . >> LDCXX=3D -nodefaultlibs -lc++ -lcxxrt -lthr -lm -lc -lgcc_s = \ >> -Wl,-rpath=3D/usr/local/lib/gcc10 >>=20 >> It ended up failing for: >>=20 >> /usr/local/bin/ld: ../objs/cpp_clockinfo-g++_10_O3-libc++.o: in = function `long = std::__1::__libcpp_atomic_refcount_decrement<long>(long&)': >> /usr/include/c++/v1/memory:3386: undefined reference to = `__aarch64_ldadd8_acq_rel' >> /usr/local/bin/ld: ../objs/cpp_clockinfo-g++_10_O3-libc++.o: in = function `long = std::__1::__libcpp_atomic_refcount_increment<long>(long&)': >> /usr/include/c++/v1/memory:3375: undefined reference to = `__aarch64_ldadd8_relax' >> /usr/local/bin/ld: ../objs/cpp_clockinfo-g++_10_O3-libc++.o: in = function `long = std::__1::__libcpp_atomic_refcount_decrement<long>(long&)': >> /usr/include/c++/v1/memory:3386: undefined reference to = `__aarch64_ldadd8_acq_rel' >> /usr/local/bin/ld: /usr/include/c++/v1/memory:3386: undefined = reference to `__aarch64_ldadd8_acq_rel' >> /usr/local/bin/ld: /usr/include/c++/v1/memory:3386: undefined = reference to `__aarch64_ldadd8_acq_rel' >> /usr/local/bin/ld: /usr/include/c++/v1/memory:3386: undefined = reference to `__aarch64_ldadd8_acq_rel' >> /usr/local/bin/ld: /usr/include/c++/v1/memory:3386: undefined = reference to `__aarch64_ldadd8_acq_rel' >> /usr/local/bin/ld: = ../objs/cpp_clockinfo-g++_10_O3-libc++.o:/usr/include/c++/v1/memory:3386: = more undefined references to `__aarch64_ldadd8_acq_rel' follow >> collect2: error: ld returned 1 exit status >> *** Error code 1 >>=20 >> Stop. >> make: stopped in /root/acpphint/acpphint_src >>=20 >> (Omitting -Wl,-rpath=3D/usr/local/lib/gcc10 made no difference.) >>=20 >> I did not have such an issue for powerpc64. I've not tried the >> other platforms yet. >>=20 >>=20 >> Anyone know if I'm out in "if it hurts, then do not do that" >> land? Or is this something that should be possible but is >> currently broken? >>=20 >>=20 >> Note: The C++ source in question tries to be pure C++17 compliant >> code for normal builds. (And I was doing a normal build: no FreeBSD >> specific code or the like enabled.) >=20 > I just tried lang/gcc9 ( -r543890 ports ) on a head -r363590 > aarch64 based system, without -Wl,-rpath=3D/usr/local/lib/gcc9 > used, and it still builds but at run-time programs get the > likes of: >=20 > ld-elf.so.1: = /root/acpphint/acpphint_kernelsurveyors_main-RPi4B-4096MiB-threads_4-LP64-= FreeBSD_13_r363590M_64bit-g++_9_O3-libc++: Undefined symbol = "__floatunditf@GCC_4.2.0" >=20 > So that has not changed. This is a very different issue than > what attempting to use lang/gcc10 gets. >=20 I finally figured out what is going on as of gcc10.1 and later for aarch64: -moutline-atomics is now the default in gcc10.1 and later for aarch64 but FreeBSD is not set up for such as far as I can tell. (Outlined atomics dynamically detect later-added instructions being available and use them instead of the original code sequences that are required on the older aarch64 hardware. On the older hardware they do things the old way.) To get the older style of code generation that avoids needing to have an implementation of the outlined atomics, I've added use of -mno-outline-atomics for aarch64. For example, for avoiding use of gcc's libraries for the most part: CXX+=3D -Wno-psabi -nostdinc -nostdinc++ -I/usr/include/c++/v1 = -I/usr/include OPT=3D -O3 -mcpu=3Dcortex-a53 -mno-outline-atomics . . . LDCXX=3D -nodefaultlibs -lc++ -lcxxrt -lthr -lm -lc -lgcc_s \ -Wl,-rpath=3D/usr/local/lib/gcc10 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19322774.3413.1596626785313>