From nobody Mon Jun 07 20:09:52 2021 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 7F04895B9C2 for ; Mon, 7 Jun 2021 20:10:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205]) (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 4FzPc86NkXz4VbJ for ; Mon, 7 Jun 2021 20:10:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1623096598; bh=RD7gMDGRCnkCtcusI/mhLuN3qSGk6en90OhyU8RF1HA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=LcXV2/8c+ZcpC3SYnYDcLY7/sFJEXw5wxZS67IBQD7nDip5AeCnqWxRrpwpfOokBE6k9Ol0L4Pg6xlWmFSbeBAg7YrGoVoY0dL/QIigl/3ARS/HrJb/yGQft952yEaWC+ncNBo1OvhCZFfrjGtEui7hzG+l0kPqqHebKuPPZnff1tkiQVxfRMla50XSV2WqBR/OPNzYncum5Rz/72R6VPYRKOHjFJA0cLRHlDLG3koQA7IUPicMFfGtroqg/KNbTE76jIFGBRD/eUoN8KS2JHI8on7uwBDxL+wWNgtItnk148KL27ROiHZRRyG35Zc+/m9D27uF32SW1uNLn1QFjdA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1623096598; bh=zCt1sfYFXSqyBnOaRgC9O4uwR+ksrQ4CWiTkG8Ah1IB=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ni5wxp5d0ZqcUjvCgsNwSGbrnl+u2+a/IxATjJ6Zo4O38vJB8sppVoG8T8xpjCOUY3EKSiX9HeMTVPWP0DYKrBA4qJTdb7T1s84qpD7b3M0yplaPNHe3PgY5+UHA2AqNvLkXH3cKMILOT+wrfVMijVhX0Y3FrX/f4ctgRTLoaeX6IP1VjMnWzPKSpU0LSH9jSk4YboTgSvVE9SBkOWh7GdAsbdF9kLLWvTN17P+a83RvVVh43XkWyu58eIGeSwGMzx/8g8RXWId+CnrfGP+LNMWzRoduxst1LYylg0zoRCCL1btzTWL2uByYys9QsG3hU3Xp4ex6jBQxVDraeLe10Q== X-YMail-OSG: lVgkzUoVM1mwlHAyKH4ZoM4B7a2y7CGyLwOTpjPhnRAMqJqepolDqST0whwwxT_ jBZk25VBYz.iT419CkyvfDikFVkkVUh9jtt5UuVMePw91HUU5a7VXfOhZGmS2rYkxwgvJu4WWuMo WFhrSDuOHs5Xy0pnlpyxaEmzQy8cUoqF43L_GpHpD6x29TvKu18othSplKzNAioJ4SJWMKUrHqLn BAmTsTO37nxxiWElbJEnMb1Ik.fCLQmSWj8P3sGsLGjg7ZkKNV6uhKJWMMjq7aoiJ2b9VRsBElNx bagvzGmxKEYjs3LdokbFkv2GpVLchDzhHC.vlgINd0AkKMbml5PeiAdD91pMXFdm5_Nc4PIhB3d0 IBNj.57Q2qBZIgsdAuFCMPCRs14YFZAqDebZHQWbp9YQZ6YhyqZd86kJLBBrJvGX0u0MXdy3vvtK pd628MPck1cdjiOgF.8GtKntmBPSLiGogEUuPchQUR1AW.gA0OXeY6GAZ7deXz1ppnVO2VqejPh5 pLG_ubsddZWMHP6vkMj8xGkp_fLK8DlG4Yt7AJf9_S8LFGmylJa2zdNVapP.pebH_8O6ZwsUi5BC z.sUHt1W2XehC7BhOk5fiT8_1OSeuQJNpeHAy5CUMb1hNF8TZ.IVH.eI_.S2m4xDmmxfw4qoKeXv SEY.AlxBkvMRgSqx.O.zmUln9KNVBkLqzfaAzhRbiWMBOzS729PutYSqeebfWcr51Rmjd3cPH6_c Mffb0RsG2FyhhZrueYiAyncvWW7fROfsUP9mq0EgN5uMwq0vICFCLjTpHyNw_DcxX24SIBxrKd.2 TGnWK_MZfSgytEuq4GSqF_0HcJXK4QaDlKgUHGMvOGqIcBp06wL0l5j6m.0BFcI.OiiWiMityp_F Vsv0owA48TFy.eQNp6q8E3_KqxA0ebQ_jUFcrZ_nUlXtbaVPLxlIvIlkPe20PMY7qUgftHaqU8ES mqfPihjeJK2P1aFSoi2hDSNM..zywhhKWKdgU.T77X0C0ZWbZpR.YxFKqiZFoi1qQris9HBWpGSO _hp_.YUw4m5.rWdr0laH7jyThv7qi4_QVhx.iC_h3IFvfIQPKJ4qZ6FwvfppEJlQ.RmmNPtg7DME bdnTuYwrzV2H20epaKbe9AfMdE4r_toB6sAKYf9wnvKYhMEyj.ln9ipYTCaH9JQ11lK1DBvj6JJA 3gYHmeBxeGhZ5UZSuK87bDk0Y0VAtFIRveVzthzkh0bG241WH0DKQe3m_UH5aN66b0H7cwlDAZP5 _m._lLYgbOQxSqfdDIfotpaDDKEvM_hgbbrrFAEY4iCLzihmjuopfQ3YcY.bkP185al7vP.I_zBZ o2_KuIh3sqvoelaz6_7EJLGRrms5DXEwdgklwV0ts7vu4uuky6teno7mK.pmFLNStAqTd6.haE_D JcR6uatyAlD3zRoUgHbFpNySukYnhyz1ypNpMAfpVHZd1n3W7IGYH1wQWKahNbf9S2xNJmBa8dgZ MsoODUPyGHXKoC7SCpfBYe6F_uJ_vBYnrmY.tjFycjgRTrzW5WTcJNh8AGQ2__hP8XSgQeaLV1ba ShNXoxl8As78r0c0YtQi1vspULdOHRp6WRKaawg.bFLOqqLTM3XMcCVUC2JsfCKn2Hy3xglgqHmV 8GDcKCRYuoZw1sNhBb_nDs03hgvz_jsVVbob2QzRBC96rdiRwQNEcVZW3Mw2z_EY30DCfHSuxx.i zOJZqp91T0kJaEy4CTP0mAMWp.I7iam8UVYtrZmCnwfTuOZSmnY1riJTBSC.dUDWY7Nq5NkBGdGr TRH9yH4VAttkY5gTZv49YECCZRoVbcJb2t5A_QBd.ntSvqpKFAiRvqUmuTcyRTq3oIaDnqaAGjFo 3ZUghPZzzKgW5NmieQbBxQ1yrq2ZJsls0vSkYiViSyE6kgAkIf1FHa1GMCDFXA5gLr0mTg6C66Zl TvPb93O3J5QVTYaDb0KEdx5Ieb_nLzeGmRbJguyTDDLfv4oHihQUC2HV9ADlzgoI2oGUMr2sBcy8 3yrg9lSacoSx5TiY1t8cEmZFk29.8Cx2ugaH821TTKgXtJFpYnFVRoj_H2wpkdZxZ84oUrbakR9z IQgMa7p_xQ68ucnptI_lWxQQ8uvW28nRijIHMmNG2ts.wRDz6WnEhFTZDDBrAhUgf0vG5PO9LkdK ZoGjtiNVaK2YCfPKCAyaewYSx52RMOMAN1aDTIvGIImsctTKdytXY7P3BWTFQW6FZUuYSoRfXPG_ Kw8.3lIxI_.LiefS4gN_6AYPrekUIy0mc81YX5PpEVYlJT54d0jQgt7LLde1AMZH1KZXWdX4jCwH 2vl2LBcQqNDj7gvgiJEImNJYJA1.p11AovGkIPH9C97YKdrAA3T66CDVwsSZ3PSa68WEOpOHFRbL Z1Fou1IMr9Vth456kBm0jLPaT12uK80q7eoCTWbw9.OwSaySatk0isA1ddv1mUQ7jqy0nLC3DqgU 7XqCybi9j2D99wtJ8MA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Mon, 7 Jun 2021 20:09:58 +0000 Received: by kubenode518.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID eb9335f46370b89fd79642d158f1c164; Mon, 07 Jun 2021 20:09:54 +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 14.0 \(3654.100.0.2.22\)) Subject: Re: Strange u-boot behavior In-Reply-To: <20210607184016.GA11184@www.zefox.net> Date: Mon, 7 Jun 2021 13:09:52 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20210606043152.GA94545@www.zefox.net> <27786296-8C55-4CEC-A587-14BF4465A4F8@yahoo.com> <20210606160040.GA97697@www.zefox.net> <407FDEDF-8595-4F20-91B9-B475CCE95B39@yahoo.com> <20210607184016.GA11184@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4FzPc86NkXz4VbJ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jun-7, at 11:40, bob prohaska wrote: > On Sun, Jun 06, 2021 at 10:34:26AM -0700, Mark Millard via freebsd-arm = wrote: >>=20 >>=20 >> On 2021-Jun-6, at 09:00, bob prohaska wrote: >>=20 >>>=20 >>> It's a dual-boot system, with a complete FreeBSD-current install >>> on both USB and microSD storage.=20 >>=20 >> How do you control which device provides kernel+world >> if both have a kernel_world? >>=20 >=20 > If the machine is powered up and not touched, it boots from the > microSD card. If boot is interrupted at the u-boot prompt it's > (was) possible to issue a=20 > usb reset > command, at which point the external USB hard drive was discovered. > At that point issuing a=20 > run bootcmd_usb0 > command would boot kernel and mount world from the USB device.=20 I see I force to to tell me what you had already reported. Sorry for that. As for your manual usb commands . . . Looking around on the web I see reports of the: Request Sense returned 02 04 01 (and the matching Device NOT ready) mean that the problem will occur and that repeating usb start or usb reset again until it does not report that leads to things working. But I've also seen other, more complete information indicating that there is a environment setting (showing an example value): usb_ready_retry=3D5 to set up before the usb restart (or usb start) command. It deals with the issue more explicitly for slow devices. Another one is (units: msec): usb_pgood_delay=3D10000 There are also device that have problems with large transfers and require extra protocol to deal with transfer problems before they will work again, U-Boot not doing that. usb_max_blk=3D20 sets a old historical value that generally just works for such devices form what I read. I see no indication that other usb commands are worthwhile until one has avoided that "Request Sense returned 02 04 01" message for usb reset (a.k.a. usb start). The reports of this sort of thing are not limited to RPi's and go back to at least 2014. If I understand correctly, usb_ready_retry and usb_pgood_delay and usb_max_blk are part of normal U-Boot builds these days. But I'm not certain of that. I will note: QUOTE Common USB Commands: - usb start: - usb reset: (re)starts the USB. All USB devices will be initialized and a device tree is build for them - usb tree: shows all USB devices in a tree like display . . . Storage USB Commands: - usb scan: scans the USB for storage devices.The USB must be running for this command (usb start) . . . END QUOTE Note that the wording indicates that having the tree is not the same as having classified the storage devices: storage classification is an seprate step. "usb reset" seems to automatically do a scan. But, still, the tree listing things that "usb storage" or "usb part" would not is apparently normal util after a successful "usb scan" has occured (possibly automatically executed). >> I suggest trying the same vintage that is on 13.0-RELEASE's >=20 > I've written the 13.0-release image to a microSD card and tried > that. It reports a version of > U-Boot 2020.10 (Apr 09 2021 - 03:55:54 +0000) >=20 > Stopped at the u-boot prompt and given the=20 > usb reset command, zero storage devices are found. However, > usb tree still reports >=20 > USB device tree: > 1 Hub (480 Mb/s, 0mA) > | U-Boot Root Hub=20 > | > +-2 Hub (480 Mb/s, 2mA) > | > +-3 Vendor specific (12 Mb/s, 90mA) > | FTDI FT232R USB UART AM00FGTR > | =20 > +-4 Vendor specific (480 Mb/s, 2mA) > | =20 > +-5 Mass Storage (480 Mb/s, 0mA) > ASMT ASM105x 12345678D558 >=20 > The mismatch between what usb reset and usb tree report strikes me > as extremely puzzling. See my earlier notes about tree vs. storage and part information. > As an experiment, I tried booting with no microSD card installed at > all. This got confusing; u-boot still came up, apparently from the > USB hard drive. The RPi internal code is handling the USB drive initially and loading the RPifirmware from the USB drive. That firmware is in turn loading U-Boot in this case. It is when U-Boot tries to take over and set up the USB drive for its own use that things are having the problem. > The USB disk is still not found by usb scan, but it=20 > is recognized by usb tree.=20 See the earlier notes about tree vs. storage and part information. > As a final test I tried connecting a monitor that had been used with=20= > this Pi previously. The monitor's presence made no difference, the > display looked normal. =20 >=20 > A hands-off boot to single user is successful from the microSD card.=20= > It's possible to see and access the USB hard drive.=20 This sequence by-passes U-Boot having to have usb storage operational. The FreeBSD kernel is better behaved for handling the properties of your devices involved. > At this point I'm beginning to suspect some obscure mischief with the > USB-SATA adapter, based only on earlier intermittent problems = detecting > the USB hard drive. In those cases a few repeats of usb scan found > the disk and allowed booting from it. =20 But did the problem cases show: Request Sense returned 02 04 01 or: Device NOT ready ? Or were such details different? =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)