From nobody Sat Jan 21 20:18:16 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Nznk02vrwz2t7lb for ; Sat, 21 Jan 2023 20:18:16 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Nznk00hcqz3FH2 for ; Sat, 21 Jan 2023 20:18:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1674332296; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=7jK8bCWprV5WPnCwrMwWr0Op3ThaN3HN2/EIQf+ussQ=; b=SoARma2Fc4ZqH1nNJRt/mJiIUmKowF015Z/Zx4IqyKh5qNfdU2jP0wFqOSx8kPrmrh8oHN ePf7vT/e3UWLD2CayW/3Juv92Nw5QKsFz0txdWw0w9AFdySo9swSgXHGOWf3wsu+n2/NWR ejOrnpHLsmxNxIhK3b9I+G4Cc3k0AYxB+66Og3VavRfI+cV5xUFDr14FhMFB3n1I5BIM2H KVPOVDutRH3GecgbgLwhJMLG1pvI9AjShWKZJs/Enxj8H6JDoARnYGlMHo99rwZa2TpXOv zK2NMIPO6XOufDFSw946r2BWfupgOvezGk2ki1Xd7SoSynXmpsyNU2mf9w6cgQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1674332296; a=rsa-sha256; cv=none; b=ghL9RDuUtJ+bYfe943X8H+V807Xw5ua89Swbmf07tc9fWWYH8WDijvHRBVFs/T8pnFIN7m EM+Y12YiIS3jt4gcHPl0FtqzRdQQYBGxajEF6hgyY65iC/gp4Svqfia14zVekVu7RIFmGv 3cxhnUTmhhXPxtgUZRR2gIWxFd4dNtVMiHlq+krsgaEPVW+znmbzXf4xJYh5iKmdYaFZpV NKxoPPW8ZPp63KY/2PPgO9HQE+bnwIlLmfoU9v/zQJZIg6LU3V52e1Kjlnt3baLuVLkobY aHc+2jdbX58BhvK0GaG2OJJ1LOPOCO0FOFpVf9f25kFSa+UOPhXJMn9R7/qlDA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Nznjz6cQzzN7P for ; Sat, 21 Jan 2023 20:18:15 +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 30LKIFBE033054 for ; Sat, 21 Jan 2023 20:18:15 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 30LKIFb8033053 for freebsd-arm@FreeBSD.org; Sat, 21 Jan 2023 20:18:15 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 269085] USB device not recognized Date: Sat, 21 Jan 2023 20:18:16 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 13.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: greg.bal4@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D269085 Bug ID: 269085 Summary: USB device not recognized Product: Base System Version: 13.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: greg.bal4@gmail.com I have a USB stick that's recognized under Linux but not FreeBSD. I've tried multiple computers running various Linux distributions and they can all recognize it. But the same hardware running FreeBSD 13.1 or 12.2 results in the following errors: Jan 21 13:58:24 desktop kernel: usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set= for USB mass storage device ACTIONS HS USB FlashDisk (0x10d6:0x1101) Jan 21 13:58:24 desktop kernel: usb_msc_auto_quirk: UQ_MSC_NO_SYNC_CACHE set for USB mass storage device ACTIONS HS USB FlashDisk (0x10d6:0x1101) Jan 21 13:58:24 desktop kernel: usb_msc_auto_quirk: UQ_MSC_NO_PREVENT_ALLOW= set for USB mass storage device ACTIONS HS USB FlashDisk (0x10d6:0x1101) Jan 21 13:58:24 desktop kernel: usb_msc_auto_quirk: UQ_MSC_NO_TEST_UNIT_REA= DY set for USB mass storage device ACTIONS H S USB FlashDisk (0x10d6:0x1101) Jan 21 13:58:24 desktop kernel: usb_msc_auto_quirk: UQ_MSC_NO_START_STOP set for USB mass storage device ACTIONS HS USB FlashDisk (0x10d6:0x1101) Jan 21 13:58:31 desktop kernel: usbd_setup_device_desc: getting device descriptor at addr 5 failed, USB_ERR_IOERROR Jan 21 13:58:34 desktop syslogd: last message repeated 1 times Jan 21 13:58:34 desktop kernel: usb_alloc_device: Failure selecting configuration index 0:USB_ERR_IOERROR, port 4, addr 5 (ignored) Jan 21 13:58:34 desktop kernel: ugen1.5: at usbu= s1 Jan 21 13:58:38 desktop kernel: ugen1.5: at usbu= s1 (disconnected) The device is a Taheng 64GB Mini Voice Activated Recorder. https://www.amazon.com/Activated-Recorder-Taheng-Recording-Interview/dp/B09= Z8C8RVX/ --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sun Jan 22 01:12:22 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NzwFl5XmGz32DWh for ; Sun, 22 Jan 2023 01:12:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.146]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NzwFk5KGzz3nXv for ; Sun, 22 Jan 2023 01:12:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Ox3W9mNb; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1674349960; bh=z1K8uyzE4CTsIRBaRt9y7p6fAC8SCGzI++eJI54Bymw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Ox3W9mNb5Ci30lLVTL8Y6pGbLS3/+QRdD1Itv0Rj7QT53YUy2VQW3ew9SKIZuUK/k4nMXqb322KDtUKd5VLQxo64Ix7MvA6Xj92KuqYTqi51LhUXNfpTVIgZZjfjVMS8z/rNCx6lFkdSl54+I3TG8hS50OuXEBDbwoKu7hD66vnTPK2XRjGa6+1wHLL47EyIic/wMYMrNUJcO5NZFcOXZ61exiD5CXRI3t8FlalzlWMThJzegCXeCAqVe0ou2C7q0yUQDaRgp7G6Z1O0jMsyrB99EQhaiWAuNTB/ZF4UZyBYcKFozEJXXJ4Q90ITgImRutPBYjx38ZsOXRu1VkHXkg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1674349960; bh=Q/tGZWjmCZeuYDIpAA8qGCJVzFpPydmlipn8cwl1TE3=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=c1qC//y6OLC6JNQ3xdK1WLII4lkC9k/PpcaqyCUSiuH3JZ0zaELXxHcLOfQKpaMv3BQtm2CVmqg0cQ3QNYyuiD2pFU5vzZhxuoDEHqi49IThNSIII9VNng9/U7sT1YJs1WyDFOr0kDH3sXl722bfzGgxjFSRPEqYu0s93irF4HP//tsiOClqLOJctYAdXX43tb8D7jP1TRURmkNYa07UXdyk2+lGklK6IQS9lhaKN3kmFwFfjkus6Ftfnm7Hf780x2p/lNqypbDoY6EUcVQPEkktbNFdmQL8+7kG1Y7/h16ogj2A/hlZlhtzvxWFralXvGxLhPsnvK4wUtC3i6TiGw== X-YMail-OSG: 50XLzd0VM1k4v73lbVI4ij6Df3A5NxV6saP0uH.y_3TF3iqaE_jnCVNzaCYci2Q Bxuko7OnrM9lr011p4nCONEcyCGdDVGZT0VXCFGU_DApyq38cYH6hm5jsyeQ16CDncX_9HEyOGzG d4ozC7VXa.PerHPgqhQLZu165W9g9ghBnI2VcwuNfITM7sTjmVzcBvIz9njtQaOSJV5R5tgQtd2P TOPHEbLPObFS9On7KGXuan.JP9eMUOwHwXg8Aq0u.62u6NIwLoW6Q3OnYsPeoqFXZUfwakiWX87g xPe_JivU.l1qi3fx3JXyAwicRELSsDBAFyfObK6TP098pVgR3hUsC8f06WijrbCZ9K6GhFY5dkm3 nn2P2Qf4MprtZtubq0y6E_Y1UvNgguI403bTOEecaZd2QB7cZFgbnmgj97uwL9JUE4gDhQDvKibR bPRPxT1ts6NQ2ohMmqLbjm6VEY9hJUQ5EzNjGPckXRIXARE7BXzxP1_MDup.oJVqGCDbfuXyWjIJ UhvsPOsq_teeT1SsW6p24v7fdUTPenkqL45R0uoUQNWQNGCNlEjZ23yBoyk2hvhWowcJrXrNjIYj fp6iGno.dhoqaZn0EgMiOT_MH4v9p_XA2ZFtIiDQJC4.aVAz3EVn04UzG_VrGDsft8dAaDQL86Lq maiqjNvtLvA33A97JG4Ts_6illr2znwpc8Ho.fPGqwkxfvObdBr_4g1J2XFgfUdgeohKIvC4wZ1j Su9vRMiudAx23gfEtoL8uu0x5zg6yVJSgtnTb5UKMmXqxQ3rxRYlbYylrWgpJS9t.mGHWt.T_dxy 0wGV_dlmooBqlQnJX9vNXZ4LGWJDsd0qd_FN9RBICX7Ddg66myq0CKmCjP9JntcGbnTxvwpo656l Kpwo8dKD47wJzLyNgYLu7VBf8Nj8W0Tas3yj._xPcTceJbCZ8xkb8BJRXmkuR.x.dX26OGJcs0nE KrK8KivPD6y1czOCQpqGSIwgUIAettFGkNAb71pM3SJj8VKjZd7dKJb__6HJuyk5Jt.gmErpwr6q jrGJ7ibg33UuXxb5WQf49qtenTibwFbAv_.u_3WF2krZrXUwd6MR2hGSpnCGBCzPJeJN0cS.i7iz WJkXZ69Joo0NrwW3Zkc_yyQml2ga7PKqGIUjeMRALa.8jH.HPRKcLSQRa_JFrRW3VTonWtkCZH05 Jfi6_HnJ.OmQX2m7XJdlufIMQqp1lWGF3N_0SMC6toX8gEKSrhTFHO2ThbGCTVXtmm540pMSSq_2 KWwFshsgxTjLpE.8.lgG0xsJ1Sk3AcRR.j1JgIp2DsJXKiACtzbf7Olor7oTtTcg9eWxvM_vd1_E 5Hb75z4efw6yv19pPyJpD8j2UEdFwrqpVdqIugOp5bsJvvio61WFobemLJkwytNc1N8K4G8YfwKG 098ex05aE040JKTknLVyrnKBwGdFQsQmmPZ.4ItQYD_i51FdCdL8qViaueQaT9AOx59.tqVE6YWo hbFM2_AsQlyK9EowZvynoJnoRTeXHAbFcHUJ_eWw.ejygWElGGHF6K.8lBlNRdxIIpQiNlf25E9g 1JEoHwS1WFuepdRNHyJDzXOwSbmRKQiHCZUtoLYqS_2iPd3eDuLJPFDylmW8OPnBhtGlp5nCcM6z PHouBTN1FkPOCImo31iTsWgWCk_yYNd1n5jicnjlFpHsasOP1cLI10tR.eskeKUEF6eSLArimZuP rh9h2nMTryzS1h8jkinvpGYehJI_CjcN.WtldcumZPdYqwPQirx5F4qOR8yu3Hh0O2VclKPNAxZM 88itoMOFPujrhyArk2AkYAW4BtYYsIKITjquk_Lc5agdtJnRc0m0CuSUUZKfzH6KvaZaAj82VXrw kvefB6KvqxtlSFrH0LuTPbcbprbKJqI.N3H6q2C_.zXGe1J1USOkpRqkUHidsXn9yTSH_jN1kFll GPEimjoBq4fc5KK4ITYrkSdOn3lHPcY3oy3goH8VXcarEF4YsNm.jHcjciD2WS2fgp3rB64wPUK3 Y_1.bIvYCvyXKM8g.DBWjtF9cTN8oxAmK4t.CBAT.WO6kea7hrnksLFZTY8unLIOwc7w0vHsSZ63 lN9SI3kGcBlAP4hJUSztcYYI6AgdXN5Nt9dBmsY_ZojxG6vmQvQl5KM4ezzlgmQmW8bUlU5JZwhK S8fq7uwjt.YcpqgjTYx9F01vJocX4SPjuag3.5NHsGByYQ3P2LmJAD1hT3LNug3V6r8fvNW2aPb4 Or4f1r56szaMHlrRPybXmlDqQ9Hw19QyTnuJN69XFQjguwEKCk3Wz.eZNeZbiEVckRGYw0sNYXBE s X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sun, 22 Jan 2023 01:12:40 +0000 Received: by hermes--production-ne1-749986b79f-4lqrp (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 574f1416dc3dca91b73968451bb2ccea; Sun, 22 Jan 2023 01:12:34 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: Raspberry Pi 4B not booting single user mode on FreeBSD 14.0 aarch64. Does it work for you? From: Mark Millard In-Reply-To: Date: Sat, 21 Jan 2023 17:12:22 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Fred Finster X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Spamd-Result: default: False [-1.68 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_SHORT(-0.18)[-0.178]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146:from] X-Rspamd-Queue-Id: 4NzwFk5KGzz3nXv X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N On Jan 20, 2023, at 06:22, Fred Finster wrote: > was just trying to boot into single user mode from this documentation = below: > https://people.freebsd.org/~rodrigc/doc/handbook/makeworld.html > Once in single-user mode, run these commands if the system is = formatted with UFS: >=20 > |#| *|mount -u /|* > |#| *|mount -a -t ufs|* > |#| *|swapon -a|* >=20 > example I created this blog post: = https://ghostbsd-arm64.blogspot.com/2023/01/time-make-j4-buildworld.html > I could boot into multi-user mode but not into Single User Mode on = this Raspberry Pi 4B. > What do you suggest and how to trouble shoot? I turned on verbose = mode and saw that it hung after starting /sbin/init > but do not know why this aarch64 ARM64 BCM2711 cpu hangs on FreeBSD = 14.0 going into "single user mode". >=20 > This Version: >=20 > root@Fred_RasPi4B:~ # uname -Kmnopr > FreeBSD Fred_RasPi4B 14.0-CURRENT arm64 aarch64 1400077 > root@Fred_RasPi4B:~ # uname -a > FreeBSD Fred_RasPi4B 14.0-CURRENT FreeBSD 14.0-CURRENT #6 = main-n259952-7e2600ea7be2-dirty: Sun Jan 15 18:14:05 PST 2023 = root@Fred_RasPi4B:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-VCHIQ arm64 . . . I've never tried GENERIC-VCHIQ. Have you tried testing a standard build on some media, such as trying a dd of an uncompressed: = http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/14.0/FreeBSD-14.0= -CURRENT-arm64-aarch64-RPI-20230120-43703bc489ec-260163.img.xz and seeing if the problem replicates for that in your context? If it replicates, then at least you know it is not something more specific to your context and other folks would be able to test similarly with a sufficiently analogous context. But, if it does not replicate when you try such a test, then folks likely would have to try to reproduce your context to have a sufficiently analogous context to test. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Jan 22 02:34:59 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Nzy4y3ppcz2slfF for ; Sun, 22 Jan 2023 02:35:14 +0000 (UTC) (envelope-from jjrushford@gmail.com) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Nzy4x4Y5Vz3v03 for ; Sun, 22 Jan 2023 02:35:13 +0000 (UTC) (envelope-from jjrushford@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=YqPPZmAn; spf=pass (mx1.freebsd.org: domain of jjrushford@gmail.com designates 2607:f8b0:4864:20::132 as permitted sender) smtp.mailfrom=jjrushford@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-il1-x132.google.com with SMTP id f8so4621789ilj.5 for ; Sat, 21 Jan 2023 18:35:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:date:message-id:subject:mime-version:content-transfer-encoding :from:from:to:cc:subject:date:message-id:reply-to; bh=xjZCBw1jPoIRtyZwI2J9h6F2IA76Pu9f4E81UgeDeJM=; b=YqPPZmAnN7L9Vhl4vWZx0OjAyiJqsbpUwht2USWXDBoY2XlQXiKGpPOzLrCJn2A92N sZQWPbp3QKNhxWjpniFUHt65QKm7Bxms7NfP/WYMt+04+XcNX7FQLISB05SkY4g7e+X8 VpQzt7udDHMxQP6bZDkyun5uXjPlRzXKqQQy2gIH83RNY6XJ2McIdp//x1YZiV8DY+N6 VbPoX0wGY0ACmJiSrTgVWFT4eP2fu6laQo95zuyRzXia/wPbywfcPwDAmtdGbuIgq/q2 T9XHqHYqRnLJxyJJgrry2JwNLPvT9L6mccJULPLCi3ex8/7JY9cCBkEJZVaoANVBKjxO PGtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:date:message-id:subject:mime-version:content-transfer-encoding :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=xjZCBw1jPoIRtyZwI2J9h6F2IA76Pu9f4E81UgeDeJM=; b=V8QSGGAziQPcsjQf7eMOMlKofdnTE0vBshLEhwRdjOjGJGoXlB+ysslFLPAPRO5Eme NY1tAa4cZOZvBrugIQ3Uv6Q38FzS6qnUbOIKxeGcDq0RMq8YR+18rSAKPgQJE6L+sWSl L2wirYtJs3hdG9lmLUapC+y6UpK791OGTPIt3sChWwmeEHEktue4B7so2VD2pADwzkHJ T3uXthYoHOHbQq0bH1Rw52SMvtM7DJ+ZZX+T9E2Fg8NFLgyE2z+C4FZcSH5r3WAWnIZ7 F2gcjRnk1vWKXfL9p3hllV3UZ+KZcLTnPx6yVXTGpXHgZjwOrIIAAFDFhxhZrkvS8I/X EqeQ== X-Gm-Message-State: AFqh2kqfuQautAXi7MSqJR1chaOhpRX5NXDRwObejoGqhDRtYyk+XJBi GjajG+YjhgXYSyRgn3X6SAlYg7vlt3/MHg== X-Google-Smtp-Source: AMrXdXsuO3ljyNl40vWKsbdom6BUWqXT952M4zkYltb0R0RIPSOkilaBIcp4WiXq2gIln9B7kZfeAQ== X-Received: by 2002:a05:6e02:492:b0:30f:36b1:dfac with SMTP id b18-20020a056e02049200b0030f36b1dfacmr10626783ils.10.1674354911366; Sat, 21 Jan 2023 18:35:11 -0800 (PST) Received: from smtpclient.apple ([2601:280:587f:1450:d1a3:f492:d408:e2b3]) by smtp.gmail.com with ESMTPSA id m4-20020a056638224400b0036c8a246f54sm13798789jas.142.2023.01.21.18.35.10 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Jan 2023 18:35:10 -0800 (PST) From: John Rushford Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Pi 4 uarts Message-Id: <6496EB45-1CC8-4BF3-8A5E-A90039485D2F@gmail.com> Date: Sat, 21 Jan 2023 19:34:59 -0700 To: "freebsd-arm@freebsd.org" X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.995]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::132:from]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_EQ_ADDR_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-Rspamd-Queue-Id: 4Nzy4x4Y5Vz3v03 X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Greetings, I have installed FreeBSD 13.1 on a raspberry PI 4b rev 1.4 and I am = trying to use the additional serial ports that are available with the PI = 4 with an Adafruit ultimate GPS card. I found that it was problematic using the first serial port ttyu0 on = GPIO pins 14 and 15 as data on the line from the GPS would interrupt the = boot process and I verified that I was in fact able see data time stamps = from the GPS card on the first uart port once I got FreeBSD to boot. Now since I do not wish to use the first serial port, I=E2=80=99ve built = the rpi-firmware port and copied all the uart dtb=E2=80=99s to = /boot/msdos/overlays and I=E2=80=99ve tried enabling the uart=E2=80=99s = in /boot/msdos/config.txt with =E2=80=9Cdtoverlay=3Duart3=E2=80=9D for = example. =20 Enabling them does in fact result in device entries created for them in = /dev but, I am unable to see any data on the corresponding ttyuX or = cuauX ports. Just to eliminate a wiring error, I installed another SD card with = Raspberry PI OS, enabled uart3 and I am able to see data on uart3 = without any issue confirming I have everything wired up properly. With FreeBSD, I have set the proper baud rate on the ports and I=E2=80=99v= e tried disabling flow control on them, using stty, but no matter what I = do, I never see any data on them. Unless I=E2=80=99m missing something, = I can only conclude there is some bug in FreeBSD preventing me from = using these additional serial ports. Has anyone here on this mailing = list been able to use them? If so, what does it take? thanks John jjrushford@gmail.com From nobody Sun Jan 22 03:18:03 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Nzz2f12Tsz2srJH for ; Sun, 22 Jan 2023 03:18:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Nzz2d55F9z3wwx for ; Sun, 22 Jan 2023 03:18:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1674357495; bh=P0O+Rso1P25p0atIX4w6rYzKNZrbBCBJzZYjI9r42I0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=qQ8c1rO+lZbq6lRPo9DqTAuFnLLgAg9asfzr3vPGUq2PTQV7qBmCu0m+SQ8W9dQHr1q46o5vUYqIS+IaxuaoywW3ztDDYREK3CRLiSVAsIyuF1ne8klO53mVsNkxifNm4IX24b3lpVvdSyWxS6bgTgPpudU44tkBHqHv3SRbKkvMOMSmZDp8ro94I7oP/ATvBT2EDfzVbfG7jFNcSc8gkYGLD3/7//A3Tr4Wq3a0a56QOw4kF8IA9x60gQgip7lvO8g1t0FnCTDalsbkYpteXVCgrXWeRQqMZJvn4W6vy4WayKtZfi7Nfn4VxaqF8492PFckbPP/TunqD/opST9QIw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1674357495; bh=CJdJysXHFkGuIcTYDU5L4le8ZiBbN9VgP7osYCx0W6K=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Bpx3PFJneTce/4rHNHN72WrHDAPKZ75xw4unhuDgnEQTUgWrZPWE37//J37yGxLGDJJF3opJpa9Th1lpG0+nDINEKbG30COWUe+SnKwuMrauliY4s0+GVSU7M2dRuY7US8kAKApRogBtOe2I11vJDVFaooChy48tuuQqE4EJpT11yfCwwE96X5FKemyWR8ZVCx/AjE3WeKLGmcf29IPJn4HwCxA7eZrmeYQP7SvlRRdVhRDqldTyt9B48zG1I/btIjCQlKE+efnCs/PbxwTHBQ9AnIb4eA+xIyBH0wn7pNXQ4j7cvZOYnSXVUrx/rStLHD+s6VCfe1fdeFm+qtcR8w== X-YMail-OSG: 3eqmzdIVM1mGqFuth_mLH9FgbjUmLRPge3H6KV9GQeFFEv7pk6Su4ACv9nXHEwI 0WKyiw064t7KL_t9pXxjCY8nlVoAMWVTWVZXx92MWViBu.548IlSNyVJR5aI.Y0B5WyZLhCrExtU 63CONtsgHtUr4L.LgMz_51hexsEM5yaKD2fJ0HH77Cx1vSkoG8af0LOqCmL7KdpV9VboOs3VYI.s LoTiw8NGU5rzdzsaZBPHWgQLwBh08ERMjOEgeOwVyNvWUaM2c9BscC1rbEhnee07SvB4edbpLOCN C4QCR8uj1UWTL9Yr5boxC7Rb2VZcN2k1Sn7VCMOZpRWWa.HXxApwctZM7YDqx0CPBMacBPHZTD5E QnJ7xAvsTTvlF.dl115J4lN_st8McJ2uyZpUrJ4508D4ppawOreYaDPa1R7vPyy781pMIb4JWB2c CyEuym_.WTcFBo54HzWLCXxKwumpAtYw4PY.CAAaUUO.YTwuVOurz7FP5WqErMdyHSNaGkA5.9pm tgjxPLUAXuJ8.U9FVb4_FLWRGaK4CirsaYfKBBe2Hy4gr6zp3VpjFREoyTV0irc_EB6y1kc8kJ1M VrwrYv6JdChDLbUkY3iFAn_SBgg_hsV8PBRraTqS0rXUrDZjFScCcfOvxim16Kh7aebJFdoFLAGP XV72KV.3y47xK4WFq.mQjwILjtSxMwShzKbS91FIpU5iu98.1mstak3lfHGfiS87RugF8FzZFtPe F_6Bnziw4DnnJOHGpV9aPt9ucuAJuNPTk8lATJZvtiAow6CsbmKP5pzJwUu8lQkpReYaBpwcynkG uRlFrWqpHKraJ2M.mOlWhIieYUjGXoNqvc6f80G84JO0XH9PcnK2.b_9E6N8KfxATdsgocQz0f_b gOgcQqWdU9NE2_KqiMofyz07bKYAX_hdHXadNc9ISIVqFHxdxUZzXrgtXIXEH0YuIZ7AHXpjWxgm SWN1tXodYxCpLEYHXx63nmdrApmodTOzuRIm_d.iEEQPCIyc8LXZitBYunVQnHSVM.ZAyMGbmT2S KGl7AwbrhAq3e1NJ2cE5iwOZX43o5_zAcBP.HeUsKfsn8WMrSXttfy2skl5MyR99AsrnW4.vXDWQ 9wHlxAD1bg8oAJx8zJIlmcSShLuTBtnaBzyJcPE5nKkKfttglsxViJC5ttqlOMfTnv54m3gbIqhg KJXuQPFCiRWSuuzko4ciRe5FjcQzMEpbn0zm11sK6AQQ2Wru6JDFw.qU0Cgh9kmNk0r1d08yqKh7 5xUPvy9alWDFxu8ylqxU70mu.DSNv40VcAWDS6_3qDC11Tv0GoZ.FaBhQTQCPePLzjPOrgRKg2w9 6_Jvieb7fpUgUQX9zgngCrzp86RiQtF0jXB1mgoeA8m3YBS5qMYNWUKDuqhPRewjB7ICMBrEAEM7 06.fRF58EZlabmjQlCjgm17hUR81AvuIyj6RR7QWH9RN3vzBEYZcn5pqDkuXxGEAciw2cCO4wkig YzpPNKiffTr3coSvE193UoQwYn9A7mQD39QE7dtwz5xY7ifGZcVcln6Rrq.Bat1NwFLZWB0mPQkm ssQVkC7CF0D6C.k2ajj_OcPhybrSu_kNG6zoyrhD0E3iUvSZv_PyZ1KUGriptBXJXLJ.XBJxnkhR QiSCuzagTBWWhiQ3G1jHms1MlB357Et0QJPxcI8GFABbFqeFzyZEObXWb9STP8FNRbHk5XRROJCo _3isIxspMcv4g0Xk8O1i84C1DwP9ASXnYqLRA5tqVw0WCYH9_Nxbb4IsoT37oi0oaABfbkIi0giy HFhjGo3BPOpCLXWwwIhBWO7emYqr.DKCgulhMtjA.6CWZEpphiV0HxUAck8h31kyRRB5JPRziMTs e7gzMe8yG8DaLgpVO2HeonOOyaBmIByRPvoJRcgKbBketeQHc8q6dF6Jy5DTQkec7MMTVB1KM6lb 4JOr906DhI52clvt0arK.qpuviBSCkFmatuSmDPuyxf9S9Rgs82jw_drO7yXe_X1t7DlfCQ15xN4 CeFfeFCEe1mx6VEjYqlq5Tw9H4eCffCXKChDyXdV8iS25EtMSn57jiAS0zxVlJcOuPIkzVuNQbyg JStb5D2d1VGLFqC1jHrXKa2I2EBoAhFwQcY3svw_ebVF9QCiFyohsgX2NHa_Tl599WyPWupPCePg akb3DnQ8m3o1WWHO0cFNQRaqNNn36ndD08A3jKO_1xRSzxK39KCUxKZCnmSzX0s7UfaQw8kAgKk. lNbQL6YyNVlGzoNaVaEz039SadRV5g8cu7KP7i00E2ZZ0iMqfD1h79UuGGST_qx5RmkNjJhPFK7S Q X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Sun, 22 Jan 2023 03:18:15 +0000 Received: by hermes--production-ne1-749986b79f-29jwl (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1063d271c8d0fa56962f2df96a3052c8; Sun, 22 Jan 2023 03:18:14 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: Pi 4 uarts From: Mark Millard In-Reply-To: <6496EB45-1CC8-4BF3-8A5E-A90039485D2F@gmail.com> Date: Sat, 21 Jan 2023 19:18:03 -0800 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <07307CEC-9C0B-42AC-8D17-2C81427081A0@yahoo.com> References: <6496EB45-1CC8-4BF3-8A5E-A90039485D2F@gmail.com> To: John Rushford X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Rspamd-Queue-Id: 4Nzz2d55F9z3wwx X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Jan 21, 2023, at 18:34, John Rushford wrote: > I have installed FreeBSD 13.1 on a raspberry PI 4b rev 1.4 and I am = trying to use the additional serial ports that are available with the PI = 4 with an Adafruit ultimate GPS card. > I found that it was problematic using the first serial port ttyu0 on = GPIO pins 14 and 15 as data on the line from the GPS would interrupt the = boot process and I verified that I was in fact able see data time stamps = from the GPS card on the first uart port once I got FreeBSD to boot. >=20 > Now since I do not wish to use the first serial port, I=E2=80=99ve = built the rpi-firmware port and copied all the uart dtb=E2=80=99s to = /boot/msdos/overlays and I=E2=80=99ve tried enabling the uart=E2=80=99s = in /boot/msdos/config.txt with =E2=80=9Cdtoverlay=3Duart3=E2=80=9D for = example. =20 > Enabling them does in fact result in device entries created for them = in /dev but, I am unable to see any data on the corresponding ttyuX or = cuauX ports. >=20 > Just to eliminate a wiring error, I installed another SD card with = Raspberry PI OS, enabled uart3 and I am able to see data on uart3 = without any issue confirming I have everything wired up properly. >=20 > With FreeBSD, I have set the proper baud rate on the ports and I=E2=80=99= ve tried disabling flow control on them, using stty, but no matter what = I do, I never see any data on them. Unless I=E2=80=99m missing = something, I can only conclude there is some bug in FreeBSD preventing = me from using these additional serial ports. Has anyone here on this = mailing list been able to use them? If so, what does it take? You did not mention /etc/ttys editing. So I wonder if you changed any of the lines like, say, # Serial terminals # The 'dialup' keyword identifies dialin lines to login, fingerd etc. ttyu0 "/usr/libexec/getty 3wire" vt100 onifconsole secure ttyu1 "/usr/libexec/getty 3wire" vt100 onifconsole secure ttyu2 "/usr/libexec/getty 3wire" vt100 onifconsole secure ttyu3 "/usr/libexec/getty 3wire" vt100 onifconsole secure to use, say, none instead of "/usr/libexec/getty 3wire", and other related edits. But I've not tried to get any extra serial ports going on an RPi4B. So the above is just guess work about something to experiment with. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Jan 22 03:27:38 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NzzFg08Qwz2ssQd for ; Sun, 22 Jan 2023 03:27:51 +0000 (UTC) (envelope-from jjrushford@gmail.com) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NzzFf53K8z3y2b for ; Sun, 22 Jan 2023 03:27:50 +0000 (UTC) (envelope-from jjrushford@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-io1-xd36.google.com with SMTP id y69so4259782iof.3 for ; Sat, 21 Jan 2023 19:27:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=NL1tK14ek2Y/rQ9guFFKR0reGVJPOtlGesjwRR6ZtXc=; b=XlD3mCWWigkvvTBtKDtOBqW1igMQ+ZYo1fCuGPNj7oNU8hypErtKr1eoVILxxQ5Ql0 feSr8KKlo4dMqRHsjS6SA91juIEK8FzJ9/BQ+yVn4Ayqk/0fNv12RumuQK476EIWqcZ+ V5F5zZv8AFQesl3jVkbablXBxuJj/5f3f5+08YC7Z4yFQ9gS6860sN3dLUPAhAvxbvDT qOtwR/9DVvh1uTndt/3yJSb1gKZqRBhVLN21uQC1+8LqaRyM6aFfjqzAKAxtJyUanr9Z uvCzDckYqYr5XLVScH4SgPRdtlAlrpmnykTeDnmDQZIifWjys58CQ4oE31Xoxg+TUl5+ l1LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=NL1tK14ek2Y/rQ9guFFKR0reGVJPOtlGesjwRR6ZtXc=; b=jyrctJLJ9kMrqd25dQc7oGsRV9ZeHPCt7k+mw+BxA+uh9m/c2amPS2N3y549Rnvw4B 4dUfIfixvlVKSSPkKSmyarFct9dditsgfzqlFCMY72rDwsdByLN9W0NSzt8PyuWxPNDC kr7noAdZoTHeANqTG4GOIYTIcLqKnhvjBG8UnOa4KbDjZ3nR59q8k4vhtkUq+JizuVDe mZTe3gQlSthK1nSS6yy2wc4QuKd78OdR+OreDGEJYf6ISCmjIHg4hm+2+TkPptHRDEbo TH4B2TerNP2VOJm/NgANd9GyDeKXbVZvrUi1FCpi1KEvtyGayDawZ1gxFVZCAWoTW/px 6/pA== X-Gm-Message-State: AFqh2krWVFEvZz8iCPa2nffACmWes7130SEkSDOCOBys07mVxMQAG8kB TC/N0PPzYWteuqAQyh/xInPsh3w/OXmWfA== X-Google-Smtp-Source: AMrXdXsjw5nMiLoc/gSW5ZQFojXBJxX9nLQqU/HdPxqLfZGoyO3FCwv3/HU6kwVCfDJ7/qkvZJBzGQ== X-Received: by 2002:a6b:e61a:0:b0:704:d0d8:632b with SMTP id g26-20020a6be61a000000b00704d0d8632bmr12984871ioh.16.1674358069680; Sat, 21 Jan 2023 19:27:49 -0800 (PST) Received: from smtpclient.apple ([2601:280:587f:1450:d1a3:f492:d408:e2b3]) by smtp.gmail.com with ESMTPSA id w11-20020a056602034b00b006f8ee49c22dsm14941879iou.10.2023.01.21.19.27.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Jan 2023 19:27:49 -0800 (PST) From: John Rushford Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C7B40EBF-C50B-4CB3-913E-23EAF42AF00F" List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: Pi 4 uarts Date: Sat, 21 Jan 2023 20:27:38 -0700 In-Reply-To: <07307CEC-9C0B-42AC-8D17-2C81427081A0@yahoo.com> Cc: "freebsd-arm@freebsd.org" To: Mark Millard References: <6496EB45-1CC8-4BF3-8A5E-A90039485D2F@gmail.com> <07307CEC-9C0B-42AC-8D17-2C81427081A0@yahoo.com> X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Rspamd-Queue-Id: 4NzzFf53K8z3y2b X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_C7B40EBF-C50B-4CB3-913E-23EAF42AF00F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Mark, Thanks for the reply. I only have =E2=80=9Cdtoverlay=3Duart3=E2=80=9D = in the config.txt and with that entry, FreeBSD creates /dev/ttyu1 and = /dev/cuau1 along with the .init and .lock files. So, I tried with this entry in /etc/ttys and it was of no help, still no = data: ttyu1 "none" vt100 on secure thanks John jjrushford@gmail.com > On Jan 21, 2023, at 8:18 PM, Mark Millard wrote: >=20 > On Jan 21, 2023, at 18:34, John Rushford wrote: >=20 >> I have installed FreeBSD 13.1 on a raspberry PI 4b rev 1.4 and I am = trying to use the additional serial ports that are available with the PI = 4 with an Adafruit ultimate GPS card. >> I found that it was problematic using the first serial port ttyu0 on = GPIO pins 14 and 15 as data on the line from the GPS would interrupt the = boot process and I verified that I was in fact able see data time stamps = from the GPS card on the first uart port once I got FreeBSD to boot. >>=20 >> Now since I do not wish to use the first serial port, I=E2=80=99ve = built the rpi-firmware port and copied all the uart dtb=E2=80=99s to = /boot/msdos/overlays and I=E2=80=99ve tried enabling the uart=E2=80=99s = in /boot/msdos/config.txt with =E2=80=9Cdtoverlay=3Duart3=E2=80=9D for = example. =20 >> Enabling them does in fact result in device entries created for them = in /dev but, I am unable to see any data on the corresponding ttyuX or = cuauX ports. >>=20 >> Just to eliminate a wiring error, I installed another SD card with = Raspberry PI OS, enabled uart3 and I am able to see data on uart3 = without any issue confirming I have everything wired up properly. >>=20 >> With FreeBSD, I have set the proper baud rate on the ports and I=E2=80=99= ve tried disabling flow control on them, using stty, but no matter what = I do, I never see any data on them. Unless I=E2=80=99m missing = something, I can only conclude there is some bug in FreeBSD preventing = me from using these additional serial ports. Has anyone here on this = mailing list been able to use them? If so, what does it take? >=20 > You did not mention /etc/ttys editing. So I wonder if you > changed any of the lines like, say, >=20 > # Serial terminals > # The 'dialup' keyword identifies dialin lines to login, fingerd etc. > ttyu0 "/usr/libexec/getty 3wire" vt100 onifconsole secure > ttyu1 "/usr/libexec/getty 3wire" vt100 onifconsole secure > ttyu2 "/usr/libexec/getty 3wire" vt100 onifconsole secure > ttyu3 "/usr/libexec/getty 3wire" vt100 onifconsole secure >=20 > to use, say, none instead of "/usr/libexec/getty 3wire", and other > related edits. >=20 > But I've not tried to get any extra serial ports going on > an RPi4B. So the above is just guess work about something > to experiment with. >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com >=20 --Apple-Mail=_C7B40EBF-C50B-4CB3-913E-23EAF42AF00F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Mark,

Thanks for the reply. =  I only have =E2=80=9Cdtoverlay=3Duart3=E2=80=9D in the config.txt = and with that entry, FreeBSD creates /dev/ttyu1 and /dev/cuau1 along = with the .init and .lock files.
So, I tried with this entry in = /etc/ttys and it was of no help, still no = data:

ttyu1 "none" vt100 on = secure

thanks
John
On Jan 21, 2023, at 8:18 PM, Mark = Millard <marklmi@yahoo.com> wrote:

On Jan 21, 2023, at 18:34, = John Rushford <jjrushford@gmail.com> wrote:

I have installed FreeBSD 13.1 on a raspberry PI 4b rev 1.4 = and I am trying to use the additional serial ports that are available = with the PI 4 with an Adafruit ultimate GPS card.
I found that it was = problematic using the first serial port ttyu0 on GPIO pins 14 and 15 as = data on the line from the GPS would interrupt the boot process and I = verified that I was in fact able see data time stamps from the GPS card = on the first uart port once I got FreeBSD to boot.

Now since I do = not wish to use the first serial port, I=E2=80=99ve built the = rpi-firmware port and copied all the uart dtb=E2=80=99s to = /boot/msdos/overlays and I=E2=80=99ve tried enabling the uart=E2=80=99s = in /boot/msdos/config.txt with =E2=80=9Cdtoverlay=3Duart3=E2=80=9D for = example.  
Enabling them does in fact  result in device = entries created for them in /dev but, I am unable to see any data on the = corresponding ttyuX or cuauX ports.

Just to eliminate a wiring = error, I installed another SD card with Raspberry PI OS, enabled uart3 = and I am able to see data on uart3 without any issue confirming I have = everything wired up properly.

With FreeBSD, I have set the proper = baud rate on the ports and I=E2=80=99ve tried disabling flow control on = them, using stty, but no matter what I do, I never see any data on them. =  Unless I=E2=80=99m missing something, I can only conclude there is = some bug in FreeBSD preventing me from using these additional serial = ports.  Has anyone here on this mailing list been able to use them? =  If so, what does it take?

You did not mention = /etc/ttys editing. So I wonder if you
changed any of the lines like, = say,

# Serial terminals
# The 'dialup' keyword identifies = dialin lines to login, fingerd etc.
ttyu0 =   "/usr/libexec/getty 3wire" =      vt100   onifconsole = secure
ttyu1   "/usr/libexec/getty 3wire" =      vt100   onifconsole = secure
ttyu2   "/usr/libexec/getty 3wire" =      vt100   onifconsole = secure
ttyu3   "/usr/libexec/getty 3wire" =      vt100   onifconsole = secure

to use, say, none instead of "/usr/libexec/getty 3wire", = and other
related edits.

But I've not tried to get any extra = serial ports going on
an RPi4B. So the above is just guess work about = something
to experiment with.

=3D=3D=3D
Mark = Millard
marklmi at = yahoo.com


= --Apple-Mail=_C7B40EBF-C50B-4CB3-913E-23EAF42AF00F-- From nobody Sun Jan 22 17:13:11 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P0KZ14C7Lz3NBDS for ; Sun, 22 Jan 2023 17:13:13 +0000 (UTC) (envelope-from jammin2night@gmail.com) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P0KZ04yq9z4PDr for ; Sun, 22 Jan 2023 17:13:12 +0000 (UTC) (envelope-from jammin2night@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="Xt/1ofYu"; spf=pass (mx1.freebsd.org: domain of jammin2night@gmail.com designates 2607:f8b0:4864:20::f2b as permitted sender) smtp.mailfrom=jammin2night@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-qv1-xf2b.google.com with SMTP id e19so4294690qvw.13 for ; Sun, 22 Jan 2023 09:13:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:to:subject:from:content-language :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=7/W/zeL7UsIxOwMugEcOSAkCckXV3wYDADjfwwB6J0w=; b=Xt/1ofYuQcjrsltUNIc9eec7uolR3jbJveY9h4SdlN+j/2JTkLHAMoXintfKFEsucW bNSMs8Eq/NUHRv5ML7X42bMVDkKMYNgdWkazALkrV2TqsHAeVAf2ex/DJsZIIdLaGboc rfjf5w8pUghpu2uBAFzgOI/8anaYafVgd4RLadWorakNHd5xGBJm8TvzN3Lr3Fosvra8 8ScaxYIci7qJgwNvD+d8+u5+PNk0ZRxRKJlTDEUfbV2qwPGbzPytKKTALR9ZQURBGjHn lOOuCwZas3c7uwiTHPBC6DscB3RnC+crNT24LNDuvR15O3VGev4FEeDRnkKSwZKPKgBa MVIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:to:subject:from:content-language :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=7/W/zeL7UsIxOwMugEcOSAkCckXV3wYDADjfwwB6J0w=; b=CMosijyc2LfNgMb7taTch8nDh33+f9UEEyKsyMwx246jH55V3nNgW81mF+Xk9LrCOA GiaP8MrcOauJthQVwy0BMJ87a3QX0mgfK4VTxsE6IlqvZLxtRYtm+tqN8Tj97aqvHcu+ DJth6/2jZlc9Ih/zuzmwrDcc8gFu859j5PEw50Wf5Ix+wWIXJjrPTejSJWIyWsJE5TwK EKOSd2c4Reikjip0Tjz/zekxnF44RklBBwPFGHaKwYUMUMQekYzRgKbdC/+7zgTykJId lrQxzGxA2Sqfe9nzDk2bAye4IXwkeP+C8zURHLkvJY5oMK3bbXN8tQikdfwkt0Jqtcjj TJhw== X-Gm-Message-State: AFqh2kreUDixT4D4cH52rA4YtZuzXnX1Ti4dioTpLDu8VGjs8hikla0m gApI99q9UkuZKsVRdknY+hONoMndR1w= X-Google-Smtp-Source: AMrXdXtiKNiKtCyt95ezyEm3tQ1k64Kp7HvowFTgGN+B7tN2jYcaeMRdD2f8Lg+61ON6O/l2Xam5Tw== X-Received: by 2002:a0c:cc83:0:b0:536:85d1:1458 with SMTP id f3-20020a0ccc83000000b0053685d11458mr14023088qvl.19.1674407591660; Sun, 22 Jan 2023 09:13:11 -0800 (PST) Received: from [192.168.6.10] (71-150-188-187.lightspeed.lsvlky.sbcglobal.net. [71.150.188.187]) by smtp.gmail.com with ESMTPSA id w26-20020a05620a0e9a00b006fa22f0494bsm10298230qkm.117.2023.01.22.09.13.11 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 22 Jan 2023 09:13:11 -0800 (PST) Message-ID: Date: Sun, 22 Jan 2023 12:13:11 -0500 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Content-Language: en-US From: Michael Jung Subject: arm.armv7 crashing To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-3.98 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.975]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f2b:from]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-Rspamd-Queue-Id: 4P0KZ04yq9z4PDr X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Hi: New to arm but I was given a handful of OrangePI's and I had been wanting to work with GPIO for some time so I though I would give a go. I will be honest, even as a user of FreeBSD since  the 2.x days I started with armbian - it crashed a lot - and so FreeBSD here I came. The crashes are infrequent but present. It will normally run days, but sometimes only a few hours.  I have learned a lot about ARM in general but  still struggle in some area's one of them getting crash dumps. System:  OrangePi-R1 with add on card for 2xUSB + audio FreeBSD Boot image from downloads.freebsd.org FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n259842-c89209c674f2: Sat Dec 24 05:49:58 UTC 2022 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm and  u-boot-orangepi-2e as it's DTS? tables allow the kernel to recognize my add on board  for the Orange-PI that provides 2xUSB + audio which I need for my project.   u-boot-orangepi-r1 does not address the additional hardware. The system sits and runs webcamd and ustreamer and that is basically it outside of what can be seen in the log file - like the wireless driver etc.  Unless I can get the board not to crash I will need to switch to another board - this little board fits my bill as other than what is running I expect to have a little python code to handle other things including GPIO (plans change you know...) My two USB devices are a web-cam and a Cisco wifi stick that is Linksys WUSB600N compatible. I followed the  handbook and tried to provide all the DDB commands recommended when you get a kernel panic and are dropped into the debugger.  I have attempted at great length to get  a dump on the MicroSD card and "dumpon -l" plus the partition table info all looks good but if debug.kdb.panic=1 is set in /loader.conf I only see "Dumping:" on the console and then no progress and I ave let it sit for hours. There is a copy of /boot/loader.conf, systctl -a , all the DDB output and a copy of "boot -v" here: http://mail.mikej.com/armv7-new.log The DDB and verbose boot are mid way down the log file. Other than a fix could someone clue me in if my issue in using the incorrect u-boot loader which means I will need to learn a lot about how to build flattened device trees to support the add on card or is there something wrong in the kernel itself. Any hints on how to get real dumps to micro-sd if that even is possible would also be appreciated. I read hundreds? of  articles and board postings and there is a lot of info out their but none of it has clued me in - maybe I'm just getting too old :-( Thanks for ANY advise. Michael Jung From nobody Sun Jan 22 21:00:46 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P0QcZ4QTdz2t0Zb for ; Sun, 22 Jan 2023 21:00:46 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P0QcZ209rz4Hsp for ; Sun, 22 Jan 2023 21:00:46 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1674421246; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=/2rPnwMNsSpwgLw6e4paKe3KBr7nByRnprfQKLEtqmE=; b=anxWEwvLKnlUifKs7s+6gmvE790v+qiGVri7rnxUl+fHMHqPQFKRLJBwsFUd/EtAvkpSx7 VhCAz2LfttZtTfvfLZJ2loPZbkoIXJcl3YUfWNVrw/3VPjQroXGwvdAGPghbBtmDj9F4F9 BPF1NSLsfq74DV3f5j5Is6xcNRWTFhXNbIQhWI1LZiKyK1xyS0X8T0no76toHQu1x1o4JF wjzju3yR7C49zmHFnWlGfxzWExyM0R39kStYBAr57r/RTz3oPKPIqPUfv7BrK6W3HFuJ9Z N4YprFwQO0elwhSHr1eteKZJIU1FBI+on18PZk/HN8hi0y7D4wRB6YPYQ48eQA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1674421246; a=rsa-sha256; cv=none; b=fqdRmCNrj00UyBijxxeOgmr4uD6CizzSi8BjSF3Xu/Oi5Fg0/nHlFWp+RBRYb7o25I4wVy 9Rz+LXqVVouqNHrtxisxodipp+1yM/9zxluNxh9CLhpKp5Mv3QMmvGlLY7otykwZiMR5or Y/soHdudYP3viX5yPUF9nqN2mxJbDGWSzPk/remkyU/uCXs7S7C0mxH4xcN4BVXdV+aR6t vl7eknR5DIVo6/+TJ1e7AZW8FQBD40EVj32y8myKj6le+SLCO1vpKWycjvW7gpAx6Q0VKq luHPe/pwPXLAPmtRabS5Jse010cwXbgq5CjtlmKdvmjqZf/D8X7o2vVUrldP7g== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4P0QcZ15Jyz13Jf for ; Sun, 22 Jan 2023 21:00:46 +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 30ML0k7v042516 for ; Sun, 22 Jan 2023 21:00:46 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 30ML0kqk042515 for freebsd-arm@FreeBSD.org; Sun, 22 Jan 2023 21:00:46 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202301222100.30ML0kqk042515@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, 22 Jan 2023 21:00:46 +0000 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="16744212460.0a8a.39854" Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N --16744212460.0a8a.39854 Date: Sun, 22 Jan 2023 21:00:46 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 238576 | Raspberry Pi 3B+ "shutdown -p" does not shut off Open | 257670 | mpr(4): SAS3008 PCI-Express Fusion-MPT SAS-3: Fat 2 problems total for which you should take action. --16744212460.0a8a.39854 Date: Sun, 22 Jan 2023 21:00:46 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" 
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.

Status      |    Bug Id | Description
------------+-----------+---------------------------------------------------
Open        |    238576 | Raspberry Pi 3B+ "shutdown -p" does not shut off 
Open        |    257670 | mpr(4): SAS3008 PCI-Express Fusion-MPT SAS-3: Fat

2 problems total for which you should take action.
--16744212460.0a8a.39854-- From nobody Sun Jan 22 21:36:36 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P0RPx0pqDz2t4m2 for ; Sun, 22 Jan 2023 21:36:37 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P0RPw64H4z4PFj for ; Sun, 22 Jan 2023 21:36:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1674423396; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=H63ao9ZLoSICyYUYKo6FRt7C7OcyK2jsgAuIoIC38Fo=; b=N2fC9F8hu29ybbuu0IjkTBfoVjGS65hm9+U1eIEFidlQcysIM9IrxEBX/05LCAjqyOQ+dJ 3oejmJBEXu2vWKVgnvKf/9qC650CcP33l9LX5U0X1iAeE6H+CET3KDahr3TX24YixUjvWq YPWwRpqVjcqQuogAl/gzfLlc099HjgIBuQCD6Ip3AycSftsB+BW7H23c7U2EwGRjNGSFnZ nblBPi4EZrMzt2vn5A7EkSfOPbzc7bG4bEG8fjmPV51ojhdwY9lMGNd3IDqImKnipGxMlx JUDsEbm2GfHJFIvDlq41lrga8JLOYP5hN+1pYnlB3KZWBrHaCj9QSxv4tZIvnw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1674423396; a=rsa-sha256; cv=none; b=AycxMUEwEKNrp2mOmdE+qvdfM+vO2D3IZSHqM45UJgLnHYhTBJW2dnMW7dgL2NBSbVj18T Q+WgXzb2wG00CMXuSCly6/xrEBJCRrDlL2R1Z94C5f+BCYR+Vtj7IGnA7dJlSloiM/Ps2I gfCXpKbLnxVNdcqyuXFo+1UCPMSn87EMimRw1Wcc1ncKmm4Kc+GjT0+Ar6+aXEC38g2cPn ritI+hKn0xCnPez0+s6JtzDQDf1RpoNyuguZ0sSMXKyqAn5BfjckWoJEE5CbIO9aK4B0Hh PtpGS5mieZ+n19eZTwhhiHWZw8RITqwaSikON2BRVAIbPT8rY1HW12dECW+78Q== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4P0RPw51sDz14K4 for ; Sun, 22 Jan 2023 21:36:36 +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 30MLaa6h096170 for ; Sun, 22 Jan 2023 21:36:36 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 30MLaaDk096169 for freebsd-arm@FreeBSD.org; Sun, 22 Jan 2023 21:36:36 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 269104] The uarts2 - uarts5 do not function on raspberry pi 4B Date: Sun, 22 Jan 2023 21:36:36 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 13.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jjrushford@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D269104 Bug ID: 269104 Summary: The uarts2 - uarts5 do not function on raspberry pi 4B Product: Base System Version: 13.1-RELEASE Hardware: arm64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: jjrushford@gmail.com I=E2=80=99ve tried using the additional serial ports that are available wit= h a raspberry pi 4B by enabling them in config.txt and when I try to read data = on them, I see nothing.=20=20 Specifically, I=E2=80=99ve wired an Adafruit ultimate GPS to uart3, gpio pi= ns 4 and 5. I=E2=80=99ve built the RPI-firmware port and copied the uart0-5 dtb=E2=80= =99s to /boot/msdos/overlays. I then enable uart3 in /boot/msdos/config.txt with dtoverlay=3Duart3 and reboot. After boot, I see that FreeBSD has created /dev/ttyu1 and /dev/cuau1 in the dev tree for uart3. When I try reading fr= om ttyu1 or cuau1, I do not see any data whatsoever. I=E2=80=99ve set the bau= d rate to 9600 and disabled flow control but still no data is seen. If I change the wiring to use ttyu0, gpio pins 14 and 15, I do see data there. Just to verify the hardware, I installed a different SD card with raspberry= pi OS, Debian, and enabled uart3 in config.txt. When I read the /dev/ttyAMA1 = I do see the NMEA time stamps coming in uart3 at 9600 baud with no issue. Next I reboot back to FreeBSD 13.1, I cannot see any data from The GPS card on tty= u1 or cuau1. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Mon Jan 23 14:41:45 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P0t8y5qF3z2tx7P for ; Mon, 23 Jan 2023 14:41:54 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P0t8y0672z3mb3 for ; Mon, 23 Jan 2023 14:41:54 +0000 (UTC) (envelope-from karl@denninger.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net; dmarc=pass (policy=none) header.from=denninger.net Received: from denninger.net (097-081-026-048.res.spectrum.com [97.81.26.48]) by colo1.denninger.net (Postfix) with ESMTP id 9AE29211083 for ; Mon, 23 Jan 2023 09:41:47 -0500 (EST) Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 328421D5168 for ; Mon, 23 Jan 2023 09:41:47 -0500 (EST) Message-ID: <0b235f83-7cb3-1d14-7c64-aee7c1c0c23d@denninger.net> Date: Mon, 23 Jan 2023 09:41:45 -0500 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Content-Language: en-US To: "freebsd-arm@freebsd.org" From: Karl Denninger Subject: GPIO inputs on Pis? Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms000601070800060604040601" X-Spamd-Result: default: False [-4.90 / 15.00]; SIGNED_SMIME(-2.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[denninger.net,none]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+mx]; TO_DN_EQ_ADDR_ALL(0.00)[]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[karl]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; HAS_ATTACHMENT(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4P0t8y0672z3mb3 X-Spamd-Bar: ---- X-ThisMailContainsUnwantedMimeParts: N This is a cryptographically signed message in MIME format. --------------ms000601070800060604040601 Content-Type: multipart/alternative; boundary="------------x2pMdr7LsuFFqjpJMaYDHEJj" --------------x2pMdr7LsuFFqjpJMaYDHEJj Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Is there support somewhere in the 13.x for other than "read current state" / "set current state"? Specifically, there is evidence in the sys/gpio.h header file that I can open up a file descriptor and then use select()/read() to grab the contents of a ring buffer of some size (presumably interrupt-posted) of events since last look, and determine if there's anything in there.  Provided you're reasonably fast this might be enough to, for example, read an optical encoder that has a modest pulse rate. I see apparent review code at https://reviews.freebsd.org/D27398 from late 2020, but nothing else I can find digging around; an example (assuming it is actually implemented and works) would be helpful. Thanks in advance! -- Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------x2pMdr7LsuFFqjpJMaYDHEJj Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Is there support somewhere in the 13.x for other than "read current state" / "set current state"?

Specifically, there is evidence in the sys/gpio.h header file that I can open up a file descriptor and then use select()/read() to grab the contents of a ring buffer of some size (presumably interrupt-posted) of events since last look, and determine if there's anything in there.  Provided you're reasonably fast this might be enough to, for example, read an optical encoder that has a modest pulse rate.

I see apparent review code at https://reviews.freebsd.org/D27398 from late 2020, but nothing else I can find digging around; an example (assuming it is actually implemented and works) would be helpful.

Thanks in advance!

--
Karl Denninger
karl@denninger.net
The Market Ticker
[S/MIME encrypted email preferred]
--------------x2pMdr7LsuFFqjpJMaYDHEJj-- --------------ms000601070800060604040601 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DbowggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBxIwggT6oAMCAQICEgLG8yH4PQFdbd9x Ugmpzl1jXzANBgkqhkiG9w0BAQsFADB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlk YTEZMBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENB MSUwIwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBMB4XDTIyMDYyOTE2MTYz NloXDTI3MDYyODE2MTYzNlowOjELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEX MBUGA1UEAwwOS2FybCBEZW5uaW5nZXIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC AQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvW ZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B 3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTgy+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYI XgVVPgfZZrbJJb5HWOQpvvhILpPCD3xsYJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMi WapsatKm8mxuOOGOEBhAoTVTwUHlMNTg6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMb NQm1mWREQhw3axgGLSntjjnznJr5vsvXSYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZM qa20JLAF1YagutDiMRURU23iWS7bA9tMcXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5 CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1l y+5ZOZbxBAZZMod4y4b4FiRUhRI97r9lCxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY 2BlA7ExM8XShMd9bRPZrNTokPQPUCWCgCdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEE MDAuMCwGCCsGAQUFBzABhiBodHRwOi8vb2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNV HRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYI KwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCGSAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBD bGllbnQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNV HSMEgcIwgb+AFF3AXsKnjdPND5+bxVECGKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQ MA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5 c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lz dGVtcyBMTEMgMjAxNyBDQYITAORIioIQzl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJs QGRlbm5pbmdlci5uZXQwDQYJKoZIhvcNAQELBQADggIBAKquc7cu0xc8FNtAQauZvocDzWQj 7HG9YvMbWnMi+ckhiA3rdW5NwWg0HBhBho1YlnqV+ntCVE2L8ezohHWm+KAdfXgpraL86Vsn 3ywNlZu/3COMpo2ALuHln8YQtH3Y8ebvzKMdlf2b5WB+7mOFIxXIr4AnNOLKCkq5ZhzC6JW6 Jvw3P0csiGa3UrfatYID5NvPgkaQvEgimEjG3psZqwQTL2Wxohvw783PrDt3wS0XeNhvQ61g 3QJFZKuv+bmGH3YBSPo1t6NUGAr+JozX5lDihB8JGkBt/NwdYec49a08uL0BbPaAJ7NjuIPG 7Y0Ak7PXZT37yx/Zla9PzLMJFgbelOkaatdzbblMZPDEVZ27l4lGMmV83Lm3YP17sdAyS/Wp mav7WmJUkQ9iuIKzSpdc82i9Mfujl1vbBtwtkHNPPtKuulIFM4ZwrPKjlVdLqTSqD8m9yHEi Y0PuAooq63OpJWF6hvMaiIPBWEAVIaDW9uG0MshLl9DnHnMyrJTfuC33Z9mOGMz7dRBjJd5Y W02xAzYnUuEBOpj+LQv5R8XIFMHFXktqEKvQrXeM2RU+PcZqKOBkTktxBLn3NI5VfA15Jk0c 5V5XcOqo3p2hvrwvXrinrb2pEREnoqmfrkXT3zOq5Y6ryRH8u734lGEF0dILXzoV4PM7XFit oTePoEjmMYIFBDCCBQACAQEwgZEwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGEx GTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTEl MCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQQISAsbzIfg9AV1t33FSCanO XWNfMA0GCWCGSAFlAwQCAwUAoIICQzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0yMzAxMjMxNDQxNDZaME8GCSqGSIb3DQEJBDFCBEAe/7VsTtNVTP2INm+T aAwhuoYES87qbAQzM8HqV78RTr75oxNhoL0ec7bSVjWfLCLDYUN02BWxkZgrtopXG4eZMGwG CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw gaIGCSsGAQQBgjcQBDGBlDCBkTB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTEZ MBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENBMSUw IwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBAhICxvMh+D0BXW3fcVIJqc5d Y18wgaQGCyqGSIb3DQEJEAILMYGUoIGRMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9y aWRhMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMg Q0ExJTAjBgNVBAMMHEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0ECEgLG8yH4PQFdbd9x Ugmpzl1jXzANBgkqhkiG9w0BAQEFAASCAgCkb0GVWVRwkSu1Bg3qs8s5Y6UMGpdkxnPLyJSv TH9gocbUA5iFoAMH8CKHnKlTbqq6ObiOx+puZxIiAvpzOtwQXD1zbJMFpcE1ZuQgjwr/ztA3 7ANyuAUh5GlOnGldkU8LYyuh4nM7TRwc8LwvNKyyVDVfCV7jnO7IhH4agVZV7Ax1kAc+zoFg N1mBOmEAqCioDY6nD6wo6H+I4QO2OxKbooK04fEC4FCiNa8yDHRU5e2jBhfqSmyxsTIMRU7K FFok9jDrObhNjdQlaLlUelLpZAmmppg5KO2nVK8mrYsrv57QgBaL04DyZT6Wz+RGNTd4Wmkd 35cuQljakHFBCygr1eyfveaaWb6AHORxCTtcov1WjCmSQMnOEFY7vMo6PQFNvs32xtyjBlKp VIxzOoYYKBzusCumFG60hfZzcOaCx2EaBDcnZYRRWjogdodx/4HcNorUJ8orGiV+gme07ujQ ZhVlTQdVJhHEJ8JrdBNUNn1/3Jz4miRfDLm9HldV0zcg+0FJ6ge64kfcYduzby2f8N7SwnKB Le/u1vOvIxJqpM1bw+BS0J+pgDGrt/vSBxvQVIvANBVV/txfRU9Cx5KbUQaugMU7mH29FJI6 rTbX9ZmkIcDCcsBOi6WQdDT1XJtMFwbgutww1VGA1MoVPoCPLP5S6zXp+xn0fh/OIeABaAAA AAAAAA== --------------ms000601070800060604040601-- From nobody Mon Jan 23 14:53:52 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P0tQv0Y5Hz2tykj for ; Mon, 23 Jan 2023 14:53:59 +0000 (UTC) (envelope-from fred@thegalacticzoo.com) Received: from nmtao202.oxsus-vadesecure.net (mta-232a.oxsus-vadesecure.net [15.204.3.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P0tQs51djz3nZ1 for ; Mon, 23 Jan 2023 14:53:57 +0000 (UTC) (envelope-from fred@thegalacticzoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=webcom.xion.oxcs.net header.s=mail1 header.b=jm1XEB+0; spf=pass (mx1.freebsd.org: domain of fred@thegalacticzoo.com designates 15.204.3.6 as permitted sender) smtp.mailfrom=fred@thegalacticzoo.com; dmarc=pass (policy=quarantine) header.from=thegalacticzoo.com DKIM-Signature: v=1; a=rsa-sha256; bh=SAQ34uzdSclpmzwt5BsxPagOyxGAQ5aCjnuV3g LxTfo=; c=relaxed/relaxed; d=webcom.xion.oxcs.net; h=from:reply-to: subject:date:to:cc:resent-date:resent-from:resent-to:resent-cc: in-reply-to:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; q=dns/txt; s=mail1; t=1674485635; x=1675090435; b=jm1XEB+0zsjbI7msLhPBbsUOOyiIDAfvsXhyszegh 0d28+JnMmSfmiIFZah/QTA1Dk8wu6NnJ0AUlLzORBaMrTAeZ/wN3WeKli33vSci0nbxAh+p XT5LfCdEUm/8h1twptAohjLELqasVTrxRGNaXLiUKP5t+ctfQINB4iHAE83iZkbmw73GHwf lV3uOp+WaMYINNZkG10mXIvwjeNhhXEsemnIxhejqw5FyY61ILWuJxAXX0dqCaEWH2wWQ0T APBFYj4Ur9dAgAJM/NrJMegMnzAyiHK2qqL1+B3Lq3NjmjoUXvpUZC2QnS06L16m3o9sZSe e5mwoVTpACJX9M3Zw== Received: from proxy-8.proxy.cloudus.ewr.xion.oxcs.net ([76.14.221.149]) by oxsus2nmtao02p.internal.vadesecure.com with ngmta id 931861c1-173cf7cfec492aeb; Mon, 23 Jan 2023 14:53:55 +0000 Message-ID: <68e61133-cb1c-60ae-59bf-5569a0f18d40@thegalacticzoo.com> Date: Mon, 23 Jan 2023 06:53:52 -0800 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 From: Fred Finster Subject: Re: Raspberry Pi 4B is now booting single user mode on FreeBSD 14.0 aarch64. Does it work for you? To: Mark Millard Cc: freebsd-arm@freebsd.org References: Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[thegalacticzoo.com,quarantine]; R_DKIM_ALLOW(-0.20)[webcom.xion.oxcs.net:s=mail1]; R_SPF_ALLOW(-0.20)[+ip4:15.204.3.6]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; FREEMAIL_TO(0.00)[yahoo.com]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:16276, ipnet:15.204.0.0/17, country:FR]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[15.204.3.6:from]; TO_DN_SOME(0.00)[]; DKIM_TRACE(0.00)[webcom.xion.oxcs.net:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[15.204.3.6:from] X-Rspamd-Queue-Id: 4P0tQs51djz3nZ1 X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N On 1/21/23 17:12, Mark Millard wrote: > On Jan 20, 2023, at 06:22, Fred Finster wrote: > >> was just trying to boot into single user mode from this documentation below: >> https://people.freebsd.org/~rodrigc/doc/handbook/makeworld.html >> Once in single-user mode, run these commands if the system is formatted with UFS: >> >> |#| *|mount -u /|* >> |#| *|mount -a -t ufs|* >> |#| *|swapon -a|* >> >> example I created this blog post:https://ghostbsd-arm64.blogspot.com/2023/01/time-make-j4-buildworld.html >> I could boot into multi-user mode but not into Single User Mode on this Raspberry Pi 4B. >> What do you suggest and how to trouble shoot? I turned on verbose mode and saw that it hung after starting /sbin/init >> but do not know why this aarch64 ARM64 BCM2711 cpu hangs on FreeBSD 14.0 going into "single user mode". >> >> This Version: >> >> root@Fred_RasPi4B:~ # uname -Kmnopr >> FreeBSD Fred_RasPi4B 14.0-CURRENT arm64 aarch64 1400077 >> root@Fred_RasPi4B:~ # uname -a >> FreeBSD Fred_RasPi4B 14.0-CURRENT FreeBSD 14.0-CURRENT #6 main-n259952-7e2600ea7be2-dirty: Sun Jan 15 18:14:05 PST 2023root@Fred_RasPi4B:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-VCHIQ arm64 > . . . > > I've never tried GENERIC-VCHIQ. > > Have you tried testing a standard build on some > media, such as trying a dd of an uncompressed: > > http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/14.0/FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20230120-43703bc489ec-260163.img.xz > > and seeing if the problem replicates for that in > your context? If it replicates, then at least you > know it is not something more specific to your > context and other folks would be able to test > similarly with a sufficiently analogous context. > > But, if it does not replicate when you try such a > test, then folks likely would have to try to > reproduce your context to have a sufficiently > analogous context to test. > > === > Mark Millard > marklmi at yahoo.com > Mark thank you for answering my email question directly! I realize you, Mark, are busy, with some many details. Your suggestion of using a Snapshot image is good for debugging. http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/14.0/FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20230120-43703bc489ec-260163.img.xz Is there a shell script file to build this image, just like FreeBSD.org does? I would like to natively build an image with the VCHIQ patch included from my /usr/src hosted on the Raspberry Pi 4B /8G dram with a 500GB SSD drive with 92GB FreeBSD partition. Uart0 Serial Console pin 14 TXD, Pin 15 RXD works in Single User Mode on the Raspberry Pi 4B with 8G dram executing FreeBSD 14.0 GENERIC-VCHIQ. The serial console and video console both issue messages, upto this point, The Video Console stops just after a verbose debug message '/sbin/init' , yet the serial console continues working and receives commands and issues results. root@:/usr/src # uname -a FreeBSD 14.0-CURRENT FreeBSD 14.0-CURRENT #6 main-n259952-7e2600ea7be2-dirty: Sun Jan 15 18:14:05 PST 2023root@Fred_RasPi4B:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-VCHIQ arm64 root@:/usr/src # uname -Kmnopr FreeBSD 14.0-CURRENT arm64 aarch64 1400077 I have the Black Magic Probehttp://black-magic.org set up and using the 3.3V TTL serial port device at /dev/ttyU1. You have to load kernel modules kldload ucom, umodem, usb_template, and set hw.usb.template to 3. sysctl hw.usb.template=3 . *#kldload ucom umodem usb_template* #*sudo sysctl hw.usb.template=3* hw.usb.template: -1 -> 3 *sudo vi /boot/loader.conf* #add 4 lines for next boot to include modules umodem_load="YES" usb_template_load="YES" ucom_load="YES" hw.usb.template=3 Use cu Connect Unix command to open the USB serial port to the Raspberry Pi 4B Uart0 # *cu -s 115200 -l /dev/ttyU1* Connected OPEN URL for more details:https://ghostbsd-arm64.blogspot.com/2023/01/hookup-gdb-to-black-magic-probe-v23.html URLS to My Efforts with FreeBSD 14.0 Current on the Raspberry Pi 4B and documentation: https://ghostbsd-arm64.blogspot.com/ https://ghostbsd-arm64.blogspot.com/2023/01/hookup-gdb-to-black-magic-probe-v23.html Hooking up USB Serial port to Black Magic Probe https://ghostbsd-arm64.blogspot.com/2023/01/time-make-j4-buildworld.html FreeBSD 14.0 make -j4 buildworld https://ghostbsd-arm64.blogspot.com/2022/09/freebsd-140-compiling-kernel-for.html FreeBSD 14.0 snapshot install, use bsdinstall to a SSD drive, compiling make -j4 buildkernel -KERNCONF=GENERIC-VCHIQ https://ghostbsd-arm64.blogspot.com/2021/05/audit-your-boot-files-with-md5deep.html Audit your boot files with md5deep tool to verify basic system boot files https://ghostbsd-arm64.blogspot.com/2021/02/download-freebsd-140-current-version.html FreeBSD 14.0 snapshot install method Conclusion: 1. Uart0 Serial Console is working and I can see boot messages via USB serial port on Black Magic Probe 2. I can enter boot into and use single user mode of FreeBSD 3. Shared my work with others via my Google Blogpost website https://ghostbsd-arm64.blogspot.com/ 4. Working to get a JTAG debugger working with Black Magic Probe hardware debugger to use GDB software. Not Finished 5. What do others suggest for a JTAG hardware debugging environment on the ARM64 aarch64?  Anything specific for Raspberry Pi 4B? Maybe is the RasPi4B hardware system is complete enough to just debug via GDB. 6. I realize in my efforts to be complete, I write a book instead of a short note.  Sorry, always feel I am forgetting some data or a piece of good information Mark, thanks again for your suggestion to use a current SNAPShot image.  I appreciate a direct short answer. To the other person testing uart serial ports look at Raspberry Pi documentation.  Set some GPIO pins to Alt-X in the config.txt file in the boot directory.  Look at the pictures and URL Links I share on "Hookup GDB to black magic probe." uart_enable=1  3.3V  3milliamp drive. https://pinout.xyz/pinout/uart https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#disable-other-gpio-peripherals https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#gpio-and-the-40-pin-header -- Fred Finster fred@thegalacticzoo.com +1 971-718-9144 https://GhostBSD-ARM64.blogspot.com https://ghostbsd.org From nobody Mon Jan 23 21:41:28 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P13TR06phz3bTL3 for ; Mon, 23 Jan 2023 21:41:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-55.consmr.mail.gq1.yahoo.com (sonic308-55.consmr.mail.gq1.yahoo.com [98.137.68.31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P13TQ4vZ2z3FZ3 for ; Mon, 23 Jan 2023 21:41:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1674510104; bh=nxDt9HxEKpDuz9i4AbHGUNY7KRMUVXFHX7H+YtdpIu4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=d7pZutyDsd0lUIbM7QMRpvtL7Iao0FY6Ybu2zGbLOa89tAqr5pbYSvowt48qvDUsDUI6KHyp5Agtj1pfuWToNfcN78d/S35lJPeNCWBUfzAFcpsXK8jurZMs4TkxikumFr4F3v5gozNH+LJrgnUiNV4xW+gGGW98kDLxbpqfC1ozsY3WZyZGy7dy2vCojNMq+r6fq7rWKSPFTeGJfotSIlvdP8AR28XG0/+dO5Llw8j6Rmgm6Wsax3QxD5ApDdaghIG0m+C1XpvDN/6TQ8BFJvbblR0GPwk9h0j9EUEsi8t8jvawB/Sjb4ivC26IfV74ibJXlY5kY4CN6lQV9jKNlQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1674510104; bh=f2XxlDNXbTWuUpBTCa9sxQS8br11t/E5rIg1y8/vVIH=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ngjZshwvcS35zviqhp+ckeXAemSERynz0gD67zxlEezjg4ANJsxzgw28gWGsLnKNTiDH7tPR/7QSZbhsKe5IIVGMhWdbo6NHxTIZUnrANvYmAIVzn6Ld54/IpHAXB6LrMPebjm65aYqHRZ0g3N3WwgJmCl+3mFQCJsqvOqgHv6Tx7nFIUiuLAtILBcN4q7mDX/HafQOX+/vwg21jwnpK2+UyZbIl14n2gtvysKWSZ/LwJIJzmLejm1W5d5v2qislaAksAFjVgQm7TtPH7SiWp7ArI71LQN9sjE8qOov3NGJiJryNMRWNTTpjDM8BXygMJMpuhl5ZuX7f6vwjT/aEog== X-YMail-OSG: 8O6YTVQVM1l8rm0FjRlI61OiJvh5uvJd63TkEcG8BBcUHWf8dPZ0u_UwehVUPXD aREez9GgPlzF03mZ0MKiaQX.Jku1M_rZ27_EMxTzTLSWxgcc6iIH57tWoJchwm4.IvQ.PetysI9D T.j3Ww3z_J7q6FlzhcrvS6W8Ruyo1JaYwlwHeaqPJi0jHKooN_XDu5pA9X47nRncQ_MpmwpZXXtz SUWRH9nRie2wlHFIpYIogtukhbNJyPlUpqJay3o6A0PpO8XwUqppIYqpdTWOpqaRRWeoRk_n1hfi I6SQpfOvl7fqma8AxIaRw3iMuw8a_rYsSWRJWHsLtdh20KqG6F5K1ldv5yJcaT.4Evn1wZ4qG6Mp JW5P84RhruClBhVXC.KdMlGVNdYLD4M_zfCzx5UcSG0KUxKJgl8zFCZDcdGyrbu70kNkaK1gxDWw cnWWwyarYHfFxLpDjKowr.Y8TyhW9Ra0OgYMV.jU12TBmwaQwar_pFe2NQeySAOmalx5rWM2qyla qbLtdFABkeLfIIyFVsvW5AaPT1tJKQDp7jJw86r.KHgZcYEWQNLhpIqua9wOzosc73TSIrvHInhq 53P82W1GBZg0rNxVIEAuziAZhQInoWZSwKu16Skec0kgwjblX2fp7waeJOqzJKxm91Fr_JkZBJtS HLLTRcRZ_Jz1Gelb.F8RtJxVGKvjAPfGNxztVtzgOV3hvrt5XH3EWroM7o6zhFJ7F2oy1yzK83fW F1a2KNYfbLaLm.OdWsSuq9eC3EgIWme7sYPgiafLNqiaQgFR28rbL9mCotkkyEPb_kHe4Pjpzyo2 rgANOKQ7tieOOQAD8c.P2ACCG7BgJSRI2UViJC_wJ_kQBvU0yjjZsY9kkTVDV.iGgDitK0u1mBLO qFPe9cyzeS_eyiHGbF91lwYGdLaUMW3rxjJAa3K4SNBhivxfvTOQxjF_KJRBmk.7Om8ULRZRltvZ D60oXlYbImXVwuJWduavSBKa2imkozNuFeKcOimu.1qIykTatzfnACGaO3fdFY.FC.TP.CxaloYh gogWfvN.nmDKGX3Q0qN.KUq0MPgo2VmidWesvHs_5jVcBSychbx911Txe9qf5Lj0JSJbLNkcJq4J pe9I4KE4HCQp9NZRYhTpBlUWarhbjvbaj17fh_yD5vwN0wA9ayWslT_ggzmd_6Lcx5wGKZgpPJbl hvMV43Ft5.1hXEWItCKDCTwVU8lPHggysWtBgvhWfnGLlLmgd3svR8pYoioZERmnrSxI3fzi_dPh qnevsHOIGQomvrX6.ouYJhgk9VvbCB26f_c9Agsu7A9GLdRR4wVZdof0gJqPmwGEk5OPGYtpbcYQ JihzxFjIqc5w.WXjCJwxA6vPrRsdslkDV7ipWsYtKj_uKyQn_AU0O5ua2qKWDKli0erbL6ubKsGb leho55Czv5Skl68E2yRGXuUBS.oe4t6qBUl6HpTHoeDP3Tb3fQdjlrwwddeEN_y5BXcbKs0f2Ajm Y0qphYB8tMugPTeSsp5ztUg7P2wjYV5GMmHSVrGGDbmjgRmbaLrjQ78NCszdw6nhwJtC8OgeKHZm VnPlHs8FC.6xaQqPsQhalCYozhwjlKnUxr.DsfeXIKewLN0sGqn2y4e26Uomj5mZDyU2VzhxXLje QsxBZjF35PajaSCJfoC8r.kQyMdacZzLuetKp0shZehx5Vn4C2xuhHVPZNoRZwDiOQGrqNHEa2e0 Yg3YpcV.g1Bd62p.VQKxqgUeH6VZLOXdoriuiRFRa5p.f7rNLJcwaBEDONVJCENqn.ATPlkPtEc3 Fn52UHy4XzJmEB60SX7KCa1qu1LXRQ4tyb22tc7ONbnl1V0BRPCu9QEEYiqvhtoov6DqMqjh9F5Y 9lfvq5k_T5BE8tCq9fpy.DHHrYAQoMqg.9ds5y4gOhnPAUS7.WXQ6GU_ZeXvqagWy2SHcA6PP3uw RV9Jwi3lOIZir0mtsrAmvwRL2FeF7Z4flBxo25C1x2utUsf5kFyaxUxe6sBEighwqmDnc643IHOb eqC9aVqGnB.HWUsbV0z6PhHG17kE4.Hk0q8iIXyhse7ROPac6gfkncfp6XV_xtShCzlgwayk5KRl B5RmJQ7ONeYaen4t6sVd6KR91.nSPKkrk0CGSd7ee8z0ia9ndRpjqkUNn9BtdbGx0FcnKy9IHl2. D9LPxWqRfp8uMKdD7iGZzWuztgrmWAPFAnY7vpummCSzKPXZOPfwBMeWG0ON.exqi_17QeUmuSN6 _c0mrjuzba9.Jj4XJqnuILK8s.kg4w_ELM2bvyQUU.NKlY.5iZnwAJfQBKUUq4.XyZoyeAoGz7ga vsQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Mon, 23 Jan 2023 21:41:44 +0000 Received: by hermes--production-bf1-6bb65c4965-2q6bd (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 11c2f90e7f36908914bebd4b37ffcc9a; Mon, 23 Jan 2023 21:41:40 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: Raspberry Pi 4B is now booting single user mode on FreeBSD 14.0 aarch64. Does it work for you? From: Mark Millard In-Reply-To: <68e61133-cb1c-60ae-59bf-5569a0f18d40@thegalacticzoo.com> Date: Mon, 23 Jan 2023 13:41:28 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <7187F5AE-A36F-407D-8784-B9527A620820@yahoo.com> References: <68e61133-cb1c-60ae-59bf-5569a0f18d40@thegalacticzoo.com> To: Fred Finster X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Rspamd-Queue-Id: 4P13TQ4vZ2z3FZ3 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Jan 23, 2023, at 06:53, Fred Finster wrote: > On 1/21/23 17:12, Mark Millard wrote: >> On Jan 20, 2023, at 06:22, Fred Finster = wrote: >>=20 >>> was just trying to boot into single user mode from this = documentation below: >>> https://people.freebsd.org/~rodrigc/doc/handbook/makeworld.html >>> Once in single-user mode, run these commands if the system is = formatted with UFS: >>>=20 >>> |#| *|mount -u /|* >>> |#| *|mount -a -t ufs|* >>> |#| *|swapon -a|* >>>=20 >>> example I created this blog = post:https://ghostbsd-arm64.blogspot.com/2023/01/time-make-j4-buildworld.h= tml >>> I could boot into multi-user mode but not into Single User Mode on = this Raspberry Pi 4B. >>> What do you suggest and how to trouble shoot? I turned on verbose = mode and saw that it hung after starting /sbin/init >>> but do not know why this aarch64 ARM64 BCM2711 cpu hangs on FreeBSD = 14.0 going into "single user mode". >>>=20 >>> This Version: >>>=20 >>> root@Fred_RasPi4B:~ # uname -Kmnopr >>> FreeBSD Fred_RasPi4B 14.0-CURRENT arm64 aarch64 1400077 >>> root@Fred_RasPi4B:~ # uname -a >>> FreeBSD Fred_RasPi4B 14.0-CURRENT FreeBSD 14.0-CURRENT #6 = main-n259952-7e2600ea7be2-dirty: Sun Jan 15 18:14:05 PST = 2023root@Fred_RasPi4B:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-VCHIQ = arm64 >> . . . >>=20 >> I've never tried GENERIC-VCHIQ. >>=20 >> Have you tried testing a standard build on some >> media, such as trying a dd of an uncompressed: >>=20 >> = http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/14.0/FreeBSD-14.0= -CURRENT-arm64-aarch64-RPI-20230120-43703bc489ec-260163.img.xz >>=20 >> and seeing if the problem replicates for that in >> your context? If it replicates, then at least you >> know it is not something more specific to your >> context and other folks would be able to test >> similarly with a sufficiently analogous context. >>=20 >> But, if it does not replicate when you try such a >> test, then folks likely would have to try to >> reproduce your context to have a sufficiently >> analogous context to test. >>=20 >> =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com >>=20 > Mark thank you for answering my email question directly! I realize = you, Mark, are busy, with some many details. Your suggestion of using a = Snapshot image is good for debugging. > = http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/14.0/FreeBSD-14.0= -CURRENT-arm64-aarch64-RPI-20230120-43703bc489ec-260163.img.xz > Is there a shell script file to build this image, just like = FreeBSD.org does? I would like to natively build an image with the = VCHIQ patch included from my /usr/src hosted > on the Raspberry Pi 4B /8G dram with a 500GB SSD drive with 92GB = FreeBSD partition. The 43703bc489ec part of the *.img.xz name indicates the exact commit used for the snapshot build. Thus you can set up to be using the exact same source content for buildkernel (or even buildworld). This does get into avoiding src.conf and make.conf tailoring and using the same kernel configuration file in order to fully have things the same when that happens to be what is wanted. (This can allow seeing if your own build of deliberately-the-same manages to match the snapshot's behavior.) You can rename the original /boot/kernel in the installed snapshot ( such as to /boot/kerorg ). You can installkernel your own kernel build as /boot/kernel . =46rom the loader you can pick kernel which to boot. The renaming I used as an example makes your build the default for booting. This avoids needing to buildworld or installworld at the time: just a kernel update. It allows trying both kernels with the rest held constant in order to compare/constrast. You can also go the other way: do possible renaming (or deleting) of the kernel on the media that you have been using and copy over /boot/kernel from the snapshot to a desired /boot/* name on your media and then use the snapshot's kernel to try booting with your build of world. Again, it can allow booting both ways and doing comparison and contrast investigations. Of course, you can also do buildworld buildkernel with your intended tailoring, such as using the alternate kernel configuration file, but otherwise based on the same source files used for a snapshot. The official release building scripts and such are intended generally for avoiding any non-standardness in the builds. So I doubt that you would use them for making locally-tailored builds. I do not use them. The tail part of UPDATING has material about doing various types of personal builds/installs/updates, starting with the text "To build a kernel". There are also more instructions in the likes of the /usr/src/Makefile in its initial comment block. It starts around the text: "If you want to build your system from source," It does not cover as many variations. But it can be good to read both sets of instructions. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Jan 24 12:53:44 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P1Rjn1NP7z3bP7m for ; Tue, 24 Jan 2023 12:53:49 +0000 (UTC) (envelope-from fred@thegalacticzoo.com) Received: from nmtao201.oxsus-vadesecure.net (mta-231a.oxsus-vadesecure.net [15.204.3.4]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P1Rjl6LkVz48ls for ; Tue, 24 Jan 2023 12:53:47 +0000 (UTC) (envelope-from fred@thegalacticzoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=webcom.xion.oxcs.net header.s=mail1 header.b=o+9UYFeD; spf=pass (mx1.freebsd.org: domain of fred@thegalacticzoo.com designates 15.204.3.4 as permitted sender) smtp.mailfrom=fred@thegalacticzoo.com; dmarc=pass (policy=quarantine) header.from=thegalacticzoo.com DKIM-Signature: v=1; a=rsa-sha256; bh=b1LFqUXebn9ZD3BYvTY+oQRi0qXnMu6eYP61+g d5uVQ=; c=relaxed/relaxed; d=webcom.xion.oxcs.net; h=from:reply-to: subject:date:to:cc:resent-date:resent-from:resent-to:resent-cc: in-reply-to:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; q=dns/txt; s=mail1; t=1674564826; x=1675169626; b=o+9UYFeDA2PEgXs/fVHT5mCngn8ACwf6bfG7YtSuv Y94WS98x6x/ORr+4o63uJWTC8SB/oLs85tsJA0gYyDY5BEvL3IksSmf5XqfaDY2D/aehewQ D70npI15ZnhPWnxy0PcsFZSVs8vtw2WJiw3wPm6+QMu2Qvoa/Vo39WyPJ1JAEbacJEFP7SP S8N8zAI1YBtnq4gONNMlT6V+g8eUmn3MEkMqhs92cXDcPzRUclD4gGGqiygvxcG14BJd+Ds Wp7XzYO0/Ao0I8AZvhKjMfQWQzXQdcEevHEoeLqrvS4ksTEF4U3Fj0dI/pN64wKfLY4VejR Y6VkxPqkSsQC5jjQg== Received: from proxy-12.proxy.cloudus.ewr.xion.oxcs.net ([76.14.221.149]) by oxsus2nmtao01p.internal.vadesecure.com with ngmta id 8e36903e-173d3fd631941e55; Tue, 24 Jan 2023 12:53:46 +0000 Message-ID: <97c23a36-a98e-f83c-e0e2-02bbeee0fdfe@thegalacticzoo.com> Date: Tue, 24 Jan 2023 04:53:44 -0800 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Content-Language: en-US To: freebsd-arm@freebsd.org From: Fred Finster Subject: Testing All 5 Uarts on Raspberry Pi 4B Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[thegalacticzoo.com,quarantine]; R_DKIM_ALLOW(-0.20)[webcom.xion.oxcs.net:s=mail1]; R_SPF_ALLOW(-0.20)[+ip4:15.204.3.4]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:16276, ipnet:15.204.0.0/17, country:FR]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[webcom.xion.oxcs.net:+]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[15.204.3.4:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4P1Rjl6LkVz48ls X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N TOP POST answer : https://forums.raspberrypi.com/viewtopic.php?t=244827  Testing of all 5 UARTS near bottom of this URL link https://forums.raspberrypi.com/viewtopic.php?t=244827&sid=9955627b0e7844c752f46b5ae55ef684&start=75 Page 4 URL link *I copied and pasted below.  I /apologize in advance for troubles I am inflicting on text only email viewers.  I have set my Thunderbird/* */email to send out only text email.   Fred/* FreeBSD creates /dev/ttyu1 Sounds like  you need to disable bt???? Adding "dtoverlay=disable-bt" switches the UART roles so that UART0 is mapped to 14 & 15 (Alt0), leaving UART1 unmapped. https://forums.raspberrypi.com/viewtopic.php?t=244827&sid=f4a784a3c40ed0940e6fbb9f81af5015&start=25#p1590882 Re: Pi-4 Activating additional UART ports Mon Jan 06, 2020 10:36 am On all Pis, UART0 is a PL011 that appear to Linux as ttyAMA, and UART1 is an 8250 clone that appears as ttyS0. On a Pi4, UART2-5 are additional PL011s that also appear as ttyAMA. The number starts at 0 for the first enabled PL011 and counts up through all the enabled interfaces. The numbering is stable for any given combination of UARTs, but enabling or disabling one can change the number assignments of others. Adding "enable_uart=1" to config.txt on a Pi4 enables ttyS0 (UART1) on GPIOs 14 & 15 (Alt5), leaving UART0 driving the Bluetooth interface on 30-33 (Alt3). Adding "dtoverlay=disable-bt" switches the UART roles so that UART0 is mapped to 14 & 15 (Alt0), leaving UART1 unmapped. As rpdom says, you can only enable one function on any pin at once, and enabling the same alternate function (e.g. RXD0) on multiple pins usually results in failure (outputs tend to work, inputs don't, but it is essentially undefined behaviour). *//* */ /* */From:/*John Rushford */Date:/*Sun, 22 Jan 2023 03:27:38 UTC Mark, Thanks for the reply. I only have “dtoverlay=uart3” in the config.txt and with that entry, FreeBSD creates /dev/ttyu1 and /dev/cuau1 along with the .init and .lock files. So, I tried with this entry in /etc/ttys and it was of no help, still no data: ttyu1 "none" vt100 on secure thanks John jjrushford@gmail.com > On Jan 21, 2023, at 8:18 PM, Mark Millard wrote: > > On Jan 21, 2023, at 18:34, John Rushford wrote: > >> I have installed FreeBSD 13.1 on a raspberry PI 4b rev 1.4 and I am trying to use the additional serial ports that are available with the PI 4 with an Adafruit ultimate GPS card. >> I found that it was problematic using the first serial port ttyu0 on GPIO pins 14 and 15 as data on the line from the GPS would interrupt the boot process and I verified that I was in fact able see data time stamps from the GPS card on the first uart port once I got FreeBSD to boot. >> >> Now since I do not wish to use the first serial port, I’ve built the rpi-firmware port and copied all the uart dtb’s to /boot/msdos/overlays and I’ve tried enabling the uart’s in /boot/msdos/config.txt with “dtoverlay=uart3” for example. >> Enabling them does in fact result in device entries created for them in /dev but, I am unable to see any data on the corresponding ttyuX or cuauX ports. >> >> Just to eliminate a wiring error, I installed another SD card with Raspberry PI OS, enabled uart3 and I am able to see data on uart3 without any issue confirming I have everything wired up properly. >> >> With FreeBSD, I have set the proper baud rate on the ports and I’ve tried disabling flow control on them, using stty, but no matter what I do, I never see any data on them. Unless I’m missing something, I can only conclude there is some bug in FreeBSD preventing me from using these additional serial ports. Has anyone here on this mailing list been able to use them? If so, what does it take? > > You did not mention /etc/ttys editing. So I wonder if you > changed any of the lines like, say, > > # Serial terminals > # The 'dialup' keyword identifies dialin lines to login, fingerd etc. > ttyu0 "/usr/libexec/getty 3wire" vt100 onifconsole secure > ttyu1 "/usr/libexec/getty 3wire" vt100 onifconsole secure > ttyu2 "/usr/libexec/getty 3wire" vt100 onifconsole secure > ttyu3 "/usr/libexec/getty 3wire" vt100 onifconsole secure > > to use, say, none instead of "/usr/libexec/getty 3wire", and other > related edits. > > But I've not tried to get any extra serial ports going on > an RPi4B. So the above is just guess work about something > to experiment with. > > === > Mark Millard > marklmi at yahoo.com https://forums.raspberrypi.com/viewtopic.php?t=244827 Testing All 5 Uarts on Raspberry Pi 4B near bottom of this URL link. Question has anybody here on FreeBSD arm mailing list group made some or all of the Raspbian Linux Tools operational on FreeBSD? Maybe this is a simple recompile with a couple modifications? I should just try myself first.  Just checking that NO ONE ELSE has already completed a Tool and is willing to share. raspi-gpio,  rasp-imager,  rasp-config, dtoverlay I suggest you start by running the following to establish whether the configuration has been successful: $ raspi-gpio get 0-15 $ ls /dev/ttyAMA* raspi-gpio get 0-15 GPIO 0: level=1 fsel=3 alt=4 func=TXD2 pull=NONE GPIO 1: level=1 fsel=3 alt=4 func=RXD2 pull=UP GPIO 2: level=1 fsel=4 alt=0 func=SDA1 pull=UP GPIO 3: level=1 fsel=4 alt=0 func=SCL1 pull=UP GPIO 4: level=1 fsel=3 alt=4 func=TXD3 pull=NONE GPIO 5: level=1 fsel=3 alt=4 func=RXD3 pull=UP GPIO 6: level=1 fsel=0 func=INPUT pull=UP GPIO 7: level=1 fsel=0 func=INPUT pull=UP GPIO 8: level=1 fsel=3 alt=4 func=TXD4 pull=NONE GPIO 9: level=1 fsel=3 alt=4 func=RXD4 pull=UP GPIO 10: level=0 fsel=0 func=INPUT pull=DOWN GPIO 11: level=0 fsel=0 func=INPUT pull=DOWN GPIO 12: level=1 fsel=3 alt=4 func=TXD5 pull=NONE GPIO 13: level=1 fsel=3 alt=4 func=RXD5 pull=UP GPIO 14: level=0 fsel=4 alt=0 func=TXD0 pull=NONE GPIO 15: level=1 fsel=4 alt=0 func=RXD0 pull=UP pi@raspberrypi:~$ ls /dev/ttyAMA* /dev/ttyAMA0 /dev/ttyAMA1 /dev/ttyAMA2 /dev/ttyAMA3 /dev/ttyAMA4 config.txt   file contains enable_uart=1 dtoverlay=pi3-miniuart-bt dtoverlay=uart5 dtoverlay=uart4 dtoverlay=uart3 dtoverlay=uart2 (The miniuart overlay uses ttyS0 for Bluetooth, freeing /dev/ttyAMA0). The help info shows the GPIOs used by each new UART - 0-3 for UART 2, 4-7 for 3, 8-11 for 4 and 12-15 for 5. This does mean that UART 5 overlaps with the standard UARTs on 14 & 15, but UART 5 has its flow control signals there - TXD5 and RXD5 appear on 12 & 13. I wonder, as GPIO 14 and 15 already used for uart0, how could Uart5 flow control use GPIO 14 & 15 ? By not enabling UART0. I deliberately reversed the order of the UART overlays to demonstrate that ordering here makes no difference to the ttyAMA numbering. Using this script: Code:Select all |#!/bin/sh sudo stty -F /dev/ttyAMA0 115200 sudo stty -F /dev/ttyAMA1 115200 sudo stty -F /dev/ttyAMA2 115200 sudo stty -F /dev/ttyAMA3 115200 sudo stty -F /dev/ttyAMA4 115200 while true; do sudo sh -c "echo 0 > /dev/ttyAMA0" sudo sh -c "echo 1 > /dev/ttyAMA1" sudo sh -c "echo 2 > /dev/ttyAMA2" sudo sh -c "echo 3 > /dev/ttyAMA3" sudo sh -c "echo 4 > /dev/ttyAMA4" sleep 1 done | and moving my PC serial cable around the pins I found the following mapping: Code:Select all |GPIO14 = TXD0 -> ttyAMA0 GPIO0 = TXD2 -> ttyAMA1 GPIO4 = TXD3 -> ttyAMA2 GPIO8 = TXD4 -> ttyAMA3 GPIO12 = TXD5 -> ttyAMA4 | In other words, transmitting works on all 5 PL011/ttyAMA UARTs. Running "cat /dev/ttyAMA" on each of the different UARTs in turn and moving the TX pin of the PC serial port around the various RXD pins produced the RX mapping: Anyone know of Top Hats for a Raspberry Pi 4 that brings all 5 uarts to a 3.3V TTL level and drive some LEDs to see TX and RX activity, plus MAX232 style drivers to shift from 3.3 Volt level to + - ~10V RS-232 drive level to a DB-9 IBM compatible D shell Connector?  With possibly a RS-485 driver style connection for long wiring runs? Does this exist?  or  Should one fire up KiCAD and design such a board specifically for Raspberry Pi 4B 5 uarts?  Probably a market size of 10 - 50 boards world wide, not much? Hope this works for you John R. -- Fred Finster fred@thegalacticzoo.com +1 971-718-9144 https://GhostBSD-ARM64.blogspot.com https://ghostbsd.org From nobody Tue Jan 24 13:09:00 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P1S3Q1f9Mz3bQwF for ; Tue, 24 Jan 2023 13:09:06 +0000 (UTC) (envelope-from fred@thegalacticzoo.com) Received: from nmtao201.oxsus-vadesecure.net (mta-231b.oxsus-vadesecure.net [15.204.3.5]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P1S3N6MNMz4CLv for ; Tue, 24 Jan 2023 13:09:04 +0000 (UTC) (envelope-from fred@thegalacticzoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=webcom.xion.oxcs.net header.s=mail1 header.b=BlYIgVRc; spf=pass (mx1.freebsd.org: domain of fred@thegalacticzoo.com designates 15.204.3.5 as permitted sender) smtp.mailfrom=fred@thegalacticzoo.com; dmarc=pass (policy=quarantine) header.from=thegalacticzoo.com DKIM-Signature: v=1; a=rsa-sha256; bh=t4AgEktF50W8XwIJchVUOYmv/cGyAH4HA3pgwG LWKok=; c=relaxed/relaxed; d=webcom.xion.oxcs.net; h=from:reply-to: subject:date:to:cc:resent-date:resent-from:resent-to:resent-cc: in-reply-to:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; q=dns/txt; s=mail1; t=1674565742; x=1675170542; b=BlYIgVRc9y4dL/Rbn97sjyimOBIJ9+MahsZTQX0ng eVhjqufosmnEhI5DPO3GM5lcGM2dwGHcOVTKxK+98Wjtfw2ZiYtsl+ePyFdrYN7ztmtFhn6 0E6dp/DHXONy1c3ugjzKpUCsa8SQjXrhJahXtZiklnshdciElr8lKWN+KGoNgBPHDDoRqXU Zo2ZKudoSriiUatuGg/Ncycl80hVlZKqtY5NX3u4IxX27BY66Z6kmgkWW5DqioRHTo8j2sT Gel6aG812dUVUcnXap1irl/ctuEyCOVtHY3s4XEaa17QJiDfbv439QaZOPLTBTrnVeJczUY Z1CwSCCQDiYW4nqlw== Received: from proxy-6.proxy.cloudus.ewr.xion.oxcs.net ([76.14.221.149]) by oxsus2nmtao01p.internal.vadesecure.com with ngmta id 4a85bb05-173d40ab8361123e; Tue, 24 Jan 2023 13:09:02 +0000 Message-ID: <2bd8e680-df6a-cfe1-fbd2-ade1ac2d0497@thegalacticzoo.com> Date: Tue, 24 Jan 2023 05:09:00 -0800 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Content-Language: en-US To: freebsd-arm@freebsd.org From: Fred Finster Subject: Enabling Raspberry Pi 4B Uarts, specifically uart3 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[thegalacticzoo.com,quarantine]; R_DKIM_ALLOW(-0.20)[webcom.xion.oxcs.net:s=mail1]; R_SPF_ALLOW(-0.20)[+ip4:15.204.3.5]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:16276, ipnet:15.204.0.0/17, country:FR]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[webcom.xion.oxcs.net:+]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[15.204.3.5:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4P1S3N6MNMz4CLv X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N */ /* */From:/* */Date:/*Sun, 22 Jan 2023 21:36:36 UTC https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269104 Bug ID: 269104 Summary: The uarts2 - uarts5 do not function on raspberry pi 4B Product: Base System Version: 13.1-RELEASE Hardware: arm64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: jjrushford@gmail.com I’ve tried using the additional serial ports that are available with a raspberry pi 4B by enabling them in config.txt and when I try to read data on them, I see nothing. Specifically, I’ve wired an Adafruit ultimate GPS to uart3, gpio pins 4 and 5. I’ve built the RPI-firmware port and copied the uart0-5 dtb’s to /boot/msdos/overlays. I then enable uart3 in /boot/msdos/config.txt with dtoverlay=uart3 and reboot. After boot, I see that FreeBSD has created /dev/ttyu1 and /dev/cuau1 in the dev tree for uart3. When I try reading from ttyu1 or cuau1, I do not see any data whatsoever. I’ve set the baud rate to 9600 and disabled flow control but still no data is seen. If I change the wiring to use ttyu0, gpio pins 14 and 15, I do see data there. Just to verify the hardware, I installed a different SD card with raspberry pi OS, Debian, and enabled uart3 in config.txt. When I read the /dev/ttyAMA1 I do see the NMEA time stamps coming in uart3 at 9600 baud with no issue. Next I reboot back to FreeBSD 13.1, I cannot see any data from The GPS card on ttyu1 or cuau1. -- You are receiving this mail because: You are the assignee for the bug. In the aarch64 arm64 Raspberry Pi FreeBSD, maybe you need to enable some kernel modules kldstat kldload ucom umodem usb_template sysctl hw.usb.template=3 add in file /boot/loader.conf ucom_load="YES" umodem_load="YES" usb_template_load="YES" hw.usb.template=3 *cu -s 9600 -l /dev/ttyU1 What do you see? or rather cu? :>)  Do report back success or failure or changes necessary to make work, please. *https://forums.raspberrypi.com/viewtopic.php?t=244827&sid=f4a784a3c40ed0940e6fbb9f81af5015&start=25#p1590882 Re: Pi-4 Activating additional UART ports Mon Jan 06, 2020 10:36 am On all Pis, UART0 is a PL011 that appear to Linux as ttyAMA, and UART1 is an 8250 clone that appears as ttyS0. On a Pi4, UART2-5 are additional PL011s that also appear as ttyAMA. The number starts at 0 for the first enabled PL011 and counts up through all the enabled interfaces. The numbering is stable for any given combination of UARTs, but enabling or disabling one can change the number assignments of others. /PL011 appear to FreeBSD/*as /dev/ttyUx   So I wonder if one has to enable ucom and umodem and usb_template to view serial data comming back over what looks like a USB to serial interface?  Your thoughts? https://ghostbsd-arm64.blogspot.com/2023/01/hookup-gdb-to-black-magic-probe-v23.html * My setup trying to connect to USB serial port under X86_64 FreeBSD 13 to a Black Magic Probe -- Fred Finster fred@thegalacticzoo.com +1 971-718-9144 https://GhostBSD-ARM64.blogspot.com https://ghostbsd.org From nobody Tue Jan 24 14:21:55 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P1TgX5DXbz3bZs7 for ; Tue, 24 Jan 2023 14:22:00 +0000 (UTC) (envelope-from fred@thegalacticzoo.com) Received: from nmtao102.oxsus-vadesecure.net (mta-132a.oxsus-vadesecure.net [135.148.117.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P1TgW4qZTz4KqQ for ; Tue, 24 Jan 2023 14:21:59 +0000 (UTC) (envelope-from fred@thegalacticzoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=webcom.xion.oxcs.net header.s=mail1 header.b=NPc1GoQo; spf=pass (mx1.freebsd.org: domain of fred@thegalacticzoo.com designates 135.148.117.230 as permitted sender) smtp.mailfrom=fred@thegalacticzoo.com; dmarc=pass (policy=quarantine) header.from=thegalacticzoo.com DKIM-Signature: v=1; a=rsa-sha256; bh=QV/jk54QouH04SArWQAD2HrKUiCq3Upw2XLxG+ crahM=; c=relaxed/relaxed; d=webcom.xion.oxcs.net; h=from:reply-to: subject:date:to:cc:resent-date:resent-from:resent-to:resent-cc: in-reply-to:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; q=dns/txt; s=mail1; t=1674570117; x=1675174917; b=NPc1GoQouy5xg0oHJWrDoHHotdW3zePUtKKdKEolN K7ogB4IXiUzCHFtCyuskHZH08mSfbTJQ8Gv8FWCS5Glt1ouZdPoy90KW6cQWOkGx7ZQWJMS ClsYz2VokmrORQfaFDZjhSkO4m5X4bsrWmXe5fvLX+2rInq6Cqy+wCokZBu1hEjAEAFTI95 kcH1zkXZLj3oBpWINk7r+u7Foh7foT3INYnXhAAz4iXWPAdK1co0pQny/0AuNVZtiRQb0zn +NKltYAABXiKTAGcbLsysyhxC/NAkJujXag1cxyAG4T/c8oHzRnH7hSG3skHFxBr7iiOTWV /OayVtZ1JUK2liZ1A== Received: from proxy-2.proxy.cloudus.ewr.xion.oxcs.net ([76.14.221.149]) by oxsus1nmtao02p.internal.vadesecure.com with ngmta id d71021bf-173d44a62096a934; Tue, 24 Jan 2023 14:21:57 +0000 Message-ID: <3eb41d8b-742f-17db-b56d-56d5dd748b50@thegalacticzoo.com> Date: Tue, 24 Jan 2023 06:21:55 -0800 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Content-Language: en-US To: freebsd-arm@freebsd.org From: Fred Finster Subject: Advertising FreeBSD 14.0 on Raspberry Pi on BSDnow.tv Podcast , a raspberryi.com forum post Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[thegalacticzoo.com,quarantine]; R_DKIM_ALLOW(-0.20)[webcom.xion.oxcs.net:s=mail1]; R_SPF_ALLOW(-0.20)[+ip4:135.148.117.230]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:16276, ipnet:135.148.0.0/17, country:FR]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[webcom.xion.oxcs.net:+]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[135.148.117.230:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[135.148.117.230:from] X-Rspamd-Queue-Id: 4P1TgW4qZTz4KqQ X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N https://www.bsdnow.tv/489   FreeBSD 14.0 install  is mentioned on BSDNOW.TV  podcast 489.  WorldWide Baby!  wow! https://forums.raspberrypi.com/viewtopic.php?t=343233 Raspberrypi.com forum post. Other O/S --> FreeBSD --> (Solved), HDMI audio sound output through TV speakers Freebsd 13 or 14 plus VCHIQ audio patch file https://ghostbsd-arm64.blogspot.com/2022/09/freebsd-140-compiling-kernel-for.html?m=1 Fred Finster's blog, detailing starting from a new Raspberry Pi 4B and installing FreeBSD using a USB Flash drive stick and "bsdinstall" to install FreeBSD over the internet to a 500GB SSD drive. Plus details of  building a new kernel with VCHIQ patch to enable HDMI Audio sound over HDMI TV speakers. Yes, we are all busy with our own particular needs and interests as to why we choose to use FreeBSD versus the well supported Raspberry Pi O/S (Raspbian). Could you take a moment and create a short forum post in the FreeBSD subtopic about your reason to use FreeBSD and what value you obtained by using FreeBSD versus using Linux.   A little advertising will grow arm64 FreeBSD using population on the Raspberry Pis. We will all benefit from having a few more users.   Without us sharing FreeBSD knowledge, we will stay a tiny secret UNIX(tm) clan group. Here is FreeBSD Subtopic at RaspberryPi.com https://forums.raspberrypi.com/viewforum.php?f=85 Create a forum post in your own style and direction.   Include a short paragraph, This is why I use FreeBSD and the value it gives me over using the available Linux distributions. A few more forum posts and replies might help grow the number of FreeBSD users on arm64 hardware. Thank you, Fred  You are welcome to submit your own ideas to BSDnow.tv https://www.bsdnow.tv/contact  or email feedback@bsdnow.tv ps.  Here is forum post asking for a BSD supporter to update the FreeBSD wiki.freebsd.org/arm/Raspberry%20Pi With the sake of completeness some BSD fan could please update this table: https://wiki.freebsd.org/arm/Raspberry%20Pi https://forums.raspberrypi.com/viewtopic.php?t=341196&sid=d6678de0b38cdd1b93ced45ee109e9f9 Does the Camera support motion hosted on Raspberry Pi Zero W?   Particularly I'm interested if the camera works with motion with the latest FreeBSD on RPI Zero W. As I see it will be a nogo because WIFI is not supported either, unless that doc is completely obsolete. :X -- Fred Finster fred@thegalacticzoo.com +1 971-718-9144 https://GhostBSD-ARM64.blogspot.com https://ghostbsd.org Original Email sent to BSDnow.tv November 22, 2022 Subject: Installing FreeBSD 14.0 to 500gb SSD usb external drive, using bsdinstall. (solved) HDMI audio patch to FreeBSD kernel Hello gentlemen, Sharing with your listeners this Forum Post about: 1.) starting from a bare Raspberry Pi 4B or RasPi 400 keyboard, 2.) adding a usb external (usb - sata )  ssd drive, 3.) burning a Freebsd 14.0 snapshot image, https://freebsd.org/where 4.) booting freebsd from usb flash drive, 5.) installing Freebsd 13.1 or 14.0 over the internet to ssd drive using bsdinstall command. link to my forum post https://forums.raspberrypi.com/viewforum.php?f=85 https://t.me/+ST6N61pnu3Di8zgk  ARM Open-Source Telegram group to discuss ARM software. https://t.me/SBcomputing  Single Board Computing Telegram Group I share these sites to encourage others to have a inexpensive desktop computer of their own. Since Freebsd Foundation has made ARM64 a Tier 1 supported cpu  Desktop Environments like MATE and XFCE4 are available along with 30,000 other packages.  All Free to use for DIY (do it yourself). Welcome others to test and share this method around the 🌍 world.  yes Linux is also good O/S, yet I choose Freebsd for stability. Respectfully, Fred Finster +1 971-718-9144 fred@thegalacticzoo.com GhostBSD-ARM64.blogspot.com puppylinux-or-pcbsd.blogspot.com From nobody Tue Jan 24 15:35:02 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P1WHt0LMCz3blKf for ; Tue, 24 Jan 2023 15:35:06 +0000 (UTC) (envelope-from 01070185e46b1a6e-ee34b885-1215-45c7-ac18-83320c02cac2-000000@eu-central-1.amazonses.com) Received: from b224-8.smtp-out.eu-central-1.amazonses.com (b224-8.smtp-out.eu-central-1.amazonses.com [69.169.224.8]) (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 4P1WHr5Bk2z3CH5 for ; Tue, 24 Jan 2023 15:35:04 +0000 (UTC) (envelope-from 01070185e46b1a6e-ee34b885-1215-45c7-ac18-83320c02cac2-000000@eu-central-1.amazonses.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cyclaero.com header.s=ez3m2wtglgbm5wj4q3hdyvc7qtjtqmlb header.b=kHgSvj+u; dkim=pass header.d=amazonses.com header.s=sokbgaaqhfgd6qjht2wmdajpuuanpimv header.b=y2BxlDLl; spf=pass (mx1.freebsd.org: domain of 01070185e46b1a6e-ee34b885-1215-45c7-ac18-83320c02cac2-000000@eu-central-1.amazonses.com designates 69.169.224.8 as permitted sender) smtp.mailfrom=01070185e46b1a6e-ee34b885-1215-45c7-ac18-83320c02cac2-000000@eu-central-1.amazonses.com; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ez3m2wtglgbm5wj4q3hdyvc7qtjtqmlb; d=cyclaero.com; t=1674574502; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References; bh=mavJHJUlTh/CxGREvyTY729ddrZtjeFDVLA8CjX9ucs=; b=kHgSvj+uR71v1L7VEnF69VQKwqs7mwT4pGBC2yQxetOZxjG1H/WXkqz+2da5hwsE 1dQkn9XPFm6CuXb3uO8BRgyn3eyReWO4RwEz1TdNntBzlNF5rEJe7NZiBd90C+KKeqq +H2L30jlkCNjfkr66j97UoygBsPa6bJzqJz76QWJJVgKEpiaH/YimOrGw+WhlKPP9hF jCJ1+1OJArSRci11prcexEsdEEEwo70OUF3SeXdqt1UX7SO8L45vFPTZ+lWXdhJ3mRP vJdKciBd7WCENzZgViFiG3f/9MG6xXhCa6XjblH6ZT1ID4Qxi78x9An21wZ/KsRZECx RDO+blcP6A== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=sokbgaaqhfgd6qjht2wmdajpuuanpimv; d=amazonses.com; t=1674574502; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=mavJHJUlTh/CxGREvyTY729ddrZtjeFDVLA8CjX9ucs=; b=y2BxlDLlaGZxRAw7Ftkd2XgFndumhxM/54J7WSEhWWq254MSKqK47JgI6ioh/5UL fiiIuQdIfg0JIEsxq9l7dqOqn5fH02al18pWRO9HdQlkWbSwREj0GNxLNz+8VxCnh9K L9yGg3wYeW7VKMacPCqWYrDSmGcOe23+xG+WOwyY= From: "Dr. Rolf Jansen" Message-ID: <01070185e46b1a6e-ee34b885-1215-45c7-ac18-83320c02cac2-000000@eu-central-1.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A3A27D85-289A-4F7A-9B78-6572DD14D844" List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Subject: Re: GPIO inputs on Pis? Date: Tue, 24 Jan 2023 15:35:02 +0000 In-Reply-To: <0b235f83-7cb3-1d14-7c64-aee7c1c0c23d@denninger.net> Cc: Karl Denninger To: "freebsd-arm@freebsd.org" References: <0b235f83-7cb3-1d14-7c64-aee7c1c0c23d@denninger.net> X-Mailer: Apple Mail (2.3445.104.15) Feedback-ID: 1.eu-central-1.i3TZMOZE/rJo3HQG0qvfyolMxXljeCj2Qj8Jp3rxK3c=:AmazonSES X-SES-Outgoing: 2023.01.24-69.169.224.8 X-Spamd-Result: default: False [-0.70 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; FROM_NAME_HAS_TITLE(1.00)[dr]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MV_CASE(0.50)[]; FORGED_SENDER(0.30)[freebsd-rj@cyclaero.com,01070185e46b1a6e-ee34b885-1215-45c7-ac18-83320c02cac2-000000@eu-central-1.amazonses.com]; R_DKIM_ALLOW(-0.20)[cyclaero.com:s=ez3m2wtglgbm5wj4q3hdyvc7qtjtqmlb,amazonses.com:s=sokbgaaqhfgd6qjht2wmdajpuuanpimv]; R_SPF_ALLOW(-0.20)[+ip4:69.169.224.0/20]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[69.169.224.8:from]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[cyclaero.com]; TO_DN_EQ_ADDR_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[freebsd-rj@cyclaero.com,01070185e46b1a6e-ee34b885-1215-45c7-ac18-83320c02cac2-000000@eu-central-1.amazonses.com]; DWL_DNSWL_NONE(0.00)[amazonses.com:dkim]; RCPT_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[cyclaero.com:+,amazonses.com:+]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; ASN(0.00)[asn:16509, ipnet:69.169.224.0/23, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[69.169.224.8:from] X-Rspamd-Queue-Id: 4P1WHr5Bk2z3CH5 X-Spamd-Bar: / X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_A3A27D85-289A-4F7A-9B78-6572DD14D844 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Am 23.01.2023 um 11:41 schrieb Karl Denninger : >=20 > Is there support somewhere in the 13.x for other than "read current = state" / "set current state"? >=20 > Specifically, there is evidence in the sys/gpio.h header file that I = can open up a file descriptor and then use select()/read() to grab the = contents of a ring buffer of some size (presumably interrupt-posted) of = events since last look, and determine if there's anything in there. = Provided you're reasonably fast this might be enough to, for example, = read an optical encoder that has a modest pulse rate. >=20 > I see apparent review code at https://reviews.freebsd.org/D27398 = from late 2020, but nothing else I = can find digging around; an example (assuming it is actually implemented = and works) would be helpful >=20 See = https://forums.freebsd.org/threads/gpio-api-general-orange-pi-h3.83950/pos= t-556728 = And the messages in that thread that follow the one linked above. There is a respective thread on this mailing list as well: Porting FreeBSD to ARM processors: User Space GPIO Interrupt programming = - GSoC-2018 = = --Apple-Mail=_A3A27D85-289A-4F7A-9B78-6572DD14D844 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
Am 23.01.2023 um 11:41 schrieb Karl Denninger <karl@denninger.net>:

Is there support somewhere in the 13.x for other than "read current state" / "set current state"?

Specifically, there is evidence in the sys/gpio.h header file that I can open up a file descriptor and then use select()/read() to grab the contents of a ring buffer of some size (presumably interrupt-posted) of events since last look, and determine if there's anything in there.  Provided you're reasonably fast this might be enough to, for example, read an optical encoder that has a modest pulse rate.

I see apparent review code at https://reviews.freebsd.org/D27398 from late 2020, but nothing else I can find digging around; an example (assuming it is actually implemented and works) would be helpful

See


And the messages in that thread that follow the one linked above.

There is a respective thread on this mailing list as well:

--Apple-Mail=_A3A27D85-289A-4F7A-9B78-6572DD14D844-- From nobody Tue Jan 24 15:35:56 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P1WKc5Rcqz3bkwb for ; Tue, 24 Jan 2023 15:36:36 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P1WKb6WvPz3CgT for ; Tue, 24 Jan 2023 15:36:35 +0000 (UTC) (envelope-from karl@denninger.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net; dmarc=pass (policy=none) header.from=denninger.net Received: from denninger.net (097-081-026-048.res.spectrum.com [97.81.26.48]) by colo1.denninger.net (Postfix) with ESMTP id 784012110A8 for ; Tue, 24 Jan 2023 10:35:59 -0500 (EST) Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 11E0C28025D for ; Tue, 24 Jan 2023 10:35:59 -0500 (EST) Message-ID: Date: Tue, 24 Jan 2023 10:35:56 -0500 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: GPIO inputs on Pis? Content-Language: en-US To: freebsd-arm@freebsd.org References: <0b235f83-7cb3-1d14-7c64-aee7c1c0c23d@denninger.net> <01070185e46b1a6e-ee34b885-1215-45c7-ac18-83320c02cac2-000000@eu-central-1.amazonses.com> From: Karl Denninger In-Reply-To: <01070185e46b1a6e-ee34b885-1215-45c7-ac18-83320c02cac2-000000@eu-central-1.amazonses.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms020801080202010702090908" X-Spamd-Result: default: False [-4.90 / 15.00]; SIGNED_SMIME(-2.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[denninger.net,none]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+mx]; ARC_NA(0.00)[]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[karl]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4P1WKb6WvPz3CgT X-Spamd-Bar: ---- X-ThisMailContainsUnwantedMimeParts: N This is a cryptographically signed message in MIME format. --------------ms020801080202010702090908 Content-Type: multipart/alternative; boundary="------------8LhnITfTu7p3ng0t8nbhzlM5" --------------8LhnITfTu7p3ng0t8nbhzlM5 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Thank you -- will check it out. On 1/24/2023 10:35, Dr. Rolf Jansen wrote: >> Am 23.01.2023 um 11:41 schrieb Karl Denninger : >> >> Is there support somewhere in the 13.x for other than "read current >> state" / "set current state"? >> >> Specifically, there is evidence in the sys/gpio.h header file that I >> can open up a file descriptor and then use select()/read() to grab >> the contents of a ring buffer of some size (presumably >> interrupt-posted) of events since last look, and determine if there's >> anything in there.  Provided you're reasonably fast this might be >> enough to, for example, read an optical encoder that has a modest >> pulse rate. >> >> I see apparent review code at https://reviews.freebsd.org/D27398 from >> late 2020, but nothing else I can find digging around; an example >> (assuming it is actually implemented and works) would be helpful >> > See > > https://forums.freebsd.org/threads/gpio-api-general-orange-pi-h3.83950/post-556728 > > And the messages in that thread that follow the one linked above. > > There is a respective thread on this mailing list as well: > > Porting FreeBSD to ARM processors: User Space GPIO Interrupt > programming - GSoC-2018 > -- Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------8LhnITfTu7p3ng0t8nbhzlM5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Thank you -- will check it out.

On 1/24/2023 10:35, Dr. Rolf Jansen wrote:
Am 23.01.2023 um 11:41 schrieb Karl Denninger <karl@denninger.net>:

Is there support somewhere in the 13.x for other than "read current state" / "set current state"?

Specifically, there is evidence in the sys/gpio.h header file that I can open up a file descriptor and then use select()/read() to grab the contents of a ring buffer of some size (presumably interrupt-posted) of events since last look, and determine if there's anything in there.  Provided you're reasonably fast this might be enough to, for example, read an optical encoder that has a modest pulse rate.

I see apparent review code at https://reviews.freebsd.org/D27398 from late 2020, but nothing else I can find digging around; an example (assuming it is actually implemented and works) would be helpful

See


And the messages in that thread that follow the one linked above.

There is a respective thread on this mailing list as well:

--
Karl Denninger
karl@denninger.net
The Market Ticker
[S/MIME encrypted email preferred]
--------------8LhnITfTu7p3ng0t8nbhzlM5-- --------------ms020801080202010702090908 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DbowggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBxIwggT6oAMCAQICEgLG8yH4PQFdbd9x Ugmpzl1jXzANBgkqhkiG9w0BAQsFADB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlk YTEZMBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENB MSUwIwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBMB4XDTIyMDYyOTE2MTYz NloXDTI3MDYyODE2MTYzNlowOjELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEX MBUGA1UEAwwOS2FybCBEZW5uaW5nZXIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC AQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvW ZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B 3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTgy+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYI XgVVPgfZZrbJJb5HWOQpvvhILpPCD3xsYJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMi WapsatKm8mxuOOGOEBhAoTVTwUHlMNTg6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMb NQm1mWREQhw3axgGLSntjjnznJr5vsvXSYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZM qa20JLAF1YagutDiMRURU23iWS7bA9tMcXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5 CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1l y+5ZOZbxBAZZMod4y4b4FiRUhRI97r9lCxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY 2BlA7ExM8XShMd9bRPZrNTokPQPUCWCgCdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEE MDAuMCwGCCsGAQUFBzABhiBodHRwOi8vb2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNV HRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYI KwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCGSAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBD bGllbnQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNV HSMEgcIwgb+AFF3AXsKnjdPND5+bxVECGKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQ MA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5 c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lz dGVtcyBMTEMgMjAxNyBDQYITAORIioIQzl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJs QGRlbm5pbmdlci5uZXQwDQYJKoZIhvcNAQELBQADggIBAKquc7cu0xc8FNtAQauZvocDzWQj 7HG9YvMbWnMi+ckhiA3rdW5NwWg0HBhBho1YlnqV+ntCVE2L8ezohHWm+KAdfXgpraL86Vsn 3ywNlZu/3COMpo2ALuHln8YQtH3Y8ebvzKMdlf2b5WB+7mOFIxXIr4AnNOLKCkq5ZhzC6JW6 Jvw3P0csiGa3UrfatYID5NvPgkaQvEgimEjG3psZqwQTL2Wxohvw783PrDt3wS0XeNhvQ61g 3QJFZKuv+bmGH3YBSPo1t6NUGAr+JozX5lDihB8JGkBt/NwdYec49a08uL0BbPaAJ7NjuIPG 7Y0Ak7PXZT37yx/Zla9PzLMJFgbelOkaatdzbblMZPDEVZ27l4lGMmV83Lm3YP17sdAyS/Wp mav7WmJUkQ9iuIKzSpdc82i9Mfujl1vbBtwtkHNPPtKuulIFM4ZwrPKjlVdLqTSqD8m9yHEi Y0PuAooq63OpJWF6hvMaiIPBWEAVIaDW9uG0MshLl9DnHnMyrJTfuC33Z9mOGMz7dRBjJd5Y W02xAzYnUuEBOpj+LQv5R8XIFMHFXktqEKvQrXeM2RU+PcZqKOBkTktxBLn3NI5VfA15Jk0c 5V5XcOqo3p2hvrwvXrinrb2pEREnoqmfrkXT3zOq5Y6ryRH8u734lGEF0dILXzoV4PM7XFit oTePoEjmMYIFBDCCBQACAQEwgZEwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGEx GTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTEl MCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQQISAsbzIfg9AV1t33FSCanO XWNfMA0GCWCGSAFlAwQCAwUAoIICQzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0yMzAxMjQxNTM1NThaME8GCSqGSIb3DQEJBDFCBECFtDo9KdxgEeCU3ZU4 GP+qU+QGmGQcTuf57Wryi+byCLFGHG7ogy3/hR05jgOEbucz2QtGRFpgto4BNiaRZC+rMGwG CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw gaIGCSsGAQQBgjcQBDGBlDCBkTB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTEZ MBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENBMSUw IwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBAhICxvMh+D0BXW3fcVIJqc5d Y18wgaQGCyqGSIb3DQEJEAILMYGUoIGRMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9y aWRhMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMg Q0ExJTAjBgNVBAMMHEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0ECEgLG8yH4PQFdbd9x Ugmpzl1jXzANBgkqhkiG9w0BAQEFAASCAgCLPSGSEphICe/OD5ns7ZUm0ZS3H4eEyoEBX85O LJnryk5H00VP0M5FqfJMEzqtpcNzsmiTyiNnRJ1NZfhOp2QBgu7p3/SEipWP3SHOU8pPsHJx 26dSJwc+WmyknRu1y28Sw2qMBrz7AeCjBxdASD4yXTFZj+VDp1X5c0ApSt0QdcEdTEfGPZvU 3hVN7xi22BEkrAv5sO/dg20GpE0qc0dQ0yTj5X5UYnZnXET1tabyL2heJyRpS57UWd4AsWKQ ONAQpLcPtbt9zshZ0LdlU1HWC4pfLqKgurqB9RjQptSOJUER7/NQRkqAdKPicV1PYwknVIPS GSWaS1B8+Y5ECFtK+5NQjT1iCgJvYMejj07lxFKULIveNoZb7WcO9BzE7O/slmMxX1mJwKOI i6vKlVKmno4inEbJoZtRFpmjSyE+AhAy8BvnXOETYtoyEbmqBrFZOCAP+tj0mpdWSm6R7wj1 Q91Chn6BTf88kmaUUAoN2RosA0svEy3I46IwwA/u1+7eQ2niDrF17+JaN1WiG/eXdbfRl54o D5iVv8fDpNXH9Voec96eNheBv99wr5IXSgfhPeFE5X45mSNRLucBI8oRcP5FugQRGTIdP2+6 1zktxtPBYHzAqyFxZ+El5AJqSsg6XzPHkCFdbQalQcVtrbrLszWIjTqRIKKnrzVp6N/zywAA AAAAAA== --------------ms020801080202010702090908-- From nobody Tue Jan 24 15:43:52 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P1WV30r6bz30tWc for ; Tue, 24 Jan 2023 15:43:55 +0000 (UTC) (envelope-from 01070185e4732fd8-c0bede0b-d9df-4557-a174-cb237fa4bfaf-000000@eu-central-1.amazonses.com) Received: from b224-8.smtp-out.eu-central-1.amazonses.com (b224-8.smtp-out.eu-central-1.amazonses.com [69.169.224.8]) (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 4P1WV15VtZz3Dl9 for ; Tue, 24 Jan 2023 15:43:53 +0000 (UTC) (envelope-from 01070185e4732fd8-c0bede0b-d9df-4557-a174-cb237fa4bfaf-000000@eu-central-1.amazonses.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cyclaero.com header.s=ez3m2wtglgbm5wj4q3hdyvc7qtjtqmlb header.b=NFW5OIiD; dkim=pass header.d=amazonses.com header.s=sokbgaaqhfgd6qjht2wmdajpuuanpimv header.b=GYg5wMo8; spf=pass (mx1.freebsd.org: domain of 01070185e4732fd8-c0bede0b-d9df-4557-a174-cb237fa4bfaf-000000@eu-central-1.amazonses.com designates 69.169.224.8 as permitted sender) smtp.mailfrom=01070185e4732fd8-c0bede0b-d9df-4557-a174-cb237fa4bfaf-000000@eu-central-1.amazonses.com; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ez3m2wtglgbm5wj4q3hdyvc7qtjtqmlb; d=cyclaero.com; t=1674575032; h=From:Content-Type:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id; bh=sFDBwOg0psorh5Y3uNyXV9IUUM7h/+8AoE1hzUJO+Rg=; b=NFW5OIiD5J73fFuUrKJDAu2JfhcCa4buOqmMOx7ld6Bvt6bkOrKjyp47qzGHLjJf 89dN3harLbO8kJgVUKenpY8CZ2ta4L1X84y8tkIT04isP4IKFkIqRz6igzqLVm8wzOY ItQ7+ba3buKJAoz5053cWv2Nj9yRqRirgcQ1nDhi1llE/0jQz50j7+GhsnAMIUIpum/ ZY5ewkqPvYrg2CyWuv/kV8xBLwpP4MsA9HzFLie16quOfccca7it1k3gfLvDafIonqx Xm+NTs+d0Anv7WlrR3hj7nDemJzNO2V7HA3CD2DIHPoHPWfxYFTmeRMASfWAhL3+eS8 3ES82jz7ng== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=sokbgaaqhfgd6qjht2wmdajpuuanpimv; d=amazonses.com; t=1674575032; h=From:Content-Type:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id:Feedback-ID; bh=sFDBwOg0psorh5Y3uNyXV9IUUM7h/+8AoE1hzUJO+Rg=; b=GYg5wMo8TF656DH6nam+gTyAeFQJrrrlx/TDG1+ygE5coCNIMknl4ipFlbQKjmnt P+AqJOGI45lQHZmEGjhPQud2H7a8hCNmDY5ZISko6jHPb4vHjFbp/SLY8UMrX8rto8H X4+X3nrYfYeq8u9KOd2Rx50xzMhxQGcWo2ygVFmo= From: "Dr. Rolf Jansen" Content-Type: multipart/alternative; boundary="Apple-Mail=_C69401B8-1DDE-4319-AE6A-B62FC4FF9828" List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Subject: Re: GPIO inputs on Pis? Date: Tue, 24 Jan 2023 15:43:52 +0000 References: <0b235f83-7cb3-1d14-7c64-aee7c1c0c23d@denninger.net> <01070185e46b1a6e-ee34b885-1215-45c7-ac18-83320c02cac2-000000@eu-central-1.amazonses.com> To: freebsd-arm In-Reply-To: Message-ID: <01070185e4732fd8-c0bede0b-d9df-4557-a174-cb237fa4bfaf-000000@eu-central-1.amazonses.com> X-Mailer: Apple Mail (2.3445.104.15) Feedback-ID: 1.eu-central-1.i3TZMOZE/rJo3HQG0qvfyolMxXljeCj2Qj8Jp3rxK3c=:AmazonSES X-SES-Outgoing: 2023.01.24-69.169.224.8 X-Spamd-Result: default: False [0.35 / 15.00]; FROM_NAME_HAS_TITLE(1.00)[dr]; SUBJECT_ENDS_QUESTION(1.00)[]; URI_COUNT_ODD(1.00)[17]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.994]; NEURAL_HAM_LONG(-0.96)[-0.958]; MV_CASE(0.50)[]; FORGED_SENDER(0.30)[freebsd-rj@cyclaero.com,01070185e4732fd8-c0bede0b-d9df-4557-a174-cb237fa4bfaf-000000@eu-central-1.amazonses.com]; R_DKIM_ALLOW(-0.20)[cyclaero.com:s=ez3m2wtglgbm5wj4q3hdyvc7qtjtqmlb,amazonses.com:s=sokbgaaqhfgd6qjht2wmdajpuuanpimv]; R_SPF_ALLOW(-0.20)[+ip4:69.169.224.0/20]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[cyclaero.com]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[69.169.224.8:from]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[amazonses.com:dkim]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; DKIM_TRACE(0.00)[cyclaero.com:+,amazonses.com:+]; TO_DN_ALL(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; ASN(0.00)[asn:16509, ipnet:69.169.224.0/23, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_NEQ_ENVFROM(0.00)[freebsd-rj@cyclaero.com,01070185e4732fd8-c0bede0b-d9df-4557-a174-cb237fa4bfaf-000000@eu-central-1.amazonses.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[69.169.224.8:from] X-Rspamd-Queue-Id: 4P1WV15VtZz3Dl9 X-Spamd-Bar: / X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_C69401B8-1DDE-4319-AE6A-B62FC4FF9828 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I sent an old ink to the thread on the mailing list, which does not work = anymore. Here ist the new link: = https://lists.freebsd.org/pipermail/freebsd-arm/2020-November/022738.html = > Am 24.01.2023 um 12:35 schrieb Karl Denninger >: >=20 > Thank you -- will check it out. >=20 > On 1/24/2023 10:35, Dr. Rolf Jansen wrote: >>> Am 23.01.2023 um 11:41 schrieb Karl Denninger >: >>>=20 >>> Is there support somewhere in the 13.x for other than "read current = state" / "set current state"? >>>=20 >>> Specifically, there is evidence in the sys/gpio.h header file that I = can open up a file descriptor and then use select()/read() to grab the = contents of a ring buffer of some size (presumably interrupt-posted) of = events since last look, and determine if there's anything in there. = Provided you're reasonably fast this might be enough to, for example, = read an optical encoder that has a modest pulse rate. >>>=20 >>> I see apparent review code at https://reviews.freebsd.org/D27398 = from late 2020, but nothing else I = can find digging around; an example (assuming it is actually implemented = and works) would be helpful >>>=20 >> See >>=20 >> = https://forums.freebsd.org/threads/gpio-api-general-orange-pi-h3.83950/pos= t-556728 = >>=20 >> And the messages in that thread that follow the one linked above. >>=20 >> There is a respective thread on this mailing list as well: >>=20 >> Porting FreeBSD to ARM processors: User Space GPIO Interrupt = programming - GSoC-2018 = = --=20 > Karl Denninger > karl@denninger.net > The Market Ticker > [S/MIME encrypted email preferred] --Apple-Mail=_C69401B8-1DDE-4319-AE6A-B62FC4FF9828 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
I sent an old ink to the thread on the mailing list, which does not work anymore. Here ist the new link:


Am 24.01.2023 um 12:35 schrieb Karl Denninger <karl@denninger.net>:

Thank you -- will check it out.

On 1/24/2023 10:35, Dr. Rolf Jansen wrote:
Am 23.01.2023 um 11:41 schrieb Karl Denninger <karl@denninger.net>:

Is there support somewhere in the 13.x for other than "read current state" / "set current state"?

Specifically, there is evidence in the sys/gpio.h header file that I can open up a file descriptor and then use select()/read() to grab the contents of a ring buffer of some size (presumably interrupt-posted) of events since last look, and determine if there's anything in there.  Provided you're reasonably fast this might be enough to, for example, read an optical encoder that has a modest pulse rate.

I see apparent review code at https://reviews.freebsd.org/D27398 from late 2020, but nothing else I can find digging around; an example (assuming it is actually implemented and works) would be helpful

See


And the messages in that thread that follow the one linked above.

There is a respective thread on this mailing list as well:

--
Karl Denninger
karl@denninger.net
The Market Ticker
[S/MIME encrypted email preferred]

--Apple-Mail=_C69401B8-1DDE-4319-AE6A-B62FC4FF9828-- From nobody Tue Jan 24 16:58:31 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P1Y8p4qLqz314YV for ; Tue, 24 Jan 2023 16:59:06 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P1Y8n3bTwz3NR2 for ; Tue, 24 Jan 2023 16:59:05 +0000 (UTC) (envelope-from karl@denninger.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net; dmarc=pass (policy=none) header.from=denninger.net Received: from denninger.net (097-081-026-048.res.spectrum.com [97.81.26.48]) by colo1.denninger.net (Postfix) with ESMTP id AA2AE2110A8 for ; Tue, 24 Jan 2023 11:58:34 -0500 (EST) Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 43D022805A4 for ; Tue, 24 Jan 2023 11:58:34 -0500 (EST) Message-ID: Date: Tue, 24 Jan 2023 11:58:31 -0500 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: GPIO inputs on Pis? Content-Language: en-US To: freebsd-arm@freebsd.org References: <0b235f83-7cb3-1d14-7c64-aee7c1c0c23d@denninger.net> <01070185e46b1a6e-ee34b885-1215-45c7-ac18-83320c02cac2-000000@eu-central-1.amazonses.com> <01070185e4732fd8-c0bede0b-d9df-4557-a174-cb237fa4bfaf-000000@eu-central-1.amazonses.com> From: Karl Denninger In-Reply-To: <01070185e4732fd8-c0bede0b-d9df-4557-a174-cb237fa4bfaf-000000@eu-central-1.amazonses.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms090701070402000207070901" X-Spamd-Result: default: False [-4.90 / 15.00]; SIGNED_SMIME(-2.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[denninger.net,none]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+mx:c]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; R_DKIM_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[karl]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4P1Y8n3bTwz3NR2 X-Spamd-Bar: ---- X-ThisMailContainsUnwantedMimeParts: N This is a cryptographically signed message in MIME format. --------------ms090701070402000207070901 Content-Type: multipart/alternative; boundary="------------ira0iM9tBNbzoOFDp1cpalau" --------------ira0iM9tBNbzoOFDp1cpalau Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/24/2023 10:43, Dr. Rolf Jansen wrote: > I sent an old ink to the thread on the mailing list, which does not > work anymore. Here ist the new link: > > https://lists.freebsd.org/pipermail/freebsd-arm/2020-November/022738.html > >> Am 24.01.2023 um 12:35 schrieb Karl Denninger : >> >> Thank you -- will check it out. >> >> On 1/24/2023 10:35, Dr. Rolf Jansen wrote: >>>> Am 23.01.2023 um 11:41 schrieb Karl Denninger : >>>> >>>> Is there support somewhere in the 13.x for other than "read current >>>> state" / "set current state"? >>>> >>>> Specifically, there is evidence in the sys/gpio.h header file that >>>> I can open up a file descriptor and then use select()/read() to >>>> grab the contents of a ring buffer of some size (presumably >>>> interrupt-posted) of events since last look, and determine if >>>> there's anything in there.  Provided you're reasonably fast this >>>> might be enough to, for example, read an optical encoder that has a >>>> modest pulse rate. >>>> >>>> I see apparent review code at https://reviews.freebsd.org/D27398 >>>> from late 2020, but nothing else I can find digging around; an >>>> example (assuming it is actually implemented and works) would be >>>> helpful >>>> >>> See >>> >>> https://forums.freebsd.org/threads/gpio-api-general-orange-pi-h3.83950/post-556728 >>> >>> And the messages in that thread that follow the one linked above. >>> >>> There is a respective thread on this mailing list as well: >>> >>> Porting FreeBSD to ARM processors: User Space GPIO Interrupt >>> programming - GSoC-2018 >>> >> -- >> Karl Denninger >> karl@denninger.net >> /The Market Ticker/ >> /[S/MIME encrypted email preferred]/ > So the answer at this point appears to be "not in the codebase and no indication on when/if it might be, but there are patches that are in some state of development." Being able to read an encoder of some sort basically means being able to know how many events occurred between "looks"; for most purposes you don't need each event delivered exactly when it occurs, but missing some of the counts entirely is not acceptable. -- Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ira0iM9tBNbzoOFDp1cpalau Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 1/24/2023 10:43, Dr. Rolf Jansen wrote:
I sent an old ink to the thread on the mailing list, which does not work anymore. Here ist the new link:


Am 24.01.2023 um 12:35 schrieb Karl Denninger <karl@denninger.net>:

Thank you -- will check it out.

On 1/24/2023 10:35, Dr. Rolf Jansen wrote:
Am 23.01.2023 um 11:41 schrieb Karl Denninger <karl@denninger.net>:

Is there support somewhere in the 13.x for other than "read current state" / "set current state"?

Specifically, there is evidence in the sys/gpio.h header file that I can open up a file descriptor and then use select()/read() to grab the contents of a ring buffer of some size (presumably interrupt-posted) of events since last look, and determine if there's anything in there.  Provided you're reasonably fast this might be enough to, for example, read an optical encoder that has a modest pulse rate.

I see apparent review code at https://reviews.freebsd.org/D27398 from late 2020, but nothing else I can find digging around; an example (assuming it is actually implemented and works) would be helpful

See


And the messages in that thread that follow the one linked above.

There is a respective thread on this mailing list as well:

--
Karl Denninger
karl@denninger.net
The Market Ticker
[S/MIME encrypted email preferred]

So the answer at this point appears to be "not in the codebase and no indication on when/if it might be, but there are patches that are in some state of development."

Being able to read an encoder of some sort basically means being able to know how many events occurred between "looks"; for most purposes you don't need each event delivered exactly when it occurs, but missing some of the counts entirely is not acceptable.

--
Karl Denninger
karl@denninger.net
The Market Ticker
[S/MIME encrypted email preferred]
--------------ira0iM9tBNbzoOFDp1cpalau-- --------------ms090701070402000207070901 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DbowggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBxIwggT6oAMCAQICEgLG8yH4PQFdbd9x Ugmpzl1jXzANBgkqhkiG9w0BAQsFADB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlk YTEZMBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENB MSUwIwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBMB4XDTIyMDYyOTE2MTYz NloXDTI3MDYyODE2MTYzNlowOjELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEX MBUGA1UEAwwOS2FybCBEZW5uaW5nZXIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC AQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvW ZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B 3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTgy+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYI XgVVPgfZZrbJJb5HWOQpvvhILpPCD3xsYJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMi WapsatKm8mxuOOGOEBhAoTVTwUHlMNTg6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMb NQm1mWREQhw3axgGLSntjjnznJr5vsvXSYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZM qa20JLAF1YagutDiMRURU23iWS7bA9tMcXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5 CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1l y+5ZOZbxBAZZMod4y4b4FiRUhRI97r9lCxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY 2BlA7ExM8XShMd9bRPZrNTokPQPUCWCgCdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEE MDAuMCwGCCsGAQUFBzABhiBodHRwOi8vb2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNV HRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYI KwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCGSAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBD bGllbnQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNV HSMEgcIwgb+AFF3AXsKnjdPND5+bxVECGKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQ MA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5 c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lz dGVtcyBMTEMgMjAxNyBDQYITAORIioIQzl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJs QGRlbm5pbmdlci5uZXQwDQYJKoZIhvcNAQELBQADggIBAKquc7cu0xc8FNtAQauZvocDzWQj 7HG9YvMbWnMi+ckhiA3rdW5NwWg0HBhBho1YlnqV+ntCVE2L8ezohHWm+KAdfXgpraL86Vsn 3ywNlZu/3COMpo2ALuHln8YQtH3Y8ebvzKMdlf2b5WB+7mOFIxXIr4AnNOLKCkq5ZhzC6JW6 Jvw3P0csiGa3UrfatYID5NvPgkaQvEgimEjG3psZqwQTL2Wxohvw783PrDt3wS0XeNhvQ61g 3QJFZKuv+bmGH3YBSPo1t6NUGAr+JozX5lDihB8JGkBt/NwdYec49a08uL0BbPaAJ7NjuIPG 7Y0Ak7PXZT37yx/Zla9PzLMJFgbelOkaatdzbblMZPDEVZ27l4lGMmV83Lm3YP17sdAyS/Wp mav7WmJUkQ9iuIKzSpdc82i9Mfujl1vbBtwtkHNPPtKuulIFM4ZwrPKjlVdLqTSqD8m9yHEi Y0PuAooq63OpJWF6hvMaiIPBWEAVIaDW9uG0MshLl9DnHnMyrJTfuC33Z9mOGMz7dRBjJd5Y W02xAzYnUuEBOpj+LQv5R8XIFMHFXktqEKvQrXeM2RU+PcZqKOBkTktxBLn3NI5VfA15Jk0c 5V5XcOqo3p2hvrwvXrinrb2pEREnoqmfrkXT3zOq5Y6ryRH8u734lGEF0dILXzoV4PM7XFit oTePoEjmMYIFBDCCBQACAQEwgZEwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGEx GTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTEl MCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQQISAsbzIfg9AV1t33FSCanO XWNfMA0GCWCGSAFlAwQCAwUAoIICQzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0yMzAxMjQxNjU4MzNaME8GCSqGSIb3DQEJBDFCBEDCW8zrMNptfmNx+TY5 2YOwkPRygEE7sWYaYjCe/tyrW7ECxW35hpFz+xtcVWTC0WrbKxHEZja9lHy1+oKWfK/3MGwG CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw gaIGCSsGAQQBgjcQBDGBlDCBkTB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTEZ MBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENBMSUw IwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBAhICxvMh+D0BXW3fcVIJqc5d Y18wgaQGCyqGSIb3DQEJEAILMYGUoIGRMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9y aWRhMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMg Q0ExJTAjBgNVBAMMHEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0ECEgLG8yH4PQFdbd9x Ugmpzl1jXzANBgkqhkiG9w0BAQEFAASCAgAjxkh7mSiyPjJyfW/saNk6ckgdR+jIxDlqfzbe pjTZtz9XurdKD1xxYddfs4NDxwF1nhAACqU374tboikocd8eD2WI8pPDOsSM1/qXUyG6hvN1 u7kl3kwbh1o/eY8tJzUSmgPLPLjJJTCGfwxPV24cWyrfnroJDuxdhQMpOKl02HZR/KwOYoJq 6c18shYKbi8SZKmpgAlwTf83mGL22iy81mRnedsaWzbUx1UVCbBv9dwDMONRft6JEpqOoHqo Qat1ZPQb+5JesWuM1eYmM2Ic6L5Hrt7J284sd4iK1AKdhCfh+GRX3CJKOArNzkzJAvHHQu92 yK+lomHhJtyzq27qmYJ2y04WH0g7LTklaJ0AAENbjBqZ9GdwkCqZNN9TZ2zcqCSrGPK20bDl LGGnTdN+ozfxuPB+CR17QDRtxFh1R8Tp3tIsZpuzijcPV3gUWEb8wlv5miG1Og2uIw72L5LO rblkMtW1tvCIjPmSptwnOeaoq3VD3j9wsrrYYTqjgtioIta4oJ1lVTf9/ow/TxiCpSXOsmeR MEKrWcOsN5HKFP74SOycNwR7zZZQTSpODcn4ZoJMk6Ost8oJm1g2a3sVAUdQf4uz1sy0WPn8 ATmGkv42PBhV5wI8r1hHSWzj+1sOzISMdf8U0HfIJAWy+ZXrfLSr+wfSdF5tWWxZooHGQAAA AAAAAA== --------------ms090701070402000207070901-- From nobody Tue Jan 24 17:11:20 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P1YR95t31z316KL for ; Tue, 24 Jan 2023 17:11:33 +0000 (UTC) (envelope-from jjrushford@gmail.com) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P1YR946llz3Prk for ; Tue, 24 Jan 2023 17:11:33 +0000 (UTC) (envelope-from jjrushford@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-il1-x136.google.com with SMTP id i1so7699929ilu.8 for ; Tue, 24 Jan 2023 09:11:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=k89bQXy6x5hVui7a9UwmTMMbqybWZkgD9FWA69N/GF4=; b=i9gBA0mRSc4s44BNygHyf7DstKiuUNnZodT/WLImlZ+2ciAOVS7dpiFFP5Gp8G4Sj2 P99cnIpifTmDD9XMQBMgi6KXOZAu8ciUZKbBLuSfhAgtzwwxBLXxZ72BYcox9YhqSEjB 8rOIpk1IqNvObs+NqW3cp4f14Wu6pfLgwd9apYb8sgDSry4/2P/3DeR53fd2xXz/KSm2 Biu1dW6HCMWL7GQuqQ7Aczje98Degyv2eah6vcvPVNvvBeqxIsI+Nk5vlc3a3yVr2cqi uU+gDRVFZuedlr+lJSt61cQXUPyrbYfi8tSZsyAb8zcH0vvxCOv01YT9/C6BA4c7gXWg cxeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=k89bQXy6x5hVui7a9UwmTMMbqybWZkgD9FWA69N/GF4=; b=xqkjS62IEV15qn+a3KNk/llu2EQ1WUJiNsbOyEmmU2dlqtnZp0IN5WQbxUxLohDuXT oMJcYciGgImxDA7/EP/vQMvAL/qfmldsYaSFlCCqqkMZBVTil5tcf9wZKF+f8HF9kcNq FUTGcWC7g18wQPKik4yrNbwI5GwDcxxPYgAt1qhRqxa9aZd8yg4/7DrseK0beIx2HcoR k4ZAcnyi9X8hK+MS+19eV0FC3zpGKnvr+OU0F97jqTJJGzDByu16fOzUWuwvotMp1Vxe tSFH+DNQAQZtk1kyFlWACMGDp8PbL+zhB3PsLIi4p4DureRdPQY7yHEpY0spaXrdJ//d 9qCA== X-Gm-Message-State: AFqh2koOWEE53UXtpPr4/WTln7NsItZhVsv0Ye4nd9bsnpAZ72qX3hAp 4cyymknE4p/+3OuuU566OQXorXV1x/a3Sg== X-Google-Smtp-Source: AMrXdXsrCyDIvNGQ1BhkJZq0z30ZkKrltsVHudQXJNVYKYepfjbgZ9tV3SJKfoW6jSqucMxQOVz03A== X-Received: by 2002:a05:6e02:1a6c:b0:30f:40fc:7a2b with SMTP id w12-20020a056e021a6c00b0030f40fc7a2bmr19755848ilv.32.1674580292493; Tue, 24 Jan 2023 09:11:32 -0800 (PST) Received: from smtpclient.apple ([2601:280:587f:1450:84e6:9743:8888:b2e8]) by smtp.gmail.com with ESMTPSA id g8-20020a0566380bc800b003a60e059970sm856590jad.84.2023.01.24.09.11.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Jan 2023 09:11:31 -0800 (PST) Content-Type: text/plain; charset=utf-8 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: Enabling Raspberry Pi 4B Uarts, specifically uart3 From: John Rushford In-Reply-To: <2bd8e680-df6a-cfe1-fbd2-ade1ac2d0497@thegalacticzoo.com> Date: Tue, 24 Jan 2023 10:11:20 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <2bd8e680-df6a-cfe1-fbd2-ade1ac2d0497@thegalacticzoo.com> To: Fred Finster X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Rspamd-Queue-Id: 4P1YR946llz3Prk X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Fred, This is my /boot/loader.conf. After rebooting, no change and no data on = uart3. BTW, FreeBSD does=20 not create a /dev/ttyU1. =46rom the config.txt with dtoverlay=3Duart3, = FreeBSD creates a /dev/ttyu1 ucom_load=3D"YES" umodem_load=3D"YES" usb_template_load=3D"YES" hw.usb.template=3D3 umodem_load=3D"YES" umodem_load=3D"YES" # Multiple console (serial+efi gop) enabled. boot_multicons=3D"YES" boot_serial=3D"YES" # Disable the beastie menu and color beastie_disable=3D"YES" loader_color=3D"NO" kern.vty=3Dvt gpiopps_load=3D"YES"This is my /boot/loader.conf: /boot/msdos/config.txt: cat msdos/config.txt: [all] arm_64bit=3D1 dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don dtoverlay=3Dmmc dtoverlay=3Ddisable-bt device_tree_address=3D0x4000 kernel=3Du-boot.bin dtoverlay=3Dpps-gpio,gpiopin=3D18 dtoverlay=3Duart3 enable_uart=3D1 [pi4] # hdmi_safe=3D1 armstub=3Darmstub8-gic.bin # dmesg|grep uart uart0: mem 0x7e201000-0x7e2011ff irq 16 on = simplebus0 uart0: console (115200,n,8,1) uart1: mem 0x7e201600-0x7e2017ff irq 43 on = simplebus0 The memory address 0x7e201600 corresponds to that assigned to uart3 in: = src/freebsd-src/sys/contrib/device-tree/src/arm/bcm2711.dtsi=20 Still no data seen thanks John Rushford > On Jan 24, 2023, at 6:09 AM, Fred Finster = wrote: >=20 > */ > /* >=20 > */From:/* > */Date:/*Sun, 22 Jan 2023 21:36:36 UTC >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D269104 >=20 > Bug ID: 269104 > Summary: The uarts2 - uarts5 do not function on raspberry pi = 4B > Product: Base System > Version: 13.1-RELEASE > Hardware: arm64 > OS: Any > Status: New > Severity: Affects Only Me > Priority: --- > Component: arm > Assignee: freebsd-arm@FreeBSD.org > Reporter: jjrushford@gmail.com >=20 > I=E2=80=99ve tried using the additional serial ports that are = available with a > raspberry pi 4B by enabling them in config.txt and when I try to read = data on > them, I see nothing. >=20 > Specifically, I=E2=80=99ve wired an Adafruit ultimate GPS to uart3, = gpio pins 4 and 5. > I=E2=80=99ve built the RPI-firmware port and copied the uart0-5 = dtb=E2=80=99s to > /boot/msdos/overlays. I then enable uart3 in /boot/msdos/config.txt = with > dtoverlay=3Duart3 and reboot. After boot, I see that FreeBSD has = created > /dev/ttyu1 and /dev/cuau1 in the dev tree for uart3. When I try = reading from > ttyu1 or cuau1, I do not see any data whatsoever. I=E2=80=99ve set = the baud rate to > 9600 and disabled flow control but still no data is seen. If I change = the > wiring to use ttyu0, gpio pins 14 and 15, I do see data there. >=20 > Just to verify the hardware, I installed a different SD card with = raspberry pi > OS, Debian, and enabled uart3 in config.txt. When I read the = /dev/ttyAMA1 I do > see the NMEA time stamps coming in uart3 at 9600 baud with no issue. = Next I > reboot back to FreeBSD 13.1, I cannot see any data from The GPS card = on ttyu1 > or cuau1. >=20 > --=20 > You are receiving this mail because: > You are the assignee for the bug. >=20 > In the aarch64 arm64 Raspberry Pi FreeBSD, maybe you need to enable = some kernel modules > kldstat > kldload ucom umodem usb_template > sysctl hw.usb.template=3D3 >=20 > add in file /boot/loader.conf >=20 > ucom_load=3D"YES" > umodem_load=3D"YES" > usb_template_load=3D"YES" > hw.usb.template=3D3 >=20 >=20 > *cu -s 9600 -l /dev/ttyU1 What do you see? or rather cu? :>) Do = report back success or failure or changes necessary to make work, = please. = *https://forums.raspberrypi.com/viewtopic.php?t=3D244827&sid=3Df4a784a3c40= ed0940e6fbb9f81af5015&start=3D25#p1590882 = >=20 >=20 > Re: Pi-4 Activating additional UART ports > = >=20 > Mon Jan 06, 2020 10:36 am = >=20 > On all Pis, UART0 is a PL011 that appear to Linux as ttyAMA, and = UART1 is an 8250 clone that appears as ttyS0. On a Pi4, UART2-5 are = additional PL011s that also appear as ttyAMA. The number starts at 0 = for the first enabled PL011 and counts up through all the enabled = interfaces. The numbering is stable for any given combination of UARTs, = but enabling or disabling one can change the number assignments of = others. >=20 > /PL011 appear to FreeBSD/*as /dev/ttyUx So I wonder if one has to = enable ucom and umodem and usb_template to view serial data comming back = over what looks like a USB to serial interface? Your thoughts? = https://ghostbsd-arm64.blogspot.com/2023/01/hookup-gdb-to-black-magic-prob= e-v23.html * >=20 > My setup trying to connect to USB serial port under X86_64 FreeBSD 13 = to a Black Magic Probe >=20 >=20 > --=20 > Fred Finster > fred@thegalacticzoo.com > +1 971-718-9144 > https://GhostBSD-ARM64.blogspot.com > https://ghostbsd.org >=20 From nobody Tue Jan 24 18:43:56 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P1bV21XrKz3bCpQ for ; Tue, 24 Jan 2023 18:44:10 +0000 (UTC) (envelope-from jjrushford@gmail.com) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P1bV119G5z3lvQ for ; Tue, 24 Jan 2023 18:44:09 +0000 (UTC) (envelope-from jjrushford@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=bbPo4EF+; spf=pass (mx1.freebsd.org: domain of jjrushford@gmail.com designates 2607:f8b0:4864:20::134 as permitted sender) smtp.mailfrom=jjrushford@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-il1-x134.google.com with SMTP id m15so7832787ilq.2 for ; Tue, 24 Jan 2023 10:44:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=/QN3dr+i3CXrqh6mBnmFj8MC+szoTR1cDa8HQb+J4OE=; b=bbPo4EF+ohyR+fKhf261/DCmBEHV18iCQWOTmpMvzGPVA5D4MQ6o7YkzUhzt0GYIpj L+W4CDc1SDoxzwB/EPyyep2HiIDRY48XDMO3KE9tFYQ7w2K9Z11HbznbFMAYDKerNBqM bCdcxEX13DLO5fYOpWb+GDblKkKLRaG57XVf7QDflmFN4sAU6mrZaFZfYN06KG4yDPnk nw/WqkdXiXLgT4MchwvsFtPSYITfjL3mg7tIkOgmdk+n4oLNN+6QSjtmQs79MFFkqBbP l0CkINOgpJROn/4Y0tXR6+Ign0osd8DP53vFltLzYiG3X33eVlcEjFEIiR1mObHfCIjh 0smQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/QN3dr+i3CXrqh6mBnmFj8MC+szoTR1cDa8HQb+J4OE=; b=5hrY4Gjuqbo4jNzsoQjJmpQM7L/zTg0rRFzA4NDMlEMsFcAr+rsIuuT9yuD2+lcHg9 Neb91jEkvX5A8k3xOYG1cx/c3MEHojOf5HI44hRdCmRC7neMhpqCQpCo6qGuIiIgeWJ1 KH4N62px7iQ94N3GAYEzW+HmSBH4cvo2Z/MUmO/+HgDvfxCBNM+KXI1QJID25jVeBc6C AX95sHOpVsF6FOuCJ7+LA+XC8AfKquKCEuR9QEgTH0skHPAwDGOSWNbmRJgrAnPorsbS hpS3p1WOUWaoTNHJmFTxdtuL/qYGwQrCtzYPvl+RxlO3LLDa+VsfYXaV+4c2hqA5TT0c s3Rg== X-Gm-Message-State: AO0yUKU5L18Y+319FLuGyk2CxemzFyH79B9esJkRbQE5rDLugPlwyWmw NQGrrkT0Bew52CwKzDN+2Rs= X-Google-Smtp-Source: AK7set+ggp168OHFbhNDFMOa8BDgFW2UdSQcSyRIlUGYGMzmLq+ECFgeoQZP+5Bgc1Tk8GIRU/VrnQ== X-Received: by 2002:a92:cda3:0:b0:310:8c3e:e512 with SMTP id g3-20020a92cda3000000b003108c3ee512mr3412123ild.24.1674585847293; Tue, 24 Jan 2023 10:44:07 -0800 (PST) Received: from smtpclient.apple ([2601:280:587f:1450:84e6:9743:8888:b2e8]) by smtp.gmail.com with ESMTPSA id k10-20020a056638370a00b0039df8e7af39sm934009jav.41.2023.01.24.10.44.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Jan 2023 10:44:06 -0800 (PST) Content-Type: text/plain; charset=utf-8 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: Enabling Raspberry Pi 4B Uarts, specifically uart3 From: John Rushford In-Reply-To: Date: Tue, 24 Jan 2023 11:43:56 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <2bd8e680-df6a-cfe1-fbd2-ade1ac2d0497@thegalacticzoo.com> To: Fred Finster X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Spamd-Result: default: False [-3.48 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.984]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::134:from]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-Rspamd-Queue-Id: 4P1bV119G5z3lvQ X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Fred, Looking at the pstat -t output, I see no data available on ttyu1. I = know that there is data coming from the GPS card as I can see it when I switch OS to Debian. This confirms the problem = though with the additional uarts. pstat -t LINE INQ CAN LIN LOW OUTQ USE LOW COL SESS PGID STATE ttyu0 23040 0 0 2304 23064 0 2307 7 1167 1167 ICOil ttyu1 0 0 0 0 0 0 0 4 0 0 IC ttyv0 1920 0 0 192 1984 0 199 7 1159 1159 Oil ttyv1 1920 0 0 192 1984 0 199 7 1160 1160 Oil ttyv2 1920 0 0 192 1984 0 199 7 1161 1161 Oil ttyv3 1920 0 0 192 1984 0 199 7 1162 1162 Oil ttyv4 1920 0 0 192 1984 0 199 7 1163 1163 Oil ttyv5 1920 0 0 192 1984 0 199 7 1164 1164 Oil ttyv6 1920 0 0 192 1984 0 199 7 1165 1165 Oil ttyv7 1920 0 0 192 1984 0 199 7 1166 1166 Oil ttyv8 0 0 0 0 0 0 0 0 0 0 - ttyv9 0 0 0 0 0 0 0 0 0 0 - ttyva 0 0 0 0 0 0 0 0 0 0 - ttyvb 0 0 0 0 0 0 0 0 0 0 - pts/0 7680 0 0 768 7688 0 769 0 1336 1420 Oi pts/1 7680 0 0 768 7688 0 769 36 1380 1380 Oi On Jan 24, 2023, at 10:11 AM, John Rushford = wrote: >=20 > Fred, >=20 > This is my /boot/loader.conf. After rebooting, no change and no data = on uart3. BTW, FreeBSD does=20 > not create a /dev/ttyU1. =46rom the config.txt with dtoverlay=3Duart3, = FreeBSD creates a /dev/ttyu1 >=20 > ucom_load=3D"YES" > umodem_load=3D"YES" > usb_template_load=3D"YES" > hw.usb.template=3D3 > umodem_load=3D"YES" > umodem_load=3D"YES" > # Multiple console (serial+efi gop) enabled. > boot_multicons=3D"YES" > boot_serial=3D"YES" > # Disable the beastie menu and color > beastie_disable=3D"YES" > loader_color=3D"NO" > kern.vty=3Dvt > gpiopps_load=3D"YES"This is my /boot/loader.conf: >=20 > /boot/msdos/config.txt: >=20 > cat msdos/config.txt: >=20 > [all] > arm_64bit=3D1 > dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don > dtoverlay=3Dmmc > dtoverlay=3Ddisable-bt > device_tree_address=3D0x4000 > kernel=3Du-boot.bin > dtoverlay=3Dpps-gpio,gpiopin=3D18 > dtoverlay=3Duart3 > enable_uart=3D1 >=20 > [pi4] > # hdmi_safe=3D1 > armstub=3Darmstub8-gic.bin >=20 > # dmesg|grep uart > uart0: mem 0x7e201000-0x7e2011ff irq 16 on = simplebus0 > uart0: console (115200,n,8,1) > uart1: mem 0x7e201600-0x7e2017ff irq 43 on = simplebus0 >=20 > The memory address 0x7e201600 corresponds to that assigned to uart3 = in: src/freebsd-src/sys/contrib/device-tree/src/arm/bcm2711.dtsi=20 >=20 > Still no data seen >=20 > thanks > John Rushford >=20 >=20 >> On Jan 24, 2023, at 6:09 AM, Fred Finster = wrote: >>=20 >> */ >> /* >>=20 >> */From:/* >> */Date:/*Sun, 22 Jan 2023 21:36:36 UTC >>=20 >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D269104 >>=20 >> Bug ID: 269104 >> Summary: The uarts2 - uarts5 do not function on raspberry pi = 4B >> Product: Base System >> Version: 13.1-RELEASE >> Hardware: arm64 >> OS: Any >> Status: New >> Severity: Affects Only Me >> Priority: --- >> Component: arm >> Assignee: freebsd-arm@FreeBSD.org >> Reporter: jjrushford@gmail.com >>=20 >> I=E2=80=99ve tried using the additional serial ports that are = available with a >> raspberry pi 4B by enabling them in config.txt and when I try to read = data on >> them, I see nothing. >>=20 >> Specifically, I=E2=80=99ve wired an Adafruit ultimate GPS to uart3, = gpio pins 4 and 5. >> I=E2=80=99ve built the RPI-firmware port and copied the uart0-5 = dtb=E2=80=99s to >> /boot/msdos/overlays. I then enable uart3 in /boot/msdos/config.txt = with >> dtoverlay=3Duart3 and reboot. After boot, I see that FreeBSD has = created >> /dev/ttyu1 and /dev/cuau1 in the dev tree for uart3. When I try = reading from >> ttyu1 or cuau1, I do not see any data whatsoever. I=E2=80=99ve set = the baud rate to >> 9600 and disabled flow control but still no data is seen. If I = change the >> wiring to use ttyu0, gpio pins 14 and 15, I do see data there. >>=20 >> Just to verify the hardware, I installed a different SD card with = raspberry pi >> OS, Debian, and enabled uart3 in config.txt. When I read the = /dev/ttyAMA1 I do >> see the NMEA time stamps coming in uart3 at 9600 baud with no issue. = Next I >> reboot back to FreeBSD 13.1, I cannot see any data from The GPS card = on ttyu1 >> or cuau1. >>=20 >> --=20 >> You are receiving this mail because: >> You are the assignee for the bug. >>=20 >> In the aarch64 arm64 Raspberry Pi FreeBSD, maybe you need to enable = some kernel modules >> kldstat >> kldload ucom umodem usb_template >> sysctl hw.usb.template=3D3 >>=20 >> add in file /boot/loader.conf >>=20 >> ucom_load=3D"YES" >> umodem_load=3D"YES" >> usb_template_load=3D"YES" >> hw.usb.template=3D3 >>=20 >>=20 >> *cu -s 9600 -l /dev/ttyU1 What do you see? or rather cu? :>) Do = report back success or failure or changes necessary to make work, = please. = *https://forums.raspberrypi.com/viewtopic.php?t=3D244827&sid=3Df4a784a3c40= ed0940e6fbb9f81af5015&start=3D25#p1590882 = >>=20 >>=20 >> Re: Pi-4 Activating additional UART ports >> = >>=20 >> Mon Jan 06, 2020 10:36 am = >>=20 >> On all Pis, UART0 is a PL011 that appear to Linux as ttyAMA, and = UART1 is an 8250 clone that appears as ttyS0. On a Pi4, UART2-5 are = additional PL011s that also appear as ttyAMA. The number starts at 0 = for the first enabled PL011 and counts up through all the enabled = interfaces. The numbering is stable for any given combination of UARTs, = but enabling or disabling one can change the number assignments of = others. >>=20 >> /PL011 appear to FreeBSD/*as /dev/ttyUx So I wonder if one has to = enable ucom and umodem and usb_template to view serial data comming back = over what looks like a USB to serial interface? Your thoughts? = https://ghostbsd-arm64.blogspot.com/2023/01/hookup-gdb-to-black-magic-prob= e-v23.html * >>=20 >> My setup trying to connect to USB serial port under X86_64 FreeBSD 13 = to a Black Magic Probe >>=20 >>=20 >> --=20 >> Fred Finster >> fred@thegalacticzoo.com >> +1 971-718-9144 >> https://GhostBSD-ARM64.blogspot.com >> https://ghostbsd.org >>=20 >=20 From nobody Tue Jan 24 19:15:30 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P1cBF72KQz3bGxp for ; Tue, 24 Jan 2023 19:15:33 +0000 (UTC) (envelope-from 01070185e534f221-14f362b5-2b96-43f0-b0b0-f496ad9994fe-000000@eu-central-1.amazonses.com) Received: from b224-10.smtp-out.eu-central-1.amazonses.com (b224-10.smtp-out.eu-central-1.amazonses.com [69.169.224.10]) (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 4P1cBD01SHz3ps2 for ; Tue, 24 Jan 2023 19:15:31 +0000 (UTC) (envelope-from 01070185e534f221-14f362b5-2b96-43f0-b0b0-f496ad9994fe-000000@eu-central-1.amazonses.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cyclaero.com header.s=ez3m2wtglgbm5wj4q3hdyvc7qtjtqmlb header.b=kOVw2Qan; dkim=pass header.d=amazonses.com header.s=sokbgaaqhfgd6qjht2wmdajpuuanpimv header.b="eo/MgMk6"; spf=pass (mx1.freebsd.org: domain of 01070185e534f221-14f362b5-2b96-43f0-b0b0-f496ad9994fe-000000@eu-central-1.amazonses.com designates 69.169.224.10 as permitted sender) smtp.mailfrom=01070185e534f221-14f362b5-2b96-43f0-b0b0-f496ad9994fe-000000@eu-central-1.amazonses.com; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ez3m2wtglgbm5wj4q3hdyvc7qtjtqmlb; d=cyclaero.com; t=1674587730; h=From:Content-Type:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id; bh=7Z7uc+qKlUNYqVFe02eqy/tMXSCC5S3XEJqn5jBp/4c=; b=kOVw2QanshBWntBRkaBYUTe2IzIDZaYSWPIIhC5Hmd3kmKQXcv5x+pYlOQxCelE+ ECfYLhe23S45UEB/2a7X2ZNI20yGLl+rJ2QI5+jDIEvLUdhifQwzF/Z55NyB1aI+g/p 4+BVzMgO+8EHMK7jQhs7/fvBnkWEHPRwVPFvIsN9EjFOoDbDXgWxE31OGuw6mimNGXy PdW2vJKCP6h3AD4wBmqD0JDcWenGTScTiTCE8sAAMtGOauwkLv1tnglbnd04Y3A0tcq tQvHobmPywMdQtPpuGfx5N34UfVMBdEFKyNYd+byECqGve5ZGRpzFSlnQi7Cyjy2oFz FFwHa//kdw== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=sokbgaaqhfgd6qjht2wmdajpuuanpimv; d=amazonses.com; t=1674587730; h=From:Content-Type:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id:Feedback-ID; bh=7Z7uc+qKlUNYqVFe02eqy/tMXSCC5S3XEJqn5jBp/4c=; b=eo/MgMk6rmvj1bxu4C4hepMSx4d2bHKKzzjlgnYQuJuZOnm8a6PUJmi8GjMbHDnX oQWM8EdW8rRUSLKr7im+EZaRYzNE0bNLAzWclKqv45XWBPy9r7IO4pAV26Ra87idV4/ VPYJWzYG+fGiVddD3RNSOV4mTjN5AE/15crmD2C4= From: "Dr. Rolf Jansen" Content-Type: multipart/alternative; boundary="Apple-Mail=_A11E81C7-9742-46CA-9F56-79152AC5767A" List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Subject: Re: GPIO inputs on Pis? Date: Tue, 24 Jan 2023 19:15:30 +0000 References: <0b235f83-7cb3-1d14-7c64-aee7c1c0c23d@denninger.net> <01070185e46b1a6e-ee34b885-1215-45c7-ac18-83320c02cac2-000000@eu-central-1.amazonses.com> <01070185e4732fd8-c0bede0b-d9df-4557-a174-cb237fa4bfaf-000000@eu-central-1.amazonses.com> To: freebsd-arm In-Reply-To: Message-ID: <01070185e534f221-14f362b5-2b96-43f0-b0b0-f496ad9994fe-000000@eu-central-1.amazonses.com> X-Mailer: Apple Mail (2.3445.104.15) Feedback-ID: 1.eu-central-1.i3TZMOZE/rJo3HQG0qvfyolMxXljeCj2Qj8Jp3rxK3c=:AmazonSES X-SES-Outgoing: 2023.01.24-69.169.224.10 X-Spamd-Result: default: False [1.91 / 15.00]; URI_COUNT_ODD(1.00)[27]; FROM_NAME_HAS_TITLE(1.00)[dr]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_LONG(-0.97)[-0.974]; NEURAL_SPAM_MEDIUM(0.58)[0.583]; MV_CASE(0.50)[]; FORGED_SENDER(0.30)[freebsd-rj@cyclaero.com,01070185e534f221-14f362b5-2b96-43f0-b0b0-f496ad9994fe-000000@eu-central-1.amazonses.com]; R_DKIM_ALLOW(-0.20)[cyclaero.com:s=ez3m2wtglgbm5wj4q3hdyvc7qtjtqmlb,amazonses.com:s=sokbgaaqhfgd6qjht2wmdajpuuanpimv]; R_SPF_ALLOW(-0.20)[+ip4:69.169.224.0/20]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[69.169.224.10:from]; DMARC_NA(0.00)[cyclaero.com]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[amazonses.com:dkim]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; DKIM_TRACE(0.00)[cyclaero.com:+,amazonses.com:+]; TO_DN_ALL(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; ASN(0.00)[asn:16509, ipnet:69.169.224.0/23, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_NEQ_ENVFROM(0.00)[freebsd-rj@cyclaero.com,01070185e534f221-14f362b5-2b96-43f0-b0b0-f496ad9994fe-000000@eu-central-1.amazonses.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[69.169.224.10:from] X-Rspamd-Queue-Id: 4P1cBD01SHz3ps2 X-Spamd-Bar: + X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_A11E81C7-9742-46CA-9F56-79152AC5767A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Am 24.01.2023 um 13:58 schrieb Karl Denninger >: >=20 > On 1/24/2023 10:43, Dr. Rolf Jansen wrote: >> I sent an old ink to the thread on the mailing list, which does not = work anymore. Here ist the new link: >>=20 >> = https://lists.freebsd.org/pipermail/freebsd-arm/2020-November/022738.html = >>=20 >>> Am 24.01.2023 um 12:35 schrieb Karl Denninger >: >>>=20 >>> Thank you -- will check it out. >>>=20 >>> On 1/24/2023 10:35, Dr. Rolf Jansen wrote: >>>>> Am 23.01.2023 um 11:41 schrieb Karl Denninger >: >>>>>=20 >>>>> Is there support somewhere in the 13.x for other than "read = current state" / "set current state"? >>>>>=20 >>>>> Specifically, there is evidence in the sys/gpio.h header file that = I can open up a file descriptor and then use select()/read() to grab the = contents of a ring buffer of some size (presumably interrupt-posted) of = events since last look, and determine if there's anything in there. = Provided you're reasonably fast this might be enough to, for example, = read an optical encoder that has a modest pulse rate. >>>>>=20 >>>>> I see apparent review code at https://reviews.freebsd.org/D27398 = from late 2020, but nothing else I = can find digging around; an example (assuming it is actually implemented = and works) would be helpful >>>>>=20 >>>> See >>>>=20 >>>> = https://forums.freebsd.org/threads/gpio-api-general-orange-pi-h3.83950/pos= t-556728 = >>>>=20 >>>> And the messages in that thread that follow the one linked above. >>>>=20 >>>> There is a respective thread on this mailing list as well: >>>>=20 >>>> Porting FreeBSD to ARM processors: User Space GPIO Interrupt = programming - GSoC-2018 = = --=20 >>> Karl Denninger >>> karl@denninger.net >>> The Market Ticker >>> [S/MIME encrypted email preferred] >>=20 > So the answer at this point appears to be "not in the codebase and no = indication on when/if it might be, but there are patches that are in = some state of development.=E2=80=9C >=20 No, at this point (13.1-RELEASE) everything is in the kernel, no patches = needed. Even the test tool made it into the source tree. It has only be = renamed from gpioc_intr_test.c to gpioevents.c. /usr/src/tools/test/gpioevents/gpioevents.c The documentation is missing. It is however easy to learn how things = work by examining the code of gpioevents.c. > Being able to read an encoder of some sort basically means being able = to know how many events occurred between "looks"; for most purposes you = don't need each event delivered exactly when it occurs, but missing some = of the counts entirely is not acceptable. Yes, and for this reason, this GPIO event code which was developed by = Christian Kr=C3=A4mer in the course of the GSoC-2018 and has been = submitted in 2020 by Ian Lepore to the freebsd tree is perfect. Ian tested it with a 10 MHz sqaure wave on an imx6 (ARMv7, 1GHz) and got = an event every 10 =C2=B5s. That means the max. speed without event = losses would be 100 kHz. I did not do exact measurements, however, my = impression is that my RPi4B can do it a tad faster than my BeagleBone = Black. With the RPi4, I needed to improve the debouncing of the encoder = and the buttons, because it saw hundreds of bounces which the BBB = didn=E2=80=99t. However, it may also be, that the internal GPIO circuits = of the BBB have a different damping characteristic. Anyway for my applications, 100 kHz way faster than what I need. On my GitHub repository I placed another example on using the GPIO = events for the RPi: https://github.com/cyclaero/shutdd See also the respective thread on this mailing list: https://lists.freebsd.org/archives/freebsd-arm/2022-July/001576.html = = --Apple-Mail=_A11E81C7-9742-46CA-9F56-79152AC5767A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Am = 24.01.2023 um 13:58 schrieb Karl Denninger <karl@denninger.net>:

On 1/24/2023 10:43, Dr. Rolf Jansen wrote:
I = sent an old ink to the thread on the mailing list, which does not work = anymore. Here ist the new link:

https://lists.freebsd.org/pipermail/freebsd-arm/2= 020-November/022738.html

Am 24.01.2023 um 12:35 schrieb Karl = Denninger <karl@denninger.net>:

Thank you -- will check it out.

On 1/24/2023 10:35, Dr. Rolf Jansen wrote:
Am 23.01.2023 um 11:41 schrieb = Karl Denninger <karl@denninger.net>:

Is there support somewhere in the 13.x for other than "read = current state" / "set current state"?

Specifically, = there is evidence in the sys/gpio.h header file that I can open up a = file descriptor and then use select()/read() to grab the contents of a = ring buffer of some size (presumably interrupt-posted) of events since = last look, and determine if there's anything in there.  Provided = you're reasonably fast this might be enough to, for example, read an = optical encoder that has a modest pulse rate.

I see = apparent review code at https://reviews.freebsd.org/D27398 from late 2020, but nothing = else I can find digging around; an example (assuming it is actually = implemented and works) would be = helpful

See

https://forums.freebsd.org/threads/gpio-api-gener= al-orange-pi-h3.83950/post-556728

And the messages in that thread that = follow the one linked above.

There is a respective thread on this = mailing list as well:

Porting FreeBSD to ARM = processors: User Space GPIO Interrupt programming - = GSoC-2018
-- 
Karl = Denninger
karl@denninger.net
The Market Ticker
[S/MIME encrypted email = preferred]

So the answer at this = point appears to be "not in the codebase and no indication on when/if it = might be, but there are patches that are in some state of = development.=E2=80=9C

No, at this point = (13.1-RELEASE) everything is in the kernel, no patches needed. Even the = test tool made it into the source tree. It has only be renamed = from gpioc_intr_test.c to gpioevents.c.

/usr/src/tools/test/gpioevents/gpioevents.c

The documentation is missing. It is = however easy to learn how things work by examining the code of = gpioevents.c.

Being able to read an encoder of some sort basically means = being able to know how many events occurred between "looks"; for most = purposes you don't need each event delivered exactly when it occurs, but = missing some of the counts entirely is not = acceptable.

Yes, and for this reason, this GPIO = event code which was developed by Christian Kr=C3=A4mer in the = course of the GSoC-2018 and has been submitted in 2020 by Ian Lepore to = the freebsd tree is perfect.

Ian tested it with a 10 MHz sqaure = wave on an imx6 (ARMv7, 1GHz) and got an event every 10 =C2=B5s. = That means the max. speed without event losses would be 100 kHz. I did = not do exact measurements, however, my impression is that my RPi4B can = do it a tad faster than my BeagleBone Black. With the RPi4, I needed to = improve the debouncing of the encoder and the buttons, because it saw = hundreds of bounces which the BBB didn=E2=80=99t. However, it may also = be, that the internal GPIO circuits of the BBB have a different damping = characteristic.

Anyway for my applications, 100 kHz way faster than what I = need.

On my = GitHub repository I placed another example on using the GPIO events for = the RPi:

https://github.com/cyclaero/shutdd
See also the respective thread on this = mailing list:

https://lists.freebsd.org/archives/freebsd-arm/2022-July/001576= .html
= --Apple-Mail=_A11E81C7-9742-46CA-9F56-79152AC5767A-- From nobody Tue Jan 24 19:17:58 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P1cFj3NkVz3bH95 for ; Tue, 24 Jan 2023 19:18:33 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P1cFh2byLz3qTf for ; Tue, 24 Jan 2023 19:18:32 +0000 (UTC) (envelope-from karl@denninger.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net; dmarc=pass (policy=none) header.from=denninger.net Received: from denninger.net (097-081-026-048.res.spectrum.com [97.81.26.48]) by colo1.denninger.net (Postfix) with ESMTP id 6FF3A2110A8 for ; Tue, 24 Jan 2023 14:18:01 -0500 (EST) Received: from [192.168.10.12] (D2.Denninger.Net [192.168.10.12]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id EB6CB28098E for ; Tue, 24 Jan 2023 14:18:00 -0500 (EST) Message-ID: <568943a8-c919-a72d-f3c1-f5dc05c77305@denninger.net> Date: Tue, 24 Jan 2023 14:17:58 -0500 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: GPIO inputs on Pis? Content-Language: en-US To: freebsd-arm@freebsd.org References: <0b235f83-7cb3-1d14-7c64-aee7c1c0c23d@denninger.net> <01070185e46b1a6e-ee34b885-1215-45c7-ac18-83320c02cac2-000000@eu-central-1.amazonses.com> <01070185e4732fd8-c0bede0b-d9df-4557-a174-cb237fa4bfaf-000000@eu-central-1.amazonses.com> <01070185e534f221-14f362b5-2b96-43f0-b0b0-f496ad9994fe-000000@eu-central-1.amazonses.com> From: Karl Denninger In-Reply-To: <01070185e534f221-14f362b5-2b96-43f0-b0b0-f496ad9994fe-000000@eu-central-1.amazonses.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms040303040201060107080104" X-Spamd-Result: default: False [-4.89 / 15.00]; SIGNED_SMIME(-2.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.994]; NEURAL_HAM_MEDIUM(-0.99)[-0.992]; DMARC_POLICY_ALLOW(-0.50)[denninger.net,none]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+mx:c]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[karl]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; HAS_ATTACHMENT(0.00)[]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-Rspamd-Queue-Id: 4P1cFh2byLz3qTf X-Spamd-Bar: ---- X-ThisMailContainsUnwantedMimeParts: N This is a cryptographically signed message in MIME format. --------------ms040303040201060107080104 Content-Type: multipart/alternative; boundary="------------xufv58awLsQCflyz0sXPDgOc" --------------xufv58awLsQCflyz0sXPDgOc Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/24/2023 2:15 PM, Dr. Rolf Jansen wrote: >> Am 24.01.2023 um 13:58 schrieb Karl Denninger : >> >> On 1/24/2023 10:43, Dr. Rolf Jansen wrote: >>> I sent an old ink to the thread on the mailing list, which does not >>> work anymore. Here ist the new link: >>> >>> https://lists.freebsd.org/pipermail/freebsd-arm/2020-November/022738.html >>> >>>> Am 24.01.2023 um 12:35 schrieb Karl Denninger : >>>> >>>> Thank you -- will check it out. >>>> >>>> On 1/24/2023 10:35, Dr. Rolf Jansen wrote: >>>>>> Am 23.01.2023 um 11:41 schrieb Karl Denninger : >>>>>> >>>>>> Is there support somewhere in the 13.x for other than "read >>>>>> current state" / "set current state"? >>>>>> >>>>>> Specifically, there is evidence in the sys/gpio.h header file >>>>>> that I can open up a file descriptor and then use select()/read() >>>>>> to grab the contents of a ring buffer of some size (presumably >>>>>> interrupt-posted) of events since last look, and determine if >>>>>> there's anything in there. Provided you're reasonably fast this >>>>>> might be enough to, for example, read an optical encoder that has >>>>>> a modest pulse rate. >>>>>> >>>>>> I see apparent review code >>>>>> athttps://reviews.freebsd.org/D27398from late 2020, but nothing >>>>>> else I can find digging around; an example (assuming it is >>>>>> actually implemented and works) would be helpful >>>>>> >>>>> See >>>>> >>>>> https://forums.freebsd.org/threads/gpio-api-general-orange-pi-h3.83950/post-556728 >>>>> >>>>> And the messages in that thread that follow the one linked above. >>>>> >>>>> There is a respective thread on this mailing list as well: >>>>> >>>>> Porting FreeBSD to ARM processors: User Space GPIO Interrupt >>>>> programming - GSoC-2018 >>>>> >>>> -- >>>> Karl Denninger >>>> karl@denninger.net >>>> /The Market Ticker/ >>>> /[S/MIME encrypted email preferred]/ >>> >> So the answer at this point appears to be "not in the codebase and no >> indication on when/if it might be, but there are patches that are in >> some state of development.“ >> > No, at this point (13.1-RELEASE) everything is in the kernel, no > patches needed. Even the test tool made it into the source tree. It > has only be renamed from gpioc_intr_test.c to gpioevents.c. > > /usr/src/tools/test/gpioevents/gpioevents.c > > The documentation is missing. It is however easy to learn how things > work by examining the code of gpioevents.c. > >> Being able to read an encoder of some sort basically means being able >> to know how many events occurred between "looks"; for most purposes >> you don't need each event delivered exactly when it occurs, but >> missing some of the counts entirely is not acceptable. > > Yes, and for this reason, this GPIO event code which was developed > by Christian Krämer in the course of the GSoC-2018 and has been > submitted in 2020 by Ian Lepore to the freebsd tree is perfect. > > Ian tested it with a 10 MHz sqaure wave on an imx6 (ARMv7, 1GHz) and > got an event every 10 µs. That means the max. speed without event > losses would be 100 kHz. I did not do exact measurements, however, my > impression is that my RPi4B can do it a tad faster than my BeagleBone > Black. With the RPi4, I needed to improve the debouncing of the > encoder and the buttons, because it saw hundreds of bounces which the > BBB didn’t. However, it may also be, that the internal GPIO circuits > of the BBB have a different damping characteristic. > > Anyway for my applications, 100 kHz way faster than what I need. > > On my GitHub repository I placed another example on using the GPIO > events for the RPi: > > https://github.com/cyclaero/shutdd > > See also the respective thread on this mailing list: > > https://lists.freebsd.org/archives/freebsd-arm/2022-July/001576.html Ok, I misunderstood.  Thank you; will look into it and give it a crack, this is good news. -- -- Karl Denninger /The Market-Ticker/ S/MIME Email accepted and preferred --------------xufv58awLsQCflyz0sXPDgOc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On 1/24/2023 2:15 PM, Dr. Rolf Jansen wrote:
Am 24.01.2023 um 13:58 schrieb Karl Denninger <karl@denninger.net>:

On 1/24/2023 10:43, Dr. Rolf Jansen wrote:
I sent an old ink to the thread on the mailing list, which does not work anymore. Here ist the new link:


Am 24.01.2023 um 12:35 schrieb Karl Denninger <karl@denninger.net>:

Thank you -- will check it out.

On 1/24/2023 10:35, Dr. Rolf Jansen wrote:
Am 23.01.2023 um 11:41 schrieb Karl Denninger <karl@denninger.net>:

Is there support somewhere in the 13.x for other than "read current state" / "set current state"?

Specifically, there is evidence in the sys/gpio.h header file that I can open up a file descriptor and then use select()/read() to grab the contents of a ring buffer of some size (presumably interrupt-posted) of events since last look, and determine if there's anything in there.  Provided you're reasonably fast this might be enough to, for example, read an optical encoder that has a modest pulse rate.

I see apparent review code at https://reviews.freebsd.org/D27398 from late 2020, but nothing else I can find digging around; an example (assuming it is actually implemented and works) would be helpful

See


And the messages in that thread that follow the one linked above.

There is a respective thread on this mailing list as well:

-- 
Karl Denninger
karl@denninger.net
The Market Ticker
[S/MIME encrypted email preferred]

So the answer at this point appears to be "not in the codebase and no indication on when/if it might be, but there are patches that are in some state of development.“

No, at this point (13.1-RELEASE) everything is in the kernel, no patches needed. Even the test tool made it into the source tree. It has only be renamed from gpioc_intr_test.c to gpioevents.c.

/usr/src/tools/test/gpioevents/gpioevents.c

The documentation is missing. It is however easy to learn how things work by examining the code of gpioevents.c.

Being able to read an encoder of some sort basically means being able to know how many events occurred between "looks"; for most purposes you don't need each event delivered exactly when it occurs, but missing some of the counts entirely is not acceptable.

Yes, and for this reason, this GPIO event code which was developed by Christian Krämer in the course of the GSoC-2018 and has been submitted in 2020 by Ian Lepore to the freebsd tree is perfect.

Ian tested it with a 10 MHz sqaure wave on an imx6 (ARMv7, 1GHz) and got an event every 10 µs. That means the max. speed without event losses would be 100 kHz. I did not do exact measurements, however, my impression is that my RPi4B can do it a tad faster than my BeagleBone Black. With the RPi4, I needed to improve the debouncing of the encoder and the buttons, because it saw hundreds of bounces which the BBB didn’t. However, it may also be, that the internal GPIO circuits of the BBB have a different damping characteristic.

Anyway for my applications, 100 kHz way faster than what I need.

On my GitHub repository I placed another example on using the GPIO events for the RPi:


See also the respective thread on this mailing list:

Ok, I misunderstood.  Thank you; will look into it and give it a crack, this is good news.
--
-- Karl Denninger
The Market-Ticker
S/MIME Email accepted and preferred
--------------xufv58awLsQCflyz0sXPDgOc-- --------------ms040303040201060107080104 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DbowggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBxIwggT6oAMCAQICEgLG8yH4PQFdbd9x Ugmpzl1jXzANBgkqhkiG9w0BAQsFADB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlk YTEZMBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENB MSUwIwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBMB4XDTIyMDYyOTE2MTYz NloXDTI3MDYyODE2MTYzNlowOjELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEX MBUGA1UEAwwOS2FybCBEZW5uaW5nZXIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC AQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvW ZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B 3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTgy+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYI XgVVPgfZZrbJJb5HWOQpvvhILpPCD3xsYJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMi WapsatKm8mxuOOGOEBhAoTVTwUHlMNTg6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMb NQm1mWREQhw3axgGLSntjjnznJr5vsvXSYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZM qa20JLAF1YagutDiMRURU23iWS7bA9tMcXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5 CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1l y+5ZOZbxBAZZMod4y4b4FiRUhRI97r9lCxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY 2BlA7ExM8XShMd9bRPZrNTokPQPUCWCgCdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEE MDAuMCwGCCsGAQUFBzABhiBodHRwOi8vb2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNV HRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYI KwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCGSAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBD bGllbnQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNV HSMEgcIwgb+AFF3AXsKnjdPND5+bxVECGKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQ MA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5 c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lz dGVtcyBMTEMgMjAxNyBDQYITAORIioIQzl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJs QGRlbm5pbmdlci5uZXQwDQYJKoZIhvcNAQELBQADggIBAKquc7cu0xc8FNtAQauZvocDzWQj 7HG9YvMbWnMi+ckhiA3rdW5NwWg0HBhBho1YlnqV+ntCVE2L8ezohHWm+KAdfXgpraL86Vsn 3ywNlZu/3COMpo2ALuHln8YQtH3Y8ebvzKMdlf2b5WB+7mOFIxXIr4AnNOLKCkq5ZhzC6JW6 Jvw3P0csiGa3UrfatYID5NvPgkaQvEgimEjG3psZqwQTL2Wxohvw783PrDt3wS0XeNhvQ61g 3QJFZKuv+bmGH3YBSPo1t6NUGAr+JozX5lDihB8JGkBt/NwdYec49a08uL0BbPaAJ7NjuIPG 7Y0Ak7PXZT37yx/Zla9PzLMJFgbelOkaatdzbblMZPDEVZ27l4lGMmV83Lm3YP17sdAyS/Wp mav7WmJUkQ9iuIKzSpdc82i9Mfujl1vbBtwtkHNPPtKuulIFM4ZwrPKjlVdLqTSqD8m9yHEi Y0PuAooq63OpJWF6hvMaiIPBWEAVIaDW9uG0MshLl9DnHnMyrJTfuC33Z9mOGMz7dRBjJd5Y W02xAzYnUuEBOpj+LQv5R8XIFMHFXktqEKvQrXeM2RU+PcZqKOBkTktxBLn3NI5VfA15Jk0c 5V5XcOqo3p2hvrwvXrinrb2pEREnoqmfrkXT3zOq5Y6ryRH8u734lGEF0dILXzoV4PM7XFit oTePoEjmMYIFBDCCBQACAQEwgZEwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGEx GTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTEl MCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQQISAsbzIfg9AV1t33FSCanO XWNfMA0GCWCGSAFlAwQCAwUAoIICQzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0yMzAxMjQxOTE3NTlaME8GCSqGSIb3DQEJBDFCBECChN8Jgm53VzZW+A3q KrgsdlMFg9twm/1Frnew3LmtIPpy9G9kdOz9K/YwgHmDxG0RdPBwxbQ7TYx1NalVb5++MGwG CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw gaIGCSsGAQQBgjcQBDGBlDCBkTB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTEZ MBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENBMSUw IwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBAhICxvMh+D0BXW3fcVIJqc5d Y18wgaQGCyqGSIb3DQEJEAILMYGUoIGRMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9y aWRhMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMg Q0ExJTAjBgNVBAMMHEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0ECEgLG8yH4PQFdbd9x Ugmpzl1jXzANBgkqhkiG9w0BAQEFAASCAgCszCgEX7RkxA6RNDfMWh8YR6PDimpl+J/Wij6l H4p+6ZjmLJk4oeEeD8cd+voXgZ7hXMJDfq2QIYIai6kjczaS7LARSsbTEly1RZgEQRheah/b adT/ZcEjB2GI7mJ3ngFVstU9d2wMal1XMdcrlX22zd0cBUdtocbsLvfLFsgugo0T1fKnOL4O ZOsxww9dboDZCMJ0LhP0hZ6dVgMukwfYE4ZHZPoHEnDZm38H9nl+byiYCLoRx+eHcWuEC1iq IDLSJ5jEgpeMGgaXrr0q6P81P71ASWrC60GvNRX9fouwv4ZDJqeBZQOxx8lkkVg0iGbN7+Ix OxRD+jzkp38K/Qj4WSX6Jse/TAyZyJZqQ5Q1bo2AzWNCFzCGLHIVouT3s9xY2gae2EluJG7Q 2m+18rp+ucIsqhLGQ8jyuZZv9iKBYItyYwPzuExyRqlyiAGhYigJjq9sl5aB+zmpobgtl1Uv Z62VkVKB0GAnf+UfITv8e0Z5Pq5JBMm3k+0L7XQKAG1t3IF06HEHayTKdpkphlD5UYvfMn0f G3apIgaNU0QuS4LB/TvtNVs4HgVW03OgCrX5TyxfOcJiYYvGocBnYtgYbic8fR23/ACSMIfu qR/brhd7q/wjh1r7hOu61+A+p3vay55mwSgcqSqbeAY3hUp89b6G8761cqIVIX177WHoUgAA AAAAAA== --------------ms040303040201060107080104-- From nobody Tue Jan 24 19:55:10 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P1d4B4gZbz3bMF2 for ; Tue, 24 Jan 2023 19:55:22 +0000 (UTC) (envelope-from jjrushford@gmail.com) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P1d4B2pBDz3trG for ; Tue, 24 Jan 2023 19:55:22 +0000 (UTC) (envelope-from jjrushford@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-il1-x12b.google.com with SMTP id r19so7548311ilt.7 for ; Tue, 24 Jan 2023 11:55:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=hkjfU5Tdk2TZLUFnhUtBgenE1zM1S5z/Id26RzHD8bU=; b=CjQ3KN2vqPq2k3kyBQgyBjkEMCbvvroo9l/vJ8oWaYGYPDtefw6nHLHU7+yIeGpyow 7D0K4F0Y5Rd/Tg3qajBsjG77HE13k4haOuW3MpvnWwlUKhpZH5JgdQEiHinKKjbXtHq5 UkqcUJNTXa4myYY3rvAZ1v1JmfCDC2K8Ym9+jnN6lanUwvPNvn7sviZMdzYulMpfENwi 7hFNg/X5vjudCo7GaAVsCD3mNTTP1fvyGhINFX0vwfET4Y81Ultdjx2ExgOzNnErGIwJ GGh+ha1fTQ/5fz+ZTnagD3kbpLkcuZ05O1VjB9ry/4KFCOq0JaenmOQ8Hm2bOLivXBW/ K2Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hkjfU5Tdk2TZLUFnhUtBgenE1zM1S5z/Id26RzHD8bU=; b=QPbLnPwqUZISe4d8DhKgCxxmqtwWwNDAQyBZJuDxHsYfsZZeR9EmG+dNhny6+fLcyW cI3riHYhtF8seIwo08HMMvsXv7+Qtgg4C4mMONkINb1glExwb4R2HoTHqxx96mnsizZD eWL3K/Xx4OE3uTUmYh7oREFrFsUVJ2oARh9VBLgv0Q/z9BI5MmHUjt+SRVhq73ZT1pk3 naf3bXBVqc++KdVSCUWNpg/Xy2ToqLVm84H7U4xV8KQdCHPibvSTt9Ps41jcYPCD1Zn2 2qvzIoDDQMWRtMKpQK+ZP3BnuPeNrleTcJj11GNnz5H8fNVbQSqIYmTRxRbgdwLUgAK/ YLlQ== X-Gm-Message-State: AFqh2kpsrRjyrZk1TZ8eFSoi4DdbVFF6SQBdVxrliiGo3WUw6+yQws6L PS7Hapm19LgESwm78SCrIygjh9KBPR+oCg== X-Google-Smtp-Source: AMrXdXu3i7Dy6jAKpfr9dNOXg3sAeFhE3x0r8tAwvGy02aezNw4Lf1hV6yqBLxP2IyFsSSMTz3OO4A== X-Received: by 2002:a05:6e02:1ca7:b0:30e:ed6d:ef37 with SMTP id x7-20020a056e021ca700b0030eed6def37mr27466614ill.6.1674590121328; Tue, 24 Jan 2023 11:55:21 -0800 (PST) Received: from smtpclient.apple ([2601:280:587f:1450:84e6:9743:8888:b2e8]) by smtp.gmail.com with ESMTPSA id g16-20020a92d7d0000000b0030c332915aasm916591ilq.49.2023.01.24.11.55.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Jan 2023 11:55:20 -0800 (PST) Content-Type: text/plain; charset=utf-8 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: Testing All 5 Uarts on Raspberry Pi 4B From: John Rushford In-Reply-To: <97c23a36-a98e-f83c-e0e2-02bbeee0fdfe@thegalacticzoo.com> Date: Tue, 24 Jan 2023 12:55:10 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <97c23a36-a98e-f83c-e0e2-02bbeee0fdfe@thegalacticzoo.com> To: Fred Finster X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Rspamd-Queue-Id: 4P1d4B2pBDz3trG X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Fred, I=E2=80=99ve updated the bug with the additional data you requested. I = have the GPS card wired: VIN: pin 2, 5v PPS: GPIO pin 18 GND: pin 5 ground. RX: pin 4 TXD. RX of the card is wired to TX on uart3=20 TX: pin 5 RXD. TX on the card is wired to RX on uart3 FreeBSD shows no incoming data from the card and gpsd there is unable to = read any data. pstat -t shows no available data on ttyu1, where is it? With the same pi and wiring shown above, booted into Debian, incoming = data is fine from the card. The gpsd daemon reads the data and I can = get NTP to use the PPS signal to synchronize the pi clock. John > On Jan 24, 2023, at 5:53 AM, Fred Finster = wrote: >=20 > TOP POST answer : = https://forums.raspberrypi.com/viewtopic.php?t=3D244827 Testing of all = 5 UARTS near bottom of this URL link >=20 > = https://forums.raspberrypi.com/viewtopic.php?t=3D244827&sid=3D9955627b0e78= 44c752f46b5ae55ef684&start=3D75 Page 4 URL link >=20 > *I copied and pasted below. I /apologize in advance for troubles I am = inflicting on text only email viewers. I have set my Thunderbird/* >=20 > */email to send out only text email. Fred/* >=20 > FreeBSD creates /dev/ttyu1 >=20 > Sounds like you need to disable bt???? Adding "dtoverlay=3Ddisable-bt" = switches the UART roles so that UART0 is mapped to 14 & 15 (Alt0), = leaving UART1 unmapped. >=20 >=20 > = https://forums.raspberrypi.com/viewtopic.php?t=3D244827&sid=3Df4a784a3c40e= d0940e6fbb9f81af5015&start=3D25#p1590882 = >=20 >=20 > Re: Pi-4 Activating additional UART ports > = >=20 > Mon Jan 06, 2020 10:36 am = >=20 > On all Pis, UART0 is a PL011 that appear to Linux as ttyAMA, and = UART1 is an 8250 clone that appears as ttyS0. On a Pi4, UART2-5 are = additional PL011s that also appear as ttyAMA. The number starts at 0 = for the first enabled PL011 and counts up through all the enabled = interfaces. The numbering is stable for any given combination of UARTs, = but enabling or disabling one can change the number assignments of = others. >=20 > Adding "enable_uart=3D1" to config.txt on a Pi4 enables ttyS0 (UART1) = on GPIOs 14 & 15 (Alt5), leaving UART0 driving the Bluetooth interface = on 30-33 (Alt3). Adding "dtoverlay=3Ddisable-bt" switches the UART roles = so that UART0 is mapped to 14 & 15 (Alt0), leaving UART1 unmapped. >=20 > As rpdom says, you can only enable one function on any pin at once, = and enabling the same alternate function (e.g. RXD0) on multiple pins = usually results in failure (outputs tend to work, inputs don't, but it = is essentially undefined behaviour). >=20 > *//* >=20 > */ > /* >=20 > */From:/*John Rushford > */Date:/*Sun, 22 Jan 2023 03:27:38 UTC >=20 > Mark, >=20 > Thanks for the reply. I only have =E2=80=9Cdtoverlay=3Duart3=E2=80=9D = in the config.txt and with that entry, FreeBSD creates /dev/ttyu1 and = /dev/cuau1 along with the .init and .lock files. > So, I tried with this entry in /etc/ttys and it was of no help, still = no data: >=20 > ttyu1 "none" vt100 on secure >=20 > thanks > John > jjrushford@gmail.com >=20 >> On Jan 21, 2023, at 8:18 PM, Mark Millard wrote: >> On Jan 21, 2023, at 18:34, John Rushford = wrote: >>> I have installed FreeBSD 13.1 on a raspberry PI 4b rev 1.4 and I am = trying to use the additional serial ports that are available with the PI = 4 with an Adafruit ultimate GPS card. >>> I found that it was problematic using the first serial port ttyu0 on = GPIO pins 14 and 15 as data on the line from the GPS would interrupt the = boot process and I verified that I was in fact able see data time stamps = from the GPS card on the first uart port once I got FreeBSD to boot. >>> Now since I do not wish to use the first serial port, I=E2=80=99ve = built the rpi-firmware port and copied all the uart dtb=E2=80=99s to = /boot/msdos/overlays and I=E2=80=99ve tried enabling the uart=E2=80=99s = in /boot/msdos/config.txt with =E2=80=9Cdtoverlay=3Duart3=E2=80=9D for = example. Enabling them does in fact result in device entries created = for them in /dev but, I am unable to see any data on the corresponding = ttyuX or cuauX ports. >>> Just to eliminate a wiring error, I installed another SD card with = Raspberry PI OS, enabled uart3 and I am able to see data on uart3 = without any issue confirming I have everything wired up properly. >>> With FreeBSD, I have set the proper baud rate on the ports and = I=E2=80=99ve tried disabling flow control on them, using stty, but no = matter what I do, I never see any data on them. Unless I=E2=80=99m = missing something, I can only conclude there is some bug in FreeBSD = preventing me from using these additional serial ports. Has anyone here = on this mailing list been able to use them? If so, what does it take? >> You did not mention /etc/ttys editing. So I wonder if you >> changed any of the lines like, say, >> # Serial terminals >> # The 'dialup' keyword identifies dialin lines to login, fingerd etc. >> ttyu0 "/usr/libexec/getty 3wire" vt100 onifconsole secure >> ttyu1 "/usr/libexec/getty 3wire" vt100 onifconsole secure >> ttyu2 "/usr/libexec/getty 3wire" vt100 onifconsole secure >> ttyu3 "/usr/libexec/getty 3wire" vt100 onifconsole secure >> to use, say, none instead of "/usr/libexec/getty 3wire", and other >> related edits. >> But I've not tried to get any extra serial ports going on >> an RPi4B. So the above is just guess work about something >> to experiment with. >> =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com >=20 > https://forums.raspberrypi.com/viewtopic.php?t=3D244827 Testing All 5 = Uarts on Raspberry Pi 4B near bottom of this URL link. >=20 > Question has anybody here on FreeBSD arm mailing list group made some = or all of the Raspbian Linux Tools operational on FreeBSD? Maybe this is = a simple recompile with a couple modifications? >=20 > I should just try myself first. Just checking that NO ONE ELSE has = already completed a Tool and is willing to share. >=20 > raspi-gpio, rasp-imager, rasp-config, dtoverlay >=20 >=20 > I suggest you start by running the following to establish whether the = configuration has been successful: >=20 > $ raspi-gpio get 0-15 $ ls /dev/ttyAMA* >=20 > raspi-gpio get 0-15 GPIO 0: level=3D1 fsel=3D3 alt=3D4 func=3DTXD2 = pull=3DNONE GPIO 1: level=3D1 fsel=3D3 alt=3D4 func=3DRXD2 pull=3DUP = GPIO 2: level=3D1 fsel=3D4 alt=3D0 func=3DSDA1 pull=3DUP GPIO 3: level=3D1= fsel=3D4 alt=3D0 func=3DSCL1 pull=3DUP GPIO 4: level=3D1 fsel=3D3 alt=3D4= func=3DTXD3 pull=3DNONE GPIO 5: level=3D1 fsel=3D3 alt=3D4 func=3DRXD3 = pull=3DUP GPIO 6: level=3D1 fsel=3D0 func=3DINPUT pull=3DUP GPIO 7: = level=3D1 fsel=3D0 func=3DINPUT pull=3DUP GPIO 8: level=3D1 fsel=3D3 = alt=3D4 func=3DTXD4 pull=3DNONE GPIO 9: level=3D1 fsel=3D3 alt=3D4 = func=3DRXD4 pull=3DUP GPIO 10: level=3D0 fsel=3D0 func=3DINPUT pull=3DDOWN= GPIO 11: level=3D0 fsel=3D0 func=3DINPUT pull=3DDOWN GPIO 12: level=3D1 = fsel=3D3 alt=3D4 func=3DTXD5 pull=3DNONE GPIO 13: level=3D1 fsel=3D3 = alt=3D4 func=3DRXD5 pull=3DUP GPIO 14: level=3D0 fsel=3D4 alt=3D0 = func=3DTXD0 pull=3DNONE GPIO 15: level=3D1 fsel=3D4 alt=3D0 func=3DRXD0 = pull=3DUP pi@raspberrypi:~$ ls /dev/ttyAMA* /dev/ttyAMA0 /dev/ttyAMA1 = /dev/ttyAMA2 /dev/ttyAMA3 /dev/ttyAMA4 >=20 > config.txt file contains >=20 > enable_uart=3D1 dtoverlay=3Dpi3-miniuart-bt dtoverlay=3Duart5 = dtoverlay=3Duart4 dtoverlay=3Duart3 dtoverlay=3Duart2 >=20 > (The miniuart overlay uses ttyS0 for Bluetooth, freeing /dev/ttyAMA0). >=20 > The help info shows the GPIOs used by each new UART - 0-3 for UART 2, = 4-7 for 3, 8-11 for 4 and 12-15 for 5. This does mean that UART 5 = overlaps with the standard UARTs on 14 & 15, but UART 5 has its flow = control signals there - TXD5 and RXD5 appear on 12 & 13. >=20 > I wonder, as GPIO 14 and 15 already used for uart0, how could Uart5 > flow control use GPIO 14 & 15 ? >=20 > By not enabling UART0. >=20 >=20 > I deliberately reversed the order of the UART overlays to demonstrate = that ordering here makes no difference to the ttyAMA numbering. Using = this script: >=20 > Code:Select all = >=20 > |#!/bin/sh sudo stty -F /dev/ttyAMA0 115200 sudo stty -F /dev/ttyAMA1 = 115200 sudo stty -F /dev/ttyAMA2 115200 sudo stty -F /dev/ttyAMA3 115200 = sudo stty -F /dev/ttyAMA4 115200 while true; do sudo sh -c "echo 0 > = /dev/ttyAMA0" sudo sh -c "echo 1 > /dev/ttyAMA1" sudo sh -c "echo 2 > = /dev/ttyAMA2" sudo sh -c "echo 3 > /dev/ttyAMA3" sudo sh -c "echo 4 > = /dev/ttyAMA4" sleep 1 done | >=20 > and moving my PC serial cable around the pins I found the following = mapping: >=20 > Code:Select all = >=20 > |GPIO14 =3D TXD0 -> ttyAMA0 GPIO0 =3D TXD2 -> ttyAMA1 GPIO4 =3D TXD3 = -> ttyAMA2 GPIO8 =3D TXD4 -> ttyAMA3 GPIO12 =3D TXD5 -> ttyAMA4 | >=20 > In other words, transmitting works on all 5 PL011/ttyAMA UARTs. >=20 > Running "cat /dev/ttyAMA" on each of the different UARTs in turn = and moving the TX pin of the PC serial port around the various RXD pins = produced the RX mapping: >=20 > Anyone know of Top Hats for a Raspberry Pi 4 that brings all 5 uarts = to a 3.3V TTL level and drive some LEDs to see TX and RX activity, plus = MAX232 style drivers to shift >=20 > from 3.3 Volt level to + - ~10V RS-232 drive level to a DB-9 IBM = compatible D shell Connector? With possibly a RS-485 driver style = connection for long wiring runs? >=20 > Does this exist? or Should one fire up KiCAD and design such a board = specifically for Raspberry Pi 4B 5 uarts? Probably a market size of 10 = - 50 boards world wide, not much? >=20 > Hope this works for you John R. >=20 > --=20 > Fred Finster > fred@thegalacticzoo.com > +1 971-718-9144 > https://GhostBSD-ARM64.blogspot.com > https://ghostbsd.org >=20 >=20 From nobody Tue Jan 24 23:13:22 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P1jT25bLWz30xPX for ; Tue, 24 Jan 2023 23:13:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P1jT13DDpz3NhQ for ; Tue, 24 Jan 2023 23:13:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=PHBJblGG; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1674602019; bh=HD+0B+8XZgSgbgL4tyXMO3SHYxyFxIkHJgyQA13kRjU=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=PHBJblGGf+0NQXOOzrwMZgQv+R8ODVVY3tWQcsBoZUq16MQnv7XRaM7XZwij6uOkj3PPyFEKjL7H6qDujQRy1zkZ72Xz1nVuDPQUnzz2ARCWuysrTtnsdE9KAJUgKNsKpIbA9TlkaKxMa/GbtS0Lh3oAwAozREZBTbSQoUSPoiUrEPyeeQVnaYyLIhFMxde71Henvws+NKaerk57HVgZiMceeEXngrrefJ2V5HIs9C9ThILdj4h/9UtPSolCcBzrytoaNGzToICQ+AulZnIJM/c7mdU0rkQLihtrwbSIgV9T0cZ2hjiUudANBNdCdbqTV9/RMRSB9q1Ohoat+KU4Yw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1674602019; bh=CTL6SHTqFM4Q/+s0xVH8KK4oa0IjOWaLIuTtE9bpZRG=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Xbs3RIjjhtJ7piqjgiIwIU1lK65BAgsw4vP2oFhH3vxFvmuvC2TJBo4TvqT4p9c96xmxts+QXH/RWMrbUrOCS6xnyi4FN/10/xoLiDErDr2YxksS8bOqXfTExhS4+NZiSv8Y6lGAga/EvEDqT7FH8a57EEqctdXvEfAqOC9ru7oxX+FdPCC6BitcEfNwxAIwKseA8fChjM5o5X3hAzOq+lQPtHq1Jyl3y4lQq/BXhgv8Ef24YtyX0W2tDB3i4C3KudQtSvSpUAiUSvpneLZeOjv5J/GFs5nxn7EqXu/701SubyrBcdMOVpbud/A81yTF7GmOv+7UwptDkSA0F3QvWA== X-YMail-OSG: M2xr3SMVM1kGWsnovAw2daSNXNPKwwNkzrY9xb3yM5fDyMFi_ZmBrckPQvFB.9p 8a.jwFmoKaPiMeKh1MPi1wQOn0UIdVgUzvG5B.y9O44KgO5jWpq1k6HGILnKhuBQgqmKcjUnaBX5 aYl5rcm3MK5a8som0zll9aqRu03TY_gPg633BpLJeqsoq3bi4RD256Wtc_qb5AIOMllCqyuQuNyD cYxkD0eO2ReoA65ZgHGgtk7khS0552rx7rjNzChiH3F1ERMIt5p.9hlYP0lQrS8C6eg0Blu5qUNQ H188NidYFTk1MubcC8.zIFx2W2zpWgvEtGAELI0g7pUWgApWo4elyty8joRhbVbaWBXCQ73d9Ir. ttrazQPv23bdNDiLQ0Z3IKVDpo0jvN6HOBO9IjGB1tH5w5vGuT1xT3X7h4D1KtE0OMroaejf7z4s CCQOmen9jP_0Q1OZNI7YqgzGJkaz3xl1CYENqEHR5rg1crstU6It0FmIb6nzfPXT93cR3huTSlUF 8ftdpzqNnAK1s_j80sMP1E51PyO..aFS2XrCGFQPB2yUojhWAnrJamLcgsi6xrfLlnnae35uSbqT puSnBzb_Q_XocOm8eGVhu_ldTTjH2Ax2JFyZf7p5eQVkmAmv0XRGHT3.gn2yrbZ6WeEAOb7O6qVg zdCTWbpl3XzSyLchlOK3heQ7dEIcmyohvZKYhGHfRqOHRnF.PVhlxR.Ve8QsLQ9.jirkjZafy2YM HlA3p5ZVRl4mzb0HRagX_GaJS1Orzp9LPW.iHvy_n.EVUyrLVU1OM9vXio3VVsYKGIl.e7dN93nI jOmv8ntQN3l7..1n4aSkOnJay2cyekwOLRaPYTq3MHqtQBdx62CEjDDji6X9Euepoy52P5ZEqE42 9WZ8uvNOEvX8MCNpUmBMIXfdjFkbJHTCOXUE2fmKcwv7l7dDcQQOZXk9D4aqhJXQs1daukbZk6Fp _zfd0wXCdU_cot4E3KdmLtvC5As3uN0AKQlvtv94VTCc_KZ6WPpNGhoshMMBeiwyLkWNfjQN4RIa cgTEp52t5D8dUhKDDBIWMMYISNqnSsURE4Cr4d2Kp6F_vMmvcLvkaRHYOjTO8HbPeWIQoe_9cb00 qUvC351UaFONxsid5BdNK1ZiAhYWwGZ_pw4nd1pn03.gSR5OmNgopg7l59OAA8uyc6R_x36QlDIk ysq4GXyDwzmHCDSgFuD0IbKwouum.BYH43SLjtcyEmftllG8ggSGJIQQPGUAWdywsSfIBmNrW6wz VUAC.7C8hzKoCmR9U0TaT6zWcXZkWfRkH.w0wOF5quYg0Iva8l6W9RGKfFks5eB0Ywi9GqT36pd_ I.0USbgLiy7F6hlTqg3W8e4OdO4TxUvwMeB6VfgcV6hTQv32pXCgaGiO1VSYkPkwVvigJGmTPvyk yFbxCzba2XMbLzoCSGau7njOcbZ9EOPYjq7nBNE.y.EH9GQp7gCsEV8UAejsbdDf9hxMeft.FrbB f529nI.nnkdfI89SnwtzzuFtPXp6Sm1IDLD52qg8D6H9Nw_rrrucK3e0saiyVtlucXFLY.AIb7e0 RUYXrxSGlQBpU.bWQU6QrnqmE15ClNh4E0E7wLAWbtVKQSAxmjghqYmQI._Qf8Ro8K9zpeahDkIM 7QAMieqVw2Nkiqnz.Rx2BO5KWERViglbUQLyaf2JZLUICJCYmNPW4f27KVvI7ugYIWwRVFiDCQjJ IoxK1KYgsnSpcjm_1yNml2vnG.EdQQp.Pz1sg0AwEvrQRbDaUYixw1P.PWPVp17pT8Bp7ce0Uovw BoJQ2P2dAhJRSuPG.8Q55UtekRE28NA1uHD_7XWyFk6ENiHdzisEnQ94B5EHrrXw48IeP6jEi139 AcNV8QR36oAoDBUcLXnMdEbxrUwZSsLPEa._BWH3.7or_BBca3.lOD_.JzILZwNgZTbrdqwZ1TVi c6e_Ike1ZA4PKE4dCSUusTeaD4_hxTZ4erWaDJe81b7ZioN12JDayz4eYIY4Ns40qKrYQ0T3eUko 2fmL2bWzrrxt1hoiiGK0VfsoXN8O19Wjhjd2ujW5g32N2WZGjbQSZmqdvgP0chMz8av.kJuhFCDh AAQhs8ONq.RJ.iHpRQ7hfhyaRJfDKJ3NlrS778B.rww14vEN5gqkKvRPQwdYYrW2JmiagIxPK5mv aeKwnHbpoKO99Iua7W9Rr3pkGrtAevWfljWi1RMrfWN7jkROs3MFVqL9JsUkujZDTMMAuqaVHCYi qKjJLaquXqehg4GRNdesT.VYWD64tDOtjyx6KxOMrL7F.zLaSxdIAqjHzDkxo9Q-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Tue, 24 Jan 2023 23:13:39 +0000 Received: by hermes--production-ne1-644674576b-9thps (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3becd1baaefc510647da10edf2b3c2dc; Tue, 24 Jan 2023 23:13:34 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: FYI: RPi4B "C0T" vs. "B0T" (Inbound from PCIe 3 GiByte limit for XHCI use) in various Operating System/Firmware combinations Message-Id: <69C5120B-B0F3-48A0-875C-1CA8E29F78B0@yahoo.com> Date: Tue, 24 Jan 2023 15:13:22 -0800 To: freebsd-arm X-Mailer: Apple Mail (2.3731.300.101.1.3) References: <69C5120B-B0F3-48A0-875C-1CA8E29F78B0.ref@yahoo.com> X-Spamd-Result: default: False [-3.19 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.69)[-0.693]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-Rspamd-Queue-Id: 4P1jT13DDpz3NhQ X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N [To a notable extent here, "C0T" vs. "B0T" RPi4B handling is a stand-in example for the more general issue of Device Tree dma-ranges support for address space translations (or analogous in UEFI/ACPI), not limited to RPi*'s at all.] In exploring the status of handling "C0T" RPi4B's (and more) vs. "B0T" RPi4B's for the XHCI related context that involved the 3 GiByte mistake in the PCIe wrapper logic for the "B0T" parts, what I have found is that . . . A) OpenBSD has had full Device Tree handling of the dma-ranges in place for some time. It supports "C0T" XHCI use in a manor that avoids needing the bouncing. For "B0T" it uses the dma-ranges and spans the 3 GiByte range as well, no longer using a hand coded, much smaller value somewhat under 1 GiByte. OpenBSD normally uses U-Boot. Some (possibly outdated?) material indicates that RPi400's require(?) https://github.com/pftf/RPi4/ (EDK2) use instead, warning to probably use a specific known-working release, 1.21 as I remember. So see later EDK2 related notes for if that is the case. (I do not have access to a RPi400.) B) Linux has had Device Tree handling of the dma-ranges in place for some time. It supports "C0T" XHCI use in a manor that avoids needing the bouncing. For "B0T" it uses the dma-ranges and spans the 3 GiByte range as well. Fedora uses U-Boot. RaspiOS64 (my abbreviation) does not (nor does it use EDK2). Both avoid bouncing for "C0T". (I've not looked at others in operation.) C) The EDK2 implementation treats "C0T" parts in same the manor it handles the "B0T" parts. So bounce buffers end up being used for above the lower 3 GiBytes. Thus, even if something using EDK2 could support avoiding that bouncing for "C0T" parts, it would not avoid such: only a smaller-size aspect is published, using an identity for the address space translation. But see below for OpenBSD mixed with EDK2/DeviceTree. D) For EDK2/DeviceTree, OpenBSD actually undoes some of what EDK2 provides. This was for OPenBSD to support more modern RPi* firmware to support more modern devices according to comments in the code. (Some of what EDK2 does was to avoid earlier problems with OpenBSD and Linux when used with EDK2. So much for a clean firmware/OS partitioning.) E) NetBSD is based on UEFI/ACPI and, so, is an example of (C) for https://github.com/pftf/RPi4/ . I'm not sure if NetBSD would "just work" if EDK2 started to allow "C0T" parts to have the PCIe space vs. CPU memory space address translations that are involved in avoiding bouncing. As stands, it might be untested because of EDK2 avoiding involving such space translations: only a smaller-size aspect is actually in use --instead of a address space translation with a full-size. F) FreeBSD Device Tree handling hand codes a "B0T"-like structure and ignores dma-ranges completely. If I have understood the PCIe/XHCI related code correctly, there is no general infrastructure for supporting the generality of the PCIe space vs. CPU memory space addressing translations that dma-ranges support would need to be effective. More than just decoding the dma-ranges in order to initialize an existing infrastructure would be required as far as code changes go from what I can tell. So, if I understand right, any Device Tree with dma-ranges indicating non-identity address space translations currently needs to hand code a no-address-translation alternative unless they go to the effort to add the infrastructure. It is not just an RPi* issue. Also, for an identity address space translation but a smaller-size, this too is ignored. But it appears that the existing infrastructure could be initialized for this case, if I understood correctly. It did not appear to have to be handled in RPi* specific code. Note: FreeBSD's UEFI/ACPI support for the RPI4B used to not handle even just the smaller-size aspect when the translation was just an identity translation: it was set up such that one page past the end of the smaller-size ended up being allowed to be used. That lead to corrupted files and such in deliberate testing. I've not checked the status of this in recent times. === Mark Millard marklmi at yahoo.com From nobody Wed Jan 25 16:45:28 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P28pr4gl2z3bswm for ; Wed, 25 Jan 2023 16:45:40 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P28pq6MNBz3CCF for ; Wed, 25 Jan 2023 16:45:39 +0000 (UTC) (envelope-from karl@denninger.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net; dmarc=pass (policy=none) header.from=denninger.net Received: from denninger.net (097-081-026-048.res.spectrum.com [97.81.26.48]) by colo1.denninger.net (Postfix) with ESMTP id 6C1572110B5 for ; Wed, 25 Jan 2023 11:45:33 -0500 (EST) Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id B17B0281F67 for ; Wed, 25 Jan 2023 11:45:30 -0500 (EST) Message-ID: <1cd552a7-b015-c935-06fc-9f12e1b37daa@denninger.net> Date: Wed, 25 Jan 2023 11:45:28 -0500 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: GPIO inputs on Pis? Content-Language: en-US To: freebsd-arm@freebsd.org References: <0b235f83-7cb3-1d14-7c64-aee7c1c0c23d@denninger.net> <01070185e46b1a6e-ee34b885-1215-45c7-ac18-83320c02cac2-000000@eu-central-1.amazonses.com> <01070185e4732fd8-c0bede0b-d9df-4557-a174-cb237fa4bfaf-000000@eu-central-1.amazonses.com> <01070185e534f221-14f362b5-2b96-43f0-b0b0-f496ad9994fe-000000@eu-central-1.amazonses.com> From: Karl Denninger In-Reply-To: <01070185e534f221-14f362b5-2b96-43f0-b0b0-f496ad9994fe-000000@eu-central-1.amazonses.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms090009090809040403030506" X-Spamd-Result: default: False [-4.90 / 15.00]; SIGNED_SMIME(-2.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[denninger.net,none]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+mx]; ARC_NA(0.00)[]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[karl]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4P28pq6MNBz3CCF X-Spamd-Bar: ---- X-ThisMailContainsUnwantedMimeParts: N This is a cryptographically signed message in MIME format. --------------ms090009090809040403030506 Content-Type: multipart/alternative; boundary="------------k2FnGkugSJrI0WsNDUAuyMyd" --------------k2FnGkugSJrI0WsNDUAuyMyd Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/24/2023 14:15, Dr. Rolf Jansen wrote: > Yes, and for this reason, this GPIO event code which was developed > by Christian Krämer in the course of the GSoC-2018 and has been > submitted in 2020 by Ian Lepore to the freebsd tree is perfect. > > Ian tested it with a 10 MHz sqaure wave on an imx6 (ARMv7, 1GHz) and > got an event every 10 µs. That means the max. speed without event > losses would be 100 kHz. I did not do exact measurements, however, my > impression is that my RPi4B can do it a tad faster than my BeagleBone > Black. With the RPi4, I needed to improve the debouncing of the > encoder and the buttons, because it saw hundreds of bounces which the > BBB didn’t. However, it may also be, that the internal GPIO circuits > of the BBB have a different damping characteristic. > > Anyway for my applications, 100 kHz way faster than what I need. > > On my GitHub repository I placed another example on using the GPIO > events for the RPi: > > https://github.com/cyclaero/shutdd > > See also the respective thread on this mailing list: > > https://lists.freebsd.org/archives/freebsd-arm/2022-July/001576.html So..... just to see  if I'm understanding this correctly (pretty sure I am having read through the test code). Presume I have "X" pins configured as inputs and "Y" configured as outputs.  I use the ioctl calls to set the outputs (which works just fine) and can read current input state (which also works.) If I set /on the same descriptor /(not on the specific pins; it applies to all input pins on that descriptor as it appears there's no pin-specific setting in the configuration flags to enable this on a pin-by-pin basis) the event report config type I want I can then select() on the descriptor with the usual timeouts (or zero for a poll) and get a "ready" (much as one would for any other sort of I/O) and, if I do get a "ready" return on the descriptor a read() on that descriptor will return zero or more structures of the type I said I configured, each of which describes either an individual state change on one of configured input pins that is set up for individual event reporting OR a structure of the summary of changes for a given pin.  I assume given the 16-bit "count" field on the summary return that counts are "since last returned" and not "since boot" or "since descriptor was opened and configuration set." This also presumes that there is some buffer depth on this that, at some point, may be exceeded so if I "go away" for too long I may miss things -- particularly if I need detail-level reporting. Thus it looks like that its possible for most cases (assuming resolution of the time stamps is high enough and the driver timing is accurate enough, plus the code is sparse enough that actually does the reading) to not just read an optical encoder with this but also (if you use detail reporting) to read a bi-phase encoder so you can determine which direction it is moving. On to check it out; if I missed something here a "heh idiot, no it actually works like this!" would be appreciated :-) -- Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------k2FnGkugSJrI0WsNDUAuyMyd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 1/24/2023 14:15, Dr. Rolf Jansen wrote:
Yes, and for this reason, this GPIO event code which was developed by Christian Krämer in the course of the GSoC-2018 and has been submitted in 2020 by Ian Lepore to the freebsd tree is perfect.

Ian tested it with a 10 MHz sqaure wave on an imx6 (ARMv7, 1GHz) and got an event every 10 µs. That means the max. speed without event losses would be 100 kHz. I did not do exact measurements, however, my impression is that my RPi4B can do it a tad faster than my BeagleBone Black. With the RPi4, I needed to improve the debouncing of the encoder and the buttons, because it saw hundreds of bounces which the BBB didn’t. However, it may also be, that the internal GPIO circuits of the BBB have a different damping characteristic.

Anyway for my applications, 100 kHz way faster than what I need.

On my GitHub repository I placed another example on using the GPIO events for the RPi:


See also the respective thread on this mailing list:

So..... just to see  if I'm understanding this correctly (pretty sure I am having read through the test code).

Presume I have "X" pins configured as inputs and "Y" configured as outputs.  I use the ioctl calls to set the outputs (which works just fine) and can read current input state (which also works.)

If I set on the same descriptor (not on the specific pins; it applies to all input pins on that descriptor as it appears there's no pin-specific setting in the configuration flags to enable this on a pin-by-pin basis) the event report config type I want I can then select() on the descriptor with the usual timeouts (or zero for a poll) and get a "ready" (much as one would for any other sort of I/O) and, if I do get a "ready" return on the descriptor a read() on that descriptor will return zero or more structures of the type I said I configured, each of which describes either an individual state change on one of configured input pins that is set up for individual event reporting OR a structure of the summary of changes for a given pin.  I assume given the 16-bit "count" field on the summary return that counts are "since last returned" and not "since boot" or "since descriptor was opened and configuration set."

This also presumes that there is some buffer depth on this that, at some point, may be exceeded so if I "go away" for too long I may miss things -- particularly if I need detail-level reporting.

Thus it looks like that its possible for most cases (assuming resolution of the time stamps is high enough and the driver timing is accurate enough, plus the code is sparse enough that actually does the reading) to not just read an optical encoder with this but also (if you use detail reporting) to read a bi-phase encoder so you can determine which direction it is moving.

On to check it out; if I missed something here a "heh idiot, no it actually works like this!" would be appreciated :-)

--
Karl Denninger
karl@denninger.net
The Market Ticker
[S/MIME encrypted email preferred]
--------------k2FnGkugSJrI0WsNDUAuyMyd-- --------------ms090009090809040403030506 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DbowggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBxIwggT6oAMCAQICEgLG8yH4PQFdbd9x Ugmpzl1jXzANBgkqhkiG9w0BAQsFADB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlk YTEZMBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENB MSUwIwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBMB4XDTIyMDYyOTE2MTYz NloXDTI3MDYyODE2MTYzNlowOjELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEX MBUGA1UEAwwOS2FybCBEZW5uaW5nZXIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC AQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvW ZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B 3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTgy+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYI XgVVPgfZZrbJJb5HWOQpvvhILpPCD3xsYJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMi WapsatKm8mxuOOGOEBhAoTVTwUHlMNTg6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMb NQm1mWREQhw3axgGLSntjjnznJr5vsvXSYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZM qa20JLAF1YagutDiMRURU23iWS7bA9tMcXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5 CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1l y+5ZOZbxBAZZMod4y4b4FiRUhRI97r9lCxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY 2BlA7ExM8XShMd9bRPZrNTokPQPUCWCgCdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEE MDAuMCwGCCsGAQUFBzABhiBodHRwOi8vb2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNV HRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYI KwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCGSAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBD bGllbnQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNV HSMEgcIwgb+AFF3AXsKnjdPND5+bxVECGKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQ MA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5 c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lz dGVtcyBMTEMgMjAxNyBDQYITAORIioIQzl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJs QGRlbm5pbmdlci5uZXQwDQYJKoZIhvcNAQELBQADggIBAKquc7cu0xc8FNtAQauZvocDzWQj 7HG9YvMbWnMi+ckhiA3rdW5NwWg0HBhBho1YlnqV+ntCVE2L8ezohHWm+KAdfXgpraL86Vsn 3ywNlZu/3COMpo2ALuHln8YQtH3Y8ebvzKMdlf2b5WB+7mOFIxXIr4AnNOLKCkq5ZhzC6JW6 Jvw3P0csiGa3UrfatYID5NvPgkaQvEgimEjG3psZqwQTL2Wxohvw783PrDt3wS0XeNhvQ61g 3QJFZKuv+bmGH3YBSPo1t6NUGAr+JozX5lDihB8JGkBt/NwdYec49a08uL0BbPaAJ7NjuIPG 7Y0Ak7PXZT37yx/Zla9PzLMJFgbelOkaatdzbblMZPDEVZ27l4lGMmV83Lm3YP17sdAyS/Wp mav7WmJUkQ9iuIKzSpdc82i9Mfujl1vbBtwtkHNPPtKuulIFM4ZwrPKjlVdLqTSqD8m9yHEi Y0PuAooq63OpJWF6hvMaiIPBWEAVIaDW9uG0MshLl9DnHnMyrJTfuC33Z9mOGMz7dRBjJd5Y W02xAzYnUuEBOpj+LQv5R8XIFMHFXktqEKvQrXeM2RU+PcZqKOBkTktxBLn3NI5VfA15Jk0c 5V5XcOqo3p2hvrwvXrinrb2pEREnoqmfrkXT3zOq5Y6ryRH8u734lGEF0dILXzoV4PM7XFit oTePoEjmMYIFBDCCBQACAQEwgZEwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGEx GTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTEl MCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQQISAsbzIfg9AV1t33FSCanO XWNfMA0GCWCGSAFlAwQCAwUAoIICQzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0yMzAxMjUxNjQ1MjlaME8GCSqGSIb3DQEJBDFCBEAcLys5e1vL3jKshe/a UmcYxsgI61k6GRiAkhgWjwyROOLqrNM5pIgSOt+EIsepWhL7IfICUg5KCZAa9exFGgjGMGwG CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw gaIGCSsGAQQBgjcQBDGBlDCBkTB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTEZ MBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENBMSUw IwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBAhICxvMh+D0BXW3fcVIJqc5d Y18wgaQGCyqGSIb3DQEJEAILMYGUoIGRMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9y aWRhMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMg Q0ExJTAjBgNVBAMMHEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0ECEgLG8yH4PQFdbd9x Ugmpzl1jXzANBgkqhkiG9w0BAQEFAASCAgBbCfGt9AO3h52xDmbQi4ehEhsoSF1vI65ixauV v2UmPgyUXFJwJj9K8aRV+7lxabBoXFYgFn63dAGnTtG+U27wPgmV2X+xyNPJEAWnFAWm6HBG FSP30ZkDEdOsYBr61R2j2sJkJ+lpUs+wYaT2+oaix1Lg3mqWbIcve/RW3a+FZYAD9ZZUSNKl eScIkQ1BVOPg/kmKqL94TivxCkSIBRy8bgWP/AWgJS7HqqnsyaEfmm/34Y2qqg4f2D6khkFZ dn3JGqhp0udtFofJKRhVIaJaVaZ+ayFV7ha4zIn3BuSBduImaa4XDHfP2s7xqs1g11Szoxbk OG5te+ai38gOsN1p5yI1P7i76qhBn2sqkqpatUELa2UUEzLmppLE/9lsNyLNWJlHgY8yZ/mW bZQDbgLRlZmVvu87kegqPR/n7ESb8jVlRposMchV5GH1xUIUuvYpXku29BN9/VZUk/uoRw5K k+BHaUtDqeBwKcINJ+e5WGcoyIyjLt6GI2xBAf67gkyjXQxK2LFhXFc3auaewmdqFUmIi1iE /WYszmM8Ezj19dqG92N6EBxqZU0DebdwJ4ew0fepC6JuIvdwQyLVS56BzboOxeuvkpvKoBYj bxmXy/7Wudn+Fh40STVLyraAbOim+QOpiuY8PnBhI+jl61iHC2O97saNmqhfVMqdspmXjwAA AAAAAA== --------------ms090009090809040403030506-- From nobody Thu Jan 26 04:04:51 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P2RtZ2F2Vz3bKWh for ; Thu, 26 Jan 2023 04:04:54 +0000 (UTC) (envelope-from 01070185ec3ff177-a3ef6a92-17ae-4b94-819b-c86b90ebb681-000000@eu-central-1.amazonses.com) Received: from b224-8.smtp-out.eu-central-1.amazonses.com (b224-8.smtp-out.eu-central-1.amazonses.com [69.169.224.8]) (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 4P2RtY6Xbnz3Pk0 for ; Thu, 26 Jan 2023 04:04:53 +0000 (UTC) (envelope-from 01070185ec3ff177-a3ef6a92-17ae-4b94-819b-c86b90ebb681-000000@eu-central-1.amazonses.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ez3m2wtglgbm5wj4q3hdyvc7qtjtqmlb; d=cyclaero.com; t=1674705892; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To; bh=jlV5/TIfPy1vhrWrJHEPX1s5s71YpDZEM1tWFQpyxP4=; b=ETPVhFSmthK6uspsHHvf3QtIRrDalcCkPF2IVKiNaCoRLvyIRigc1fHskReSnXSW F6YK91BhjUBnHXhdfAoP1DtTwq3FtuSfpZ7gkEIUSTDcACFZFgAwgYa0PM4dgEoHicQ Xi9fEBGbobV1J8cQaHTh1Cn7G1ki01XfHhILod5qPV37ty6LEGdGue+Fxq7z3XuzRe8 l+YZKDXXCb1P0cNo2KpuFJpe7XAT/rrCnIudbVeCKj5lI/MQ9RDmXZkNbykldOzlpxg a6I0h15v9643M5Wuy11clFkFz4p2GKdKlqfQoVjNU/TFfaXU1+2qjW0RCEvURtErkpe qf6DcFEedg== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=sokbgaaqhfgd6qjht2wmdajpuuanpimv; d=amazonses.com; t=1674705892; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=jlV5/TIfPy1vhrWrJHEPX1s5s71YpDZEM1tWFQpyxP4=; b=b/s4pK456h+J5BMCQDbAP7DD1lnmsP6wPaocdIrHoQd4+P0JRbxG16GtHXx8d2AC XgBnu3f914UIsyODG2O7n759VT4QaVKPNbABiieKLbKBxkwlPUkZO5SUmAIOkamCRlA 2WEU81fNiOeGexJRaWZ9AQ5wHJY3PBc4DaW5TDvY= Content-Type: text/plain; charset=utf-8 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Subject: Re: GPIO inputs on Pis? From: "Dr. Rolf Jansen" In-Reply-To: <1cd552a7-b015-c935-06fc-9f12e1b37daa@denninger.net> Date: Thu, 26 Jan 2023 04:04:51 +0000 Cc: Karl Denninger Content-Transfer-Encoding: quoted-printable Message-ID: <01070185ec3ff177-a3ef6a92-17ae-4b94-819b-c86b90ebb681-000000@eu-central-1.amazonses.com> References: <0b235f83-7cb3-1d14-7c64-aee7c1c0c23d@denninger.net> <01070185e46b1a6e-ee34b885-1215-45c7-ac18-83320c02cac2-000000@eu-central-1.amazonses.com> <01070185e4732fd8-c0bede0b-d9df-4557-a174-cb237fa4bfaf-000000@eu-central-1.amazonses.com> <01070185e534f221-14f362b5-2b96-43f0-b0b0-f496ad9994fe-000000@eu-central-1.amazonses.com> <1cd552a7-b015-c935-06fc-9f12e1b37daa@denninger.net> To: freebsd-arm X-Mailer: Apple Mail (2.3445.104.15) Feedback-ID: 1.eu-central-1.i3TZMOZE/rJo3HQG0qvfyolMxXljeCj2Qj8Jp3rxK3c=:AmazonSES X-SES-Outgoing: 2023.01.26-69.169.224.8 X-Rspamd-Queue-Id: 4P2RtY6Xbnz3Pk0 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:69.169.224.0/23, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N > Am 25.01.2023 um 13:45 schrieb Karl Denninger : >=20 > On 1/24/2023 14:15, Dr. Rolf Jansen wrote: >> Yes, and for this reason, this GPIO event code which was developed by = Christian Kr=C3=A4mer in the course of the GSoC-2018 and has been = submitted in 2020 by Ian Lepore to the freebsd tree is perfect. >>=20 >> Ian tested it with a 10 MHz sqaure wave on an imx6 (ARMv7, 1GHz) and = got an event every 10 =C2=B5s. That means the max. speed without event = losses would be 100 kHz. I did not do exact measurements, however, my = impression is that my RPi4B can do it a tad faster than my BeagleBone = Black. With the RPi4, I needed to improve the debouncing of the encoder = and the buttons, because it saw hundreds of bounces which the BBB = didn=E2=80=99t. However, it may also be, that the internal GPIO circuits = of the BBB have a different damping characteristic. >>=20 >> Anyway for my applications, 100 kHz way faster than what I need. >>=20 >> On my GitHub repository I placed another example on using the GPIO = events for the RPi: >>=20 >> https://github.com/cyclaero/shutdd >>=20 >> See also the respective thread on this mailing list: >>=20 >> https://lists.freebsd.org/archives/freebsd-arm/2022-July/001576.html > So..... just to see if I'm understanding this correctly (pretty sure = I am having read through the test code). >=20 > Presume I have "X" pins configured as inputs and "Y" configured as = outputs. I use the ioctl calls to set the outputs (which works just = fine) and can read current input state (which also works.) >=20 > If I set on the same descriptor (not on the specific pins; it applies = to all input pins on that descriptor as it appears there's no = pin-specific setting in the configuration flags to enable this on a = pin-by-pin basis) the event report config type I want I can then = select() on the descriptor with the usual timeouts (or zero for a poll) = and get a "ready" (much as one would for any other sort of I/O) and, if = I do get a "ready" return on the descriptor a read() on that descriptor = will return zero or more structures of the type I said I configured, = each of which describes either an individual state change on one of = configured input pins that is set up for individual event reporting OR a = structure of the summary of changes for a given pin. >=20 My understanding of what you wrote above sounds correct. However, I = don=E2=80=99t use select(), since I am very comfortable with calling a = blocking read() from a loop in a pthread. The advantage with this is, = that there is almost no time gap in the user land between reading of the = events. Below comes an example You open the respective GPIO bank (the RPI4 got only 1 while the BBB got = 4) for reading. gpio_handle_t gpio0; if ((gpio0 =3D gpio_open(0)) !=3D GPIO_INVALID_HANDLE) { You configure the pins, here for a mechanical rotary encoder having a = push button facility on the axis. The clock and the button changes shall = cause interrupts, while the direction shall be polled.=20 gpio_config_t gcfg =3D {0, {}, 0, = GPIO_PIN_INPUT|GPIO_INTR_EDGE_FALLING}; // Encoder CLOCK gcfg.g_pin =3D 20; gpio_pin_set_flags(gpio0, &gcfg); // Encoder BUTTON gcfg.g_pin =3D 26; gpio_pin_set_flags(gpio0, &gcfg); // Encoder DIRECTION gcfg.g_pin =3D 19; gcfg.g_flags =3D GPIO_PIN_INPUT|GPIO_INTR_NONE; gpio_pin_set_flags(gpio0, &gcfg); Now the event loop: ssize_t n, rc, rs =3D sizeof(struct gpio_event_detail); double t; int c =3D 0; struct gpio_event_detail buffer[64]; do { if ((rc =3D read(gpio0, buffer, sizeof(buffer))) < 0) err(EXIT_FAILURE, "Cannot read from GPIO0"); if (rc%rs !=3D 0) err(EXIT_FAILURE, "%s: read() the odd count of %zd bytes = from GPIO0\n", getprogname(), rc); else { n =3D rc/rs - 1; t =3D nanostamp(buffer[n].gp_time); switch (buffer[n].gp_pin) { case 20: c +=3D (gpio_pin_get(gpio0, 19)) ? +1 : -1; break; case 19: break; case 26: default: break; } printf("%5d %12.9f\tGPIO0.%u \t%u\t%zd\n", c, t, = buffer[n].gp_pin, buffer[n].gp_pinstate, n); } } while (buffer[n].gp_pin !=3D 26); } Basically, that=E2=80=99s it. =20 > I assume given the 16-bit "count" field on the summary return that = counts are "since last returned" and not "since boot" or "since = descriptor was opened and configuration set.=E2=80=9C >=20 > This also presumes that there is some buffer depth on this that, at = some point, may be exceeded so if I "go away" for too long I may miss = things -- particularly if I need detail-level reporting. Yes, and for this reason I like to call blocking reads from within a = relatively tight event loop. > Thus it looks like that its possible for most cases (assuming = resolution of the time stamps is high enough and the driver timing is = accurate enough, plus the code is sparse enough that actually does the = reading) to not just read an optical encoder with this but also (if you = use detail reporting) to read a bi-phase encoder so you can determine = which direction it is moving. The computational resolution is nanoseconds, but of course you won=E2=80=99= t see interrupts in GHz speed - on a RPI4 expect some hundred kHz. I use = the following function for conversion to a double value: static inline double nanostamp(int64_t stamp) { uint64_t ns =3D (1000000000*(stamp & 0xFFFFFFFFu) >> 32); return (int32_t)(stamp >> 32) + ns*1e-9; } > On to check it out; if I missed something here a "heh idiot, no it = actually works like this!" would be appreciated :-) I do poll the direction pin when the clock pin of the encoder cause = interrupts. At least for mechanical encoders this is less cumbersome = because depending on the debouncing circuit you might see pulse trains = for each tick and tack. With respect to the direction it is then hard to = figure out whether it is actually 0 or 1. From nobody Thu Jan 26 17:49:24 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P2pB038SKz3bDkj for ; Thu, 26 Jan 2023 17:49:28 +0000 (UTC) (envelope-from fred@thegalacticzoo.com) Received: from nmtao102.oxsus-vadesecure.net (mta-132a.oxsus-vadesecure.net [135.148.117.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P2p9z0h83z3vvw for ; Thu, 26 Jan 2023 17:49:26 +0000 (UTC) (envelope-from fred@thegalacticzoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=webcom.xion.oxcs.net header.s=mail1 header.b=NRih7D6p; spf=pass (mx1.freebsd.org: domain of fred@thegalacticzoo.com designates 135.148.117.230 as permitted sender) smtp.mailfrom=fred@thegalacticzoo.com; dmarc=pass (policy=quarantine) header.from=thegalacticzoo.com DKIM-Signature: v=1; a=rsa-sha256; bh=vgnCerIwdYabdux1/Vu3uyF1MDqfJlhApL8X3E uvhEY=; c=relaxed/relaxed; d=webcom.xion.oxcs.net; h=from:reply-to: subject:date:to:cc:resent-date:resent-from:resent-to:resent-cc: in-reply-to:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; q=dns/txt; s=mail1; t=1674755366; x=1675360166; b=NRih7D6pvrwtmKxYmIPv4kZKXn/fQlPGruwNehl11 P/FIJ234iOw09xL1K1BfirSZ134JvW2hHafHrp6GdGYxlrzukJSTflJXQP/fGUa65oIBeL2 2W/UInpLGudNAUbObd7t/6CQu1QMGa/Ql1HNOeXEpeVMGua+VC01I7HegMEg7sjcdWr576b 1wb8TBzCYnmiwWtamBCFl0oiFJN7FCHNYsUg7szC7cPRwulL7Bv0S3oATwR7/tUwr7X5lvg ta6BjUAzaNcprK6wonhR89fuWL0FeVxs8XacMXl7GCDc7awU8YKefegYPfa3hi+V0vWRG/I nGNbploW7j3dXSh+A== Received: from proxy-4.proxy.cloudus.ewr.xion.oxcs.net ([76.14.221.149]) by oxsus1nmtao02p.internal.vadesecure.com with ngmta id 91d9d2d8-173ded21b3ca740e; Thu, 26 Jan 2023 17:49:26 +0000 Message-ID: Date: Thu, 26 Jan 2023 09:49:24 -0800 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Content-Language: en-US To: John Rushford , freebsd-arm@freebsd.org From: Fred Finster Subject: sys/uart fdt Here is pointers to the code we should be using Hope this helps, John. FreeBSD, UART and Raspberry Pi 3 B+ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[thegalacticzoo.com,quarantine]; R_DKIM_ALLOW(-0.20)[webcom.xion.oxcs.net:s=mail1]; R_SPF_ALLOW(-0.20)[+ip4:135.148.117.230]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; ASN(0.00)[asn:16276, ipnet:135.148.0.0/17, country:FR]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[135.148.117.230:from]; RCPT_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_SOME(0.00)[]; DKIM_TRACE(0.00)[webcom.xion.oxcs.net:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[135.148.117.230:from] X-Rspamd-Queue-Id: 4P2p9z0h83z3vvw X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N https://blackdot.be/2018/08/freebsd-uart-and-raspberry-pi-3-b/ FreeBSD, UART and Raspberry Pi 3 B+ He also wanted to hook up a GPS input to a serial port 0. Fred If you are reading this because you, like me were lost and frustrated… I feel your pain. But let me try and help! A few weeks ago I added a POE HAT to a Raspberry Pi 3B+ and installed FreeBSD to so I could build a remote access server. I also bough another Raspberry Pi 3B+ to replace by OrangePi Zero + USB uBlox 5 NTP server. Unlike Raspbian it is surprisingly hard to stop FreeBSD’s kernel from grabbing uart0 for it’s console. Lets start with why you are probably here… how do I stop the kernel from doing this? |echo 'hw.fdt.console="NO"' >> /boot/loader.conf.local | Easy right? It took me more than 24 hours to find this. Most of which was one long Saturday. I could not find much (any) documentation on this parameter. So how did I find it? One of the embedded device devs from FreeBSD recommended to remove /chosen/stdout-path from the fdt tree. This did not work. After a few hours of messing around with building kernels without baked in uart support and other dead-ends I went back to looking at the fdt stuff. |/usr/src/sys/gnu/dts/arm/bcm2837-rpi-3-b-plus.dts /usr/src/sys/gnu/dts/arm/bcm2835-rpi.dtsi /usr/src/sys/gnu/dts/arm/bcm2837.dts | These dtsi and dts files are what eventually end up in the fdt…*bcm2837-rpi-3-b-plus.dts*holds the /chosen/stdout-path for the rPI 3B+. -- Fred Finster fred@thegalacticzoo.com +1 971-718-9144 https://GhostBSD-ARM64.blogspot.com https://ghostbsd.org From nobody Sat Jan 28 14:58:40 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P3yJm4s8xz3b2rH for ; Sat, 28 Jan 2023 14:59:20 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P3yJl6bxHz3sb2 for ; Sat, 28 Jan 2023 14:59:19 +0000 (UTC) (envelope-from karl@denninger.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net; dmarc=pass (policy=none) header.from=denninger.net Received: from denninger.net (097-081-026-048.res.spectrum.com [97.81.26.48]) by colo1.denninger.net (Postfix) with ESMTP id 3B0492110C9 for ; Sat, 28 Jan 2023 09:58:43 -0500 (EST) Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id CAAEB1D1E9F for ; Sat, 28 Jan 2023 09:58:42 -0500 (EST) Message-ID: <5b816cb7-5c65-bbc3-ac14-bb3bcf078175@denninger.net> Date: Sat, 28 Jan 2023 09:58:40 -0500 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: GPIO inputs on Pis? Content-Language: en-US To: freebsd-arm@freebsd.org References: <0b235f83-7cb3-1d14-7c64-aee7c1c0c23d@denninger.net> <01070185e46b1a6e-ee34b885-1215-45c7-ac18-83320c02cac2-000000@eu-central-1.amazonses.com> <01070185e4732fd8-c0bede0b-d9df-4557-a174-cb237fa4bfaf-000000@eu-central-1.amazonses.com> <01070185e534f221-14f362b5-2b96-43f0-b0b0-f496ad9994fe-000000@eu-central-1.amazonses.com> <1cd552a7-b015-c935-06fc-9f12e1b37daa@denninger.net> <01070185ec3ff177-a3ef6a92-17ae-4b94-819b-c86b90ebb681-000000@eu-central-1.amazonses.com> From: Karl Denninger In-Reply-To: <01070185ec3ff177-a3ef6a92-17ae-4b94-819b-c86b90ebb681-000000@eu-central-1.amazonses.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms060401080303050203050306" X-Spamd-Result: default: False [-4.13 / 15.00]; SIGNED_SMIME(-2.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[denninger.net,none]; NEURAL_HAM_SHORT(-0.23)[-0.229]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+mx]; ARC_NA(0.00)[]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[karl]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4P3yJl6bxHz3sb2 X-Spamd-Bar: ---- X-ThisMailContainsUnwantedMimeParts: N This is a cryptographically signed message in MIME format. --------------ms060401080303050203050306 Content-Type: multipart/alternative; boundary="------------6X6bDqpDPj0DJmDVneqyOCYF" --------------6X6bDqpDPj0DJmDVneqyOCYF Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/25/2023 23:04, Dr. Rolf Jansen wrote: >> Am 25.01.2023 um 13:45 schrieb Karl Denninger: >> >> On 1/24/2023 14:15, Dr. Rolf Jansen wrote: >>> Yes, and for this reason, this GPIO event code which was developed by Christian Krämer in the course of the GSoC-2018 and has been submitted in 2020 by Ian Lepore to the freebsd tree is perfect. >>> >>> Ian tested it with a 10 MHz sqaure wave on an imx6 (ARMv7, 1GHz) and got an event every 10 µs. That means the max. speed without event losses would be 100 kHz. I did not do exact measurements, however, my impression is that my RPi4B can do it a tad faster than my BeagleBone Black. With the RPi4, I needed to improve the debouncing of the encoder and the buttons, because it saw hundreds of bounces which the BBB didn’t. However, it may also be, that the internal GPIO circuits of the BBB have a different damping characteristic. >>> >>> Anyway for my applications, 100 kHz way faster than what I need. >>> >>> On my GitHub repository I placed another example on using the GPIO events for the RPi: >>> >>> https://github.com/cyclaero/shutdd >>> >>> See also the respective thread on this mailing list: >>> >>> https://lists.freebsd.org/archives/freebsd-arm/2022-July/001576.html >> So..... just to see if I'm understanding this correctly (pretty sure I am having read through the test code). >> >> Presume I have "X" pins configured as inputs and "Y" configured as outputs. I use the ioctl calls to set the outputs (which works just fine) and can read current input state (which also works.) >> >> If I set on the same descriptor (not on the specific pins; it applies to all input pins on that descriptor as it appears there's no pin-specific setting in the configuration flags to enable this on a pin-by-pin basis) the event report config type I want I can then select() on the descriptor with the usual timeouts (or zero for a poll) and get a "ready" (much as one would for any other sort of I/O) and, if I do get a "ready" return on the descriptor a read() on that descriptor will return zero or more structures of the type I said I configured, each of which describes either an individual state change on one of configured input pins that is set up for individual event reporting OR a structure of the summary of changes for a given pin. >> > My understanding of what you wrote above sounds correct. However, I don’t use select(), since I am very comfortable with calling a blocking read() from a loop in a pthread. The advantage with this is, that there is almost no time gap in the user land between reading of the events. Below comes an example It does indeed work "as-expected" from my testing; this is a welcome addition that I did not realize was there (when I originally started working with this stuff it wasn't in the kernel, materially before the ARM code was considered Tier 1.) BTW one warning which might be worthy of at least a note in the man page -- if you enable reporting but do not assign any pins to have interrupts enabled you will get a "ready for read" immediately on a poll or select, but an attempt to read the descriptor comes back with ENXIO. IMHO a select() or poll() should not return a ready state for reads unless it really is ready to be read (it would be ok to return a "ready on error/exception" of course; I haven't checked that.)  The man page is too sparse to know if this is intended behavior or a bug against which perhaps I should file a PR. I also generated a panic in the provided test code on the Pi3 by setting nonblocking and using select.  Unfortunately I do not have a crash dump from it as it occurred on an embedded test board. Thanks. -- Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------6X6bDqpDPj0DJmDVneqyOCYF Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 1/25/2023 23:04, Dr. Rolf Jansen wrote:
Am 25.01.2023 um 13:45 schrieb Karl Denninger <karl@denninger.net>:

On 1/24/2023 14:15, Dr. Rolf Jansen wrote:

Yes, and for this reason, this GPIO event code which was developed by Christian Krämer in the course of the GSoC-2018 and has been submitted in 2020 by Ian Lepore to the freebsd tree is perfect.

Ian tested it with a 10 MHz sqaure wave on an imx6 (ARMv7, 1GHz) and got an event every 10 µs. That means the max. speed without event losses would be 100 kHz. I did not do exact measurements, however, my impression is that my RPi4B can do it a tad faster than my BeagleBone Black. With the RPi4, I needed to improve the debouncing of the encoder and the buttons, because it saw hundreds of bounces which the BBB didn’t. However, it may also be, that the internal GPIO circuits of the BBB have a different damping characteristic.

Anyway for my applications, 100 kHz way faster than what I need.

On my GitHub repository I placed another example on using the GPIO events for the RPi:

https://github.com/cyclaero/shutdd

See also the respective thread on this mailing list:

https://lists.freebsd.org/archives/freebsd-arm/2022-July/001576.html

So..... just to see  if I'm understanding this correctly (pretty sure I am having read through the test code).

Presume I have "X" pins configured as inputs and "Y" configured as outputs.  I use the ioctl calls to set the outputs (which works just fine) and can read current input state (which also works.)

If I set on the same descriptor (not on the specific pins; it applies to all input pins on that descriptor as it appears there's no pin-specific setting in the configuration flags to enable this on a pin-by-pin basis) the event report config type I want I can then select() on the descriptor with the usual timeouts (or zero for a poll) and get a "ready" (much as one would for any other sort of I/O) and, if I do get a "ready" return on the descriptor a read() on that descriptor will return zero or more structures of the type I said I configured, each of which describes either an individual state change on one of configured input pins that is set up for individual event reporting OR a structure of the summary of changes for a given pin.


My understanding of what you wrote above sounds correct. However, I don’t use select(), since I am very comfortable with calling a blocking read() from a loop in a pthread. The advantage with this is, that there is almost no time gap in the user land between reading of the events. Below comes an example

It does indeed work "as-expected" from my testing; this is a welcome addition that I did not realize was there (when I originally started working with this stuff it wasn't in the kernel, materially before the ARM code was considered Tier 1.)

BTW one warning which might be worthy of at least a note in the man page -- if you enable reporting but do not assign any pins to have interrupts enabled you will get a "ready for read" immediately on a poll or select, but an attempt to read the descriptor comes back with ENXIO. 

IMHO a select() or poll() should not return a ready state for reads unless it really is ready to be read (it would be ok to return a "ready on error/exception" of course; I haven't checked that.)  The man page is too sparse to know if this is intended behavior or a bug against which perhaps I should file a PR.

I also generated a panic in the provided test code on the Pi3 by setting nonblocking and using select.  Unfortunately I do not have a crash dump from it as it occurred on an embedded test board.

Thanks.

--
Karl Denninger
karl@denninger.net
The Market Ticker
[S/MIME encrypted email preferred]
--------------6X6bDqpDPj0DJmDVneqyOCYF-- --------------ms060401080303050203050306 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DbowggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBxIwggT6oAMCAQICEgLG8yH4PQFdbd9x Ugmpzl1jXzANBgkqhkiG9w0BAQsFADB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlk YTEZMBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENB MSUwIwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBMB4XDTIyMDYyOTE2MTYz NloXDTI3MDYyODE2MTYzNlowOjELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEX MBUGA1UEAwwOS2FybCBEZW5uaW5nZXIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC AQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvW ZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B 3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTgy+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYI XgVVPgfZZrbJJb5HWOQpvvhILpPCD3xsYJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMi WapsatKm8mxuOOGOEBhAoTVTwUHlMNTg6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMb NQm1mWREQhw3axgGLSntjjnznJr5vsvXSYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZM qa20JLAF1YagutDiMRURU23iWS7bA9tMcXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5 CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1l y+5ZOZbxBAZZMod4y4b4FiRUhRI97r9lCxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY 2BlA7ExM8XShMd9bRPZrNTokPQPUCWCgCdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEE MDAuMCwGCCsGAQUFBzABhiBodHRwOi8vb2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNV HRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYI KwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCGSAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBD bGllbnQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNV HSMEgcIwgb+AFF3AXsKnjdPND5+bxVECGKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQ MA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5 c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lz dGVtcyBMTEMgMjAxNyBDQYITAORIioIQzl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJs QGRlbm5pbmdlci5uZXQwDQYJKoZIhvcNAQELBQADggIBAKquc7cu0xc8FNtAQauZvocDzWQj 7HG9YvMbWnMi+ckhiA3rdW5NwWg0HBhBho1YlnqV+ntCVE2L8ezohHWm+KAdfXgpraL86Vsn 3ywNlZu/3COMpo2ALuHln8YQtH3Y8ebvzKMdlf2b5WB+7mOFIxXIr4AnNOLKCkq5ZhzC6JW6 Jvw3P0csiGa3UrfatYID5NvPgkaQvEgimEjG3psZqwQTL2Wxohvw783PrDt3wS0XeNhvQ61g 3QJFZKuv+bmGH3YBSPo1t6NUGAr+JozX5lDihB8JGkBt/NwdYec49a08uL0BbPaAJ7NjuIPG 7Y0Ak7PXZT37yx/Zla9PzLMJFgbelOkaatdzbblMZPDEVZ27l4lGMmV83Lm3YP17sdAyS/Wp mav7WmJUkQ9iuIKzSpdc82i9Mfujl1vbBtwtkHNPPtKuulIFM4ZwrPKjlVdLqTSqD8m9yHEi Y0PuAooq63OpJWF6hvMaiIPBWEAVIaDW9uG0MshLl9DnHnMyrJTfuC33Z9mOGMz7dRBjJd5Y W02xAzYnUuEBOpj+LQv5R8XIFMHFXktqEKvQrXeM2RU+PcZqKOBkTktxBLn3NI5VfA15Jk0c 5V5XcOqo3p2hvrwvXrinrb2pEREnoqmfrkXT3zOq5Y6ryRH8u734lGEF0dILXzoV4PM7XFit oTePoEjmMYIFBDCCBQACAQEwgZEwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGEx GTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTEl MCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQQISAsbzIfg9AV1t33FSCanO XWNfMA0GCWCGSAFlAwQCAwUAoIICQzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0yMzAxMjgxNDU4NDJaME8GCSqGSIb3DQEJBDFCBEC76ARfKEOzHT/ggGRx G6AREG1CZQacWSih79slavEM/bmgDxR3spKE4YWlWxvCfnjId9jXD7Akm5SyTYzN6C1pMGwG CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw gaIGCSsGAQQBgjcQBDGBlDCBkTB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTEZ MBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENBMSUw IwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBAhICxvMh+D0BXW3fcVIJqc5d Y18wgaQGCyqGSIb3DQEJEAILMYGUoIGRMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9y aWRhMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMg Q0ExJTAjBgNVBAMMHEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0ECEgLG8yH4PQFdbd9x Ugmpzl1jXzANBgkqhkiG9w0BAQEFAASCAgCil3PFMXJD0g70e9ciADKq2+1JSM0qReWI2meJ eTUz+cTr1tvHEHsYsA/qMH0HagIXrED3GtAPs6qMZcxtZoyx4Wq7rFKCLFHoW467bpmV/bay RQTfHGWE7oXgMQaQrn5WTWEC98WKQcmyptMuMzXYRJFH4cErtpC701NuftWXsWFQ3QlIFJdV yoJu8Xp1zu14q9lW+1pEbLcvW0/NCQC9/ly0FOUcw+bAnCaimBE1GEDb+wz9Zs6SANdSHwYu TSUhr5GoYMw0b067uYUuiQsJE7ctSdQW8V0jCkykI3ly6lGaguduTgC4IToGcjS/nMgjjdJR OF0A/tpy/cUg2tWyQjEOfbQlKr1RjmKqqir12dKKRYkPQVdbJbXGdm+qclo/uBcZIEOxmBWx lin6vMhJ34AJ855mZQbAX3aUN/J36TDWOjKcJPMTHKiKmdgpwDMbwmJKD9WtPGRtKQpFRCT/ gjH2id/WTbos+dljn8zcvy2j8B/P3ncAznBAUiOwNiiQM/APPpikOmOhfeSnfSzT5TcZL51u tLJQKFkUb7Aet9x7iMUD2M+ishSVfvmisI1cAO5g7ZYOucql3A1MiDjS1Kxcr4HiiXUaUf8C QUk4JbY2JXD0cdVyP45huiNmQ1XNkFP161cMAkRNW6KEGIkXABeT96B642T9PyWIeAa5nQAA AAAAAA== --------------ms060401080303050203050306--