From owner-freebsd-arm@freebsd.org Sun Aug 18 07:47:54 2019 Return-Path: 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 80E89BF10D for ; Sun, 18 Aug 2019 07:47:54 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 46B8L16YLyz4Fc8 for ; Sun, 18 Aug 2019 07:47:53 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.nyi.freebsd.org (Postfix) id E0CD4BF10C; Sun, 18 Aug 2019 07:47:53 +0000 (UTC) Delivered-To: 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 E08ABBF10B for ; Sun, 18 Aug 2019 07:47:53 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46B8L00lnfz4Fby for ; Sun, 18 Aug 2019 07:47:51 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=QVT4/7XMA93s82hZYyEUZeOpcZtvg/qAz4cfUGipY9w=; b=tUH593Hec5LD5tSyejmZ5GiZd4F1inbwpqBdhoVO77RvHbYYJkBzNN1015nwjNjokeHWI8oVPYhg5c2U2jg1e8AKDbC/Af2TWwlTv54nkewpfbJOuL+1BlRjjJixo1MnxtCAMjx/aBn8Qhix6aTx6z0Jpxk371jT+WnPORSXXjt7iQAfWjthwMPpMLtDBCDGJSsE8Ec76ZzMzh5JK96VP9Bw6KdNhGzMJMyLT9wJg/SAFF43MfixeAvBMyHGlmJyssQRAoMd9ObYKo4WXdEg1PnPjOSOLMbC+TLVDILUR6xqePLKvdaFlzD0h0Jeiwk86oyhNDTnO/5miN5c4/U8yg==; Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1hzFul-0004yE-IO; Sun, 18 Aug 2019 10:47:47 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: boot hangs in nanopi-neo From: Daniel Braniss In-Reply-To: <20190817203259.e028141082262cd0dda70c68@bidouilliste.com> Date: Sun, 18 Aug 2019 10:47:46 +0300 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <116689BE-9231-4591-BFBB-8E823931D2D2@cs.huji.ac.il> <20190817203259.e028141082262cd0dda70c68@bidouilliste.com> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3445.9.1) X-Rspamd-Queue-Id: 46B8L00lnfz4Fby X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=tUH593He; dmarc=none; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il X-Spamd-Result: default: False [-2.92 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.996,0]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-0.996,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[huji.ac.il]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[210.116.65.132.list.dnswl.org : 127.0.10.0]; NEURAL_HAM_SHORT(-0.85)[-0.846,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/13, country:IL]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-0.28)[ipnet: 132.64.0.0/13(-0.82), asn: 378(-0.66), country: IL(0.05)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2019 07:47:54 -0000 > On 17 Aug 2019, at 21:32, Emmanuel Vadot = wrote: >=20 > On Sat, 17 Aug 2019 19:55:13 +0300 > Daniel Braniss wrote: >=20 >> after some months, I decided to upgrade, but now it stucks here: >> ? >>=20 >> FreeBSD 13.0-CURRENT #13 r351126M: Sat Aug 17 13:19:09 IDT 2019 >> = danny@pe-44:/home/obj/pe-44/arm/neo/r+d/vanilla/13/arm.armv7/r+d/vanilla/1= 3/sys/AWG arm >> FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on = LLVM 8.0.1) >> WARNING: WITNESS option enabled, expect reduced performance. >> ? >>=20 >> hub3: on = usbus3 >> mmcsd0: 8GB at mmc0 = 50.0MHz/4bit/32768-block >> Release A >>=20 >> at which point it hangs solid. >>=20 >> BTW, I installed a newer u-boot (maybe it?s not the very latest) >>=20 >> this is the full console output: >>=20 >> USB Device(s) found >> scanning bus 1 for devices... 1 USB Device(s) found >> scanning bus 2 for devices... 1 USB Device(s) found >> scanning bus 3 for devices... 1 USB Device(s) found >> scanning usb for storage devices... 0 Storage Device(s) found >> Hit any key to stop autoboot: 0=20 >> switch to partitions #0, OK >> mmc0 is current device >> Scanning mmc 0:1... >> Found U-Boot script /boot.scr >> 199 bytes read in 0 ms >> ## Executing script at 43100000 >> 384788 bytes read in 24 ms (15.3 MiB/s) >> ## Starting application at 0x42000000 ... >> Consoles: U-Boot console =20 >> Compatible U-Boot API signature found @0x5bf6bca0 >>=20 >> FreeBSD/armv7 U-Boot loader, Revision 1.3 >> (Sat Aug 17 12:49:43 IDT 2019 danny@pe-44) >>=20 >> DRAM: 512MB >> Number of U-Boot devices: 1 >> U-Boot env: loaderdev not set, will probe all devices. >> Found U-Boot device: disk >> Probing all devices... >> Checking unit=3D0 slice=3D partition=3D... good. >> Booting from disk0s2a: >> Loading /boot/defaults/loader.conf >> Loading /boot/device.hints >> Loading /boot/loader.conf >> Loading /boot/loader.conf.local >> Loading kernel... >> /boot/kernel/kernel text=3D0x870a68 data=3D0xb4e18+0x259768 = syms=3D[0x4+0xaa340+0x4+0x10d2ac] >> Loading configured modules... >> can't find '/boot/entropy' >>=20 >> Hit [Enter] to boot immediately, or any other key for command prompt. >> Booting [/boot/kernel/kernel]... =20 >> /boot/dtb/sun8i-h3-nanopi-neo.dtb size=3D0x64d1 >> Loaded DTB from file 'sun8i-h3-nanopi-neo.dtb'. >> Kernel entry at 0x42400180... >> Kernel args: (null) >> ---<>--- >> KDB: debugger backends: ddb >> KDB: current backend: ddb >> Copyright (c) 1992-2019 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 >> The Regents of the University of California. All rights = reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 13.0-CURRENT #13 r351126M: Sat Aug 17 13:19:09 IDT 2019 >> = danny@pe-44:/home/obj/pe-44/arm/neo/r+d/vanilla/13/arm.armv7/r+d/vanilla/1= 3/sys/AWG arm >> FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on = LLVM 8.0.1) >> WARNING: WITNESS option enabled, expect reduced performance. >> VT: init without driver. >> module_register: cannot register ofwbus/pcib from kernel; already = loaded from kernel >> Module ofwbus/pcib failed to register: 17 >> module_register: cannot register simplebus/pcib from kernel; already = loaded from kernel >> Module simplebus/pcib failed to register: 17 >> CPU: ARM Cortex-A7 r0p5 (ECO: 0x00000000) >> CPU Features:=20 >> Multiprocessing, Thumb2, Security, Virtualization, Generic Timer, = VMSAv7, >> PXN, LPAE, Coherent Walk >> Optional instructions:=20 >> SDIV/UDIV, UMULL, SMULL, SIMD(ext) >> LoUU:2 LoC:3 LoUIS:2=20 >> Cache level 1: >> 32KB/64B 4-way data cache WB Read-Alloc Write-Alloc >> 32KB/32B 2-way instruction cache Read-Alloc >> Cache level 2: >> 512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc >> real memory =3D 536870912 (512 MB) >> avail memory =3D 506929152 (483 MB) >> No PSCI/SMCCC call function found >> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >> arc4random: WARNING: initial seeding bypassed the cryptographic = random device because it was not yet seeded and the knob = 'bypass_before_seeding' was enabled. >> random: entropy device external interface >> kbd0 at kbdmux0 >> ofwbus0: >> ofw_clkbus0: on ofwbus0 >> clk_fixed0: on ofw_clkbus0 >> clk_fixed1: on ofw_clkbus0 >> simplebus0: on ofwbus0 >> regfix0: on ofwbus0 >> regfix1: on ofwbus0 >> regfix2: on ofwbus0 >> rtc0: mem 0x1f00000-0x1f003ff irq 40,41 on simplebus0 >> rtc0: registered as a time-of-day clock, resolution 1.000000s >> ccu_h3ng0: mem = 0x1c20000-0x1c203ff on simplebus0 >> ccu_sun8i_r0: mem = 0x1f01400-0x1f014ff on simplebus0 >> gic0: mem = 0x1c81000-0x1c81fff,0x1c82000-0x1c83fff,0x1c84000-0x1c85fff,0x1c86000-0x1c= 87fff irq 37 on simplebus0 >> gic0: pn 0x1, arch 0x2, rev 0x1, implementer 0x43b irqs 160 >> gpio0: mem 0x1c20800-0x1c20bff irq = 18,19 on simplebus0 >> gpiobus0: on gpio0 >> gpio1: mem 0x1f02c00-0x1f02fff irq = 44 on simplebus0 >> gpiobus1: on gpio1 >> generic_timer0: irq 0,1,2,3 on ofwbus0 >> Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality = 1000 >> Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality = 1000 >> aw_syscon0: mem 0x1c00000-0x1c00fff on simplebus0 >> awusbphy0: mem = 0x1c19400-0x1c1942b,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803,0x1c1c800-0x1c= 1c803,0x1c1d800-0x1c1d803 on simplebus0 >> a31dmac0: mem 0x1c02000-0x1c02fff irq 4 on = simplebus0 >> aw_mmc0: mem = 0x1c0f000-0x1c0ffff irq 6 on simplebus0 >> mmc0: on aw_mmc0 >> ehci0: mem = 0x1c1a000-0x1c1a0ff irq 10 on simplebus0 >> usbus0: EHCI version 1.0 >> usbus0 on ehci0 >> ohci0: mem 0x1c1a400-0x1c1a4ff irq 11 on = simplebus0 >> usbus1 on ohci0 >> ehci1: mem = 0x1c1d000-0x1c1d0ff irq 16 on simplebus0 >> usbus2: EHCI version 1.0 >> usbus2 on ehci1 >> ohci1: mem 0x1c1d400-0x1c1d4ff irq 17 on = simplebus0 >> usbus3 on ohci1 >> gpioc0: on gpio0 >> awg0: mem 0x1c30000-0x1c3ffff irq 22 on = simplebus0 >> miibus0: on awg0 >> ukphy0: PHY 0 on miibus0 >> ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, = auto-flow >> ukphy1: PHY 1 on miibus0 >> ukphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, = auto-flow >> awg0: Ethernet address: f2:00:e7:81:61:2e >> aw_wdog0: mem 0x1c20ca0-0x1c20cbf irq 25 on = simplebus0 >> uart2: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 30 on = simplebus0 >> uart2: console (115384,n,8,1) >> gpioc1: on gpio1 >> cpulist0: on ofwbus0 >> cpu0: on cpulist0 >> cpu1: on cpulist0 >> cpu2: on cpulist0 >> cpu3: on cpulist0 >> gpioled0: on ofwbus0 >> cryptosoft0: >> Timecounters tick every 1.000 msec >> usbus0: 480Mbps High Speed USB v2.0 >> usbus1: 12Mbps Full Speed USB v1.0 >> usbus2: 480Mbps High Speed USB v2.0 >> usbus3: 12Mbps Full Speed USB v1.0 >> ugen1.1: at usbus1 >> uhub0 on usbus1 >> uhub0: on = usbus1 >> ugen0.1: at usbus0 >> uhub1 on usbus0 >> uhub1: on = usbus0 >> ugen2.1: at usbus2 >> uhub2 on usbus2 >> uhub2: on = usbus2 >> ugen3.1: at usbus3 >> uhub3 on usbus3 >> uhub3: on = usbus3 >> mmcsd0: 8GB at mmc0 = 50.0MHz/4bit/32768-block >> Release A >=20 > Could you boot -v please ? I think I found the problem, lousy usb power, will confirm later. btw, any chance to enable the sid stuff? without it the ethernet changes = it=E2=80=99s mac =09 /dts-v1/; /plugin/; / { compatible =3D "allwinner,sun50i-h5"; }; &{/soc} { sid: eeprom@1c14000 { compatible =3D "allwinner,sun50i-h5-sid"; reg =3D <0x1c14000 0x400>; }; }; >=20 > --=20 > Emmanuel Vadot From owner-freebsd-arm@freebsd.org Sun Aug 18 10:11:17 2019 Return-Path: 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 A216EC2C9B for ; Sun, 18 Aug 2019 10:11:17 +0000 (UTC) (envelope-from soren.schmidt@gmail.com) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46BCWS3K63z4N1B for ; Sun, 18 Aug 2019 10:11:16 +0000 (UTC) (envelope-from soren.schmidt@gmail.com) Received: by mail-ed1-x530.google.com with SMTP id z51so8669584edz.13 for ; Sun, 18 Aug 2019 03:11:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=M1uyF/eaXkAAiLaM1B/L0kUDb+cESJ867leeZMjedpI=; b=OBoA8jq7OBeI5IUZYBglVRXPcfRgFFufbyF2/XLMYlzXn2EcGlmhuXWhxmocjCWXPh RYMZgwtNXxZGTjsbBjZtIIP2RnNy1CQrXvPadPX9rfz5KsOVhtNQxDLICr0DRhk9p921 t6HlA2stkwLcJczsV8M78/NMv7xOTrfzvJa64RkkVreBBzjTKGj6ac/0G0GoINRrKbIC MKVAMIg9+bVX9oii+p2ov02EOMic6D4ZMidKSe/+sf53YzrD8RK8xYVlga6hrlGzys7A wHogi/2GZ4uAwupi7bdHoCSOiK4Wg8gQoPywhMxjBbCxVWkQ+w+bAX0B9yi9HfRuypKf bMBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=M1uyF/eaXkAAiLaM1B/L0kUDb+cESJ867leeZMjedpI=; b=k2XKH1+CKGOiIkPcvpHz2Sc6XkVsGitg8s47dSxQtumUB6x9Xyu2y3jXgHSSJRDiMX xkycxJkHQkLnG4ShFRsqSXPz3CnBs1/GQVZFJsoOLErGe+2sQ3bk2kIFxDCozyMIHfCD k/MY7JdB71cIOjKmEYPHtG5XgHQ2twDNKVqMv2CEe41QGeWGfNiDTBObiIp1/aeQI9K1 hODsOJQrDI0jmMZg2wfV67IKJsk29PQZIJwDTVFU1LW9MLuX8SSzQGw6b0cLKB8uauT7 eWYJs+9oDq1bTSGBYkcNyfeEqNFt8d9y1q1eIHq8fHNi6ecgf2Bo/VBrx1pawImJfEk7 ee/Q== X-Gm-Message-State: APjAAAXRZQ8GTmz1FfEBADs1IC2wE573fTnKG7Pain6dXN7SDWURHTco bcvObGmfxKvbKqlAKl/1yFM= X-Google-Smtp-Source: APXvYqyRiaS9OAD1iLiUZ2+hMdrlhX7mrXf59qcPnRiFoALa1QbiktDiNWUzzNbET69rPfkpVZFzLw== X-Received: by 2002:a17:906:4ed8:: with SMTP id i24mr16157978ejv.312.1566123074287; Sun, 18 Aug 2019 03:11:14 -0700 (PDT) Received: from mac.deepcore.dk ([85.27.186.9]) by smtp.gmail.com with ESMTPSA id k12sm2115047edr.84.2019.08.18.03.11.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Aug 2019 03:11:13 -0700 (PDT) From: =?utf-8?Q?S=C3=B8ren_Schmidt?= Message-Id: <2D6D4BDA-75EC-403F-B5E2-52A468369DE2@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_BE762473-F918-4384-9DC1-E0188BF0465B"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Espressobin anyone ? Date: Sun, 18 Aug 2019 12:11:11 +0200 In-Reply-To: Cc: freebsd-arm To: Jeffrey Bowers References: <1547777156.662147.1565798461515.JavaMail.zimbra@perftech.com> <0E42E605-477E-4E65-810E-BD3A8CDE2C80@gmail.com> <973015183.1067498.1565890674099.JavaMail.zimbra@perftech.com> <20190815210311.1035f64b003e2bc85fa47ca8@bidouilliste.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> <20190817153053.5592b15b8a42982fda0fc123@bidouilliste.com> <9749945A-FDAD-47E0-947A-FA62138C2F83@gmail.com> <20190817210822.8920656bad0855b554883cf2@bidouilliste.com> X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 46BCWS3K63z4N1B X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=OBoA8jq7; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sorenschmidt@gmail.com designates 2a00:1450:4864:20::530 as permitted sender) smtp.mailfrom=sorenschmidt@gmail.com X-Spamd-Result: default: False [-4.60 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; HAS_ATTACHMENT(0.00)[]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.995,0]; SIGNED_PGP(-2.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.46.224,0.0.117.48]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; SH_EMAIL_ZRD(0.00)[0.0.117.48,0.0.46.224]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[0.3.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(0.00)[ip: (-9.52), ipnet: 2a00:1450::/32(-3.03), asn: 15169(-2.38), country: US(-0.05)]; RCVD_TLS_ALL(0.00)[] X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2019 10:11:17 -0000 --Apple-Mail=_BE762473-F918-4384-9DC1-E0188BF0465B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Jeffrey You can unmount the memory disk on /tmp to get at the space on the SD = card. It is however not recommend to use the AD card for random storage, it = will wear out fast, that=E2=80=99s why the memory disk is setup. You could connect a SSD og laptop disk to the SATA interface and use = that for the workload. However compiling is slow, its much much faster to cross compile on a = PC=E2=80=A6 -S=C3=B8ren > On 18 Aug 2019, at 00.22, Jeffrey Bowers wrote: >=20 > Hi! I've got a new one :) > I'm trying to do an svn checkout to fix the pkg problem, but it tells = me it can't write to a to a temp folder because there is no room left on = the device. However, FreeBSD partition is 29GB. It's never also never = the same file in TMP that it can't write to. Here is a screenshot of the = issue, along with the output of gpart: >=20 > >=20 > Any ideas? >=20 > Thanks! >=20 > On Sat, Aug 17, 2019 at 2:08 PM Emmanuel Vadot > wrote: > On Sat, 17 Aug 2019 17:14:36 +0200 > S=C3=B8ren Schmidt > wrote: >=20 > > HI > > > > Well, I have a whole forrest of tree?s here, but the error posted = here was on a clean checkout. > > > > Anyhow, with the latest changes to -stable and the two RF_SHAREABLE = patches from -current all works. >=20 > 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. >=20 > > It would be nice with the etherswitch changes as well so VLAN = tagging etc was standard. > > > > -S=C3=B8ren > > > > PS: given up on bottom & inline popsting, top posting is all the = rage now (yeah I miss elm etc :) ) > > > > > On 17 Aug 2019, at 15.30, Emmanuel Vadot > wrote: > > > > > > On Sat, 17 Aug 2019 11:07:22 +0200 > > > S=C3=B8ren Schmidt >> wrote: > > > > > >> Hi Emmunuel > > >> > > >> Yes the 3720 gpio driver I already back ported long ago, its = needed, I?m happy its now part of std stable 12! > > > > > > Would have been nice of you to say that you were not running a = clean > > > tree. > > > > > >> My issue seems to be the inclusion of the phy_usb driver, if I = leave that out, I?m back to normal.. > > > > > > What make you think this is this driver ? What works/doesn't work > > > with it ? could you provide logs. > > > > > >> I?ll have have another go at the latest -stable sources during = the weekend and see how it goes. > > >> > > >> Thanks for looking into this, with a little cooperation we?ll get = this solved for the greater good.. > > >> > > >> -S=C3=B8ren > > > > > > P.S. Please stop top posting, it's really hard to read the = conversation > > > > > >>> On 16 Aug 2019, at 22.58, Emmanuel Vadot > wrote: > > >>> > > >>> On Fri, 16 Aug 2019 19:12:30 +0200 > > >>> Emmanuel Vadot >> wrote: > > >>> > > >>>> On Fri, 16 Aug 2019 17:10:37 +0200 > > >>>> Emmanuel Vadot > wrote: > > >>>> > > >>>>> On Fri, 16 Aug 2019 15:24:54 +0200 > > >>>>> Emmanuel Vadot > wrote: > > >>>>> > > >>>>>> On Fri, 16 Aug 2019 07:28:59 +0200 > > >>>>>> S=C3=B8ren Schmidt > wrote: > > >>>>>> > > >>>>>>> Hi > > >>>>>>> > > >>>>>>> Very simple, reverting sys/gnu/dts to what was before 350595 = (actually 350592). > > >>>>>>> Thats what we have svn for ? > > >>>>>> > > >>>>>> If I asked how it was to have the svn command that you used, = I want to > > >>>>>> make sure that you didn't revert anything else, like do you = have > > >>>>>> r350596 and r350628 ? > > >>>>>> > > >>>>>>> That does make my bananapi work again, no other changes just = a recompiled kernel. > > >>>>>> > > >>>>>> That + copying the dtb to the fat32 partition ? > > >>>>>> > > >>>>>> Can you post the dtb somewhere. > > >>>>>> > > >>>>>>> However it does not bring the Espressobin back to life, = thats something in one of the ~30 other files that changed between those = two revisions. > > >>>>>> > > >>>>>> What Linux version of DTS are you using then ? The ones that = were in > > >>>>>> stable/12 when it was branched (4.18) or a later revision ? > > >>>>> > > >>>>> So I think that I've found the problem on the Espressobin. > > >>>>> I think that the problem comes from the simple-mfd driver that = I've > > >>>>> mfc in r350600. > > >>>>> The pinctrl/gpio controller compatible is > > >>>>> "marvell,armada3710-nb-pinctrl", "syscon", "simple-mfd" and it = attaches > > >>>>> at BUS_PASS_INTERRUPT while the simple_mfd driver attaches at > > >>>>> BUS_PASS_BUS (so earlier) which means that no gpio controller = will be > > >>>>> available for sdhci to detect the card. > > >>>>> > > >>>>> If someone with a non-working espressobin could post a full = verbose > > >>>>> boot log that would help me confirming that this is the case. > > >>>>> I'll try to find a solution on how to solve this problem. > > >>>> > > >>>> So this wasn't the problem but I've found it, see r351129 and = r351130 > > >>>> > > >>>> SD card now work again in HEAD, I'll have a look at stable = later next > > >>>> week. > > >>> > > >>> I've did a quick test and I've MFC r348880, r348882 and r349596, = the > > >>> two other commits needed to be mfc'ed are the one I did today on = head, > > >>> I'll do that next week. > > >>> With them sdcard is working again on stable/12 > > >>> > > >>>>>>> -S=C3=B8ren > > >>>>>>> > > >>>>>>>> On 15 Aug 2019, at 23.37, Emmanuel Vadot = > wrote: > > >>>>>>>> > > >>>>>>>> On Thu, 15 Aug 2019 21:56:23 +0200 > > >>>>>>>> S=C3=B8ren Schmidt > wrote: > > >>>>>>>> > > >>>>>>>>> > > >>>>>>>>> Well, I don?t care where you are from and what color you = have :) > > >>>>>>>>> > > >>>>>>>>> Now, if I update my stable12 sources to r350595 the = bananapi breaks, if revert sys/gnu/dts it works again, go figure.. > > >>>>>>>> > > >>>>>>>> Reverting to what ? and how ? > > >>>>>>>> > > >>>>>>>> Because I've just test 12-stable and I have the problem = that I've said > > >>>>>>>> in my previous mail so setting = hw.regulator.disable_unused=3D0 is the > > >>>>>>>> work around. > > >>>>>>>> The problem is in twsi not in the DTS so I'm curious how = reverting > > >>>>>>>> only the dts fixes this problem. > > >>>>>>>> > > >>>>>>>>> The r351099 fix is already like that in -stable, and not = part of the problem. > > >>>>>>>>> > > >>>>>>>>> -S=C3=B8ren > > >>>>>>>> > > >>>>>>>>>> On 15 Aug 2019, at 21.03, Emmanuel Vadot = > wrote: > > >>>>>>>>>> > > >>>>>>>>>> On Thu, 15 Aug 2019 19:48:54 +0200 > > >>>>>>>>>> S=C3=B8ren Schmidt > wrote: > > >>>>>>>>>> > > >>>>>>>>>>> Hi Mit! > > >>>>>>>>>>> > > >>>>>>>>>>> Right, I suspected that, 12-stable broke many embedded = systems between r350592 and r350595 where all the latest and greatest = DTS files was pulled in, I guess the same holds for -current. > > >>>>>>>>>>> > > >>>>>>>>>>> -S=C3=B8ren > > >>>>>>>>>> > > >>>>>>>>>> Mhm it's fun that you think that DTS import is the source = of all your > > >>>>>>>>>> problems, I get it, it's easy to blame the French guy = that bulk import > > >>>>>>>>>> the DTS, he surely don't know what he is doing. > > >>>>>>>>>> Anyway, two problems were raised in this thread : > > >>>>>>>>>> > > >>>>>>>>>> 1) BananaPi (A20) doesn't boot > > >>>>>>>>>> 2) Espressobin sd support is broken > > >>>>>>>>>> > > >>>>>>>>>> I've just looked at the BananaPi problem today, I've = fixed a first > > >>>>>>>>>> problem in r351099. > > >>>>>>>>>> The main problem is that when we disable the unused = regulators we hang > > >>>>>>>>>> when trying to disabling ldo3. It's weird because the = board doesn't use > > >>>>>>>>>> LDO3 (which is why we are disabling it, it's unused). The = problem is in > > >>>>>>>>>> twsi I think as only leaving the part in axp209 that read = the > > >>>>>>>>>> voltage register value make FreeBSD hang. > > >>>>>>>>>> I'll have a proper look later, in the meantime you can = set > > >>>>>>>>>> hw.regulator.disable_unused=3D0 > > >>>>>>>>>> in /boot/loader.conf > > >>>>>>>>>> This isn't a DTS problem. > > >>>>>>>>>> > > >>>>>>>>>> For Espressobin I haven't found any thing related to SD = in the DTS > > >>>>>>>>>> updates since the import, the only things slighly related = are mmc and > > >>>>>>>>>> sdio. > > >>>>>>>>>> So if someone could find which DTS import broke this I = can have a look. > > >>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>>> On 15 Aug 2019, at 19.37, Mit Matelske > wrote: > > >>>>>>>>>>>> > > >>>>>>>>>>>> Yeah, that was the problem. I went back to r348882 and = everything worked out of the box. > > >>>>>>>>>>>> > > >>>>>>>>>>>> Thanks again for the hand holding! > > >>>>>>>>>>>> > > >>>>>>>>>>>> Mit > > >>>>>>>>>>>> > > >>>>>>>>>>>> From: "S=C3=B8ren Schmidt" >> > > >>>>>>>>>>>> To: "Mit Matelske" = >> > > >>>>>>>>>>>> Cc: "Marcin Wojtas" >>, "freebsd-arm" >> > > >>>>>>>>>>>> Sent: Wednesday, August 14, 2019 1:33:04 PM > > >>>>>>>>>>>> Subject: Re: Espressobin anyone ? > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> It might simply be broken in -current (again). > > >>>>>>>>>>>> > > >>>>>>>>>>>> I just updated my stable12 tree and I pulled in new = .dts files for just about anything? > > >>>>>>>>>>>> > > >>>>>>>>>>>> Needless to say, it broke the Espressobin?s SD support, = it now fails just like yours.. > > >>>>>>>>>>>> > > >>>>>>>>>>>> It also broke allwinner builds and what not, so I?m = just going back in time again :) > > >>>>>>>>>>>> > > >>>>>>>>>>>> I wonder why there is this overwhelming need to import = stuff that breaks things right, left and center in a -stable branch ? > > >>>>>>>>>>>> That would have earned you the pointy hat back when?. > > >>>>>>>>>>>> > > >>>>>>>>>>>> -S=C3=B8ren > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> On 14 Aug 2019, at 18.01, Mit Matelske >> wrote: > > >>>>>>>>>>>> > > >>>>>>>>>>>> Marcin- > > >>>>>>>>>>>> > > >>>>>>>>>>>> Sorry I didn't reply yesterday. I didn't have any luck = with that either. I tried a lot of permutations. > > >>>>>>>>>>>> > > >>>>>>>>>>>> Not saying for 100% it doesn't work, but I couldn't get = it to work! > > >>>>>>>>>>>> > > >>>>>>>>>>>> Mit > > >>>>>>>>>>>> > > >>>>>>>>>>>> From: "Marcin Wojtas" >> > > >>>>>>>>>>>> To: "Mit Matelske" = >> > > >>>>>>>>>>>> Cc: "S=C3=B8ren Schmidt" >>, "freebsd-arm" = = >> > > >>>>>>>>>>>> Sent: Wednesday, August 14, 2019 10:41:04 AM > > >>>>>>>>>>>> Subject: Re: Espressobin anyone ? > > >>>>>>>>>>>> > > >>>>>>>>>>>> Hi Mit, > > >>>>>>>>>>>> Since you are using the latest 13-current, could you = please try if passing rootdev via u-boot bootargs (please see my = previous email) works for you without the loader modification? > > >>>>>>>>>>>> > > >>>>>>>>>>>> Best regards, > > >>>>>>>>>>>> Marcin > > >>>>>>>>>>>> > > >>>>>>>>>>>> ?r., 14 sie 2019 o 16:29 Mit Matelske >> napisa?(a): > > >>>>>>>>>>>> Soren- > > >>>>>>>>>>>> > > >>>>>>>>>>>> Thanks for the info. I'll grab a couple more SD cards = at lunch. This one is a new Samsung 32GB. I'll also try putting the = changes into 12 and see if that helps. I'm using the latest 13-current. > > >>>>>>>>>>>> > > >>>>>>>>>>>> Again, appreciate the hand holding! > > >>>>>>>>>>>> > > >>>>>>>>>>>> Mit > > >>>>>>>>>>>> > > >>>>>>>>>>>> From: "S=C3=B8ren Schmidt" >> > > >>>>>>>>>>>> To: "Mit Matelske" = >> > > >>>>>>>>>>>> Cc: "Marcin Wojtas" >>, "freebsd-arm" >> > > >>>>>>>>>>>> Sent: Wednesday, August 14, 2019 2:30:31 AM > > >>>>>>>>>>>> Subject: Re: Espressobin anyone ? > > >>>>>>>>>>>> > > >>>>>>>>>>>> Hi Mit > > >>>>>>>>>>>> Hmm, from your earlier posted dmesgs it looks like the = SD card is not getting detected properly.. > > >>>>>>>>>>>> > > >>>>>>>>>>>> I get this output: > > >>>>>>>>>>>> > > >>>>>>>>>>>> sdhci_xenon0: mem = 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 > > >>>>>>>>>>>> mmc0: on sdhci_xenon0 > > >>>>>>>>>>>> ?snip? > > >>>>>>>>>>>> mmcsd0: 16GB at mmc0 50.0MHz/4bit/65535-block > > >>>>>>>>>>>> > > >>>>>>>>>>>> The problem you see was fixed for me by r348882, maybe = it got broken later, I havn?t backported the later changes.. > > >>>>>>>>>>>> > > >>>>>>>>>>>> Have you tried another SD card ? I have found 2 of mine = that the espressobin doesn?t like, but works fine with bananapi and = friends... > > >>>>>>>>>>>> > > >>>>>>>>>>>> -S=C3=B8ren > > >>>>>>>>>>>> > > >>>>>>>>>>>> On 13 Aug 2019, at 23.30, Mit Matelske >> wrote: > > >>>>>>>>>>>> > > >>>>>>>>>>>> Soren- > > >>>>>>>>>>>> > > >>>>>>>>>>>> Thanks for the code snippet! That will fix one of the = problems. > > >>>>>>>>>>>> > > >>>>>>>>>>>> I still can't mount my filesystem, though. I think I'm = doing something really simple, wrong. I believe I'm running the latest = code and added some printfs to show the kernel setting the regulator: > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> usbus1 on ehci0 > > >>>>>>>>>>>> syscon_generic4: mem 0x5f800-0x5ffff on = simplebus1 > > >>>>>>>>>>>> sdhci_xenon0: = regulator_get_by_ofw_property(vqmmc-supply) =3D 19 > > >>>>>>>>>>>> sdhci_xenon0: vqmmc-supply regulator found > > >>>>>>>>>>>> sdhci_xenon0: mem = 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 > > >>>>>>>>>>>> ahci0: mem 0xe0000-0xe0177 irq = 26 on simplebus1 > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> Could there be a problem with how I am setting up my = filesystem? I've tried both freebsd-ufs and freebsd as the type, with = no luck. A gpart listing of my SD card: > > >>>>>>>>>>>> > > >>>>>>>>>>>> root@fbl:~ # gpart list da3 > > >>>>>>>>>>>> Geom name: da3 > > >>>>>>>>>>>> modified: false > > >>>>>>>>>>>> state: OK > > >>>>>>>>>>>> fwheads: 255 > > >>>>>>>>>>>> fwsectors: 63 > > >>>>>>>>>>>> last: 62521335 > > >>>>>>>>>>>> first: 3 > > >>>>>>>>>>>> entries: 4 > > >>>>>>>>>>>> scheme: GPT > > >>>>>>>>>>>> Providers: > > >>>>>>>>>>>> 1. Name: da3p1 > > >>>>>>>>>>>> Mediasize: 41943040 (40M) > > >>>>>>>>>>>> Sectorsize: 512 > > >>>>>>>>>>>> Stripesize: 0 > > >>>>>>>>>>>> Stripeoffset: 1536 > > >>>>>>>>>>>> Mode: r0w0e0 > > >>>>>>>>>>>> efimedia: = HD(1,GPT,19894dc5-b8b2-11e9-871f-08008a0010e0,0x3,0x14000) > > >>>>>>>>>>>> rawuuid: 19894dc5-b8b2-11e9-871f-08008a0010e0 > > >>>>>>>>>>>> rawtype: c12a7328-f81f-11d2-ba4b-00a0c93ec93b > > >>>>>>>>>>>> label: (null) > > >>>>>>>>>>>> length: 41943040 > > >>>>>>>>>>>> offset: 1536 > > >>>>>>>>>>>> type: efi > > >>>>>>>>>>>> index: 1 > > >>>>>>>>>>>> end: 81922 > > >>>>>>>>>>>> start: 3 > > >>>>>>>>>>>> 2. Name: da3p2 > > >>>>>>>>>>>> Mediasize: 31968979456 (30G) > > >>>>>>>>>>>> Sectorsize: 512 > > >>>>>>>>>>>> Stripesize: 0 > > >>>>>>>>>>>> Stripeoffset: 41944576 > > >>>>>>>>>>>> Mode: r0w0e0 > > >>>>>>>>>>>> efimedia: = HD(2,GPT,98786462-be30-11e9-ae6e-08008a0010e0,0x14003,0x3b8bff5) > > >>>>>>>>>>>> rawuuid: 98786462-be30-11e9-ae6e-08008a0010e0 > > >>>>>>>>>>>> rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b > > >>>>>>>>>>>> label: (null) > > >>>>>>>>>>>> length: 31968979456 > > >>>>>>>>>>>> offset: 41944576 > > >>>>>>>>>>>> type: freebsd-ufs > > >>>>>>>>>>>> index: 2 > > >>>>>>>>>>>> end: 62521335 > > >>>>>>>>>>>> start: 81923 > > >>>>>>>>>>>> Consumers: > > >>>>>>>>>>>> 1. Name: da3 > > >>>>>>>>>>>> Mediasize: 32010928128 (30G) > > >>>>>>>>>>>> Sectorsize: 512 > > >>>>>>>>>>>> Mode: r0w0e0 > > >>>>>>>>>>>> > > >>>>>>>>>>>> Thanks!! > > >>>>>>>>>>>> > > >>>>>>>>>>>> Mit > > >>>>>>>>>>>> > > >>>>>>>>>>>> From: "S=C3=B8ren Schmidt" >> > > >>>>>>>>>>>> To: "Marcin Wojtas" >> > > >>>>>>>>>>>> Cc: "Mit Matelske" = >>, "freebsd-arm" = = >> > > >>>>>>>>>>>> Sent: Tuesday, August 13, 2019 12:55:09 PM > > >>>>>>>>>>>> Subject: Re: Espressobin anyone ? > > >>>>>>>>>>>> > > >>>>>>>>>>>> Hi > > >>>>>>>>>>>> That doesn?t seen to work on the espressobin, or least = I can?t get it to pick it up. > > >>>>>>>>>>>> > > >>>>>>>>>>>> I use this patch as a workaround: > > >>>>>>>>>>>> > > >>>>>>>>>>>> Index: main.c > > >>>>>>>>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >>>>>>>>>>>> --- main.c (revision 350496) > > >>>>>>>>>>>> +++ main.c (working copy) > > >>>>>>>>>>>> @@ -463,6 +462,13 @@ > > >>>>>>>>>>>> int rv; > > >>>>>>>>>>>> char *rootdev; > > >>>>>>>>>>>> > > >>>>>>>>>>>> +#if defined(__aarch64__) > > >>>>>>>>>>>> + /* SOS HACK in rootdev, at least Espressobin gets = this wrong */ > > >>>>>>>>>>>> + printf("Setting currdev hack\n"); > > >>>>>>>>>>>> + set_currdev("disk0p2"); > > >>>>>>>>>>>> + return (0); > > >>>>>>>>>>>> +#endif > > >>>>>>>>>>>> + > > >>>>>>>>>>>> /* > > >>>>>>>>>>>> * First choice: if rootdev is already set, use that, = even if > > >>>>>>>>>>>> * it's wrong. > > >>>>>>>>>>>> > > >>>>>>>>>>>> Its not pretty but it does the job until I get time to = look into why bootargs aren?t passed / won?t stick, probably something I = havn?t backported to my -stable12 sources yet... > > >>>>>>>>>>>> > > >>>>>>>>>>>> -S=C3=B8ren > > >>>>>>>>>>>> > > >>>>>>>>>>>> On 13 Aug 2019, at 01.38, Marcin Wojtas = >> wrote: > > >>>>>>>>>>>> > > >>>>>>>>>>>> Hi, > > >>>>>>>>>>>> > > >>>>>>>>>>>> Not sure if it's what you are looking for, but in order = to autoboot, I > > >>>>>>>>>>>> simply pass 'rootdev=3DdiskXpY' in the bootargs = variable. Here's example from > > >>>>>>>>>>>> A3720-DB (same should work on EspressoBin): > > >>>>>>>>>>>> > > >>>>>>>>>>>> Marvell>> set bootargs "rootdev=3Ddisk1p1";usb reset; = fatload usb 0:1 > > >>>>>>>>>>>> ${fdt_addr} armada-3720-db.dtb; fatload usb 0:1 = ${kernel_addr} > > >>>>>>>>>>>> boot/loader.efi; bootefi ${kernel_addr} ${fdt_addr} > > >>>>>>>>>>>> resetting USB... > > >>>>>>>>>>>> USB0: Register 2000104 NbrPorts 2 > > >>>>>>>>>>>> Starting the controller > > >>>>>>>>>>>> USB XHCI 1.00 > > >>>>>>>>>>>> USB1: USB EHCI 1.00 > > >>>>>>>>>>>> - ______ ____ _____ _____ > > >>>>>>>>>>>> | ____| | _ \ / ____| __ \ > > >>>>>>>>>>>> | |___ _ __ ___ ___ | |_) | (___ | | | | > > >>>>>>>>>>>> | ___| '__/ _ \/ _ \| _ < \___ \| | | | > > >>>>>>>>>>>> | | | | | __/ __/| |_) |____) | |__| | > > >>>>>>>>>>>> | | | | | | || | | | > > >>>>>>>>>>>> |_| |_| \___|\___||____/|_____/|_____/ > > >>>>>>>>>>>> ``` > > >>>>>>>>>>>> ` > > >>>>>>>>>>>> ????????????Welcome to FreeBSD????????????? s` = `.....---.......--.``` > > >>>>>>>>>>>> -/ > > >>>>>>>>>>>> ? ? +o = .--` /y:` > > >>>>>>>>>>>> +. > > >>>>>>>>>>>> ? 1. Boot Multi user [Enter] ? yo`:. = :o > > >>>>>>>>>>>> `+- > > >>>>>>>>>>>> ? 2. Boot Single user ? y/ = -/` -o/ > > >>>>>>>>>>>> ? 3. Escape to loader prompt ? .- > > >>>>>>>>>>>> ::/sy+:. > > >>>>>>>>>>>> ? 4. Reboot ? / = `-- > > >>>>>>>>>>>> / > > >>>>>>>>>>>> ? ? `: > > >>>>>>>>>>>> :` > > >>>>>>>>>>>> ? Options: ? `: > > >>>>>>>>>>>> :` > > >>>>>>>>>>>> ? 5. Kernel: default/kernel (1 of 1) ? / > > >>>>>>>>>>>> / > > >>>>>>>>>>>> ? 6. Boot Options ? .- > > >>>>>>>>>>>> -. > > >>>>>>>>>>>> ? ? -- = -. > > >>>>>>>>>>>> ? ? `:` = `:` > > >>>>>>>>>>>> ? ? .-- = `--. > > >>>>>>>>>>>> ??????????????????????????????????????????? = .---.....----. > > >>>>>>>>>>>> Autoboot in 9 seconds, hit [Enter] to boot or any other = key to stop > > >>>>>>>>>>>> > > >>>>>>>>>>>> Loading kernel... > > >>>>>>>>>>>> /boot/kernel/kernel text=3D0x95047c = data=3D0x1919d0+0x84aa94 > > >>>>>>>>>>>> syms=3D[0x8+0x13aaa8+0x8+0x12610d] > > >>>>>>>>>>>> Loading configured modules... > > >>>>>>>>>>>> can't find '/boot/entropy' > > >>>>>>>>>>>> Using DTB provided by EFI at 0x8000000. > > >>>>>>>>>>>> ---<>--- > > >>>>>>>>>>>> KDB: debugger backends: ddb > > >>>>>>>>>>>> KDB: current backend: ddb > > >>>>>>>>>>>> Copyright (c) 1992-2019 The FreeBSD Project. > > >>>>>>>>>>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, = 1992, 1993, 1994 > > >>>>>>>>>>>> The Regents of the University of California. All rights = reserved. > > >>>>>>>>>>>> FreeBSD is a registered trademark of The FreeBSD = Foundation. > > >>>>>>>>>>>> FreeBSD 13.0-CURRENT = 17a1fc80d57-c261519(upstream_master) GENERIC arm64 > > >>>>>>>>>>>> FreeBSD clang version 8.0.0 (tags/RELEASE_800/final = 356365) (based on LLVM > > >>>>>>>>>>>> 8.0.0) > > >>>>>>>>>>>> WARNING: WITNESS option enabled, expect reduced = performance. > > >>>>>>>>>>>> VT: init without driver. > > >>>>>>>>>>>> Starting CPU 1 (1) > > >>>>>>>>>>>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > >>>>>>>>>>>> [...] > > >>>>>>>>>>>> > > >>>>>>>>>>>> Best regards, > > >>>>>>>>>>>> Marcin > > >>>>>>>>>>>> > > >>>>>>>>>>>> pon., 12 sie 2019 o 23:14 Mit Matelske >> napisa?(a): > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> Soren- > > >>>>>>>>>>>> > > >>>>>>>>>>>> Thanks for the quick response. I built this kernel = with revision 350924. > > >>>>>>>>>>>> I'll dig into whats going on in the morning. > > >>>>>>>>>>>> > > >>>>>>>>>>>> Mind posting your diff for your loader.efi? > > >>>>>>>>>>>> > > >>>>>>>>>>>> Thanks again! > > >>>>>>>>>>>> > > >>>>>>>>>>>> Mit > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> ----- Original Message ----- > > >>>>>>>>>>>> From: "S=C3=B8ren Schmidt" >> > > >>>>>>>>>>>> To: "Mit Matelske" = >> > > >>>>>>>>>>>> Cc: "tscho" >>, "freebsd-arm" < > > >>>>>>>>>>>> freebsd-arm@freebsd.org = >> > > >>>>>>>>>>>> Sent: Monday, August 12, 2019 3:49:48 PM > > >>>>>>>>>>>> Subject: Re: Espressobin anyone ? > > >>>>>>>>>>>> > > >>>>>>>>>>>> Hi > > >>>>>>>>>>>> > > >>>>>>>>>>>> Looks like your sources may be too old, you need to be = at least at r348882 > > >>>>>>>>>>>> to get the fix for the SD card VCC regulator. > > >>>>>>>>>>>> > > >>>>>>>>>>>> That change fixed it for me backported to 12-stable... > > >>>>>>>>>>>> > > >>>>>>>>>>>> The currdev problem still exists, I have it hardwired = in my loader for > > >>>>>>>>>>>> aarch64 :) > > >>>>>>>>>>>> > > >>>>>>>>>>>> -S=C3=B8ren > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> On 12 Aug 2019, at 21.06, Mit Matelske >> wrote: > > >>>>>>>>>>>> > > >>>>>>>>>>>> I'm having a couple little hiccups booting this board = also. One has > > >>>>>>>>>>>> been commented on already, that I can't get the loader = to automatically > > >>>>>>>>>>>> start loading the kernel on "disk0p2"... > > >>>>>>>>>>>> > > >>>>>>>>>>>> The second, is that the kernel can't find the SD card = after booting so > > >>>>>>>>>>>> it can't mount the root filesystem. I'm using the = dts/dtb and kernel from > > >>>>>>>>>>>> the 13-current branch. > > >>>>>>>>>>>> > > >>>>>>>>>>>> Thanks for any and all help. I haven't used u-boot in = about decade. > > >>>>>>>>>>>> Spoiled by the x86 platform. > > >>>>>>>>>>>> > > >>>>>>>>>>>> Mit Matelske > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> ***U-boot environment:*** > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> Marvell>> printenv > > >>>>>>>>>>>> baudrate=3D115200 > > >>>>>>>>>>>> bootargs=3Dconsole=3DttyMV0,115200 = earlycon=3Dar3700_uart,0xd0012000 > > >>>>>>>>>>>> root=3D/dev/mmcblk0p1 rw rootwait net.ifnames=3D0 = biosdevname=3D0 > > >>>>>>>>>>>> bootcmd=3Dmmc dev 0; fatload mmc 0:1 $kernel_addr = $image_name;fatload mmc > > >>>>>>>>>>>> 0:1 $fdt_addr $fdt_name; bootefi $kernel_addr $fdt_addr > > >>>>>>>>>>>> bootdelay=3D2 > > >>>>>>>>>>>> bootmmc=3Dmmc dev 0; fatload mmc 0:1 $kernel_addr = $image_name;fatload mmc > > >>>>>>>>>>>> 0:1 $fdt_addr $fdt_name; bootefi $kernel_addr $fdt_addr > > >>>>>>>>>>>> console=3Dconsole=3DttyMV0,115200 = earlycon=3Dar3700_uart,0xd0012000 > > >>>>>>>>>>>> eth1addr=3D00:51:82:11:22:01 > > >>>>>>>>>>>> eth2addr=3D00:51:82:11:22:02 > > >>>>>>>>>>>> eth3addr=3D00:51:82:11:22:03 > > >>>>>>>>>>>> ethact=3Dneta@30000 > > >>>>>>>>>>>> ethaddr=3DF0:AD:4E:09:6B:8F > > >>>>>>>>>>>> ethprime=3Deth0 > > >>>>>>>>>>>> fdt_addr=3D0x4f00000 > > >>>>>>>>>>>> fdt_high=3D0xffffffffffffffff > > >>>>>>>>>>>> fdt_name=3Defi/boot/armada-3720-espressobin.dtb > > >>>>>>>>>>>> fdtcontroladdr=3D3f7161b8 > > >>>>>>>>>>>> gatewayip=3D10.4.50.254 > > >>>>>>>>>>>> get_images=3Dtftpboot $kernel_addr $image_name; = tftpboot $fdt_addr > > >>>>>>>>>>>> $fdt_name; run get_ramfs > > >>>>>>>>>>>> get_ramfs=3Dif test "${ramfs_name}" !=3D "-"; then = setenv ramfs_addr > > >>>>>>>>>>>> 0x8000000; tftpboot $ramfs_addr $ramfs_name; else = setenv ramfs_addr -;fi > > >>>>>>>>>>>> hostname=3Dmarvell > > >>>>>>>>>>>> image_name=3Defi/freebsd/loader.efi > > >>>>>>>>>>>> initrd_addr=3D0xa00000 > > >>>>>>>>>>>> initrd_size=3D0x2000000 > > >>>>>>>>>>>> ipaddr=3D0.0.0.0 > > >>>>>>>>>>>> kernel_addr=3D0x5000000 > > >>>>>>>>>>>> loadaddr=3D0x5000000 > > >>>>>>>>>>>> netdev=3Deth0 > > >>>>>>>>>>>> netmask=3D255.255.255.0 > > >>>>>>>>>>>> ramfs_addr=3D0x8000000 > > >>>>>>>>>>>> ramfs_name=3D- > > >>>>>>>>>>>> root=3Droot=3D/dev/nfs rw > > >>>>>>>>>>>> rootpath=3D/srv/nfs/ > > >>>>>>>>>>>> serverip=3D0.0.0.0 > > >>>>>>>>>>>> set_bootargs=3Dsetenv bootargs $console $root > > >>>>>>>>>>>> = ip=3D$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:none > > >>>>>>>>>>>> nfsroot=3D$serverip:$rootpath $extra_params > > >>>>>>>>>>>> stderr=3Dserial@12000 > > >>>>>>>>>>>> stdin=3Dserial@12000 > > >>>>>>>>>>>> stdout=3Dserial@12000 > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> ***Full boot logs:*** > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> U-Boot 2017.03-armada-17.10.2-g14aeedc (Jun 01 2018 - = 15:39:10 +0800) > > >>>>>>>>>>>> > > >>>>>>>>>>>> Model: Marvell Armada 3720 Community Board ESPRESSOBin > > >>>>>>>>>>>> CPU @ 1000 [MHz] > > >>>>>>>>>>>> L2 @ 800 [MHz] > > >>>>>>>>>>>> TClock @ 200 [MHz] > > >>>>>>>>>>>> DDR @ 800 [MHz] > > >>>>>>>>>>>> DRAM: 1 GiB > > >>>>>>>>>>>> U-Boot DT blob at : 000000003f7161b8 > > >>>>>>>>>>>> Comphy-0: USB3 5 Gbps > > >>>>>>>>>>>> Comphy-1: PEX0 2.5 Gbps > > >>>>>>>>>>>> Comphy-2: SATA0 6 Gbps > > >>>>>>>>>>>> SATA link 0 timeout. > > >>>>>>>>>>>> AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA = mode > > >>>>>>>>>>>> flags: ncq led only pmp fbss pio slum part sxs > > >>>>>>>>>>>> PCIE-0: Link down > > >>>>>>>>>>>> MMC: sdhci@d0000: 0, sdhci@d8000: 1 > > >>>>>>>>>>>> SF: Detected mx25u3235f with page size 256 Bytes, erase = size 64 KiB, > > >>>>>>>>>>>> total 4 MiB > > >>>>>>>>>>>> Net: eth0: neta@30000 [PRIME] > > >>>>>>>>>>>> Hit any key to stop autoboot: 0 > > >>>>>>>>>>>> switch to partitions #0, OK > > >>>>>>>>>>>> mmc0 is current device > > >>>>>>>>>>>> reading efi/freebsd/loader.efi > > >>>>>>>>>>>> 603872 bytes read in 49 ms (11.8 MiB/s) > > >>>>>>>>>>>> reading efi/boot/armada-3720-espressobin.dtb > > >>>>>>>>>>>> 15946 bytes read in 17 ms (916 KiB/s) > > >>>>>>>>>>>> ## Starting EFI application at 05000000 ... > > >>>>>>>>>>>> Scanning disk sdhci@d0000.blk >... > > >>>>>>>>>>>> Card did not respond to voltage select! > > >>>>>>>>>>>> mmc_init: -95, time 50 > > >>>>>>>>>>>> Found 1 disks > > >>>>>>>>>>>> Consoles: EFI console > > >>>>>>>>>>>> FreeBSD/arm64 EFI loader, Revision 1.1 > > >>>>>>>>>>>> > > >>>>>>>>>>>> Command line arguments: loader.efi > > >>>>>>>>>>>> EFI version: 2.05 > > >>>>>>>>>>>> EFI Firmware: Das U-boot (rev 0.00) > > >>>>>>>>>>>> Console: efi (0) > > >>>>>>>>>>>> Failed to find bootable partition > > >>>>>>>>>>>> Startup error in /boot/lua/loader.lua: seconds > > >>>>>>>>>>>> LUA ERROR: cannot open /boot/lua/loader.lua: invalid = argument. > > >>>>>>>>>>>> > > >>>>>>>>>>>> can't load 'kernel' > > >>>>>>>>>>>> > > >>>>>>>>>>>> Type '?' for a list of commands, 'help' for more = detailed help. > > >>>>>>>>>>>> OK > > >>>>>>>>>>>> OK set currdev=3Ddisk0p2 > > >>>>>>>>>>>> OK boot > > >>>>>>>>>>>> > > >>>>>>>>>>>> /boot/kernel/kernel text=3D0x97d6a0 = data=3D0x191b50+0x84ae94 > > >>>>>>>>>>>> syms=3D[0x8+0x137dd8+0x8+0x126260] > > >>>>>>>>>>>> Using DTB provided by EFI at 0x8000000. > > >>>>>>>>>>>> ---<>--- > > >>>>>>>>>>>> KDB: debugger backends: ddb > > >>>>>>>>>>>> KDB: current backend: ddb > > >>>>>>>>>>>> Copyright (c) 1992-2019 The FreeBSD Project. > > >>>>>>>>>>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, = 1992, 1993, 1994 > > >>>>>>>>>>>> The Regents of the University of California. All = rights reserved. > > >>>>>>>>>>>> FreeBSD is a registered trademark of The FreeBSD = Foundation. > > >>>>>>>>>>>> FreeBSD 13.0-CURRENT GENERIC arm64 > > >>>>>>>>>>>> FreeBSD clang version 6.0.1 (tags/RELEASE_601/final = 335540) (based on > > >>>>>>>>>>>> LLVM 6.0.1) > > >>>>>>>>>>>> WARNING: WITNESS option enabled, expect reduced = performance. > > >>>>>>>>>>>> VT: init without driver. > > >>>>>>>>>>>> Starting CPU 1 (1) > > >>>>>>>>>>>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > >>>>>>>>>>>> arc4random: WARNING: initial seeding bypassed the = cryptographic random > > >>>>>>>>>>>> device because it was not yet seeded and the knob = 'bypass_before_seeding' > > >>>>>>>>>>>> was enabled. > > >>>>>>>>>>>> random: entropy device external interface > > >>>>>>>>>>>> MAP 3e681000 mode 2 pages 1 > > >>>>>>>>>>>> MAP 3ffa6000 mode 2 pages 1 > > >>>>>>>>>>>> kbd0 at kbdmux0 > > >>>>>>>>>>>> ofwbus0: > > >>>>>>>>>>>> simplebus0: on = ofwbus0 > > >>>>>>>>>>>> simplebus1: on = simplebus0 > > >>>>>>>>>>>> simple_mfd0: mem > > >>>>>>>>>>>> 0x13800-0x138ff,0x13c00-0x13c1f on simplebus1 > > >>>>>>>>>>>> simple_mfd1: mem > > >>>>>>>>>>>> 0x18800-0x188ff,0x18c00-0x18c1f on simplebus1 > > >>>>>>>>>>>> psci0: = on ofwbus0 > > >>>>>>>>>>>> gic0: mem > > >>>>>>>>>>>> = 0x1d00000-0x1d0ffff,0x1d40000-0x1d7ffff,0x1d80000-0x1d81fff,0x1d90000-0x1d= 91fff,0x1da0000-0x1dbffff > > >>>>>>>>>>>> irq 27 on simplebus1 > > >>>>>>>>>>>> gpio0: 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: 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: on ofwbus0 > > >>>>>>>>>>>> gpioregulator0: cannot get pin 0 > > >>>>>>>>>>>> gpioregulator0: cannot parse parameters > > >>>>>>>>>>>> device_attach: gpioregulator0 attach returned 6 > > >>>>>>>>>>>> generic_timer0: irq 0,1,2,3 on = ofwbus0 > > >>>>>>>>>>>> Timecounter "ARM MPCore Timecounter" frequency 12500000 = Hz quality 1000 > > >>>>>>>>>>>> Event timer "ARM MPCore Eventtimer" frequency 12500000 = Hz quality 1000 > > >>>>>>>>>>>> gpio0: 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: 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: on ofwbus0 > > >>>>>>>>>>>> gpioregulator0: cannot get pin 0 > > >>>>>>>>>>>> gpioregulator0: cannot parse parameters > > >>>>>>>>>>>> device_attach: gpioregulator0 attach returned 6 > > >>>>>>>>>>>> gpio0: 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: 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: on ofwbus0 > > >>>>>>>>>>>> gpioregulator0: cannot get pin 0 > > >>>>>>>>>>>> gpioregulator0: cannot parse parameters > > >>>>>>>>>>>> device_attach: gpioregulator0 attach returned 6 > > >>>>>>>>>>>> gpio0: 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: 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: on ofwbus0 > > >>>>>>>>>>>> gpioregulator0: cannot get pin 0 > > >>>>>>>>>>>> gpioregulator0: cannot parse parameters > > >>>>>>>>>>>> device_attach: gpioregulator0 attach returned 6 > > >>>>>>>>>>>> gpio0: 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: 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: on ofwbus0 > > >>>>>>>>>>>> gpioregulator0: cannot get pin 0 > > >>>>>>>>>>>> gpioregulator0: cannot parse parameters > > >>>>>>>>>>>> device_attach: gpioregulator0 attach returned 6 > > >>>>>>>>>>>> cpulist0: on ofwbus0 > > >>>>>>>>>>>> cpu0: on cpulist0 > > >>>>>>>>>>>> cpu1: on cpulist0 > > >>>>>>>>>>>> pmu0: irq 4 on ofwbus0 > > >>>>>>>>>>>> syscon_generic0: mem 0xd000-0xdfff on = simplebus1 > > >>>>>>>>>>>> syscon_generic1: mem 0x11500-0x1153f on = simplebus1 > > >>>>>>>>>>>> uart0: mem 0x12000-0x121ff = irq 9,10,11 on > > >>>>>>>>>>>> simplebus1 > > >>>>>>>>>>>> uart0: console (115200,n,8,1) > > >>>>>>>>>>>> gpio0: 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: mem 0x14000-0x1405f on = simplebus1 > > >>>>>>>>>>>> gpio0: 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: mem 0x30000-0x33fff irq 14 = on simplebus1 > > >>>>>>>>>>>> mvneta0: version is 10 > > >>>>>>>>>>>> mvneta0: Ethernet address: 00:a6:39:ca:e8:00 > > >>>>>>>>>>>> mdio0: on mvneta0 > > >>>>>>>>>>>> mdioproxy0: on mdio0 > > >>>>>>>>>>>> e6000sw0: on mdio0 > > >>>>>>>>>>>> e6000sw0: multi-chip addressing mode (0x1) > > >>>>>>>>>>>> e6000sw0: CPU port at 0 > > >>>>>>>>>>>> e6000sw0: fixed port at 0 > > >>>>>>>>>>>> e6000sw0: PHY at port 1 > > >>>>>>>>>>>> miibus0: on e6000sw0 > > >>>>>>>>>>>> e1000phy0: 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: on e6000sw0 > > >>>>>>>>>>>> e1000phy1: 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: on e6000sw0 > > >>>>>>>>>>>> e1000phy2: 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: on e6000sw0 > > >>>>>>>>>>>> xhci0: mem 0x58000-0x5bfff = irq 16 on > > >>>>>>>>>>>> simplebus1 > > >>>>>>>>>>>> xhci0: 32 bytes context size, 32-bit DMA > > >>>>>>>>>>>> usbus0 on xhci0 > > >>>>>>>>>>>> syscon_generic3: mem 0x5d800-0x5dfff on = simplebus1 > > >>>>>>>>>>>> ehci0: mem = 0x5e000-0x5efff irq > > >>>>>>>>>>>> 17 on simplebus1 > > >>>>>>>>>>>> usbus1: EHCI version 1.0 > > >>>>>>>>>>>> usbus1 on ehci0 > > >>>>>>>>>>>> syscon_generic4: mem 0x5f800-0x5ffff on = simplebus1 > > >>>>>>>>>>>> sdhci_xenon0: mem > > >>>>>>>>>>>> 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 > > >>>>>>>>>>>> ahci0: mem 0xe0000-0xe0177 irq = 26 on simplebus1 > > >>>>>>>>>>>> ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier = supported with FBS > > >>>>>>>>>>>> ahcich0: at channel 0 on ahci0 > > >>>>>>>>>>>> device_attach: ahcich0 attach returned 6 > > >>>>>>>>>>>> gpioregulator0: on ofwbus0 > > >>>>>>>>>>>> gpioregulator0: cannot get pin 0 > > >>>>>>>>>>>> gpioregulator0: cannot parse parameters > > >>>>>>>>>>>> device_attach: gpioregulator0 attach returned 6 > > >>>>>>>>>>>> cryptosoft0: > > >>>>>>>>>>>> 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 = > > >>>>>>>>>>>> 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 > > >>>>>>>>>>>> > > >>>>>>>>>>>> usbus1 Processor Features 1 =3D <0> > > >>>>>>>>>>>> usbus0 Memory Model Features 0 =3D <4k Granule,64k = Granule,S/NS > > >>>>>>>>>>>> Mem,MixedEndian,16bit ASID,1TB PA> > > >>>>>>>>>>>> > > >>>>>>>>>>>> Memory Model Features 1 =3D <> > > >>>>>>>>>>>> Memory Model Features 2 =3D <32b CCIDX,48b VA> > > >>>>>>>>>>>> Debug Features 0 =3D <2 CTX Breakpoints,4 = Watchpoints,6 > > >>>>>>>>>>>> Breakpoints,PMUv3,Debug v8> > > >>>>>>>>>>>> Debug Features 1 =3D <0> > > >>>>>>>>>>>> Auxiliary Features 0 =3D <0> > > >>>>>>>>>>>> Auxiliary Features 1 =3D <0> > > >>>>>>>>>>>> CPU 1: ARM Cortex-A53 r0p4 affinity: 1 > > >>>>>>>>>>>> WARNING: WITNESS option enabled, expect reduced = performance. > > >>>>>>>>>>>> ugen0.1: at usbus0 > > >>>>>>>>>>>> ugen1.1: at usbus1 > > >>>>>>>>>>>> uhub0 on usbus0 > > >>>>>>>>>>>> uhub1 on usbus1 > > >>>>>>>>>>>> uhub0: on > > >>>>>>>>>>>> usbus0 > > >>>>>>>>>>>> uhub1: on > > >>>>>>>>>>>> usbus1 > > >>>>>>>>>>>> uhub0: 2 ports with 2 removable, self powered > > >>>>>>>>>>>> uhub1: 1 port with 1 removable, self powered > > >>>>>>>>>>>> mountroot: waiting for device = /dev/ufs/FreeBSD_Install... > > >>>>>>>>>>>> Mounting from ufs:/dev/ufs/FreeBSD_Install failed with = error 19. > > >>>>>>>>>>>> > > >>>>>>>>>>>> Loader variables: > > >>>>>>>>>>>> vfs.root.mountfrom=3Dufs:/dev/ufs/FreeBSD_Install > > >>>>>>>>>>>> vfs.root.mountfrom.options=3Dro,noatime > > >>>>>>>>>>>> > > >>>>>>>>>>>> Manual root filesystem specification: > > >>>>>>>>>>>> : [options] > > >>>>>>>>>>>> Mount using filesystem > > >>>>>>>>>>>> and with the specified (optional) option list. > > >>>>>>>>>>>> > > >>>>>>>>>>>> eg. ufs:/dev/da0s1a > > >>>>>>>>>>>> zfs:zroot/ROOT/default > > >>>>>>>>>>>> cd9660:/dev/cd0 ro > > >>>>>>>>>>>> (which is equivalent to: mount -t cd9660 -o ro = /dev/cd0 /) > > >>>>>>>>>>>> > > >>>>>>>>>>>> ? List valid disk boot devices > > >>>>>>>>>>>> . Yield 1 second (for background tasks) > > >>>>>>>>>>>> Abort manual input > > >>>>>>>>>>>> > > >>>>>>>>>>>> mountroot> ? > > >>>>>>>>>>>> > > >>>>>>>>>>>> List of GEOM managed disk devices: > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> mountroot> > > >>>>>>>>>>>> _______________________________________________ > > >>>>>>>>>>>> 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 = = >" > > >>>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> -- > > >>>>>>>>>> Emmanuel Vadot > > > > >>>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> -- > > >>>>>>>> Emmanuel Vadot > > > > >>>>>> > > >>>>>> > > >>>>>> -- > > >>>>>> Emmanuel Vadot > > > > >>>>>> _______________________________________________ > > >>>>>> freebsd-arm@freebsd.org = mailing list > > >>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm = > > >>>>>> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org = " > > >>>>> > > >>>>> > > >>>>> -- > > >>>>> Emmanuel Vadot > > > > >>>>> _______________________________________________ > > >>>>> freebsd-arm@freebsd.org = mailing list > > >>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm = > > >>>>> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org = " > > >>>> > > >>>> > > >>>> -- > > >>>> Emmanuel Vadot > > > > >>>> _______________________________________________ > > >>>> freebsd-arm@freebsd.org = mailing list > > >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm = > > >>>> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org = " > > >>> > > >>> > > >>> -- > > >>> Emmanuel Vadot >> >> > > >> > > > > > > > > > -- > > > Emmanuel Vadot >> >> > > >=20 >=20 > -- > Emmanuel Vadot > = > > _______________________________________________ > 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 = " --Apple-Mail=_BE762473-F918-4384-9DC1-E0188BF0465B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEkC0kEuD0Me2xEj5EGvRMAY4qbRsFAl1ZJD8ACgkQGvRMAY4q bRsiNQ//fl+sIYBvuNDmbkNBX90AHB8WApM3m0Vm9pvcQy7GmEGipVBK+L6r7YNG 41j0dAPzc1hsxhKTxQWNKna1zW4CiRtGVID1P7IcX0KGU0MdegH3bQ5qNTQ2Rpt2 ILT0H1whZwf3XImPxU/VHtLkyPHaDXdbroTa1sX6o+2H/VvQugXaDyBwVeJoMSZ3 7iAD8MLcCT7jdyjZU0vyky2NETWL4ruK2GNwN1McDVYB6UoPPpDBF+0CuSpF4x+Y w71MGQqn4xLcTWyj7F73xjkwDGV22tEY5OcET+/ZDwgVbocCgnhCsKVHeUzTEZjC S5dXjFNrvHFnGb5PAx/QeE9CEor1Dw8348Agba+0vytVleCFVP7/GsbuUFttPQ83 EVyPIUYxIE4vPvLOOvUnolUcsMb8+QrGXsCyAws+48y4DV0wPbLwl9ZAXRiALkAF F8pFqYo4xZ+QOJSyj8isccbw2W3df/vCqC+eUAOylYD5ldALZoL6KFHkdMT1HkRt Q1ubIhfvWrUbMb6AIv6Ypm2z4GBErfxUQYc+S/sSJvwNPA3T45cai+FX17W3Fv4G gNp7N8MkFU5mwMDjns3f2hJKgv8t2Bex1WGkiXtrEmvqU9ss6a2iEI7ANkB2dZPZ sTTR/P0AmoaZDBqHogoYycvZqAxITLGIm501yIou3BipMJBoyLI= =HXQr -----END PGP SIGNATURE----- --Apple-Mail=_BE762473-F918-4384-9DC1-E0188BF0465B-- From owner-freebsd-arm@freebsd.org Sun Aug 18 10:17:56 2019 Return-Path: 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 05002C31B5 for ; Sun, 18 Aug 2019 10:17:56 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46BCg54JLRz4NP4 for ; Sun, 18 Aug 2019 10:17:52 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan) by mailhost.netlabit.sk with ESMTPA; Sun, 18 Aug 2019 12:17:50 +0200 id 00F406D8.5D5925CE.00004325 Date: Sun, 18 Aug 2019 12:17:41 +0200 From: Milan Obuch To: freebsd-arm@freebsd.org Subject: Zynq qspi driver https://reviews.freebsd.org/D14698 Message-ID: <20190818121741.7bd82a63@zeta.dino.sk> X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; i386-portbld-freebsd11.3) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46BCg54JLRz4NP4 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-arm@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-arm@dino.sk X-Spamd-Result: default: False [-5.26 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; URL_IN_SUBJECT(1.00)[reviews.freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[dino.sk]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.983,0]; RCVD_IN_DNSWL_NONE(0.00)[72.65.245.84.list.dnswl.org : 127.0.10.0]; IP_SCORE(-2.97)[ip: (-8.36), ipnet: 84.245.64.0/18(-4.18), asn: 16160(-2.42), country: SK(0.09)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16160, ipnet:84.245.64.0/18, country:SK]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2019 10:17:56 -0000 Hi, I was able to use in subject mentioned driver on my Zybo Z7 board. I just downloaded zy7_qspi.c file, put it in sys/arm/xilinx directory and all other necessary patches applied per hand to 12.0-STABLE source tree. I am able to read and write flash attached to qspi on my board. u-boot uses qspi flash for environment storage so some caution should be taken with that. Question: what needs to be done in order to get this driver into official source tree? Is there any show stopper? My experience is - it Just Works (tm). Regards, Milan From owner-freebsd-arm@freebsd.org Sun Aug 18 12:54:23 2019 Return-Path: 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 6775CC6D3B for ; Sun, 18 Aug 2019 12:54:23 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 46BH7f5QvDz4W8s for ; Sun, 18 Aug 2019 12:54:22 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.nyi.freebsd.org (Postfix) id B855EC6D3A; Sun, 18 Aug 2019 12:54:22 +0000 (UTC) Delivered-To: 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 B6DBFC6D39 for ; Sun, 18 Aug 2019 12:54:22 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46BH7c65Xpz4W8r for ; Sun, 18 Aug 2019 12:54:20 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type:Message-Id:From; bh=cLszyIzz7Q/gz6hrTxs5WkW7BcImmI3J/qJrr3eC8j4=; b=jQGsYjVgzPDJnmBXt7QUuSFBWCyOPRp2jdguIdIALtO/3hxse73pV6jOs+xTK4inckohQJHlmrLsXRuUGp5VS0S/0nrscdTpkZMEB47C7EFhVcV0Be8F+tyLtSuX4PWsYjrInusvSPJw5f5KqHrH4QWsYMQ+WU+2JCxLcWVUrFU000Cwa2mXL/pzVF/vcLVng5CfVK8JV45j0Bx9d3EnIffJY+iNrwuMLl/Was4JfCoY57k8ha1TJqZ8QieDM7rfOja++GEK6MZhL3xkl0EsLRvq/sbKKc54LGmyAMwESgoLNY5QSMoAbxTtkAWmD1NSE1HAPDggxidbwrcmRvTfKg==; Received: from macmini.bk.cs.huji.ac.il ([132.65.179.19]) by kabab.cs.huji.ac.il with esmtp id 1hzKhL-000JmQ-V7; Sun, 18 Aug 2019 15:54:16 +0300 From: Daniel Braniss Message-Id: <272A8B27-55B4-4145-9569-78CB2ED7A58D@cs.huji.ac.il> Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: boot hangs in nanopi-neo Date: Sun, 18 Aug 2019 15:54:15 +0300 In-Reply-To: Cc: "freebsd-arm@freebsd.org" To: Emmanuel Vadot References: <116689BE-9231-4591-BFBB-8E823931D2D2@cs.huji.ac.il> <20190817203259.e028141082262cd0dda70c68@bidouilliste.com> X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 46BH7c65Xpz4W8r X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=jQGsYjVg; dmarc=none; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il X-Spamd-Result: default: False [-2.90 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.996,0]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-0.996,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[huji.ac.il]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[210.116.65.132.list.dnswl.org : 127.0.10.0]; NEURAL_HAM_SHORT(-0.83)[-0.829,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/13, country:IL]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-0.28)[ipnet: 132.64.0.0/13(-0.79), asn: 378(-0.63), country: IL(0.05)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2019 12:54:23 -0000 > On 18 Aug 2019, at 10:47, Daniel Braniss wrote: >=20 >=20 >=20 >> On 17 Aug 2019, at 21:32, Emmanuel Vadot = wrote: >>=20 >> On Sat, 17 Aug 2019 19:55:13 +0300 >> Daniel Braniss wrote: >>=20 >>> after some months, I decided to upgrade, but now it stucks here: >>> ? >>>=20 >>> FreeBSD 13.0-CURRENT #13 r351126M: Sat Aug 17 13:19:09 IDT 2019 >>> = danny@pe-44:/home/obj/pe-44/arm/neo/r+d/vanilla/13/arm.armv7/r+d/vanilla/1= 3/sys/AWG arm >>> FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based = on LLVM 8.0.1) >>> WARNING: WITNESS option enabled, expect reduced performance. >>> ? >>>=20 >>> hub3: on = usbus3 >>> mmcsd0: 8GB at mmc0 = 50.0MHz/4bit/32768-block >>> Release A >>>=20 >>> at which point it hangs solid. >>>=20 >>> BTW, I installed a newer u-boot (maybe it?s not the very latest) >>>=20 >>> this is the full console output: >>>=20 >>> USB Device(s) found >>> scanning bus 1 for devices... 1 USB Device(s) found >>> scanning bus 2 for devices... 1 USB Device(s) found >>> scanning bus 3 for devices... 1 USB Device(s) found >>> scanning usb for storage devices... 0 Storage Device(s) found >>> Hit any key to stop autoboot: 0=20 >>> switch to partitions #0, OK >>> mmc0 is current device >>> Scanning mmc 0:1... >>> Found U-Boot script /boot.scr >>> 199 bytes read in 0 ms >>> ## Executing script at 43100000 >>> 384788 bytes read in 24 ms (15.3 MiB/s) >>> ## Starting application at 0x42000000 ... >>> Consoles: U-Boot console =20 >>> Compatible U-Boot API signature found @0x5bf6bca0 >>>=20 >>> FreeBSD/armv7 U-Boot loader, Revision 1.3 >>> (Sat Aug 17 12:49:43 IDT 2019 danny@pe-44) >>>=20 >>> DRAM: 512MB >>> Number of U-Boot devices: 1 >>> U-Boot env: loaderdev not set, will probe all devices. >>> Found U-Boot device: disk >>> Probing all devices... >>> Checking unit=3D0 slice=3D partition=3D... good. >>> Booting from disk0s2a: >>> Loading /boot/defaults/loader.conf >>> Loading /boot/device.hints >>> Loading /boot/loader.conf >>> Loading /boot/loader.conf.local >>> Loading kernel... >>> /boot/kernel/kernel text=3D0x870a68 data=3D0xb4e18+0x259768 = syms=3D[0x4+0xaa340+0x4+0x10d2ac] >>> Loading configured modules... >>> can't find '/boot/entropy' >>>=20 >>> Hit [Enter] to boot immediately, or any other key for command = prompt. >>> Booting [/boot/kernel/kernel]... =20 >>> /boot/dtb/sun8i-h3-nanopi-neo.dtb size=3D0x64d1 >>> Loaded DTB from file 'sun8i-h3-nanopi-neo.dtb'. >>> Kernel entry at 0x42400180... >>> Kernel args: (null) >>> ---<>--- >>> KDB: debugger backends: ddb >>> KDB: current backend: ddb >>> Copyright (c) 1992-2019 The FreeBSD Project. >>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 >>> The Regents of the University of California. All rights = reserved. >>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>> FreeBSD 13.0-CURRENT #13 r351126M: Sat Aug 17 13:19:09 IDT 2019 >>> = danny@pe-44:/home/obj/pe-44/arm/neo/r+d/vanilla/13/arm.armv7/r+d/vanilla/1= 3/sys/AWG arm >>> FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based = on LLVM 8.0.1) >>> WARNING: WITNESS option enabled, expect reduced performance. >>> VT: init without driver. >>> module_register: cannot register ofwbus/pcib from kernel; already = loaded from kernel >>> Module ofwbus/pcib failed to register: 17 >>> module_register: cannot register simplebus/pcib from kernel; already = loaded from kernel >>> Module simplebus/pcib failed to register: 17 >>> CPU: ARM Cortex-A7 r0p5 (ECO: 0x00000000) >>> CPU Features:=20 >>> Multiprocessing, Thumb2, Security, Virtualization, Generic Timer, = VMSAv7, >>> PXN, LPAE, Coherent Walk >>> Optional instructions:=20 >>> SDIV/UDIV, UMULL, SMULL, SIMD(ext) >>> LoUU:2 LoC:3 LoUIS:2=20 >>> Cache level 1: >>> 32KB/64B 4-way data cache WB Read-Alloc Write-Alloc >>> 32KB/32B 2-way instruction cache Read-Alloc >>> Cache level 2: >>> 512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc >>> real memory =3D 536870912 (512 MB) >>> avail memory =3D 506929152 (483 MB) >>> No PSCI/SMCCC call function found >>> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >>> arc4random: WARNING: initial seeding bypassed the cryptographic = random device because it was not yet seeded and the knob = 'bypass_before_seeding' was enabled. >>> random: entropy device external interface >>> kbd0 at kbdmux0 >>> ofwbus0: >>> ofw_clkbus0: on ofwbus0 >>> clk_fixed0: on ofw_clkbus0 >>> clk_fixed1: on ofw_clkbus0 >>> simplebus0: on ofwbus0 >>> regfix0: on ofwbus0 >>> regfix1: on ofwbus0 >>> regfix2: on ofwbus0 >>> rtc0: mem 0x1f00000-0x1f003ff irq 40,41 on = simplebus0 >>> rtc0: registered as a time-of-day clock, resolution 1.000000s >>> ccu_h3ng0: mem = 0x1c20000-0x1c203ff on simplebus0 >>> ccu_sun8i_r0: mem = 0x1f01400-0x1f014ff on simplebus0 >>> gic0: mem = 0x1c81000-0x1c81fff,0x1c82000-0x1c83fff,0x1c84000-0x1c85fff,0x1c86000-0x1c= 87fff irq 37 on simplebus0 >>> gic0: pn 0x1, arch 0x2, rev 0x1, implementer 0x43b irqs 160 >>> gpio0: mem 0x1c20800-0x1c20bff = irq 18,19 on simplebus0 >>> gpiobus0: on gpio0 >>> gpio1: mem 0x1f02c00-0x1f02fff = irq 44 on simplebus0 >>> gpiobus1: on gpio1 >>> generic_timer0: irq 0,1,2,3 on ofwbus0 >>> Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality = 1000 >>> Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality = 1000 >>> aw_syscon0: mem 0x1c00000-0x1c00fff on simplebus0 >>> awusbphy0: mem = 0x1c19400-0x1c1942b,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803,0x1c1c800-0x1c= 1c803,0x1c1d800-0x1c1d803 on simplebus0 >>> a31dmac0: mem 0x1c02000-0x1c02fff irq 4 = on simplebus0 >>> aw_mmc0: mem = 0x1c0f000-0x1c0ffff irq 6 on simplebus0 >>> mmc0: on aw_mmc0 >>> ehci0: mem = 0x1c1a000-0x1c1a0ff irq 10 on simplebus0 >>> usbus0: EHCI version 1.0 >>> usbus0 on ehci0 >>> ohci0: mem 0x1c1a400-0x1c1a4ff irq 11 on = simplebus0 >>> usbus1 on ohci0 >>> ehci1: mem = 0x1c1d000-0x1c1d0ff irq 16 on simplebus0 >>> usbus2: EHCI version 1.0 >>> usbus2 on ehci1 >>> ohci1: mem 0x1c1d400-0x1c1d4ff irq 17 on = simplebus0 >>> usbus3 on ohci1 >>> gpioc0: on gpio0 >>> awg0: mem 0x1c30000-0x1c3ffff irq 22 on = simplebus0 >>> miibus0: on awg0 >>> ukphy0: PHY 0 on miibus0 >>> ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, = auto-flow >>> ukphy1: PHY 1 on miibus0 >>> ukphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, = auto-flow >>> awg0: Ethernet address: f2:00:e7:81:61:2e >>> aw_wdog0: mem 0x1c20ca0-0x1c20cbf irq 25 on = simplebus0 >>> uart2: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 30 on = simplebus0 >>> uart2: console (115384,n,8,1) >>> gpioc1: on gpio1 >>> cpulist0: on ofwbus0 >>> cpu0: on cpulist0 >>> cpu1: on cpulist0 >>> cpu2: on cpulist0 >>> cpu3: on cpulist0 >>> gpioled0: on ofwbus0 >>> cryptosoft0: >>> Timecounters tick every 1.000 msec >>> usbus0: 480Mbps High Speed USB v2.0 >>> usbus1: 12Mbps Full Speed USB v1.0 >>> usbus2: 480Mbps High Speed USB v2.0 >>> usbus3: 12Mbps Full Speed USB v1.0 >>> ugen1.1: at usbus1 >>> uhub0 on usbus1 >>> uhub0: on = usbus1 >>> ugen0.1: at usbus0 >>> uhub1 on usbus0 >>> uhub1: = on usbus0 >>> ugen2.1: at usbus2 >>> uhub2 on usbus2 >>> uhub2: = on usbus2 >>> ugen3.1: at usbus3 >>> uhub3 on usbus3 >>> uhub3: on = usbus3 >>> mmcsd0: 8GB at mmc0 = 50.0MHz/4bit/32768-block >>> Release A >>=20 >> Could you boot -v please ? >=20 > I think I found the problem, lousy usb power, will confirm later. confirmed, had too many usb devs connected to my pc (really), changed it=E2=80=99s power supply and now it=E2=80=99s ok! thanks! >=20 > btw, any chance to enable the sid stuff? without it the ethernet = changes it=E2=80=99s mac > =09 > /dts-v1/; > /plugin/; >=20 > / { > compatible =3D "allwinner,sun50i-h5"; > }; >=20 > &{/soc} { > sid: eeprom@1c14000 { > compatible =3D "allwinner,sun50i-h5-sid"; > reg =3D <0x1c14000 0x400>; >=20 > }; > }; >>=20 >> --=20 >> Emmanuel Vadot > = > >=20 > _______________________________________________ > 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 = " From owner-freebsd-arm@freebsd.org Sun Aug 18 14:23:33 2019 Return-Path: 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 1E8D0C88E5 for ; Sun, 18 Aug 2019 14:23:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46BK6W60ZZz4ZWT for ; Sun, 18 Aug 2019 14:23:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x829.google.com with SMTP id l9so11348051qtu.6 for ; Sun, 18 Aug 2019 07:23:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YkinLbJksz74I3N/rbCFRP5hJarSOux5r2+/Li87NA0=; b=cJpp5rkoew6i3HhGZX5xB3pwi0kTEdoAOUAnJ5IBke83645dNb803XRpqpxPXbGt4Y sxrCIfkHeReyb9ylIjOQ4tG2LhurCMMuQY5PxLAvQmlQb7Xa4XjZks9vyIUrk3tW/o/2 2cyfmc1tYbSRBuWKOsLRb78FQkgTR70o5Zg4OKm7kRpeHtu9mqU93vdocXr6Mbg5/TGL pkDptMAoJXsonDBgGBJSIgHww9x+6akAbN9I46PNnisDwqm7i2Ez7vAVg+tElbDisw+M cIoo1fgIGGAYpLiXq71dGiRgOvCoEJSur41hK1Yrp9Tfs/PIkebzV+BAR9cv52+Q6ckB ioGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YkinLbJksz74I3N/rbCFRP5hJarSOux5r2+/Li87NA0=; b=DWNGkDzb2a4rZoDZn+L6OUNtzpsj/ByLZ2Ehq5G2JzIp0IkEfVexcJSd5PyxUN2CW/ YYsjp4RIWLYD293GrEgfBvFCb7mcCNoNapiKM1uY6E2iK9hAZVHv9VhRWQsS3niH13cT xgMWrwgKwi/phSGkWZ9OmhvVqf8j6KAJt2KmHSS6OftJGu4eaYOX2sEld+JxtE/fCKwz 7k0QNwzCzxuIfxXWbuV+lpl8vTEER4lw0XRBfKgujg3XnIcEKDRGmj4m17OBxUvzTbmd H7LANGEQjN68ZvQFjpLRnWe/WF8UMlyCAVy7epa85MorehfISTXhYJXRycP4XlC5GKdi 9e+w== X-Gm-Message-State: APjAAAVblYu/105uVWvTuig0CTMsbal/397GU018xQ77ecDjG6lfvHTA Do6ArJZj96nEJN/zWisGuirbt6W1YRiynpWS+7RgmhCbhvM= X-Google-Smtp-Source: APXvYqyTQH1Gf++9COw4d7XXCEEhQXPQaoWsRaYIaHGd4GPygTElMEbYYM/wR9OJgV+rnj2RLyzT82n63mBZr1h7+Rw= X-Received: by 2002:a0c:b0ef:: with SMTP id p44mr7854219qvc.27.1566138210346; Sun, 18 Aug 2019 07:23:30 -0700 (PDT) MIME-Version: 1.0 References: <20190818121741.7bd82a63@zeta.dino.sk> In-Reply-To: <20190818121741.7bd82a63@zeta.dino.sk> From: Warner Losh Date: Sun, 18 Aug 2019 08:23:19 -0600 Message-ID: Subject: Re: Zynq qspi driver https://reviews.freebsd.org/D14698 To: Milan Obuch Cc: "freebsd-arm@freebsd.org" X-Rspamd-Queue-Id: 46BK6W60ZZz4ZWT X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=cJpp5rko; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::829) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-4.95 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; URL_IN_SUBJECT(1.00)[reviews.freebsd.org]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[9.2.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-1.00)[-0.996,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.96)[ip: (-9.40), ipnet: 2607:f8b0::/32(-2.95), asn: 15169(-2.38), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2019 14:23:33 -0000 On Sun, Aug 18, 2019 at 4:18 AM Milan Obuch wrote: > Hi, > > I was able to use in subject mentioned driver on my Zybo Z7 board. I > just downloaded zy7_qspi.c file, put it in sys/arm/xilinx directory and > all other necessary patches applied per hand to 12.0-STABLE source > tree. > > I am able to read and write flash attached to qspi on my board. u-boot > uses qspi flash for environment storage so some caution should be taken > with that. > > Question: what needs to be done in order to get this driver into > official source tree? Is there any show stopper? My experience is - it > Just Works (tm). > It looks almost ready to my eye. Not sure what the hold up is. Warner From owner-freebsd-arm@freebsd.org Sun Aug 18 15:21:39 2019 Return-Path: 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 304EAC9976 for ; Sun, 18 Aug 2019 15:21:39 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound3d.ore.mailhop.org (outbound3d.ore.mailhop.org [54.186.57.195]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46BLPZ49r1z4dNd for ; Sun, 18 Aug 2019 15:21:38 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1566141697; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=kjDnAov/Z88sdDEDkx5FEqizreDI8kCOEvXJRONRot4c8QBQkKuOr3E9CNRCfn4UbmprFq1oxc4rC hPw0fMyEy35u/YqBzz7UvShNRRgTPPUv301fOqdyBPNvQEfdN0uWYbS8tRiLgAgc8JPweD1GmHqiKC iEGvUKrKjyYsPIRE2xD8D6O0PmOykJZ7HCmymyaLQ3Bc1e9zcAzXqhPkIgimAv002LGvL7soEw0GjO 4YAjijdnyn9kInOCjALfq6ALuAuIk9v2fWMaCInfv7yk9W5WCSLyPIVg2GvZyZDy/MjPaVDW1JqBDc Z7WRSk9LEO3sX9HirCp2nYYBXWkAHEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=52rd915rP6PedWKVGZqsbXWpt3lygrQtvOnvRgqabuE=; b=EYpnMuY7yMPZsFH96oIBoxtNe52NFKGXRAvjYI7xQY8OiP4xNtoovK/DyPqR0/f56Ics6Wsv3VcH4 7V89VvpY5Wbx4wPr2zZlHgdnDWpyQH14xRw7lSNqWjLuRwRRAzmbuu1+A56HLKLjIoJRjR7GAmq2ze D+aofJ22w+zyQl5JxJQAXjjAQR/ECr3VgWlOKhdC+YcYpv30vA66thZwSEkE1eJGOEKE5Z2HQKduN9 vwfv0LKzHJbfDOLOmA9fxEwdBo4A+jlJi/euAy6RYt/UP1aVIUWwFBKdSFHwVF2OKmwkzgF1HR/bc8 dpwexj+f/47HAWm8bQqZtfVlGstLoLg== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=52rd915rP6PedWKVGZqsbXWpt3lygrQtvOnvRgqabuE=; b=f0sli1UAjiwgQQwHAGQ3nOJF4Rd48CZK4jprnjyYrbGGX4dgU6KHt9JbzmTnWf1BwNLmIMWxvSYq7 SD6IQsJX4j+IGnkjn8VXbZLfkHqgF/PUorHSBcB2yp8pTrtZt4OJeCzraww+yTpXuMMuyJnMImFhPi cL67UzK5a4WrWAVyZeOn9fgifd8kLRXddBfAiwQ55+mfaZuHBVOqBSYUksvq67AR4i9ECGrdPu6XEo e1wmNE5aHuTt9BDnoGE1jQBn/Ft+kBWbsn+eSR5NRiuXoTSZygbYO81KnQ4RcMXfEhmLA5WrQDjWUu 0GgI2vPZNJGrF+M7DYLynD73l17BbNA== X-MHO-RoutePath: aGlwcGll X-MHO-User: dbeee85c-c1cb-11e9-b67b-cdd75d6ce7a8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id dbeee85c-c1cb-11e9-b67b-cdd75d6ce7a8; Sun, 18 Aug 2019 15:21:35 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x7IFLVWb072111; Sun, 18 Aug 2019 09:21:31 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <9f0d3934c9b715696643f0ea93de8e589355a560.camel@freebsd.org> Subject: Re: Zynq qspi driver https://reviews.freebsd.org/D14698 From: Ian Lepore To: Warner Losh , Milan Obuch Cc: "freebsd-arm@freebsd.org" Date: Sun, 18 Aug 2019 09:21:31 -0600 In-Reply-To: References: <20190818121741.7bd82a63@zeta.dino.sk> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46BLPZ49r1z4dNd X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.980,0]; ASN(0.00)[asn:16509, ipnet:54.186.0.0/15, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2019 15:21:39 -0000 On Sun, 2019-08-18 at 08:23 -0600, Warner Losh wrote: > On Sun, Aug 18, 2019 at 4:18 AM Milan Obuch > wrote: > > > Hi, > > > > I was able to use in subject mentioned driver on my Zybo Z7 board. > > I > > just downloaded zy7_qspi.c file, put it in sys/arm/xilinx directory > > and > > all other necessary patches applied per hand to 12.0-STABLE source > > tree. > > > > I am able to read and write flash attached to qspi on my board. u- > > boot > > uses qspi flash for environment storage so some caution should be > > taken > > with that. > > > > Question: what needs to be done in order to get this driver into > > official source tree? Is there any show stopper? My experience is - > > it > > Just Works (tm). > > > > It looks almost ready to my eye. Not sure what the hold up is. > > Warner > I think I'm probably among those who dropped the ball on this. I vaguely remember that when it was submitted, I thought I was going to be buying a xilinx development board soon and I'd just test and commit it after that. But then plans changed at $work and the devel board thing never happened. -- Ian From owner-freebsd-arm@freebsd.org Sun Aug 18 19:28:03 2019 Return-Path: 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 243EECF063 for ; Sun, 18 Aug 2019 19:28:03 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2m.ore.mailhop.org (outbound2m.ore.mailhop.org [54.149.155.156]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46BRst5DRjz3NWl for ; Sun, 18 Aug 2019 19:28:02 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1566156481; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=o4tncbuj8jpwHm6fbWGW3JvojEtJc80WFuwo1OIJJq3LC+Lz9Vh8PaS9ywfH6E1w/FWiMca2A16Xu vxUJaX3aQbHzX6rPn4GPZjL3t9CAoYUx+qi7cbnAo9m5pQFMxmCcKRTshhCjgHItZlIcMIQuMeQs5a ADE5FJ5VdPETDpZynXAY2gmdPAIMxR2x/XyJ5AwNnykFnGef57Rc+FciMqCMm7tHydCvPUH3cvNIbC AAQPJwgTvqKPMFGoIAPdGWQF4MF6jyQfmFwvntLisZkyDUDcFsbPXNzuG25U4MjuqTYhozMI9fAT9w d536gScetfNxeSe0QXReCgeqXPruqCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=XCY10LqHFluE6HoDVCGHQtkHRN5Ucbj06q6Cxoxssmo=; b=rvr2DyF4EWlW/KtepbgS2kgM/UQOdWvA3cYDMuVIeuBx0gkIYM3lc4JpkHyIshCzZYLfeLD3dsnqS cr2myqfDIcR/5qezMh+d3WRjeSkKsR9M6hSrWeWmz/osdkIxuuIj9DiWylxaD3OTMihEII4P50mM0v 8SWvjdllVKX3Z7K6La6vICiOBT6pVU0hB/lwOw7UXhEa9ibVoYsL4QLiBmInur3w6KgPo1q+50ZKFa mRZD3qjZ201DKvbqC1XTJiH8JbnlfALMTA5Qaw2JIUT2nvHLz7lYJFNTiUELT9oh/pKdBSRLL/NShP ROqil1N7Kl16PDNIU38MwJw8TNsbhqA== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=XCY10LqHFluE6HoDVCGHQtkHRN5Ucbj06q6Cxoxssmo=; b=wsOOq+QkJ46KMLp8CH0Un2iCNcXBWE+nKTOK35K972FgCxHCJEdZt4G3X259PPDwyA5O8hUNG1NKO +ueE7+9AMqPZ8q4GMpBeKULWnDirYbGzh1WEAssWzbUdLt95m4Fo7hgZKDRS/0padjVF/hS0R2BF0x NP/Cq6p8sJhPww+6El3U1/IgAcsjjPrLCZF+MRxeO+IJC8CX+VgGx+NJeGrh1lvIfMywOMgTifA06q HqlCn4SbVf4g6nxwrM6KFyzv+sV4+V3iUe3TZvIn2bKvxEC2PWbNc/COnwwIk2hbceWJcFbORaARPd sioKQttra/CB4fXLjCl+nAUxu9/WovQ== X-MHO-RoutePath: aGlwcGll X-MHO-User: 483872f6-c1ee-11e9-85ec-13b9aae3a1d2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 483872f6-c1ee-11e9-85ec-13b9aae3a1d2; Sun, 18 Aug 2019 19:27:58 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x7IJRuEc072782; Sun, 18 Aug 2019 13:27:56 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <72a964c78cbfc36be2345919633ca2196f0783e3.camel@freebsd.org> Subject: Re: Is it a good idea to use a usb-serial adapter for PPS? Yes, it is. From: Ian Lepore To: Per Hedeland Cc: freebsd-arm@freebsd.org Date: Sun, 18 Aug 2019 13:27:56 -0600 In-Reply-To: <16c91be1-6f2a-b26d-22c7-be8e4ba8eec0@hedeland.org> References: <69a9bed3-4d0a-f8f6-91af-a8f7d84ee307@hedeland.org> <345bae77417c2495f55799b4c7ca2784f4ece9ed.camel@freebsd.org> <7312032d-2908-9414-0445-6b442c3a02e5@hedeland.org> <523b6f0a0fa5f2aeec298fa74df25d3c4af66acc.camel@freebsd.org> <0426fc8b-5398-d8ab-561e-7823c24403a5@hedeland.org> <24b0eaf25b64d6098b390df092866c69e352d859.camel@freebsd.org> <16c91be1-6f2a-b26d-22c7-be8e4ba8eec0@hedeland.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46BRst5DRjz3NWl X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.985,0]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2019 19:28:03 -0000 On Thu, 2019-08-15 at 23:05 +0200, Per Hedeland wrote: > On 2019-08-15 17:49, Ian Lepore wrote: > > On Thu, 2019-08-15 at 13:46 +0200, Per Hedeland wrote: > > > On 2019-08-09 22:17, Ian Lepore wrote: > > > > [...] > > > > > > I have a theory that your making the kernel clock be based on the 10 > > > MHz clock also ended up locking the USB poll frequency to that clock, > > > and thus to the PPS signal - this would certainly explain the result. > > > Do you think this is a possibility? Would it be possible for you to > > > re-run the test without modifying the kernel clock? (I do understand > > > that the results will be harder to interpret with the drift, and > > > ntpd's correction of it, coming into play.) > > > > > > --Per > > > > > > > I'm not sure what you mean by "modifying the kernel clock". The kernel > > clock always runs on some frequency source. Typically it's derived > > from the cheap 24 MHz crystal that clocks the SoC, sometimes after > > being scaled up to 66 MHz by a phase-fractional PLL within the SoC. I > > arranged to use a very stable nearly-drift-free frequency source > > instead of a cheap crystal for counting time in the kernel. > > > > The kernel clock has nothing to do with usb, including polling > > intervals; the usb controller hardware handles that, and the root > > source clock for that is the cheap 24 MHz crystal. > > The thing that made me hypothesize that the kernel clock *could* have > *something* to do with the USB polling frequency was this observation > in https://blog.dan.drown.org/pps-over-usb (link provided by one of > the posters in the newsgroup, though he didn't refer specifically to > this): > > Looking closer at the USB latency, you can see the PPS drifting > relative to the host schedule of polling the USB device for its > status. The system clock error was 2.215ppm during this time > period, and this drift matches that error exactly. This probably > means USB on this system shares the same clock as the system > clock. This hardware is a Raspberry Pi 2, and I suspect it won't be > true for other platforms. > > So at least on RPi 2, there appears to be a relation between the > "normal" system/kernel clock and the USB polling frequency. But I have > no idea if there is such a relation on the system you used, and even > in that case, *I* certainly can't see how using a different source for > the kernel clock could affect the USB polling frequency, which is why > asked if you thought that it was a possibility... > I probably should have been clearer that I meant there was no correlation between the kernel clock and the usb polling on the system I was using as a testbed. On most SoCs, and probably even modern x86 systems, the same frequency source (typically a 24MHz crystal) will be the root clock for both the usb controller hardware and the timer hardware from which the kernel clock is derived. However, the kernel clock is numerically steered to be more stable in frequency and accurate in phase, so once ntpd has been running for long enough to capture and disipline the kernel clock, the situation will change. The usb polling will still be happening at the drifting frequency of the underlying crystal, while the kernel timestamps used to mark the PPS pulse time will not be drifting at that rate. I have a hard time understanding how the measurements were made in that pps-over-usb page you cited. There is mention of a STM32F103 microcontroller, but it's not clear to me what role it plays. There is also mention of a usb irq and something about a message in a buffer. For the measurements I made, I was using FTDI usb-serial devices directly connected to the usb bus on the Wandboard I was using to make measurements. When the DCD pin changes at the ftdi chip, the chip internally notes that it has a line-status change that must be communicated upstream at the next opportunity. When the time comes to send the data, it sends a 2-byte packet which contains the modem and line status register bits. (If there are any routine uart data bytes in the buffer, they also get transferred, but I'm not doing any data transfer on the adapters I'm using for this test, in fact the only pins connected are ground and DCD.) When the input packet arrives, the uftdi driver sees the change in the DCD bit and captures a pps event. For ftdi chips, all of the foregoing is done with usb BULK-IN transfers, not control or interrupt transfers. I need to run the same tests with some other brands of usb-serial adapters. I think I may have a cable laying around based on Prolific PL2303 chipset. If I can find it. I should just go buy a few other- brand breakout boards and test them. > > I think people are massively confused by usb. A usb 2.0 bus runs at > > 480MHz. That means the time to transmit a packet describing a usb > > serial pin-change event takes literally a dozen or so nanoseconds. The > > time it takes to transmit an entire sector of disk data is 2 > > microseconds; even if continuous disk data is flowing, the usb serial > > adapter gets its round-robin opportunity to send a packet on the bus in > > between them. > > Yes, the transmission speed is obviously not a problem, the question > is about varying latency due to the polling. > > > A USB 2.0 bus spends most of its time idle. The > > devices on the bus are polled, but the polling happens in time slots > > that are 125 microseconds wide. There's just no reason for a lot of > > jitter or latency. > > In the newsgroup it was claimed that the polling frequency was 1 kHz > for USB 1.1 and 4 kHz for USB 2.0, but it seems it should indeed be 8 > kHz for 2.0 "high" speed. And your test used one USB 1.1 device and > one 2.0 device. > > And "a lot" is a bit subjective, but for any polling at a frequency > that isn't an exact integral number of periods per second, there will > be a latency between the start of the PPS pulse and the detection in > the host that *varies* in an interval the size of the polling > interval. I believe that interval should thus be expected to be 1000 > microseconds for 1.1 and 125 microseconds for 2.0. > I think there is some confusion around the concept of usb 1.x devices on a usb 2.0 bus. I think there may even be some confusion when a 1.x bus is involved. And then adding to the confusion is the likelyhood that different usb-serial adapters use different usb transfer types (bulk vs interrupt)_to communicate line-state changes. A usb 1.x bus is divided into 1ms frames. A 2.0 bus is divided into 125us (micro-)frames. For interrupt endpoints, a usb 1.x bus limits devices to 1 interrupt transfer per frame, and that may imply that there is up to 1ms of latency for reporting a DCD change on such a 1.x bus. A 2.0 bus allows up to 3 interrupt transfers per microframe, implying latency of up to 125us. However, there is no limit on either 1.x or 2.0 busses for how many bulk transfers can happen to a given endpoint during a frame. The controller needs to fill a frame with transactions in a way that first provides all the g'teed bandwidth that is promised to control, interrupt, and isochronous transfers. It is then free to fill all the remaining time with bulk transfers. To me, this implies that you may end up with nearly no latency (and negligible jitter) if you have a usb 2.0 bus that has just one or two devices on it which are communicating via bulk-transfer endpoints. The controller would be continuously sending BULK IN tokens to the one or two devices, so that as soon as one of them has data, it gets an opportunity to deliver it almost immediately (meaning within a few microseconds). The results I see with FTDI usb-serial adapters which use bulk transfers provide some evidence that my theory may be correct. I think the bus looks like this: BULK IN token to usb 1.x device (do you have anything to say?) 1.x device NAKs BULK IN token to usb 2.0 device 2.0 device NAKs BULK IN token to usb 1.x device 1.x device NAKs ... (repeat forever) In other words, the device(s) aren't getting 1 chance per frame to transfer data, they are getting many thousands of chances per second. I think the bus overhead of the BULK-IN token followed by a NAK from the device, along with the various framing bits and crc and all that probably adds up to less than 64 bytes per poll. But assuming it took as much as 64 bytes to do that, if there was one usb-serial device on a usb 2.0 bus, it would be getting asked about 1 million times per second whether it had anything to say. I'd welcome input from low-level USB gurus about the bus and controller behavior in this regard. > Your ntpq output showed an offset close to 200 microseconds for both > devices, and I *assumed* that it was more or less constant and thus > ntpd could trivially be told to correct for it - but maybe that > assumption was incorrect, there was only one instance of ntpq output? > > If it actually varied in an interval per above, I would expect the > jitter to be significantly higher though. And if it *is* more or less > constant, can you explain how this is possible? Even the 2.0 125 > microsecond case should be clearly visible in the offset reported by > ntpd across a sequence of ntpq requests. > > > I'm not on a crusade to change the minds of people who make judgements > > based on gut feelings and reject objective measurements. I put the > > measurements out there, and I described the measurement methodology. > > (Precision timing is what I do for a living, btw.) I'm perfectly > > willing to explain the methodology in more detail or help interpret the > > results, but I'm not going to butt heads with people who just reject > > data they don't like for emotional reasons. > > Well, I guess a problem here is that it's my confused head that is > butted between yours and those of the supposedly-experts that > participate in the NTP newsgroup/maillist:-) - you already declined to > participate there, and I don't expect that any of them will take the > trouble to participate here. Maybe we'll just have to leave it at > that... I had a brief look at whether I could get posting access to the ntp newsgroup and didn't find anything easy to set up and use, and I'm reluctant to get an nntp provider and install a newsreader for one conversation. (The 1980s me would be astounded to hear that future-me would have any reluctance to get involved in usenet.) -- Ian From owner-freebsd-arm@freebsd.org Sun Aug 18 20:53:59 2019 Return-Path: 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 74D75D0B53 for ; Sun, 18 Aug 2019 20:53:59 +0000 (UTC) (envelope-from per@hedeland.org) Received: from outbound1g.eu.mailhop.org (outbound1g.eu.mailhop.org [52.28.6.212]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46BTn22cdsz3x9G for ; Sun, 18 Aug 2019 20:53:57 +0000 (UTC) (envelope-from per@hedeland.org) ARC-Seal: i=1; a=rsa-sha256; t=1566161636; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=q0CE8OGVCIvhuf+XoZZloas76o/M9JbnX0ech+8QAfPHVeUxFNHZ4ocQvfXEe6LmuSNzEsD3SPr6j tZ4x/ZyWzJjYawDHydUNi2QvaxK+HNXKRitk7XHFh32EBkIy5wZjvIyxXs/LBVWl369EoZm9hZYqXR 6Rkmo6NFJO5zckFEjza43FcBfOSNvgPF9rD8Q8ACtTY3eki5+VCI6vjqLjo/TVJCAx3T6hjwQ898JT NznjdXMXV1+Dbynht4EKnnPATMyBRm0iQZacf5F4JyswjKNMJGsjn05Zu1R4uGAoI09uSpIPqdRpjv Qy2UgubWobqLMa2me9M8+xwv2bShrcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:references:cc:to:subject:dkim-signature:from; bh=x6CcadSo+QBxpRQVFrjeX9264AjLDFgAmEgeynUGGls=; b=jvtBVFiVjO4d2XHqh8bDNGNzB6bDaXDnWWQleXoRBch2DjLbpAhiinlUm2HnjdrkYT9xTM3ZUChAO IQEaf7p8UhbPrLiI2GyNPQm+GVGkNe81mTYyWAlglM7/yGY3gQ+jvjK5fEs7AMhNDB6ldXi0nJxzyI VR0PZ44K3bJ8NutNbZ3L6fd4XQ3ajoPmsDHwZkwLWNvponh8iglm5o8upPUHVuzhnY2TszcmVmsFCp f8/iP+dz61B1AMpy7GTOrMFfqVoBVCRqsrGTOEmP1jxfEl3ttVetPUJG7ayfOIUZ4NQDvoe8mdsIPo 2q51DrLV2lWfERKqL4W2W5/TR35+1XQ== ARC-Authentication-Results: i=1; outbound3.eu.mailhop.org; spf=none smtp.mailfrom=hedeland.org smtp.remote-ip=81.228.157.209; dmarc=none header.from=hedeland.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:references:cc:to:subject:from; bh=x6CcadSo+QBxpRQVFrjeX9264AjLDFgAmEgeynUGGls=; b=sirbGGddlkJdCfxNCOb9vbYyrefBwpy/WuCXsdrH/fW8PWXHZPfiisQ6ULY7n6F5q7WfzUxGoJ7Mr F9paQPtHhhLjpQMm4uYRv/RwaYL4/ReLcjr/cRIDuMeZ2p+z53OxpvXNmdCn4fIs/KvG7l3q+jRLD+ Rl8RWCiX+OeYLuQxMXoXlN3Zo1nDHUYpZEZPUmsc3J0jGcPZNISrdEmxXEynEr8uCs6PNz7du8FTdv AjFGNC81IYkjw94ty60SgxujtNKvQVTdPT0gDM9zQ+lWMk7TqmiIxUQaes3TP2JMgdlmQLkTg0/77o 8tviMw4g5ru1CSTq8gZWmFtdH9y7qJA== X-MHO-RoutePath: cGVyaGVkZWxhbmQ= X-MHO-User: 48e63aec-c1fa-11e9-98b8-25195f42ee1c X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 81.228.157.209 X-Mail-Handler: DuoCircle Outbound SMTP Received: from hedeland.org (unknown [81.228.157.209]) by outbound3.eu.mailhop.org (Halon) with ESMTPSA id 48e63aec-c1fa-11e9-98b8-25195f42ee1c; Sun, 18 Aug 2019 20:53:52 +0000 (UTC) Received: from pluto.hedeland.org (pluto.hedeland.org [10.1.1.5]) by tellus.hedeland.org (8.15.2/8.15.2) with ESMTPS id x7IKrpv1054253 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 18 Aug 2019 22:53:51 +0200 (CEST) (envelope-from per@hedeland.org) Subject: Re: Is it a good idea to use a usb-serial adapter for PPS? Yes, it is. To: Ian Lepore Cc: freebsd-arm@freebsd.org References: <69a9bed3-4d0a-f8f6-91af-a8f7d84ee307@hedeland.org> <345bae77417c2495f55799b4c7ca2784f4ece9ed.camel@freebsd.org> <7312032d-2908-9414-0445-6b442c3a02e5@hedeland.org> <523b6f0a0fa5f2aeec298fa74df25d3c4af66acc.camel@freebsd.org> <0426fc8b-5398-d8ab-561e-7823c24403a5@hedeland.org> <24b0eaf25b64d6098b390df092866c69e352d859.camel@freebsd.org> <16c91be1-6f2a-b26d-22c7-be8e4ba8eec0@hedeland.org> <72a964c78cbfc36be2345919633ca2196f0783e3.camel@freebsd.org> From: Per Hedeland Message-ID: Date: Sun, 18 Aug 2019 22:53:51 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <72a964c78cbfc36be2345919633ca2196f0783e3.camel@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46BTn22cdsz3x9G X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=outbound.mailhop.org header.s=dkim-high header.b=sirbGGdd; dmarc=none; spf=none (mx1.freebsd.org: domain of per@hedeland.org has no SPF policy when checking 52.28.6.212) smtp.mailfrom=per@hedeland.org X-Spamd-Result: default: False [-5.53 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[outbound.mailhop.org:s=dkim-high]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[hedeland.org]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[outbound.mailhop.org:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[212.6.28.52.list.dnswl.org : 127.0.20.0]; NEURAL_HAM_SHORT(-0.97)[-0.975,0]; RECEIVED_SPAMHAUS_PBL(0.00)[209.157.228.81.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-1.26)[ipnet: 52.28.0.0/16(-4.88), asn: 16509(-1.35), country: US(-0.05)]; ASN(0.00)[asn:16509, ipnet:52.28.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_ALLOW(-1.00)[i=1] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2019 20:53:59 -0000 On 2019-08-18 21:27, Ian Lepore wrote: > On Thu, 2019-08-15 at 23:05 +0200, Per Hedeland wrote: >> On 2019-08-15 17:49, Ian Lepore wrote: >>> On Thu, 2019-08-15 at 13:46 +0200, Per Hedeland wrote: >>>> On 2019-08-09 22:17, Ian Lepore wrote: >>>>> [...] >>>> >>>> I have a theory that your making the kernel clock be based on the 10 >>>> MHz clock also ended up locking the USB poll frequency to that clock, >>>> and thus to the PPS signal - this would certainly explain the result. >>>> Do you think this is a possibility? Would it be possible for you to >>>> re-run the test without modifying the kernel clock? (I do understand >>>> that the results will be harder to interpret with the drift, and >>>> ntpd's correction of it, coming into play.) >>>> >>>> --Per >>>> >>> >>> I'm not sure what you mean by "modifying the kernel clock". The kernel >>> clock always runs on some frequency source. Typically it's derived >>> from the cheap 24 MHz crystal that clocks the SoC, sometimes after >>> being scaled up to 66 MHz by a phase-fractional PLL within the SoC. I >>> arranged to use a very stable nearly-drift-free frequency source >>> instead of a cheap crystal for counting time in the kernel. >>> >>> The kernel clock has nothing to do with usb, including polling >>> intervals; the usb controller hardware handles that, and the root >>> source clock for that is the cheap 24 MHz crystal. >> >> The thing that made me hypothesize that the kernel clock *could* have >> *something* to do with the USB polling frequency was this observation >> in https://blog.dan.drown.org/pps-over-usb (link provided by one of >> the posters in the newsgroup, though he didn't refer specifically to >> this): >> >> Looking closer at the USB latency, you can see the PPS drifting >> relative to the host schedule of polling the USB device for its >> status. The system clock error was 2.215ppm during this time >> period, and this drift matches that error exactly. This probably >> means USB on this system shares the same clock as the system >> clock. This hardware is a Raspberry Pi 2, and I suspect it won't be >> true for other platforms. >> >> So at least on RPi 2, there appears to be a relation between the >> "normal" system/kernel clock and the USB polling frequency. But I have >> no idea if there is such a relation on the system you used, and even >> in that case, *I* certainly can't see how using a different source for >> the kernel clock could affect the USB polling frequency, which is why >> asked if you thought that it was a possibility... >> > > I probably should have been clearer that I meant there was no > correlation between the kernel clock and the usb polling on the system > I was using as a testbed. On most SoCs, and probably even modern x86 > systems, the same frequency source (typically a 24MHz crystal) will be > the root clock for both the usb controller hardware and the timer > hardware from which the kernel clock is derived. However, the kernel > clock is numerically steered to be more stable in frequency and > accurate in phase, so once ntpd has been running for long enough to > capture and disipline the kernel clock, the situation will change. The > usb polling will still be happening at the drifting frequency of the > underlying crystal, while the kernel timestamps used to mark the PPS > pulse time will not be drifting at that rate. Understood. What I don't understand is if, and if so how, your "replacing" the kernel clock with an "exact" frequency from your 10 MHz clock might affect the USB polling. > I have a hard time understanding how the measurements were made in that > pps-over-usb page you cited. There is mention of a STM32F103 > microcontroller, but it's not clear to me what role it plays. There is > also mention of a usb irq and something about a message in a buffer. My understanding is that the "STM32F103 devboard" actually *implements* the USB-to-serial adapter. This means that the author has detailed insight into the workings of the adapter, including the possibilty to modify its firmware - something that is obviously not the case for an off-the-shelf adapter. The "PPS IRQ" is thus something that happens *inside* the "adapter". > For the measurements I made, I was using FTDI usb-serial devices > directly connected to the usb bus on the Wandboard I was using to make > measurements. When the DCD pin changes at the ftdi chip, the chip > internally notes that it has a line-status change that must be > communicated upstream at the next opportunity. When the time comes to > send the data, it sends a 2-byte packet which contains the modem and > line status register bits. (If there are any routine uart data bytes > in the buffer, they also get transferred, but I'm not doing any data > transfer on the adapters I'm using for this test, in fact the only pins > connected are ground and DCD.) When the input packet arrives, the > uftdi driver sees the change in the DCD bit and captures a pps event. > For ftdi chips, all of the foregoing is done with usb BULK-IN > transfers, not control or interrupt transfers. > > I need to run the same tests with some other brands of usb-serial > adapters. I think I may have a cable laying around based on Prolific > PL2303 chipset. If I can find it. I should just go buy a few other- > brand breakout boards and test them. FWIW, I did a bleak replica of your setup, using a "noname" USB-to-serial adapter that I had laying around, which was actually identified as pi kernel: uplcom0: on usbus0 - and since the uplcom driver has "support for Prolific PL-2303/2303X/2303HX", I assume it is one of those. Since I don't have a "real" PPS source, I simulated one with a simple program running on an RPi 3, that generated a pulse on a gpio pin at the turn of the second. This pin was then connected to a gpio pin on an RPi B, and to the DCD pin on the above adapter, also connected to the RPi B - notably without any ttl-to-rs232 converter (since I also don't have one of those). I then set up ntpd on the RPi B to use gpiopps plus the PPS from the uplcom driver: server iburst prefer server 127.127.22.0 minpoll 4 maxpoll 4 fudge 127.127.22.0 refid gpio server 127.127.22.1 minpoll 4 maxpoll 4 noselect fudge 127.127.22.1 refid usb The result was very nice for gpiopps, but the offset for the uplcom PPS varied way more than the 1 ms that could be expected even from a constant 1 ms polling interval (this is a 1.1 device), more like a 5-6 ms interval - some ntpq samples approximately 16 s apart: remote refid st t when poll reach delay offset jitter ============================================================================== * 194.58.205.148 2 u 40 64 377 0.996 -0.049 0.034 oPPS(0) .gpio. 0 l 14 16 377 0.000 -0.004 0.004 PPS(1) .usb. 0 l 13 16 377 0.000 -7.090 3.273 remote refid st t when poll reach delay offset jitter ============================================================================== * 194.58.205.148 2 u 56 64 377 0.996 -0.049 0.034 oPPS(0) .gpio. 0 l 14 16 377 0.000 0.000 0.004 PPS(1) .usb. 0 l 13 16 377 0.000 -2.957 2.567 remote refid st t when poll reach delay offset jitter ============================================================================== * 194.58.205.148 2 u 6 64 377 0.996 -0.049 0.034 oPPS(0) .gpio. 0 l 15 16 377 0.000 -0.001 0.004 PPS(1) .usb. 0 l 14 16 377 0.000 -8.627 4.871 This *could* be taken to imply that there was also some polling going on *in* the adapter towards the DCD pin - especially since the above was with a 10 ms pulse, while if I shortened the pulse to 1 ms, the variation went down to ~ 1 ms, but almost half the pulses were missed. Or it might be due to shaky detection due to the lack of a ttl-to-rs232 converter. In any case pretty inconclusive, other than the observation that it's certainly possible to mess things up...:-) >>> I think people are massively confused by usb. A usb 2.0 bus runs at >>> 480MHz. That means the time to transmit a packet describing a usb >>> serial pin-change event takes literally a dozen or so nanoseconds. The >>> time it takes to transmit an entire sector of disk data is 2 >>> microseconds; even if continuous disk data is flowing, the usb serial >>> adapter gets its round-robin opportunity to send a packet on the bus in >>> between them. >> >> Yes, the transmission speed is obviously not a problem, the question >> is about varying latency due to the polling. >> >>> A USB 2.0 bus spends most of its time idle. The >>> devices on the bus are polled, but the polling happens in time slots >>> that are 125 microseconds wide. There's just no reason for a lot of >>> jitter or latency. >> >> In the newsgroup it was claimed that the polling frequency was 1 kHz >> for USB 1.1 and 4 kHz for USB 2.0, but it seems it should indeed be 8 >> kHz for 2.0 "high" speed. And your test used one USB 1.1 device and >> one 2.0 device. >> >> And "a lot" is a bit subjective, but for any polling at a frequency >> that isn't an exact integral number of periods per second, there will >> be a latency between the start of the PPS pulse and the detection in >> the host that *varies* in an interval the size of the polling >> interval. I believe that interval should thus be expected to be 1000 >> microseconds for 1.1 and 125 microseconds for 2.0. >> > > I think there is some confusion around the concept of usb 1.x devices > on a usb 2.0 bus. I think there may even be some confusion when a 1.x > bus is involved. And then adding to the confusion is the likelyhood > that different usb-serial adapters use different usb transfer types > (bulk vs interrupt)_to communicate line-state changes. > > A usb 1.x bus is divided into 1ms frames. A 2.0 bus is divided into > 125us (micro-)frames. For interrupt endpoints, a usb 1.x bus limits > devices to 1 interrupt transfer per frame, and that may imply that > there is up to 1ms of latency for reporting a DCD change on such a 1.x > bus. A 2.0 bus allows up to 3 interrupt transfers per microframe, > implying latency of up to 125us. > > However, there is no limit on either 1.x or 2.0 busses for how many > bulk transfers can happen to a given endpoint during a frame. The > controller needs to fill a frame with transactions in a way that first > provides all the g'teed bandwidth that is promised to control, > interrupt, and isochronous transfers. It is then free to fill all the > remaining time with bulk transfers. > > To me, this implies that you may end up with nearly no latency (and > negligible jitter) if you have a usb 2.0 bus that has just one or two > devices on it which are communicating via bulk-transfer endpoints. The > controller would be continuously sending BULK IN tokens to the one or > two devices, so that as soon as one of them has data, it gets an > opportunity to deliver it almost immediately (meaning within a few > microseconds). > > The results I see with FTDI usb-serial adapters which use bulk > transfers provide some evidence that my theory may be correct. I think > the bus looks like this: > > BULK IN token to usb 1.x device (do you have anything to say?) > 1.x device NAKs > BULK IN token to usb 2.0 device > 2.0 device NAKs > > BULK IN token to usb 1.x device > 1.x device NAKs > ... (repeat forever) > > In other words, the device(s) aren't getting 1 chance per frame to > transfer data, they are getting many thousands of chances per second. > I think the bus overhead of the BULK-IN token followed by a NAK from > the device, along with the various framing bits and crc and all that > probably adds up to less than 64 bytes per poll. But assuming it took > as much as 64 bytes to do that, if there was one usb-serial device on a > usb 2.0 bus, it would be getting asked about 1 million times per second > whether it had anything to say. This is extremely interesting - if it really is the case that the host will poll "as fast as it can", as opposed to always doing it with a fixed frequency, it would definitely change the picture. Unfortunately I haven't seen any documentation to support that this is the case. > I'd welcome input from low-level USB gurus about the bus and controller > behavior in this regard. I'm afraid we have lost freebsd-usb@ in this sub-thread (it was actually the case before my first comment, but it would probably have happened anyway, since I'm not subscribed to that list). Unless you know that "low-level USB gurus" are also subscribed to freebsd-arm@, it might make sense to forward your message to freebsd-usb@. >> Your ntpq output showed an offset close to 200 microseconds for both >> devices, and I *assumed* that it was more or less constant and thus >> ntpd could trivially be told to correct for it - but maybe that >> assumption was incorrect, there was only one instance of ntpq output? >> >> If it actually varied in an interval per above, I would expect the >> jitter to be significantly higher though. And if it *is* more or less >> constant, can you explain how this is possible? Even the 2.0 125 >> microsecond case should be clearly visible in the offset reported by >> ntpd across a sequence of ntpq requests. >> >>> I'm not on a crusade to change the minds of people who make judgements >>> based on gut feelings and reject objective measurements. I put the >>> measurements out there, and I described the measurement methodology. >>> (Precision timing is what I do for a living, btw.) I'm perfectly >>> willing to explain the methodology in more detail or help interpret the >>> results, but I'm not going to butt heads with people who just reject >>> data they don't like for emotional reasons. >> >> Well, I guess a problem here is that it's my confused head that is >> butted between yours and those of the supposedly-experts that >> participate in the NTP newsgroup/maillist:-) - you already declined to >> participate there, and I don't expect that any of them will take the >> trouble to participate here. Maybe we'll just have to leave it at >> that... > > I had a brief look at whether I could get posting access to the ntp > newsgroup and didn't find anything easy to set up and use, and I'm > reluctant to get an nntp provider and install a newsreader for one > conversation. Understood - there are free nntp providers, but you do need a newsreader of some kind. The newsgroup is sort-of gatewayed to the questions@lists.ntp.org mailing list, but the gatewaying is pretty broken - posts to the mailing list do not appear at all in the newsgroup, and posts to the newsgroup only appear on the mailing list after manual approval by a moderator (at least unless you are subscribed to the mailing list). Thus I believe most participants use the newsgroup. > (The 1980s me would be astounded to hear that future-me > would have any reluctance to get involved in usenet.) Well, there isn't much value there anymore, but there are some groups that refuse to die.:-) --Per From owner-freebsd-arm@freebsd.org Sun Aug 18 21:00:14 2019 Return-Path: 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 49DFCD0D58 for ; Sun, 18 Aug 2019 21:00:14 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46BTwG1Fg2z3xYK for ; Sun, 18 Aug 2019 21:00:14 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 0E1027D66 for ; Sun, 18 Aug 2019 21:00:14 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x7IL0DV6018826 for ; Sun, 18 Aug 2019 21:00:13 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x7IL0DA0018824 for freebsd-arm@FreeBSD.org; Sun, 18 Aug 2019 21:00:13 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201908182100.x7IL0DA0018824@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: freebsd-arm@FreeBSD.org Subject: Problem reports for freebsd-arm@FreeBSD.org that need special attention Date: Sun, 18 Aug 2019 21:00:13 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2019 21:00:14 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 238576 | Raspberry Pi 3B+ "shutdown -p" does not shut off Open | 239673 | Spurious Interrupt message from /dev/led/led1 2 problems total for which you should take action. From owner-freebsd-arm@freebsd.org Sun Aug 18 21:46:00 2019 Return-Path: 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 4A076D21BB for ; Sun, 18 Aug 2019 21:46:00 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound3d.ore.mailhop.org (outbound3d.ore.mailhop.org [54.186.57.195]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46BVx36JrWz419n for ; Sun, 18 Aug 2019 21:45:59 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1566164758; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=wKOa/be2SUo1ADaPZdjJLudZcwsPIB6XJKuGeblI7Lm1ncYkGhVB5E9sfldPukVcv6trdlxKg7Tf7 fqqdchyx2WCnp+8rg3Ee4xJcitTLd34beCOCMYwSZBuPvnr9iwpDRfXuEPiiiFYlJMb2OZrNvivBai GJwTlDBorLof/utgsFKhl6wCY+n9Gwtsr6qcnGlIuIVQ3JdaeNJZo4htLeJ322yPL4oq45hm0kFpk3 fvbPuhil4Wb0dRw6eoHNj8/DhKoK7oSN7XF8ktRyPoq9S4jXqBqTdeJWCgu6UXKdwSqx5YNpXSAz/u 95C+LwYwNh4LitTSg2rMqVvdmeIDugw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:dkim-signature:from; bh=5BxlUEQeczJB/RLYG3Xp0hZVVJ5lapbfxS/mupg09+I=; b=kkktc4OutFRk7KqmbkGOYRp+lolrzD/Y2oxslgRnOos7+35r+i1JZm8HyUDjRaqGesxtiqWOL1dcp ocLSy3sqd34IeuHz3L1q68w8jBFrJLz7iUouLFmDnWqHkWZZB56RYcibLyMO4nMiFns7NcveZNbFwN gizx95ydC/6mdwQ2us/w39Su0aI+emwAMYPPKYzxgUuern1kC8COhC9WETIImZGD5fxywlULbKGQFD H37CX9CCEvn5BqDEjlDhWlduZk1ddxr86S/8kY+BI6/imd3HdAPDkwzuWfHD0IGzyXKaUHiy6bjyHo 47tjS8oZruOV26VEFBEog3+0PR9TnrA== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:from; bh=5BxlUEQeczJB/RLYG3Xp0hZVVJ5lapbfxS/mupg09+I=; b=WlNuK1C0NwlffmiemrvP22icfr/zdL31ydFzXlI59wYbJMsx9v3NcO3I250qL6fWX2zsW0/d9zE6m OuHHypV+GOiP6ZqditbuGxSVX8XlfFrNEJTKjsvDkABq0n2pPPGawd2K6A3zlP67efYPvtUJSdsI7x 0koOxOOVBIaWdyJKmGhzaRARjdt//JRSlwJHCcc7eFlOunt3y8JJqglPq8rDYk9HjqEUPmA+EnT8mr +WG3mhoyadakUGvhI3V4J/WqVDCG0fAdNt4CnX65QlcTMQwjb1FdN4RhxXmtMs6EmXOC8f4gLcDFln isgbqfIv+enjw7Bz0VTgWpMGg52h9bA== X-MHO-RoutePath: aGlwcGll X-MHO-User: 8e2f4f86-c201-11e9-b67b-cdd75d6ce7a8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 8e2f4f86-c201-11e9-b67b-cdd75d6ce7a8; Sun, 18 Aug 2019 21:45:56 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x7ILjsq2073110; Sun, 18 Aug 2019 15:45:54 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <804cfca3edf6d8d40a72257b4f1e876200721c48.camel@freebsd.org> Subject: Re: Is it a good idea to use a usb-serial adapter for PPS? Yes, it is. From: Ian Lepore To: Ross Alexander , freebsd-arm@freebsd.org Date: Sun, 18 Aug 2019 15:45:54 -0600 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46BVx36JrWz419n X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.984,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:16509, ipnet:54.186.0.0/15, country:US] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2019 21:46:00 -0000 On Thu, 2019-08-15 at 16:02 -0600, Ross Alexander wrote: > In <24b0eaf25b64d6098b390df092866c69e352d859.camel@freebsd.org>, > Ian Lepore writes: > > > [... ed.] I arranged to use a very stable nearly-drift-free > > frequency source instead of a cheap crystal for counting time in the > > kernel. > > You have my complete and focussed attention. Say on. > I detailed the design of the measurement system in the original message. Basically it involves feeding a very stable external clock signal to a block of timer hardware within the imx6 SoC and using that timer hardware as the kernel clock. The source of the stable external clock has these specs: https://www.microsemi.com/product-directory/gps-instruments/4152-syncsystem-4380a I'm a software engineer for the division of Microsemi that makes those devices. If it wasn't the clock source you wanted to hear more about, then let me know in more detail what you'd like to know. > > [WRT USB 2, ed.] the polling happens in time slots that are 125 > > microseconds wide. There's just no reason for a lot of jitter or > > latency. > > 125 microseconds is a lot of jitter. Latency is a don't care, you can > fudge that out. Looking at a Pi 1b+, running some consumer grade > Ublocks GPS module, a five year old Linux, and with a view of only > half the sky (but using PPS on a GPIO pin): > It's negligible jitter for everyday computer use. It's a lot if you're doing something like timestamping financial transactions, or recording radio-astronomy observations, but the people doing that sort of thing usually aren't using ntpd to sync their clocks (they're using ieee- 1588, or custom solutions such as PCI irig input cards). But, as I detailed in the previous followup to Per Hedelund's post, I don't think there is a 125us latency or jitter introduced due to the usb bus frame rate. At least on the FTDI usb-serial chips I tested with, usb bulk transfers are used, and those are not limited to one transfer per bus frame or microframe. I'm still trying to find more info on the low-level usb part of this, because I was expecting to see average latency and jitter on the order of 50-60us each. That was based on an assumption I held until recently that on a usb 2.0 bus any given device would get an opportunity to deliver new data at most once every 125us, but now I don't think that limitation exists, at least for bulk transfers. > > autopsy:/u0/rwa > ntpq chime > > > > ntpq> lpee > > remote refid st t when poll reach delay offset jitter > > ============================================================================== > > oPPS(0) .PPS. 0 l 8 16 377 0.000 0.001 0.002 > > *SHM(0) .GPS. 5 l 6 16 377 0.000 419.464 310.013 > > > > ntpq> rl &1 > > associd=10146 status=911a conf, reach, sel_falsetick, 1 event, sys_peer, > > srcadr=PPS(0), srcport=123, dstadr=127.0.0.1, dstport=123, leap=00, > > stratum=0, precision=-20, rootdelay=0.000, rootdisp=0.000, refid=PPS, > > reftime=e1005453.fffff7a5 Thu, Aug 15 2019 15:59:47.999, > > rec=e1005454.debc0ef4 Thu, Aug 15 2019 15:59:48.870, reach=377, > > unreach=0, hmode=3, pmode=4, hpoll=4, ppoll=4, headway=0, flash=00 ok, > > keyid=0, ttl=0, offset=0.001, delay=0.000, dispersion=0.233, > > jitter=0.002, > > filtdelay= 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00, > > filtoffset= 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00, > > filtdisp= 0.00 0.24 0.48 0.72 0.96 1.20 1.44 1.68 > > > > ntpq> rl > > associd=0 status=0413 leap_none, sync_uhf_radio, 1 event, spike_detect, > > version="ntpd 4.2.7p397@1.2483-o Sun May 3 05:32:19 UTC 2015 (1)", > > processor="armv7l", system="Linux/4.1.12-v7+", leap=00, stratum=6, > > precision=-19, rootdelay=0.000, rootdisp=733.955, refid=SHM(0), > > reftime=e1005456.debbfb5d Thu, Aug 15 2019 15:59:50.870, > > clock=e100545c.084cd64c Thu, Aug 15 2019 15:59:56.032, peer=10147, tc=4, > > mintc=3, offset=0.000921, frequency=0.047, sys_jitter=310.013202, > > clk_jitter=0.000, clk_wander=0.000 > > The jitter is expressed in units of 1 millisecond, unless I am badly > mistaken; for which possibility I apologize in advance. > Yes, it's reported in milliseconds. The jitter number is the RMS of the differences between the offset from the measurement with the lowest delay for that peer and the other 7 offsets for that peer in the 8-step filter. That is, it finds the lowest delay, then it does, roughly: jitter = 0; for offset in {the other 7 samples that aren't the lowest delay} jitter += SQUARE(offset - lowest_delay_offset) then the final number is jitter = SQRT(jitter / 7) > (as an aside, has editing quotation text gone utterly out of style? > Present company excepted, of course.) > I tend to err on the side of not trimming away too much context when replying, so that people finding the thread from a web search some day will have enough context to interpret the hit they found without having to track down the entire thread and start from the beginning. > regards, > Ross > From owner-freebsd-arm@freebsd.org Sun Aug 18 21:57:57 2019 Return-Path: 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 535D9D285E for ; Sun, 18 Aug 2019 21:57:57 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound3d.ore.mailhop.org (outbound3d.ore.mailhop.org [54.186.57.195]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46BWBs11XZz41rB for ; Sun, 18 Aug 2019 21:57:56 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1566165475; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=aPFaiVp7G7IIcgWkAhpdgTlo7gt+j0XcCLx9QCEl4yNtMjFtZA1dPyB0CR7b1X1i+j35uFBb1gaSU ZNrrr183+kBE/J8PBCAcdVx+306I4dmCcmJqhohQkIRowXzgC6hbYJdtLjmHf37s+ItVsgUZj8WbPP AwLKclmEp6rGcH8oeaGT044ClH2UXjyHvI/NEmnAjc9NbklQBHV1NUKawhF2zoyBmAVmSEwvtAMay/ A8mJxijOj7faylQxYTNUX+a/X039h/0KejVXz6Qkbr3T34I78UKumEcJ9UUHl5OaHAZ1vMk+onIjxw F5JMar4Kzv0B1K/lrtK0i/hhN+OdFvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=S5ZzNmDn1vy3IDDRu1dxPXW2p74atwavG0VeogbSHls=; b=MJrNzEn153OuUIke0jHh11mcLSWDhw4pmZ3BuXaCMYTT2+WoRjY83krsNuhKsbCMDpHc/1HLtOq03 0Y/O8WE2JgkqF0dpivh3B8mW3k7DMlJAYMsJ6Loy5kgGzPgCvKxBGotWEDLr0pRXYxRUBlxtM7i2t0 XXU0F33inxECh3ZnS2gzU3LKXIcFoSLsslJNLpmIa9CLeAhXKE8CRnUazLDsMszteA96Bpbbi5rdeG evo0eRLP1gsWVZZn7T8cAAv62YgMMuu3FdEqqvXDyRlDvnx5iN2JbA26Hgv2nSHQF/u3DCBJvfmpzc pceKQEZXhEXq1ur//qsjOTlpKL1GqBQ== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=S5ZzNmDn1vy3IDDRu1dxPXW2p74atwavG0VeogbSHls=; b=sB8YVV/sWmmN1Fyg30cjC+hxy/bZVQjLBDebJA0p9K3Fz4+3lwFvRliw5p3EjaZx4IN6897Sr6Xm6 ihhVNw6WuLQCY869bbHx0xae91aUBEMzUrNdGYgY12L4d3iegvT5arafrO63qvfY/W1XLhbeb+BFbf 4US7X5Abt/0AOSDjS3ULjLmtm2mVcxbS0EOsgEJKgTkCzs+2FeNwBuif97qZezkFUGjMJUnpLswV+c 8yvZx1/zFH8okyc9loErJYlYmnYSudH8p36flRUO49Vg03sHcOMPMBfo9gl2dbmxAiFOUWr6JnpY7N 1UrM/4FRIw7yCmsWx6Yf1WRU3/1oZxA== X-MHO-RoutePath: aGlwcGll X-MHO-User: 3a3bde78-c203-11e9-b67b-cdd75d6ce7a8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 3a3bde78-c203-11e9-b67b-cdd75d6ce7a8; Sun, 18 Aug 2019 21:57:54 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x7ILvqsZ073138; Sun, 18 Aug 2019 15:57:52 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: Is it a good idea to use a usb-serial adapter for PPS? Yes, it is. From: Ian Lepore To: Per Hedeland Cc: freebsd-arm@freebsd.org, Hans Petter Selasky Date: Sun, 18 Aug 2019 15:57:52 -0600 In-Reply-To: References: <69a9bed3-4d0a-f8f6-91af-a8f7d84ee307@hedeland.org> <345bae77417c2495f55799b4c7ca2784f4ece9ed.camel@freebsd.org> <7312032d-2908-9414-0445-6b442c3a02e5@hedeland.org> <523b6f0a0fa5f2aeec298fa74df25d3c4af66acc.camel@freebsd.org> <0426fc8b-5398-d8ab-561e-7823c24403a5@hedeland.org> <24b0eaf25b64d6098b390df092866c69e352d859.camel@freebsd.org> <16c91be1-6f2a-b26d-22c7-be8e4ba8eec0@hedeland.org> <72a964c78cbfc36be2345919633ca2196f0783e3.camel@freebsd.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46BWBs11XZz41rB X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.983,0]; ASN(0.00)[asn:16509, ipnet:54.186.0.0/15, country:US] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2019 21:57:57 -0000 On Sun, 2019-08-18 at 22:53 +0200, Per Hedeland wrote: > > > > I probably should have been clearer that I meant there was no > > correlation between the kernel clock and the usb polling on the system > > I was using as a testbed. On most SoCs, and probably even modern x86 > > systems, the same frequency source (typically a 24MHz crystal) will be > > the root clock for both the usb controller hardware and the timer > > hardware from which the kernel clock is derived. However, the kernel > > clock is numerically steered to be more stable in frequency and > > accurate in phase, so once ntpd has been running for long enough to > > capture and disipline the kernel clock, the situation will change. The > > usb polling will still be happening at the drifting frequency of the > > underlying crystal, while the kernel timestamps used to mark the PPS > > pulse time will not be drifting at that rate. > > Understood. What I don't understand is if, and if so how, your > "replacing" the kernel clock with an "exact" frequency from your 10 > MHz clock might affect the USB polling. I don't think there is any connection at all. As I vaguely understand it, the usb ehci driver sets up lists of transfers to be done in memory and hands the ehci hardware a pointer to that list, and the hardware executes everything based on its own internal timers (which are ultimately sourced from the 24mhz clock). It's not like the OS has to periodically wake up and tell the ehci hardware "now is the time to do some polling". > > I think there is some confusion around the concept of usb 1.x devices > > on a usb 2.0 bus. I think there may even be some confusion when a 1.x > > bus is involved. And then adding to the confusion is the likelyhood > > that different usb-serial adapters use different usb transfer types > > (bulk vs interrupt)_to communicate line-state changes. > > > > A usb 1.x bus is divided into 1ms frames. A 2.0 bus is divided into > > 125us (micro-)frames. For interrupt endpoints, a usb 1.x bus limits > > devices to 1 interrupt transfer per frame, and that may imply that > > there is up to 1ms of latency for reporting a DCD change on such a 1.x > > bus. A 2.0 bus allows up to 3 interrupt transfers per microframe, > > implying latency of up to 125us. > > > > However, there is no limit on either 1.x or 2.0 busses for how many > > bulk transfers can happen to a given endpoint during a frame. The > > controller needs to fill a frame with transactions in a way that first > > provides all the g'teed bandwidth that is promised to control, > > interrupt, and isochronous transfers. It is then free to fill all the > > remaining time with bulk transfers. > > > > To me, this implies that you may end up with nearly no latency (and > > negligible jitter) if you have a usb 2.0 bus that has just one or two > > devices on it which are communicating via bulk-transfer endpoints. The > > controller would be continuously sending BULK IN tokens to the one or > > two devices, so that as soon as one of them has data, it gets an > > opportunity to deliver it almost immediately (meaning within a few > > microseconds). > > > > The results I see with FTDI usb-serial adapters which use bulk > > transfers provide some evidence that my theory may be correct. I think > > the bus looks like this: > > > > BULK IN token to usb 1.x device (do you have anything to say?) > > 1.x device NAKs > > BULK IN token to usb 2.0 device > > 2.0 device NAKs > > > > BULK IN token to usb 1.x device > > 1.x device NAKs > > ... (repeat forever) > > > > In other words, the device(s) aren't getting 1 chance per frame to > > transfer data, they are getting many thousands of chances per second. > > I think the bus overhead of the BULK-IN token followed by a NAK from > > the device, along with the various framing bits and crc and all that > > probably adds up to less than 64 bytes per poll. But assuming it took > > as much as 64 bytes to do that, if there was one usb-serial device on a > > usb 2.0 bus, it would be getting asked about 1 million times per second > > whether it had anything to say. > > This is extremely interesting - if it really is the case that the > will poll "as fast as it can", as opposed to always doing it with a > fixed frequency, it would definitely change the picture. Unfortunately > I haven't seen any documentation to support that this is the case. > > I'd welcome input from low-level USB gurus about the bus and controller > > behavior in this regard. > > I'm afraid we have lost freebsd-usb@ in this sub-thread (it was actually > the case before my first comment, but it would probably have happened > anyway, since I'm not subscribed to that list). Unless you know that > "low-level USB gurus" are also subscribed to freebsd-arm@, it might make > sense to forward your message to freebsd-usb@. I think HPS reads the arm@ list, but I'll cc him directly on this reply, just in case he has time to weigh in on this stuff. -- Ian From owner-freebsd-arm@freebsd.org Mon Aug 19 07:21:09 2019 Return-Path: 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 A181DAB1C0 for ; Mon, 19 Aug 2019 07:21:09 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46Blhf5VCnz4QJF; Mon, 19 Aug 2019 07:21:06 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 200C5260266; Mon, 19 Aug 2019 09:20:58 +0200 (CEST) Subject: Re: Is it a good idea to use a usb-serial adapter for PPS? Yes, it is. To: Ian Lepore , Per Hedeland Cc: freebsd-arm@freebsd.org References: <69a9bed3-4d0a-f8f6-91af-a8f7d84ee307@hedeland.org> <345bae77417c2495f55799b4c7ca2784f4ece9ed.camel@freebsd.org> <7312032d-2908-9414-0445-6b442c3a02e5@hedeland.org> <523b6f0a0fa5f2aeec298fa74df25d3c4af66acc.camel@freebsd.org> <0426fc8b-5398-d8ab-561e-7823c24403a5@hedeland.org> <24b0eaf25b64d6098b390df092866c69e352d859.camel@freebsd.org> <16c91be1-6f2a-b26d-22c7-be8e4ba8eec0@hedeland.org> <72a964c78cbfc36be2345919633ca2196f0783e3.camel@freebsd.org> From: Hans Petter Selasky Message-ID: <540c8b5f-5e81-b67b-4a00-49b86044efe0@selasky.org> Date: Mon, 19 Aug 2019 09:20:17 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46Blhf5VCnz4QJF X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-5.85 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.96)[-0.965,0]; IP_SCORE(-2.58)[ip: (-9.11), ipnet: 2a01:4f8::/29(-1.95), asn: 24940(-1.84), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 07:21:09 -0000 On 2019-08-18 23:57, Ian Lepore wrote: > I think HPS reads the arm@ list, but I'll cc him directly on this > reply, just in case he has time to weigh in on this stuff. Hi, I'm subscribed. The behaviour of BULK transfers depend on the actual USB host controller manufacturer. USB transfers are executed by priority, typically: ISOCHRONOUS, INTERRUPT, CONTROL, BULK Depending on the endpoint descriptor, the service rate may vary. The minimum guarantee is to be serviced one time every 125us (for USB2.0). Completion interrupts are usually delayed a bit (63-125us for EHCI/XHCI, 1ms for USB 1.0 via UHCI/OHCI). The USB stack in FreeBSD does not have any memory allocations in the fast path and so is very quick to complete jobs. Also in user-space. Technically speaking, the time device could make predictions about when the packet is read from the USB buffer and when the USB host issues the completion interrupt. These adjustment values could be calibrated by some kind of ping protocol. --HPS From owner-freebsd-arm@freebsd.org Mon Aug 19 08:01:31 2019 Return-Path: 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 DFB7CACD7B for ; Mon, 19 Aug 2019 08:01:31 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by mx1.freebsd.org (Postfix) with ESMTP id 46BmbF1hCbz4SLB for ; Mon, 19 Aug 2019 08:01:28 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ppp118-210-70-93.adl-adc-lon-bras32.tpg.internode.on.net (HELO midget.dons.net.au) ([118.210.70.93]) by ipmail06.adl2.internode.on.net with ESMTP; 19 Aug 2019 17:31:03 +0930 Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.15.2/8.15.2) with ESMTPS id x7J80vBj043527 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 19 Aug 2019 17:30:58 +0930 (ACST) (envelope-from darius@dons.net.au) Received: (from mailnull@localhost) by midget.dons.net.au (8.15.2/8.15.2/Submit) id x7J7e2Ow026024 for ; Mon, 19 Aug 2019 17:10:02 +0930 (ACST) (envelope-from darius@dons.net.au) X-Authentication-Warning: midget.dons.net.au: mailnull set sender to using -f Received: from havok.gsoft.com.au (Havok.gsoft.com.au [203.31.81.177]) by ppp118-210-70-93.adl-adc-lon-bras32.tpg.internode.on.net (envelope-sender ) (MIMEDefang) with ESMTP id x7J7du16025725; Mon, 19 Aug 2019 17:10:02 +0930 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Is it a good idea to use a usb-serial adapter for PPS input? Yes, it is. From: "O'Connor, Daniel" In-Reply-To: <61B1AAF3-40F6-47BC-8F05-7491C13BF288@dons.net.au> Date: Mon, 19 Aug 2019 17:09:56 +0930 Cc: "usb@freebsd.org" , "freebsd-arm@FreeBSD.org" Content-Transfer-Encoding: 7bit Message-Id: <9E142F1A-5E8C-4410-91F5-7C80B3D0A15B@dons.net.au> References: <61B1AAF3-40F6-47BC-8F05-7491C13BF288@dons.net.au> To: Ian Lepore X-Mailer: Apple Mail (2.3445.104.11) X-Spam-Score: 0 () No, score=0.0 required=5.0 tests=SPF_HELO_NONE, SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.1 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: 46BmbF1hCbz4SLB X-Spamd-Bar: ++++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of darius@dons.net.au has no SPF policy when checking 150.101.137.129) smtp.mailfrom=darius@dons.net.au X-Spamd-Result: default: False [6.65 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; HAS_XAW(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(2.22)[ip: (5.83), ipnet: 150.101.0.0/16(3.63), asn: 4739(1.65), country: AU(0.01)]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:4739, ipnet:150.101.0.0/16, country:AU]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.94)[0.935,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.99)[0.994,0]; DMARC_NA(0.00)[dons.net.au]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[0.997,0]; RCVD_IN_DNSWL_NONE(0.00)[129.137.101.150.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[] X-Spam: Yes X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 08:01:31 -0000 > On 12 Aug 2019, at 09:09, O'Connor, Daniel wrote: >> always get lost on single-core processors which are in cpu_idle() at >> the time the hardclock interrupt happens. (But that's fixable by just >> increasing the number of timehands, I think at least 4 are required.) > > OK, how do I increase the number of clock hands? I am going to try this diff but buildkernel is going to take a while... diff --git a/sys/kern/kern_tc.c b/sys/kern/kern_tc.c index 2656fb4d2..00440b6a2 100644 --- a/sys/kern/kern_tc.c +++ b/sys/kern/kern_tc.c @@ -83,8 +83,48 @@ struct timehands { struct timehands *th_next; }; -static struct timehands th0; +static struct timehands th2; static struct timehands th1 = { + .th_next = &th2 +}; + +static struct timehands th3; +static struct timehands th2 = { + .th_next = &th3 +}; + +static struct timehands th4; +static struct timehands th3 = { + .th_next = &th4 +}; + +static struct timehands th5; +static struct timehands th4 = { + .th_next = &th5 +}; + +static struct timehands th6; +static struct timehands th5 = { + .th_next = &th6 +}; + +static struct timehands th7; +static struct timehands th6 = { + .th_next = &th7 +}; + +static struct timehands th8; +static struct timehands th7 = { + .th_next = &th8 +}; + +static struct timehands th9; +static struct timehands th8 = { + .th_next = &th9 +}; + +static struct timehands th0; +static struct timehands th9 = { .th_next = &th0 }; static struct timehands th0 = { -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From owner-freebsd-arm@freebsd.org Mon Aug 19 14:26:47 2019 Return-Path: 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 F318CC8140 for ; Mon, 19 Aug 2019 14:26:47 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2m.ore.mailhop.org (outbound2m.ore.mailhop.org [54.149.155.156]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46Bx7q3mPsz3PKd for ; Mon, 19 Aug 2019 14:26:47 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1566224805; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=oM6oTFCEHZNdkQmxl6u0M9BN6ua+zI6nLpKWlM5Sm0Cw/uIJ0PHoyzfA2qsnyPKtmyzmTsDvj2yC2 73991igd2Go49hOLFAgFEfqguFWel83LRJ8KVs+eOFfyvmRcGnpxEMJt6XHvf2fQYSAIjQJrAVy7gk APSmuRoED4q0mEroxQVjy6EubcGtYQ/O4ahJPjKpoTvfF22TnRLKXU9Q9ujqnfSUKPo1LlBMevWPXX alMfplYjX6oXtGnAnax0cChsUsSicBWQTVAOWxlXdbHh9DAoenB9Jlg6+j8kzQBkNFrkFWqOPT+ap+ YSlVSteXyMeqvJ9bi2jmO5pouMXIuyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=dUhtPb/Y5GQIcYY8TWECX942zsMVTCQS4jJa0WpUPJA=; b=JQ6KnCU0xQioOrLnMPGi/1FrXnutrj+AF2xBSJSDx4fUHs/8V4Cu0zwWG/o/MMSIz3klFYJmw5QAS h2kC3/B9Y9j9sfe1KUxFWYcNb8YUfLyBn2R5YA57yDnjXgD8f2gcFBQMleFgXmIZt+QvshKDloZ6tX r4JnT0d4oIKYlQHx0i/sqzwrLPN1mONyvYhtccfRb2AhlIsECsIsXZ060UuakTASKUNfMUbcvVFZi/ Kkghbft1yxf1BvL6IRLOIbE6CCeD3W4PXvFKwx9lazgpILNQI4o/IlgkG5I6VZy3mxXpVxx6HGUi9I GHNzEbOAs3ZVqfCqxPh6Zo3qyYm4g/g== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=dUhtPb/Y5GQIcYY8TWECX942zsMVTCQS4jJa0WpUPJA=; b=fVXOnUf+gkoN5DNXHjC9SVKSHooihC5+tweDM8Lps1+/EB9i/JlNlNdnxdszBXbHHRj25yQDNMbEn gSBes40ep+5W6TSm57p2/dJ7tVe3tsAeBysJQmOUOKFBAE3iIiLp05oiP5w2sd6PcH5GgL2tI97/pV 0rZ1aaU8sj255aVK4R3bUdsJurAzYP7V4kiOL7KwZNFFjFxlnoEtOo4782xkzGWhG1zbp+u31ffwME HQiXjVhOupbGEYUdi9iRYVheBF0qeFZplT4muAYmoCYOxJm+BI8Mo/2xUI0NJjNr+SNV5hcb5qzQsA 8kxFnWxh3RNPwAD+dE1XjzZr2dthm4A== X-MHO-RoutePath: aGlwcGll X-MHO-User: 5d5bc8dc-c28d-11e9-85ec-13b9aae3a1d2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 5d5bc8dc-c28d-11e9-85ec-13b9aae3a1d2; Mon, 19 Aug 2019 14:26:44 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x7JEQggv075993; Mon, 19 Aug 2019 08:26:42 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: Is it a good idea to use a usb-serial adapter for PPS input? Yes, it is. From: Ian Lepore To: "O'Connor, Daniel" Cc: "usb@freebsd.org" , "freebsd-arm@FreeBSD.org" Date: Mon, 19 Aug 2019 08:26:42 -0600 In-Reply-To: <9E142F1A-5E8C-4410-91F5-7C80B3D0A15B@dons.net.au> References: <61B1AAF3-40F6-47BC-8F05-7491C13BF288@dons.net.au> <9E142F1A-5E8C-4410-91F5-7C80B3D0A15B@dons.net.au> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46Bx7q3mPsz3PKd X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.983,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 14:26:48 -0000 On Mon, 2019-08-19 at 17:09 +0930, O'Connor, Daniel wrote: > > On 12 Aug 2019, at 09:09, O'Connor, Daniel > > wrote: > > > always get lost on single-core processors which are in cpu_idle() > > > at > > > the time the hardclock interrupt happens. (But that's fixable by > > > just > > > increasing the number of timehands, I think at least 4 are > > > required.) > > > > OK, how do I increase the number of clock hands? > > I am going to try this diff but buildkernel is going to take a > while... > > diff --git a/sys/kern/kern_tc.c b/sys/kern/kern_tc.c > index 2656fb4d2..00440b6a2 100644 > --- a/sys/kern/kern_tc.c > +++ b/sys/kern/kern_tc.c > @@ -83,8 +83,48 @@ struct timehands { > struct timehands *th_next; > }; > > -static struct timehands th0; > +static struct timehands th2; > static struct timehands th1 = { > + .th_next = &th2 > +}; > + > +static struct timehands th3; > +static struct timehands th2 = { > + .th_next = &th3 > +}; > + > +static struct timehands th4; > +static struct timehands th3 = { > + .th_next = &th4 > +}; > + > +static struct timehands th5; > +static struct timehands th4 = { > + .th_next = &th5 > +}; > + > +static struct timehands th6; > +static struct timehands th5 = { > + .th_next = &th6 > +}; > + > +static struct timehands th7; > +static struct timehands th6 = { > + .th_next = &th7 > +}; > + > +static struct timehands th8; > +static struct timehands th7 = { > + .th_next = &th8 > +}; > + > +static struct timehands th9; > +static struct timehands th8 = { > + .th_next = &th9 > +}; > + > +static struct timehands th0; > +static struct timehands th9 = { > .th_next = &th0 > }; > static struct timehands th0 = { > Oh, I'm sorry, I forgot to respond about this. Yeah, that patch would do it. I think a minimum of 4 sets of timehands are needed for pps capture on a single-core system with a latching timecounter like dmtpps. -- Ian From owner-freebsd-arm@freebsd.org Mon Aug 19 14:32:28 2019 Return-Path: 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 5E5B5C8411 for ; Mon, 19 Aug 2019 14:32:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46BxGM5KxRz3Pmj for ; Mon, 19 Aug 2019 14:32:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x829.google.com with SMTP id j15so2071270qtl.13 for ; Mon, 19 Aug 2019 07:32:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YJ5VLjHDvS5lMHvLDxXuoV6qN0OIhFuG04wYGF2nOf0=; b=Qy7YQEkF9+SfqzO+SNpQdwCd+/umaBobHdS8oPaFh+gfpyXuzGtOqb2JyGOaaK7W/Q 9urSGI1NzrMdxfH96BrNJl/6W0kFnWysQOoPWRgk3ChZbUrYJ5KHrT2bljHdqMJS58hS IIo5L6Srv9YDk2DXL9fCy5shoYALt+rj8HhsszTy5dX4CgFqY2tmW88Qt736tNCLlqh/ y2qej4UP9DJoZMGe5odAJ/1Updu9QA5KmG1nPQFFAkLPLtx1oa6i3HmzFVMTiDs0r1Eh jBXis3eJDYhOimam6RzJXer8yix1PepOd7dSM2aip6fM99XxKkUFinkcuoUWUKshf89E sXCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YJ5VLjHDvS5lMHvLDxXuoV6qN0OIhFuG04wYGF2nOf0=; b=eN9usxEskKPc47YNb0f58Zbp2Wo4D4nP3aWgZ5PzCbO0/36+ywNaCM0Fhvrn5uThBN 7v/8vzLYLxK4SzdUFvdOsPgqrqMt7Py+uZssBGrzAmhAKw2wexisfIX17LP+lqoTNcEL 5ivT1lZzvBQ8whe/5OOQrClqcSVJ3+TO1sanfVcHl1qGnFVqgsz1evVu2EcrCOgftbwy VPhOQS8l/RDzSJd4XjPaRaRJ7VK8ggVJ2HzncuWjkXtLTAPOHX0zit+feK9oUEbxdDOl wGBnMBA7vk/1tHLWorSKLcanowPzqvffdHk8s2oeQHIep9V3HhTEs/tvvCWu27HKrg1/ zt9w== X-Gm-Message-State: APjAAAVYiiWmzxofD907c5gmiyzjyc4zsHw+YrRdU75XqdjLmV85xaSu qHC09FdjdVwio61RJgW/9hSvIGuF7vujr/nfQ5B+WA== X-Google-Smtp-Source: APXvYqydrxtofOhGYdwUYtSXvQiF5mH3GSCf+S0/DKGl9aH4kyAK2iSDmH2xRX646FzhYDhWi6tW8tWmZdwWhsJNcz0= X-Received: by 2002:a0c:e5c6:: with SMTP id u6mr10984000qvm.102.1566225146359; Mon, 19 Aug 2019 07:32:26 -0700 (PDT) MIME-Version: 1.0 References: <61B1AAF3-40F6-47BC-8F05-7491C13BF288@dons.net.au> <9E142F1A-5E8C-4410-91F5-7C80B3D0A15B@dons.net.au> In-Reply-To: From: Warner Losh Date: Mon, 19 Aug 2019 08:32:15 -0600 Message-ID: Subject: Re: Is it a good idea to use a usb-serial adapter for PPS input? Yes, it is. To: Ian Lepore Cc: "O'Connor, Daniel" , "usb@freebsd.org" , "freebsd-arm@FreeBSD.org" X-Rspamd-Queue-Id: 46BxGM5KxRz3Pmj X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=Qy7YQEkF; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::829) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-5.94 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-0.996,0]; RCVD_IN_DNSWL_NONE(0.00)[9.2.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.95)[ip: (-9.39), ipnet: 2607:f8b0::/32(-2.93), asn: 15169(-2.37), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; SUBJECT_HAS_QUESTION(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 14:32:28 -0000 On Mon, Aug 19, 2019 at 8:26 AM Ian Lepore wrote: > On Mon, 2019-08-19 at 17:09 +0930, O'Connor, Daniel wrote: > > > On 12 Aug 2019, at 09:09, O'Connor, Daniel > > > wrote: > > > > always get lost on single-core processors which are in cpu_idle() > > > > at > > > > the time the hardclock interrupt happens. (But that's fixable by > > > > just > > > > increasing the number of timehands, I think at least 4 are > > > > required.) > > > > > > OK, how do I increase the number of clock hands? > > > > I am going to try this diff but buildkernel is going to take a > > while... > > > > diff --git a/sys/kern/kern_tc.c b/sys/kern/kern_tc.c > > index 2656fb4d2..00440b6a2 100644 > > --- a/sys/kern/kern_tc.c > > +++ b/sys/kern/kern_tc.c > > @@ -83,8 +83,48 @@ struct timehands { > > struct timehands *th_next; > > }; > > > > -static struct timehands th0; > > +static struct timehands th2; > > static struct timehands th1 = { > > + .th_next = &th2 > > +}; > > + > > +static struct timehands th3; > > +static struct timehands th2 = { > > + .th_next = &th3 > > +}; > > + > > +static struct timehands th4; > > +static struct timehands th3 = { > > + .th_next = &th4 > > +}; > > + > > +static struct timehands th5; > > +static struct timehands th4 = { > > + .th_next = &th5 > > +}; > > + > > +static struct timehands th6; > > +static struct timehands th5 = { > > + .th_next = &th6 > > +}; > > + > > +static struct timehands th7; > > +static struct timehands th6 = { > > + .th_next = &th7 > > +}; > > + > > +static struct timehands th8; > > +static struct timehands th7 = { > > + .th_next = &th8 > > +}; > > + > > +static struct timehands th9; > > +static struct timehands th8 = { > > + .th_next = &th9 > > +}; > > + > > +static struct timehands th0; > > +static struct timehands th9 = { > > .th_next = &th0 > > }; > > static struct timehands th0 = { > > > > Oh, I'm sorry, I forgot to respond about this. Yeah, that patch would > do it. I think a minimum of 4 sets of timehands are needed for pps > capture on a single-core system with a latching timecounter like > dmtpps. > Do we have a good (or even a bad) writeup of how to know that 4 is good, or when 5 or 6 might be needed? Warner From owner-freebsd-arm@freebsd.org Mon Aug 19 14:47:51 2019 Return-Path: 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 BEC16C8B21 for ; Mon, 19 Aug 2019 14:47:51 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound3d.ore.mailhop.org (outbound3d.ore.mailhop.org [54.186.57.195]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46Bxc72dJKz3QbG for ; Mon, 19 Aug 2019 14:47:51 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1566226070; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=IJMJwkGMxlKF9/9fob9209DQ5oS/hqyLNy5Y4q9F0VFiTOQCPX8C5gKAQ0jGgTEv9R1VAmEkHvhaN DqtGB9FB2rXWBTh9XSijqRwoTZAWk3b2Z4qfgomJizcfd8evnJlI8f1FJsQ0L4cOsaDvWMUEXEXs3S dKXGopu07OA+Rr14MZwgVslaUiNSdiJxyy5fQM2nFE3BaAnPtszOQF2fFZjk6RvZOLoCglSBycqgUw fDFpwiNuWtQme0PYEahkXx78OY5lVoKht6fRLOMsSNYtzFbCzhJYgzjDJCj/RHLlvCXDdsN5VfAnQh hmgHsbtvJBm58sVA8MvEWjkXLdWH1Bw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=mISlLEyjLj4nys2etSdFebfNNm6qAUTNeahEhQdYBpo=; b=l60QLTPTuJYaKU0y49XHec/rpBqKd9QZ0aQtqgf6enD7ADZ5ekj0nLncAGhvw8/oYL5rXgTWaiBn1 zAA/xuR1soM7pbbX+JbAycS4tasx21r37RH4wSz7YSu0uIEwantMK6kleir6KFEaELEv0Wnu1Fn0Mi uAoel8Xs82TSevdMj4Bw3rauhHdqpstznd8SeHKXpLadhlBBvQSWhYI1pqgwj20UOMVfcgbUr47j5D 72eg7dhi5VLfuLLlPjVYwq0rFyyNO9vsN9d60qjSAHiZFx6sIvUixWllZLFbQ+ClzUbBSzbeTNw7aG 17sqJIB0PBpAWCIR20D1jZmFlfs1law== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=mISlLEyjLj4nys2etSdFebfNNm6qAUTNeahEhQdYBpo=; b=Uw571RKd94vGT50d1J+trqpHKM/Ak9g4a5ciujKwOHOXMvzlPV7BQTEUfemc+1yXmIAhXL2lua/lM JGavbRKoxgmKHNZjYXVR7YJ0ejW45wZnASPvNBz43y7D16x83Us42zIifCe+R2A7cp0ekqlNX8A2di Fdet3KIED57/AcPobzrgkoq1r5qP99MNzjLXLm/VpMCJzkaonu4cVc5hjfnH4T6mvP5r5DRpgDgzRd VTZobYFfxK/HGpLNHTQB0wx2kUu8ALBiwEc9xGSCQxdy2OAN+Ck/KfQLMGiS3mP4FTxYXQkxjE5VS0 vegedjGGRSxOERhC+by0I4ER2YS7RLg== X-MHO-RoutePath: aGlwcGll X-MHO-User: 4ef77d15-c290-11e9-b67b-cdd75d6ce7a8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 4ef77d15-c290-11e9-b67b-cdd75d6ce7a8; Mon, 19 Aug 2019 14:47:48 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x7JElkKt076047; Mon, 19 Aug 2019 08:47:46 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: dmtpps driver on beaglebone [was: Is it a good idea to use a usb-serial adapter for PPS input? Yes, it is.] From: Ian Lepore To: Warner Losh Cc: "O'Connor, Daniel" , "freebsd-arm@FreeBSD.org" Date: Mon, 19 Aug 2019 08:47:46 -0600 In-Reply-To: References: <61B1AAF3-40F6-47BC-8F05-7491C13BF288@dons.net.au> <9E142F1A-5E8C-4410-91F5-7C80B3D0A15B@dons.net.au> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46Bxc72dJKz3QbG X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.983,0]; ASN(0.00)[asn:16509, ipnet:54.186.0.0/15, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 14:47:51 -0000 On Mon, 2019-08-19 at 08:32 -0600, Warner Losh wrote: > On Mon, Aug 19, 2019 at 8:26 AM Ian Lepore wrote: > > > On Mon, 2019-08-19 at 17:09 +0930, O'Connor, Daniel wrote: > > > > On 12 Aug 2019, at 09:09, O'Connor, Daniel > > > > wrote: > > > > > always get lost on single-core processors which are in cpu_idle() > > > > > at > > > > > the time the hardclock interrupt happens. (But that's fixable by > > > > > just > > > > > increasing the number of timehands, I think at least 4 are > > > > > required.) > > > > > > > > OK, how do I increase the number of clock hands? > > > > > > I am going to try this diff but buildkernel is going to take a > > > while... > > > > > > diff --git a/sys/kern/kern_tc.c b/sys/kern/kern_tc.c > > > index 2656fb4d2..00440b6a2 100644 > > > --- a/sys/kern/kern_tc.c > > > +++ b/sys/kern/kern_tc.c > > > @@ -83,8 +83,48 @@ struct timehands { > > > struct timehands *th_next; > > > }; > > > > > > -static struct timehands th0; > > > +static struct timehands th2; > > > static struct timehands th1 = { > > > + .th_next = &th2 > > > +}; > > > + > > > +static struct timehands th3; > > > +static struct timehands th2 = { > > > + .th_next = &th3 > > > +}; > > > + > > > +static struct timehands th4; > > > +static struct timehands th3 = { > > > + .th_next = &th4 > > > +}; > > > + > > > +static struct timehands th5; > > > +static struct timehands th4 = { > > > + .th_next = &th5 > > > +}; > > > + > > > +static struct timehands th6; > > > +static struct timehands th5 = { > > > + .th_next = &th6 > > > +}; > > > + > > > +static struct timehands th7; > > > +static struct timehands th6 = { > > > + .th_next = &th7 > > > +}; > > > + > > > +static struct timehands th8; > > > +static struct timehands th7 = { > > > + .th_next = &th8 > > > +}; > > > + > > > +static struct timehands th9; > > > +static struct timehands th8 = { > > > + .th_next = &th9 > > > +}; > > > + > > > +static struct timehands th0; > > > +static struct timehands th9 = { > > > .th_next = &th0 > > > }; > > > static struct timehands th0 = { > > > > > > > Oh, I'm sorry, I forgot to respond about this. Yeah, that patch would > > do it. I think a minimum of 4 sets of timehands are needed for pps > > capture on a single-core system with a latching timecounter like > > dmtpps. > > > > Do we have a good (or even a bad) writeup of how to know that 4 is good, or > when 5 or 6 might be needed? > I first ran into the problem on a beaglebone a few years ago, not that long after the number was reduced to two. The number 4 is pretty much just a vague-ish memory of the debugging I did back then. When you don't have enough timehands, the symptom is that you lose most of the pps events (but enough get captured that ntpd will more or less run properly on the reduced data). The busier the system is, the more events get captured succesfully, because the loss is caused when the pps pulse happens while sleeping in cpu_idle(); the path that unwinds out of there leads to calling tc_windup 3 times, iirc, which means the value latched in the timecounter hardware belongs to a set of timehands whose generation count is not valid anymore because of all the tc_windup calls, and the event gets discarded because of the generation mismatch. -- Ian From owner-freebsd-arm@freebsd.org Mon Aug 19 15:23:01 2019 Return-Path: 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 5BD03C9417 for ; Mon, 19 Aug 2019 15:23:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46ByNj0NWlz3x57; Mon, 19 Aug 2019 15:23:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x7JFMirF077073 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 19 Aug 2019 18:22:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x7JFMirF077073 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x7JFMiMW077072; Mon, 19 Aug 2019 18:22:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 19 Aug 2019 18:22:44 +0300 From: Konstantin Belousov To: Ian Lepore Cc: Warner Losh , "freebsd-arm@FreeBSD.org" Subject: Re: dmtpps driver on beaglebone [was: Is it a good idea to use a usb-serial adapter for PPS input? Yes, it is.] Message-ID: <20190819152244.GN71821@kib.kiev.ua> References: <61B1AAF3-40F6-47BC-8F05-7491C13BF288@dons.net.au> <9E142F1A-5E8C-4410-91F5-7C80B3D0A15B@dons.net.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-Rspamd-Queue-Id: 46ByNj0NWlz3x57 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.94 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.94)[-0.937,0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 15:23:01 -0000 On Mon, Aug 19, 2019 at 08:47:46AM -0600, Ian Lepore wrote: > I first ran into the problem on a beaglebone a few years ago, not that > long after the number was reduced to two. The number 4 is pretty much > just a vague-ish memory of the debugging I did back then. When you > don't have enough timehands, the symptom is that you lose most of the > pps events (but enough get captured that ntpd will more or less run > properly on the reduced data). > > The busier the system is, the more events get captured succesfully, > because the loss is caused when the pps pulse happens while sleeping in > cpu_idle(); the path that unwinds out of there leads to calling > tc_windup 3 times, iirc, which means the value latched in the > timecounter hardware belongs to a set of timehands whose generation > count is not valid anymore because of all the tc_windup calls, and the > event gets discarded because of the generation mismatch. Is the problem specific to the platform then ? The issue you see might come from tc_ticktock(), but it is strange. All calls to tc_windup() are serialized by spinlock. tc_ticktock(), potentially being called from interrupt context, uses try-lock to avoid spinning while other CPU does the update. But this is impossible on UP machine, because spinlock in top half disables interrupts, which means that event that triggers tc_ticktock() call and which trylock fails should be impossible, until the top half finishes. Having too many timehands is bad because reader get a higher chance to find obsoleted th pointer. With the rework of the generation counts for timehands reader would not use stalled data, but it might have to spin somewhat prolonged time. In fact, it might be worth trying reducing the timehands count from two to one, since then there is no non-current th at all. From owner-freebsd-arm@freebsd.org Mon Aug 19 15:52:08 2019 Return-Path: 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 C321ACA061 for ; Mon, 19 Aug 2019 15:52:08 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2m.ore.mailhop.org (outbound2m.ore.mailhop.org [54.149.155.156]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46Bz2J4BbJz3ydj for ; Mon, 19 Aug 2019 15:52:08 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1566229926; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=nz0Z/2sqqez1ElCOMgiNUoPiukkCV4VF5WlX8ZErJzJd5aVLJR8DBaZy5icT5bCO6somHEbyn+8na J856QGL5q6Fe1TpQmggfc0GuQmoF2zoU0oYJhkSl6feXgQpwSpEVavXAEerIugMNF9mU/xx1Glg5Pq dBLLQSW4zlufcxl5XRH6LKlphnLRZQ0OG6zCdrwr2K5uA/x1goJys3gqirpRQpw1FHaTHJq9P7/fuU fQXmDPIiY0nG9rqf2Hwh/DAcCBIvIXoLgqjkL5ANmUqOHHO3qYwbnRtb6xJ4+JJM/n8JwlidA0/xBw L//kjQyyTxOZO19byV3TzAMPWdGbUIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=1s36/kbLRuPHZahLoSbUDpqMfuFjKo42SUI2XyOrdYQ=; b=itovK+hzExaUt5H4BTQ32qaEzZCVJ08hoTWSroNeS4NiSu9Q/ADrrAZ9J2kEwbuH+liT1HEoL2APO Sl/OFxJTVGdzJrsb+wqwX/SUMuwFo915Eax0fPGTEoEzUj4zi0ey8tOZhqiyTUkPG9gOTrytRlgeOO eT/mxz6I1xAqGw8SJ5oa2AXsqsP7w6VF4y0d2u6NbkkRsmkg6I9ON7RwyKvfhA36cVa8qJCdwPpKWn sOzP+TTAwhkmEMPVuNoYC1oKpt/n2S3tcDtPJspeGBgHNZQMv1A1bgJ0AEO1fg95blCsHGve7jx9vU c9ZBDouAqoDHZROXT2n+l3fGBDkGMKg== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=1s36/kbLRuPHZahLoSbUDpqMfuFjKo42SUI2XyOrdYQ=; b=eOHn1Lo2pbi1JZEUcWOKXDU2CwjGVLrUcF/Sno3h972uqcKhtIlbjWnAgAD0Q8dr622eZqUV5JPnK qKohnwUKUzBZvgCNbtsXdyaFkwl2V+QKGGhkwdkI8W/YQrszSIpSFE/oJBSWQrU6mGUuJkdRuQ1nWq /7Dhey0Afj3BTsfBXSLzUUzeBVcGCFQa6q0bVKiWop2/rMM+Nqzp3hyOWFY/OWxD/kgtUvAkrDUW8q iOZHM3fSwBFur6x8OV84Hnrwf1FTBD5bG2w0pDM4WmLC1dfDNj8YpYiPxVehvDrnMmLcWi2WGCbdMZ EloKUcwjKJghOUgG/sOLw9FfI4IcPFA== X-MHO-RoutePath: aGlwcGll X-MHO-User: 49f9d5ec-c299-11e9-85ec-13b9aae3a1d2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 49f9d5ec-c299-11e9-85ec-13b9aae3a1d2; Mon, 19 Aug 2019 15:52:05 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x7JFq39k076197; Mon, 19 Aug 2019 09:52:03 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <8220eafa44d1f3a4d38e3ecfd18f2ff9c7f3ce97.camel@freebsd.org> Subject: Re: dmtpps driver on beaglebone [was: Is it a good idea to use a usb-serial adapter for PPS input? Yes, it is.] From: Ian Lepore To: Konstantin Belousov Cc: Warner Losh , "freebsd-arm@FreeBSD.org" Date: Mon, 19 Aug 2019 09:52:03 -0600 In-Reply-To: <20190819152244.GN71821@kib.kiev.ua> References: <61B1AAF3-40F6-47BC-8F05-7491C13BF288@dons.net.au> <9E142F1A-5E8C-4410-91F5-7C80B3D0A15B@dons.net.au> <20190819152244.GN71821@kib.kiev.ua> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46Bz2J4BbJz3ydj X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.983,0]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 15:52:08 -0000 On Mon, 2019-08-19 at 18:22 +0300, Konstantin Belousov wrote: > On Mon, Aug 19, 2019 at 08:47:46AM -0600, Ian Lepore wrote: > > I first ran into the problem on a beaglebone a few years ago, not that > > long after the number was reduced to two. The number 4 is pretty much > > just a vague-ish memory of the debugging I did back then. When you > > don't have enough timehands, the symptom is that you lose most of the > > pps events (but enough get captured that ntpd will more or less run > > properly on the reduced data). > > > > The busier the system is, the more events get captured succesfully, > > because the loss is caused when the pps pulse happens while sleeping in > > cpu_idle(); the path that unwinds out of there leads to calling > > tc_windup 3 times, iirc, which means the value latched in the > > timecounter hardware belongs to a set of timehands whose generation > > count is not valid anymore because of all the tc_windup calls, and the > > event gets discarded because of the generation mismatch. > > Is the problem specific to the platform then ? I think it is specific to timecounters that implement pps capture using the polling mechanism (tc_poll_pps pointer is non-NULL), and I remember that there was something about the sequence of events that made me think it would only be a problem on a single-core system. Or maybe just way more likely on a single-core system (I've got similarly- structured drivers on multicore systems that don't have this problem). But I don't think it was so much platform-specific as specific to that pair of conditions. > > The issue you see might come from tc_ticktock(), but it is strange. > All calls to tc_windup() are serialized by spinlock. tc_ticktock(), > potentially being called from interrupt context, uses try-lock to avoid > spinning while other CPU does the update. But this is impossible on UP > machine, because spinlock in top half disables interrupts, which means > that event that triggers tc_ticktock() call and which trylock fails > should be impossible, until the top half finishes. > > Having too many timehands is bad because reader get a higher chance to > find obsoleted th pointer. With the rework of the generation counts for > timehands reader would not use stalled data, but it might have to spin > somewhat prolonged time. > > In fact, it might be worth trying reducing the timehands count from two > to one, since then there is no non-current th at all. The driver involved is arm/ti/am335x/am335x_dmptpps.c. The basic sequence that occurs is: The dmtpps_poll() function is called (via the timecounter.tc_poll_pps pointer), and it calls pps_capture(), then schedules a taskqueue_fast task to do the rest of the processing. That task function calls pps_event(), and most of the time pps_event() does nothing because it hits this early out: /* If the timecounter was wound up underneath us, bail out. */ if (pps->capgen == 0 || pps->capgen != atomic_load_acq_int(&pps->capth->th_generation)) return; I forget the exact sequence, but there was something about getting from the point where the taskqueue task begins running to the point where it calls pps_event() that almost always burned through 3 timehands generations, but if the machine was busy enough, sometimes there would only be one windup and the event would get processed properly. I don't remember why I used a taskqueue task to separate the capture and event processing. Maybe so I could use a mutex to protect the pps event state, and it was written before I extended the internal pps api stuff to let drivers use a spin mutex with pps_ioctl(). -- Ian From owner-freebsd-arm@freebsd.org Mon Aug 19 17:26:25 2019 Return-Path: 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 EE40DCC39B for ; Mon, 19 Aug 2019 17:26:25 +0000 (UTC) (envelope-from rwa@athabascau.ca) Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-co1nam05on0624.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe50::624]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46C1740ryjz44V0; Mon, 19 Aug 2019 17:26:23 +0000 (UTC) (envelope-from rwa@athabascau.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ebWAAxerkRxgsIM++9PP7J5vEor1MY7Ol6u17RpMm2+HghKC6daq9wtGYbygxKS30dK8Y8YZ0+27yS9JJB6CVUrhQlbw8V1GofauCJj+6aLtbVCQnKjQuOOH9Vc4YVddrgJe8PfgRN0Mtk2CPRNGS8D1bZg6/Bc1njrtB17JhX0Ao3UI3L7egh+Guc9AVOCLxwD7zVzY265u/aDbnVbMWqdQCRDvA5LDgOF+nfu1UCdELrMw/rzC0+94SShiKR295MftSTGxHnD62rr6cGgz5hBBxHRNBEBARpyRutHJGdf1ptMtkeADA0jv0WthgZaJXjuRV5BiUzj7N/kA0WxW5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3cY2FDV2zHLwpknDU7C+etPwgOD329cr3+iP/z5yI8A=; b=RVBsd551N24l6xIavzLkqVkdsHJtMcoE0hcf8QH7f26ep3Cvu9g/j5yPJkzhQY95GnaMf/ltFmm7XDTO9CIrMJbp2fIJoZ+kBEcz+Pg4ShDgxR8urajpeA7IqdYIv+l21R5eeOSdrE5M6yyX/kpHMJ9agZk3cdlgGy+8cTTkH73xZGCCR+TKfIuYyvbynb5mQvZUSSzt+kuW7P+Lsem0MKmVviy+1Z12bNNEjAtN1+wXTj4hGJdWqe1uM8564NQCqviYVGhn0K6BgdcyaWB/rwet2vKScIs9WidStaDX6vuSmuAjRlmP6xHh5qumS+Izvu4ZkMqML/pSOG075yLhDQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 131.232.32.37) smtp.rcpttodomain=freebsd.org smtp.mailfrom=athabascau.ca; dmarc=bestguesspass action=none header.from=athabascau.ca; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=austaff.onmicrosoft.com; s=selector2-austaff-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3cY2FDV2zHLwpknDU7C+etPwgOD329cr3+iP/z5yI8A=; b=wHrjzABXnYCMU7aNXhQUZcWsuXZZ2XsnwJoRcqxx8WnuCc5yAguo0JsuI7i6NklrrIEbTLvmXo6xo0Y1O4g1A4phYiRXqj6AufW2WuS6C9Q0t0xJeyLhpAUv4NPjLgNx2jiwSalkrBUtUlXr1GofzLS3e7KoyEKah2N8zi3rKf4= Received: from MWHPR13CA0029.namprd13.prod.outlook.com (10.173.117.143) by CY4PR1301MB2166.namprd13.prod.outlook.com (10.171.240.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.15; Mon, 19 Aug 2019 17:26:19 +0000 Received: from TO1CAN01FT007.eop-CAN01.prod.protection.outlook.com (2a01:111:f400:7e5d::209) by MWHPR13CA0029.outlook.office365.com (2603:10b6:300:95::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.6 via Frontend Transport; Mon, 19 Aug 2019 17:26:19 +0000 Received-SPF: Pass (protection.outlook.com: domain of athabascau.ca designates 131.232.32.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.232.32.37; helo=smtp-relay.cs.athabascau.ca; Received: from smtp-relay.cs.athabascau.ca (131.232.32.37) by TO1CAN01FT007.mail.protection.outlook.com (10.152.122.104) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.16 via Frontend Transport; Mon, 19 Aug 2019 17:26:18 +0000 Received: from autopsy.pc.athabascau.ca (autopsy.pc.athabascau.ca [131.232.4.80]) by smtp-relay.cs.athabascau.ca (Postfix) with ESMTPS id 08A1C2016E; Mon, 19 Aug 2019 11:26:18 -0600 (MDT) Date: Mon, 19 Aug 2019 11:26:17 -0600 (MDT) From: Ross Alexander X-X-Sender: rwa@autopsy.pc.athabascau.ca To: Ian Lepore cc: freebsd-arm@freebsd.org Subject: Re: Is it a good idea to use a usb-serial adapter for PPS? Yes, it is. In-Reply-To: <804cfca3edf6d8d40a72257b4f1e876200721c48.camel@freebsd.org> Message-ID: References: <804cfca3edf6d8d40a72257b4f1e876200721c48.camel@freebsd.org> User-Agent: Alpine 2.21.99999 (BSF 352 2019-06-22) Organization: Athabasca University MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.232.32.37; IPV:NLI; CTRY:CA; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(39860400002)(376002)(346002)(2980300002)(189003)(199004)(55674003)(6916009)(14444005)(47776003)(50466002)(186003)(26005)(426003)(956004)(11346002)(446003)(476003)(126002)(486006)(336012)(36916002)(76176011)(7696005)(86362001)(305945005)(8676002)(246002)(7636002)(786003)(316002)(478600001)(106002)(58126008)(70586007)(70206006)(966005)(8746002)(8936002)(23726003)(2906002)(5660300002)(6266002)(6306002)(4326008)(356004)(6246003)(450100002)(229853002)(55016002)(102196002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR1301MB2166; H:smtp-relay.cs.athabascau.ca; FPR:; SPF:Pass; LANG:en; PTR:vs001lpmp1609.cs.athabascau.ca; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8ebf1b25-f569-4220-10eb-08d724ca5900 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(4709080)(1401327)(2017052603328); SRVR:CY4PR1301MB2166; X-MS-TrafficTypeDiagnostic: CY4PR1301MB2166: X-MS-Exchange-PUrlCount: 1 X-Microsoft-Antispam-PRVS: Content-Transfer-Encoding: quoted-printable X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-Forefront-PRVS: 0134AD334F X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: wLuVuL4oIiO1TECr8mjlOZnqGWyd7ysXpWn8nqEUJ02e8LVAQ4BAm1I4YSjCUcBw78+JVefcB+BKqfpU2GB20B9WDJdcwVMDYllQg6N4dhHdze7W9JN36XT5/CDsFKV1mmL4MmkRKkTCI71t76IaIVhxCihwkIELDqFxXiYaMTuyq+LO4wseRRdJ/hQKnOlg4FzSlzQnR+VWH0jEc2nFttc0vHi6DMx8DiwZ2U/w44CsY6usdbf+MetmUOrQ9AP5XBcNDiC/whtwDH1RqP53/Y/1TtYVZxq4HxXcDwOGmr4nIuO3JJ89kiGi/S6NujT2Oi8yeaO3lNqoCDzQ8L0pzdDyvj04fS/j4XVVVYCcW6+YPIZ9o3S84762ywSkB9MXPvbatAHh/CK6PvXrl+GGyEyajOec4E0wG2AXiTw6TsQ= X-OriginatorOrg: athabascau.ca X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Aug 2019 17:26:18.9753 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8ebf1b25-f569-4220-10eb-08d724ca5900 X-MS-Exchange-CrossTenant-Id: a893bdd2-f460-4252-aa34-4d057436a09d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=a893bdd2-f460-4252-aa34-4d057436a09d; Ip=[131.232.32.37]; Helo=[smtp-relay.cs.athabascau.ca] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1301MB2166 X-Rspamd-Queue-Id: 46C1740ryjz44V0 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=austaff.onmicrosoft.com header.s=selector2-austaff-onmicrosoft-com header.b=wHrjzABX; dmarc=none; spf=pass (mx1.freebsd.org: domain of rwa@athabascau.ca designates 2a01:111:f400:fe50::624 as permitted sender) smtp.mailfrom=rwa@athabascau.ca X-Spamd-Result: default: False [-5.52 / 15.00]; IP_SCORE(-1.06)[ipnet: 2a01:111:f000::/36(-2.91), asn: 8075(-2.32), country: US(-0.05)]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[austaff.onmicrosoft.com:s=selector2-austaff-onmicrosoft-com]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f400::/48]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[athabascau.ca]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; HAS_ORG_HEADER(0.00)[]; DKIM_TRACE(0.00)[austaff.onmicrosoft.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.97)[-0.966,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:2a01:111:f000::/36, country:US]; ARC_ALLOW(-1.00)[i=1]; SUBJECT_HAS_QUESTION(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 17:26:26 -0000 On Sun, 18 Aug 2019, Ian Lepore wrote: > On Thu, 2019-08-15 at 16:02 -0600, Ross Alexander wrote: >> In <24b0eaf25b64d6098b390df092866c69e352d859.camel@freebsd.org>, >> Ian Lepore writes: >> >>> [... ed.] I arranged to use a very stable nearly-drift-free >>> frequency source instead of a cheap crystal for counting time in the >>> kernel. >> >> You have my complete and focussed attention. Say on. > > I detailed the design of the measurement system in the original > message. Basically it involves feeding a very stable external clock > signal to a block of timer hardware within the imx6 SoC and using that > timer hardware as the kernel clock. The source of the stable external > clock has these specs: > > https://www.microsemi.com/product-directory/gps-instruments/4152-syncsyst= em-4380a > > I'm a software engineer for the division of Microsemi that makes those > devices. If it wasn't the clock source you wanted to hear more about, > then let me know in more detail what you'd like to know. No, the clock source is the ticket. I've got a TAPR clockblock lying around somewhere, and have been meaning to pick up a precision 10 MHz source from eBay (or equiv.) for some time. In the meantime I've just ovenized the whole Pi, all you need is a shoebox and an old towel :). > [...] I said: >> 125 microseconds is a lot of jitter. [...] > It's negligible jitter for everyday computer use. It's a lot if you're > doing something like timestamping financial transactions, or recording > radio-astronomy observations, but the people doing that sort of thing > usually aren't using ntpd to sync their clocks (they're using ieee- > 1588, or custom solutions such as PCI irig input cards). I'm measuring packet roundtrip times to regional campii and that sort of thing. We're linked to various tier-3 carriers via a provincial gov't MPLS network that makes QOS questions rather opaque, and this is one of the things I do to probe it. I wrote: >> [...] >> The jitter is expressed in units of 1 millisecond, unless I am badly >> mistaken; for which possibility I apologize in advance. > > Yes, it's reported in milliseconds. The jitter number is the RMS of > the differences between the offset from the measurement with the lowest > delay for that peer and the other 7 offsets for that peer in the 8-step > filter. That is, it finds the lowest delay, then it does, roughly: > > jitter =3D 0; > for offset in {the other 7 samples that aren't the lowest delay} > jitter +=3D SQUARE(offset - lowest_delay_offset) > > then the final number is > > jitter =3D SQRT(jitter / 7) That is a fine thing to have clarified. I've dug into the code, but only because I wanted to run multiple sound card radio modems (two WWV and two CHU) to deal with varying HF propagation and path dropouts. Obviously those patches were a long way from the actual PLL logic at the core of the protocol. regards, Ross =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D Ross Alexander, (780) 675-6823 desk / (780) 689-0749 cell, rwa@athabascau.c= a 54.71593 N 113.30835 W, ve6pdq Order is simply a thin, perilous condition we try to impose on the basic reality of chaos. -- William Gaddis, _J R_ -- This communication is intended for the use of the recipient to whom it is a= ddressed, and may contain confidential, personal, and or privileged informa= tion. Please contact us immediately if you are not the intended recipient o= f this communication, and do not copy, distribute, or take action relying o= n it. Any communications received in error, or subsequent reply, should be = deleted or destroyed. --- From owner-freebsd-arm@freebsd.org Tue Aug 20 00:38:44 2019 Return-Path: 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 14B9DD64DF for ; Tue, 20 Aug 2019 00:38:44 +0000 (UTC) (envelope-from khantroll@gmail.com) Received: from mail-oi1-x243.google.com (mail-oi1-x243.google.com [IPv6:2607:f8b0:4864:20::243]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46CBjv1MPsz4dhq for ; Tue, 20 Aug 2019 00:38:42 +0000 (UTC) (envelope-from khantroll@gmail.com) Received: by mail-oi1-x243.google.com with SMTP id h21so2779464oie.7 for ; Mon, 19 Aug 2019 17:38:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=qA2o/42EzhQSxFwyUcxIpIX8DSX3E3ftQiCHAw7YX1E=; b=L+yVE9gDd3MHL/SeIhBWxwjJV72odX6WLQ5xSa2+jYxaHvDaiLDiQCt8fJy6jlVjB8 O4t4l0+saFZ3UCVJL2XzqYofZ3XeNVfRyc9ynXoHGaML4LLELGhr//cpmq1mjrcD6zDO cnK5kx8GIo2txBO9lo54j1Jxk+YkWGcWE0TaHVVIptPrypcH6FXakcWmF4GbXGIO4g0z nLre48nkznAIwVP9I2Xvx6fIGi5xYmL9yn/Te7fdzrcaAfBo4jnc/kdPZf/vFltfWAwR +gLs2y7/T0fRgvzsYGPlQ9FCWgHkNawaIo0TcyDVn9ymn3Rlo5jrtjPEihmukM3tm5zM Q9Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=qA2o/42EzhQSxFwyUcxIpIX8DSX3E3ftQiCHAw7YX1E=; b=KxO5ClLxnGuEKe1FK4+ww49XjrSce3yeWtduin44zp4kJbZe2uPNhK5SvnyOU5A2K6 A2vlDjhvtuwBUponfnbOmMf8SC13cTdCAUd5JLL9I7RsOgqU0XNcoLx9hG3/qZY8SYEc WfpficUUFDe38vyH+DQOeaiMLpumwMlmmFp5HHnPWKhFjRCsu9vzTJJ1UaU/1+WxRQKl F3eZNxB55fBNMCJiX+nHlCuy3vXBjCUjtnk9ZeegaZoHUbCF4hgLqS1HKAXtSwlkJJWP apApq5rKDlACkuD5sEJ4SMP4widllulGh9UH97kEprkKSFdrfu+1nd8I4Wxnd6Zi7Qtl u0Yw== X-Gm-Message-State: APjAAAXoKYZhRaeEdn7i4cTJ3t9F9tqlLFja7FbC74rfKeSHNaVvWOmu /FLphynm66qIDs2ZDsxhI91p296DKcOa+r7Stvo14JsjT2k= X-Google-Smtp-Source: APXvYqzSHZsYeO87HVQhqNmZRYdD/G4QWHxs/844mLnPvy8/9+eOG7eVJyosgpBphCppoFi06/cuFw4Z+lUwJz9tGPA= X-Received: by 2002:aca:c588:: with SMTP id v130mr14547382oif.165.1566261520696; Mon, 19 Aug 2019 17:38:40 -0700 (PDT) MIME-Version: 1.0 References: <1547777156.662147.1565798461515.JavaMail.zimbra@perftech.com> <0E42E605-477E-4E65-810E-BD3A8CDE2C80@gmail.com> <973015183.1067498.1565890674099.JavaMail.zimbra@perftech.com> <20190815210311.1035f64b003e2bc85fa47ca8@bidouilliste.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> <20190817153053.5592b15b8a42982fda0fc123@bidouilliste.com> <9749945A-FDAD-47E0-947A-FA62138C2F83@gmail.com> <20190817210822.8920656bad0855b554883cf2@bidouilliste.com> <2D6D4BDA-75EC-403F-B5E2-52A468369DE2@gmail.com> <627099DD-804B-412F-A083-768CEFCF955C@gmail.com> <6DA8E736-8031-4BF7-8B20-CF8B0E8A7FEF@gmail.com> In-Reply-To: From: Jeffrey Bowers Date: Mon, 19 Aug 2019 19:38:26 -0500 Message-ID: Subject: Re: Espressobin anyone ? To: freebsd-arm X-Rspamd-Queue-Id: 46CBjv1MPsz4dhq X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=L+yVE9gD; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of khantroll@gmail.com designates 2607:f8b0:4864:20::243 as permitted sender) smtp.mailfrom=khantroll@gmail.com X-Spamd-Result: default: False [-1.98 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; URI_COUNT_ODD(1.00)[31]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.98)[-0.985,0]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (1.92), ipnet: 2607:f8b0::/32(-2.93), asn: 15169(-2.37), country: US(-0.05)]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; SH_EMAIL_ZRD(0.00)[0.0.117.48]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.117.48,0.0.46.224]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[3.4.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 00:38:44 -0000 Hi all, I'm having trouble getting subversion to work. When I run: svn checkout https://svn.FreeBSD.org/ports/head /usr/ports It scrolls through many lines of text before stating: svn: E000060: Operation timed out When I run: svn checkout svn+ssh://repo.freebsd.org/ports/head /usr/ports It tells me that the authenticity of the host cannot be identified, and asks me to confirm that I want to connect. I say yes, and then it says: svn: E170013: Unable to connect to a repository at URL 'svn+ssh:// repo.freebsd.org/ports/head' svn: E210002: To better debug SSH connection problems, remove the -q option from 'ssh' in the [tunnels] section of your Subversion configuration file. Any ideas? Thanks in advance! On Mon, Aug 19, 2019 at 8:51 PM Jeffrey Bowers wrote: > I didn't think it remounting. Thank you! > > On Mon, Aug 19, 2019 at 11:39 AM S=C3=B8ren Schmidt > wrote: > >> Hi Jeffrey >> >> You need to unmount the /tmp filesystem :) >> You can do that permanently by commenting it out in /etc/fstab >> >> >> On 19 Aug 2019, at 21.45, Jeffrey Bowers wrote: >> >> Hi Soren, >> >> I'm getting the same error message. Any other ideas what it might be? >> It's got to be something in the partition scheme or the file permissions= , >> but I'm just not sure what. >> >> >> On Sun, Aug 18, 2019 at 10:03 AM Jeffrey Bowers >> wrote: >> >>> D=E2=80=99Oh! I thought I too care of that with gpart. I literally miss= ed growfs >>> part of the instructions.. >>> >>> On Sun, Aug 18, 2019 at 10:00 AM S=C3=B8ren Schmidt >>> wrote: >>> >>>> Hi >>>> >>>> You are out of space :) >>>> >>>> Boot the board into singleuser mode, and do =E2=80=9Cservice growfs st= art=E2=80=9D, >>>> that will expand you / filesystem to the entire SD card=E2=80=A6 >>>> >>>> -S=C3=B8ren >>>> >>>> On 18 Aug 2019, at 14.50, Jeffrey Bowers wrote: >>>> >>>> Sure thing! Here's the screenshot! >>>> >>>> >>>> >>>> On Sun, Aug 18, 2019 at 7:35 AM S=C3=B8ren Schmidt >>>> wrote: >>>> >>>>> Hi >>>>> >>>>> Can I have you paste the output from df -h ? >>>>> >>>>> You should be able to utilise the full SD card=E2=80=A6 >>>>> >>>>> -S=C3=B8ren >>>>> >>>>> On 18 Aug 2019, at 14.29, Jeffrey Bowers wrote: >>>>> >>>>> Hi, >>>>> >>>>> Just make sure I understand the process, I should hook up a hard disk >>>>> and map it to to /TMP ? >>>>> >>>>> I already tried just unmapping /tmp, and it gave me the same error >>>>> once, and then the next time I ran it I got an error saying /usr/port= s was >>>>> out of space )which I guess I shouldn=E2=80=99t mount to another dire= ctor on the >>>>> hard drive? >>>>> >>>>> On Sun, Aug 18, 2019 at 5:11 AM S=C3=B8ren Schmidt >>>>> wrote: >>>>> >>>>>> Hi Jeffrey >>>>>> >>>>>> You can unmount the memory disk on /tmp to get at the space on the S= D >>>>>> card. >>>>>> >>>>>> It is however not recommend to use the AD card for random storage, i= t >>>>>> will wear out fast, that=E2=80=99s why the memory disk is setup. >>>>>> >>>>>> You could connect a SSD og laptop disk to the SATA interface and use >>>>>> that for the workload. >>>>>> >>>>>> However compiling is slow, its much much faster to cross compile on = a >>>>>> PC=E2=80=A6 >>>>>> >>>>>> -S=C3=B8ren >>>>>> >>>>>> On 18 Aug 2019, at 00.22, Jeffrey Bowers wrote= : >>>>>> >>>>>> Hi! I've got a new one :) >>>>>> I'm trying to do an svn checkout to fix the pkg problem, but it tell= s >>>>>> me it can't write to a to a temp folder because there is no room lef= t on >>>>>> the device. However, FreeBSD partition is 29GB. It's never also neve= r the >>>>>> same file in TMP that it can't write to. Here is a screenshot of the= issue, >>>>>> along with the output of gpart: >>>>>> >>>>>> >>>>>> >>>>>> Any ideas? >>>>>> >>>>>> Thanks! >>>>>> >>>>>> >>>>>> On Sat, Aug 17, 2019 at 2:08 PM Emmanuel Vadot >>>>>> wrote: >>>>>> >>>>>>> On Sat, 17 Aug 2019 17:14:36 +0200 >>>>>>> S=C3=B8ren Schmidt wrote: >>>>>>> >>>>>>> > HI >>>>>>> > >>>>>>> > Well, I have a whole forrest of tree?s here, but the error posted >>>>>>> here was on a clean checkout. >>>>>>> > >>>>>>> > Anyhow, with the latest changes to -stable and the two >>>>>>> RF_SHAREABLE patches from -current all works. >>>>>>> >>>>>>> I've reverted the commits, see >>>>>>> https://github.com/evadot/freebsd/commits/a37x0_gpio for a better >>>>>>> way >>>>>>> to deal with this issue. >>>>>>> I'm waiting for mmel@ as he wrote the syscon_get_default_handle >>>>>>> part. >>>>>>> >>>>>>> > It would be nice with the etherswitch changes as well so VLAN >>>>>>> tagging etc was standard. >>>>>>> > >>>>>>> > -S=C3=B8ren >>>>>>> > >>>>>>> > PS: given up on bottom & inline popsting, top posting is all the >>>>>>> rage now (yeah I miss elm etc :) ) >>>>>>> > >>>>>>> > > On 17 Aug 2019, at 15.30, Emmanuel Vadot >>>>>>> wrote: >>>>>>> > > >>>>>>> > > On Sat, 17 Aug 2019 11:07:22 +0200 >>>>>>> > > S=C3=B8ren Schmidt >>>>>> soren.schmidt@gmail.com>> wrote: >>>>>>> > > >>>>>>> > >> Hi Emmunuel >>>>>>> > >> >>>>>>> > >> Yes the 3720 gpio driver I already back ported long ago, its >>>>>>> needed, I?m happy its now part of std stable 12! >>>>>>> > > >>>>>>> > > Would have been nice of you to say that you were not running a >>>>>>> clean >>>>>>> > > tree. >>>>>>> > > >>>>>>> > >> My issue seems to be the inclusion of the phy_usb driver, if I >>>>>>> leave that out, I?m back to normal.. >>>>>>> > > >>>>>>> > > What make you think this is this driver ? What works/doesn't wo= rk >>>>>>> > > with it ? could you provide logs. >>>>>>> > > >>>>>>> > >> I?ll have have another go at the latest -stable sources during >>>>>>> the weekend and see how it goes. >>>>>>> > >> >>>>>>> > >> Thanks for looking into this, with a little cooperation we?ll >>>>>>> get this solved for the greater good.. >>>>>>> > >> >>>>>>> > >> -S=C3=B8ren >>>>>>> > > >>>>>>> > > P.S. Please stop top posting, it's really hard to read the >>>>>>> conversation >>>>>>> > > >>>>>>> > >>> On 16 Aug 2019, at 22.58, Emmanuel Vadot < >>>>>>> manu@bidouilliste.com> wrote: >>>>>>> > >>> >>>>>>> > >>> On Fri, 16 Aug 2019 19:12:30 +0200 >>>>>>> > >>> Emmanuel Vadot >>>>>> manu@bidouilliste.com>> wrote: >>>>>>> > >>> >>>>>>> > >>>> On Fri, 16 Aug 2019 17:10:37 +0200 >>>>>>> > >>>> Emmanuel Vadot wrote: >>>>>>> > >>>> >>>>>>> > >>>>> On Fri, 16 Aug 2019 15:24:54 +0200 >>>>>>> > >>>>> Emmanuel Vadot wrote: >>>>>>> > >>>>> >>>>>>> > >>>>>> On Fri, 16 Aug 2019 07:28:59 +0200 >>>>>>> > >>>>>> S=C3=B8ren Schmidt wrote: >>>>>>> > >>>>>> >>>>>>> > >>>>>>> Hi >>>>>>> > >>>>>>> >>>>>>> > >>>>>>> Very simple, reverting sys/gnu/dts to what was before >>>>>>> 350595 (actually 350592). >>>>>>> > >>>>>>> Thats what we have svn for ? >>>>>>> > >>>>>> >>>>>>> > >>>>>> If I asked how it was to have the svn command that you >>>>>>> used, I want to >>>>>>> > >>>>>> make sure that you didn't revert anything else, like do yo= u >>>>>>> have >>>>>>> > >>>>>> r350596 and r350628 ? >>>>>>> > >>>>>> >>>>>>> > >>>>>>> That does make my bananapi work again, no other changes >>>>>>> just a recompiled kernel. >>>>>>> > >>>>>> >>>>>>> > >>>>>> That + copying the dtb to the fat32 partition ? >>>>>>> > >>>>>> >>>>>>> > >>>>>> Can you post the dtb somewhere. >>>>>>> > >>>>>> >>>>>>> > >>>>>>> However it does not bring the Espressobin back to life, >>>>>>> thats something in one of the ~30 other files that changed between = those >>>>>>> two revisions. >>>>>>> > >>>>>> >>>>>>> > >>>>>> What Linux version of DTS are you using then ? The ones >>>>>>> that were in >>>>>>> > >>>>>> stable/12 when it was branched (4.18) or a later revision = ? >>>>>>> > >>>>> >>>>>>> > >>>>> So I think that I've found the problem on the Espressobin. >>>>>>> > >>>>> I think that the problem comes from the simple-mfd driver >>>>>>> that I've >>>>>>> > >>>>> mfc in r350600. >>>>>>> > >>>>> The pinctrl/gpio controller compatible is >>>>>>> > >>>>> "marvell,armada3710-nb-pinctrl", "syscon", "simple-mfd" and >>>>>>> it attaches >>>>>>> > >>>>> at BUS_PASS_INTERRUPT while the simple_mfd driver attaches = at >>>>>>> > >>>>> BUS_PASS_BUS (so earlier) which means that no gpio >>>>>>> controller will be >>>>>>> > >>>>> available for sdhci to detect the card. >>>>>>> > >>>>> >>>>>>> > >>>>> If someone with a non-working espressobin could post a full >>>>>>> verbose >>>>>>> > >>>>> boot log that would help me confirming that this is the cas= e. >>>>>>> > >>>>> I'll try to find a solution on how to solve this problem. >>>>>>> > >>>> >>>>>>> > >>>> So this wasn't the problem but I've found it, see r351129 an= d >>>>>>> r351130 >>>>>>> > >>>> >>>>>>> > >>>> SD card now work again in HEAD, I'll have a look at stable >>>>>>> later next >>>>>>> > >>>> week. >>>>>>> > >>> >>>>>>> > >>> I've did a quick test and I've MFC r348880, r348882 and >>>>>>> r349596, the >>>>>>> > >>> two other commits needed to be mfc'ed are the one I did today >>>>>>> on head, >>>>>>> > >>> I'll do that next week. >>>>>>> > >>> With them sdcard is working again on stable/12 >>>>>>> > >>> >>>>>>> > >>>>>>> -S=C3=B8ren >>>>>>> > >>>>>>> >>>>>>> > >>>>>>>> On 15 Aug 2019, at 23.37, Emmanuel Vadot < >>>>>>> manu@bidouilliste.com> wrote: >>>>>>> > >>>>>>>> >>>>>>> > >>>>>>>> On Thu, 15 Aug 2019 21:56:23 +0200 >>>>>>> > >>>>>>>> S=C3=B8ren Schmidt wrote: >>>>>>> > >>>>>>>> >>>>>>> > >>>>>>>>> >>>>>>> > >>>>>>>>> Well, I don?t care where you are from and what color yo= u >>>>>>> have :) >>>>>>> > >>>>>>>>> >>>>>>> > >>>>>>>>> Now, if I update my stable12 sources to r350595 the >>>>>>> bananapi breaks, if revert sys/gnu/dts it works again, go figure.. >>>>>>> > >>>>>>>> >>>>>>> > >>>>>>>> Reverting to what ? and how ? >>>>>>> > >>>>>>>> >>>>>>> > >>>>>>>> Because I've just test 12-stable and I have the problem >>>>>>> that I've said >>>>>>> > >>>>>>>> in my previous mail so setting >>>>>>> hw.regulator.disable_unused=3D0 is the >>>>>>> > >>>>>>>> work around. >>>>>>> > >>>>>>>> The problem is in twsi not in the DTS so I'm curious how >>>>>>> reverting >>>>>>> > >>>>>>>> only the dts fixes this problem. >>>>>>> > >>>>>>>> >>>>>>> > >>>>>>>>> The r351099 fix is already like that in -stable, and no= t >>>>>>> part of the problem. >>>>>>> > >>>>>>>>> >>>>>>> > >>>>>>>>> -S=C3=B8ren >>>>>>> > >>>>>>>> >>>>>>> > >>>>>>>>>> On 15 Aug 2019, at 21.03, Emmanuel Vadot < >>>>>>> manu@bidouilliste.com> wrote: >>>>>>> > >>>>>>>>>> >>>>>>> > >>>>>>>>>> On Thu, 15 Aug 2019 19:48:54 +0200 >>>>>>> > >>>>>>>>>> S=C3=B8ren Schmidt wrote: >>>>>>> > >>>>>>>>>> >>>>>>> > >>>>>>>>>>> Hi Mit! >>>>>>> > >>>>>>>>>>> >>>>>>> > >>>>>>>>>>> Right, I suspected that, 12-stable broke many embedde= d >>>>>>> systems between r350592 and r350595 where all the latest and greate= st DTS >>>>>>> files was pulled in, I guess the same holds for -current. >>>>>>> > >>>>>>>>>>> >>>>>>> > >>>>>>>>>>> -S=C3=B8ren >>>>>>> > >>>>>>>>>> >>>>>>> > >>>>>>>>>> Mhm it's fun that you think that DTS import is the >>>>>>> source of all your >>>>>>> > >>>>>>>>>> problems, I get it, it's easy to blame the French guy >>>>>>> that bulk import >>>>>>> > >>>>>>>>>> the DTS, he surely don't know what he is doing. >>>>>>> > >>>>>>>>>> Anyway, two problems were raised in this thread : >>>>>>> > >>>>>>>>>> >>>>>>> > >>>>>>>>>> 1) BananaPi (A20) doesn't boot >>>>>>> > >>>>>>>>>> 2) Espressobin sd support is broken >>>>>>> > >>>>>>>>>> >>>>>>> > >>>>>>>>>> I've just looked at the BananaPi problem today, I've >>>>>>> fixed a first >>>>>>> > >>>>>>>>>> problem in r351099. >>>>>>> > >>>>>>>>>> The main problem is that when we disable the unused >>>>>>> regulators we hang >>>>>>> > >>>>>>>>>> when trying to disabling ldo3. It's weird because the >>>>>>> board doesn't use >>>>>>> > >>>>>>>>>> LDO3 (which is why we are disabling it, it's unused). >>>>>>> The problem is in >>>>>>> > >>>>>>>>>> twsi I think as only leaving the part in axp209 that >>>>>>> read the >>>>>>> > >>>>>>>>>> voltage register value make FreeBSD hang. >>>>>>> > >>>>>>>>>> I'll have a proper look later, in the meantime you can >>>>>>> set >>>>>>> > >>>>>>>>>> hw.regulator.disable_unused=3D0 >>>>>>> > >>>>>>>>>> in /boot/loader.conf >>>>>>> > >>>>>>>>>> This isn't a DTS problem. >>>>>>> > >>>>>>>>>> >>>>>>> > >>>>>>>>>> For Espressobin I haven't found any thing related to S= D >>>>>>> in the DTS >>>>>>> > >>>>>>>>>> updates since the import, the only things slighly >>>>>>> related are mmc and >>>>>>> > >>>>>>>>>> sdio. >>>>>>> > >>>>>>>>>> So if someone could find which DTS import broke this I >>>>>>> can have a look. >>>>>>> > >>>>>>>>>> >>>>>>> > >>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> On 15 Aug 2019, at 19.37, Mit Matelske >>>>>>> wrote: >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Yeah, that was the problem. I went back to r348882 >>>>>>> and everything worked out of the box. >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Thanks again for the hand holding! >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Mit >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> From: "S=C3=B8ren Schmidt" >>>>>> > >>>>>>> > >>>>>>>>>>>> To: "Mit Matelske" > >>>>>>> > >>>>>>>>>>>> Cc: "Marcin Wojtas" >>>>>> mw@semihalf.com>>, "freebsd-arm" >>>>>> freebsd-arm@freebsd.org>> >>>>>>> > >>>>>>>>>>>> Sent: Wednesday, August 14, 2019 1:33:04 PM >>>>>>> > >>>>>>>>>>>> Subject: Re: Espressobin anyone ? >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> It might simply be broken in -current (again). >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> I just updated my stable12 tree and I pulled in new >>>>>>> .dts files for just about anything? >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Needless to say, it broke the Espressobin?s SD >>>>>>> support, it now fails just like yours.. >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> It also broke allwinner builds and what not, so I?m >>>>>>> just going back in time again :) >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> I wonder why there is this overwhelming need to >>>>>>> import stuff that breaks things right, left and center in a -stable= branch ? >>>>>>> > >>>>>>>>>>>> That would have earned you the pointy hat back when?= . >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> -S=C3=B8ren >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> On 14 Aug 2019, at 18.01, Mit Matelske >>>>>> > wrote: >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Marcin- >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Sorry I didn't reply yesterday. I didn't have any >>>>>>> luck with that either. I tried a lot of permutations. >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Not saying for 100% it doesn't work, but I couldn't >>>>>>> get it to work! >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Mit >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> From: "Marcin Wojtas" >>>>>> mw@semihalf.com>> >>>>>>> > >>>>>>>>>>>> To: "Mit Matelske" > >>>>>>> > >>>>>>>>>>>> Cc: "S=C3=B8ren Schmidt" >>>>>> soren.schmidt@gmail.com>>, "freebsd-arm" >>>>>> > >>>>>>> > >>>>>>>>>>>> Sent: Wednesday, August 14, 2019 10:41:04 AM >>>>>>> > >>>>>>>>>>>> Subject: Re: Espressobin anyone ? >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Hi Mit, >>>>>>> > >>>>>>>>>>>> Since you are using the latest 13-current, could you >>>>>>> please try if passing rootdev via u-boot bootargs (please see my pr= evious >>>>>>> email) works for you without the loader modification? >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Best regards, >>>>>>> > >>>>>>>>>>>> Marcin >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> ?r., 14 sie 2019 o 16:29 Mit Matelske >>>>>> > napisa?(a): >>>>>>> > >>>>>>>>>>>> Soren- >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Thanks for the info. I'll grab a couple more SD >>>>>>> cards at lunch. This one is a new Samsung 32GB. I'll also try put= ting the >>>>>>> changes into 12 and see if that helps. I'm using the latest 13-cur= rent. >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Again, appreciate the hand holding! >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Mit >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> From: "S=C3=B8ren Schmidt" >>>>>> > >>>>>>> > >>>>>>>>>>>> To: "Mit Matelske" > >>>>>>> > >>>>>>>>>>>> Cc: "Marcin Wojtas" >>>>>> mw@semihalf.com>>, "freebsd-arm" >>>>>> freebsd-arm@freebsd.org>> >>>>>>> > >>>>>>>>>>>> Sent: Wednesday, August 14, 2019 2:30:31 AM >>>>>>> > >>>>>>>>>>>> Subject: Re: Espressobin anyone ? >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Hi Mit >>>>>>> > >>>>>>>>>>>> Hmm, from your earlier posted dmesgs it looks like >>>>>>> the SD card is not getting detected properly.. >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> I get this output: >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> sdhci_xenon0: mem >>>>>>> 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 >>>>>>> > >>>>>>>>>>>> mmc0: on sdhci_xenon0 >>>>>>> > >>>>>>>>>>>> ?snip? >>>>>>> > >>>>>>>>>>>> mmcsd0: 16GB >>>>>> by 39 PH> at mmc0 50.0MHz/4bit/65535-block >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> The problem you see was fixed for me by r348882, >>>>>>> maybe it got broken later, I havn?t backported the later changes.. >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Have you tried another SD card ? I have found 2 of >>>>>>> mine that the espressobin doesn?t like, but works fine with bananap= i and >>>>>>> friends... >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> -S=C3=B8ren >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> On 13 Aug 2019, at 23.30, Mit Matelske >>>>>> > wrote: >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Soren- >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Thanks for the code snippet! That will fix one of >>>>>>> the problems. >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> I still can't mount my filesystem, though. I think >>>>>>> I'm doing something really simple, wrong. I believe I'm running th= e latest >>>>>>> code and added some printfs to show the kernel setting the regulato= r: >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> usbus1 on ehci0 >>>>>>> > >>>>>>>>>>>> syscon_generic4: mem 0x5f800-0x5ffff on >>>>>>> simplebus1 >>>>>>> > >>>>>>>>>>>> sdhci_xenon0: >>>>>>> regulator_get_by_ofw_property(vqmmc-supply) =3D 19 >>>>>>> > >>>>>>>>>>>> sdhci_xenon0: vqmmc-supply regulator found >>>>>>> > >>>>>>>>>>>> sdhci_xenon0: mem >>>>>>> 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 >>>>>>> > >>>>>>>>>>>> ahci0: mem 0xe0000-0xe0177 ir= q >>>>>>> 26 on simplebus1 >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Could there be a problem with how I am setting up my >>>>>>> filesystem? I've tried both freebsd-ufs and freebsd as the type, w= ith no >>>>>>> luck. A gpart listing of my SD card: >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> root@fbl:~ # gpart list da3 >>>>>>> > >>>>>>>>>>>> Geom name: da3 >>>>>>> > >>>>>>>>>>>> modified: false >>>>>>> > >>>>>>>>>>>> state: OK >>>>>>> > >>>>>>>>>>>> fwheads: 255 >>>>>>> > >>>>>>>>>>>> fwsectors: 63 >>>>>>> > >>>>>>>>>>>> last: 62521335 >>>>>>> > >>>>>>>>>>>> first: 3 >>>>>>> > >>>>>>>>>>>> entries: 4 >>>>>>> > >>>>>>>>>>>> scheme: GPT >>>>>>> > >>>>>>>>>>>> Providers: >>>>>>> > >>>>>>>>>>>> 1. Name: da3p1 >>>>>>> > >>>>>>>>>>>> Mediasize: 41943040 (40M) >>>>>>> > >>>>>>>>>>>> Sectorsize: 512 >>>>>>> > >>>>>>>>>>>> Stripesize: 0 >>>>>>> > >>>>>>>>>>>> Stripeoffset: 1536 >>>>>>> > >>>>>>>>>>>> Mode: r0w0e0 >>>>>>> > >>>>>>>>>>>> efimedia: >>>>>>> HD(1,GPT,19894dc5-b8b2-11e9-871f-08008a0010e0,0x3,0x14000) >>>>>>> > >>>>>>>>>>>> rawuuid: 19894dc5-b8b2-11e9-871f-08008a0010e0 >>>>>>> > >>>>>>>>>>>> rawtype: c12a7328-f81f-11d2-ba4b-00a0c93ec93b >>>>>>> > >>>>>>>>>>>> label: (null) >>>>>>> > >>>>>>>>>>>> length: 41943040 >>>>>>> > >>>>>>>>>>>> offset: 1536 >>>>>>> > >>>>>>>>>>>> type: efi >>>>>>> > >>>>>>>>>>>> index: 1 >>>>>>> > >>>>>>>>>>>> end: 81922 >>>>>>> > >>>>>>>>>>>> start: 3 >>>>>>> > >>>>>>>>>>>> 2. Name: da3p2 >>>>>>> > >>>>>>>>>>>> Mediasize: 31968979456 (30G) >>>>>>> > >>>>>>>>>>>> Sectorsize: 512 >>>>>>> > >>>>>>>>>>>> Stripesize: 0 >>>>>>> > >>>>>>>>>>>> Stripeoffset: 41944576 >>>>>>> > >>>>>>>>>>>> Mode: r0w0e0 >>>>>>> > >>>>>>>>>>>> efimedia: >>>>>>> HD(2,GPT,98786462-be30-11e9-ae6e-08008a0010e0,0x14003,0x3b8bff5) >>>>>>> > >>>>>>>>>>>> rawuuid: 98786462-be30-11e9-ae6e-08008a0010e0 >>>>>>> > >>>>>>>>>>>> rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b >>>>>>> > >>>>>>>>>>>> label: (null) >>>>>>> > >>>>>>>>>>>> length: 31968979456 >>>>>>> > >>>>>>>>>>>> offset: 41944576 >>>>>>> > >>>>>>>>>>>> type: freebsd-ufs >>>>>>> > >>>>>>>>>>>> index: 2 >>>>>>> > >>>>>>>>>>>> end: 62521335 >>>>>>> > >>>>>>>>>>>> start: 81923 >>>>>>> > >>>>>>>>>>>> Consumers: >>>>>>> > >>>>>>>>>>>> 1. Name: da3 >>>>>>> > >>>>>>>>>>>> Mediasize: 32010928128 (30G) >>>>>>> > >>>>>>>>>>>> Sectorsize: 512 >>>>>>> > >>>>>>>>>>>> Mode: r0w0e0 >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Thanks!! >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Mit >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> From: "S=C3=B8ren Schmidt" >>>>>> > >>>>>>> > >>>>>>>>>>>> To: "Marcin Wojtas" >>>>>> mw@semihalf.com>> >>>>>>> > >>>>>>>>>>>> Cc: "Mit Matelske" >, >>>>>>> "freebsd-arm" >>>>>> freebsd-arm@freebsd.org>> >>>>>>> > >>>>>>>>>>>> Sent: Tuesday, August 13, 2019 12:55:09 PM >>>>>>> > >>>>>>>>>>>> Subject: Re: Espressobin anyone ? >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Hi >>>>>>> > >>>>>>>>>>>> That doesn?t seen to work on the espressobin, or >>>>>>> least I can?t get it to pick it up. >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> I use this patch as a workaround: >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Index: main.c >>>>>>> > >>>>>>>>>>>> >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>> > >>>>>>>>>>>> --- main.c (revision 350496) >>>>>>> > >>>>>>>>>>>> +++ main.c (working copy) >>>>>>> > >>>>>>>>>>>> @@ -463,6 +462,13 @@ >>>>>>> > >>>>>>>>>>>> int rv; >>>>>>> > >>>>>>>>>>>> char *rootdev; >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> +#if defined(__aarch64__) >>>>>>> > >>>>>>>>>>>> + /* SOS HACK in rootdev, at least Espressobin >>>>>>> gets this wrong */ >>>>>>> > >>>>>>>>>>>> + printf("Setting currdev hack\n"); >>>>>>> > >>>>>>>>>>>> + set_currdev("disk0p2"); >>>>>>> > >>>>>>>>>>>> + return (0); >>>>>>> > >>>>>>>>>>>> +#endif >>>>>>> > >>>>>>>>>>>> + >>>>>>> > >>>>>>>>>>>> /* >>>>>>> > >>>>>>>>>>>> * First choice: if rootdev is already set, use >>>>>>> that, even if >>>>>>> > >>>>>>>>>>>> * it's wrong. >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Its not pretty but it does the job until I get time >>>>>>> to look into why bootargs aren?t passed / won?t stick, probably som= ething I >>>>>>> havn?t backported to my -stable12 sources yet... >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> -S=C3=B8ren >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> On 13 Aug 2019, at 01.38, Marcin Wojtas < >>>>>>> mw@semihalf.com > wrote: >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Hi, >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Not sure if it's what you are looking for, but in >>>>>>> order to autoboot, I >>>>>>> > >>>>>>>>>>>> simply pass 'rootdev=3DdiskXpY' in the bootargs >>>>>>> variable. Here's example from >>>>>>> > >>>>>>>>>>>> A3720-DB (same should work on EspressoBin): >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Marvell>> set bootargs "rootdev=3Ddisk1p1";usb reset= ; >>>>>>> fatload usb 0:1 >>>>>>> > >>>>>>>>>>>> ${fdt_addr} armada-3720-db.dtb; fatload usb 0:1 >>>>>>> ${kernel_addr} >>>>>>> > >>>>>>>>>>>> boot/loader.efi; bootefi ${kernel_addr} ${fdt_addr} >>>>>>> > >>>>>>>>>>>> resetting USB... >>>>>>> > >>>>>>>>>>>> USB0: Register 2000104 NbrPorts 2 >>>>>>> > >>>>>>>>>>>> Starting the controller >>>>>>> > >>>>>>>>>>>> USB XHCI 1.00 >>>>>>> > >>>>>>>>>>>> USB1: USB EHCI 1.00 >>>>>>> > >>>>>>>>>>>> - ______ ____ _____ _____ >>>>>>> > >>>>>>>>>>>> | ____| | _ \ / ____| __ \ >>>>>>> > >>>>>>>>>>>> | |___ _ __ ___ ___ | |_) | (___ | | | | >>>>>>> > >>>>>>>>>>>> | ___| '__/ _ \/ _ \| _ < \___ \| | | | >>>>>>> > >>>>>>>>>>>> | | | | | __/ __/| |_) |____) | |__| | >>>>>>> > >>>>>>>>>>>> | | | | | | || | | | >>>>>>> > >>>>>>>>>>>> |_| |_| \___|\___||____/|_____/|_____/ >>>>>>> > >>>>>>>>>>>> ``` >>>>>>> > >>>>>>>>>>>> ` >>>>>>> > >>>>>>>>>>>> ????????????Welcome to FreeBSD????????????? s` >>>>>>> `.....---.......--.``` >>>>>>> > >>>>>>>>>>>> -/ >>>>>>> > >>>>>>>>>>>> ? ? +o >>>>>>> .--` /y:` >>>>>>> > >>>>>>>>>>>> +. >>>>>>> > >>>>>>>>>>>> ? 1. Boot Multi user [Enter] ? >>>>>>> yo`:. :o >>>>>>> > >>>>>>>>>>>> `+- >>>>>>> > >>>>>>>>>>>> ? 2. Boot Single user ? y/ >>>>>>> -/` -o/ >>>>>>> > >>>>>>>>>>>> ? 3. Escape to loader prompt ? .- >>>>>>> > >>>>>>>>>>>> ::/sy+:. >>>>>>> > >>>>>>>>>>>> ? 4. Reboot ? / >>>>>>> `-- >>>>>>> > >>>>>>>>>>>> / >>>>>>> > >>>>>>>>>>>> ? ? `: >>>>>>> > >>>>>>>>>>>> :` >>>>>>> > >>>>>>>>>>>> ? Options: ? `: >>>>>>> > >>>>>>>>>>>> :` >>>>>>> > >>>>>>>>>>>> ? 5. Kernel: default/kernel (1 of 1) ? / >>>>>>> > >>>>>>>>>>>> / >>>>>>> > >>>>>>>>>>>> ? 6. Boot Options ? .- >>>>>>> > >>>>>>>>>>>> -. >>>>>>> > >>>>>>>>>>>> ? ? -- >>>>>>> -. >>>>>>> > >>>>>>>>>>>> ? ? >>>>>>> `:` `:` >>>>>>> > >>>>>>>>>>>> ? ? >>>>>>> .-- `--. >>>>>>> > >>>>>>>>>>>> ??????????????????????????????????????????? >>>>>>> .---.....----. >>>>>>> > >>>>>>>>>>>> Autoboot in 9 seconds, hit [Enter] to boot or any >>>>>>> other key to stop >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Loading kernel... >>>>>>> > >>>>>>>>>>>> /boot/kernel/kernel text=3D0x95047c >>>>>>> data=3D0x1919d0+0x84aa94 >>>>>>> > >>>>>>>>>>>> syms=3D[0x8+0x13aaa8+0x8+0x12610d] >>>>>>> > >>>>>>>>>>>> Loading configured modules... >>>>>>> > >>>>>>>>>>>> can't find '/boot/entropy' >>>>>>> > >>>>>>>>>>>> Using DTB provided by EFI at 0x8000000. >>>>>>> > >>>>>>>>>>>> ---<>--- >>>>>>> > >>>>>>>>>>>> KDB: debugger backends: ddb >>>>>>> > >>>>>>>>>>>> KDB: current backend: ddb >>>>>>> > >>>>>>>>>>>> Copyright (c) 1992-2019 The FreeBSD Project. >>>>>>> > >>>>>>>>>>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, >>>>>>> 1991, 1992, 1993, 1994 >>>>>>> > >>>>>>>>>>>> The Regents of the University of California. All >>>>>>> rights reserved. >>>>>>> > >>>>>>>>>>>> FreeBSD is a registered trademark of The FreeBSD >>>>>>> Foundation. >>>>>>> > >>>>>>>>>>>> FreeBSD 13.0-CURRENT >>>>>>> 17a1fc80d57-c261519(upstream_master) GENERIC arm64 >>>>>>> > >>>>>>>>>>>> FreeBSD clang version 8.0.0 (tags/RELEASE_800/final >>>>>>> 356365) (based on LLVM >>>>>>> > >>>>>>>>>>>> 8.0.0) >>>>>>> > >>>>>>>>>>>> WARNING: WITNESS option enabled, expect reduced >>>>>>> performance. >>>>>>> > >>>>>>>>>>>> VT: init without driver. >>>>>>> > >>>>>>>>>>>> Starting CPU 1 (1) >>>>>>> > >>>>>>>>>>>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >>>>>>> > >>>>>>>>>>>> [...] >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Best regards, >>>>>>> > >>>>>>>>>>>> Marcin >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> pon., 12 sie 2019 o 23:14 Mit Matelske >>>>>> > napisa?(a): >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Soren- >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Thanks for the quick response. I built this kernel >>>>>>> with revision 350924. >>>>>>> > >>>>>>>>>>>> I'll dig into whats going on in the morning. >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Mind posting your diff for your loader.efi? >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Thanks again! >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Mit >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> ----- Original Message ----- >>>>>>> > >>>>>>>>>>>> From: "S=C3=B8ren Schmidt" >>>>>> > >>>>>>> > >>>>>>>>>>>> To: "Mit Matelske" > >>>>>>> > >>>>>>>>>>>> Cc: "tscho" >>>>>> johannes@t-beutel.com>>, "freebsd-arm" < >>>>>>> > >>>>>>>>>>>> freebsd-arm@freebsd.org >>>>>> freebsd-arm@freebsd.org>> >>>>>>> > >>>>>>>>>>>> Sent: Monday, August 12, 2019 3:49:48 PM >>>>>>> > >>>>>>>>>>>> Subject: Re: Espressobin anyone ? >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Hi >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Looks like your sources may be too old, you need to >>>>>>> be at least at r348882 >>>>>>> > >>>>>>>>>>>> to get the fix for the SD card VCC regulator. >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> That change fixed it for me backported to 12-stable.= .. >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> The currdev problem still exists, I have it hardwire= d >>>>>>> in my loader for >>>>>>> > >>>>>>>>>>>> aarch64 :) >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> -S=C3=B8ren >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> On 12 Aug 2019, at 21.06, Mit Matelske >>>>>> > wrote: >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> I'm having a couple little hiccups booting this boar= d >>>>>>> also. One has >>>>>>> > >>>>>>>>>>>> been commented on already, that I can't get the >>>>>>> loader to automatically >>>>>>> > >>>>>>>>>>>> start loading the kernel on "disk0p2"... >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> The second, is that the kernel can't find the SD car= d >>>>>>> after booting so >>>>>>> > >>>>>>>>>>>> it can't mount the root filesystem. I'm using the >>>>>>> dts/dtb and kernel from >>>>>>> > >>>>>>>>>>>> the 13-current branch. >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Thanks for any and all help. I haven't used u-boot >>>>>>> in about decade. >>>>>>> > >>>>>>>>>>>> Spoiled by the x86 platform. >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Mit Matelske >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> ***U-boot environment:*** >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Marvell>> printenv >>>>>>> > >>>>>>>>>>>> baudrate=3D115200 >>>>>>> > >>>>>>>>>>>> bootargs=3Dconsole=3DttyMV0,115200 >>>>>>> earlycon=3Dar3700_uart,0xd0012000 >>>>>>> > >>>>>>>>>>>> root=3D/dev/mmcblk0p1 rw rootwait net.ifnames=3D0 >>>>>>> biosdevname=3D0 >>>>>>> > >>>>>>>>>>>> bootcmd=3Dmmc dev 0; fatload mmc 0:1 $kernel_addr >>>>>>> $image_name;fatload mmc >>>>>>> > >>>>>>>>>>>> 0:1 $fdt_addr $fdt_name; bootefi $kernel_addr >>>>>>> $fdt_addr >>>>>>> > >>>>>>>>>>>> bootdelay=3D2 >>>>>>> > >>>>>>>>>>>> bootmmc=3Dmmc dev 0; fatload mmc 0:1 $kernel_addr >>>>>>> $image_name;fatload mmc >>>>>>> > >>>>>>>>>>>> 0:1 $fdt_addr $fdt_name; bootefi $kernel_addr >>>>>>> $fdt_addr >>>>>>> > >>>>>>>>>>>> console=3Dconsole=3DttyMV0,115200 >>>>>>> earlycon=3Dar3700_uart,0xd0012000 >>>>>>> > >>>>>>>>>>>> eth1addr=3D00:51:82:11:22:01 >>>>>>> > >>>>>>>>>>>> eth2addr=3D00:51:82:11:22:02 >>>>>>> > >>>>>>>>>>>> eth3addr=3D00:51:82:11:22:03 >>>>>>> > >>>>>>>>>>>> ethact=3Dneta@30000 >>>>>>> > >>>>>>>>>>>> ethaddr=3DF0:AD:4E:09:6B:8F >>>>>>> > >>>>>>>>>>>> ethprime=3Deth0 >>>>>>> > >>>>>>>>>>>> fdt_addr=3D0x4f00000 >>>>>>> > >>>>>>>>>>>> fdt_high=3D0xffffffffffffffff >>>>>>> > >>>>>>>>>>>> fdt_name=3Defi/boot/armada-3720-espressobin.dtb >>>>>>> > >>>>>>>>>>>> fdtcontroladdr=3D3f7161b8 >>>>>>> > >>>>>>>>>>>> gatewayip=3D10.4.50.254 >>>>>>> > >>>>>>>>>>>> get_images=3Dtftpboot $kernel_addr $image_name; >>>>>>> tftpboot $fdt_addr >>>>>>> > >>>>>>>>>>>> $fdt_name; run get_ramfs >>>>>>> > >>>>>>>>>>>> get_ramfs=3Dif test "${ramfs_name}" !=3D "-"; then s= etenv >>>>>>> ramfs_addr >>>>>>> > >>>>>>>>>>>> 0x8000000; tftpboot $ramfs_addr $ramfs_name; else >>>>>>> setenv ramfs_addr -;fi >>>>>>> > >>>>>>>>>>>> hostname=3Dmarvell >>>>>>> > >>>>>>>>>>>> image_name=3Defi/freebsd/loader.efi >>>>>>> > >>>>>>>>>>>> initrd_addr=3D0xa00000 >>>>>>> > >>>>>>>>>>>> initrd_size=3D0x2000000 >>>>>>> > >>>>>>>>>>>> ipaddr=3D0.0.0.0 >>>>>>> > >>>>>>>>>>>> kernel_addr=3D0x5000000 >>>>>>> > >>>>>>>>>>>> loadaddr=3D0x5000000 >>>>>>> > >>>>>>>>>>>> netdev=3Deth0 >>>>>>> > >>>>>>>>>>>> netmask=3D255.255.255.0 >>>>>>> > >>>>>>>>>>>> ramfs_addr=3D0x8000000 >>>>>>> > >>>>>>>>>>>> ramfs_name=3D- >>>>>>> > >>>>>>>>>>>> root=3Droot=3D/dev/nfs rw >>>>>>> > >>>>>>>>>>>> rootpath=3D/srv/nfs/ >>>>>>> > >>>>>>>>>>>> serverip=3D0.0.0.0 >>>>>>> > >>>>>>>>>>>> set_bootargs=3Dsetenv bootargs $console $root >>>>>>> > >>>>>>>>>>>> >>>>>>> ip=3D$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:none >>>>>>> > >>>>>>>>>>>> nfsroot=3D$serverip:$rootpath $extra_params >>>>>>> > >>>>>>>>>>>> stderr=3Dserial@12000 >>>>>>> > >>>>>>>>>>>> stdin=3Dserial@12000 >>>>>>> > >>>>>>>>>>>> stdout=3Dserial@12000 >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> ***Full boot logs:*** >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> U-Boot 2017.03-armada-17.10.2-g14aeedc (Jun 01 2018 = - >>>>>>> 15:39:10 +0800) >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Model: Marvell Armada 3720 Community Board ESPRESSOB= in >>>>>>> > >>>>>>>>>>>> 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 >>>>>> >... >>>>>>> > >>>>>>>>>>>> Card did not respond to voltage select! >>>>>>> > >>>>>>>>>>>> mmc_init: -95, time 50 >>>>>>> > >>>>>>>>>>>> Found 1 disks >>>>>>> > >>>>>>>>>>>> Consoles: EFI console >>>>>>> > >>>>>>>>>>>> FreeBSD/arm64 EFI loader, Revision 1.1 >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Command line arguments: loader.efi >>>>>>> > >>>>>>>>>>>> EFI version: 2.05 >>>>>>> > >>>>>>>>>>>> EFI Firmware: Das U-boot (rev 0.00) >>>>>>> > >>>>>>>>>>>> Console: efi (0) >>>>>>> > >>>>>>>>>>>> Failed to find bootable partition >>>>>>> > >>>>>>>>>>>> Startup error in /boot/lua/loader.lua: seconds >>>>>>> > >>>>>>>>>>>> LUA ERROR: cannot open /boot/lua/loader.lua: invalid >>>>>>> argument. >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> can't load 'kernel' >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Type '?' for a list of commands, 'help' for more >>>>>>> detailed help. >>>>>>> > >>>>>>>>>>>> OK >>>>>>> > >>>>>>>>>>>> OK set currdev=3Ddisk0p2 >>>>>>> > >>>>>>>>>>>> OK boot >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> /boot/kernel/kernel text=3D0x97d6a0 >>>>>>> data=3D0x191b50+0x84ae94 >>>>>>> > >>>>>>>>>>>> syms=3D[0x8+0x137dd8+0x8+0x126260] >>>>>>> > >>>>>>>>>>>> Using DTB provided by EFI at 0x8000000. >>>>>>> > >>>>>>>>>>>> ---<>--- >>>>>>> > >>>>>>>>>>>> KDB: debugger backends: ddb >>>>>>> > >>>>>>>>>>>> KDB: current backend: ddb >>>>>>> > >>>>>>>>>>>> Copyright (c) 1992-2019 The FreeBSD Project. >>>>>>> > >>>>>>>>>>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, >>>>>>> 1991, 1992, 1993, 1994 >>>>>>> > >>>>>>>>>>>> The Regents of the University of California. All >>>>>>> rights reserved. >>>>>>> > >>>>>>>>>>>> FreeBSD is a registered trademark of The FreeBSD >>>>>>> Foundation. >>>>>>> > >>>>>>>>>>>> FreeBSD 13.0-CURRENT GENERIC arm64 >>>>>>> > >>>>>>>>>>>> FreeBSD clang version 6.0.1 (tags/RELEASE_601/final >>>>>>> 335540) (based on >>>>>>> > >>>>>>>>>>>> LLVM 6.0.1) >>>>>>> > >>>>>>>>>>>> WARNING: WITNESS option enabled, expect reduced >>>>>>> performance. >>>>>>> > >>>>>>>>>>>> VT: init without driver. >>>>>>> > >>>>>>>>>>>> Starting CPU 1 (1) >>>>>>> > >>>>>>>>>>>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >>>>>>> > >>>>>>>>>>>> arc4random: WARNING: initial seeding bypassed the >>>>>>> cryptographic random >>>>>>> > >>>>>>>>>>>> device because it was not yet seeded and the knob >>>>>>> 'bypass_before_seeding' >>>>>>> > >>>>>>>>>>>> was enabled. >>>>>>> > >>>>>>>>>>>> random: entropy device external interface >>>>>>> > >>>>>>>>>>>> MAP 3e681000 mode 2 pages 1 >>>>>>> > >>>>>>>>>>>> MAP 3ffa6000 mode 2 pages 1 >>>>>>> > >>>>>>>>>>>> kbd0 at kbdmux0 >>>>>>> > >>>>>>>>>>>> ofwbus0: >>>>>>> > >>>>>>>>>>>> simplebus0: on >>>>>>> ofwbus0 >>>>>>> > >>>>>>>>>>>> simplebus1: on >>>>>>> simplebus0 >>>>>>> > >>>>>>>>>>>> simple_mfd0: m= em >>>>>>> > >>>>>>>>>>>> 0x13800-0x138ff,0x13c00-0x13c1f on simplebus1 >>>>>>> > >>>>>>>>>>>> simple_mfd1: m= em >>>>>>> > >>>>>>>>>>>> 0x18800-0x188ff,0x18c00-0x18c1f on simplebus1 >>>>>>> > >>>>>>>>>>>> psci0: >>>>>> Driver> on ofwbus0 >>>>>>> > >>>>>>>>>>>> gic0: mem >>>>>>> > >>>>>>>>>>>> >>>>>>> 0x1d00000-0x1d0ffff,0x1d40000-0x1d7ffff,0x1d80000-0x1d81fff,0x1d900= 00-0x1d91fff,0x1da0000-0x1dbffff >>>>>>> > >>>>>>>>>>>> irq 27 on simplebus1 >>>>>>> > >>>>>>>>>>>> gpio0: me= m >>>>>>> > >>>>>>>>>>>> 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: me= m >>>>>>> > >>>>>>>>>>>> 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 o= n >>>>>>> simple_mfd1 >>>>>>> > >>>>>>>>>>>> gpio0: cannot allocate memory window >>>>>>> > >>>>>>>>>>>> device_attach: gpio0 attach returned 6 >>>>>>> > >>>>>>>>>>>> gpioregulator0: on ofwbu= s0 >>>>>>> > >>>>>>>>>>>> gpioregulator0: cannot get pin 0 >>>>>>> > >>>>>>>>>>>> gpioregulator0: cannot parse parameters >>>>>>> > >>>>>>>>>>>> device_attach: gpioregulator0 attach returned 6 >>>>>>> > >>>>>>>>>>>> generic_timer0: irq 0,1,2,3 on >>>>>>> ofwbus0 >>>>>>> > >>>>>>>>>>>> Timecounter "ARM MPCore Timecounter" frequency >>>>>>> 12500000 Hz quality 1000 >>>>>>> > >>>>>>>>>>>> Event timer "ARM MPCore Eventtimer" frequency >>>>>>> 12500000 Hz quality 1000 >>>>>>> > >>>>>>>>>>>> gpio0: me= m >>>>>>> > >>>>>>>>>>>> 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: me= m >>>>>>> > >>>>>>>>>>>> 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 o= n >>>>>>> simple_mfd1 >>>>>>> > >>>>>>>>>>>> gpio0: cannot allocate memory window >>>>>>> > >>>>>>>>>>>> device_attach: gpio0 attach returned 6 >>>>>>> > >>>>>>>>>>>> gpioregulator0: on ofwbu= s0 >>>>>>> > >>>>>>>>>>>> gpioregulator0: cannot get pin 0 >>>>>>> > >>>>>>>>>>>> gpioregulator0: cannot parse parameters >>>>>>> > >>>>>>>>>>>> device_attach: gpioregulator0 attach returned 6 >>>>>>> > >>>>>>>>>>>> gpio0: me= m >>>>>>> > >>>>>>>>>>>> 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: me= m >>>>>>> > >>>>>>>>>>>> 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 o= n >>>>>>> simple_mfd1 >>>>>>> > >>>>>>>>>>>> gpio0: cannot allocate memory window >>>>>>> > >>>>>>>>>>>> device_attach: gpio0 attach returned 6 >>>>>>> > >>>>>>>>>>>> gpioregulator0: on ofwbu= s0 >>>>>>> > >>>>>>>>>>>> gpioregulator0: cannot get pin 0 >>>>>>> > >>>>>>>>>>>> gpioregulator0: cannot parse parameters >>>>>>> > >>>>>>>>>>>> device_attach: gpioregulator0 attach returned 6 >>>>>>> > >>>>>>>>>>>> gpio0: me= m >>>>>>> > >>>>>>>>>>>> 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: me= m >>>>>>> > >>>>>>>>>>>> 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 o= n >>>>>>> simple_mfd1 >>>>>>> > >>>>>>>>>>>> gpio0: cannot allocate memory window >>>>>>> > >>>>>>>>>>>> device_attach: gpio0 attach returned 6 >>>>>>> > >>>>>>>>>>>> gpioregulator0: on ofwbu= s0 >>>>>>> > >>>>>>>>>>>> gpioregulator0: cannot get pin 0 >>>>>>> > >>>>>>>>>>>> gpioregulator0: cannot parse parameters >>>>>>> > >>>>>>>>>>>> device_attach: gpioregulator0 attach returned 6 >>>>>>> > >>>>>>>>>>>> gpio0: me= m >>>>>>> > >>>>>>>>>>>> 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: me= m >>>>>>> > >>>>>>>>>>>> 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 o= n >>>>>>> simple_mfd1 >>>>>>> > >>>>>>>>>>>> gpio0: cannot allocate memory window >>>>>>> > >>>>>>>>>>>> device_attach: gpio0 attach returned 6 >>>>>>> > >>>>>>>>>>>> gpioregulator0: on ofwbu= s0 >>>>>>> > >>>>>>>>>>>> gpioregulator0: cannot get pin 0 >>>>>>> > >>>>>>>>>>>> gpioregulator0: cannot parse parameters >>>>>>> > >>>>>>>>>>>> device_attach: gpioregulator0 attach returned 6 >>>>>>> > >>>>>>>>>>>> cpulist0: on ofwbus0 >>>>>>> > >>>>>>>>>>>> cpu0: on cpulist0 >>>>>>> > >>>>>>>>>>>> cpu1: on cpulist0 >>>>>>> > >>>>>>>>>>>> pmu0: irq 4 on ofwbus0 >>>>>>> > >>>>>>>>>>>> syscon_generic0: mem 0xd000-0xdfff on >>>>>>> simplebus1 >>>>>>> > >>>>>>>>>>>> syscon_generic1: mem 0x11500-0x1153f on >>>>>>> simplebus1 >>>>>>> > >>>>>>>>>>>> uart0: mem 0x12000-0x121f= f >>>>>>> irq 9,10,11 on >>>>>>> > >>>>>>>>>>>> simplebus1 >>>>>>> > >>>>>>>>>>>> uart0: console (115200,n,8,1) >>>>>>> > >>>>>>>>>>>> gpio0: me= m >>>>>>> > >>>>>>>>>>>> 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: mem 0x14000-0x1405f on >>>>>>> simplebus1 >>>>>>> > >>>>>>>>>>>> gpio0: me= m >>>>>>> > >>>>>>>>>>>> 0x18800-0x188ff,0x18c00-0x18c1f irq 40,41,42,43,44 o= n >>>>>>> simple_mfd1 >>>>>>> > >>>>>>>>>>>> gpio0: cannot allocate memory window >>>>>>> > >>>>>>>>>>>> device_attach: gpio0 attach returned 6 >>>>>>> > >>>>>>>>>>>> mvneta0: mem 0x30000-0x33fff irq 1= 4 >>>>>>> on simplebus1 >>>>>>> > >>>>>>>>>>>> mvneta0: version is 10 >>>>>>> > >>>>>>>>>>>> mvneta0: Ethernet address: 00:a6:39:ca:e8:00 >>>>>>> > >>>>>>>>>>>> mdio0: on mvneta0 >>>>>>> > >>>>>>>>>>>> mdioproxy0: on mdio0 >>>>>>> > >>>>>>>>>>>> e6000sw0: on mdio0 >>>>>>> > >>>>>>>>>>>> e6000sw0: multi-chip addressing mode (0x1) >>>>>>> > >>>>>>>>>>>> e6000sw0: CPU port at 0 >>>>>>> > >>>>>>>>>>>> e6000sw0: fixed port at 0 >>>>>>> > >>>>>>>>>>>> e6000sw0: PHY at port 1 >>>>>>> > >>>>>>>>>>>> miibus0: on e6000sw0 >>>>>>> > >>>>>>>>>>>> e1000phy0: 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: on e6000sw0 >>>>>>> > >>>>>>>>>>>> e1000phy1: 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: on e6000sw0 >>>>>>> > >>>>>>>>>>>> e1000phy2: 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: on e6000sw0 >>>>>>> > >>>>>>>>>>>> xhci0: mem >>>>>>> 0x58000-0x5bfff irq 16 on >>>>>>> > >>>>>>>>>>>> simplebus1 >>>>>>> > >>>>>>>>>>>> xhci0: 32 bytes context size, 32-bit DMA >>>>>>> > >>>>>>>>>>>> usbus0 on xhci0 >>>>>>> > >>>>>>>>>>>> syscon_generic3: mem 0x5d800-0x5dfff on >>>>>>> simplebus1 >>>>>>> > >>>>>>>>>>>> ehci0: mem >>>>>>> 0x5e000-0x5efff irq >>>>>>> > >>>>>>>>>>>> 17 on simplebus1 >>>>>>> > >>>>>>>>>>>> usbus1: EHCI version 1.0 >>>>>>> > >>>>>>>>>>>> usbus1 on ehci0 >>>>>>> > >>>>>>>>>>>> syscon_generic4: mem 0x5f800-0x5ffff on >>>>>>> simplebus1 >>>>>>> > >>>>>>>>>>>> sdhci_xenon0: mem >>>>>>> > >>>>>>>>>>>> 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 >>>>>>> > >>>>>>>>>>>> ahci0: mem 0xe0000-0xe0177 ir= q >>>>>>> 26 on simplebus1 >>>>>>> > >>>>>>>>>>>> ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplie= r >>>>>>> supported with FBS >>>>>>> > >>>>>>>>>>>> ahcich0: at channel 0 on ahci0 >>>>>>> > >>>>>>>>>>>> device_attach: ahcich0 attach returned 6 >>>>>>> > >>>>>>>>>>>> gpioregulator0: on ofwbu= s0 >>>>>>> > >>>>>>>>>>>> gpioregulator0: cannot get pin 0 >>>>>>> > >>>>>>>>>>>> gpioregulator0: cannot parse parameters >>>>>>> > >>>>>>>>>>>> device_attach: gpioregulator0 attach returned 6 >>>>>>> > >>>>>>>>>>>> cryptosoft0: >>>>>>> > >>>>>>>>>>>> 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 >>>>>>> >>>>>>> > >>>>>>>>>>>> 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 >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> usbus1 Processor Features 1 =3D <0> >>>>>>> > >>>>>>>>>>>> usbus0 Memory Model Features 0 =3D <4k Granule,= 64k >>>>>>> Granule,S/NS >>>>>>> > >>>>>>>>>>>> Mem,MixedEndian,16bit ASID,1TB PA> >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Memory Model Features 1 =3D <> >>>>>>> > >>>>>>>>>>>> Memory Model Features 2 =3D <32b CCIDX,48b VA> >>>>>>> > >>>>>>>>>>>> Debug Features 0 =3D <2 CTX Breakpoints,4 >>>>>>> Watchpoints,6 >>>>>>> > >>>>>>>>>>>> Breakpoints,PMUv3,Debug v8> >>>>>>> > >>>>>>>>>>>> Debug Features 1 =3D <0> >>>>>>> > >>>>>>>>>>>> Auxiliary Features 0 =3D <0> >>>>>>> > >>>>>>>>>>>> Auxiliary Features 1 =3D <0> >>>>>>> > >>>>>>>>>>>> CPU 1: ARM Cortex-A53 r0p4 affinity: 1 >>>>>>> > >>>>>>>>>>>> WARNING: WITNESS option enabled, expect reduced >>>>>>> performance. >>>>>>> > >>>>>>>>>>>> ugen0.1: at usbus0 >>>>>>> > >>>>>>>>>>>> ugen1.1: at usbus1 >>>>>>> > >>>>>>>>>>>> uhub0 on usbus0 >>>>>>> > >>>>>>>>>>>> uhub1 on usbus1 >>>>>>> > >>>>>>>>>>>> uhub0: >>>>>> 3.00/1.00, addr 1> on >>>>>>> > >>>>>>>>>>>> usbus0 >>>>>>> > >>>>>>>>>>>> uhub1: >>>>>> 2.00/1.00, addr 1> on >>>>>>> > >>>>>>>>>>>> usbus1 >>>>>>> > >>>>>>>>>>>> uhub0: 2 ports with 2 removable, self powered >>>>>>> > >>>>>>>>>>>> uhub1: 1 port with 1 removable, self powered >>>>>>> > >>>>>>>>>>>> mountroot: waiting for device >>>>>>> /dev/ufs/FreeBSD_Install... >>>>>>> > >>>>>>>>>>>> Mounting from ufs:/dev/ufs/FreeBSD_Install failed >>>>>>> with error 19. >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Loader variables: >>>>>>> > >>>>>>>>>>>> vfs.root.mountfrom=3Dufs:/dev/ufs/FreeBSD_Install >>>>>>> > >>>>>>>>>>>> vfs.root.mountfrom.options=3Dro,noatime >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> Manual root filesystem specification: >>>>>>> > >>>>>>>>>>>> : [options] >>>>>>> > >>>>>>>>>>>> Mount using filesystem >>>>>>> > >>>>>>>>>>>> and with the specified (optional) option list. >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> eg. ufs:/dev/da0s1a >>>>>>> > >>>>>>>>>>>> zfs:zroot/ROOT/default >>>>>>> > >>>>>>>>>>>> cd9660:/dev/cd0 ro >>>>>>> > >>>>>>>>>>>> (which is equivalent to: mount -t cd9660 -o ro >>>>>>> /dev/cd0 /) >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> ? List valid disk boot devices >>>>>>> > >>>>>>>>>>>> . Yield 1 second (for background tasks= ) >>>>>>> > >>>>>>>>>>>> Abort manual input >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> mountroot> ? >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> List of GEOM managed disk devices: >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> mountroot> >>>>>>> > >>>>>>>>>>>> _______________________________________________ >>>>>>> > >>>>>>>>>>>> freebsd-arm@freebsd.org >>>>>> 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 >>>>>> freebsd-arm-unsubscribe@freebsd.org>" >>>>>>> > >>>>>>>>>>>> >>>>>>> > >>>>>>>>>>>> _______________________________________________ >>>>>>> > >>>>>>>>>>>> freebsd-arm@freebsd.org >>>>>> 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 >>>>>> freebsd-arm-unsubscribe@freebsd.org>" >>>>>>> > >>>>>>>>>>> >>>>>>> > >>>>>>>>>> >>>>>>> > >>>>>>>>>> >>>>>>> > >>>>>>>>>> -- >>>>>>> > >>>>>>>>>> Emmanuel Vadot < >>>>>>> manu@freebsd.org> >>>>>>> > >>>>>>>>> >>>>>>> > >>>>>>>> >>>>>>> > >>>>>>>> >>>>>>> > >>>>>>>> -- >>>>>>> > >>>>>>>> Emmanuel Vadot >>>>>>> > >>>>>> >>>>>>> > >>>>>> >>>>>>> > >>>>>> -- >>>>>>> > >>>>>> Emmanuel Vadot >>>>>>> > >>>>>> _______________________________________________ >>>>>>> > >>>>>> freebsd-arm@freebsd.org mailing list >>>>>>> > >>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >>>>>>> > >>>>>> To unsubscribe, send any mail to " >>>>>>> freebsd-arm-unsubscribe@freebsd.org" >>>>>>> > >>>>> >>>>>>> > >>>>> >>>>>>> > >>>>> -- >>>>>>> > >>>>> Emmanuel Vadot >>>>>>> > >>>>> _______________________________________________ >>>>>>> > >>>>> freebsd-arm@freebsd.org mailing list >>>>>>> > >>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >>>>>>> > >>>>> To unsubscribe, send any mail to " >>>>>>> freebsd-arm-unsubscribe@freebsd.org" >>>>>>> > >>>> >>>>>>> > >>>> >>>>>>> > >>>> -- >>>>>>> > >>>> Emmanuel Vadot >>>>>>> > >>>> _______________________________________________ >>>>>>> > >>>> freebsd-arm@freebsd.org mailing list >>>>>>> > >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >>>>>>> > >>>> To unsubscribe, send any mail to " >>>>>>> freebsd-arm-unsubscribe@freebsd.org" >>>>>>> > >>> >>>>>>> > >>> >>>>>>> > >>> -- >>>>>>> > >>> Emmanuel Vadot >>>>>> manu@bidouilliste.com>> = > >>>>>>> > >> >>>>>>> > > >>>>>>> > > >>>>>>> > > -- >>>>>>> > > Emmanuel Vadot >>>>>> manu@bidouilliste.com>> = > >>>>>>> > >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Emmanuel Vadot >>>>>>> _______________________________________________ >>>>>>> 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" >>>>>>> >>>>>> >>>>>> >>>>> >>>> >> From owner-freebsd-arm@freebsd.org Tue Aug 20 02:18:20 2019 Return-Path: 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 62716C0ED5 for ; Tue, 20 Aug 2019 02:18:20 +0000 (UTC) (envelope-from zhangchaowang@gmail.com) Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46CDwq0mWCz3GNm for ; Tue, 20 Aug 2019 02:18:18 +0000 (UTC) (envelope-from zhangchaowang@gmail.com) Received: by mail-lj1-x241.google.com with SMTP id f9so3573679ljc.13 for ; Mon, 19 Aug 2019 19:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=y7+iO3JPyC3B4a73GxBznObDGmPs9hxYPJdw/yYGcVw=; b=Jzg3kU1/SL3PdMMhjlx9ooSODSBbrWRTuFRQxUamaH5TS0XLhVjMdlSOT5zLFhfWqd vTnzZnmPDbszBIDXeqGx6YZlBBCPf0hTqOjhgLdb0+LETxRKdV/PZQpy7ePOTaKiXN7q Fa0KzHqXhOAg7fucgGbiUUonFAMQUc5XuV0+CK/3Kau2xtzwJOqwR+iS1lKMsag0t60t /xXao/kOSCDFIFJ6h1H/7gnC8snTbKyzEi60KTu7X2aTp00buwIECFBYBSSCeEW9Yywz ayA3BHkUbxMZlnXOinuErun7llitq5Ml0GItYCjvX94hBXki6BFyCj/y9zsUOT61Znhw ZbDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=y7+iO3JPyC3B4a73GxBznObDGmPs9hxYPJdw/yYGcVw=; b=LEk6fUWkmMuAruFrrsZ+UqLJa+Ph9uXyVk4xyKD1ApXjdlqVO59A+nCgsJx/4l/cPr xKWN6qieDKihwcnGfx88IO/jhYFwgf9ZfznPL70BERcDpbwxZxNTbCfSZEzgnp2U3MLL W+LCM6Zi6f3SHQQ+4zmt46Q340PnP6w8j//lowXxy0kBw+zp/kfmnnLqcrVOmfKfCe8U D4PbV9Tc8uTuv3Ffn/r4sNJ9zYqEmpELcv4kUXxRs31FmPOeWx3nTYbAzmU/RmsGjBk8 FtnrC0QJL81/dOHG+rGqKejpDlY8pkzG1MCOKaVc/YxheF0jwI6tV/Ath65m2k2Se/90 /uxw== X-Gm-Message-State: APjAAAWHNvy14KlOK/V5HyxVp/XvIZHY2FJyKy2bkmBbfkD1abHH/0NH xC43sdmBXoTpYkqcPw9Kfr3sNkLyyK29GlsKJfY2Oilv X-Google-Smtp-Source: APXvYqx/Jl+rPVhK8a1gZhG3D1459qPkZLV1zcAfKaRH/Jzf7z6kRuxj4+sXYljVT1g9BNIBY7e0isKsvat3OK1xqgA= X-Received: by 2002:a2e:1518:: with SMTP id s24mr5529229ljd.205.1566267495961; Mon, 19 Aug 2019 19:18:15 -0700 (PDT) MIME-Version: 1.0 From: Ricky Zhang Date: Mon, 19 Aug 2019 22:18:05 -0400 Message-ID: Subject: How to change rootfs from official RPI3 image To: freebsd-arm@freebsd.org X-Rspamd-Queue-Id: 46CDwq0mWCz3GNm X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=Jzg3kU1/; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of zhangchaowang@gmail.com designates 2a00:1450:4864:20::241 as permitted sender) smtp.mailfrom=zhangchaowang@gmail.com X-Spamd-Result: default: False [-3.99 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(0.00)[ip: (3.23), ipnet: 2a00:1450::/32(-3.02), asn: 15169(-2.37), country: US(-0.05)]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[1.4.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.99)[-0.990,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 02:18:20 -0000 Hi, I dd a FreeBSD 12.0 RPI3 image to a SD card. Everything works like a charm on my RPI3. But I want to switch rootfs to a larger USB hard drive. The boot partition contains one configurable text file config.txt. I can't google how the uboot load kernel from the rootfs partition. To my surprise, the FreeBSD kernel is in the rootfs partition. Is this u-boot pieces open source? Where are the user guide documents? The only document I could find provides no technical details in boot sequence. thanks, Ricky From owner-freebsd-arm@freebsd.org Tue Aug 20 02:31:12 2019 Return-Path: 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 8AB1CC152B for ; Tue, 20 Aug 2019 02:31:12 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by mx1.freebsd.org (Postfix) with ESMTP id 46CFCf0rTlz3H64 for ; Tue, 20 Aug 2019 02:31:09 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from ppp118-210-70-93.adl-adc-lon-bras32.tpg.internode.on.net (HELO midget.dons.net.au) ([118.210.70.93]) by ipmail06.adl2.internode.on.net with ESMTP; 20 Aug 2019 12:01:05 +0930 Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.15.2/8.15.2) with ESMTPS id x7K2V0OQ020763 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 20 Aug 2019 12:01:00 +0930 (ACST) (envelope-from darius@dons.net.au) Received: (from mailnull@localhost) by midget.dons.net.au (8.15.2/8.15.2/Submit) id x7K285IC002460 for ; Tue, 20 Aug 2019 11:38:05 +0930 (ACST) (envelope-from darius@dons.net.au) X-Authentication-Warning: midget.dons.net.au: mailnull set sender to using -f Received: from [203.31.81.177] ([203.31.81.177]) by ppp118-210-70-93.adl-adc-lon-bras32.tpg.internode.on.net (envelope-sender ) (MIMEDefang) with ESMTP id x7K27xlJ002453; Tue, 20 Aug 2019 11:38:05 +0930 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Is it a good idea to use a usb-serial adapter for PPS input? Yes, it is. From: "O'Connor, Daniel" In-Reply-To: <9E142F1A-5E8C-4410-91F5-7C80B3D0A15B@dons.net.au> Date: Tue, 20 Aug 2019 11:37:59 +0930 Cc: "usb@freebsd.org" , "freebsd-arm@FreeBSD.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9D2ACA87-C2DB-40D9-9638-B0E215A4EEC0@dons.net.au> References: <61B1AAF3-40F6-47BC-8F05-7491C13BF288@dons.net.au> <9E142F1A-5E8C-4410-91F5-7C80B3D0A15B@dons.net.au> To: Ian Lepore X-Mailer: Apple Mail (2.3445.104.11) X-Spam-Score: 1.3 (*) No, score=1.3 required=5.0 tests=HELO_MISC_IP, RDNS_NONE, SPF_NONE autolearn=no autolearn_force=no version=3.4.1 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: 46CFCf0rTlz3H64 X-Spamd-Bar: ++++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of darius@dons.net.au has no SPF policy when checking 150.101.137.129) smtp.mailfrom=darius@dons.net.au X-Spamd-Result: default: False [6.53 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; HAS_XAW(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(2.11)[ip: (5.33), ipnet: 150.101.0.0/16(3.58), asn: 4739(1.63), country: AU(0.01)]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:4739, ipnet:150.101.0.0/16, country:AU]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.94)[0.938,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.98)[0.981,0]; DMARC_NA(0.00)[dons.net.au]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[0.997,0]; RCVD_IN_DNSWL_NONE(0.00)[129.137.101.150.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[] X-Spam: Yes X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 02:31:12 -0000 > On 19 Aug 2019, at 17:09, O'Connor, Daniel wrote: > I am going to try this diff but buildkernel is going to take a = while... Was a lot faster cross building, so I installed it this morning: [gps 1:56] ~ >uname -a FreeBSD gps 13.0-CURRENT FreeBSD 13.0-CURRENT #1 = 41a4c010326-c262109(master)-dirty: Tue Aug 20 11:04:57 ACST 2019 = darius@midget.dons.net.au:/usr/obj/arm-src/arm.armv7/sys/GENERIC arm [gps 1:57] ~ >dmesg|grep pps am335x_dmtpps0: mem 0x48044000-0x480443ff = irq 30 on simplebus0 [gps 1:58] ~ >ll /dev/pps0 /dev/dmtpps crw-rw---- 1 root ntpd 0x41 20 Aug 01:09 /dev/dmtpps lrwxr-xr-x 1 root wheel 6 20 Aug 01:09 /dev/pps0 -> dmtpps [gps 1:58] ~ >cat /etc/ntp.conf server 10.0.2.1 iburst prefer server 127.127.22.0 minpoll 4 maxpoll 4 fudge 127.127.22.0 refid PPS [gps 1:59] ~ >ntpq -nc pe remote refid st t when poll reach delay offset = jitter = =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D *10.0.2.1 214.52.129.40 3 u 64 64 37 0.349 -0.631 = 0.299 o127.127.22.0 .PPS. 0 l 13 16 377 0.000 1.000 = 0.106 It certainly seems happier with the PPS than it was before. Next up would be to use the NMEA coming from the GPS engine for time = instead of using the LAN host so it's self contained. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From owner-freebsd-arm@freebsd.org Tue Aug 20 07:49:56 2019 Return-Path: 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 5A60CC93B9 for ; Tue, 20 Aug 2019 07:49:56 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46CNHR1Qt3z4294 for ; Tue, 20 Aug 2019 07:49:54 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Date: Tue, 20 Aug 2019 09:49:53 +0200 (CEST) From: Ronald Klop To: freebsd-arm@freebsd.org Message-ID: <1782739482.1.1566287393414@localhost> In-Reply-To: References: Subject: Re: How to change rootfs from official RPI3 image MIME-Version: 1.0 X-Mailer: Realworks (471.10.dac909626d7) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 46CNHR1Qt3z4294 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 194.109.157.24 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws X-Spamd-Result: default: False [-1.30 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.95)[-0.949,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[klop.ws]; URI_COUNT_ODD(1.00)[3]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-0.06)[ipnet: 194.109.0.0/16(-0.16), asn: 3265(-0.13), country: NL(0.01)]; NEURAL_HAM_LONG(-0.93)[-0.926,0]; NEURAL_HAM_SHORT(-0.57)[-0.570,0]; RCVD_IN_DNSWL_NONE(0.00)[24.157.109.194.list.dnswl.org : 127.0.15.0]; HAS_X_PRIO_THREE(0.00)[3]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; MIME_TRACE(0.00)[0:+,1:+,2:~] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 07:49:56 -0000 Van: Ricky Zhang Datum: dinsdag, 20 augustus 2019 04:18 Aan: freebsd-arm@freebsd.org Onderwerp: How to change rootfs from official RPI3 image > > Hi, > > I dd a FreeBSD 12.0 RPI3 image to a SD card. Everything works like a charm > on my RPI3. > > But I want to switch rootfs to a larger USB hard drive. The boot partition > contains one configurable text file config.txt. I can't google how the > uboot load kernel from the rootfs partition. To my surprise, the FreeBSD > kernel is in the rootfs partition. > > Is this u-boot pieces open source? Where are the user guide documents? The > only document I could find provides no technical details in boot sequence. > > thanks, > Ricky > _______________________________________________ > 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" > > > Hi, I have it arranged that the kernel is loaded from the SD card, but the rest of the system is from an SSD via USB. In /etc/fstab: /dev/gpt/ssdrootfs / ufs rw,noatime 1 1 /dev/ufs/rootfs /bootdir ufs rw,noatime 1 2 /dev/msdosfs/MSDOSBOOT /boot/msdos msdosfs rw,noatime 0 2 And a symlink from /boot -> /bootdir/boot In /boot/loader.conf: vfs.root.mountfrom="ufs:/dev/gpt/ssdrootfs" kern.cam.boot_delay="20000" My 2 cents. Regards, Ronald. From owner-freebsd-arm@freebsd.org Tue Aug 20 08:09:54 2019 Return-Path: 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 75A61CA5F4 for ; Tue, 20 Aug 2019 08:09:54 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46CNkT1cQHz43B8 for ; Tue, 20 Aug 2019 08:09:52 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Date: Tue, 20 Aug 2019 10:09:51 +0200 (CEST) From: Ronald Klop To: freebsd-arm@freebsd.org Message-ID: <1006930075.14.1566288591351@localhost> In-Reply-To: <1782739482.1.1566287393414@localhost> References: <1782739482.1.1566287393414@localhost> Subject: Re: How to change rootfs from official RPI3 image MIME-Version: 1.0 X-Mailer: Realworks (471.10.dac909626d7) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 46CNkT1cQHz43B8 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 194.109.157.24 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws X-Spamd-Result: default: False [-2.69 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[klop.ws]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-0.997,0]; IP_SCORE(-0.06)[ipnet: 194.109.0.0/16(-0.16), asn: 3265(-0.13), country: NL(0.01)]; NEURAL_HAM_SHORT(-0.84)[-0.838,0]; RCVD_IN_DNSWL_NONE(0.00)[24.157.109.194.list.dnswl.org : 127.0.15.0]; HAS_X_PRIO_THREE(0.00)[3]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; MIME_TRACE(0.00)[0:+,1:+,2:~] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 08:09:54 -0000 Van: Ronald Klop Datum: dinsdag, 20 augustus 2019 09:49 Aan: freebsd-arm@freebsd.org Onderwerp: Re: How to change rootfs from official RPI3 image > > > Van: Ricky Zhang > Datum: dinsdag, 20 augustus 2019 04:18 > Aan: freebsd-arm@freebsd.org > Onderwerp: How to change rootfs from official RPI3 image > > > > Hi, > > > > I dd a FreeBSD 12.0 RPI3 image to a SD card. Everything works like a charm > > on my RPI3. > > > > But I want to switch rootfs to a larger USB hard drive. The boot partition > > contains one configurable text file config.txt. I can't google how the > > uboot load kernel from the rootfs partition. To my surprise, the FreeBSD > > kernel is in the rootfs partition. > > > > Is this u-boot pieces open source? Where are the user guide documents? The > > only document I could find provides no technical details in boot sequence. > > > > thanks, > > Ricky > > _______________________________________________ > > 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" > > > > > > > > Hi, I have it arranged that the kernel is loaded from the SD card, but the rest of the system is from an SSD via USB. > > In /etc/fstab: > /dev/gpt/ssdrootfs / ufs rw,noatime 1 1 > /dev/ufs/rootfs /bootdir ufs rw,noatime 1 2 > /dev/msdosfs/MSDOSBOOT /boot/msdos msdosfs rw,noatime 0 2 > > And a symlink from /boot -> /bootdir/boot > > In /boot/loader.conf: > vfs.root.mountfrom="ufs:/dev/gpt/ssdrootfs" > kern.cam.boot_delay="20000" > > My 2 cents. > > Regards, > Ronald. > > _______________________________________________ > 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" > > > BTW: Yes, u-boot is opensource: /usr/ports/sysutils/u-boot-rpi3 There are sysutils/u-boot-* ports for different system. With sysutils/u-boot-master as the main part of it. https://www.freshports.org/sysutils/u-boot-rpi3 http://www.denx.de/wiki/U-Boot Regards, Ronald. From owner-freebsd-arm@freebsd.org Tue Aug 20 11:38:36 2019 Return-Path: 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 63FACCF069 for ; Tue, 20 Aug 2019 11:38:36 +0000 (UTC) (envelope-from per@hedeland.org) Received: from outbound1f.eu.mailhop.org (outbound1f.eu.mailhop.org [52.28.59.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46CTMG50gtz4FMv for ; Tue, 20 Aug 2019 11:38:34 +0000 (UTC) (envelope-from per@hedeland.org) ARC-Seal: i=1; a=rsa-sha256; t=1566301112; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=h/09w8tuDcojQNxQqNds1hkTPD0OdxtcGsAJwVA2JmgU4fEJHSAO7j7ZDIU+cjekFTgTUCrUabj3O OXJP3hxDp0W5VaeimK15nnfpGuH4bWdP+qACkYMdXonjb0TqhtZReRj8PxVtXky/GF6CxezVpvy34i PRz3mpluel/KimVxLznfdVUBJj9S+2TuwXUxPRQUHfyuJSpCORAJh0lYPd2KCYR64nMcN4gYjIGzu8 /N/CEenF8U6WI0gJRlbbxgP4OGWBfYtXcrt+S+2K7k0edJcK9NXU1KJo9dImSx4PgkiBSG2SUVl7wG z8t3qhQG9sptrfS16gMv1d+Peh4/Saw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:references:cc:to:subject:dkim-signature:from; bh=bD9mFAOhMY3UWBI7gDewz93Le3Oym8Z+o1hmbUXepCw=; b=cEpuZCaRWvtR8R/Dlt2FsO2oOXoS41Q7mSamneFty09NkfSZp3kCAYvPEHDCYJX+NEA5sNHPQw0WS +zEwycAkVbLLBZUtGAz7NaNIAE63AHhkGwWU+QW3FkRhkq1VQ9HFPWejPCAmJYz3gOgRBWGEZZ1IeP TSBKu6nJP+fKRn0FtOD9TGDHFCIDwWQ32dPmWPmrJRmAS3Rbs8bkIDKEsI01tzkLzDr20nSHKgDgqb DVODm1Cz7Gdyca3ccSJY6reaPyEmEbPanvyQcX0ydlJi7bW7Rhw3MdTmVdYMcuPQpqWTbgKAXlTBoE Oh3aWiySN8haun7yt6OlMxxZiFkcsLQ== ARC-Authentication-Results: i=1; outbound2.eu.mailhop.org; spf=none smtp.mailfrom=hedeland.org smtp.remote-ip=81.228.157.209; dmarc=none header.from=hedeland.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:references:cc:to:subject:from; bh=bD9mFAOhMY3UWBI7gDewz93Le3Oym8Z+o1hmbUXepCw=; b=C1rpgfqt/8vg6HAcqW5V56XXHbgoaMGtLlKXcFbsYlnqvQqehDCLzd6Nl7N2DOQontbs+zeHtY7K/ rx82oNfPaIWEQDN3yg0GRkTMBO21zYuujAdjqYjIMPL1UlOmBYo0+8WvGGw1TGA9wpl+OSSmgfvfQx Pt1bSc3xUwqkOUNtADfbj/cO4hb6u9HV6/XM2e3JzSC+MCKZZ5bxTKh/rrwj37bquCcpjtAoy+dusy MDs9mKggFd8OLcqjpdSxWcH1NEoHPDK9p7Pio+LpuaHu4QUcrGDcWH19iLo1D6vZUCnwSz3EUH3/YR 1Lt2fYzgYn2SrBOsSAmeTvuD8a/GVVQ== X-MHO-RoutePath: cGVyaGVkZWxhbmQ= X-MHO-User: 079cd59a-c33f-11e9-a204-f5e3bb5d0a28 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 81.228.157.209 X-Mail-Handler: DuoCircle Outbound SMTP Received: from hedeland.org (unknown [81.228.157.209]) by outbound2.eu.mailhop.org (Halon) with ESMTPSA id 079cd59a-c33f-11e9-a204-f5e3bb5d0a28; Tue, 20 Aug 2019 11:38:29 +0000 (UTC) Received: from plutt.hedeland.org (82-209-140-38.cust.bredband2.com [82.209.140.38]) (authenticated bits=0) by tellus.hedeland.org (8.15.2/8.15.2) with ESMTPSA id x7KBcRK6062124 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 20 Aug 2019 13:38:28 +0200 (CEST) (envelope-from per@hedeland.org) X-Authentication-Warning: tellus.hedeland.org: Host 82-209-140-38.cust.bredband2.com [82.209.140.38] claimed to be plutt.hedeland.org Subject: Re: Is it a good idea to use a usb-serial adapter for PPS? Yes, it is. To: Hans Petter Selasky , Ian Lepore Cc: freebsd-arm@freebsd.org References: <69a9bed3-4d0a-f8f6-91af-a8f7d84ee307@hedeland.org> <345bae77417c2495f55799b4c7ca2784f4ece9ed.camel@freebsd.org> <7312032d-2908-9414-0445-6b442c3a02e5@hedeland.org> <523b6f0a0fa5f2aeec298fa74df25d3c4af66acc.camel@freebsd.org> <0426fc8b-5398-d8ab-561e-7823c24403a5@hedeland.org> <24b0eaf25b64d6098b390df092866c69e352d859.camel@freebsd.org> <16c91be1-6f2a-b26d-22c7-be8e4ba8eec0@hedeland.org> <72a964c78cbfc36be2345919633ca2196f0783e3.camel@freebsd.org> <540c8b5f-5e81-b67b-4a00-49b86044efe0@selasky.org> From: Per Hedeland Message-ID: <8e28c96e-92c6-5beb-277f-0876a5aba272@hedeland.org> Date: Tue, 20 Aug 2019 13:38:22 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: <540c8b5f-5e81-b67b-4a00-49b86044efe0@selasky.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46CTMG50gtz4FMv X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=outbound.mailhop.org header.s=dkim-high header.b=C1rpgfqt; dmarc=none; spf=none (mx1.freebsd.org: domain of per@hedeland.org has no SPF policy when checking 52.28.59.28) smtp.mailfrom=per@hedeland.org X-Spamd-Result: default: False [-5.53 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_XOIP(0.00)[]; TO_DN_SOME(0.00)[]; HAS_XAW(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[outbound.mailhop.org:+]; NEURAL_HAM_SHORT(-0.98)[-0.977,0]; RECEIVED_SPAMHAUS_PBL(0.00)[209.157.228.81.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11,38.140.209.82.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_ALLOW(-1.00)[i=1]; IP_SCORE(-1.26)[ipnet: 52.28.0.0/16(-4.88), asn: 16509(-1.35), country: US(-0.05)]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[outbound.mailhop.org:s=dkim-high]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:16509, ipnet:52.28.0.0/16, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[hedeland.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[28.59.28.52.list.dnswl.org : 127.0.20.0]; R_SPF_NA(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 11:38:36 -0000 On 2019-08-19 09:20, Hans Petter Selasky wrote: > On 2019-08-18 23:57, Ian Lepore wrote: >> I think HPS reads the arm@ list, but I'll cc him directly on this >> reply, just in case he has time to weigh in on this stuff. > > Hi, > > I'm subscribed. > > The behaviour of BULK transfers depend on the actual USB host controller manufacturer. > > USB transfers are executed by priority, typically: > ISOCHRONOUS, INTERRUPT, CONTROL, BULK > > Depending on the endpoint descriptor, the service rate may vary. The minimum guarantee is to be serviced one time every 125us (for USB2.0). > > Completion interrupts are usually delayed a bit (63-125us for EHCI/XHCI, 1ms for USB 1.0 via UHCI/OHCI). > > The USB stack in FreeBSD does not have any memory allocations in the fast path and so is very quick to complete jobs. Also in user-space. I'm sorry, I'm afraid I still don't really understand... The question, at least in my mind, was whether polling was done in a "strictly periodic" fashion, at most once per 125 us for USB 2.0 - or whether the host controller would poll "as fast as it could", which could result in a *much* higher polling rate. As others too have pointed out, the size of the latency doesn't really matter for NTP as long as it is more or less constant (i.e. varies at most a few tens of us, preferably less). I can't see how polling with an interval of 125 us or more, based on the frequency of a crystal on the host, could achieve a variation that is smaller than the size of the polling interval. > Technically speaking, the time device could make predictions about when the packet is read from the USB buffer and when the USB host issues the completion interrupt. > > These adjustment values could be calibrated by some kind of ping protocol. This sounds like a method to determine a fixed latency - or am I misunderstanding? --Per From owner-freebsd-arm@freebsd.org Tue Aug 20 11:50:58 2019 Return-Path: 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 14196CF443 for ; Tue, 20 Aug 2019 11:50:58 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46CTdY10Gzz4FwH; Tue, 20 Aug 2019 11:50:56 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 2C024260295; Tue, 20 Aug 2019 13:50:49 +0200 (CEST) Subject: Re: Is it a good idea to use a usb-serial adapter for PPS? Yes, it is. To: Per Hedeland , Ian Lepore Cc: freebsd-arm@freebsd.org References: <69a9bed3-4d0a-f8f6-91af-a8f7d84ee307@hedeland.org> <345bae77417c2495f55799b4c7ca2784f4ece9ed.camel@freebsd.org> <7312032d-2908-9414-0445-6b442c3a02e5@hedeland.org> <523b6f0a0fa5f2aeec298fa74df25d3c4af66acc.camel@freebsd.org> <0426fc8b-5398-d8ab-561e-7823c24403a5@hedeland.org> <24b0eaf25b64d6098b390df092866c69e352d859.camel@freebsd.org> <16c91be1-6f2a-b26d-22c7-be8e4ba8eec0@hedeland.org> <72a964c78cbfc36be2345919633ca2196f0783e3.camel@freebsd.org> <540c8b5f-5e81-b67b-4a00-49b86044efe0@selasky.org> <8e28c96e-92c6-5beb-277f-0876a5aba272@hedeland.org> From: Hans Petter Selasky Message-ID: Date: Tue, 20 Aug 2019 13:50:08 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <8e28c96e-92c6-5beb-277f-0876a5aba272@hedeland.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46CTdY10Gzz4FwH X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-5.85 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.96)[-0.964,0]; IP_SCORE(-2.58)[ip: (-9.11), ipnet: 2a01:4f8::/29(-1.95), asn: 24940(-1.85), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 11:50:58 -0000 On 2019-08-20 13:38, Per Hedeland wrote: > > I'm sorry, I'm afraid I still don't really understand... The question, > at least in my mind, was whether polling was done in a "strictly > periodic" fashion, at most once per 125 us for USB 2.0 - or whether > the host controller would poll "as fast as it could", which could > result in a *much* higher polling rate. That depends on the endpoint type. INTERRUPT endpoints poll regularly, one time, every 125 us for example, when a job is queued. BULK endpoints poll all the time, depending a bit on the HC in use. Anyways, the computer is not notified of the completion before the HC is generating an interrupt. This usually happens at some fixed point in time. I.E. multiple completions can be joined into one HC interrupt. It is the completion interrupt which notifies the software about the PPS event. --HPS From owner-freebsd-arm@freebsd.org Tue Aug 20 11:54:16 2019 Return-Path: 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 29514CF670 for ; Tue, 20 Aug 2019 11:54:16 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46CTjL4nHNz4GCx; Tue, 20 Aug 2019 11:54:14 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 108F8260295; Tue, 20 Aug 2019 13:54:13 +0200 (CEST) Subject: Re: Is it a good idea to use a usb-serial adapter for PPS? Yes, it is. To: Per Hedeland , Ian Lepore Cc: freebsd-arm@freebsd.org References: <69a9bed3-4d0a-f8f6-91af-a8f7d84ee307@hedeland.org> <345bae77417c2495f55799b4c7ca2784f4ece9ed.camel@freebsd.org> <7312032d-2908-9414-0445-6b442c3a02e5@hedeland.org> <523b6f0a0fa5f2aeec298fa74df25d3c4af66acc.camel@freebsd.org> <0426fc8b-5398-d8ab-561e-7823c24403a5@hedeland.org> <24b0eaf25b64d6098b390df092866c69e352d859.camel@freebsd.org> <16c91be1-6f2a-b26d-22c7-be8e4ba8eec0@hedeland.org> <72a964c78cbfc36be2345919633ca2196f0783e3.camel@freebsd.org> <540c8b5f-5e81-b67b-4a00-49b86044efe0@selasky.org> <8e28c96e-92c6-5beb-277f-0876a5aba272@hedeland.org> From: Hans Petter Selasky Message-ID: <832f8e20-443b-868f-083d-ccff3ea32372@selasky.org> Date: Tue, 20 Aug 2019 13:53:32 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <8e28c96e-92c6-5beb-277f-0876a5aba272@hedeland.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46CTjL4nHNz4GCx X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-5.85 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; SUBJECT_HAS_QUESTION(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.96)[-0.964,0]; IP_SCORE(-2.58)[ip: (-9.11), ipnet: 2a01:4f8::/29(-1.95), asn: 24940(-1.85), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 11:54:16 -0000 On 2019-08-20 13:38, Per Hedeland wrote: > > This sounds like a method to determine a fixed latency - or am I > misunderstanding? The HC sends out a timestamp, called SOF, to all USB devices every 1ms or 125us. This SOF mark is usually the beginning of the polling schedule. All USB endpoints are polled by the HC. The USB device can predict the time of the SOF and also completion on the HC and so I believe adjust the timestamp, so that it would appear to be received instantaneously. --HPS From owner-freebsd-arm@freebsd.org Tue Aug 20 12:33:24 2019 Return-Path: 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 14072D1175 for ; Tue, 20 Aug 2019 12:33:24 +0000 (UTC) (envelope-from khantroll@gmail.com) Received: from mail-ot1-x343.google.com (mail-ot1-x343.google.com [IPv6:2607:f8b0:4864:20::343]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46CVZW0m3Pz4JWT for ; Tue, 20 Aug 2019 12:33:22 +0000 (UTC) (envelope-from khantroll@gmail.com) Received: by mail-ot1-x343.google.com with SMTP id m24so4824292otp.12 for ; Tue, 20 Aug 2019 05:33:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=WbDSBpCqm6rRyI+33J2vG7wtfcuvuclbXKQ2AjyED4g=; b=i7KG6eAL38rm+rqPsWHxFZxkKV4+blhLp60xJtj/AYT6Zdv6eiaponU9VtMYHxO2C1 YgfL4s35b/9muaBQToJX6Y5neC8rMI9HhWSt3RePoUWux76Oeb04U4OKylwPfa75l+/t WlZj6BcLw6BCyGF/em63g/wD7kBTLYi1aN9TGPI7dkg4XvL/4bR6DUv0gHFJK1vt9OsI rjX7Q9USpGzhrkkV3RWiSSFxUmsyFoH5M/EBGyfeKAI/rCK18wB+4ASQVAJm7EzxCRZB FFFj+MjbMacV8cIRvwDTcQiakuKlofRrT0jzmZnFRAi4KTj9mC5WkYH779G7HXcnO2o5 vrPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=WbDSBpCqm6rRyI+33J2vG7wtfcuvuclbXKQ2AjyED4g=; b=C7WY83MF7zVH30R6PG0on8iXI+yWGb7N7Zw36oW8zhHWE7whQLcyaFzaUGFsQ+YMnS oPBEefK70Z5GRY82Y1DeXt5jCG7up5kh7/t49kt3+fXFOtdewmy2z1ktTmQ7PFiZASDR 4XID1eEdjH+gxYeTazW2BaIlyWGOnp5fbsfDFJWr5V9bB92dTOn0eMUFLVVqhjRgwaNO 5nTSrSN1Xw7Rmdy2QazzCrdwmdK7gi9SIizuLT0NCMKOMba4oej0m+7SF3TtYmGmjv91 gipxkyje+FaZycFWuDsRGxWukjsHok/M9fe9mOolJJcYSCFw2ilTWvnXrmrE8JA2uT9z n+VA== X-Gm-Message-State: APjAAAXTC4EoaFKdko163mq+byCIuMLP0ybuOekySP1uBXH5tPlm97bg b7Utw16cFVTPF7XTsuHwd67t9dt7Z6C+J122txo= X-Google-Smtp-Source: APXvYqxbWer3ml0sEVCpT0K+8CupTRxgwwDz6U2dTQ6dQ3y2jkBERkMj96f6wH7Xcdv+VDq0kSVoqxB4UOMilM0UcZw= X-Received: by 2002:a05:6830:51:: with SMTP id d17mr13833467otp.358.1566304401463; Tue, 20 Aug 2019 05:33:21 -0700 (PDT) MIME-Version: 1.0 References: <1547777156.662147.1565798461515.JavaMail.zimbra@perftech.com> <0E42E605-477E-4E65-810E-BD3A8CDE2C80@gmail.com> <973015183.1067498.1565890674099.JavaMail.zimbra@perftech.com> <20190815210311.1035f64b003e2bc85fa47ca8@bidouilliste.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> <20190817153053.5592b15b8a42982fda0fc123@bidouilliste.com> <9749945A-FDAD-47E0-947A-FA62138C2F83@gmail.com> <20190817210822.8920656bad0855b554883cf2@bidouilliste.com> <2D6D4BDA-75EC-403F-B5E2-52A468369DE2@gmail.com> <627099DD-804B-412F-A083-768CEFCF955C@gmail.com> <6DA8E736-8031-4BF7-8B20-CF8B0E8A7FEF@gmail.com> In-Reply-To: From: Jeffrey Bowers Date: Tue, 20 Aug 2019 07:33:07 -0500 Message-ID: Subject: Re: Espressobin anyone ? To: =?UTF-8?Q?S=C3=B8ren_Schmidt?= , freebsd-arm X-Rspamd-Queue-Id: 46CVZW0m3Pz4JWT X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=i7KG6eAL; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of khantroll@gmail.com designates 2607:f8b0:4864:20::343 as permitted sender) smtp.mailfrom=khantroll@gmail.com X-Spamd-Result: default: False [-2.99 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.99)[-0.989,0]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; SH_EMAIL_ZRD(0.00)[0.0.46.224,0.0.117.48]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.117.48,0.0.46.224]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE_FREEMAIL(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[3.4.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(0.00)[ip: (2.93), ipnet: 2607:f8b0::/32(-2.93), asn: 15169(-2.37), country: US(-0.05)]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 12:33:24 -0000 I'm still getting: svn: E000060: Operation timed out It goes for several minutes scrolling through text, and I feel like using your link got further. Thanks! On Tue, Aug 20, 2019 at 2:49 AM S=C3=B8ren Schmidt wrote: > Hmm, I use this URL > > Repository Root: https://svn.freebsd.org/ports/head > > Not sure the svn+ssh thing works=E2=80=A6 > > -S=C3=B8ren > > > On 20 Aug 2019, at 02.38, Jeffrey Bowers wrote: > > Hi all, > > I'm having trouble getting subversion to work. When I run: > > svn checkout https://svn.FreeBSD.org/ports/head /usr/ports > > It scrolls through many lines of text before stating: svn: E000060: > Operation timed out > > When I run: > > svn checkout svn+ssh://repo.freebsd.org/ports/head /usr/ports > > It tells me that the authenticity of the host cannot be identified, and > asks me to confirm that I want to connect. I say yes, and then it says: > > svn: E170013: Unable to connect to a repository at URL 'svn+ssh:// > repo.freebsd.org/ports/head' > svn: E210002: To better debug SSH connection problems, remove the -q opti= on > from 'ssh' in the [tunnels] section of your Subversion configuration file= . > > Any ideas? > > Thanks in advance! > > On Mon, Aug 19, 2019 at 8:51 PM Jeffrey Bowers > wrote: > > I didn't think it remounting. Thank you! > > On Mon, Aug 19, 2019 at 11:39 AM S=C3=B8ren Schmidt > wrote: > > Hi Jeffrey > > You need to unmount the /tmp filesystem :) > You can do that permanently by commenting it out in /etc/fstab > > > On 19 Aug 2019, at 21.45, Jeffrey Bowers wrote: > > Hi Soren, > > I'm getting the same error message. Any other ideas what it might be? > It's got to be something in the partition scheme or the file permissions, > but I'm just not sure what. > > > On Sun, Aug 18, 2019 at 10:03 AM Jeffrey Bowers > wrote: > > D=E2=80=99Oh! I thought I too care of that with gpart. I literally missed= growfs > part of the instructions.. > > On Sun, Aug 18, 2019 at 10:00 AM S=C3=B8ren Schmidt > wrote: > > Hi > > You are out of space :) > > Boot the board into singleuser mode, and do =E2=80=9Cservice growfs start= =E2=80=9D, > that will expand you / filesystem to the entire SD card=E2=80=A6 > > -S=C3=B8ren > > On 18 Aug 2019, at 14.50, Jeffrey Bowers wrote: > > Sure thing! Here's the screenshot! > > > > On Sun, Aug 18, 2019 at 7:35 AM S=C3=B8ren Schmidt > wrote: > > Hi > > Can I have you paste the output from df -h ? > > You should be able to utilise the full SD card=E2=80=A6 > > -S=C3=B8ren > > On 18 Aug 2019, at 14.29, Jeffrey Bowers wrote: > > Hi, > > Just make sure I understand the process, I should hook up a hard disk > and map it to to /TMP ? > > I already tried just unmapping /tmp, and it gave me the same error > once, and then the next time I ran it I got an error saying /usr/ports wa= s > out of space )which I guess I shouldn=E2=80=99t mount to another director= on the > hard drive? > > On Sun, Aug 18, 2019 at 5:11 AM S=C3=B8ren Schmidt > wrote: > > Hi Jeffrey > > You can unmount the memory disk on /tmp to get at the space on the SD > card. > > It is however not recommend to use the AD card for random storage, it > will wear out fast, that=E2=80=99s why the memory disk is setup. > > You could connect a SSD og laptop disk to the SATA interface and use > that for the workload. > > However compiling is slow, its much much faster to cross compile on a > PC=E2=80=A6 > > -S=C3=B8ren > > On 18 Aug 2019, at 00.22, Jeffrey Bowers wrote: > > Hi! I've got a new one :) > I'm trying to do an svn checkout to fix the pkg problem, but it tells > me it can't write to a to a temp folder because there is no room left on > the device. However, FreeBSD partition is 29GB. It's never also never the > same file in TMP that it can't write to. Here is a screenshot of the issu= e, > along with the output of gpart: > > > > Any ideas? > > Thanks! > > > On Sat, Aug 17, 2019 at 2:08 PM Emmanuel Vadot > wrote: > > On Sat, 17 Aug 2019 17:14:36 +0200 > S=C3=B8ren Schmidt wrote: > > HI > > Well, I have a whole forrest of tree?s here, but the error posted > > here was on a clean checkout. > > > Anyhow, with the latest changes to -stable and the two > > RF_SHAREABLE patches from -current all works. > > I've reverted the commits, see > https://github.com/evadot/freebsd/commits/a37x0_gpio for a better > way > to deal with this issue. > I'm waiting for mmel@ as he wrote the syscon_get_default_handle > part. > > It would be nice with the etherswitch changes as well so VLAN > > tagging etc was standard. > > > -S=C3=B8ren > > PS: given up on bottom & inline popsting, top posting is all the > > rage now (yeah I miss elm etc :) ) > > > On 17 Aug 2019, at 15.30, Emmanuel Vadot > > wrote: > > > On Sat, 17 Aug 2019 11:07:22 +0200 > S=C3=B8ren Schmidt > soren.schmidt@gmail.com>> wrote: > > > Hi Emmunuel > > Yes the 3720 gpio driver I already back ported long ago, its > > needed, I?m happy its now part of std stable 12! > > > Would have been nice of you to say that you were not running a > > clean > > tree. > > My issue seems to be the inclusion of the phy_usb driver, if I > > leave that out, I?m back to normal.. > > > What make you think this is this driver ? What works/doesn't work > with it ? could you provide logs. > > I?ll have have another go at the latest -stable sources during > > the weekend and see how it goes. > > > Thanks for looking into this, with a little cooperation we?ll > > get this solved for the greater good.. > > > -S=C3=B8ren > > > P.S. Please stop top posting, it's really hard to read the > > conversation > > > On 16 Aug 2019, at 22.58, Emmanuel Vadot < > > manu@bidouilliste.com> wrote: > > > On Fri, 16 Aug 2019 19:12:30 +0200 > Emmanuel Vadot > manu@bidouilliste.com>> wrote: > > > On Fri, 16 Aug 2019 17:10:37 +0200 > Emmanuel Vadot wrote: > > On Fri, 16 Aug 2019 15:24:54 +0200 > Emmanuel Vadot wrote: > > On Fri, 16 Aug 2019 07:28:59 +0200 > S=C3=B8ren Schmidt wrote: > > Hi > > Very simple, reverting sys/gnu/dts to what was before > > 350595 (actually 350592). > > Thats what we have svn for ? > > > If I asked how it was to have the svn command that you > > used, I want to > > make sure that you didn't revert anything else, like do you > > have > > r350596 and r350628 ? > > That does make my bananapi work again, no other changes > > just a recompiled kernel. > > > That + copying the dtb to the fat32 partition ? > > Can you post the dtb somewhere. > > However it does not bring the Espressobin back to life, > > thats something in one of the ~30 other files that changed between those > two revisions. > > > What Linux version of DTS are you using then ? The ones > > that were in > > stable/12 when it was branched (4.18) or a later revision ? > > > So I think that I've found the problem on the Espressobin. > I think that the problem comes from the simple-mfd driver > > that I've > > mfc in r350600. > The pinctrl/gpio controller compatible is > "marvell,armada3710-nb-pinctrl", "syscon", "simple-mfd" and > > it attaches > > at BUS_PASS_INTERRUPT while the simple_mfd driver attaches at > BUS_PASS_BUS (so earlier) which means that no gpio > > controller will be > > available for sdhci to detect the card. > > If someone with a non-working espressobin could post a full > > verbose > > boot log that would help me confirming that this is the case. > I'll try to find a solution on how to solve this problem. > > > So this wasn't the problem but I've found it, see r351129 and > > r351130 > > > SD card now work again in HEAD, I'll have a look at stable > > later next > > week. > > > I've did a quick test and I've MFC r348880, r348882 and > > r349596, the > > two other commits needed to be mfc'ed are the one I did today > > on head, > > I'll do that next week. > With them sdcard is working again on stable/12 > > -S=C3=B8ren > > On 15 Aug 2019, at 23.37, Emmanuel Vadot < > > manu@bidouilliste.com> wrote: > > > On Thu, 15 Aug 2019 21:56:23 +0200 > S=C3=B8ren Schmidt wrote: > > > Well, I don?t care where you are from and what color you > > have :) > > > Now, if I update my stable12 sources to r350595 the > > bananapi breaks, if revert sys/gnu/dts it works again, go figure.. > > > Reverting to what ? and how ? > > Because I've just test 12-stable and I have the problem > > that I've said > > in my previous mail so setting > > hw.regulator.disable_unused=3D0 is the > > work around. > The problem is in twsi not in the DTS so I'm curious how > > reverting > > only the dts fixes this problem. > > The r351099 fix is already like that in -stable, and not > > part of the problem. > > > -S=C3=B8ren > > > On 15 Aug 2019, at 21.03, Emmanuel Vadot < > > manu@bidouilliste.com> wrote: > > > On Thu, 15 Aug 2019 19:48:54 +0200 > S=C3=B8ren Schmidt wrote: > > Hi Mit! > > Right, I suspected that, 12-stable broke many embedded > > systems between r350592 and r350595 where all the latest and greatest DTS > files was pulled in, I guess the same holds for -current. > > > -S=C3=B8ren > > > Mhm it's fun that you think that DTS import is the > > source of all your > > problems, I get it, it's easy to blame the French guy > > that bulk import > > the DTS, he surely don't know what he is doing. > Anyway, two problems were raised in this thread : > > 1) BananaPi (A20) doesn't boot > 2) Espressobin sd support is broken > > I've just looked at the BananaPi problem today, I've > > fixed a first > > problem in r351099. > The main problem is that when we disable the unused > > regulators we hang > > when trying to disabling ldo3. It's weird because the > > board doesn't use > > LDO3 (which is why we are disabling it, it's unused). > > The problem is in > > twsi I think as only leaving the part in axp209 that > > read the > > voltage register value make FreeBSD hang. > I'll have a proper look later, in the meantime you can > > set > > hw.regulator.disable_unused=3D0 > in /boot/loader.conf > This isn't a DTS problem. > > For Espressobin I haven't found any thing related to SD > > in the DTS > > updates since the import, the only things slighly > > related are mmc and > > sdio. > So if someone could find which DTS import broke this I > > can have a look. > > > > On 15 Aug 2019, at 19.37, Mit Matelske > > wrote: > > > Yeah, that was the problem. I went back to r348882 > > and everything worked out of the box. > > > Thanks again for the hand holding! > > Mit > > From: "S=C3=B8ren Schmidt" > > > > To: "Mit Matelske" > > Cc: "Marcin Wojtas" > mw@semihalf.com>>, "freebsd-arm" freebsd-arm@freebsd.org>> > > Sent: Wednesday, August 14, 2019 1:33:04 PM > Subject: Re: Espressobin anyone ? > > > It might simply be broken in -current (again). > > I just updated my stable12 tree and I pulled in new > > .dts files for just about anything? > > > Needless to say, it broke the Espressobin?s SD > > support, it now fails just like yours.. > > > It also broke allwinner builds and what not, so I?m > > just going back in time again :) > > > I wonder why there is this overwhelming need to > > import stuff that breaks things right, left and center in a -stable branc= h > ? > > That would have earned you the pointy hat back when?. > > -S=C3=B8ren > > > On 14 Aug 2019, at 18.01, Mit Matelske > > wrote: > > > Marcin- > > Sorry I didn't reply yesterday. I didn't have any > > luck with that either. I tried a lot of permutations. > > > Not saying for 100% it doesn't work, but I couldn't > > get it to work! > > > Mit > > From: "Marcin Wojtas" > mw@semihalf.com>> > > To: "Mit Matelske" > > Cc: "S=C3=B8ren Schmidt" > soren.schmidt@gmail.com>>, "freebsd-arm" > > > Sent: Wednesday, August 14, 2019 10:41:04 AM > Subject: Re: Espressobin anyone ? > > Hi Mit, > Since you are using the latest 13-current, could you > > please try if passing rootdev via u-boot bootargs (please see my previous > email) works for you without the loader modification? > > > Best regards, > Marcin > > ?r., 14 sie 2019 o 16:29 Mit Matelske > > napisa?(a): > > Soren- > > Thanks for the info. I'll grab a couple more SD > > cards at lunch. This one is a new Samsung 32GB. I'll also try putting t= he > changes into 12 and see if that helps. I'm using the latest 13-current. > > > Again, appreciate the hand holding! > > Mit > > From: "S=C3=B8ren Schmidt" > > > > To: "Mit Matelske" > > Cc: "Marcin Wojtas" > mw@semihalf.com>>, "freebsd-arm" freebsd-arm@freebsd.org>> > > Sent: Wednesday, August 14, 2019 2:30:31 AM > Subject: Re: Espressobin anyone ? > > Hi Mit > Hmm, from your earlier posted dmesgs it looks like > > the SD card is not getting detected properly.. > > > I get this output: > > sdhci_xenon0: mem > > 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 > > mmc0: on sdhci_xenon0 > ?snip? > mmcsd0: 16GB > by 39 PH> at mmc0 50.0MHz/4bit/65535-block > > > The problem you see was fixed for me by r348882, > > maybe it got broken later, I havn?t backported the later changes.. > > > Have you tried another SD card ? I have found 2 of > > mine that the espressobin doesn?t like, but works fine with bananapi and > friends... > > > -S=C3=B8ren > > On 13 Aug 2019, at 23.30, Mit Matelske > > wrote: > > > Soren- > > Thanks for the code snippet! That will fix one of > > the problems. > > > I still can't mount my filesystem, though. I think > > I'm doing something really simple, wrong. I believe I'm running the late= st > code and added some printfs to show the kernel setting the regulator: > > > > usbus1 on ehci0 > syscon_generic4: mem 0x5f800-0x5ffff on > > simplebus1 > > sdhci_xenon0: > > regulator_get_by_ofw_property(vqmmc-supply) =3D 19 > > sdhci_xenon0: vqmmc-supply regulator found > sdhci_xenon0: mem > > 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 > > ahci0: mem 0xe0000-0xe0177 irq > > 26 on simplebus1 > > > > Could there be a problem with how I am setting up my > > filesystem? I've tried both freebsd-ufs and freebsd as the type, with no > luck. A gpart listing of my SD card: > > > root@fbl:~ # gpart list da3 > Geom name: da3 > modified: false > state: OK > fwheads: 255 > fwsectors: 63 > last: 62521335 > first: 3 > entries: 4 > scheme: GPT > Providers: > 1. Name: da3p1 > Mediasize: 41943040 (40M) > Sectorsize: 512 > Stripesize: 0 > Stripeoffset: 1536 > Mode: r0w0e0 > efimedia: > > HD(1,GPT,19894dc5-b8b2-11e9-871f-08008a0010e0,0x3,0x14000) > > rawuuid: 19894dc5-b8b2-11e9-871f-08008a0010e0 > rawtype: c12a7328-f81f-11d2-ba4b-00a0c93ec93b > label: (null) > length: 41943040 > offset: 1536 > type: efi > index: 1 > end: 81922 > start: 3 > 2. Name: da3p2 > Mediasize: 31968979456 (30G) > Sectorsize: 512 > Stripesize: 0 > Stripeoffset: 41944576 > Mode: r0w0e0 > efimedia: > > HD(2,GPT,98786462-be30-11e9-ae6e-08008a0010e0,0x14003,0x3b8bff5) > > rawuuid: 98786462-be30-11e9-ae6e-08008a0010e0 > rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b > label: (null) > length: 31968979456 > offset: 41944576 > type: freebsd-ufs > index: 2 > end: 62521335 > start: 81923 > Consumers: > 1. Name: da3 > Mediasize: 32010928128 (30G) > Sectorsize: 512 > Mode: r0w0e0 > > Thanks!! > > Mit > > From: "S=C3=B8ren Schmidt" > > > > To: "Marcin Wojtas" > mw@semihalf.com>> > > Cc: "Mit Matelske" >, > > "freebsd-arm" freebsd-arm@freebsd.org>> > > Sent: Tuesday, August 13, 2019 12:55:09 PM > Subject: Re: Espressobin anyone ? > > Hi > That doesn?t seen to work on the espressobin, or > > least I can?t get it to pick it up. > > > I use this patch as a workaround: > > Index: main.c > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --- main.c (revision 350496) > +++ main.c (working copy) > @@ -463,6 +462,13 @@ > int rv; > char *rootdev; > > +#if defined(__aarch64__) > + /* SOS HACK in rootdev, at least Espressobin > > gets this wrong */ > > + printf("Setting currdev hack\n"); > + set_currdev("disk0p2"); > + return (0); > +#endif > + > /* > * First choice: if rootdev is already set, use > > that, even if > > * it's wrong. > > Its not pretty but it does the job until I get time > > to look into why bootargs aren?t passed / won?t stick, probably something= I > havn?t backported to my -stable12 sources yet... > > > -S=C3=B8ren > > On 13 Aug 2019, at 01.38, Marcin Wojtas < > > mw@semihalf.com > wrote: > > > Hi, > > Not sure if it's what you are looking for, but in > > order to autoboot, I > > simply pass 'rootdev=3DdiskXpY' in the bootargs > > variable. Here's example from > > A3720-DB (same should work on EspressoBin): > > Marvell>> set bootargs "rootdev=3Ddisk1p1";usb reset; > > fatload usb 0:1 > > ${fdt_addr} armada-3720-db.dtb; fatload usb 0:1 > > ${kernel_addr} > > boot/loader.efi; bootefi ${kernel_addr} ${fdt_addr} > resetting USB... > USB0: Register 2000104 NbrPorts 2 > Starting the controller > USB XHCI 1.00 > USB1: USB EHCI 1.00 > - ______ ____ _____ _____ > | ____| | _ \ / ____| __ \ > | |___ _ __ ___ ___ | |_) | (___ | | | | > | ___| '__/ _ \/ _ \| _ < \___ \| | | | > | | | | | __/ __/| |_) |____) | |__| | > | | | | | | || | | | > |_| |_| \___|\___||____/|_____/|_____/ > ``` > ` > ????????????Welcome to FreeBSD????????????? s` > > `.....---.......--.``` > > -/ > ? ? +o > > .--` /y:` > > +. > ? 1. Boot Multi user [Enter] ? > > yo`:. :o > > `+- > ? 2. Boot Single user ? y/ > > -/` -o/ > > ? 3. Escape to loader prompt ? .- > ::/sy+:. > ? 4. Reboot ? / > > `-- > > / > ? ? `: > :` > ? Options: ? `: > :` > ? 5. Kernel: default/kernel (1 of 1) ? / > / > ? 6. Boot Options ? .- > -. > ? ? -- > > -. > > ? ? > > `:` `:` > > ? ? > > .-- `--. > > ??????????????????????????????????????????? > > .---.....----. > > Autoboot in 9 seconds, hit [Enter] to boot or any > > other key to stop > > > Loading kernel... > /boot/kernel/kernel text=3D0x95047c > > data=3D0x1919d0+0x84aa94 > > syms=3D[0x8+0x13aaa8+0x8+0x12610d] > Loading configured modules... > can't find '/boot/entropy' > Using DTB provided by EFI at 0x8000000. > ---<>--- > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2019 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, > > 1991, 1992, 1993, 1994 > > The Regents of the University of California. All > > rights reserved. > > FreeBSD is a registered trademark of The FreeBSD > > Foundation. > > FreeBSD 13.0-CURRENT > > 17a1fc80d57-c261519(upstream_master) GENERIC arm64 > > FreeBSD clang version 8.0.0 (tags/RELEASE_800/final > > 356365) (based on LLVM > > 8.0.0) > WARNING: WITNESS option enabled, expect reduced > > performance. > > VT: init without driver. > Starting CPU 1 (1) > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > [...] > > Best regards, > Marcin > > pon., 12 sie 2019 o 23:14 Mit Matelske > > napisa?(a): > > > > Soren- > > Thanks for the quick response. I built this kernel > > with revision 350924. > > I'll dig into whats going on in the morning. > > Mind posting your diff for your loader.efi? > > Thanks again! > > Mit > > > ----- Original Message ----- > From: "S=C3=B8ren Schmidt" > > > > To: "Mit Matelske" > > Cc: "tscho" > johannes@t-beutel.com>>, "freebsd-arm" < > > freebsd-arm@freebsd.org > freebsd-arm@freebsd.org>> > > Sent: Monday, August 12, 2019 3:49:48 PM > Subject: Re: Espressobin anyone ? > > Hi > > Looks like your sources may be too old, you need to > > be at least at r348882 > > to get the fix for the SD card VCC regulator. > > That change fixed it for me backported to 12-stable... > > The currdev problem still exists, I have it hardwired > > in my loader for > > aarch64 :) > > -S=C3=B8ren > > > On 12 Aug 2019, at 21.06, Mit Matelske > > wrote: > > > I'm having a couple little hiccups booting this board > > also. One has > > been commented on already, that I can't get the > > loader to automatically > > start loading the kernel on "disk0p2"... > > The second, is that the kernel can't find the SD card > > after booting so > > it can't mount the root filesystem. I'm using the > > dts/dtb and kernel from > > the 13-current branch. > > Thanks for any and all help. I haven't used u-boot > > in about decade. > > Spoiled by the x86 platform. > > Mit Matelske > > > ***U-boot environment:*** > > > Marvell>> printenv > baudrate=3D115200 > bootargs=3Dconsole=3DttyMV0,115200 > > earlycon=3Dar3700_uart,0xd0012000 > > root=3D/dev/mmcblk0p1 rw rootwait net.ifnames=3D0 > > biosdevname=3D0 > > bootcmd=3Dmmc dev 0; fatload mmc 0:1 $kernel_addr > > $image_name;fatload mmc > > 0:1 $fdt_addr $fdt_name; bootefi $kernel_addr > > $fdt_addr > > bootdelay=3D2 > bootmmc=3Dmmc dev 0; fatload mmc 0:1 $kernel_addr > > $image_name;fatload mmc > > 0:1 $fdt_addr $fdt_name; bootefi $kernel_addr > > $fdt_addr > > console=3Dconsole=3DttyMV0,115200 > > earlycon=3Dar3700_uart,0xd0012000 > > eth1addr=3D00:51:82:11:22:01 > eth2addr=3D00:51:82:11:22:02 > eth3addr=3D00:51:82:11:22:03 > ethact=3Dneta@30000 > ethaddr=3DF0:AD:4E:09:6B:8F > ethprime=3Deth0 > fdt_addr=3D0x4f00000 > fdt_high=3D0xffffffffffffffff > fdt_name=3Defi/boot/armada-3720-espressobin.dtb > fdtcontroladdr=3D3f7161b8 > gatewayip=3D10.4.50.254 > get_images=3Dtftpboot $kernel_addr $image_name; > > tftpboot $fdt_addr > > $fdt_name; run get_ramfs > get_ramfs=3Dif test "${ramfs_name}" !=3D "-"; then setenv > > ramfs_addr > > 0x8000000; tftpboot $ramfs_addr $ramfs_name; else > > setenv ramfs_addr -;fi > > hostname=3Dmarvell > image_name=3Defi/freebsd/loader.efi > initrd_addr=3D0xa00000 > initrd_size=3D0x2000000 > ipaddr=3D0.0.0.0 > kernel_addr=3D0x5000000 > loadaddr=3D0x5000000 > netdev=3Deth0 > netmask=3D255.255.255.0 > ramfs_addr=3D0x8000000 > ramfs_name=3D- > root=3Droot=3D/dev/nfs rw > rootpath=3D/srv/nfs/ > serverip=3D0.0.0.0 > set_bootargs=3Dsetenv bootargs $console $root > > ip=3D$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:none > > nfsroot=3D$serverip:$rootpath $extra_params > stderr=3Dserial@12000 > stdin=3Dserial@12000 > stdout=3Dserial@12000 > > > ***Full boot logs:*** > > > U-Boot 2017.03-armada-17.10.2-g14aeedc (Jun 01 2018 - > > 15:39:10 +0800) > > > Model: Marvell Armada 3720 Community Board ESPRESSOBin > CPU @ 1000 [MHz] > L2 @ 800 [MHz] > TClock @ 200 [MHz] > DDR @ 800 [MHz] > DRAM: 1 GiB > U-Boot DT blob at : 000000003f7161b8 > Comphy-0: USB3 5 Gbps > Comphy-1: PEX0 2.5 Gbps > Comphy-2: SATA0 6 Gbps > SATA link 0 timeout. > AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA > > mode > > flags: ncq led only pmp fbss pio slum part sxs > PCIE-0: Link down > MMC: sdhci@d0000: 0, sdhci@d8000: 1 > SF: Detected mx25u3235f with page size 256 Bytes, > > erase size 64 KiB, > > total 4 MiB > Net: eth0: neta@30000 [PRIME] > Hit any key to stop autoboot: 0 > switch to partitions #0, OK > mmc0 is current device > reading efi/freebsd/loader.efi > 603872 bytes read in 49 ms (11.8 MiB/s) > reading efi/boot/armada-3720-espressobin.dtb > 15946 bytes read in 17 ms (916 KiB/s) > ## Starting EFI application at 05000000 ... > Scanning disk sdhci@d0000.blk > ... > > Card did not respond to voltage select! > mmc_init: -95, time 50 > Found 1 disks > Consoles: EFI console > FreeBSD/arm64 EFI loader, Revision 1.1 > > Command line arguments: loader.efi > EFI version: 2.05 > EFI Firmware: Das U-boot (rev 0.00) > Console: efi (0) > Failed to find bootable partition > Startup error in /boot/lua/loader.lua: seconds > LUA ERROR: cannot open /boot/lua/loader.lua: invalid > > argument. > > > can't load 'kernel' > > Type '?' for a list of commands, 'help' for more > > detailed help. > > OK > OK set currdev=3Ddisk0p2 > OK boot > > /boot/kernel/kernel text=3D0x97d6a0 > > data=3D0x191b50+0x84ae94 > > syms=3D[0x8+0x137dd8+0x8+0x126260] > Using DTB provided by EFI at 0x8000000. > ---<>--- > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2019 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, > > 1991, 1992, 1993, 1994 > > The Regents of the University of California. All > > rights reserved. > > FreeBSD is a registered trademark of The FreeBSD > > Foundation. > > FreeBSD 13.0-CURRENT GENERIC arm64 > FreeBSD clang version 6.0.1 (tags/RELEASE_601/final > > 335540) (based on > > LLVM 6.0.1) > WARNING: WITNESS option enabled, expect reduced > > performance. > > VT: init without driver. > Starting CPU 1 (1) > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > arc4random: WARNING: initial seeding bypassed the > > cryptographic random > > device because it was not yet seeded and the knob > > 'bypass_before_seeding' > > was enabled. > random: entropy device external interface > MAP 3e681000 mode 2 pages 1 > MAP 3ffa6000 mode 2 pages 1 > kbd0 at kbdmux0 > ofwbus0: > simplebus0: on > > ofwbus0 > > simplebus1: on > > simplebus0 > > simple_mfd0: mem > 0x13800-0x138ff,0x13c00-0x13c1f on simplebus1 > simple_mfd1: mem > 0x18800-0x188ff,0x18c00-0x18c1f on simplebus1 > psci0: > Driver> on ofwbus0 > > gic0: mem > > > 0x1d00000-0x1d0ffff,0x1d40000-0x1d7ffff,0x1d80000-0x1d81fff,0x1d90000-0x1= d91fff,0x1da0000-0x1dbffff > > irq 27 on simplebus1 > gpio0: 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: 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: on ofwbus0 > gpioregulator0: cannot get pin 0 > gpioregulator0: cannot parse parameters > device_attach: gpioregulator0 attach returned 6 > generic_timer0: irq 0,1,2,3 on > > ofwbus0 > > Timecounter "ARM MPCore Timecounter" frequency > > 12500000 Hz quality 1000 > > Event timer "ARM MPCore Eventtimer" frequency > > 12500000 Hz quality 1000 > > gpio0: 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: 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: on ofwbus0 > gpioregulator0: cannot get pin 0 > gpioregulator0: cannot parse parameters > device_attach: gpioregulator0 attach returned 6 > gpio0: 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: 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: on ofwbus0 > gpioregulator0: cannot get pin 0 > gpioregulator0: cannot parse parameters > device_attach: gpioregulator0 attach returned 6 > gpio0: 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: 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: on ofwbus0 > gpioregulator0: cannot get pin 0 > gpioregulator0: cannot parse parameters > device_attach: gpioregulator0 attach returned 6 > gpio0: 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: 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: on ofwbus0 > gpioregulator0: cannot get pin 0 > gpioregulator0: cannot parse parameters > device_attach: gpioregulator0 attach returned 6 > cpulist0: on ofwbus0 > cpu0: on cpulist0 > cpu1: on cpulist0 > pmu0: irq 4 on ofwbus0 > syscon_generic0: mem 0xd000-0xdfff on > > simplebus1 > > syscon_generic1: mem 0x11500-0x1153f on > > simplebus1 > > uart0: mem 0x12000-0x121ff > > irq 9,10,11 on > > simplebus1 > uart0: console (115200,n,8,1) > gpio0: 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: mem 0x14000-0x1405f on > > simplebus1 > > gpio0: 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: mem 0x30000-0x33fff irq 14 > > on simplebus1 > > mvneta0: version is 10 > mvneta0: Ethernet address: 00:a6:39:ca:e8:00 > mdio0: on mvneta0 > mdioproxy0: on mdio0 > e6000sw0: on mdio0 > e6000sw0: multi-chip addressing mode (0x1) > e6000sw0: CPU port at 0 > e6000sw0: fixed port at 0 > e6000sw0: PHY at port 1 > miibus0: on e6000sw0 > e1000phy0: 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: on e6000sw0 > e1000phy1: 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: on e6000sw0 > e1000phy2: 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: on e6000sw0 > xhci0: mem > > 0x58000-0x5bfff irq 16 on > > simplebus1 > xhci0: 32 bytes context size, 32-bit DMA > usbus0 on xhci0 > syscon_generic3: mem 0x5d800-0x5dfff on > > simplebus1 > > ehci0: mem > > 0x5e000-0x5efff irq > > 17 on simplebus1 > usbus1: EHCI version 1.0 > usbus1 on ehci0 > syscon_generic4: mem 0x5f800-0x5ffff on > > simplebus1 > > sdhci_xenon0: mem > 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 > ahci0: mem 0xe0000-0xe0177 irq > > 26 on simplebus1 > > ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier > > supported with FBS > > ahcich0: at channel 0 on ahci0 > device_attach: ahcich0 attach returned 6 > gpioregulator0: on ofwbus0 > gpioregulator0: cannot get pin 0 > gpioregulator0: cannot parse parameters > device_attach: gpioregulator0 attach returned 6 > cryptosoft0: > 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 > > > > 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 > > usbus1 Processor Features 1 =3D <0> > usbus0 Memory Model Features 0 =3D <4k Granule,64k > > Granule,S/NS > > Mem,MixedEndian,16bit ASID,1TB PA> > > Memory Model Features 1 =3D <> > Memory Model Features 2 =3D <32b CCIDX,48b VA> > Debug Features 0 =3D <2 CTX Breakpoints,4 > > Watchpoints,6 > > Breakpoints,PMUv3,Debug v8> > Debug Features 1 =3D <0> > Auxiliary Features 0 =3D <0> > Auxiliary Features 1 =3D <0> > CPU 1: ARM Cortex-A53 r0p4 affinity: 1 > WARNING: WITNESS option enabled, expect reduced > > performance. > > ugen0.1: at usbus0 > ugen1.1: at usbus1 > uhub0 on usbus0 > uhub1 on usbus1 > uhub0: > 3.00/1.00, addr 1> on > > usbus0 > uhub1: > 2.00/1.00, addr 1> on > > usbus1 > uhub0: 2 ports with 2 removable, self powered > uhub1: 1 port with 1 removable, self powered > mountroot: waiting for device > > /dev/ufs/FreeBSD_Install... > > Mounting from ufs:/dev/ufs/FreeBSD_Install failed > > with error 19. > > > Loader variables: > vfs.root.mountfrom=3Dufs:/dev/ufs/FreeBSD_Install > vfs.root.mountfrom.options=3Dro,noatime > > Manual root filesystem specification: > : [options] > Mount using filesystem > and with the specified (optional) option list. > > eg. ufs:/dev/da0s1a > zfs:zroot/ROOT/default > cd9660:/dev/cd0 ro > (which is equivalent to: mount -t cd9660 -o ro > > /dev/cd0 /) > > > ? List valid disk boot devices > . Yield 1 second (for background tasks) > Abort manual input > > mountroot> ? > > List of GEOM managed disk devices: > > > mountroot> > _______________________________________________ > freebsd-arm@freebsd.org > 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 freebsd-arm-unsubscribe@freebsd.org>" > > > _______________________________________________ > freebsd-arm@freebsd.org > 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 freebsd-arm-unsubscribe@freebsd.org>" > > > > > -- > Emmanuel Vadot < > > manu@freebsd.org> > > > > > -- > Emmanuel Vadot > > > > -- > Emmanuel Vadot > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to " > > freebsd-arm-unsubscribe@freebsd.org" > > > > -- > Emmanuel Vadot > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to " > > freebsd-arm-unsubscribe@freebsd.org" > > > > -- > Emmanuel Vadot > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to " > > freebsd-arm-unsubscribe@freebsd.org" > > > > -- > Emmanuel Vadot > manu@bidouilliste.com>> > > > > > > -- > Emmanuel Vadot > manu@bidouilliste.com>> > > > > > > -- > Emmanuel Vadot > _______________________________________________ > 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" > > > From owner-freebsd-arm@freebsd.org Tue Aug 20 12:37:15 2019 Return-Path: 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 9A75FD13DB for ; Tue, 20 Aug 2019 12:37:15 +0000 (UTC) (envelope-from khantroll@gmail.com) Received: from mail-oi1-x243.google.com (mail-oi1-x243.google.com [IPv6:2607:f8b0:4864:20::243]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46CVfy3p7dz4JsM for ; Tue, 20 Aug 2019 12:37:14 +0000 (UTC) (envelope-from khantroll@gmail.com) Received: by mail-oi1-x243.google.com with SMTP id a127so3928766oii.2 for ; Tue, 20 Aug 2019 05:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=gqqcwWq9dilUUfGbQJbmT5p53HvnYBo7y5dX+VjaGHg=; b=HA6r9rMXpPke5gxJOR9vXdS8JBERqcPV0kVc8dvJ2YcF//KWVSvKJtYDSvOFnBBgS5 G0kKUmFOdpQIF2Vg83J63tbafNj/yJP9PjlTrLCdGNvWnGTagWifdo1NXVo9OfVKwNlu menYf6izz7zyCcgMYBAOoFJE9/OXGwD8Uu0EHP0O7mT/ciFG3NsAilIhkGt2lJmwWNI1 Ca1mFV/+pi9LHFRvaeyHEHm2KvYaXAEgx8LMGpiGg9zewCg6UQc40tG4fFAbfCFz2aZe MqdUYccVTn2/BUltuibDSHBY8JEByNZDyOG6Etcud5PmR3cTrMQ9MWx7hU7OnRyZkuDt pezA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=gqqcwWq9dilUUfGbQJbmT5p53HvnYBo7y5dX+VjaGHg=; b=ARBAjwwJU7baqdvFQ1gjZNohJiiV5YP58z/FMmM9jde0YTNCvQ49BpkzFTAA/b/D8a oa/L1lvGlPGetZTVfnRsup6y9olAyyjpqxNc5cuUGSEJygn1Qejns7arNys/zclGDnBN nZGcoSukgHe4jkbqq7trENoAyQBTTf4biLp02+MYpJ65RJOgGemHrwidy/33Jes9EOgZ LcEUoGJpAxR4YmHBXS+b6YQVZdHcPVn3wZTdaVh8rPmF/eb9herQDQkQJl9QXqIx3bXb sncLODp1scnOxUCijq14MDqoVzD8H0ptgG110654anN9QcG6DxeoOMIKgNfd66+OjWxq U0CA== X-Gm-Message-State: APjAAAUu4dxLvJOx+w3RvJCkeILaJHFdPjJY3ilV/QneUDC7iSeNEWQl nw/0pzb1o449zAJwmCizC0aUedCNnM4kKKofvzPld1uGmx0= X-Google-Smtp-Source: APXvYqzldsnBKKJ6eXy8XnLbju6QNNGltz+V932YTg+jO0rSvMW1LzHGLqrsM2cW6H1EI8bAvtaDpmBoGucoURi+lrA= X-Received: by 2002:a05:6808:5cf:: with SMTP id d15mr1025641oij.140.1566304632905; Tue, 20 Aug 2019 05:37:12 -0700 (PDT) MIME-Version: 1.0 References: <1547777156.662147.1565798461515.JavaMail.zimbra@perftech.com> <0E42E605-477E-4E65-810E-BD3A8CDE2C80@gmail.com> <973015183.1067498.1565890674099.JavaMail.zimbra@perftech.com> <20190815210311.1035f64b003e2bc85fa47ca8@bidouilliste.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> <20190817153053.5592b15b8a42982fda0fc123@bidouilliste.com> <9749945A-FDAD-47E0-947A-FA62138C2F83@gmail.com> <20190817210822.8920656bad0855b554883cf2@bidouilliste.com> <2D6D4BDA-75EC-403F-B5E2-52A468369DE2@gmail.com> <627099DD-804B-412F-A083-768CEFCF955C@gmail.com> <6DA8E736-8031-4BF7-8B20-CF8B0E8A7FEF@gmail.com> In-Reply-To: From: Jeffrey Bowers Date: Tue, 20 Aug 2019 07:36:58 -0500 Message-ID: Subject: Re: Espressobin anyone ? To: =?UTF-8?Q?S=C3=B8ren_Schmidt?= , freebsd-arm X-Rspamd-Queue-Id: 46CVfy3p7dz4JsM X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=HA6r9rMX; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of khantroll@gmail.com designates 2607:f8b0:4864:20::243 as permitted sender) smtp.mailfrom=khantroll@gmail.com X-Spamd-Result: default: False [-2.99 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.99)[-0.993,0]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (1.91), ipnet: 2607:f8b0::/32(-2.93), asn: 15169(-2.37), country: US(-0.05)]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.46.224,0.0.117.48]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[3.4.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 12:37:15 -0000 I just tried to ping https://svn.freebsd.org/ports/head, and even though it scrolsl through all that text I get an error saying "could not resolve https://svn.freebsd.org/ports/head ; unknown server error" . I can ping google just fine. Is it a DNS issue? On Tue, Aug 20, 2019 at 7:33 AM Jeffrey Bowers wrote: > I'm still getting: svn: E000060: Operation timed out > It goes for several minutes scrolling through text, and I feel like using > your link got further. > > Thanks! > > On Tue, Aug 20, 2019 at 2:49 AM S=C3=B8ren Schmidt > wrote: > >> Hmm, I use this URL >> >> Repository Root: https://svn.freebsd.org/ports/head >> >> Not sure the svn+ssh thing works=E2=80=A6 >> >> -S=C3=B8ren >> >> >> On 20 Aug 2019, at 02.38, Jeffrey Bowers wrote: >> >> Hi all, >> >> I'm having trouble getting subversion to work. When I run: >> >> svn checkout https://svn.FreeBSD.org/ports/head /usr/ports >> >> It scrolls through many lines of text before stating: svn: E000060: >> Operation timed out >> >> When I run: >> >> svn checkout svn+ssh://repo.freebsd.org/ports/head /usr/ports >> >> It tells me that the authenticity of the host cannot be identified, and >> asks me to confirm that I want to connect. I say yes, and then it says: >> >> svn: E170013: Unable to connect to a repository at URL 'svn+ssh:// >> repo.freebsd.org/ports/head' >> svn: E210002: To better debug SSH connection problems, remove the -q >> option >> from 'ssh' in the [tunnels] section of your Subversion configuration fil= e. >> >> Any ideas? >> >> Thanks in advance! >> >> On Mon, Aug 19, 2019 at 8:51 PM Jeffrey Bowers >> wrote: >> >> I didn't think it remounting. Thank you! >> >> On Mon, Aug 19, 2019 at 11:39 AM S=C3=B8ren Schmidt >> wrote: >> >> Hi Jeffrey >> >> You need to unmount the /tmp filesystem :) >> You can do that permanently by commenting it out in /etc/fstab >> >> >> On 19 Aug 2019, at 21.45, Jeffrey Bowers wrote: >> >> Hi Soren, >> >> I'm getting the same error message. Any other ideas what it might be? >> It's got to be something in the partition scheme or the file permissions= , >> but I'm just not sure what. >> >> >> On Sun, Aug 18, 2019 at 10:03 AM Jeffrey Bowers >> wrote: >> >> D=E2=80=99Oh! I thought I too care of that with gpart. I literally misse= d growfs >> part of the instructions.. >> >> On Sun, Aug 18, 2019 at 10:00 AM S=C3=B8ren Schmidt >> wrote: >> >> Hi >> >> You are out of space :) >> >> Boot the board into singleuser mode, and do =E2=80=9Cservice growfs star= t=E2=80=9D, >> that will expand you / filesystem to the entire SD card=E2=80=A6 >> >> -S=C3=B8ren >> >> On 18 Aug 2019, at 14.50, Jeffrey Bowers wrote: >> >> Sure thing! Here's the screenshot! >> >> >> >> On Sun, Aug 18, 2019 at 7:35 AM S=C3=B8ren Schmidt >> wrote: >> >> Hi >> >> Can I have you paste the output from df -h ? >> >> You should be able to utilise the full SD card=E2=80=A6 >> >> -S=C3=B8ren >> >> On 18 Aug 2019, at 14.29, Jeffrey Bowers wrote: >> >> Hi, >> >> Just make sure I understand the process, I should hook up a hard disk >> and map it to to /TMP ? >> >> I already tried just unmapping /tmp, and it gave me the same error >> once, and then the next time I ran it I got an error saying /usr/ports w= as >> out of space )which I guess I shouldn=E2=80=99t mount to another directo= r on the >> hard drive? >> >> On Sun, Aug 18, 2019 at 5:11 AM S=C3=B8ren Schmidt >> wrote: >> >> Hi Jeffrey >> >> You can unmount the memory disk on /tmp to get at the space on the SD >> card. >> >> It is however not recommend to use the AD card for random storage, it >> will wear out fast, that=E2=80=99s why the memory disk is setup. >> >> You could connect a SSD og laptop disk to the SATA interface and use >> that for the workload. >> >> However compiling is slow, its much much faster to cross compile on a >> PC=E2=80=A6 >> >> -S=C3=B8ren >> >> On 18 Aug 2019, at 00.22, Jeffrey Bowers wrote: >> >> Hi! I've got a new one :) >> I'm trying to do an svn checkout to fix the pkg problem, but it tells >> me it can't write to a to a temp folder because there is no room left on >> the device. However, FreeBSD partition is 29GB. It's never also never th= e >> same file in TMP that it can't write to. Here is a screenshot of the >> issue, >> along with the output of gpart: >> >> >> >> Any ideas? >> >> Thanks! >> >> >> On Sat, Aug 17, 2019 at 2:08 PM Emmanuel Vadot >> wrote: >> >> On Sat, 17 Aug 2019 17:14:36 +0200 >> S=C3=B8ren Schmidt wrote: >> >> HI >> >> Well, I have a whole forrest of tree?s here, but the error posted >> >> here was on a clean checkout. >> >> >> Anyhow, with the latest changes to -stable and the two >> >> RF_SHAREABLE patches from -current all works. >> >> I've reverted the commits, see >> https://github.com/evadot/freebsd/commits/a37x0_gpio for a better >> way >> to deal with this issue. >> I'm waiting for mmel@ as he wrote the syscon_get_default_handle >> part. >> >> It would be nice with the etherswitch changes as well so VLAN >> >> tagging etc was standard. >> >> >> -S=C3=B8ren >> >> PS: given up on bottom & inline popsting, top posting is all the >> >> rage now (yeah I miss elm etc :) ) >> >> >> On 17 Aug 2019, at 15.30, Emmanuel Vadot >> >> wrote: >> >> >> On Sat, 17 Aug 2019 11:07:22 +0200 >> S=C3=B8ren Schmidt > >> soren.schmidt@gmail.com>> wrote: >> >> >> Hi Emmunuel >> >> Yes the 3720 gpio driver I already back ported long ago, its >> >> needed, I?m happy its now part of std stable 12! >> >> >> Would have been nice of you to say that you were not running a >> >> clean >> >> tree. >> >> My issue seems to be the inclusion of the phy_usb driver, if I >> >> leave that out, I?m back to normal.. >> >> >> What make you think this is this driver ? What works/doesn't work >> with it ? could you provide logs. >> >> I?ll have have another go at the latest -stable sources during >> >> the weekend and see how it goes. >> >> >> Thanks for looking into this, with a little cooperation we?ll >> >> get this solved for the greater good.. >> >> >> -S=C3=B8ren >> >> >> P.S. Please stop top posting, it's really hard to read the >> >> conversation >> >> >> On 16 Aug 2019, at 22.58, Emmanuel Vadot < >> >> manu@bidouilliste.com> wrote: >> >> >> On Fri, 16 Aug 2019 19:12:30 +0200 >> Emmanuel Vadot > >> manu@bidouilliste.com>> wrote: >> >> >> On Fri, 16 Aug 2019 17:10:37 +0200 >> Emmanuel Vadot wrote: >> >> On Fri, 16 Aug 2019 15:24:54 +0200 >> Emmanuel Vadot wrote: >> >> On Fri, 16 Aug 2019 07:28:59 +0200 >> S=C3=B8ren Schmidt wrote: >> >> Hi >> >> Very simple, reverting sys/gnu/dts to what was before >> >> 350595 (actually 350592). >> >> Thats what we have svn for ? >> >> >> If I asked how it was to have the svn command that you >> >> used, I want to >> >> make sure that you didn't revert anything else, like do you >> >> have >> >> r350596 and r350628 ? >> >> That does make my bananapi work again, no other changes >> >> just a recompiled kernel. >> >> >> That + copying the dtb to the fat32 partition ? >> >> Can you post the dtb somewhere. >> >> However it does not bring the Espressobin back to life, >> >> thats something in one of the ~30 other files that changed between those >> two revisions. >> >> >> What Linux version of DTS are you using then ? The ones >> >> that were in >> >> stable/12 when it was branched (4.18) or a later revision ? >> >> >> So I think that I've found the problem on the Espressobin. >> I think that the problem comes from the simple-mfd driver >> >> that I've >> >> mfc in r350600. >> The pinctrl/gpio controller compatible is >> "marvell,armada3710-nb-pinctrl", "syscon", "simple-mfd" and >> >> it attaches >> >> at BUS_PASS_INTERRUPT while the simple_mfd driver attaches at >> BUS_PASS_BUS (so earlier) which means that no gpio >> >> controller will be >> >> available for sdhci to detect the card. >> >> If someone with a non-working espressobin could post a full >> >> verbose >> >> boot log that would help me confirming that this is the case. >> I'll try to find a solution on how to solve this problem. >> >> >> So this wasn't the problem but I've found it, see r351129 and >> >> r351130 >> >> >> SD card now work again in HEAD, I'll have a look at stable >> >> later next >> >> week. >> >> >> I've did a quick test and I've MFC r348880, r348882 and >> >> r349596, the >> >> two other commits needed to be mfc'ed are the one I did today >> >> on head, >> >> I'll do that next week. >> With them sdcard is working again on stable/12 >> >> -S=C3=B8ren >> >> On 15 Aug 2019, at 23.37, Emmanuel Vadot < >> >> manu@bidouilliste.com> wrote: >> >> >> On Thu, 15 Aug 2019 21:56:23 +0200 >> S=C3=B8ren Schmidt wrote: >> >> >> Well, I don?t care where you are from and what color you >> >> have :) >> >> >> Now, if I update my stable12 sources to r350595 the >> >> bananapi breaks, if revert sys/gnu/dts it works again, go figure.. >> >> >> Reverting to what ? and how ? >> >> Because I've just test 12-stable and I have the problem >> >> that I've said >> >> in my previous mail so setting >> >> hw.regulator.disable_unused=3D0 is the >> >> work around. >> The problem is in twsi not in the DTS so I'm curious how >> >> reverting >> >> only the dts fixes this problem. >> >> The r351099 fix is already like that in -stable, and not >> >> part of the problem. >> >> >> -S=C3=B8ren >> >> >> On 15 Aug 2019, at 21.03, Emmanuel Vadot < >> >> manu@bidouilliste.com> wrote: >> >> >> On Thu, 15 Aug 2019 19:48:54 +0200 >> S=C3=B8ren Schmidt wrote: >> >> Hi Mit! >> >> Right, I suspected that, 12-stable broke many embedded >> >> systems between r350592 and r350595 where all the latest and greatest DT= S >> files was pulled in, I guess the same holds for -current. >> >> >> -S=C3=B8ren >> >> >> Mhm it's fun that you think that DTS import is the >> >> source of all your >> >> problems, I get it, it's easy to blame the French guy >> >> that bulk import >> >> the DTS, he surely don't know what he is doing. >> Anyway, two problems were raised in this thread : >> >> 1) BananaPi (A20) doesn't boot >> 2) Espressobin sd support is broken >> >> I've just looked at the BananaPi problem today, I've >> >> fixed a first >> >> problem in r351099. >> The main problem is that when we disable the unused >> >> regulators we hang >> >> when trying to disabling ldo3. It's weird because the >> >> board doesn't use >> >> LDO3 (which is why we are disabling it, it's unused). >> >> The problem is in >> >> twsi I think as only leaving the part in axp209 that >> >> read the >> >> voltage register value make FreeBSD hang. >> I'll have a proper look later, in the meantime you can >> >> set >> >> hw.regulator.disable_unused=3D0 >> in /boot/loader.conf >> This isn't a DTS problem. >> >> For Espressobin I haven't found any thing related to SD >> >> in the DTS >> >> updates since the import, the only things slighly >> >> related are mmc and >> >> sdio. >> So if someone could find which DTS import broke this I >> >> can have a look. >> >> >> >> On 15 Aug 2019, at 19.37, Mit Matelske >> >> wrote: >> >> >> Yeah, that was the problem. I went back to r348882 >> >> and everything worked out of the box. >> >> >> Thanks again for the hand holding! >> >> Mit >> >> From: "S=C3=B8ren Schmidt" > >> > >> >> To: "Mit Matelske" > >> Cc: "Marcin Wojtas" > >> mw@semihalf.com>>, "freebsd-arm" > freebsd-arm@freebsd.org>> >> >> Sent: Wednesday, August 14, 2019 1:33:04 PM >> Subject: Re: Espressobin anyone ? >> >> >> It might simply be broken in -current (again). >> >> I just updated my stable12 tree and I pulled in new >> >> .dts files for just about anything? >> >> >> Needless to say, it broke the Espressobin?s SD >> >> support, it now fails just like yours.. >> >> >> It also broke allwinner builds and what not, so I?m >> >> just going back in time again :) >> >> >> I wonder why there is this overwhelming need to >> >> import stuff that breaks things right, left and center in a -stable >> branch ? >> >> That would have earned you the pointy hat back when?. >> >> -S=C3=B8ren >> >> >> On 14 Aug 2019, at 18.01, Mit Matelske > >> > wrote: >> >> >> Marcin- >> >> Sorry I didn't reply yesterday. I didn't have any >> >> luck with that either. I tried a lot of permutations. >> >> >> Not saying for 100% it doesn't work, but I couldn't >> >> get it to work! >> >> >> Mit >> >> From: "Marcin Wojtas" > >> mw@semihalf.com>> >> >> To: "Mit Matelske" > >> Cc: "S=C3=B8ren Schmidt" > >> soren.schmidt@gmail.com>>, "freebsd-arm" > > >> >> Sent: Wednesday, August 14, 2019 10:41:04 AM >> Subject: Re: Espressobin anyone ? >> >> Hi Mit, >> Since you are using the latest 13-current, could you >> >> please try if passing rootdev via u-boot bootargs (please see my previou= s >> email) works for you without the loader modification? >> >> >> Best regards, >> Marcin >> >> ?r., 14 sie 2019 o 16:29 Mit Matelske > >> > napisa?(a): >> >> Soren- >> >> Thanks for the info. I'll grab a couple more SD >> >> cards at lunch. This one is a new Samsung 32GB. I'll also try putting >> the >> changes into 12 and see if that helps. I'm using the latest 13-current. >> >> >> Again, appreciate the hand holding! >> >> Mit >> >> From: "S=C3=B8ren Schmidt" > >> > >> >> To: "Mit Matelske" > >> Cc: "Marcin Wojtas" > >> mw@semihalf.com>>, "freebsd-arm" > freebsd-arm@freebsd.org>> >> >> Sent: Wednesday, August 14, 2019 2:30:31 AM >> Subject: Re: Espressobin anyone ? >> >> Hi Mit >> Hmm, from your earlier posted dmesgs it looks like >> >> the SD card is not getting detected properly.. >> >> >> I get this output: >> >> sdhci_xenon0: mem >> >> 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 >> >> mmc0: on sdhci_xenon0 >> ?snip? >> mmcsd0: 16GB > >> by 39 PH> at mmc0 50.0MHz/4bit/65535-block >> >> >> The problem you see was fixed for me by r348882, >> >> maybe it got broken later, I havn?t backported the later changes.. >> >> >> Have you tried another SD card ? I have found 2 of >> >> mine that the espressobin doesn?t like, but works fine with bananapi and >> friends... >> >> >> -S=C3=B8ren >> >> On 13 Aug 2019, at 23.30, Mit Matelske > >> > wrote: >> >> >> Soren- >> >> Thanks for the code snippet! That will fix one of >> >> the problems. >> >> >> I still can't mount my filesystem, though. I think >> >> I'm doing something really simple, wrong. I believe I'm running the >> latest >> code and added some printfs to show the kernel setting the regulator: >> >> >> >> usbus1 on ehci0 >> syscon_generic4: mem 0x5f800-0x5ffff on >> >> simplebus1 >> >> sdhci_xenon0: >> >> regulator_get_by_ofw_property(vqmmc-supply) =3D 19 >> >> sdhci_xenon0: vqmmc-supply regulator found >> sdhci_xenon0: mem >> >> 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 >> >> ahci0: mem 0xe0000-0xe0177 irq >> >> 26 on simplebus1 >> >> >> >> Could there be a problem with how I am setting up my >> >> filesystem? I've tried both freebsd-ufs and freebsd as the type, with n= o >> luck. A gpart listing of my SD card: >> >> >> root@fbl:~ # gpart list da3 >> Geom name: da3 >> modified: false >> state: OK >> fwheads: 255 >> fwsectors: 63 >> last: 62521335 >> first: 3 >> entries: 4 >> scheme: GPT >> Providers: >> 1. Name: da3p1 >> Mediasize: 41943040 (40M) >> Sectorsize: 512 >> Stripesize: 0 >> Stripeoffset: 1536 >> Mode: r0w0e0 >> efimedia: >> >> HD(1,GPT,19894dc5-b8b2-11e9-871f-08008a0010e0,0x3,0x14000) >> >> rawuuid: 19894dc5-b8b2-11e9-871f-08008a0010e0 >> rawtype: c12a7328-f81f-11d2-ba4b-00a0c93ec93b >> label: (null) >> length: 41943040 >> offset: 1536 >> type: efi >> index: 1 >> end: 81922 >> start: 3 >> 2. Name: da3p2 >> Mediasize: 31968979456 (30G) >> Sectorsize: 512 >> Stripesize: 0 >> Stripeoffset: 41944576 >> Mode: r0w0e0 >> efimedia: >> >> HD(2,GPT,98786462-be30-11e9-ae6e-08008a0010e0,0x14003,0x3b8bff5) >> >> rawuuid: 98786462-be30-11e9-ae6e-08008a0010e0 >> rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b >> label: (null) >> length: 31968979456 >> offset: 41944576 >> type: freebsd-ufs >> index: 2 >> end: 62521335 >> start: 81923 >> Consumers: >> 1. Name: da3 >> Mediasize: 32010928128 (30G) >> Sectorsize: 512 >> Mode: r0w0e0 >> >> Thanks!! >> >> Mit >> >> From: "S=C3=B8ren Schmidt" > >> > >> >> To: "Marcin Wojtas" > >> mw@semihalf.com>> >> >> Cc: "Mit Matelske" >, >> >> "freebsd-arm" > freebsd-arm@freebsd.org>> >> >> Sent: Tuesday, August 13, 2019 12:55:09 PM >> Subject: Re: Espressobin anyone ? >> >> Hi >> That doesn?t seen to work on the espressobin, or >> >> least I can?t get it to pick it up. >> >> >> I use this patch as a workaround: >> >> Index: main.c >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> --- main.c (revision 350496) >> +++ main.c (working copy) >> @@ -463,6 +462,13 @@ >> int rv; >> char *rootdev; >> >> +#if defined(__aarch64__) >> + /* SOS HACK in rootdev, at least Espressobin >> >> gets this wrong */ >> >> + printf("Setting currdev hack\n"); >> + set_currdev("disk0p2"); >> + return (0); >> +#endif >> + >> /* >> * First choice: if rootdev is already set, use >> >> that, even if >> >> * it's wrong. >> >> Its not pretty but it does the job until I get time >> >> to look into why bootargs aren?t passed / won?t stick, probably somethin= g >> I >> havn?t backported to my -stable12 sources yet... >> >> >> -S=C3=B8ren >> >> On 13 Aug 2019, at 01.38, Marcin Wojtas < >> >> mw@semihalf.com > wrote: >> >> >> Hi, >> >> Not sure if it's what you are looking for, but in >> >> order to autoboot, I >> >> simply pass 'rootdev=3DdiskXpY' in the bootargs >> >> variable. Here's example from >> >> A3720-DB (same should work on EspressoBin): >> >> Marvell>> set bootargs "rootdev=3Ddisk1p1";usb reset; >> >> fatload usb 0:1 >> >> ${fdt_addr} armada-3720-db.dtb; fatload usb 0:1 >> >> ${kernel_addr} >> >> boot/loader.efi; bootefi ${kernel_addr} ${fdt_addr} >> resetting USB... >> USB0: Register 2000104 NbrPorts 2 >> Starting the controller >> USB XHCI 1.00 >> USB1: USB EHCI 1.00 >> - ______ ____ _____ _____ >> | ____| | _ \ / ____| __ \ >> | |___ _ __ ___ ___ | |_) | (___ | | | | >> | ___| '__/ _ \/ _ \| _ < \___ \| | | | >> | | | | | __/ __/| |_) |____) | |__| | >> | | | | | | || | | | >> |_| |_| \___|\___||____/|_____/|_____/ >> ``` >> ` >> ????????????Welcome to FreeBSD????????????? s` >> >> `.....---.......--.``` >> >> -/ >> ? ? +o >> >> .--` /y:` >> >> +. >> ? 1. Boot Multi user [Enter] ? >> >> yo`:. :o >> >> `+- >> ? 2. Boot Single user ? y/ >> >> -/` -o/ >> >> ? 3. Escape to loader prompt ? .- >> ::/sy+:. >> ? 4. Reboot ? / >> >> `-- >> >> / >> ? ? `: >> :` >> ? Options: ? `: >> :` >> ? 5. Kernel: default/kernel (1 of 1) ? / >> / >> ? 6. Boot Options ? .- >> -. >> ? ? -- >> >> -. >> >> ? ? >> >> `:` `:` >> >> ? ? >> >> .-- `--. >> >> ??????????????????????????????????????????? >> >> .---.....----. >> >> Autoboot in 9 seconds, hit [Enter] to boot or any >> >> other key to stop >> >> >> Loading kernel... >> /boot/kernel/kernel text=3D0x95047c >> >> data=3D0x1919d0+0x84aa94 >> >> syms=3D[0x8+0x13aaa8+0x8+0x12610d] >> Loading configured modules... >> can't find '/boot/entropy' >> Using DTB provided by EFI at 0x8000000. >> ---<>--- >> KDB: debugger backends: ddb >> KDB: current backend: ddb >> Copyright (c) 1992-2019 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, >> >> 1991, 1992, 1993, 1994 >> >> The Regents of the University of California. All >> >> rights reserved. >> >> FreeBSD is a registered trademark of The FreeBSD >> >> Foundation. >> >> FreeBSD 13.0-CURRENT >> >> 17a1fc80d57-c261519(upstream_master) GENERIC arm64 >> >> FreeBSD clang version 8.0.0 (tags/RELEASE_800/final >> >> 356365) (based on LLVM >> >> 8.0.0) >> WARNING: WITNESS option enabled, expect reduced >> >> performance. >> >> VT: init without driver. >> Starting CPU 1 (1) >> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >> [...] >> >> Best regards, >> Marcin >> >> pon., 12 sie 2019 o 23:14 Mit Matelske > >> > napisa?(a): >> >> >> >> Soren- >> >> Thanks for the quick response. I built this kernel >> >> with revision 350924. >> >> I'll dig into whats going on in the morning. >> >> Mind posting your diff for your loader.efi? >> >> Thanks again! >> >> Mit >> >> >> ----- Original Message ----- >> From: "S=C3=B8ren Schmidt" > >> > >> >> To: "Mit Matelske" > >> Cc: "tscho" > >> johannes@t-beutel.com>>, "freebsd-arm" < >> >> freebsd-arm@freebsd.org > >> freebsd-arm@freebsd.org>> >> >> Sent: Monday, August 12, 2019 3:49:48 PM >> Subject: Re: Espressobin anyone ? >> >> Hi >> >> Looks like your sources may be too old, you need to >> >> be at least at r348882 >> >> to get the fix for the SD card VCC regulator. >> >> That change fixed it for me backported to 12-stable... >> >> The currdev problem still exists, I have it hardwired >> >> in my loader for >> >> aarch64 :) >> >> -S=C3=B8ren >> >> >> On 12 Aug 2019, at 21.06, Mit Matelske > >> > wrote: >> >> >> I'm having a couple little hiccups booting this board >> >> also. One has >> >> been commented on already, that I can't get the >> >> loader to automatically >> >> start loading the kernel on "disk0p2"... >> >> The second, is that the kernel can't find the SD card >> >> after booting so >> >> it can't mount the root filesystem. I'm using the >> >> dts/dtb and kernel from >> >> the 13-current branch. >> >> Thanks for any and all help. I haven't used u-boot >> >> in about decade. >> >> Spoiled by the x86 platform. >> >> Mit Matelske >> >> >> ***U-boot environment:*** >> >> >> Marvell>> printenv >> baudrate=3D115200 >> bootargs=3Dconsole=3DttyMV0,115200 >> >> earlycon=3Dar3700_uart,0xd0012000 >> >> root=3D/dev/mmcblk0p1 rw rootwait net.ifnames=3D0 >> >> biosdevname=3D0 >> >> bootcmd=3Dmmc dev 0; fatload mmc 0:1 $kernel_addr >> >> $image_name;fatload mmc >> >> 0:1 $fdt_addr $fdt_name; bootefi $kernel_addr >> >> $fdt_addr >> >> bootdelay=3D2 >> bootmmc=3Dmmc dev 0; fatload mmc 0:1 $kernel_addr >> >> $image_name;fatload mmc >> >> 0:1 $fdt_addr $fdt_name; bootefi $kernel_addr >> >> $fdt_addr >> >> console=3Dconsole=3DttyMV0,115200 >> >> earlycon=3Dar3700_uart,0xd0012000 >> >> eth1addr=3D00:51:82:11:22:01 >> eth2addr=3D00:51:82:11:22:02 >> eth3addr=3D00:51:82:11:22:03 >> ethact=3Dneta@30000 >> ethaddr=3DF0:AD:4E:09:6B:8F >> ethprime=3Deth0 >> fdt_addr=3D0x4f00000 >> fdt_high=3D0xffffffffffffffff >> fdt_name=3Defi/boot/armada-3720-espressobin.dtb >> fdtcontroladdr=3D3f7161b8 >> gatewayip=3D10.4.50.254 >> get_images=3Dtftpboot $kernel_addr $image_name; >> >> tftpboot $fdt_addr >> >> $fdt_name; run get_ramfs >> get_ramfs=3Dif test "${ramfs_name}" !=3D "-"; then setenv >> >> ramfs_addr >> >> 0x8000000; tftpboot $ramfs_addr $ramfs_name; else >> >> setenv ramfs_addr -;fi >> >> hostname=3Dmarvell >> image_name=3Defi/freebsd/loader.efi >> initrd_addr=3D0xa00000 >> initrd_size=3D0x2000000 >> ipaddr=3D0.0.0.0 >> kernel_addr=3D0x5000000 >> loadaddr=3D0x5000000 >> netdev=3Deth0 >> netmask=3D255.255.255.0 >> ramfs_addr=3D0x8000000 >> ramfs_name=3D- >> root=3Droot=3D/dev/nfs rw >> rootpath=3D/srv/nfs/ >> serverip=3D0.0.0.0 >> set_bootargs=3Dsetenv bootargs $console $root >> >> ip=3D$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:none >> >> nfsroot=3D$serverip:$rootpath $extra_params >> stderr=3Dserial@12000 >> stdin=3Dserial@12000 >> stdout=3Dserial@12000 >> >> >> ***Full boot logs:*** >> >> >> U-Boot 2017.03-armada-17.10.2-g14aeedc (Jun 01 2018 - >> >> 15:39:10 +0800) >> >> >> Model: Marvell Armada 3720 Community Board ESPRESSOBin >> CPU @ 1000 [MHz] >> L2 @ 800 [MHz] >> TClock @ 200 [MHz] >> DDR @ 800 [MHz] >> DRAM: 1 GiB >> U-Boot DT blob at : 000000003f7161b8 >> Comphy-0: USB3 5 Gbps >> Comphy-1: PEX0 2.5 Gbps >> Comphy-2: SATA0 6 Gbps >> SATA link 0 timeout. >> AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA >> >> mode >> >> flags: ncq led only pmp fbss pio slum part sxs >> PCIE-0: Link down >> MMC: sdhci@d0000: 0, sdhci@d8000: 1 >> SF: Detected mx25u3235f with page size 256 Bytes, >> >> erase size 64 KiB, >> >> total 4 MiB >> Net: eth0: neta@30000 [PRIME] >> Hit any key to stop autoboot: 0 >> switch to partitions #0, OK >> mmc0 is current device >> reading efi/freebsd/loader.efi >> 603872 bytes read in 49 ms (11.8 MiB/s) >> reading efi/boot/armada-3720-espressobin.dtb >> 15946 bytes read in 17 ms (916 KiB/s) >> ## Starting EFI application at 05000000 ... >> Scanning disk sdhci@d0000.blk > >> ... >> >> Card did not respond to voltage select! >> mmc_init: -95, time 50 >> Found 1 disks >> Consoles: EFI console >> FreeBSD/arm64 EFI loader, Revision 1.1 >> >> Command line arguments: loader.efi >> EFI version: 2.05 >> EFI Firmware: Das U-boot (rev 0.00) >> Console: efi (0) >> Failed to find bootable partition >> Startup error in /boot/lua/loader.lua: seconds >> LUA ERROR: cannot open /boot/lua/loader.lua: invalid >> >> argument. >> >> >> can't load 'kernel' >> >> Type '?' for a list of commands, 'help' for more >> >> detailed help. >> >> OK >> OK set currdev=3Ddisk0p2 >> OK boot >> >> /boot/kernel/kernel text=3D0x97d6a0 >> >> data=3D0x191b50+0x84ae94 >> >> syms=3D[0x8+0x137dd8+0x8+0x126260] >> Using DTB provided by EFI at 0x8000000. >> ---<>--- >> KDB: debugger backends: ddb >> KDB: current backend: ddb >> Copyright (c) 1992-2019 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, >> >> 1991, 1992, 1993, 1994 >> >> The Regents of the University of California. All >> >> rights reserved. >> >> FreeBSD is a registered trademark of The FreeBSD >> >> Foundation. >> >> FreeBSD 13.0-CURRENT GENERIC arm64 >> FreeBSD clang version 6.0.1 (tags/RELEASE_601/final >> >> 335540) (based on >> >> LLVM 6.0.1) >> WARNING: WITNESS option enabled, expect reduced >> >> performance. >> >> VT: init without driver. >> Starting CPU 1 (1) >> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >> arc4random: WARNING: initial seeding bypassed the >> >> cryptographic random >> >> device because it was not yet seeded and the knob >> >> 'bypass_before_seeding' >> >> was enabled. >> random: entropy device external interface >> MAP 3e681000 mode 2 pages 1 >> MAP 3ffa6000 mode 2 pages 1 >> kbd0 at kbdmux0 >> ofwbus0: >> simplebus0: on >> >> ofwbus0 >> >> simplebus1: on >> >> simplebus0 >> >> simple_mfd0: mem >> 0x13800-0x138ff,0x13c00-0x13c1f on simplebus1 >> simple_mfd1: mem >> 0x18800-0x188ff,0x18c00-0x18c1f on simplebus1 >> psci0: > >> Driver> on ofwbus0 >> >> gic0: mem >> >> >> 0x1d00000-0x1d0ffff,0x1d40000-0x1d7ffff,0x1d80000-0x1d81fff,0x1d90000-0x= 1d91fff,0x1da0000-0x1dbffff >> >> irq 27 on simplebus1 >> gpio0: 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: 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: on ofwbus0 >> gpioregulator0: cannot get pin 0 >> gpioregulator0: cannot parse parameters >> device_attach: gpioregulator0 attach returned 6 >> generic_timer0: irq 0,1,2,3 on >> >> ofwbus0 >> >> Timecounter "ARM MPCore Timecounter" frequency >> >> 12500000 Hz quality 1000 >> >> Event timer "ARM MPCore Eventtimer" frequency >> >> 12500000 Hz quality 1000 >> >> gpio0: 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: 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: on ofwbus0 >> gpioregulator0: cannot get pin 0 >> gpioregulator0: cannot parse parameters >> device_attach: gpioregulator0 attach returned 6 >> gpio0: 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: 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: on ofwbus0 >> gpioregulator0: cannot get pin 0 >> gpioregulator0: cannot parse parameters >> device_attach: gpioregulator0 attach returned 6 >> gpio0: 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: 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: on ofwbus0 >> gpioregulator0: cannot get pin 0 >> gpioregulator0: cannot parse parameters >> device_attach: gpioregulator0 attach returned 6 >> gpio0: 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: 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: on ofwbus0 >> gpioregulator0: cannot get pin 0 >> gpioregulator0: cannot parse parameters >> device_attach: gpioregulator0 attach returned 6 >> cpulist0: on ofwbus0 >> cpu0: on cpulist0 >> cpu1: on cpulist0 >> pmu0: irq 4 on ofwbus0 >> syscon_generic0: mem 0xd000-0xdfff on >> >> simplebus1 >> >> syscon_generic1: mem 0x11500-0x1153f on >> >> simplebus1 >> >> uart0: mem 0x12000-0x121ff >> >> irq 9,10,11 on >> >> simplebus1 >> uart0: console (115200,n,8,1) >> gpio0: 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: mem 0x14000-0x1405f on >> >> simplebus1 >> >> gpio0: 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: mem 0x30000-0x33fff irq 14 >> >> on simplebus1 >> >> mvneta0: version is 10 >> mvneta0: Ethernet address: 00:a6:39:ca:e8:00 >> mdio0: on mvneta0 >> mdioproxy0: on mdio0 >> e6000sw0: on mdio0 >> e6000sw0: multi-chip addressing mode (0x1) >> e6000sw0: CPU port at 0 >> e6000sw0: fixed port at 0 >> e6000sw0: PHY at port 1 >> miibus0: on e6000sw0 >> e1000phy0: 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: on e6000sw0 >> e1000phy1: 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: on e6000sw0 >> e1000phy2: 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: on e6000sw0 >> xhci0: mem >> >> 0x58000-0x5bfff irq 16 on >> >> simplebus1 >> xhci0: 32 bytes context size, 32-bit DMA >> usbus0 on xhci0 >> syscon_generic3: mem 0x5d800-0x5dfff on >> >> simplebus1 >> >> ehci0: mem >> >> 0x5e000-0x5efff irq >> >> 17 on simplebus1 >> usbus1: EHCI version 1.0 >> usbus1 on ehci0 >> syscon_generic4: mem 0x5f800-0x5ffff on >> >> simplebus1 >> >> sdhci_xenon0: mem >> 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 >> ahci0: mem 0xe0000-0xe0177 irq >> >> 26 on simplebus1 >> >> ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier >> >> supported with FBS >> >> ahcich0: at channel 0 on ahci0 >> device_attach: ahcich0 attach returned 6 >> gpioregulator0: on ofwbus0 >> gpioregulator0: cannot get pin 0 >> gpioregulator0: cannot parse parameters >> device_attach: gpioregulator0 attach returned 6 >> cryptosoft0: >> 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 >> >> >> >> 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 >> >> usbus1 Processor Features 1 =3D <0> >> usbus0 Memory Model Features 0 =3D <4k Granule,64k >> >> Granule,S/NS >> >> Mem,MixedEndian,16bit ASID,1TB PA> >> >> Memory Model Features 1 =3D <> >> Memory Model Features 2 =3D <32b CCIDX,48b VA> >> Debug Features 0 =3D <2 CTX Breakpoints,4 >> >> Watchpoints,6 >> >> Breakpoints,PMUv3,Debug v8> >> Debug Features 1 =3D <0> >> Auxiliary Features 0 =3D <0> >> Auxiliary Features 1 =3D <0> >> CPU 1: ARM Cortex-A53 r0p4 affinity: 1 >> WARNING: WITNESS option enabled, expect reduced >> >> performance. >> >> ugen0.1: at usbus0 >> ugen1.1: at usbus1 >> uhub0 on usbus0 >> uhub1 on usbus1 >> uhub0: > >> 3.00/1.00, addr 1> on >> >> usbus0 >> uhub1: > >> 2.00/1.00, addr 1> on >> >> usbus1 >> uhub0: 2 ports with 2 removable, self powered >> uhub1: 1 port with 1 removable, self powered >> mountroot: waiting for device >> >> /dev/ufs/FreeBSD_Install... >> >> Mounting from ufs:/dev/ufs/FreeBSD_Install failed >> >> with error 19. >> >> >> Loader variables: >> vfs.root.mountfrom=3Dufs:/dev/ufs/FreeBSD_Install >> vfs.root.mountfrom.options=3Dro,noatime >> >> Manual root filesystem specification: >> : [options] >> Mount using filesystem >> and with the specified (optional) option list. >> >> eg. ufs:/dev/da0s1a >> zfs:zroot/ROOT/default >> cd9660:/dev/cd0 ro >> (which is equivalent to: mount -t cd9660 -o ro >> >> /dev/cd0 /) >> >> >> ? List valid disk boot devices >> . Yield 1 second (for background tasks) >> Abort manual input >> >> mountroot> ? >> >> List of GEOM managed disk devices: >> >> >> mountroot> >> _______________________________________________ >> freebsd-arm@freebsd.org > >> 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 > freebsd-arm-unsubscribe@freebsd.org>" >> >> >> _______________________________________________ >> freebsd-arm@freebsd.org > >> 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 > freebsd-arm-unsubscribe@freebsd.org>" >> >> >> >> >> -- >> Emmanuel Vadot < >> >> manu@freebsd.org> >> >> >> >> >> -- >> Emmanuel Vadot >> >> >> >> -- >> Emmanuel Vadot >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to " >> >> freebsd-arm-unsubscribe@freebsd.org" >> >> >> >> -- >> Emmanuel Vadot >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to " >> >> freebsd-arm-unsubscribe@freebsd.org" >> >> >> >> -- >> Emmanuel Vadot >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to " >> >> freebsd-arm-unsubscribe@freebsd.org" >> >> >> >> -- >> Emmanuel Vadot > >> manu@bidouilliste.com>> > >> >> >> >> >> -- >> Emmanuel Vadot > >> manu@bidouilliste.com>> > >> >> >> >> >> -- >> Emmanuel Vadot >> _______________________________________________ >> 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" >> >> >> From owner-freebsd-arm@freebsd.org Tue Aug 20 12:44:00 2019 Return-Path: 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 3212CD16CE for ; Tue, 20 Aug 2019 12:44:00 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46CVpk1y74z4KF0 for ; Tue, 20 Aug 2019 12:43:57 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Date: Tue, 20 Aug 2019 14:43:55 +0200 (CEST) From: Ronald Klop To: Jeffrey Bowers Cc: =?utf-8?Q?S=C3=B8ren_Schmidt?= , freebsd-arm Message-ID: <912587110.50.1566305035850@localhost> In-Reply-To: References: <1547777156.662147.1565798461515.JavaMail.zimbra@perftech.com> <0E42E605-477E-4E65-810E-BD3A8CDE2C80@gmail.com> <973015183.1067498.1565890674099.JavaMail.zimbra@perftech.com> <20190815210311.1035f64b003e2bc85fa47ca8@bidouilliste.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> <20190817153053.5592b15b8a42982fda0fc123@bidouilliste.com> <9749945A-FDAD-47E0-947A-FA62138C2F83@gmail.com> <20190817210822.8920656bad0855b554883cf2@bidouilliste.com> <2D6D4BDA-75EC-403F-B5E2-52A468369DE2@gmail.com> <627099DD-804B-412F-A083-768CEFCF955C@gmail.com> <6DA8E736-8031-4BF7-8B20-CF8B0E8A7FEF@gmail.com> Subject: Re: Espressobin anyone ? (svn https timeout) MIME-Version: 1.0 X-Mailer: Realworks (471.1011.ce02e15a2ad) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 46CVpk1y74z4KF0 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 194.109.157.24 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws X-Spamd-Result: default: False [-1.33 / 15.00]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; URI_COUNT_ODD(1.00)[41]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.66)[-0.657,0]; HAS_X_PRIO_THREE(0.00)[3]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; IP_SCORE(-0.06)[ipnet: 194.109.0.0/16(-0.16), asn: 3265(-0.13), country: NL(0.01)]; SUBJECT_HAS_QUESTION(0.00)[]; SH_EMAIL_ZRD(0.00)[0.0.117.48]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.91)[-0.907,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.117.48,0.0.46.224]; NEURAL_HAM_LONG(-0.91)[-0.907,0]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[klop.ws]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[24.157.109.194.list.dnswl.org : 127.0.15.0]; MID_RHS_NOT_FQDN(0.50)[]; FREEMAIL_CC(0.00)[gmail.com] Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 12:44:00 -0000 #: host svn.freebsd.org svn.freebsd.org is an alias for svnmir.geo.freebsd.org. svnmir.geo.freebsd.org has address 213.138.116.72 svnmir.geo.freebsd.org has IPv6 address 2001:41c8:112:8300::e6a:0 It might be possible that you are directed to a different server. It uses g= eo-location on DNS level. Regards, Ronald. =20 Van: Jeffrey Bowers Datum: dinsdag, 20 augustus 2019 14:33 Aan: "S=C3=B8ren Schmidt" , freebsd-arm Onderwerp: Re: Espressobin anyone ? >=20 > I'm still getting: svn: E000060: Operation timed out > It goes for several minutes scrolling through text, and I feel like using > your link got further. >=20 > Thanks! >=20 > On Tue, Aug 20, 2019 at 2:49 AM S=C3=B8ren Schmidt > wrote: >=20 > > Hmm, I use this URL > > > > Repository Root: https://svn.freebsd.org/ports/head > > > > Not sure the svn+ssh thing works=E2=80=A6 > > > > -S=C3=B8ren > > > > > > On 20 Aug 2019, at 02.38, Jeffrey Bowers wrote: > > > > Hi all, > > > > I'm having trouble getting subversion to work. When I run: > > > > svn checkout https://svn.FreeBSD.org/ports/head /usr/ports > > > > It scrolls through many lines of text before stating: svn: E000060: > > Operation timed out > > > > When I run: > > > > svn checkout svn+ssh://repo.freebsd.org/ports/head /usr/ports > > > > It tells me that the authenticity of the host cannot be identified, and > > asks me to confirm that I want to connect. I say yes, and then it says: > > > > svn: E170013: Unable to connect to a repository at URL 'svn+ssh:// > > repo.freebsd.org/ports/head' > > svn: E210002: To better debug SSH connection problems, remove the -q op= tion > > from 'ssh' in the [tunnels] section of your Subversion configuration fi= le. > > > > Any ideas? > > > > Thanks in advance! > > > > On Mon, Aug 19, 2019 at 8:51 PM Jeffrey Bowers > > wrote: > > > > I didn't think it remounting. Thank you! > > > > On Mon, Aug 19, 2019 at 11:39 AM S=C3=B8ren Schmidt > > wrote: > > > > Hi Jeffrey > > > > You need to unmount the /tmp filesystem :) > > You can do that permanently by commenting it out in /etc/fstab > > > > > > On 19 Aug 2019, at 21.45, Jeffrey Bowers wrote: > > > > Hi Soren, > > > > I'm getting the same error message. Any other ideas what it might be? > > It's got to be something in the partition scheme or the file permission= s, > > but I'm just not sure what. > > > > > > On Sun, Aug 18, 2019 at 10:03 AM Jeffrey Bowers > > wrote: > > > > D=E2=80=99Oh! I thought I too care of that with gpart. I literally miss= ed growfs > > part of the instructions.. > > > > On Sun, Aug 18, 2019 at 10:00 AM S=C3=B8ren Schmidt > > wrote: > > > > Hi > > > > You are out of space :) > > > > Boot the board into singleuser mode, and do =E2=80=9Cservice growfs sta= rt=E2=80=9D, > > that will expand you / filesystem to the entire SD card=E2=80=A6 > > > > -S=C3=B8ren > > > > On 18 Aug 2019, at 14.50, Jeffrey Bowers wrote: > > > > Sure thing! Here's the screenshot! > > > > > > > > On Sun, Aug 18, 2019 at 7:35 AM S=C3=B8ren Schmidt > > wrote: > > > > Hi > > > > Can I have you paste the output from df -h ? > > > > You should be able to utilise the full SD card=E2=80=A6 > > > > -S=C3=B8ren > > > > On 18 Aug 2019, at 14.29, Jeffrey Bowers wrote: > > > > Hi, > > > > Just make sure I understand the process, I should hook up a hard disk > > and map it to to /TMP ? > > > > I already tried just unmapping /tmp, and it gave me the same error > > once, and then the next time I ran it I got an error saying /usr/ports = was > > out of space )which I guess I shouldn=E2=80=99t mount to another direct= or on the > > hard drive? > > > > On Sun, Aug 18, 2019 at 5:11 AM S=C3=B8ren Schmidt > > wrote: > > > > Hi Jeffrey > > > > You can unmount the memory disk on /tmp to get at the space on the SD > > card. > > > > It is however not recommend to use the AD card for random storage, it > > will wear out fast, that=E2=80=99s why the memory disk is setup. > > > > You could connect a SSD og laptop disk to the SATA interface and use > > that for the workload. > > > > However compiling is slow, its much much faster to cross compile on a > > PC=E2=80=A6 > > > > -S=C3=B8ren > > > > On 18 Aug 2019, at 00.22, Jeffrey Bowers wrote: > > > > Hi! I've got a new one :) > > I'm trying to do an svn checkout to fix the pkg problem, but it tells > > me it can't write to a to a temp folder because there is no room left o= n > > the device. However, FreeBSD partition is 29GB. It's never also never t= he > > same file in TMP that it can't write to. Here is a screenshot of the is= sue, > > along with the output of gpart: > > > > > > > > Any ideas? > > > > Thanks! > > > > > > On Sat, Aug 17, 2019 at 2:08 PM Emmanuel Vadot > > wrote: > > > > On Sat, 17 Aug 2019 17:14:36 +0200 > > S=C3=B8ren Schmidt wrote: > > > > HI > > > > Well, I have a whole forrest of tree?s here, but the error posted > > > > here was on a clean checkout. > > > > > > Anyhow, with the latest changes to -stable and the two > > > > RF_SHAREABLE patches from -current all works. > > > > I've reverted the commits, see > > https://github.com/evadot/freebsd/commits/a37x0_gpio for a better > > way > > to deal with this issue. > > I'm waiting for mmel@ as he wrote the syscon_get_default_handle > > part. > > > > It would be nice with the etherswitch changes as well so VLAN > > > > tagging etc was standard. > > > > > > -S=C3=B8ren > > > > PS: given up on bottom & inline popsting, top posting is all the > > > > rage now (yeah I miss elm etc :) ) > > > > > > On 17 Aug 2019, at 15.30, Emmanuel Vadot > > > > wrote: > > > > > > On Sat, 17 Aug 2019 11:07:22 +0200 > > S=C3=B8ren Schmidt > > > soren.schmidt@gmail.com>> wrote: > > > > > > Hi Emmunuel > > > > Yes the 3720 gpio driver I already back ported long ago, its > > > > needed, I?m happy its now part of std stable 12! > > > > > > Would have been nice of you to say that you were not running a > > > > clean > > > > tree. > > > > My issue seems to be the inclusion of the phy_usb driver, if I > > > > leave that out, I?m back to normal.. > > > > > > What make you think this is this driver ? What works/doesn't work > > with it ? could you provide logs. > > > > I?ll have have another go at the latest -stable sources during > > > > the weekend and see how it goes. > > > > > > Thanks for looking into this, with a little cooperation we?ll > > > > get this solved for the greater good.. > > > > > > -S=C3=B8ren > > > > > > P.S. Please stop top posting, it's really hard to read the > > > > conversation > > > > > > On 16 Aug 2019, at 22.58, Emmanuel Vadot < > > > > manu@bidouilliste.com> wrote: > > > > > > On Fri, 16 Aug 2019 19:12:30 +0200 > > Emmanuel Vadot > > > manu@bidouilliste.com>> wrote: > > > > > > On Fri, 16 Aug 2019 17:10:37 +0200 > > Emmanuel Vadot wrote: > > > > On Fri, 16 Aug 2019 15:24:54 +0200 > > Emmanuel Vadot wrote: > > > > On Fri, 16 Aug 2019 07:28:59 +0200 > > S=C3=B8ren Schmidt wrote: > > > > Hi > > > > Very simple, reverting sys/gnu/dts to what was before > > > > 350595 (actually 350592). > > > > Thats what we have svn for ? > > > > > > If I asked how it was to have the svn command that you > > > > used, I want to > > > > make sure that you didn't revert anything else, like do you > > > > have > > > > r350596 and r350628 ? > > > > That does make my bananapi work again, no other changes > > > > just a recompiled kernel. > > > > > > That + copying the dtb to the fat32 partition ? > > > > Can you post the dtb somewhere. > > > > However it does not bring the Espressobin back to life, > > > > thats something in one of the ~30 other files that changed between thos= e > > two revisions. > > > > > > What Linux version of DTS are you using then ? The ones > > > > that were in > > > > stable/12 when it was branched (4.18) or a later revision ? > > > > > > So I think that I've found the problem on the Espressobin. > > I think that the problem comes from the simple-mfd driver > > > > that I've > > > > mfc in r350600. > > The pinctrl/gpio controller compatible is > > "marvell,armada3710-nb-pinctrl", "syscon", "simple-mfd" and > > > > it attaches > > > > at BUS_PASS_INTERRUPT while the simple_mfd driver attaches at > > BUS_PASS_BUS (so earlier) which means that no gpio > > > > controller will be > > > > available for sdhci to detect the card. > > > > If someone with a non-working espressobin could post a full > > > > verbose > > > > boot log that would help me confirming that this is the case. > > I'll try to find a solution on how to solve this problem. > > > > > > So this wasn't the problem but I've found it, see r351129 and > > > > r351130 > > > > > > SD card now work again in HEAD, I'll have a look at stable > > > > later next > > > > week. > > > > > > I've did a quick test and I've MFC r348880, r348882 and > > > > r349596, the > > > > two other commits needed to be mfc'ed are the one I did today > > > > on head, > > > > I'll do that next week. > > With them sdcard is working again on stable/12 > > > > -S=C3=B8ren > > > > On 15 Aug 2019, at 23.37, Emmanuel Vadot < > > > > manu@bidouilliste.com> wrote: > > > > > > On Thu, 15 Aug 2019 21:56:23 +0200 > > S=C3=B8ren Schmidt wrote: > > > > > > Well, I don?t care where you are from and what color you > > > > have :) > > > > > > Now, if I update my stable12 sources to r350595 the > > > > bananapi breaks, if revert sys/gnu/dts it works again, go figure.. > > > > > > Reverting to what ? and how ? > > > > Because I've just test 12-stable and I have the problem > > > > that I've said > > > > in my previous mail so setting > > > > hw.regulator.disable_unused=3D0 is the > > > > work around. > > The problem is in twsi not in the DTS so I'm curious how > > > > reverting > > > > only the dts fixes this problem. > > > > The r351099 fix is already like that in -stable, and not > > > > part of the problem. > > > > > > -S=C3=B8ren > > > > > > On 15 Aug 2019, at 21.03, Emmanuel Vadot < > > > > manu@bidouilliste.com> wrote: > > > > > > On Thu, 15 Aug 2019 19:48:54 +0200 > > S=C3=B8ren Schmidt wrote: > > > > Hi Mit! > > > > Right, I suspected that, 12-stable broke many embedded > > > > systems between r350592 and r350595 where all the latest and greatest D= TS > > files was pulled in, I guess the same holds for -current. > > > > > > -S=C3=B8ren > > > > > > Mhm it's fun that you think that DTS import is the > > > > source of all your > > > > problems, I get it, it's easy to blame the French guy > > > > that bulk import > > > > the DTS, he surely don't know what he is doing. > > Anyway, two problems were raised in this thread : > > > > 1) BananaPi (A20) doesn't boot > > 2) Espressobin sd support is broken > > > > I've just looked at the BananaPi problem today, I've > > > > fixed a first > > > > problem in r351099. > > The main problem is that when we disable the unused > > > > regulators we hang > > > > when trying to disabling ldo3. It's weird because the > > > > board doesn't use > > > > LDO3 (which is why we are disabling it, it's unused). > > > > The problem is in > > > > twsi I think as only leaving the part in axp209 that > > > > read the > > > > voltage register value make FreeBSD hang. > > I'll have a proper look later, in the meantime you can > > > > set > > > > hw.regulator.disable_unused=3D0 > > in /boot/loader.conf > > This isn't a DTS problem. > > > > For Espressobin I haven't found any thing related to SD > > > > in the DTS > > > > updates since the import, the only things slighly > > > > related are mmc and > > > > sdio. > > So if someone could find which DTS import broke this I > > > > can have a look. > > > > > > > > On 15 Aug 2019, at 19.37, Mit Matelske > > > > wrote: > > > > > > Yeah, that was the problem. I went back to r348882 > > > > and everything worked out of the box. > > > > > > Thanks again for the hand holding! > > > > Mit > > > > From: "S=C3=B8ren Schmidt" > > > > > > > > To: "Mit Matelske" > > > Cc: "Marcin Wojtas" > > > mw@semihalf.com>>, "freebsd-arm" > freebsd-arm@freebsd.org>> > > > > Sent: Wednesday, August 14, 2019 1:33:04 PM > > Subject: Re: Espressobin anyone ? > > > > > > It might simply be broken in -current (again). > > > > I just updated my stable12 tree and I pulled in new > > > > .dts files for just about anything? > > > > > > Needless to say, it broke the Espressobin?s SD > > > > support, it now fails just like yours.. > > > > > > It also broke allwinner builds and what not, so I?m > > > > just going back in time again :) > > > > > > I wonder why there is this overwhelming need to > > > > import stuff that breaks things right, left and center in a -stable bra= nch > > ? > > > > That would have earned you the pointy hat back when?. > > > > -S=C3=B8ren > > > > > > On 14 Aug 2019, at 18.01, Mit Matelske > > > > wrote: > > > > > > Marcin- > > > > Sorry I didn't reply yesterday. I didn't have any > > > > luck with that either. I tried a lot of permutations. > > > > > > Not saying for 100% it doesn't work, but I couldn't > > > > get it to work! > > > > > > Mit > > > > From: "Marcin Wojtas" > > > mw@semihalf.com>> > > > > To: "Mit Matelske" > > > Cc: "S=C3=B8ren Schmidt" > > > soren.schmidt@gmail.com>>, "freebsd-arm" > > > > > > Sent: Wednesday, August 14, 2019 10:41:04 AM > > Subject: Re: Espressobin anyone ? > > > > Hi Mit, > > Since you are using the latest 13-current, could you > > > > please try if passing rootdev via u-boot bootargs (please see my previo= us > > email) works for you without the loader modification? > > > > > > Best regards, > > Marcin > > > > ?r., 14 sie 2019 o 16:29 Mit Matelske > > > > napisa?(a): > > > > Soren- > > > > Thanks for the info. I'll grab a couple more SD > > > > cards at lunch. This one is a new Samsung 32GB. I'll also try putting= the > > changes into 12 and see if that helps. I'm using the latest 13-current= . > > > > > > Again, appreciate the hand holding! > > > > Mit > > > > From: "S=C3=B8ren Schmidt" > > > > > > > > To: "Mit Matelske" > > > Cc: "Marcin Wojtas" > > > mw@semihalf.com>>, "freebsd-arm" > freebsd-arm@freebsd.org>> > > > > Sent: Wednesday, August 14, 2019 2:30:31 AM > > Subject: Re: Espressobin anyone ? > > > > Hi Mit > > Hmm, from your earlier posted dmesgs it looks like > > > > the SD card is not getting detected properly.. > > > > > > I get this output: > > > > sdhci_xenon0: mem > > > > 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 > > > > mmc0: on sdhci_xenon0 > > ?snip? > > mmcsd0: 16GB > > > by 39 PH> at mmc0 50.0MHz/4bit/65535-block > > > > > > The problem you see was fixed for me by r348882, > > > > maybe it got broken later, I havn?t backported the later changes.. > > > > > > Have you tried another SD card ? I have found 2 of > > > > mine that the espressobin doesn?t like, but works fine with bananapi an= d > > friends... > > > > > > -S=C3=B8ren > > > > On 13 Aug 2019, at 23.30, Mit Matelske > > > > wrote: > > > > > > Soren- > > > > Thanks for the code snippet! That will fix one of > > > > the problems. > > > > > > I still can't mount my filesystem, though. I think > > > > I'm doing something really simple, wrong. I believe I'm running the la= test > > code and added some printfs to show the kernel setting the regulator: > > > > > > > > usbus1 on ehci0 > > syscon_generic4: mem 0x5f800-0x5ffff on > > > > simplebus1 > > > > sdhci_xenon0: > > > > regulator_get_by_ofw_property(vqmmc-supply) =3D 19 > > > > sdhci_xenon0: vqmmc-supply regulator found > > sdhci_xenon0: mem > > > > 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 > > > > ahci0: mem 0xe0000-0xe0177 irq > > > > 26 on simplebus1 > > > > > > > > Could there be a problem with how I am setting up my > > > > filesystem? I've tried both freebsd-ufs and freebsd as the type, with = no > > luck. A gpart listing of my SD card: > > > > > > root@fbl:~ # gpart list da3 > > Geom name: da3 > > modified: false > > state: OK > > fwheads: 255 > > fwsectors: 63 > > last: 62521335 > > first: 3 > > entries: 4 > > scheme: GPT > > Providers: > > 1. Name: da3p1 > > Mediasize: 41943040 (40M) > > Sectorsize: 512 > > Stripesize: 0 > > Stripeoffset: 1536 > > Mode: r0w0e0 > > efimedia: > > > > HD(1,GPT,19894dc5-b8b2-11e9-871f-08008a0010e0,0x3,0x14000) > > > > rawuuid: 19894dc5-b8b2-11e9-871f-08008a0010e0 > > rawtype: c12a7328-f81f-11d2-ba4b-00a0c93ec93b > > label: (null) > > length: 41943040 > > offset: 1536 > > type: efi > > index: 1 > > end: 81922 > > start: 3 > > 2. Name: da3p2 > > Mediasize: 31968979456 (30G) > > Sectorsize: 512 > > Stripesize: 0 > > Stripeoffset: 41944576 > > Mode: r0w0e0 > > efimedia: > > > > HD(2,GPT,98786462-be30-11e9-ae6e-08008a0010e0,0x14003,0x3b8bff5) > > > > rawuuid: 98786462-be30-11e9-ae6e-08008a0010e0 > > rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b > > label: (null) > > length: 31968979456 > > offset: 41944576 > > type: freebsd-ufs > > index: 2 > > end: 62521335 > > start: 81923 > > Consumers: > > 1. Name: da3 > > Mediasize: 32010928128 (30G) > > Sectorsize: 512 > > Mode: r0w0e0 > > > > Thanks!! > > > > Mit > > > > From: "S=C3=B8ren Schmidt" > > > > > > > > To: "Marcin Wojtas" > > > mw@semihalf.com>> > > > > Cc: "Mit Matelske" >, > > > > "freebsd-arm" > freebsd-arm@freebsd.org>> > > > > Sent: Tuesday, August 13, 2019 12:55:09 PM > > Subject: Re: Espressobin anyone ? > > > > Hi > > That doesn?t seen to work on the espressobin, or > > > > least I can?t get it to pick it up. > > > > > > I use this patch as a workaround: > > > > Index: main.c > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > --- main.c (revision 350496) > > +++ main.c (working copy) > > @@ -463,6 +462,13 @@ > > int rv; > > char *rootdev; > > > > +#if defined(__aarch64__) > > + /* SOS HACK in rootdev, at least Espressobin > > > > gets this wrong */ > > > > + printf("Setting currdev hack\n"); > > + set_currdev("disk0p2"); > > + return (0); > > +#endif > > + > > /* > > * First choice: if rootdev is already set, use > > > > that, even if > > > > * it's wrong. > > > > Its not pretty but it does the job until I get time > > > > to look into why bootargs aren?t passed / won?t stick, probably somethi= ng I > > havn?t backported to my -stable12 sources yet... > > > > > > -S=C3=B8ren > > > > On 13 Aug 2019, at 01.38, Marcin Wojtas < > > > > mw@semihalf.com > wrote: > > > > > > Hi, > > > > Not sure if it's what you are looking for, but in > > > > order to autoboot, I > > > > simply pass 'rootdev=3DdiskXpY' in the bootargs > > > > variable. Here's example from > > > > A3720-DB (same should work on EspressoBin): > > > > Marvell>> set bootargs "rootdev=3Ddisk1p1";usb reset; > > > > fatload usb 0:1 > > > > ${fdt_addr} armada-3720-db.dtb; fatload usb 0:1 > > > > ${kernel_addr} > > > > boot/loader.efi; bootefi ${kernel_addr} ${fdt_addr} > > resetting USB... > > USB0: Register 2000104 NbrPorts 2 > > Starting the controller > > USB XHCI 1.00 > > USB1: USB EHCI 1.00 > > - ______ ____ _____ _____ > > | ____| | _ \ / ____| __ \ > > | |___ _ __ ___ ___ | |_) | (___ | | | | > > | ___| '__/ _ \/ _ \| _ < \___ \| | | | > > | | | | | __/ __/| |_) |____) | |__| | > > | | | | | | || | | | > > |_| |_| \___|\___||____/|_____/|_____/ > > ``` > > ` > > ????????????Welcome to FreeBSD????????????? s` > > > > `.....---.......--.``` > > > > -/ > > ? ? +o > > > > .--` /y:` > > > > +. > > ? 1. Boot Multi user [Enter] ? > > > > yo`:. :o > > > > `+- > > ? 2. Boot Single user ? y/ > > > > -/` -o/ > > > > ? 3. Escape to loader prompt ? .- > > ::/sy+:. > > ? 4. Reboot ? / > > > > `-- > > > > / > > ? ? `: > > :` > > ? Options: ? `: > > :` > > ? 5. Kernel: default/kernel (1 of 1) ? / > > / > > ? 6. Boot Options ? .- > > -. > > ? ? -- > > > > -. > > > > ? ? > > > > `:` `:` > > > > ? ? > > > > .-- `--. > > > > ??????????????????????????????????????????? > > > > .---.....----. > > > > Autoboot in 9 seconds, hit [Enter] to boot or any > > > > other key to stop > > > > > > Loading kernel... > > /boot/kernel/kernel text=3D0x95047c > > > > data=3D0x1919d0+0x84aa94 > > > > syms=3D[0x8+0x13aaa8+0x8+0x12610d] > > Loading configured modules... > > can't find '/boot/entropy' > > Using DTB provided by EFI at 0x8000000. > > ---<>--- > > KDB: debugger backends: ddb > > KDB: current backend: ddb > > Copyright (c) 1992-2019 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, > > > > 1991, 1992, 1993, 1994 > > > > The Regents of the University of California. All > > > > rights reserved. > > > > FreeBSD is a registered trademark of The FreeBSD > > > > Foundation. > > > > FreeBSD 13.0-CURRENT > > > > 17a1fc80d57-c261519(upstream_master) GENERIC arm64 > > > > FreeBSD clang version 8.0.0 (tags/RELEASE_800/final > > > > 356365) (based on LLVM > > > > 8.0.0) > > WARNING: WITNESS option enabled, expect reduced > > > > performance. > > > > VT: init without driver. > > Starting CPU 1 (1) > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > [...] > > > > Best regards, > > Marcin > > > > pon., 12 sie 2019 o 23:14 Mit Matelske > > > > napisa?(a): > > > > > > > > Soren- > > > > Thanks for the quick response. I built this kernel > > > > with revision 350924. > > > > I'll dig into whats going on in the morning. > > > > Mind posting your diff for your loader.efi? > > > > Thanks again! > > > > Mit > > > > > > ----- Original Message ----- > > From: "S=C3=B8ren Schmidt" > > > > > > > > To: "Mit Matelske" > > > Cc: "tscho" > > > johannes@t-beutel.com>>, "freebsd-arm" < > > > > freebsd-arm@freebsd.org > > > freebsd-arm@freebsd.org>> > > > > Sent: Monday, August 12, 2019 3:49:48 PM > > Subject: Re: Espressobin anyone ? > > > > Hi > > > > Looks like your sources may be too old, you need to > > > > be at least at r348882 > > > > to get the fix for the SD card VCC regulator. > > > > That change fixed it for me backported to 12-stable... > > > > The currdev problem still exists, I have it hardwired > > > > in my loader for > > > > aarch64 :) > > > > -S=C3=B8ren > > > > > > On 12 Aug 2019, at 21.06, Mit Matelske > > > > wrote: > > > > > > I'm having a couple little hiccups booting this board > > > > also. One has > > > > been commented on already, that I can't get the > > > > loader to automatically > > > > start loading the kernel on "disk0p2"... > > > > The second, is that the kernel can't find the SD card > > > > after booting so > > > > it can't mount the root filesystem. I'm using the > > > > dts/dtb and kernel from > > > > the 13-current branch. > > > > Thanks for any and all help. I haven't used u-boot > > > > in about decade. > > > > Spoiled by the x86 platform. > > > > Mit Matelske > > > > > > ***U-boot environment:*** > > > > > > Marvell>> printenv > > baudrate=3D115200 > > bootargs=3Dconsole=3DttyMV0,115200 > > > > earlycon=3Dar3700_uart,0xd0012000 > > > > root=3D/dev/mmcblk0p1 rw rootwait net.ifnames=3D0 > > > > biosdevname=3D0 > > > > bootcmd=3Dmmc dev 0; fatload mmc 0:1 $kernel_addr > > > > $image_name;fatload mmc > > > > 0:1 $fdt_addr $fdt_name; bootefi $kernel_addr > > > > $fdt_addr > > > > bootdelay=3D2 > > bootmmc=3Dmmc dev 0; fatload mmc 0:1 $kernel_addr > > > > $image_name;fatload mmc > > > > 0:1 $fdt_addr $fdt_name; bootefi $kernel_addr > > > > $fdt_addr > > > > console=3Dconsole=3DttyMV0,115200 > > > > earlycon=3Dar3700_uart,0xd0012000 > > > > eth1addr=3D00:51:82:11:22:01 > > eth2addr=3D00:51:82:11:22:02 > > eth3addr=3D00:51:82:11:22:03 > > ethact=3Dneta@30000 > > ethaddr=3DF0:AD:4E:09:6B:8F > > ethprime=3Deth0 > > fdt_addr=3D0x4f00000 > > fdt_high=3D0xffffffffffffffff > > fdt_name=3Defi/boot/armada-3720-espressobin.dtb > > fdtcontroladdr=3D3f7161b8 > > gatewayip=3D10.4.50.254 > > get_images=3Dtftpboot $kernel_addr $image_name; > > > > tftpboot $fdt_addr > > > > $fdt_name; run get_ramfs > > get_ramfs=3Dif test "${ramfs_name}" !=3D "-"; then setenv > > > > ramfs_addr > > > > 0x8000000; tftpboot $ramfs_addr $ramfs_name; else > > > > setenv ramfs_addr -;fi > > > > hostname=3Dmarvell > > image_name=3Defi/freebsd/loader.efi > > initrd_addr=3D0xa00000 > > initrd_size=3D0x2000000 > > ipaddr=3D0.0.0.0 > > kernel_addr=3D0x5000000 > > loadaddr=3D0x5000000 > > netdev=3Deth0 > > netmask=3D255.255.255.0 > > ramfs_addr=3D0x8000000 > > ramfs_name=3D- > > root=3Droot=3D/dev/nfs rw > > rootpath=3D/srv/nfs/ > > serverip=3D0.0.0.0 > > set_bootargs=3Dsetenv bootargs $console $root > > > > ip=3D$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:none > > > > nfsroot=3D$serverip:$rootpath $extra_params > > stderr=3Dserial@12000 > > stdin=3Dserial@12000 > > stdout=3Dserial@12000 > > > > > > ***Full boot logs:*** > > > > > > U-Boot 2017.03-armada-17.10.2-g14aeedc (Jun 01 2018 - > > > > 15:39:10 +0800) > > > > > > Model: Marvell Armada 3720 Community Board ESPRESSOBin > > CPU @ 1000 [MHz] > > L2 @ 800 [MHz] > > TClock @ 200 [MHz] > > DDR @ 800 [MHz] > > DRAM: 1 GiB > > U-Boot DT blob at : 000000003f7161b8 > > Comphy-0: USB3 5 Gbps > > Comphy-1: PEX0 2.5 Gbps > > Comphy-2: SATA0 6 Gbps > > SATA link 0 timeout. > > AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA > > > > mode > > > > flags: ncq led only pmp fbss pio slum part sxs > > PCIE-0: Link down > > MMC: sdhci@d0000: 0, sdhci@d8000: 1 > > SF: Detected mx25u3235f with page size 256 Bytes, > > > > erase size 64 KiB, > > > > total 4 MiB > > Net: eth0: neta@30000 [PRIME] > > Hit any key to stop autoboot: 0 > > switch to partitions #0, OK > > mmc0 is current device > > reading efi/freebsd/loader.efi > > 603872 bytes read in 49 ms (11.8 MiB/s) > > reading efi/boot/armada-3720-espressobin.dtb > > 15946 bytes read in 17 ms (916 KiB/s) > > ## Starting EFI application at 05000000 ... > > Scanning disk sdhci@d0000.blk > > > ... > > > > Card did not respond to voltage select! > > mmc_init: -95, time 50 > > Found 1 disks > > Consoles: EFI console > > FreeBSD/arm64 EFI loader, Revision 1.1 > > > > Command line arguments: loader.efi > > EFI version: 2.05 > > EFI Firmware: Das U-boot (rev 0.00) > > Console: efi (0) > > Failed to find bootable partition > > Startup error in /boot/lua/loader.lua: seconds > > LUA ERROR: cannot open /boot/lua/loader.lua: invalid > > > > argument. > > > > > > can't load 'kernel' > > > > Type '?' for a list of commands, 'help' for more > > > > detailed help. > > > > OK > > OK set currdev=3Ddisk0p2 > > OK boot > > > > /boot/kernel/kernel text=3D0x97d6a0 > > > > data=3D0x191b50+0x84ae94 > > > > syms=3D[0x8+0x137dd8+0x8+0x126260] > > Using DTB provided by EFI at 0x8000000. > > ---<>--- > > KDB: debugger backends: ddb > > KDB: current backend: ddb > > Copyright (c) 1992-2019 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, > > > > 1991, 1992, 1993, 1994 > > > > The Regents of the University of California. All > > > > rights reserved. > > > > FreeBSD is a registered trademark of The FreeBSD > > > > Foundation. > > > > FreeBSD 13.0-CURRENT GENERIC arm64 > > FreeBSD clang version 6.0.1 (tags/RELEASE_601/final > > > > 335540) (based on > > > > LLVM 6.0.1) > > WARNING: WITNESS option enabled, expect reduced > > > > performance. > > > > VT: init without driver. > > Starting CPU 1 (1) > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > arc4random: WARNING: initial seeding bypassed the > > > > cryptographic random > > > > device because it was not yet seeded and the knob > > > > 'bypass_before_seeding' > > > > was enabled. > > random: entropy device external interface > > MAP 3e681000 mode 2 pages 1 > > MAP 3ffa6000 mode 2 pages 1 > > kbd0 at kbdmux0 > > ofwbus0: > > simplebus0: on > > > > ofwbus0 > > > > simplebus1: on > > > > simplebus0 > > > > simple_mfd0: mem > > 0x13800-0x138ff,0x13c00-0x13c1f on simplebus1 > > simple_mfd1: mem > > 0x18800-0x188ff,0x18c00-0x18c1f on simplebus1 > > psci0: > > > Driver> on ofwbus0 > > > > gic0: mem > > > > > > 0x1d00000-0x1d0ffff,0x1d40000-0x1d7ffff,0x1d80000-0x1d81fff,0x1d90000-0= x1d91fff,0x1da0000-0x1dbffff > > > > irq 27 on simplebus1 > > gpio0: 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: 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: on ofwbus0 > > gpioregulator0: cannot get pin 0 > > gpioregulator0: cannot parse parameters > > device_attach: gpioregulator0 attach returned 6 > > generic_timer0: irq 0,1,2,3 on > > > > ofwbus0 > > > > Timecounter "ARM MPCore Timecounter" frequency > > > > 12500000 Hz quality 1000 > > > > Event timer "ARM MPCore Eventtimer" frequency > > > > 12500000 Hz quality 1000 > > > > gpio0: 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: 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: on ofwbus0 > > gpioregulator0: cannot get pin 0 > > gpioregulator0: cannot parse parameters > > device_attach: gpioregulator0 attach returned 6 > > gpio0: 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: 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: on ofwbus0 > > gpioregulator0: cannot get pin 0 > > gpioregulator0: cannot parse parameters > > device_attach: gpioregulator0 attach returned 6 > > gpio0: 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: 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: on ofwbus0 > > gpioregulator0: cannot get pin 0 > > gpioregulator0: cannot parse parameters > > device_attach: gpioregulator0 attach returned 6 > > gpio0: 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: 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: on ofwbus0 > > gpioregulator0: cannot get pin 0 > > gpioregulator0: cannot parse parameters > > device_attach: gpioregulator0 attach returned 6 > > cpulist0: on ofwbus0 > > cpu0: on cpulist0 > > cpu1: on cpulist0 > > pmu0: irq 4 on ofwbus0 > > syscon_generic0: mem 0xd000-0xdfff on > > > > simplebus1 > > > > syscon_generic1: mem 0x11500-0x1153f on > > > > simplebus1 > > > > uart0: mem 0x12000-0x121ff > > > > irq 9,10,11 on > > > > simplebus1 > > uart0: console (115200,n,8,1) > > gpio0: 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: mem 0x14000-0x1405f on > > > > simplebus1 > > > > gpio0: 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: mem 0x30000-0x33fff irq 14 > > > > on simplebus1 > > > > mvneta0: version is 10 > > mvneta0: Ethernet address: 00:a6:39:ca:e8:00 > > mdio0: on mvneta0 > > mdioproxy0: on mdio0 > > e6000sw0: on mdio0 > > e6000sw0: multi-chip addressing mode (0x1) > > e6000sw0: CPU port at 0 > > e6000sw0: fixed port at 0 > > e6000sw0: PHY at port 1 > > miibus0: on e6000sw0 > > e1000phy0: 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: on e6000sw0 > > e1000phy1: 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: on e6000sw0 > > e1000phy2: 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: on e6000sw0 > > xhci0: mem > > > > 0x58000-0x5bfff irq 16 on > > > > simplebus1 > > xhci0: 32 bytes context size, 32-bit DMA > > usbus0 on xhci0 > > syscon_generic3: mem 0x5d800-0x5dfff on > > > > simplebus1 > > > > ehci0: mem > > > > 0x5e000-0x5efff irq > > > > 17 on simplebus1 > > usbus1: EHCI version 1.0 > > usbus1 on ehci0 > > syscon_generic4: mem 0x5f800-0x5ffff on > > > > simplebus1 > > > > sdhci_xenon0: mem > > 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 > > ahci0: mem 0xe0000-0xe0177 irq > > > > 26 on simplebus1 > > > > ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier > > > > supported with FBS > > > > ahcich0: at channel 0 on ahci0 > > device_attach: ahcich0 attach returned 6 > > gpioregulator0: on ofwbus0 > > gpioregulator0: cannot get pin 0 > > gpioregulator0: cannot parse parameters > > device_attach: gpioregulator0 attach returned 6 > > cryptosoft0: > > 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 > > > > > > > > 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 > > > > usbus1 Processor Features 1 =3D <0> > > usbus0 Memory Model Features 0 =3D <4k Granule,64k > > > > Granule,S/NS > > > > Mem,MixedEndian,16bit ASID,1TB PA> > > > > Memory Model Features 1 =3D <> > > Memory Model Features 2 =3D <32b CCIDX,48b VA> > > Debug Features 0 =3D <2 CTX Breakpoints,4 > > > > Watchpoints,6 > > > > Breakpoints,PMUv3,Debug v8> > > Debug Features 1 =3D <0> > > Auxiliary Features 0 =3D <0> > > Auxiliary Features 1 =3D <0> > > CPU 1: ARM Cortex-A53 r0p4 affinity: 1 > > WARNING: WITNESS option enabled, expect reduced > > > > performance. > > > > ugen0.1: at usbus0 > > ugen1.1: at usbus1 > > uhub0 on usbus0 > > uhub1 on usbus1 > > uhub0: > > > 3.00/1.00, addr 1> on > > > > usbus0 > > uhub1: > > > 2.00/1.00, addr 1> on > > > > usbus1 > > uhub0: 2 ports with 2 removable, self powered > > uhub1: 1 port with 1 removable, self powered > > mountroot: waiting for device > > > > /dev/ufs/FreeBSD_Install... > > > > Mounting from ufs:/dev/ufs/FreeBSD_Install failed > > > > with error 19. > > > > > > Loader variables: > > vfs.root.mountfrom=3Dufs:/dev/ufs/FreeBSD_Install > > vfs.root.mountfrom.options=3Dro,noatime > > > > Manual root filesystem specification: > > : [options] > > Mount using filesystem > > and with the specified (optional) option list. > > > > eg. ufs:/dev/da0s1a > > zfs:zroot/ROOT/default > > cd9660:/dev/cd0 ro > > (which is equivalent to: mount -t cd9660 -o ro > > > > /dev/cd0 /) > > > > > > ? List valid disk boot devices > > . Yield 1 second (for background tasks) > > Abort manual input > > > > mountroot> ? > > > > List of GEOM managed disk devices: > > > > > > mountroot> > > _______________________________________________ > > freebsd-arm@freebsd.org > > > 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 > freebsd-arm-unsubscribe@freebsd.org>" > > > > > > _______________________________________________ > > freebsd-arm@freebsd.org > > > 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 > freebsd-arm-unsubscribe@freebsd.org>" > > > > > > > > > > -- > > Emmanuel Vadot < > > > > manu@freebsd.org> > > > > > > > > > > -- > > Emmanuel Vadot > > > > > > > > -- > > Emmanuel Vadot > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to " > > > > freebsd-arm-unsubscribe@freebsd.org" > > > > > > > > -- > > Emmanuel Vadot > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to " > > > > freebsd-arm-unsubscribe@freebsd.org" > > > > > > > > -- > > Emmanuel Vadot > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to " > > > > freebsd-arm-unsubscribe@freebsd.org" > > > > > > > > -- > > Emmanuel Vadot > > > manu@bidouilliste.com>> > > > > > > > > > > > -- > > Emmanuel Vadot > > > manu@bidouilliste.com>> > > > > > > > > > > > -- > > Emmanuel Vadot > > _______________________________________________ > > 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 From owner-freebsd-arm@freebsd.org Tue Aug 20 12:46:09 2019 Return-Path: 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 51FAED178C for ; Tue, 20 Aug 2019 12:46:09 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46CVsD2LT6z4KJT for ; Tue, 20 Aug 2019 12:46:07 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Date: Tue, 20 Aug 2019 14:46:06 +0200 (CEST) From: Ronald Klop To: Jeffrey Bowers Cc: =?utf-8?Q?S=C3=B8ren_Schmidt?= , freebsd-arm Message-ID: <2002575095.53.1566305166664@localhost> In-Reply-To: References: <1547777156.662147.1565798461515.JavaMail.zimbra@perftech.com> <0E42E605-477E-4E65-810E-BD3A8CDE2C80@gmail.com> <973015183.1067498.1565890674099.JavaMail.zimbra@perftech.com> <20190815210311.1035f64b003e2bc85fa47ca8@bidouilliste.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> <20190817153053.5592b15b8a42982fda0fc123@bidouilliste.com> <9749945A-FDAD-47E0-947A-FA62138C2F83@gmail.com> <20190817210822.8920656bad0855b554883cf2@bidouilliste.com> <2D6D4BDA-75EC-403F-B5E2-52A468369DE2@gmail.com> <627099DD-804B-412F-A083-768CEFCF955C@gmail.com> <6DA8E736-8031-4BF7-8B20-CF8B0E8A7FEF@gmail.com> Subject: Re: Espressobin anyone ? MIME-Version: 1.0 X-Mailer: Realworks (471.1011.ce02e15a2ad) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 46CVsD2LT6z4KJT X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 194.109.157.24 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws X-Spamd-Result: default: False [-1.61 / 15.00]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.79)[-0.792,0]; HAS_X_PRIO_THREE(0.00)[3]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; SUBJECT_ENDS_QUESTION(1.00)[]; SH_EMAIL_ZRD(0.00)[0.0.46.224,0.0.117.48]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.981,0]; FROM_HAS_DN(0.00)[]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.117.48,0.0.46.224]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-0.98)[-0.982,0]; TAGGED_RCPT(0.00)[]; DMARC_NA(0.00)[klop.ws]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[24.157.109.194.list.dnswl.org : 127.0.15.0]; IP_SCORE(-0.06)[ipnet: 194.109.0.0/16(-0.16), asn: 3265(-0.13), country: NL(0.01)]; MID_RHS_NOT_FQDN(0.50)[]; FREEMAIL_CC(0.00)[gmail.com] Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 12:46:09 -0000 It is not possible to 'ping https://svn.freebsd.org/ports/head'. You can 'ping svn.freebsd.org'. Ronald. =20 Van: Jeffrey Bowers Datum: dinsdag, 20 augustus 2019 14:36 Aan: "S=C3=B8ren Schmidt" , freebsd-arm Onderwerp: Re: Espressobin anyone ? >=20 > I just tried to ping https://svn.freebsd.org/ports/head, and even though > it scrolsl through all that text I get an error saying "could not resolve > https://svn.freebsd.org/ports/head ; unknown server error" . I can ping > google just fine. Is it a DNS issue? >=20 > On Tue, Aug 20, 2019 at 7:33 AM Jeffrey Bowers wrot= e: >=20 > > I'm still getting: svn: E000060: Operation timed out > > It goes for several minutes scrolling through text, and I feel like usi= ng > > your link got further. > > > > Thanks! > > > > On Tue, Aug 20, 2019 at 2:49 AM S=C3=B8ren Schmidt > > wrote: > > > >> Hmm, I use this URL > >> > >> Repository Root: https://svn.freebsd.org/ports/head > >> > >> Not sure the svn+ssh thing works=E2=80=A6 > >> > >> -S=C3=B8ren > >> > >> > >> On 20 Aug 2019, at 02.38, Jeffrey Bowers wrote: > >> > >> Hi all, > >> > >> I'm having trouble getting subversion to work. When I run: > >> > >> svn checkout https://svn.FreeBSD.org/ports/head /usr/ports > >> > >> It scrolls through many lines of text before stating: svn: E000060: > >> Operation timed out > >> > >> When I run: > >> > >> svn checkout svn+ssh://repo.freebsd.org/ports/head /usr/ports > >> > >> It tells me that the authenticity of the host cannot be identified, an= d > >> asks me to confirm that I want to connect. I say yes, and then it says= : > >> > >> svn: E170013: Unable to connect to a repository at URL 'svn+ssh:// > >> repo.freebsd.org/ports/head' > >> svn: E210002: To better debug SSH connection problems, remove the -q > >> option > >> from 'ssh' in the [tunnels] section of your Subversion configuration f= ile. > >> > >> Any ideas? > >> > >> Thanks in advance! > >> > >> On Mon, Aug 19, 2019 at 8:51 PM Jeffrey Bowers > >> wrote: > >> > >> I didn't think it remounting. Thank you! > >> > >> On Mon, Aug 19, 2019 at 11:39 AM S=C3=B8ren Schmidt > >> wrote: > >> > >> Hi Jeffrey > >> > >> You need to unmount the /tmp filesystem :) > >> You can do that permanently by commenting it out in /etc/fstab > >> > >> > >> On 19 Aug 2019, at 21.45, Jeffrey Bowers wrote: > >> > >> Hi Soren, > >> > >> I'm getting the same error message. Any other ideas what it might be? > >> It's got to be something in the partition scheme or the file permissio= ns, > >> but I'm just not sure what. > >> > >> > >> On Sun, Aug 18, 2019 at 10:03 AM Jeffrey Bowers > >> wrote: > >> > >> D=E2=80=99Oh! I thought I too care of that with gpart. I literally mis= sed growfs > >> part of the instructions.. > >> > >> On Sun, Aug 18, 2019 at 10:00 AM S=C3=B8ren Schmidt > >> wrote: > >> > >> Hi > >> > >> You are out of space :) > >> > >> Boot the board into singleuser mode, and do =E2=80=9Cservice growfs st= art=E2=80=9D, > >> that will expand you / filesystem to the entire SD card=E2=80=A6 > >> > >> -S=C3=B8ren > >> > >> On 18 Aug 2019, at 14.50, Jeffrey Bowers wrote: > >> > >> Sure thing! Here's the screenshot! > >> > >> > >> > >> On Sun, Aug 18, 2019 at 7:35 AM S=C3=B8ren Schmidt > >> wrote: > >> > >> Hi > >> > >> Can I have you paste the output from df -h ? > >> > >> You should be able to utilise the full SD card=E2=80=A6 > >> > >> -S=C3=B8ren > >> > >> On 18 Aug 2019, at 14.29, Jeffrey Bowers wrote: > >> > >> Hi, > >> > >> Just make sure I understand the process, I should hook up a hard disk > >> and map it to to /TMP ? > >> > >> I already tried just unmapping /tmp, and it gave me the same error > >> once, and then the next time I ran it I got an error saying /usr/ports= was > >> out of space )which I guess I shouldn=E2=80=99t mount to another direc= tor on the > >> hard drive? > >> > >> On Sun, Aug 18, 2019 at 5:11 AM S=C3=B8ren Schmidt > >> wrote: > >> > >> Hi Jeffrey > >> > >> You can unmount the memory disk on /tmp to get at the space on the SD > >> card. > >> > >> It is however not recommend to use the AD card for random storage, it > >> will wear out fast, that=E2=80=99s why the memory disk is setup. > >> > >> You could connect a SSD og laptop disk to the SATA interface and use > >> that for the workload. > >> > >> However compiling is slow, its much much faster to cross compile on a > >> PC=E2=80=A6 > >> > >> -S=C3=B8ren > >> > >> On 18 Aug 2019, at 00.22, Jeffrey Bowers wrote: > >> > >> Hi! I've got a new one :) > >> I'm trying to do an svn checkout to fix the pkg problem, but it tells > >> me it can't write to a to a temp folder because there is no room left = on > >> the device. However, FreeBSD partition is 29GB. It's never also never = the > >> same file in TMP that it can't write to. Here is a screenshot of the > >> issue, > >> along with the output of gpart: > >> > >> > >> > >> Any ideas? > >> > >> Thanks! > >> > >> > >> On Sat, Aug 17, 2019 at 2:08 PM Emmanuel Vadot > >> wrote: > >> > >> On Sat, 17 Aug 2019 17:14:36 +0200 > >> S=C3=B8ren Schmidt wrote: > >> > >> HI > >> > >> Well, I have a whole forrest of tree?s here, but the error posted > >> > >> here was on a clean checkout. > >> > >> > >> Anyhow, with the latest changes to -stable and the two > >> > >> RF_SHAREABLE patches from -current all works. > >> > >> I've reverted the commits, see > >> https://github.com/evadot/freebsd/commits/a37x0_gpio for a better > >> way > >> to deal with this issue. > >> I'm waiting for mmel@ as he wrote the syscon_get_default_handle > >> part. > >> > >> It would be nice with the etherswitch changes as well so VLAN > >> > >> tagging etc was standard. > >> > >> > >> -S=C3=B8ren > >> > >> PS: given up on bottom & inline popsting, top posting is all the > >> > >> rage now (yeah I miss elm etc :) ) > >> > >> > >> On 17 Aug 2019, at 15.30, Emmanuel Vadot > >> > >> wrote: > >> > >> > >> On Sat, 17 Aug 2019 11:07:22 +0200 > >> S=C3=B8ren Schmidt >> > >> soren.schmidt@gmail.com>> wrote: > >> > >> > >> Hi Emmunuel > >> > >> Yes the 3720 gpio driver I already back ported long ago, its > >> > >> needed, I?m happy its now part of std stable 12! > >> > >> > >> Would have been nice of you to say that you were not running a > >> > >> clean > >> > >> tree. > >> > >> My issue seems to be the inclusion of the phy_usb driver, if I > >> > >> leave that out, I?m back to normal.. > >> > >> > >> What make you think this is this driver ? What works/doesn't work > >> with it ? could you provide logs. > >> > >> I?ll have have another go at the latest -stable sources during > >> > >> the weekend and see how it goes. > >> > >> > >> Thanks for looking into this, with a little cooperation we?ll > >> > >> get this solved for the greater good.. > >> > >> > >> -S=C3=B8ren > >> > >> > >> P.S. Please stop top posting, it's really hard to read the > >> > >> conversation > >> > >> > >> On 16 Aug 2019, at 22.58, Emmanuel Vadot < > >> > >> manu@bidouilliste.com> wrote: > >> > >> > >> On Fri, 16 Aug 2019 19:12:30 +0200 > >> Emmanuel Vadot >> > >> manu@bidouilliste.com>> wrote: > >> > >> > >> On Fri, 16 Aug 2019 17:10:37 +0200 > >> Emmanuel Vadot wrote: > >> > >> On Fri, 16 Aug 2019 15:24:54 +0200 > >> Emmanuel Vadot wrote: > >> > >> On Fri, 16 Aug 2019 07:28:59 +0200 > >> S=C3=B8ren Schmidt wrote: > >> > >> Hi > >> > >> Very simple, reverting sys/gnu/dts to what was before > >> > >> 350595 (actually 350592). > >> > >> Thats what we have svn for ? > >> > >> > >> If I asked how it was to have the svn command that you > >> > >> used, I want to > >> > >> make sure that you didn't revert anything else, like do you > >> > >> have > >> > >> r350596 and r350628 ? > >> > >> That does make my bananapi work again, no other changes > >> > >> just a recompiled kernel. > >> > >> > >> That + copying the dtb to the fat32 partition ? > >> > >> Can you post the dtb somewhere. > >> > >> However it does not bring the Espressobin back to life, > >> > >> thats something in one of the ~30 other files that changed between tho= se > >> two revisions. > >> > >> > >> What Linux version of DTS are you using then ? The ones > >> > >> that were in > >> > >> stable/12 when it was branched (4.18) or a later revision ? > >> > >> > >> So I think that I've found the problem on the Espressobin. > >> I think that the problem comes from the simple-mfd driver > >> > >> that I've > >> > >> mfc in r350600. > >> The pinctrl/gpio controller compatible is > >> "marvell,armada3710-nb-pinctrl", "syscon", "simple-mfd" and > >> > >> it attaches > >> > >> at BUS_PASS_INTERRUPT while the simple_mfd driver attaches at > >> BUS_PASS_BUS (so earlier) which means that no gpio > >> > >> controller will be > >> > >> available for sdhci to detect the card. > >> > >> If someone with a non-working espressobin could post a full > >> > >> verbose > >> > >> boot log that would help me confirming that this is the case. > >> I'll try to find a solution on how to solve this problem. > >> > >> > >> So this wasn't the problem but I've found it, see r351129 and > >> > >> r351130 > >> > >> > >> SD card now work again in HEAD, I'll have a look at stable > >> > >> later next > >> > >> week. > >> > >> > >> I've did a quick test and I've MFC r348880, r348882 and > >> > >> r349596, the > >> > >> two other commits needed to be mfc'ed are the one I did today > >> > >> on head, > >> > >> I'll do that next week. > >> With them sdcard is working again on stable/12 > >> > >> -S=C3=B8ren > >> > >> On 15 Aug 2019, at 23.37, Emmanuel Vadot < > >> > >> manu@bidouilliste.com> wrote: > >> > >> > >> On Thu, 15 Aug 2019 21:56:23 +0200 > >> S=C3=B8ren Schmidt wrote: > >> > >> > >> Well, I don?t care where you are from and what color you > >> > >> have :) > >> > >> > >> Now, if I update my stable12 sources to r350595 the > >> > >> bananapi breaks, if revert sys/gnu/dts it works again, go figure.. > >> > >> > >> Reverting to what ? and how ? > >> > >> Because I've just test 12-stable and I have the problem > >> > >> that I've said > >> > >> in my previous mail so setting > >> > >> hw.regulator.disable_unused=3D0 is the > >> > >> work around. > >> The problem is in twsi not in the DTS so I'm curious how > >> > >> reverting > >> > >> only the dts fixes this problem. > >> > >> The r351099 fix is already like that in -stable, and not > >> > >> part of the problem. > >> > >> > >> -S=C3=B8ren > >> > >> > >> On 15 Aug 2019, at 21.03, Emmanuel Vadot < > >> > >> manu@bidouilliste.com> wrote: > >> > >> > >> On Thu, 15 Aug 2019 19:48:54 +0200 > >> S=C3=B8ren Schmidt wrote: > >> > >> Hi Mit! > >> > >> Right, I suspected that, 12-stable broke many embedded > >> > >> systems between r350592 and r350595 where all the latest and greatest = DTS > >> files was pulled in, I guess the same holds for -current. > >> > >> > >> -S=C3=B8ren > >> > >> > >> Mhm it's fun that you think that DTS import is the > >> > >> source of all your > >> > >> problems, I get it, it's easy to blame the French guy > >> > >> that bulk import > >> > >> the DTS, he surely don't know what he is doing. > >> Anyway, two problems were raised in this thread : > >> > >> 1) BananaPi (A20) doesn't boot > >> 2) Espressobin sd support is broken > >> > >> I've just looked at the BananaPi problem today, I've > >> > >> fixed a first > >> > >> problem in r351099. > >> The main problem is that when we disable the unused > >> > >> regulators we hang > >> > >> when trying to disabling ldo3. It's weird because the > >> > >> board doesn't use > >> > >> LDO3 (which is why we are disabling it, it's unused). > >> > >> The problem is in > >> > >> twsi I think as only leaving the part in axp209 that > >> > >> read the > >> > >> voltage register value make FreeBSD hang. > >> I'll have a proper look later, in the meantime you can > >> > >> set > >> > >> hw.regulator.disable_unused=3D0 > >> in /boot/loader.conf > >> This isn't a DTS problem. > >> > >> For Espressobin I haven't found any thing related to SD > >> > >> in the DTS > >> > >> updates since the import, the only things slighly > >> > >> related are mmc and > >> > >> sdio. > >> So if someone could find which DTS import broke this I > >> > >> can have a look. > >> > >> > >> > >> On 15 Aug 2019, at 19.37, Mit Matelske > >> > >> wrote: > >> > >> > >> Yeah, that was the problem. I went back to r348882 > >> > >> and everything worked out of the box. > >> > >> > >> Thanks again for the hand holding! > >> > >> Mit > >> > >> From: "S=C3=B8ren Schmidt" >> > >> > > >> > >> To: "Mit Matelske" > > >> Cc: "Marcin Wojtas" >> > >> mw@semihalf.com>>, "freebsd-arm" >> freebsd-arm@freebsd.org>> > >> > >> Sent: Wednesday, August 14, 2019 1:33:04 PM > >> Subject: Re: Espressobin anyone ? > >> > >> > >> It might simply be broken in -current (again). > >> > >> I just updated my stable12 tree and I pulled in new > >> > >> .dts files for just about anything? > >> > >> > >> Needless to say, it broke the Espressobin?s SD > >> > >> support, it now fails just like yours.. > >> > >> > >> It also broke allwinner builds and what not, so I?m > >> > >> just going back in time again :) > >> > >> > >> I wonder why there is this overwhelming need to > >> > >> import stuff that breaks things right, left and center in a -stable > >> branch ? > >> > >> That would have earned you the pointy hat back when?. > >> > >> -S=C3=B8ren > >> > >> > >> On 14 Aug 2019, at 18.01, Mit Matelske >> > >> > wrote: > >> > >> > >> Marcin- > >> > >> Sorry I didn't reply yesterday. I didn't have any > >> > >> luck with that either. I tried a lot of permutations. > >> > >> > >> Not saying for 100% it doesn't work, but I couldn't > >> > >> get it to work! > >> > >> > >> Mit > >> > >> From: "Marcin Wojtas" >> > >> mw@semihalf.com>> > >> > >> To: "Mit Matelske" > > >> Cc: "S=C3=B8ren Schmidt" >> > >> soren.schmidt@gmail.com>>, "freebsd-arm" >> > > >> > >> Sent: Wednesday, August 14, 2019 10:41:04 AM > >> Subject: Re: Espressobin anyone ? > >> > >> Hi Mit, > >> Since you are using the latest 13-current, could you > >> > >> please try if passing rootdev via u-boot bootargs (please see my previ= ous > >> email) works for you without the loader modification? > >> > >> > >> Best regards, > >> Marcin > >> > >> ?r., 14 sie 2019 o 16:29 Mit Matelske >> > >> > napisa?(a): > >> > >> Soren- > >> > >> Thanks for the info. I'll grab a couple more SD > >> > >> cards at lunch. This one is a new Samsung 32GB. I'll also try puttin= g > >> the > >> changes into 12 and see if that helps. I'm using the latest 13-curren= t. > >> > >> > >> Again, appreciate the hand holding! > >> > >> Mit > >> > >> From: "S=C3=B8ren Schmidt" >> > >> > > >> > >> To: "Mit Matelske" > > >> Cc: "Marcin Wojtas" >> > >> mw@semihalf.com>>, "freebsd-arm" >> freebsd-arm@freebsd.org>> > >> > >> Sent: Wednesday, August 14, 2019 2:30:31 AM > >> Subject: Re: Espressobin anyone ? > >> > >> Hi Mit > >> Hmm, from your earlier posted dmesgs it looks like > >> > >> the SD card is not getting detected properly.. > >> > >> > >> I get this output: > >> > >> sdhci_xenon0: mem > >> > >> 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 > >> > >> mmc0: on sdhci_xenon0 > >> ?snip? > >> mmcsd0: 16GB >> > >> by 39 PH> at mmc0 50.0MHz/4bit/65535-block > >> > >> > >> The problem you see was fixed for me by r348882, > >> > >> maybe it got broken later, I havn?t backported the later changes.. > >> > >> > >> Have you tried another SD card ? I have found 2 of > >> > >> mine that the espressobin doesn?t like, but works fine with bananapi a= nd > >> friends... > >> > >> > >> -S=C3=B8ren > >> > >> On 13 Aug 2019, at 23.30, Mit Matelske >> > >> > wrote: > >> > >> > >> Soren- > >> > >> Thanks for the code snippet! That will fix one of > >> > >> the problems. > >> > >> > >> I still can't mount my filesystem, though. I think > >> > >> I'm doing something really simple, wrong. I believe I'm running the > >> latest > >> code and added some printfs to show the kernel setting the regulator: > >> > >> > >> > >> usbus1 on ehci0 > >> syscon_generic4: mem 0x5f800-0x5ffff on > >> > >> simplebus1 > >> > >> sdhci_xenon0: > >> > >> regulator_get_by_ofw_property(vqmmc-supply) =3D 19 > >> > >> sdhci_xenon0: vqmmc-supply regulator found > >> sdhci_xenon0: mem > >> > >> 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 > >> > >> ahci0: mem 0xe0000-0xe0177 irq > >> > >> 26 on simplebus1 > >> > >> > >> > >> Could there be a problem with how I am setting up my > >> > >> filesystem? I've tried both freebsd-ufs and freebsd as the type, with= no > >> luck. A gpart listing of my SD card: > >> > >> > >> root@fbl:~ # gpart list da3 > >> Geom name: da3 > >> modified: false > >> state: OK > >> fwheads: 255 > >> fwsectors: 63 > >> last: 62521335 > >> first: 3 > >> entries: 4 > >> scheme: GPT > >> Providers: > >> 1. Name: da3p1 > >> Mediasize: 41943040 (40M) > >> Sectorsize: 512 > >> Stripesize: 0 > >> Stripeoffset: 1536 > >> Mode: r0w0e0 > >> efimedia: > >> > >> HD(1,GPT,19894dc5-b8b2-11e9-871f-08008a0010e0,0x3,0x14000) > >> > >> rawuuid: 19894dc5-b8b2-11e9-871f-08008a0010e0 > >> rawtype: c12a7328-f81f-11d2-ba4b-00a0c93ec93b > >> label: (null) > >> length: 41943040 > >> offset: 1536 > >> type: efi > >> index: 1 > >> end: 81922 > >> start: 3 > >> 2. Name: da3p2 > >> Mediasize: 31968979456 (30G) > >> Sectorsize: 512 > >> Stripesize: 0 > >> Stripeoffset: 41944576 > >> Mode: r0w0e0 > >> efimedia: > >> > >> HD(2,GPT,98786462-be30-11e9-ae6e-08008a0010e0,0x14003,0x3b8bff5) > >> > >> rawuuid: 98786462-be30-11e9-ae6e-08008a0010e0 > >> rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b > >> label: (null) > >> length: 31968979456 > >> offset: 41944576 > >> type: freebsd-ufs > >> index: 2 > >> end: 62521335 > >> start: 81923 > >> Consumers: > >> 1. Name: da3 > >> Mediasize: 32010928128 (30G) > >> Sectorsize: 512 > >> Mode: r0w0e0 > >> > >> Thanks!! > >> > >> Mit > >> > >> From: "S=C3=B8ren Schmidt" >> > >> > > >> > >> To: "Marcin Wojtas" >> > >> mw@semihalf.com>> > >> > >> Cc: "Mit Matelske" >, > >> > >> "freebsd-arm" >> freebsd-arm@freebsd.org>> > >> > >> Sent: Tuesday, August 13, 2019 12:55:09 PM > >> Subject: Re: Espressobin anyone ? > >> > >> Hi > >> That doesn?t seen to work on the espressobin, or > >> > >> least I can?t get it to pick it up. > >> > >> > >> I use this patch as a workaround: > >> > >> Index: main.c > >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > >> --- main.c (revision 350496) > >> +++ main.c (working copy) > >> @@ -463,6 +462,13 @@ > >> int rv; > >> char *rootdev; > >> > >> +#if defined(__aarch64__) > >> + /* SOS HACK in rootdev, at least Espressobin > >> > >> gets this wrong */ > >> > >> + printf("Setting currdev hack\n"); > >> + set_currdev("disk0p2"); > >> + return (0); > >> +#endif > >> + > >> /* > >> * First choice: if rootdev is already set, use > >> > >> that, even if > >> > >> * it's wrong. > >> > >> Its not pretty but it does the job until I get time > >> > >> to look into why bootargs aren?t passed / won?t stick, probably someth= ing > >> I > >> havn?t backported to my -stable12 sources yet... > >> > >> > >> -S=C3=B8ren > >> > >> On 13 Aug 2019, at 01.38, Marcin Wojtas < > >> > >> mw@semihalf.com > wrote: > >> > >> > >> Hi, > >> > >> Not sure if it's what you are looking for, but in > >> > >> order to autoboot, I > >> > >> simply pass 'rootdev=3DdiskXpY' in the bootargs > >> > >> variable. Here's example from > >> > >> A3720-DB (same should work on EspressoBin): > >> > >> Marvell>> set bootargs "rootdev=3Ddisk1p1";usb reset; > >> > >> fatload usb 0:1 > >> > >> ${fdt_addr} armada-3720-db.dtb; fatload usb 0:1 > >> > >> ${kernel_addr} > >> > >> boot/loader.efi; bootefi ${kernel_addr} ${fdt_addr} > >> resetting USB... > >> USB0: Register 2000104 NbrPorts 2 > >> Starting the controller > >> USB XHCI 1.00 > >> USB1: USB EHCI 1.00 > >> - ______ ____ _____ _____ > >> | ____| | _ \ / ____| __ \ > >> | |___ _ __ ___ ___ | |_) | (___ | | | | > >> | ___| '__/ _ \/ _ \| _ < \___ \| | | | > >> | | | | | __/ __/| |_) |____) | |__| | > >> | | | | | | || | | | > >> |_| |_| \___|\___||____/|_____/|_____/ > >> ``` > >> ` > >> ????????????Welcome to FreeBSD????????????? s` > >> > >> `.....---.......--.``` > >> > >> -/ > >> ? ? +o > >> > >> .--` /y:` > >> > >> +. > >> ? 1. Boot Multi user [Enter] ? > >> > >> yo`:. :o > >> > >> `+- > >> ? 2. Boot Single user ? y/ > >> > >> -/` -o/ > >> > >> ? 3. Escape to loader prompt ? .- > >> ::/sy+:. > >> ? 4. Reboot ? / > >> > >> `-- > >> > >> / > >> ? ? `: > >> :` > >> ? Options: ? `: > >> :` > >> ? 5. Kernel: default/kernel (1 of 1) ? / > >> / > >> ? 6. Boot Options ? .- > >> -. > >> ? ? -- > >> > >> -. > >> > >> ? ? > >> > >> `:` `:` > >> > >> ? ? > >> > >> .-- `--. > >> > >> ??????????????????????????????????????????? > >> > >> .---.....----. > >> > >> Autoboot in 9 seconds, hit [Enter] to boot or any > >> > >> other key to stop > >> > >> > >> Loading kernel... > >> /boot/kernel/kernel text=3D0x95047c > >> > >> data=3D0x1919d0+0x84aa94 > >> > >> syms=3D[0x8+0x13aaa8+0x8+0x12610d] > >> Loading configured modules... > >> can't find '/boot/entropy' > >> Using DTB provided by EFI at 0x8000000. > >> ---<>--- > >> KDB: debugger backends: ddb > >> KDB: current backend: ddb > >> Copyright (c) 1992-2019 The FreeBSD Project. > >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, > >> > >> 1991, 1992, 1993, 1994 > >> > >> The Regents of the University of California. All > >> > >> rights reserved. > >> > >> FreeBSD is a registered trademark of The FreeBSD > >> > >> Foundation. > >> > >> FreeBSD 13.0-CURRENT > >> > >> 17a1fc80d57-c261519(upstream_master) GENERIC arm64 > >> > >> FreeBSD clang version 8.0.0 (tags/RELEASE_800/final > >> > >> 356365) (based on LLVM > >> > >> 8.0.0) > >> WARNING: WITNESS option enabled, expect reduced > >> > >> performance. > >> > >> VT: init without driver. > >> Starting CPU 1 (1) > >> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > >> [...] > >> > >> Best regards, > >> Marcin > >> > >> pon., 12 sie 2019 o 23:14 Mit Matelske >> > >> > napisa?(a): > >> > >> > >> > >> Soren- > >> > >> Thanks for the quick response. I built this kernel > >> > >> with revision 350924. > >> > >> I'll dig into whats going on in the morning. > >> > >> Mind posting your diff for your loader.efi? > >> > >> Thanks again! > >> > >> Mit > >> > >> > >> ----- Original Message ----- > >> From: "S=C3=B8ren Schmidt" >> > >> > > >> > >> To: "Mit Matelske" > > >> Cc: "tscho" >> > >> johannes@t-beutel.com>>, "freebsd-arm" < > >> > >> freebsd-arm@freebsd.org >> > >> freebsd-arm@freebsd.org>> > >> > >> Sent: Monday, August 12, 2019 3:49:48 PM > >> Subject: Re: Espressobin anyone ? > >> > >> Hi > >> > >> Looks like your sources may be too old, you need to > >> > >> be at least at r348882 > >> > >> to get the fix for the SD card VCC regulator. > >> > >> That change fixed it for me backported to 12-stable... > >> > >> The currdev problem still exists, I have it hardwired > >> > >> in my loader for > >> > >> aarch64 :) > >> > >> -S=C3=B8ren > >> > >> > >> On 12 Aug 2019, at 21.06, Mit Matelske >> > >> > wrote: > >> > >> > >> I'm having a couple little hiccups booting this board > >> > >> also. One has > >> > >> been commented on already, that I can't get the > >> > >> loader to automatically > >> > >> start loading the kernel on "disk0p2"... > >> > >> The second, is that the kernel can't find the SD card > >> > >> after booting so > >> > >> it can't mount the root filesystem. I'm using the > >> > >> dts/dtb and kernel from > >> > >> the 13-current branch. > >> > >> Thanks for any and all help. I haven't used u-boot > >> > >> in about decade. > >> > >> Spoiled by the x86 platform. > >> > >> Mit Matelske > >> > >> > >> ***U-boot environment:*** > >> > >> > >> Marvell>> printenv > >> baudrate=3D115200 > >> bootargs=3Dconsole=3DttyMV0,115200 > >> > >> earlycon=3Dar3700_uart,0xd0012000 > >> > >> root=3D/dev/mmcblk0p1 rw rootwait net.ifnames=3D0 > >> > >> biosdevname=3D0 > >> > >> bootcmd=3Dmmc dev 0; fatload mmc 0:1 $kernel_addr > >> > >> $image_name;fatload mmc > >> > >> 0:1 $fdt_addr $fdt_name; bootefi $kernel_addr > >> > >> $fdt_addr > >> > >> bootdelay=3D2 > >> bootmmc=3Dmmc dev 0; fatload mmc 0:1 $kernel_addr > >> > >> $image_name;fatload mmc > >> > >> 0:1 $fdt_addr $fdt_name; bootefi $kernel_addr > >> > >> $fdt_addr > >> > >> console=3Dconsole=3DttyMV0,115200 > >> > >> earlycon=3Dar3700_uart,0xd0012000 > >> > >> eth1addr=3D00:51:82:11:22:01 > >> eth2addr=3D00:51:82:11:22:02 > >> eth3addr=3D00:51:82:11:22:03 > >> ethact=3Dneta@30000 > >> ethaddr=3DF0:AD:4E:09:6B:8F > >> ethprime=3Deth0 > >> fdt_addr=3D0x4f00000 > >> fdt_high=3D0xffffffffffffffff > >> fdt_name=3Defi/boot/armada-3720-espressobin.dtb > >> fdtcontroladdr=3D3f7161b8 > >> gatewayip=3D10.4.50.254 > >> get_images=3Dtftpboot $kernel_addr $image_name; > >> > >> tftpboot $fdt_addr > >> > >> $fdt_name; run get_ramfs > >> get_ramfs=3Dif test "${ramfs_name}" !=3D "-"; then setenv > >> > >> ramfs_addr > >> > >> 0x8000000; tftpboot $ramfs_addr $ramfs_name; else > >> > >> setenv ramfs_addr -;fi > >> > >> hostname=3Dmarvell > >> image_name=3Defi/freebsd/loader.efi > >> initrd_addr=3D0xa00000 > >> initrd_size=3D0x2000000 > >> ipaddr=3D0.0.0.0 > >> kernel_addr=3D0x5000000 > >> loadaddr=3D0x5000000 > >> netdev=3Deth0 > >> netmask=3D255.255.255.0 > >> ramfs_addr=3D0x8000000 > >> ramfs_name=3D- > >> root=3Droot=3D/dev/nfs rw > >> rootpath=3D/srv/nfs/ > >> serverip=3D0.0.0.0 > >> set_bootargs=3Dsetenv bootargs $console $root > >> > >> ip=3D$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:none > >> > >> nfsroot=3D$serverip:$rootpath $extra_params > >> stderr=3Dserial@12000 > >> stdin=3Dserial@12000 > >> stdout=3Dserial@12000 > >> > >> > >> ***Full boot logs:*** > >> > >> > >> U-Boot 2017.03-armada-17.10.2-g14aeedc (Jun 01 2018 - > >> > >> 15:39:10 +0800) > >> > >> > >> Model: Marvell Armada 3720 Community Board ESPRESSOBin > >> CPU @ 1000 [MHz] > >> L2 @ 800 [MHz] > >> TClock @ 200 [MHz] > >> DDR @ 800 [MHz] > >> DRAM: 1 GiB > >> U-Boot DT blob at : 000000003f7161b8 > >> Comphy-0: USB3 5 Gbps > >> Comphy-1: PEX0 2.5 Gbps > >> Comphy-2: SATA0 6 Gbps > >> SATA link 0 timeout. > >> AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA > >> > >> mode > >> > >> flags: ncq led only pmp fbss pio slum part sxs > >> PCIE-0: Link down > >> MMC: sdhci@d0000: 0, sdhci@d8000: 1 > >> SF: Detected mx25u3235f with page size 256 Bytes, > >> > >> erase size 64 KiB, > >> > >> total 4 MiB > >> Net: eth0: neta@30000 [PRIME] > >> Hit any key to stop autoboot: 0 > >> switch to partitions #0, OK > >> mmc0 is current device > >> reading efi/freebsd/loader.efi > >> 603872 bytes read in 49 ms (11.8 MiB/s) > >> reading efi/boot/armada-3720-espressobin.dtb > >> 15946 bytes read in 17 ms (916 KiB/s) > >> ## Starting EFI application at 05000000 ... > >> Scanning disk sdhci@d0000.blk >> > >> ... > >> > >> Card did not respond to voltage select! > >> mmc_init: -95, time 50 > >> Found 1 disks > >> Consoles: EFI console > >> FreeBSD/arm64 EFI loader, Revision 1.1 > >> > >> Command line arguments: loader.efi > >> EFI version: 2.05 > >> EFI Firmware: Das U-boot (rev 0.00) > >> Console: efi (0) > >> Failed to find bootable partition > >> Startup error in /boot/lua/loader.lua: seconds > >> LUA ERROR: cannot open /boot/lua/loader.lua: invalid > >> > >> argument. > >> > >> > >> can't load 'kernel' > >> > >> Type '?' for a list of commands, 'help' for more > >> > >> detailed help. > >> > >> OK > >> OK set currdev=3Ddisk0p2 > >> OK boot > >> > >> /boot/kernel/kernel text=3D0x97d6a0 > >> > >> data=3D0x191b50+0x84ae94 > >> > >> syms=3D[0x8+0x137dd8+0x8+0x126260] > >> Using DTB provided by EFI at 0x8000000. > >> ---<>--- > >> KDB: debugger backends: ddb > >> KDB: current backend: ddb > >> Copyright (c) 1992-2019 The FreeBSD Project. > >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, > >> > >> 1991, 1992, 1993, 1994 > >> > >> The Regents of the University of California. All > >> > >> rights reserved. > >> > >> FreeBSD is a registered trademark of The FreeBSD > >> > >> Foundation. > >> > >> FreeBSD 13.0-CURRENT GENERIC arm64 > >> FreeBSD clang version 6.0.1 (tags/RELEASE_601/final > >> > >> 335540) (based on > >> > >> LLVM 6.0.1) > >> WARNING: WITNESS option enabled, expect reduced > >> > >> performance. > >> > >> VT: init without driver. > >> Starting CPU 1 (1) > >> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > >> arc4random: WARNING: initial seeding bypassed the > >> > >> cryptographic random > >> > >> device because it was not yet seeded and the knob > >> > >> 'bypass_before_seeding' > >> > >> was enabled. > >> random: entropy device external interface > >> MAP 3e681000 mode 2 pages 1 > >> MAP 3ffa6000 mode 2 pages 1 > >> kbd0 at kbdmux0 > >> ofwbus0: > >> simplebus0: on > >> > >> ofwbus0 > >> > >> simplebus1: on > >> > >> simplebus0 > >> > >> simple_mfd0: mem > >> 0x13800-0x138ff,0x13c00-0x13c1f on simplebus1 > >> simple_mfd1: mem > >> 0x18800-0x188ff,0x18c00-0x18c1f on simplebus1 > >> psci0: >> > >> Driver> on ofwbus0 > >> > >> gic0: mem > >> > >> > >> 0x1d00000-0x1d0ffff,0x1d40000-0x1d7ffff,0x1d80000-0x1d81fff,0x1d90000-= 0x1d91fff,0x1da0000-0x1dbffff > >> > >> irq 27 on simplebus1 > >> gpio0: 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: 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: on ofwbus0 > >> gpioregulator0: cannot get pin 0 > >> gpioregulator0: cannot parse parameters > >> device_attach: gpioregulator0 attach returned 6 > >> generic_timer0: irq 0,1,2,3 on > >> > >> ofwbus0 > >> > >> Timecounter "ARM MPCore Timecounter" frequency > >> > >> 12500000 Hz quality 1000 > >> > >> Event timer "ARM MPCore Eventtimer" frequency > >> > >> 12500000 Hz quality 1000 > >> > >> gpio0: 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: 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: on ofwbus0 > >> gpioregulator0: cannot get pin 0 > >> gpioregulator0: cannot parse parameters > >> device_attach: gpioregulator0 attach returned 6 > >> gpio0: 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: 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: on ofwbus0 > >> gpioregulator0: cannot get pin 0 > >> gpioregulator0: cannot parse parameters > >> device_attach: gpioregulator0 attach returned 6 > >> gpio0: 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: 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: on ofwbus0 > >> gpioregulator0: cannot get pin 0 > >> gpioregulator0: cannot parse parameters > >> device_attach: gpioregulator0 attach returned 6 > >> gpio0: 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: 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: on ofwbus0 > >> gpioregulator0: cannot get pin 0 > >> gpioregulator0: cannot parse parameters > >> device_attach: gpioregulator0 attach returned 6 > >> cpulist0: on ofwbus0 > >> cpu0: on cpulist0 > >> cpu1: on cpulist0 > >> pmu0: irq 4 on ofwbus0 > >> syscon_generic0: mem 0xd000-0xdfff on > >> > >> simplebus1 > >> > >> syscon_generic1: mem 0x11500-0x1153f on > >> > >> simplebus1 > >> > >> uart0: mem 0x12000-0x121ff > >> > >> irq 9,10,11 on > >> > >> simplebus1 > >> uart0: console (115200,n,8,1) > >> gpio0: 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: mem 0x14000-0x1405f on > >> > >> simplebus1 > >> > >> gpio0: 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: mem 0x30000-0x33fff irq 14 > >> > >> on simplebus1 > >> > >> mvneta0: version is 10 > >> mvneta0: Ethernet address: 00:a6:39:ca:e8:00 > >> mdio0: on mvneta0 > >> mdioproxy0: on mdio0 > >> e6000sw0: on mdio0 > >> e6000sw0: multi-chip addressing mode (0x1) > >> e6000sw0: CPU port at 0 > >> e6000sw0: fixed port at 0 > >> e6000sw0: PHY at port 1 > >> miibus0: on e6000sw0 > >> e1000phy0: 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: on e6000sw0 > >> e1000phy1: 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: on e6000sw0 > >> e1000phy2: 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: on e6000sw0 > >> xhci0: mem > >> > >> 0x58000-0x5bfff irq 16 on > >> > >> simplebus1 > >> xhci0: 32 bytes context size, 32-bit DMA > >> usbus0 on xhci0 > >> syscon_generic3: mem 0x5d800-0x5dfff on > >> > >> simplebus1 > >> > >> ehci0: mem > >> > >> 0x5e000-0x5efff irq > >> > >> 17 on simplebus1 > >> usbus1: EHCI version 1.0 > >> usbus1 on ehci0 > >> syscon_generic4: mem 0x5f800-0x5ffff on > >> > >> simplebus1 > >> > >> sdhci_xenon0: mem > >> 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 > >> ahci0: mem 0xe0000-0xe0177 irq > >> > >> 26 on simplebus1 > >> > >> ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier > >> > >> supported with FBS > >> > >> ahcich0: at channel 0 on ahci0 > >> device_attach: ahcich0 attach returned 6 > >> gpioregulator0: on ofwbus0 > >> gpioregulator0: cannot get pin 0 > >> gpioregulator0: cannot parse parameters > >> device_attach: gpioregulator0 attach returned 6 > >> cryptosoft0: > >> 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 > >> > >> > >> > >> 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 > >> > >> usbus1 Processor Features 1 =3D <0> > >> usbus0 Memory Model Features 0 =3D <4k Granule,64k > >> > >> Granule,S/NS > >> > >> Mem,MixedEndian,16bit ASID,1TB PA> > >> > >> Memory Model Features 1 =3D <> > >> Memory Model Features 2 =3D <32b CCIDX,48b VA> > >> Debug Features 0 =3D <2 CTX Breakpoints,4 > >> > >> Watchpoints,6 > >> > >> Breakpoints,PMUv3,Debug v8> > >> Debug Features 1 =3D <0> > >> Auxiliary Features 0 =3D <0> > >> Auxiliary Features 1 =3D <0> > >> CPU 1: ARM Cortex-A53 r0p4 affinity: 1 > >> WARNING: WITNESS option enabled, expect reduced > >> > >> performance. > >> > >> ugen0.1: at usbus0 > >> ugen1.1: at usbus1 > >> uhub0 on usbus0 > >> uhub1 on usbus1 > >> uhub0: >> > >> 3.00/1.00, addr 1> on > >> > >> usbus0 > >> uhub1: >> > >> 2.00/1.00, addr 1> on > >> > >> usbus1 > >> uhub0: 2 ports with 2 removable, self powered > >> uhub1: 1 port with 1 removable, self powered > >> mountroot: waiting for device > >> > >> /dev/ufs/FreeBSD_Install... > >> > >> Mounting from ufs:/dev/ufs/FreeBSD_Install failed > >> > >> with error 19. > >> > >> > >> Loader variables: > >> vfs.root.mountfrom=3Dufs:/dev/ufs/FreeBSD_Install > >> vfs.root.mountfrom.options=3Dro,noatime > >> > >> Manual root filesystem specification: > >> : [options] > >> Mount using filesystem > >> and with the specified (optional) option list. > >> > >> eg. ufs:/dev/da0s1a > >> zfs:zroot/ROOT/default > >> cd9660:/dev/cd0 ro > >> (which is equivalent to: mount -t cd9660 -o ro > >> > >> /dev/cd0 /) > >> > >> > >> ? List valid disk boot devices > >> . Yield 1 second (for background tasks) > >> Abort manual input > >> > >> mountroot> ? > >> > >> List of GEOM managed disk devices: > >> > >> > >> mountroot> > >> _______________________________________________ > >> freebsd-arm@freebsd.org >> > >> 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 >> freebsd-arm-unsubscribe@freebsd.org>" > >> > >> > >> _______________________________________________ > >> freebsd-arm@freebsd.org >> > >> 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 >> freebsd-arm-unsubscribe@freebsd.org>" > >> > >> > >> > >> > >> -- > >> Emmanuel Vadot < > >> > >> manu@freebsd.org> > >> > >> > >> > >> > >> -- > >> Emmanuel Vadot > >> > >> > >> > >> -- > >> Emmanuel Vadot > >> _______________________________________________ > >> freebsd-arm@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm > >> To unsubscribe, send any mail to " > >> > >> freebsd-arm-unsubscribe@freebsd.org" > >> > >> > >> > >> -- > >> Emmanuel Vadot > >> _______________________________________________ > >> freebsd-arm@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm > >> To unsubscribe, send any mail to " > >> > >> freebsd-arm-unsubscribe@freebsd.org" > >> > >> > >> > >> -- > >> Emmanuel Vadot > >> _______________________________________________ > >> freebsd-arm@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm > >> To unsubscribe, send any mail to " > >> > >> freebsd-arm-unsubscribe@freebsd.org" > >> > >> > >> > >> -- > >> Emmanuel Vadot >> > >> manu@bidouilliste.com>> > > >> > >> > >> > >> > >> -- > >> Emmanuel Vadot >> > >> manu@bidouilliste.com>> > > >> > >> > >> > >> > >> -- > >> Emmanuel Vadot > >> _______________________________________________ > >> 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 From owner-freebsd-arm@freebsd.org Tue Aug 20 13:22:35 2019 Return-Path: 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 777D2D22DD for ; Tue, 20 Aug 2019 13:22:35 +0000 (UTC) (envelope-from per@hedeland.org) Received: from outbound1f.eu.mailhop.org (outbound1f.eu.mailhop.org [52.28.59.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46CWgG1CxXz4M0p for ; Tue, 20 Aug 2019 13:22:33 +0000 (UTC) (envelope-from per@hedeland.org) ARC-Seal: i=1; a=rsa-sha256; t=1566307352; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=SHceF4ooCP1wBUjX+N6GsfKYUNU7k1p5onPa3PGoXuuxw2HdRgMeOPaX086bs+F/8BknkGvrmZQOs 6oeShy6ydMi1i1Qhzs8VxYvQP13o8GYflR6rtVDpeWJpxcdguciqhSCD8JQ1s85rI7YYs/LIg1eJSk lHXTQ1TelDx5/leKtJw1EZjcd3zNywVXsqOyuNMFJSlJKV/p7gyqU0GfuX9Moo/eAxJEEnoQbTltBt 2rA1XUKsBdPNupgFsrEYfH+3hBCkdzDfzz2F72tfRqJxNzY6NI6Vu6etNmyY0lbYAmQWKVaZYpbLJL EcN902tVPZ9xqMksXmP2h6ajjHotw3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:references:cc:to:subject:dkim-signature:from; bh=735sxqa4xDD7yfG3BbIGsPiZ9NkUDQrVKwXQpbr5VGU=; b=SuECPvZCNoXxy/E5bIGjqf06wJ1l78p5jgh2mkRZWLvDLEGf8kqDj4FX/UldUwJXXGZptQlyJAknc efw5JlPiSNzzpNTokIaO8fdqSbTh8nxzZp9bfjW+1EB8QakNGb2mx/frfVw6sTmq+5AAZYx3FvGYVv kh7r3RLsLMTyNuihn7juysYrZok1waDyx4fM0h3rThaZAUxoY+p+4xUI+/tTMYL0DY7AWgX7fjVl4+ rxqq5m95QccsF0Zh45vVkSTT8et8RTw8io3IU90J0kjLB5N5p4ZwYlD22ERNcMxrTsUgSl/7YokT8O mrmVNHjfJmlArByPluStqytJW/PPezg== ARC-Authentication-Results: i=1; outbound2.eu.mailhop.org; spf=none smtp.mailfrom=hedeland.org smtp.remote-ip=81.228.157.209; dmarc=none header.from=hedeland.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:references:cc:to:subject:from; bh=735sxqa4xDD7yfG3BbIGsPiZ9NkUDQrVKwXQpbr5VGU=; b=ZpgPGJ4LfD96Mhk/Vdk7lQvh6M2JdK0nklrdgOSnUC/A7JpZ9yJIFqCv0Bsz0norJfjRk7XycFYkx DZmzMZ8z3hplivzNH22ZALYOfcq4cGrU1BmR2uvPeV09f+T5Exi9lr0BjBWjhueT68GPUOQP1SIIhL BQUQNbP8iGYbUfXVl3LPqJ/ozF/ukrLEVHYOmfv+PrP/2omXBKAuc/UwpG0ZABM2Ue080DPvtt00sg REcQ/3OMYQ6vMHQJATDleoJhOPVvvuieUNKfzIFxnuAhzyEjPYXnlR0MLER04zuKot+MGincr+hGDY 9DCeumVT78TnRNE+2l9CZzp/Wg+eZeA== X-MHO-RoutePath: cGVyaGVkZWxhbmQ= X-MHO-User: 8e8d1f77-c34d-11e9-a204-f5e3bb5d0a28 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 81.228.157.209 X-Mail-Handler: DuoCircle Outbound SMTP Received: from hedeland.org (unknown [81.228.157.209]) by outbound2.eu.mailhop.org (Halon) with ESMTPSA id 8e8d1f77-c34d-11e9-a204-f5e3bb5d0a28; Tue, 20 Aug 2019 13:22:29 +0000 (UTC) Received: from plutt.hedeland.org (82-209-140-38.cust.bredband2.com [82.209.140.38]) (authenticated bits=0) by tellus.hedeland.org (8.15.2/8.15.2) with ESMTPSA id x7KDMR3Z062393 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 20 Aug 2019 15:22:28 +0200 (CEST) (envelope-from per@hedeland.org) X-Authentication-Warning: tellus.hedeland.org: Host 82-209-140-38.cust.bredband2.com [82.209.140.38] claimed to be plutt.hedeland.org Subject: Re: Is it a good idea to use a usb-serial adapter for PPS? Yes, it is. To: Hans Petter Selasky , Ian Lepore Cc: freebsd-arm@freebsd.org References: <69a9bed3-4d0a-f8f6-91af-a8f7d84ee307@hedeland.org> <345bae77417c2495f55799b4c7ca2784f4ece9ed.camel@freebsd.org> <7312032d-2908-9414-0445-6b442c3a02e5@hedeland.org> <523b6f0a0fa5f2aeec298fa74df25d3c4af66acc.camel@freebsd.org> <0426fc8b-5398-d8ab-561e-7823c24403a5@hedeland.org> <24b0eaf25b64d6098b390df092866c69e352d859.camel@freebsd.org> <16c91be1-6f2a-b26d-22c7-be8e4ba8eec0@hedeland.org> <72a964c78cbfc36be2345919633ca2196f0783e3.camel@freebsd.org> <540c8b5f-5e81-b67b-4a00-49b86044efe0@selasky.org> <8e28c96e-92c6-5beb-277f-0876a5aba272@hedeland.org> From: Per Hedeland Message-ID: Date: Tue, 20 Aug 2019 15:22:22 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46CWgG1CxXz4M0p X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=outbound.mailhop.org header.s=dkim-high header.b=ZpgPGJ4L; dmarc=none; spf=none (mx1.freebsd.org: domain of per@hedeland.org has no SPF policy when checking 52.28.59.28) smtp.mailfrom=per@hedeland.org X-Spamd-Result: default: False [-5.54 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_XOIP(0.00)[]; TO_DN_SOME(0.00)[]; HAS_XAW(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[outbound.mailhop.org:+]; NEURAL_HAM_SHORT(-0.98)[-0.976,0]; RECEIVED_SPAMHAUS_PBL(0.00)[209.157.228.81.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11,38.140.209.82.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_ALLOW(-1.00)[i=1]; IP_SCORE(-1.26)[ipnet: 52.28.0.0/16(-4.89), asn: 16509(-1.35), country: US(-0.05)]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[outbound.mailhop.org:s=dkim-high]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:16509, ipnet:52.28.0.0/16, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[hedeland.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[28.59.28.52.list.dnswl.org : 127.0.20.0]; R_SPF_NA(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 13:22:35 -0000 On 2019-08-20 13:50, Hans Petter Selasky wrote: > On 2019-08-20 13:38, Per Hedeland wrote: >> >> I'm sorry, I'm afraid I still don't really understand... The question, >> at least in my mind, was whether polling was done in a "strictly >> periodic" fashion, at most once per 125 us for USB 2.0 - or whether >> the host controller would poll "as fast as it could", which could >> result in a *much* higher polling rate. > > That depends on the endpoint type. INTERRUPT endpoints poll regularly, one time, every 125 us for example, when a job is queued. BULK endpoints poll all the time, depending a bit on the HC in use. OK, Ian reported earlier that the FTDI usb-serial adapter he used was using BULK transfers, so far so good... > Anyways, the computer is not notified of the completion before the HC is generating an interrupt. This usually happens at some fixed point in time. I.E. multiple completions can be joined into one HC interrupt. It is the completion interrupt which > notifies the software about the PPS event. ...but this sounds like we might be back to square one... Is there a fixed interval between those fixed points in time, and what would the length of that interval be? And, what is the source for the generation of the intervals? On 2019-08-20 13:53, Hans Petter Selasky wrote: > On 2019-08-20 13:38, Per Hedeland wrote: >> >> This sounds like a method to determine a fixed latency - or am I >> misunderstanding? > > The HC sends out a timestamp, called SOF, to all USB devices every 1ms or 125us. This SOF mark is usually the beginning of the polling schedule. All USB endpoints are polled by the HC. The USB device can predict the time of the SOF and also > completion on the HC and so I believe adjust the timestamp, so that it would appear to be received instantaneously. Hm, but this doesn't sound like something an off-the-shelf usb-serial adapter could or would do, I think? --Per From owner-freebsd-arm@freebsd.org Tue Aug 20 19:01:57 2019 Return-Path: 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 D0975D9093 for ; Tue, 20 Aug 2019 19:01:57 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46CgBq1ZjBz3F7X for ; Tue, 20 Aug 2019 19:01:54 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i09O2-0006jp-O0; Tue, 20 Aug 2019 21:01:45 +0200 To: "Jeffrey Bowers" Subject: Re: Espressobin anyone ? References: <20190817153053.5592b15b8a42982fda0fc123@bidouilliste.com> <9749945A-FDAD-47E0-947A-FA62138C2F83@gmail.com> <20190817210822.8920656bad0855b554883cf2@bidouilliste.com> <2D6D4BDA-75EC-403F-B5E2-52A468369DE2@gmail.com> <627099DD-804B-412F-A083-768CEFCF955C@gmail.com> <6DA8E736-8031-4BF7-8B20-CF8B0E8A7FEF@gmail.com> <2002575095.53.1566305166664@localhost> Date: Tue, 20 Aug 2019 21:01:43 +0200 Cc: freebsd-arm MIME-Version: 1.0 From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: + X-Spam-Score: 1.0 X-Spam-Status: No, score=1.0 required=5.0 tests=ALL_TRUSTED, BAYES_50, HTML_MESSAGE, NORMAL_HTTP_TO_IP, NUMERIC_HTTP_ADDR autolearn=disabled version=3.4.2 X-Scan-Signature: 121048a6ad151eb42b904ae111794fa6 X-Rspamd-Queue-Id: 46CgBq1ZjBz3F7X X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 195.190.28.88 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws X-Spamd-Result: default: False [-0.70 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.968,0]; FROM_HAS_DN(0.00)[]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.46.224,0.0.117.48]; R_SPF_ALLOW(-0.20)[+ip4:195.190.28.64/27]; NEURAL_HAM_LONG(-0.85)[-0.852,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain,multipart/related]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_NA(0.00)[klop.ws]; URI_COUNT_ODD(1.00)[51]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.63)[-0.627,0]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(-0.46)[ip: (-1.16), ipnet: 195.190.28.0/24(-0.39), asn: 47172(-0.74), country: NL(0.01)]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:47172, ipnet:195.190.28.0/24, country:NL]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: Quoted-Printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 19:01:57 -0000 On Wed, 21 Aug 2019 01:03:37 +0200, Jeffrey Bowers = = wrote: > Yes sir, I can ping svn.freebsd.org. Any idea why the checkout fails?= I don't know. What ip address do you get when pinging? Does this work for you? Does it work using the ip address you get? svn checkout https://213.138.116.72/ports/head Regards, Ronald. > > On Tue, Aug 20, 2019 at 7:46 AM Ronald Klop wro= te: >> It is not possible to 'ping https://svn.freebsd.org/ports/head'. >> You can 'ping svn.freebsd.org'. >> >> Ronald. >> = >> Van: Jeffrey Bowers >> Datum: dinsdag, 20 augustus 2019 14:36 >> Aan: "S=C3=B8ren Schmidt" , freebsd-arm = >> >> Onderwerp: Re: Espressobin anyone ? >>> I just tried to ping https://svn.freebsd.org/ports/head, and even = >>> though >>> it scrolsl through all that text I get an error saying "could not = >>> resolve >>> https://svn.freebsd.org/ports/head ; unknown server error" . I can p= ing >>> google just fine. Is it a DNS issue? >>> >>> On Tue, Aug 20, 2019 at 7:33 AM Jeffrey Bowers = = >>> wrote: >>> >>>> I'm still getting: svn: E000060: Operation timed out >>>> It goes for several minutes scrolling through text, and I feel like= = >>>> using >>>> your link got further. >>>> >>>> Thanks! >>>> >>>> On Tue, Aug 20, 2019 at 2:49 AM S=C3=B8ren Schmidt = >>>> >>>> wrote: >>>> >>>>> Hmm, I use this URL >>>>> >>>>> Repository Root: https://svn.freebsd.org/ports/head >>>>> >>>>> Not sure the svn+ssh thing works=E2=80=A6 >>>>> >>>>> -S=C3=B8ren >>>>> >>>>> >>>>> On 20 Aug 2019, at 02.38, Jeffrey Bowers wro= te: >>>>> >>>>> Hi all, >>>>> >>>>> I'm having trouble getting subversion to work. When I run: >>>>> >>>>> svn checkout https://svn.FreeBSD.org/ports/head /usr/ports >>>>> >>>>> It scrolls through many lines of text before stating: svn: E00006= 0: >>>>> Operation timed out >>>>> >>>>> When I run: >>>>> >>>>> svn checkout svn+ssh://repo.freebsd.org/ports/head /usr/ports >>>>> >>>>> It tells me that the authenticity of the host cannot be identified= , = >>>>> and >>>>> asks me to confirm that I want to connect. I say yes, and then it = = >>>>> says: >>>>> >>>>> svn: E170013: Unable to connect to a repository at URL 'svn+ssh://= >>>>> repo.freebsd.org/ports/head' >>>>> svn: E210002: To better debug SSH connection problems, remove the = -q >>>>> option >>>>> from 'ssh' in the [tunnels] section of your Subversion configurati= on = >>>>> file. >>>>> >>>>> Any ideas? >>>>> >>>>> Thanks in advance! >>>>> >>>>> On Mon, Aug 19, 2019 at 8:51 PM Jeffrey Bowers >>>>> wrote: >>>>> >>>>> I didn't think it remounting. Thank you! >>>>> >>>>> On Mon, Aug 19, 2019 at 11:39 AM S=C3=B8ren Schmidt = >>>>> >>>>> wrote: >>>>> >>>>> Hi Jeffrey >>>>> >>>>> You need to unmount the /tmp filesystem :) >>>>> You can do that permanently by commenting it out in /etc/fstab >>>>> >>>>> >>>>> On 19 Aug 2019, at 21.45, Jeffrey Bowers wro= te: >>>>> >>>>> Hi Soren, >>>>> >>>>> I'm getting the same error message. Any other ideas what it might = be? >>>>> It's got to be something in the partition scheme or the file = >>>>> permissions, >>>>> but I'm just not sure what. >>>>> >>>>> >>>>> On Sun, Aug 18, 2019 at 10:03 AM Jeffrey Bowers >>>>> wrote: >>>>> >>>>> D=E2=80=99Oh! I thought I too care of that with gpart. I literally= missed = >>>>> growfs >>>>> part of the instructions.. >>>>> >>>>> On Sun, Aug 18, 2019 at 10:00 AM S=C3=B8ren Schmidt = >>>>> >>>>> wrote: >>>>> >>>>> Hi >>>>> >>>>> You are out of space :) >>>>> >>>>> Boot the board into singleuser mode, and do =E2=80=9Cservice growf= s start=E2=80=9D, >>>>> that will expand you / filesystem to the entire SD card=E2=80=A6 >>>>> >>>>> -S=C3=B8ren >>>>> >>>>> On 18 Aug 2019, at 14.50, Jeffrey Bowers wro= te: >>>>> >>>>> Sure thing! Here's the screenshot! >>>>> >>>>> >>>>> >>>>> On Sun, Aug 18, 2019 at 7:35 AM S=C3=B8ren Schmidt = >>>>> >>>>> wrote: >>>>> >>>>> Hi >>>>> >>>>> Can I have you paste the output from df -h ? >>>>> >>>>> You should be able to utilise the full SD card=E2=80=A6 >>>>> >>>>> -S=C3=B8ren >>>>> >>>>> On 18 Aug 2019, at 14.29, Jeffrey Bowers wro= te: >>>>> >>>>> Hi, >>>>> >>>>> Just make sure I understand the process, I should hook up a hard d= isk >>>>> and map it to to /TMP ? >>>>> >>>>> I already tried just unmapping /tmp, and it gave me the same error= >>>>> once, and then the next time I ran it I got an error saying = >>>>> /usr/ports was >>>>> out of space )which I guess I shouldn=E2=80=99t mount to another d= irector on = >>>>> the >>>>> hard drive? >>>>> >>>>> On Sun, Aug 18, 2019 at 5:11 AM S=C3=B8ren Schmidt = >>>>> >>>>> wrote: >>>>> >>>>> Hi Jeffrey >>>>> >>>>> You can unmount the memory disk on /tmp to get at the space on the= SD >>>>> card. >>>>> >>>>> It is however not recommend to use the AD card for random storage,= it >>>>> will wear out fast, that=E2=80=99s why the memory disk is setup. >>>>> >>>>> You could connect a SSD og laptop disk to the SATA interface and u= se >>>>> that for the workload. >>>>> >>>>> However compiling is slow, its much much faster to cross compile o= n a >>>>> PC=E2=80=A6 >>>>> >>>>> -S=C3=B8ren >>>>> >>>>> On 18 Aug 2019, at 00.22, Jeffrey Bowers wro= te: >>>>> >>>>> Hi! I've got a new one :) >>>>> I'm trying to do an svn checkout to fix the pkg problem, but it te= lls >>>>> me it can't write to a to a temp folder because there is no room = >>>>> left on >>>>> the device. However, FreeBSD partition is 29GB. It's never also = >>>>> never the >>>>> same file in TMP that it can't write to. Here is a screenshot of t= he >>>>> issue, >>>>> along with the output of gpart: >>>>> >>>>> >>>>> >>>>> Any ideas? >>>>> >>>>> Thanks! >>>>> >>>>> >>>>> On Sat, Aug 17, 2019 at 2:08 PM Emmanuel Vadot = >>>>> >>>>> wrote: >>>>> >>>>> On Sat, 17 Aug 2019 17:14:36 +0200 >>>>> S=C3=B8ren Schmidt wrote: >>>>> >>>>> HI >>>>> >>>>> Well, I have a whole forrest of tree?s here, but the error posted >>>>> >>>>> here was on a clean checkout. >>>>> >>>>> >>>>> Anyhow, with the latest changes to -stable and the two >>>>> >>>>> RF_SHAREABLE patches from -current all works. >>>>> >>>>> I've reverted the commits, see >>>>> https://github.com/evadot/freebsd/commits/a37x0_gpio for a better >>>>> way >>>>> to deal with this issue. >>>>> I'm waiting for mmel@ as he wrote the syscon_get_default_handle >>>>> part. >>>>> >>>>> It would be nice with the etherswitch changes as well so VLAN >>>>> >>>>> tagging etc was standard. >>>>> >>>>> >>>>> -S=C3=B8ren >>>>> >>>>> PS: given up on bottom & inline popsting, top posting is all the >>>>> >>>>> rage now (yeah I miss elm etc :) ) >>>>> >>>>> >>>>> On 17 Aug 2019, at 15.30, Emmanuel Vadot >>>>> >>>>> wrote: >>>>> >>>>> >>>>> On Sat, 17 Aug 2019 11:07:22 +0200 >>>>> S=C3=B8ren Schmidt >>>> >>>>> soren.schmidt@gmail.com>> wrote: >>>>> >>>>> >>>>> Hi Emmunuel >>>>> >>>>> Yes the 3720 gpio driver I already back ported long ago, its >>>>> >>>>> needed, I?m happy its now part of std stable 12! >>>>> >>>>> >>>>> Would have been nice of you to say that you were not running a >>>>> >>>>> clean >>>>> >>>>> tree. >>>>> >>>>> My issue seems to be the inclusion of the phy_usb driver, if I >>>>> >>>>> leave that out, I?m back to normal.. >>>>> >>>>> >>>>> What make you think this is this driver ? What works/doesn't work >>>>> with it ? could you provide logs. >>>>> >>>>> I?ll have have another go at the latest -stable sources during >>>>> >>>>> the weekend and see how it goes. >>>>> >>>>> >>>>> Thanks for looking into this, with a little cooperation we?ll >>>>> >>>>> get this solved for the greater good.. >>>>> >>>>> >>>>> -S=C3=B8ren >>>>> >>>>> >>>>> P.S. Please stop top posting, it's really hard to read the >>>>> >>>>> conversation >>>>> >>>>> >>>>> On 16 Aug 2019, at 22.58, Emmanuel Vadot < >>>>> >>>>> manu@bidouilliste.com> wrote: >>>>> >>>>> >>>>> On Fri, 16 Aug 2019 19:12:30 +0200 >>>>> Emmanuel Vadot >>>> >>>>> manu@bidouilliste.com>> wrote: >>>>> >>>>> >>>>> On Fri, 16 Aug 2019 17:10:37 +0200 >>>>> Emmanuel Vadot wrote: >>>>> >>>>> On Fri, 16 Aug 2019 15:24:54 +0200 >>>>> Emmanuel Vadot wrote: >>>>> >>>>> On Fri, 16 Aug 2019 07:28:59 +0200 >>>>> S=C3=B8ren Schmidt wrote: >>>>> >>>>> Hi >>>>> >>>>> Very simple, reverting sys/gnu/dts to what was before >>>>> >>>>> 350595 (actually 350592). >>>>> >>>>> Thats what we have svn for ? >>>>> >>>>> >>>>> If I asked how it was to have the svn command that you >>>>> >>>>> used, I want to >>>>> >>>>> make sure that you didn't revert anything else, like do you >>>>> >>>>> have >>>>> >>>>> r350596 and r350628 ? >>>>> >>>>> That does make my bananapi work again, no other changes >>>>> >>>>> just a recompiled kernel. >>>>> >>>>> >>>>> That + copying the dtb to the fat32 partition ? >>>>> >>>>> Can you post the dtb somewhere. >>>>> >>>>> However it does not bring the Espressobin back to life, >>>>> >>>>> thats something in one of the ~30 other files that changed between= = >>>>> those >>>>> two revisions. >>>>> >>>>> >>>>> What Linux version of DTS are you using then ? The ones >>>>> >>>>> that were in >>>>> >>>>> stable/12 when it was branched (4.18) or a later revision ? >>>>> >>>>> >>>>> So I think that I've found the problem on the Espressobin. >>>>> I think that the problem comes from the simple-mfd driver >>>>> >>>>> that I've >>>>> >>>>> mfc in r350600. >>>>> The pinctrl/gpio controller compatible is >>>>> "marvell,armada3710-nb-pinctrl", "syscon", "simple-mfd" and >>>>> >>>>> it attaches >>>>> >>>>> at BUS_PASS_INTERRUPT while the simple_mfd driver attaches at >>>>> BUS_PASS_BUS (so earlier) which means that no gpio >>>>> >>>>> controller will be >>>>> >>>>> available for sdhci to detect the card. >>>>> >>>>> If someone with a non-working espressobin could post a full >>>>> >>>>> verbose >>>>> >>>>> boot log that would help me confirming that this is the case. >>>>> I'll try to find a solution on how to solve this problem. >>>>> >>>>> >>>>> So this wasn't the problem but I've found it, see r351129 and >>>>> >>>>> r351130 >>>>> >>>>> >>>>> SD card now work again in HEAD, I'll have a look at stable >>>>> >>>>> later next >>>>> >>>>> week. >>>>> >>>>> >>>>> I've did a quick test and I've MFC r348880, r348882 and >>>>> >>>>> r349596, the >>>>> >>>>> two other commits needed to be mfc'ed are the one I did today >>>>> >>>>> on head, >>>>> >>>>> I'll do that next week. >>>>> With them sdcard is working again on stable/12 >>>>> >>>>> -S=C3=B8ren >>>>> >>>>> On 15 Aug 2019, at 23.37, Emmanuel Vadot < >>>>> >>>>> manu@bidouilliste.com> wrote: >>>>> >>>>> >>>>> On Thu, 15 Aug 2019 21:56:23 +0200 >>>>> S=C3=B8ren Schmidt wrote: >>>>> >>>>> >>>>> Well, I don?t care where you are from and what color you >>>>> >>>>> have :) >>>>> >>>>> >>>>> Now, if I update my stable12 sources to r350595 the >>>>> >>>>> bananapi breaks, if revert sys/gnu/dts it works again, go figure..= >>>>> >>>>> >>>>> Reverting to what ? and how ? >>>>> >>>>> Because I've just test 12-stable and I have the problem >>>>> >>>>> that I've said >>>>> >>>>> in my previous mail so setting >>>>> >>>>> hw.regulator.disable_unused=3D0 is the >>>>> >>>>> work around. >>>>> The problem is in twsi not in the DTS so I'm curious how >>>>> >>>>> reverting >>>>> >>>>> only the dts fixes this problem. >>>>> >>>>> The r351099 fix is already like that in -stable, and not >>>>> >>>>> part of the problem. >>>>> >>>>> >>>>> -S=C3=B8ren >>>>> >>>>> >>>>> On 15 Aug 2019, at 21.03, Emmanuel Vadot < >>>>> >>>>> manu@bidouilliste.com> wrote: >>>>> >>>>> >>>>> On Thu, 15 Aug 2019 19:48:54 +0200 >>>>> S=C3=B8ren Schmidt wrote: >>>>> >>>>> Hi Mit! >>>>> >>>>> Right, I suspected that, 12-stable broke many embedded >>>>> >>>>> systems between r350592 and r350595 where all the latest and = >>>>> greatest DTS >>>>> files was pulled in, I guess the same holds for -current. >>>>> >>>>> >>>>> -S=C3=B8ren >>>>> >>>>> >>>>> Mhm it's fun that you think that DTS import is the >>>>> >>>>> source of all your >>>>> >>>>> problems, I get it, it's easy to blame the French guy >>>>> >>>>> that bulk import >>>>> >>>>> the DTS, he surely don't know what he is doing. >>>>> Anyway, two problems were raised in this thread : >>>>> >>>>> 1) BananaPi (A20) doesn't boot >>>>> 2) Espressobin sd support is broken >>>>> >>>>> I've just looked at the BananaPi problem today, I've >>>>> >>>>> fixed a first >>>>> >>>>> problem in r351099. >>>>> The main problem is that when we disable the unused >>>>> >>>>> regulators we hang >>>>> >>>>> when trying to disabling ldo3. It's weird because the >>>>> >>>>> board doesn't use >>>>> >>>>> LDO3 (which is why we are disabling it, it's unused). >>>>> >>>>> The problem is in >>>>> >>>>> twsi I think as only leaving the part in axp209 that >>>>> >>>>> read the >>>>> >>>>> voltage register value make FreeBSD hang. >>>>> I'll have a proper look later, in the meantime you can >>>>> >>>>> set >>>>> >>>>> hw.regulator.disable_unused=3D0 >>>>> in /boot/loader.conf >>>>> This isn't a DTS problem. >>>>> >>>>> For Espressobin I haven't found any thing related to SD >>>>> >>>>> in the DTS >>>>> >>>>> updates since the import, the only things slighly >>>>> >>>>> related are mmc and >>>>> >>>>> sdio. >>>>> So if someone could find which DTS import broke this I >>>>> >>>>> can have a look. >>>>> >>>>> >>>>> >>>>> On 15 Aug 2019, at 19.37, Mit Matelske >>>>> >>>>> wrote: >>>>> >>>>> >>>>> Yeah, that was the problem. I went back to r348882 >>>>> >>>>> and everything worked out of the box. >>>>> >>>>> >>>>> Thanks again for the hand holding! >>>>> >>>>> Mit >>>>> >>>>> From: "S=C3=B8ren Schmidt" >>>> >>>>> > >>>>> >>>>> To: "Mit Matelske" > >>>>> Cc: "Marcin Wojtas" >>>> >>>>> mw@semihalf.com>>, "freebsd-arm" >>>> freebsd-arm@freebsd.org>> >>>>> >>>>> Sent: Wednesday, August 14, 2019 1:33:04 PM >>>>> Subject: Re: Espressobin anyone ? >>>>> >>>>> >>>>> It might simply be broken in -current (again). >>>>> >>>>> I just updated my stable12 tree and I pulled in new >>>>> >>>>> .dts files for just about anything? >>>>> >>>>> >>>>> Needless to say, it broke the Espressobin?s SD >>>>> >>>>> support, it now fails just like yours.. >>>>> >>>>> >>>>> It also broke allwinner builds and what not, so I?m >>>>> >>>>> just going back in time again :) >>>>> >>>>> >>>>> I wonder why there is this overwhelming need to >>>>> >>>>> import stuff that breaks things right, left and center in a -stabl= e >>>>> branch ? >>>>> >>>>> That would have earned you the pointy hat back when?. >>>>> >>>>> -S=C3=B8ren >>>>> >>>>> >>>>> On 14 Aug 2019, at 18.01, Mit Matelske >>>> >>>>> > wrote: >>>>> >>>>> >>>>> Marcin- >>>>> >>>>> Sorry I didn't reply yesterday. I didn't have any >>>>> >>>>> luck with that either. I tried a lot of permutations. >>>>> >>>>> >>>>> Not saying for 100% it doesn't work, but I couldn't >>>>> >>>>> get it to work! >>>>> >>>>> >>>>> Mit >>>>> >>>>> From: "Marcin Wojtas" >>>> >>>>> mw@semihalf.com>> >>>>> >>>>> To: "Mit Matelske" > >>>>> Cc: "S=C3=B8ren Schmidt" >>>> >>>>> soren.schmidt@gmail.com>>, "freebsd-arm" >>>> > >>>>> >>>>> Sent: Wednesday, August 14, 2019 10:41:04 AM >>>>> Subject: Re: Espressobin anyone ? >>>>> >>>>> Hi Mit, >>>>> Since you are using the latest 13-current, could you >>>>> >>>>> please try if passing rootdev via u-boot bootargs (please see my = >>>>> previous >>>>> email) works for you without the loader modification? >>>>> >>>>> >>>>> Best regards, >>>>> Marcin >>>>> >>>>> ?r., 14 sie 2019 o 16:29 Mit Matelske >>>> >>>>> > napisa?(a): >>>>> >>>>> Soren- >>>>> >>>>> Thanks for the info. I'll grab a couple more SD >>>>> >>>>> cards at lunch. This one is a new Samsung 32GB. I'll also try = >>>>> putting >>>>> the >>>>> changes into 12 and see if that helps. I'm using the latest = >>>>> 13-current. >>>>> >>>>> >>>>> Again, appreciate the hand holding! >>>>> >>>>> Mit >>>>> >>>>> From: "S=C3=B8ren Schmidt" >>>> >>>>> > >>>>> >>>>> To: "Mit Matelske" > >>>>> Cc: "Marcin Wojtas" >>>> >>>>> mw@semihalf.com>>, "freebsd-arm" >>>> freebsd-arm@freebsd.org>> >>>>> >>>>> Sent: Wednesday, August 14, 2019 2:30:31 AM >>>>> Subject: Re: Espressobin anyone ? >>>>> >>>>> Hi Mit >>>>> Hmm, from your earlier posted dmesgs it looks like >>>>> >>>>> the SD card is not getting detected properly.. >>>>> >>>>> >>>>> I get this output: >>>>> >>>>> sdhci_xenon0: mem >>>>> >>>>> 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 >>>>> >>>>> mmc0: on sdhci_xenon0 >>>>> ?snip? >>>>> mmcsd0: 16GB >>>> >>>>> by 39 PH> at mmc0 50.0MHz/4bit/65535-block >>>>> >>>>> >>>>> The problem you see was fixed for me by r348882, >>>>> >>>>> maybe it got broken later, I havn?t backported the later changes..= >>>>> >>>>> >>>>> Have you tried another SD card ? I have found 2 of >>>>> >>>>> mine that the espressobin doesn?t like, but works fine with banana= pi = >>>>> and >>>>> friends... >>>>> >>>>> >>>>> -S=C3=B8ren >>>>> >>>>> On 13 Aug 2019, at 23.30, Mit Matelske >>>> >>>>> > wrote: >>>>> >>>>> >>>>> Soren- >>>>> >>>>> Thanks for the code snippet! That will fix one of >>>>> >>>>> the problems. >>>>> >>>>> >>>>> I still can't mount my filesystem, though. I think >>>>> >>>>> I'm doing something really simple, wrong. I believe I'm running t= he >>>>> latest >>>>> code and added some printfs to show the kernel setting the regulat= or: >>>>> >>>>> >>>>> >>>>> usbus1 on ehci0 >>>>> syscon_generic4: mem 0x5f800-0x5ffff on >>>>> >>>>> simplebus1 >>>>> >>>>> sdhci_xenon0: >>>>> >>>>> regulator_get_by_ofw_property(vqmmc-supply) =3D 19 >>>>> >>>>> sdhci_xenon0: vqmmc-supply regulator found >>>>> sdhci_xenon0: mem >>>>> >>>>> 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 >>>>> >>>>> ahci0: mem 0xe0000-0xe0177 irq >>>>> >>>>> 26 on simplebus1 >>>>> >>>>> >>>>> >>>>> Could there be a problem with how I am setting up my >>>>> >>>>> filesystem? I've tried both freebsd-ufs and freebsd as the type, = = >>>>> with no >>>>> luck. A gpart listing of my SD card: >>>>> >>>>> >>>>> root@fbl:~ # gpart list da3 >>>>> Geom name: da3 >>>>> modified: false >>>>> state: OK >>>>> fwheads: 255 >>>>> fwsectors: 63 >>>>> last: 62521335 >>>>> first: 3 >>>>> entries: 4 >>>>> scheme: GPT >>>>> Providers: >>>>> 1. Name: da3p1 >>>>> Mediasize: 41943040 (40M) >>>>> Sectorsize: 512 >>>>> Stripesize: 0 >>>>> Stripeoffset: 1536 >>>>> Mode: r0w0e0 >>>>> efimedia: >>>>> >>>>> HD(1,GPT,19894dc5-b8b2-11e9-871f-08008a0010e0,0x3,0x14000) >>>>> >>>>> rawuuid: 19894dc5-b8b2-11e9-871f-08008a0010e0 >>>>> rawtype: c12a7328-f81f-11d2-ba4b-00a0c93ec93b >>>>> label: (null) >>>>> length: 41943040 >>>>> offset: 1536 >>>>> type: efi >>>>> index: 1 >>>>> end: 81922 >>>>> start: 3 >>>>> 2. Name: da3p2 >>>>> Mediasize: 31968979456 (30G) >>>>> Sectorsize: 512 >>>>> Stripesize: 0 >>>>> Stripeoffset: 41944576 >>>>> Mode: r0w0e0 >>>>> efimedia: >>>>> >>>>> HD(2,GPT,98786462-be30-11e9-ae6e-08008a0010e0,0x14003,0x3b8bff5) >>>>> >>>>> rawuuid: 98786462-be30-11e9-ae6e-08008a0010e0 >>>>> rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b >>>>> label: (null) >>>>> length: 31968979456 >>>>> offset: 41944576 >>>>> type: freebsd-ufs >>>>> index: 2 >>>>> end: 62521335 >>>>> start: 81923 >>>>> Consumers: >>>>> 1. Name: da3 >>>>> Mediasize: 32010928128 (30G) >>>>> Sectorsize: 512 >>>>> Mode: r0w0e0 >>>>> >>>>> Thanks!! >>>>> >>>>> Mit >>>>> >>>>> From: "S=C3=B8ren Schmidt" >>>> >>>>> > >>>>> >>>>> To: "Marcin Wojtas" >>>> >>>>> mw@semihalf.com>> >>>>> >>>>> Cc: "Mit Matelske" >, >>>>> >>>>> "freebsd-arm" >>>> freebsd-arm@freebsd.org>> >>>>> >>>>> Sent: Tuesday, August 13, 2019 12:55:09 PM >>>>> Subject: Re: Espressobin anyone ? >>>>> >>>>> Hi >>>>> That doesn?t seen to work on the espressobin, or >>>>> >>>>> least I can?t get it to pick it up. >>>>> >>>>> >>>>> I use this patch as a workaround: >>>>> >>>>> Index: main.c >>>>> >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> >>>>> --- main.c (revision 350496) >>>>> +++ main.c (working copy) >>>>> @@ -463,6 +462,13 @@ >>>>> int rv; >>>>> char *rootdev; >>>>> >>>>> +#if defined(__aarch64__) >>>>> + /* SOS HACK in rootdev, at least Espressobin >>>>> >>>>> gets this wrong */ >>>>> >>>>> + printf("Setting currdev hack\n"); >>>>> + set_currdev("disk0p2"); >>>>> + return (0); >>>>> +#endif >>>>> + >>>>> /* >>>>> * First choice: if rootdev is already set, use >>>>> >>>>> that, even if >>>>> >>>>> * it's wrong. >>>>> >>>>> Its not pretty but it does the job until I get time >>>>> >>>>> to look into why bootargs aren?t passed / won?t stick, probably = >>>>> something >>>>> I >>>>> havn?t backported to my -stable12 sources yet... >>>>> >>>>> >>>>> -S=C3=B8ren >>>>> >>>>> On 13 Aug 2019, at 01.38, Marcin Wojtas < >>>>> >>>>> mw@semihalf.com > wrote: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> Not sure if it's what you are looking for, but in >>>>> >>>>> order to autoboot, I >>>>> >>>>> simply pass 'rootdev=3DdiskXpY' in the bootargs >>>>> >>>>> variable. Here's example from >>>>> >>>>> A3720-DB (same should work on EspressoBin): >>>>> >>>>> Marvell>> set bootargs "rootdev=3Ddisk1p1";usb reset; >>>>> >>>>> fatload usb 0:1 >>>>> >>>>> ${fdt_addr} armada-3720-db.dtb; fatload usb 0:1 >>>>> >>>>> ${kernel_addr} >>>>> >>>>> boot/loader.efi; bootefi ${kernel_addr} ${fdt_addr} >>>>> resetting USB... >>>>> USB0: Register 2000104 NbrPorts 2 >>>>> Starting the controller >>>>> USB XHCI 1.00 >>>>> USB1: USB EHCI 1.00 >>>>> - ______ ____ _____ _____ >>>>> | ____| | _ \ / ____| __ \ >>>>> | |___ _ __ ___ ___ | |_) | (___ | | | | >>>>> | ___| '__/ _ \/ _ \| _ < \___ \| | | | >>>>> | | | | | __/ __/| |_) |____) | |__| | >>>>> | | | | | | || | | | >>>>> |_| |_| \___|\___||____/|_____/|_____/ >>>>> ``` >>>>> ` >>>>> ????????????Welcome to FreeBSD????????????? s` >>>>> >>>>> `.....---.......--.``` >>>>> >>>>> -/ >>>>> ? ? +o >>>>> >>>>> .--` /y:` >>>>> >>>>> +. >>>>> ? 1. Boot Multi user [Enter] ? >>>>> >>>>> yo`:. :o >>>>> >>>>> `+- >>>>> ? 2. Boot Single user ? y/ >>>>> >>>>> -/` -o/ >>>>> >>>>> ? 3. Escape to loader prompt ? .- >>>>> ::/sy+:. >>>>> ? 4. Reboot ? / >>>>> >>>>> `-- >>>>> >>>>> / >>>>> ? ? `: >>>>> :` >>>>> ? Options: ? `: >>>>> :` >>>>> ? 5. Kernel: default/kernel (1 of 1) ? / >>>>> / >>>>> ? 6. Boot Options ? .- >>>>> -. >>>>> ? ? -- >>>>> >>>>> -. >>>>> >>>>> ? ? >>>>> >>>>> `:` `:` >>>>> >>>>> ? ? >>>>> >>>>> .-- `--. >>>>> >>>>> ??????????????????????????????????????????? >>>>> >>>>> .---.....----. >>>>> >>>>> Autoboot in 9 seconds, hit [Enter] to boot or any >>>>> >>>>> other key to stop >>>>> >>>>> >>>>> Loading kernel... >>>>> /boot/kernel/kernel text=3D0x95047c >>>>> >>>>> data=3D0x1919d0+0x84aa94 >>>>> >>>>> syms=3D[0x8+0x13aaa8+0x8+0x12610d] >>>>> Loading configured modules... >>>>> can't find '/boot/entropy' >>>>> Using DTB provided by EFI at 0x8000000. >>>>> ---<>--- >>>>> KDB: debugger backends: ddb >>>>> KDB: current backend: ddb >>>>> Copyright (c) 1992-2019 The FreeBSD Project. >>>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, >>>>> >>>>> 1991, 1992, 1993, 1994 >>>>> >>>>> The Regents of the University of California. All >>>>> >>>>> rights reserved. >>>>> >>>>> FreeBSD is a registered trademark of The FreeBSD >>>>> >>>>> Foundation. >>>>> >>>>> FreeBSD 13.0-CURRENT >>>>> >>>>> 17a1fc80d57-c261519(upstream_master) GENERIC arm64 >>>>> >>>>> FreeBSD clang version 8.0.0 (tags/RELEASE_800/final >>>>> >>>>> 356365) (based on LLVM >>>>> >>>>> 8.0.0) >>>>> WARNING: WITNESS option enabled, expect reduced >>>>> >>>>> performance. >>>>> >>>>> VT: init without driver. >>>>> Starting CPU 1 (1) >>>>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >>>>> [...] >>>>> >>>>> Best regards, >>>>> Marcin >>>>> >>>>> pon., 12 sie 2019 o 23:14 Mit Matelske >>>> >>>>> > napisa?(a): >>>>> >>>>> >>>>> >>>>> Soren- >>>>> >>>>> Thanks for the quick response. I built this kernel >>>>> >>>>> with revision 350924. >>>>> >>>>> I'll dig into whats going on in the morning. >>>>> >>>>> Mind posting your diff for your loader.efi? >>>>> >>>>> Thanks again! >>>>> >>>>> Mit >>>>> >>>>> >>>>> ----- Original Message ----- >>>>> From: "S=C3=B8ren Schmidt" >>>> >>>>> > >>>>> >>>>> To: "Mit Matelske" > >>>>> Cc: "tscho" >>>> >>>>> johannes@t-beutel.com>>, "freebsd-arm" < >>>>> >>>>> freebsd-arm@freebsd.org >>>> >>>>> freebsd-arm@freebsd.org>> >>>>> >>>>> Sent: Monday, August 12, 2019 3:49:48 PM >>>>> Subject: Re: Espressobin anyone ? >>>>> >>>>> Hi >>>>> >>>>> Looks like your sources may be too old, you need to >>>>> >>>>> be at least at r348882 >>>>> >>>>> to get the fix for the SD card VCC regulator. >>>>> >>>>> That change fixed it for me backported to 12-stable... >>>>> >>>>> The currdev problem still exists, I have it hardwired >>>>> >>>>> in my loader for >>>>> >>>>> aarch64 :) >>>>> >>>>> -S=C3=B8ren >>>>> >>>>> >>>>> On 12 Aug 2019, at 21.06, Mit Matelske >>>> >>>>> > wrote: >>>>> >>>>> >>>>> I'm having a couple little hiccups booting this board >>>>> >>>>> also. One has >>>>> >>>>> been commented on already, that I can't get the >>>>> >>>>> loader to automatically >>>>> >>>>> start loading the kernel on "disk0p2"... >>>>> >>>>> The second, is that the kernel can't find the SD card >>>>> >>>>> after booting so >>>>> >>>>> it can't mount the root filesystem. I'm using the >>>>> >>>>> dts/dtb and kernel from >>>>> >>>>> the 13-current branch. >>>>> >>>>> Thanks for any and all help. I haven't used u-boot >>>>> >>>>> in about decade. >>>>> >>>>> Spoiled by the x86 platform. >>>>> >>>>> Mit Matelske >>>>> >>>>> >>>>> ***U-boot environment:*** >>>>> >>>>> >>>>> Marvell>> printenv >>>>> baudrate=3D115200 >>>>> bootargs=3Dconsole=3DttyMV0,115200 >>>>> >>>>> earlycon=3Dar3700_uart,0xd0012000 >>>>> >>>>> root=3D/dev/mmcblk0p1 rw rootwait net.ifnames=3D0 >>>>> >>>>> biosdevname=3D0 >>>>> >>>>> bootcmd=3Dmmc dev 0; fatload mmc 0:1 $kernel_addr >>>>> >>>>> $image_name;fatload mmc >>>>> >>>>> 0:1 $fdt_addr $fdt_name; bootefi $kernel_addr >>>>> >>>>> $fdt_addr >>>>> >>>>> bootdelay=3D2 >>>>> bootmmc=3Dmmc dev 0; fatload mmc 0:1 $kernel_addr >>>>> >>>>> $image_name;fatload mmc >>>>> >>>>> 0:1 $fdt_addr $fdt_name; bootefi $kernel_addr >>>>> >>>>> $fdt_addr >>>>> >>>>> console=3Dconsole=3DttyMV0,115200 >>>>> >>>>> earlycon=3Dar3700_uart,0xd0012000 >>>>> >>>>> eth1addr=3D00:51:82:11:22:01 >>>>> eth2addr=3D00:51:82:11:22:02 >>>>> eth3addr=3D00:51:82:11:22:03 >>>>> ethact=3Dneta@30000 >>>>> ethaddr=3DF0:AD:4E:09:6B:8F >>>>> ethprime=3Deth0 >>>>> fdt_addr=3D0x4f00000 >>>>> fdt_high=3D0xffffffffffffffff >>>>> fdt_name=3Defi/boot/armada-3720-espressobin.dtb >>>>> fdtcontroladdr=3D3f7161b8 >>>>> gatewayip=3D10.4.50.254 >>>>> get_images=3Dtftpboot $kernel_addr $image_name; >>>>> >>>>> tftpboot $fdt_addr >>>>> >>>>> $fdt_name; run get_ramfs >>>>> get_ramfs=3Dif test "${ramfs_name}" !=3D "-"; then setenv >>>>> >>>>> ramfs_addr >>>>> >>>>> 0x8000000; tftpboot $ramfs_addr $ramfs_name; else >>>>> >>>>> setenv ramfs_addr -;fi >>>>> >>>>> hostname=3Dmarvell >>>>> image_name=3Defi/freebsd/loader.efi >>>>> initrd_addr=3D0xa00000 >>>>> initrd_size=3D0x2000000 >>>>> ipaddr=3D0.0.0.0 >>>>> kernel_addr=3D0x5000000 >>>>> loadaddr=3D0x5000000 >>>>> netdev=3Deth0 >>>>> netmask=3D255.255.255.0 >>>>> ramfs_addr=3D0x8000000 >>>>> ramfs_name=3D- >>>>> root=3Droot=3D/dev/nfs rw >>>>> rootpath=3D/srv/nfs/ >>>>> serverip=3D0.0.0.0 >>>>> set_bootargs=3Dsetenv bootargs $console $root >>>>> >>>>> ip=3D$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:none >>>>> >>>>> nfsroot=3D$serverip:$rootpath $extra_params >>>>> stderr=3Dserial@12000 >>>>> stdin=3Dserial@12000 >>>>> stdout=3Dserial@12000 >>>>> >>>>> >>>>> ***Full boot logs:*** >>>>> >>>>> >>>>> U-Boot 2017.03-armada-17.10.2-g14aeedc (Jun 01 2018 - >>>>> >>>>> 15:39:10 +0800) >>>>> >>>>> >>>>> Model: Marvell Armada 3720 Community Board ESPRESSOBin >>>>> CPU @ 1000 [MHz] >>>>> L2 @ 800 [MHz] >>>>> TClock @ 200 [MHz] >>>>> DDR @ 800 [MHz] >>>>> DRAM: 1 GiB >>>>> U-Boot DT blob at : 000000003f7161b8 >>>>> Comphy-0: USB3 5 Gbps >>>>> Comphy-1: PEX0 2.5 Gbps >>>>> Comphy-2: SATA0 6 Gbps >>>>> SATA link 0 timeout. >>>>> AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA >>>>> >>>>> mode >>>>> >>>>> flags: ncq led only pmp fbss pio slum part sxs >>>>> PCIE-0: Link down >>>>> MMC: sdhci@d0000: 0, sdhci@d8000: 1 >>>>> SF: Detected mx25u3235f with page size 256 Bytes, >>>>> >>>>> erase size 64 KiB, >>>>> >>>>> total 4 MiB >>>>> Net: eth0: neta@30000 [PRIME] >>>>> Hit any key to stop autoboot: 0 >>>>> switch to partitions #0, OK >>>>> mmc0 is current device >>>>> reading efi/freebsd/loader.efi >>>>> 603872 bytes read in 49 ms (11.8 MiB/s) >>>>> reading efi/boot/armada-3720-espressobin.dtb >>>>> 15946 bytes read in 17 ms (916 KiB/s) >>>>> ## Starting EFI application at 05000000 ... >>>>> Scanning disk sdhci@d0000.blk >>>> >>>>> ... >>>>> >>>>> Card did not respond to voltage select! >>>>> mmc_init: -95, time 50 >>>>> Found 1 disks >>>>> Consoles: EFI console >>>>> FreeBSD/arm64 EFI loader, Revision 1.1 >>>>> >>>>> Command line arguments: loader.efi >>>>> EFI version: 2.05 >>>>> EFI Firmware: Das U-boot (rev 0.00) >>>>> Console: efi (0) >>>>> Failed to find bootable partition >>>>> Startup error in /boot/lua/loader.lua: seconds >>>>> LUA ERROR: cannot open /boot/lua/loader.lua: invalid >>>>> >>>>> argument. >>>>> >>>>> >>>>> can't load 'kernel' >>>>> >>>>> Type '?' for a list of commands, 'help' for more >>>>> >>>>> detailed help. >>>>> >>>>> OK >>>>> OK set currdev=3Ddisk0p2 >>>>> OK boot >>>>> >>>>> /boot/kernel/kernel text=3D0x97d6a0 >>>>> >>>>> data=3D0x191b50+0x84ae94 >>>>> >>>>> syms=3D[0x8+0x137dd8+0x8+0x126260] >>>>> Using DTB provided by EFI at 0x8000000. >>>>> ---<>--- >>>>> KDB: debugger backends: ddb >>>>> KDB: current backend: ddb >>>>> Copyright (c) 1992-2019 The FreeBSD Project. >>>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, >>>>> >>>>> 1991, 1992, 1993, 1994 >>>>> >>>>> The Regents of the University of California. All >>>>> >>>>> rights reserved. >>>>> >>>>> FreeBSD is a registered trademark of The FreeBSD >>>>> >>>>> Foundation. >>>>> >>>>> FreeBSD 13.0-CURRENT GENERIC arm64 >>>>> FreeBSD clang version 6.0.1 (tags/RELEASE_601/final >>>>> >>>>> 335540) (based on >>>>> >>>>> LLVM 6.0.1) >>>>> WARNING: WITNESS option enabled, expect reduced >>>>> >>>>> performance. >>>>> >>>>> VT: init without driver. >>>>> Starting CPU 1 (1) >>>>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >>>>> arc4random: WARNING: initial seeding bypassed the >>>>> >>>>> cryptographic random >>>>> >>>>> device because it was not yet seeded and the knob >>>>> >>>>> 'bypass_before_seeding' >>>>> >>>>> was enabled. >>>>> random: entropy device external interface >>>>> MAP 3e681000 mode 2 pages 1 >>>>> MAP 3ffa6000 mode 2 pages 1 >>>>> kbd0 at kbdmux0 >>>>> ofwbus0: >>>>> simplebus0: on >>>>> >>>>> ofwbus0 >>>>> >>>>> simplebus1: on >>>>> >>>>> simplebus0 >>>>> >>>>> simple_mfd0: mem >>>>> 0x13800-0x138ff,0x13c00-0x13c1f on simplebus1 >>>>> simple_mfd1: mem >>>>> 0x18800-0x188ff,0x18c00-0x18c1f on simplebus1 >>>>> psci0: >>>> >>>>> Driver> on ofwbus0 >>>>> >>>>> gic0: mem >>>>> >>>>> >>>>> 0x1d00000-0x1d0ffff,0x1d40000-0x1d7ffff,0x1d80000-0x1d81fff,0x1d90= 000-0x1d91fff,0x1da0000-0x1dbffff >>>>> >>>>> irq 27 on simplebus1 >>>>> gpio0: 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: 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: on ofwbus0 >>>>> gpioregulator0: cannot get pin 0 >>>>> gpioregulator0: cannot parse parameters >>>>> device_attach: gpioregulator0 attach returned 6 >>>>> generic_timer0: irq 0,1,2,3 on >>>>> >>>>> ofwbus0 >>>>> >>>>> Timecounter "ARM MPCore Timecounter" frequency >>>>> >>>>> 12500000 Hz quality 1000 >>>>> >>>>> Event timer "ARM MPCore Eventtimer" frequency >>>>> >>>>> 12500000 Hz quality 1000 >>>>> >>>>> gpio0: 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: 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: on ofwbus0 >>>>> gpioregulator0: cannot get pin 0 >>>>> gpioregulator0: cannot parse parameters >>>>> device_attach: gpioregulator0 attach returned 6 >>>>> gpio0: 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: 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: on ofwbus0 >>>>> gpioregulator0: cannot get pin 0 >>>>> gpioregulator0: cannot parse parameters >>>>> device_attach: gpioregulator0 attach returned 6 >>>>> gpio0: 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: 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: on ofwbus0 >>>>> gpioregulator0: cannot get pin 0 >>>>> gpioregulator0: cannot parse parameters >>>>> device_attach: gpioregulator0 attach returned 6 >>>>> gpio0: 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: 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: on ofwbus0 >>>>> gpioregulator0: cannot get pin 0 >>>>> gpioregulator0: cannot parse parameters >>>>> device_attach: gpioregulator0 attach returned 6 >>>>> cpulist0: on ofwbus0 >>>>> cpu0: on cpulist0 >>>>> cpu1: on cpulist0 >>>>> pmu0: irq 4 on ofwbus0 >>>>> syscon_generic0: mem 0xd000-0xdfff on >>>>> >>>>> simplebus1 >>>>> >>>>> syscon_generic1: mem 0x11500-0x1153f on >>>>> >>>>> simplebus1 >>>>> >>>>> uart0: mem 0x12000-0x121ff >>>>> >>>>> irq 9,10,11 on >>>>> >>>>> simplebus1 >>>>> uart0: console (115200,n,8,1) >>>>> gpio0: 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: mem 0x14000-0x1405f on >>>>> >>>>> simplebus1 >>>>> >>>>> gpio0: 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: mem 0x30000-0x33fff irq 14 >>>>> >>>>> on simplebus1 >>>>> >>>>> mvneta0: version is 10 >>>>> mvneta0: Ethernet address: 00:a6:39:ca:e8:00 >>>>> mdio0: on mvneta0 >>>>> mdioproxy0: on mdio0 >>>>> e6000sw0: on mdio0 >>>>> e6000sw0: multi-chip addressing mode (0x1) >>>>> e6000sw0: CPU port at 0 >>>>> e6000sw0: fixed port at 0 >>>>> e6000sw0: PHY at port 1 >>>>> miibus0: on e6000sw0 >>>>> e1000phy0: 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: on e6000sw0 >>>>> e1000phy1: 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: on e6000sw0 >>>>> e1000phy2: 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: on e6000sw0 >>>>> xhci0: mem >>>>> >>>>> 0x58000-0x5bfff irq 16 on >>>>> >>>>> simplebus1 >>>>> xhci0: 32 bytes context size, 32-bit DMA >>>>> usbus0 on xhci0 >>>>> syscon_generic3: mem 0x5d800-0x5dfff on >>>>> >>>>> simplebus1 >>>>> >>>>> ehci0: mem >>>>> >>>>> 0x5e000-0x5efff irq >>>>> >>>>> 17 on simplebus1 >>>>> usbus1: EHCI version 1.0 >>>>> usbus1 on ehci0 >>>>> syscon_generic4: mem 0x5f800-0x5ffff on >>>>> >>>>> simplebus1 >>>>> >>>>> sdhci_xenon0: mem >>>>> 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 >>>>> ahci0: mem 0xe0000-0xe0177 irq >>>>> >>>>> 26 on simplebus1 >>>>> >>>>> ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier >>>>> >>>>> supported with FBS >>>>> >>>>> ahcich0: at channel 0 on ahci0 >>>>> device_attach: ahcich0 attach returned 6 >>>>> gpioregulator0: on ofwbus0 >>>>> gpioregulator0: cannot get pin 0 >>>>> gpioregulator0: cannot parse parameters >>>>> device_attach: gpioregulator0 attach returned 6 >>>>> cryptosoft0: >>>>> 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 >>>>> >>>>> >>>>> >>>>> 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 >>>>> >>>>> usbus1 Processor Features 1 =3D <0> >>>>> usbus0 Memory Model Features 0 =3D <4k Granule,64k >>>>> >>>>> Granule,S/NS >>>>> >>>>> Mem,MixedEndian,16bit ASID,1TB PA> >>>>> >>>>> Memory Model Features 1 =3D <> >>>>> Memory Model Features 2 =3D <32b CCIDX,48b VA> >>>>> Debug Features 0 =3D <2 CTX Breakpoints,4 >>>>> >>>>> Watchpoints,6 >>>>> >>>>> Breakpoints,PMUv3,Debug v8> >>>>> Debug Features 1 =3D <0> >>>>> Auxiliary Features 0 =3D <0> >>>>> Auxiliary Features 1 =3D <0> >>>>> CPU 1: ARM Cortex-A53 r0p4 affinity: 1 >>>>> WARNING: WITNESS option enabled, expect reduced >>>>> >>>>> performance. >>>>> >>>>> ugen0.1: at usbus0 >>>>> ugen1.1: at usbus1 >>>>> uhub0 on usbus0 >>>>> uhub1 on usbus1 >>>>> uhub0: >>>> >>>>> 3.00/1.00, addr 1> on >>>>> >>>>> usbus0 >>>>> uhub1: >>>> >>>>> 2.00/1.00, addr 1> on >>>>> >>>>> usbus1 >>>>> uhub0: 2 ports with 2 removable, self powered >>>>> uhub1: 1 port with 1 removable, self powered >>>>> mountroot: waiting for device >>>>> >>>>> /dev/ufs/FreeBSD_Install... >>>>> >>>>> Mounting from ufs:/dev/ufs/FreeBSD_Install failed >>>>> >>>>> with error 19. >>>>> >>>>> >>>>> Loader variables: >>>>> vfs.root.mountfrom=3Dufs:/dev/ufs/FreeBSD_Install >>>>> vfs.root.mountfrom.options=3Dro,noatime >>>>> >>>>> Manual root filesystem specification: >>>>> : [options] >>>>> Mount using filesystem >>>>> and with the specified (optional) option list. >>>>> >>>>> eg. ufs:/dev/da0s1a >>>>> zfs:zroot/ROOT/default >>>>> cd9660:/dev/cd0 ro >>>>> (which is equivalent to: mount -t cd9660 -o ro >>>>> >>>>> /dev/cd0 /) >>>>> >>>>> >>>>> ? List valid disk boot devices >>>>> . Yield 1 second (for background tasks) >>>>> Abort manual input >>>>> >>>>> mountroot> ? >>>>> >>>>> List of GEOM managed disk devices: >>>>> >>>>> >>>>> mountroot> >>>>> _______________________________________________ >>>>> freebsd-arm@freebsd.org >>>> >>>>> 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 >>>> freebsd-arm-unsubscribe@freebsd.org>" >>>>> >>>>> >>>>> _______________________________________________ >>>>> freebsd-arm@freebsd.org >>>> >>>>> 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 >>>> freebsd-arm-unsubscribe@freebsd.org>" >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Emmanuel Vadot < >>>>> >>>>> manu@freebsd.org> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Emmanuel Vadot >>>>> >>>>> >>>>> >>>>> -- >>>>> Emmanuel Vadot >>>>> _______________________________________________ >>>>> freebsd-arm@freebsd.org mailing list >>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >>>>> To unsubscribe, send any mail to " >>>>> >>>>> freebsd-arm-unsubscribe@freebsd.org" >>>>> >>>>> >>>>> >>>>> -- >>>>> Emmanuel Vadot >>>>> _______________________________________________ >>>>> freebsd-arm@freebsd.org mailing list >>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >>>>> To unsubscribe, send any mail to " >>>>> >>>>> freebsd-arm-unsubscribe@freebsd.org" >>>>> >>>>> >>>>> >>>>> -- >>>>> Emmanuel Vadot >>>>> _______________________________________________ >>>>> freebsd-arm@freebsd.org mailing list >>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >>>>> To unsubscribe, send any mail to " >>>>> >>>>> freebsd-arm-unsubscribe@freebsd.org" >>>>> >>>>> >>>>> >>>>> -- >>>>> Emmanuel Vadot >>>> >>>>> manu@bidouilliste.com>> > >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Emmanuel Vadot >>>> >>>>> manu@bidouilliste.com>> > >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Emmanuel Vadot >>>>> _______________________________________________ >>>>> freebsd-arm@freebsd.org mailing list >>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >>>>> To unsubscribe, send any mail to " >>>>> freebsd-arm-unsubscribe@freebsd.org" >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> freebsd-arm@freebsd.org mailing list >>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >>>>> To unsubscribe, send any mail to = >>>>> "freebsd-arm-unsubscribe@freebsd.org" >>>>> >>>>> >>>>> >>> _______________________________________________ >>> freebsd-arm@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.or= g" From owner-freebsd-arm@freebsd.org Wed Aug 21 02:58:53 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7778EE7A54 for ; Wed, 21 Aug 2019 02:58:53 +0000 (UTC) (envelope-from zhangchaowang@gmail.com) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46Csn81fNNz4NmL for ; Wed, 21 Aug 2019 02:58:51 +0000 (UTC) (envelope-from zhangchaowang@gmail.com) Received: by mail-qk1-x734.google.com with SMTP id 125so597910qkl.6 for ; Tue, 20 Aug 2019 19:58:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=8YXS7BoFVTrc+BHX1Tji5lhGa8Kh+AuA0UXVgQKoB9w=; b=e1eID4L47JU9s7PUHMwfXwZXaWO5H2aRGHa2nHvAOeDjmBdDcxW583O4yXy3PpLyox oqNkklsYmhaf9BPb3sMWvnSW6gYEYRwwgkngVOy/Grd2MEAie81/uIAozcy+7F5C01MW qBFdb+W+kQZQSKrig/jLNp40UNnRR8H5vA2ZvpN34yBhcxSUpSe/ACda0S2e0DJeV11r hDOV/nnNmthgmWbiu4zELMqtunoJ81fcHgLz4FwFHxT+tCpzo1WAxB33Qe1Jhvv7WTBM 0ukbuu7ax6+9MCpwVQxLu9vkIzN0g+1od8PsNUVIQvX9NOT29sPmPMm6V7FJ81H8WdFE eUwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=8YXS7BoFVTrc+BHX1Tji5lhGa8Kh+AuA0UXVgQKoB9w=; b=RLl+ENmrhnFugWylLZR83AspMI8FEjtY9FyHhIWzCJmZSBR5mfLqZNcODRXROZXDNq Jsrp3ULMPbICDPrGDtg693Q4s4qzlhGIO6th7oDof3a/RRVGEGURMdIvQ2oGLwL2kbDj idj3WxGa+6tzQdgjgTS+3/J+XeiVXdgBOzKJam5RfWMFnkjf0/KvMPlHPaDf10aPioec SpPm0nQMC9ZTqqg3hF776ncp5wkrw2rikU/P7dFs84tF3T44NBwBTRD9vVg1852iiyIP eykXxCTgoviilQ5RUbhdwk9QtLthoxsz3vSwGB0NAQHLlDMKU0RtqJ1R6ZniX+qilFyT JczA== X-Gm-Message-State: APjAAAW6zQKyaD+XvRgsEaTLhv43JrWD6bs+l2r4ebIkVKAHJPvDbRy5 jxnf1G42xtchdPUbRb6SAAzOKJK5pcA= X-Google-Smtp-Source: APXvYqw1XzG/UqogoofVW07JZg0ng750z3qEflRpNrgzeQVzH07ST1zgb8hoiNOvi0AiLQYxVARFhg== X-Received: by 2002:a37:6715:: with SMTP id b21mr1384251qkc.397.1566356330432; Tue, 20 Aug 2019 19:58:50 -0700 (PDT) Received: from [192.168.2.15] (cpe-76-182-13-165.nc.res.rr.com. [76.182.13.165]) by smtp.gmail.com with ESMTPSA id u13sm10592591qkm.97.2019.08.20.19.58.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Aug 2019 19:58:49 -0700 (PDT) From: Ricky Zhang Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: How to change rootfs from official RPI3 image Message-Id: <0FC8815E-58D7-4196-BF7E-0D6B127B314D@gmail.com> Date: Tue, 20 Aug 2019 22:58:47 -0400 To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 46Csn81fNNz4NmL X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=e1eID4L4; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of zhangchaowang@gmail.com designates 2607:f8b0:4864:20::734 as permitted sender) smtp.mailfrom=zhangchaowang@gmail.com X-Spamd-Result: default: False [-2.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.997,0]; RECEIVED_SPAMHAUS_PBL(0.00)[165.13.182.76.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; FAKE_REPLY(1.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(0.00)[ip: (-9.44), ipnet: 2607:f8b0::/32(-2.92), asn: 15169(-2.36), country: US(-0.05)]; RCVD_IN_DNSWL_NONE(0.00)[4.3.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 02:58:53 -0000 > BTW: Yes, u-boot is opensource: /usr/ports/sysutils/u-boot-rpi3 > There are sysutils/u-boot-* ports for different system. With = sysutils/u-boot-master as the main part of it. >=20 > https://www.freshports.org/sysutils/u-boot-rpi3 = > http://www.denx.de/wiki/U-Boot >=20 > Regards, > Ronald. Hi Ronald, Sorry, if I messed up the mailing list thread. I didn=E2=80=99t receive = your email directly. Instead, I got your reply from daily digest. I have = to copy subject and quote your reply manually in my email client. I have = no idea how to fix it after reading all FAQ = (https://www.freebsd.org/doc/en_US.ISO8859-1/articles/mailing-list-faq/art= icle.html#etiquette = ). Any other mailing list I subscribed didn=E2=80=99t = work this way... In any case, the magic works. I did rsync: rsync -aAXvr --progress --delete /* /mnt/USB \ --exclude=3D'/boot/msdos/*' \ --exclude=3D'/dev/*' \ --exclude=3D'/proc/*' \ --exclude=3D'/net/*' \ --exclude=3D'/tmp/*' \ --exclude=3D'/mnt/*' \ --exclude=3D'/media/*' I confirmed that it mount ssd as rootfs: Ricky@router ~ $ df -h Filesystem Size Used Avail Capacity Mounted on /dev/label/gpt/ssdrootfs 407G 5.5G 369G 1% / devfs 1.0K 1.0K 0B 100% /dev /dev/msdosfs/MSDOSBOOT 50M 13M 37M 26% /boot/msdos tmpfs 50M 4.0K 50M 0% /tmp As you said, kernel still comes from SD card. I don=E2=80=99t fully = understand the FreeBSD boot process. Neither am I familiar with UEFI. - I guess /boot/msdos/uboot.bin finds the SD card roofs system. Load the = kernel from /boot/kernel in SD card and scan /boot/loader.conf to find = the rootfs. Please correct me if I=E2=80=99m wrong. - Should I remove /boot folder from SSD to avoid confusion?=20 - Are there any guide how to compile and deploy kernel? From owner-freebsd-arm@freebsd.org Wed Aug 21 09:56:13 2019 Return-Path: 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 AF294C2177 for ; Wed, 21 Aug 2019 09:56:13 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46D32h33CSz3Fks for ; Wed, 21 Aug 2019 09:56:12 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Date: Wed, 21 Aug 2019 11:56:09 +0200 (CEST) From: Ronald Klop To: Ricky Zhang Cc: freebsd-arm@freebsd.org Message-ID: <1668312327.7.1566381369480@localhost> In-Reply-To: <0FC8815E-58D7-4196-BF7E-0D6B127B314D@gmail.com> References: <0FC8815E-58D7-4196-BF7E-0D6B127B314D@gmail.com> Subject: Re: How to change rootfs from official RPI3 image MIME-Version: 1.0 X-Mailer: Realworks (471.1013.e1f3338f2e1) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 46D32h33CSz3Fks X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 194.109.157.24 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws X-Spamd-Result: default: False [-1.15 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.78)[-0.775,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; NEURAL_HAM_LONG(-0.94)[-0.944,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[klop.ws]; URI_COUNT_ODD(1.00)[21]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.58)[-0.579,0]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[24.157.109.194.list.dnswl.org : 127.0.15.0]; HAS_X_PRIO_THREE(0.00)[3]; IP_SCORE(-0.05)[ipnet: 194.109.0.0/16(-0.16), asn: 3265(-0.12), country: NL(0.01)]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; MIME_TRACE(0.00)[0:+,1:+,2:~] Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 09:56:13 -0000 Sorry, I did only reply to the mailinglist. I will use reply-all now. You are right about uboot finding /boot/kernel and /boot/loader.conf. What you need to do is mount the SD-card on /bootdir; in fstab: /dev/yoursdcard /bootdir ufs rw,noatime 1 2 And a symlink from /boot -> /bootdir/boot on your SSD. Then installworld/installkernel will do the proper thing. So the complete /boot stays on the SD-card. Regards, Ronald. =20 Van: Ricky Zhang Datum: woensdag, 21 augustus 2019 04:58 Aan: freebsd-arm@freebsd.org Onderwerp: Re: How to change rootfs from official RPI3 image >=20 > > BTW: Yes, u-boot is opensource: /usr/ports/sysutils/u-boot-rpi3 > > There are sysutils/u-boot-* ports for different system. With sysutils/u= -boot-master as the main part of it. > > > > https://www.freshports.org/sysutils/u-boot-rpi3 > > http://www.denx.de/wiki/U-Boot > > > > Regards, > > Ronald. >=20 >=20 > Hi Ronald, >=20 > Sorry, if I messed up the mailing list thread. I didn=E2=80=99t receive y= our email directly. Instead, I got your reply from daily digest. I have to = copy subject and quote your reply manually in my email client. I have no id= ea how to fix it after reading all FAQ (https://www.freebsd.org/doc/en_US.I= SO8859-1/articles/mailing-list-faq/article.html#etiquette ). Any other mailing list I subscribed didn=E2=80=99t work this way... >=20 > In any case, the magic works. I did rsync: >=20 > rsync -aAXvr --progress --delete /* /mnt/USB \ > --exclude=3D'/boot/msdos/*' \ > --exclude=3D'/dev/*' \ > --exclude=3D'/proc/*' \ > --exclude=3D'/net/*' \ > --exclude=3D'/tmp/*' \ > --exclude=3D'/mnt/*' \ > --exclude=3D'/media/*' >=20 > I confirmed that it mount ssd as rootfs: >=20 > Ricky@router ~ $ df -h > Filesystem Size Used Avail Capacity Mounted on > /dev/label/gpt/ssdrootfs 407G 5.5G 369G 1% / > devfs 1.0K 1.0K 0B 100% /dev > /dev/msdosfs/MSDOSBOOT 50M 13M 37M 26% /boot/msdos > tmpfs 50M 4.0K 50M 0% /tmp >=20 > As you said, kernel still comes from SD card. I don=E2=80=99t fully under= stand the FreeBSD boot process. Neither am I familiar with UEFI. >=20 > - I guess /boot/msdos/uboot.bin finds the SD card roofs system. Load the = kernel from /boot/kernel in SD card and scan /boot/loader.conf to find the = rootfs. Please correct me if I=E2=80=99m wrong. > - Should I remove /boot folder from SSD to avoid confusion? > - Are there any guide how to compile and deploy kernel? >=20 >=20 >=20 >=20 > _______________________________________________ > 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 From owner-freebsd-arm@freebsd.org Wed Aug 21 11:16:15 2019 Return-Path: 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 56355C44C6 for ; Wed, 21 Aug 2019 11:16:15 +0000 (UTC) (envelope-from zhangchaowang@gmail.com) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46D4q22B1Sz3Kby for ; Wed, 21 Aug 2019 11:16:13 +0000 (UTC) (envelope-from zhangchaowang@gmail.com) Received: by mail-qk1-x72f.google.com with SMTP id w18so1442007qki.0 for ; Wed, 21 Aug 2019 04:16:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=lzmtt2GJxownP5Oh2j74I8hRFZWqKur5qtb4RK6XtG4=; b=fMC6YDz0ObO9Njg9JtL9Ty9A3eE7ZFbRh9Rup7pOvKjonBAhQuva/3/a/0++Fh+TIL /QUgUtJBfwLZjSBqKHfKT/2NwVMF3IGju2g9Wj69UA8ysCJZNemJbprpF3w5k3RKp/uc FRwE+LnZ8UT59tfGgy8bc+4tcjMilivsKaVw4ienYiJEdAfeS/rG6aBUlYYgeasZAgJa WCtd2KyIs6MyL7KKTgabMS7PETGSBkMVmkNurFVDuk67i4pir1cf4EIs0LSBcO2IrPTA f1QsEYRdl98mjdle27LMnWHGWlJifTshfZ6tU8xCZyMaw2SC5oQRsrLd4IeKWqkEb05N qegA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=lzmtt2GJxownP5Oh2j74I8hRFZWqKur5qtb4RK6XtG4=; b=eZYbLQV3EGM4V73RvIyILuZSuUgNmLRit1kPFOWjRS4+h5aLajC8PlIwaTMOwG3To3 kxSmDYMHuNtUnBtG25nqSr6dtB2EN3roH6TSEuIIhigg3Vguf6dQV35mzor0N13Nnzzf vW4UDFvtFyeMlM1sItrch4GtEkYTErT9BPTZo71h4gxjL3DS98VFcig9WBowVcd37hBg WeCAUiFeUJomZVtGGHMiLWIe2Lz/zG+VXpDgHuyd3JH7xSMKbTl109KPW5l651Y2CO5F TKJBLRviUNiHVak+MSVTDQqbEq0eAV3qiv+gEniQgITgSYfzXv32EYWMOTIFpS5Ma93O YnZg== X-Gm-Message-State: APjAAAWWm8qYeI3UflBeYFlRLyvOji9og2Lbo+3gXFjPfEU7tEWTGIBb jVZiPIev0UoR3PtlpQmZApY= X-Google-Smtp-Source: APXvYqwChLEhA2pKEaZLcYGbidOAQNT6KmNDkWbnAoYePcBtWYNXEA8yFIQXUyc4Xjb/66cipsppJw== X-Received: by 2002:a37:4b49:: with SMTP id y70mr28500670qka.447.1566386172918; Wed, 21 Aug 2019 04:16:12 -0700 (PDT) Received: from [192.168.2.15] (cpe-76-182-13-165.nc.res.rr.com. [76.182.13.165]) by smtp.gmail.com with ESMTPSA id x28sm11172767qtk.8.2019.08.21.04.16.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Aug 2019 04:16:12 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: How to change rootfs from official RPI3 image From: Ricky Zhang X-Priority: 3 (Normal) In-Reply-To: <1668312327.7.1566381369480@localhost> Date: Wed, 21 Aug 2019 07:16:11 -0400 Cc: freebsd-arm@freebsd.org Message-Id: References: <0FC8815E-58D7-4196-BF7E-0D6B127B314D@gmail.com> <1668312327.7.1566381369480@localhost> To: Ronald Klop X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 46D4q22B1Sz3Kby X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=fMC6YDz0; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of zhangchaowang@gmail.com designates 2607:f8b0:4864:20::72f as permitted sender) smtp.mailfrom=zhangchaowang@gmail.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; HAS_X_PRIO_THREE(0.00)[3]; NEURAL_HAM_SHORT(-1.00)[-0.996,0]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RECEIVED_SPAMHAUS_PBL(0.00)[165.13.182.76.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[f.2.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(0.00)[ip: (-9.49), ipnet: 2607:f8b0::/32(-2.91), asn: 15169(-2.35), country: US(-0.05)]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 11:16:15 -0000 Your idea is brilliant. It solved the dilemma.=20 Ricky@router ~ $ sudo cat /etc/fstab # Custom /etc/fstab for FreeBSD embedded images /dev/ufs/rootfs /bootdir ufs rw 1 1 /dev/label/gpt/ssdrootfs / ufs rw 1 1 /dev/msdosfs/MSDOSBOOT /boot/msdos msdosfs rw,noatime 0 0 tmpfs /tmp tmpfs rw,mode=3D1777,size=3D50m 0 0 Ricky@router ~ $ mount /dev/label/gpt/ssdrootfs on / (ufs, local, soft-updates) devfs on /dev (devfs, local, multilabel) /dev/ufs/rootfs on /bootdir (ufs, local, soft-updates) /dev/msdosfs/MSDOSBOOT on /bootdir/boot/msdos (msdosfs, local, noatime) tmpfs on /tmp (tmpfs, local) I wrote the whole thing down in my wiki: = https://github.com/rickyzhang82/FreeBSDWiki/wiki/1.-Migrate-SD-card-rootfs= -to-SSD-for-RPI3 = Thanks Ricky > On Aug 21, 2019, at 5:56 AM, Ronald Klop wrote: >=20 > Sorry, I did only reply to the mailinglist. I will use reply-all now. >=20 > You are right about uboot finding /boot/kernel and /boot/loader.conf. >=20 > What you need to do is mount the SD-card on /bootdir; in fstab: > /dev/yoursdcard /bootdir ufs rw,noatime 1 2 >=20 > And a symlink from /boot -> /bootdir/boot on your SSD. >=20 > Then installworld/installkernel will do the proper thing. > So the complete /boot stays on the SD-card. >=20 > Regards, >=20 > Ronald. >=20 > Van: Ricky Zhang > Datum: woensdag, 21 augustus 2019 04:58 > Aan: freebsd-arm@freebsd.org > Onderwerp: Re: How to change rootfs from official RPI3 image >=20 > > BTW: Yes, u-boot is opensource: /usr/ports/sysutils/u-boot-rpi3 > > There are sysutils/u-boot-* ports for different system. With = sysutils/u-boot-master as the main part of it. > > > > https://www.freshports.org/sysutils/u-boot-rpi3 = = > > > http://www.denx.de/wiki/U-Boot = > > > > > Regards, > > Ronald. >=20 >=20 > Hi Ronald, >=20 > Sorry, if I messed up the mailing list thread. I didn=E2=80=99t = receive your email directly. Instead, I got your reply from daily = digest. I have to copy subject and quote your reply manually in my email = client. I have no idea how to fix it after reading all FAQ = (https://www.freebsd.org/doc/en_US.ISO8859-1/articles/mailing-list-faq/art= icle.html#etiquette = = >). Any other mailing list I subscribed didn=E2=80=99t= work this way... >=20 > In any case, the magic works. I did rsync: >=20 > rsync -aAXvr --progress --delete /* /mnt/USB \ > --exclude=3D'/boot/msdos/*' \ > --exclude=3D'/dev/*' \ > --exclude=3D'/proc/*' \ > --exclude=3D'/net/*' \ > --exclude=3D'/tmp/*' \ > --exclude=3D'/mnt/*' \ > --exclude=3D'/media/*' >=20 > I confirmed that it mount ssd as rootfs: >=20 > Ricky@router ~ $ df -h > Filesystem Size Used Avail Capacity Mounted on > /dev/label/gpt/ssdrootfs 407G 5.5G 369G 1% / > devfs 1.0K 1.0K 0B 100% /dev > /dev/msdosfs/MSDOSBOOT 50M 13M 37M 26% /boot/msdos > tmpfs 50M 4.0K 50M 0% /tmp >=20 > As you said, kernel still comes from SD card. I don=E2=80=99t fully = understand the FreeBSD boot process. Neither am I familiar with UEFI. >=20 > - I guess /boot/msdos/uboot.bin finds the SD card roofs system. Load = the kernel from /boot/kernel in SD card and scan /boot/loader.conf to = find the rootfs. Please correct me if I=E2=80=99m wrong. > - Should I remove /boot folder from SSD to avoid confusion? > - Are there any guide how to compile and deploy kernel? >=20 >=20 >=20 >=20 > _______________________________________________ > 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" From owner-freebsd-arm@freebsd.org Wed Aug 21 12:15:06 2019 Return-Path: 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 A1526C6B9C for ; Wed, 21 Aug 2019 12:15:06 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46D66x1tL8z3Ndy for ; Wed, 21 Aug 2019 12:15:04 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Date: Wed, 21 Aug 2019 14:15:02 +0200 (CEST) From: Ronald Klop To: Ricky Zhang Cc: freebsd-arm@freebsd.org Message-ID: <61580006.14.1566389702495@localhost> In-Reply-To: References: <0FC8815E-58D7-4196-BF7E-0D6B127B314D@gmail.com> <1668312327.7.1566381369480@localhost> Subject: Re: How to change rootfs from official RPI3 image MIME-Version: 1.0 X-Mailer: Realworks (472.1017.0f7ee417e6d) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 46D66x1tL8z3Ndy X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 194.109.157.24 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws X-Spamd-Result: default: False [-2.67 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.980,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; NEURAL_HAM_LONG(-1.00)[-0.998,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[klop.ws]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.83)[-0.834,0]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[24.157.109.194.list.dnswl.org : 127.0.15.0]; HAS_X_PRIO_THREE(0.00)[3]; IP_SCORE(-0.05)[ipnet: 194.109.0.0/16(-0.16), asn: 3265(-0.12), country: NL(0.01)]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; MIME_TRACE(0.00)[0:+,1:+,2:~] Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 12:15:06 -0000 Thanks. I will not take the credits for the idea though. :-) The FreeBSD wiki has some more examples of similar setups: https://wiki.freebsd.org/ZFSOnRoot describes how to do /boot on UFS and the= rest on ZFS, which is similar to /boot on SD-card and the rest on SSD. https://wiki.freebsd.org/RootOnZFS/UFSBoot Nice that you made a write up also. More exposure for FreeBSD is always a g= ood thing. :-) Good luck and keep hacking. Ronald. =20 Van: Ricky Zhang Datum: woensdag, 21 augustus 2019 13:16 Aan: Ronald Klop CC: freebsd-arm@freebsd.org Onderwerp: Re: How to change rootfs from official RPI3 image >=20 > Your idea is brilliant. It solved the dilemma.=20 > >>=20 >> Ricky@router ~ $ sudo cat /etc/fstab >> # Custom /etc/fstab for FreeBSD embedded images >> /dev/ufs/rootfs /bootdir ufs rw 1 1 >> /dev/label/gpt/ssdrootfs / ufs rw 1 1 >> /dev/msdosfs/MSDOSBOOT /boot/msdos msdosfs rw,noatime 0 0 >> tmpfs /tmp tmpfs rw,mode=3D1777,size=3D50m 0 0 >> =20 >> Ricky@router ~ $ mount >> /dev/label/gpt/ssdrootfs on / (ufs, local, soft-updates) >> devfs on /dev (devfs, local, multilabel) >> /dev/ufs/rootfs on /bootdir (ufs, local, soft-updates) >> /dev/msdosfs/MSDOSBOOT on /bootdir/boot/msdos (msdosfs, local, noatime) >> tmpfs on /tmp (tmpfs, local) >=20 > =20 > I wrote the whole thing down in my wiki: https://github.com/rickyzhang82/= FreeBSDWiki/wiki/1.-Migrate-SD-card-rootfs-to-SSD-for-RPI3 > =20 > Thanks > =20 > Ricky > >>=20 >> On Aug 21, 2019, at 5:56 AM, Ronald Klop wrote: >> =20 >> Sorry, I did only reply to the mailinglist. I will use reply-all now. >>=20 >> You are right about uboot finding /boot/kernel and /boot/loader.conf. >>=20 >> What you need to do is mount the SD-card on /bootdir; in fstab: >> /dev/yoursdcard /bootdir ufs rw,noatime 1 2 >>=20 >> And a symlink from /boot -> /bootdir/boot on your SSD. >>=20 >> Then installworld/installkernel will do the proper thing. >> So the complete /boot stays on the SD-card. >>=20 >> Regards, >>=20 >> Ronald. >> =20 >> Van: Ricky Zhang >> Datum: woensdag, 21 augustus 2019 04:58 >> Aan: freebsd-arm@freebsd.org >> Onderwerp: Re: How to change rootfs from official RPI3 image >>>=20 >>> > BTW: Yes, u-boot is opensource: /usr/ports/sysutils/u-boot-rpi3 >>> > There are sysutils/u-boot-* ports for different system. With sysutils= /u-boot-master as the main part of it. >>> > >>> > https://www.freshports.org/sysutils/u-boot-rpi3 >>> > http://www.denx.de/wiki/U-Boot >>> > >>> > Regards, >>> > Ronald. >>>=20 >>>=20 >>> Hi Ronald, >>>=20 >>> Sorry, if I messed up the mailing list thread. I didn=E2=80=99t receive= your email directly. Instead, I got your reply from daily digest. I have t= o copy subject and quote your reply manually in my email client. I have no = idea how to fix it after reading all FAQ (https://www.freebsd.org/doc/en_US= .ISO8859-1/articles/mailing-list-faq/article.html#etiquette ). Any other mailing list I subscribed didn=E2=80=99t work this way... >>>=20 >>> In any case, the magic works. I did rsync: >>>=20 >>> rsync -aAXvr --progress --delete /* /mnt/USB \ >>> --exclude=3D'/boot/msdos/*' \ >>> --exclude=3D'/dev/*' \ >>> --exclude=3D'/proc/*' \ >>> --exclude=3D'/net/*' \ >>> --exclude=3D'/tmp/*' \ >>> --exclude=3D'/mnt/*' \ >>> --exclude=3D'/media/*' >>>=20 >>> I confirmed that it mount ssd as rootfs: >>>=20 >>> Ricky@router ~ $ df -h >>> Filesystem Size Used Avail Capacity Mounted on >>> /dev/label/gpt/ssdrootfs 407G 5.5G 369G 1% / >>> devfs 1.0K 1.0K 0B 100% /dev >>> /dev/msdosfs/MSDOSBOOT 50M 13M 37M 26% /boot/msdos >>> tmpfs 50M 4.0K 50M 0% /tmp >>>=20 >>> As you said, kernel still comes from SD card. I don=E2=80=99t fully und= erstand the FreeBSD boot process. Neither am I familiar with UEFI. >>>=20 >>> - I guess /boot/msdos/uboot.bin finds the SD card roofs system. Load th= e kernel from /boot/kernel in SD card and scan /boot/loader.conf to find th= e rootfs. Please correct me if I=E2=80=99m wrong. >>> - Should I remove /boot folder from SSD to avoid confusion? >>> - Are there any guide how to compile and deploy kernel? >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> 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 >=20 From owner-freebsd-arm@freebsd.org Thu Aug 22 17:27:09 2019 Return-Path: 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 66B71CDA6A for ; Thu, 22 Aug 2019 17:27:09 +0000 (UTC) (envelope-from khantroll@gmail.com) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46Ds0X3RTgz3CN2 for ; Thu, 22 Aug 2019 17:27:08 +0000 (UTC) (envelope-from khantroll@gmail.com) Received: by mail-ot1-x334.google.com with SMTP id m24so6161835otp.12 for ; Thu, 22 Aug 2019 10:27:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=GSKftrR5eXMmtV8Ql4zIutvZQ78Vmm0N25yVXzXwDeI=; b=Os0M9G91D8oW9tbIu2qLoaCe+un4Hau+3OFmILGD/jlTDFykXaODTDsD0aDFMlhSWD 8GZzcYZDX5WDxvV4y0+bsIldYhM+yCr8OIWHPoM4oghMGAgLlhWKQ70f8AT8tMWJKUPY 5JnPGeg7pMlLr22uGJ7lULHU2VYy0x9PCPFsvbBBSSHTdwOozY422v+cRo/CSFALU/2H foKcNK0LLCGYB/Wxs9fB6CZj6iDyj11FvyLZjPTe4QEFerKeYTL0uq90LaI0nStofwdf O7cTMZ8+zsjHOrQPhl2oZ3BvODBNNve6Dyc0QhI69ED5nZPo6J3jQJ/ZTyALVmt9p/hR +MlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=GSKftrR5eXMmtV8Ql4zIutvZQ78Vmm0N25yVXzXwDeI=; b=cHC9J3m+W3dFMehNK4+yVJcpkl7Td2tJdSEerlk1vbOeuDifSIYt/MXDTJOYyb5act ip50pQeOmnjHfVaSHibdbkj0nx5GDsMjJLrq9Nces1whsS+R2fEhiiQa6ZkAq2b2WjyE G8Cf8C/wQRvPl2nvY7agLOGi+9Zaayfrt7S4XhJ0pCYPZ4h70+7GOiUTUxiOxmrkGdmo fFDIZslwSU2v+nCLj76RVSpYyjMjJZMdadfg8ZNcZT6jKct8QGo+2RkKVuf4YFcad9h0 r7d8lu6Au8DkcDLfM43hwOMKUSV4+Z+G5szkhJ14Omq2d87i9RrV6uuHpUy8lBEbl7IC FbeQ== X-Gm-Message-State: APjAAAUOd4/Hlpy54H1py+VWYQgD4gZ3EeyRKFYlhZ+fADmiGqff453X bzfiIpklFBc1MHx7UOF8aP1NXWXHW5grd6r473Pr8aVC X-Google-Smtp-Source: APXvYqyNu4yUzl8DdfAp4jNJmROvMabqkBrVPZAN5Yw68WQKEaw2dmI6aaxADjYdw6dek3HX5qlSEgsu+Jpr7mIWAsw= X-Received: by 2002:a9d:1288:: with SMTP id g8mr598198otg.306.1566494826358; Thu, 22 Aug 2019 10:27:06 -0700 (PDT) MIME-Version: 1.0 References: <20190817153053.5592b15b8a42982fda0fc123@bidouilliste.com> <9749945A-FDAD-47E0-947A-FA62138C2F83@gmail.com> <20190817210822.8920656bad0855b554883cf2@bidouilliste.com> <2D6D4BDA-75EC-403F-B5E2-52A468369DE2@gmail.com> <627099DD-804B-412F-A083-768CEFCF955C@gmail.com> <6DA8E736-8031-4BF7-8B20-CF8B0E8A7FEF@gmail.com> <2002575095.53.1566305166664@localhost> In-Reply-To: From: Jeffrey Bowers Date: Thu, 22 Aug 2019 17:27:00 -0500 Message-ID: Subject: Re: Espressobin anyone ? To: Ronald Klop , freebsd-arm X-Rspamd-Queue-Id: 46Ds0X3RTgz3CN2 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=Os0M9G91; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of khantroll@gmail.com designates 2607:f8b0:4864:20::334 as permitted sender) smtp.mailfrom=khantroll@gmail.com X-Spamd-Result: default: False [2.00 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; DATE_IN_FUTURE(4.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.998,0]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (-6.87), ipnet: 2607:f8b0::/32(-2.90), asn: 15169(-2.35), country: US(-0.05)]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.117.48,0.0.46.224]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[4.3.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; HTTP_TO_IP(1.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2019 17:27:09 -0000 No, unfortunately it still ends in an E000060: Operation timed out. However, there are files and directories in my local ports directory, so it's downloading at least some things. On Tue, Aug 20, 2019 at 2:01 PM Ronald Klop wrote: > On Wed, 21 Aug 2019 01:03:37 +0200, Jeffrey Bowers > wrote: > > Yes sir, I can ping svn.freebsd.org. Any idea why the checkout fails? > > > I don't know. What ip address do you get when pinging? > > Does this work for you? Does it work using the ip address you get? > > svn checkout https://213.138.116.72/ports/head > > Regards, > Ronald. > > > > > On Tue, Aug 20, 2019 at 7:46 AM Ronald Klop wrote: > >> It is not possible to 'ping https://svn.freebsd.org/ports/head'. >> You can 'ping svn.freebsd.org'. >> >> Ronald. >> >> >> *Van:* Jeffrey Bowers >> *Datum:* dinsdag, 20 augustus 2019 14:36 >> *Aan:* "S=C3=B8ren Schmidt" , freebsd-arm < >> freebsd-arm@freebsd.org> >> *Onderwerp:* Re: Espressobin anyone ? >> >> I just tried to ping https://svn.freebsd.org/ports/head, and even thoug= h >> it scrolsl through all that text I get an error saying "could not resolv= e >> https://svn.freebsd.org/ports/head ; unknown server error" . I can ping >> google just fine. Is it a DNS issue? >> >> On Tue, Aug 20, 2019 at 7:33 AM Jeffrey Bowers >> wrote: >> >> > I'm still getting: svn: E000060: Operation timed out >> > It goes for several minutes scrolling through text, and I feel like >> using >> > your link got further. >> > >> > Thanks! >> > >> > On Tue, Aug 20, 2019 at 2:49 AM S=C3=B8ren Schmidt >> > wrote: >> > >> >> Hmm, I use this URL >> >> >> >> Repository Root: https://svn.freebsd.org/ports/head >> >> >> >> Not sure the svn+ssh thing works=E2=80=A6 >> >> >> >> -S=C3=B8ren >> >> >> >> >> >> On 20 Aug 2019, at 02.38, Jeffrey Bowers wrote: >> >> >> >> Hi all, >> >> >> >> I'm having trouble getting subversion to work. When I run: >> >> >> >> svn checkout https://svn.FreeBSD.org/ports/head /usr/ports >> >> >> >> It scrolls through many lines of text before stating: svn: E000060: >> >> Operation timed out >> >> >> >> When I run: >> >> >> >> svn checkout svn+ssh://repo.freebsd.org/ports/head /usr/ports >> >> >> >> It tells me that the authenticity of the host cannot be identified, a= nd >> >> asks me to confirm that I want to connect. I say yes, and then it say= s: >> >> >> >> svn: E170013: Unable to connect to a repository at URL 'svn+ssh:// >> >> repo.freebsd.org/ports/head' >> >> svn: E210002: To better debug SSH connection problems, remove the -q >> >> option >> >> from 'ssh' in the [tunnels] section of your Subversion configuration >> file. >> >> >> >> Any ideas? >> >> >> >> Thanks in advance! >> >> >> >> On Mon, Aug 19, 2019 at 8:51 PM Jeffrey Bowers >> >> wrote: >> >> >> >> I didn't think it remounting. Thank you! >> >> >> >> On Mon, Aug 19, 2019 at 11:39 AM S=C3=B8ren Schmidt < >> soren.schmidt@gmail.com> >> >> wrote: >> >> >> >> Hi Jeffrey >> >> >> >> You need to unmount the /tmp filesystem :) >> >> You can do that permanently by commenting it out in /etc/fstab >> >> >> >> >> >> On 19 Aug 2019, at 21.45, Jeffrey Bowers wrote: >> >> >> >> Hi Soren, >> >> >> >> I'm getting the same error message. Any other ideas what it might be? >> >> It's got to be something in the partition scheme or the file >> permissions, >> >> but I'm just not sure what. >> >> >> >> >> >> On Sun, Aug 18, 2019 at 10:03 AM Jeffrey Bowers >> >> wrote: >> >> >> >> D=E2=80=99Oh! I thought I too care of that with gpart. I literally mi= ssed >> growfs >> >> part of the instructions.. >> >> >> >> On Sun, Aug 18, 2019 at 10:00 AM S=C3=B8ren Schmidt < >> soren.schmidt@gmail.com> >> >> wrote: >> >> >> >> Hi >> >> >> >> You are out of space :) >> >> >> >> Boot the board into singleuser mode, and do =E2=80=9Cservice growfs s= tart=E2=80=9D, >> >> that will expand you / filesystem to the entire SD card=E2=80=A6 >> >> >> >> -S=C3=B8ren >> >> >> >> On 18 Aug 2019, at 14.50, Jeffrey Bowers wrote: >> >> >> >> Sure thing! Here's the screenshot! >> >> >> >> >> >> >> >> On Sun, Aug 18, 2019 at 7:35 AM S=C3=B8ren Schmidt > > >> >> wrote: >> >> >> >> Hi >> >> >> >> Can I have you paste the output from df -h ? >> >> >> >> You should be able to utilise the full SD card=E2=80=A6 >> >> >> >> -S=C3=B8ren >> >> >> >> On 18 Aug 2019, at 14.29, Jeffrey Bowers wrote: >> >> >> >> Hi, >> >> >> >> Just make sure I understand the process, I should hook up a hard disk >> >> and map it to to /TMP ? >> >> >> >> I already tried just unmapping /tmp, and it gave me the same error >> >> once, and then the next time I ran it I got an error saying /usr/port= s >> was >> >> out of space )which I guess I shouldn=E2=80=99t mount to another dire= ctor on >> the >> >> hard drive? >> >> >> >> On Sun, Aug 18, 2019 at 5:11 AM S=C3=B8ren Schmidt > > >> >> wrote: >> >> >> >> Hi Jeffrey >> >> >> >> You can unmount the memory disk on /tmp to get at the space on the SD >> >> card. >> >> >> >> It is however not recommend to use the AD card for random storage, it >> >> will wear out fast, that=E2=80=99s why the memory disk is setup. >> >> >> >> You could connect a SSD og laptop disk to the SATA interface and use >> >> that for the workload. >> >> >> >> However compiling is slow, its much much faster to cross compile on a >> >> PC=E2=80=A6 >> >> >> >> -S=C3=B8ren >> >> >> >> On 18 Aug 2019, at 00.22, Jeffrey Bowers wrote: >> >> >> >> Hi! I've got a new one :) >> >> I'm trying to do an svn checkout to fix the pkg problem, but it tells >> >> me it can't write to a to a temp folder because there is no room left >> on >> >> the device. However, FreeBSD partition is 29GB. It's never also never >> the >> >> same file in TMP that it can't write to. Here is a screenshot of the >> >> issue, >> >> along with the output of gpart: >> >> >> >> >> >> >> >> Any ideas? >> >> >> >> Thanks! >> >> >> >> >> >> On Sat, Aug 17, 2019 at 2:08 PM Emmanuel Vadot >> >> wrote: >> >> >> >> On Sat, 17 Aug 2019 17:14:36 +0200 >> >> S=C3=B8ren Schmidt wrote: >> >> >> >> HI >> >> >> >> Well, I have a whole forrest of tree?s here, but the error posted >> >> >> >> here was on a clean checkout. >> >> >> >> >> >> Anyhow, with the latest changes to -stable and the two >> >> >> >> RF_SHAREABLE patches from -current all works. >> >> >> >> I've reverted the commits, see >> >> https://github.com/evadot/freebsd/commits/a37x0_gpio for a better >> >> way >> >> to deal with this issue. >> >> I'm waiting for mmel@ as he wrote the syscon_get_default_handle >> >> part. >> >> >> >> It would be nice with the etherswitch changes as well so VLAN >> >> >> >> tagging etc was standard. >> >> >> >> >> >> -S=C3=B8ren >> >> >> >> PS: given up on bottom & inline popsting, top posting is all the >> >> >> >> rage now (yeah I miss elm etc :) ) >> >> >> >> >> >> On 17 Aug 2019, at 15.30, Emmanuel Vadot >> >> >> >> wrote: >> >> >> >> >> >> On Sat, 17 Aug 2019 11:07:22 +0200 >> >> S=C3=B8ren Schmidt > >> >> >> soren.schmidt@gmail.com>> wrote: >> >> >> >> >> >> Hi Emmunuel >> >> >> >> Yes the 3720 gpio driver I already back ported long ago, its >> >> >> >> needed, I?m happy its now part of std stable 12! >> >> >> >> >> >> Would have been nice of you to say that you were not running a >> >> >> >> clean >> >> >> >> tree. >> >> >> >> My issue seems to be the inclusion of the phy_usb driver, if I >> >> >> >> leave that out, I?m back to normal.. >> >> >> >> >> >> What make you think this is this driver ? What works/doesn't work >> >> with it ? could you provide logs. >> >> >> >> I?ll have have another go at the latest -stable sources during >> >> >> >> the weekend and see how it goes. >> >> >> >> >> >> Thanks for looking into this, with a little cooperation we?ll >> >> >> >> get this solved for the greater good.. >> >> >> >> >> >> -S=C3=B8ren >> >> >> >> >> >> P.S. Please stop top posting, it's really hard to read the >> >> >> >> conversation >> >> >> >> >> >> On 16 Aug 2019, at 22.58, Emmanuel Vadot < >> >> >> >> manu@bidouilliste.com> wrote: >> >> >> >> >> >> On Fri, 16 Aug 2019 19:12:30 +0200 >> >> Emmanuel Vadot > >> >> >> manu@bidouilliste.com>> wrote: >> >> >> >> >> >> On Fri, 16 Aug 2019 17:10:37 +0200 >> >> Emmanuel Vadot wrote: >> >> >> >> On Fri, 16 Aug 2019 15:24:54 +0200 >> >> Emmanuel Vadot wrote: >> >> >> >> On Fri, 16 Aug 2019 07:28:59 +0200 >> >> S=C3=B8ren Schmidt wrote: >> >> >> >> Hi >> >> >> >> Very simple, reverting sys/gnu/dts to what was before >> >> >> >> 350595 (actually 350592). >> >> >> >> Thats what we have svn for ? >> >> >> >> >> >> If I asked how it was to have the svn command that you >> >> >> >> used, I want to >> >> >> >> make sure that you didn't revert anything else, like do you >> >> >> >> have >> >> >> >> r350596 and r350628 ? >> >> >> >> That does make my bananapi work again, no other changes >> >> >> >> just a recompiled kernel. >> >> >> >> >> >> That + copying the dtb to the fat32 partition ? >> >> >> >> Can you post the dtb somewhere. >> >> >> >> However it does not bring the Espressobin back to life, >> >> >> >> thats something in one of the ~30 other files that changed between >> those >> >> two revisions. >> >> >> >> >> >> What Linux version of DTS are you using then ? The ones >> >> >> >> that were in >> >> >> >> stable/12 when it was branched (4.18) or a later revision ? >> >> >> >> >> >> So I think that I've found the problem on the Espressobin. >> >> I think that the problem comes from the simple-mfd driver >> >> >> >> that I've >> >> >> >> mfc in r350600. >> >> The pinctrl/gpio controller compatible is >> >> "marvell,armada3710-nb-pinctrl", "syscon", "simple-mfd" and >> >> >> >> it attaches >> >> >> >> at BUS_PASS_INTERRUPT while the simple_mfd driver attaches at >> >> BUS_PASS_BUS (so earlier) which means that no gpio >> >> >> >> controller will be >> >> >> >> available for sdhci to detect the card. >> >> >> >> If someone with a non-working espressobin could post a full >> >> >> >> verbose >> >> >> >> boot log that would help me confirming that this is the case. >> >> I'll try to find a solution on how to solve this problem. >> >> >> >> >> >> So this wasn't the problem but I've found it, see r351129 and >> >> >> >> r351130 >> >> >> >> >> >> SD card now work again in HEAD, I'll have a look at stable >> >> >> >> later next >> >> >> >> week. >> >> >> >> >> >> I've did a quick test and I've MFC r348880, r348882 and >> >> >> >> r349596, the >> >> >> >> two other commits needed to be mfc'ed are the one I did today >> >> >> >> on head, >> >> >> >> I'll do that next week. >> >> With them sdcard is working again on stable/12 >> >> >> >> -S=C3=B8ren >> >> >> >> On 15 Aug 2019, at 23.37, Emmanuel Vadot < >> >> >> >> manu@bidouilliste.com> wrote: >> >> >> >> >> >> On Thu, 15 Aug 2019 21:56:23 +0200 >> >> S=C3=B8ren Schmidt wrote: >> >> >> >> >> >> Well, I don?t care where you are from and what color you >> >> >> >> have :) >> >> >> >> >> >> Now, if I update my stable12 sources to r350595 the >> >> >> >> bananapi breaks, if revert sys/gnu/dts it works again, go figure.. >> >> >> >> >> >> Reverting to what ? and how ? >> >> >> >> Because I've just test 12-stable and I have the problem >> >> >> >> that I've said >> >> >> >> in my previous mail so setting >> >> >> >> hw.regulator.disable_unused=3D0 is the >> >> >> >> work around. >> >> The problem is in twsi not in the DTS so I'm curious how >> >> >> >> reverting >> >> >> >> only the dts fixes this problem. >> >> >> >> The r351099 fix is already like that in -stable, and not >> >> >> >> part of the problem. >> >> >> >> >> >> -S=C3=B8ren >> >> >> >> >> >> On 15 Aug 2019, at 21.03, Emmanuel Vadot < >> >> >> >> manu@bidouilliste.com> wrote: >> >> >> >> >> >> On Thu, 15 Aug 2019 19:48:54 +0200 >> >> S=C3=B8ren Schmidt wrote: >> >> >> >> Hi Mit! >> >> >> >> Right, I suspected that, 12-stable broke many embedded >> >> >> >> systems between r350592 and r350595 where all the latest and greatest >> DTS >> >> files was pulled in, I guess the same holds for -current. >> >> >> >> >> >> -S=C3=B8ren >> >> >> >> >> >> Mhm it's fun that you think that DTS import is the >> >> >> >> source of all your >> >> >> >> problems, I get it, it's easy to blame the French guy >> >> >> >> that bulk import >> >> >> >> the DTS, he surely don't know what he is doing. >> >> Anyway, two problems were raised in this thread : >> >> >> >> 1) BananaPi (A20) doesn't boot >> >> 2) Espressobin sd support is broken >> >> >> >> I've just looked at the BananaPi problem today, I've >> >> >> >> fixed a first >> >> >> >> problem in r351099. >> >> The main problem is that when we disable the unused >> >> >> >> regulators we hang >> >> >> >> when trying to disabling ldo3. It's weird because the >> >> >> >> board doesn't use >> >> >> >> LDO3 (which is why we are disabling it, it's unused). >> >> >> >> The problem is in >> >> >> >> twsi I think as only leaving the part in axp209 that >> >> >> >> read the >> >> >> >> voltage register value make FreeBSD hang. >> >> I'll have a proper look later, in the meantime you can >> >> >> >> set >> >> >> >> hw.regulator.disable_unused=3D0 >> >> in /boot/loader.conf >> >> This isn't a DTS problem. >> >> >> >> For Espressobin I haven't found any thing related to SD >> >> >> >> in the DTS >> >> >> >> updates since the import, the only things slighly >> >> >> >> related are mmc and >> >> >> >> sdio. >> >> So if someone could find which DTS import broke this I >> >> >> >> can have a look. >> >> >> >> >> >> >> >> On 15 Aug 2019, at 19.37, Mit Matelske >> >> >> >> wrote: >> >> >> >> >> >> Yeah, that was the problem. I went back to r348882 >> >> >> >> and everything worked out of the box. >> >> >> >> >> >> Thanks again for the hand holding! >> >> >> >> Mit >> >> >> >> From: "S=C3=B8ren Schmidt" > >> >> >> > >> >> >> >> To: "Mit Matelske" > >> >> Cc: "Marcin Wojtas" > >> >> >> mw@semihalf.com>>, "freebsd-arm" > >> freebsd-arm@freebsd.org>> >> >> >> >> Sent: Wednesday, August 14, 2019 1:33:04 PM >> >> Subject: Re: Espressobin anyone ? >> >> >> >> >> >> It might simply be broken in -current (again). >> >> >> >> I just updated my stable12 tree and I pulled in new >> >> >> >> .dts files for just about anything? >> >> >> >> >> >> Needless to say, it broke the Espressobin?s SD >> >> >> >> support, it now fails just like yours.. >> >> >> >> >> >> It also broke allwinner builds and what not, so I?m >> >> >> >> just going back in time again :) >> >> >> >> >> >> I wonder why there is this overwhelming need to >> >> >> >> import stuff that breaks things right, left and center in a -stable >> >> branch ? >> >> >> >> That would have earned you the pointy hat back when?. >> >> >> >> -S=C3=B8ren >> >> >> >> >> >> On 14 Aug 2019, at 18.01, Mit Matelske > >> >> >> > wrote: >> >> >> >> >> >> Marcin- >> >> >> >> Sorry I didn't reply yesterday. I didn't have any >> >> >> >> luck with that either. I tried a lot of permutations. >> >> >> >> >> >> Not saying for 100% it doesn't work, but I couldn't >> >> >> >> get it to work! >> >> >> >> >> >> Mit >> >> >> >> From: "Marcin Wojtas" > >> >> >> mw@semihalf.com>> >> >> >> >> To: "Mit Matelske" > >> >> Cc: "S=C3=B8ren Schmidt" > >> >> >> soren.schmidt@gmail.com>>, "freebsd-arm" > >> > >> >> >> >> Sent: Wednesday, August 14, 2019 10:41:04 AM >> >> Subject: Re: Espressobin anyone ? >> >> >> >> Hi Mit, >> >> Since you are using the latest 13-current, could you >> >> >> >> please try if passing rootdev via u-boot bootargs (please see my >> previous >> >> email) works for you without the loader modification? >> >> >> >> >> >> Best regards, >> >> Marcin >> >> >> >> ?r., 14 sie 2019 o 16:29 Mit Matelske > >> >> >> > napisa?(a): >> >> >> >> Soren- >> >> >> >> Thanks for the info. I'll grab a couple more SD >> >> >> >> cards at lunch. This one is a new Samsung 32GB. I'll also try putti= ng >> >> the >> >> changes into 12 and see if that helps. I'm using the latest >> 13-current. >> >> >> >> >> >> Again, appreciate the hand holding! >> >> >> >> Mit >> >> >> >> From: "S=C3=B8ren Schmidt" > >> >> >> > >> >> >> >> To: "Mit Matelske" > >> >> Cc: "Marcin Wojtas" > >> >> >> mw@semihalf.com>>, "freebsd-arm" > >> freebsd-arm@freebsd.org>> >> >> >> >> Sent: Wednesday, August 14, 2019 2:30:31 AM >> >> Subject: Re: Espressobin anyone ? >> >> >> >> Hi Mit >> >> Hmm, from your earlier posted dmesgs it looks like >> >> >> >> the SD card is not getting detected properly.. >> >> >> >> >> >> I get this output: >> >> >> >> sdhci_xenon0: mem >> >> >> >> 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 >> >> >> >> mmc0: on sdhci_xenon0 >> >> ?snip? >> >> mmcsd0: 16GB > >> >> >> by 39 PH> at mmc0 50.0MHz/4bit/65535-block >> >> >> >> >> >> The problem you see was fixed for me by r348882, >> >> >> >> maybe it got broken later, I havn?t backported the later changes.. >> >> >> >> >> >> Have you tried another SD card ? I have found 2 of >> >> >> >> mine that the espressobin doesn?t like, but works fine with bananapi >> and >> >> friends... >> >> >> >> >> >> -S=C3=B8ren >> >> >> >> On 13 Aug 2019, at 23.30, Mit Matelske > >> >> >> > wrote: >> >> >> >> >> >> Soren- >> >> >> >> Thanks for the code snippet! That will fix one of >> >> >> >> the problems. >> >> >> >> >> >> I still can't mount my filesystem, though. I think >> >> >> >> I'm doing something really simple, wrong. I believe I'm running the >> >> latest >> >> code and added some printfs to show the kernel setting the regulator: >> >> >> >> >> >> >> >> usbus1 on ehci0 >> >> syscon_generic4: mem 0x5f800-0x5ffff on >> >> >> >> simplebus1 >> >> >> >> sdhci_xenon0: >> >> >> >> regulator_get_by_ofw_property(vqmmc-supply) =3D 19 >> >> >> >> sdhci_xenon0: vqmmc-supply regulator found >> >> sdhci_xenon0: mem >> >> >> >> 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 >> >> >> >> ahci0: mem 0xe0000-0xe0177 irq >> >> >> >> 26 on simplebus1 >> >> >> >> >> >> >> >> Could there be a problem with how I am setting up my >> >> >> >> filesystem? I've tried both freebsd-ufs and freebsd as the type, wit= h >> no >> >> luck. A gpart listing of my SD card: >> >> >> >> >> >> root@fbl:~ # gpart list da3 >> >> Geom name: da3 >> >> modified: false >> >> state: OK >> >> fwheads: 255 >> >> fwsectors: 63 >> >> last: 62521335 >> >> first: 3 >> >> entries: 4 >> >> scheme: GPT >> >> Providers: >> >> 1. Name: da3p1 >> >> Mediasize: 41943040 (40M) >> >> Sectorsize: 512 >> >> Stripesize: 0 >> >> Stripeoffset: 1536 >> >> Mode: r0w0e0 >> >> efimedia: >> >> >> >> HD(1,GPT,19894dc5-b8b2-11e9-871f-08008a0010e0,0x3,0x14000) >> >> >> >> rawuuid: 19894dc5-b8b2-11e9-871f-08008a0010e0 >> >> rawtype: c12a7328-f81f-11d2-ba4b-00a0c93ec93b >> >> label: (null) >> >> length: 41943040 >> >> offset: 1536 >> >> type: efi >> >> index: 1 >> >> end: 81922 >> >> start: 3 >> >> 2. Name: da3p2 >> >> Mediasize: 31968979456 (30G) >> >> Sectorsize: 512 >> >> Stripesize: 0 >> >> Stripeoffset: 41944576 >> >> Mode: r0w0e0 >> >> efimedia: >> >> >> >> HD(2,GPT,98786462-be30-11e9-ae6e-08008a0010e0,0x14003,0x3b8bff5) >> >> >> >> rawuuid: 98786462-be30-11e9-ae6e-08008a0010e0 >> >> rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b >> >> label: (null) >> >> length: 31968979456 >> >> offset: 41944576 >> >> type: freebsd-ufs >> >> index: 2 >> >> end: 62521335 >> >> start: 81923 >> >> Consumers: >> >> 1. Name: da3 >> >> Mediasize: 32010928128 (30G) >> >> Sectorsize: 512 >> >> Mode: r0w0e0 >> >> >> >> Thanks!! >> >> >> >> Mit >> >> >> >> From: "S=C3=B8ren Schmidt" > >> >> >> > >> >> >> >> To: "Marcin Wojtas" > >> >> >> mw@semihalf.com>> >> >> >> >> Cc: "Mit Matelske" >, >> >> >> >> "freebsd-arm" > >> freebsd-arm@freebsd.org>> >> >> >> >> Sent: Tuesday, August 13, 2019 12:55:09 PM >> >> Subject: Re: Espressobin anyone ? >> >> >> >> Hi >> >> That doesn?t seen to work on the espressobin, or >> >> >> >> least I can?t get it to pick it up. >> >> >> >> >> >> I use this patch as a workaround: >> >> >> >> Index: main.c >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> >> >> --- main.c (revision 350496) >> >> +++ main.c (working copy) >> >> @@ -463,6 +462,13 @@ >> >> int rv; >> >> char *rootdev; >> >> >> >> +#if defined(__aarch64__) >> >> + /* SOS HACK in rootdev, at least Espressobin >> >> >> >> gets this wrong */ >> >> >> >> + printf("Setting currdev hack\n"); >> >> + set_currdev("disk0p2"); >> >> + return (0); >> >> +#endif >> >> + >> >> /* >> >> * First choice: if rootdev is already set, use >> >> >> >> that, even if >> >> >> >> * it's wrong. >> >> >> >> Its not pretty but it does the job until I get time >> >> >> >> to look into why bootargs aren?t passed / won?t stick, probably >> something >> >> I >> >> havn?t backported to my -stable12 sources yet... >> >> >> >> >> >> -S=C3=B8ren >> >> >> >> On 13 Aug 2019, at 01.38, Marcin Wojtas < >> >> >> >> mw@semihalf.com > wrote: >> >> >> >> >> >> Hi, >> >> >> >> Not sure if it's what you are looking for, but in >> >> >> >> order to autoboot, I >> >> >> >> simply pass 'rootdev=3DdiskXpY' in the bootargs >> >> >> >> variable. Here's example from >> >> >> >> A3720-DB (same should work on EspressoBin): >> >> >> >> Marvell>> set bootargs "rootdev=3Ddisk1p1";usb reset; >> >> >> >> fatload usb 0:1 >> >> >> >> ${fdt_addr} armada-3720-db.dtb; fatload usb 0:1 >> >> >> >> ${kernel_addr} >> >> >> >> boot/loader.efi; bootefi ${kernel_addr} ${fdt_addr} >> >> resetting USB... >> >> USB0: Register 2000104 NbrPorts 2 >> >> Starting the controller >> >> USB XHCI 1.00 >> >> USB1: USB EHCI 1.00 >> >> - ______ ____ _____ _____ >> >> | ____| | _ \ / ____| __ \ >> >> | |___ _ __ ___ ___ | |_) | (___ | | | | >> >> | ___| '__/ _ \/ _ \| _ < \___ \| | | | >> >> | | | | | __/ __/| |_) |____) | |__| | >> >> | | | | | | || | | | >> >> |_| |_| \___|\___||____/|_____/|_____/ >> >> ``` >> >> ` >> >> ????????????Welcome to FreeBSD????????????? s` >> >> >> >> `.....---.......--.``` >> >> >> >> -/ >> >> ? ? +o >> >> >> >> .--` /y:` >> >> >> >> +. >> >> ? 1. Boot Multi user [Enter] ? >> >> >> >> yo`:. :o >> >> >> >> `+- >> >> ? 2. Boot Single user ? y/ >> >> >> >> -/` -o/ >> >> >> >> ? 3. Escape to loader prompt ? .- >> >> ::/sy+:. >> >> ? 4. Reboot ? / >> >> >> >> `-- >> >> >> >> / >> >> ? ? `: >> >> :` >> >> ? Options: ? `: >> >> :` >> >> ? 5. Kernel: default/kernel (1 of 1) ? / >> >> / >> >> ? 6. Boot Options ? .- >> >> -. >> >> ? ? -- >> >> >> >> -. >> >> >> >> ? ? >> >> >> >> `:` `:` >> >> >> >> ? ? >> >> >> >> .-- `--. >> >> >> >> ??????????????????????????????????????????? >> >> >> >> .---.....----. >> >> >> >> Autoboot in 9 seconds, hit [Enter] to boot or any >> >> >> >> other key to stop >> >> >> >> >> >> Loading kernel... >> >> /boot/kernel/kernel text=3D0x95047c >> >> >> >> data=3D0x1919d0+0x84aa94 >> >> >> >> syms=3D[0x8+0x13aaa8+0x8+0x12610d] >> >> Loading configured modules... >> >> can't find '/boot/entropy' >> >> Using DTB provided by EFI at 0x8000000. >> >> ---<>--- >> >> KDB: debugger backends: ddb >> >> KDB: current backend: ddb >> >> Copyright (c) 1992-2019 The FreeBSD Project. >> >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, >> >> >> >> 1991, 1992, 1993, 1994 >> >> >> >> The Regents of the University of California. All >> >> >> >> rights reserved. >> >> >> >> FreeBSD is a registered trademark of The FreeBSD >> >> >> >> Foundation. >> >> >> >> FreeBSD 13.0-CURRENT >> >> >> >> 17a1fc80d57-c261519(upstream_master) GENERIC arm64 >> >> >> >> FreeBSD clang version 8.0.0 (tags/RELEASE_800/final >> >> >> >> 356365) (based on LLVM >> >> >> >> 8.0.0) >> >> WARNING: WITNESS option enabled, expect reduced >> >> >> >> performance. >> >> >> >> VT: init without driver. >> >> Starting CPU 1 (1) >> >> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >> >> [...] >> >> >> >> Best regards, >> >> Marcin >> >> >> >> pon., 12 sie 2019 o 23:14 Mit Matelske > >> >> >> > napisa?(a): >> >> >> >> >> >> >> >> Soren- >> >> >> >> Thanks for the quick response. I built this kernel >> >> >> >> with revision 350924. >> >> >> >> I'll dig into whats going on in the morning. >> >> >> >> Mind posting your diff for your loader.efi? >> >> >> >> Thanks again! >> >> >> >> Mit >> >> >> >> >> >> ----- Original Message ----- >> >> From: "S=C3=B8ren Schmidt" > >> >> >> > >> >> >> >> To: "Mit Matelske" > >> >> Cc: "tscho" > >> >> >> johannes@t-beutel.com>>, "freebsd-arm" < >> >> >> >> freebsd-arm@freebsd.org > >> >> >> freebsd-arm@freebsd.org>> >> >> >> >> Sent: Monday, August 12, 2019 3:49:48 PM >> >> Subject: Re: Espressobin anyone ? >> >> >> >> Hi >> >> >> >> Looks like your sources may be too old, you need to >> >> >> >> be at least at r348882 >> >> >> >> to get the fix for the SD card VCC regulator. >> >> >> >> That change fixed it for me backported to 12-stable... >> >> >> >> The currdev problem still exists, I have it hardwired >> >> >> >> in my loader for >> >> >> >> aarch64 :) >> >> >> >> -S=C3=B8ren >> >> >> >> >> >> On 12 Aug 2019, at 21.06, Mit Matelske > >> >> >> > wrote: >> >> >> >> >> >> I'm having a couple little hiccups booting this board >> >> >> >> also. One has >> >> >> >> been commented on already, that I can't get the >> >> >> >> loader to automatically >> >> >> >> start loading the kernel on "disk0p2"... >> >> >> >> The second, is that the kernel can't find the SD card >> >> >> >> after booting so >> >> >> >> it can't mount the root filesystem. I'm using the >> >> >> >> dts/dtb and kernel from >> >> >> >> the 13-current branch. >> >> >> >> Thanks for any and all help. I haven't used u-boot >> >> >> >> in about decade. >> >> >> >> Spoiled by the x86 platform. >> >> >> >> Mit Matelske >> >> >> >> >> >> ***U-boot environment:*** >> >> >> >> >> >> Marvell>> printenv >> >> baudrate=3D115200 >> >> bootargs=3Dconsole=3DttyMV0,115200 >> >> >> >> earlycon=3Dar3700_uart,0xd0012000 >> >> >> >> root=3D/dev/mmcblk0p1 rw rootwait net.ifnames=3D0 >> >> >> >> biosdevname=3D0 >> >> >> >> bootcmd=3Dmmc dev 0; fatload mmc 0:1 $kernel_addr >> >> >> >> $image_name;fatload mmc >> >> >> >> 0:1 $fdt_addr $fdt_name; bootefi $kernel_addr >> >> >> >> $fdt_addr >> >> >> >> bootdelay=3D2 >> >> bootmmc=3Dmmc dev 0; fatload mmc 0:1 $kernel_addr >> >> >> >> $image_name;fatload mmc >> >> >> >> 0:1 $fdt_addr $fdt_name; bootefi $kernel_addr >> >> >> >> $fdt_addr >> >> >> >> console=3Dconsole=3DttyMV0,115200 >> >> >> >> earlycon=3Dar3700_uart,0xd0012000 >> >> >> >> eth1addr=3D00:51:82:11:22:01 >> >> eth2addr=3D00:51:82:11:22:02 >> >> eth3addr=3D00:51:82:11:22:03 >> >> ethact=3Dneta@30000 >> >> ethaddr=3DF0:AD:4E:09:6B:8F >> >> ethprime=3Deth0 >> >> fdt_addr=3D0x4f00000 >> >> fdt_high=3D0xffffffffffffffff >> >> fdt_name=3Defi/boot/armada-3720-espressobin.dtb >> >> fdtcontroladdr=3D3f7161b8 >> >> gatewayip=3D10.4.50.254 >> >> get_images=3Dtftpboot $kernel_addr $image_name; >> >> >> >> tftpboot $fdt_addr >> >> >> >> $fdt_name; run get_ramfs >> >> get_ramfs=3Dif test "${ramfs_name}" !=3D "-"; then setenv >> >> >> >> ramfs_addr >> >> >> >> 0x8000000; tftpboot $ramfs_addr $ramfs_name; else >> >> >> >> setenv ramfs_addr -;fi >> >> >> >> hostname=3Dmarvell >> >> image_name=3Defi/freebsd/loader.efi >> >> initrd_addr=3D0xa00000 >> >> initrd_size=3D0x2000000 >> >> ipaddr=3D0.0.0.0 >> >> kernel_addr=3D0x5000000 >> >> loadaddr=3D0x5000000 >> >> netdev=3Deth0 >> >> netmask=3D255.255.255.0 >> >> ramfs_addr=3D0x8000000 >> >> ramfs_name=3D- >> >> root=3Droot=3D/dev/nfs rw >> >> rootpath=3D/srv/nfs/ >> >> serverip=3D0.0.0.0 >> >> set_bootargs=3Dsetenv bootargs $console $root >> >> >> >> ip=3D$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:none >> >> >> >> nfsroot=3D$serverip:$rootpath $extra_params >> >> stderr=3Dserial@12000 >> >> stdin=3Dserial@12000 >> >> stdout=3Dserial@12000 >> >> >> >> >> >> ***Full boot logs:*** >> >> >> >> >> >> U-Boot 2017.03-armada-17.10.2-g14aeedc (Jun 01 2018 - >> >> >> >> 15:39:10 +0800) >> >> >> >> >> >> Model: Marvell Armada 3720 Community Board ESPRESSOBin >> >> CPU @ 1000 [MHz] >> >> L2 @ 800 [MHz] >> >> TClock @ 200 [MHz] >> >> DDR @ 800 [MHz] >> >> DRAM: 1 GiB >> >> U-Boot DT blob at : 000000003f7161b8 >> >> Comphy-0: USB3 5 Gbps >> >> Comphy-1: PEX0 2.5 Gbps >> >> Comphy-2: SATA0 6 Gbps >> >> SATA link 0 timeout. >> >> AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA >> >> >> >> mode >> >> >> >> flags: ncq led only pmp fbss pio slum part sxs >> >> PCIE-0: Link down >> >> MMC: sdhci@d0000: 0, sdhci@d8000: 1 >> >> SF: Detected mx25u3235f with page size 256 Bytes, >> >> >> >> erase size 64 KiB, >> >> >> >> total 4 MiB >> >> Net: eth0: neta@30000 [PRIME] >> >> Hit any key to stop autoboot: 0 >> >> switch to partitions #0, OK >> >> mmc0 is current device >> >> reading efi/freebsd/loader.efi >> >> 603872 bytes read in 49 ms (11.8 MiB/s) >> >> reading efi/boot/armada-3720-espressobin.dtb >> >> 15946 bytes read in 17 ms (916 KiB/s) >> >> ## Starting EFI application at 05000000 ... >> >> Scanning disk sdhci@d0000.blk > >> >> >> ... >> >> >> >> Card did not respond to voltage select! >> >> mmc_init: -95, time 50 >> >> Found 1 disks >> >> Consoles: EFI console >> >> FreeBSD/arm64 EFI loader, Revision 1.1 >> >> >> >> Command line arguments: loader.efi >> >> EFI version: 2.05 >> >> EFI Firmware: Das U-boot (rev 0.00) >> >> Console: efi (0) >> >> Failed to find bootable partition >> >> Startup error in /boot/lua/loader.lua: seconds >> >> LUA ERROR: cannot open /boot/lua/loader.lua: invalid >> >> >> >> argument. >> >> >> >> >> >> can't load 'kernel' >> >> >> >> Type '?' for a list of commands, 'help' for more >> >> >> >> detailed help. >> >> >> >> OK >> >> OK set currdev=3Ddisk0p2 >> >> OK boot >> >> >> >> /boot/kernel/kernel text=3D0x97d6a0 >> >> >> >> data=3D0x191b50+0x84ae94 >> >> >> >> syms=3D[0x8+0x137dd8+0x8+0x126260] >> >> Using DTB provided by EFI at 0x8000000. >> >> ---<>--- >> >> KDB: debugger backends: ddb >> >> KDB: current backend: ddb >> >> Copyright (c) 1992-2019 The FreeBSD Project. >> >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, >> >> >> >> 1991, 1992, 1993, 1994 >> >> >> >> The Regents of the University of California. All >> >> >> >> rights reserved. >> >> >> >> FreeBSD is a registered trademark of The FreeBSD >> >> >> >> Foundation. >> >> >> >> FreeBSD 13.0-CURRENT GENERIC arm64 >> >> FreeBSD clang version 6.0.1 (tags/RELEASE_601/final >> >> >> >> 335540) (based on >> >> >> >> LLVM 6.0.1) >> >> WARNING: WITNESS option enabled, expect reduced >> >> >> >> performance. >> >> >> >> VT: init without driver. >> >> Starting CPU 1 (1) >> >> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >> >> arc4random: WARNING: initial seeding bypassed the >> >> >> >> cryptographic random >> >> >> >> device because it was not yet seeded and the knob >> >> >> >> 'bypass_before_seeding' >> >> >> >> was enabled. >> >> random: entropy device external interface >> >> MAP 3e681000 mode 2 pages 1 >> >> MAP 3ffa6000 mode 2 pages 1 >> >> kbd0 at kbdmux0 >> >> ofwbus0: >> >> simplebus0: on >> >> >> >> ofwbus0 >> >> >> >> simplebus1: on >> >> >> >> simplebus0 >> >> >> >> simple_mfd0: mem >> >> 0x13800-0x138ff,0x13c00-0x13c1f on simplebus1 >> >> simple_mfd1: mem >> >> 0x18800-0x188ff,0x18c00-0x18c1f on simplebus1 >> >> psci0: > >> >> >> Driver> on ofwbus0 >> >> >> >> gic0: mem >> >> >> >> >> >> >> 0x1d00000-0x1d0ffff,0x1d40000-0x1d7ffff,0x1d80000-0x1d81fff,0x1d90000-0x= 1d91fff,0x1da0000-0x1dbffff >> >> >> >> irq 27 on simplebus1 >> >> gpio0: 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: 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: on ofwbus0 >> >> gpioregulator0: cannot get pin 0 >> >> gpioregulator0: cannot parse parameters >> >> device_attach: gpioregulator0 attach returned 6 >> >> generic_timer0: irq 0,1,2,3 on >> >> >> >> ofwbus0 >> >> >> >> Timecounter "ARM MPCore Timecounter" frequency >> >> >> >> 12500000 Hz quality 1000 >> >> >> >> Event timer "ARM MPCore Eventtimer" frequency >> >> >> >> 12500000 Hz quality 1000 >> >> >> >> gpio0: 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: 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: on ofwbus0 >> >> gpioregulator0: cannot get pin 0 >> >> gpioregulator0: cannot parse parameters >> >> device_attach: gpioregulator0 attach returned 6 >> >> gpio0: 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: 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: on ofwbus0 >> >> gpioregulator0: cannot get pin 0 >> >> gpioregulator0: cannot parse parameters >> >> device_attach: gpioregulator0 attach returned 6 >> >> gpio0: 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: 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: on ofwbus0 >> >> gpioregulator0: cannot get pin 0 >> >> gpioregulator0: cannot parse parameters >> >> device_attach: gpioregulator0 attach returned 6 >> >> gpio0: 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: 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: on ofwbus0 >> >> gpioregulator0: cannot get pin 0 >> >> gpioregulator0: cannot parse parameters >> >> device_attach: gpioregulator0 attach returned 6 >> >> cpulist0: on ofwbus0 >> >> cpu0: on cpulist0 >> >> cpu1: on cpulist0 >> >> pmu0: irq 4 on ofwbus0 >> >> syscon_generic0: mem 0xd000-0xdfff on >> >> >> >> simplebus1 >> >> >> >> syscon_generic1: mem 0x11500-0x1153f on >> >> >> >> simplebus1 >> >> >> >> uart0: mem 0x12000-0x121ff >> >> >> >> irq 9,10,11 on >> >> >> >> simplebus1 >> >> uart0: console (115200,n,8,1) >> >> gpio0: 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: mem 0x14000-0x1405f on >> >> >> >> simplebus1 >> >> >> >> gpio0: 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: mem 0x30000-0x33fff irq 14 >> >> >> >> on simplebus1 >> >> >> >> mvneta0: version is 10 >> >> mvneta0: Ethernet address: 00:a6:39:ca:e8:00 >> >> mdio0: on mvneta0 >> >> mdioproxy0: on mdio0 >> >> e6000sw0: on mdio0 >> >> e6000sw0: multi-chip addressing mode (0x1) >> >> e6000sw0: CPU port at 0 >> >> e6000sw0: fixed port at 0 >> >> e6000sw0: PHY at port 1 >> >> miibus0: on e6000sw0 >> >> e1000phy0: 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: on e6000sw0 >> >> e1000phy1: 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: on e6000sw0 >> >> e1000phy2: 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: on e6000sw0 >> >> xhci0: mem >> >> >> >> 0x58000-0x5bfff irq 16 on >> >> >> >> simplebus1 >> >> xhci0: 32 bytes context size, 32-bit DMA >> >> usbus0 on xhci0 >> >> syscon_generic3: mem 0x5d800-0x5dfff on >> >> >> >> simplebus1 >> >> >> >> ehci0: mem >> >> >> >> 0x5e000-0x5efff irq >> >> >> >> 17 on simplebus1 >> >> usbus1: EHCI version 1.0 >> >> usbus1 on ehci0 >> >> syscon_generic4: mem 0x5f800-0x5ffff on >> >> >> >> simplebus1 >> >> >> >> sdhci_xenon0: mem >> >> 0xd0000-0xd02ff,0x1e808-0x1e80b irq 24 on simplebus1 >> >> ahci0: mem 0xe0000-0xe0177 irq >> >> >> >> 26 on simplebus1 >> >> >> >> ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier >> >> >> >> supported with FBS >> >> >> >> ahcich0: at channel 0 on ahci0 >> >> device_attach: ahcich0 attach returned 6 >> >> gpioregulator0: on ofwbus0 >> >> gpioregulator0: cannot get pin 0 >> >> gpioregulator0: cannot parse parameters >> >> device_attach: gpioregulator0 attach returned 6 >> >> cryptosoft0: >> >> 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 >> >> >> >> >> >> >> >> 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 >> >> >> >> usbus1 Processor Features 1 =3D <0> >> >> usbus0 Memory Model Features 0 =3D <4k Granule,64k >> >> >> >> Granule,S/NS >> >> >> >> Mem,MixedEndian,16bit ASID,1TB PA> >> >> >> >> Memory Model Features 1 =3D <> >> >> Memory Model Features 2 =3D <32b CCIDX,48b VA> >> >> Debug Features 0 =3D <2 CTX Breakpoints,4 >> >> >> >> Watchpoints,6 >> >> >> >> Breakpoints,PMUv3,Debug v8> >> >> Debug Features 1 =3D <0> >> >> Auxiliary Features 0 =3D <0> >> >> Auxiliary Features 1 =3D <0> >> >> CPU 1: ARM Cortex-A53 r0p4 affinity: 1 >> >> WARNING: WITNESS option enabled, expect reduced >> >> >> >> performance. >> >> >> >> ugen0.1: at usbus0 >> >> ugen1.1: at usbus1 >> >> uhub0 on usbus0 >> >> uhub1 on usbus1 >> >> uhub0: > >> >> >> 3.00/1.00, addr 1> on >> >> >> >> usbus0 >> >> uhub1: > >> >> >> 2.00/1.00, addr 1> on >> >> >> >> usbus1 >> >> uhub0: 2 ports with 2 removable, self powered >> >> uhub1: 1 port with 1 removable, self powered >> >> mountroot: waiting for device >> >> >> >> /dev/ufs/FreeBSD_Install... >> >> >> >> Mounting from ufs:/dev/ufs/FreeBSD_Install failed >> >> >> >> with error 19. >> >> >> >> >> >> Loader variables: >> >> vfs.root.mountfrom=3Dufs:/dev/ufs/FreeBSD_Install >> >> vfs.root.mountfrom.options=3Dro,noatime >> >> >> >> Manual root filesystem specification: >> >> : [options] >> >> Mount using filesystem >> >> and with the specified (optional) option list. >> >> >> >> eg. ufs:/dev/da0s1a >> >> zfs:zroot/ROOT/default >> >> cd9660:/dev/cd0 ro >> >> (which is equivalent to: mount -t cd9660 -o ro >> >> >> >> /dev/cd0 /) >> >> >> >> >> >> ? List valid disk boot devices >> >> . Yield 1 second (for background tasks) >> >> Abort manual input >> >> >> >> mountroot> ? >> >> >> >> List of GEOM managed disk devices: >> >> >> >> >> >> mountroot> >> >> _______________________________________________ >> >> freebsd-arm@freebsd.org > >> >> >> 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 > >> freebsd-arm-unsubscribe@freebsd.org>" >> >> >> >> >> >> _______________________________________________ >> >> freebsd-arm@freebsd.org > >> >> >> 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 > >> freebsd-arm-unsubscribe@freebsd.org>" >> >> >> >> >> >> >> >> >> >> -- >> >> Emmanuel Vadot < >> >> >> >> manu@freebsd.org> >> >> >> >> >> >> >> >> >> >> -- >> >> Emmanuel Vadot >> >> >> >> >> >> >> >> -- >> >> Emmanuel Vadot >> >> _______________________________________________ >> >> freebsd-arm@freebsd.org mailing list >> >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> >> To unsubscribe, send any mail to " >> >> >> >> freebsd-arm-unsubscribe@freebsd.org" >> >> >> >> >> >> >> >> -- >> >> Emmanuel Vadot >> >> _______________________________________________ >> >> freebsd-arm@freebsd.org mailing list >> >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> >> To unsubscribe, send any mail to " >> >> >> >> freebsd-arm-unsubscribe@freebsd.org" >> >> >> >> >> >> >> >> -- >> >> Emmanuel Vadot >> >> _______________________________________________ >> >> freebsd-arm@freebsd.org mailing list >> >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> >> To unsubscribe, send any mail to " >> >> >> >> freebsd-arm-unsubscribe@freebsd.org" >> >> >> >> >> >> >> >> -- >> >> Emmanuel Vadot > >> >> >> manu@bidouilliste.com>> > >> >> >> >> >> >> >> >> >> >> -- >> >> Emmanuel Vadot > >> >> >> manu@bidouilliste.com>> > >> >> >> >> >> >> >> >> >> >> -- >> >> Emmanuel Vadot >> >> _______________________________________________ >> >> 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" >> ------------------------------ >> >> > > > From owner-freebsd-arm@freebsd.org Sat Aug 24 01:52:46 2019 Return-Path: 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 0402BD453F for ; Sat, 24 Aug 2019 01:52:46 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from nh503-vm12.bullet.mail.kks.yahoo.co.jp (nh503-vm12.bullet.mail.kks.yahoo.co.jp [183.79.56.198]) by mx1.freebsd.org (Postfix) with SMTP id 46Fh9Q6VLnz4VXR for ; Sat, 24 Aug 2019 01:52:42 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from [183.79.100.139] by nh503.bullet.mail.kks.yahoo.co.jp with NNFMP; 24 Aug 2019 01:52:38 -0000 Received: from [183.79.100.135] by t502.bullet.mail.kks.yahoo.co.jp with NNFMP; 24 Aug 2019 01:52:38 -0000 Received: from [127.0.0.1] by omp504.mail.kks.yahoo.co.jp with NNFMP; 24 Aug 2019 01:52:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 563453.88649.bm@omp504.mail.kks.yahoo.co.jp X-YMail-OSG: kYeROiUVM1nCuNLoVdYyztsSYIVIi7DOc5TKVevhb3VvW4sFSY9C.v7QQUQyDJq gQkHr4rQaD1pWKbJyJvN4bySZo56mjNOZaUchUmRAWAqcrl9gd84LSyDwIQooK0a0wxObe.bYzBr _IiuOFPVBii4IAhRgcrm_Mx3sQBseMFCMKS_be3fznYyBYI2tW.8jg9GZuIzjSUTDPie16a3OYGQ VUOD4hdl3JEUPxxRq_ATpqAeM4bgN9Yj5pAcx.eHyd_dfs3SWcaoX7Mt3ZD1e_inoKie7awMG7iH kJgLOTq9LSIk_e0X.WAvnqEYwI0Gi9lmK3.xMkN1FmZXlMr6lqBHL_6727V8.zL.ae6F_lBN2Bv8 cV_.5p5erUDqkFpmO6X3cRgGiStFmfDAn0b0.0L0Dw6J.Ctdjks9OxdOi2gIE9zy56F42UMujHi0 Tg3tvFfCcrcuM4Jp3JgPEhvjfhiMIHAzAhhmCkjj209Xahs6PgMXeSU2x.YXbGPxaylGwhgyFP7O HVD73k915PHpdvNHsBVoJXl5FvhlFHdo6cq7L4YJrVrdR62ZklZ5.OZwzC2ekdbPlAXgMcbwvxX6 ZFGE8hadq0SPT2f5Gtqra1g6988mfGDuN.et5xOYJ.lasnCW.DP3CfVmyHxuqXlY94NnWmOymhs3 wXyYuWuRACV9WCPU9UM.BmMq6kVVS_E6KHOy_ZKTBaVZD Received: from jws703107.mail.ssk.yahoo.co.jp by sendmailws605.mail.ssk.yahoo.co.jp; Sat, 24 Aug 2019 10:52:37 +0000; 1566611557.811 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1566611558; s=yj20110701; d=yahoo.co.jp; h=Date:From:Reply-To:To:Message-ID:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:References; bh=pPQni+ZM07kG+b3hcZSsgIzW0iV5LnkTfqgx5wFx0ws=; b=JpJn5IDbTjB+PA/JyXRa2SMHDEM00M06LPS84XaBtLHDv9P31DKuDEIQrcT0JRZY ES/DFrx0wrSOn/XhTLEg4LcOABMoty2LF3trCbeJEx9+Lv4j2vNZ0GL/VQyYfdxYj9C Wwg718ls/HPk4TwT9wGKv8Pf2KVhZuu+RIZtIIvk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=yj20110701; d=yahoo.co.jp; h=Date:From:Reply-To:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:References; b=Yluq63Jyn3q3Y2+2EmzublOjd3PILKVOeLrSNSSwoyjw6gbJpHd55C5F5+gaRF/m bKfqUq41xjJhcdWErybLptuxM0kLUFi/DgZN0RkyxkQCKk06rGpcCHYDSPIKF5cei4e /qWs1JDFF79BkG2pSaipfTmKd4utJIQBBaqxxGn8=; Date: Sat, 24 Aug 2019 10:52:37 +0900 (JST) From: Mori Hiroki Reply-To: Mori Hiroki To: "freebsd-arm@freebsd.org" , "freebsd-mips@freebsd.org" Message-ID: <2112006177.257933.1566611557240.JavaMail.yahoo@jws703107.mail.ssk.yahoo.co.jp> Subject: geom_flashmap linux compatibility MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable References: <2112006177.257933.1566611557240.JavaMail.yahoo.ref@jws703107.mail.ssk.yahoo.co.jp> X-Rspamd-Queue-Id: 46Fh9Q6VLnz4VXR X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.co.jp header.s=yj20110701 header.b=JpJn5IDb; dmarc=pass (policy=none) header.from=yahoo.co.jp; spf=pass (mx1.freebsd.org: domain of yamori813@yahoo.co.jp designates 183.79.56.198 as permitted sender) smtp.mailfrom=yamori813@yahoo.co.jp X-Spamd-Result: default: False [-3.02 / 15.00]; HAS_REPLYTO(0.00)[yamori813@yahoo.co.jp]; R_SPF_ALLOW(-0.20)[+ip4:183.79.0.0/16]; FREEMAIL_FROM(0.00)[yahoo.co.jp]; DKIM_TRACE(0.00)[yahoo.co.jp:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.co.jp,none]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.30)[-0.301,0]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.co.jp]; ASN(0.00)[asn:24572, ipnet:183.79.0.0/16, country:JP]; IP_SCORE(0.00)[ipnet: 183.79.0.0/16(1.27), asn: 24572(1.01), country: JP(-0.03)]; SH_EMAIL_ZRD(0.00)[0.1.173.176,0.0.195.80,0.0.78.32]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.82)[-0.825,0]; R_DKIM_ALLOW(-0.20)[yahoo.co.jp:s=yj20110701]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.1.173.176,0.0.78.32,0.0.195.80]; REPLYTO_EQ_FROM(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[yahoo.co.jp]; IP_SCORE_FREEMAIL(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.co.jp.dwl.dnswl.org : 127.0.5.0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[198.56.79.183.list.dnswl.org : 127.0.5.0]; TO_DN_EQ_ADDR_ALL(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2019 01:52:46 -0000 Hi I want get linux dts compatibility geom_flashmap. Current FreeBSD dts need set offset and size directory. for example. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0partition@2000= 0 { =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 label =3D "kernel"; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 reg =3D <0x20000 0x100000>; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 partition@110000 { =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 label =3D "rootfs"; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 reg =3D <0x120000 0x6e0000>; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }; But Linux dts is this. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0partition@5000= 0 { =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 label =3D "firmware"; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 reg =3D <0x50000 0x7b0000>; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }; Linux have find rootfs point by u-boot header. I make prototype this. But abandon. https://reviews.freebsd.org/D13648 Some body work this ? Thanks Hiroki Mori From owner-freebsd-arm@freebsd.org Sat Aug 24 10:15:40 2019 Return-Path: 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 B15EDDBFAA for ; Sat, 24 Aug 2019 10:15:40 +0000 (UTC) (envelope-from zhangchaowang@gmail.com) Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46FvKl5VY6z4ptg for ; Sat, 24 Aug 2019 10:15:39 +0000 (UTC) (envelope-from zhangchaowang@gmail.com) Received: by mail-qt1-x841.google.com with SMTP id b11so13578826qtp.10 for ; Sat, 24 Aug 2019 03:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CilPi2fI/6NkjbvNSEbnrKCJnThpTqF2qdHzE5gf3JM=; b=IyeSLetPaDRfy2+hDDhCyNzKrAfwO6e8vJ9qIeCL5C9+TV/FJtFJ/WUs3+4OiGrerT limMVe/5SganQiFouNdzZSZi91IBkY12rczkBPzGr4FznNCGbzdXlMeQwFEySZ7SSZKN buUyl0ciKnb8zxBgyBri78E/DLF1pXJXMSEogRpZI87uQWiKTygzFqd6rj6BsTUclUrV voO2rdX/qr8yb1ZsbIGUkGi96inqoJG5EfDS7ho8w5SCxE/W9JyUYEhmKa/3TzGTorsF +zdsEOEgogIWka8sUI+SzEtEileWRni0Bl4S2zkz+30hy8B3C9LbvwIx0risZLWnJuNJ jURw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CilPi2fI/6NkjbvNSEbnrKCJnThpTqF2qdHzE5gf3JM=; b=NU1pWNJFnz3GYuJwjAfOqr/5M3PoZiRzAfFVoMlAQNY7X/P3XnTl860K9wig3cu1il 9DDmcvsgO9u72LxVQ5tpNc5+f3O8CZHGf7A3QuvpDyFDdNNCooljve6fO9dPSJLaRCLy 6oQ7wGSM+DPm5XRE8NvsJ2xcaIVSB6C/EX1m3HWsImiH09YZnl/LuS+GtwsIfkMCjVCM lB2gi+BgomfSN+CZGZ64f5UjzfEUwNAe8TMJ6cStFpXnHUXJa+N7Ao+hBi9viKQNH9iH bAShIOZwDazRBGg73LiTA+kJAGaWNKrGD31CUH/8KPZ5kgLqDg2RFF4uRFDq/8IHz1DD IBKg== X-Gm-Message-State: APjAAAW2STp+hLvfe+reYvG0NWdKoAzhSZE7H4SGj0mc3uMpGujoR7DE og4v874zyArMIITP66ovobBHtDsunvc= X-Google-Smtp-Source: APXvYqzmC/w6IVsLJL22DZjYuAKZim1kZW5YCrPKqhjSE4eCBPTtIVp+pZ/CIpJBrbazmrNbsGSEVw== X-Received: by 2002:aed:3b30:: with SMTP id p45mr8664017qte.84.1566641738219; Sat, 24 Aug 2019 03:15:38 -0700 (PDT) Received: from [192.168.2.15] (cpe-76-182-13-165.nc.res.rr.com. [76.182.13.165]) by smtp.gmail.com with ESMTPSA id x28sm3120308qtk.8.2019.08.24.03.15.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Aug 2019 03:15:37 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: How to change rootfs from official RPI3 image From: Ricky Zhang X-Priority: 3 (Normal) In-Reply-To: <61580006.14.1566389702495@localhost> Date: Sat, 24 Aug 2019 06:15:35 -0400 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <0FC8815E-58D7-4196-BF7E-0D6B127B314D@gmail.com> <1668312327.7.1566381369480@localhost> <61580006.14.1566389702495@localhost> To: Ronald Klop X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 46FvKl5VY6z4ptg X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=IyeSLetP; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of zhangchaowang@gmail.com designates 2607:f8b0:4864:20::841 as permitted sender) smtp.mailfrom=zhangchaowang@gmail.com X-Spamd-Result: default: False [-3.48 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; HAS_X_PRIO_THREE(0.00)[3]; NEURAL_HAM_SHORT(-0.98)[-0.983,0]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (2.59), ipnet: 2607:f8b0::/32(-2.87), asn: 15169(-2.34), country: US(-0.05)]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[1.4.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2019 10:15:40 -0000 Hi Ronald, After migrating to UFS, I read from BSD Journal May/2019 = (https://www.freebsdfoundation.org/past-issues/freebsd-for-makers/). = RPI3 can boot from ZFS rootfs. So I tried it on my own (see the step details below in method 2): = https://github.com/rickyzhang82/FreeBSDWiki/wiki/1.-Migrate-SD-card-rootfs= -to-SSD-for-RPI3#method-2-sd-card-kernel-boot--ssd-zfs-rootfs Unfortunately, it hangs when try to mount root from dataset tank/rootfs.=20= I read between lines that the the author in the BSD Journal only mount = /var and /usr from ZFS dataset. The rest of rootfs still comes from SD = card ufs partition. My way moved the whole rootfs and home to tank/rootfs and tank/home = dataset. When it boots, I saw my USB SSD LED is flashing periodically. = The screen prints =E2=80=9CTry to mount root from tank/roofs[]...". It = seems to me that the kernel struggled to find the zpool from SSD. I saw = that zfs module gets loaded properly from the screen. I have added two = module in /boot/loader.conf as Internet suggest: ... opensolaris_load=3D"YES" zfs_load=3D"YES=E2=80=9D ... If I unplug USB SSD without any settings change, hit Ctrl-C. I can = override mount root from command line at run time with = "ufs:ufs/rootfs=E2=80=9D rathe than =E2=80=9Czfs:tank/rootfs". Then I = can boot from SD card as before. Once I login, I can run zfs list and = show both tank/rootfs and tank/home data set. So that confirmed my ZFS = pool can be found. But somehow the boot process messed up somewhere. Do you have any suggestion? thanks Ricky > On Aug 21, 2019, at 8:15 AM, Ronald Klop wrote: >=20 > Thanks. I will not take the credits for the idea though. :-) > The FreeBSD wiki has some more examples of similar setups: > https://wiki.freebsd.org/ZFSOnRoot describes how to do /boot on UFS = and the rest on ZFS, which is similar to /boot on SD-card and the rest = on SSD. > https://wiki.freebsd.org/RootOnZFS/UFSBoot >=20 > Nice that you made a write up also. More exposure for FreeBSD is = always a good thing. :-) >=20 > Good luck and keep hacking. >=20 > Ronald. > Van: Ricky Zhang > Datum: woensdag, 21 augustus 2019 13:16 > Aan: Ronald Klop > CC: freebsd-arm@freebsd.org > Onderwerp: Re: How to change rootfs from official RPI3 image >=20 > Your idea is brilliant. It solved the dilemma.=20 > =20 > Ricky@router ~ $ sudo cat /etc/fstab > # Custom /etc/fstab for FreeBSD embedded images > /dev/ufs/rootfs /bootdir ufs rw 1 1 > /dev/label/gpt/ssdrootfs / ufs rw 1 1 > /dev/msdosfs/MSDOSBOOT /boot/msdos msdosfs rw,noatime 0 0 > tmpfs /tmp tmpfs rw,mode=3D1777,size=3D50m 0 0 > =20 > Ricky@router ~ $ mount > /dev/label/gpt/ssdrootfs on / (ufs, local, soft-updates) > devfs on /dev (devfs, local, multilabel) > /dev/ufs/rootfs on /bootdir (ufs, local, soft-updates) > /dev/msdosfs/MSDOSBOOT on /bootdir/boot/msdos (msdosfs, local, = noatime) > tmpfs on /tmp (tmpfs, local) > =20 > I wrote the whole thing down in my wiki: = https://github.com/rickyzhang82/FreeBSDWiki/wiki/1.-Migrate-SD-card-rootfs= -to-SSD-for-RPI3 > =20 > Thanks > =20 > Ricky > =20 > On Aug 21, 2019, at 5:56 AM, Ronald Klop wrote: > =20 > Sorry, I did only reply to the mailinglist. I will use reply-all now. >=20 > You are right about uboot finding /boot/kernel and /boot/loader.conf. >=20 > What you need to do is mount the SD-card on /bootdir; in fstab: > /dev/yoursdcard /bootdir ufs rw,noatime 1 2 >=20 > And a symlink from /boot -> /bootdir/boot on your SSD. >=20 > Then installworld/installkernel will do the proper thing. > So the complete /boot stays on the SD-card. >=20 > Regards, >=20 > Ronald. > Van: Ricky Zhang > Datum: woensdag, 21 augustus 2019 04:58 > Aan: freebsd-arm@freebsd.org > Onderwerp: Re: How to change rootfs from official RPI3 image >=20 > > BTW: Yes, u-boot is opensource: /usr/ports/sysutils/u-boot-rpi3 > > There are sysutils/u-boot-* ports for different system. With = sysutils/u-boot-master as the main part of it. > > > > https://www.freshports.org/sysutils/u-boot-rpi3 = > > http://www.denx.de/wiki/U-Boot > > > > Regards, > > Ronald. >=20 >=20 > Hi Ronald, >=20 > Sorry, if I messed up the mailing list thread. I didn=E2=80=99t = receive your email directly. Instead, I got your reply from daily = digest. I have to copy subject and quote your reply manually in my email = client. I have no idea how to fix it after reading all FAQ = (https://www.freebsd.org/doc/en_US.ISO8859-1/articles/mailing-list-faq/art= icle.html#etiquette = ). Any other mailing list I subscribed didn=E2=80=99t = work this way... >=20 > In any case, the magic works. I did rsync: >=20 > rsync -aAXvr --progress --delete /* /mnt/USB \ > --exclude=3D'/boot/msdos/*' \ > --exclude=3D'/dev/*' \ > --exclude=3D'/proc/*' \ > --exclude=3D'/net/*' \ > --exclude=3D'/tmp/*' \ > --exclude=3D'/mnt/*' \ > --exclude=3D'/media/*' >=20 > I confirmed that it mount ssd as rootfs: >=20 > Ricky@router ~ $ df -h > Filesystem Size Used Avail Capacity Mounted on > /dev/label/gpt/ssdrootfs 407G 5.5G 369G 1% / > devfs 1.0K 1.0K 0B 100% /dev > /dev/msdosfs/MSDOSBOOT 50M 13M 37M 26% /boot/msdos > tmpfs 50M 4.0K 50M 0% /tmp >=20 > As you said, kernel still comes from SD card. I don=E2=80=99t fully = understand the FreeBSD boot process. Neither am I familiar with UEFI. >=20 > - I guess /boot/msdos/uboot.bin finds the SD card roofs system. Load = the kernel from /boot/kernel in SD card and scan /boot/loader.conf to = find the rootfs. Please correct me if I=E2=80=99m wrong. > - Should I remove /boot folder from SSD to avoid confusion? > - Are there any guide how to compile and deploy kernel? >=20 >=20 >=20 >=20 > _______________________________________________ > 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"