From nobody Tue Feb 15 10:47:29 2022 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7CD3119BD436 for ; Tue, 15 Feb 2022 10:47:45 +0000 (UTC) (envelope-from archimedes.gaviola@gmail.com) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jyd8Y0b0Xz4Ydb for ; Tue, 15 Feb 2022 10:47:41 +0000 (UTC) (envelope-from archimedes.gaviola@gmail.com) Received: by mail-ej1-x62c.google.com with SMTP id jg20so18365190ejc.3 for ; Tue, 15 Feb 2022 02:47:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FPM/RDQWgMGO5YQkF2tChWodNuqzKuphiIi9YECE53g=; b=jEoRaReFhBZpWNK7Ci9KBm07A5tzjhFFFdGDKQGaBL+xvAempFc067y/COie7zqvUD IDy2gtPKfHQZMwl2LUJEshZbetv2xZPLhJtj2Bf2hU9/TA2zLPRVE/DcjsQWEFobHx0M qEwOzWJOrkK2jnsBtadBC9OOcnJ2Vibjh/TZul0wQFB5ST89eL+1HeJrahjDJyGUGOJT NhAnPLgWeJX/8taLIT9RQDiIXu0PcZeOI6WYi1asI3znNzkJNoYORDAe5SMhxLtUDghr h+MlTUFsmaXM05pVJdrP6GRaAUL4qwUG7xfRH8Wr8SGAe8VDM0E/lA8EuDXdZkcwVXx4 wgcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FPM/RDQWgMGO5YQkF2tChWodNuqzKuphiIi9YECE53g=; b=Ynj8B/nL5ePxu5f70ZrYBFaNt3qHC86d1ujxZRRn174zuRIhZIvLaTzsmCjNZ1NQfk nG0kpu77BGWUDTcloccjfBDQK1WQlN0I7Zwit4TOuI9pwrc3que046/5SY9P/KIW/PxM lO6yYenBsP9F0RJ7VhchD3eMVC2Eltsd0GwkppmByq9ERd0G4cUloPl7q8W3C246ia9u 284UodQEu7yZA5QYcV4kHi446aw0rXR8DeoGi2FE9CvW8atdZCyDW3cBaLYfEAXBp5mx TMjOHrX/8sIud9T3kdoI+r0fKIQHZFP/pxpVPw+FqRrh+HXGyQCccpd2olKSpN+EwC+W tKWQ== X-Gm-Message-State: AOAM531n2WWcH2f2JD9IQFRYZCfMruQi96U1SrRvjyHDohPrCfrEv47C EvYGvGpyyYoXNW8IW9Y3/gWrwiJUB7JM8INts7UR566uPoCP8Q== X-Google-Smtp-Source: ABdhPJzwYFxAljaJB1gwoR5n9s3wY113+T7XeKH94dEpSrz6DO/ARhGGtu6cX0RnqfvZgv1/lJeLTS1q6d4NT+hbLq8= X-Received: by 2002:a17:906:3f5b:: with SMTP id f27mr2538210ejj.62.1644922060033; Tue, 15 Feb 2022 02:47:40 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <202112231500.1BNF0FgX014693@mail.karels.net> In-Reply-To: From: Archimedes Gaviola Date: Tue, 15 Feb 2022 18:47:29 +0800 Message-ID: Subject: Re: Raspberry Pi 4B does not detect devices in USB 3.0 To: "Daniel O'Connor" Cc: mike@karels.net, freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="00000000000012548405d80c4324" X-Rspamd-Queue-Id: 4Jyd8Y0b0Xz4Ydb X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=jEoRaReF; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::62c as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; BLOCKLISTDE_FAIL(0.00)[2a00:1450:4864:20::62c:server fail]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62c:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 5015 Lines: 96 --00000000000012548405d80c4324 Content-Type: text/plain; charset="UTF-8" On Tue, Feb 15, 2022 at 6:22 AM Daniel O'Connor wrote: > > > > On 14 Feb 2022, at 23:10, Archimedes Gaviola < > archimedes.gaviola@gmail.com> wrote: > > I just tried my new RPI4 board and it seems to work fine the same as my > old board. I just observed that the problem is when my VFD (vacuum > fluorescent display) device is connected to either of the two USB 3.0 > ports, this device having uplcom(4) driver is not detected. > > I wonder if the VFD is causing interference - it likely has a high voltage > supply and those are notorious for generating electrical noise. > > > It's a Prolific USB-serial device having PL2303 chipset. However, when > plugged-in to USB 2.0 ports, this device is detected and functioning. I can > send characters with the echo command and redirect it to /dev/cuaU0 for > display without any problem. Other observations when this VFD device is > connected to either 3.0 ports, the 2.0 ports will not function i.e. > plugging-in any USB devices like my keyboard or my EMV reader. When this > device is also connected to either of the 2.0 ports, the other 2.0 port is > functioning for other USB devices while 3.0 ports are not. I attached two > dmesg outputs when the device is detected with 2.0 ports and undetected > with 3.0. I also include kldstat and usbdump. > > I would be curious if putting the VFD on a longer cable, or wrapping the > cable through a ferrite, or using an external hub fixes it. > > Any of those would give a bit more isolation between the VFD and USB3 > hardware. > Thanks Daniel for your recommendations, I've tried extending it to a long cable and using an external USB hub however the outcomes were still the same, it cannot be detected. As per checking, this device has a default ferrite bead clamped over its USB cable. Using the same RPI 4B hardware, this VFD device has been tested as well with OpenBSD 6.9 and CentOS 8. They both work with USB 3.0 except OpenBSD system will panic the first time you plug-in the device but will work fine after a forced reboot or when you unplug and plug back the power. Thanks, Archimedes --00000000000012548405d80c4324 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Feb 15, 2022 at 6:22 AM Daniel O&= #39;Connor <darius@dons.net.au= > wrote:


> On 14 Feb 2022, at 23:10, Archimedes Gaviola <archimedes.gaviola@gmail.com> wrote:
> I just tried my new RPI4 board and it seems to work fine the same as m= y old board. I just observed that the problem is when my VFD (vacuum fluore= scent display) device is connected to either of the two USB 3.0 ports, this= device having uplcom(4) driver is not detected.

I wonder if the VFD is causing interference - it likely has a high voltage = supply and those are notorious for generating electrical noise.

> It's a Prolific USB-serial device having PL2303 chipset. However, = when plugged-in to USB 2.0 ports, this device is detected and functioning. = I can send characters with the echo command and redirect it to /dev/cuaU0 f= or display without any problem. Other observations when this VFD device is = connected to either 3.0 ports, the 2.0 ports will not function i.e. pluggin= g-in any USB devices like my keyboard or my EMV reader. When this device is= also connected to either of the 2.0 ports, the other 2.0 port is functioni= ng for other USB devices while 3.0 ports are not. I attached two dmesg outp= uts when the device is detected with 2.0 ports and undetected with 3.0. I a= lso include kldstat and usbdump.

I would be curious if putting the VFD on a longer cable, or wrapping the ca= ble through a ferrite, or using an external hub fixes it.

Any of those would give a bit more isolation between the VFD and USB3 hardw= are.


--00000000000012548405d80c4324--