From nobody Fri Oct 29 22:10: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 7648F183A468 for ; Fri, 29 Oct 2021 22:11:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205]) (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 4HgxTN1FV2z3Hvy for ; Fri, 29 Oct 2021 22:11:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1635545455; bh=8JBMhqnrMyhdcyX9KhBvAcIhYV5mQJFuDT4MBgsnjOI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=oYmjbuOkMt63IPdQA25zRUca6TteVEYyxi9PA8edQJS93ggizVUec/Q4CrKUQ2iQMk2xsd2HzhLJ3BD3RoUaXPth78mrbo1mE68QxMu32txAzxMhgwcyjwyWzxQBqFFPu0tU+ta2m0ApJ83pXlz2861ZQDMaJme8lCgLJIxyE+FsNLYU5lNmVAND5lmQrrGCheD/hqy5dn6hIPbyMLP2uQeevbMLUy3wv6PyGUG+buvdI4DHugAV1jRfR7pJz318g/0uJi5sYzDrIs4utHjQByAb2vXmFM/S7cHuZmliJG7qcPUPoDMX5PvPEJLYs44rlm3JaXMapj7A8VlDotMCjA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1635545455; bh=FJ6LUofWFUxbhiKz03JwE41OVETEtDGVvwo2f2Ww42i=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ACi901V7AgLCwNXKVoqLot4n4vH1pSAIIomgY134YFm3wAE2m0s+GyMh/8YKYk5kAqfU8xbrVqKn8AIn6PWC37XZ/idoCXFuwB+/RRuwyLZIvfDvVaoIiO12JTRPke7iAoyAg295OZaRvDLcljuRCYadVZOLR1iTW9UmY6ZT5c3+HVzBCKnTAQM3/91uH4XIPhw+tDeo9R9BpXhQbZ7Pk4Ld2fCCwJe75MUgHs9f88I+Oj2HjIkzKT3ov1QNjP1ykx/gWb5hYhNNPh3goe610blYw3j9oCNBKyZ0MOLD7kIhus3zXhhhl8yWVTCrAb4JXhhSxgnWrZFN5l7Hsh6+rg== X-YMail-OSG: 4NQhUFQVM1mE.uWkidzE2p9gx68njUvAvlJYp9kUqcHQKTRz2HwGqaM.qgUDsqA F.QBmfTN4cMqw08t3m8d41qtuEn6xJ.xlfH_x.XsQGi2LeZzoEC6uY1qaGu.74AdSAF1jUYjxGmT HU.bMCjKTvy0HLqkod3Em0cImxNasX4i90sVScElgzcPcdr2ccm01e1ScB5WBM1AicCCLeOQOQja Btw7JfCQd860R5PvJiAZhNssgrvluEsfmJO1dWkX1WqkQY5b8Dj6ZsKtSJfyHq5wIHPo3fPWc733 JqTU47sgIy46SB2nhfZci2WF75ZC1i5eWnB6iYB20f.g7W0wU3QPBmNn2Z_DMQKEr5e8YJAKeTyB sskAZOFp0j3cVV2sNFuuKpw4cyx.wOWczJfcOejdkl7z.l.VRD5SP2tKe_63Shzc6IKGY7yBcoRu .pM1ilh2GaDPCXFFeb5lqPBQPBUK34y_TWTBMuVlf98bkcDAhMaeJut50mqLk48FlAMKP5pWC2Dt jfP3ok06IgilYcoGIe_BjtOH51mjUbZfleIcPjwRKMy.NQS1ZYMYlZG8eqFcxX_ltlgN8_UmerB8 0HUhrCb5Cn2A8E9jUXmbAv_Yaq4QOtZGnu4b2lRLmUUC1ExdDanIomDz8lE58Y.q543ZRlkUW6D7 XfCeqhpwBk8Eni4Whgul.2M4AI9W8bU_GQgpWHWm_rk1vetlQ_vyJMgndUJofsNCZLHdlaxgQqSS F5UrL3G0OvKMTwqNLT98LfC7heb5TehJcSgtpwEy0n6YKBeLBC3J.Xfhn3YphCFib58XXd5anraC 64sFgfKX4RfRVW9ieJ9gEsHywRF70xvNl5qNW9nnzR6vasFrb.QpdiexxUyies961jiUTbqcjD08 Id5ETs.CdtR_hK4mBoHBFDzZvUDEGl0bmqtvw4n6SZcD5eALtEPHTfwtLSc4KfRldbRatTjBR1e6 QTtAdfiKg2O9gwDR2mpOOMsK1TV8bx0BSsrCt.4JSL7xsDSulCvk5O4.i1b4V8XSyzHPXrMM3mF8 _78md9NpptAQHFq_FBtBu8LqR_ii0ZH6myBe8iHBk5yQdpxOEreuZaaYEYXjXmu1qyMOHhTnnXmf yyf9ns7sBEp1LGWgFuSUUs07fJ23xttgbAIn7SBaRFpQZyTXMP78Kuglpc35IfWgImw0rdnqr8l. lAcl9.t7j15TT_X1g35zCqpsRfgsX0bE8VSipiiteOwgNERaGvWayGXhlKVrx8iFGVhhk.Q45b0_ CuKcWnny_Rnf27VrPE_rP0yqTPoWnD0sZ_YNQAi77h86QTdjjlBQxCa7_MItTRDocPXMRtE9hg26 Tjoqsr.qs5j6FwIntoZm9sn9ovYs96U7UBPDW7G0vdC.RPP.iABvE6Qf.rUdKjY8kPDM5NOyl9V1 RRsonHiN8lvLyHXm3WtjJMWHeul5uy1Z2UYozCXus4QrN3erzEjNCuvUxinR3x7Q3VOeK2c5CuZK rt7wmozJ5rsPJP6av5esbkXYQdiA8bITIKNcRx2Hqc8uajqhPBiBk2F33qvhYhv.dp4F.1E53usd pao1vI9Wso5ikKqk1xpnTJ1fUOODOx69MpNtiwXMorxD3vX_80gwxT8aKr0CW13gEcsmLrZZ_6V6 DjZz4OnmypqXLO3lCT6CI70f9kh7EABoDzy.PMPlNfDEUe74vL0tOd7cKytyjd8WMp1XwYK3clNp nDPQT1LZk.UpDwBZjBBNsT4QgUiE8EiHbUJrUxFH8rb24Kf_XS5cEv0l0L52LENIkEwhSJmHG5uP nAA7LzH_6cPpgckaB_DbvnZpLOnUbDYs.j8CRo2kDDYRIQDQWujugwvyQ4PupHi.uo0b2zq_4YWy TpS0h4xoFcOqY1vQpQ2R3EdTy9JaVnSSG2FseoVQ4xpHPLO911KBno9lysrUjbcegrpkuAdKZgm5 h_gDrHjVzIU8OtGinzkMLGjqViY8wkMNmr_oX5MerSxjzUrrHhEaXn_LymoyZi4q4GW8CU6LdaqN UQP475zHs.RAVk20II1TPPWDDcIKHgWL64egSJ9hT3Fw4Q4nbwbDB5IysuzHIFjHkJmUStgqVXw2 JetVDac1u2ZsMgbYM1g3st0b3aWYVnWgiYffEJW2XTmnGNuf.z7.Bua0fwrrCgTkenOhOd3OzHzm uuIk4kl4RT7y6wbP.vDIcTorKrbb7LxM_WXM09tHlUL0oj0uGTpwv2ldB1_D3gSVwcpceUCbf4yj kUdiUT7hWYutowEOIsLl4BUy1tNc1vapg_hqq3xRHLvGo X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Fri, 29 Oct 2021 22:10:55 +0000 Received: by kubenode524.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 0269600edd4ce45723e37e9a7ca5183a; Fri, 29 Oct 2021 22:10:49 +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: Troubles booting Pi2 from USB using bootcode.bin method In-Reply-To: <20211029182430.GA22414@www.zefox.net> Date: Fri, 29 Oct 2021 15:10:46 -0700 Cc: Free BSD , freebsd-ports@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: References: <20211025034332.GA8398@www.zefox.net> <20211027162852.GA16010@www.zefox.net> <41C0A656-D898-4381-BB81-034D54CA04A0@yahoo.com> <02806205-6685-41FD-B2D1-415C82FBCF92@yahoo.com> <20211028191635.GA19540@www.zefox.net> <7AC0733A-3FC9-4FA6-A6D7-0689A8ACB4CA@yahoo.com> <20211029182430.GA22414@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4HgxTN1FV2z3Hvy 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 On 2021-Oct-29, at 11:24, bob prohaska wrote: > > I should have stated earlier that the FreeBSD system on > the USB3 disk orginated from > FreeBSD-13.0-RELEASE-arm-armv7-GENERICSD.img > using dd and then repartitioning to add a swap and separate > /usr partition. > > On Thu, Oct 28, 2021 at 04:53:29PM -0700, Mark Millard wrote: >> On 2021-Oct-28, at 15:21, Mark Millard wrote: >> >>> On 2021-Oct-28, at 12:16, bob prohaska wrote: >>> >>>> To make a clean start on this thread I've turned on the UART >>>> for bootcode.bin per Mark's instructions and done a few boot >>>> attempts with the USB2 and USB3 mechanical disks, singly and >>>> in unison. >>>> >>>> The bootlogs are in >>>> http://www.zefox.net/~fbsd/rpi2/bootproblems/ >>>> >>>> An immediate curiosity is that on the first try, booting >>>> with the USB3 device alone worked. I didn't record that >>>> output, unfortunately. >>> >>> Hmm. Too bad. >>> > Indeed! I thought maybe the failure was fixed by turning on the UART... > >>>> The second attempt failed, as expected, >>>> and is recorded in bootlog-fail. The third attempt booted both >>>> USB2 and USB3 disks together, recorded in bootlog.success. >>> >>> The two logs do not have the same set of dtdebug messages >>> for loading bcm2709-rpi-2-b.dtb . This is long before >>> u-boot.bin is loaded and so is during the RPi* firmware >>> time frame not u_Boot or FreeBSD;s loader or FreeBSD's kernel >>> or FreeBSD's world. >>> >>> From this I infer that there are two different msdosfs's >>> wtith differing content on the 2 drives and when both >>> drives are in place . >>> > > That's correct. Actually there are three, counting the microSD. But later you show that start.elf and the like are missing on the microsd card. That prevents the microsd card from being involved for the stage getting the errors in the one case (other than the bootcode.bin content used). >>> You have not reported on the following for either drive's >>> msdosfs : >>> >>> # strings ???/start.elf | grep "VC_BUILD_" >>> > > The are different. On the USB3 disk, which I want to boot, I get > bob@www:/boot/msdos % strings start.elf | grep "VC_BUILD_" > VC_BUILD_ID_USER: dom > VC_BUILD_ID_TIME: 12:12:09 > VC_BUILD_ID_VARIANT: start > VC_BUILD_ID_TIME: Feb 25 2021 > VC_BUILD_ID_BRANCH: bcm2711_2 > VC_BUILD_ID_HOSTNAME: buildbot > VC_BUILD_ID_PLATFORM: raspberrypi_linux > VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean) The above matches what I use on the USB3 SSD that I use for armv7 (Cortex-A7) systems, including the RPi2 v1.1 . But I do not have access to the RPi2B v1.1 currently to test with. In my context overlays/* and the rest are from the same release as my start.elf . But that sort of thing is messier to check. > On the USB2 disk, which seems to be needed for booting, I get > oot@www:/mnt # strings start.elf | grep "VC_BUILD_" > VC_BUILD_ID_USER: dom > VC_BUILD_ID_TIME: 16:43:13 > VC_BUILD_ID_BRANCH: master > VC_BUILD_ID_VARIANT: start > VC_BUILD_ID_TIME: Nov 19 2019 > VC_BUILD_ID_HOSTNAME: buildbot > VC_BUILD_ID_PLATFORM: raspberrypi_linux > VC_BUILD_ID_VERSION: 2354eac70a98807e06bed2149bc0c5613e751c15 (clean) That is rather old. I've no clue what to expect for it. >>> Another thing of interest would be something like (both >>> msdosfs mounts): >>> >>> # diff -rq ... ... >>> >>> in order to see what files have distinctions on the >>> two media. A diff of the two config.txt files would be >>> relevant (no -q involvement). Based on the VC_BUILD_ID_* checks, it looks like a diff -rq would list a lot or most files as different, presuming all the files. > On the USB3 disk config.txt contains > bob@www:/boot/msdos % more config.txt > init_uart_clock=3000000 > enable_uart=1 > kernel=u-boot.bin > kernel7=u-boot.bin > dtoverlay=mmc > enable_uart=1 > uart_2ndstage=1 > dtdebug=1 enable_uart=1 is listed twice above. > On the USB2 disk config.txt contains > root@www:/mnt # more config.txt > init_uart_clock=3000000 > enable_uart=1 > kernel=u-boot.bin > kernel7=u-boot.bin > dtoverlay=mmc The above is missing: uart_2ndstage=1 dtdebug=1 so there likely would be less debug information for the case when this file is used. Rerunning tests with both config.txt files having those llines as well might give additional information. Swapping ports used on the powered hub for the two drives might allow controlling which drive's msdosfs file system is used. (This is not the only port position/swapping that may be useful for such, it is just an illustration.) >>>> I'm trying to build u-boot-rpi2 and will try to update the USB3 >>>> disk with it once complete. > Still working on that part 8-) The failures start before u-boot is involved. This is unlikely to be sufficient. >>>> >>>> The actual boot sequence using bootcode.bin is still a bit hazy: >>>> Is it microSD/dos -> USB/dos ->USB/freebsd ? >>>> >>> >>> Based on the log file for success the ordering is >>> >>> bootcode.bin from the microsd card > > So bootcode.bin runs from the microSD, but config.txt and all else > is picked up from whichever USB disk is recognized first? Yep: it picks one. Swapping or moving which ports are used may change which one is used when both are connected. >>> config.txt (also re-read multiple times later, not listed) >>> start.elf >>> fixup.dat >>> bcm2709-rpi-2-b.dtb >>> overlays/mmc.dtbo >>> cmdline.txt (if it exists) >>> u-boot.bin >>> efi/boot/bootarm.efi >>> efi/freebsd/loader.env >>> /boot/defaults/loader.conf >>> /boot/device.hints >>> /boot/loader.conf >>> /boot/loader.conf.local >>> /boot/boot/kernel >>> /boot/kernel/fi.lemon.ko >>> /boot/kernel/umodem.ko >>> FreeBSD world Do both USB* drives also have a bootable FreeBSD installed? >>> However the failing one has the following involved >>> (I omit various lines): >>> >>> . . . >>> Loading 'bcm2709-rpi-2-b.dtb' to 0x100 size 0x6879 >>> Unknown dtparam 'pwr_led_gpio' - ignored The above seems odd. >>> dterror: no symbols found >>> dtdebug: /__overrides__ node not found >>> Unknown dtparam 'uart0_clkrate' - ignored >>> dtdebug: Opened overlay file 'overlays/mmc.dtbo' >>> brfs: File read: /mfs/sd/overlays/mmc.dtbo >>> dterror: not a valid FDT - err -9 The above may indicate a corrupted mmc.dtbo . Or it might be problems reading the drive and so be an example of garbage-in/garbage-out. >>> . . . >>> >>> That seqeunce makes no mention of: "using platform 'bcm2835'" >>> and the like. An example is: "found override pwr_led_gpio". >>> >>> Again, all this looks like tehre are two msdosfs involved and >>> the two are not the same by content. >>> >> >> Another possibility is that you have more in the microsd card's >> msdosfs than just bootcode.bin so that that microsd card might >> be the source of alternative files. (That makes up to 3 media >> that might be sources of files.) > > That's correct. The microSD's msdos partition contains > -rwxr-xr-x 1 root wheel 52456 Oct 28 02:12 bootcode.bin > -rwxr-xr-x 1 root wheel 52456 Oct 22 16:00 bootcode.bin-e > -rwxr-xr-x 1 root wheel 52304 Nov 22 2019 bootcode.old > -rwxr-xr-x 1 root wheel 0 Jan 16 2021 timeout > drwxr-xr-x 1 root wheel 4096 Jan 16 2021 unused > > I'm expecting that only bootcode.bin and timeout are involved. For that microsd card msdosfs file system content: yep. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)