From nobody Wed Oct 05 17:29:28 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 4MjM5C17fSz4dfyx for ; Wed, 5 Oct 2022 17:29:35 +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.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 4MjM595l9Dz3xKm for ; Wed, 5 Oct 2022 17:29:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664990972; bh=ha24ULWjlVbizmonAwtH/rNxr2aPGs+5i1lYLi+hM10=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=lqzD+z4tZX7eQkEBHTB9cyDFzkmm7cqISqZa0PGFVkXcCsXCmb4IOqA0K8uG6dSNg0RkvDXQhgoFqssdeXiDtEaVaZeGu8EygmIhkmZH5gZAXuio87yzJUAeFQ1aGkh3CQZuncnIhHbhVnIUpIUxYg4BMWJ83vZiNJRmxdvaijMh6qx31TPnLjTsr0qULHuKD840/8YqdzYOuvLNn4kpnx7kB0x0H3ZPRs30iOMsmXdyVOInTtCUbicRqnrYyNONP4b3bRK0DNCV8UsDke+gfZsmHr69/zWeBgIexpBEIVBdHG6oCT/y9DacFQ/4P9nwQwq3qVDgsUDgBBlGKIIwAw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664990972; bh=zkoCUTm+IbFq8JYxuSWn4yEmcS9UCglfcrFPL4fPzvf=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=NUXdo8ITVQmqBBbg8caideea1V+DGV7rjx5FIMLBsqMYOz1aCGzap49VA4GG9FyAUGCggy22fWUKrDvKIaUzm4kZ8OPt4WHy03WqsY9cfWqjTCmjhRWKoABn3glGAHtSS7kpUyByOZZUVmWLdhG9ZI7D3JkRxAPJD23vsvJX5TybYJLTpP1ZKMfw98GwxCCA9oC4CBIaOpaJSG+CbcZg1GViFdNBWO4aiauIXgQw1I7TPPau7Pyvv1wt8aUOct3la5YDHKeHNKPBh6yfO7fIB6PFIDBy4uiDG7ijcDl/Z1BryhIztM1pLxk0Qjb8qi8t2/BTZs2/nBIxxgN6MaV7lw== X-YMail-OSG: cQsnI10VM1nN05j.K6BCEDotaxMlb_dlRbsp_N6mXSbKgyVzmHzD5W8HqcJAEGV aVx7.e7i8iB27Mlsm3WTMKPDMeoObH5not0mhjVFM8XwonC9BDpqjahpK9qkY8Qn1uFEwoX1KTw_ KEhmV91NYa8hBRkjoVhSJYvfeL6_E4eTXqNqOBUNzJOylRCrOwKg.kXeZ2RH4j2sf631UBxBX0XP eLmQ3uh6NjAz38T6UsLpxculBiRmAffA1P5.h_xo9xNTmdX_5fE6Z57QIOQyXyNKEXVv9v0LyUTj c7_xA3SdI17FRdLiCFDY3uLWBVW3v4wCiF7xwOnedeC0ki6QZa3VAT0QH3MFSFx5CKjEAxSin.lC hhnYozcmyUzHxguDvGIxlam1afx1TYp_4tAzdP5oOWo4G3n1EHM5Dms3x0XVdViW9nf.jzkjTsIP QQ8I9xe3cf.xgsb3.kQ9s1nWtW7RGOgWG6WLQFxllpT1eEHiF_PnS96dnh1Zo6EJKkUbSNtNIO7f p4VtEZeBwpvScUTG97xmTGO.TsnzwfeJTbL4WlpCuWcvCH5EBCE7sC68tpVlGIqLQnbHKvFFdIhJ x3hz7OgxaxC4fg8X3wureBY9yRZR2vArBhomF_xnVSvLeZ89ZotcO_XBaJ42rxoQKLr3IQ5AXDCs XRLFq5Z_SxnNjnvS1AMcuSF65zCPB4vjolxSLagNUz0R6QYp_IM.8EG2Hux8GLy8C1YFnFwcN2sj tkFXhpLIGKhA4qSH57bmIkKnkLxdDbjcMfg2PE1jutC4IYTU1lcmRYdsWbDK70.i_dZ.2fAVhePZ L_5FauxOG8Vj72UNtKLFzJsZ8os3r0vn2qLt_k57dXjanmijuuGCN0q8FZ.MpWuPF4Fw1Qpm.wVp U70F2w96TB7p1azkTTQ.pkIHoQ8avhPFqKh3I.6jXuv3MlUWN0JHQ5OqfMxtY2LGPc2xGgwtItE5 b4dLWZRrPsxNO3S55etq5wjIBGqnYWqiuh.7LTpxFTM2mNuQ4JuvsDYginCB.hWopNBHgp2v6PHr ydBle1zwfDYdoNkmFSAX.yrn2OUj2WUlZQCRP926kxyq.JAhsPX9Wrorjr7y9z3UXHfncpMAG68z xEDjzrCIDwpMFKlHnGLW_jyMWgT.ngmrR_vb3vqqTPMJ6PzqTNWM89N94C9pJjAGVErtqtkZWgTT Zp2GeMtehhcrDRUJjpCL8gEIuuEI49R8s_1iSjAJN77mFjYQxoJQfV6KvZcPgTQPexiZE6TUgi0a VWPKsv4kxd3YAcvsD6ajLywvFPtAHWtJo3Y0fo4H4sEyro1WSwq6s87pmYry7sb74JGMmGe.n0em IxHTFlI.vY.ufuJmvY8unScVdwb4FwwVNW2y.1R3D_PqCvAaeX3ehKF8HcS.K.a1A1w5wBw0E2OP pry1iAnsyhTLHHYD44pO3aqbNEptfblhjwY4Ma1.bD9iRXQvUaZRvmWJmGAHNAkQaLoO0fxF5w1q 1gfwmOSCH._nXma0b5YayXFUoJpDrWpYXq6fkoPIywL8VpKwTRRJSiHpgUQIQWSBiBsvx0UFc7uq XwATMbCk02uhkhy08FZnbn1946KxhH2gxLIc.xj.QSTGiKrJobDF1LP8AvHZrvyNbbc4d78VY02e D.X3iZF5kIZ4ftQvR.jF28_TZtWtqzJ3ji.DkyQyP4zSnxWycHkopo4yPXaoAU8DWzEbg.MnciOL DCN0byfnF3XpGHzUsZeU7z812cem9kOuNW14q1EXqseFwtZxb_9l2V6W_4RWukHB4O7eYIbW7qky PnyHrqdMcn5St7SxLFx.ywhCcpmVXohBW.8wiwhCb0dFugrBDkJQMaoIfE19gRLJa364uNGtc98b BCOE3M2Vpcx0fQJyJIBoH.B4845iRQEG5qPo4_H4Ras8zgT1NPFrWroIBxuX7pqPKE6Xbmuq2kx6 QPjOaOCECRw9l4M.nj7l_swn57G0lA2IEYKjT_zUvCEqIf6ziw_Lyuiblhsl9CTMLnp9MQt9GFHk 6xBOXcIO4h0VYNPXrxtP54Oso1ha8Zjydg9MzKFwSvRekohD.QkBHsnPekzFRtPDr8i8PsgKiZFG o9ctqtvftVJLw.Rf3KWNXWT3a9SZJmRkFI.5pSw7HSnV7xupIcQ3SuOE3H6RsArPm5541ugpM2P2 .95BiTLi6xLIgsXVp9Y1Lr6EZ3FWJwvmujdhdEI0KMH0DaVryIsdmINsfl3jjjiaBK1dGqrqBnGN uPIYJ2LRmqCQEe37wm8VaTXnfQK_hzGEYiyBqnxRWDRW3yif3v1CRL9WGdLmLRnTwESueGFZlHMR .j3g- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Wed, 5 Oct 2022 17:29:32 +0000 Received: by hermes--production-gq1-94b89944-k82lp (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d9bd95eae22e1be6ac0860b873e9c9cf; Wed, 05 Oct 2022 17:29:29 +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: EDK2 on RPi3 was: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it From: Mark Millard In-Reply-To: <20221005160737.GA15227@www.zefox.net> Date: Wed, 5 Oct 2022 10:29:28 -0700 Cc: freebsd-arm@freebsd.org, freebsd-uboot@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <136B9190-4C73-45FB-8B41-FEEF7C38A253@yahoo.com> References: <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com> <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com> <20221003004624.GA3381@www.zefox.net> <20221004001857.GA7109@www.zefox.net> <62F8D709-BBC3-41C4-B1A9-939B2001BA52@yahoo.com> <1DE565E3-3906-4C53-83C8-EBC20A4E3C95@yahoo.com> <20221005034608.GA12761@www.zefox.net> <1560695E-4D99-40A1-8D62-29EAB24C7997@yahoo.com> <20221005160737.GA15227@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Rspamd-Queue-Id: 4MjM595l9Dz3xKm X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=lqzD+z4t; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.45 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.95)[-0.950]; 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.64.148: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-5, at 09:07, bob prohaska wrote: > . . . >=20 >> There is such a thing as a pre-built debug EDK2 build, >> at least for RPi4 EDK2. If there is for RPi3 EDK2, >> then we might be able to get more message text. But >> it need not lead to avoiding the problem. >>=20 >=20 > I gather you're suggesting that debugging delays in EDK2 > might not have the same effect as debugging delays in u-boot? > Would it still be worth trying if available? They still would be problematical. But we did learn things like that the root hub in the RPi3 was having odd behavior via U-Boot --even if we did not find a solution to your overall problem. But, it turns out that the "build artifacts" for the official RPi* EDK2 builds have an expiration duration. It has been long enough since the EDK2 releases release that there is no debug build artifact available now. >>=20 >> Note that U-Boot was not involved at any stage this time. >=20 > To my understanding u-boot isn't present, unless I made a > mistake. Are you suggesting something else? No: the point is that the problems are occurring when U-Boot can not contribute to the problems. The problem is in no way U-Boot specific. >> Adjusting U-Boot would be unlikely to prevent this from >> happening. Nor is it likely that adjusting EDK2 could. >=20 > Perhaps, but I don't understand the inference... yet. > AIUI, EDK2 discovers the parameters the kernel needs to > communicate with the disk and passes them to the kernel. The kernel uses the Device Tree handed over by either U-Boot or EDK2. They in turn start from the 1 that is handed by the RPi* firmware. That in turn starts from .dtb's in the msdosfs. The RPi* firmware and U-Boot/EDK2 can make adjustments to the original .dtb material to cover platform details not handled by the static files in msdosfs. (An example is the 8 GiByte variations with and without the lower-3-GiByte DMA limitation: some address ranges in the final Device Tree vary.) The Device Tree does not reference the specific USB devices plugged in. The FreeBSD kernel handles such on its own. (Such is why it can boot world via USB3 on the Rock64 but U-Boot and the FreeBSD loader do not deal with the USB3 as things are.) FreeBSD's kernel does its own binding and initializations to the USB context(s). > Is this a distiction between reading the disk and writing? I was not referencing that distinction at all. >> Looks like the FreeBSD kernel would have to manage to deal >> with the issue via an error recovery handling. There is >> no evidence to suggest being able to avoid the problem >> occurring. >>=20 >>> . . . >>> usbd_setup_device_desc: getting device descriptor at addr 5 failed, = USB_ERR_IOERROR >>=20 >> Looks to be a consequence of the above. >>=20 >>> Root mount waiting for: usbus1 >>> ugen1.5: at usbus1 >>> umass0 on uhub2 >>> umass0: = on usbus1 >>> umass0: SCSI over Bulk-Only; quirks =3D 0x8100 >>> umass0:0:0: Attached to scbus0 >>> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 >>> da0: Fixed Direct Access SPC-4 SCSI device >>> da0: Serial Number DD564198838F9 >>> da0: 40.000MB/s transfers >>> da0: 953869MB (1953525168 512 byte sectors) >>> da0: quirks=3D0x2 >>> ugen1.6: at usbus1 >>> ugen1.5: at usbus1 (disconnected) >>=20 >> Possibly another consequence? Or a new failure? >> ("addr 5" is, apparently, successfully referenced >> a few lines above. So I'm guessing: new failure.) >>=20 >>> umass0: at uhub2, port 4, addr 5 (disconnected) >>> (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 74 70 6d af 00 00 01 00=20= >>> (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an = error >>> (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain >=20 > The "...request completed with an error... line is rather familiar > and in the past has proved innocuous on Pi3 and I think Pi4, though > not seen recently. In various past configurations, I've seen one such message in the kernel's part of the boot sequence historically. I treat it as normal for what FreeBSD does at this stage for some types of RPi* --and that is why I did not comment about it explicitly. >>> . . . >=20 > For now buildworld is still in the building libraries=20 > stage. At the moment it's swap-bound and showing ~750=20 > MB swap in use at 53% idle. No sign of disk problems > yet. Looks like moutroot is more delicate than I/O. The command sequences are not the same for normal operation vs. binding time. For example, the kind of activity that reports: usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device = JMicron USB Mass Storage (0x152d:0x0577) usb_msc_auto_quirk: UQ_MSC_NO_PREVENT_ALLOW set for USB mass storage = device JMicron USB Mass Storage (0x152d:0x0577) only happens at binding time. And the next message is the first error report: usbd_req_re_enumerate: addr=3D5, set address failed! (USB_ERR_IOERROR, = ignored) There is no evidence that the 0x0577 is doing anything odd for the normal-operation context: No issue to be delicate relative to, for that kind of context. There is evidence that the 0x0577 does odd things for some of the the binding time activities, although the details relative to the status relative to the standards is not clear. I do not have the background to know from the evidence that we have seen, just what violations of the standard by the 0x0577 may be involved vs. what incompletenesses in the FreeBSD binding logic might be vs. both. Binding logic can not reasonably be expected to handle arbitrary violations of the standards --and the 0x0577 context might well be violating the standards. But implementations of binding logic can be incomplete relative to standard-conformant devices as well. So: Unsure. > If there are any EDK2 boot options worth exploring > please indicate. I've seen the help menu but nothing > looks familiar. Nothing in EDK2 or U-Boot is likely to help with avoiding the kernel getting the sequence: usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device = JMicron USB Mass Storage (0x152d:0x0577) usb_msc_auto_quirk: UQ_MSC_NO_PREVENT_ALLOW set for USB mass storage = device JMicron USB Mass Storage (0x152d:0x0577) usbd_req_re_enumerate: addr=3D5, set address failed! (USB_ERR_IOERROR, = ignored) I'm also not aware of anything that would be relevant to avoiding the: BdsDxe: No bootable option or device was found. during EDK2's activity. I will note that FreeBSD likely has debugging notices for the USB binding activities that could be enabled, not that I know such would prove useful. Side note: I got the following once over night: Oct 5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: Controller timeout Oct 5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D REGISTER DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= Oct 5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: Sys addr: 0x00000000 = | Version: 0x00000000 Oct 5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: Blk size: 0x00000200 = | Blk cnt: 0x00000001 Oct 5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: Argument: 0x40510000 = | Trn mode: 0x00000000 Oct 5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: Present: 0x000b0000 = | Host ctl: 0x00000002 Oct 5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: Power: 0x0000000f = | Blk gap: 0x00000000 Oct 5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: Wake-up: 0x00000000 = | Clock: 0x00000107 Oct 5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: Timeout: 0x00000000 = | Int stat: 0x00000000 Oct 5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: Int enab: 0x00000000 = | Sig enab: 0x01ff00fa Oct 5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: AC12 err: 0x00000000 = | Host ctl2:0x00000000 Oct 5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: Caps: 0x00000000 = | Caps2: 0x00000000 Oct 5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: Max curr: 0x00000000 = | ADMA err: 0x00000000 Oct 5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: ADMA addr:0x00000000 = | Slot int: 0x00000000 Oct 5 03:01:11 CA72_UFS kernel: sdhost_bcm0-slot0: = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Oct 5 03:01:11 CA72_UFS kernel: mmcsd0: Error indicated: 1 Timeout So, apparently, there can be occasional messages about the microsd card slot for the RPi3 EDK2 context. I've no clue why the messages were produced but I had removed and put back the microsd card earlier in the day, without rebooting between or after. Thus the message lines might also happen for other types of booting, such as via U-Boot, if I'd done similarly. =3D=3D=3D Mark Millard marklmi at yahoo.com