From nobody Fri Dec 17 07:00:46 2021 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 2888618FE36C for ; Fri, 17 Dec 2021 07:00:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-21.consmr.mail.gq1.yahoo.com (sonic314-21.consmr.mail.gq1.yahoo.com [98.137.69.84]) (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 4JFfyd6B01z3Ddl for ; Fri, 17 Dec 2021 07:00:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639724450; bh=JYur/AlsOydKEJWz48CoviwkmUZHSx0wu9Sk44ApcfI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=j8yvIRBSrr3YmrNI92WmCarWb7ivnVNL3QYv+hIHQkAzhlgNVVYUgMha2Bu14DjMCVjCL1KFMcx7uaIXg8xazckEGBpRG3UeA+ZUD4pAT0nIDBbH2b4lQhYLIxuShGxOr3vgbfWoToTomPqwgzrb4B4BqTvwreNnrTTs/udI2M871fk2bGhdDFylIWTJnyuh9jqwNhW5Wwk2DnFV6ZU4IxIXc9m55oj+MBMaZGTFTnbe04ylAvK6h7HsAJB21XGj4WCBhHZeaXN/aIhxuOds8g6KkTe+RS/qgnU714XLLjC9MywdsJw8ScaMPxNZQFpJaG2LcnmsgetRKuttRoDapg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639724450; bh=D5qj8mp4hU66FEndkNqrn87YcYmlb2Lwb6l6TM+YjeE=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=QxD3GG9tVSLiyL+pn9V8y5p3bQLMSdLM3hawcrf4702X09TcE3O5eTYlN7gygbFWeTI1XVdtABKEPEgc2gT6XX3KMIOlkqmK5leHL+lZ7CLJ1+j8wN5UdvY0VQXocgnSCzQ6/9SPdkPPkLrkpd1ciRcCcD0bjYKdXvQE5Pz2lAJxwbi1cfHDA65beVw66NWYIVfO/lpt5bZQ+9z0z2lZmySQ8KAnU5VOy/a9Amc/PILGnL0x53dryAxoslS8BDd2CY54qXnqzT9D0+nQ7hI44EwBUMJDDniUsQ5VLpAySj9mGxatRYJeACDExX6x06NfmEAMsKAsM1Bdc/60C0C6yA== X-YMail-OSG: P5d8gQwVM1mzVF.kakG6rIAi_X28g55IJeeuM2mwt.RaIjRm0OUjMj2FKX37ibD OOoPxpYFcRjUw2rqWzytgumJASLIuBl1qluuBy85SueUZCdYLgR071a81YLErOod6kCvsXPvviPa rB.8rdL1T8vyjsxxw3TEe4tAXD9Md1mLYZQhyv8mS1CP2WVyGHUQj3QVAEhvjm6DxXV2znpK_En3 PE4tWHsmcwcLKQRFRFBjnUAtam3FhhXSrYO8hCyTqsjRuaMdlpFU39qn4QaEfyArFc2oFA2OJnZv oR8qXRbddBXT8yj.sxTlNJj_nuQyvgn7CJkB.zu7JEX0lKcGp5Er1_03kl5znYJlvj9XO33uu8Z. Fs9SrL.hGMQghsrQ.maXjt49o9_rFXUQ4JQTMZWSIkCzVQDr6P6.5dhHg1v2.BeLtYIlh.9UQhyd 6iCj_ff0LVYGrIWN6Xh6th.mdk2bMkjMUA7Ldlr6WYq8om_73A3.6l8nas5ooSxqgGRg3H.keTQC E.gD3GdR72C7NDg_6dSz_0n4vwD3qkRQpKuEUoXMp7Jvv_gfixmrbppLuW8lPRc9XyMpYmMkCaCS 6SURtlV6rnaOdCEn1cX_D0FS7I1S2.ppMqN23lQWLAIOf.hlC2k2lEMZzGATR4uKo4JW0jrvqJ.3 4qtSMRdwHH9vsBB65riRYUc8JPhmoBYlU.upiBaTAb0fnXHY6DpGON4G6zBkMNS.vmtRp338s1QF amysXYiMCNeGpNGOEXvkJAFFoN3NsBSa0yBnLZnD63nMobl4GjXhjLnzen7zzW0M07EXB38u69ay OTZLThygQJve.IHCbqlc2KMbASN327_K9UzHtbNwZHvvB0JbcSF9uAP2x.8UpltRStWnZ6gKuE1c hkSjaV8TE0bKmXE20WgoDLLaE281PG0tYkBSBzoivp2fWsDvM87jrLMcJZW0fkqAQtaPXK5LYanc 5WYie8fR0tA7U7PSeYh3l0x.YES5.SEEYbuLmfttjJR9xbFv9IU4R7_1V2ocMUxScxzcUSFtdChi IbFukRTRzh59X0ISL_G07tw9SOfhidosm9d0UHBmSyt3bfIlbXHZuuWsl4N7835G8QhpsfjHvKOv W1PRULGZf1_2G5lw9MIQikDH8sivdppCdZ3mZ8qYFmSTPrhwYIqE8JqnEu_a5hR0x_oy.enHKECV LqY9hjsQfcaRFKz7QuXUxBBclThchQX4aTyafJq35rNeah1ozVUL8C_9.z8H0KjvTQx2i9mF0QVj lCfc6zv_rMJPdyK3hbHo7qafgBPgNClDCsLo.fNj.njMVfVHGQaSCU9Cc25EoNuuXX17nS561wzD 4y37PdLZX8_jSA3gOktrPUmtPNarbLUeN.X2pqUOm5G46__jPYzOo5_4zaCM6U9T2yVxHFaelSOG AITtE1iPVmkF4._LtZxaCD6V.S2rIebomqTTGw8MQvZvfO9omJAP1ePnHzSmKbQIs1zbu3d4SaWo yj1kEbQr_OnoZyCPAy6lNqioVwg2UHPtzt2EimEQGzt5LVxZx8mG8Gy3Bgb.ghoTSqWoa8uiuV.Y zxUkNLFpr9PmMlp7kkS7k7cWwwQtMPfDdzV4._cHs4k2uy5q5_lSQ3F9FjyBLg10K15rwbX_Z86N TwE0Vzud2QloDoqCSZm.fEpA4hXC3K2D8qt1G5WuhGme1Q4kP7RW49njUOqYTAJqLT56_HD4a_Vf kfd7ePb512Bq2hnC0lyWhG16iPu8gcNNk8SdU1YpT3_1nStsmwXIUIN1EWGrIsj6X2U9QDhuaQPK 4aX3GIkquQ7a1YOszSwhjO8XHk5Mz_HR50PJGMSDfoOu3IDYI.I76UBIpDhij.pzys_MOLBvAGxd JobJEJnyz0WV82goaVA_KQ0v4x5wwhtLzbGlrjRo2DEoyta4lszKvF3LNXGf0vyfrwcpDTCMq.gZ 6SDu0a43hDeqRw_0j7IYDQBLKLAQzCJMNzV144gmDxPb7LZ.XHK2iYsP92F.7CutVakqFwmBQ0zj jms64YUzIDw8ZkjwimoKwqyhUAnlRnwPITtrEiOPdcu_7I2wnE3SsaesDdPOwoIZZ5WCHSVu4qf6 Drdr_LbnaF_6Vz55JbxkLGUjWrdzYd1qauCozpnZDhkbfMQrMQCbX6d129GkCzywnUiaJMJItgZK aO3Qx4s3pcBh7EJo4THyfMYdPUPtWXPksWuCAjRBgZEaJ6lgu_XSrlUmpTIdyOVupDyvUchOoSid FQRc9Y3Ai8QTPGILLe.r6wBV8KKUmmiYEySv5UzLrThLhFlPtunSTbrAPjJ18iCFX88pv5vestDj yf_zwQa4peeLDjejgxSc- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Fri, 17 Dec 2021 07:00:50 +0000 Received: by kubenode538.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a4247d77cf4c9110046e27d81c6d4cb7; Fri, 17 Dec 2021 07:00:46 +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: Saving environment variables in u-boot In-Reply-To: <20211217013613.GA4452@www.zefox.net> Date: Thu, 16 Dec 2021 23:00:46 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20211216180704.GA4173@www.zefox.net> <214132DD-A095-4349-BB81-B79CB8CF6B0C@yahoo.com> <20211217013613.GA4452@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JFfyd6B01z3Ddl X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 5686 Lines: 161 On 2021-Dec-16, at 17:36, bob prohaska wrote: > On Thu, Dec 16, 2021 at 11:12:01AM -0800, Mark Millard via freebsd-arm = wrote: >>=20 >>=20 >> On 2021-Dec-16, at 10:07, bob prohaska wrote: >>=20 >>> U-Boot> saveenv >>> Saving Environment to FAT... Failed (1) >>=20 >> I expect that is based on there being a microsd card with >> a FAT file system on it, possibly containing the u-boot that >> is in use. I doubt that it supports saving to a FAT on USB >> media. Do you have an appropriate microsd card in place? >>=20 >=20 > Yes, the microSD contains a dd of=20 > FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img > The DOS partition is writeable, AFAIK. Hmm. That means there is also a UFS root with a kernel and world on the microsd card. Both the microsd card and the USB drive contain contain such, as well as each having an /etc/fstab (and so on). Having multiple such makes for a mess for controlling which is used (and knowing which is used). What is the first stage that you made sure the USB drive was in use and how did you make sure? You also have 2 U-Boot's and 2 sets of RPi* firmware: similar issues for those. What are you doing to control which is used vs. which is not? avoiding extra copies is the simplest way to be sure which started for a stage (once you get a stage to start). The order of activity is: MSDOSFS: (all on one of: microsd card vs. usb drive) RPi* firmware (I do not report the file-level sequencing) U-Boot FreeBSD loader (which uses information from U-Boot) UFS: (both: together on one of: microsd card vs. usb drive) FreeBSD kernel FreeBSD world (I do not specify which MSDOSFS is used when there are multiple viable ones in separate places. Similarly for UFS.) I word the below deliberately avoiding getting into how to control which is used when multiple copies of some things are present in various usable forms/places. (It is technically possible to have kernel vs. world in separate UFS partitions, possibly on separate media. I've an example context that I deal with that way to avoid a U-boot limitation for the device: the kernel can find the world where the U-Boot/FreeBSD-Loader can not. (The FreeBSD loader depends on what USB can find: it does not look elsewhere.) I only mention this in case I need to reference it in the future, avoiding a surprise in such a case. Otherwise ignore the complication.) You might move (not copy) the MSDOSFS material between the microsd card and the usb drive during experiments, avoiding having duplications. There is the possibility of instead renaming things so files are not found on a partition, for example. A similar point goes for UFS materials: avoid having multiple viable-for-booting UFS file systems present. As stands, things seem too hard to track for me to be of much help. Please make things obvious for what was in use by making the material uniquely placed (for the form that can be used). Separate issues/questions: Do you have the file "timeout" in the MSDOSFS, in addition to config.txt and the like? If not, I recommend including it. What other RPi* firmware controls for having various deliberate RPi* firmware delays do you have set up? It is not so much that these would be sufficient, but they do establish some context before U-Boot is even active. It could be important to understand that context. (Unsure at this point.) >> But that was for the u-boot-rpi4 or u-boot-rpi-arm64 ports. >> (They also later mentioned using "usb_pgood_delay=3D2000\0" >> instead, a figure they found in a bunch of configrations.) >>=20 > The Pi3 in question is capable of booting from solid-state USB > storage without any microSD card, but fails to detect a mechanical > disk. Which is the appropriate u-boot-rpi3 port to tamper with? I=20 > tried sysutils/u-boot-rpi3 as an upgrade but that simply froze.=20 > The u-boot from FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img finds > the USB mechanical disk, but erratically.=20 FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img uses u-boot-rpi-arm64 as I remember: it is set up for both the RPI3 and RPI4. Given that it works some, that would be the U-Boot port I would experiment with if I was doing the experiments. >> So something somewhat analogous might help if you are willing >> to build and use your own u-boot port variant. >=20 > Obviously, that's a fraught enterprise at my skill level.... > I'm still somewhat hazy on the actual boot sequence when > chaining from microSD to USB.=20 Having the extra text in the U-Boot build does not really depend on the chaining order question. But, to repeat (sticking to the simpler context), the order is: MSDOSFS: (all on one of: microsd card vs. usb drive) RPi* firmware (I do not report the file-level sequencing) U-Boot FreeBSD loader (which uses information from U-Boot) UFS: (both: together on one of: microsd card vs. usb drive) FreeBSD kernel FreeBSD world > Indeed, it's unclear how or if u-boot plays a role in starting=20 > RasPiOS. The term u-boot isn't found on the Raspberry Pi doc=20 > website, and the Pi isn't mentioned in the Denx manuals. Those > discoveries surprised me. RaspiOS and RaspiOS64 do not use U-boot. The RPi*'s can boot some forms of a linux kernel directly and that is what RaspiOS and RaspiOS64 are doing. That is why the config.txt type of content makes no mention of u-boot or of any kernel=3D assignment in RaspiOS and RaspiOS64. By contrast, config.txt for FreeBSD lists kernel=3D and an explicit *u-boot*.bin as the value. By contrast to RaspiOS and RaspiOS64, Fedora chooses to use U-Boot and lists kernel=3D assignment(s), each listing a *u-boot*.bin . =3D=3D=3D Mark Millard marklmi at yahoo.com