Date: Tue, 16 Mar 2021 18:16:58 +0100 From: =?utf-8?Q?Klaus_K=C3=BCchemann?= <maciphone2@googlemail.com> To: Mark Millard <marklmi@yahoo.com>, freebsd-arm@freebsd.org, tech-lists <tech-lists@zyxst.net> Subject: Re: rpi4b main-n245392-8423f5d4c12 won't boot due to microsd timeout [FIXED] Message-ID: <4DF0F59D-20A8-4E80-8AA6-76A85C8BDC38@googlemail.com> In-Reply-To: <E80FE3D8-0494-49A7-AB98-87EE80876C4B@yahoo.com> References: <A2A5B0EA-3BEA-4721-9E65-83D4FBF56724.ref@yahoo.com> <A2A5B0EA-3BEA-4721-9E65-83D4FBF56724@yahoo.com> <YE%2BY4HsI5KxfTLxG@ceres.zyxst.net> <79EB88DA-0144-4A12-B716-3CF5011F16C4@yahoo.com> <0281510F-3FDF-4500-AD98-D20A2150BD91@googlemail.com> <E80FE3D8-0494-49A7-AB98-87EE80876C4B@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Am 16.03.2021 um 11:23 schrieb Mark Millard <marklmi@yahoo.com>:
>=20
> On 2021-Mar-15, at 23:26, Klaus K=C3=BCchemann <maciphone2 at =
googlemail.com> wrote:
>=20
>> Am 16.03.2021 um 02:50 schrieb Mark Millard via freebsd-arm =
<freebsd-arm@freebsd.org>:
>>>=20
>>> So there would seem to be no urgent aspect of
>>> existing RPi[34] u-boot ports vs. Klaus K.'s
>>> build(s) to lead Klaus to put up reviews on
>>> Phabricator for updates to:
>>>=20
>>> sysutils/u-boot-rpi-arm64
>>> sysutils/u-boot-rpi3
>>> sysutils/u-boot-rpi4
>>=20
>> Well, while it would be possible to suggest (pre-)-patches e.g. in =
sysutils/u-boot-rpi4 for review, if necessary ...
>> it=E2=80=99s not possible to upgrade u-boot-release-versions only for =
the RPI in its single-ports,
>> because there is a single =E2=80=9AMasterdir`- u-boot which will =
upgrade all u-boot-single-ports in the ports-tree.
>=20
> As I understand some of the sysutils/u-boot-master/Makefile
> notation, there is a hook for slave ports to specify a
> UBOOT_VERSION different from 2020.10 without changing
> other u-boot ports:
>=20
> # grep UBOOT_VERSION /usr/ports/sysutils/u-boot*/Makefile
> /usr/ports/sysutils/u-boot-master/Makefile:PORTVERSION=3D =
${UBOOT_VERSION}
> /usr/ports/sysutils/u-boot-master/Makefile:.if !defined(UBOOT_VERSION) =
&& defined(UBOOT_VERSION_${FAMILY:tu})
> =
/usr/ports/sysutils/u-boot-master/Makefile:UBOOT_VERSION=3D${UBOOT_VERSION=
_${FAMILY:tu}}
> /usr/ports/sysutils/u-boot-master/Makefile:UBOOT_VERSION?=3D 2020.10
> /usr/ports/sysutils/u-boot-master/Makefile:.if =
defined(U_BOOT_SLAVE_PORTREVISION_${UBOOT_VERSION})
> /usr/ports/sysutils/u-boot-master/Makefile:PORTREVISION=3D =
${U_BOOT_SLAVE_PORTREVISION_${UBOOT_VERSION}}
>=20
> Note the:
>=20
> UBOOT_VERSION?=3D 2020.10
>=20
> which makes 2020.10 just a default that a slave
> ports can override.
well, of course we can override whatever we want when doing for =
ourselves.
But in this case it wouldn=E2=80=99t even make sense only for myself as =
1 person,
because I have 4 or 5 totally different compile -targets.
Of course, this only applies in principle, because exceptions confirm =
the rule.
1 popular exception was the =E2=80=9Eboot-from-SSD-killer-feature=E2=80=9C=
where I uploaded a=20
U-boot-rc somewhere together with a dts-patch before that patches made =
it upstream somewhere.
So FreeBSD was able to boot off xhci even before some tux-distros .
>=20
>> masterdir-upgrades usually come relatively slow in FreeBSD, sometimes =
weeks after the upstream.
>=20
> Possibly because folks have not been putting
> up reviews to get a committer to apply an
> update that they have tested first.
Well, when understanding u-boot- releases(not rc) as an needed =
upstream-source ,
I don`t think that there would be any technical objection doing =
u-boot-upgrades nearly "the same day" as the upstream does.=20
Well, I remember that putting up reviews in this context can lead to =
something like complication ,I=E2=80=99m sure you also remember :-) Ha =
Ha=20
>=20
>> So if we want u-boot release-candidates (-rc) , faster ports-upgrades =
or add own features, upstream-patches: we have to compile them =
ourselves.=20
>=20
> It is true that someone likely has to build
> and test before committal by a committer
> (and you have in the example at hand).
>=20
>> That=E2=80=99s why I upload them sometimes to somewhere for some =
reason(testing, patches, whatever).
>=20
> So there has been more than personal testing
> by you.
Well, for u-boot it=E2=80=99s always good to have the latest( in =
contrast to the firmware).
>=20
>> Fortunately u-boot is not as much error-prone as the firmware so =
uploads of u-boot - rc can be more seen as feature.
>>=20
>> As an example it would be possible to apply patches to :
>>> sysutils/u-boot-rpi-arm64
>>> sysutils/u-boot-rpi3
>>> sysutils/u-boot-rpi4
>> But the maintainers then always have look if patches made it =
upstream and then remove/change=20
>> them again for every single port with the next release=E2=80=A6 =
understandable why they would not like that :-)
>=20
> Not true for those 3 ports, at least as worded: those 3
> ports have no maintainer now. (A committer might impose
> requirements to be willing to commit but their judgments
> might not exactly match what they would make as a
> maintainer.)
>=20
> And, again, there seem to be hooks in the infrastructure
> to support having something other than 2020.10 for some
> u-boot ports but not others. This suggests that using
> newer is not, of itself, out of bounds.
>=20
IIRC it=E2=80=99s the firmware-port which is out of maintenance, not =
u-boot ??
But seeing Mike`s name mentioned in the sysutils/u-boot-rpi-arm64 - port=20=
seems to clearly mean that there=E2=80=99s 'official' interest to get =
things under control ;-)
>> =E2=80=A6.while on the other hand it=E2=80=99s not so uncommon to =
apply patches before they make it upstream in u-boot.
>> So self-compiling makes life a bit easier.
>=20
> Note that I've no clue if you had to do patching
> of something that could possibly go upstream or
> not. The above could apply either way.
I did nothing special with u-boot2021-04-rc3 (except unimportant =
'ums'-feature),
In this case I was more interested in having the latest =
upstream-patches(not only for the rpi).
> Am 16.03.2021 um 17:44 schrieb tech-lists <tech-lists@zyxst.net>:
>=20
> If my usb3 disk is plugged in after it boots, the pi will panic. If I =
reboot replacing just the u-boot with Klaus's u-boot, I get the same =
result.=20
> If I replace all 3 files with the latest versions as described in the
> URLs, (again generic kernel so with debug on main/14), it will still =
panic when usb is plugged in.=20
of course that panic really should never happen.
Having a =E2=80=9Epoisoned=E2=80=9C mix of firmware-files can lead to =
that.
USB needs a clean combination of at least fixup4x.dat, start4.elf & =
bcm2711-rpi-4-b.dtb.
So you could use the git-tagged one mentioned by Mark or the complete=20
Msdos-partition(only for 4b) I had uploaded.
If your machine still panics (even after a msdos-partition - cleanup) :
please report wit dmesg(if possible),
Thank you !
=E2=80=A6.P.S: overwriting u-boot is much less risk than overwriting =
firmware-files !)
K.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DF0F59D-20A8-4E80-8AA6-76A85C8BDC38>