From nobody Sat Oct 30 08:41:52 2021
X-Original-To: freebsd-ports@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 A1A10181FADA
for <freebsd-ports@mlmmj.nyi.freebsd.org>; 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 4HhCTV1DXsz3NdX
for <freebsd-ports@freebsd.org>; 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: <marklmi@yahoo.com>
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 software to FreeBSD <freebsd-ports.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-ports
List-Help: <mailto:ports+help@freebsd.org>
List-Post: <mailto:ports@freebsd.org>
List-Subscribe: <mailto:ports+subscribe@freebsd.org>
List-Unsubscribe: <mailto:ports+unsubscribe@freebsd.org>
Sender: owner-freebsd-ports@freebsd.org
X-BeenThere: freebsd-ports@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: <B723533A-A8DD-4F20-A3F0-BAE4D675A304@yahoo.com>
Date: Sat, 30 Oct 2021 01:41:52 -0700
Cc: Free BSD <freebsd-arm@freebsd.org>,
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>
<F54AB76B-83AE-40BD-B035-F35C7B898357@yahoo.com>
<41C0A656-D898-4381-BB81-034D54CA04A0@yahoo.com>
<02806205-6685-41FD-B2D1-415C82FBCF92@yahoo.com>
<C99139A0-09A9-4A5E-AB53-719E07C16A22@yahoo.com>
<20211028191635.GA19540@www.zefox.net>
<7AC0733A-3FC9-4FA6-A6D7-0689A8ACB4CA@yahoo.com>
<D8DC329F-DFE4-4542-AA4D-87C41A50C8A4@yahoo.com>
<20211029182430.GA22414@www.zefox.net>
<F1FDAFBC-5CC7-41D0-BC62-9B7AFBC037DD@yahoo.com>
<B723533A-A8DD-4F20-A3F0-BAE4D675A304@yahoo.com>
To: bob prohaska <fbsd@www.zefox.net>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Rspamd-Queue-Id: 4HhCTV1DXsz3NdX
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 <freebsd-arm@freebsd.org>
X-Original-From: Mark Millard <marklmi@yahoo.com>
X-ThisMailContainsUnwantedMimeParts: N
On 2021-Oct-29, at 15:32, Mark Millard <marklmi@yahoo.com> wrote:
> On 2021-Oct-29, at 15:10, Mark Millard <marklmi@yahoo.com> wrote:
>
>> On 2021-Oct-29, at 11:24, bob prohaska <fbsd@www.zefox.net> 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 <marklmi at yahoo.com> wrote:
>>>>
>>>>> On 2021-Oct-28, at 12:16, bob prohaska <fbsd@www.zefox.net> 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)