From nobody Tue Jan 04 09:31:14 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 578001923B3B for ; Tue, 4 Jan 2022 09:31:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.32]) (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 4JSnRy1QGqz3lMj for ; Tue, 4 Jan 2022 09:31:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641288679; bh=ODU9uP4cLaCmbbGpS65nrGhUrqn7h8EZUf+qdF1RZzg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=pTBRq4Gy0SeyxLRLrBkKub1gY8zBeoMc6qy3iEwwgzUdOxsjktEB6cS+MkgDbk6Y7vQh9CRPzot0hxbEGanJ4M4QF7prAEsiztYffHt79CzpuLaTlRbJMyYS9Usaox1b95+uYNvbxsuyzHgZytXsocfQ5lf2opBD6wc4J0SyrBRF3kDYcOZIjJI4SwkSvZ5FidpA3Wpb1R8gIJQVcAUGWSZ68//wUjlZabGhLPtwDSNFoIybKYRf/t2D0IVRvG35YjBqae6pleYzmjRGQkgrQPG8oeYOQBuNE85ibz9wOfTjz4jIzfHxMgjb7JhqP/bwGpzGistWAbTveJk4CZs8HA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641288679; bh=785EiFz3Ngr5RIZYzELx8jSPVQD0AsS0+UVdxncp9QH=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=VrnOtLBh19q2FOy3dnVjAW3E1F7r2wc7z5+RbXCNgb/y8jl+qdS/u2ZNdF8OH0TLB0v9whK2qqWy4YOH/bIL5C0cyQPn9AwgUtJeeeAIrvdfn/ftGoh+/tudAz/T4IxYBVCVIGqYAjlI5WS/+KkhJJNOmoWQCClFFWo/UY2BTkD8z8fK7C39YIT3Vkcx325hJeCr6gDBfBX7cIpLZvOCd7+5DaFyuc5SxJHEhgSWe85MBv1nDVIiwZieQVGpVg+R02YCaoB2qs3zcxkF3u5+WYJMPOjlgEzqLF7t4/BT5Jj3bDfMsz8zxG85ZvPsDn4QtJu0NvakoZFclup0yfM9rQ== X-YMail-OSG: iO10DqUVM1n4gdRZpXc.glnLk3_mwNPTK.ZJ6ldRj6eca.0SuoSsRIOyix5sFHT rXuqsVXQYemkhKpfQU4Jo3u.wjznhi5dvmr6E9EONCtyD4Fs3Mf4W4D_yFnEE3Gvm8.L.w7T7kGA 15ltAdn6jtu4.6eOP7EbxEz4WbKPh.v4PENHOGTOOXSjjjiv3iHa8FbOWjF3qWZKZ9bCn7m2FA8c vqFDJ.eCrYlvbvi7YaHjsGUsQx.sDSCfAQkAsphidUneZT2rI7hdp5Y6bclYbeChp6O3UDU9S4qm 8WywF191zDjxSYaGEVui1ZphOpSrDT12.fqlkUGLWVfZMqWpJ6yKfG3axTpT4BRv11WirFz5cUXR AsbmAzkpbmBC.ZuNl3JJU7n8LLmfiSLyPNzMCvS9ocKn3aOCoBV1mD4_0nSf9mhbnNDM092wsC0U _jrhU_DhknjWq.hNAef8IW1lMx68JivmGb.cw9oyaji_5T4iAOBhbmAgJLFXMyMac3I3xR2jFNDb AJ52qlJbvvWUlK1Cuu2RwPnYdoPYBanf1Tj5JCGfBv49jIxDMBCInamwVGItsPTr2tug4RM_yDIX Byy4KZLClP8cddX6F3PIE05Yv3aIXKU6.WGFgjDG.gxV0YRqj7yy.5Mb49vvYbFWtP0g60kQJSW8 _HuJ5m9aWdxpWEdBqy24yXlO6IfOGt6M.b9nNxvrZhNGuIqjGOarbtwgxaQTYbTaDL2FzTyAm_gk JZE6j3ryhaw3vvSBkVUwHW.sn_x671KS5lcb_thggM9wqNmwy2QWfRTxwNb2IEi6E_YYHiVZ6fjV ojNfy0jxZS4ixF1Sjgr3tLo2bwoCNz0ghdR_M7tl5ekkb2QSGTbbtbqEMf0zMLm8TkJkz_OMV9kU 8jZ.JexCMdYV_O9vwBw1eH1Yg8ZExpHr6NvheqtbVQ1aTYnMHGh8WzrOPv_tWgK7mPy9v4W0Ihe0 3CxEvdjTDd5HSAlQUia8KJdlEkZtx9LvDJWKRhwkUx0GUta4n0eAcbKR8FMvcKPk_3gNliBQ_hrh oIyB6FVcZM_lWs2JqSJeZgCeHudizGxXdaEADdDK5mPO9LroAYbtR6CXEtHKMIZcBtWLogHrK2Pp EQ9B3_K65DNqhPZmg8muCkI0veGxshPE8ZcoVTumkQleduAV0eC0YN3MZ5bstDqoJuzmixPqS9DY qs8c9pNbhDmnO0dONZmbmU9vQEPp_bCogEfrqFTj9IRRHvCUM5bBM4oz9cB6b0xhg3Y9zFHbN8VE wGgBTrTTT797e3_.rUk9IPAU67mgC21ncSVxofhKvquifEBdhfj01RyIkcB5hSxQaY1iwsCBNOJP qtpno6R5xzJOhC987.2arkUUP0dqIzxffDDdsmh9iU6RlyWh1ZOo0ananX4Sy6pTtYdapPvMgBHX 0ZHNasBgE9Sx9dEBAFO93A_qa12BW0aAjCQrEEjuJ82wpui83vusoiLB1edpVRKmjDPfun_qEwje nZy3Uj_fOBaZFODRtD11sdx6sOR8GKRiEVa935avXSVbm1B6b5UoGtwemQDDHrF.C5nXbM9nlIyn .nLpb4X.PH2F3BigwWWK3uy4myGsxtrh7eWFOz.2d0ePwR2f8JsxXcZ0D1H5Mb76ZEAs4HT104Ml qWuetvJt02bmPQpLCYR.wQQ0VScFBh9aN4eMcFQDTNgNx4CJB0MI36mwzP2_k.R_B961Ogq87Ijb ckX2slm1rqmzXiQuXYm_t4AEiEk0Fi9UCvuifk2rvHePeGWKiNobqFiJ20FWo1pSAWTurJVSLR5u ly50SqaReqj2PFRnJjqTOymECv1bsQKBelgFFy1TklmZSYcSIgjPd5hiam.CHBrprluL1MVEM3NC sDpD6reTr3t4dxbheZy_rUfDGrGcE6voR.flS6etdr3a7yA3yVb4k0gxXQBHzD6EUHuajr9fokLm oa6VdGk2uPNbbAjraMRxXyeYn6R1fqtWMTN0lAyOEMLjZrkDvOnxmuvMMA4MBTYR3zfopaQ1XxcA 8kEu7vtwfv.OTnGGlzgKyiD2PBcKAsn.iUYWkzQ374qeOqJyOfamU..gwLtHZWkeLqhMx_eLddn2 xel8qZm2p_GDy4oFSkFWrMzQWFP0OBcUteCfzXirts7i_.05t.It5EZwZTgx03bQMe2W9FqGP_ia Wx62lFdDYIeO5PSAtdABZz.Oc.GuI9s9y71CbmyioJG7MrjqEED10qYjbfpnFHWx_Vdgm6rIm0W_ ldbQFoZVD6ezXz0CviTiQ73edV6_RbWUCUXjlgncpo9hwGvHEdE4v6711 X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Tue, 4 Jan 2022 09:31:19 +0000 Received: by kubenode549.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID c2449902ac428a9af9d58eb56270f3b2; Tue, 04 Jan 2022 09:31:16 +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.120.0.1.13\)) Subject: Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot In-Reply-To: <073F48C5-4F96-496C-B23F-607752312072@yahoo.com> Date: Tue, 4 Jan 2022 01:31:14 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: <8551EF27-BF69-44E5-BC32-FB7E1752FDD6@yahoo.com> References: <20211218223543.GA9484@www.zefox.net> <772E3794-B762-429F-B2A5-F504EA293C59@yahoo.com> <20211219043422.GA12811@www.zefox.net> <288258B0-40B0-44EC-B449-7A8FB81575F8@yahoo.com> <20211219192854.GB14873@www.zefox.net> <28D85D32-7C9A-45FC-8965-DBE8E0DF5A5D@yahoo.com> <20211219235409.GA15576@www.zefox.net> <20211220043956.GA16208@www.zefox.net> <85C29A39-824B-4FFF-8EE4-70CECE7AD09D@yahoo.com> <20220102025818.GA42622@www.zefox.net> <073F48C5-4F96-496C-B23F-607752312072@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JSnRy1QGqz3lMj X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=pTBRq4Gy; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [0.43 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.32:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; NEURAL_SPAM_SHORT(0.93)[0.934]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.32:from]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2022-Jan-4, at 01:03, Mark Millard via freebsd-arm = wrote: > On 2022-Jan-1, at 18:58, bob prohaska wrote: >=20 >> Coming back to the saving of u-boot environment variables, >> backing down to a much older set of FAT files seems to help. >>=20 >> The machine now has a DOS-only microSD with an old set of >> files: >>=20 >> root@pelorus:/mnt # strings start.elf | grep "VC_BUILD_ID_" >> VC_BUILD_ID_USER: dc4 >> VC_BUILD_ID_TIME: 15:31:38 >> VC_BUILD_ID_BRANCH: master >> VC_BUILD_ID_TIME: Jun 7 2018 >=20 > I've no clue what the status is for this vintage of RPi* firmware. > But it is not obvious that the RPi* firmware is what enabled > saving u-boot environment variables: the U-Boot vintage may be > what made the difference. (It would not be the FreeeBSD loader > that makes the difference: not involved until too late to > contribute to the issue.) >=20 >> With this suite of bootfiles it's possible to save a value for >> usb_pgood_delay of 19000, which in most cases results in a hands- >> off detection of the usb hard disk (via a powered hub): >=20 > I do not see anything here identifying the U-Boot vintage used. > But the vintage may be tied to the save working. I may have implicitly presumed that the U-Boot vintage supports presenting a UEFI interface. I've no clue what vintage such was first good in. Thus, I may be implicitly indicating requirements on the U-Boot vintage used when I suggest FreeBSD loader related material. >> MMC: mmc@7e300000: 1 >> Loading Environment from FAT... OK >> In: serial >> Out: vidconsole >> Err: vidconsole >> Bus usb@7e980000: scanning bus usb@7e980000 for devices... 6 USB = Device(s) found >> scanning usb for storage devices... 1 Storage Device(s) found >> Hit any key to stop autoboot: 0 >>=20 >> Intervention with run bootcmd_usb0 gives a successful boot from USB.=20= >> If nothing is touched, the console displays:=20 >>=20 >> MMC Device 0 not found >> no mmc device at slot 0 >> switch to partitions #0, OK >> mmc1 is current device >> Scanning mmc 1:1... >> Found EFI removable media binary efi/boot/bootaa64.efi >> BootOrder not defined >> libfdt fdt_check_header(): FDT_ERR_BADMAGIC >=20 > I do not see anything here identifying the FreeBSD loader.efi > vintage used. Likely it need not be old? >=20 >> Consoles: EFI console >> Reading loader env vars from /efi/freebsd/loader.env >=20 > It might be possible to tell the FreeBSD loader to use the > USB drive via the content of the /efi/freebsd/loader.env > file on the microsd card's msdos file system. Likely this > file would need to be created. >=20 > For all I know setting rootdev ( or currdev ?) to the > appropriate disk?p?: text might do such. (That notation > presumes UFS, ZFS. ZFS uses zfs:DATASETNOTATION: I've > never tried using /efi/freebsd/loader.env and I've never > found documentation in the system. But there are notes > in: >=20 > https://reviews.freebsd.org/rS346879 >=20 > Given that wording, I'm not sure just where > /efi/freebsd/loader.env ends up being relative to in the > msdos file system. I've not done much analysis of the > code that is also listed. >=20 > There also is a loaddev that seems to be involved. >=20 > I expect that in some respects part of what is described > in: >=20 > # man loader_simp >=20 > applies to the contents of /efi/freebsd/loader.env . But > Other things may not, such as rootdev being used to > initialize currdev . >=20 >> Setting currdev to disk0p1: >> FreeBSD/arm64 EFI loader, Revision 1.1 >>=20 >> Command line arguments: loader.efi >> Image base: 0x39e91000 >> EFI version: 2.80 >> EFI Firmware: Das U-Boot (rev 8217.4096) >> Console: comconsole (0) >> Load Path: /efi\boot\bootaa64.efi >> Load Device: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(0)/HD(1,0x >> 01,0,0x81f,0x18fa8) >> Trying ESP: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(0)/HD(1,0x01,0 >> ,0x81f,0x18fa8) >> Setting currdev to disk0p1: >=20 > /efi/freebsd/loader.env content might be able to control the above? >=20 >> Trying: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(0)/HD(2,0x01,0,0x1 >> 97c7,0x7726839) >> Setting currdev to disk0p2: >=20 > /efi/freebsd/loader.env content might be able to control the above? >=20 >> Startup error in /boot/lua/loader.lua: >> LUA ERROR: cannot open /boot/lua/loader.lua: no such file or = directory. >>=20 >> Type '?' for a list of commands, 'help' for more detailed help. >>=20 >> It looks like the root device is still the microSD card, >=20 > /efi/freebsd/loader.env content might be able to control the > kernel load device (via indirectly or directly controlling > the currdev value), possibly via assigning the rootdev value > so that it will be copied to currdev ? >=20 >> even though >> the USB disk has been found. Any suggestions appreciated. There's a >> complete and recent ports tree if it's helpful, attempts to use it=20 >> on my own have caused more trouble than they've solved, in particular >> that's what lead to the "saving to FAT....FAILED" messages. . =20 I'll note that the code from https://reviews.freebsd.org/rS346879 that added reading /efi/freebsd/loader.env if it exists was not committed until 2019-Apr-28, well after "Jun 7 2018" (the only date I have for your context). The FreeBSD loader in the msdos file system would need to be from after the 2019-Apr-28 commit involved. My guess is that a modern one would be fine, but it is just a guess. Setting rootdev via U-Boot may be another alternative that might not have such a vintage-tie involved. =3D=3D=3D Mark Millard marklmi at yahoo.com