From nobody Sun Oct 02 19:48:33 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 4MgZK80Lxtz4cvbR for ; Sun, 2 Oct 2022 19:48:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-20.consmr.mail.gq1.yahoo.com (sonic306-20.consmr.mail.gq1.yahoo.com [98.137.68.83]) (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 4MgZK63yxQz3S2B for ; Sun, 2 Oct 2022 19:48:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664740119; bh=/tyvSeK3WiBOs7u/rW0dhezNFn9lb2kEqvxWjNm77Jg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=DzzPgd5XBOGQ0pR+wL7QF+zGhbPpZ0bteTJTHHPYwR/s1gUZnuzPLJNuFRSeu78xFvAQlKAR1gxTtKbRqyarG48BjdOJguWSO9zaeF1e39BzjwRbdAph/a82v6YjXjh+VP0ZMHlRw7t44J+rSn0drw3ynVtbZRTsECLpCX+x0O6SYsw1LR8QXwhdwNNLsNmWp86YGa9jfYsZ7tLi4b3daSHPw4DmvRHlxjSqjirscaf25ByvGC+VEl/T6XR1UYtvBGkjRZa6sY90wxff9BkvDgs2KIlz3yyrkOZhs4HhufbFAkg0To2cZvnp7J7mDWx1yfozCpDNDPl9zF8LJOp+ig== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664740119; bh=QkZBiWHd4V3/beHKtV8/FbqCKr9vek70CDgFVxFdlkN=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=BcgcaBd9cWYsPjWGBmxteq6fMWyBqhrfESEUBO7qwPM2Ir46dfAHdhtLwMoWV6YS1o7tZ95Yz96UHH7eioIdAR2xFrCPYcZeFahWenFMKDdoo3AWO1HFeGaaL31jH6tjT+r2UzzXR+U/kqoge95Krrt/xHAhbnQqqQDJXsxUeIUECKyLIc1f4EfiUqIwsofbPsm6oKIQWFfp6VjXcnKmgEziOOqh7DsfGaaZvr2DmT9LkyQVqROGph+/mjquX8NuwgEzTC8SAp6mSRmk9Ri1j3jeNNpJSjUBJoIV2D1D23Z7tsiMg5x2ef4SUMHwKav6pQiCZfJxLudRYYHv8Mi/iA== X-YMail-OSG: VLzFZDYVM1mAR77AjvRcA_Znl8tgMi1pjuf1uVwoGI2.QW5pdb3T4DSClP_zZBH kaCxnPDZQGr3K5X9SxrK3A8HT3vnpC7Vsxg2jhml4VVKk0xhz0CwN_CivPGxk6kUiqCsv5ncCpOm 7vupn7n2jq0qLUgdlh.YdQiKAZ1ij3RdKLEy7iJzTuccy5zntNFj4mptndvMFgXzi7Ug1hyxUdGv ezvQ7bUP0QiqZGp.hgaMcrYpBAX0bCSw3UCKMALbwxPBYIthrLN1O3zmQMLOrELMwl6zlmUG5Oap MFLzKeXrct6XtsMnZDyRC_.iHuuLN_RM.JhN2O8vbYHijX5N5vcgFF2zPvDtAoQSAIDtLdF0vaMM PoEMu7FVCPVV5C53aetpEEUcjTRcoriXXlhkJO8hMFiBSoC2UippYUqsHxwg9pW7H1wGBVjqa2tQ Xq.WWEK3R3oo4kQIJGACcbni8N4jtUNEMrTDqtkj4yLTA6_L5ooo4cUasgAHcH_ncyO.BaFFA4bT QRSXN74A_2q.PP1xdxe0dJlCYW9llXFHS1McjlOnisLR_JNhiuWUc7IqLOF_6mlOKZuqSPyNbL3A Sc3Rd.XAIqW_EzM5Xj7dMOqEobVdvfdIKwya.XVPw6mP_DZNLnSQ.1HV22tK3WVFLQw8DnKmHG9O hzRJc9IAStddSYeSm2KTz0uJ_ENj.mhWqofpe86NTmiKy0g17y0gItiqbx7OjSjJjjAlXdjyjtMb BcG5vUBA99rBT6.J8U1BR..CYv5h4qabai9UWN9bM4S9nAQTUqmzoaqhK.ROhvCu7VEVTRU0HYGK _GVyfsoPGC.YseSxnvL4ZZ1rRo3yDi0WYxdYXQy5BxeHg.K9VjMhYCUDt1dqXQ.EgLBRmHH2A4Dd UPy50WoqtKJGcccwGRtLp09EmUp4kWzMXBqh1wqOJX3DeMGgXRniXgsNxfzSsHxtRIBn.k6YNgrp AE.KSUT7Fovy_Gwd6JZW7ks2jfqJxlJlnZZKTVeuvBEJvQ2Z.4At2ubTDigPiIdjbz3XX218eAE_ _LhtTDJGJp_XydsW9dKUq1cgs8zo15HQ2qMKjVTcjBE7tbob5YCszxoacJwUhba8h8sK_FSB_.pm FhIcfsn4C4RHzCCjkhNApMSBlhpLj_hyDEDxkyt40.VgX4VjwEbI0.z72MhyiozHy18ppDtugOhM 21Gg1HLwWLkKn361bRGhHTT0Ge225eBW9_Fn8teTyL0yHxgQ3pd4qNBDLOFEd.qI5W.YOpxokbfH wYP1Jn1jdQwNVcczy83a6xCfw3XKW6bmd2TpVdjYngO9RpA77nmcGoY6K3CWIHFzTxVDAoCL1VF5 IBvWHuoJXpRA1S078ei.6bRVlCpaLuBqimEsG_pEzXqG8zkqM7FP8tYAej.L9fT8ZfWyLpa8hxip 07kxPiZiugVPnOaUnBgZY.c._FDKgOTQA8da_lhsmEurXgO5wspzATHqdNHlly_Dtw10CNnp.HlC BipfxE.0zPkk1ggehLNH063B67EpEAElzw5qD061UT7K61W2IMvvCHRL3ug2zaHiBPKW5f3ANofD UZ.BT2Q2V9vvJjD6_ciYQ_WnfCFqzRx62xk.cBSLOsbmQoLTHZx7dvVOSgvROzteguEFjIC06dqq X3bGpdZPnNS48zQHTzumSKuDX2wU_3_ZUioF6Rg81YvJ9lqkQpjbMJjYS_4OQ_Lgg30Z1qexacNz C24ZBBZ_iIbZbvsYjEhzTBbihnzNdIkyuKjneZBcZ_yFdEPR9IKS1kmA.JWGGz1koGMeaS_ZqJDv CcPbH_p0qJl1taOtTY8wUt5fo3hau4q_rKOerCnzEGbCB9y5tNwWyq8o8IK.xYVf_W0Lf1.ANORe HDRG3gprWaQEEqZarLQOD5kKUrtrdsIE1nDmwvZdeWrR2g.191VT03mwgLUmMNmGQtTvBSF74.Wu 4XLveVUQfUkj.0i5FUobq4SBcMH6xYI1kR_0ndGEmwhauGseJZ1sEXz.MvlxUgmaTlckw4YhW1uB W2atkkaZ.v_VvEK5Tiup0u8qUzi6LF9xd_5E0LNFmQErMs_kM3X_JAFkIJMH63t9jZZrHhOfFEyA YCcw4pqcIcogvpbdAbaZpbWOb5CMlQG_eCxD7ylgmk1nDWG9a7SewuoHdpzEQn8YHBfC5K.LOEfV rDfkx4zK2g.vMF3DGov8RjmkmM9QEeWnFom5eAlJTtaj1eG0EIYxKsq0PocMWYhill3cLtwZf7jW 3U_v1tuzrUBjseuF681t2.2VaKYz15jCA.DeFmod2CAbCHLDEk32v0AMkID01Sk0lIuL8TgEqd3H OB80sFe8- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sun, 2 Oct 2022 19:48:39 +0000 Received: by hermes--production-ne1-6944b4579f-t822l (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 331916cd8482c9e935da24c1c8453286; Sun, 02 Oct 2022 19:48:35 +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: <20221002182049.GA2255@www.zefox.net> Date: Sun, 2 Oct 2022 12:48:33 -0700 Cc: freebsd-arm , freebsd-uboot@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20220929002131.GA77106@www.zefox.net> <197D3C46-063B-4C67-AB1A-A3A072521D7F@yahoo.com> <6AA65AE6-41F1-405F-A592-7D641EA4C9CF@yahoo.com> <20221001174724.GA98055@www.zefox.net> <20221001193033.GA98348@www.zefox.net> <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com> <6DB88FC9-629C-43E6-9673-32640FC547F7@yahoo.com> <20221002182049.GA2255@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Rspamd-Queue-Id: 4MgZK63yxQz3S2B X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=DzzPgd5X; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.83:from]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N On 2022-Oct-2, at 11:20, bob prohaska wrote: > On Sat, Oct 01, 2022 at 02:21:42PM -0700, Mark Millard wrote: >>=20 >> http://nemesis.zefox.com/~fbsd/pelorus_console.txt7_orig_fragment >>=20 >> still shows all the debug output. It did not >> avoid the timing changes. >>=20 >> You might need to not use either of: >>=20 >> patch-common_usb__hub.c >> patch-common_usb__storage.c >>=20 >> and to disable the LOG_DEBUG and DEBUG lines in: >>=20 >> patch-common_usb.c >>=20 >> via turning them into comments by adding // as >> indicated below: >>=20 >> +//#define LOG_DEBUG >> +//#define DEBUG >>=20 >=20 > I think the changes were successful, u-boot compiles and > runs. There's no extra output, and unfortunately only one=20 > successful reboot so far. Bus scanning seems quite slow. > Storage devices are rarely found on reset, but usb reset > does sometimes work. Run bootcmd_usb0 paused for minutes > at Device 0: and paused again after reporting ..current device. > No echo from the console, ctrl-C did nothing.=20 >=20 > The attempt sequence was > SRBSPRMRPRRPUPPRRUPUCUUC > where=20 > S is shutdown -r > R is reset of u-boot > U is usb reset > P is powercycle > M is stop at mountroot > C is run bootcmd_usb0 >=20 > The console log is at > http://nemesis.zefox.com/~fbsd/pelorus_console.txt8_no_debug >=20 > It now appears that the run bootcmd_usb0 rather reliably gets > stuck, with the disk LED on steadily (no activity). Maybe in > one of the loops seen earlier?=20 Of 27 " Storage Device(s) found" notices: 18 are: "0 Storage Device(s) found". 9 are: "1 Storage Device(s) found". so the 3 mdelay(...) lines are far from sufficient for that issue. I see no way to tell if some variation of them (different delays and/or a subset of the 3) is somehow necessary. It would seem that some of the delays from the debug output to the console were an essential part of the prior lack of examples of "0 Storage Device(s) found". I'm not worrying about what happens after " Storage Device(s) found" so long as "0 Storage Device(s) found" is still an issue for one or both of: 0x152d:0x0577 0x152d:0x0583 In part that is because, for all I know, the source of the earlier problem might well also contribute to the later problem(s), even when "1 Storage Device(s) found" happens. If the build had the adjusted mdelay and the 2 additional mdelay calls in place, it is not obvious if they should be kept or not. Fedora 37 is in Beta currently and is supposed to be final in late October or so. It is the first Fedora version to officially support RPi4B's, now that it has accelerated display support and the like. Fedora (older and 37) uses U-Boot for how it boots RPi*'s. If you had the resources, I'd suggest producing Fedora-based media and seeing if it has the same sort of U-Boot-stage problems in your device-types context. (RaspiOS and Ubuntu do not use U-Boot last I knew. So they do not make for good comparisons for the purpose as far as I know.) I'm going to provide notes below about how I produced the patch-common_usb*.c files. The sysutils/u-boot-rpi-arm64 port did/does not already have patches for these files. I build via poudriere, not via use of /wrkdirs/ . . . so I can use /wrkdirs/ . . . as an area to look at source code without needing to worry about building the port in there. Starting with a /wrkdirs that did not contain a /wrkdirs/usr/ports/sysutils/u-boot-rpi-arm64/ I did: # make -C /usr/ports/sysutils/u-boot-rpi-arm64/ extract to populate /wrkdirs/usr/ports/sysutils/u-boot-rpi-arm64/ . I then made copies of the sources that I was going to change, adding a .orig suffix to the names of the copies. Showing the resulting paths: # find -s = /wrkdirs/usr/ports/sysutils/u-boot-rpi-arm64/work/u-boot-2022.04/ -name = '*.orig' -print = /wrkdirs/usr/ports/sysutils/u-boot-rpi-arm64/work/u-boot-2022.04/common/us= b.c.orig = /wrkdirs/usr/ports/sysutils/u-boot-rpi-arm64/work/u-boot-2022.04/common/us= b_hub.c.orig = /wrkdirs/usr/ports/sysutils/u-boot-rpi-arm64/work/u-boot-2022.04/common/us= b_storage.c.orig The copies were made via: # cd /wrkdirs/usr/ports/sysutils/u-boot-rpi-arm64/work/u-boot-2022.04/ # cp -aRx common/usb.c common/usb.c.orig # cp -aRx common/usb_hub.c common/usb_hub.c.orig # cp -aRx common/usb_storage.c common/usb_storage.c.orig (-aRx use is just habitual for me.) I then made changes to the 3 common/usb*.c versions of those files, editing not shown here. After that I produced the patch files via: # diff -u common/usb.c.orig common/usb.c > = /usr/ports/sysutils/u-boot-rpi-arm64/files/patch-common_usb.c # diff -u common/usb.c.orig common/usb_hub.c > = /usr/ports/sysutils/u-boot-rpi-arm64/files/patch-common_usb__hub.c # diff -u common/usb.c.orig common/usb_storage.c > = /usr/ports/sysutils/u-boot-rpi-arm64/files/patch-common_usb__storage.c Doing the diff from work/u-boot-2022.04/ with the common/ part of the paths being explicit is important to the content produced in te patch-* files. The "_" vs. "__" use after "patch-" is important in the patch-* names: "_" is used where a "/" is in the original path. "__" is used where just one "_" by itself is in the original path. The FreeBSD ports infrastructure does the translations to produce the parts of the final path needed. =3D=3D=3D Mark Millard marklmi at yahoo.com