From nobody Fri Oct 29 22:32:37 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 78F04181A7E6 for ; Fri, 29 Oct 2021 22:32:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (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 4HgxyR1NJ4z3Pdx for ; Fri, 29 Oct 2021 22:32:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1635546759; bh=HR4CaHYRmgU6GkXspZhFKxAv4Lrl5bqi+/MqxY0Ac54=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=oLLPENNKl0eFj6M90LdgHfbhllC7qq5al7EnOJ0MyARpsgbdllR5aLZiP4DX7QIpx7f3H1VufPvUKh5F5PQVx1gEuwm5u2HPg2Y4vU30ruNkBED/2o2jNmIJOsBwajRiL9xZSMNhz8lcG3EbfNOC7x/QOWAZgKEU+LYpYHLtRTcCfJcI8FbRbl9d76XbSzk+sN3jvwriH1JpwqaQY+BUx1p0e/KD6rNYzK72/1ZUJ78jZ1q9IvZSafs3Dpz4Vt/nB1YQRKGqlwYKEAAYm+LNNIKPpT75y1x+xLTGSQCHnRhUDPUTr9YjxKDY5irWvu0J7eAjjVaHHMJPJTQlvHFP7A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1635546759; bh=iDzGAm+yP+0tvNbcrjcW4C1i2Fq+52pqw15n1MIwAbp=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=bljoG7UG/vDC+bsyDQY5qoxPvz98nDWngPS3ztVlC7q+qHlxl5NLdnrbFMbJ6VagAhOIm17sbCYqZeV6r95KheD8i5W+bJMzuRy5ntANptv+1r6qwSlfmf37d0sspzM0y/8YyxKMhvC8rPobXmCuWN3R9L4nQ1mtk5ngBQGxcS63Kcjd2zTng1aN8BBScEyHpmFGuZvztZljg+dSENoSfv3Siz6ahiFhq9i01EzYQ0K880SA36l6fHVQEC/WBclx+bxC/mDkJpUWZKIzfh3DESoAqarL7e5AvxtC84Bs4n/7Y40jCedsPQ3YPctACjRnf+eE9XLlUNTzyiad8u5uIw== X-YMail-OSG: UBeMLZ8VM1noFGZwIsyTyb5moP3BpTvICSuEKr4WgXa_.tmzDfx7f4BNOk7KCSK 72P6WmEWrkfzJROy4ajbuic64qHdJ6cYHQLs.h4_029H9G43LcPjLmHt2C6tCZKm3mYV.ARyRXQ6 2O8mcJTlTzCvyN_HkztxbuIsPs.F.c1rQUguMoVHLc9qibQmTkOTPHMWN.uqfFAoKLMGoSTJfkk5 82jSzZoPr.p2e2PNKc4GVzK.RtRiN6PjU4wqKdFDNgD4Xef3pmltg11rlW_ROricDTApFOD402pb 6fJDmkvwTKrqufQP5yqUoX8tXk_dXbcYd2GN09D4kaFGwwCcrFjZG2mrakD7yn2Udvke0L0mYDBA 2xDMdsAWuV69_yAObmBLh3n..PROnqwjGZHDguxazz8ZtF9.r12Db.HnbCSAu8O_il02FOs5HjrW 4CZ5I0xrn1_1bL6BXsoZxQNIIhDPC5zdOeSx5zYKtf2LptVw4pnQwFdMaDuNCliXfSl3O.MpmWZF 2IfpOuDxqE8BjSkIvVMcuiUW3KbhQtjoLDCPsmyLeMLbToHeUaaBiBLFMdN_6AMkyP81TscZGL9h JleDdwd5sKmte3OZ1h5HKImBcr9x7p3XScoofZH2cw6428C7uvEFTk7RIEeoxtSO2oukPi0o0M1w 32DKh51rTVVaLqC1siS0w7Z8AYrxem_B2q8Pg4uKCld7mGnQfB1.3fa1qUSPhBiKzy9z_pvUeJ6M u_YShZta5hPa_LPnE9zBeGDp9qm8GYBpY3C70XsVG8ezUoQXPGMU0T.rpYeun7Sl.m8J5wr_YAyU Gn1QJjVte1i12Y1lUnxaTLZOTrf1clMAwElAdRLQPyssQO.MIgWoHl5r6HUm5ZOSgkyXBcuEZwRm mt_8.abGecdEvViaspOXNIyK6h7OWarLwGZENk8wMjVB9lpbaHEzGu11KqCFw6w2qKBmm_GbCF3f MOpDi9RtGJpobCqVUP4df06RlhvtEV_NiFxEl88j1CaLGdXo42dhlvBAGFVFyLpmYTaUznkb_0H. gwGs1AA9kDKG_.Q4ZrOMRtscUZvvVIsNv2.SfahadckBM0IdwmDiJwpSAZbv2kC3SmC626xmpBHZ 5UKTtg3_XTVzChSvcHXtyNfAEiBhkS2PbzFyvs_gbfM_e_9nrep4V4N4eGnQ7L9YCEB_FIrtswf3 qLYZ.yfLODtSUECK_vnmQbV8F3swK7UVXjQTQGvUssbiXkJzv4fyIt4GKzLHAqo4hNYkNA_hff46 cXbbANXUkbpo4VgmCt3PnsMnZDOSoShDwfqdkFw4mb7OAHffIlNuZAWCsvFIQ.OUBvdnors7X05w XdNfM_4o7_wJBxtZSP9SxYEs0LPRSyMzN.dmk8FIjzOmmhjwBTuQANFCafm2hBZvLp8mKr0Bjwrq VYYJ_3gNzUahK57CyvFbqFhwE.V9gG4QIm0BhHq7dglFsoqKWbiwhAntW6hanODjjKz.u56deuT6 BEUWYZXBFQsiKNFw2nS91TGE_4TcrzG1vrzFLtIZQ4f7LnoM4333.ij5RmiB.a1ygPRdmwJyr5nB J0mbfgq.scHhiJL17GmTTNfXiGr8Yr6SOFY9Is9Di0XvwkY0SvFOQxYvutbvJf8F3F5GD_RNBs58 SIHpaNdbC0OzHAu1QuBJwFCHrP9yWdoK6YaXemFMYtjJlF.s6G7trsyaKAywtJD56dOpiCfObPAO 4.aEkC6rv9jwNM3seGtUXr2sgxR6Wd79AfmE6oCH1NdGaorZNVP4e_K_oL4KFWMEGZw33NEAnCgb A1ECyaUPTPIOhh68f4HIrLcc1lAMhb.xrcy7NZVD5WkUTljv48gW4sOb1hOBNiBvNa16ANiwzX0B rghsunYTQTPaFBT1qcPBd5SIpBho9mgPy_s7u1NtvOlnxG8WUl.BYZ0XnWqU3Mk4Q_XHyli1qJZ4 mCdU7Dj1_V55vuGhV0PrVqutlG5uuVKCWe0ikuq4Zr3qGDKutiDdo.u_NjBDbgcV5WXIg7Kb0X3f 5cCk.7zNldZ7XlfSVSy6ryiiK8jkFv8Vlskevdys9ha0JtVWXWC3dm31I8S.ci1S7_SFsnH3pELI ZHqblTDwL4VcTNViEuXtnHHJOT_Iu0FruJZn3iN0Gkniv1ZLmjvdeWy8sZgS8T0hJ4wSdaQxAhVs EzQ7oIpi8Ak4VjByhKRtjQ9ZKYkeahdZ1BS_JE9u_W8TFyaAdve3V17mmlL.2iVVdb3jLw2GZ2Eb JAc0CQbaEUUDPI.V5T_FFqaolyWsaLWaShNFUAhYwjaafc_ps9la9.bn3EvMDJ86tyLiHslWI90H ngbTbHl5qcvhMLWvpOr3Q4_M- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Fri, 29 Oct 2021 22:32:39 +0000 Received: by kubenode540.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID fb10bbe60ed42ccc8262d81587529ff3; Fri, 29 Oct 2021 22:32:38 +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: Fri, 29 Oct 2021 15:32:37 -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: 4HgxyR1NJ4z3Pdx X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=oLLPENNK; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 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.31:from]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; 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.31:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; 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: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. > > 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)