Date: Tue, 16 Mar 2021 03:23:47 -0700 From: Mark Millard <marklmi@yahoo.com> To: =?utf-8?Q?Klaus_K=C3=BCchemann?= <maciphone2@googlemail.com> Cc: freebsd-arm@freebsd.org Subject: Re: rpi4b main-n245392-8423f5d4c12 won't boot due to microsd timeout [FIXED] Message-ID: <E80FE3D8-0494-49A7-AB98-87EE80876C4B@yahoo.com> In-Reply-To: <0281510F-3FDF-4500-AD98-D20A2150BD91@googlemail.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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Mar-15, at 23:26, Klaus K=C3=BCchemann <maciphone2 at =
googlemail.com> wrote:
> 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.
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:
# 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}}
Note the:
UBOOT_VERSION?=3D 2020.10
which makes 2020.10 just a default that a slave
ports can override.
> masterdir-upgrades usually come relatively slow in FreeBSD, sometimes =
weeks after the upstream.
Possibly because folks have not been putting
up reviews to get a committer to apply an
update that they have tested first.
> 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
It is true that someone likely has to build
and test before committal by a committer
(and you have in the example at hand).
> That=E2=80=99s why I upload them sometimes to somewhere for some =
reason(testing, patches, whatever).
So there has been more than personal testing
by you.
> 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 :-)
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.)
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.
> =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.
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.
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E80FE3D8-0494-49A7-AB98-87EE80876C4B>