From owner-freebsd-arm@freebsd.org Sun Jul 28 01:50: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 F0B9CC6B45 for ; Sun, 28 Jul 2019 01:50:17 +0000 (UTC) (envelope-from return@ukpropertyinvest.co.za) Received: from slot8.ukpropertyinvest.co.za (slot8.ukpropertyinvest.co.za [151.80.112.141]) by mx1.freebsd.org (Postfix) with ESMTP id 3DD16777A0 for ; Sun, 28 Jul 2019 01:50:17 +0000 (UTC) (envelope-from return@ukpropertyinvest.co.za) Message-ID: <0f5b0218ebdab311ed0abf95468b38ff@ukpropertyinvest.co.za> Date: Sun, 28 Jul 2019 01:20:05 +0000 Subject: Our Summer 2019 payment plan is here From: UK Investment Properties Reply-To: UK Investment Properties To: "freebsd-arm@freebsd.org" MIME-Version: 1.0 X-Sender: return@ukpropertyinvest.co.za X-Report-Abuse: Please report abuse for this campaign here: http://maildirect.co.za/campaigns/ra312ffvx7558/report-abuse/fo135dxxxx227/ag532d844g8d5 X-Receiver: freebsd-arm@freebsd.org X-Hmcw-Tracking-Did: 0 X-Hmcw-Subscriber-Uid: ag532d844g8d5 X-Hmcw-Mailer: SwiftMailer - 5.4.x X-Hmcw-EBS: http://maildirect.co.za/lists/block-address X-Hmcw-Delivery-Sid: 27 X-Hmcw-Customer-Uid: jt258rnhj3953 X-Hmcw-Customer-Gid: 22 X-Hmcw-Campaign-Uid: ra312ffvx7558 Precedence: bulk Feedback-ID: ra312ffvx7558:ag532d844g8d5:fo135dxxxx227:jt258rnhj3953 X-Rspamd-Queue-Id: 3DD16777A0 X-Spamd-Bar: +++++++++++ X-Spamd-Result: default: False [11.75 / 15.00]; HAS_REPLYTO(0.00)[reply@ukpropertyinvest.co.za]; GREYLIST(0.00)[pass,body]; R_SPF_ALLOW(0.00)[+ptr]; REPLYTO_DN_EQ_FROM_DN(0.00)[]; DKIM_TRACE(0.00)[ukpropertyinvest.co.za:+]; MX_GOOD(-0.01)[cached: ukpropertyinvest.co.za]; DMARC_POLICY_ALLOW(0.00)[ukpropertyinvest.co.za,quarantine]; MAILLIST(-0.10)[generic]; FORGED_SENDER(0.00)[contact@ukpropertyinvest.co.za,return@ukpropertyinvest.co.za]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+,1:+]; IP_SCORE(0.29)[ipnet: 151.80.0.0/16(0.28), asn: 16276(1.18), country: FR(-0.01)]; ASN(0.00)[asn:16276, ipnet:151.80.0.0/16, country:FR]; FROM_NEQ_ENVFROM(0.00)[contact@ukpropertyinvest.co.za,return@ukpropertyinvest.co.za]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(0.00)[ukpropertyinvest.co.za:s=default]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PRECEDENCE_BULK(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; HTML_SHORT_LINK_IMG_2(1.00)[]; REPLYTO_DOM_EQ_FROM_DOM(0.00)[]; HAS_LIST_UNSUB(-0.01)[]; RCPT_COUNT_ONE(0.00)[1]; BAD_REP_POLICIES(0.10)[]; MANY_INVISIBLE_PARTS(0.10)[2]; NEURAL_SPAM_SHORT(0.98)[0.977,0]; NEURAL_SPAM_MEDIUM(1.00)[1.000,0]; NEURAL_SPAM_LONG(1.00)[1.000,0]; TO_DN_EQ_ADDR_ALL(0.00)[]; URIBL_BLACK(7.50)[ukpropertyinvest.co.za.multi.uribl.com]; RCVD_TLS_ALL(0.00)[]; FORGED_SENDER_MAILLIST(0.00)[] X-Spam: Yes 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 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2019 01:50:18 -0000 ONE OF THE MOST TRUSTED UK INVESTMENT BRANDS 6.5% NET yields assured for = 3 years One of the most trusted UK investment brands http://maildirect.= co.za/campaigns/ra312ffvx7558/track-url/ag532d844g8d5/217aeb0586a9fdd1ad94e= 1a3b216b468e02944b4 http://maildirect.co.za/campaigns/ra312ffvx7558/track= -url/ag532d844g8d5/217aeb0586a9fdd1ad94e1a3b216b468e02944b4 20% contrac= t =C2=A0 =C2=A0 10% in January 2020 =C2=A0 =C2=A0 70% on co= mpletion =C2=A0 WHY YOU SHOULD INVEST IN THE 20TH PROJECT FROM THE UK= =E2=80=99S LEADING STUDENT PROPERTY DEVELOPER 6.5% minimum NET yields a= ssured for 3 years =E2=80=93 a fully managed investment Prime city cent= re location =E2=80=93 just 5 minutes=E2=80=99 walk from Cardiff Universit= y Deposit from only GBP 35,095 =E2=80=93 limited time payment plan UK s= tudent property is proven to grow your returns, even during times of wide= r economic uncertainty 8,100 international students in Cardiff ENQUIRE = NOW http://maildirect.co.za/campaigns/ra312ffvx7558/track-url/ag532d844g8= d5/217aeb0586a9fdd1ad94e1a3b216b468e02944b4 http://maildirect.co.za/campa= igns/ra312ffvx7558/track-url/ag532d844g8d5/217aeb0586a9fdd1ad94e1a3b216b468= e02944b4 GLOBAL OFFICE NETWORK =C2=A0 MANCHESTER | DUBAI | HONG KONG = | SHANGHAI =C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0 View online ve= rsion http://maildirect.co.za/campaigns/ra312ffvx7558/track-url/ag532d844= g8d5/8d361059f536c6371cca7a28b8032757cf437c84 Unsubscribe http://maildi= rect.co.za/campaigns/ra312ffvx7558/track-url/ag532d844g8d5/ab9d45ae2c9f579e= 70fc9ebfb0b6416507d67fb1 =C2=A0 This email was sent to freebsd-arm@free= bsd.org from=C2=A0UK Investment Properties on=C2=A007/28/2019 View this= email online http://maildirect.co.za/campaigns/ra312ffvx7558/track-url/a= g532d844g8d5/8d361059f536c6371cca7a28b8032757cf437c84=C2=A0~ Unsubscribe= http://maildirect.co.za/lists/fo135dxxxx227/unsubscribe/ag532d844g8d5/ra= 312ffvx7558 ~ Report email as unsolicited http://maildirect.co.za/campa= igns/ra312ffvx7558/track-url/ag532d844g8d5/2c0bfc1aa3bfef6ebf97d84373833d30= 6590271e ---=3D--- Mail Direct=C2=A0is an email-marketing service that = serves companies of all shapes and sizes. With several users/companies = sending campaigns to hundreds of millions of recipients, we're bound to g= et abuse reports.=C2=A0 We take abuse reports seriously, if you believe a= customer is sending unsolicited and or spam email, please report abuse i= mmediately HERE http://maildirect.co.za/campaigns/ra312ffvx7558/track-url= /ag532d844g8d5/2c0bfc1aa3bfef6ebf97d84373833d306590271e =C2=A0 From owner-freebsd-arm@freebsd.org Sun Jul 28 14:33: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 71E5AAC8EE for ; Sun, 28 Jul 2019 14:33:23 +0000 (UTC) (envelope-from dpolyg@gmail.com) Received: from mail-pl1-x644.google.com (mail-pl1-x644.google.com [IPv6:2607:f8b0:4864:20::644]) (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 88D4B97372 for ; Sun, 28 Jul 2019 14:33:21 +0000 (UTC) (envelope-from dpolyg@gmail.com) Received: by mail-pl1-x644.google.com with SMTP id c14so26434953plo.0 for ; Sun, 28 Jul 2019 07:33:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=jWbz4lFQ7VM1TDVFqnTWxCZKv1+RQvvxQcj0qzuQRu8=; b=RszgZ3Nyd+NLjNefBCRTLKNuWx+n/7Xgf24WTGzzENOoGVkR7uac6+CmKFf95X9pc7 ias0AO4axzxYGp59xovtd0hHczrSmqZITV5cGqwZ7G/KKxINRAxOdDHZrteKTwAJejSH xh0m3wA0WpIYwhevkNnNbSzTuOuXl0Y5KpZ/V+/DDdgQh5YpI4avylvAoAr6Pi8/xYpN 4L/9QB3GNYhlBz/g0l7YoORCzVwP2gDIz5tgalhR9IHIIi7X98OJ4hoj5CYwTX8dE7je jErSre3LE0iWqlK+LjCGH1w0zo2zIBS9T3tH5+C7QOadAgk1iYP9+BjVqzdenjaHauBC Hx7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jWbz4lFQ7VM1TDVFqnTWxCZKv1+RQvvxQcj0qzuQRu8=; b=ms/dVyi/BWQO00s6cQUrzaFJG422EjYzcSBiJWbkvlI1HzPxLyziUSzWZBxAX/EZOW qd6y74f8xSgJ9621wr1VZOXHDXXZYSPx3OHAfJrmhbMgAZVfLxj9XcevUGDjqPA5BWPo YmpWjfNxP1ruXJYmXoiV8JHvKb+cNYGIZgxa/fzZjiQtHxsTZjCZbwisRoJXONwIzB58 gxXEMiC8jOECqJkyXDZWOD3DfTAOlWAVAgilnjk1LleMKVmsIePl4E/ucSQKWxNH+L95 cC2PTy0AS6BTSpymlz4BaBtHjrT+Q5Wzgzuqmh+ROYNpmaUr8J7gFETmMv7LjAND5IcY FVxw== X-Gm-Message-State: APjAAAV/bnYwGy12vDDj9k61OuZ/G9LPIOtdZc5DiMDiFxHKfyTd3f8I b69M0EL1OEpmlOVBv3yIKyb81X33 X-Google-Smtp-Source: APXvYqzK6Tw/qRXhn7M1lRm4fbhy3GbqjaF/32a9xnaVgkNg1931K9sF3hrsqWtVl/BJaHBQbnb4Pw== X-Received: by 2002:a17:902:aa8a:: with SMTP id d10mr107776176plr.154.1564324400475; Sun, 28 Jul 2019 07:33:20 -0700 (PDT) Received: from [192.168.1.100] (ngn8-ppp1551.tokyo.sannet.ne.jp. [157.192.118.27]) by smtp.googlemail.com with ESMTPSA id c7sm1345056pgq.31.2019.07.28.07.33.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Jul 2019 07:33:19 -0700 (PDT) Subject: Re: Booting FreeBSD on Rock64 To: freebsd-arm@freebsd.org References: <169de7cf-32f2-7b7b-c12e-a86a4b6a9e87@gmail.com> <20190715200127.4b649877d8baefeb5282df64@bidouilliste.com> <878b15d5-92a5-5137-121c-5a5038323857@gmail.com> <20190718145840.c4487d2174930374300a0d7d@bidouilliste.com> From: Denis Polygalov Message-ID: <300bcdce-1471-e9a6-e332-84d3f822a65c@gmail.com> Date: Sun, 28 Jul 2019 23:33:16 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190718145840.c4487d2174930374300a0d7d@bidouilliste.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 88D4B97372 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=RszgZ3Ny; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of dpolyg@gmail.com designates 2607:f8b0:4864:20::644 as permitted sender) smtp.mailfrom=dpolyg@gmail.com X-Spamd-Result: default: False [-4.90 / 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)[]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.71)[-0.708,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; 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(-0.99)[-0.989,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-1.20)[ip: (-0.39), ipnet: 2607:f8b0::/32(-3.09), asn: 15169(-2.44), country: US(-0.05)]; RCVD_IN_DNSWL_NONE(0.00)[4.4.6.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] 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, 28 Jul 2019 14:33:23 -0000 Can somebody please explain what is exact command to switch FreeBSD's serial console speed to the 1.5Mbps as required by ROCK64 board? I have u-boot interrupted from auto-loading and trying to boot FreeBSD via network manually by typing this: => dhcp tftpboot ${kernel_addr_r} boot/loader.efi tftpboot ${fdt_addr_r} boot/dtb/rockchip/rk3328-rock64.dtb bootefi ${kernel_addr_r} ${fdt_addr_r} After that I can see the FreeBSD loader's menu, but then kernel hangs during loading. Is the fact that I can see FreeBSD loader's menu is enough to ensure that kernel will also inherit and continue use the correct baud-rate? How can I be sure that FreeBSD kernel when loaded will continue to use 1.5Mbps speed or this is not supported and I have to switch u-boot to something standard (115200) somehow? If so - how? thanks in advance, Denis. On 18/07/2019 9:58 pm, Emmanuel Vadot wrote: > On Thu, 18 Jul 2019 21:51:43 +0900 > Denis Polygalov wrote: > >>> On 16/07/2019 3:01 am, Emmanuel Vadot wrote: >>> How did you setup the boot ? >> >> download u-boot-flash-spi-rock64.img.xz from here: >> https://github.com/ayufan-rock64/linux-u-boot/releases >> and flash it. Remove the microSD card. >> Setup tftp server and nfs servers. >> Reset the board, interrupt u-boot and switch to manual mode. >> Then type in terminal: >> dhcp >> tftpboot ${kernel_addr_r} boot/loader.efi >> tftpboot ${fdt_addr_r} boot/dtb/rockchip/rk3399-rockpro64.dtb > > You need to 'fdt addr ${fdt_addr_r}' here iirc > >> bootefi ${kernel_addr_r} ${fdt_addr_r} >> >> >>> Do you have tftpd running so u-boot can download the loader and the >>> dtb ? >> >> yes, I do and I can see in the tftp server logs that both >> boot/loader.efi >> and boot/dtb/rockchip/rk3399-rockpro64.dtb >> are downloaded successfully. >> >>> If you don't have the dtb in $TFTPDIR/dtb/rockchip/ that might be the >>> problem, I recall the dtb included in u-boot being incomplete. >> >> I'm using dtb that is included into the >> FreeBSD-13.0-CURRENT-arm64-aarch64-20190711-r349909-memstick.img >> >> >>> I've just booted mine after updating to r350003+c99cb2e79ed6 >>> without a problem. >>> >> >> Well, I don't see image of this release on the FreeBSD.org server. >> I guess you mean you compile it from source by yourself? >> >>> On 16/07/2019 4:49 am, Peter Jeremy wrote: >>>> I'm running a Rock64 with >>>> U-Boot SPL 2017.09-rockchip-ayufan-1035-gd646df03ac (Oct 26 2018 - 08:35:43) >>>> and booting FreeBSD diskless. >> >> I tried this old 1035 u-boot. No luck, same problem. >> >> Regards, >> Denis. > > From owner-freebsd-arm@freebsd.org Sun Jul 28 14:39:37 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 CBDDBAC9C6 for ; Sun, 28 Jul 2019 14:39:37 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out.migadu.com (out.migadu.com [91.121.223.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.migadu.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DA0219753D for ; Sun, 28 Jul 2019 14:39:35 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: (Migadu outbound); Sun, 28 Jul 2019 14:38:21 +0000 Received: from wms1-eu-central.migadu.org (wms1-eu-central.migadu.org [172.104.244.218]) by out.migadu.com (Haraka/2.8.16) with ESMTPSA id C41C5841-1DC0-415F-9C80-7CBF5D821376.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 verify=FAIL); Sun, 28 Jul 2019 14:38:21 +0000 MIME-Version: 1.0 Date: Sun, 28 Jul 2019 14:38:21 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: RainLoop/1.12.1 From: greg@unrelenting.technology Message-ID: <1952b119fb6df8afaaaed38f23684b78@unrelenting.technology> Subject: Re: Booting FreeBSD on Rock64 To: "Denis Polygalov" , freebsd-arm@freebsd.org In-Reply-To: <300bcdce-1471-e9a6-e332-84d3f822a65c@gmail.com> References: <300bcdce-1471-e9a6-e332-84d3f822a65c@gmail.com> <169de7cf-32f2-7b7b-c12e-a86a4b6a9e87@gmail.com> <20190715200127.4b649877d8baefeb5282df64@bidouilliste.com> <878b15d5-92a5-5137-121c-5a5038323857@gmail.com> <20190718145840.c4487d2174930374300a0d7d@bidouilliste.com> DKIM-Signature: v=1; a=rsa-sha256; bh=YW80B9kUMVYguZn+R51bPx2vlSlngADO+GBJ/V4YFu0=; c=relaxed/simple; d=unrelenting.technology; h=from:subject:date:to; s=default; b=W4KDEm7nDLx9uPk2AJu/Rbgj0EFF8ScV0gOqTDpYfDDn4l/2zZ4RVYGAMG8JJJt0Cv6mOMynxzSi/ix4OeW9EsSmR6OaLZhwztsK0xr+4VaptWEEp5byn0sgWIc+84TLwPa/z/9CbGYuTxjCiOTqwMNGjgpzyuKQQnXEgLId1Fo= X-Rspamd-Queue-Id: DA0219753D X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=default header.b=W4KDEm7n; dmarc=pass (policy=none) header.from=unrelenting.technology; spf=pass (mx1.freebsd.org: domain of greg@unrelenting.technology designates 91.121.223.63 as permitted sender) smtp.mailfrom=greg@unrelenting.technology X-Spamd-Result: default: False [-6.18 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=default]; NEURAL_HAM_MEDIUM(-0.99)[-0.989,0]; IP_SCORE(-2.63)[ip: (-9.90), ipnet: 91.121.0.0/16(-4.40), asn: 16276(1.18), country: FR(-0.01)]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:91.121.223.63]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_SHORT(-0.56)[-0.557,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[unrelenting.technology:+]; RCPT_COUNT_TWO(0.00)[2]; FROM_NO_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[63.223.121.91.list.dnswl.org : 127.0.10.0]; DMARC_POLICY_ALLOW(-0.50)[unrelenting.technology,none]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MX_GOOD(-0.01)[aspmx1.migadu.com,aspmx2.migadu.com]; ASN(0.00)[asn:16276, ipnet:91.121.0.0/16, country:FR]; MID_RHS_MATCH_FROM(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: Sun, 28 Jul 2019 14:39:37 -0000 July 28, 2019 5:33 PM, "Denis Polygalov" wrote:=0A=0A>= Can somebody please explain what is exact=0A> command to switch FreeBSD'= s serial console=0A> speed to the 1.5Mbps as required by ROCK64 board?=0A= > How can I be sure that FreeBSD kernel when loaded=0A> will continue to = use 1.5Mbps speed or this is not supported=0A> and I have to switch u-boo= t to something standard (115200)=0A> somehow? If so - how?=0A=0AMy boot s= cript is:=0A=0Aenv set serverip 192.168.1.2=0Aenv set baudrate 15000000= =0Aenv set bootargs boot.nfsroot.server=3D${serverip} boot.nfsroot.path= =3D/=E2=80=A6/ROCK64FBSD12 comconsole_speed=3D${baudrate}=0Atftpboot ${ke= rnel_addr_r} loader.efi=0Atftpboot ${fdt_addr_r} dtb/rockchip/rk3328-rock= 64.dtb=0Abootefi ${kernel_addr_r} ${fdt_addr_r}=0A=0AI'm not sure how muc= h of this is necessary, but try the comconsole_speed argument if your ker= nel doesn't get the right speed. From owner-freebsd-arm@freebsd.org Sun Jul 28 14:46:29 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 9EB8FACD41 for ; Sun, 28 Jul 2019 14:46:29 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 03D7A979BF for ; Sun, 28 Jul 2019 14:46:27 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 0f68ab18; Sun, 28 Jul 2019 16:46:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=Th4FyJ5r7lmEQkmR5GBsRT2Z6qw=; b=ENOcUL2rSuSoRm5fGkzh6mWQBHy0 r0AGKNSWd5zeVhAM6MDPXZBaLmZEkcaWR8//O/2aLIx9IUAlA1NmVhVybkGehvGM 23o4YZU5uXy2251T1VY0nIeRiVijpLyVsxM2R46EaI8cHe9+6OwBu0IP4nB60Q2b JnI2bV9ZF2RPG9M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=oWWayJrRnrHocSV2UjO7HJUv3XDz/IVxIhD1up58O2H8RlJubbOghRdd 2pBy8bf7aYhT9dvtPBz3OOJN3RhkmukTf7oZOPZKZjZ9YFZkFXyYcimiy2S26ubY i4NoEic396L8wOCbrw9BGxaz0138e7c1iUm5NU6y8EfCH8mu0xw= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 14660e77 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Sun, 28 Jul 2019 16:46:19 +0200 (CEST) Date: Sun, 28 Jul 2019 16:46:19 +0200 From: Emmanuel Vadot To: Denis Polygalov Cc: freebsd-arm@freebsd.org Subject: Re: Booting FreeBSD on Rock64 Message-Id: <20190728164619.7f40eccb59717d18996164b1@bidouilliste.com> In-Reply-To: <300bcdce-1471-e9a6-e332-84d3f822a65c@gmail.com> References: <169de7cf-32f2-7b7b-c12e-a86a4b6a9e87@gmail.com> <20190715200127.4b649877d8baefeb5282df64@bidouilliste.com> <878b15d5-92a5-5137-121c-5a5038323857@gmail.com> <20190718145840.c4487d2174930374300a0d7d@bidouilliste.com> <300bcdce-1471-e9a6-e332-84d3f822a65c@gmail.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 03D7A979BF X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mail header.b=ENOcUL2r; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.177.182 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [2.00 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mail]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:212.83.177.182/32]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[bidouilliste.com]; NEURAL_SPAM_MEDIUM(0.56)[0.561,0]; NEURAL_SPAM_SHORT(0.96)[0.961,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.04)[0.043,0]; MX_GOOD(-0.01)[mx-backup.blih.net,mail.blih.net]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(0.34)[ip: (-0.97), ipnet: 212.83.160.0/19(2.61), asn: 12876(0.08), country: FR(-0.01)]; ASN(0.00)[asn:12876, ipnet:212.83.160.0/19, country:FR]; MID_RHS_MATCH_FROM(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: Sun, 28 Jul 2019 14:46:29 -0000 On Sun, 28 Jul 2019 23:33:16 +0900 Denis Polygalov wrote: > Can somebody please explain what is exact > command to switch FreeBSD's serial console > speed to the 1.5Mbps as required by ROCK64 board? > > I have u-boot interrupted from auto-loading > and trying to boot FreeBSD via network manually > by typing this: > > => dhcp > tftpboot ${kernel_addr_r} boot/loader.efi > tftpboot ${fdt_addr_r} boot/dtb/rockchip/rk3328-rock64.dtb > bootefi ${kernel_addr_r} ${fdt_addr_r} > > After that I can see the FreeBSD loader's menu, > but then kernel hangs during loading. You didn't do what I said in my last email : fdt addr ${fdt_addr_r} before bootefi. Note that if your DHCP server expose the next-server option you can just do : => setenv boot_targets dhcp => boot > Is the fact that I can see FreeBSD loader's menu is enough > to ensure that kernel will also inherit and continue use > the correct baud-rate? The kernel will use the baud rate specified in the DTB. > How can I be sure that FreeBSD kernel when loaded > will continue to use 1.5Mbps speed or this is not supported > and I have to switch u-boot to something standard (115200) > somehow? If so - how? > > thanks in advance, > Denis. BTW there is a new u-boot-rock64 port that you might want to use, you can boot from sdcard now. > On 18/07/2019 9:58 pm, Emmanuel Vadot wrote: > > On Thu, 18 Jul 2019 21:51:43 +0900 > > Denis Polygalov wrote: > > > >>> On 16/07/2019 3:01 am, Emmanuel Vadot wrote: > >>> How did you setup the boot ? > >> > >> download u-boot-flash-spi-rock64.img.xz from here: > >> https://github.com/ayufan-rock64/linux-u-boot/releases > >> and flash it. Remove the microSD card. > >> Setup tftp server and nfs servers. > >> Reset the board, interrupt u-boot and switch to manual mode. > >> Then type in terminal: > >> dhcp > >> tftpboot ${kernel_addr_r} boot/loader.efi > >> tftpboot ${fdt_addr_r} boot/dtb/rockchip/rk3399-rockpro64.dtb > > > > You need to 'fdt addr ${fdt_addr_r}' here iirc > > > >> bootefi ${kernel_addr_r} ${fdt_addr_r} > >> > >> > >>> Do you have tftpd running so u-boot can download the loader and the > >>> dtb ? > >> > >> yes, I do and I can see in the tftp server logs that both > >> boot/loader.efi > >> and boot/dtb/rockchip/rk3399-rockpro64.dtb > >> are downloaded successfully. > >> > >>> If you don't have the dtb in $TFTPDIR/dtb/rockchip/ that might be the > >>> problem, I recall the dtb included in u-boot being incomplete. > >> > >> I'm using dtb that is included into the > >> FreeBSD-13.0-CURRENT-arm64-aarch64-20190711-r349909-memstick.img > >> > >> > >>> I've just booted mine after updating to r350003+c99cb2e79ed6 > >>> without a problem. > >>> > >> > >> Well, I don't see image of this release on the FreeBSD.org server. > >> I guess you mean you compile it from source by yourself? > >> > >>> On 16/07/2019 4:49 am, Peter Jeremy wrote: > >>>> I'm running a Rock64 with > >>>> U-Boot SPL 2017.09-rockchip-ayufan-1035-gd646df03ac (Oct 26 2018 - 08:35:43) > >>>> and booting FreeBSD diskless. > >> > >> I tried this old 1035 u-boot. No luck, same problem. > >> > >> Regards, > >> Denis. > > > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Sun Jul 28 15:08: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 C7120AD40C for ; Sun, 28 Jul 2019 15:08:00 +0000 (UTC) (envelope-from dpolyg@gmail.com) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (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 EEFBC6843D for ; Sun, 28 Jul 2019 15:07:59 +0000 (UTC) (envelope-from dpolyg@gmail.com) Received: by mail-pl1-x62c.google.com with SMTP id a93so26465484pla.7 for ; Sun, 28 Jul 2019 08:07:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=OTulV2gFAfoNw0ZRqmAV1oJVbLPeuUoJu1Ocl5hrQMM=; b=rD9V03bBFosmaisjJIc56cIFparW72IHFX7xjj0+dPoWOOegLUbtX6qu+kqCXn8KzN PkyEd3K/MrbMKvnNi8IqrE//CvdH+OkY+pzFYKOl17GowANjb3Z/p2SZ2oGC9TOqmyRa +GJugdu4kyZrDI2eM5fVOUduFT23TYwOCBGYOuN2GZqYCn0ag4cYg5IzYihwHylaKzJO mFQ0+CJdkaJfV6FAJUrx7r3Tl+1s6n+vJ3oE4ILRitFeH4J7fvUYy+gx+uQshqyKPEb8 uuXtIeSLJHANqA6B+4wzmpngHW+IV8vK7xZExeJfrzPfAw0pUjd6Jhbun7PAiAcfiVs8 1ZBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=OTulV2gFAfoNw0ZRqmAV1oJVbLPeuUoJu1Ocl5hrQMM=; b=GV2KrQhRrskSjBobri69P7nHxTpCt8lCqcRDgyMSUYVXXEAAVtMsqyr9VBiIx4KlTY Pv7rf5rsc1x53Lh8QDJYp0SommP035QAxifN94abPwHeygwH3ElZYJRTFX9Ux0DBKXuP HwbKB95qqKduUWQgfTSt3X/ho9g3TDCUGKSXQGZ/hvQ2UtIj4iWLeVd3gyOtygxIPuxE pcdi6Pdliu3EwNSaWh8zdV6s4mGqy9RPpfpCM+MA+mK5uvcnTojAsGyCkNVPQpn2uxDA GqpmHVS0aBrtoEa0w2wqJ6zHZUL8DjJoptVZWznDunEadKF0g+GE3V+cEcOjwsqp8rNa fDdA== X-Gm-Message-State: APjAAAXAgS/g+zKjda26f3LaVQhE0r3NFNfvLUorgIueWMPlAdP8dyYE 24DOdOP0KI57HPvBCvQpxjombhWI X-Google-Smtp-Source: APXvYqyqvQl6VelNqbu957k8UsyUQgmZk8KnHT8QbKifVUrsaJ4JxNaav1t8Zed1u1qu7r7xcdK03g== X-Received: by 2002:a17:902:2de4:: with SMTP id p91mr74883983plb.28.1564326478708; Sun, 28 Jul 2019 08:07:58 -0700 (PDT) Received: from [192.168.1.100] (ngn8-ppp1551.tokyo.sannet.ne.jp. [157.192.118.27]) by smtp.googlemail.com with ESMTPSA id f15sm66391215pje.17.2019.07.28.08.07.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Jul 2019 08:07:58 -0700 (PDT) Subject: Re: Booting FreeBSD on Rock64 To: Emmanuel Vadot Cc: freebsd-arm@freebsd.org References: <169de7cf-32f2-7b7b-c12e-a86a4b6a9e87@gmail.com> <20190715200127.4b649877d8baefeb5282df64@bidouilliste.com> <878b15d5-92a5-5137-121c-5a5038323857@gmail.com> <20190718145840.c4487d2174930374300a0d7d@bidouilliste.com> <300bcdce-1471-e9a6-e332-84d3f822a65c@gmail.com> <20190728164619.7f40eccb59717d18996164b1@bidouilliste.com> From: Denis Polygalov Message-ID: Date: Mon, 29 Jul 2019 00:07:55 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190728164619.7f40eccb59717d18996164b1@bidouilliste.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: EEFBC6843D X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=rD9V03bB; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of dpolyg@gmail.com designates 2607:f8b0:4864:20::62c as permitted sender) smtp.mailfrom=dpolyg@gmail.com X-Spamd-Result: default: False [-6.72 / 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]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.82)[-0.821,0]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; 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)[-0.997,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]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[c.2.6.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(-2.90)[ip: (-8.90), ipnet: 2607:f8b0::/32(-3.09), asn: 15169(-2.44), country: US(-0.05)] 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, 28 Jul 2019 15:08:00 -0000 > You didn't do what I said in my last email : fdt addr ${fdt_addr_r} > before bootefi. oh, I'm sorry, actually I did, just decide not to send more e-mails because the result was the same - freezing at the same booting stage. I was troubleshooting other parts of my setup (dhcp, tftp, nfs servers). Now I'm sure the servers works because I manage to boot via network using NanoPi Neo2 board. I will try the fdt addr ${fdt_addr_r} command in combination with console speed setup anyway, thanks. Regards, Denis. From owner-freebsd-arm@freebsd.org Sun Jul 28 20:54: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 81D63B3C2F for ; Sun, 28 Jul 2019 20:54:24 +0000 (UTC) (envelope-from rj@obsigna.com) 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 1AF50762EE for ; Sun, 28 Jul 2019 20:54:24 +0000 (UTC) (envelope-from rj@obsigna.com) Received: by mailman.nyi.freebsd.org (Postfix) id 1A60FB3C2E; Sun, 28 Jul 2019 20:54:24 +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 1A20BB3C2D for ; Sun, 28 Jul 2019 20:54:24 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from projectstore.net (ec2-18-228-164-192.sa-east-1.compute.amazonaws.com [18.228.164.192]) (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 CA9F9762E9; Sun, 28 Jul 2019 20:54:18 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mail.obsigna.com (unknown [179.212.183.9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by projectstore.net (Postfix) with ESMTPSA id 6D6FA1E11CD; Sun, 28 Jul 2019 17:54:08 -0300 (-03) Received: from rolf.obsigna.com (rolf.obsigna.com [192.168.222.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 375B81350F946; Sun, 28 Jul 2019 17:54:04 -0300 (-03) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: 13-CURRENT snapshot 20190718 r350103 doesn't boot on BeagleBone White From: "Dr. Rolf Jansen" In-Reply-To: <20190723002116.75493451127739cf50b4077d@bidouilliste.com> Date: Sun, 28 Jul 2019 17:54:02 -0300 Cc: John-Mark Gurney , arm@FreeBSD.org, Ian Lepore Content-Transfer-Encoding: quoted-printable Message-Id: <24B1B5B9-4B50-4F63-AC50-FB3724BAC418@obsigna.com> References: <20190721180510.GQ2342@funkthat.com> <415c9b4760029235cd62bf95a35a736f7566cb9d.camel@freebsd.org> <20190721205557.GR2342@funkthat.com> <20190722102652.abde19a9fb609451cb618fde@bidouilliste.com> <20190722171251.GU2342@funkthat.com> <20190723002116.75493451127739cf50b4077d@bidouilliste.com> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3445.9.1) X-Rspamd-Queue-Id: 1AF50762EE X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; spf=fail (mx1.freebsd.org: domain of rj@obsigna.com does not designate 2610:1c1:1:606c::50:13 as permitted sender) smtp.mailfrom=rj@obsigna.com X-Spamd-Result: default: False [-1.74 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FORGED_RECIPIENTS_FORWARDING(0.00)[]; FORWARDED(0.00)[arm@mailman.nyi.freebsd.org]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; SPF_FAIL_FORWARDING(0.00)[]; MX_GOOD(-0.01)[cached: obsigna.com]; NEURAL_HAM_SHORT(-0.24)[-0.238,0]; RCVD_NO_TLS_LAST(0.10)[]; RECEIVED_SPAMHAUS_PBL(0.00)[9.183.212.179.zen.spamhaus.org : 127.0.0.11]; IP_SCORE(-1.05)[ip: (1.13), ipnet: 2610:1c1:1::/48(-3.58), asn: 11403(-2.72), country: US(-0.05)]; R_DKIM_NA(0.00)[]; FORGED_RECIPIENTS(0.00)[jmg@funkthat.com ..,freebsd-arm@freebsd.org]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; ARC_NA(0.00)[]; R_SPF_FAIL(0.00)[-all]; RCVD_COUNT_FIVE(0.00)[6]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_MEDIUM(-0.95)[-0.950,0]; NEURAL_HAM_LONG(-1.00)[-0.996,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[obsigna.com]; FROM_NAME_HAS_TITLE(1.00)[dr] 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, 28 Jul 2019 20:54:24 -0000 > Am 22.07.2019 um 19:21 schrieb Emmanuel Vadot : >=20 > On Mon, 22 Jul 2019 10:12:51 -0700 > John-Mark Gurney wrote: >=20 >> Emmanuel Vadot wrote this message on Mon, Jul 22, 2019 at 10:26 = +0200: >>> On Sun, 21 Jul 2019 13:55:57 -0700 >>> John-Mark Gurney wrote: >>>=20 >>>> Ian Lepore wrote this message on Sun, Jul 21, 2019 at 12:31 -0600: >>>>> On Sun, 2019-07-21 at 11:05 -0700, John-Mark Gurney wrote: >>>>>> The microSD card that I was using on my BeagleBone white got >>>>>> corrupted, >>>>>> so I decided to update to the latest version. The latest = snapshot >>>>>> fails >>>>>> to boot. It loads the kernel, but then when starting the kernel, = it >>>>>> hangs, and eventually it will reset. >>>>>>=20 >>>>>> The latest 12 snapshot boots fine: BEAGLEBONE-20190718-r350087. >>>>>>=20 >>>>>> Any ideas? I tried all three available 13 snaps, and they all = behave >>>>>> the same. >>>>>>=20 >>>>>=20 >>>>> This happened with the latest DTS import (which was months ago). = A >>>>> couple people have speculated that we just need a trivial = do-nothing >>>>> driver for the new ti,sysc device, but when I tried that a couple >>>>> months ago it didn't work, so instead I just reverted sys/dts to = the >>>>> old source and got on with what I needed to do. >>>>=20 >>>> Can we revert the dts in the tree then? Doesn't help when we know >>>> the fix, but don't apply it... >>>=20 >>> That would be a pain for the next updates. >>=20 >> Well, IMO, better than leaving a platform broken for months... >>=20 >>>> Or add an overlay that undoes the changes? >>>>=20 >>>> I can do some testing... >>>=20 >>> Could be possible but that will probably break in a few updates of = the >>> DTS files. >>>=20 >>> We need a TI maintainer that's all. >>=20 >> I'd recommend we disconnect the builds then or something so that = people >> know not even to bother to try the images instead of wasting hours of >> time trying to figure out what's wrong w/ the images... >>=20 >> At least then I'd post where's the images, and you would have replied >> that things aren't working... >>=20 >>>>> This is just the latest in a years-long string of breakages = because the >>>>> linux TI folks just never stop tinkering with their device-tree = source. >>>>> I'm sure they're doing it because it gets them some benefits, but = for >>>>> us the changes add no value and have a high maintenance cost. A = hang >>>>> before the copyright banner appears is especially painful to debug >>>>> (doubly so because there's no existing EARLY_PRINTF support in the = ti >>>>> code). >>>>=20 >>>> [...] >>=20 >> --=20 >> John-Mark Gurney Voice: +1 415 225 5579 >>=20 >> "All that I will do, has been done, All that I have, has not." >=20 > So I've unbroken the BBB. >=20 > I've made two commits : > r350229 ([1]) changes the hwmod driver to lookup the property in the > parent node as the dts changed that. > r350230 ([2]) adds a new driver for the ti,sysc bus. It's a simplebus > like bus and for now we only threat it like if it was. >=20 > But this is not enough to boot on BBB for now with the latest DTS. > I've put on a github branch ([3]) two other commits. >=20 > The first one correct the region of uart0 which isn't correct, I guess = linux > doesn't care about this as much as we do. Since this patches the DTS I = want > to start the process of upstreaming first before commiting this patch = into > our tree. I also want to update the DTS to Linux 5.2 since I want to = merge > those for 12.1 . > The second one take care of a problem in ofw_reg_to_paddr. Since we = have now > a lot of region in the ti.sysc drivers, using only 32 pcells for the = regions > isn't enough. I've temporary bumped this value to 64 which is enough = for booting > on the BBB but we need a cleaner solution. I'll look into it soon-ish. >=20 > So right now if you want to run current on BBB please take update you = source tree > and take the two patches from my github branch. >=20 > Note that I think that this is the last time that I fix TI related = problems > in the tree. I've spent too much time fixing BBB and Pandaboard during = the > last 12 months and I don't even use or care about those boards. If = someone > wants to keep them alive please invest time or money into this. >=20 > Thanks to ian@ for helping me with this issue. >=20 > [1] : = https://svnweb.freebsd.org/base/head/sys/arm/ti/ti_hwmods.c?revision=3D350= 229&view=3Dmarkup > [2] : = https://svnweb.freebsd.org/base/head/sys/arm/ti/ti_sysc.c?revision=3D35023= 0&view=3Dmarkup > [3] : https://github.com/evadot/freebsd/tree/bbb In the course of resuming the work on a measurement controller project, = whose heart is a BeagleBone Black, I updated the running FreeBSD = 13.0-CURRENT r345380 (March 2019) to the latest snapshot r350103 = (2019-07-18), which didn=E2=80=99t include your patches yet, and as = expected, I experienced the BBB hanging at boot. So, I compiled a new = Kernel from trunk, r350391, including your patches [1]/[2] and manually = [3], and I replaced the dtb directory on the FAT partition of the BBB = with the new one, which has been generated together with the kernel. = Unfortunately, the BBB still hangs in the very same stage during booting = up. So, nothing has been unbroken. I tried the kernel r350103 (no =E2=80=9Eun-breaking=E2=80=9C patches = yet) with the latest dtb, no dice either. Now, I checked out the other stages of the sys/gnu/dts/arm directory, = i.e.: svn co -r 347365 https://svn.freebsd.org/base/head/sys/gnu/dts/arm = arm-5.0 svn co -r 346091 https://svn.freebsd.org/base/head/sys/gnu/dts/arm = arm-4.2 I rebuild the kernel r350391 having all patches applied, but after = replacing sys/gnu/dts/arm by a symlink to each of the older DTS = versions, respectively. DTS-5.0 did not work same hanger. However, with = DTS-4.2, I saw a major advancement in the boot sequence, and the BB = Black stopped only when it thought it is a Green one: ... fb0: mem 0x4830e000-0x4830efff irq 43 on = simplebus0 ti_adc0: mem 0x44e0d000-0x44e0dfff irq 44 = disabled on simplebus0 ti_adc0: scheme: 0x1 func: 0x730 rtl: 0 rev: 0.1 custom rev: 0 gpioled0: on ofwbus0 gpioled0: failed to map pin gpioled0: failed to map pin gpioled0: failed to map pin gpioled0: failed to map pin cryptosoft0: panic: No usable event timer found! cpuid =3D 0 time =3D 1 Uptime: 1s Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... I removed patches [1] and [3] and left the DTS-4.2 in place, then I = compiled and installed another kernel+dtb, and finally, with this one, = the BBB completed booting successfully without any hick-up. Bottom line. Your patches didn=E2=80=99t resolve anything, but only made = the situation worse. Without [1] we were at least able to refrain to the = ARM-DTS-4.2, in order to get the BBB running. With [1] even this path is = broken. So please revert [1], and then I happily take your word that = this was the last time =E2=80=9Ethat you fix TI related problems.=E2=80=9C= Best regards Rolf From owner-freebsd-arm@freebsd.org Sun Jul 28 21:00:45 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 52349B3E8A for ; Sun, 28 Jul 2019 21:00:45 +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 6B2D9766D0 for ; Sun, 28 Jul 2019 21:00:34 +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 CABA31D8F2 for ; Sun, 28 Jul 2019 21:00:31 +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 x6SL0VdV075911 for ; Sun, 28 Jul 2019 21:00:31 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x6SL0VTA075900 for freebsd-arm@FreeBSD.org; Sun, 28 Jul 2019 21:00:31 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201907282100.x6SL0VTA075900@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, 28 Jul 2019 21:00:31 +0000 MIME-Version: 1.0 X-Rspamd-Queue-Id: 6B2D9766D0 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; NEURAL_HAM_SHORT(-0.99)[-0.991,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,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, 28 Jul 2019 21:00:45 -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 1 problems total for which you should take action. From owner-freebsd-arm@freebsd.org Mon Jul 29 07:08: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 66BBEBF770 for ; Mon, 29 Jul 2019 07:08:13 +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 6184D6AF4B for ; Mon, 29 Jul 2019 07:08:11 +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; Mon, 29 Jul 2019 09:07:55 +0200 id 00F40534.5D3E9B4B.00010C6D Date: Mon, 29 Jul 2019 09:07:55 +0200 From: Milan Obuch To: freebsd-arm@freebsd.org Subject: Re: Zybo Z7 board running FreeBSD success Message-ID: <20190729090755.4a07f71b@zeta.dino.sk> In-Reply-To: <20190722181202.5d69411e@zeta.dino.sk> References: <20190722181202.5d69411e@zeta.dino.sk> X-Mailer: Claws Mail 3.17.3 (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: 6184D6AF4B X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; 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 [-6.08 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,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)[]; MX_GOOD(-0.01)[mail.dino.sk]; NEURAL_HAM_SHORT(-0.96)[-0.957,0]; RCVD_IN_DNSWL_NONE(0.00)[72.65.245.84.list.dnswl.org : 127.0.10.0]; IP_SCORE(-2.81)[ip: (-8.08), ipnet: 84.245.64.0/18(-4.04), asn: 16160(-2.00), country: SK(0.06)]; 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: Mon, 29 Jul 2019 07:08:13 -0000 On Mon, 22 Jul 2019 18:12:02 +0200 Milan Obuch wrote: > Hi, > > page at http://www.skibo.net/zedbsd/ lists Zybo can run FreeBSD, but > image provided does not work on Zybo Z7 I have. After some struggles I > found a way to do it. My work is based on image provided there and, > with some help from Thomas Skibo, I was able to run it on my board. > > There was two troubles caused by some differences of the boards, main > one being different clock speed. I've got DTS from Thomas, which > should work on Z7, but it was not enough. It turned out u-boot need > to be built specifically for Z7 vs. original Zybo. Fortunatelly, we > have sysutils/u-boot-zybo port in our tree and it was easy to modify > it for Z7. Basically, rewrite Makefile zybo -> zybo-z7 and using > 2019.01 u-boot sources. Detail on freebsd-uboot mailing list. > > For some reason, not yet known, I must set verbose boot to overcome > panic from kernel at start. See serial console output in that case: [ snip ] > ugen0.1: at usbus0 > uhub0: on > usbus0 mmcsd0: 16GB TI> at mmc0 25.0MHz/4bit/65535-block vm_thread_new: kstack allocation > TI> failed > panic: kproc_start: bufdaemon: error 12 > cpuid = 0 > time = 1 > Uptime: 1s > Automatic reboot in 15 seconds - press a key on the console to abort > > No idea what's wrong, and why verbose boot 'fixes' (or maybe better > just works around this) a problem. Any hint? Note: real memory being > 0 MB is surely an error, but it shows this way when booting verbose > too. > I did full rebuild from source with usual buildworld/buildkernel and installkernel/installworld dance and this panic is gone, non-verbose boot works as well. My current svn revision is 350234, 12.0-STABLE. This took couple of days on board natively, but everything went smooth, with souces and object trees residing on nfs mounted volume. I just need to make /tmp filesystem large enough, -s150m in /etc/fstab, to ensure succesfull install - cullprit is clang and ll binaries stripping with install -s. They are just huge. My next plan is create 13-CURRENT version, but I do not expect anything substantially diferent - comparing sources in arm/xilinx and dev/xilinx does not show many differences, whe not counting FBSDID changes, just one in dev/xilinx/axidma.c. But development should occur here, so the move... Regards, Milan From owner-freebsd-arm@freebsd.org Mon Jul 29 11:20:27 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 18C03A6477 for ; Mon, 29 Jul 2019 11:20:27 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id C01B980008 for ; Mon, 29 Jul 2019 11:20:26 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: by mailman.nyi.freebsd.org (Postfix) id BF8CEA6476; Mon, 29 Jul 2019 11:20:26 +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 BF43DA6475 for ; Mon, 29 Jul 2019 11:20:26 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E840580006; Mon, 29 Jul 2019 11:20:24 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 30355877; Mon, 29 Jul 2019 13:20:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=BPfcCiKwm0GyiFrwgBQIUq6SoVM=; b=XpAT1PAjIIdO88VoUpXRPUzSMDtO VT1frQ+NJfOzJBSJRmejGGnLyQGGrt9UXzwnSpH+efKXRUO/nNYe0VirveavER30 wjcL3etr5oi67RyBMCmOCJx2xIk3fHUI6PDD6kOvTgNaA2LKHyQL3F2vmgLhr3Ka M+CShctGASKfMFw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=Scg7pTVld9/mFkzmSYLnNPK6RMWZZmnubBWBFB0JR1+Uvoht61JZj5j1 061ffL+RGnmIVNV2b9ydhuqU5elAnYKnI5N/NOhBZTbm/JWOENQXXLDRRkYfTdHP T2FW8V3ymrebxYDuUsHK/YnI3AzgTFMjyKctIKJaf2XL/YPXvGw= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 05a542db TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Mon, 29 Jul 2019 13:20:21 +0200 (CEST) Date: Mon, 29 Jul 2019 13:20:21 +0200 From: Emmanuel Vadot To: "Dr. Rolf Jansen" Cc: John-Mark Gurney , arm@FreeBSD.org, Ian Lepore Subject: Re: 13-CURRENT snapshot 20190718 r350103 doesn't boot on BeagleBone White Message-Id: <20190729132021.118a1d967ffac7772bd21ef4@bidouilliste.com> In-Reply-To: <24B1B5B9-4B50-4F63-AC50-FB3724BAC418@obsigna.com> References: <20190721180510.GQ2342@funkthat.com> <415c9b4760029235cd62bf95a35a736f7566cb9d.camel@freebsd.org> <20190721205557.GR2342@funkthat.com> <20190722102652.abde19a9fb609451cb618fde@bidouilliste.com> <20190722171251.GU2342@funkthat.com> <20190723002116.75493451127739cf50b4077d@bidouilliste.com> <24B1B5B9-4B50-4F63-AC50-FB3724BAC418@obsigna.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: E840580006 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mail header.b=XpAT1PAj; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.177.182 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [2.51 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mail]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:212.83.177.182/32]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[bidouilliste.com]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_MEDIUM(0.79)[0.789,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.91)[0.907,0]; MX_GOOD(-0.01)[cached: mx-backup.blih.net]; DKIM_TRACE(0.00)[bidouilliste.com:+]; NEURAL_SPAM_LONG(0.38)[0.379,0]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(0.34)[ip: (-0.96), ipnet: 212.83.160.0/19(2.61), asn: 12876(0.08), country: FR(-0.01)]; ASN(0.00)[asn:12876, ipnet:212.83.160.0/19, country:FR]; MID_RHS_MATCH_FROM(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, 29 Jul 2019 11:20:27 -0000 On Sun, 28 Jul 2019 17:54:02 -0300 "Dr. Rolf Jansen" wrote: > > Am 22.07.2019 um 19:21 schrieb Emmanuel Vadot : > >=20 > > On Mon, 22 Jul 2019 10:12:51 -0700 > > John-Mark Gurney wrote: > >=20 > >> Emmanuel Vadot wrote this message on Mon, Jul 22, 2019 at 10:26 +0200: > >>> On Sun, 21 Jul 2019 13:55:57 -0700 > >>> John-Mark Gurney wrote: > >>>=20 > >>>> Ian Lepore wrote this message on Sun, Jul 21, 2019 at 12:31 -0600: > >>>>> On Sun, 2019-07-21 at 11:05 -0700, John-Mark Gurney wrote: > >>>>>> The microSD card that I was using on my BeagleBone white got > >>>>>> corrupted, > >>>>>> so I decided to update to the latest version. The latest snapshot > >>>>>> fails > >>>>>> to boot. It loads the kernel, but then when starting the kernel, = it > >>>>>> hangs, and eventually it will reset. > >>>>>>=20 > >>>>>> The latest 12 snapshot boots fine: BEAGLEBONE-20190718-r350087. > >>>>>>=20 > >>>>>> Any ideas? I tried all three available 13 snaps, and they all beh= ave > >>>>>> the same. > >>>>>>=20 > >>>>>=20 > >>>>> This happened with the latest DTS import (which was months ago). A > >>>>> couple people have speculated that we just need a trivial do-nothing > >>>>> driver for the new ti,sysc device, but when I tried that a couple > >>>>> months ago it didn't work, so instead I just reverted sys/dts to the > >>>>> old source and got on with what I needed to do. > >>>>=20 > >>>> Can we revert the dts in the tree then? Doesn't help when we know > >>>> the fix, but don't apply it... > >>>=20 > >>> That would be a pain for the next updates. > >>=20 > >> Well, IMO, better than leaving a platform broken for months... > >>=20 > >>>> Or add an overlay that undoes the changes? > >>>>=20 > >>>> I can do some testing... > >>>=20 > >>> Could be possible but that will probably break in a few updates of the > >>> DTS files. > >>>=20 > >>> We need a TI maintainer that's all. > >>=20 > >> I'd recommend we disconnect the builds then or something so that people > >> know not even to bother to try the images instead of wasting hours of > >> time trying to figure out what's wrong w/ the images... > >>=20 > >> At least then I'd post where's the images, and you would have replied > >> that things aren't working... > >>=20 > >>>>> This is just the latest in a years-long string of breakages because= the > >>>>> linux TI folks just never stop tinkering with their device-tree sou= rce. > >>>>> I'm sure they're doing it because it gets them some benefits, but f= or > >>>>> us the changes add no value and have a high maintenance cost. A ha= ng > >>>>> before the copyright banner appears is especially painful to debug > >>>>> (doubly so because there's no existing EARLY_PRINTF support in the = ti > >>>>> code). > >>>>=20 > >>>> [...] > >>=20 > >> --=20 > >> John-Mark Gurney Voice: +1 415 225 5579 > >>=20 > >> "All that I will do, has been done, All that I have, has not." > >=20 > > So I've unbroken the BBB. > >=20 > > I've made two commits : > > r350229 ([1]) changes the hwmod driver to lookup the property in the > > parent node as the dts changed that. > > r350230 ([2]) adds a new driver for the ti,sysc bus. It's a simplebus > > like bus and for now we only threat it like if it was. > >=20 > > But this is not enough to boot on BBB for now with the latest DTS. > > I've put on a github branch ([3]) two other commits. > >=20 > > The first one correct the region of uart0 which isn't correct, I guess = linux > > doesn't care about this as much as we do. Since this patches the DTS I = want > > to start the process of upstreaming first before commiting this patch i= nto > > our tree. I also want to update the DTS to Linux 5.2 since I want to me= rge > > those for 12.1 . > > The second one take care of a problem in ofw_reg_to_paddr. Since we hav= e now > > a lot of region in the ti.sysc drivers, using only 32 pcells for the re= gions > > isn't enough. I've temporary bumped this value to 64 which is enough fo= r booting > > on the BBB but we need a cleaner solution. I'll look into it soon-ish. > >=20 > > So right now if you want to run current on BBB please take update you s= ource tree > > and take the two patches from my github branch. > >=20 > > Note that I think that this is the last time that I fix TI related prob= lems > > in the tree. I've spent too much time fixing BBB and Pandaboard during = the > > last 12 months and I don't even use or care about those boards. If some= one > > wants to keep them alive please invest time or money into this. > >=20 > > Thanks to ian@ for helping me with this issue. > >=20 > > [1] : https://svnweb.freebsd.org/base/head/sys/arm/ti/ti_hwmods.c?revis= ion=3D350229&view=3Dmarkup > > [2] : https://svnweb.freebsd.org/base/head/sys/arm/ti/ti_sysc.c?revisio= n=3D350230&view=3Dmarkup > > [3] : https://github.com/evadot/freebsd/tree/bbb >=20 > In the course of resuming the work on a measurement controller project, w= hose heart is a BeagleBone Black, I updated the running FreeBSD 13.0-CURREN= T r345380 (March 2019) to the latest snapshot r350103 (2019-07-18), which d= idn?t include your patches yet, and as expected, I experienced the BBB hang= ing at boot. So, I compiled a new Kernel from trunk, r350391, including you= r patches [1]/[2] and manually [3], and I replaced the dtb directory on the= FAT partition of the BBB with the new one, which has been generated togeth= er with the kernel. Unfortunately, the BBB still hangs in the very same sta= ge during booting up. So, nothing has been unbroken. >=20 > I tried the kernel r350103 (no ?un-breaking? patches yet) with the latest= dtb, no dice either. >=20 > Now, I checked out the other stages of the sys/gnu/dts/arm directory, i.e= .: >=20 > svn co -r 347365 https://svn.freebsd.org/base/head/sys/gnu/dts/arm arm-5.0 > svn co -r 346091 https://svn.freebsd.org/base/head/sys/gnu/dts/arm arm-4.2 >=20 > I rebuild the kernel r350391 having all patches applied, but after replac= ing sys/gnu/dts/arm by a symlink to each of the older DTS versions, respect= ively. DTS-5.0 did not work same hanger. However, with DTS-4.2, I saw a maj= or advancement in the boot sequence, and the BB Black stopped only when it = thought it is a Green one: >=20 > ... > fb0: mem 0x4830e000-0x4830efff irq 43 on simpl= ebus0 > ti_adc0: mem 0x44e0d000-0x44e0dfff irq 44 disabled= on simplebus0 > ti_adc0: scheme: 0x1 func: 0x730 rtl: 0 rev: 0.1 custom rev: 0 > gpioled0: on ofwbus0 > gpioled0: failed to map pin > gpioled0: failed to map pin > gpioled0: failed to map pin > gpioled0: failed to map pin > cryptosoft0: > panic: No usable event timer found! > cpuid =3D 0 > time =3D 1 > Uptime: 1s > Automatic reboot in 15 seconds - press a key on the console to abort > Rebooting... >=20 > I removed patches [1] and [3] and left the DTS-4.2 in place, then I compi= led and installed another kernel+dtb, and finally, with this one, the BBB c= ompleted booting successfully without any hick-up. In my patch that bump the cell var in ofw_reg_to_paddr I've set to 64 before pushing at the last minute, I must have not test with the right DTB because we need more than 64 elements. I've pushed a new set of patches in https://github.com/evadot/freebsd/commits/bbb_v2 (commits 9b33b59 and 94ec550). I've also fixed cpsw as the slave address changed (commited in r350410). > Bottom line. Your patches didn?t resolve anything, but only made the situ= ation worse. Without [1] we were at least able to refrain to the ARM-DTS-4.= 2, in order to get the BBB running. With [1] even this path is broken. So p= lease revert [1], and then I happily take your word that this was the last = time ?that you fix TI related problems.? Since it was so nicely asked I've commited a fix for this in r350408 that lookup the ti,hwmods property in the device node and fallback on the parent. > Best regards >=20 > Rolf P.S. : Note that I don't know how to solve the ofw_reg_to_paddr problem, 128 * uint32_t is really big for the kernel stack and we cannot use malloc since it is really early in boot and we also cannot use libfdt to lookup the data as this would only work on system that have libfdt. P.S. 2: the eMMC doesn't seems to work, sdhci complain that it cannot power the bus, this cause a big delay in boot as it is a possible root target. --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Mon Jul 29 11:25: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 92816A671D for ; Mon, 29 Jul 2019 11:25:14 +0000 (UTC) (envelope-from manu@bidouilliste.com) 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 72488803E4 for ; Mon, 29 Jul 2019 11:25:14 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: by mailman.nyi.freebsd.org (Postfix) id 6FE02A671C; Mon, 29 Jul 2019 11:25:14 +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 6F982A671B for ; Mon, 29 Jul 2019 11:25:14 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1DB93803E2; Mon, 29 Jul 2019 11:25:13 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 52377807; Mon, 29 Jul 2019 13:25:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=bS1Yz1q9taMHkR15OgNiDKdgYiY=; b=Xn/kbvSCPPhGOXGPDLJKLQN5ug05 S92FISTS2Jtbwx0sT9TN84ELxe1dTiqZbgCM5KQBo/TqdIyXiirq/NceNbRLXev/ cjGhaNe7TSAUi8Q9J40T8jlqxepE/fhBOBDfSnmEHrX0wgOlmWNs/cKp+iKhp8Ax jXQ4W6zxicFNNYk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=iQK/JrLGu22Xp+jUX9+wQBno2Zifwce6xFUxlxlQzSgYtBCddmxpG9A6 VO7Qd/a/757BtTftuNO0N1DXCivA+VXOu5oFAtXp+0eWX0SZbS9KUXJGynlGaRi5 I+DfkH5qgeHyXUc1jwH7mM5NZU78KU+PjThUJXzJq0lTqPp0ySQ= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 1a5129df TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Mon, 29 Jul 2019 13:25:11 +0200 (CEST) Date: Mon, 29 Jul 2019 13:25:11 +0200 From: Emmanuel Vadot To: arm@FreeBSD.org Cc: "Dr. Rolf Jansen" , Ian Lepore Subject: Re: 13-CURRENT snapshot 20190718 r350103 doesn't boot on BeagleBone White Message-Id: <20190729132511.82c5490259122e672f7e7275@bidouilliste.com> In-Reply-To: <20190729132021.118a1d967ffac7772bd21ef4@bidouilliste.com> References: <20190721180510.GQ2342@funkthat.com> <415c9b4760029235cd62bf95a35a736f7566cb9d.camel@freebsd.org> <20190721205557.GR2342@funkthat.com> <20190722102652.abde19a9fb609451cb618fde@bidouilliste.com> <20190722171251.GU2342@funkthat.com> <20190723002116.75493451127739cf50b4077d@bidouilliste.com> <24B1B5B9-4B50-4F63-AC50-FB3724BAC418@obsigna.com> <20190729132021.118a1d967ffac7772bd21ef4@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 72488803E4 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.983,0]; REPLY(-4.00)[]; 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, 29 Jul 2019 11:25:14 -0000 On Mon, 29 Jul 2019 13:20:21 +0200 Emmanuel Vadot wrote: > On Sun, 28 Jul 2019 17:54:02 -0300 > "Dr. Rolf Jansen" wrote: > > > > Am 22.07.2019 um 19:21 schrieb Emmanuel Vadot : > > > > > > On Mon, 22 Jul 2019 10:12:51 -0700 > > > John-Mark Gurney wrote: > > > > > >> Emmanuel Vadot wrote this message on Mon, Jul 22, 2019 at 10:26 +0200: > > >>> On Sun, 21 Jul 2019 13:55:57 -0700 > > >>> John-Mark Gurney wrote: > > >>> > > >>>> Ian Lepore wrote this message on Sun, Jul 21, 2019 at 12:31 -0600: > > >>>>> On Sun, 2019-07-21 at 11:05 -0700, John-Mark Gurney wrote: > > >>>>>> The microSD card that I was using on my BeagleBone white got > > >>>>>> corrupted, > > >>>>>> so I decided to update to the latest version. The latest snapshot > > >>>>>> fails > > >>>>>> to boot. It loads the kernel, but then when starting the kernel, it > > >>>>>> hangs, and eventually it will reset. > > >>>>>> > > >>>>>> The latest 12 snapshot boots fine: BEAGLEBONE-20190718-r350087. > > >>>>>> > > >>>>>> Any ideas? I tried all three available 13 snaps, and they all behave > > >>>>>> the same. > > >>>>>> > > >>>>> > > >>>>> This happened with the latest DTS import (which was months ago). A > > >>>>> couple people have speculated that we just need a trivial do-nothing > > >>>>> driver for the new ti,sysc device, but when I tried that a couple > > >>>>> months ago it didn't work, so instead I just reverted sys/dts to the > > >>>>> old source and got on with what I needed to do. > > >>>> > > >>>> Can we revert the dts in the tree then? Doesn't help when we know > > >>>> the fix, but don't apply it... > > >>> > > >>> That would be a pain for the next updates. > > >> > > >> Well, IMO, better than leaving a platform broken for months... > > >> > > >>>> Or add an overlay that undoes the changes? > > >>>> > > >>>> I can do some testing... > > >>> > > >>> Could be possible but that will probably break in a few updates of the > > >>> DTS files. > > >>> > > >>> We need a TI maintainer that's all. > > >> > > >> I'd recommend we disconnect the builds then or something so that people > > >> know not even to bother to try the images instead of wasting hours of > > >> time trying to figure out what's wrong w/ the images... > > >> > > >> At least then I'd post where's the images, and you would have replied > > >> that things aren't working... > > >> > > >>>>> This is just the latest in a years-long string of breakages because the > > >>>>> linux TI folks just never stop tinkering with their device-tree source. > > >>>>> I'm sure they're doing it because it gets them some benefits, but for > > >>>>> us the changes add no value and have a high maintenance cost. A hang > > >>>>> before the copyright banner appears is especially painful to debug > > >>>>> (doubly so because there's no existing EARLY_PRINTF support in the ti > > >>>>> code). > > >>>> > > >>>> [...] > > >> > > >> -- > > >> John-Mark Gurney Voice: +1 415 225 5579 > > >> > > >> "All that I will do, has been done, All that I have, has not." > > > > > > So I've unbroken the BBB. > > > > > > I've made two commits : > > > r350229 ([1]) changes the hwmod driver to lookup the property in the > > > parent node as the dts changed that. > > > r350230 ([2]) adds a new driver for the ti,sysc bus. It's a simplebus > > > like bus and for now we only threat it like if it was. > > > > > > But this is not enough to boot on BBB for now with the latest DTS. > > > I've put on a github branch ([3]) two other commits. > > > > > > The first one correct the region of uart0 which isn't correct, I guess linux > > > doesn't care about this as much as we do. Since this patches the DTS I want > > > to start the process of upstreaming first before commiting this patch into > > > our tree. I also want to update the DTS to Linux 5.2 since I want to merge > > > those for 12.1 . > > > The second one take care of a problem in ofw_reg_to_paddr. Since we have now > > > a lot of region in the ti.sysc drivers, using only 32 pcells for the regions > > > isn't enough. I've temporary bumped this value to 64 which is enough for booting > > > on the BBB but we need a cleaner solution. I'll look into it soon-ish. > > > > > > So right now if you want to run current on BBB please take update you source tree > > > and take the two patches from my github branch. > > > > > > Note that I think that this is the last time that I fix TI related problems > > > in the tree. I've spent too much time fixing BBB and Pandaboard during the > > > last 12 months and I don't even use or care about those boards. If someone > > > wants to keep them alive please invest time or money into this. > > > > > > Thanks to ian@ for helping me with this issue. > > > > > > [1] : https://svnweb.freebsd.org/base/head/sys/arm/ti/ti_hwmods.c?revision=350229&view=markup > > > [2] : https://svnweb.freebsd.org/base/head/sys/arm/ti/ti_sysc.c?revision=350230&view=markup > > > [3] : https://github.com/evadot/freebsd/tree/bbb > > > > In the course of resuming the work on a measurement controller project, whose heart is a BeagleBone Black, I updated the running FreeBSD 13.0-CURRENT r345380 (March 2019) to the latest snapshot r350103 (2019-07-18), which didn?t include your patches yet, and as expected, I experienced the BBB hanging at boot. So, I compiled a new Kernel from trunk, r350391, including your patches [1]/[2] and manually [3], and I replaced the dtb directory on the FAT partition of the BBB with the new one, which has been generated together with the kernel. Unfortunately, the BBB still hangs in the very same stage during booting up. So, nothing has been unbroken. > > > > I tried the kernel r350103 (no ?un-breaking? patches yet) with the latest dtb, no dice either. > > > > Now, I checked out the other stages of the sys/gnu/dts/arm directory, i.e.: > > > > svn co -r 347365 https://svn.freebsd.org/base/head/sys/gnu/dts/arm arm-5.0 > > svn co -r 346091 https://svn.freebsd.org/base/head/sys/gnu/dts/arm arm-4.2 > > > > I rebuild the kernel r350391 having all patches applied, but after replacing sys/gnu/dts/arm by a symlink to each of the older DTS versions, respectively. DTS-5.0 did not work same hanger. However, with DTS-4.2, I saw a major advancement in the boot sequence, and the BB Black stopped only when it thought it is a Green one: > > > > ... > > fb0: mem 0x4830e000-0x4830efff irq 43 on simplebus0 > > ti_adc0: mem 0x44e0d000-0x44e0dfff irq 44 disabled on simplebus0 > > ti_adc0: scheme: 0x1 func: 0x730 rtl: 0 rev: 0.1 custom rev: 0 > > gpioled0: on ofwbus0 > > gpioled0: failed to map pin > > gpioled0: failed to map pin > > gpioled0: failed to map pin > > gpioled0: failed to map pin > > cryptosoft0: > > panic: No usable event timer found! > > cpuid = 0 > > time = 1 > > Uptime: 1s > > Automatic reboot in 15 seconds - press a key on the console to abort > > Rebooting... > > > > I removed patches [1] and [3] and left the DTS-4.2 in place, then I compiled and installed another kernel+dtb, and finally, with this one, the BBB completed booting successfully without any hick-up. > > In my patch that bump the cell var in ofw_reg_to_paddr I've set to 64 > before pushing at the last minute, I must have not test with the right > DTB because we need more than 64 elements. > I've pushed a new set of patches in > https://github.com/evadot/freebsd/commits/bbb_v2 > (commits 9b33b59 and 94ec550). > > I've also fixed cpsw as the slave address changed (commited in > r350410). > > > Bottom line. Your patches didn?t resolve anything, but only made the situation worse. Without [1] we were at least able to refrain to the ARM-DTS-4.2, in order to get the BBB running. With [1] even this path is broken. So please revert [1], and then I happily take your word that this was the last time ?that you fix TI related problems.? > > Since it was so nicely asked I've commited a fix for this in r350408 > that lookup the ti,hwmods property in the device node and fallback on > the parent. > > > Best regards > > > > Rolf > > P.S. : Note that I don't know how to solve the ofw_reg_to_paddr > problem, 128 * uint32_t is really big for the kernel stack and we > cannot use malloc since it is really early in boot and we also cannot > use libfdt to lookup the data as this would only work on system that > have libfdt. > P.S. 2: the eMMC doesn't seems to work, sdhci complain that it cannot > power the bus, this cause a big delay in boot as it is a possible root > target. Also I've submitted a patch upstream for the DTS region size, I'm waiting on having a feedback to commit it in our tree. https://www.spinics.net/lists/devicetree/msg299750.html https://www.spinics.net/lists/devicetree/msg299751.html -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Mon Jul 29 11:25:27 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 DABEFA6738 for ; Mon, 29 Jul 2019 11:25:27 +0000 (UTC) (envelope-from 0102016c3d7a5dc3-7d7e0f9b-75c5-4055-939a-3922643aa3a9-000000@eu-west-1.amazonses.com) Received: from a4-5.smtp-out.eu-west-1.amazonses.com (a4-5.smtp-out.eu-west-1.amazonses.com [54.240.4.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 44BCE8043F for ; Mon, 29 Jul 2019 11:25:27 +0000 (UTC) (envelope-from 0102016c3d7a5dc3-7d7e0f9b-75c5-4055-939a-3922643aa3a9-000000@eu-west-1.amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=uwfrvhlat3drqdfg3hx77nynjjjdh6z6; d=sitaridev.co.za; t=1564399525; h=Message-ID:Date:Subject:From:Reply-To:To:MIME-Version:Content-Type:List-Unsubscribe:List-Id; bh=esUF8WA40zb8iiu3+4lBnHRyuTh62YX7iCfF+DX2yyQ=; b=N6vErUzMzYymooGCBqwl3NSqXt5X0MwPzmAXCQC7pR/0ZWrIHyRFiHKQCFCDZ91x MNfOeMuLoPLV6t1wwzSJYsonFCYY7IAk3q712vSDWIDYO7ZymyMTSH0Cd7vtQxHppNb vPautfRFAYE6lIV4BopyGq+y12K/tx6LMvDTGsPU= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ihchhvubuqgjsxyuhssfvqohv7z3u4hn; d=amazonses.com; t=1564399525; h=Message-ID:Date:Subject:From:Reply-To:To:MIME-Version:Content-Type:List-Unsubscribe:List-Id:Feedback-ID; bh=esUF8WA40zb8iiu3+4lBnHRyuTh62YX7iCfF+DX2yyQ=; b=Evq4dG7wKTecTEmuHuCLH/rJPAYyEkIjJDxABqigoGgwZobTyMre32Hv7C4wSxE4 Bg97T8uwDhumcT3cYfO3xB+GOfOXv1XjST535VaCNZmWev256z21j8s0ZDkY+vhOaGE NmLR+qrKbOe14k21eW7SK5f+t7LrkzakV+pRNd0c= Message-ID: <0102016c3d7a5dc3-7d7e0f9b-75c5-4055-939a-3922643aa3a9-000000@eu-west-1.amazonses.com> Date: Mon, 29 Jul 2019 11:25:25 +0000 Subject: Apartments | Ready to Move In | Waterbrook From: Sitari Country Estate | Somerset West Reply-To: Sitari Country Estate | Somerset West To: "freebsd-arm@freebsd.org" MIME-Version: 1.0 X-Sender: schelderberg@sitaridev.co.za X-Report-Abuse: Please report abuse for this campaign here: http://leopardmail.co.za/index.php/campaigns/fa692f264n566/report-abuse/kr5611ywn5335/zn951cqdvg0b8 X-Receiver: freebsd-arm@freebsd.org X-Ntog-Tracking-Did: 0 X-Ntog-Subscriber-Uid: zn951cqdvg0b8 X-Ntog-Mailer: SwiftMailer - 5.4.x X-Ntog-EBS: http://leopardmail.co.za/index.php/lists/block-address X-Ntog-Delivery-Sid: 1 X-Ntog-Customer-Uid: qy253wb5dy193 X-Ntog-Customer-Gid: 1 X-Ntog-Campaign-Uid: fa692f264n566 Precedence: bulk Feedback-ID: 1.eu-west-1.uvn48qXFNfbBCSq27QjYopu03+ZevnFjz7NsiwWAkk8=:AmazonSES X-SES-Outgoing: 2019.07.29-54.240.4.5 X-Rspamd-Queue-Id: 44BCE8043F X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=sitaridev.co.za header.s=uwfrvhlat3drqdfg3hx77nynjjjdh6z6 header.b=N6vErUzM; dkim=pass header.d=amazonses.com header.s=ihchhvubuqgjsxyuhssfvqohv7z3u4hn header.b=Evq4dG7w; spf=pass (mx1.freebsd.org: domain of 0102016c3d7a5dc3-7d7e0f9b-75c5-4055-939a-3922643aa3a9-000000@eu-west-1.amazonses.com designates 54.240.4.5 as permitted sender) smtp.mailfrom=0102016c3d7a5dc3-7d7e0f9b-75c5-4055-939a-3922643aa3a9-000000@eu-west-1.amazonses.com X-Spamd-Result: default: False [-3.56 / 15.00]; HAS_REPLYTO(0.00)[reply@sitaridev.co.za]; R_SPF_ALLOW(-0.20)[+ip4:54.240.0.0/18]; REPLYTO_DN_EQ_FROM_DN(0.00)[]; DKIM_TRACE(0.00)[sitaridev.co.za:+,amazonses.com:+]; MX_GOOD(-0.01)[cached: feedback-smtp.eu-west-1.amazonses.com]; NEURAL_HAM_SHORT(-0.50)[-0.499,0]; MAILLIST(-0.10)[generic]; FORGED_SENDER(0.00)[schelderberg@sitaridev.co.za,0102016c3d7a5dc3-7d7e0f9b-75c5-4055-939a-3922643aa3a9-000000@eu-west-1.amazonses.com]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+,1:+]; IP_SCORE(-0.55)[ipnet: 54.240.0.0/21(-1.35), asn: 16509(-1.34), country: US(-0.05)]; ASN(0.00)[asn:16509, ipnet:54.240.0.0/21, country:US]; FROM_NEQ_ENVFROM(0.00)[schelderberg@sitaridev.co.za,0102016c3d7a5dc3-7d7e0f9b-75c5-4055-939a-3922643aa3a9-000000@eu-west-1.amazonses.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.90)[-0.897,0]; R_DKIM_ALLOW(-0.20)[sitaridev.co.za:s=uwfrvhlat3drqdfg3hx77nynjjjdh6z6,amazonses.com:s=ihchhvubuqgjsxyuhssfvqohv7z3u4hn]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PRECEDENCE_BULK(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[sitaridev.co.za]; REPLYTO_DOM_EQ_FROM_DOM(0.00)[]; HAS_LIST_UNSUB(-0.01)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_IN_DNSWL_NONE(0.00)[5.4.240.54.list.dnswl.org : 127.0.15.0]; TO_DN_EQ_ADDR_ALL(0.00)[]; FORGED_SENDER_MAILLIST(0.00)[]; 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 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2019 11:25:27 -0000 NEW DEVELOPMENT =E2=80=A2 HELDERBERG WATERBROOK PREMIUM APARTMENTS = =C2=A0 Just Launched - Developers' Release A limited collection of 9 mo= ve-in ready Apartments =C2=A0 =C2=A0 =C2=A0 =C2=A0 Now Selling fr= om R 1 240 000 (Includes Transfer Duty) =C2=A0 =C2=A0 CALL ME BACK= http://leopardmail.co.za/index.php/campaigns/fa692f264n566/track-url/zn9= 51cqdvg0b8/a2183050e9e5193631c76e3977bbe3d6007fb8fa =C2=A0 GET SALES PA= CK =C2=A0 =C2=A0 =C2=A0 =C2=A0 VISIT WEBSITE http://leopardmail= .co.za/index.php/campaigns/fa692f264n566/track-url/zn951cqdvg0b8/d94332bfbb= ce26c2ee06372d8228cddaf2044096 =C2=A0 =C2=A0 Click here if you're not= able to view this mailer http://leopardmail.co.za/index.php/campaigns/fa= 692f264n566/track-url/zn951cqdvg0b8/770813fb77ecbc7aac88e8be224840486342c7d= 3 This email was sent to freebsd-arm@freebsd.org on=C2=A007/29/2019 from= Sitari Country Estate If the email was send in error please unsubscrib= e here -=C2=A0=C2=A0Unsubscribe http://leopardmail.co.za/index.php/list= s/kr5611ywn5335/unsubscribe/zn951cqdvg0b8/fa692f264n566 ~ Report email as= unsolicited http://leopardmail.co.za/index.php/campaigns/fa692f264n566/t= rack-url/zn951cqdvg0b8/c136613e29772fa6f76b868e2e363b215c88aede Leopard M= ail is an email-marketing service that serves companies of all shapes and= sizes. With several users/companies sending campaigns to hundreds of m= illions of recipients, we're bound to get abuse reports.=C2=A0 We take ab= use reports seriously, if you believe a customer is sending unsolicited a= nd or spam email, please report abuse immediately HERE http://leopardmail= .co.za/index.php/campaigns/fa692f264n566/track-url/zn951cqdvg0b8/c136613e29= 772fa6f76b868e2e363b215c88aede From owner-freebsd-arm@freebsd.org Mon Jul 29 11:35:34 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 B563CA6A56 for ; Mon, 29 Jul 2019 11:35:34 +0000 (UTC) (envelope-from dpolyg@gmail.com) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 20E4680A13 for ; Mon, 29 Jul 2019 11:35:34 +0000 (UTC) (envelope-from dpolyg@gmail.com) Received: by mail-pl1-x631.google.com with SMTP id k8so27422930plt.3 for ; Mon, 29 Jul 2019 04:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=GTqJHjTVTMfJKUi9AmCiB57V8JmnJkttn5xyWpD69MU=; b=EWpkOHt90JeOi5+D4RORBGrrL16Nh84EfWwDMRz6kANwTTJ7YrkyclnxwwHbaLKPlv dzbC6/iUFG8KrfvXSAKf7k3DBT5hbH8eeto3feXzQzonKF6/4A7kk5wUJNOjDMg+0Qxh sEJgoAVbR5Qtf5DlTTJTZX4Cv5sNdXh6x/IRBTfQ9wHG6N54gWrNuUPU0mlWeKteCwd1 vu3FBxDV+K6gw/5YuyfK7FNQTVOQNpsEL4Hy1dlvuCYMmbCZdxbahJariqC1cpcwPNlU BstvRlTXI4Mm7tn1VVBXAPfHvAZzyfNz+NaJ6Gg6qucEMnToyv4isalkLi+qOsxlT8h0 5Ocg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=GTqJHjTVTMfJKUi9AmCiB57V8JmnJkttn5xyWpD69MU=; b=qYPc9Q98xzFdAq7bMmRVwzBQivnOlgSv+T3ZIzKYYjLAz/e8CH1qV7Qfip2dGbV4R6 owwcLnCgSJs9rn0NBnEpBg5XYp8EpqxicDZAA0qbjyi8vWzx+weutUeCcJTwCftCRq75 do2Qvux3yjLDTGdu16OEzXxYz3ijZhRWlkMMxR3Wb3zYHk3FW5vNQ6Nw4JS8yUD92un2 4bPvzg6snkU7wD9h+OaXP7Ij/+RuVsu/xc5NN2ehVUy8kzopH+e6momAW08Ig6eMCRWU T+fGkEoKSHl4Jf4qtKH579vsGy8R8456vaT5CQEpd5XZ06ujjLxVtLE6X03clHF7OrWj 93gw== X-Gm-Message-State: APjAAAUqS/DJ9+Rv0gNgl20DwRJ3nXKmjdJOcQdfummNedgrkDISKonQ EvRPNGYcMHbgginQpi5H0ogRdew1o1I= X-Google-Smtp-Source: APXvYqwKzEDu8ZUsBU6jqOPCx2ouLPm3sp6ezkVcUKUFUiWBa5yOQv8IwyWdk/wgNWPVYgW3wRtmbw== X-Received: by 2002:a17:902:9a42:: with SMTP id x2mr110841965plv.106.1564400132505; Mon, 29 Jul 2019 04:35:32 -0700 (PDT) Received: from [192.168.1.100] (ngn8-ppp1551.tokyo.sannet.ne.jp. [157.192.118.27]) by smtp.googlemail.com with ESMTPSA id v63sm63819159pfv.174.2019.07.29.04.35.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jul 2019 04:35:32 -0700 (PDT) Subject: Re: Zybo Z7 board running FreeBSD success To: Milan Obuch , freebsd-arm@freebsd.org References: <20190722181202.5d69411e@zeta.dino.sk> From: Denis Polygalov Message-ID: Date: Mon, 29 Jul 2019 20:35:29 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190722181202.5d69411e@zeta.dino.sk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 20E4680A13 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=EWpkOHt9; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of dpolyg@gmail.com designates 2607:f8b0:4864:20::631 as permitted sender) smtp.mailfrom=dpolyg@gmail.com X-Spamd-Result: default: False [-6.95 / 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]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.98)[-0.977,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; 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)[-0.998,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]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[1.3.6.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(-2.96)[ip: (-9.22), ipnet: 2607:f8b0::/32(-3.09), asn: 15169(-2.44), country: US(-0.05)] 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, 29 Jul 2019 11:35:34 -0000 > Currently, nothing else seen. I plan to investigate FPGA possibilities, > too, but that's basically FreeBSD unrelated. > the main yummy point of Zynq SoC boards is the FPGA. I have some experience of working with SDAccel/Vivado and AFAIK there is no way to generate bitstream files on any platform except supported by Xilinx (i.e. Windows/Linux). At the same time I've seen products shipped with bunch of pre-generated bit files and a host software that program FPGA completely 'on the fly' with these files building various DSP pipelines according to user-defined plain text configuration file. Do you aim for something similar? Regards, Denis. From owner-freebsd-arm@freebsd.org Mon Jul 29 11:55: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 1A27DA704E for ; Mon, 29 Jul 2019 11:55:58 +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 EEC0681331 for ; Mon, 29 Jul 2019 11:55:56 +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; Mon, 29 Jul 2019 13:55:54 +0200 id 00F406AE.5D3EDECA.00014F71 Date: Mon, 29 Jul 2019 13:55:53 +0200 From: Milan Obuch To: Denis Polygalov Cc: freebsd-arm@freebsd.org Subject: Re: Zybo Z7 board running FreeBSD success Message-ID: <20190729135553.10ae2c8e@zeta.dino.sk> In-Reply-To: References: <20190722181202.5d69411e@zeta.dino.sk> X-Mailer: Claws Mail 3.17.3 (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: EEC0681331 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; 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 [-6.12 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dino.sk]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: mail.dino.sk]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[72.65.245.84.list.dnswl.org : 127.0.10.0]; NEURAL_HAM_SHORT(-0.97)[-0.971,0]; IP_SCORE(-2.84)[ip: (-8.13), ipnet: 84.245.64.0/18(-4.07), asn: 16160(-2.07), country: SK(0.06)]; FREEMAIL_TO(0.00)[gmail.com]; 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: Mon, 29 Jul 2019 11:55:58 -0000 On Mon, 29 Jul 2019 20:35:29 +0900 Denis Polygalov wrote: > > Currently, nothing else seen. I plan to investigate FPGA > > possibilities, too, but that's basically FreeBSD unrelated. > > > > the main yummy point of Zynq SoC boards is the FPGA. I agree. And its integration of PS and PL... > I have some experience of working with SDAccel/Vivado and > AFAIK there is no way to generate bitstream files on any > platform except supported by Xilinx (i.e. Windows/Linux). Well, nothing could be done here... Xilinx decided the way... maybe the software could run under linux emulation or in bhyve VM, but that's not an issue for me. This is limitation for hardware design stage, so I have not big trouble with it. It would be nice to be able to use my preferred OS even for that, but that's just a wish now. > At the same time I've seen products shipped with bunch of > pre-generated bit files and a host software that program > FPGA completely 'on the fly' with these files building > various DSP pipelines according to user-defined plain text > configuration file. Do you aim for something similar? Well, I am not that far yet. I am just starting to learn about possibilities in this area with no target set yet. I am starting my exploration with The Zynq Book. In any case, every additional link for design will be appreciated. Regards, Milan From owner-freebsd-arm@freebsd.org Mon Jul 29 19:52: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 B0F4DB3F5D for ; Mon, 29 Jul 2019 19:52:24 +0000 (UTC) (envelope-from filippo@ml.filippo.io) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.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 095366A1FC for ; Mon, 29 Jul 2019 19:52:22 +0000 (UTC) (envelope-from filippo@ml.filippo.io) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 0D9484A8 for ; Mon, 29 Jul 2019 15:52:14 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute3.internal (MEProxy); Mon, 29 Jul 2019 15:52:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=filippo.io; h= mime-version:message-id:date:from:to:subject:content-type; s= fm1; bh=pudGjTbg1M5n1eJIFRcKUXii8Df/Wm3lbRLsZpkzxSg=; b=j8Ca7cYR AbZ7LWaTYRnjALI/20coVIJ4e20Xpe34XH7z2qjROHoHm2K1qWm+FC4pyV6+5PrU JVLMnvHGObKA5dMyaXYwJWQP/nvbmLfcNYLM+1bV4Tgfm5vt+AiEmQPIqBSsgeeD ek8AhOw0cjrzx9b31l5ocZRTU0WvH7qwkbStlLVhLmD/PJODrZCDT0klIAmIuhfi kx0FCPeGIN9F5iOv5sDp8cFIs3oJHcAyOXeB1H5atTtoAE90msO4Rsk4yZM0QL+k Ao+S680MsFEr9vx3Yha2mGys1KPPsjkcl9nHH2G8o+of5Ezd5ItTRj1j3ozAwio/ 1ZGFnsER64W5hA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=pudGjTbg1M5n1eJIFRcKUXii8Df/W m3lbRLsZpkzxSg=; b=DAPNoM6xwgcN1QaiqUejl8Kl+zOz9ERgD+vRGex8BpJTk MjUwwhwLav/Wnrl07Un7Re4cEkHB5xpwV4PkttOSFnv8JATtMQaS5GjjmRoMgDBH XHlQhKVAQgLTd43PrPPUWtneB1lXS2HQu4aZw+3dojoFDyg2p8UuoJlSQzI7a7S/ yua/9K+/MgvMyNXvudi5v8Ovh2kyuRDYwrJJ7oCcPQTzOEJwLXUD1jQVKCgqyWF/ gTvSdNNuDlXHLICQOn58FEexny/sALWhmxvVpJWN0fM8yK6/y1m5oFnSgpaDdueC rWXUxSToBW8Oj7aLlk56qSGwzsBC8dw+oDnXBe4Hg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrledugddugeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsehttdertd erredtnecuhfhrohhmpedfhfhilhhiphhpohcugggrlhhsohhruggrfdcuoehfihhlihhp phhosehmlhdrfhhilhhiphhpohdrihhoqeenucffohhmrghinhepghhithhhuhgsrdgtoh hmpdhkohgsohhlrdhiohenucfrrghrrghmpehmrghilhhfrhhomhepfhhilhhiphhpohes mhhlrdhfihhlihhpphhordhiohenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 12D4CC200A4; Mon, 29 Jul 2019 15:52:14 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-736-gdfb8e44-fmstable-20190718v2 Mime-Version: 1.0 Message-Id: <5dfec78c-9a41-4e01-8834-ec0178f1ac9d@www.fastmail.com> Date: Mon, 29 Jul 2019 21:49:57 +0200 From: "Filippo Valsorda" To: freebsd-arm@freebsd.org Subject: PWM fan control on Helios4 (Marvell ARMADA 388) Content-Type: text/plain X-Rspamd-Queue-Id: 095366A1FC X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=filippo.io header.s=fm1 header.b=j8Ca7cYR; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=DAPNoM6x; dmarc=pass (policy=none) header.from=ml.filippo.io; spf=pass (mx1.freebsd.org: domain of filippo@ml.filippo.io designates 64.147.123.24 as permitted sender) smtp.mailfrom=filippo@ml.filippo.io X-Spamd-Result: default: False [-6.56 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; R_DKIM_ALLOW(-0.20)[filippo.io:s=fm1,messagingengine.com:s=fm3]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.24]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[filippo.io:+,messagingengine.com:+]; DMARC_POLICY_ALLOW(-0.50)[ml.filippo.io,none]; MX_GOOD(-0.01)[in2-smtp.messagingengine.com,in1-smtp.messagingengine.com,in2-smtp.messagingengine.com,in1-smtp.messagingengine.com,in2-smtp.messagingengine.com,in1-smtp.messagingengine.com]; NEURAL_HAM_SHORT(-0.99)[-0.987,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:11403, ipnet:64.147.123.0/24, country:US]; IP_SCORE(-3.48)[ip: (-9.77), ipnet: 64.147.123.0/24(-4.88), asn: 11403(-2.70), country: US(-0.05)]; MID_RHS_WWW(0.50)[]; RCVD_IN_DNSWL_LOW(-0.10)[24.123.147.64.list.dnswl.org : 127.0.5.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: Mon, 29 Jul 2019 19:52:24 -0000 I am running FreeBSD 12.0-GENERIC-350203 on the Helios4, a Marvell ARMADA 388 board. The device tree has two PWM GPIO fans https://github.com/Artox/crochet/blob/4d40896f182ad704e23dd55c31290f5859145483/board/Clearfog/files/armada-388-helios4.dts#L133-L141 but it doesn't look like the OS can see them at all, and they spin at full speed. Here's the full sysctl. https://gist.github.com/FiloSottile/5a44f2fd0bacb44b4120b1f5c6828583 Interestingly, the Linux DTS has different pwms parameters, but I couldn't find documentation on what they are. https://github.com/torvalds/linux/blob/2a11c76e5301dddefcb618dac04f74e6314df6bc/arch/arm/boot/dts/armada-388-helios4.dts#L123 The Helios4 PWM circuits seem very well documented, at least. https://wiki.kobol.io/pwm/ I would like to be able to slow the fans down. Runtime changes or adaptive behavior are a plus, but I'd be also happy with setting them at a fixed duty cycle. What docs should I look at? Has anyone tried this? What are my options, short of a hardware controller? Thank you, Filippo (Please keep me CC'd.) From owner-freebsd-arm@freebsd.org Mon Jul 29 22:01:18 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 EBA8CB78D5 for ; Mon, 29 Jul 2019 22:01:18 +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 499396FAED for ; Mon, 29 Jul 2019 22:01:18 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1564437671; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=tP51wPRY7u3awk7T/YO/ki7t+kEszOp5nnZeZHZMhD/WXJPBaP547OHltIp2IoNEP0YjzegYCtmlC WLrqjW0UkYR6oZtS8XN7kY1/p1Xx5vMY7zRSS3bKPTqRk5Sqt2brfQbfJEOjFPmYOcz3fGlotF1XUB LeWkazaQLcnkoyZ+Ri8LRar1AWuUKcBr7wNEzrKDAqAWM+gF9fgtcHDWsllXayt89x/m5Z0AQt9e5m 3o2ZKM80crIrTFun90MHG17KAmL+LgtMRICic3CZ/JlimZXAM0Rk0ngbjzlrMhY2QUSdugZs+0ISG0 q0tu5fUC2pYbx2gDI3kJYH1kastEVGw== 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=KgvKllkGYGJdKkFER0TiA6vI3+EKd6VZIWDpyugkwoA=; b=aReS1+UakfeDfD9rvCWQCwfOT/KClygsNAJbeiCR8WM7n/07Z52NQUAGYIzBc3JurXuWuNJjWfwPm 7BzwBHI5sDLSiM20LsThJPOrnUD/hhsiOzYZ6dMWeoxcn33JnWQBI7kXBq6gQ1cWL6VKVS2gDl0s86 Dq5qggKj67ipEMV94lj3He+CBQeHJ08GZha27LDuyU2tQ5QscknD8gm9p0ihbrO80FHM5t8ehlf4v5 i6BjoNOGsXWUxKMVzVoAdZ/9palG5Lur94Mr0JJg/sDmILAODaMRgLkUvf9aZuBqEPOffj1lX44fLc ibmRQ7f7408dEMbXrKXIdfoH+zShByA== 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=KgvKllkGYGJdKkFER0TiA6vI3+EKd6VZIWDpyugkwoA=; b=NM81pHSLg8s0daNHVHTdxjA/3iUMyqXNYlxU/2jdd6NOLgemAawAU5X7OKFTSMDCCsu4RS5u9qeOe LkXem5yrea5WkDCplAT/YaIW5+AjtgUo12CMjTuWUPa9DbIP+pI+FexEqx2MULL1EvbcU76Nlz/VQ+ pJBBjqkVEgKDGu9PAuRerHtWc3gnNTrh8It8306IAeK7xWSVCy3dCsLW46cgaJJ7ae3Vg9ONMBZ57G Gh443jD0j6rDn7mtMbnS7z0U8B0UZjRsm3J8+XtcgJYR6M5N00ZAye9hzRUC4G45ruPw9Ddo+IUJn/ SvHrq3ZmqFgEeaKgP9dWVCzveRfhsvA== X-MHO-RoutePath: aGlwcGll X-MHO-User: 5ed4ba6b-b24c-11e9-b679-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 5ed4ba6b-b24c-11e9-b679-cdd75d6ce7a8; Mon, 29 Jul 2019 22:01:10 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x6TM18Ld090741; Mon, 29 Jul 2019 16:01:08 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <8d00e4a213c93826c3e4d25c58126d22ab20fd33.camel@freebsd.org> Subject: Re: PWM fan control on Helios4 (Marvell ARMADA 388) From: Ian Lepore To: Filippo Valsorda , freebsd-arm@freebsd.org Date: Mon, 29 Jul 2019 16:01:08 -0600 In-Reply-To: <5dfec78c-9a41-4e01-8834-ec0178f1ac9d@www.fastmail.com> References: <5dfec78c-9a41-4e01-8834-ec0178f1ac9d@www.fastmail.com> 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: 499396FAED X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; NEURAL_HAM_SHORT(-0.99)[-0.989,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, 29 Jul 2019 22:01:19 -0000 On Mon, 2019-07-29 at 21:49 +0200, Filippo Valsorda wrote: > I am running FreeBSD 12.0-GENERIC-350203 on the Helios4, a Marvell > ARMADA 388 board. > > The device tree has two PWM GPIO fans > > https://github.com/Artox/crochet/blob/4d40896f182ad704e23dd55c31290f5859145483/board/Clearfog/files/armada-388-helios4.dts#L133-L141 > > but it doesn't look like the OS can see them at all, and they spin at > full speed. Here's the full sysctl. > > https://gist.github.com/FiloSottile/5a44f2fd0bacb44b4120b1f5c6828583 > > Interestingly, the Linux DTS has different pwms parameters, but I > couldn't find documentation on what they are. > > https://github.com/torvalds/linux/blob/2a11c76e5301dddefcb618dac04f74e6314df6bc/arch/arm/boot/dts/armada-388-helios4.dts#L123 > > The Helios4 PWM circuits seem very well documented, at least. > > https://wiki.kobol.io/pwm/ > > I would like to be able to slow the fans down. Runtime changes or > adaptive behavior are a plus, but I'd be also happy with setting them > at > a fixed duty cycle. > > What docs should I look at? Has anyone tried this? What are my > options, > short of a hardware controller? > > Thank you, > Filippo > > (Please keep me CC'd.) It looks like the news is mostly bad... based on that dts source (and what's in our tree from the latest import), the pwm-fan stuff relies on the marvell gpio driver being able to use the hardware's "blink mode" as a sort of poor man's PWM controller. It doesn't look like the freebsd marvell gpio driver has any code to support that (probably since it hasn't been touched by anyone since Sheevaplug was leading- edge hardware). I just had a quick look at the reference manual for the 388 SOC, and it looks like adding PWM support to the gpio driver would be more than trivial, and less than rocket science. It looks like it would be fun, but I don't have any hardware for testing it if I were to try. If the gpio driver did pwm, then the next problem is actually controlling fans with it. You could easily use the pwm(8) command line utility to manually control them. It would also be possible to rig up some userland scripting to periodically query temperature and control the fans from userland. Doing all that properly in-kernel would take a bunch more work that we have little or no current driver support for. -- Ian From owner-freebsd-arm@freebsd.org Tue Jul 30 23:46: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 03A44B0234 for ; Tue, 30 Jul 2019 23:46:16 +0000 (UTC) (envelope-from kayasaman@optiplex-networks.com) Received: from x-ray.optiplex-networks.com (mail.optiplex-networks.com [212.159.80.20]) (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 175DF86411 for ; Tue, 30 Jul 2019 23:46:14 +0000 (UTC) (envelope-from kayasaman@optiplex-networks.com) Received: from localhost (localhost [127.0.0.1]) by x-ray.optiplex-networks.com (Postfix) with ESMTP id 8B3437210E3 for ; Wed, 31 Jul 2019 00:46:13 +0100 (BST) Received: from x-ray.optiplex-networks.com ([127.0.0.1]) by localhost (x-ray.optiplex-networks.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id duBNCBq3FARH for ; Wed, 31 Jul 2019 00:46:13 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by x-ray.optiplex-networks.com (Postfix) with ESMTP id 5FC3172645A for ; Wed, 31 Jul 2019 00:46:13 +0100 (BST) X-Virus-Scanned: amavisd-new at x-ray.optiplex-networks.com Received: from x-ray.optiplex-networks.com ([127.0.0.1]) by localhost (x-ray.optiplex-networks.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DA3gNkeT3b4M for ; Wed, 31 Jul 2019 00:46:13 +0100 (BST) Received: from x220.optiplex-networks.com (unknown [192.168.0.195]) by x-ray.optiplex-networks.com (Postfix) with ESMTPSA id 345B57210E3 for ; Wed, 31 Jul 2019 00:46:13 +0100 (BST) To: "freebsd-arm@freebsd.org" From: Kaya Saman Subject: Pine64-LTS overlays for uart ports fixed! Message-ID: <5f30c425-60c6-d54a-9593-2584bcf25925@optiplex-networks.com> Date: Wed, 31 Jul 2019 00:46:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 175DF86411 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of kayasaman@optiplex-networks.com designates 212.159.80.20 as permitted sender) smtp.mailfrom=kayasaman@optiplex-networks.com X-Spamd-Result: default: False [-6.81 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[6]; 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]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[optiplex-networks.com]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_TLS_LAST(0.00)[]; MX_GOOD(-0.01)[mail.optiplex-networks.com]; NEURAL_HAM_SHORT(-0.91)[-0.905,0]; SUBJECT_ENDS_EXCLAIM(0.00)[]; TO_DN_EQ_ADDR_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6871, ipnet:212.159.64.0/18, country:GB]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-3.60)[ip: (-9.53), ipnet: 212.159.64.0/18(-4.77), asn: 6871(-3.60), country: GB(-0.08)] 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, 30 Jul 2019 23:46:16 -0000 Hi guys, just wanted to say that I managed to fix the overlay issue for the uart ports. I just updated my bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239390 So, thanks to everyone who provided assistance and especially Milan for the introduction to the 'overlay' system and the dtso file :-) Just need to figure out why PPS isn't working now, my GPS receiver is sending the information so it definitely is a system config issue - either wrong pin or something in the OS... (still looking into it). Also needing a driver in lcdproc for my Newhaven displays and after that the project will be perfect :-) :-) :-) Best Regards, Kaya From owner-freebsd-arm@freebsd.org Wed Jul 31 00:42:55 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 2E8C1B156B for ; Wed, 31 Jul 2019 00:42:55 +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 7BCC587F97 for ; Wed, 31 Jul 2019 00:42:54 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1564533767; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=lWme49jQIKjOpbuFd1wRgZZJjaCxUvEfkbYfP+2HsJnrcW4Ng8r16KxdbIJ+g0FzarFKd7eLn+s2f Y5rTDezOIPI16qXMxB5RYyL933nhqgAcLe8b7lXgMhtV0HkO4U3ytajeMBNVC0ai63cBf7luR+cHyv 3nSMvtAp445i80K0rJkh7Zw2+js6c82vUwCG/ChAxVsAnqcE9DwNe71NpymZglKlpICjWCHn2+/BtN SzivleusS6PdfZJzOOf5BqJC4kkReV3DgQtM/e6kG3BqtO2f0fDmj2up1yx+NO2/UXIsKw8oaoDjr9 TG3Nq2+fLOMx84sSqDjJkNys1D7XYpA== 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=LNQ9+2ko/DHOHboKJYeobzgYE2pKLZxE32KcXwPalgw=; b=ItBTnNNxxo9fvLCtpQ8LQ7IB2QG0dNA/6i5DlDSs/CFH3PDSU0KZ6bmqzR5n18Me/ho5DAqZRWTld VuBKr8IEYw2A1vvM5MnJc0QZLX3DOKN7pY7jptEZkuNRVTamMYmu5RYxZtCVaOe23W7TLnCEduyQ1Z 1ZsRRM5KVX5SKx7VvUPYPLi/i82o37d/RMcYpGSvfGavm6soCbYH9EmHjYkrHaUQ0f/6dBWGXU0aQR 3XrkQSj0re4BZ8v4zz/Pgo3wclDWwZHst/l+e3GS0AcvkvzX7Xno3GhM3ERPPnzrHdXBiwzrYZ/5IU a2VR4vjn89CZZLIbQUkIDyntUPQcDEg== 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:to:from:subject:message-id:from; bh=LNQ9+2ko/DHOHboKJYeobzgYE2pKLZxE32KcXwPalgw=; b=vq4fR7F5zkzgT6cErWUwEU/YFWAZU0jPh7NjVsSzKBfzigPUnn5ZI0fTeF0ucr8Kl6/7B+2wKSM6u XFXfPpvPotGJxTqoFVEhn0NJDp+WLLvbvjWsWrQOPoMR9KmfJwlOw5uXPi1QvAY20ZtS1eO8cUCavE n+ijx69/y1aaW19lWe2+ZuygmHXvgdygRsx1ZJtPGv0gBVWXcNZnO6DC8yW8vVXoqEHXFvvhEXrQ9s wsrPiB0DUC0ihJ0HHt/tWXcYjbNCg2MkNpP8HSO+CatPtiidTer4rTkYmv4ZWRGJjNutTty5Zmxt+f Vfa9c0zMAYvs1K2/RNfkoXTiVg66qBg== X-MHO-RoutePath: aGlwcGll X-MHO-User: 1bdd2188-b32c-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 1bdd2188-b32c-11e9-85ec-13b9aae3a1d2; Wed, 31 Jul 2019 00:42:45 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x6V0ghEs094852; Tue, 30 Jul 2019 18:42:43 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: Pine64-LTS overlays for uart ports fixed! From: Ian Lepore To: Kaya Saman , "freebsd-arm@freebsd.org" Date: Tue, 30 Jul 2019 18:42:43 -0600 In-Reply-To: <5f30c425-60c6-d54a-9593-2584bcf25925@optiplex-networks.com> References: <5f30c425-60c6-d54a-9593-2584bcf25925@optiplex-networks.com> 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: 7BCC587F97 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.99)[-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: Wed, 31 Jul 2019 00:42:55 -0000 On Wed, 2019-07-31 at 00:46 +0100, Kaya Saman wrote: > Hi guys, > > > just wanted to say that I managed to fix the overlay issue for the uart > ports. I just updated my bug report: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239390 > > > So, thanks to everyone who provided assistance and especially Milan for > the introduction to the 'overlay' system and the dtso file :-) > > > Just need to figure out why PPS isn't working now, my GPS receiver is > sending the information so it definitely is a system config issue - > either wrong pin or something in the OS... (still looking into it). Also > needing a driver in lcdproc for my Newhaven displays and after that the > project will be perfect :-) :-) :-) > > > Best Regards, > > > Kaya > > Is the GPS receiver delivering the pps signal on one of the uart pins such as cts? If it's using cts, you probably need this change to your overlay: --- sun50i-a64-uart4.dts.orig 2019-07-30 18:35:19.188762000 -0600 +++ sun50i-a64-uart4.dts 2019-07-30 18:37:02.015479000 -0600 @@ -30,7 +30,7 @@ target = <&uart4>; __overlay__ { pinctrl-names = "default"; - pinctrl-0 = <&uart4_pins>; + pinctrl-0 = <&uart4_pins &uart4_rts_cts_pins>; status = "okay"; }; }; You may also need to set sysctl dev.uart.4.pps_mode=1 for CTS, in /etc/sysctl.conf. If it's using some other pin such as RI or CD, there is no pre-written pinctrl entry for it in those overlays you found, and some more research into how to add the right pinctrl nodes will be needed. -- Ian From owner-freebsd-arm@freebsd.org Wed Jul 31 13:33: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 75571BEBB3 for ; Wed, 31 Jul 2019 13:33:40 +0000 (UTC) (envelope-from kayasaman@optiplex-networks.com) Received: from x-ray.optiplex-networks.com (mail.optiplex-networks.com [212.159.80.20]) (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 45zDsH4lSmz3Ld1; Wed, 31 Jul 2019 13:33:39 +0000 (UTC) (envelope-from kayasaman@optiplex-networks.com) Received: from localhost (localhost [127.0.0.1]) by x-ray.optiplex-networks.com (Postfix) with ESMTP id 9EB5F725F59; Wed, 31 Jul 2019 14:33:37 +0100 (BST) Received: from x-ray.optiplex-networks.com ([127.0.0.1]) by localhost (x-ray.optiplex-networks.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 5lcZBCQupdqQ; Wed, 31 Jul 2019 14:33:37 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by x-ray.optiplex-networks.com (Postfix) with ESMTP id 5FBF5726464; Wed, 31 Jul 2019 14:33:37 +0100 (BST) X-Virus-Scanned: amavisd-new at x-ray.optiplex-networks.com Received: from x-ray.optiplex-networks.com ([127.0.0.1]) by localhost (x-ray.optiplex-networks.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9rpaGh_TTvtg; Wed, 31 Jul 2019 14:33:37 +0100 (BST) Received: from x220.optiplex-networks.com (unknown [192.168.0.195]) by x-ray.optiplex-networks.com (Postfix) with ESMTPSA id 4D260725F59; Wed, 31 Jul 2019 14:33:37 +0100 (BST) Subject: Re: Pine64-LTS overlays for uart ports fixed! To: Ian Lepore , "freebsd-arm@freebsd.org" References: <5f30c425-60c6-d54a-9593-2584bcf25925@optiplex-networks.com> From: Kaya Saman Message-ID: <09afae63-3583-46bd-8911-82a0f0a3185f@optiplex-networks.com> Date: Wed, 31 Jul 2019 14:33:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 45zDsH4lSmz3Ld1 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of kayasaman@optiplex-networks.com designates 212.159.80.20 as permitted sender) smtp.mailfrom=kayasaman@optiplex-networks.com X-Spamd-Result: default: False [-4.89 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_FIVE(0.00)[6]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[optiplex-networks.com]; IP_SCORE(-3.60)[ip: (-9.53), ipnet: 212.159.64.0/18(-4.77), asn: 6871(-3.61), country: GB(-0.08)]; MX_GOOD(-0.01)[cached: mail.optiplex-networks.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.98)[-0.978,0]; SUBJECT_ENDS_EXCLAIM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6871, ipnet:212.159.64.0/18, country:GB]; MID_RHS_MATCH_FROM(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: Wed, 31 Jul 2019 13:33:40 -0000 On 7/31/19 1:42 AM, Ian Lepore wrote: > On Wed, 2019-07-31 at 00:46 +0100, Kaya Saman wrote: >> Hi guys, >> >> >> just wanted to say that I managed to fix the overlay issue for the uar= t >> ports. I just updated my bug report: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D239390 >> >> >> So, thanks to everyone who provided assistance and especially Milan fo= r >> the introduction to the 'overlay' system and the dtso file :-) >> >> >> Just need to figure out why PPS isn't working now, my GPS receiver is >> sending the information so it definitely is a system config issue - >> either wrong pin or something in the OS... (still looking into it). Al= so >> needing a driver in lcdproc for my Newhaven displays and after that th= e >> project will be perfect :-) :-) :-) >> >> >> Best Regards, >> >> >> Kaya >> >> > Is the GPS receiver delivering the pps signal on one of the uart pins > such as cts? If it's using cts, you probably need this change to your > overlay: > > --- sun50i-a64-uart4.dts.orig 2019-07-30 18:35:19.188762000 -0600 > +++ sun50i-a64-uart4.dts 2019-07-30 18:37:02.015479000 -0600 > @@ -30,7 +30,7 @@ > target =3D <&uart4>; > __overlay__ { > pinctrl-names =3D "default"; > - pinctrl-0 =3D <&uart4_pins>; > + pinctrl-0 =3D <&uart4_pins &uart4_rts_cts_pins>; > status =3D "okay"; > }; > }; > > You may also need to set sysctl dev.uart.4.pps_mode=3D1 for CTS, in > /etc/sysctl.conf. > > If it's using some other pin such as RI or CD, there is no pre-written > pinctrl entry for it in those overlays you found, and some more > research into how to add the right pinctrl nodes will be needed. > > -- Ian > Bingo!!! :-) :-) Thank you so much Ian..... I am seeing this: gpsd:PROG: PPS:/dev/gps1 Assert cycle:=C2=A0 999973, duration:=C2=A0 7999= 77 @=C2=A0=20 1564579823.472659791 gpsd:PROG: PPS:/dev/gps1 Assert rejected missing last_fixtime Perfect ;-) I think I need to add pps_mode=3D0x11 or 17 in dec. as the pulse is inver= ted. This setup was working previously using a Prolific Serial to USB adapter=20 for testing purposes as of course the USB introduces high latency. Time for testing and analysis :-) Best Regards, Kaya From owner-freebsd-arm@freebsd.org Wed Jul 31 13:56:07 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 656E9BF222 for ; Wed, 31 Jul 2019 13:56:07 +0000 (UTC) (envelope-from 0102016c4851021b-7745c3b4-fa1b-4d50-839c-2979eccb2676-000000@eu-west-1.amazonses.com) Received: from a4-6.smtp-out.eu-west-1.amazonses.com (a4-6.smtp-out.eu-west-1.amazonses.com [54.240.4.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 45zFMB0pCgz3Mrd for ; Wed, 31 Jul 2019 13:56:05 +0000 (UTC) (envelope-from 0102016c4851021b-7745c3b4-fa1b-4d50-839c-2979eccb2676-000000@eu-west-1.amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=uwfrvhlat3drqdfg3hx77nynjjjdh6z6; d=sitaridev.co.za; t=1564581364; h=Message-ID:Date:Subject:From:Reply-To:To:MIME-Version:Content-Type:List-Unsubscribe:List-Id; bh=Vgq5xpDc+rBQwFSQQlRG1Reh0pM0jpMwXagSVo+XroY=; b=SFS3/3Nm3ltpmR3LhtGufvS/jBn1x0PJjJ/BECFwau+fxhNt3E0dsPudXOHABcet nvI9mx1EmBEOwiZgBJdXGsqjPKtMDkksgBxvEFDlwSgpNMjO36LZJvnWdoCSfU1PgzB PM+irS06E1CzoFGEPKKwzO+EHcJfqunLprRLdJWs= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ihchhvubuqgjsxyuhssfvqohv7z3u4hn; d=amazonses.com; t=1564581364; h=Message-ID:Date:Subject:From:Reply-To:To:MIME-Version:Content-Type:List-Unsubscribe:List-Id:Feedback-ID; bh=Vgq5xpDc+rBQwFSQQlRG1Reh0pM0jpMwXagSVo+XroY=; b=d3jsfXNSW8zNnQP2M18aSlYNY5CnIAUu7a03wNuMb90Cvjz+hudtcTU4QMUuNPal /9E0+cNh+wsZ98zopdhnsvaXIvLuk2LDHAAo6ZbsZvMm0zEd5az+ti2c1mdGmxQdPA7 0gFtsu3840Ni8uqVMFwa7RvMAUJGFcXItl+iiTw0= Message-ID: <0102016c4851021b-7745c3b4-fa1b-4d50-839c-2979eccb2676-000000@eu-west-1.amazonses.com> Date: Wed, 31 Jul 2019 13:56:04 +0000 Subject: Apartments | Luxury and Convenience | Waterford Place From: Sitari Country Estate | Somerset West Reply-To: Sitari Country Estate | Somerset West To: "freebsd-arm@freebsd.org" MIME-Version: 1.0 X-Sender: schelderberg@sitaridev.co.za X-Report-Abuse: Please report abuse for this campaign here: http://leopardmail.co.za/index.php/campaigns/lf883gccxo28a/report-abuse/kr5611ywn5335/zn951cqdvg0b8 X-Receiver: freebsd-arm@freebsd.org X-Ntog-Tracking-Did: 0 X-Ntog-Subscriber-Uid: zn951cqdvg0b8 X-Ntog-Mailer: SwiftMailer - 5.4.x X-Ntog-EBS: http://leopardmail.co.za/index.php/lists/block-address X-Ntog-Delivery-Sid: 1 X-Ntog-Customer-Uid: qy253wb5dy193 X-Ntog-Customer-Gid: 1 X-Ntog-Campaign-Uid: lf883gccxo28a Precedence: bulk Feedback-ID: 1.eu-west-1.uvn48qXFNfbBCSq27QjYopu03+ZevnFjz7NsiwWAkk8=:AmazonSES X-SES-Outgoing: 2019.07.31-54.240.4.6 X-Rspamd-Queue-Id: 45zFMB0pCgz3Mrd X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=sitaridev.co.za header.s=uwfrvhlat3drqdfg3hx77nynjjjdh6z6 header.b=SFS3/3Nm; dkim=pass header.d=amazonses.com header.s=ihchhvubuqgjsxyuhssfvqohv7z3u4hn header.b=d3jsfXNS; dmarc=none; spf=pass (mx1.freebsd.org: domain of 0102016c4851021b-7745c3b4-fa1b-4d50-839c-2979eccb2676-000000@eu-west-1.amazonses.com designates 54.240.4.6 as permitted sender) smtp.mailfrom=0102016c4851021b-7745c3b4-fa1b-4d50-839c-2979eccb2676-000000@eu-west-1.amazonses.com X-Spamd-Result: default: False [-4.04 / 15.00]; HAS_REPLYTO(0.00)[reply@sitaridev.co.za]; R_SPF_ALLOW(-0.20)[+ip4:54.240.0.0/18]; REPLYTO_DN_EQ_FROM_DN(0.00)[]; DKIM_TRACE(0.00)[sitaridev.co.za:+,amazonses.com:+]; MX_GOOD(-0.01)[cached: feedback-smtp.eu-west-1.amazonses.com]; NEURAL_HAM_SHORT(-0.98)[-0.980,0]; MAILLIST(-0.10)[generic]; FORGED_SENDER(0.00)[schelderberg@sitaridev.co.za,0102016c4851021b-7745c3b4-fa1b-4d50-839c-2979eccb2676-000000@eu-west-1.amazonses.com]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.44)[ip: (-9.35), ipnet: 54.240.0.0/21(-1.44), asn: 16509(-1.34), country: US(-0.05)]; ASN(0.00)[asn:16509, ipnet:54.240.0.0/21, country:US]; FROM_NEQ_ENVFROM(0.00)[schelderberg@sitaridev.co.za,0102016c4851021b-7745c3b4-fa1b-4d50-839c-2979eccb2676-000000@eu-west-1.amazonses.com]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[sitaridev.co.za:s=uwfrvhlat3drqdfg3hx77nynjjjdh6z6,amazonses.com:s=ihchhvubuqgjsxyuhssfvqohv7z3u4hn]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PRECEDENCE_BULK(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[sitaridev.co.za]; REPLYTO_DOM_EQ_FROM_DOM(0.00)[]; HAS_LIST_UNSUB(-0.01)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[6.4.240.54.list.dnswl.org : 127.0.15.0]; TO_DN_EQ_ADDR_ALL(0.00)[]; FORGED_SENDER_MAILLIST(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 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 13:56:07 -0000 NEW DEVELOPMENT =E2=80=A2 HELDERBERG WATERFORD PLACE LUXURY APARTMENTS= =C2=A0 Enjoy a Unique Combination of Luxury and Convenience =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Now Selling from R 1 399 000 (Includes T= ransfer Duty) =C2=A0 =C2=A0 CALL ME BACK http://leopardmail.co.za/i= ndex.php/campaigns/lf883gccxo28a/track-url/zn951cqdvg0b8/61806851854ecd954c= af5b251a60dde4a0c55c86 =C2=A0 GET SALES PACK /mailtoreplys@sitaridev.= co.za?subject=3DSend%20me%20the%20Waterford%20Place%20Sales%20Pack =C2= =A0 =C2=A0 =C2=A0 =C2=A0 VISIT WEBSITE http://leopardmail.co.za/i= ndex.php/campaigns/lf883gccxo28a/track-url/zn951cqdvg0b8/99963867fd7f355c5f= 78ed69a1030ba3f2cca805 =C2=A0 =C2=A0 Click here if you're not able to= view this mailer http://leopardmail.co.za/index.php/campaigns/lf883gccxo= 28a/track-url/zn951cqdvg0b8/7012fc63dc8e1e38cee87e09bb7e102c06844ecf This= email was sent to freebsd-arm@freebsd.org on=C2=A007/31/2019 from Sitari= Country Estate If the email was send in error please unsubscribe here = -=C2=A0=C2=A0Unsubscribe http://leopardmail.co.za/index.php/lists/kr5611y= wn5335/unsubscribe/zn951cqdvg0b8/lf883gccxo28a ~ Report email as unsolici= ted http://leopardmail.co.za/index.php/campaigns/lf883gccxo28a/track-url/= zn951cqdvg0b8/885c67839af868eb076f253478b4ab6288f5cf5d Leopard Mail is an= email-marketing service that serves companies of all shapes and sizes.= With several users/companies sending campaigns to hundreds of millions= of recipients, we're bound to get abuse reports.=C2=A0 We take abuse rep= orts seriously, if you believe a customer is sending unsolicited and or s= pam email, please report abuse immediately HERE http://leopardmail.co.za/= index.php/campaigns/lf883gccxo28a/track-url/zn951cqdvg0b8/885c67839af868eb0= 76f253478b4ab6288f5cf5d From owner-freebsd-arm@freebsd.org Wed Jul 31 14:06:34 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 579EFBF51F for ; Wed, 31 Jul 2019 14:06:34 +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 45zFbF6wwsz3Nb6 for ; Wed, 31 Jul 2019 14:06:33 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1564581992; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=uUSdWrzPMMOPIIHyKPH09vd6qomPzjwHFpdai3Ngh2zNJIbsgjzGt13HmmdZn0zjKpIpTXWdP+oqv 1SrFO7FxEQ13BIKNXZuwtOo3K5PYCFYbChgD5Bbod+X2/b+8y+dMP4bi+eHX+kacgu5JBORfA665s0 2jMDZPKxE1Dxt/I+ubjp57NgK4onDEVO0hLx/YeOgQb9Z0UZcSiyro9w4mxAB19+bWoGLzTrok9fqL ZHlZ/ljaBwTliK8N4BPFlq4E0KNjnnsPClC/tA1BneNbqODJAn8h1SAdxEb4SD01CA3fxmFBNVOP1k Is6mL0QW5ho60UawD7glDJ2wBSa85JA== 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=IY1rDdS6/7YQpqg1Hlfr+1+YUioYx7MqSO3B/2sQCiY=; b=pjOYp/9JXMJ0NUSQdJ+PJ83qOmXiZoX7tVmRKxUYZCJML1AGmIL/TxxbVHOwQ2BgFWAwZomAWvwMl h7Gd9FBD1YGQJf4pW2zg+NBkjglZst+WyWJ7FMiIpXAH8EZT6JhJD2E0sl6K7P22keJ3m7RLdl0AqZ WxBN1DtqkVdFi03Q0v5Mim3LlAViTWcmCMCZG8Vr7pcxN5VTAK7kDH95QAwWFvzeXn5a3BiLDoQINE miip1vsM8rAch5oKwcqKDhvrjYId9bXZjQR+86l53K3IkKyXnAsk8ZdB61a9gjdyRNcGnuT2puDpif y4CvI4b+6K2Jo+oSvTjhfWVSXm9VrRQ== 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:to:from:subject:message-id:from; bh=IY1rDdS6/7YQpqg1Hlfr+1+YUioYx7MqSO3B/2sQCiY=; b=Ot/+FTX6eCfLa7M6c417ODMPmxp9ukjirmPzYFqb0gpC1gXopPZzFGHnJT7IlsoBHRf5Qg80O/DJs 4T2Ji0UVjKK5m8BvQ9VlOJ+mw8Nm0g023tBqlzDuferc38Waff8JA3ZPjybxHrSP/JMJk0/my0Blhr xR4eCQ0jj0Q145IG8KKbBjvs+v02p96qgW+94fANaH2RwLfFuvHKwkmAOTRi0r81ojQM8JjYBylTA+ YWAtnxckFt8U2I/P4JGFXAu/rOab05l4n/Tl3jdzD1sPQ5/FhVcbgkWvDs0nPj/aEac5v9FKOjdXre NKDgqPk4OYdSPgwVofG5AFrObv/WFxg== X-MHO-RoutePath: aGlwcGll X-MHO-User: 64bb1636-b39c-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 64bb1636-b39c-11e9-85ec-13b9aae3a1d2; Wed, 31 Jul 2019 14:06:31 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x6VE6TeH097151; Wed, 31 Jul 2019 08:06:29 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <2ab16425ac48bb7ff4365561b8959ee3eac50530.camel@freebsd.org> Subject: Re: Pine64-LTS overlays for uart ports fixed! From: Ian Lepore To: Kaya Saman , "freebsd-arm@freebsd.org" Date: Wed, 31 Jul 2019 08:06:29 -0600 In-Reply-To: <09afae63-3583-46bd-8911-82a0f0a3185f@optiplex-networks.com> References: <5f30c425-60c6-d54a-9593-2584bcf25925@optiplex-networks.com> <09afae63-3583-46bd-8911-82a0f0a3185f@optiplex-networks.com> 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: 45zFbF6wwsz3Nb6 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.20 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_SPAM_SHORT(0.20)[0.202,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: Wed, 31 Jul 2019 14:06:34 -0000 On Wed, 2019-07-31 at 14:33 +0100, Kaya Saman wrote: > On 7/31/19 1:42 AM, Ian Lepore wrote: > > On Wed, 2019-07-31 at 00:46 +0100, Kaya Saman wrote: > > > Hi guys, > > > > > > > > > just wanted to say that I managed to fix the overlay issue for > > > the uart > > > ports. I just updated my bug report: > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239390 > > > > > > > > > So, thanks to everyone who provided assistance and especially > > > Milan for > > > the introduction to the 'overlay' system and the dtso file :-) > > > > > > > > > Just need to figure out why PPS isn't working now, my GPS > > > receiver is > > > sending the information so it definitely is a system config issue > > > - > > > either wrong pin or something in the OS... (still looking into > > > it). Also > > > needing a driver in lcdproc for my Newhaven displays and after > > > that the > > > project will be perfect :-) :-) :-) > > > > > > > > > Best Regards, > > > > > > > > > Kaya > > > > > > > > > > Is the GPS receiver delivering the pps signal on one of the uart > > pins > > such as cts? If it's using cts, you probably need this change to > > your > > overlay: > > > > --- sun50i-a64-uart4.dts.orig 2019-07-30 18:35:19.188762000 > > -0600 > > +++ sun50i-a64-uart4.dts 2019-07-30 18:37:02.015479000 -0600 > > @@ -30,7 +30,7 @@ > > target = <&uart4>; > > __overlay__ { > > pinctrl-names = "default"; > > - pinctrl-0 = <&uart4_pins>; > > + pinctrl-0 = <&uart4_pins &uart4_rts_cts_pins>; > > status = "okay"; > > }; > > }; > > > > You may also need to set sysctl dev.uart.4.pps_mode=1 for CTS, in > > /etc/sysctl.conf. > > > > If it's using some other pin such as RI or CD, there is no pre- > > written > > pinctrl entry for it in those overlays you found, and some more > > research into how to add the right pinctrl nodes will be needed. > > > > -- Ian > > > > Bingo!!! :-) :-) > > > Thank you so much Ian..... > > > I am seeing this: > > gpsd:PROG: PPS:/dev/gps1 Assert cycle: 999973, duration: 799977 @ > 1564579823.472659791 > gpsd:PROG: PPS:/dev/gps1 Assert rejected missing last_fixtime > > > Perfect ;-) > > > I think I need to add pps_mode=0x11 or 17 in dec. as the pulse is > inverted. > > > This setup was working previously using a Prolific Serial to USB adapter > for testing purposes as of course the USB introduces high latency. > Actually, not so much as you'd think. I expected both high latency and a lot of jitter when using a usb-serial for PPS, and what I found was a fixed latency of less than a millisecond and jitter on the order of 60- 80 microseconds. Even trying to saturate the usb bus by doing continuous or bursty IO to a disk drive didn't noticibly increase the pps latency or jitter. I was pretty surprised. -- Ian From owner-freebsd-arm@freebsd.org Wed Jul 31 15:17: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 99B61A16C3 for ; Wed, 31 Jul 2019 15:17:46 +0000 (UTC) (envelope-from kayasaman@optiplex-networks.com) Received: from x-ray.optiplex-networks.com (mail.optiplex-networks.com [212.159.80.20]) (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 45zH9P3JPzz3x8M; Wed, 31 Jul 2019 15:17:45 +0000 (UTC) (envelope-from kayasaman@optiplex-networks.com) Received: from localhost (localhost [127.0.0.1]) by x-ray.optiplex-networks.com (Postfix) with ESMTP id 790637210E3; Wed, 31 Jul 2019 16:17:42 +0100 (BST) Received: from x-ray.optiplex-networks.com ([127.0.0.1]) by localhost (x-ray.optiplex-networks.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ap9xJewso0hu; Wed, 31 Jul 2019 16:17:42 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by x-ray.optiplex-networks.com (Postfix) with ESMTP id 28B15726464; Wed, 31 Jul 2019 16:17:42 +0100 (BST) X-Virus-Scanned: amavisd-new at x-ray.optiplex-networks.com Received: from x-ray.optiplex-networks.com ([127.0.0.1]) by localhost (x-ray.optiplex-networks.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id fkc-7vjudT5U; Wed, 31 Jul 2019 16:17:42 +0100 (BST) Received: from x220.optiplex-networks.com (unknown [192.168.0.195]) by x-ray.optiplex-networks.com (Postfix) with ESMTPSA id 0D8BA7210E3; Wed, 31 Jul 2019 16:17:42 +0100 (BST) Subject: Re: Pine64-LTS overlays for uart ports fixed! To: Ian Lepore , "freebsd-arm@freebsd.org" References: <5f30c425-60c6-d54a-9593-2584bcf25925@optiplex-networks.com> <09afae63-3583-46bd-8911-82a0f0a3185f@optiplex-networks.com> <2ab16425ac48bb7ff4365561b8959ee3eac50530.camel@freebsd.org> From: Kaya Saman Message-ID: <388e17e7-a277-9cd9-47ea-a38f10c7c741@optiplex-networks.com> Date: Wed, 31 Jul 2019 16:17:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <2ab16425ac48bb7ff4365561b8959ee3eac50530.camel@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 45zH9P3JPzz3x8M X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of kayasaman@optiplex-networks.com designates 212.159.80.20 as permitted sender) smtp.mailfrom=kayasaman@optiplex-networks.com X-Spamd-Result: default: False [-4.90 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_FIVE(0.00)[6]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[optiplex-networks.com]; IP_SCORE(-3.60)[ip: (-9.53), ipnet: 212.159.64.0/18(-4.77), asn: 6871(-3.61), country: GB(-0.08)]; MX_GOOD(-0.01)[cached: mail.optiplex-networks.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.99)[-0.993,0]; SUBJECT_ENDS_EXCLAIM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6871, ipnet:212.159.64.0/18, country:GB]; MID_RHS_MATCH_FROM(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: Wed, 31 Jul 2019 15:17:46 -0000 On 7/31/19 3:06 PM, Ian Lepore wrote: > On Wed, 2019-07-31 at 14:33 +0100, Kaya Saman wrote: >> On 7/31/19 1:42 AM, Ian Lepore wrote: >>> On Wed, 2019-07-31 at 00:46 +0100, Kaya Saman wrote: >>>> Hi guys, >>>> >>>> >>>> just wanted to say that I managed to fix the overlay issue for >>>> the uart >>>> ports. I just updated my bug report: >>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D239390 >>>> >>>> >>>> So, thanks to everyone who provided assistance and especially >>>> Milan for >>>> the introduction to the 'overlay' system and the dtso file :-) >>>> >>>> >>>> Just need to figure out why PPS isn't working now, my GPS >>>> receiver is >>>> sending the information so it definitely is a system config issue >>>> - >>>> either wrong pin or something in the OS... (still looking into >>>> it). Also >>>> needing a driver in lcdproc for my Newhaven displays and after >>>> that the >>>> project will be perfect :-) :-) :-) >>>> >>>> >>>> Best Regards, >>>> >>>> >>>> Kaya >>>> >>>> >>> Is the GPS receiver delivering the pps signal on one of the uart >>> pins >>> such as cts? If it's using cts, you probably need this change to >>> your >>> overlay: >>> >>> --- sun50i-a64-uart4.dts.orig 2019-07-30 18:35:19.188762000 >>> -0600 >>> +++ sun50i-a64-uart4.dts 2019-07-30 18:37:02.015479000 -0600 >>> @@ -30,7 +30,7 @@ >>> target =3D <&uart4>; >>> __overlay__ { >>> pinctrl-names =3D "default"; >>> - pinctrl-0 =3D <&uart4_pins>; >>> + pinctrl-0 =3D <&uart4_pins &uart4_rts_cts_pins>; >>> status =3D "okay"; >>> }; >>> }; >>> >>> You may also need to set sysctl dev.uart.4.pps_mode=3D1 for CTS, in >>> /etc/sysctl.conf. >>> >>> If it's using some other pin such as RI or CD, there is no pre- >>> written >>> pinctrl entry for it in those overlays you found, and some more >>> research into how to add the right pinctrl nodes will be needed. >>> >>> -- Ian >>> >> Bingo!!! :-) :-) >> >> >> Thank you so much Ian..... >> >> >> I am seeing this: >> >> gpsd:PROG: PPS:/dev/gps1 Assert cycle: 999973, duration: 799977 @ >> 1564579823.472659791 >> gpsd:PROG: PPS:/dev/gps1 Assert rejected missing last_fixtime >> >> >> Perfect ;-) >> >> >> I think I need to add pps_mode=3D0x11 or 17 in dec. as the pulse is >> inverted. >> >> >> This setup was working previously using a Prolific Serial to USB adapt= er >> for testing purposes as of course the USB introduces high latency. >> > Actually, not so much as you'd think. I expected both high latency and > a lot of jitter when using a usb-serial for PPS, and what I found was a > fixed latency of less than a millisecond and jitter on the order of 60- > 80 microseconds. Even trying to saturate the usb bus by doing > continuous or bursty IO to a disk drive didn't noticibly increase the > pps latency or jitter. I was pretty surprised. > > -- Ian > > That's very interesting! My finding was that the accuracy went from the 10's of uS using a=20 standard RS232 D-Sub port on one of my x64 systems to the 100's of uS=20 range when switching to the Pine64 and using the USB->Serial adapter. Looks like the PPS signal just kicked in: gpsd:PROG: KPPS:/dev/gps1 Clear cycle:=C2=A0 999974, duration:=C2=A0 7999= 81 @=C2=A0=20 1564585351.860177245 gpsd:PROG: PPS:/dev/gps1 Clear cycle:=C2=A0 999974, duration:=C2=A0 79998= 1 @=C2=A0=20 1564585351.860177245 gpsd:PROG: PPS:/dev/gps1 Clear rejected this second already handled gpsd:PROG: KPPS:/dev/gps1 assert=C2=A0 1564585352.060170121, sequence: 55= 43,=20 clear=C2=A0=C2=A0 1564585351.860177245, sequence: 5543 - using: assert gpsd:PROG: KPPS:/dev/gps1 Assert cycle:=C2=A0 999974, duration:=C2=A0 199= 992 @=C2=A0=20 1564585352.060170121 gpsd:PROG: PPS:/dev/gps1 Assert cycle:=C2=A0 999974, duration:=C2=A0 1999= 92 @=C2=A0=20 1564585352.060170121 gpsd:PROG: PPS:/dev/gps1 Assert rejected 1Hz trailing edge After stopping the gpsd service and restarting it's finding it difficult=20 to startup again. I attempted with dev.uart.4.pps_mode=3D0x21 for 'narrow= '=20 pulses even though 200ms-1 shouldn't be considered 'narrow'?? I'm guessin= g. Once I understand a little bit more about the behavior and quirks of the=20 setup I'll probably start looking at how to enable an input switch on a=20 GPIO pin then trying to get/write a driver for lcdproc and the Newhaven=20 display. The aim is to use the retractive mechanical switch to change=20 the LCD display from clock to GPS info.... Still lots of work to go but it's definitely a really fun project :-) Regards, Kaya From owner-freebsd-arm@freebsd.org Wed Jul 31 15:32:42 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 C7B77A1D0A for ; Wed, 31 Jul 2019 15:32:42 +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 45zHVf4KwPz3yCD for ; Wed, 31 Jul 2019 15:32:42 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1564587161; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=GsnOALfAfTaLBjFanqT39jVtimRBIOZf+yeMvAOnt2/gUa8Twm3mn2jAJQpxIC3AhH10SIdwjNwjP UxsQLpL4toFrDZHe0T0sbVnpqJvYA3EBtFTaeSGaIRIE4fTBY7tp8k/v8q7QB32sKTzIIzuDokJu+L bi/+VoBQfvQaxTiw2SAglJdy3hrIfwozv4maPwulV3zMvPeW8bSLQEJvsA/ctjJEUDqjVB80x4qFHK RUjec0POv7UgV6b1zRtot8vMpBpsJXwDjlR2ja2GLDO/eFLSaFwKyA5tyWhxRz8sk+f2mnJ+1aien8 w4r6Z1EHUiNmiBOMIwD7YxdlTSDRfVw== 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=Tjk3HnQX1BDv1C3qy8BA1krGLD+Itgm2tngXo87j8DU=; b=vOL6PEbXVAoxQCop4Lvm5A57IYRLvCy5eqXAak+ZDlNynN3b//7TDy9bm4euuuyDG53upeGP2vBvq zaan7VYH6KlBJUxlLHV9ypOGOrIpkNFWT2rNgpcZnbm/6bcTn5XKECx70Rh6tiBkVdX8ylBpl6newr 24HeTMTkZ60I9kZ988nGyW2p8DfkMSxPFM1c9DB0Fez9ajVJbiaWGae3ChgFcX74CYu7lJmZgL7YQa H5Z6jJ33CdOFwWHqMrDVx/PfglAptXIqzsipKnIVIodjOLAW989mh3MFnwXE55zVX+TA3TT7rxo3g/ Su+p/6YBVQeNpLolkCuzI3wZCk70IRA== 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:to:from:subject:message-id:from; bh=Tjk3HnQX1BDv1C3qy8BA1krGLD+Itgm2tngXo87j8DU=; b=JiZMZEUzXZoU4B4IrdNI56JRqzFIJWilQ98BWupv/APVudUgH7X/RQFgVpecg4E3pJoqVPYZP84Vy xmKK0BmM01QjwhOEhbfcFbr8lB66/mPSpOG+VrKzbgEBHg3qzI4brDaYF7Y66kI3IBx8UQjJkjvIIy Adxyk9jwyk2B902aFdtDZvMOUZMzaO+XnWkS0copnRVJ/0mJpyF8/i7o7IB78kEzItyqtcR16RIDzo qHeEAbzqw3pZYnKX4CqDowYrQym0Ki4oR+FxkML54ID6nEpNDv53XVQuYFkMg5BHdY5Odui7tomiFh +XWHwy0R8kiBOemLtuwPNo/mrJsRz5g== X-MHO-RoutePath: aGlwcGll X-MHO-User: 6db30a48-b3a8-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 6db30a48-b3a8-11e9-85ec-13b9aae3a1d2; Wed, 31 Jul 2019 15:32:40 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x6VFWcis097366; Wed, 31 Jul 2019 09:32:38 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <8e33e48f83f9a53015e165e53d4123c1c5b4e33e.camel@freebsd.org> Subject: Re: Pine64-LTS overlays for uart ports fixed! From: Ian Lepore To: Kaya Saman , "freebsd-arm@freebsd.org" Date: Wed, 31 Jul 2019 09:32:38 -0600 In-Reply-To: <388e17e7-a277-9cd9-47ea-a38f10c7c741@optiplex-networks.com> References: <5f30c425-60c6-d54a-9593-2584bcf25925@optiplex-networks.com> <09afae63-3583-46bd-8911-82a0f0a3185f@optiplex-networks.com> <2ab16425ac48bb7ff4365561b8959ee3eac50530.camel@freebsd.org> <388e17e7-a277-9cd9-47ea-a38f10c7c741@optiplex-networks.com> 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: 45zHVf4KwPz3yCD X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-0.13 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_SHORT(-0.13)[-0.127,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: Wed, 31 Jul 2019 15:32:42 -0000 On Wed, 2019-07-31 at 16:17 +0100, Kaya Saman wrote: > On 7/31/19 3:06 PM, Ian Lepore wrote: > > On Wed, 2019-07-31 at 14:33 +0100, Kaya Saman wrote: > > > On 7/31/19 1:42 AM, Ian Lepore wrote: > > > > On Wed, 2019-07-31 at 00:46 +0100, Kaya Saman wrote: > > > > > [...] > > > > > > I am seeing this: > > > > > > gpsd:PROG: PPS:/dev/gps1 Assert cycle: 999973, duration: 799977 @ > > > 1564579823.472659791 > > > gpsd:PROG: PPS:/dev/gps1 Assert rejected missing last_fixtime > > > > > > > > > Perfect ;-) > > > > > > > > > I think I need to add pps_mode=0x11 or 17 in dec. as the pulse is > > > inverted. > > > > > > > > > This setup was working previously using a Prolific Serial to USB adapter > > > for testing purposes as of course the USB introduces high latency. > > > > > > > Actually, not so much as you'd think. I expected both high latency and > > a lot of jitter when using a usb-serial for PPS, and what I found was a > > fixed latency of less than a millisecond and jitter on the order of 60- > > 80 microseconds. Even trying to saturate the usb bus by doing > > continuous or bursty IO to a disk drive didn't noticibly increase the > > pps latency or jitter. I was pretty surprised. > > > > -- Ian > > > > > > That's very interesting! > > > My finding was that the accuracy went from the 10's of uS using a > standard RS232 D-Sub port on one of my x64 systems to the 100's of uS > range when switching to the Pine64 and using the USB->Serial adapter. > > > Looks like the PPS signal just kicked in: > > > gpsd:PROG: KPPS:/dev/gps1 Clear cycle: 999974, duration: 799981 @ > 1564585351.860177245 > gpsd:PROG: PPS:/dev/gps1 Clear cycle: 999974, duration: 799981 @ > 1564585351.860177245 > gpsd:PROG: PPS:/dev/gps1 Clear rejected this second already handled > gpsd:PROG: KPPS:/dev/gps1 assert 1564585352.060170121, sequence: 5543, > clear 1564585351.860177245, sequence: 5543 - using: assert > gpsd:PROG: KPPS:/dev/gps1 Assert cycle: 999974, duration: 199992 @ > 1564585352.060170121 > gpsd:PROG: PPS:/dev/gps1 Assert cycle: 999974, duration: 199992 @ > 1564585352.060170121 > gpsd:PROG: PPS:/dev/gps1 Assert rejected 1Hz trailing edge > > > After stopping the gpsd service and restarting it's finding it difficult > to startup again. I attempted with dev.uart.4.pps_mode=0x21 for 'narrow' > pulses even though 200ms-1 shouldn't be considered 'narrow'?? I'm guessing. > > > Once I understand a little bit more about the behavior and quirks of the > setup I'll probably start looking at how to enable an input switch on a > GPIO pin then trying to get/write a driver for lcdproc and the Newhaven > display. The aim is to use the retractive mechanical switch to change > the LCD display from clock to GPS info.... > / { > pps@0 { > compatible = "pps-gpio"; > pinctrl-names = "default"; > pinctrl-0 = <&pinctrl_pps0>; > gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* change this */ > status = "okay"; > }; > }; > > The gpios= property will need to refer to the right bank and > > Still lots of work to go but it's definitely a really fun project :-) > > > Regards, > > > Kaya I've never used gpsd and don't know how to interpret its output. Narrow-pulse mode is for pulses down in the few-microseconds range (professional timekeeping equipment often has very short pps pulses, in the 1-100us range). I've always been uneasy with the idea of using CTS for a pps signal, since the uart hardware itself may want to use that line. I wonder if it would help to use the .lock device to force off rtscts flow control? Or, maybe even better, instead of using that pin as a uart cts signal, maybe redo the pinmux to make it a gpio pin, then use the standard gpiopps driver. You might need to add a symlink from /dev/gpiopps0 to /dev/gps1 or whatever gpsd expects. I'm not sure how to do the pinmux node for a gpio pin on that hardware, but you can probably find an example of that. The dts source to enable a gpio pin for pps is: / { pps@0 { compatible = "pps-gpio"; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_pps0>; gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* change this */ status = "okay"; }; }; The gpios= property will need to refer to the right bank and pin number for that hardware. -- Ian From owner-freebsd-arm@freebsd.org Wed Jul 31 16:23:02 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 65274A30F6 for ; Wed, 31 Jul 2019 16:23:02 +0000 (UTC) (envelope-from kayasaman@optiplex-networks.com) Received: from x-ray.optiplex-networks.com (mail.optiplex-networks.com [212.159.80.20]) (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 45zJcj0mxfz429n; Wed, 31 Jul 2019 16:23:01 +0000 (UTC) (envelope-from kayasaman@optiplex-networks.com) Received: from localhost (localhost [127.0.0.1]) by x-ray.optiplex-networks.com (Postfix) with ESMTP id 6B6B77210E3; Wed, 31 Jul 2019 17:22:57 +0100 (BST) Received: from x-ray.optiplex-networks.com ([127.0.0.1]) by localhost (x-ray.optiplex-networks.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id JwmYpydbaCc1; Wed, 31 Jul 2019 17:22:57 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by x-ray.optiplex-networks.com (Postfix) with ESMTP id 118E272645A; Wed, 31 Jul 2019 17:22:57 +0100 (BST) X-Virus-Scanned: amavisd-new at x-ray.optiplex-networks.com Received: from x-ray.optiplex-networks.com ([127.0.0.1]) by localhost (x-ray.optiplex-networks.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 749T2rK4aoyU; Wed, 31 Jul 2019 17:22:57 +0100 (BST) Received: from x220.optiplex-networks.com (unknown [192.168.0.195]) by x-ray.optiplex-networks.com (Postfix) with ESMTPSA id F1E477210E3; Wed, 31 Jul 2019 17:22:56 +0100 (BST) Subject: Re: Pine64-LTS overlays for uart ports fixed! To: Ian Lepore , "freebsd-arm@freebsd.org" References: <5f30c425-60c6-d54a-9593-2584bcf25925@optiplex-networks.com> <09afae63-3583-46bd-8911-82a0f0a3185f@optiplex-networks.com> <2ab16425ac48bb7ff4365561b8959ee3eac50530.camel@freebsd.org> <388e17e7-a277-9cd9-47ea-a38f10c7c741@optiplex-networks.com> <8e33e48f83f9a53015e165e53d4123c1c5b4e33e.camel@freebsd.org> From: Kaya Saman Message-ID: <20926ddd-425d-601c-0d8d-46bb480f61ff@optiplex-networks.com> Date: Wed, 31 Jul 2019 17:22:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <8e33e48f83f9a53015e165e53d4123c1c5b4e33e.camel@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 45zJcj0mxfz429n X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of kayasaman@optiplex-networks.com designates 212.159.80.20 as permitted sender) smtp.mailfrom=kayasaman@optiplex-networks.com X-Spamd-Result: default: False [2.46 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_FIVE(0.00)[6]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(0.00)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[optiplex-networks.com]; SH_EMAIL_DBL(7.00)[0.0.0.0]; BAD_REP_POLICIES(0.10)[]; IP_SCORE(-3.55)[ip: (-9.41), ipnet: 212.159.64.0/18(-4.71), asn: 6871(-3.57), country: GB(-0.08)]; MX_GOOD(-0.01)[cached: mail.optiplex-networks.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.97)[-0.973,0]; SUBJECT_ENDS_EXCLAIM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6871, ipnet:212.159.64.0/18, country:GB]; MID_RHS_MATCH_FROM(0.00)[]; SH_EMAIL_ZRD(0.00)[0.0.0.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: Wed, 31 Jul 2019 16:23:02 -0000 On 7/31/19 4:32 PM, Ian Lepore wrote: > On Wed, 2019-07-31 at 16:17 +0100, Kaya Saman wrote: >> On 7/31/19 3:06 PM, Ian Lepore wrote: >>> On Wed, 2019-07-31 at 14:33 +0100, Kaya Saman wrote: >>>> On 7/31/19 1:42 AM, Ian Lepore wrote: >>>>> On Wed, 2019-07-31 at 00:46 +0100, Kaya Saman wrote: > [...] >>>> I am seeing this: >>>> >>>> gpsd:PROG: PPS:/dev/gps1 Assert cycle: 999973, duration: 799977 @ >>>> 1564579823.472659791 >>>> gpsd:PROG: PPS:/dev/gps1 Assert rejected missing last_fixtime >>>> >>>> >>>> Perfect ;-) >>>> >>>> >>>> I think I need to add pps_mode=0x11 or 17 in dec. as the pulse is >>>> inverted. >>>> >>>> >>>> This setup was working previously using a Prolific Serial to USB adapter >>>> for testing purposes as of course the USB introduces high latency. >>>> >>> Actually, not so much as you'd think. I expected both high latency and >>> a lot of jitter when using a usb-serial for PPS, and what I found was a >>> fixed latency of less than a millisecond and jitter on the order of 60- >>> 80 microseconds. Even trying to saturate the usb bus by doing >>> continuous or bursty IO to a disk drive didn't noticibly increase the >>> pps latency or jitter. I was pretty surprised. >>> >>> -- Ian >>> >>> >> That's very interesting! >> >> >> My finding was that the accuracy went from the 10's of uS using a >> standard RS232 D-Sub port on one of my x64 systems to the 100's of uS >> range when switching to the Pine64 and using the USB->Serial adapter. >> >> >> Looks like the PPS signal just kicked in: >> >> >> gpsd:PROG: KPPS:/dev/gps1 Clear cycle: 999974, duration: 799981 @ >> 1564585351.860177245 >> gpsd:PROG: PPS:/dev/gps1 Clear cycle: 999974, duration: 799981 @ >> 1564585351.860177245 >> gpsd:PROG: PPS:/dev/gps1 Clear rejected this second already handled >> gpsd:PROG: KPPS:/dev/gps1 assert 1564585352.060170121, sequence: 5543, >> clear 1564585351.860177245, sequence: 5543 - using: assert >> gpsd:PROG: KPPS:/dev/gps1 Assert cycle: 999974, duration: 199992 @ >> 1564585352.060170121 >> gpsd:PROG: PPS:/dev/gps1 Assert cycle: 999974, duration: 199992 @ >> 1564585352.060170121 >> gpsd:PROG: PPS:/dev/gps1 Assert rejected 1Hz trailing edge >> >> >> After stopping the gpsd service and restarting it's finding it difficult >> to startup again. I attempted with dev.uart.4.pps_mode=0x21 for 'narrow' >> pulses even though 200ms-1 shouldn't be considered 'narrow'?? I'm guessing. >> >> >> Once I understand a little bit more about the behavior and quirks of the >> setup I'll probably start looking at how to enable an input switch on a >> GPIO pin then trying to get/write a driver for lcdproc and the Newhaven >> display. The aim is to use the retractive mechanical switch to change >> the LCD display from clock to GPS info.... >> / { >> pps@0 { >> compatible = "pps-gpio"; >> pinctrl-names = "default"; >> pinctrl-0 = <&pinctrl_pps0>; >> gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* change this */ >> status = "okay"; >> }; >> }; >> >> The gpios= property will need to refer to the right bank and >> >> Still lots of work to go but it's definitely a really fun project :-) >> >> >> Regards, >> >> >> Kaya > I've never used gpsd and don't know how to interpret its output. > Narrow-pulse mode is for pulses down in the few-microseconds range > (professional timekeeping equipment often has very short pps pulses, in > the 1-100us range). Ok then I don't need to use it as my receiver isn't capable of anything below 20ms-1 http://static.garmin.com/pumac/GPS_18x_Tech_Specs.pdf > > I've always been uneasy with the idea of using CTS for a pps signal, > since the uart hardware itself may want to use that line. I wonder if > it would help to use the .lock device to force off rtscts flow control? I could try this though I'm not sure how to go about it. Would this be performed by the stty command? Currently -ixon is set on the port so that makes output control disabled. I could also try setting -ixoff to disable the input queue.... > > Or, maybe even better, instead of using that pin as a uart cts signal, > maybe redo the pinmux to make it a gpio pin, then use the standard > gpiopps driver. You might need to add a symlink from /dev/gpiopps0 to > /dev/gps1 or whatever gpsd expects. > > I'm not sure how to do the pinmux node for a gpio pin on that hardware, > but you can probably find an example of that. The dts source to enable > a gpio pin for pps is: > > / { > pps@0 { > compatible = "pps-gpio"; > pinctrl-names = "default"; > pinctrl-0 = <&pinctrl_pps0>; > gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* change this */ > status = "okay"; > }; > }; > > The gpios= property will need to refer to the right bank and pin number > for that hardware. > > -- Ian > This might work better. I'll have a go later today. I did have issues while trying things out on Armbian so I don't know if it will the same case with FreeBSD. Virtually what happened was that setting the pin in the loader didn't take effect. Thanks again Ian :-) Best Regards, Kaya From owner-freebsd-arm@freebsd.org Thu Aug 1 12:27:04 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 AE7ADBC7D7 for ; Thu, 1 Aug 2019 12:27:04 +0000 (UTC) (envelope-from kayasaman@optiplex-networks.com) Received: from x-ray.optiplex-networks.com (mail.optiplex-networks.com [212.159.80.20]) (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 45zqL03mPCz4Zst for ; Thu, 1 Aug 2019 12:27:04 +0000 (UTC) (envelope-from kayasaman@optiplex-networks.com) Received: from localhost (localhost [127.0.0.1]) by x-ray.optiplex-networks.com (Postfix) with ESMTP id 5627A721EFA for ; Thu, 1 Aug 2019 13:27:03 +0100 (BST) Received: from x-ray.optiplex-networks.com ([127.0.0.1]) by localhost (x-ray.optiplex-networks.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 7zXk2aSk-Rgy for ; Thu, 1 Aug 2019 13:27:02 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by x-ray.optiplex-networks.com (Postfix) with ESMTP id 11096725F59 for ; Thu, 1 Aug 2019 13:27:02 +0100 (BST) X-Virus-Scanned: amavisd-new at x-ray.optiplex-networks.com Received: from x-ray.optiplex-networks.com ([127.0.0.1]) by localhost (x-ray.optiplex-networks.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id bE4LFnScgbgu for ; Thu, 1 Aug 2019 13:27:01 +0100 (BST) Received: from x220.optiplex-networks.com (unknown [192.168.0.195]) by x-ray.optiplex-networks.com (Postfix) with ESMTPSA id F05A7721EFA for ; Thu, 1 Aug 2019 13:27:01 +0100 (BST) To: "freebsd-arm@freebsd.org" From: Kaya Saman Subject: Re: Pine64-LTS overlays for uart ports fixed! Message-ID: <0fb22c15-c514-338c-04d0-03ae274e8250@optiplex-networks.com> Date: Thu, 1 Aug 2019 13:27:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 Content-Language: en-US X-Rspamd-Queue-Id: 45zqL03mPCz4Zst X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-0.77 / 15.00]; NEURAL_HAM_MEDIUM(-0.44)[-0.438,0]; NEURAL_HAM_SHORT(-0.33)[-0.327,0]; ASN(0.00)[asn:6871, ipnet:212.159.64.0/18, country:GB]; local_wl_ip(0.00)[212.159.80.20] 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: Thu, 01 Aug 2019 12:27:04 -0000 [snip] On 7/31/19 5:22 PM, Kaya Saman wrote: > >>> >>> Kaya >> I've never used gpsd and don't know how to interpret its output. >> Narrow-pulse mode is for pulses down in the few-microseconds range >> (professional timekeeping equipment often has very short pps pulses, i= n >> the 1-100us range). Just found this: https://lists.gnu.org/archive/html/gpsd-users/2017-09/msg00031.html Uh, no. lease reread the output. gpsd is accepting the leading edge, an= d rejeecting the trailing edge. Just as it should. >/Sep 18 23:36:50 k9 gpsd[15453]: gpsd:PROG: KPPS:/dev/ttyS2 assert> / >/1505777810.100060219, sequence: 8, clear 1505777810.000026753, sequence= : 8 / >/- using: assert/ Accepted edge. >/Sep 18 23:36:50 k9 gpsd[15453]: gpsd:PROG: PPS:/dev/ttyS2 Assert=20 rejected 1Hz / >/trailing edge/ Rejected trailing edge. A pulse has two edges. PPS uses the eading one, and ignores the trailing edge. Looks like it's working properly :-) > > > [snip] >> >> Or, maybe even better, instead of using that pin as a uart cts signal, >> maybe redo the pinmux to make it a gpio pin, then use the standard >> gpiopps driver.=C2=A0 You might need to add a symlink from /dev/gpiopp= s0 to >> /dev/gps1 or whatever gpsd expects. >> >> I'm not sure how to do the pinmux node for a gpio pin on that hardware= , >> but you can probably find an example of that.=C2=A0 The dts source to = enable >> a gpio pin for pps is: >> >> / { >> =C2=A0=C2=A0=C2=A0=C2=A0pps@0 { >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 compatible =3D "pps-gpio"; >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pinctrl-names =3D "default"= ; >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pinctrl-0 =3D <&pinctrl_pps= 0>; >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 gpios =3D <&gpio1 0 GPIO_AC= TIVE_HIGH>; /* change this */ >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 status =3D "okay"; >> =C2=A0=C2=A0=C2=A0=C2=A0}; >> }; >> >> The gpios=3D property will need to refer to the right bank and pin num= ber >> for that hardware. >> >> -- Ian >> > > This might work better. I'll have a go later today. I did have issues=20 > while trying things out on Armbian so I don't know if it will the same=20 > case with FreeBSD. Virtually what happened was that setting the pin in=20 > the loader didn't take effect. > > > Thanks again Ian :-) > > > Best Regards, > > > Kaya > > _______________________________________________ > 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" My GPIO file features this: /dts-v1/; /plugin/; / { =C2=A0=C2=A0=C2=A0 compatible =3D "allwinner,sun50i-a64"; =C2=A0=C2=A0=C2=A0 fragment@0 { =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 target =3D <&pio>; =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 __overlay__ { =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 pps_pins: pps_p= ins { =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0 pins =3D "PD4"; =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0 function =3D "gpio_in"; =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=C2=A0=C2=A0 }; =C2=A0=C2=A0=C2=A0 fragment@1 { =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 target-path =3D "/"; =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 __overlay__ { =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 pps@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 compatible =3D "pps-gpio"; =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0 pinctrl-names =3D "default"; =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0 pinctrl-0 =3D <&pps_pins>; =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0 gpios =3D <&pio 3 4 0>; /* PD4 */ =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0 status =3D "okay"; =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=C2=A0=C2=A0 }; }; So in conjunction with reading the example: gpios =3D <&gpio1 0 GPIO_ACTIVE_HIGH>; /* change this */ If we take the Pi2-bus connector:=20 http://synfare.com/599N105E/hwdocs/pine64/gpiosgeo.html and just use for argument sake pine PC9 as PPS input. Using: gpioctl -lv the pin number becomes: pin 19:=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0 PC9= , caps: I'm not sure how to interpret this: gpios =3D <&pio 3 4 0>; /* PD4 */ - as pin PD4 is being registered as: pin 31:=C2=A0=C2=A0=C2=A0 0 PD4<>, c= aps: I can only guess that it is 'bank 3' , 'pin 4' , there=20 for the line would need to be changed to: gpios =3D <&pio 3 4 0>; -> gpios =3D <&pio 2 9 0>; Possibly?? <- ok just=20 tested and it's not working :-( Ian, I think I ran in to an issue with the CTS. It might be exactly as=20 you mentioned in that the uart port maybe trying to use it for something=20 else?? I disabled flow control using stty for both cuau4.init and=20 ttyu4.init. The interesting thing here is that with the GPS PPS plugged=20 in I get 'PPS time out' messages, if I move the PPS wire to a different=20 ping (a GPIO pin for example) then re-plug it back into the uart4 CTS=20 pin it works? ---- 3rd send attempt; have just contacted @Postmaster about the issue=20 and seems like there is an issue so if anyone else is having issues=20 sending to the list it is being worked on currently :-) -> just an FYI :-= ) Regards, Kaya From owner-freebsd-arm@freebsd.org Fri Aug 2 12:40: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 0D429B242E for ; Fri, 2 Aug 2019 12:40:47 +0000 (UTC) (envelope-from return@latestdeals.co.za) Received: from slot16.latestdeals.co.za (slot16.latestdeals.co.za [51.79.119.215]) by mx1.freebsd.org (Postfix) with ESMTP id 460RbK4gRfz42qQ for ; Fri, 2 Aug 2019 12:40:45 +0000 (UTC) (envelope-from return@latestdeals.co.za) Message-ID: <8eb59b00fc047f436f2791ab0b6ca386@latestdeals.co.za> Date: Fri, 02 Aug 2019 12:30:10 +0000 Subject: Massive Winter Sale! From: Snatcher Online Reply-To: Snatcher Online To: "freebsd-arm@freebsd.org" MIME-Version: 1.0 X-Sender: return@latestdeals.co.za X-Report-Abuse: Please report abuse for this campaign here: http://latestdeals.co.za/mw/index.php/campaigns/cg1899reb35f8/report-abuse/bo662bcbmkd10/ya049v8fwh03d X-Receiver: freebsd-arm@freebsd.org X-Mw-Tracking-Did: 0 X-Mw-Subscriber-Uid: ya049v8fwh03d X-Mw-Mailer: SwiftMailer - 5.4.x X-Mw-EBS: http://latestdeals.co.za/mw/index.php/lists/block-address X-Mw-Delivery-Sid: 1 X-Mw-Customer-Uid: am502fsba844f X-Mw-Customer-Gid: 0 X-Mw-Campaign-Uid: cg1899reb35f8 Precedence: bulk Feedback-ID: cg1899reb35f8:ya049v8fwh03d:bo662bcbmkd10:am502fsba844f X-Rspamd-Queue-Id: 460RbK4gRfz42qQ X-Spamd-Bar: +++ X-Spamd-Result: default: False [3.43 / 15.00]; HAS_REPLYTO(0.00)[reply@latestdeals.co.za]; R_SPF_ALLOW(-0.20)[+ptr]; ZERO_FONT(0.50)[5]; REPLYTO_DN_EQ_FROM_DN(0.00)[]; DKIM_TRACE(0.00)[latestdeals.co.za:+]; DMARC_POLICY_ALLOW(-0.50)[latestdeals.co.za,reject]; SUBJECT_ENDS_EXCLAIM(0.00)[]; MAILLIST(-0.10)[generic]; FORGED_SENDER(0.00)[deals@latestdeals.co.za,return@latestdeals.co.za]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(0.55)[ipnet: 51.79.0.0/17(1.55), asn: 16276(1.21), country: FR(-0.01)]; ASN(0.00)[asn:16276, ipnet:51.79.0.0/17, country:FR]; FROM_NEQ_ENVFROM(0.00)[deals@latestdeals.co.za,return@latestdeals.co.za]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[latestdeals.co.za:s=default]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PRECEDENCE_BULK(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; REPLYTO_DOM_EQ_FROM_DOM(0.00)[]; HTML_SHORT_LINK_IMG_1(2.00)[]; HAS_LIST_UNSUB(-0.01)[]; RCPT_COUNT_ONE(0.00)[1]; MANY_INVISIBLE_PARTS(0.80)[9]; NEURAL_SPAM_SHORT(0.69)[0.692,0]; TO_DN_EQ_ADDR_ALL(0.00)[]; FORGED_SENDER_MAILLIST(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 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 12:40:47 -0000 Up to 50% off on selected items=20 Upto 80% Discount=C2=A0=20 Hurry!=C2=A0=20 Snatch Now!=20 =C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0= =E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C View this email in your browser http://latestdeals.co.za/mw/index.php/campaigns/cg1899reb35f8/track-url/ya= 049v8fwh03d/e58677fe7ef73ba027aeeb6bad221e8ff3d3e0e1 =09 http://latestdeals.co.za/mw/index.php/campaigns/cg1899reb35f8/track-url/ya= 049v8fwh03d/f682fdbe05fd7b621b6baa5fd43b876f9e5d872d =C2=A0 http://latestdeals.co.za/mw/index.php/campaigns/cg1899reb35f8/track-url/= ya049v8fwh03d/f682fdbe05fd7b621b6baa5fd43b876f9e5d872d=C2=A0 http://latestdeals.co.za/mw/index.php/campaigns/cg1899reb35f8/track-url/y= a049v8fwh03d/66dbb1d7e10ea7c15d94e18c72dfa3279356b086 =C2=A0 http://latestdeals.co.za/mw/index.php/campaigns/cg1899reb35f8/track-url/ya= 049v8fwh03d/14f9a520b6b461feaca94ea222651beb8d7f022d =C2=A0 Snatcher Online=20 5 Star Business Park, Unit 1 Insite Park, Bailey Road Laser Park, Honeydew =C2=A0Johannesburg 1725=20 =C2=A0=20 info@snatcher.co.za=20 =09 http://latestdeals.co.za/mw/index.php/campaigns/cg1899reb35f8/track-url/y= a049v8fwh03d/bdb1ac1efb29cc4f3e96139351e19691bd26b3ce =09 http://latestdeals.co.za/mw/index.php/campaigns/cg1899reb35f8/track-url/y= a049v8fwh03d/4b4c392b89ee40f74a3acebde11f1cbbaf5c389c =09 http://latestdeals.co.za/mw/index.php/campaigns/cg1899reb35f8/track-url/y= a049v8fwh03d/25b73438d403c2fc4b5a375063f576e0b3033cb5 =C2=A0 Unsubscribe from this list http://latestdeals.co.za/mw/index.php/campaigns/cg1899reb35f8/track-url/ya0= 49v8fwh03d/8172c090294ab4cd87142a687c4b84f9ceabdd46 =C2=A0=20 =20 From owner-freebsd-arm@freebsd.org Fri Aug 2 15:14: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 48A50B5575 for ; Fri, 2 Aug 2019 15:14:39 +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 460W0t6K9Vz4B0Z for ; Fri, 2 Aug 2019 15:14:38 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1564758877; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=BCenVL+MNLDW2NeYBnEDWG/MpAWnOfXVvzriDzBXO2bkKYrQKdzRmASFzSWS15s0ycLjxv+OqZXGx A+FcHsSvT77vfIRXIFQaVicKY7xh8ilzJ1a+H9o7OFBYhKZeXuB09YvH6VPemFljDIY2JzOlmlwop5 S9RP2uc6368ddy2mhdAnXz6faMkg3QTYy2PvPDWN2EaOB/V0drIz9kmLnWkqpIrEjKXXteGIiRYtbZ k/cc1XxmygAmI3TxHIJw89UGkxB5WGhnBfsVPPlVztQZXPmWZ6haquvVSroXxEswtuukCt1WIY5LMj uxoDLPZO05w8IJMdiKSBgbBPETA6RkA== 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=KIRX8xinu64DsoRkaB9DkxYCQrxXnUDDA22uxGQsHeg=; b=FnDwKgOcT+P0dS1zcGSa8oPAd4Xy//caOKO+VyKrm5N48dCaURmDs2UbZxP/h1FEr8824KJJS8AdN clCOTuMqekEVKLfakuQmpKsNlzN/rIPHKwH6osGVNP0vPhF2DFPWLgW+00AkeWEm7zxekBD4/QZ6XB g1yj8rxKcsO2BmHy5pfxrcsgG5ckc465FiTRhw4ND1fDlJQhlnFJWX/N5KIb4Fzqsa/o0zSSzNV41M 74tlqfzuNprrGxA326oxyzkHPTdlAfAx6syq4UrAxBbPZg63VksQVnx+0PZHNfOd/B4OF8kGt9KsaB Ii5MvoHZq96HLq4wowT/HB0F8vOEnpg== 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:to:from:subject:message-id:from; bh=KIRX8xinu64DsoRkaB9DkxYCQrxXnUDDA22uxGQsHeg=; b=jszPDq/MFScInGSEbT1P/qt9Oicc0axaSIOQkHodo27m1DayvpD7Bnexly575BAwfiOu8lgLGrKhL lPk4ZQSoJA8OnZEiLUzk9b0cxBuw2NvmCA8ORwnqYRYRerr/V00/+oHWxfF1xKsCas//mVH5CnOIvw oLht8832E/C/cypZsrrnzx1OS/gbJlMRj1NFtTLK4QrBxwyxi1N12kQrZ7vHuzgxOG+73Kwj3ghErZ Lno6o6IyjAcVUNO+FzGVg4p3jf/QeTBn9KhomHsLrMmdhO4L77pZ7sNqpWUiutPOeZLA1MzNQ3wHOQ ODrUT3p5YwxGmFxzkRo7DubhgHe8vqw== X-MHO-RoutePath: aGlwcGll X-MHO-User: 3beacde6-b538-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 3beacde6-b538-11e9-85ec-13b9aae3a1d2; Fri, 02 Aug 2019 15:14:36 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x72FEXTe005797; Fri, 2 Aug 2019 09:14:33 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: Pine64-LTS overlays for uart ports fixed! From: Ian Lepore To: Kaya Saman , "freebsd-arm@freebsd.org" Date: Fri, 02 Aug 2019 09:14:33 -0600 In-Reply-To: <0fb22c15-c514-338c-04d0-03ae274e8250@optiplex-networks.com> References: <0fb22c15-c514-338c-04d0-03ae274e8250@optiplex-networks.com> 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: 460W0t6K9Vz4B0Z X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-0.41 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_SHORT(-0.41)[-0.410,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: Fri, 02 Aug 2019 15:14:39 -0000 On Thu, 2019-08-01 at 13:27 +0100, Kaya Saman wrote: > [snip] > > On 7/31/19 5:22 PM, Kaya Saman wrote: > > > > > > > > > > Kaya > > > > > > I've never used gpsd and don't know how to interpret its output. > > > Narrow-pulse mode is for pulses down in the few-microseconds range > > > (professional timekeeping equipment often has very short pps pulses, in > > > the 1-100us range). > > > Just found this: > > https://lists.gnu.org/archive/html/gpsd-users/2017-09/msg00031.html > > > Uh, no. lease reread the output. gpsd is accepting the leading edge, and > rejeecting the trailing edge. Just as it should. > > > /Sep 18 23:36:50 k9 gpsd[15453]: gpsd:PROG: KPPS:/dev/ttyS2 assert> / > > /1505777810.100060219, sequence: 8, clear 1505777810.000026753, sequence: 8 / > > /- using: assert/ > > Accepted edge. > > > /Sep 18 23:36:50 k9 gpsd[15453]: gpsd:PROG: PPS:/dev/ttyS2 Assert > > rejected 1Hz / > > /trailing edge/ > > Rejected trailing edge. > > A pulse has two edges. PPS uses the eading one, and ignores the > trailing edge. > > > Looks like it's working properly :-) > > > > > > > > [snip] > > > > > > Or, maybe even better, instead of using that pin as a uart cts signal, > > > maybe redo the pinmux to make it a gpio pin, then use the standard > > > gpiopps driver. You might need to add a symlink from /dev/gpiopps0 to > > > /dev/gps1 or whatever gpsd expects. > > > > > > I'm not sure how to do the pinmux node for a gpio pin on that hardware, > > > but you can probably find an example of that. The dts source to enable > > > a gpio pin for pps is: > > > > > > / { > > > pps@0 { > > > compatible = "pps-gpio"; > > > pinctrl-names = "default"; > > > pinctrl-0 = <&pinctrl_pps0>; > > > gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* change this */ > > > status = "okay"; > > > }; > > > }; > > > > > > The gpios= property will need to refer to the right bank and pin number > > > for that hardware. > > > > > > -- Ian > > > > > > > This might work better. I'll have a go later today. I did have issues > > while trying things out on Armbian so I don't know if it will the same > > case with FreeBSD. Virtually what happened was that setting the pin in > > the loader didn't take effect. > > > > > > Thanks again Ian :-) > > > > > My GPIO file features this: > > > /dts-v1/; > /plugin/; > > / { > compatible = "allwinner,sun50i-a64"; > > fragment@0 { > target = <&pio>; > __overlay__ { > pps_pins: pps_pins { > pins = "PD4"; > function = "gpio_in"; > }; > }; > }; > > fragment@1 { > target-path = "/"; > __overlay__ { > pps@0 { > compatible = "pps-gpio"; > pinctrl-names = "default"; > pinctrl-0 = <&pps_pins>; > gpios = <&pio 3 4 0>; /* PD4 */ > status = "okay"; > }; > }; > }; > }; > > > So in conjunction with reading the example: > > > gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* change this */ > > > If we take the Pi2-bus connector: > http://synfare.com/599N105E/hwdocs/pine64/gpiosgeo.html > > and just use for argument sake pine PC9 as PPS input. > > Using: gpioctl -lv > > the pin number becomes: pin 19: 0 PC9, caps: > > > I'm not sure how to interpret this: gpios = <&pio 3 4 0>; /* PD4 */ > > - as pin PD4 is being registered as: pin 31: 0 PD4<>, caps: > > I can only guess that it is 'bank 3' , 'pin 4' , there > for the line would need to be changed to: > > gpios = <&pio 3 4 0>; -> gpios = <&pio 2 9 0>; Possibly?? <- ok just > tested and it's not working :-( > > > Ian, I think I ran in to an issue with the CTS. It might be exactly as > you mentioned in that the uart port maybe trying to use it for something > else?? I disabled flow control using stty for both cuau4.init and > > > Best Regards,> > > > > > > > Kaya> > > > > _______________________________________________> > 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"> > > > ttyu4.init. The interesting thing here is that with the GPS PPS plugged > in I get 'PPS time out' messages, if I move the PPS wire to a different > ping (a GPIO pin for example) then re-plug it back into the uart4 CTS > pin it works? > > > ---- 3rd send attempt; have just contacted @Postmaster about the > issue > and seems like there is an issue so if anyone else is having issues > sending to the list it is being worked on currently :-) -> just an > FYI :-) > > > When gpio pins are banked and a single device instance handles all the banks, which appears to be your case, then it's device-specific how gpioctl maps bank+pin to a linear pin number. I would make the same guesses you did. Or I would look at the driver code, but I don't even know what driver is involved there. One thing to check is to make sure nothing else is trying to configure the PC9 pin if that's the one you chose for gpio-pps input. I created that problem for myself last night while setting up a test... I wrote an overlay that reassigned a given pin as a gpio input, but forgot that elsewhere in the dts that pin was assigned to an sdcard slot. So during kernel init the pin was first getting set to my gpio input, then later when it got to the sd device's pins it got reassigned back to an output. Easily fixed by adding a status = "disabled" for the sd device once I remembered it was there. Another thing I ran into... I wanted to test using CTS as the pps input on an imx6 board, and it wasn't working. Eventually I figured out that the uart driver for imx6 just doesn't support rts/cts signals at all. Doh! So your efforts to use CTS could be running into something like that; I suspect imx6 isn't the only arm uart driver that's basically a 3-wire driver. -- Ian From owner-freebsd-arm@freebsd.org Fri Aug 2 19:09: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 761AEB90B3 for ; Fri, 2 Aug 2019 19:09:14 +0000 (UTC) (envelope-from kayasaman@optiplex-networks.com) Received: from x-ray.optiplex-networks.com (mail.optiplex-networks.com [212.159.80.20]) (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 460cCZ0gLhz4MXC; Fri, 2 Aug 2019 19:09:13 +0000 (UTC) (envelope-from kayasaman@optiplex-networks.com) Received: from localhost (localhost [127.0.0.1]) by x-ray.optiplex-networks.com (Postfix) with ESMTP id 65C8E725F59; Fri, 2 Aug 2019 20:09:12 +0100 (BST) Received: from x-ray.optiplex-networks.com ([127.0.0.1]) by localhost (x-ray.optiplex-networks.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 3eBoeN1jplkG; Fri, 2 Aug 2019 20:09:11 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by x-ray.optiplex-networks.com (Postfix) with ESMTP id C8FB6722DF7; Fri, 2 Aug 2019 20:09:11 +0100 (BST) X-Virus-Scanned: amavisd-new at x-ray.optiplex-networks.com Received: from x-ray.optiplex-networks.com ([127.0.0.1]) by localhost (x-ray.optiplex-networks.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mvLFr89raSWm; Fri, 2 Aug 2019 20:09:11 +0100 (BST) Received: from x220.optiplex-networks.com (unknown [192.168.0.195]) by x-ray.optiplex-networks.com (Postfix) with ESMTPSA id B4CE8721FB9; Fri, 2 Aug 2019 20:09:11 +0100 (BST) Subject: Re: Pine64-LTS overlays for uart ports fixed! To: Ian Lepore , "freebsd-arm@freebsd.org" References: <0fb22c15-c514-338c-04d0-03ae274e8250@optiplex-networks.com> From: Kaya Saman Message-ID: <3e2688d9-0a13-5ecd-8495-ce947c7b176b@optiplex-networks.com> Date: Fri, 2 Aug 2019 20:09:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 460cCZ0gLhz4MXC X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-0.45 / 15.00]; NEURAL_HAM_SHORT(-0.45)[-0.455,0]; ASN(0.00)[asn:6871, ipnet:212.159.64.0/18, country:GB]; local_wl_ip(0.00)[212.159.80.20] 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: Fri, 02 Aug 2019 19:09:14 -0000 On 8/2/19 4:14 PM, Ian Lepore wrote: > On Thu, 2019-08-01 at 13:27 +0100, Kaya Saman wrote: >> [snip] >> >> On 7/31/19 5:22 PM, Kaya Saman wrote: >>>>> Kaya >>>> I've never used gpsd and don't know how to interpret its output. >>>> Narrow-pulse mode is for pulses down in the few-microseconds range >>>> (professional timekeeping equipment often has very short pps pulses,= in >>>> the 1-100us range). >> >> Just found this: >> >> https://lists.gnu.org/archive/html/gpsd-users/2017-09/msg00031.html >> >> >> Uh, no. lease reread the output. gpsd is accepting the leading edge,= and >> rejeecting the trailing edge. Just as it should. >> >>> /Sep 18 23:36:50 k9 gpsd[15453]: gpsd:PROG: KPPS:/dev/ttyS2 assert> / >>> /1505777810.100060219, sequence: 8, clear 1505777810.000026753, seque= nce: 8 / >>> /- using: assert/ >> Accepted edge. >> >>> /Sep 18 23:36:50 k9 gpsd[15453]: gpsd:PROG: PPS:/dev/ttyS2 Assert >> rejected 1Hz / >>> /trailing edge/ >> Rejected trailing edge. >> >> A pulse has two edges. PPS uses the eading one, and ignores the >> trailing edge. >> >> >> Looks like it's working properly :-) >> >> >>> >>> [snip] >>>> Or, maybe even better, instead of using that pin as a uart cts signa= l, >>>> maybe redo the pinmux to make it a gpio pin, then use the standard >>>> gpiopps driver. You might need to add a symlink from /dev/gpiopps0 = to >>>> /dev/gps1 or whatever gpsd expects. >>>> >>>> I'm not sure how to do the pinmux node for a gpio pin on that hardwa= re, >>>> but you can probably find an example of that. The dts source to ena= ble >>>> a gpio pin for pps is: >>>> >>>> / { >>>> pps@0 { >>>> compatible =3D "pps-gpio"; >>>> pinctrl-names =3D "default"; >>>> pinctrl-0 =3D <&pinctrl_pps0>; >>>> gpios =3D <&gpio1 0 GPIO_ACTIVE_HIGH>; /* change this */ >>>> status =3D "okay"; >>>> }; >>>> }; >>>> >>>> The gpios=3D property will need to refer to the right bank and pin n= umber >>>> for that hardware. >>>> >>>> -- Ian >>>> >>> This might work better. I'll have a go later today. I did have issues >>> while trying things out on Armbian so I don't know if it will the sam= e >>> case with FreeBSD. Virtually what happened was that setting the pin i= n >>> the loader didn't take effect. >>> >>> >>> Thanks again Ian :-) >>> >>> >> My GPIO file features this: >> >> >> /dts-v1/; >> /plugin/; >> >> / { >> compatible =3D "allwinner,sun50i-a64"; >> >> fragment@0 { >> target =3D <&pio>; >> __overlay__ { >> pps_pins: pps_pins { >> pins =3D "PD4"; >> function =3D "gpio_in"; >> }; >> }; >> }; >> >> fragment@1 { >> target-path =3D "/"; >> __overlay__ { >> pps@0 { >> compatible =3D "pps-gpio"; >> pinctrl-names =3D "default"; >> pinctrl-0 =3D <&pps_pins>; >> gpios =3D <&pio 3 4 0>; /* PD4 */ >> status =3D "okay"; >> }; >> }; >> }; >> }; >> >> >> So in conjunction with reading the example: >> >> >> gpios =3D <&gpio1 0 GPIO_ACTIVE_HIGH>; /* change this */ >> >> >> If we take the Pi2-bus connector: >> http://synfare.com/599N105E/hwdocs/pine64/gpiosgeo.html >> >> and just use for argument sake pine PC9 as PPS input. >> >> Using: gpioctl -lv >> >> the pin number becomes: pin 19: 0 PC9, caps: >> >> >> I'm not sure how to interpret this: gpios =3D <&pio 3 4 0>; /* PD4 */ >> >> - as pin PD4 is being registered as: pin 31: 0 PD4<>, caps: >> >> I can only guess that it is 'bank 3' , 'pin 4' , ther= e >> for the line would need to be changed to: >> >> gpios =3D <&pio 3 4 0>; -> gpios =3D <&pio 2 9 0>; Possibly?? <- ok ju= st >> tested and it's not working :-( >> >> >> Ian, I think I ran in to an issue with the CTS. It might be exactly as >> you mentioned in that the uart port maybe trying to use it for somethi= ng >> else?? I disabled flow control using stty for both cuau4.init and >>>> Best Regards,> > >>>> >>>> Kaya> > >>>> _______________________________________________> > 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"> >> ttyu4.init. The interesting thing here is that with the GPS PPS plugge= d >> in I get 'PPS time out' messages, if I move the PPS wire to a differen= t >> ping (a GPIO pin for example) then re-plug it back into the uart4 CTS >> pin it works? >> >> >> ---- 3rd send attempt; have just contacted @Postmaster about the >> issue >> and seems like there is an issue so if anyone else is having issues >> sending to the list it is being worked on currently :-) -> just an >> FYI :-) >> >> >> > When gpio pins are banked and a single device instance handles all the > banks, which appears to be your case, then it's device-specific how > gpioctl maps bank+pin to a linear pin number. I would make the same > guesses you did. Or I would look at the driver code, but I don't even > know what driver is involved there. > > One thing to check is to make sure nothing else is trying to configure > the PC9 pin if that's the one you chose for gpio-pps input. I created > that problem for myself last night while setting up a test... I wrote > an overlay that reassigned a given pin as a gpio input, but forgot that > elsewhere in the dts that pin was assigned to an sdcard slot. So > during kernel init the pin was first getting set to my gpio input, then > later when it got to the sd device's pins it got reassigned back to an > output. Easily fixed by adding a status =3D "disabled" for the sd devi= ce > once I remembered it was there. > > Another thing I ran into... I wanted to test using CTS as the pps input > on an imx6 board, and it wasn't working. Eventually I figured out that > the uart driver for imx6 just doesn't support rts/cts signals at all. > Doh! So your efforts to use CTS could be running into something like > that; I suspect imx6 isn't the only arm uart driver that's basically a > 3-wire driver. > > -- Ian > > Initially I performed a few tests on gpio just to see if the OS pin=20 mappings correlated to the the actual mappings. Starting with gpioctl -lv - I got a listing of all the pins; great ;-) pin 19:=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0 PC9, caps: pin 20:=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0 PC10, caps: pin 21:=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0 PC11, caps: pin 22:=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0 PC12, caps: pin 23:=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0 PC13, caps: pin 24:=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0 PC14, caps: pin 25:=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0 PC15, caps: pin 26:=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0 PC16, caps: Then I tried to assign PC9 and PC16 which are adjacent as output pins.=20 As I don't have a multimeter on hand or CRO I used the next best thing,=20 a 5v LED. Using jumper cables I coupled the LED between PC9 first and=20 GND. Then ran: gpioctl -c 19 OUT observe output using -lv and yes it has changed. Afterwards I tried to=20 set the pin to a 'high' level: gpioctl 19 1 LED illuminates. Fantastic! Same procedure for pin 26 too. Satisfied=20 that the pin numbers are correct and mapped properly I then looked at=20 connecting a switch. First set pin 26 to IN. Connect switch between GND=20 and PC16. Press button and observe output of pin... nothing. Ok fine, it=20 is waiting for a state change and is already at 0 doh! Let's attempt to=20 invert the behavior: gpioctl -c 26 II -> no change, nothing is working. Aaaah but there is a 3.3v output header on the board so let's try that=20 instead of GND and bang waddya know.... state change from 0 to 1 whoohoo=20 :-) :-) Next thing is just simply tying the pin to Lcdproc which shouldn't be=20 too difficult. for reference to GPIO I found this=20 (https://vzaigrin.wordpress.com/2014/04/18/working-with-gpio-on-raspberry= -pi-with-freebsd/) Something interesting I found out. It seems at the initialization=20 (startup) stage that the TTL -> RS232 shifter is going high on the CTS=20 pin. This is the reason why my PPS signal is not being detected. If I=20 power down the board and remove the PPS jumper wire from the CTS header=20 then power up and start GPSD as normal, then insert the PPS jumper back=20 into the CTS pin it functions fine. Accuracy is also very good: # ntpq -p =C2=A0=C2=A0=C2=A0=C2=A0 remote=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 refid=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 st t when poll rea= ch=C2=A0=C2=A0 delay offset=C2=A0=20 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 =C2=A0SHM(0)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .NMEA= .=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0 l=C2=A0=C2= =A0 12=C2=A0=C2=A0 16=C2=A0 377=C2=A0=C2=A0=C2=A0 0.000 -31.383=C2=A0=20 16.450 *SHM(1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .PPS.=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0 l=C2=A0=C2= =A0 11=C2=A0=C2=A0 16=C2=A0 377=C2=A0=C2=A0=C2=A0 0.000 -0.004=C2=A0=C2=A0= 0.002 Here I need to do one of two things; 1. set the CTS pin to disabled in=20 FreeBSD until the PPS signal starts pulsing then enable it - or - 2.=20 introduce a mechanical switch into the signal path to manually=20 enable/disable the PPS signal. Testing with my trusty LED, at startup the voltage on the RS232-TTL=20 shifter is at a constant high, ie. LED is on. After a while it will=20 start to pulse. Hence my thoughts above. Perhaps " Easily fixed by adding a status =3D "disabled" for the sd device once I remembered it was there. " is what I'm looking for? Where is this set? Regards, Kaya From owner-freebsd-arm@freebsd.org Fri Aug 2 21:16: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 984B6BC005 for ; Fri, 2 Aug 2019 21:16: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 460g2b1FM0z4WNn for ; Fri, 2 Aug 2019 21:16:38 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1564780597; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=GHUxBdYL7IDGdDqqxpfsSwBcWX5R5fbciVvFqqEDcl0ZCUus0Tq9FQR2eocBL0cbiYyk396cZr6u3 q3mGiz9ZCN8G3eaxfxPx7c1vJ/rpknT2N4fYGVDNX1NmphjsKPIr6HikgEi+5Boq/4EcgdDGB22Q/Z VV8szdq4+6w7T8+eUjB9m6PGUGfcBZVx7xo3rY7bRFBT1LNaPHK7J3yGYEjwgQCtPFGZTcI9XkY5P+ ccvzwOMSqqDzrLipmVQTLurYuNNUROtEZ8yDRnbbSx3j4tbk/eRrMblQyQXIYfMkrF5zRQzuJhmUb+ kdHRnXjyqbUFAsl8wHzBSTrmboQJdwg== 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:date:to:from:subject: message-id:dkim-signature:from; bh=fk5Wcs3Iz1Lm5Hkyzn5pZaMfjSL3G9a8YbzYHGhqb34=; b=lBoVF+1vjeyUARYfAbciFizW7dHvX+clMxT/SCQPOVImIssW3cJEry7DTmMV9FyNLBhVz7fEYnZhk 3YP6koJEJfT25vCy6VUE8WGNhxKOp9QiaML5y91FC4i29yX+U+ihkM3+193eOgTDECdlaIyLnaaMes gWG41+HSTXvuyy2CeVDDfG51j7VYidCvdlnNUZAAdl8H53HbtGs7dTpv6qAj476BISdn0eHlEW3qUZ S7nfbmy3Eg5SR0B9orTEx59VAiQVxTRyB8mcru6QIwP8EUxpgQZBc//an6pNcBAsGrK3yBpd3IGh4t VA3j09C1A/XWvIbUSkQrytuFQ/+B7zg== 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:date:to:from:subject: message-id:from; bh=fk5Wcs3Iz1Lm5Hkyzn5pZaMfjSL3G9a8YbzYHGhqb34=; b=FGYDuZheCCepVmtImPrmA/wCW99+csxDDanf3t2Qf3j91bbyjNg9SW8yK4Am4JE/csFSfinkn0qlI 7XMfA6yndfkoRidw7Xz1yEgwiWlQunqO75qewmFkq63COFdYOiLCglR45oqUOoAUZ/wyBW58qx8qsJ i/wivb5z5AQAJGMJ9xxcW+30Al4ljJvXL+wld2g0TJeK2fkkEK5vpaER1y34tKR5QznCvBGuc9nQWp X9bypbsHiKMzz1T1jwlqu4eWqNP5ofyzdVgdeW1jepRNxtbOWhPNG9i9eLltuQlmQ25FjHMxifrmQ7 Qsh6am7wPvq8rUsUw/+ZGSP2k3D+4kQ== X-MHO-RoutePath: aGlwcGll X-MHO-User: cecc6a2d-b56a-11e9-b679-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 cecc6a2d-b56a-11e9-b679-cdd75d6ce7a8; Fri, 02 Aug 2019 21:16:36 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x72LGZUk006832; Fri, 2 Aug 2019 15:16:35 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Is it a good idea to use a usb-serial adapter for PPS input? Yes, it is. From: Ian Lepore To: "freebsd-arm@FreeBSD.org" , usb@FreeBSD.org Date: Fri, 02 Aug 2019 15:16:34 -0600 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: 460g2b1FM0z4WNn X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.31 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_SPAM_SHORT(0.31)[0.306,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: Fri, 02 Aug 2019 21:16:39 -0000 Since we added support for accepting a PPS signal on a USB-serial adapter a couple years ago, I've seen people express reluctance to use it several times. Usually they cite concerns about latency and jitter. I decided it was time to do some rigorous testing, and post the results. Complete details on the test setup appear below. The tl;dr summary is: A single PPS source is fanned out to 4 different types of inputs on a Wandboard system (armv7, imx6 SoC). Ntpd is configured to steer only to PPS(0), and the offset and jitter numbers for the other sources allow comparing the various PPS processing paths. After running about 12 hours, the results are: remote refid st t when poll reach delay offset jitter ===================================================================== oPPS(0) .gpt. 0 l 8 16 377 0.000 0.000 0.002 PPS(1) .gpio. 0 l 7 16 377 0.000 -0.002 0.002 PPS(2) .usb1. 0 l 6 16 377 0.000 -0.201 0.034 PPS(3) .usb2. 0 l 5 16 377 0.000 -0.215 0.026 *tflex.my.lan .GPS. 1 u 32 64 377 0.568 0.038 0.061 PPS(0) is fed to a hardware timer block within the imx6 SoC. The PPS pulse triggers hardware capture of the kernel clock, eliminating latency and jitter due to interrupt processing. PPS(1) is fed to a generic gpio input pin on the SoC, handled by the standard gpiopps driver processing a pin-change interrupt. PPS(2) is an FTDI 232R, a USB 1.1 serial adapter, connected to a port on a USB 2.0 hub that's connected to a USB 2.0 host port on the Wandboard. PPS(3) is an FTDI 4232H, a USB 2.0 serial adapter, connected to a port on the same USB hub as PPS(2). Unfortunately, the uart driver for the imx6 SoC doesn't support the CTS or CD signals, so I couldn't measure native uart performance directly. I would expect the performance to be comparable to the gpio pin input. As shown above, there is a 2 microsecond latency and virtually no jitter on the GPIO input. The USB 1.1 and USB 2.0 adapters performed essentially identically to each other, with about 200 microseconds of latency and negligible jitter. There was no difference in performance between using the CTS versus the CD pins on the adapters for input. To see if lots of USB bus activity increased latency or noise, I connected a USB SATA dock containing an SSD drive to the same USB hub as the serial adapters, and ran a continuous dd(1) from the drive to /dev/null. Surprisingly, there was absolutely no difference in the results during that run. Most people are not worried about their kernel clock being 200 microseconds off from UTC, even if they're using the PPS signal from a GPS receiver. So I think most people should feel completely at ease using a USB serial adapter as the input device for a PPS signal. Test setup details... PPS measurements are made using the kernel clock. Typically the kernel clock is sourced from a hardware clock which isn't particularly accurate in terms of frequency. All clocks drift; cheap crystals on computer boards drift a lot. Ntpd will align both the frequency and phase of the kernel clock using a PPS signal, but to compare the various processing paths a PPS signal can go through, you must be able to determine how much error came from the reference path and how much from the path being tested. In an ideal world, there would be no measurement jitter, or frequency drift in the kernel clock, and thus all PPS measurements made would be directly comparable to each other without having to ascribe any part of the differences between sources to the kernel clock. I am able to configure a Wandboard imx6 system so that the frequency and phase alignment of kernel time is "perfect" with respect to one of the PPS inputs. Since all the PPS inputs are sourced by fanning out the same source PPS signal, any difference in the offset or jitter reported by ntpd directly represents differences in the processing paths taken by those signals. The test setup consists of a commercial precision timing system which generates a 10 MHz clock signal from a GPS-disciplined rubidium oscillator, and it generates a PPS pulse that is derived from that 10 MHz clock using a simple "divide by 10 million" counter. So the leading edge of the PPS pulse is phase-coherent with the leading edge of one of the clock pulses. The 10 MHz clock signal is fed to an external clock input pin on the imx6 SoC. Within the imx6 timer block, that clock signal drives a 32- bit counter register, and that counter is used to implement a kernel timecounter. The PPS signal is also fed into that imx6 timer block, and the leading edge of the PPS pulse causes the hardware to latch the current value of the 32-bit timecounter into a capture register. This captured value is then used to generate a PPS measurement that doesn't incorporate any interrupt processing latency or jitter. Because the PPS pulse and the kernel timecounter clock are derived from the same source, the kernel clock will never appear to drift in frequency. That is, when ntpd compares two successive PPS measurements, it will always find that exactly 1 billion nanoseconds elapased between PPS pulses. At startup, there will be some offset between the kernel clock and the PPS pulse, and ntpd will slowly steer out that error until the beginning of the kernel's second exactly matches the PPS pulse edge. I force ntpd to step the clock at startup; that typically leaves about a hundred microseconds of offset, and it takes a couple hours to slowly reduce that to zero. Once that happens, the system is in a steady state, where ntpd will never again have to apply any correction to the kernel clock. You can see this state in the output of ntptime(8) which reports on the kernel clock's phase and frequency. The important numbers are flagged with => root # ntptime ntp_gettime() returns code 0 (OK) time e0eed6a9.b6875d58 Fri, Aug 2 2019 15:35:05.713, (.713003500), maximum error 8000 us, estimated error 1 us, TAI offset 0 ntp_adjtime() returns code 0 (OK) modes 0x0 (), => offset 0.000 us, frequency 0.000 ppm, interval 4 s, maximum error 8000 us, estimated error 1 us, status 0x2001 (PLL,NANO), time constant 4, precision 1.000 us, tolerance 496 ppm, => pps frequency 0.000 ppm, stability 0.000 ppm, jitter 0.000 us, intervals 0, jitter exceeded 0, stability exceeded 0, errors 0. Finally, for making these measurements, I wasn't worried about jitter and latency that occurs down in the "handful of nanoseconds" range. For example, a single PPS source is fanned out into 4 different inputs on the Wandboard, and I didn't worry at all about things like using equal cable lengths, because I was looking for differences on the order of microseconds, not nanos (and with a 10 MHz timecounter, the measurement resolution is 100ns, so I can't see those little differences anyway). -- Ian From owner-freebsd-arm@freebsd.org Sat Aug 3 07:10: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 C02B4A9117 for ; Sat, 3 Aug 2019 07:10:31 +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 460wCp5RNPz40lg for ; Sat, 3 Aug 2019 07:10:29 +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; Sat, 03 Aug 2019 09:10:27 +0200 id 00F406AA.5D453363.0000DC4D Date: Sat, 3 Aug 2019 09:10:19 +0200 From: Milan Obuch To: freebsd-arm@freebsd.org Subject: Attempt to use uart0 on Zybo Z7 Message-ID: <20190803091019.2d067756@zeta.dino.sk> X-Mailer: Claws Mail 3.17.3 (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: 460wCp5RNPz40lg 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 [-4.20 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; 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]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.976,0]; RCVD_IN_DNSWL_NONE(0.00)[72.65.245.84.list.dnswl.org : 127.0.10.0]; IP_SCORE(-2.92)[ip: (-8.28), ipnet: 84.245.64.0/18(-4.14), asn: 16160(-2.25), country: SK(0.06)]; 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: Sat, 03 Aug 2019 07:10:31 -0000 Hi, Zynq SoC has several peripherals available on its PS/ARM side of thing. Currently supported list contains UART, USB, ethernet, SDIO and GPIO. No driver yet for SPI, I2C and CAN. Available GPIO pins are on JF6 (MIO pmod connector), I tested them as inputs and they are working as expected. All other peripherals are present in pairs, so I decided to try the simplest one - UART. On Zybo Z7 we use uart1 as console for both u-boot and kernel, so the unused one is uart0. In order to create its driver instance, it was necessary to add just &uart0 {status = "okay";}; into dts, create dtb from it and use it for boot. This is enough for uart0 to present itself as uart0: mem 0-0xfff irq 6 on simplebus1 in dmesg (or uart0: mem 0-0xfff irq 6 on simplebus1 uart0: fast interrupt uart0: PPS capture mode: DCD in verbose boot dmesg). That was really easy. Now we need uart0 interface (rx and tx) to appear on some available pins. According to MIO-at-a-glance table in Zynq TRM (section 2.5.4) there are two possibilities - MIO10 and MIO11 or MIO14 and MIO15. I played a bit with zy7_slcr_attach() function in arm/xilinx/zy7_slcr.c file. With some printf and RD4 calls I can see MIO pin configuration - currently we have no pinmux for Zynq, so I decided to try register access to check and eventually program. Studying existing configuration and Zynq TRM, appendix B.28 for registers detail of slcr leads me to believe I need something like WR4(sc, ZY7_SLCR_MIO_PIN(14), 0x16E0); WR4(sc, ZY7_SLCR_MIO_PIN(15), 0x16E1); to do the necessary pinmuxing. As access to slcr register is locked, it was necessary to add call zy7_slcr_unlock(sc); before in order for write to be executed at all, which I verified with values being read back correctly. Without this call no change to registers was done. Unfortunatelly, I am still missing something - I tried to create physical loop connecting pins MIO14 and MIO15 (on my board connected to JF9 and JF10 pins) but nothing - typing anything to 'cu -l /dev/cuau0' does not make to read it back. Did anybody any clue what I am missing? I verified I am connecting the right pins, but I see nothing arriving back when typing... Regards, Milan