From owner-freebsd-arm@freebsd.org Sun Sep 13 01:05:23 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E4F8F3E7266 for ; Sun, 13 Sep 2020 01:05:23 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bprrf62dDz4kJQ for ; Sun, 13 Sep 2020 01:05:22 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: by mail-wm1-x333.google.com with SMTP id x23so7521463wmi.3 for ; Sat, 12 Sep 2020 18:05:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=QQrVrADuZHSlT/yTjYbwaKmUTalRhm29r0yvTuGjS5w=; b=ap7VF7aKu5eQGsGW/+SpBS/oLoMEMINKuA/rX5xlYzHFAfD7g5i8t21oUW4G0it2MK KdAD98XPv6a0O1JPo7dQswYdtpp87/qGXUBhmsaiZj9uYaQxddHGMnyoMtjpgvII4qZl xeH+f14AeIeTKg8MICk8gPatue9nlJ1mgIC8jzXMPD0lE9iY/nCnxX6CVwIy+wm9VKNW wzdWngdGDejcjgDlv8o9XJ6GPIDmC02KomJV03sahhcBPyygl9D0wYaZaMH8qWYsdZfk fd9dDxK0neiJ4nswqnNmcO8kxrkEnzZEXgCHhtHZspuyNYt0ae+XFfdZKYeR2F+p3fOD EaFw== X-Gm-Message-State: AOAM530O1A6Nr91gcW3nGgJKPM61i5UXw8PAtPXRTDYW1hfrSE64dthd yWf1A39HVwUeO6IAC/QBMv8= X-Google-Smtp-Source: ABdhPJzETX4921I0pHgFFJ8sJTOww4EFkjeCCXAoJMdpSCdv7WeCiKwR/vbA84fNfiEccRv/q3NYoQ== X-Received: by 2002:a1c:7418:: with SMTP id p24mr8818692wmc.123.1599959121219; Sat, 12 Sep 2020 18:05:21 -0700 (PDT) Received: from localhost.localdomain (x2e726c73.dyn.telefonica.de. [46.114.108.115]) by smtp.googlemail.com with ESMTPSA id x10sm12807370wmi.37.2020.09.12.18.05.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 12 Sep 2020 18:05:20 -0700 (PDT) From: Klaus Cucinauomo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.26\)) Subject: Re: Attempting to install on RPi4B w/ UEFI, having some problems Date: Sun, 13 Sep 2020 03:05:18 +0200 References: <20200910201146.GA99827@fuz.su> <0E3AD53C-AA47-491B-B1C3-931C559CDC10@yahoo.com> <20200911114214.GA56507@fuz.su> <9E14D44F-2F16-486E-ACFB-EC189A345D5B@yahoo.com> To: Mark Millard , freebsd-arm@freebsd.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3654.0.3.2.26) X-Rspamd-Queue-Id: 4Bprrf62dDz4kJQ X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.46 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[googlemail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[googlemail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine]; NEURAL_HAM_SHORT(-0.90)[-0.897]; FREEMAIL_TO(0.00)[yahoo.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[googlemail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[googlemail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.08)[-1.082]; R_DKIM_ALLOW(-0.20)[googlemail.com:s=20161025]; RECEIVED_SPAMHAUS_PBL(0.00)[46.114.108.115:received]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.985]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::333:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2020 01:05:24 -0000 >=20 > M.Millard: >> .if ${FLAVOR} =3D=3D rpi4 > Von: Klaus > Betreff: Aw: Attempting to install on RPi4B w/ UEFI, having some = problems >=20 > While in this case you would be right if you tell me, that the = following is just a =E2=80=9Eguess=E2=80=9C : > I guess you can completely forget and ignore the edkII in sysutils.. = while I=E2=80=99m only guessing(guessing is now my favorite term ;-) : > It=E2=80=99s probably just a bulk-import of edkII without any = intention to target and support RPI4=E2=80=A6 > I did NEVER guess in the Wiki(only I do this one guess here and only = once) :-) >=20 Hmmm, quoting myself..hmm, before goin to have a sleep I wanted to know = how good(or bad) I am in guessing (what I normally never do) :-) .... So, hmmm, 1 wrong guess(the port in fact targets RPI4(&3) !) =E2=80=A6( = and 1 right guess) = https://github.com/freebsd/freebsd-ports/blob/de18ba58f56406625c04bcfc3a67= 7fc969a32210/sysutils/edk2/Makefile I like the idea to support RPI4 in sysutils/edkII, nothing wrong with = that idea .. On the other side Mark Millard is right : <<... But pftf/RPi4 is no longer strictly based on just edk2 =E2=80=A6..>>= And there are some other things to pay attention to in = rpi4-uefi-dev(-files)... The right =E2=80=9Eguess": (for now no publicly or communicated = intention to support RPI4-uefi-dev by any developer in FreeBSD=E2=80=A6)= .. ( it=E2=80=99s unsupported and lacks many functionalities=E2=80=A6 = specially when compared to u-boot/fdt) : > Am 10.09.2020 um 23:03 schrieb Greg V : >=20 > I wanted to do the genet one but kinda don't have the time/motivation = right now. ... On the other side it would be quite unfair to remove the Wiki-entry of = rpi4-uefi-dev because=20 Greg did a very good job and the Wiki-article is very popular(because of = the device itself), I even receive private support-request-emails sometimes because of the = article... So I will leave the Wiki-entry untouched and the sysutils - maintainer = is of course invited to tell the Wiki=20 something of the intention of the edkII-port and to where FreeBSD wants = to go with RPI4-Uefi . Regards kls From owner-freebsd-arm@freebsd.org Sun Sep 13 05:06:39 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 206733ECE8E for ; Sun, 13 Sep 2020 05:06:39 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BpyC172Blz3SWc; Sun, 13 Sep 2020 05:06:37 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id 08D56fTk016782 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 12 Sep 2020 22:06:42 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 08D56fMR016780; Sat, 12 Sep 2020 22:06:41 -0700 (PDT) (envelope-from fbsd) Date: Sat, 12 Sep 2020 22:06:39 -0700 From: bob prohaska To: Andriy Gapon Cc: "Bjoern A. Zeeb" , freebsd-arm@freebsd.org, bob prohaska Subject: Re: MMCCAM - Re: onboard wireless on rpi4 Message-ID: <20200913050639.GA16755@www.zefox.net> References: <75E08DC2-D229-45AA-85AE-CCF06FD0B490@kronometrix.org> <09959D86-E3E3-43E9-8134-C2FC73343DBA@lists.zabbadoz.net> <507782579.41.1599484468967@localhost> <20200907152118.GA89696@www.zefox.net> <40D76B81-934B-43A4-B269-E075D2F4B4CD@lists.zabbadoz.net> <98fb91a8-00e3-4b5c-3b0f-efa2c51388bc@FreeBSD.org> <20200910162452.GA5528@www.zefox.net> <008036a3-bdbf-3ee9-ca21-d445c0867921@FreeBSD.org> <20200910190723.GA5825@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200910190723.GA5825@www.zefox.net> X-Rspamd-Queue-Id: 4BpyC172Blz3SWc X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [1.55 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.02)[-0.025]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(0.05)[0.046]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.37)[-0.367]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm]; MID_RHS_WWW(0.50)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2020 05:06:39 -0000 On Thu, Sep 10, 2020 at 12:07:23PM -0700, bob prohaska wrote: > On Thu, Sep 10, 2020 at 09:41:35PM +0300, Andriy Gapon wrote: > > On 10/09/2020 19:24, bob prohaska wrote: > > > On Tue, Sep 08, 2020 at 09:59:36AM +0300, Andriy Gapon wrote: > > >> > > >> Bob, I noticed this: > > >> (sdda0:sdhci_slot0:0:0:0): Partition 0 -> 8265462 > > >> > > >> Perhaps r365445 might be of some help. > > >> > > > > > > Indeed, moving up to r365459 results in a kernel that boots > > > to multi-user. There does seems to be a lot of chatter about FWIW, FreeBSD 13.0-CURRENT (GENERIC-MMCCAM) #0 r365615: Sat Sep 12 18:49:16 PDT 2020 seems to compile and boot without trouble on a Pi2. bob prohaska From owner-freebsd-arm@freebsd.org Sun Sep 13 12:04:03 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B1CC63D7926 for ; Sun, 13 Sep 2020 12:04:03 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bq7Sf5SXMz45nS for ; Sun, 13 Sep 2020 12:04:02 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id DF4513AF for ; Sun, 13 Sep 2020 08:04:00 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sun, 13 Sep 2020 08:04:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=mEZ6oZs0tWrZf50WlhTXPh0CiRp 8rINAcLs1OqxpvAE=; b=l6qt1973siCwfCyEWXgTdRsY/Hlxq8l1Lti93C3eSV5 iOaCgs5ygu88WSCBFUuzUMDDdHudHyCCqXCB2NjQ1hi1Af8X8/IdvvNukJKCFA+3 HMHPB94+XMByIsa6DkG2LwSOVXeTN8f2Q/6JY9i8Vfcn/+IOJc2jHgQfLH9CbBuX AP/AX0gHVGg1jt02UWkKm37yv/uvBNhEB9XyiW8DG11FDjog0bE1IivUiPsj2w/N GJQyyls7cMiN6CeiE34Y+2RERvc+5CCjar1S2eCgmRHpsyRQwHza+a5lfCBx0Guf 7SnG98V+fEqYL0U4ydeAgqndYG4RZHDvf6O0/gkgLNA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=mEZ6oZ s0tWrZf50WlhTXPh0CiRp8rINAcLs1OqxpvAE=; b=YRBENa0Veyls48wtiHfvFa ciE5lPkZCEJ1BXCcE2UeuJVngj7dLkIPsTpIJSkQpssEU+mdD8Ey8+y31Wx8MASJ XeK1K6eFkMUk41om/xS0fjshzDjrpOfJnPJ8BnuC9frmhgSxcjTnpihXd5yfj+I5 syY12MUlr6pJBEgUWO/mQNq1TjeAs5wzhOwv88/aXXU0t/Enr3TJDo6eziZkW9zz 01dmIlBbqw4y6bkfdswxLpyK4aj3Sf3H4cpNCmEusP4DDOh8cQfpGEVPLooYiyq3 SHp5Zh/A1pQcXigtz6UgD/YO68KHtIZCD5rJw4dH35fY6JeuHsFzMmBsgkb+Y1Eg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudeifedggeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesghdtre ertddtjeenucfhrhhomhepthgvtghhqdhlihhsthhsuceothgvtghhqdhlihhsthhsseii hiigshhtrdhnvghtqeenucggtffrrghtthgvrhhnpedtteelkeeuvedthfeuleeiffeivd dvffdtleduteekffevueffledtledvveegueenucfkphepkedvrdejtddrledurdelleen ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehtvggthh dqlhhishhtshesiiihgihsthdrnhgvth X-ME-Proxy: Received: from bastion.zyxst.net (bastion.zyxst.net [82.70.91.99]) by mail.messagingengine.com (Postfix) with ESMTPA id 0B5753064674 for ; Sun, 13 Sep 2020 08:03:59 -0400 (EDT) Date: Sun, 13 Sep 2020 13:03:31 +0100 From: tech-lists To: freebsd-arm@freebsd.org Subject: Re: onboard wireless on rpi4 Message-ID: <20200913120331.GH91422@bastion.zyxst.net> Mail-Followup-To: freebsd-arm@freebsd.org References: <20200904134619.GB80905@bastion.zyxst.net> <69934262-D9D3-4986-849D-9E8221D1E387@kronometrix.org> <1677459627.55.1599232125847@localhost> <75E08DC2-D229-45AA-85AE-CCF06FD0B490@kronometrix.org> <09959D86-E3E3-43E9-8134-C2FC73343DBA@lists.zabbadoz.net> <20200905181220.GG80905@bastion.zyxst.net> <9C0C5FEB-2620-49C2-8501-190237644884@googlemail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cfJ13FhsvNR/yOpm" Content-Disposition: inline In-Reply-To: <9C0C5FEB-2620-49C2-8501-190237644884@googlemail.com> X-Rspamd-Queue-Id: 4Bq7Sf5SXMz45nS X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm3 header.b=l6qt1973; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=YRBENa0V; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 64.147.123.20 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-5.19 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm3,messagingengine.com:s=fm3]; NEURAL_HAM_MEDIUM(-1.04)[-1.043]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[64.147.123.20:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.20]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.99)[-0.992]; RCVD_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[zyxst.net]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-0.45)[-0.450]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:11403, ipnet:64.147.123.0/24, country:US]; MAILMAN_DEST(0.00)[freebsd-arm]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.20:from] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2020 12:04:03 -0000 --cfJ13FhsvNR/yOpm Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sat, Sep 05, 2020 at 09:17:16PM +0200, Klaus Cucinauomo wrote: > > >> Am 05.09.2020 um 20:12 schrieb tech-lists : >> >> ...Sure, it'll be the next thing i build ... > >> Have to admit i've never built MMCCAM kernel before for rpi 1,2b+ or 3b+. >> What's significant about it? > >Thanks that you=E2=80=99re willing to step into tests ( a very important t= hing to save the devs some (testing) time >And give feedback on boards/machines that devs don=E2=80=99t own)! GENERIC-MMCCAM has this: nodevice mmcsd so, if it installs, I won't be able to reboot, because the system is on an = sd card? So, is GENERIC-MMCCAM meant to be used with a bootable usb disk? is this correct? --=20 J. --cfJ13FhsvNR/yOpm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAl9eCqUACgkQs8o7QhFz NAWehQ/8CBzFaxJ0wpESoB5dgV+rdrFHQH/0HiRgIP5jQxqcHF0OlK9xlox0cLRz 6erSQUwhFJJ+37mfKaCvKu6KQSFioi/ZvsCHcwiJDLcp7khC1uqky0vTe8lqdO6f GDD03aB2LzWAaI358x9O9MrYm9Pxb3MI75+pVV63setGHqOyWaLDFWHdZItAyfsH GIwKjtFqkZ3vphXB2wx6jh7qakFc8iFqf1yLneAc1N0Us1j6YycyxEH09mnQy2Nb FpDV7UgHWXQ+Ml/7M/RuVqnq8kw4J9gdtVJ7KneRMcvU4Ag72UXDi25rLS1NnaYu C2/qnIYcV/m44pEt0gJCxGZliUKg2tUZN1KKbNWxqUGyVdjPHvapxsvQ/hAX8wvH 0o3ucXXbH80xI1LiFLTon1kiErqUBTa6wdkZOMhgjQDvIFo73KRG/dv+sEBYqndn Z28TIJYhbWlxzixOxShsjJJyOMvp4DnqeOzGhM9NySC+UYR4MppBQT8qVrCeUBIb 8xtvW3C6UwwRNpwBFAkdzoLez+3OsXQJDrlxwTS65jcGbZPHHJLlvrzd6WQBpkAd HYG5GDS3W1Bj6KGgunNO4ONEVlpytmGuN/3iT86KM2Ei18iU241/FUMs3dnodvbl faEdTODmvLgFYqHnK5EPQLQ55nKjwKsCyP1rmxUxRizfqd1K4jo= =D7XD -----END PGP SIGNATURE----- --cfJ13FhsvNR/yOpm-- From owner-freebsd-arm@freebsd.org Sun Sep 13 14:35:13 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AF9893DC061 for ; Sun, 13 Sep 2020 14:35:13 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BqBq45d2fz4Ggd for ; Sun, 13 Sep 2020 14:35:12 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: by mail-wm1-x32b.google.com with SMTP id k18so8772903wmj.5 for ; Sun, 13 Sep 2020 07:35:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=namkVV89r0Mj6D8VhrdPgJ099olwQN4u4kpMz/s6KJc=; b=mGdGLfxtiTKR7K91Wd0PqI6DIYKVv9a2wWqv8HrJUP0Bw79FLaIvhn3vpa9ZA4cJeO V5u2e7cdDEHMa71YcjtGIiLZCTvw58/SGgwkRPectH7JjmAAIeFoThUJe11MoW11KQbY gtfqx6YvR7dFjoyq88/OpNLMyUKZbnwwz/OYw9SCZpY1Hv+q+KjE8aBX6eIs1bK6ndsc iF4Y7/ekTNZV8uHqvRa8g9DKnd4sxG3ReCwue9mROHGK3+zE+E/hfPS58pnkfXiW9gtQ F0DPregUlF7Ub/dRobxK2RSGHaLF6UhG8iGkPoqMR5kj0Tyry4/7+tUGpXmMqXuMZR2V M1Ww== X-Gm-Message-State: AOAM530Wz/q35VL3YB3a9UicEtVTRnq4up5H4HP2FMRpLvXDDTZQ6x3e TmO/JQTLjQpOX9Dcyc86rryOkyMXNdk= X-Google-Smtp-Source: ABdhPJxMkV+SdTBiJs0I1HdCjzeD27SQk/qCa1WbJarg5g7GD39TSUrUINkfsxUozuYxfXUJDm5+vQ== X-Received: by 2002:a7b:c318:: with SMTP id k24mr11178097wmj.150.1600007711177; Sun, 13 Sep 2020 07:35:11 -0700 (PDT) Received: from localhost.localdomain (x2e7269d4.dyn.telefonica.de. [46.114.105.212]) by smtp.googlemail.com with ESMTPSA id f6sm15733607wro.5.2020.09.13.07.35.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Sep 2020 07:35:10 -0700 (PDT) From: Klaus Cucinauomo Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.26\)) Subject: Re: onboard wireless on rpi4 Date: Sun, 13 Sep 2020 16:35:08 +0200 References: <20200904134619.GB80905@bastion.zyxst.net> <69934262-D9D3-4986-849D-9E8221D1E387@kronometrix.org> <1677459627.55.1599232125847@localhost> <75E08DC2-D229-45AA-85AE-CCF06FD0B490@kronometrix.org> <09959D86-E3E3-43E9-8134-C2FC73343DBA@lists.zabbadoz.net> <20200905181220.GG80905@bastion.zyxst.net> <9C0C5FEB-2620-49C2-8501-190237644884@googlemail.com> <20200913120331.GH91422@bastion.zyxst.net> To: tech-lists , freebsd-arm@freebsd.org In-Reply-To: <20200913120331.GH91422@bastion.zyxst.net> Message-Id: <52AF5A61-4F24-44AC-9A48-3F57E552E3F7@googlemail.com> X-Mailer: Apple Mail (2.3654.0.3.2.26) X-Rspamd-Queue-Id: 4BqBq45d2fz4Ggd X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.41 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[googlemail.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[googlemail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine]; NEURAL_HAM_SHORT(-0.83)[-0.831]; RECEIVED_SPAMHAUS_PBL(0.00)[46.114.105.212:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[googlemail.com]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.06)[-1.062]; R_DKIM_ALLOW(-0.20)[googlemail.com:s=20161025]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[googlemail.com:dkim]; NEURAL_HAM_LONG(-1.02)[-1.017]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32b:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2020 14:35:13 -0000 Exactly the opposite of what you think: FreeBSD has a secret language : When those guys say NO( we will not trigger boot issue by cam probe = fail)=20 they want to say YES(we will leave the device untouched by cam and let = it boot). :-)=20 kls > Am 13.09.2020 um 14:03 schrieb tech-lists : >=20 >=20 > GENERIC-MMCCAM has this: >=20 > nodevice mmcsd >=20 > so, if it installs, I won't be able to reboot, because the system is = on an sd > card? So, is GENERIC-MMCCAM meant to be used with a bootable usb disk? >=20 > is this correct? > --=20 > J. From owner-freebsd-arm@freebsd.org Sun Sep 13 17:25:49 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8EA9B3E1B84 for ; Sun, 13 Sep 2020 17:25:49 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound5a.ore.mailhop.org (outbound5a.ore.mailhop.org [44.233.67.66]) (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 4BqGbx0YWQz4R8R for ; Sun, 13 Sep 2020 17:25:48 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1600017941; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=knn5zd9BBaT0i9zgGpMAYBPq8zUj4bxr9YbWNd6rS362hvMbFfjPJN1wgrM0wMZ15oyXC1kYWOq7W wtmMBa2kTCzldopcaj1RHjIgjGHYjCwlgDlUS+6MW3CApNbpjrubcTbNJW5dTRBeuzh0M7Swgoh6GU 4qRg6aeMfks++E9roPq45YSed0KRHcqTcyKDMhq84E1Mnw8b0F7Z/YNE5hEDaleJ8uvO3JHam6mYC/ qcgsHlqPdYSk51Jiq7lVGojKnOp7kbl3Iinl1I9X3DmrR+ur2Wb9J77JW2KrOk//LrOQvbiVQqoD0z VxgEJw9X+qMSoV8MllnqQCkdo5A7jPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:dkim-signature:from; bh=ttl4cQl3lmywBQ9YcnuIZcvcqOaUxWpSzTjt7Wfrzpg=; b=RuAMnYkJ3AObi3jBgbTJPE5+QJ1IBJqzAU5vO7RD8yXP5Ro1hMfuWW5y7K8hVdILL6On8IhMG3G0G Cz+T17XVX39g7bOhVSXm8E0wN3OpvLHFPsT7KFUP8/T5w0QRuBo0ws/w8DI6hV/QkDEeY6D1vWLv/R 1kc8UXtAoPIo60xAQw9VkKm7Y64WhetJWtr056/h2QCCeam2iSIKA48VfKrtDHiCFML3T4jZ5ryWuC Bt3D2Fn24cMM5voPsWGbVOibQau5qAjYhPWlHiGBWqPkhgZ/yI9VjeskRqaC4fVHM8qD5Uxjfpkz1c DzCY6xxrcB33K1h4ZsQwnzphTxaS5+g== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:from; bh=ttl4cQl3lmywBQ9YcnuIZcvcqOaUxWpSzTjt7Wfrzpg=; b=FRHkovmOic9LF0OJhjVfqWtr5PtYWNvu+j89W0JgY68Mc4iANrm/c9JCbG6w8X2BtNtn+C9YijKws b5GZR72+Wvzzc+cy3HGRc65vB4+HZjbZIjDZ07IuzWMIRlCU4stTcHHPf2ksA4dVtvlIhLFUH0Z5C4 KKfEzCq1pAOVp+Fgd1l6BkX9VOijpNO/2iNKbDcJiiEvmHJo95ZYulRF5bx+W0ORZsjC/cFn/3RTrX 87CNzPypxeA6gIRc2rrfP/L9j/e7SISmsNgYFXk8cpQuTszqiiQY7loeJBFjb0LSoVZgnF+WGotR9U yyvi95xXwsKlfIhOj/qSxdTG4xtlVEw== X-MHO-RoutePath: aGlwcGll X-MHO-User: 24c2d3e7-f5e6-11ea-8b38-614106969e8d X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 24c2d3e7-f5e6-11ea-8b38-614106969e8d; Sun, 13 Sep 2020 17:25:40 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 08DHPdBR089209; Sun, 13 Sep 2020 11:25:39 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <69c01bd0488bd66dfae332664932057a0f1199e1.camel@freebsd.org> Subject: Re: onboard wireless on rpi4 From: Ian Lepore To: tech-lists , freebsd-arm@freebsd.org Date: Sun, 13 Sep 2020 11:25:39 -0600 In-Reply-To: <20200913120331.GH91422@bastion.zyxst.net> References: <20200904134619.GB80905@bastion.zyxst.net> <69934262-D9D3-4986-849D-9E8221D1E387@kronometrix.org> <1677459627.55.1599232125847@localhost> <75E08DC2-D229-45AA-85AE-CCF06FD0B490@kronometrix.org> <09959D86-E3E3-43E9-8134-C2FC73343DBA@lists.zabbadoz.net> <20200905181220.GG80905@bastion.zyxst.net> <9C0C5FEB-2620-49C2-8501-190237644884@googlemail.com> <20200913120331.GH91422@bastion.zyxst.net> Content-Type: text/plain; charset="iso-8859-7" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4BqGbx0YWQz4R8R X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:16509, ipnet:44.224.0.0/11, country:US] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2020 17:25:49 -0000 On Sun, 2020-09-13 at 13:03 +0100, tech-lists wrote: > Hi, > > On Sat, Sep 05, 2020 at 09:17:16PM +0200, Klaus Cucinauomo wrote: > > > > > > > Am 05.09.2020 um 20:12 schrieb tech-lists : > > > > > > ...Sure, it'll be the next thing i build ... > > > Have to admit i've never built MMCCAM kernel before for rpi 1,2b+ or 3b+. > > > What's significant about it? > > > > Thanks that you�re willing to step into tests ( a very important thing to save the devs some (testing) time > > And give feedback on boards/machines that devs don�t own)! > > GENERIC-MMCCAM has this: > > nodevice mmcsd > > so, if it installs, I won't be able to reboot, because the system is on an sd > card? So, is GENERIC-MMCCAM meant to be used with a bootable usb disk? > > is this correct? mmcsd is the old non-CAM sdcard driver. If you're using the MMCCAM kernel it uses the new CAM-based sdcard driver and the old one is removed from the kernel. It's a bit non-intuitive, but saying "options MMCAM" in the config is equivelent to also saying "device mmccam", and in sys/conf/files you'll see that there are a variety of cam-based mmc and sdcard driver pieces that are conditionally compiled based on 'mmccam'. -- Ian From owner-freebsd-arm@freebsd.org Sat Sep 19 03:41:22 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E56063F90F3 for ; Sat, 19 Sep 2020 03:41:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-8.consmr.mail.gq1.yahoo.com (sonic308-8.consmr.mail.gq1.yahoo.com [98.137.68.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Btc1s4cCrz4X5W for ; Sat, 19 Sep 2020 03:41:21 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: CkGtj5QVM1lqw5jDY6YJAZPofr5v0v7IMO.Eo2sSwggZ_uqpDqxEOWM3qHSpKII myL2AaBoW1b.byceaFz565abKcJBs2vB.zn9bXh0lfhJv7gxHC3.m9._ezy6hFPIteqdM.LvgGSU 3F8Xv15uufWiDReRmk_1AmeqWCbh1bAOMSzn1I0ICUI61B6BvGarswzDJmIfO0WBK3KBvymRBXAt Gqur4mHScfpQosN5X1trxFa2WHs25v_37gCLqcoYnzpdiz9_NNbicIo89snkCS8DjFyfvf6x.fcR Y1zHnT8bpSpD5SldRwymN904PoRjKzaWXkButmZhTO0VUsgcZTWUWQjDoFdjE9y.LE30v4iuu4uj QwdPa7qtBOtr5qJ3L.W.dAWqA6hBaBWy1H9K0xbDx2T0TSk2Aka3W.fiu4kg9x1EhRRdsgAhgaPG Qb3diYZpwwd2mPmV0he8zYAfXKndrzbpVpiw1AOS1QnX4zNFCu6maP5NHh_M0HnosziI_I6H4JXv xccRiwySv4QEzW9UbdwBE4Z3J5v_fplgGFvi8CjxVXhWdXWFU.gHrOkkq7R_8IxTz2YHwvsofs1F .Im_u7X9dg_yjQpsvdk3gRzb.9Utu6W0Bsqr9uQJ.vmFDs.muKWUEax0AKIUF3BIRPfqnbWD1VwH qYniIiCunPwpp.3Y6tXoYuzn3iMKj_mBfoRYTRcwtxuqDdLGx7oj3rYY2nDJTBcOO32uLd6QCl7g mzVwHTxjUmDr_JWmh9tK6vcBXbM41fr5PNu3dXHPTofSExdJaC6ppW0ZDerGrOqASMeWGXcTTump KLAbjz.BxISlYmfgZryblE2RnRGZwSDI68gKCVBALm3wRV2_yxNpP2vxFESIGX.IRDEZPzByW6Sx luOLUp7O7xSZTQ3B6w_xb6D3lQpoMlE2WUZLgsskKAV5.IMtBTCtazxZNGuZ9AcOCmmPT7PBO5QL njtYJuNr9tfk3QBDldixmZFBGpydSU_xR_.Rhd4NzS.G.xhP4hBYxo5jTk_Waeyz7ry28wwE60sB mNqNi5RME88j7mTG.5iIwu9BBm.y4kYuI.hi1OHikdE1.7t18zXxipGv8XGGs_s14I.lCd88sYy5 5zXj29zeDUoRFwOVjIOgu2JaCcSxBGGcjMjfsXztxVEHuGBw2YJJXwhr2REDQnpXGCE5Fjlx8R.z _K4ReJ1LCor3GE5y6evKB1zOO6ZOZRKMTi_S7W693xi_VVvWz2UrnItOyHIp0ETEhi6eOao28LdD dYUrqvcfUWr.8vnOuz_t5J1qGG1gyOH6bnQklu5e4HsigIQO3dvKb17PUN1qeTciKakYL7dg0b9g CNJwDid.Uys7CZzkfLqq3ouXTqVCb81QCwG55e24PX7zvW0gxFg.NjnUKPPb9YCGvseISRbIF6sY xLUcj9TrZKZmtnkbjX5zwfLSaHUuXHZkCHPVctcoWcg6D0XzURz7V3fbE5D2F_KzDjHRed1ej0EI GuRqHtRE6pc8o5Ff_fBI6zTAeVoG2u9.DJDj2TUL3OX6HKipFsaHFUI_RvW0mQL7HTrnkQxqLls0 TbGBY_yWAKtyGvw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Sat, 19 Sep 2020 03:41:19 +0000 Received: by smtp420.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b42748159b4324e5795b5165d20adb1f; Sat, 19 Sep 2020 03:41:14 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Comment #135 for bugzilla 237666 : a USB3-handling problem with a investigatory fix for a cortex-a72 context Message-Id: <6E618C3D-12DF-429E-A249-5BAB90FC6B15@yahoo.com> Date: Fri, 18 Sep 2020 20:41:14 -0700 To: freebsd-arm X-Mailer: Apple Mail (2.3608.120.23.2.1) References: <6E618C3D-12DF-429E-A249-5BAB90FC6B15.ref@yahoo.com> X-Rspamd-Queue-Id: 4Btc1s4cCrz4X5W X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.46 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.96)[-0.959]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.980]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.02)[-1.016]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.32:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.32:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2020 03:41:23 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237666 is about USB3 problems that folks have been having for over a year. Bjoern A. Zeeb comment #125 that looked like something I'd seen on a cortex-a72 when I tried a kernel that had been built with -mcpu=cortex-a72 : an indefinite looping that involved "Resetting controller" for xhci0. (This prevented booting from the USB3 device.) Well, I got the A72 to boot and comment #135 indicates how but I'll paste the information below. All that was involved was adding examples of "dsb st" and one "dsb ld". Comment 135's content: A cortex-a72 success! (In the form of investigatory code, not code to check-in as is.) Just by adding some "dsb st" commands and a "dsb ld" command in places in the xhci code (just for __arach64__), I've gotten the cortext-A72 to boot from the USB3 SSD via a -mcpu=cortex-a72 based kernel build. No more indefinitely repeating "Resetting controller" problem. I do not claim the additions are the minimal ones. I know one place is required for sure: the last one added enabled the boot (given the others were already present). Prior to that I still had the indefinitely repeating "Resetting controller" problem. There could be more places that should have dsb st or dsb ld for overall correctness. This evidence may suggest somewhat analogous problems for other platforms than aarch64 that are seeing problems. For the aarch64 context, the evidence is (the changes are) as follows. The first "dsb st" textually is the last one I added. # svnlite diff /usr/src/sys/dev/usb/controller/xhci.c Index: /usr/src/sys/dev/usb/controller/xhci.c =================================================================== --- /usr/src/sys/dev/usb/controller/xhci.c (revision 363590) +++ /usr/src/sys/dev/usb/controller/xhci.c (working copy) @@ -431,6 +431,9 @@ phwr->hwr_ring_seg[0].qwEvrsTablePtr = htole64(addr); phwr->hwr_ring_seg[0].dwEvrsTableSize = htole32(XHCI_MAX_EVENTS); +#ifdef __aarch64__ +__asm __volatile("dsb st" : : : "memory"); +#endif DPRINTF("ERDP(0)=0x%016llx\n", (unsigned long long)addr); @@ -1098,6 +1101,9 @@ while (1) { +#ifdef __aarch64__ +__asm __volatile("dsb ld" : : : "memory"); +#endif temp = le32toh(phwr->hwr_events[i].dwTrb3); k = (temp & XHCI_TRB_3_CYCLE_BIT) ? 1 : 0; @@ -1107,6 +1113,9 @@ event = XHCI_TRB_3_TYPE_GET(temp); +#ifdef __aarch64__ +__asm __volatile("dsb ld" : : : "memory"); +#endif DPRINTFN(10, "event[%u] = %u (0x%016llx 0x%08lx 0x%08lx)\n", i, event, (long long)le64toh(phwr->hwr_events[i].qwTrb0), (long)le32toh(phwr->hwr_events[i].dwTrb2), @@ -1239,6 +1248,9 @@ sc->sc_command_idx = i; sc->sc_command_ccs = j; +#ifdef __aarch64__ +__asm __volatile("dsb st" : : : "memory"); +#endif XWRITE4(sc, door, XHCI_DOORBELL(0), 0); err = cv_timedwait(&sc->sc_cmd_cv, &sc->sc_bus.bus_mtx, @@ -2855,6 +2867,9 @@ index = xfer->xroot->udev->controller_slot_id; if (xfer->xroot->udev->flags.self_suspended == 0) { +#ifdef __aarch64__ +__asm __volatile("dsb st" : : : "memory"); +#endif XWRITE4(sc, door, XHCI_DOORBELL(index), epno | XHCI_DB_SID_SET(xfer->stream_id)); } @@ -4180,6 +4195,9 @@ for (n = 1; n != XHCI_MAX_ENDPOINTS; n++) { for (p = 0; p != XHCI_MAX_STREAMS; p++) { +#ifdef __aarch64__ +__asm __volatile("dsb st" : : : "memory"); +#endif XWRITE4(sc, door, XHCI_DOORBELL(index), n | XHCI_DB_SID_SET(p)); } I'm clearly just "evidence hacking" here. I've no clue what a good design for allowing aarch64 build to supply having any of those "dsb st"s or the "dsb ld". Hopefully someone that knows what they are doing can figure out if any of the other examples on other platforms are analogous --and ,if they are, provide some hook for platform to contribute such code to the xhci code. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Sep 19 08:09:33 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DAE553FE1CA for ; Sat, 19 Sep 2020 08:09:33 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 4BtjzJ6WL3z4kSR for ; Sat, 19 Sep 2020 08:09:32 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [178.17.145.105]) (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 mail.turbocat.net (Postfix) with ESMTPSA id 9416D26010A; Sat, 19 Sep 2020 10:09:25 +0200 (CEST) Subject: Re: Comment #135 for bugzilla 237666 : a USB3-handling problem with a investigatory fix for a cortex-a72 context To: Mark Millard , freebsd-arm References: <6E618C3D-12DF-429E-A249-5BAB90FC6B15.ref@yahoo.com> <6E618C3D-12DF-429E-A249-5BAB90FC6B15@yahoo.com> From: Hans Petter Selasky Message-ID: <866bd652-5a8b-7500-b1e0-7528c035048b@selasky.org> Date: Sat, 19 Sep 2020 10:08:54 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <6E618C3D-12DF-429E-A249-5BAB90FC6B15@yahoo.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BtjzJ6WL3z4kSR X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-2.38 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; NEURAL_HAM_LONG(-1.01)[-1.014]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.11)[-0.110]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-0.96)[-0.959]; FREEMAIL_TO(0.00)[yahoo.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2020 08:09:33 -0000 On 2020-09-19 05:41, Mark Millard via freebsd-arm wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237666 is about USB3 > problems that folks have been having for over a year. Bjoern A. Zeeb > comment #125 that looked like something I'd seen on a cortex-a72 when > I tried a kernel that had been built with -mcpu=cortex-a72 : an > indefinite looping that involved "Resetting controller" for xhci0. > (This prevented booting from the USB3 device.) > > Well, I got the A72 to boot and comment #135 indicates how but I'll > paste the information below. All that was involved was adding > examples of "dsb st" and one "dsb ld". > > > Comment 135's content: > > A cortex-a72 success! (In the form of investigatory code, not > code to check-in as is.) > > Just by adding some "dsb st" commands and a "dsb ld" command in > places in the xhci code (just for __arach64__), I've gotten the > cortext-A72 to boot from the USB3 SSD via a -mcpu=cortex-a72 > based kernel build. No more indefinitely repeating "Resetting > controller" problem. > > I do not claim the additions are the minimal ones. I know one place > is required for sure: the last one added enabled the boot (given > the others were already present). Prior to that I still had the > indefinitely repeating "Resetting controller" problem. > > There could be more places that should have dsb st or dsb ld for > overall correctness. > > This evidence may suggest somewhat analogous problems for other > platforms than aarch64 that are seeing problems. > > For the aarch64 context, the evidence is (the changes are) > as follows. The first "dsb st" textually is the last one I > added. > > # svnlite diff /usr/src/sys/dev/usb/controller/xhci.c > Index: /usr/src/sys/dev/usb/controller/xhci.c > =================================================================== > --- /usr/src/sys/dev/usb/controller/xhci.c (revision 363590) > +++ /usr/src/sys/dev/usb/controller/xhci.c (working copy) > @@ -431,6 +431,9 @@ > > phwr->hwr_ring_seg[0].qwEvrsTablePtr = htole64(addr); > phwr->hwr_ring_seg[0].dwEvrsTableSize = htole32(XHCI_MAX_EVENTS); > +#ifdef __aarch64__ > +__asm __volatile("dsb st" : : : "memory"); > +#endif > > DPRINTF("ERDP(0)=0x%016llx\n", (unsigned long long)addr); > > @@ -1098,6 +1101,9 @@ > > while (1) { > > +#ifdef __aarch64__ > +__asm __volatile("dsb ld" : : : "memory"); > +#endif > temp = le32toh(phwr->hwr_events[i].dwTrb3); > > k = (temp & XHCI_TRB_3_CYCLE_BIT) ? 1 : 0; > @@ -1107,6 +1113,9 @@ > > event = XHCI_TRB_3_TYPE_GET(temp); > > +#ifdef __aarch64__ > +__asm __volatile("dsb ld" : : : "memory"); > +#endif > DPRINTFN(10, "event[%u] = %u (0x%016llx 0x%08lx 0x%08lx)\n", > i, event, (long long)le64toh(phwr->hwr_events[i].qwTrb0), > (long)le32toh(phwr->hwr_events[i].dwTrb2), > @@ -1239,6 +1248,9 @@ > sc->sc_command_idx = i; > sc->sc_command_ccs = j; > > +#ifdef __aarch64__ > +__asm __volatile("dsb st" : : : "memory"); > +#endif > XWRITE4(sc, door, XHCI_DOORBELL(0), 0); > > err = cv_timedwait(&sc->sc_cmd_cv, &sc->sc_bus.bus_mtx, > @@ -2855,6 +2867,9 @@ > index = xfer->xroot->udev->controller_slot_id; > > if (xfer->xroot->udev->flags.self_suspended == 0) { > +#ifdef __aarch64__ > +__asm __volatile("dsb st" : : : "memory"); > +#endif > XWRITE4(sc, door, XHCI_DOORBELL(index), > epno | XHCI_DB_SID_SET(xfer->stream_id)); > } > @@ -4180,6 +4195,9 @@ > > for (n = 1; n != XHCI_MAX_ENDPOINTS; n++) { > for (p = 0; p != XHCI_MAX_STREAMS; p++) { > +#ifdef __aarch64__ > +__asm __volatile("dsb st" : : : "memory"); > +#endif > XWRITE4(sc, door, XHCI_DOORBELL(index), > n | XHCI_DB_SID_SET(p)); > } > > > I'm clearly just "evidence hacking" here. I've no clue what a > good design for allowing aarch64 build to supply having any of > those "dsb st"s or the "dsb ld". > > Hopefully someone that knows what they are doing can figure out > if any of the other examples on other platforms are analogous > --and ,if they are, provide some hook for platform to contribute > such code to the xhci code. > Hi Mark, Your finding indicate a problem in usb_pc_cpu_flush() and bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREWRITE); Try to put the dsb only after dmamap_sync. void usb_pc_cpu_flush(struct usb_page_cache *pc) { if (pc->page_offset_end == pc->page_offset_buf) { /* nothing has been loaded into this page cache! */ return; } bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREWRITE); } The PCI I/O memory should be coherent and should not need any DSB's. --HPS From owner-freebsd-arm@freebsd.org Sat Sep 19 09:31:12 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 35D6C3D8292 for ; Sat, 19 Sep 2020 09:31:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-22.consmr.mail.gq1.yahoo.com (sonic317-22.consmr.mail.gq1.yahoo.com [98.137.66.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BtlnV4CnFz4nRd for ; Sat, 19 Sep 2020 09:31:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: XLEFc4gVM1mkv_I80AqM95NAO2rJaOliu4tzgHrobYsj7Qg0x6K99wJKaMW.t.x xRhKWTrAOURJCGGxUIcbe4DZ1hXd9Yy3RDkmeHJ_NptuxZtQkUZe2V4sQ2Jin.niq5fSxvL8ice_ Jt82rLbK9sYcrNWbrLHJEPuHMPYaIZ4KDFDUODH_QY6.yYe3DDHj8iLfoOXAat7gUZUwxqFrc6Tx nT.XShvgfd73x52iGjU.G1uNI6cL2pamjoD_5oaH99WflWqTVSXyed.3zpeBuIARUI33NLwm.1L0 oWwjluCyDtf3xfEKQRGK3OMmX0hNYcW.xiZRoZiwhy0.O3FM_xhMKEFNUeWJCvfsN3XUV.mKHyTw Q4oFMiCEV7U4Ve0iFfkzSKhY4Gi17BYdPcPYPcYm0HEhd0FTPSpbBpTmxLosXYnV5VwYTad9Yz0e mH1SK9Xmq.5A2bH9WvuJelQsUB_AGZhoDUR0oO1F2LP8IcrrP3fBaeYeXY4TyugityqbqN7kqyY2 iBdWVrR92O0D2iuXXpy.XfKIruuSQHaxcNO7KR_FtJyKQ1oKzO1Xh0halo4yfUhFDEVgxls5yn7U .TOk8FR77jxDQbhNiR5n7E3mcrbgCpcdsfbUl05q_ogRN2oP6vZEBcCreWkaEJPL5By4j1MR14pz 6tzQYhXjEpAmeznxIbTjBp2_MlXyZrg4RA1W.By0s3KF5V1J.6LptZ1xik15OEcw6aeV2RkrE6Xf rWPHftvlrSDinNKccPT7EMBSKjmaJPVqRfKTy2sMZtrIIamVq5PD6objJtwNm19Z0Ax0QmdGWAyY ZKXAtmMQoekr_awSbVoAt5d1D3whvU74TDjg1FUbbx0QU3KiUUUTkawLQQ6FuBOhNrfDk0L2XIkz WQQiRBbd9yeu9N3OZsrYTW_h7ZpLEucuWRpRMv0rlod4zY7fgKheNSAylp3nEnI0XRc1eRRM2uQm EznzWlMV6fo._qzSChJgtgDdrhFkKGjLVwTNAWO4ntq5v9VgugRgrjdSIl6YqiTgQa2YNJc7fYQ6 ANe2BaCDyZ0hZQZv1Q0F94_.dDLv.kwiVql3GONJ3PvX.PduBQfGKlvJXGmHfhIk71u0N2eTHk20 uhKkntY11ZppWzP_j2FVlFHbUFJmKkiNrELhU_KVqM.R2xBtNw4VZZ45rXnaJCoiagjEKjoomPoj B1Qdyg_7yn85R3a.mNamfAYQhsbOd7LmoAezHAGIArFNLq16JqOC7lW8Re7gPR_uzlUk_sTAaOyM NZKNapSFyQ2cH1EAM4RW_QvucR6.hnq7RcE4FkxPgpJ1nqmFzKUl1pVqNGD_djCNyXVLWZ8n8FMZ kOp5fxtQeAzHcPtpid.JIyEk1TYJiZGGecjkNcn8Qorv_HCqo0CS3H_UyEIP4Yo5_1UQVza.ZvIy WJ2MKCn6GuaVkQqjk48lMu1Bi4pZA01ovb4kxTUrCFZ0AQhz12anNZysHQnwq40O5rq2KE309unY bQpP7UCM7UIj0sHodCKMKKv2s_QgiqcotYsXdirOjB5Cg_WbbfNbkQlsw5_pTr2dNUfvtDuU- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sat, 19 Sep 2020 09:31:08 +0000 Received: by smtp421.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 20edb5877937c6833140279aa39ac9db; Sat, 19 Sep 2020 09:31:04 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: Comment #135 for bugzilla 237666 : a USB3-handling problem with a investigatory fix for a cortex-a72 context From: Mark Millard In-Reply-To: <866bd652-5a8b-7500-b1e0-7528c035048b@selasky.org> Date: Sat, 19 Sep 2020 02:31:03 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <6E618C3D-12DF-429E-A249-5BAB90FC6B15.ref@yahoo.com> <6E618C3D-12DF-429E-A249-5BAB90FC6B15@yahoo.com> <866bd652-5a8b-7500-b1e0-7528c035048b@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4BtlnV4CnFz4nRd X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.79 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.27)[-1.269]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.005]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.02)[-1.021]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.148:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2020 09:31:12 -0000 On 2020-Sep-19, at 01:08, Hans Petter Selasky = wrote: > On 2020-09-19 05:41, Mark Millard via freebsd-arm wrote: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237666 is about = USB3 >> problems that folks have been having for over a year. Bjoern A. Zeeb >> comment #125 that looked like something I'd seen on a cortex-a72 when >> I tried a kernel that had been built with -mcpu=3Dcortex-a72 : an >> indefinite looping that involved "Resetting controller" for xhci0. >> (This prevented booting from the USB3 device.) >> Well, I got the A72 to boot and comment #135 indicates how but I'll >> paste the information below. All that was involved was adding >> examples of "dsb st" and one "dsb ld". >> Comment 135's content: >> A cortex-a72 success! (In the form of investigatory code, not >> code to check-in as is.) >> Just by adding some "dsb st" commands and a "dsb ld" command in >> places in the xhci code (just for __arach64__), I've gotten the >> cortext-A72 to boot from the USB3 SSD via a -mcpu=3Dcortex-a72 >> based kernel build. No more indefinitely repeating "Resetting >> controller" problem. >> I do not claim the additions are the minimal ones. I know one place >> is required for sure: the last one added enabled the boot (given >> the others were already present). Prior to that I still had the >> indefinitely repeating "Resetting controller" problem. >> There could be more places that should have dsb st or dsb ld for >> overall correctness. >> This evidence may suggest somewhat analogous problems for other >> platforms than aarch64 that are seeing problems. >> For the aarch64 context, the evidence is (the changes are) >> as follows. The first "dsb st" textually is the last one I >> added. >> # svnlite diff /usr/src/sys/dev/usb/controller/xhci.c >> Index: /usr/src/sys/dev/usb/controller/xhci.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- /usr/src/sys/dev/usb/controller/xhci.c (revision 363590) >> +++ /usr/src/sys/dev/usb/controller/xhci.c (working copy) >> @@ -431,6 +431,9 @@ >> phwr->hwr_ring_seg[0].qwEvrsTablePtr =3D htole64(addr); >> phwr->hwr_ring_seg[0].dwEvrsTableSize =3D = htole32(XHCI_MAX_EVENTS); >> +#ifdef __aarch64__ >> +__asm __volatile("dsb st" : : : "memory"); >> +#endif >> DPRINTF("ERDP(0)=3D0x%016llx\n", (unsigned long long)addr); >> @@ -1098,6 +1101,9 @@ >> while (1) { >> +#ifdef __aarch64__ >> +__asm __volatile("dsb ld" : : : "memory"); >> +#endif >> temp =3D le32toh(phwr->hwr_events[i].dwTrb3); >> k =3D (temp & XHCI_TRB_3_CYCLE_BIT) ? 1 : 0; >> @@ -1107,6 +1113,9 @@ >> event =3D XHCI_TRB_3_TYPE_GET(temp); >> +#ifdef __aarch64__ >> +__asm __volatile("dsb ld" : : : "memory"); >> +#endif >> DPRINTFN(10, "event[%u] =3D %u (0x%016llx 0x%08lx = 0x%08lx)\n", >> i, event, (long = long)le64toh(phwr->hwr_events[i].qwTrb0), >> (long)le32toh(phwr->hwr_events[i].dwTrb2), >> @@ -1239,6 +1248,9 @@ >> sc->sc_command_idx =3D i; >> sc->sc_command_ccs =3D j; >> +#ifdef __aarch64__ >> +__asm __volatile("dsb st" : : : "memory"); >> +#endif >> XWRITE4(sc, door, XHCI_DOORBELL(0), 0); >> err =3D cv_timedwait(&sc->sc_cmd_cv, &sc->sc_bus.bus_mtx, >> @@ -2855,6 +2867,9 @@ >> index =3D xfer->xroot->udev->controller_slot_id; >> if (xfer->xroot->udev->flags.self_suspended =3D=3D 0) { >> +#ifdef __aarch64__ >> +__asm __volatile("dsb st" : : : "memory"); >> +#endif >> XWRITE4(sc, door, XHCI_DOORBELL(index), >> epno | XHCI_DB_SID_SET(xfer->stream_id)); >> } >> @@ -4180,6 +4195,9 @@ >> for (n =3D 1; n !=3D XHCI_MAX_ENDPOINTS; n++) { >> for (p =3D 0; p !=3D XHCI_MAX_STREAMS; p++) { >> +#ifdef __aarch64__ >> +__asm __volatile("dsb st" : : : "memory"); >> +#endif >> XWRITE4(sc, door, XHCI_DOORBELL(index), >> n | XHCI_DB_SID_SET(p)); >> } >> I'm clearly just "evidence hacking" here. I've no clue what a >> good design for allowing aarch64 build to supply having any of >> those "dsb st"s or the "dsb ld". >> Hopefully someone that knows what they are doing can figure out >> if any of the other examples on other platforms are analogous >> --and ,if they are, provide some hook for platform to contribute >> such code to the xhci code. >=20 > Hi Mark, >=20 > Your finding indicate a problem in usb_pc_cpu_flush() and >=20 > bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREWRITE); >=20 > Try to put the dsb only after dmamap_sync. >=20 > void > usb_pc_cpu_flush(struct usb_page_cache *pc) > { > if (pc->page_offset_end =3D=3D pc->page_offset_buf) { > /* nothing has been loaded into this page cache! */ > return; > } > bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREWRITE); > } >=20 > The PCI I/O memory should be coherent and should not need any DSB's. [I'll note that historically I've gotten one "Resetting Controller" notice from the -mcpu=3Dcortex-a53 kernel during the sequence leading to the root file system mount. I get none from the -mcpu=3Dcortex-a72 kernel after the changes that I reported.] After adding a couple of more DSB ST instructions and rebuilding (cross build), installing, and booting, I started a self-hosted, from-scratch, buildworld buildlkernel and intend to installkernel installworld and reboot if it appears to go well. (Better than just a boot test for if things seem at least sufficient, even if overkill.) But it will be hours before buildworld build kernel is done (-j3). (I'll sleep during much of that time.) I'll get to experiments you suggest after that. I assume that you want the two (not one) dsb ld instructions removed as well. I'm happy to do your experiments, despite the following note about what I expect the result will be for the first one. I do not expect your experiment to work in one place because the addition that started things working does not involve a usb_pc_cpu_flush for the event ring initialization that the specific change was for: phwr =3D buf_res.buffer; addr =3D buf_res.physaddr; addr +=3D (uintptr_t)&((struct xhci_hw_root *)0)->hwr_events[0]; =20 /* reset hardware root structure */ memset(phwr, 0, sizeof(*phwr)); =20 phwr->hwr_ring_seg[0].qwEvrsTablePtr =3D htole64(addr); phwr->hwr_ring_seg[0].dwEvrsTableSize =3D = htole32(XHCI_MAX_EVENTS); =20 DPRINTF("ERDP(0)=3D0x%016llx\n", (unsigned long long)addr); =20 #ifdef __aarch64__ __asm __volatile("dsb st" : : : "memory"); #endif XWRITE4(sc, runt, XHCI_ERDP_LO(0), (uint32_t)addr); XWRITE4(sc, runt, XHCI_ERDP_HI(0), (uint32_t)(addr >> 32)); =20 addr =3D buf_res.physaddr; =20 DPRINTF("ERSTBA(0)=3D0x%016llx\n", (unsigned long long)addr); XWRITE4(sc, runt, XHCI_ERSTBA_LO(0), (uint32_t)addr); XWRITE4(sc, runt, XHCI_ERSTBA_HI(0), (uint32_t)(addr >> 32)); My understanding is that those last two lines start the event ring and without the DSB ST above the: phwr->hwr_ring_seg[0].qwEvrsTablePtr =3D htole64(addr); phwr->hwr_ring_seg[0].dwEvrsTableSize =3D = htole32(XHCI_MAX_EVENTS); result was not observed by xhci but needs to be observed at that ring start time. Without the DSB ST above, xhci_interrupt_poll's code (with one of my additions shown): #ifdef __aarch64__ __asm __volatile("dsb ld" : : : "memory"); #endif temp =3D le32toh(phwr->hwr_events[i].dwTrb3); =20 k =3D (temp & XHCI_TRB_3_CYCLE_BIT) ? 1 : 0; =20 if (j !=3D k) break; always took the break because temp was always zero, k was always zero, and j was 1. I expect this is because the wrong qwEvrsTablePtr and dwEvrsTableSize content was in use by the xhci (fixed by the DSB ST). (I had a temporarily version that printed the values. With and without the DSB LD made no difference without the DSB ST that was later added.) =46rom what I understand, the cortex-a72 has far more structure that involves the "DSB completes when" behavior being needed compared to the cortex-a53 and code tuned to the A72 is more likely to end up needing such. (Speculation and speculative-driven cache contents, out of order execution, and probably more.) QUOTE =E2=80=A2 all explicit memory accesses that are observed by Pe = before the DSB is executed, are of the required access types, and are = from observers in the same required shareability domain as Pe, are = complete for the set of observers in the required shareability domain =E2=80=A2 all cache, branch predictor, and TLB maintenance = operations issued by Pe before the DSB are complete for the required = shareability domain. END QUOTE (Pe means "executing processor".) I expect the removal of that specific DSB ST to result in xhci_interrupt_poll's code again taking the break every time, just based on event ring behavior alone. I'll note that the RPi4B SBC has a not-physically-exposed PCIe that the USB3 is off of, and the UEFI/ACPI that I have in use for the RPi4B does not expose the PICe to the loader or OS at all. ACPI does expose the USB3 related material. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Sep 19 11:47:00 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 397E03DC597 for ; Sat, 19 Sep 2020 11:47:00 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) 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 4BtppC2ygpz3T4x for ; Sat, 19 Sep 2020 11:46:59 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id DC94126010A; Sat, 19 Sep 2020 13:46:50 +0200 (CEST) Subject: Re: Comment #135 for bugzilla 237666 : a USB3-handling problem with a investigatory fix for a cortex-a72 context To: Mark Millard Cc: freebsd-arm References: <6E618C3D-12DF-429E-A249-5BAB90FC6B15.ref@yahoo.com> <6E618C3D-12DF-429E-A249-5BAB90FC6B15@yahoo.com> <866bd652-5a8b-7500-b1e0-7528c035048b@selasky.org> From: Hans Petter Selasky Message-ID: <578faf26-6042-91ec-c639-2bca17105fae@selasky.org> Date: Sat, 19 Sep 2020 13:46:18 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4BtppC2ygpz3T4x X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-2.89 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_LONG(-1.01)[-1.013]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.61)[-0.615]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-0.96)[-0.960]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2020 11:47:00 -0000 On 2020-09-19 11:31, Mark Millard wrote: > > > On 2020-Sep-19, at 01:08, Hans Petter Selasky wrote: > >> On 2020-09-19 05:41, Mark Millard via freebsd-arm wrote: >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237666 is about USB3 >>> problems that folks have been having for over a year. Bjoern A. Zeeb >>> comment #125 that looked like something I'd seen on a cortex-a72 when >>> I tried a kernel that had been built with -mcpu=cortex-a72 : an >>> indefinite looping that involved "Resetting controller" for xhci0. >>> (This prevented booting from the USB3 device.) >>> Well, I got the A72 to boot and comment #135 indicates how but I'll >>> paste the information below. All that was involved was adding >>> examples of "dsb st" and one "dsb ld". >>> Comment 135's content: >>> A cortex-a72 success! (In the form of investigatory code, not >>> code to check-in as is.) >>> Just by adding some "dsb st" commands and a "dsb ld" command in >>> places in the xhci code (just for __arach64__), I've gotten the >>> cortext-A72 to boot from the USB3 SSD via a -mcpu=cortex-a72 >>> based kernel build. No more indefinitely repeating "Resetting >>> controller" problem. >>> I do not claim the additions are the minimal ones. I know one place >>> is required for sure: the last one added enabled the boot (given >>> the others were already present). Prior to that I still had the >>> indefinitely repeating "Resetting controller" problem. >>> There could be more places that should have dsb st or dsb ld for >>> overall correctness. >>> This evidence may suggest somewhat analogous problems for other >>> platforms than aarch64 that are seeing problems. >>> For the aarch64 context, the evidence is (the changes are) >>> as follows. The first "dsb st" textually is the last one I >>> added. >>> # svnlite diff /usr/src/sys/dev/usb/controller/xhci.c >>> Index: /usr/src/sys/dev/usb/controller/xhci.c >>> =================================================================== >>> --- /usr/src/sys/dev/usb/controller/xhci.c (revision 363590) >>> +++ /usr/src/sys/dev/usb/controller/xhci.c (working copy) >>> @@ -431,6 +431,9 @@ >>> phwr->hwr_ring_seg[0].qwEvrsTablePtr = htole64(addr); >>> phwr->hwr_ring_seg[0].dwEvrsTableSize = htole32(XHCI_MAX_EVENTS); >>> +#ifdef __aarch64__ >>> +__asm __volatile("dsb st" : : : "memory"); >>> +#endif >>> DPRINTF("ERDP(0)=0x%016llx\n", (unsigned long long)addr); >>> @@ -1098,6 +1101,9 @@ >>> while (1) { >>> +#ifdef __aarch64__ >>> +__asm __volatile("dsb ld" : : : "memory"); >>> +#endif >>> temp = le32toh(phwr->hwr_events[i].dwTrb3); >>> k = (temp & XHCI_TRB_3_CYCLE_BIT) ? 1 : 0; >>> @@ -1107,6 +1113,9 @@ >>> event = XHCI_TRB_3_TYPE_GET(temp); >>> +#ifdef __aarch64__ >>> +__asm __volatile("dsb ld" : : : "memory"); >>> +#endif >>> DPRINTFN(10, "event[%u] = %u (0x%016llx 0x%08lx 0x%08lx)\n", >>> i, event, (long long)le64toh(phwr->hwr_events[i].qwTrb0), >>> (long)le32toh(phwr->hwr_events[i].dwTrb2), >>> @@ -1239,6 +1248,9 @@ >>> sc->sc_command_idx = i; >>> sc->sc_command_ccs = j; >>> +#ifdef __aarch64__ >>> +__asm __volatile("dsb st" : : : "memory"); >>> +#endif >>> XWRITE4(sc, door, XHCI_DOORBELL(0), 0); >>> err = cv_timedwait(&sc->sc_cmd_cv, &sc->sc_bus.bus_mtx, >>> @@ -2855,6 +2867,9 @@ >>> index = xfer->xroot->udev->controller_slot_id; >>> if (xfer->xroot->udev->flags.self_suspended == 0) { >>> +#ifdef __aarch64__ >>> +__asm __volatile("dsb st" : : : "memory"); >>> +#endif >>> XWRITE4(sc, door, XHCI_DOORBELL(index), >>> epno | XHCI_DB_SID_SET(xfer->stream_id)); >>> } >>> @@ -4180,6 +4195,9 @@ >>> for (n = 1; n != XHCI_MAX_ENDPOINTS; n++) { >>> for (p = 0; p != XHCI_MAX_STREAMS; p++) { >>> +#ifdef __aarch64__ >>> +__asm __volatile("dsb st" : : : "memory"); >>> +#endif >>> XWRITE4(sc, door, XHCI_DOORBELL(index), >>> n | XHCI_DB_SID_SET(p)); >>> } >>> I'm clearly just "evidence hacking" here. I've no clue what a >>> good design for allowing aarch64 build to supply having any of >>> those "dsb st"s or the "dsb ld". >>> Hopefully someone that knows what they are doing can figure out >>> if any of the other examples on other platforms are analogous >>> --and ,if they are, provide some hook for platform to contribute >>> such code to the xhci code. >> >> Hi Mark, >> >> Your finding indicate a problem in usb_pc_cpu_flush() and >> >> bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREWRITE); >> >> Try to put the dsb only after dmamap_sync. >> >> void >> usb_pc_cpu_flush(struct usb_page_cache *pc) >> { >> if (pc->page_offset_end == pc->page_offset_buf) { >> /* nothing has been loaded into this page cache! */ >> return; >> } >> bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREWRITE); >> } >> >> The PCI I/O memory should be coherent and should not need any DSB's. > > [I'll note that historically I've gotten one "Resetting Controller" > notice from the -mcpu=cortex-a53 kernel during the sequence leading > to the root file system mount. I get none from the -mcpu=cortex-a72 > kernel after the changes that I reported.] > > After adding a couple of more DSB ST instructions and rebuilding > (cross build), installing, and booting, I started a self-hosted, > from-scratch, buildworld buildlkernel and intend to installkernel > installworld and reboot if it appears to go well. (Better than > just a boot test for if things seem at least sufficient, even if > overkill.) But it will be hours before buildworld build kernel is > done (-j3). (I'll sleep during much of that time.) > > I'll get to experiments you suggest after that. I assume that > you want the two (not one) dsb ld instructions removed as well. > > I'm happy to do your experiments, despite the following note > about what I expect the result will be for the first one. > > I do not expect your experiment to work in one place because > the addition that started things working does not involve a > usb_pc_cpu_flush for the event ring initialization that the > specific change was for: > > phwr = buf_res.buffer; > addr = buf_res.physaddr; > addr += (uintptr_t)&((struct xhci_hw_root *)0)->hwr_events[0]; > > /* reset hardware root structure */ > memset(phwr, 0, sizeof(*phwr)); > > phwr->hwr_ring_seg[0].qwEvrsTablePtr = htole64(addr); > phwr->hwr_ring_seg[0].dwEvrsTableSize = htole32(XHCI_MAX_EVENTS); > > DPRINTF("ERDP(0)=0x%016llx\n", (unsigned long long)addr); > > #ifdef __aarch64__ > __asm __volatile("dsb st" : : : "memory"); > #endif Hi Mark, The values in ERDP_LO/HI are not used until the RUN bit is set. > XWRITE4(sc, runt, XHCI_ERDP_LO(0), (uint32_t)addr); > XWRITE4(sc, runt, XHCI_ERDP_HI(0), (uint32_t)(addr >> 32)); > > addr = buf_res.physaddr; > > DPRINTF("ERSTBA(0)=0x%016llx\n", (unsigned long long)addr); > > XWRITE4(sc, runt, XHCI_ERSTBA_LO(0), (uint32_t)addr); > XWRITE4(sc, runt, XHCI_ERSTBA_HI(0), (uint32_t)(addr >> 32)); > > My understanding is that those last two lines start the event ring > and without the DSB ST above the: No they don't. > > phwr->hwr_ring_seg[0].qwEvrsTablePtr = htole64(addr); > phwr->hwr_ring_seg[0].dwEvrsTableSize = htole32(XHCI_MAX_EVENTS); > > result was not observed by xhci but needs to be observed at that ring > start time. > > Without the DSB ST above, xhci_interrupt_poll's code (with one > of my additions shown): > > #ifdef __aarch64__ > __asm __volatile("dsb ld" : : : "memory"); > #endif Probably same bug in the USB invalidate function. Try to patch those generic flush/invalidate functions instead. I've been very careful about those. > temp = le32toh(phwr->hwr_events[i].dwTrb3); > > k = (temp & XHCI_TRB_3_CYCLE_BIT) ? 1 : 0; > > if (j != k) > break; > > always took the break because temp was always zero, k was always zero, > and j was 1. I expect this is because the wrong qwEvrsTablePtr and > dwEvrsTableSize content was in use by the xhci (fixed by the DSB ST). > (I had a temporarily version that printed the values. With and without > the DSB LD made no difference without the DSB ST that was later added.) > > From what I understand, the cortex-a72 has far more structure that > involves the "DSB completes when" behavior being needed compared > to the cortex-a53 and code tuned to the A72 is more likely to end > up needing such. (Speculation and speculative-driven cache contents, > out of order execution, and probably more.) > > QUOTE > • all explicit memory accesses that are observed by Pe before the DSB is executed, are of the required access types, and are from observers in the same required shareability domain as Pe, are complete for the set of observers in the required shareability domain > • all cache, branch predictor, and TLB maintenance operations issued by Pe before the DSB are complete for the required shareability domain. > END QUOTE It smells like a generic problem in the busdma synchronize code. > > (Pe means "executing processor".) > > I expect the removal of that specific DSB ST to result in > xhci_interrupt_poll's code again taking the break every time, > just based on event ring behavior alone. > Again, try to patch both usb_pc_cpu_flush() and usb_pc_cpu_invalidate() > > I'll note that the RPi4B SBC has a not-physically-exposed PCIe > that the USB3 is off of, and the UEFI/ACPI that I have in use for > the RPi4B does not expose the PICe to the loader or OS at all. > ACPI does expose the USB3 related material. --HPS From owner-freebsd-arm@freebsd.org Sat Sep 19 11:48:40 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 36F973DC1E1 for ; Sat, 19 Sep 2020 11:48:40 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 4Btpr73S4fz3TVk for ; Sat, 19 Sep 2020 11:48:39 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 116BD2606A6; Sat, 19 Sep 2020 13:48:38 +0200 (CEST) Subject: Re: Comment #135 for bugzilla 237666 : a USB3-handling problem with a investigatory fix for a cortex-a72 context To: Mark Millard Cc: freebsd-arm References: <6E618C3D-12DF-429E-A249-5BAB90FC6B15.ref@yahoo.com> <6E618C3D-12DF-429E-A249-5BAB90FC6B15@yahoo.com> <866bd652-5a8b-7500-b1e0-7528c035048b@selasky.org> From: Hans Petter Selasky Message-ID: <2e7f92d2-9fbf-8355-c5a6-9a013d118a73@selasky.org> Date: Sat, 19 Sep 2020 13:48:07 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Btpr73S4fz3TVk X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-2.94 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_LONG(-1.01)[-1.005]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.66)[-0.662]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-0.97)[-0.970]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2020 11:48:40 -0000 On 2020-09-19 11:31, Mark Millard wrote: > #ifdef __aarch64__ > __asm __volatile("dsb ld" : : : "memory"); > #endif > temp = le32toh(phwr->hwr_events[i].dwTrb3); > If you look a few lines up you'll find the: usb_pc_cpu_invalidate(&sc->sc_hw.root_pc); That's where this instruction belongs. --HPS From owner-freebsd-arm@freebsd.org Sat Sep 19 12:22:54 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1440D3DE4F6 for ; Sat, 19 Sep 2020 12:22:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-20.consmr.mail.gq1.yahoo.com (sonic310-20.consmr.mail.gq1.yahoo.com [98.137.69.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Btqbc6nQSz3Wl4 for ; Sat, 19 Sep 2020 12:22:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: PctSJrQVM1kdXnM0S3Ymdht_kpRSrej3rBQ.tZbBXrqD.OzMkEaZnlYtXBrOA5V GFney2A84ZprexPu6wA9Qnv8.XUWc7.o9zTC0L_WL3.2pmDsl.3BAgtvXhM56cFwA9z9R3v5p9Gf aPFyA7.eNZ3hktfibx0h_wV0n.NPdsFmpkWnErbvAQSnYGTMbELvS.YRZrIYeGk1WoHHJqNLdrts fenDN8PckwOki53q6MoFk_9ON3yPtzW1LGE4Kfod3ZrOu3QEtbF3zZ8ZKjX4Z690vQLGt8zks8g0 I1BnifC7SY20BUf.WVF5AjLrq2Onas1_lIAcLeWK3I53CpDlv6LV2sBF3OyIMZHtozQt_hDMQo5h 5E2GjFrODyc1lwtHqJwo1AfYxYkhu_CODixmcWOdXAyVFl.cTz920z5lBs_9OkflpRv.T7vQUjxP 5UhenPjc6nYGfryMXauuyJU4FRz7eO6FKC8Vb1zpk8mNh1W1XUlU2FD4sp6dfMTuWFrBuj9D6vNw y_1EA4gVTmKGIGB213J.PkN.dpIqP2LfIi9nIorNle2BNFDQu4uQAQ9VkjmkrvZDk3yCxIvCLY0W 4FC0Sb9Iqs5cN9vgUupfrSvyUmpHrdE1w7fMfW3c3d4CcdGBnF994eRniJhiLie6YZLtfdleTjjJ Cd3GFFOF_YBIFw5zdFwmGfW_DqKJm_elOSb1n7CWitQr_rO10OkisGipArhHgz65z4a.1jfIcjsG rptF8YZGzE4A1HJLS4VQDc5VCokgNlIzfmddjshGQXwpxMH2BdrEnGtDaTUc8r2kTkPV1KWzSizQ .Iyfa5NZ28tiPutiyUkPjYJrQCxV2bLv83odc4Uk_OIe3HuEj48hxHDx2nGdfyjEVeKXzLsCjhAs jBdkn68oLDrPKUmgzXC_mlfriAK0xm3pfy.6LL.R1WmlIIar8uVTBIcIxhyPqCZxgx3qd6_sCeG0 Cr40..F0.GHJF3uLmVg31BbfAELA6Wiv.gQeX4._5xa6z1lw0ZL6U1puIIKkFeSS5ajYOPyg2g3. _pPx6u_.IqgYG1o3xowjGGfsvRVMxy9itN9_hQI5wlH2wj8Mwg90.FJfXxOIwh0CjEsaMxsuEP.a iW8ccOW9fYLBLgXUx8rni8HlXiGtsPabCdaAdUn570b7Oa0qRUVQrSenbUPLxdHK7qWTyi_Fv9tW O6ebU5NakRdmFuPeou76QBDbN0WHBkBV7KDDcOvlADlBMr0nZ6lAz3FXDLrqHlXXW1tfcVh_C.BN DV7TtVtaUFmjweQqFu6VamuPxXYkbjk9cPQmqMffHCuU7DPJmp6hx45D.8MAZMAVtlWI34Y7c61t SXvbu.c.b3r5jiK6A7wg7zLpmQAOm9M0wiuXCsQP2.PQSbapXc4Kmv4bO8wO7TItKdpuEOPPb1LN spG6RopCmlYfHo01RTCH5kWfyVf.O8MyTUQPC.7EdZ0BWGFV590.Mih.Nj2oRn6Sm.3BZHkVEkzw RROx49qW735pfNujMGczFGwk1YtmFWou53Db0XfU0XGQ2rTgX6kr66uNqeoN6kUNUKywtuDI- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Sat, 19 Sep 2020 12:22:50 +0000 Received: by smtp402.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 28a426e723e61ad79d2968e5de8cb4d7; Sat, 19 Sep 2020 12:22:45 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: Comment #135 for bugzilla 237666 : a USB3-handling problem with a investigatory fix for a cortex-a72 context From: Mark Millard In-Reply-To: <578faf26-6042-91ec-c639-2bca17105fae@selasky.org> Date: Sat, 19 Sep 2020 05:22:43 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <723E6915-94F5-417C-B4AF-EEEBFBDF6162@yahoo.com> References: <6E618C3D-12DF-429E-A249-5BAB90FC6B15.ref@yahoo.com> <6E618C3D-12DF-429E-A249-5BAB90FC6B15@yahoo.com> <866bd652-5a8b-7500-b1e0-7528c035048b@selasky.org> <578faf26-6042-91ec-c639-2bca17105fae@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4Btqbc6nQSz3Wl4 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.21 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.69)[-0.688]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.005]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.02)[-1.020]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.146:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.146:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2020 12:22:54 -0000 On 2020-Sep-19, at 04:46, Hans Petter Selasky = wrote: > On 2020-09-19 11:31, Mark Millard wrote: >> On 2020-Sep-19, at 01:08, Hans Petter Selasky = wrote: >>> On 2020-09-19 05:41, Mark Millard via freebsd-arm wrote: >>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237666 is about = USB3 >>>> problems that folks have been having for over a year. Bjoern A. = Zeeb >>>> comment #125 that looked like something I'd seen on a cortex-a72 = when >>>> I tried a kernel that had been built with -mcpu=3Dcortex-a72 : an >>>> indefinite looping that involved "Resetting controller" for xhci0. >>>> (This prevented booting from the USB3 device.) >>>> Well, I got the A72 to boot and comment #135 indicates how but I'll >>>> paste the information below. All that was involved was adding >>>> examples of "dsb st" and one "dsb ld". >>>> Comment 135's content: >>>> A cortex-a72 success! (In the form of investigatory code, not >>>> code to check-in as is.) >>>> Just by adding some "dsb st" commands and a "dsb ld" command in >>>> places in the xhci code (just for __arach64__), I've gotten the >>>> cortext-A72 to boot from the USB3 SSD via a -mcpu=3Dcortex-a72 >>>> based kernel build. No more indefinitely repeating "Resetting >>>> controller" problem. >>>> I do not claim the additions are the minimal ones. I know one place >>>> is required for sure: the last one added enabled the boot (given >>>> the others were already present). Prior to that I still had the >>>> indefinitely repeating "Resetting controller" problem. >>>> There could be more places that should have dsb st or dsb ld for >>>> overall correctness. >>>> This evidence may suggest somewhat analogous problems for other >>>> platforms than aarch64 that are seeing problems. >>>> For the aarch64 context, the evidence is (the changes are) >>>> as follows. The first "dsb st" textually is the last one I >>>> added. >>>> # svnlite diff /usr/src/sys/dev/usb/controller/xhci.c >>>> Index: /usr/src/sys/dev/usb/controller/xhci.c >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> --- /usr/src/sys/dev/usb/controller/xhci.c (revision 363590) >>>> +++ /usr/src/sys/dev/usb/controller/xhci.c (working copy) >>>> @@ -431,6 +431,9 @@ >>>> phwr->hwr_ring_seg[0].qwEvrsTablePtr =3D htole64(addr); >>>> phwr->hwr_ring_seg[0].dwEvrsTableSize =3D = htole32(XHCI_MAX_EVENTS); >>>> +#ifdef __aarch64__ >>>> +__asm __volatile("dsb st" : : : "memory"); >>>> +#endif >>>> DPRINTF("ERDP(0)=3D0x%016llx\n", (unsigned long = long)addr); >>>> @@ -1098,6 +1101,9 @@ >>>> while (1) { >>>> +#ifdef __aarch64__ >>>> +__asm __volatile("dsb ld" : : : "memory"); >>>> +#endif >>>> temp =3D le32toh(phwr->hwr_events[i].dwTrb3); >>>> k =3D (temp & XHCI_TRB_3_CYCLE_BIT) ? 1 : 0; >>>> @@ -1107,6 +1113,9 @@ >>>> event =3D XHCI_TRB_3_TYPE_GET(temp); >>>> +#ifdef __aarch64__ >>>> +__asm __volatile("dsb ld" : : : "memory"); >>>> +#endif >>>> DPRINTFN(10, "event[%u] =3D %u (0x%016llx 0x%08lx = 0x%08lx)\n", >>>> i, event, (long = long)le64toh(phwr->hwr_events[i].qwTrb0), >>>> (long)le32toh(phwr->hwr_events[i].dwTrb2), >>>> @@ -1239,6 +1248,9 @@ >>>> sc->sc_command_idx =3D i; >>>> sc->sc_command_ccs =3D j; >>>> +#ifdef __aarch64__ >>>> +__asm __volatile("dsb st" : : : "memory"); >>>> +#endif >>>> XWRITE4(sc, door, XHCI_DOORBELL(0), 0); >>>> err =3D cv_timedwait(&sc->sc_cmd_cv, = &sc->sc_bus.bus_mtx, >>>> @@ -2855,6 +2867,9 @@ >>>> index =3D xfer->xroot->udev->controller_slot_id; >>>> if (xfer->xroot->udev->flags.self_suspended =3D=3D 0) { >>>> +#ifdef __aarch64__ >>>> +__asm __volatile("dsb st" : : : "memory"); >>>> +#endif >>>> XWRITE4(sc, door, XHCI_DOORBELL(index), >>>> epno | XHCI_DB_SID_SET(xfer->stream_id)); >>>> } >>>> @@ -4180,6 +4195,9 @@ >>>> for (n =3D 1; n !=3D XHCI_MAX_ENDPOINTS; n++) { >>>> for (p =3D 0; p !=3D XHCI_MAX_STREAMS; p++) { >>>> +#ifdef __aarch64__ >>>> +__asm __volatile("dsb st" : : : "memory"); >>>> +#endif >>>> XWRITE4(sc, door, XHCI_DOORBELL(index), >>>> n | XHCI_DB_SID_SET(p)); >>>> } >>>> I'm clearly just "evidence hacking" here. I've no clue what a >>>> good design for allowing aarch64 build to supply having any of >>>> those "dsb st"s or the "dsb ld". >>>> Hopefully someone that knows what they are doing can figure out >>>> if any of the other examples on other platforms are analogous >>>> --and ,if they are, provide some hook for platform to contribute >>>> such code to the xhci code. >>>=20 >>> Hi Mark, >>>=20 >>> Your finding indicate a problem in usb_pc_cpu_flush() and >>>=20 >>> bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREWRITE); >>>=20 >>> Try to put the dsb only after dmamap_sync. >>>=20 >>> void >>> usb_pc_cpu_flush(struct usb_page_cache *pc) >>> { >>> if (pc->page_offset_end =3D=3D pc->page_offset_buf) { >>> /* nothing has been loaded into this page cache! */ >>> return; >>> } >>> bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREWRITE); >>> } >>>=20 >>> The PCI I/O memory should be coherent and should not need any DSB's. >> [I'll note that historically I've gotten one "Resetting Controller" >> notice from the -mcpu=3Dcortex-a53 kernel during the sequence leading >> to the root file system mount. I get none from the -mcpu=3Dcortex-a72 >> kernel after the changes that I reported.] >> After adding a couple of more DSB ST instructions and rebuilding >> (cross build), installing, and booting, I started a self-hosted, >> from-scratch, buildworld buildlkernel and intend to installkernel >> installworld and reboot if it appears to go well. (Better than >> just a boot test for if things seem at least sufficient, even if >> overkill.) But it will be hours before buildworld build kernel is >> done (-j3). (I'll sleep during much of that time.) I woke up so I figured I'd look at this before trying to sleep again. >> I'll get to experiments you suggest after that. I assume that >> you want the two (not one) dsb ld instructions removed as well. >> I'm happy to do your experiments, despite the following note >> about what I expect the result will be for the first one. >> I do not expect your experiment to work in one place because >> the addition that started things working does not involve a >> usb_pc_cpu_flush for the event ring initialization that the >> specific change was for: >> phwr =3D buf_res.buffer; >> addr =3D buf_res.physaddr; >> addr +=3D (uintptr_t)&((struct xhci_hw_root = *)0)->hwr_events[0]; >> /* reset hardware root structure */ >> memset(phwr, 0, sizeof(*phwr)); >> phwr->hwr_ring_seg[0].qwEvrsTablePtr =3D = htole64(addr); >> phwr->hwr_ring_seg[0].dwEvrsTableSize =3D = htole32(XHCI_MAX_EVENTS); >> DPRINTF("ERDP(0)=3D0x%016llx\n", (unsigned long = long)addr); >> #ifdef __aarch64__ >> __asm __volatile("dsb st" : : : "memory"); >> #endif >=20 > Hi Mark, >=20 > The values in ERDP_LO/HI are not used until the RUN bit is set. I just picked between the qwEvrsTablePtr and dwEvrsTableSize writes and the following several XWRITE4's, figuring it would be sufficient placement if it helped at all. (It did help.) >> XWRITE4(sc, runt, XHCI_ERDP_LO(0), (uint32_t)addr); >> XWRITE4(sc, runt, XHCI_ERDP_HI(0), (uint32_t)(addr >> 32)); >> addr =3D buf_res.physaddr; >> DPRINTF("ERSTBA(0)=3D0x%016llx\n", (unsigned long = long)addr); >> XWRITE4(sc, runt, XHCI_ERSTBA_LO(0), (uint32_t)addr); >> XWRITE4(sc, runt, XHCI_ERSTBA_HI(0), (uint32_t)(addr >> 32)); >> My understanding is that those last two lines start the event ring >> and without the DSB ST above the: >=20 > No they don't. The text associated with "The following steps describe the xHC Event = Ring Enqueue Pointer (EREP) Advancement algorithm (left side of Figure = 4-12)" in extensible-host-controler-interface-usb-xhci.pdf says: QUOTE (partial) 1. When the ERST Base Address (ERSTBA) register is initially = written the Event Ring State Machine enters the Start state. 2. The xHC initializes its internal PCS flag to =E2=80=981=E2=80=99= . 3. The xHC sets its internal ERST Count to =E2=80=980=E2=80=99. 4. The xHC then fetches the entry in the Event Ring Segment = Table referenced by the ERST Count (ERSTE =3D ERST[ERST Count]) and = initializes its Enqueue Pointer (EREP) with the value of the Ring = Segment Base Address field (ERSTE.BaseAddr), and the TRB Count with the = value of the Segment Size field (ERSTE.Size). 5. If the USBCMD Run/Stop (R/S) flag =3D =E2=80=980=E2=80=99 the = Event Ring State Machine shall wait for Run/Stop (R/S) to return to = =E2=80=981=E2=80=99. When Run/Stop (R/S) flag=3D =E2=80=981=E2=80=99 the = xHC shall proceeds to check if an event is posted (step 6., otherwise it = proceeds immediately to step 6. END QUOTE (Steps 6-8 are omitted above.) May be I read too much into (4) and the = first reference to R/S being in step (5). >> phwr->hwr_ring_seg[0].qwEvrsTablePtr =3D htole64(addr); >> phwr->hwr_ring_seg[0].dwEvrsTableSize =3D = htole32(XHCI_MAX_EVENTS); >> result was not observed by xhci but needs to be observed at that ring >> start time. >> Without the DSB ST above, xhci_interrupt_poll's code (with one >> of my additions shown): >> #ifdef __aarch64__ >> __asm __volatile("dsb ld" : : : "memory"); >> #endif >=20 > Probably same bug in the USB invalidate function. >=20 > Try to patch those generic flush/invalidate functions instead. I've = been very careful about those. Sure. >> temp =3D le32toh(phwr->hwr_events[i].dwTrb3); >> k =3D (temp & XHCI_TRB_3_CYCLE_BIT) ? 1 : 0; >> if (j !=3D k) >> break; >> always took the break because temp was always zero, k was always = zero, >> and j was 1. I expect this is because the wrong qwEvrsTablePtr and >> dwEvrsTableSize content was in use by the xhci (fixed by the DSB ST). >> (I had a temporarily version that printed the values. With and = without >> the DSB LD made no difference without the DSB ST that was later = added.) >> =46rom what I understand, the cortex-a72 has far more structure that >> involves the "DSB completes when" behavior being needed compared >> to the cortex-a53 and code tuned to the A72 is more likely to end >> up needing such. (Speculation and speculative-driven cache contents, >> out of order execution, and probably more.) >> QUOTE >> =E2=80=A2 all explicit memory accesses that are observed by Pe = before the DSB is executed, are of the required access types, and are = from observers in the same required shareability domain as Pe, are = complete for the set of observers in the required shareability domain >> =E2=80=A2 all cache, branch predictor, and TLB maintenance = operations issued by Pe before the DSB are complete for the required = shareability domain. >> END QUOTE >=20 > It smells like a generic problem in the busdma synchronize code. >=20 >> (Pe means "executing processor".) >> I expect the removal of that specific DSB ST to result in >> xhci_interrupt_poll's code again taking the break every time, >> just based on event ring behavior alone. >=20 > Again, try to patch both > usb_pc_cpu_flush() > and > usb_pc_cpu_invalidate() Sure. >> I'll note that the RPi4B SBC has a not-physically-exposed PCIe >> that the USB3 is off of, and the UEFI/ACPI that I have in use for >> the RPi4B does not expose the PICe to the loader or OS at all. >> ACPI does expose the USB3 related material. FYI: The buildworld buildkernel is continuing. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Sep 19 16:23:08 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 29ABE3E71D0 for ; Sat, 19 Sep 2020 16:23:08 +0000 (UTC) (envelope-from crowston@protonmail.com) Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) (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 "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Btwwp6b3Cz48tW for ; Sat, 19 Sep 2020 16:23:06 +0000 (UTC) (envelope-from crowston@protonmail.com) Date: Sat, 19 Sep 2020 16:23:01 +0000 To: tech-lists From: Robert Crowston Cc: "freebsd-arm@freebsd.org" Reply-To: Robert Crowston Subject: Re: onboard wireless on rpi4 Message-ID: In-Reply-To: <20200905234313.GH80905@bastion.zyxst.net> References: <20200904134619.GB80905@bastion.zyxst.net> <69934262-D9D3-4986-849D-9E8221D1E387@kronometrix.org> <1677459627.55.1599232125847@localhost> <75E08DC2-D229-45AA-85AE-CCF06FD0B490@kronometrix.org> <09959D86-E3E3-43E9-8134-C2FC73343DBA@lists.zabbadoz.net> <20200905181220.GG80905@bastion.zyxst.net> <20200905234313.GH80905@bastion.zyxst.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch X-Rspamd-Queue-Id: 4Btwwp6b3Cz48tW X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.24 / 15.00]; HAS_REPLYTO(0.00)[crowston@protonmail.com]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[protonmail.com]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; RWL_MAILSPIKE_GOOD(0.00)[185.70.40.133:from]; DKIM_TRACE(0.00)[protonmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine]; NEURAL_HAM_SHORT(-1.20)[-1.198]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[protonmail.com]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.02)[-1.021]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.02)[-1.024]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[protonmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[185.70.40.133:from]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2020 16:23:08 -0000 Do you have a serial cable to get the console output? It would be handy to = have the boot output. =E2=80=94 RHC. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Sunday, 6 September 2020 00:43, tech-lists wrote: > On Sat, Sep 05, 2020 at 07:11:53PM +0100, tech-lists wrote: > > > On Sat, Sep 05, 2020 at 12:15:06PM +0000, Bjoern A. Zeeb wrote: > > > > > Two things which may help for the RPi/SDIO parts are: > > > > > > - please try and use MMCCAM kernels and help, test, debug, report, = .. > > > all the things you find so (other people) can jump in as well so = we can > > > switch that on as default. Without that, no SDIO. > > > > > > > Sure, it'll be the next thing i build on rpi4 after it's finished portm= aster. > > Will you need a dmesg posted somewhere? > > Have to admit i've never built MMCCAM kernel before for rpi 1,2b+ or 3b= +. > > What's significant about it? > > GENERIC-MMCCAM built and installed without error but breaks to ddb when t= he > kernel tries to load [1] I can see it by attaching a screen to HDMI. I ha= ve an FTDI usb serial device converter (built into the serial cable) is the= re any way i can grab output from there? or is the output written somewhere= on the card where I can look at it? > > [1] in other words it passes the u-boot phase, gets past where it detects= cpu, > then loads of errors zoom off the screen nd then ddb> prompt > -- > J. From owner-freebsd-arm@freebsd.org Sat Sep 19 18:47:09 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C5C693EBA78 for ; Sat, 19 Sep 2020 18:47:09 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bv0705CHLz4LTh for ; Sat, 19 Sep 2020 18:47:08 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id E573E86F for ; Sat, 19 Sep 2020 14:47:06 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sat, 19 Sep 2020 14:47:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=dw1H1Yr9leCtt0I5H1He6PFZCL4 NRysnNSB2fEOTPuQ=; b=fQyZ1RSCjrkrKVUGU+B7Ww+U/rPHSRwzD1Gxth2fLU4 sJCD4RajQ5+t7TvmAmYrvBHNhDoUSN98sj6NYYJM+4ON7OiTAlrX7ydnEi27RjUC 0iUnHDN5KYUzxNozXxruvSKB8Yz8tqxuMS3QHR/LOPb6GENxRNjZE1P1WLt3nQdN fAur3UwJqtNWGGxRceOyqhS7KOumzVtHcloQfDmq2GAccjq7sFlnmbf6onK5rYSr 7oka/81e06akmCZFnCoj01aftktmG9le8Bq95KhoICqJyx9f8dfZ6xCxRDaoZID/ vEAsYz+5Nkxibe0/Jzf8CF6vicmkHAOPdNPTvq7QzoA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=dw1H1Y r9leCtt0I5H1He6PFZCL4NRysnNSB2fEOTPuQ=; b=S/ywGuQjgKlxtZUq4P5GAw 92yYNFCghyfHzkWMW9Tk/0EvfExzlstTGyJMDu/LciwSPXTZqKNon/aFtXJHRMRX LN1hJMkPdeezlrBu4H0/nXDe7uW2gmEugkuYScDFU0NOTF3zOKExkOGJi7oGdihA /ncWVNA6tqQkyIc1st3GEUJx7dSK58smLFLXfh2MLbmZsY0HUGWVh2K+OTxzMiDk lgPYvpPBIYA03jKk3gAxeNMn8Kfj8I+HC/GpL9MQAmqLlgWeI0aiiLx9XyOxmjrA YTK6aCT9uKjDILD1mdxsVXGtFuLqUFkp1n/BhDdA2zcIMB0hJwG4LEMeHmkR2C/A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrtdekgddufedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesghdtre ertddtvdenucfhrhhomhepthgvtghhqdhlihhsthhsuceothgvtghhqdhlihhsthhsseii hiigshhtrdhnvghtqeenucggtffrrghtthgvrhhnpedtheeigfdvudefkeekvddtfedvte dttdekuddvgeevlefftdekffdujedvhfduteenucfkphepkedvrdejtddrledurdelleen ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehtvggthh dqlhhishhtshesiiihgihsthdrnhgvth X-ME-Proxy: Received: from bastion.zyxst.net (bastion.zyxst.net [82.70.91.99]) by mail.messagingengine.com (Postfix) with ESMTPA id E7C203064610 for ; Sat, 19 Sep 2020 14:47:05 -0400 (EDT) Date: Sat, 19 Sep 2020 19:46:37 +0100 From: tech-lists To: "freebsd-arm@freebsd.org" Subject: Re: onboard wireless on rpi4 Message-ID: <20200919184637.GA27098@bastion.zyxst.net> Mail-Followup-To: "freebsd-arm@freebsd.org" References: <20200904134619.GB80905@bastion.zyxst.net> <69934262-D9D3-4986-849D-9E8221D1E387@kronometrix.org> <1677459627.55.1599232125847@localhost> <75E08DC2-D229-45AA-85AE-CCF06FD0B490@kronometrix.org> <09959D86-E3E3-43E9-8134-C2FC73343DBA@lists.zabbadoz.net> <20200905181220.GG80905@bastion.zyxst.net> <20200905234313.GH80905@bastion.zyxst.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AhhlLboLdkugWU4S" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4Bv0705CHLz4LTh X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm3 header.b=fQyZ1RSC; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=S/ywGuQj; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 64.147.123.25 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-5.99 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm3,messagingengine.com:s=fm3]; NEURAL_HAM_MEDIUM(-1.03)[-1.033]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[64.147.123.25:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.25]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[zyxst.net]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.07)[-1.074]; RCVD_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.18)[-1.179]; TO_DN_EQ_ADDR_ALL(0.00)[]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:11403, ipnet:64.147.123.0/24, country:US]; MAILMAN_DEST(0.00)[freebsd-arm]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.25:from] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2020 18:47:09 -0000 --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 19, 2020 at 04:22:34PM +0000, Robert Crowston wrote: > Do you have a serial cable to get the console output? It would be handy= =20 > to have the boot output. alas, not a suitable one. Seems I need a serial (or usb masquerading as=20 serial) to tty cable for serial console output, from three GPIO pins on=20 the pi. =20 I hoped it was possible to get the output to ethernet port on the rpi but= =20 I don't know how. Think I need tty to serial/usb cable, unless you=20 know of a different method? Somehow make the ethernet port output console= =20 output? The one I already have is an FTDI usb <> rj45 console cable suitabl= e=20 for eg cisco equipment. anyway, should be getting said (usb/serial<>tty) cable in a few days though= ,=20 hopefully. --=20 J. --AhhlLboLdkugWU4S Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAl9mUh4ACgkQs8o7QhFz NAWDEA/9H1fdDVq1RNWFNiUK2wF7VzcugbfXqazU8OjC2wfCukV66NYBp1BDImbl fn1Cn3BYxdw378j4l+F3OZ4sfQQZpPeLqBv8YGF2wTD3tOl5edYqlc0VgnKqFd9o fZr13oY4N0kz7H/rjveKn7iJ60HsqwyIrWZQQRimJBqnjAG3RMIy1CYed5ahOioV tR8Zhh/nRGXRThNVjxjjGS040yZ/ZjtHZOoAye7BbnGuVLDUbwAFV7TolP4LvdND D2EaFaD/cQqkL2y162Ls5JuPpfC8qbEukUykyCIO7+o/g/4GLNWcyoqBVPv2vjlZ 2AErt8OXAiHMSdq50Z4gLOuYEyqKYi0d28enyl8YuECr0ipMVJhLyldMGrbuiMFG 5Fy15UMJ0Ah+5KrE0qy7G2fjp3cuRPS9cX4gYoAowX0izs+Ff9esWls2WbMDbRXS 9yc48wRcn3aDQCb4TSFK2n+8If1EePiVCj57s7eTRoLMU1ugqL+sV8SxsFUEeFAn KNL0WPX+MNTDV6yIJZDc9GL6q9zBYipSrzunNydKs/XVcfBszy3y2tScRdvnOwJ5 DuG2ywBWPJbQ6Rb6ALCRc79sm8c3q6qpjPj1y1YwvQcMeRh4XvebxxWdHFW3HSmK i+f17xBh1Fd6nWzwBOu6Cgi28Mw8U3FqeJMz7OWgOywxUwpgA3g= =xP/3 -----END PGP SIGNATURE----- --AhhlLboLdkugWU4S-- From owner-freebsd-arm@freebsd.org Sat Sep 19 19:18:55 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D14B73EC74C for ; Sat, 19 Sep 2020 19:18:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bv0qf6nHYz4N6X for ; Sat, 19 Sep 2020 19:18:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: UeCunM0VM1kYoboDWTqh68AXJnIUx5y4VBMzEw_WZdyNSmJuGJ4U1sDLu849ZtB EHz6BTGvmyC8vlDQvZ9dpqVTDawaJ00VMWW_ESJDMgo.hKFfCxVEefxd0uDS__7z3ULEkhipuQVH 6dIqBXsqr7GEXpn6ozj6JLw.0Cnj7oybZq9S2fGcO8XX5C5VcJajflYSWgezq7a2Ioq9ZOdtHNFr XAd32lzydIjR1_5ATOsZ4yZEIZoegrAYOnFUBC7.ZAnOjscqf7jG6nhQUlPAYvL8e5xTNjY3jbHA N_KGOCbdlTyh8jAqX.I3J5VQq4747WKbDvaepd_4McJOOe9FF3LdAuDtpMHcJakEDqsbwcX7LqmL 2.zbD_mh7zzPOfhjPzkHzdrmeRgd.__a2CGcp19lfvVeTwJnseJUXOrpYXothqxdKC3YCTe_d4lu qtD1GNJkP6MtoFNRQZU30HiKmXuupbmauAmJWFPrrYatF3sSNFhqIMzfetT_77vmoVaSx0qge1WZ zkoKSbbXpZNAF0wzF4hPnXjmzmzutKMpijt4lNpSsMzPalp875lN.EKma07CeqMyluH9rBj0aMGU bipU8FODDdDv4PDskmxEVDev_JjDqyLG3igigJTY4cOJqYz0pzq0Yl47ynoGPWyeqttY7u8k2Zzr bQVoSayisey_VGlZ_hO3hhnYJL3NZSOjqgTi3RiNWR.rz7IdQdFzV.5URV5UGlTH3tuJghpLnSKI www4mvjgLF5zc8e3tvwXvaTKIwcp6cYKPJuz.5g0yLU9_hv8qe2gunxDo20lvaqdcmBV6jxo7Bid nJpGKFT9B77cRI8RoEHZS8c06FU8ffZ6lY66naMrZgE8_neLkSNNE3V8hZGnWncyOkKCtHcilxFr ffPPgD29JtutDhDVooiHFm8qYDv2l2SMHh0QeQec8D7NZb8nmNsYT6u7uJ2MPgqei4eKirJrgCAa wvPJifsUsISqzOy.wubZnn.OoWBVnAJAPrTV3fPC8kz3KinjdMuTHVD6lcmXwEX1a2CTELcgL7x0 uIikZ8UhzSCUIJbOTcBk4O8iI8vn4DEhl.oGN.HEBpWudjD99YjWuCgGE38supSRp6yXR09urnrX bYqgANNFbdyKinJ8_1lB360dqRNi50snCMiurqF4SBIaieOPm2aiUAk.jK0S9Fmhxcs2S7G.lhPZ jjWS_R7EsIXZBwhZFEZEWdlJt_RewRQ8JG5AwJ9GuHf8dIF.cooTORqfoCP5KK6KmWO2GJHSPpRd Wyfrf.WRsi4E3KhxQWf3qqbsYE1pPKJzfqzh4zUxLZ.EcX6jxpkoc_P8s0eFxrFdZAuj_1iU599W CQzMIT9wOf2ABLSRyvZh.EbX6D7wytaI8fvm1HNucm8a2HP4CbGpAy3oEZasZg8rwQZOgoShtI.Z 9dzioB25IxK3E6QZowAjTCN1aISfQby_CGlPadWIU6Fg.dRhh.Pd6rWDRWb3A..7ZohnihxEsFNZ VfMq9.aYAyqhrpxeboMfMweQ149zxAhjj4F6c4umTiSxtXqo5GwibiWaJYbdEqS3bv8Z5Ysx8t6Z hrdAPLhoaaKk176ADZSaHPuDxxA.Hiqi2hA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sat, 19 Sep 2020 19:18:52 +0000 Received: by smtp401.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID ee9a2c4f9bc944b2d10ac9f074e682aa; Sat, 19 Sep 2020 19:18:51 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: Comment #135 for bugzilla 237666 : a USB3-handling problem with a investigatory fix for a cortex-a72 context From: Mark Millard In-Reply-To: <723E6915-94F5-417C-B4AF-EEEBFBDF6162@yahoo.com> Date: Sat, 19 Sep 2020 12:18:50 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <565258A0-BEE1-48F8-9851-E6C7CF7ADAE7@yahoo.com> References: <6E618C3D-12DF-429E-A249-5BAB90FC6B15.ref@yahoo.com> <6E618C3D-12DF-429E-A249-5BAB90FC6B15@yahoo.com> <866bd652-5a8b-7500-b1e0-7528c035048b@selasky.org> <578faf26-6042-91ec-c639-2bca17105fae@selasky.org> <723E6915-94F5-417C-B4AF-EEEBFBDF6162@yahoo.com> To: Hans Petter Selasky X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4Bv0qf6nHYz4N6X X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.61 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.06)[-1.065]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.03)[-1.029]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.02)[-1.020]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.148:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2020 19:18:55 -0000 In the below I've cut out text without always indicating where so that code looks complete that is complete. I've also included some text from another reply of yours that fills in some specifics of what you were after. On 2020-Sep-19, at 04:46, Hans Petter Selasky = wrote: >=20 >>>> . . . >>>>=20 >>>> Your finding indicate a problem in usb_pc_cpu_flush() and >>>>=20 >>>> bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREWRITE); >>>>=20 >>>> Try to put the dsb only after dmamap_sync. >>>>=20 >>>> void >>>> usb_pc_cpu_flush(struct usb_page_cache *pc) >>>> { >>>> if (pc->page_offset_end =3D=3D pc->page_offset_buf) { >>>> /* nothing has been loaded into this page cache! */ >>>> return; >>>> } >>>> bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREWRITE); >>>> } >>>> . . . >>> After adding a couple of more DSB ST instructions and rebuilding >>> (cross build), installing, and booting, I started a self-hosted, >>> from-scratch, buildworld buildlkernel and intend to installkernel >>> installworld and reboot if it appears to go well. (Better than >>> just a boot test for if things seem at least sufficient, even if >>> overkill.) But it will be hours before buildworld build kernel is >>> done (-j3). (I'll sleep during much of that time.) The buildworld buildkernel, installkernel installworld, reboot sequence seems to have gone fine. >>> . . . >>> phwr =3D buf_res.buffer; >>> addr =3D buf_res.physaddr; >>> addr +=3D (uintptr_t)&((struct xhci_hw_root = *)0)->hwr_events[0]; >>> /* reset hardware root structure */ >>> memset(phwr, 0, sizeof(*phwr)); >>> phwr->hwr_ring_seg[0].qwEvrsTablePtr =3D = htole64(addr); >>> phwr->hwr_ring_seg[0].dwEvrsTableSize =3D = htole32(XHCI_MAX_EVENTS); >>> DPRINTF("ERDP(0)=3D0x%016llx\n", (unsigned long = long)addr); >>> #ifdef __aarch64__ >>> __asm __volatile("dsb st" : : : "memory"); >>> #endif >>> XWRITE4(sc, runt, XHCI_ERDP_LO(0), (uint32_t)addr); >>> XWRITE4(sc, runt, XHCI_ERDP_HI(0), (uint32_t)(addr >> 32)); >>> addr =3D buf_res.physaddr; >>> DPRINTF("ERSTBA(0)=3D0x%016llx\n", (unsigned long = long)addr); >>> XWRITE4(sc, runt, XHCI_ERSTBA_LO(0), (uint32_t)addr); >>> XWRITE4(sc, runt, XHCI_ERSTBA_HI(0), (uint32_t)(addr >> 32)); >> . . . >> Probably same bug in the USB invalidate function. >> On 2020-09-19 11:31, Mark Millard wrote: >>> #ifdef __aarch64__ >>> __asm __volatile("dsb ld" : : : "memory"); >>> #endif >>> temp =3D le32toh(phwr->hwr_events[i].dwTrb3); >>> =20 >>=20 >>=20 >> If you look a few lines up you'll find the: >>=20 >> usb_pc_cpu_invalidate(&sc->sc_hw.root_pc); >>=20 >> That's where this instruction belongs. >> Try to patch those generic flush/invalidate functions instead. I've = been very careful about those. >=20 > Sure. >=20 >>> temp =3D le32toh(phwr->hwr_events[i].dwTrb3); >>> k =3D (temp & XHCI_TRB_3_CYCLE_BIT) ? 1 : 0; >>> if (j !=3D k) >>> break; >>> always took the break because temp was always zero, k was always = zero, >>> and j was 1. I expect this is because the wrong qwEvrsTablePtr and >>> dwEvrsTableSize content was in use by the xhci (fixed by the DSB = ST). >>> . . . >>=20 >> It smells like a generic problem in the busdma synchronize code. >>=20 >>> (Pe means "executing processor".) >>> I expect the removal of that specific DSB ST to result in >>> xhci_interrupt_poll's code again taking the break every time, >>> just based on event ring behavior alone. >>=20 >> Again, try to patch both >> usb_pc_cpu_flush() >> and >> usb_pc_cpu_invalidate() >=20 > Sure. >=20 Unfortunately, it fails the same old way as far as what is seen on the console. So the steps used were: I reverted /usr/src/sys/dev/usb/controller/xhci.c . Then changed things so that: # svnlite diff /usr/src/sys/dev/usb/usb_busdma.c Index: /usr/src/sys/dev/usb/usb_busdma.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/dev/usb/usb_busdma.c (revision 363590) +++ /usr/src/sys/dev/usb/usb_busdma.c (working copy) @@ -737,6 +737,9 @@ */ bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_POSTREAD); bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREREAD); +#ifdef __aarch64__ +__asm __volatile("dsb ld" : : : "memory"); +#endif } =20 = /*------------------------------------------------------------------------= * @@ -750,6 +753,9 @@ return; } bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREWRITE); +#ifdef __aarch64__ +__asm __volatile("dsb st" : : : "memory"); +#endif } =20 = /*------------------------------------------------------------------------= * As I expected, the resulting build fails to boot the same old way: a sequence messages that repeats indefinitely and involves "xhci0: Resetting controller" and no root file system mount happens. So I put back the just last change that had previously lead to the successful booting (given the prior DSB ST / DSB LD additions). I did so exactly as I originally had it: # svnlite diff /usr/src/sys/dev/usb/controller/xhci.c Index: /usr/src/sys/dev/usb/controller/xhci.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/dev/usb/controller/xhci.c (revision 363590) +++ /usr/src/sys/dev/usb/controller/xhci.c (working copy) @@ -406,6 +406,9 @@ =20 addr =3D buf_res.physaddr; =20 +#ifdef __aarch64__ +__asm __volatile("dsb st" : : : "memory"); +#endif XWRITE4(sc, oper, XHCI_DCBAAP_LO, (uint32_t)addr); XWRITE4(sc, oper, XHCI_DCBAAP_HI, (uint32_t)(addr >> 32)); XWRITE4(sc, oper, XHCI_DCBAAP_LO, (uint32_t)addr); The result still fails. So more is required. I'll do some exploring to try to find a combination that has fewer DSB ST / DSB LD changes in usb/controller/xhci.c than my original A72 success, leaving the usb/usb_busdma.c patch in place. It may take a while for me to have a successful result to report. Side note: The from-scratch buildworld buildkernel reported: World built in 37469 seconds, ncpu: 4, make -j3 Kernel(s) GENERIC-NODBG built in 2474 seconds, ncpu: 4, make -j3 which totals to somewhat over 1hr 50min faster than the last time I did such a -j3 from-scratch rebuild on the same RPi4B: World built in 44034 seconds, ncpu: 4, make -j3 Kernel(s) GENERIC-NODBG built in 2895 seconds, ncpu: 4, make -j3 Both were based on a head -r363590 variation rebuilding itself but the newer build is based on everything being -mcpu=3Dcortex-a72 based already in the running system. (Same over_voltage=3D6 and arm_freq=3D2000 setting in use both times.) (I can cross build, which does not take long.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Sep 19 19:36:18 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0E0653ECD48 for ; Sat, 19 Sep 2020 19:36:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-20.consmr.mail.gq1.yahoo.com (sonic317-20.consmr.mail.gq1.yahoo.com [98.137.66.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bv1Ch5GHNz4NZ8 for ; Sat, 19 Sep 2020 19:36:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: h2YTsV4VM1kP6eUhlNIRnL9T1F9icas4PVbNi_C_juQi3OrcgO7Yo9k6dumGGeN uyq_uKY0AVVLwco_OVwsDRxylgx9PPAO3gzLlN8nIS1xql6f7lpB0y24aTXZI1xWMnrrbyWuW5rW IHj9kJ.xZzZOMDb1ce3yYGwb8YE3tfhdP5XLUPS0.ZSwcocM2fi9ai6G2bAWxF8Ycujh.0qqPBE_ DAcSJOH3Gi8oEP8piQwxxBAjlstywdqc.GC1YmQ7H_si_O6nKRX6DzzQJfJwrTBaJNoy321761b_ yAn57o3V.LlkQHzXkioRw0N3Kdw7ChTFOe8rJ2eLree4dOqxlJK2o3Sbkesa2EtoPw.VtaiaC_0d 2au4zvSeydCC_OETacZ_hXXuT_zy9VR8uwcJ5sa9j6gAbHOeK_DB712K2l9hFHpA5BmT2CbQSCi7 7CQc93qj8ONyBUiNVj8uu3t7.Yqvltcug93zdaooHH8UxpZCEaUaT1NSxCXDezX9NqUL3lZHev2n xyh6_s9leg0pJP_wNx9UuXXkxyA3LMCEX1DmYQr_MJKxNLwOYUgWUFoXVHX2LCphJAoPnx2W6fX0 rpSee67FAPwwGyY8X6dUxWqmzN7AEgB9ldWQMv4.0MrPmS_F6awSVHVALV5Lzb11ichtLjoWES02 IQrSmDS83nN_E9AnElZSam46Y7Znaw.fUhEpsiQCV3RJjOP2hVjQ_brXv1RInjSExj7McUObZOdD dWJJuELKq3GMtTsdqX.0B3FupsPWH3qL_dMgtK4xSB7nOEfccXeoDZA4B66ABBl8BhdKHArIc81a E9c49J3t_qG70oIjIKzswSnovVCN6smuxXFPTf.lYgI10E7Jib4CvXA6DNWVNSjCkTHtnwC27J7E KO5mowstVMgkRGmF5sgTxUmEXm0h7.tUcxir.5LArnCUd9KSst_Yc5Y2bB0o6f1rpvKrxu5mWYQG M35CiVt1vGpkB9bNHz7dIflX9hWDzXE5qD5s8LJQq8X4qStHw2pRAk_63PYuYd8tFTbklcJWx_Ht 8kZxtTJPgNUaiU5DPLY4aFyiQHwTj93GbmunJS5hd_TNXboQPtq3Ma66NXweU.YM682lcqNSq1Az zeLeipZwimTU5hzspyO70MAonkSwCD8jHmZNeDuqjqeCkrXRSBY_Vkh6AVH7zOHSN_COz43h6Y4u ayBxL__MI0jozQOgGPrpFxZwDGSuNG0PghjjU3ogo1o_xWO33BFcuCtYdqcTfyXr9Vk5s8AKWCkp mNN6qvuLqJazJy957ZMY44Hof6PbeUmczaaD5pQNglHM2PrVnoF2yBmTpoDkrYkGjnsTzvAhRbuM 4zUuBOda7tHVMfPYlUQqlqVkw8a8MhPZFoQOWmmmhmUmUx.pFz_dKATzAeLl5.MC6rWlFbPPb_z6 ZeG_Br3sh4wR982j8sh.IE6jLIjxzHCFcPVOi8RcONSLRvIJrdutX4qzyqvpHr2Hy1Y8QkLNFftY nQHucGpro4HnWpawpAJEY0bGwl3S6iEqzDQamIos4Pzb8AJnDeBHG0kmFNnVxqmRzpRtRc65vvw- - Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sat, 19 Sep 2020 19:36:15 +0000 Received: by smtp416.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 33427ed027752951165d58eb60314798; Sat, 19 Sep 2020 19:36:10 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: Comment #135 for bugzilla 237666 : a USB3-handling problem with a investigatory fix for a cortex-a72 context From: Mark Millard In-Reply-To: <565258A0-BEE1-48F8-9851-E6C7CF7ADAE7@yahoo.com> Date: Sat, 19 Sep 2020 12:36:10 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <6E618C3D-12DF-429E-A249-5BAB90FC6B15.ref@yahoo.com> <6E618C3D-12DF-429E-A249-5BAB90FC6B15@yahoo.com> <866bd652-5a8b-7500-b1e0-7528c035048b@selasky.org> <578faf26-6042-91ec-c639-2bca17105fae@selasky.org> <723E6915-94F5-417C-B4AF-EEEBFBDF6162@yahoo.com> <565258A0-BEE1-48F8-9851-E6C7CF7ADAE7@yahoo.com> To: Hans Petter Selasky X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4Bv1Ch5GHNz4NZ8 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.62 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.07)[-1.067]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.03)[-1.029]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.02)[-1.020]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.146:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.146:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2020 19:36:18 -0000 > On 2020-Sep-19, at 12:18, Mark Millard wrote: >=20 > In the below I've cut out text without always indicating > where so that code looks complete that is complete. I've > also included some text from another reply of yours that > fills in some specifics of what you were after. >=20 > On 2020-Sep-19, at 04:46, Hans Petter Selasky = wrote: >>=20 >>>>> . . . >>>>>=20 >>>>> Your finding indicate a problem in usb_pc_cpu_flush() and >>>>>=20 >>>>> bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREWRITE); >>>>>=20 >>>>> Try to put the dsb only after dmamap_sync. >>>>>=20 >>>>> void >>>>> usb_pc_cpu_flush(struct usb_page_cache *pc) >>>>> { >>>>> if (pc->page_offset_end =3D=3D pc->page_offset_buf) { >>>>> /* nothing has been loaded into this page cache! */ >>>>> return; >>>>> } >>>>> bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREWRITE); >>>>> } >>>>> . . . >>>> After adding a couple of more DSB ST instructions and rebuilding >>>> (cross build), installing, and booting, I started a self-hosted, >>>> from-scratch, buildworld buildlkernel and intend to installkernel >>>> installworld and reboot if it appears to go well. (Better than >>>> just a boot test for if things seem at least sufficient, even if >>>> overkill.) But it will be hours before buildworld build kernel is >>>> done (-j3). (I'll sleep during much of that time.) >=20 > The buildworld buildkernel, installkernel installworld, reboot > sequence seems to have gone fine. >=20 >>>> . . . >>>> phwr =3D buf_res.buffer; >>>> addr =3D buf_res.physaddr; >>>> addr +=3D (uintptr_t)&((struct xhci_hw_root = *)0)->hwr_events[0]; >>>> /* reset hardware root structure */ >>>> memset(phwr, 0, sizeof(*phwr)); >>>> phwr->hwr_ring_seg[0].qwEvrsTablePtr =3D = htole64(addr); >>>> phwr->hwr_ring_seg[0].dwEvrsTableSize =3D = htole32(XHCI_MAX_EVENTS); >>>> DPRINTF("ERDP(0)=3D0x%016llx\n", (unsigned long = long)addr); >>>> #ifdef __aarch64__ >>>> __asm __volatile("dsb st" : : : "memory"); >>>> #endif >>>> XWRITE4(sc, runt, XHCI_ERDP_LO(0), (uint32_t)addr); >>>> XWRITE4(sc, runt, XHCI_ERDP_HI(0), (uint32_t)(addr >> 32)); >>>> addr =3D buf_res.physaddr; >>>> DPRINTF("ERSTBA(0)=3D0x%016llx\n", (unsigned long = long)addr); >>>> XWRITE4(sc, runt, XHCI_ERSTBA_LO(0), (uint32_t)addr); >>>> XWRITE4(sc, runt, XHCI_ERSTBA_HI(0), (uint32_t)(addr >> 32)); >>> . . . >>> Probably same bug in the USB invalidate function. >=20 >>> On 2020-09-19 11:31, Mark Millard wrote: >>>> #ifdef __aarch64__ >>>> __asm __volatile("dsb ld" : : : "memory"); >>>> #endif >>>> temp =3D le32toh(phwr->hwr_events[i].dwTrb3); >>>>=20 >>>=20 >>>=20 >>> If you look a few lines up you'll find the: >>>=20 >>> usb_pc_cpu_invalidate(&sc->sc_hw.root_pc); >>>=20 >>> That's where this instruction belongs. >=20 >>> Try to patch those generic flush/invalidate functions instead. I've = been very careful about those. >>=20 >> Sure. >>=20 >>>> temp =3D le32toh(phwr->hwr_events[i].dwTrb3); >>>> k =3D (temp & XHCI_TRB_3_CYCLE_BIT) ? 1 : 0; >>>> if (j !=3D k) >>>> break; >>>> always took the break because temp was always zero, k was always = zero, >>>> and j was 1. I expect this is because the wrong qwEvrsTablePtr and >>>> dwEvrsTableSize content was in use by the xhci (fixed by the DSB = ST). >>>> . . . >>>=20 >>> It smells like a generic problem in the busdma synchronize code. >>>=20 >>>> (Pe means "executing processor".) >>>> I expect the removal of that specific DSB ST to result in >>>> xhci_interrupt_poll's code again taking the break every time, >>>> just based on event ring behavior alone. >>>=20 >>> Again, try to patch both >>> usb_pc_cpu_flush() >>> and >>> usb_pc_cpu_invalidate() >>=20 >> Sure. >>=20 >=20 > Unfortunately, it fails the same old way as far as > what is seen on the console. >=20 > So the steps used were: >=20 > I reverted /usr/src/sys/dev/usb/controller/xhci.c . >=20 > Then changed things so that: >=20 > # svnlite diff /usr/src/sys/dev/usb/usb_busdma.c > Index: /usr/src/sys/dev/usb/usb_busdma.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/dev/usb/usb_busdma.c (revision 363590) > +++ /usr/src/sys/dev/usb/usb_busdma.c (working copy) > @@ -737,6 +737,9 @@ > */ > bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_POSTREAD); > bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREREAD); > +#ifdef __aarch64__ > +__asm __volatile("dsb ld" : : : "memory"); > +#endif > } >=20 > = /*------------------------------------------------------------------------= * > @@ -750,6 +753,9 @@ > return; > } > bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREWRITE); > +#ifdef __aarch64__ > +__asm __volatile("dsb st" : : : "memory"); > +#endif > } >=20 > = /*------------------------------------------------------------------------= * >=20 >=20 > As I expected, the resulting build fails to boot the same old > way: a sequence messages that repeats indefinitely and > involves "xhci0: Resetting controller" and no root file system > mount happens. >=20 > So I put back the just last change that had previously lead to > the successful booting (given the prior DSB ST / DSB LD > additions). I did so exactly as I originally had it: >=20 > # svnlite diff /usr/src/sys/dev/usb/controller/xhci.c > Index: /usr/src/sys/dev/usb/controller/xhci.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/dev/usb/controller/xhci.c (revision 363590) > +++ /usr/src/sys/dev/usb/controller/xhci.c (working copy) > @@ -406,6 +406,9 @@ >=20 > addr =3D buf_res.physaddr; >=20 > +#ifdef __aarch64__ > +__asm __volatile("dsb st" : : : "memory"); > +#endif > XWRITE4(sc, oper, XHCI_DCBAAP_LO, (uint32_t)addr); > XWRITE4(sc, oper, XHCI_DCBAAP_HI, (uint32_t)(addr >> 32)); > XWRITE4(sc, oper, XHCI_DCBAAP_LO, (uint32_t)addr); >=20 > The result still fails. So more is required. The controller/xhci.c change above was the wrong one: I grabbed the wrong text. Retrying with: # svnlite diff /usr/src/sys/dev/usb/controller/xhci.c Index: /usr/src/sys/dev/usb/controller/xhci.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/dev/usb/controller/xhci.c (revision 363590) +++ /usr/src/sys/dev/usb/controller/xhci.c (working copy) @@ -441,6 +441,9 @@ =20 DPRINTF("ERSTBA(0)=3D0x%016llx\n", (unsigned long long)addr); =20 +#ifdef __aarch64__ +__asm __volatile("dsb st" : : : "memory"); +#endif XWRITE4(sc, runt, XHCI_ERSTBA_LO(0), (uint32_t)addr); XWRITE4(sc, runt, XHCI_ERSTBA_HI(0), (uint32_t)(addr >> 32)); =20 booted just fine. This is what I expected relative to initializing for the event ring. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Sep 19 19:45:41 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 026373ED052 for ; Sat, 19 Sep 2020 19:45:41 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 4Bv1QW31XPz4P8c for ; Sat, 19 Sep 2020 19:45:39 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [178.17.145.105]) (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 mail.turbocat.net (Postfix) with ESMTPSA id 5272D26023E; Sat, 19 Sep 2020 21:45:37 +0200 (CEST) Subject: Re: Comment #135 for bugzilla 237666 : a USB3-handling problem with a investigatory fix for a cortex-a72 context To: Mark Millard Cc: freebsd-arm References: <6E618C3D-12DF-429E-A249-5BAB90FC6B15.ref@yahoo.com> <6E618C3D-12DF-429E-A249-5BAB90FC6B15@yahoo.com> <866bd652-5a8b-7500-b1e0-7528c035048b@selasky.org> <578faf26-6042-91ec-c639-2bca17105fae@selasky.org> <723E6915-94F5-417C-B4AF-EEEBFBDF6162@yahoo.com> <565258A0-BEE1-48F8-9851-E6C7CF7ADAE7@yahoo.com> From: Hans Petter Selasky Message-ID: <75af04ec-0021-3575-40bf-c5ab9b6d4703@selasky.org> Date: Sat, 19 Sep 2020 21:45:05 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Bv1QW31XPz4P8c X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-2.94 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; NEURAL_HAM_LONG(-1.00)[-1.005]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.63)[-0.630]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.01)[-1.006]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2020 19:45:41 -0000 On 2020-09-19 21:36, Mark Millard wrote: > # svnlite diff /usr/src/sys/dev/usb/controller/xhci.c > Index: /usr/src/sys/dev/usb/controller/xhci.c > =================================================================== > --- /usr/src/sys/dev/usb/controller/xhci.c (revision 363590) > +++ /usr/src/sys/dev/usb/controller/xhci.c (working copy) > @@ -441,6 +441,9 @@ > > DPRINTF("ERSTBA(0)=0x%016llx\n", (unsigned long long)addr); > > +#ifdef __aarch64__ > +__asm __volatile("dsb st" : : : "memory"); > +#endif > XWRITE4(sc, runt, XHCI_ERSTBA_LO(0), (uint32_t)addr); > XWRITE4(sc, runt, XHCI_ERSTBA_HI(0), (uint32_t)(addr >> 32)); > > booted just fine. This is what I expected relative to > initializing for the event ring. Can you replace this with a USB flush call? > Index: xhci.c > =================================================================== > --- xhci.c (revision 365238) > +++ xhci.c (working copy) > @@ -432,6 +432,8 @@ > phwr->hwr_ring_seg[0].qwEvrsTablePtr = htole64(addr); > phwr->hwr_ring_seg[0].dwEvrsTableSize = htole32(XHCI_MAX_EVENTS); > > + usb_bus_mem_flush_all(&sc->sc_bus, &xhci_iterate_hw_softc); > + > DPRINTF("ERDP(0)=0x%016llx\n", (unsigned long long)addr); > > XWRITE4(sc, runt, XHCI_ERDP_LO(0), (uint32_t)addr); --HPS From owner-freebsd-arm@freebsd.org Sat Sep 19 19:58:31 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3A0273ED466 for ; Sat, 19 Sep 2020 19:58:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-20.consmr.mail.gq1.yahoo.com (sonic317-20.consmr.mail.gq1.yahoo.com [98.137.66.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bv1jL1d9xz4Q4k for ; Sat, 19 Sep 2020 19:58:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 9.D0YyYVM1lqhAvbFZf8vSR9qPMn7iDH5OgtUAbL0SGv_TPBi4dq4jp4FUoKXVb 9s_sST_JL39hNPBeZJFojL0x7PAtdouQAS0EDKUHalWFACxly2xzvGlKpYjGReF_289l.mp2ekuX 2Trfp5G5.AmVB.vjnKc3c7q4SRdsLY7JEgl4IE8i7woRiHq7rD3rVZZFCHT1f0k5RUn811BCPvIy 1sDHSXJrsPfFt6b8i24y60YDuAswPx2ro7DM.GLuC4aZXAdFyQGCS3AHXzz9f718_5_LMDkCAm3l Ye.JRlQS_uIBz63r_zEu2GJ6.MjZXGca1HR14J7KVhQppbkauR1wZDXwbhK4c4u9SAJwj403.l.k 2p5yaVNmXzHz8hK0dv6Ro4Ked_xk9iMfpItPGe8dGJYYHZckbtvSIaEalF00FB5x_vJFXBHZHJmh O.VyxSVMxmnMkvG7rf71G_Vcqg4hiUxsIt639QqnYmU7W1lI3glNFib.z0Rx7p35ns__ESe0NS_H sCMwZz_pXaN1CiMqWfLcTki8npcl.oczoHbNtUb_h4mRdY76E7MK8JmYA5KSnlRxXznXwTLchWyo TpWFh.xaQenPeLpoi_L2lJCnr_MhckHFzPTb50x2xDq7rD3sspWjvFiDDVG5N.oXXVclHlIB.nbn Z2FKIoEGZVV.DWbEswWAeD.0f2G_TkMqGV62ZOSvdDKRGnshmUkdt5Z3fCarpqM0VcpliV7KXqww 1eOLnXp4w.Mt9k.u85uT_G55w0kbB_KO2uxJ1_bfpf9eqvixBJHYVBYVqw9ECnSY.zyWbBnE7kYh ozq_p.3zS_xQ1RjkNK2sC_Bn.XLSq2349EZE7km20gDHz_NkMZ5uZR.fhpyY53MOILuG2u3ltr_p ZAa42TKYuE3PtOx.pbTeCp.QgHgpcMLbYKeQ8xtpkuk4BlqJ8cKcYJAc8XKd1uGZ49AFOoQS2lcL qrTuWWYJyR.zzTzwacd3oOdbVnVVQsGxiMx_2ZikUiZ5XU8o3Xj7mXZ1HYDjPRqUNfq_szueUp0l XyYkEd1kO0nJ3jo4XdEl694YW5vZR_eEyicZI5.t91HrM4AApJElt6UM2PtxAl6RvlAM8wOlUNgF n9c6.08UIGsVZj7iisO8.Ogg96uwtSgyvZQndw4YpYyXQhG_btMrmvcCxc9qNiYhr2Zrgx6_vqXE WPPYDGmQj_dSYzdcAuK7kHM83v0_drCOpRyvIFb6FFYAR9TthAAWWZXHegWIn4ibHEMLevJsxzhn j1KiWJb3NAl.PvZvcj.CNYiC4di.cQqLVUdz.EXee4SpzCMWW1M5ILkUuy1Cm1kCWbbsj.vEabDs 3BDN6mbs2gA3fxa2buoHpeUQOPAEIruEKPpIuiYiB8T3Ctq9PWzi.1I2fnjltCWNQl6fbVyGrlWS hIhV8LzPXJGULbhcmsaXJVhqkEUu_shiUX1758flW6Ti9ZMpBdnt4lZdy57H4Fqzfg3qBOZzP3n. SeJYfpHz1N6UyVFw9GMLFVjoXpKwOU8FzE8mxzAQdMH2dJ8pKFh.7dI_oWZFuAkEQE3Eo9DSwyTO gTTlH.nJPCKzxeP9x.QlP_u25QrYMgqQe Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sat, 19 Sep 2020 19:58:29 +0000 Received: by smtp404.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 27ddf4676f4a3576dd50c88af3dcb48e; Sat, 19 Sep 2020 19:58:25 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: Comment #135 for bugzilla 237666 : a USB3-handling problem with a investigatory fix for a cortex-a72 context From: Mark Millard In-Reply-To: <75af04ec-0021-3575-40bf-c5ab9b6d4703@selasky.org> Date: Sat, 19 Sep 2020 12:58:24 -0700 Cc: freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: References: <6E618C3D-12DF-429E-A249-5BAB90FC6B15.ref@yahoo.com> <6E618C3D-12DF-429E-A249-5BAB90FC6B15@yahoo.com> <866bd652-5a8b-7500-b1e0-7528c035048b@selasky.org> <578faf26-6042-91ec-c639-2bca17105fae@selasky.org> <723E6915-94F5-417C-B4AF-EEEBFBDF6162@yahoo.com> <565258A0-BEE1-48F8-9851-E6C7CF7ADAE7@yahoo.com> <75af04ec-0021-3575-40bf-c5ab9b6d4703@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4Bv1jL1d9xz4Q4k X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.61 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.07)[-1.067]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.03)[-1.028]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.02)[-1.020]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.146:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.146:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2020 19:58:31 -0000 On 2020-Sep-19, at 12:45, Hans Petter Selasky wrote: > On 2020-09-19 21:36, Mark Millard wrote: >> # svnlite diff /usr/src/sys/dev/usb/controller/xhci.c >> Index: /usr/src/sys/dev/usb/controller/xhci.c >> =================================================================== >> --- /usr/src/sys/dev/usb/controller/xhci.c (revision 363590) >> +++ /usr/src/sys/dev/usb/controller/xhci.c (working copy) >> @@ -441,6 +441,9 @@ >> DPRINTF("ERSTBA(0)=0x%016llx\n", (unsigned long long)addr); >> +#ifdef __aarch64__ >> +__asm __volatile("dsb st" : : : "memory"); >> +#endif >> XWRITE4(sc, runt, XHCI_ERSTBA_LO(0), (uint32_t)addr); >> XWRITE4(sc, runt, XHCI_ERSTBA_HI(0), (uint32_t)(addr >> 32)); >> booted just fine. This is what I expected relative to >> initializing for the event ring. > > Can you replace this with a USB flush call? Sure . . . >> Index: xhci.c >> =================================================================== >> --- xhci.c (revision 365238) >> +++ xhci.c (working copy) >> @@ -432,6 +432,8 @@ >> phwr->hwr_ring_seg[0].qwEvrsTablePtr = htole64(addr); >> phwr->hwr_ring_seg[0].dwEvrsTableSize = htole32(XHCI_MAX_EVENTS); >> + usb_bus_mem_flush_all(&sc->sc_bus, &xhci_iterate_hw_softc); >> + >> DPRINTF("ERDP(0)=0x%016llx\n", (unsigned long long)addr); >> XWRITE4(sc, runt, XHCI_ERDP_LO(0), (uint32_t)addr); In my context: # svnlite diff /usr/src/sys/dev/usb/controller/xhci.c Index: /usr/src/sys/dev/usb/controller/xhci.c =================================================================== --- /usr/src/sys/dev/usb/controller/xhci.c (revision 363590) +++ /usr/src/sys/dev/usb/controller/xhci.c (working copy) @@ -431,6 +431,7 @@ phwr->hwr_ring_seg[0].qwEvrsTablePtr = htole64(addr); phwr->hwr_ring_seg[0].dwEvrsTableSize = htole32(XHCI_MAX_EVENTS); + usb_bus_mem_flush_all(&sc->sc_bus, &xhci_iterate_hw_softc); DPRINTF("ERDP(0)=0x%016llx\n", (unsigned long long)addr); The result booted just fine, no "Resetting controller" notices at all. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Sep 19 20:14:07 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6B5043EE225 for ; Sat, 19 Sep 2020 20:14:07 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) 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 4Bv23L1nWpz4RbK for ; Sat, 19 Sep 2020 20:14:05 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id C2BA526023E; Sat, 19 Sep 2020 22:14:02 +0200 (CEST) Subject: Re: Comment #135 for bugzilla 237666 : a USB3-handling problem with a investigatory fix for a cortex-a72 context To: Mark Millard Cc: freebsd-arm References: <6E618C3D-12DF-429E-A249-5BAB90FC6B15.ref@yahoo.com> <6E618C3D-12DF-429E-A249-5BAB90FC6B15@yahoo.com> <866bd652-5a8b-7500-b1e0-7528c035048b@selasky.org> <578faf26-6042-91ec-c639-2bca17105fae@selasky.org> <723E6915-94F5-417C-B4AF-EEEBFBDF6162@yahoo.com> <565258A0-BEE1-48F8-9851-E6C7CF7ADAE7@yahoo.com> <75af04ec-0021-3575-40bf-c5ab9b6d4703@selasky.org> From: Hans Petter Selasky Message-ID: <9cf87718-9d4a-60ca-004f-5818371c937b@selasky.org> Date: Sat, 19 Sep 2020 22:13:31 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Bv23L1nWpz4RbK X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-2.94 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_LONG(-1.00)[-1.005]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.63)[-0.631]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.01)[-1.007]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2020 20:14:07 -0000 On 2020-09-19 21:58, Mark Millard wrote: > In my context: > > # svnlite diff /usr/src/sys/dev/usb/controller/xhci.c > Index: /usr/src/sys/dev/usb/controller/xhci.c > =================================================================== > --- /usr/src/sys/dev/usb/controller/xhci.c (revision 363590) > +++ /usr/src/sys/dev/usb/controller/xhci.c (working copy) > @@ -431,6 +431,7 @@ > > phwr->hwr_ring_seg[0].qwEvrsTablePtr = htole64(addr); > phwr->hwr_ring_seg[0].dwEvrsTableSize = htole32(XHCI_MAX_EVENTS); > + usb_bus_mem_flush_all(&sc->sc_bus, &xhci_iterate_hw_softc); > > DPRINTF("ERDP(0)=0x%016llx\n", (unsigned long long)addr); > > > The result booted just fine, no "Resetting controller" notices at Could you add a comment describing the need for this flush? And then I think we can push that fix upstream! --HPS From owner-freebsd-arm@freebsd.org Sat Sep 19 20:55:04 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B30493EF1D3 for ; Sat, 19 Sep 2020 20:55:04 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bv2yb4hCcz4V7C for ; Sat, 19 Sep 2020 20:55:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 5SwTm6sVM1nflZiIFKbCqGScwn8lu3mZMRV.H89CQ5iP39oz7kWN0EEQVspztWC nJ.zmooXeWoDYRVh01XF4ws1jaw0I6YdFrjsqlJb9MOzhDgU6v420bdYghM4.mFUJqcNV1yUXyTW dm_W1w_slgMsUyIH67KuQPvpk6IH.GLRLSP3ZVnIoFUob9gfegSQMB3zb9yfvhS7qp50ggygXo3H qj5WdqbgeO5yyVUCZEivCmcsKbutGwo4NnTvsyNJZD2.UKwMqOziKyBi4wEpDa0h8u1eqA3Jy8XG V9b2OTlov3r.MEesScnewYx9DezCFEwC.XMjiQneDaMudCW3YjZrYShtM.uAk8PU6BZjlzwt0B64 Dmq5vles8f57m2PYEniYwZ8BzM7sgtL4ztoYS1w22ylTw3JaqUZW9uqyacLxIOtU30RLGtMHxskU E2jFlNoB9fHV3Y8SCdMqNuTm33EyGxRLlgfZnV2FTLc9YVmoPMVQB2RINRiVGen0xhOroi42qFCW fZzg6bzbZ9cQxTLRR.l0_Se46tp5oFQwAdUFdTltvKnqggC77SFcKpnRhIOPSW7Qus.COzIZsJ1A uFiuCAzHNmHzHGi3IloueMzthIYk0WUMA.WftMxK47j3FSXG5MUJ8zqMVkI2gpt_GFW_QByr9BJo XckTthfnvAKIi7IRG74zL0y0c4ZE7vuJgxeVeLY5qT1uov0y.dLHGTr9JcdwCy_e5KgfPMgIFYHl _AiFSTq_3UDfD2JV7afFMpZgKT1hWygkwv89qe45Ct_OX9kz4HIYeV5qf7ILBlE2TNnyfFwqHr8R 5PiGsA1F8.IUIhYnqXwFjic4NhEw9IPME7nZAvlZmNzt1br2ZcDXTl.ioxzNwRwpelQH8MuXR_k3 iiTJS9Aln7OCRV6rrzcfOF8rWnYmQpmfJtOrodywHz.ymgbYLVuiRABmTngZuEpPElJsz8FK4gUt _WGInYEb7M5I0LG6DU4COnVTrx9e_wlEa8dVRWHw61qrrqQS6tjVP1HkxpsTMhZEg62AoSIMpdGO l2HZq74D72uvjvrFDfORO.UdU3UR7ebwqQmqIiWcUw_BOeclzu44GkjrES7TmfFtXXni9a2lEliy Qin02xaubcWZGJt2oXDlIYjQr0EYO9JdchnWDh5EB7YJZrQ1w6NFkPE0L.5ksJCD9sYT9JlnPI5L cbQSgmIVEiC0LzaCvUZ3p6lbw.sFVVB2zAoPkMn1YLP84dRApvOaxRiZlDCGqmb42mthX_ZEKKet v8gTswPnV2TI8gyk7xIN8r5mdvsfD1ILJ9a4kIs5D7uj2n2ZI4ZIgHUb65re.yKa1mwio.Hdnj0J vrZT52PrHW3bIags5Feu0usonBGrAhAwkrjWwawlMfInFgGoQAO8qHS0LQ9FXa1opAlSJW8dYrw4 jCdMGDTyQcIWHV2HffE_mekbNfCOiDmCUSULtQYDMcV8x49J6_W2TkcE..AqaFWazDNVbpafEQbi 2QnidF_drJLsX5HLzPI.3U2BmidAfzNW1.9XhI0mPXkPSfbTzxu8LG4JHP3ZvDRzrkM_k7KrfVnj uZVvwp9rau97qis6pfZeIgFs6w1anCWt4v08- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sat, 19 Sep 2020 20:55:02 +0000 Received: by smtp423.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 273d25dd46708213ca1022bec29b535e; Sat, 19 Sep 2020 20:54:59 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: Comment #135 for bugzilla 237666 : a USB3-handling problem with a investigatory fix for a cortex-a72 context From: Mark Millard In-Reply-To: <9cf87718-9d4a-60ca-004f-5818371c937b@selasky.org> Date: Sat, 19 Sep 2020 13:54:58 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <47D6CA1E-F842-47B6-97E0-C87B33610C64@yahoo.com> References: <6E618C3D-12DF-429E-A249-5BAB90FC6B15.ref@yahoo.com> <6E618C3D-12DF-429E-A249-5BAB90FC6B15@yahoo.com> <866bd652-5a8b-7500-b1e0-7528c035048b@selasky.org> <578faf26-6042-91ec-c639-2bca17105fae@selasky.org> <723E6915-94F5-417C-B4AF-EEEBFBDF6162@yahoo.com> <565258A0-BEE1-48F8-9851-E6C7CF7ADAE7@yahoo.com> <75af04ec-0021-3575-40bf-c5ab9b6d4703@selasky.org> <9cf87718-9d4a-60ca-004f-5818371c937b@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4Bv2yb4hCcz4V7C X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.62 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.07)[-1.067]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.03)[-1.028]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.02)[-1.020]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.147:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2020 20:55:04 -0000 On 2020-Sep-19, at 13:13, Hans Petter Selasky = wrote: > On 2020-09-19 21:58, Mark Millard wrote: >> In my context: >> # svnlite diff /usr/src/sys/dev/usb/controller/xhci.c >> Index: /usr/src/sys/dev/usb/controller/xhci.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- /usr/src/sys/dev/usb/controller/xhci.c (revision 363590) >> +++ /usr/src/sys/dev/usb/controller/xhci.c (working copy) >> @@ -431,6 +431,7 @@ >> phwr->hwr_ring_seg[0].qwEvrsTablePtr =3D htole64(addr); >> phwr->hwr_ring_seg[0].dwEvrsTableSize =3D = htole32(XHCI_MAX_EVENTS); >> + usb_bus_mem_flush_all(&sc->sc_bus, &xhci_iterate_hw_softc); >> DPRINTF("ERDP(0)=3D0x%016llx\n", (unsigned long long)addr); >> The result booted just fine, no "Resetting controller" notices at >=20 > Could you add a comment describing the need for this flush? And then I = think we can push that fix upstream! I'll take a stab at it (not in this note) but 1.5 days ago or so I had no clue about such things as xhci event rings, mailbox/boorbell handling on aarch64, and so on. You may find your own wording(s) more reasonable than whatever I come up with. I'll note that if aarch64 requires the DSB ST and DSB LD additions in the two dev/usb/usb_busdma.c routines, then powerpc64, powerpc, and powerpcspe probably(?) have SYNC-related additions needed as well. (I do not have access to any modern powerpc* hardware that would have xhci involved.) There could be additions required for other architectures (that I'm unlikely to have any familiarity with or access to, other than amd64). Also, my diffs are relative to back a ways: -r363590 . While things have looked very close during this in the relevant files, I've avoiding synchronizing to head during the recent large changes and various problems I'd been monitoring the status of for some time. (And before that other parts of life had priority.) As stands, in my head -r363590 based context, the patch set for this overall currently looks like (up to E-mail variability in spaces): # svnlite diff /usr/src/sys/dev/usb/usb_busdma.c = /usr/src/sys/dev/usb/controller/xhci.c Index: /usr/src/sys/dev/usb/usb_busdma.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/dev/usb/usb_busdma.c (revision 363590) +++ /usr/src/sys/dev/usb/usb_busdma.c (working copy) @@ -737,6 +737,9 @@ */ bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_POSTREAD); bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREREAD); +#ifdef __aarch64__ +__asm __volatile("dsb ld" : : : "memory"); +#endif } =20 = /*------------------------------------------------------------------------= * @@ -750,6 +753,9 @@ return; } bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREWRITE); +#ifdef __aarch64__ +__asm __volatile("dsb st" : : : "memory"); +#endif } =20 = /*------------------------------------------------------------------------= * Index: /usr/src/sys/dev/usb/controller/xhci.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/dev/usb/controller/xhci.c (revision 363590) +++ /usr/src/sys/dev/usb/controller/xhci.c (working copy) @@ -431,6 +431,7 @@ =20 phwr->hwr_ring_seg[0].qwEvrsTablePtr =3D htole64(addr); phwr->hwr_ring_seg[0].dwEvrsTableSize =3D = htole32(XHCI_MAX_EVENTS); + usb_bus_mem_flush_all(&sc->sc_bus, &xhci_iterate_hw_softc); =20 DPRINTF("ERDP(0)=3D0x%016llx\n", (unsigned long long)addr); =20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Sep 19 21:18:10 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8A08F3EFBC2 for ; Sat, 19 Sep 2020 21:18:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bv3TF3SlDz4WkF for ; Sat, 19 Sep 2020 21:18:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: nmHS8dAVM1mn7Z5QTMcP4aF0D9Tr82sHua2uqiM2eu_r1D2GPPKDmf5zZfQ4iz1 WnCV1JsZq3gNEdY_JKdobVThJHbnx36ZhdiYBG_nYj4PIbVH_GPDJCcDTzqL_p7YgHgafRK.M2N3 63NYcbF5vELtob5Uy6Qs7gq.ea0M4XWXx8CD8vCo9ZTAnWXo9xlq4BlRFdatdC1FerJW.0jD.zao Z0DaXnK3.hS5aGRhIrLYLyAsa2LEqn66aNmKGiXm3FJJ8ziGLrE0KD2FMbCWNnu4VU3aGY85F1gy W.fFqYQjwBfUMZHqTfB0aCnFDurbN4.rxnoaK_DwhFjCqJjSEN5xX2Zc_gHrGco7QgpzbqkVLJqN rVvL78VHTuTVjm3j7v6U5Qm9O4qZ9w7k_qAQTeW9ULz7dglaKqiBC89ENRm_lVCNm2MBIBFBVxqZ GKZ2ZhqUk2t8KcesCJIQZiDWWYjpY303rsDYJTZYHwZJB6jb6t.oe65TigWmtCHipvsRK8cZDZoD O0Bz9bI.vVAVvN24shjydhkQBXpbyh.cRiOAxpifyEsW5QAr4oL7xO4WCpAC7JuT1CPorRaxXAG8 zCK7BvWbFu6uMSphS4BdiVwTSNlNxPQcEmw7QDXTOzVlLfq8tLCoK_GvgIEzq6.WLqLkaeMj8Ahi LGRkWMHMsLDKss348qjJQKrKPUjIaG2_AvEIBX5uIPdBInCtiS5fMzCq.VkJB2_h39bsekBSyX0C 56koQ1e.CaoWnbBKykQkTuxBkbcM9f1eelCFjZeivo5pAri4RkEnRtOnQ1APhMb_bPy8T0sWqXjM cXjOLjCJes3Jc1GxvpOMh6wzcgBewhmnWGH9RIrrzo8lb8E7.jJ.KmcF3DyZDE9M21.8Kdm9nC7i L3KQ3zlxJ_5BwTs4.MR5norUqWvoCgLlPVHJIRMRmuR7BX3ChzNuVnPt6sXC5t6EsUyjo3F6KHe2 gXwNWfu3__j3jl1TGpBjCO22Av9Ow3nt00nDf1ejS5YnpNRsNL.EoxzMrcz_NbRO46bYLuf.8nP_ l2diXxCkae82ddrq9OfkDnRxTZniMUrMti5rJ87Q5XwIrSLtdfchdLR9UEJJ2cC3gRsD9fNi2kVo PoFBv5nh_U8PfW0bGveyCnA_fO6iCKuGnz41ZoK8pbZJx2dkCY8cnoDIXm02eyCMGm9MDKTxJ3bq Ttr8O6pghzB2NXh5ZAnLpbIYC_3J90mHq9tYYctLAzcX.BW.k.tNgIyGGvgz6Q.Ylvsg7zmaIPsh Elk5GIvCRV2jKEGsJt._rO68AJ.fZo55uASh6pchjWGJiwTPrRs5XbxBN_CBAbYO1GWKOXdfXpmh olwWShSfEHY561bG7GKdHh4LnqEXJMHsRx4d8i0HCb0LDC75pJi_ObN9lBh9_rVco4SoW8JL6HIQ OSAP02GhUNsbt37PQrRIWuOawgO2Wg6Tu9is3BrsJV_48d6gdw6_tk3bnGMJuytHO54knWmmEb5R 1hQQXxv6jmrRrs7o7Q3_jbsXCgG5qXK7VbYxlybW5RFI.uo7nfu1rSWNYFHkhMOVHLeWY4nlSHw3 K4fhdg6H_zz2FGRDjJk1P6Inkfom93Vi6GUk- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sat, 19 Sep 2020 21:18:07 +0000 Received: by smtp409.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID ed86512132c30979690f9530208b8eb1; Sat, 19 Sep 2020 21:18:04 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: Comment #135 for bugzilla 237666 : a USB3-handling problem with a investigatory fix for a cortex-a72 context From: Mark Millard In-Reply-To: <47D6CA1E-F842-47B6-97E0-C87B33610C64@yahoo.com> Date: Sat, 19 Sep 2020 14:18:03 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <8BAF3798-4BB4-4C5E-87FC-ECD1458910A2@yahoo.com> References: <6E618C3D-12DF-429E-A249-5BAB90FC6B15.ref@yahoo.com> <6E618C3D-12DF-429E-A249-5BAB90FC6B15@yahoo.com> <866bd652-5a8b-7500-b1e0-7528c035048b@selasky.org> <578faf26-6042-91ec-c639-2bca17105fae@selasky.org> <723E6915-94F5-417C-B4AF-EEEBFBDF6162@yahoo.com> <565258A0-BEE1-48F8-9851-E6C7CF7ADAE7@yahoo.com> <75af04ec-0021-3575-40bf-c5ab9b6d4703@selasky.org> <9cf87718-9d4a-60ca-004f-5818371c937b@selasky.org> <47D6CA1E-F842-47B6-97E0-C87B33610C64@yahoo.com> To: Hans Petter Selasky X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4Bv3TF3SlDz4WkF X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.62 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.07)[-1.067]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.03)[-1.028]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.02)[-1.020]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.31:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.31:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2020 21:18:10 -0000 On 2020-Sep-19, at 13:54, Mark Millard wrote: . . . >=20 > As stands, in my head -r363590 based context, the patch set for this > overall currently looks like (up to E-mail variability in spaces): >=20 > # svnlite diff /usr/src/sys/dev/usb/usb_busdma.c = /usr/src/sys/dev/usb/controller/xhci.c > Index: /usr/src/sys/dev/usb/usb_busdma.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/dev/usb/usb_busdma.c (revision 363590) > +++ /usr/src/sys/dev/usb/usb_busdma.c (working copy) > @@ -737,6 +737,9 @@ > */ > bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_POSTREAD); > bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREREAD); > +#ifdef __aarch64__ > +__asm __volatile("dsb ld" : : : "memory"); > +#endif > } >=20 > = /*------------------------------------------------------------------------= * > @@ -750,6 +753,9 @@ > return; > } > bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREWRITE); > +#ifdef __aarch64__ > +__asm __volatile("dsb st" : : : "memory"); > +#endif > } >=20 Looking at the lower level code it looked like DSB SY is used for the above two automatically and it should be a valid sustitute for DSB ST and DSB LD, even if overkill. So I'm testing with dev/usb/usb_busdma.c reverted. (See later below.) > = /*------------------------------------------------------------------------= * > Index: /usr/src/sys/dev/usb/controller/xhci.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/dev/usb/controller/xhci.c (revision 363590) > +++ /usr/src/sys/dev/usb/controller/xhci.c (working copy) > @@ -431,6 +431,7 @@ >=20 > phwr->hwr_ring_seg[0].qwEvrsTablePtr =3D htole64(addr); > phwr->hwr_ring_seg[0].dwEvrsTableSize =3D = htole32(XHCI_MAX_EVENTS); > + usb_bus_mem_flush_all(&sc->sc_bus, &xhci_iterate_hw_softc); >=20 > DPRINTF("ERDP(0)=3D0x%016llx\n", (unsigned long long)addr); >=20 >=20 The test booted just fine, no "Resetting controller" notices or the like. So now I have just: # svnlite diff /usr/src/sys/dev/usb/controller/xhci.c Index: /usr/src/sys/dev/usb/controller/xhci.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/dev/usb/controller/xhci.c (revision 363590) +++ /usr/src/sys/dev/usb/controller/xhci.c (working copy) @@ -431,6 +431,7 @@ =20 phwr->hwr_ring_seg[0].qwEvrsTablePtr =3D htole64(addr); phwr->hwr_ring_seg[0].dwEvrsTableSize =3D = htole32(XHCI_MAX_EVENTS); + usb_bus_mem_flush_all(&sc->sc_bus, &xhci_iterate_hw_softc); =20 DPRINTF("ERDP(0)=3D0x%016llx\n", (unsigned long long)addr); =20 for the issue. (So my earlier powerpc* SYNC comments are likely junk.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Sep 19 21:48:23 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 843343F0596 for ; Sat, 19 Sep 2020 21:48:23 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bv4864PWVz4YFV for ; Sat, 19 Sep 2020 21:48:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: GuwnXgsVM1n3rpxb5dutNZpT9tZ8wdsMqW98fkile9IcOWOJGjKcU8W31pre2N2 ZghqIPE2Sbf9M6Tl9wz4roCNZEa9JICVCaIQe.HPR.T4FcGaG1k1Q0SgDsxA1fIU_P6VGPp7MdoJ Mqbk9z2G4FFgnmcwg.6IjeQU_OcjuWjFMu0lIntGSVLrJIODErTjzqjfYfFhH31pngt4i7C5DXPD ysWZ9DvaXCndgjHQGjJJBqO_pcJSMvoiSExVT2AiYhse9D8Kbnzec7epLnTFs.t3DzM9qxrPVwOc BEmvFCfqQjx.0RnZoOjfLgrt8V3ZgEzceCyAUvstp3b18CTq6dlulZCfV7XM3urN8RtTvy13EnZF H.yZdvHmO9EQq.ZnTVgz2zk_9XMVs9LCL7cQs1bX2ajXV21Plfz6j7940KLDp_EcxraGCTFQfvtt V_sGPTpyTzfxYDFwpAaywQ.bvQU143b8c7._d_xIjDUiPSC_1CtOXdNrNOWxsOOifHiskUTVFWCY hh3IZ0gZnM4gYcg7HiraOXvQQQYYDU8YLOe5aGt_Zgn9EVcdLIkdA.h7FEfKY5JsrvidCc9x2UpV k1BHdHFfq7XU7fyZAgNT50DPJe2gKNkt.2ukAfFgpqkNlPTStc1J7WefLNuZ5N.eHLN0MeFFGw7k GcLVbfG8wZB4SHAdw4Ac3ZFsyN1SpObQn_AF6Kici51s.a2ArcIy_kQR2JYkqYwRQRPGH9_HOBmT dhiDWT0H8CczP8Hfu6tlxVGMpe6d8vsX0qNLHz.n5YUw06P.Cb10u9uqg19JOV8mC8Rv29fusrD2 Icf4n1EIL_IKUd1VCKyVmKrm7IJBBms4JIsKAhcdr9y_zkFVzqmugiTGQpBLHEUl.JQZKCGFo4zP 7csJdqeDPDJ4qRSlc1R4fE9d3QE9xkwae1iloMJpD0mxFGK9Wcu3Gr8ac4hoc_TaYZFfLkZM7mZ_ 0CuQquNFsbZCFq7dY_UVVIr8CT3qw1Dteg5Iv4Z7tvct.f6mjibWUSLGWEJ3Jf1bhlsf6m0DoCyX CwKZT9YAeLrkjq8dF72BSQp04fZ57BRn2jwgheRMmQs_Yod2e2etlKDOkRTVKu1jPg7dgka3cDsk F4TrWYn2c_dzFv6aarXa.Vmnw4VrJkPr8O6q85X0XOj7tOPxy4ft4EXwld.ovYUcsG8vt.2XqGaU P.EyH.9.Cq6raHRBMxKga5uF_cc60OudevdCQ6zkoRQunRSmdNio9yCvZCKEDurwC14aZqvAdZeq eEFsXAAZ4r8lt2ll5.n2Yv5gwm1Z4XQtBj8d82tw.jZZ8UfzrGsFemeQP6FejjKldvNSpAJl66hy RcTfnxMijKdwAg7w9VfZfkJFTI1p8rkgKpiOHZx.UTajTKA_Wsz9AzuoizvFdqnqWr6kPqFq8wZ. Yfym6j7chEqyo8c95nPTCroJjFbGuAn9.VkYyWw1poDhQec_PSMbWEXOIEytdRaoIM34l7YoriBF VJePke3sL5k_T3oEaCOmeMnr79Y2uH6emb2cRG.WwlI7abQlGKMOgN5wNv5jSqd0asIAgU8pbVdk - Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sat, 19 Sep 2020 21:48:20 +0000 Received: by smtp401.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 2a4d098d62011aeba5fde0a05a097d70; Sat, 19 Sep 2020 21:48:15 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: Comment #135 for bugzilla 237666 : a USB3-handling problem with a investigatory fix for a cortex-a72 context From: Mark Millard In-Reply-To: <8BAF3798-4BB4-4C5E-87FC-ECD1458910A2@yahoo.com> Date: Sat, 19 Sep 2020 14:48:13 -0700 Cc: freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: <9E243DD6-1D11-4135-B752-0559AA4904DB@yahoo.com> References: <6E618C3D-12DF-429E-A249-5BAB90FC6B15.ref@yahoo.com> <6E618C3D-12DF-429E-A249-5BAB90FC6B15@yahoo.com> <866bd652-5a8b-7500-b1e0-7528c035048b@selasky.org> <578faf26-6042-91ec-c639-2bca17105fae@selasky.org> <723E6915-94F5-417C-B4AF-EEEBFBDF6162@yahoo.com> <565258A0-BEE1-48F8-9851-E6C7CF7ADAE7@yahoo.com> <75af04ec-0021-3575-40bf-c5ab9b6d4703@selasky.org> <9cf87718-9d4a-60ca-004f-5818371c937b@selasky.org> <47D6CA1E-F842-47B6-97E0-C87B33610C64@yahoo.com> <8BAF3798-4BB4-4C5E-87FC-ECD1458910A2@yahoo.com> To: Hans Petter Selasky X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4Bv4864PWVz4YFV X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.39 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.85)[-0.846]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.03)[-1.028]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.02)[-1.020]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.147:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2020 21:48:23 -0000 On 2020-Sep-19, at 14:18, Mark Millard wrote: > On 2020-Sep-19, at 13:54, Mark Millard wrote: > > . . . > > The test booted just fine, no "Resetting controller" notices or the > like. So now I have just: > > # svnlite diff /usr/src/sys/dev/usb/controller/xhci.c > Index: /usr/src/sys/dev/usb/controller/xhci.c > =================================================================== > --- /usr/src/sys/dev/usb/controller/xhci.c (revision 363590) > +++ /usr/src/sys/dev/usb/controller/xhci.c (working copy) > @@ -431,6 +431,7 @@ > > phwr->hwr_ring_seg[0].qwEvrsTablePtr = htole64(addr); > phwr->hwr_ring_seg[0].dwEvrsTableSize = htole32(XHCI_MAX_EVENTS); > + usb_bus_mem_flush_all(&sc->sc_bus, &xhci_iterate_hw_softc); > > DPRINTF("ERDP(0)=0x%016llx\n", (unsigned long long)addr); > > > for the issue. (So my earlier powerpc* SYNC comments are likely junk.) Comment draft added: # svnlite diff /usr/src/sys/dev/usb/controller/xhci.c Index: /usr/src/sys/dev/usb/controller/xhci.c =================================================================== --- /usr/src/sys/dev/usb/controller/xhci.c (revision 363590) +++ /usr/src/sys/dev/usb/controller/xhci.c (working copy) @@ -431,6 +431,17 @@ phwr->hwr_ring_seg[0].qwEvrsTablePtr = htole64(addr); phwr->hwr_ring_seg[0].dwEvrsTableSize = htole32(XHCI_MAX_EVENTS); + /* + * For bugzilla 237666: + * According to extensible-host-controler-interface-usb-xhci.pdf , + * the later XWRITE4's to XHCI_ERSTBA_LO and _HI lead to the xhci + * needing to copy the qwEvrsTablePtr and dwEvrsTableSize + * values above at that time (as the xhci initializes its event + * ring support). This is before the event ring starts to pay + * attention to Run/Stop. Thus, make sure the values are + * observable to the xhci before that point. + */ + usb_bus_mem_flush_all(&sc->sc_bus, &xhci_iterate_hw_softc); DPRINTF("ERDP(0)=0x%016llx\n", (unsigned long long)addr); === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Sep 19 21:49:14 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D7DCE3F05A3 for ; Sat, 19 Sep 2020 21:49:14 +0000 (UTC) (envelope-from crowston@protonmail.com) Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) (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 "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bv49558Mtz4XlB for ; Sat, 19 Sep 2020 21:49:13 +0000 (UTC) (envelope-from crowston@protonmail.com) Date: Sat, 19 Sep 2020 21:49:05 +0000 To: Mark Millard , Hans Petter Selasky From: Robert Crowston Cc: freebsd-arm Reply-To: Robert Crowston Subject: Re: Comment #135 for bugzilla 237666 : a USB3-handling problem with a investigatory fix for a cortex-a72 context Message-ID: <7_E2XXmpIwdiLPwD5tkXUAFlHsAhrFIbs87-JJnE57wRg4vrRcqCL1qSToBN_52_YjcPvt7HQSrzA0v6fWDAYIoN348pYVc62bTUXNxudBU=@protonmail.com> In-Reply-To: <8BAF3798-4BB4-4C5E-87FC-ECD1458910A2@yahoo.com> References: <6E618C3D-12DF-429E-A249-5BAB90FC6B15.ref@yahoo.com> <723E6915-94F5-417C-B4AF-EEEBFBDF6162@yahoo.com> <565258A0-BEE1-48F8-9851-E6C7CF7ADAE7@yahoo.com> <75af04ec-0021-3575-40bf-c5ab9b6d4703@selasky.org> <9cf87718-9d4a-60ca-004f-5818371c937b@selasky.org> <47D6CA1E-F842-47B6-97E0-C87B33610C64@yahoo.com> <8BAF3798-4BB4-4C5E-87FC-ECD1458910A2@yahoo.com> MIME-Version: 1.0 X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch X-Rspamd-Queue-Id: 4Bv49558Mtz4XlB X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.25 / 15.00]; HAS_REPLYTO(0.00)[crowston@protonmail.com]; RWL_MAILSPIKE_GOOD(0.00)[185.70.40.133:from]; FREEMAIL_FROM(0.00)[protonmail.com]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[protonmail.com:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine]; NEURAL_HAM_SHORT(-0.38)[-0.384]; FREEMAIL_TO(0.00)[yahoo.com,selasky.org]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[protonmail.com]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.95)[-0.946]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.02)[-1.021]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FREEMAIL_REPLYTO(0.00)[protonmail.com]; HAS_PHPMAILER_SIG(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[185.70.40.133:from]; MAILMAN_DEST(0.00)[freebsd-arm] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2020 21:49:14 -0000 SeKAmXZlIGJlZW4gd29ya2luZyB3aXRoIGFhcmNoNjQgd2l0aCBtY3B1PWNvcnRleDcyIG9uIHRo ZSBycGk0IHdpdGggdS1ib290LiBJIGRpZCBub3QgbmVlZCB0aGlzIGV4dHJhIGJhcnJpZXIgb3Ig Zmx1c2guIFRoaXMgc3VnZ2VzdHMgdGhlIHByb2JsZW0gaXMgc2xpZ2h0bHkgbW9yZSBudWFuY2Vk LiAoSSBkbyBub3Qgb2JqZWN0IHRvIHRoZSBleHRyYSBiYXJyaWVyIGlmIGl0IGZpeGVzIHlvdXIg cHJvYmxlbSwgSeKAmW0ganVzdCBhZGRpbmcgZXh0cmEgaW5mb3JtYXRpb24uKQoKTXkgcXVlc3Rp b24sIHdoaWNoIG1heSBiZSBpcnJlbGV2YW50IG9yIG1pc2d1aWRlZDogVGhlIGZsYWdzIGZpZWxk IGluIHRoZSBkbWEgdGFnIGhhcyBhbiBvcHRpb24gZm9yIHNwZWNpZnlpbmcgaWYgdGhlIGhhcmR3 YXJlIGlzIGNhY2hlIGNvaGVyZW50IChCVVNfRE1BX0NPSEVSRU5UKS4gRG9lcyB0aGUgVUVGSS1k ZXJpdmVkIHRhZyBwYXNzZWQgdGhyb3VnaCB0byB0aGUgeGhjaSBkcml2ZXIgaGF2ZSB0aGlzIGJp dCBzZXQ/CgpJIHdhcyBzbGlnaHRseSBjb25mdXNlZCB0aGF0IGV4cGxpY2l0bHkgZ2VuZXJhdGlu ZyBhIGJhcnJpZXIgYWZ0ZXIgY2FsbGluZyBidXNfZG1hbWFwX3N5bmMoOSkgaGFkIGFueSBlZmZl Y3QuIEkgdW5kZXJzdG9vZCB0aGF0IHRoZSBwdXJwb3NlIG9mIHRoZSBzeW5jIGZ1bmN0aW9uIHdh cyB0byBnZW5lcmF0ZSB3aGF0ZXZlciBiYXJyaWVyIG9yIGZlbmNlIHRoZSB1bmRlcmx5aW5nIGJ1 cyByZXF1aXJlZCwgaWYgYW55LCB0byBlbnN1cmUgY29uc2lzdGVuY3kuIEJ1dCwgaWYgdGhvc2Ug YmFycmllcnMgd2VyZSBub3QgcmVxdWlyZWQgaW4gdGhlIGVuZCwgcGVyaGFwcyB0aGF0IGlzIGEg cmVkIGhlcnJpbmc/CgrigJQgUkhDLgoKT24gU2F0LCBTZXAgMTksIDIwMjAgYXQgMjI6MTgsIE1h cmsgTWlsbGFyZCB2aWEgZnJlZWJzZC1hcm0gPGZyZWVic2QtYXJtQGZyZWVic2Qub3JnPiB3cm90 ZToKCj4gT24gMjAyMC1TZXAtMTksIGF0IDEzOjU0LCBNYXJrIE1pbGxhcmQgPG1hcmtsbWkgYXQg eWFob28uY29tPiB3cm90ZToKPgo+IC4gLiAuCj4+Cj4+IEFzIHN0YW5kcywgaW4gbXkgaGVhZCAt cjM2MzU5MCBiYXNlZCBjb250ZXh0LCB0aGUgcGF0Y2ggc2V0IGZvciB0aGlzCj4+IG92ZXJhbGwg Y3VycmVudGx5IGxvb2tzIGxpa2UgKHVwIHRvIEUtbWFpbCB2YXJpYWJpbGl0eSBpbiBzcGFjZXMp Ogo+Pgo+PiAjIHN2bmxpdGUgZGlmZiAvdXNyL3NyYy9zeXMvZGV2L3VzYi91c2JfYnVzZG1hLmMg L3Vzci9zcmMvc3lzL2Rldi91c2IvY29udHJvbGxlci94aGNpLmMKPj4gSW5kZXg6IC91c3Ivc3Jj L3N5cy9kZXYvdXNiL3VzYl9idXNkbWEuYwo+PiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Cj4+IC0tLSAvdXNyL3NyYy9z eXMvZGV2L3VzYi91c2JfYnVzZG1hLmMgKHJldmlzaW9uIDM2MzU5MCkKPj4gKysrIC91c3Ivc3Jj L3N5cy9kZXYvdXNiL3VzYl9idXNkbWEuYyAod29ya2luZyBjb3B5KQo+PiBAQCAtNzM3LDYgKzcz Nyw5IEBACj4+ICovCj4+IGJ1c19kbWFtYXBfc3luYyhwYy0+dGFnLCBwYy0+bWFwLCBCVVNfRE1B U1lOQ19QT1NUUkVBRCk7Cj4+IGJ1c19kbWFtYXBfc3luYyhwYy0+dGFnLCBwYy0+bWFwLCBCVVNf RE1BU1lOQ19QUkVSRUFEKTsKPj4gKyNpZmRlZiBfX2FhcmNoNjRfXwo+PiArX19hc20gX192b2xh dGlsZSgiZHNiIGxkIiA6IDogOiAibWVtb3J5Iik7Cj4+ICsjZW5kaWYKPj4gfQo+Pgo+PiAvKi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSoKPj4gQEAgLTc1MCw2ICs3NTMsOSBAQAo+PiByZXR1cm47Cj4+IH0KPj4g YnVzX2RtYW1hcF9zeW5jKHBjLT50YWcsIHBjLT5tYXAsIEJVU19ETUFTWU5DX1BSRVdSSVRFKTsK Pj4gKyNpZmRlZiBfX2FhcmNoNjRfXwo+PiArX19hc20gX192b2xhdGlsZSgiZHNiIHN0IiA6IDog OiAibWVtb3J5Iik7Cj4+ICsjZW5kaWYKPj4gfQo+Pgo+Cj4gTG9va2luZyBhdCB0aGUgbG93ZXIg bGV2ZWwgY29kZSBpdCBsb29rZWQgbGlrZSBEU0IgU1kgaXMgdXNlZCBmb3IKPiB0aGUgYWJvdmUg dHdvIGF1dG9tYXRpY2FsbHkgYW5kIGl0IHNob3VsZCBiZSBhIHZhbGlkIHN1c3RpdHV0ZQo+IGZv ciBEU0IgU1QgYW5kIERTQiBMRCwgZXZlbiBpZiBvdmVya2lsbC4gU28gSSdtIHRlc3Rpbmcgd2l0 aAo+IGRldi91c2IvdXNiX2J1c2RtYS5jIHJldmVydGVkLiAoU2VlIGxhdGVyIGJlbG93LikKPgo+ PiAvKi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSoKPj4gSW5kZXg6IC91c3Ivc3JjL3N5cy9kZXYvdXNiL2NvbnRy b2xsZXIveGhjaS5jCj4+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0KPj4gLS0tIC91c3Ivc3JjL3N5cy9kZXYvdXNiL2Nv bnRyb2xsZXIveGhjaS5jIChyZXZpc2lvbiAzNjM1OTApCj4+ICsrKyAvdXNyL3NyYy9zeXMvZGV2 L3VzYi9jb250cm9sbGVyL3hoY2kuYyAod29ya2luZyBjb3B5KQo+PiBAQCAtNDMxLDYgKzQzMSw3 IEBACj4+Cj4+IHBod3ItPmh3cl9yaW5nX3NlZ1swXS5xd0V2cnNUYWJsZVB0ciA9IGh0b2xlNjQo YWRkcik7Cj4+IHBod3ItPmh3cl9yaW5nX3NlZ1swXS5kd0V2cnNUYWJsZVNpemUgPSBodG9sZTMy KFhIQ0lfTUFYX0VWRU5UUyk7Cj4+ICsgdXNiX2J1c19tZW1fZmx1c2hfYWxsKCZzYy0+c2NfYnVz LCAmeGhjaV9pdGVyYXRlX2h3X3NvZnRjKTsKPj4KPj4gRFBSSU5URigiRVJEUCgwKT0weCUwMTZs bHhcbiIsICh1bnNpZ25lZCBsb25nIGxvbmcpYWRkcik7Cj4+Cj4+Cj4KPiBUaGUgdGVzdCBib290 ZWQganVzdCBmaW5lLCBubyAiUmVzZXR0aW5nIGNvbnRyb2xsZXIiIG5vdGljZXMgb3IgdGhlCj4g bGlrZS4gU28gbm93IEkgaGF2ZSBqdXN0Ogo+Cj4gIyBzdm5saXRlIGRpZmYgL3Vzci9zcmMvc3lz L2Rldi91c2IvY29udHJvbGxlci94aGNpLmMKPiBJbmRleDogL3Vzci9zcmMvc3lzL2Rldi91c2Iv Y29udHJvbGxlci94aGNpLmMKPiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Cj4gLS0tIC91c3Ivc3JjL3N5cy9kZXYvdXNi L2NvbnRyb2xsZXIveGhjaS5jIChyZXZpc2lvbiAzNjM1OTApCj4gKysrIC91c3Ivc3JjL3N5cy9k ZXYvdXNiL2NvbnRyb2xsZXIveGhjaS5jICh3b3JraW5nIGNvcHkpCj4gQEAgLTQzMSw2ICs0MzEs NyBAQAo+Cj4gcGh3ci0+aHdyX3Jpbmdfc2VnWzBdLnF3RXZyc1RhYmxlUHRyID0gaHRvbGU2NChh ZGRyKTsKPiBwaHdyLT5od3JfcmluZ19zZWdbMF0uZHdFdnJzVGFibGVTaXplID0gaHRvbGUzMihY SENJX01BWF9FVkVOVFMpOwo+ICsgdXNiX2J1c19tZW1fZmx1c2hfYWxsKCZzYy0+c2NfYnVzLCAm eGhjaV9pdGVyYXRlX2h3X3NvZnRjKTsKPgo+IERQUklOVEYoIkVSRFAoMCk9MHglMDE2bGx4XG4i LCAodW5zaWduZWQgbG9uZyBsb25nKWFkZHIpOwo+Cj4gZm9yIHRoZSBpc3N1ZS4gKFNvIG15IGVh cmxpZXIgcG93ZXJwYyogU1lOQyBjb21tZW50cyBhcmUgbGlrZWx5IGp1bmsuKQo+Cj4gPT09Cj4g TWFyayBNaWxsYXJkCj4gbWFya2xtaSBhdCB5YWhvby5jb20KPiAoIGRzbC1vbmx5Lm5ldCB3ZW50 Cj4gYXdheSBpbiBlYXJseSAyMDE4LU1hcikKPgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCj4gZnJlZWJzZC1hcm1AZnJlZWJzZC5vcmcgbWFpbGluZyBs aXN0Cj4gaHR0cHM6Ly9saXN0cy5mcmVlYnNkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZyZWVic2Qt YXJtCj4gVG8gdW5zdWJzY3JpYmUsIHNlbmQgYW55IG1haWwgdG8gImZyZWVic2QtYXJtLXVuc3Vi c2NyaWJlQGZyZWVic2Qub3JnIg== From owner-freebsd-arm@freebsd.org Sat Sep 19 22:04:42 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9FCE33F05F4 for ; Sat, 19 Sep 2020 22:04:42 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2k.ore.mailhop.org (outbound2k.ore.mailhop.org [54.148.219.64]) (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 4Bv4Vx6qBLz4Z7h for ; Sat, 19 Sep 2020 22:04:41 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1600553080; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=jfwO5kXgDLYTWDF7vq6gCXZSOCg+cZ2DUhGxEf7OLRVl2nrkSZf3Z1gWACkFV7653o2CBBsdv4gUh erg0AWlS8IkGKcQt1g/GLlzlweaAW56tPpeUvad9ZV5ITPmkxQ8Dgyzupj4BzaYAMWHQcgy0Req0Ti PtROIukljXlZcbdMaeQ9ygjvtuGTh5LOPIQU0L8ktS2slxPnW+NVNit5eIY4hqAy8qbkCtoB8Rj8Uq TC5cY7m7NiRA7eNbLuwXJChBxsc5pjPkZqE6iY7YCMJYESexi1aAZKOs28RwBhqaJvdoBqnC5rwnBo 2Poj7TarRrKB5xqlL0DtQ9P2IijzDVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:dkim-signature:from; bh=jetb5U7QBfYtYJmQ2mDYMYq/BMpOf+aw0i0AaAz6zcY=; b=mCMpGmu4pFKiFoit4qiaKhzhXc+HYi0brRw6eCqDZPF/K5cbwzVmapKR4WEiQf15idTLxFsn4LZRB hlaj0ZHwxtXPSJoc1jKtiyiyFP3iy3R/qD0TFWaI1gAeGxWBCIQy9bQQAstGPZQaN/11/HaFUF6z/H f4RLYP8R732jJ39YSPlwQDLS0pJjEs/de9UMLM8rmgWagtV3TIt4lcf1ipudQLK6qnklqkusgQjfP5 ekJFQcvG768wSvOQYiGH+EHG1icJfyLft0i23xowsR3Bz31Jrr6sghScaNhpVKLUFcDvZ2jk9M39sg vOzRcSzcx1khEL/MXxXjGYvptySYrjw== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:from; bh=jetb5U7QBfYtYJmQ2mDYMYq/BMpOf+aw0i0AaAz6zcY=; b=KyrVAxquhtSf+OYKifR4Gyi3hmuL59yJq6hlIHXic9WQqbcrbevQU4W9iqkCxopoE0ZR3UJKOKCp2 7WaQvlg63CU3hSvUjvSEABwgRabjw6wpJcSWV5QVZhZaTcaNk5BFqtDp5am4piZxfDV7b839/Q6mL3 2awpW3Cz/Qfqih3VMDTjyO8l1tielD4vA3/Kns1CW3CzK4kpWHsoIbiE2TvBlG9qKzeF6T9y+RTtrF Z12Oi2uOxv5136kuaCPse8rzMaLTHNnDvDuKMIQ1oqNYsPUPaNzedL8rU1fH1OyKNVMnCcgtBWw1/9 wQPnjVl/xplBd0sp1cHyfPQW90tPR1A== X-MHO-RoutePath: aGlwcGll X-MHO-User: 1bf7a896-fac4-11ea-9e11-df46ed8f892f X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 1bf7a896-fac4-11ea-9e11-df46ed8f892f; Sat, 19 Sep 2020 22:04:38 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 08JM4bdU015080; Sat, 19 Sep 2020 16:04:37 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: onboard wireless on rpi4 From: Ian Lepore To: tech-lists , "freebsd-arm@freebsd.org" Date: Sat, 19 Sep 2020 16:04:37 -0600 In-Reply-To: <20200919184637.GA27098@bastion.zyxst.net> References: <20200904134619.GB80905@bastion.zyxst.net> <69934262-D9D3-4986-849D-9E8221D1E387@kronometrix.org> <1677459627.55.1599232125847@localhost> <75E08DC2-D229-45AA-85AE-CCF06FD0B490@kronometrix.org> <09959D86-E3E3-43E9-8134-C2FC73343DBA@lists.zabbadoz.net> <20200905181220.GG80905@bastion.zyxst.net> <20200905234313.GH80905@bastion.zyxst.net> <20200919184637.GA27098@bastion.zyxst.net> Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Bv4Vx6qBLz4Z7h X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US]; local_wl_from(0.00)[freebsd.org] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2020 22:04:42 -0000 On Sat, 2020-09-19 at 19:46 +0100, tech-lists wrote: > On Sat, Sep 19, 2020 at 04:22:34PM +0000, Robert Crowston wrote: > > > Do you have a serial cable to get the console output? It would be handy > > to have the boot output. > > alas, not a suitable one. Seems I need a serial (or usb masquerading as > serial) to tty cable for serial console output, from three GPIO pins on > the pi. > > I hoped it was possible to get the output to ethernet port on the rpi but > I don't know how. Think I need tty to serial/usb cable, unless you > know of a different method? Somehow make the ethernet port output console > output? The one I already have is an FTDI usb <> rj45 console cable suitable > for eg cisco equipment. > > anyway, should be getting said (usb/serial<>tty) cable in a few days though, > hopefully. > Your cisco cable is a standard usb-serial adapter the same as any other, it just has an rj45 plug because cisco made a rather insane decision many years ago to use that type of jack for a serial console connection. But, the cisco cable is rs-232 (inverted high voltage signaling), whereas the console pins on the rpi are uart-level (3.3v non-inverted). -- Ian From owner-freebsd-arm@freebsd.org Sat Sep 19 22:19:48 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 95B1B3F113A for ; Sat, 19 Sep 2020 22:19:48 +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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bv4rM5Tmwz4Zdb for ; Sat, 19 Sep 2020 22:19:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 12s3WOIVM1nysYnYzCc5xfyErOvNURCWXwb.Yhy7HVAHplBkaSpYXYv3s4rmGuJ 9zZJ6zlkKxFbMPxOACgBT9R4dT_QjhV9quniLkPAP6C4YXAP.c75X6uXLDHGt952Zjme2BYrqk_M 9nIyczf.JxdDZ_opC1e_ncOybBMJmL4M84b6vzRoYLDKZrTdnJ7X0kkgrV9fwfLKQ2zGTCGy91yT 5dl08.vHlUWqsQvf5gBrHn5M.PRLEM9ZhlAA0sD6CRsf.VCqnlwspWRrwu6S1KjsPszqAWFMYk7W CnTVBKxJWrwO8ExqIDAOBc12oHLjdeDA2cXgQN3mrTz6XMIkcOFykP14pO5TMzRGJ9qJjdS3gyMk 5hXaAnOwzVT3wLvn8U2Sk3ZY_X.03_TICVqqbs6PdCf5szwtnFG1_VCg_rdhMhHWHY_eNFErB7oE ElVUw2pfDFJFYPFyGlhxiytz32PU_R6mhidX6SBhQ6KLCSPu2dA36Lkre98XXTKfifGqociAPOoc VVRubPuE8FN9YDl9mfvarmymbm_32ArBOCC2WIVQsfZTpG66kVMplTphmVemu5mK36MNScbvUqa2 lyQniup1H8WosrVZNHjhwVwPqJRd_CigwaogkW.rL0jaML06pDMpUdfeJ0XsrdZomCozFb.nCsOo JhwbOEq5X6WjdAsg55SJF4Eq8G_Wf8ZVjJxGhnRJz6M1BU75fQCeEQPTUMgFOrHGzJu2C508Ntav qU0Fcmq5wLlFFbyWhQ217a9XTOZG8bTeOWo7flAoopet14aqSb_TDFNMq40T092m7br9QrMtAGdx rhBFqEcZxOp5r.hEpUlGylXOQwz40rSKZQNeUblO4KAnE4TIrTb45DI59OwGbN2edDHFO_0BMhXL TmfCc73smdCu19LzI6bpYQ.AORxC4ViKdDlgcG0OzAmi7GJfnDSglFCpeQsZSeOFTjDzVFPud0k9 t.r8MczsiZsXTMHcWCQjuxv.H.Nd.yG2jMuovM4dbOtQ4Ua3BWwicbJ.Cu9K_RuYfLv76XS6QOnz B1jCvqZpcwZhvuGFfBLgEO5ZnJXLb3_m5agkaOnODF10np.HkDhlu6OGRL1hY7i.0O9vxTYUTu.0 F..bDm7B22LrOOBGoRPcnltvbbobhgleLIlXqKDUkIOc2OyuTKsITiFPPwxL5ZO8_SzHSYYCjp3O ngQd0m1jI2F8GdlUSAtr3vFvfyVPpQM_B1lV1IUKTjWyOfaB_iS0yRn0EBOItCiMRm5VRcX.5R0c .Wa_02r4ar5JKvZl7rN3tFGOcRbThD5re3WnExPc_VNLKUGALernfpy2P8TOVlcYV3e2NZqPul9o Zt7TKNe.9uTtdcy0PigadcS_5yVsNfRNMHGapyVgOpJFM0I8qtfsScZkgRuDbIQdIIL47lMk0brE z9g7ymVm6ujtQP7m8cjHiiKkeJbOeZnuUTRAUgmhRN5_HNEDrjr1YThpCIhXhRRyKtUL1aWeGY_h 4Ti4HKIRkSnyZK13aCwrNhqlk.Ho6v2EXPW0GYAuSLtXt7kl1YZFCIAbs9R.f_7gcohs7yeYdgNx z Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sat, 19 Sep 2020 22:19:45 +0000 Received: by smtp418.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 979d2853e5fecc080629c81695e86217; Sat, 19 Sep 2020 22:19:44 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: Comment #135 for bugzilla 237666 : a USB3-handling problem with a investigatory fix for a cortex-a72 context From: Mark Millard In-Reply-To: <7_E2XXmpIwdiLPwD5tkXUAFlHsAhrFIbs87-JJnE57wRg4vrRcqCL1qSToBN_52_YjcPvt7HQSrzA0v6fWDAYIoN348pYVc62bTUXNxudBU=@protonmail.com> Date: Sat, 19 Sep 2020 15:19:42 -0700 Cc: Hans Petter Selasky , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <3D0CFAD6-A93B-401E-82CD-831E22BD8D7A@yahoo.com> References: <6E618C3D-12DF-429E-A249-5BAB90FC6B15.ref@yahoo.com> <723E6915-94F5-417C-B4AF-EEEBFBDF6162@yahoo.com> <565258A0-BEE1-48F8-9851-E6C7CF7ADAE7@yahoo.com> <75af04ec-0021-3575-40bf-c5ab9b6d4703@selasky.org> <9cf87718-9d4a-60ca-004f-5818371c937b@selasky.org> <47D6CA1E-F842-47B6-97E0-C87B33610C64@yahoo.com> <8BAF3798-4BB4-4C5E-87FC-ECD1458910A2@yahoo.com> <7_E2XXmpIwdiLPwD5tkXUAFlHsAhrFIbs87-JJnE57wRg4vrRcqCL1qSToBN_52_YjcPvt7HQSrzA0v6fWDAYIoN348pYVc62bTUXNxudBU=@protonmail.com> To: Robert Crowston X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4Bv4rM5Tmwz4Zdb X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.57 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.04)[-1.044]; FREEMAIL_TO(0.00)[protonmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.008]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.02)[-1.022]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.147:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2020 22:19:48 -0000 On 2020-Sep-19, at 14:49, Robert Crowston = wrote: >=20 > I=E2=80=99ve been working with aarch64 with mcpu=3Dcortex72 on the = rpi4 with u-boot. I did not need this extra barrier or flush. This = suggests the problem is slightly more nuanced. (I do not object to the = extra barrier if it fixes your problem, I=E2=80=99m just adding extra = information.) >=20 > My question, which may be irrelevant or misguided: The flags field in = the dma tag has an option for specifying if the hardware is cache = coherent (BUS_DMA_COHERENT). Does the UEFI-derived tag passed through to = the xhci driver have this bit set? >=20 > I was slightly confused that explicitly generating a barrier after = calling bus_dmamap_sync(9) had any effect. I understood that the purpose = of the sync function was to generate whatever barrier or fence the = underlying bus required, if any, to ensure consistency. But, if those = barriers were not required in the end, perhaps that is a red herring? You are just somewhat behind on the investigation/testing. All my explicit DSB ST / DSB LD use has been eliminated. (I warned originally that what started working need not be minimal. Only one turned out to be contributing to allowing correct operation in my A72 context.) The one DSB that needed to be added (for aarch64 contexts) is now covered by a call to: usb_bus_mem_flush_all so that the change is machine independent at this level and picks up machine dependent code as needed: # svnlite diff /usr/src/sys/dev/usb/controller/xhci.c Index: /usr/src/sys/dev/usb/controller/xhci.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/dev/usb/controller/xhci.c (revision 363590) +++ /usr/src/sys/dev/usb/controller/xhci.c (working copy) @@ -431,6 +431,17 @@ phwr->hwr_ring_seg[0].qwEvrsTablePtr =3D htole64(addr); phwr->hwr_ring_seg[0].dwEvrsTableSize =3D = htole32(XHCI_MAX_EVENTS); + /* + * For bugzilla 237666: + * According to extensible-host-controler-interface-usb-xhci.pdf = , + * the later XWRITE4's to XHCI_ERSTBA_LO and _HI lead to the = xhci + * needing to copy the qwEvrsTablePtr and dwEvrsTableSize + * values above at that time (as the xhci initializes its event + * ring support). This is before the event ring starts to pay + * attention to Run/Stop. Thus, make sure the values are + * observable to the xhci before that point. + */ + usb_bus_mem_flush_all(&sc->sc_bus, &xhci_iterate_hw_softc); DPRINTF("ERDP(0)=3D0x%016llx\n", (unsigned long long)addr); (I'm not the one that identified usb_bus_mem_flush_all as the appropriate FreeBSD way to express the criteria in a machine independent way. I just did the testing and earlier evidence gathering in a A72 context that is an example of the more general bugzilla 237666 issue where non-arm platforms also show odd behavior. I'm hopeful that the above will fix them all.) On Sat, Sep 19, 2020 at 22:18, Mark Millard via freebsd-arm = wrote: > On 2020-Sep-19, at 13:54, Mark Millard wrote: >=20 > . . . > > > > As stands, in my head -r363590 based context, the patch set for this > > overall currently looks like (up to E-mail variability in spaces): > > > > # svnlite diff /usr/src/sys/dev/usb/usb_busdma.c = /usr/src/sys/dev/usb/controller/xhci.c > > Index: /usr/src/sys/dev/usb/usb_busdma.c > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --- /usr/src/sys/dev/usb/usb_busdma.c (revision 363590) > > +++ /usr/src/sys/dev/usb/usb_busdma.c (working copy) > > @@ -737,6 +737,9 @@ > > */ > > bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_POSTREAD); > > bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREREAD); > > +#ifdef __aarch64__ > > +__asm __volatile("dsb ld" : : : "memory"); > > +#endif > > } > > > > = /*------------------------------------------------------------------------= * > > @@ -750,6 +753,9 @@ > > return; > > } > > bus_dmamap_sync(pc->tag, pc->map, BUS_DMASYNC_PREWRITE); > > +#ifdef __aarch64__ > > +__asm __volatile("dsb st" : : : "memory"); > > +#endif > > } > > >=20 > Looking at the lower level code it looked like DSB SY is used for > the above two automatically and it should be a valid sustitute > for DSB ST and DSB LD, even if overkill. So I'm testing with > dev/usb/usb_busdma.c reverted. (See later below.) >=20 > > = /*------------------------------------------------------------------------= * > > Index: /usr/src/sys/dev/usb/controller/xhci.c > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --- /usr/src/sys/dev/usb/controller/xhci.c (revision 363590) > > +++ /usr/src/sys/dev/usb/controller/xhci.c (working copy) > > @@ -431,6 +431,7 @@ > > > > phwr->hwr_ring_seg[0].qwEvrsTablePtr =3D htole64(addr); > > phwr->hwr_ring_seg[0].dwEvrsTableSize =3D htole32(XHCI_MAX_EVENTS); > > + usb_bus_mem_flush_all(&sc->sc_bus, &xhci_iterate_hw_softc); > > > > DPRINTF("ERDP(0)=3D0x%016llx\n", (unsigned long long)addr); > > > > >=20 > The test booted just fine, no "Resetting controller" notices or the > like. So now I have just: >=20 > # svnlite diff /usr/src/sys/dev/usb/controller/xhci.c > Index: /usr/src/sys/dev/usb/controller/xhci.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/dev/usb/controller/xhci.c (revision 363590) > +++ /usr/src/sys/dev/usb/controller/xhci.c (working copy) > @@ -431,6 +431,7 @@ >=20 > phwr->hwr_ring_seg[0].qwEvrsTablePtr =3D htole64(addr); > phwr->hwr_ring_seg[0].dwEvrsTableSize =3D htole32(XHCI_MAX_EVENTS); > + usb_bus_mem_flush_all(&sc->sc_bus, &xhci_iterate_hw_softc); >=20 > DPRINTF("ERDP(0)=3D0x%016llx\n", (unsigned long long)addr); >=20 >=20 > for the issue. (So my earlier powerpc* SYNC comments are likely junk.) >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Sep 19 22:39:33 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3C86D3F1839 for ; Sat, 19 Sep 2020 22:39:33 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) 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 4Bv5H8335hz4bph for ; Sat, 19 Sep 2020 22:39:32 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [178.17.145.105]) (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 mail.turbocat.net (Postfix) with ESMTPSA id 5D47926029F; Sun, 20 Sep 2020 00:39:30 +0200 (CEST) Subject: Re: Comment #135 for bugzilla 237666 : a USB3-handling problem with a investigatory fix for a cortex-a72 context To: Mark Millard , Robert Crowston Cc: freebsd-arm References: <6E618C3D-12DF-429E-A249-5BAB90FC6B15.ref@yahoo.com> <723E6915-94F5-417C-B4AF-EEEBFBDF6162@yahoo.com> <565258A0-BEE1-48F8-9851-E6C7CF7ADAE7@yahoo.com> <75af04ec-0021-3575-40bf-c5ab9b6d4703@selasky.org> <9cf87718-9d4a-60ca-004f-5818371c937b@selasky.org> <47D6CA1E-F842-47B6-97E0-C87B33610C64@yahoo.com> <8BAF3798-4BB4-4C5E-87FC-ECD1458910A2@yahoo.com> <7_E2XXmpIwdiLPwD5tkXUAFlHsAhrFIbs87-JJnE57wRg4vrRcqCL1qSToBN_52_YjcPvt7HQSrzA0v6fWDAYIoN348pYVc62bTUXNxudBU=@protonmail.com> <3D0CFAD6-A93B-401E-82CD-831E22BD8D7A@yahoo.com> From: Hans Petter Selasky Message-ID: <486e827b-b868-abe1-0ac9-478227779a63@selasky.org> Date: Sun, 20 Sep 2020 00:38:58 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <3D0CFAD6-A93B-401E-82CD-831E22BD8D7A@yahoo.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Bv5H8335hz4bph X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-2.91 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_LONG(-1.01)[-1.013]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.59)[-0.594]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; FREEMAIL_TO(0.00)[yahoo.com,protonmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2020 22:39:33 -0000 Hi, Here you go: https://svnweb.freebsd.org/changeset/base/365918 --HPS From owner-freebsd-arm@freebsd.org Sat Sep 19 23:35:46 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 645FC3F29A0 for ; Sat, 19 Sep 2020 23:35:46 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bv6X158dCz4fR4 for ; Sat, 19 Sep 2020 23:35:45 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: by mail-lj1-x22b.google.com with SMTP id b19so8046419lji.11 for ; Sat, 19 Sep 2020 16:35:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=GN3UKGS7+PZckkIgh6yBSaVzW7kkwTBYDVdz1y6VSSQ=; b=DkIkeoed8psPzat+IM4RS3onPy+L+Loc3cn3BrqS7FE0qt59ntVJ609+V4UawWWYxr IaHjUOEJ6M0ZJvbcQJ2w3UBIw50HgzXubgA00QlHxZHEGmhGmrXXMfPYfMZnsrcyDqoS gajBz9OO5f3NH4LbkOCG8JLWD4fpkfrfjiXIrisuCedA8yvPhtNvpfuaFjh6xLLvAqGv F2hycj80otjhQWYxkYaM5Du7D5unmu/KPkcyQduKd3pNPDyUF+HQsUXBjfqXnzI+umva l11u61J0LBUzf8jEAR3qq2SfptImf7QyRGaTceoPWQjHmr4pGUI6OrSsV+IdqX2S8t1n KRfQ== X-Gm-Message-State: AOAM531kCL8ghBU9h80HxTbFILjiptEAlbt8CXH/xzRpqN78/4ZA6rNz 9dQIzJAzMpjEkdjGX8G0H1AfOJU+DIU= X-Google-Smtp-Source: ABdhPJzOpbLXsN1DwFip0SDmy7TKMbs/xkGMMPIGMdBBO6bDsCkl4cj1fqTczSP/h2HVUInxumlSuQ== X-Received: by 2002:a5d:4682:: with SMTP id u2mr48111822wrq.254.1600558083141; Sat, 19 Sep 2020 16:28:03 -0700 (PDT) Received: from localhost.localdomain (dynamic-046-114-106-162.46.114.pool.telefonica.de. [46.114.106.162]) by smtp.googlemail.com with ESMTPSA id f23sm27013562wmc.3.2020.09.19.16.28.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 Sep 2020 16:28:02 -0700 (PDT) From: Klaus Cucinauomo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.33\)) Subject: Re: Comment #135 for bugzilla 237666 : a USB3-handling problem with a investigatory fix for a cortex-a72 context Date: Sun, 20 Sep 2020 01:28:00 +0200 References: <6E618C3D-12DF-429E-A249-5BAB90FC6B15.ref@yahoo.com> <723E6915-94F5-417C-B4AF-EEEBFBDF6162@yahoo.com> <565258A0-BEE1-48F8-9851-E6C7CF7ADAE7@yahoo.com> <75af04ec-0021-3575-40bf-c5ab9b6d4703@selasky.org> <9cf87718-9d4a-60ca-004f-5818371c937b@selasky.org> <47D6CA1E-F842-47B6-97E0-C87B33610C64@yahoo.com> <8BAF3798-4BB4-4C5E-87FC-ECD1458910A2@yahoo.com> <7_E2XXmpIwdiLPwD5tkXUAFlHsAhrFIbs87-JJnE57wRg4vrRcqCL1qSToBN_52_YjcPvt7HQSrzA0v6fWDAYIoN348pYVc62bTUXNxudBU=@protonmail.com> <3D0CFAD6-A93B-401E-82CD-831E22BD8D7A@yahoo.com> <486e827b-b868-abe1-0ac9-478227779a63@selasky.org> To: Hans Petter Selasky , Mark Millard , myfreeweb , freebsd-arm@freebsd.org In-Reply-To: <486e827b-b868-abe1-0ac9-478227779a63@selasky.org> Message-Id: <8E916B11-83AB-4045-A501-8F64AD93AF8A@googlemail.com> X-Mailer: Apple Mail (2.3654.0.3.2.33) X-Rspamd-Queue-Id: 4Bv6X158dCz4fR4 X-Spamd-Bar: ++++++ X-Spamd-Result: default: False [6.73 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; GREYLIST(0.00)[pass,body]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[googlemail.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(0.00)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[googlemail.com:+]; DMARC_POLICY_ALLOW(0.00)[googlemail.com,quarantine]; NEURAL_HAM_SHORT(-0.32)[-0.319]; FREEMAIL_TO(0.00)[selasky.org,yahoo.com,unrelenting.technology,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[googlemail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[googlemail.com:dkim]; ARC_NA(0.00)[]; RECEIVED_SPAMHAUS_XBL(5.00)[46.114.106.162:received]; R_DKIM_ALLOW(0.00)[googlemail.com:s=20161025]; RECEIVED_SPAMHAUS_PBL(0.00)[46.114.106.162:received]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; NEURAL_SPAM_MEDIUM(0.55)[0.553]; BAD_REP_POLICIES(0.10)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.99)[0.991]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::22b:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] X-Spam: Yes X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2020 23:35:46 -0000 > Am 19.09.2020 um 23:18 schrieb Mark Millard via freebsd-arm = : > The test booted just fine, no =E2=80=9EResetting controller=E2=80=9C = notices or the > like. =E2=80=A6. > Am 20.09.2020 um 00:38 schrieb Hans Petter Selasky : >=20 > Hi, >=20 > Here you go: >=20 > https://svnweb.freebsd.org/changeset/base/365918 >=20 > =E2=80=94HPS from my understanding by only quickreading this thread : yours rS365918 fixes it so that D25219 was a valid patch =20 that can also be committed? If so, great !