From nobody Tue Jan 04 09:03:45 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 3E35C191C6BB for ; Tue, 4 Jan 2022 09:03:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-22.consmr.mail.gq1.yahoo.com (sonic317-22.consmr.mail.gq1.yahoo.com [98.137.66.148]) (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 4JSmrD0vjyz3Qkn for ; Tue, 4 Jan 2022 09:03:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641287027; bh=paNmKIoD3e+O54Y4YmhYQQOSkJjDFIVpihqIWH4rulM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=dF0+BBDNhqVBlog3s9fJp1g6/agF4gULJ8ByS+uCS4We09ctSDORn6o93WmWunejNRTYztNFB8ORm7RTjLkVwXaIT0mWdygWqxomUzZWRA4/ekGc5Jy5G/3zrjQz3DumHg4JawXTdsmDw4/vJgtJ6wSCDDTqZxkst1zVDAvC3nSpoLDUf+NKjYRwaQjAGQPLO9iUWmBoCszDLZHgi79VdfzxxnYCd/GV6SNeYS3SajaLmxx9Moe9YVFnfvXECSdHL6EwCnhTEDcDhQDP2mReyq8PbaA6Kn8fBtL+gxQbkFrDeDawq0ZTuCvd7+WrJHJkunkOnEZ1S60tU1ngvcQG4g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641287027; bh=Iv36SljwCs0uHHC33ZJq/y5WFts1PN9TQENqKhupk3c=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=XzAy4j+bDwbGEaghLRbxbbsP62DNeREVJ2Z0zmbXiONs8v3VnvvzZC244OzlKVWt1PcPLx1gIKK5YvUAehvU+7XRBb845d7zg7o5A+yfqFUJ60wLyK5CAONzkWdLSx5hEXCXK8M26vkbHMbwZ/medvuRAd+Z1QVqJQLI0z8u37sLrIPPu1N9bnee/SWQPs0OzxTe4Z1i6Buz9Z/H+5UY9uBZ4aRKyzwvfadXMWTqXF3Hts11Im05P9XvqLkMd7jdAIV1xxbqHkqXyZt+4czUgdHIWYoMkTqkhhvlRHGtDp6QR1ZsR/cMKWoo3DZ57b9XZLOypJ0nihtMaDILttlWXg== X-YMail-OSG: BCdGiVgVM1muAmQ9Og67OySz5nZUuKnbRKNBxnhxHOk_kkaFiY.EDifPkXSlvSB XUi5aohOJ9A8FwHtrGMkIPXfN5tysDFlIJEAs06FNxf7_neKa6UcmpoxaH02QBajPRxi.6891dhn t66.CLfsHW2dv9MOxgMC_0byw811oZnxaLt25bv0_hx0l5ZsP4r1SGdQYwvyE7lq7lc9gc3IwJ3b LQqdNEV2jHI66RWFRY_XgQu6gcHvvIM63RpvHDxH2tmJ4UwnM4jgfu1H2ZU25zbZKVA5KGYX0iOc 86Hm9GEFDEJv1KocuGcjX01ZXykfy8.qCtGbMR.3DRDroI0sfkISADMT0uHT8p09HMVwRSpVPkVa ts5neZiawqFZ.3atPUxmZquQccI2vktAN5BkHrD5AKictsybf3UatCuKkP8BGK.OhummYgZBvmAz 70GYPv2ycimKNe1fBUqdFpdrCXj0kctYL.oPkcizsDOAFU799Fi6.PMzPR0nIJBUd1S0KLSjgS37 9SN5rvAfLK4eoFk.ncgmtf6lp_0P3twryObg.WxKzZxc4c.FQaic92YhH10k93nHTlOMAxZVjLT5 kulJTygBQgumrLHSGiMl.HvhSgEXdNGhyEV0hbt7yea9CsUvh7es79pU_Wzev8E_zuFRGtypjPw3 HLDCaKnz2sY_C.rFq43Qg04UtNDyj5jEy5CBMQeWpWOcoAHuCC_O4nrxVKv2Cj2TDP_G.svy2J2e keWZ2d1RynS8hUbO_NIgGOjapXGfsSWL52Dr.W.ZiZF5TBo6ohomqYyJRCq44AC8Ntv.K53sX3nS 4WEyxwp3Zf_xQL6JMecoeavoivJDQxkJouGuDVNq6PFJffK1OLaUtQvDyWqA9qVl5iDHlLYjoEDS lk1W.vgmZxrLaDBE0zqD_uGGnNLh.zwdLVOlKfk1qZGacQJCBUthwPlWZZhvVboqFR1OEu0fdLy8 GRqb8Yni24zj8e24895.cmhNB_RBmflxHfRgGl98srjztS5GC8qdSLC_aPpTMi_1QXPUv1xObHK6 cPeBmh0f4hTahiZTLWMAPEA9RQzk8LfhrTwcCOhwVJlOF7REhUMh6T8O9_Wi1r0HYfNq4eixXi2T gy.ggn5_t4k2r_UD8F2_2LCG5CkmXjCZB0gSCOrFj0lCPZOreKNMQMr4ZcIu2Fe.QeuVUGHTSnJn brje9L04Q409T1dV.uFL8t13ojeP6DsFkxo1kc9BrRlIWRQcZk7_sm8fKB4Zq__e3z4T4Q2WSQc5 kbalga_0hkqfCDLmt.OHzojm0pd7UGRHN.0vf_rTq64QREHktWIcHdbOl9TUZMyUo918.UsBAOr_ r9qAHD2zOpfsma7RRUad0PBat01K6KTi8nc9e53_wUb1yYXEnD9B23JK.WN8xo3RckcYnu9hGDir ExFPqoptBsCl7oeHvoqkLimox1y7TGn6iwKKRSPknYdQavV.7W.ClYuJHVuFjA08HX6TkJKzn1zv ZUB_YeRVpAW62wLL9r9Ps33NIJbgH3viwXIGVlKgrhYwTDLeTnOeWBWQ2iGn8Q89OjpYPfB8Vol2 iI1Bb4P6BMEyePe5emiQc6ZQ.ItBASu2Q_q115agdjVoS40yXKx1IlBOAsfYpmYtHAkmTTkC.PaQ xeYIAxVTE.3gV3rCeP2D8nhFpaXW.GYM9CtNdFmfgoH7JHWKNuk6HRtXvIFA9.NggX7ekA3I.Yxl ZMCUc4AXDfcdPH9kQ9sSTvvvvizb.I5EiZL54VhvpmXqhOn81BWEgGRsNYiau9A5Uv8GCcROB95N yiR6J8w7Xxv_7QHNqwObC.tKHL3S71HMwCZ3V9APEdXoHX7tAuO2pYK2u95KWWlxCoz.EnK6BoMo AJ.0fuRqD1jE5E32V1aj7eDrmqDRyOOdJ_dj3HqBoipTc_grfjAos48gKDqQeyDOu1BdD94q22CD rLgdhHcI4Uob6TW1ybzOj8GPBo_jHjdJcBnmnwt2SZfoK4xKidZ6yyODm9tDnqLbX_dLnDPKL_Cx CPk_s1.UWC0PC7G9CQ5L0Zv.Q31_AnZMf2w3nmYXzILSu.Auo4YYOOj3eCU0HdWg9.t26R1KZt2Q bQmYMYg3LMuDA3guQToeZh5j0k5SNycdmbLy8YuUXh3fpe4wIrQ1D2rGiX.3rbQo0gBX2XYivoEk nYZu5ND7cA1jBg13A6E_K0InZ2xjSXi_sPqHhIHZuaLW7WZ.rZQn8RLfCf7Zw0MOAx8vNUuz2rBM wYWlZwQVD2awlsoeXL4hTDCLLUQqpblH4VA7_uE7aXgtMLPXHzautmDeLBDI96g-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Tue, 4 Jan 2022 09:03:47 +0000 Received: by kubenode538.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 355267d4262039637ef5348e38d7a548; Tue, 04 Jan 2022 09:03:45 +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: <20220102025818.GA42622@www.zefox.net> Date: Tue, 4 Jan 2022 01:03:45 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <073F48C5-4F96-496C-B23F-607752312072@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> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JSmrD0vjyz3Qkn X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=dF0+BBDN; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.81 / 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.66.148:from]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_SPAM_MEDIUM(0.58)[0.585]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.148:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; 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-1, at 18:58, bob prohaska wrote: > 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 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.) > 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): I do not see anything here identifying the U-Boot vintage used. But the vintage may be tied to the save working. > 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 I do not see anything here identifying the FreeBSD loader.efi vintage used. Likely it need not be old? > Consoles: EFI console > Reading loader env vars from /efi/freebsd/loader.env 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. 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: https://reviews.freebsd.org/rS346879 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. There also is a loaddev that seems to be involved. I expect that in some respects part of what is described in: # man loader_simp applies to the contents of /efi/freebsd/loader.env . But Other things may not, such as rootdev being used to initialize currdev . > 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: /efi/freebsd/loader.env content might be able to control the above? > Trying: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(0)/HD(2,0x01,0,0x1 > 97c7,0x7726839) > Setting currdev to disk0p2: /efi/freebsd/loader.env content might be able to control the above? > 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, /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 ? > 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 =3D=3D=3D Mark Millard marklmi at yahoo.com