From nobody Mon Oct 10 02:29:52 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 4Mm2tx2mRwz4f9nW for ; Mon, 10 Oct 2022 02:30:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (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 4Mm2tw3Rpkz46FD for ; Mon, 10 Oct 2022 02:30:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665368998; bh=+jfBvstmTgNJNWgYPItxS4Lbv3laXTfNQxMdQCZtfMc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=lQjBAke1czDSvQW4eSRs2pwi1oDjrWB/yn2fjWTf3Sv33HRPsqts9mj/Z7YCdpcR6jKJZjlPJTqBTmXUIHU7L35WOX4wqXg06sAimVdy/iuQiLtLI1oGFEMMy50syeHncqjdnMMRj0ecxPZHCF2LmUKA04b1cB1FfJjlzkaaE77zGmQKtKzaUATSR9FqFHK/WJ9VyV4fG7TKBYJCuQmfDNAsZAenGRdJXXnvn4jk1UMfi6cUnbeEEvag5m5GaKy76poh774rCha67tRT9aTCOMM95tMFz7PIL2p6uDZmp9eMXD5ByZo5AdbiCN+N0uor6cgaf3JPHmLkuPmaS4UfeA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665368998; bh=Byd65hmdm7gzoeR/1I/EMcuYlRNPoKfWFh9lQfeUnfX=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=jfCzpTqQFUsZoNaaFHfZtKKN//7nHTo+oXc38HsK/kQT+wrRSWFWMEIKdEhj4NLSp6Jdr+ViiSk0qKjvejBWDPX0Mx9XDu8p3KT7fnguunwXamUqZVHPZm2OCKEL8/SySAKwcvQa35vySjbZwtVQr1z05P3OSN/JyWkGUkXKJB4IiYskjEJPeiX1gdtXRopcUuQ28/YluOdCgi1S0bguBrqFmClpncqwIsbh1G7JZtK4gyTTA4cMDiO1jJ+dqazrmkVXNZ1nnDvll+5Bj67Okzi1kkXaIzI/CY0GETHn5YAcE+Glnjy5s3ufcNHmsNs7DGWNvQjmwoo8PMhzDNB9Rg== X-YMail-OSG: xMycSVEVM1llnla8nzMZVpRe3PFpdU3IW6DPnpahnlaT9xCde9dY8JE3CXVXIo5 0jNqG.RKdpNPbrCN_JZlPJkaeD1jSP4B_o1EJCyu6gsxCGr0lKO41EJMZRVLsBVx8vnFuvb1YuCm yNfTy4cPgT75GZYL1e5jyph9S8OFesdB7_TGSz9_OBOvUSnE2SHreiL2l6YCUGWWCTJZO2gTERC. otxtNZaH42XgOlbE4sFrSlhdOiEJiNot5iOrH5.zGILlM3Kkktowc4ddP9KXK5QBxAnbqLq0SaZh Ft02UqaNwKPv8w8I5u_66pNOXNDa.4JSpauS986KPVc3veAC_ZC7RrbHO6A8xVDkuD6ckuwKrIHk WRLcmKSGkcxTBiNAs8KsjCvSXo0E.HrZjhEpKsfwDbHB7mc9MAbBtV1il0EtWWDqKnqa4un3HW.T IM_9eemCpIBWCbxRtTGSapyPIwdkvrt.toc2fQRWVs6wMhCMuus7LiK04zAdWcsegDIWmttQUTMG 6S6NRVXl7JkVi.5UvrdGp17SEajnKVBPJ5yIcupI9qYE4WYisshIyEQR562aiXzI2l5C2rZFRyMV hSgXN6DQi1ejMvqqjDoeJnroP_BKmubsdFRYsvlWJcwUQxd9HFwIobxTEK_6.b1hwsDfskbrmj7d GvnHheJqqsQ8eHvz45uVQSijAxJJG0wnkBAcJ6X05vOwHsZoujbaDYrsqovMuKCpQJkuOvgj5bmG 5BKtIVTXHCbKrFmF0oIF0nTunAlqu8tmEKEfkkSgCcE54ZMwSucE7h0pxhYMb5abRnGRcKkDNZwb CQRiFaw2IbA.Irhi82FnhkMvnrjPmoQaMQgHJFxUbLZgHmixxtKyao.AblP_zvV023vCNr.6conx Lj.fkoZdPqO4Sj3ybwfDWDmch.Os1iP6_IWWRe4ruJDt7PbR.6pBbaKe9rPEk0Z0S2j6sIrOSpAS 1ppDK5XZzji33NdsmU2rpFqMKTcn_4Qd0wnAt6hajNEtNg4VHfgVv7u682IPD2CZfid48troaVkB W9qNTy9e67TUbRKGhtw_gFHXTWAdquTi5jX3SL9YZ_3lYK.ecK8XZ6gh5CsUqO2FrWYc2m1obVYz kdAET0vDibAHd8gMMlVdnjbr3knAVaLq.6x5sQOUSyD.lsdDpgCLaE1wRWfopPDWdf4ijW_k0_ue enHAok4v6RN6FdiXLEtSV..2EzchOgMODi8XSh6RM68BYqSVO1_RAh.35HL9W5QtZ.JEH1i9F.IV 4DbgxPelh7RC_OIA4Q75ugW0NlLGZQwxss2QCsmlZyvmjK5cR.xrHKa8_CofoNvlJ.7yNuIC1UEs fJRzu_Jv1NdONxZ4P_nkrU8g9G0_9ZMLZbwfSUUempBAvXFzj1bWCoTdmNHgtMcHILb7j6AA8nmR SJ_NgqRMNDdITSSaBH2C4Et.nXEYEPPLKfWE_ZGIZB1sDKit2G1iHeoNffyiqnvmN5j3T2B1BH2p jx.ohvOsXDu1tjvK1lvcT_rKlw97A9Ya3zrYVzfOyxjK70UO_VBZRd8owexGXacHnv7EtLnB4xaS bjLthadiJXGKR1yBJ._gfCdpSPJP5_sM4hSf91Gqa22W.iKF1SdnsnVgNHQn7DRbB.v_VKO63THo 9jF7MTAyS2cELdsVYD1_P3ENSJ52G9laDjKbXBo9mzxrZHl_rKFZqfztRnwMviFG65eD4SlnmG2n 3LrK1ukjqwPPV9jKXhygu2DjLj5aau6isCafqKLfeuzDGaCphLA37oSxwRbUq3h9BA9MgtBSHYse pDl8n_vdmEz2YAJPqRS6lFwXC9PUR_NupUi4Ww.CRuzTCabXXX3UWvt_nDca1xSIEW9ZqFP1T3Ff BZYxXNXW.rkaYyjZnwOCpgiKNqwG5lt3q7BtT7BS8hTqbtFWR2MjgmKbzyW22UocGwHQXO9tSmc7 roVIBCPSUfjZerguqjb3cjm4x4GUWrTHn39zUkeeeZynFzDPH9W.yjgDDJXktSFjy0HOMs1IOLGH 5eXoCIL1Ps7Nw3YtQL5.CmzyB7mz_F2L0wz0LK8u8R.Eq7xiaXkiNaoLq96lGBpR.9NAQN1ThOcx DQAufQTjLwHbFGQOCINxEnfwBNrW7YSmPp7UwyJfD941co5J9kOUlyUNr2MchC4K6pX5rmEoWYs3 eN0UI7k765gFLl5qDsVlaofw.y4JlcmhPztdi22B7ztJG7US6vHlOMnJgbHTgezOHvG8ukrW6DF8 Nyv0ohS63nZFI4zLucCif07NwBRN8DmrqQXmEDcwuVcz2DR6fLrY.T1bR572sOleEsB_3hFELieG DRiI- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Mon, 10 Oct 2022 02:29:58 +0000 Received: by hermes--production-ne1-54c586f8df-fmd55 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 6f28759368a467b3b5afd9f429942037; Mon, 10 Oct 2022 02:29: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 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: <20221010002828.GA4232@www.zefox.net> Date: Sun, 9 Oct 2022 19:29:52 -0700 Cc: freebsd-uboot@freebsd.org, freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <56AFA741-6370-4E21-A146-D33E26CD1228@yahoo.com> References: <20221003004624.GA3381@www.zefox.net> <20221004001857.GA7109@www.zefox.net> <62F8D709-BBC3-41C4-B1A9-939B2001BA52@yahoo.com> <20221004192707.GA11488@www.zefox.net> <6B44FACC-AECE-4BF5-9CCD-72F0056D0F88@yahoo.com> <20221007022121.GA22533@www.zefox.net> <20221009040903.GA1584@www.zefox.net> <20221010002828.GA4232@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Rspamd-Queue-Id: 4Mm2tw3Rpkz46FD X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=lQjBAke1; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.42 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.92)[-0.922]; 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.84: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-9, at 17:28, bob prohaska wrote: > On Sat, Oct 08, 2022 at 11:05:56PM -0700, Mark Millard wrote: >> On 2022-Oct-8, at 21:09, bob prohaska wrote: >>=20 >>> On Thu, Oct 06, 2022 at 07:21:21PM -0700, bob prohaska wrote: >>>>=20 >>>> Next experiments will be to try a 0x0577 enclosure with=20 >>>> Pi3 and Pi4 running -current with HPS's patch. Probably >>>> tomorrow.=20 >>>>=20 >>>=20 >>> So far it appears that the 0x0577 enclosures >>=20 >> So more than one of these 0x152d:0x0577 ? Do they all behave >> similarly for the booting issues? >=20 > To the extent that the 0x0577 enclosures boot Pi4's under both > FreeBSD and RasPiOS, yes. =20 >=20 >>=20 >> That is with HPS's patch for FreeBSD's main, if I read this >> correctly.=20 >=20 > Yes, it is with HPS's patch, but since FreeBSD never had trouble > booting from USB at any point, it seems a side issue.=20 You provided pelorus_console.txt8_no_debug.txt where FreeBSD had problems, reporting a mountroot failure. The start of that, with some context, was: 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) Root mount waiting for: usbus1 usbd_req_re_enumerate: addr=3D5, set address failed! (USB_ERR_IOERROR, = ignored) and progressed to: Mounting from ufs:/dev/da0s2a failed with error 19. pelorus_console.txt4_mountroot_failure.txt has 3 examples of such mountroot failures from 3 separate boot attempts, also when 0x152d:0x0577 was in use. So: Definitely not a side issue for FreeBSD for the RPi3B/bridge/software involved in those 2 log files. >> In some respects some of the below is presuming >> the context of the MFC to 13.1-STABLE and that the patch >> would continue to work the same in that context. >>=20 >=20 >> As I remember you indicated that the 0x152d:0x0583 was being >> well behaved with RPi3 EDK2, covering one RPi3B. >>=20 >=20 > Yes.=20 >=20 >> So is the 0x152d:0x1561 well behaved on a RPi3B (U-Boot or >> EDK2 or both)?=20 >=20 > Works most of the time, but still requires manual intervention. U-Boot? EDK2? Both? (Possibly answered by-example below.) What stage(s)? (Not answered below.) >> Does that get you to each RPi3B having a >> good context if you use a 0x152d:0x0577 on a RPi4B? >>=20 > Sort of; The "good" Pi3 is using a 0X1561 enclosure with EDK2, So this one still has the manual intervention required sometimes? What stage(s)? > the other is using an ASMT adapter with bootcode.bin and timeout. U-Boot? EDK2? Is the combination reliable? Note: The standard EDK2 related content includes a bootcode.bin in with the other RPi* firmware --and so bootcode.bin is involved in any normal EDK2 boot usage. (Adding timeout should not hurt and might help for some boot media.) >> So this RPi3B is main [so: 14] now? >=20 > Yes, the "bad" Pi3. Have any combinations involving this RPi3B worked overall? Have all the combinations involving this RPi3B been tried? If yes, which worked the best? >>> fails >>> detection with EDK2, silently stopping after the ESC/boot/setup >>> option expires. >>=20 >=20 > Yes. =20 The closest text above the "yes" is your text, not mine. I'm unsure how to interpret this "yes". >> The EDK2 stage? The FreeBSD loader stage? Log file(s)? >>=20 > I'm still not confident that the second EDK2 boot microSD > was set up correctly. Any reason that it is not just an exact/complete copy of the content of the original (working) EDK2 media, at least for this stage of testing activity? > I found an error in config.txt, fixed it > and that didn't help. Could be more than one error, however.=20 > Basically it does not report "no disk" and delivers a blank > screen. The above might be worth a serial console log of the sequence. >> At the EDK2 stage, the FreeBSD kernel is not involved. >> (The HPS patch is a kernel patch, if I understand right, >> not a loader patch. So: the kernel not involved in this >> failure if I read things right.) >>=20 > Understood. >=20 >> At the EDK2 stage, finding, loading, and starting the >> FreeBSD loader (on the same media that the FreeBSD kernel >> is to be from, but in the msdosfs) is eventually involved. >> No extra copies of the FreeBSD loader in any other msdosfs >> should be present. I can not tell form the wording if the >> FreeBSD loader was found, loaded, or started vs. if things >> hung up before the FreeBSD loader was found. >=20 > There were no extaneous files on the microSD card, but there=20 > was a full suite of MSDOS files on the USB disk. That didn't > cause problems on the first Pi3. On the second? Maybe... Extra files on the USB media should not hurt anything so one as there is only one msdosfs with the FreeBSD boot loader in its required path. >> I assume "usb-serial bridge" means USB-SATA-bridge. >>=20 > Yes, sorry. Not a typo, but a "braino".... >=20 >> I'm back to not being able to track logs vs. labeling. Is >> the following right? >>=20 >> JMS561: 0x152d:0x1561 (how many of these?) > Only one, used on a Pi4. No problems, so not reported You now indicate manual intervention for a RPi3B (earlier above). >> JMS576: 0x152d:0x0583 (how many of these?) > Only one >> JMS578:=20 > One So is the JMS578 a 0x152d:0x0578 ? It seems to be another one for which I've not seen any logs. >> 0x152d:0x0577 (?) (how many of these?) > Two.=20 >=20 >>=20 >> I do not remember any log files with/for the 0x152d:0x1561 . >> Nor do I remember any notes about if the 0x152d:0x1561 is >> well behaved with any RPi3B. >=20 > It's decently behaved with the "good" Pi3, but fails disk discovery > maybe half the time. U-Boot? EDK2? Both? What stage(s)? (Disk discovery happens multiple times overall, including it happening in FreeBSD.) > It's perhaps significant that both Pi3's were > early models that still required setting the OTP bit. The one I have access to is that old. (An editing error in recent years means the warranty bit is set to indicates unsupported overclocking of the RPi3B. But that happened long after any warranty applied.) > Maybe the USB > firmware contains bugs. Pre-RPi4's, bootcode.bin on the microsd card's msdsofs (if present) replaces the internal firmware for such. > Once FreeBSD takes over, they don't bite. =20 Again, you have supplied logs showing FreeBSD mountroot errors. FreeBSD is having troubles with disk discovery, at least when 0x152d:0x0577 is involved with one of the RPi3B. >> I do not remember your reporting observing any boot-behavior >> differences between your RPi3B, given the same U-Boot/EDK2, >> FreeBSD loader, and FreeBSD kernel used on both. If there are >> such, indicating which RPi3B for each test would be important. >>=20 > The first Pi3, once booted with a JMS bridge, has worked perfectly > The second Pi3 has so far booted only with the ASMT bridge. U-Boot? EDK2? both? I take it you use the term "booted" to mean that there were no FreeBSD mountroot errors, despite mout root being a FreeBSD activity with the kernel already running. > Once > booted either one works perfectly. =20 The kind of activity after mount root finishes does not do a bunch of the types of activity done by mount root and before. >> Having differing U-Boot/EDK2's, FreeBSD loader's, or FreeBSD >> kernel's that were involved in differing behavior is more likely >> to follow the firmware/software combination, and not the RPi3B >> when such are swapped. I do not know if you have done such >> testing. >=20 > Is it possible to boot ARMv7 on a Pi3 or Pi4? There is no ARMv7 EDK2 so far as I know. So the ARMv7 U-Boot would need to be in use U-Boot and the ARMv7 RPi* firmware files would need to be present. https://www.raspberrypi.com/news/raspberry-pi-os-64-bit/ (the end of the BETA) is from this year. Prior to that the official support was all ARMv7 or ARMv6 based. > That would let me > set up a single SATA drive that could be tested on any host in > my collection with any candidate USB-SATA bridge.=20 As I understand, such could work. But I've not tested such combinations. I doubt that those FreeBSD folks that developed the RPi4B support did much testing of armv7 use then or since. I'm not sure how much RAM would be put to use on a RPi4B with more than 2 GiBytes of RAM. > To some extent, ARMv7 was the original target system. I rather > got sidetracked by arm64. It isn't needed for present purposes,=20 > the memory demands of 64 bit are a real headache on 1GB hosts. > I was drawn to it by an expectation that FreeBSD support for 32 > bit systems would atrophy. It hasn't, yet.=20 It will be interesting to see how long FreeBSD keeps ARMv7 and ARMv6 going. Fedora 37 (in BETA) dropped ARMv7, not having ARMv6 to drop as I understand. Fedora 37 is also the first Fedora to officially support the RPi4B (and variants). =3D=3D=3D Mark Millard marklmi at yahoo.com