From nobody Wed Oct 5 06:27:00 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 4Mj4Nw2m6Tz4cy27 for ; Wed, 5 Oct 2022 06:27:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-19.consmr.mail.gq1.yahoo.com (sonic306-19.consmr.mail.gq1.yahoo.com [98.137.68.82]) (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 4Mj4Nv0s1Mz3wry for ; Wed, 5 Oct 2022 06:27:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664951227; bh=7DEPV7qV9GIonTnxWIAIg3ok1+KqFEkbHRb6NvCt+qU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=kNPpTSGxdXticsy69DgYC4eeUIfDjLDUhqYH686BnQ6ZXC5MGM06sjPn5lqIeQE86Aq511rbz0FsoMoQ3f9vBCAokfQ5KrF/EC17s3MnmrweMbiLSvcoawWqr4p1w572FFdAmCpiy+nRPYMeRvd1x/VrAAftxc25MNxN6X9Y5pUXjqe0Hh3qM894EjJAweBkM4i6JRK7hefgsMEbM1OopwLp05u9Qt5mvbFJ8nJQU1PmGF4MaG2wGwlefF1DwxjHvWzUQTlSLcevAk7pA4uRiTm/qDZ29m0vczlZpY1J8lQvKyUfvZAQ6XvPdCJ4tEDKbqW/RK06TJOShgbXLwQVhg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664951227; bh=jIrnMDJBTAeIgg2H2dZgD51CmZnIMjAgzIza1WPUOWK=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=r2WbB7u7ZQk5WxGtElVswN8AAYFM2Spu49nbQeVDYlEj9lsZ6YPAv+IZ9vthjdS1r0WC4Ba/HWv+h/lJgVA9gC4xnLCYE3/DT3+V+NnpIbLMCPw0EL41jcZRT+PzFgKEZPJ05VAoqu0HvdV0PEoQw/erqiYDdXnDS+ZcxSpgqoRN7TCpVFL4kaq5+n24xuGGI+mMRtPlnVmBNy/R7uFo8LcJxgsWJQNedE8SBCHDVcfE1um2OkqtrpOpe4rzv7ksT07rtrNpC3B2UuHERlgAh11/IXOTuRua3buf5bnREOtrEXzzj3BnV5yRd3b8puojJPak/iYs1QhqzPzL/JnGIw== X-YMail-OSG: bGU9hn8VM1mlApnFB0FwngAlVSKEVfAl.feBm5w6jIkKO7h9F9PUW_SaKcLUVxP B.Yyu8BDX0nFt3.3NGbR3rOYUDfk.ZMLpkZatAN9Zsp.z8jEHWeSdzJT13DLLTHyaDCnL1EWOq7c D0xgMz9L_CjAvIbqC.ZF_27oRFQraHoHZAvB9rf8M0isDjjsHYJMM6gKgs_91x.UBMXZy1p8QeGb oDgJYiaA0RpcRXEK1LqwM7TbkcXbmGuaix1bQUFQ6AAiOQ6siU2_wxmfEjCy6t5Sm5GtJzF.oK5l Cy4ModJN240.T.GhJ9qeFkGCRw.AmfY59lvDXj00ULKTZL8hEtUJwfFcqBy1l1xVqE4ZvX19yn9B F1KK9HcspxXLsK5gHFSfXcnfuu2n01x16WwxfUJdi0ofWKZx2KXqSY.5UUp7Wz1efMFhydmy9oL7 kBqAK2y8TSsk4m9p6hvS5RWOu2EWhblLWzRNWSATkxiWvuwSotEDzm6Rz1CjiIok4Yy.oDV9DAlm CwxRdFuM9Np4pse7gTnCYnBxy.B98MGNiLkv_ZkwxCYNXeH0iCElRjJHWOoXtVIRuEKQXOqM0yho ipuvVh.ynN3sNmQR7TEB9vxBcausR66siDd2X.SsZqD6ohGwWnsxNKJgOxdXryFJGVhSwGq6QZwb e8Ps_wZWVtX28HhX5SWWGjI0T8mBb0OtjRl5CodZh0ACSLqc6uRbUK2kUK2g35NsSWjVAsvDvy1o feR6Q.C_8tbz9lC8M08Ye.AT0XUOHm78JaGAfBMVrzfZ_XsUU2CsMYeKf_jlmFAE0I6a9l2cb0kV DYqSnYpJb_Q50MXCHESp836dWpjzwWb4ALKnASHK3KqqqRah3IzjL7pbkiyFABjCKav3PrlxekNQ fiH0laqw6pIg8k94LSnvFeBe5Kk4MHio1wkbvbnF49YHZLepZlO5mif3RBCHtgDrs8QYTDs.U1Oz TWFaW490l1EWQvb9ETMevNI8FWOOTWGWj4ice2gGBl2DFpTtrR7RqId2GK6PM7X9G9VHHBdhz6Jf iKrolhQpp1TJX05eAV2Km36NSf0XGKzAlkHRlo.7kGnoD7LA2weeOhNk75Hie86EtGi7ZPSTiyLv VgNyshl1XHfDPJJshga2qXby47tHXhcvdZdmWcnJwQoDCiDPRnRM7yNLEot5XsfUrAZTWKeud50D zMR8xhfbn.59yCUBUa7Uga187KKSBSDwJaHyf_HEWTXeHSVwCF3ZKoLY.l.RGFzb6pzpOLSONjgs 3JgpGNzYhqmfc1yvRxbZ0IHGELsJI3dVUs3wsf5zl3Sd0K6HkcGh0Rfl79r0iEc_gXGmeGHLiuax MYN6drcMpyI6YIq2A9L_sf_c2FgQvCURpL7FeSsg4yci1zNik2pL1yUKP2NwK8u0cBIHnEZsvpGj eynYvjiXzzYuns1v_2fVzlRqgYnk1f9y2VOGCWC.N4EbVo8yQSTpMJBpYpkp2izO7beT8q4bL1Ie F1WIcWyJ8GXWlKrxevTdWwEEByYzZ5biBCh9ovSeOVJjKzDfRn322fT3ZH3QjYUjkpocM.j0wA6V qWz6sY6KN7CUf8uCnk5Yq3NO.wPnVtV5H6ER4OSxCsyxA6zq8nNuX9CcA2y7Vw1bWjEbvdqoJi75 M69Sq3O4j4SMDqfpSbzzkW16QMY04mnHHryzCnmTgIPc2JLiXJiH8CTuSke4mItWU.Y2wmqKS93o 5Vt0pGxOMGQkYNta_Jp9OwvB5sPYkmJzwLWji.OOdRmyMXrQWnbQaQ7dL6t_YRcQ9bdzCI.Tl36O eb47n0M3lidy.Ir9TBz0JDrD5Jauz51kQ5_3SNqA_jEjJviAw4RZTrtZgo6r4bISRntBbTKv0uGm 4yAqbRnt_LPsW.MZchBYR1fsPUBCiA.HHiFubuKpidUPt_4oRME3gX5notHizG6_pEmKwlBtdsMU DODSR2RAzOwPlsVQJnPcjakmHM6sa4whc8oQS35vSLUGOYtkzlZFa.47.6bFs_FKKzzPhBJOTllg IwoFsAkEzcf_T6cDWoBouFfI3U7MyS2CIOiZRUNJk1Hr.daF1Luyk4YQx8LiYYZPUlrtyPoYxE4q 61X7FHCGzjRWb5sop.1sdTvEusT3MBSPUzWZggAwD6MgtL8t4ptgVCSa6QOYLbsge9WLRyQJa6h3 eItbo9WUCQ98tgBayNxqPZr_CV_rzBxUaresO5x5kbZuardBVDxlMjTLGxeHFNhcM3qA.b9UstB0 0P0aFZWKEwOvldlhZOGjIf7s2j6VgR945sqKca.bEoM5TOki1uMYq_wHkwsOVcghSu0tvg54dkgr e7bPs3A-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Wed, 5 Oct 2022 06:27:07 +0000 Received: by hermes--production-ne1-6944b4579f-p7xcb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5e8ff8d1c2a39bcfb0f5fbff9adf713f; Wed, 05 Oct 2022 06:27:02 +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: <20221005034608.GA12761@www.zefox.net> Date: Tue, 4 Oct 2022 23:27:00 -0700 Cc: Klaus K??chemann , freebsd-arm@freebsd.org, freebsd-uboot@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <1560695E-4D99-40A1-8D62-29EAB24C7997@yahoo.com> References: <6DB88FC9-629C-43E6-9673-32640FC547F7@yahoo.com> <20221002182049.GA2255@www.zefox.net> <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> To: bob prohaska X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Rspamd-Queue-Id: 4Mj4Nv0s1Mz3wry X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=kNPpTSGx; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.48 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.978]; 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)[4]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.82:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; 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:+]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_CC(0.00)[googlemail.com,freebsd.org] X-ThisMailContainsUnwantedMimeParts: N On 2022-Oct-4, at 20:46, bob prohaska wrote: > On Tue, Oct 04, 2022 at 01:25:17AM -0700, Mark Millard wrote: >> I found a configuration that gets the RPi3 EDK2 and FreeBSD >> combination to have the serial console working. You can try >> booting and operating via the RPi3 EDK2 UEFI materials. >>=20 >=20 > EDK2 boots the JMS576 enclosure rather reliably, 13 out > of 13 tries succeeded, with no failures. Note: I prefer the 0x152d:0x0583 identification, just because it is something I can see in the logs. As I remember, no log ever shows a "576" from having the specific enclosure in use. > It has more problems with the JMS577 enclosure, failing > mountroot, getting to multi-user twice out of six tries. > Maybe better to say six interventions from the keyboard. Well, at least having 0x152d:0x0583 work is a useful improvement. > But, seemingly no disk detection failures. I didn't see > anything that I recognized as an error message from EDK2. > . . . > ESC (setup), F1 (shell), ENTER (boot)......BdsDxe: No bootable option = or device=20 > was found. That looks like a "no [successful] disk detection failure" notice by EDK2 and is an example of a EDK2 error report, given that you know there should have been bootable media accessible. 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. > BdsDxe: Press any key to enter the Boot Manager Menu. > . . . > UEFI firmware (version UEFI Firmware v1.37 built at 19:07:59 on Oct 19 = 2021) > . . . > Consoles: EFI console =20 > Reading loader env vars from /efi/freebsd/loader.env > Setting currdev to disk1p1: > FreeBSD/arm64 EFI loader, Revision 1.1 > . . . > ---<>--- > . . . > Root mount waiting for: usbus1 > ugen1.4: at usbus1 > uhub2 on uhub1 > uhub2: on = usbus1 > uhub2: 4 ports with 4 removable, self powered > Root mount waiting for: usbus1 > Root mount waiting for: usbus1 > 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) That is the FreeBSD kernel having a problem dealing with the 0x152d:0x0577 . We have seen this in your prior logs as well. Note that U-Boot was not involved at any stage this time. Adjusting U-Boot would be unlikely to prevent this from happening. Nor is it likely that adjusting EDK2 could. 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. > . . . > usbd_setup_device_desc: getting device descriptor at addr 5 failed, = USB_ERR_IOERROR Looks to be a consequence of the above. > 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) Possibly another consequence? Or a new failure? ("addr 5" is, apparently, successfully referenced a few lines above. So I'm guessing: new failure.) > 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 > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > da0: s/n DD564198838F9 detached > g_dev_taste: g_dev_taste(da0) failed to g_attach, error=3D6 A consequence? > (da0:umass-sim0:0:0:0): Periph destroyed > umass0: detached > mountroot: waiting for device /dev/da0s2a... > 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_TEST_UNIT_READY set for USB mass storage = device JMicron USB Mass Storage (0x152d:0x0577) Note that UQ_MSC_NO_TEST_UNIT_READY was nor reported previously. Likely it indicates another failure lead to the extra message --or a consequence based failure. > 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) Like the earlier usbd_req_re_enumerate message. Looks like the below has some of the same points as the above sequence. I'll not comment. > Mounting from ufs:/dev/da0s2a failed with error 19. >=20 > Loader variables: > vfs.root.mountfrom=3Dufs:/dev/da0s2a > vfs.root.mountfrom.options=3Drw >=20 > Manual root filesystem specification: > : [options] > Mount using filesystem > and with the specified (optional) option list. >=20 > eg. ufs:/dev/da0s1a > zfs:zroot/ROOT/default > cd9660:/dev/cd0 ro > (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) >=20 > ? List valid disk boot devices > . Yield 1 second (for background tasks) > Abort manual input >=20 > mountroot> usbd_setup_device_desc: getting device descriptor at addr 5 = failed, USB_ERR_IOERROR > ugen1.5: at usbus1 > umass0 on uhub2 > umass0: = on usbus1 > umass0: SCSI over Bulk-Only; quirks =3D 0x8101 > umass0:0:0: Attached to scbus0 > ugen1.5: at usbus1 (disconnected) > umass0: at uhub2, port 4, addr 5 (disconnected) > (da0:umass-sim0:0:0:0): got CAM status 0xa > (da0:umass-sim0:0:0:0): fatal error, failed to attach to device > umass0: detached > usb_alloc_device: set address 5 failed (USB_ERR_TIMEOUT, ignored) > ugen1.5: at usbus1 > umass0 on uhub2 > umass0: on usbus1 > umass0: SCSI over Bulk-Only; quirks =3D 0x0000 > umass0:0:0: Attached to scbus0 > (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00=20 > (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an = error > (probe0:umass-sim0:0:0:0): Retrying command, 3 more tries remain > 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 I'm not sure if you did a: Abort manual input here or not. If you did, the below is likely not surprising. > panic: mountroot: unable to (re-)mount root. > cpuid =3D 1 > time =3D 34 > KDB: stack backtrace: > #0 0xffff0000004fb6d4 at kdb_backtrace+0x60 > #1 0xffff0000004a6da0 at vpanic+0x13c > #2 0xffff0000004a6c60 at panic+0x44 > #3 0xffff000000595ac4 at vfs_mountroot+0x1e18 > #4 0xffff00000041ebc4 at start_init+0x28 > #5 0xffff000000455dcc at fork_exit+0x88 > #6 0xffff0000007e56f4 at fork_trampoline+0x14 > Uptime: 34s > Resetting system ...=20 >=20 >=20 >=20 > Raspberry Pi Bootcode > . . . > UEFI firmware (version UEFI Firmware v1.37 built at 19:07:59 on Oct 19 = 2021) > . . . > ESC (setup), F1 (shell), ENTER (boot)...... > . . . > Consoles: EFI console =20 > Reading loader env vars from /efi/freebsd/loader.env > Setting currdev to disk1p1: > FreeBSD/arm64 EFI loader, Revision 1.1 > . . . > ---<>--- > . . . > Starting background file system checks in 60 seconds. >=20 > Tue Oct 4 20:15:42 PDT=20 > FreeBSD/arm64 (pelorus.zefox.org) (ttyu0) >=20 > login: root No problem observed this time. > . . . >=20 > At this point I decided to run an overnight buildworld/kernel > to see how the disk behaves under load. >=20 >=20 >> The above actually boots via a default setting that likely >> should be replaced. The related menu/field nesting is: >>=20 >> Device Manager >> Raspberry Pi Configuration >> Advanced Configuration >> System Table Selection >>=20 >> Picking just Devicetree instead, then saving, and then >> exiting the nested menus via a sequence of Escape key >> presses, until back to the initial display, one can >> then select Reset and it will start over based on the >> new setting. The save actually updates an area in the >> RPI_EFI.fd file. >>=20 >=20 > I'll try that after the new kernel/userland is installed. > Is it likely to affect the mountroot issue? No. So far it seems that FreeBSD is managing to ignore the ACPI and just use Devicetree. So it is more of a "lets just be sure to avoid the potential problem" issue. On a possible issue: You have ugen1.6: at usbus1 plugged in. My normal context has just the 1 USB3 NVMe media, the Ethernet cable, serial console connection, fan, and power plugged in. (I ignore the microsd card slot here.) This works fine. (I do not have a powered hub involved.) In in experiments I discovered that if I plug in an example keyboard (that also has a mouse plugged into it), it messes up my ability to boot the RPi3 via, for example, U-Boot. It might be worth experimenting with avoiding having more plugged in than: Boot USB drive (I count your powered hub as part of this) Ethernet cable serial console connection fan power and seeing if boots more often than your normal configuration vs. not doing so. =3D=3D=3D Mark Millard marklmi at yahoo.com