From nobody Sat Oct 30 08:41:52 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 A19E1181FB3D for ; Sat, 30 Oct 2021 08:42:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-23.consmr.mail.gq1.yahoo.com (sonic311-23.consmr.mail.gq1.yahoo.com [98.137.65.204]) (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 4HhCTV1KD2z3NjB for ; Sat, 30 Oct 2021 08:42:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1635583318; bh=fzS+vulf4lUb61i6qvn21Kq3qehy7nMJo7/pVSTViu0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=WDMuwqPge7z2tM3w3KJcBTRhX9Lwtf+QupJsG/w30qunpbSc8QefUhohr5KndjSuMpY9pb17qzOvP0+w/O/upa/VAGsQdue3yp8q/2+mKkRoRGgb3tA6TvqedUcNZR4HOM8udtx2x67uhiXqwcnee/95YyFY3KUK1yfUMOqSvoKXLScF+s3+Emrnpggf4MR0eulJAcHzOAkmI4508nawKReHqJzWYIH8LMfjRKw52sYw36T53UDFWqiL6MkYLCYUIV4Tvu/XXrxfPAvzD4JE1/sSLOINfQ11Og5tZwxKWsopvR4B5fuwwaNp2mySXDgo1KmkVxBXaXcdEMgHR6Lrwg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1635583318; bh=1B8JAlyg2J+UfAOBaEkOqwOaq40HYZinShPMfnsQuoT=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=n4agg5q6RSwiwwdXF4SCB8p+r1egNiVzln5amtMIAG1O3kXCCPRKCZoogevkmcQC5UmxxUG7W+tE5ZkJDVgYvYs5iCXSj77lLYxsVdJTn8H9PYEcAn/4ntnQ5LL+uOQtisH6yL0YcibK7v8fUUNraQovheAkyy377dUbeiIyufAL0j+81fd7X2/ZSZlKbwVY6M6lEP9Qocs3Ej1Ucw+42wWd6d4D0IK2UdTjJFBD25CW1fuBeZG9uo6rE9lWSfUtDiG4026s7fNjWBIEYWIo+0nUW9ipUxPAdr5NmUV6iDhOzAQkx0Qr4xkOkxcDtcwWLYj0ltd1CDzjTXz9lgKNSw== X-YMail-OSG: Za5jRrEVM1n77VB.iF2d2pzxkU9.7vuiOc2xhxFgc8Dw0gN0EW1r_2gzZRTifLa tZL8g8mdnXa7HiqK2kLb1kkAbANYnrairMaW1o4YKcPGojvGPFb1X2wLKwezJzxo8OtKWHhS9PVQ VoI0faJV7LxoH.RBylomqSM_Ht8xf9kxvxkihf8lcB1HHuA9CyksvFZ6uEA3x2SZrOtC6J4Jmi1z djXoyXZ.NFAC3j9oaH7xOiVSVHkJBFbsGDSiHCfLVAFxIwwjNaccaKKokRzEUKCAHHhUWHQEaRas 4ugIDrvU13yEfi1S7UUwgtyKH9ZyzKcFBtBALp_zcBWbeL2OBnC1RSD89viFze3mWxtSrRz58Y.C krKlL2m4joy2Om9U7dUygFw9RKHAGFKBPsUQCILDv5taPZuxFp1SNiHi6JKIpAHUmCnc.griCOhZ ABqHWcdOLXCIQ6xPkFfAqceTh6mziUNZr3kdnWSA98L7JPxRg9gX1MdJK_PGpZszQh84bxEzFXyW MsgHXBaXXkbnNJQJjC3EukGmzQ6CuuBUTHd8sWkw32HArTBa_wlAs_N2gMxEw2yVYh905OmGgthy 9v4jnFTnulc6n7Tss_sg6KiS1msbIv.dl_0rtWbqv1vXzw.XHEJk_ayfz_3XYD_52TypI7_CSC5q DZsMk0eUmYOQQ1uUFnqM5AAn7h1EbDeuNrqXQPy9LoCxc1mznre5F2M.BTlsqDsPoerUwlnMlvC5 eBcUIc.RyZioONNfwtj2ICZ28czaZg11KTu3Iy43jR.H1reAtL7CSMKurwq5PE5PeZqTqrUSt3nj uiiy21K80G1ZyRaQQ6MezL4zsVgsw36J4GtDXTEerCEp_f_ShdUhByfNqL3OngpbNVAb9zRDtqLp eA9Gj3wl8Nb6LMMqxsz2jUPVhZtBdaTRIA_0YgnxtPFYknstWYfRHn10Rst0uS6l0C.aJYvMpGK1 oCwNgdk7Z4wQxk6Aza69fL0iQKuPcm0BJbGVudZuF5w.cyI.D.kNDS8ot0ux0VxwyCrl7YfEEaJm rza0ItwrYBLVjlNqX2.zEunjsWEZLQfy6Q5T1cxEIYkbfH7atxUdUFzsBBJU1iPIX1uh0t2M_20_ .t3uXgXVdqd2ajLZ9atGjdbabMOO0xezxjfRpAmfiFwGAwsHE_cFVqwhEJCARED6MDgpXv.mdkFW FE6X4wLxoOoEwQf9m9eXTKmrnCdkNxPKCE3LNJdSGykr5pOqcnp3yvCo2RvGD_a13J8U9HTlgbxr .wdi_oY6w_5k4ELvSdwrgKl2TuPUFjzyMYervQ13PwsMvHHin_36CSfN38VZESJJEYz4Dd3LgPwp N0hdFXyDBC1YXWs_uLARYC5nZ1nBdmrB20_ECki3LyX5GgtO4twh7Blj0oIu8U.Q8UVx6zK0_iKR 5nfD4Pg4pEmEzUC_r3q2KYDoVotPXbktFQE1FzR5xkgOh.dKvkEWlSXaBTTDj2fs0EXS3VjdlWsn CoAk8G12sObM0_g9brOXvG5be6nZ20YTTz6QBjT1UsDDKcAxk_55eJea2K99DHEGSnQiS8.PJvXN D3FKss0.I1DDxstdQtK9_xFE4get5G_9O2IYLegrnxjBx9joPQW5sruxFPME2GnUTx3O8T_Wijk8 YB53IxRJmhyfU9X3_fiHDam9DR_X9qjymYLXRVnfBEIO8v.jAW3kvF9GtCt.IACPBrIdcnt9kyn8 xzQVAm4S_YJlXXWy.B0brCbDa83AFaow1_zZNssgR0BcXOB2hAZ5RUSnV29sE_wXj_lniTjNWBBY BMp23p4L_wA4WPHtDSNlpHzUitmyfx5XAMmJ2miVsnesRTZkuLx7FEDY99gngWu5RXwPlzEpGQ7c JBO0zUzXMD5cVs_g.iNHPDPeltV0pyEUXDW5.Tgk1bFlR6qiaJ24.fxJR9XxqvE7Ru3WvJz_GM55 IB5T4tpOcIPhcvkpVlfiWWE_dyRjnPVu.LbtYxoJD4cQaJUcJNyXmrqOP51gnt4pUBbU_ClQkntj opxbeYKIrTTqmkb0KeUGoSqZ2W5PG3unYzcT5_SOn.20ZeDVFkyYGs73A.btba9XMepBLd4vTnDh nbccPSYJyuSEGgqexJHpf7HjqFdISHFbPNqFLieVlmaAfyZhiBOOXI4K1kGgJ3AJycUYHvR1pAY7 8nHjeJa1T.1yqS0rIKSh.49ZQbx17xo_s_MU.rZv2UNuPpR9AYDf8IlPa_akSBGjpngaMxsHZxn5 1FSESQwDXQ_ZHo1x2luG7JtGIJkd.Hjx5j2XBzSBIqi4Eyw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sat, 30 Oct 2021 08:41:58 +0000 Received: by kubenode523.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 6e95cb51e0816499c4b95741c91ff751; Sat, 30 Oct 2021 08:41:56 +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: Date: Sat, 30 Oct 2021 01:41:52 -0700 Cc: Free BSD , freebsd-ports@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <086D6998-A96F-4560-92C5-4E2CE05FF668@yahoo.com> 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: 4HhCTV1KD2z3NjB X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=WDMuwqPg; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.20 / 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.204:from]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_FROM(0.00)[yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.204:from]; NEURAL_HAM_SHORT(-0.70)[-0.705]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; 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 2021-Oct-29, at 15:32, Mark Millard wrote: > On 2021-Oct-29, at 15:10, Mark Millard wrote: > >> 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 > > Please make the 2 config.txt files have a different number of bytes > relative to each other. This would allow us to see which USB drive > was in use from the serial console output: it reports the size > of the content of the file and then it would be unique. > > Blank lines or comment lines would be sufficient to make the > difference. > > The re-run the tests and post the results and indicate the > config.txt contents of both files. Actually, while one of your two examples do not have all the debugging output enabled, the two config.txt file contents that you list have distinct byte counts: 130 vs. 90, if I count right. Both log files report reading 130 bytes for config.txt, neither reports reading 90 (or so) characters for config.txt . Thus, it appears that both examples are for reading the same media's config.txt : the one with 130 characters (counting end-of-line related ones as well). That leaves reading the media getting inconsistent results. The timeout file is not the only control related to delaying booting some for more reliability. Default values are shown by: bootcode_delay=0 boot_delay=1 boot_delay_ms=0 See: https://www.raspberrypi.com/documentation/computers/config_txt.html Given that config.txt comes from a USB* drive, it is not as obvious how much these might help with later I/O to the USB* drive. But, for reference: bootcode_delay is for how long bootcode.bin waits before trying to load the start*.elf that would be used. (Units: seconds.) boot_delay is for show long the start8.elf waits before loading the kernel ( in this case: before loading u-boot.bin ). (Units: seconds.) boot_delay_ms adds milliseconds to boot_delay. >> 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)