From nobody Mon Sep 26 19:44:12 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 4MbtVv15Tqz4cbrg for ; Mon, 26 Sep 2022 19:44:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.206]) (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 4MbtVt0J7wz3dt1 for ; Mon, 26 Sep 2022 19:44:21 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664221459; bh=52fmxc/b/haiIQTOpGFeq8yJla1ZVCG1Irfu+vjBR+Q=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=OwVC9yVmuI8kBiu1U4OEcPpu4RcdSHTm7sfUMDojnv1lAjDHGaCGh4n746kvJwsPpKVoL3q51EJnqMZb/0oz+faRAzWtbp+ez14yLrvDLitIqUnG9omQnDYcFyffsdQKmPriEdYFoYhWLBVAxsBsNzEwFCeZDiN/sTv0tFmRwl9vCnrYIxZJpydp/oJHaf7rhVPUgcGvakVdAMFCOoza1VdYUtb+VJcOed3LwrOjcZH3Qpp/57IvEOdPpMNbyjgEmWv4yLJZgvOguSs2fwenUE6ZYQSr7qMieXziA075x4MVsPSRmsyfXTMAD6XOLIGJBBnbT/HAMLYSKiZ7JIHjnA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1664221459; bh=mkQJ/4LacTALPHdwLRVKdefbbjg5tzFL+9lg0GjJ+ST=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=VDWnIkpz7MCgmpzQmWLYxjcPK3mMWwJJYhUbcvdBBDvMo5Xc9RJjKmF+mNTSF0Kw/XmN6i8hsiTjVMYal0/Im3sJQRTE3tvtHu4vT71Pc7oXoZvxUoGmJzkMbzm5VwmFmsHHlmE+Q9SaA68X0KuMwoniG83nj7PKlEmaJbsQzZoBaMoSGoCOE2X+jTsCpF1OeLcQmvpbX/NWgSWVjLW+QfWGr91JR+OSJhGgG2rAugfHdpp3tLay6j5zcO4uvQAUCRM3Z28BjVl7idldmIHiaZVgGwvxuAxKDKH1JJjsHZCvsGHHm+PhnxjNmjj4iQTz2++vgmzVwD/FIKdA20eLaA== X-YMail-OSG: nxz3uFYVM1lea6mf.K2gY1fwoc_uv91OS96s0z.hyovo8hIY8Sus1V6iAw1UwUn QlyPI.TBgBqZLnqthGaw_umKju.SmoCYR.k09NNpBJKC8KJmgFU2o9KDRlR_MEAtat3Y.81zu8CK jH7lN_KMvm_EEbzf5cgqeYed3KrxmgJyL5LgnPfookXgCgwEwSthdhd0ovclrzHeT_9Tjc1.96Wa 5M3p_wkCJSkKqjvCgIfdAhqyVdQqMi8w77KlSiCKh.C4k981wLXgXSCqN5Fe0vqSNbTcRAuv7AIP h.Un03TZVfClIRZkk3.f6382B3OjyITmqlL2qVw.sfRauSiNI4DI62mwNLP_UMju4E6_JjAFFp0V zkZhPeL5v4zoAh31F4Bdbmh08Eyr1GXZRLyTLIQ.t25cDsHZvdQm8Q2zgsI.HyD2dKB1bGZTuNPQ oyQzMuxPaAhUgERYGdIUBvyCPsydhH49uPinlfdB6dpQH6l3z_k7K4Ki5xUURZQiBMQEoEoSFDX4 zS9upDqwISK7hfHcO3snEY3Ii4a5swojWUhCEO15NOzixM2FJj6_B0APi9qsDvskekJb3OYgxRTA 12iIQyzNZKbe9MsLUSLDDSICkZySZBPFrEe6oPJ35mHdISA3VrebkDS1fJLdFTFuI4hJB0pZxlP. w_.cz5PFe47_jv_2TEFJBczG6WETIyh6aYMQSmWTNWKsyF1q4Y6rYX4M8lKhTimnb9fJNPPb2R7K cqvKFvunFZ0yd1gYG99HgV98uvAFU94EmR3lrQikb4D81hdciPIrBL..5i.cuFFe44mXqQzu.fhi Ptou1XktfqV98i0gVrwK3sVJ50ZQ0evt7nC24v29An_hZ5I7jVai09IrzeCYMORoRJAtAyUmLMnd dCIR.RUJFGKgfTBXTPHgCN0PMoF21YfRyi3khix9z4jvAYTUspyewRnbvoLq2ynS6y8RbVzMXAK9 MkHmvIOV7HDW3_GY1ZNU9a_WP__gKorjbnqP_JXgZfrGgURQiT6oiYjuz3kFoFD4CXh6GiVd2vtl ggS2mv22eG7RqrnIbd1F3qVxtlbw7s2zZD67BOvQaeDL9w1vJH5alz2ovxZqiTBHET17ZHVfXRh5 64w6TYnzYX8kzctK87C2qGAZH7cJOXXDyEOTNIu.694hKrmiNk_ZpJjXCPCuwRCYc6oncV9M5bat ed4hNzBy._hJRSMTWrB._McxHRXOksLXrjGj8YCaomWZtVYlsiluG7erjSqTze_5i5HQQ6teoJ9k IQIsVjerUyQaHMSKh3lHR7oWHEMDS1o1LdtEVQTSAUcTDXZxMfRBllFEqoT4otsZyPoFJxgqqv4c PLjh4.WoyNUfrnPtRNdffIyR4.8Mnk39bb40Nf.kGigrQ2qTyxWry7HyobYMPCfYflt.dWHGQz7. jykpnhqbkQFIVUyH4c84sCjkbo2uwdlfCkgGl8xle5XYPGd29m6XIlE6ajRzD1dhPxeCg0jWq0m8 VHIi7gncKxbSriSxmr53Sh2CswkekyDTId43FCqyfATLLJ2Fz74PF8GFg6Vwudcfs9oF7Q7Kr7Cf MrddpTWuZ2bgxaYD2Vd05E7gagfcDCjZoxsv4uoUgD.xC12F8rdSGXbxujw82HIJ0J9PSoV.i83G E7EzPwo87jxnWdTce1XdDKuiZjlNJlx7f6aklZnM7KMsLP6OPCCY_SPFPah9meHomY942cijr32Y AQfQAtCBIT6SlwRahwyom3BZSVOa51763b6L2XewgHS7zKtMpos7WS5SNekXh7NhXlsx5p0ym.fs 0kjJUyC4xJ6dOGxXlvXVekZKym_0Utar3OXs78RYRNCE4xcCkATXQ8gOFd9Xedii.xRMil7s2aLz sIRHY.wvo7pdrpmn3rFmKF1lNU4rruWULdPIca3w96.GTM4GBo.MxkOFl5LkpTGCbWV3ZY_nwYNs sF938URaI9RfkL0wxp.utse8NWEheA0U8fmnjXB2daiAsIqt4_72f8Xfe1vzr9oU4IWsOgueAjCZ KeEj.IsHE4QkRGUDCdflyd9NQbBAcfNM7spJaN301otDiu7rxwGUtH1RrOobgEXTC1HajkPaBPNZ bpjvDWO0SxQ1HDyArqPKdELFYEqJK74qkrlBo.HCifBQP9r3WaSFPevbD3acM0mt7oS3fdwWxZL7 W4y_fC7pNY3abF3z1260Kkdp9O_ZAebcnvM2IOQGSjh_U_bvKscoW3Dq0WPTXNaXepfsl4402RYm juFTDUfLaLKWB3AxEr2CmqvqLLVYrQX7D1lc5IW2q8Kk8AuxGg.Br0cQm48goOhcG7l9T5psZmx2 qDc3aIQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Mon, 26 Sep 2022 19:44:19 +0000 Received: by hermes--production-bf1-759bcdd488-hrxt2 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 43f5bc15294caab6aff254f9548d36f7; Mon, 26 Sep 2022 19:44:15 +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: <20220926170913.GA68300@www.zefox.net> Date: Mon, 26 Sep 2022 12:44:12 -0700 Cc: FreeBSD Mailing List , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <39AAE1A4-8065-49EE-9DD2-C6C6736E3D8F@yahoo.com> References: <20220921175026.GA45144@www.zefox.net> <5DB9C93B-B9E1-418D-ABA3-8A0CFCE85C0F@yahoo.com> <3781CF46-C4F7-4579-8655-B7558B724C0A@yahoo.com> <20220922014500.GA46697@www.zefox.net> <20220925160531.GA63213@www.zefox.net> <20220925193415.GA63733@www.zefox.net> <0C5BA8D9-0EEB-421A-99E7-2E6F10D5D425@yahoo.com> <20220926010420.GA64437@www.zefox.net> <20220926170913.GA68300@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Rspamd-Queue-Id: 4MbtVt0J7wz3dt1 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=OwVC9yVm; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.988]; 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]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; 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.206:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.206:from] X-ThisMailContainsUnwantedMimeParts: N On 2022-Sep-26, at 10:09, bob prohaska wrote: > On Sun, Sep 25, 2022 at 09:47:55PM -0700, Mark Millard wrote: >>=20 >> I'll note that: >>=20 >> https://github.com/u-boot/u-boot/blob/master/include/configs/rpi.h >>=20 >> shows it #defines some other CONFIG_... names, including >> the one that my existing patch adjusts ( CONFIG_EXTRA_ENV_SETTINGS ). >> This is at least suggestive. But it may be some other .h file >> would have to be used instead. >>=20 > Looking at > = root@pelorus:/usr/ports/sysutils/u-boot-rpi-arm64/work/u-boot-2022.04/conf= igs # more rpi_arm64_defconfig >=20 > CONFIG_ARM=3Dy > CONFIG_ARCH_BCM283X=3Dy > CONFIG_SYS_TEXT_BASE=3D0x00080000 > CONFIG_SYS_MALLOC_F_LEN=3D0x2000 > CONFIG_TARGET_RPI_ARM64=3Dy > CONFIG_ENV_SIZE=3D0x4000 > CONFIG_DEFAULT_DEVICE_TREE=3D"bcm2711-rpi-4-b" > .... >=20 > the entries in the file look to be of the right format, although it > it's a .h file. Adding a few lines looks like an easy experiment,=20 > even if it's not the "correct" way. =20 Remember that, overall, I'm not familiar with building or developing U-Boot. Looking around it seems that there is a file: https://github.com/ARM-software/u-boot/blob/master/Kconfig that includes other files, such as: https://github.com/ARM-software/u-boot/blob/master/common/Kconfig that contains descriptions of things like the below under its 'menu "Logging"' section (not directly #define names here: CONFIG_ would be prefixed to the name on the right): config LOGLEVEL config LOG config SPL_LOG config LOG_MAX_LEVEL config SPL_LOG_MAX_LEVEL config LOG_CONSOLE config LOG_SPL_CONSOLE It looks like this is used as part of seting up what to allow to be controlled via the likes of: # make menuconfig in a normal U-Boot context (which ports is not). rpi_arm64_defconfig looks like it might be a result of use of that. So, specifically for the symbols: CONFIG_LOGLEVEL CONFIG_LOG CONFIG_SPL_LOG CONFIG_LOG_MAX_LEVEL CONFIG_SPL_LOG_MAX_LEVEL CONFIG_LOG_CONSOLE CONFIG_LOG_SPL_CONSOLE you are likely right about where the definitions go. But it seems likely that only things described in some used Kconfig file ( such as common/Kconfig ) would go in rpi_arm64_defconfig . So other symbols I(if any) likely go elsewhere. >>=20 >> Going in a different direction: Having the RPi* firmware and >> U-Boot load from a microsd card but the EFI material from >> the USB media likely would do you no good. U-Boot would still >> have to get the USB media working for its activity in order >> for U-Boot to find and load the EFI material that is on the >> USB media. It is the same problem again. >>=20 >=20 > U-boot seems biased toward booting a microSD, which works very well. So you blame U-Boot instead of your drive/bridge combination. I've no clue what the detailed issue is that leads to the mismatch. > Given that the FreeBSD kernel seems to have no trouble with the > disk, might it make sense to boot a small FreeBSD system from a > microSD and then run some sort of single-user script to find=20 > and re-boot from the USB device? All the machinery of the kernel > and system would be available to gather system information for > the (re)-boot step. I originally thought that's how it would be done.=20= > However, I'm no programmer. As you've doubtless noticed 8-) >=20 > It's roundabout, but u-boot seems to be a fairly black box. =20 > Great when it works, inscrutable when it doesn't.=20 The kernel and world do not have to be on the same media but splitting them makes for a non-standard updating sequence to be needed. Somewhat more than the kernel must have copies/variants on the same media as the kernel because a couple (or so) files are accessed so early. I do this on the Rock64 in order to allow world to run from the USB3 port. (Its U-Boot did not know how to deal with that USB3 port last I checked. But the FreebBSD kernel does.) So the kernel used is not on the USB3 media but the world's materials are. Going this sort of route of not getting the kernel from the USB drive, you would need to figure out how you want to do updates to the kernel and world. Some things may need copies in both places. The EFI material would go on the same media as the kernel but in a msdosfs file system with the proper path in that file system. > [snipped] >>=20 >> The above does not have FreeBSD present and has made the EFI >> material on the microsd card be not-found (via using the >> efi_disabled directory name instead). This leads U-Boot to >> find the EFI material on the USB media instead --where it >> has the normal path related names. >>=20 >=20 > Can you explain a little more how renaming /boot/efi to=20 > /boot/efi_disabled works? That is not what I did. (Warning: In my environment I use lower case names in places where FreeBSD by default uses upper case. The below shows upper case. This makes clearer just which thing is being referenced. My use of lower case was not a good idea.) /boot/efi is in the UFS (or ZFS) file system and is a mount point. The thing mounted to/in it is the msdosfs file system. That file system contains the likes of a path: EFI/BOOT/bootaa64.efi (which is the path that U-Boot looks for to find the EFI material). Having the msdosfs file system mounted at /boot/efi leads to the path: /boot/efi/EFI/BOOT/bootaa64.efi (starting from a UFS/ZFS context and reaching into msdosfs). Note that in U-Boot /boot/efi is not involved: FreeBSD has not even been started that that point and there is no active UFS/ZFS file system yet. So no /boot/efi is active. U-Boot directly deals with the msdosfs itself. What I did do was to change (on the msdosfs): EFI/BOOT/bootaa64.efi to the likes of: EFI_disabled/BOOT/bootaa64.efi This prevents U-Boot from finding/using that copy of the EFI material --so U-Boot looks elsewhere until it finds an example of: EFI/BOOT/bootaa64.efi if it manages to find such. That EFI in turn finds FreeBSD's kernel in other partitions on the same media as that EFI (at least by default). So I have an msdosfs partition on the same media as the kernel and that msdosfs contains a proper file with the path: EFI/BOOT/bootaa64.efi > If that forces u-boot on the=20 > microSD card to search for usb devices again it might do=20 > the trick for me. Or, do I misunderstand your intent? The point of the note was that it would liklely *not* do the trick. In your problem context you have to avoid U-Boot trying to use the USB drive at all or the problem likely would just repeat. The problem is not where U-Boot is loaded from. The problem is U-Boot and your USB drive configuration do not work together overall when U-Boot tries to get the USB drive set up for U-Boot's use. Avoiding U-Boot trying to use the USB drive at all would avoid hitting the mismatch consequences. =3D=3D=3D Mark Millard marklmi at yahoo.com