From nobody Thu Sep 29 03:31:12 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 4MdJmn63mjz4cy5M for ; Thu, 29 Sep 2022 03:31:21 +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.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MdJmm73Zmz3kdM for ; Thu, 29 Sep 2022 03:31:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664422279; bh=cyGhQOLIdzrN3clOdkJj7UnVKQKgA9h07bvSfWJFK5g=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=p5iy6l1jGmtmcBsMwhZxBm9K83EX78o0DBtnI0p3aANVXAVK+vpCQJbieQC+ERMaVgXI3VyFFrWf4UvAhtx7DSV9CYYfh1+JpVKNjyDgt4PxgWW1o9SScpK0g4Yw3p2nE1BbqCm8dbHGKzL0rqj6tSnRdXoDTff3DHGeiycbMUPJCN0GYmlgkcz7ddWfgtz4+KTTTpbrBU3lwv+OnKA0qamLmPVfAJwlZYdZUIIeD/rTpvxNQsgHk/DpaU0Zw6KpiJzgy2kTCMxFE8PaE4NObVuLMmCilYPTwWbJoDKOJUFxIeJw4yKkjpaYgYmBXUNKnW2K7N6mMMLc0HOULRimrg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664422279; bh=Ip+zpfjwnoJyMPNsr0cl89dfiHYp+zWmLRTWrHc+nKf=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Kum4ZmPh8lh+I34pXChO8SxtDbosaFWj/EtAMfCavE3VZUh0owPmHBE9hXdiZ/Iw6Ep4yxxqN6wYSoFFIfNOo/+RlBcJNDuwdYffooW0sWOjc5DV6wnDfIhDsmEdQ+pDM+6HXg4fQ9Na63DRtUU9UT3tma/JpasW1t0rvj0RJHLY5jB+vUWb5wZhWp8g8NfoMwOv68MhPRBr1MINPm9rtRuGqxEEHaIY7vnF4AiFju09az84HPkKnzSPwbiAU3MYgqN8+fF7XK+OpNFAjLNx5FJPRN+u31ExleoXwFJkijNpnatK5bml2+rWW3wse4xNdUsy9joUh+kvuQT0CeT3Xw== X-YMail-OSG: E8WCe4YVM1lnryw3.SuSHt3rP3VPQvxqP0Bh1V8loJ7CiBeueIB69s8cP2fUQSx pofKiHkz9GWJWHZdUY4CWmuJDmR5plOvNaIdFQiZNpktNIjr7Yzu09J0oCNEj4BY8nASPETsuwWo NVCI8lC7PDiJ24I8UGTR8Ywm1XKa1OUl8.CMmSoWhTjBDuIxx90aHGQ7kCu81jgcjCbNGoUHxHvJ r3Umx8zYg2LcGmzPG48vAOMgd38aER8kbQG1ON168mR2NLItYeVLSPfjuxOegIZVlovn4wGiIXiV P3yI88GInD8b0LxQ_95uGAXoeFx9XroHuHhZ_0sQAoNxXC7.RwaWf7x4fs93.P9iIbT53FgAkmVm p2nP9F6vPX9ftYRj5Q9aOesdI8bJhU0wtqTQ4ePxVbEfFT_Xb5p4puMwF5aOJZ_RdsHoCB0syg2p Zd_W4tfgkTXix5wwx93QRu9F4G.N8VieBD4sqECOa1AHldAVizJZtwo3XvT.12sTgLsGsvbAmsT1 X3UqO10tMXsu0XpgBsetZylt81U516pVte4tgJQvBfhgTlSBR4gLhH8E9br.WFI44EBbM2bmdHJI 4hnIHYoF8TsKGLOWzStDlTuso9.d37Sr06XGEE5q2zd11Uu08jz7Ww6x2Qjl940F61ioHj8Uni3d 63uj289yotAZOxBgFPxESS4U9dyvisvSN3xWvjJkOyJUSF9AQF7kadvPN8pcGNkYCUSDA8Xi.fZo AoEcC5Es9etf_ffhzdKHguiALG3bqt1YAMu5Mtjlavqyuz7M0GU3tD9ThjTDxH6waATrrTtq7RA0 hOGGm5jjDThUdPPQ_eosYh6GJOzJyYVs9JNZVvHbgqZGKWJQsi4WH4w5qSvHZSVHUv1H60u.B8To AE4t9VNqdjjxUfkCT40AL0OsU9Umf.Vpqj7iRZDgUCoAMoxYKrfeLF.ppMGrLD8g1i8MJu5fL2LB Vn7lYN9nEjIEHGrOB_iS.ryFlkhm2PvDPy8j_6P0Q6yIrBiCY0nyio2xjXyJ_iHkixfL6A3NxyhB hlMJCQUySOa22Qw3Kns_sYwqakbZZ8zQoLoruKBIi9hkXBBJRhTx88UbW1.9Ac8kHRqwxy8si5g7 CotbIlslxv2wwFpq.pZ55s_0iEtTwAre7Ur44BdS5_MDeLHlV6oMMovrUHzO4O1MESiVB1xg_ywR Us1ApzmGCtJAJ0p6Rq9hTxbCq7GBLPMUIFR_.lgkPPgf5M1RAimeLNofdt.ZAclDBwOnpIrpYsXX ueK93KNvDqNL7jVBepM0vscledSFCfM.2RoSgYu6i65dLdfLBZZyumITnwdQ1s2IIQUx1tZI4nZL yA51t.v4_1.363c7oEMFGPGC5t4dGvWrImqlvbAkgO7gZ6bWqWb3n0vq36P9q8uBxe1W.ojdwdM8 egua7tlfEkHHUjfAXnQznHyS4sVQ0u3kSO3hOeb9QYtW6RlBCUEVnnza_ArS3qHW8UU64L3nkW8C 9EUjTkDuTqF90OiSXZB0YX7Rfzdq4wbUoN2dVBX7JG0fyE_Sg_SJm3bp1kZdl7kdg4zh1mTddnjU h1.7uBqF7_KAqcPBI9EaP2SUl7OD7JCqcPWoXy1kx9mNbvRVGBrQq.Gb45fvtzST5LJouWvI8M0w TX.O4sHWCjZ8hIn2u6Ekkr93Ro6ZKU0v6Nt0r58uQWqhNLm4SavTuGOP9KAQEHGWmqalmkTNp1mf sS8Ao1sGCwf4XoO5fKkEG5qaOXORcuT1j1Vuja6zOo4WyAnYmhto03VwYFLeGC3ZAXnwlFU9YH16 YPdNqmYXcvp4MPuD6YQKHuQOxNijABNrYXnBkULVRIzFBq5BQscnEauDF8jxsQRwSEX0QdxcDotn 50eT2hzv6Q1UpeufWutrQlJh_X1Oe8As1wMeu_pGK7YuKyOXCVvto5_vCjBtLJEHmzoBUcgdpgPh TqpH_kTr.zUf5BE8IVCYJAAXOjMIOK0gJRhjl5o6QtCUC1bSEuKbTS5g824LIXWReaYxn9nY2ltA LC85QrHCvSA3Wx.OQL1RfSbAT06alo5MCIGPeE1aLIYnTzY13l9X9M6PszDy6mMhZ7Zv8TZt8M8i lbST2M__hVNPuJE3_MhV4bsRwzjsn6Dl1fcXqi8aZyMLmlRrGK9HlCvSR_acjP6b7.T8J738gp8x nnyvWlVlycBL4oCQBmrv66xBU4xLMlUSQ9DlqKxtc32rv3TX2PCAepdyblQWQlwvjjs3_awJfqLx PTBWKNGtyjF3DhmXB.6WU.UqLSG3xvudvale6K2DNAY7nOWof3FX2kRRtalHFVqlVSzO_zIF.3J9 Vm.Q- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Thu, 29 Sep 2022 03:31:19 +0000 Received: by hermes--production-ne1-6dd4f99767-97ndb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5a79aca97780e9efbe5897450ed11a14; Thu, 29 Sep 2022 03:31:14 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it From: Mark Millard In-Reply-To: Date: Wed, 28 Sep 2022 20:31:12 -0700 Cc: freebsd-arm , freebsd-uboot@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com> References: <9F57D5D0-F715-4DD2-A05C-FB2B9E8B5C30@yahoo.com> <20220928015721.GA73356@www.zefox.net> <20220928045145.GB73356@www.zefox.net> <81F58716-72CE-45E8-951A-B7B92AD0FE95@yahoo.com> <20220928172839.GA75564@www.zefox.net> <62A7FD9D-DFAD-46B2-8681-F6EF0E5AC0DE@yahoo.com> <8CB25EDF-704A-4F86-B0D4-40818291C161@yahoo.com> <20220928234341.GA77046@www.zefox.net> <20220929002131.GA77106@www.zefox.net> <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Rspamd-Queue-Id: 4MdJmm73Zmz3kdM X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=p5iy6l1j; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.43 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.93)[-0.930]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.31:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.31:from] X-ThisMailContainsUnwantedMimeParts: N On 2022-Sep-28, at 20:04, Mark Millard wrote: > On 2022-Sep-28, at 18:03, Mark Millard wrote: >=20 >> On 2022-Sep-28, at 17:21, bob prohaska wrote: >>=20 >>> With the correct patches finally in place there is some >>> extra output from u-boot: >>>=20 >>> U-Boot 2022.04 (Sep 28 2022 - 16:45:12 -0700) >>> . . . >>> starting USB... >>> . . . >>> usb_new_device: Cannot read configuration, skipping device 152d:0583 >>=20 >> The above is reporting U-Boot having a problem dealing with >> your bridge/drive combination as seen via bridge access, >> presuming that I recognize the 152d:0583 correctly. >>=20 >>=20 >>=20 >> Interestingly, that message is not from the routine usb_new_device >> but is from: >>=20 >>=20 >> int usb_select_config(struct usb_device *dev) >> { >> . . . >> /* >> * Kingston DT Ultimate 32GB USB 3.0 seems to be extremely = sensitive >> * about this first Get Descriptor request. If there are any = other >> * requests in the first microframe, the stick crashes. Wait = about >> * one microframe duration here (1mS for USB 1.x , 125uS for = USB 2.0). >> */ >> mdelay(1); >>=20 >> /* only support for one config for now */ >> err =3D usb_get_configuration_len(dev, 0); >> if (err >=3D 0) { >> tmpbuf =3D (unsigned char *)malloc_cache_aligned(err); >> if (!tmpbuf) >> err =3D -ENOMEM; >> else >> err =3D usb_get_configuration_no(dev, 0, = tmpbuf, err); >> } >> if (err < 0) { >> printf("usb_new_device: Cannot read configuration, " \ >> "skipping device %04x:%04x\n", >> dev->descriptor.idVendor, = dev->descriptor.idProduct); >> free(tmpbuf); >> return err; >> } >> . . . >>=20 >> where: >>=20 >> = /********************************************************************** >> * gets len of configuration cfgno >> */ >> int usb_get_configuration_len(struct usb_device *dev, int cfgno) >> { >> int result; >> ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, 9); >> struct usb_config_descriptor *config; >>=20 >> config =3D (struct usb_config_descriptor *)&buffer[0]; >> result =3D usb_get_descriptor(dev, USB_DT_CONFIG, cfgno, = buffer, 9); >> if (result < 9) { =20 >> if (result < 0) >> printf("unable to get descriptor, error %lX\n", >> dev->status); >> else >> printf("config descriptor too short " \ >> "(expected %i, got %i)\n", 9, result); >> return -EIO; >> } >> return le16_to_cpu(config->wTotalLength); >> } >>=20 >> and: >>=20 >> = /********************************************************************** >> * gets configuration cfgno and store it in the buffer >> */ >> int usb_get_configuration_no(struct usb_device *dev, int cfgno, >> unsigned char *buffer, int length) >> { >> int result; >> struct usb_config_descriptor *config; >>=20 >> config =3D (struct usb_config_descriptor *)&buffer[0]; >> result =3D usb_get_descriptor(dev, USB_DT_CONFIG, cfgno, = buffer, length); >> debug("get_conf_no %d Result %d, wLength %d\n", cfgno, result, >> le16_to_cpu(config->wTotalLength)); >> config->wTotalLength =3D result; /* validated, with CPU byte = order */ >>=20 >> return result; >> } >>=20 >> (I'll skip more nested routine usage.) >>=20 >>=20 >> We apparently do not have enough output enabled to see the debug >> routine's output. We are seeing the printf output. >>=20 >> There might be a way to set the output message levels while at a >> U-Boot prompt, up to the maximum compiled in. But it may also be >> that we would need, say, >>=20 >> CONFIG_LOG_MAX_LEVEL=3D8 >>=20 >> instead of the 7 we are now using. >=20 > 7 vs. 8 was not the issue. >=20 > I had the: >=20 > #define LOG_DDEBUG > #define DEBUG >=20 > lines too late in the 3 usb*.c files. Moving them to > before all the #include's in each leads to getting > all the debug output too, at least if I set the > default level to do so. >=20 > But if it gets far enough to make use of the USB media, > then it reports, for example, every usb read via output > like: >=20 > usb_read: udev 0 >=20 > usb_read: dev 0 startblk 87878da0, blccnt 20 buffer 381a1200 > read10: start 87878da0 blocks 20 > COMMAND phase > DATA phase > STATUS phase > usb_read: end startblk 87878dc0, blccnt 20 buffer 381a5200 >=20 >=20 > It is a rather large amount of output (after the failure > point you are hitting). The output messes up the loader serial > output. The EFI loader loading the kernel is done via > U-Boot services and so all those reads are present. Once > the kernel is active, U-Boot is not and the serial I/O is > back to normal. >=20 >=20 > I've included the updated usb*.c files and the rpi_arm64_fragment > update with an extra line explicitly for setting the default > log level. >=20 It looks like that if you remove files/patch-common_usb__storage.c and rebuild/install the large output reporting usb reads will not happen. =3D=3D=3D Mark Millard marklmi at yahoo.com = = =3D=3D=3D Mark Millard marklmi at yahoo.com