rpi4b main-n245392-8423f5d4c12 won't boot due to microsd timeout [FIXED]

[Mark Millard]

On 2021-Mar-15, at 23:26, Klaus Küchemann <maciphone2 at googlemail.com> wrote:

> Am 16.03.2021 um 02:50 schrieb Mark Millard via freebsd-arm <freebsd-arm at freebsd.org>:
>> 
>> 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:
>> 
>> sysutils/u-boot-rpi-arm64
>> sysutils/u-boot-rpi3
>> sysutils/u-boot-rpi4
> 
> Well, while it would be possible to suggest (pre-)-patches e.g. in sysutils/u-boot-rpi4 for review, if necessary ...
> it’s not possible to upgrade u-boot-release-versions only for the RPI in its single-ports,
> because there is a single ‚Masterdir`- 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=	${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=${UBOOT_VERSION_${FAMILY:tu}}
/usr/ports/sysutils/u-boot-master/Makefile:UBOOT_VERSION?=	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=	${U_BOOT_SLAVE_PORTREVISION_${UBOOT_VERSION}}

Note the:

UBOOT_VERSION?=	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. 

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’s 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.
> 
> 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 
> them again for every single port with the next release… 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.

> ….while on the other hand it’s 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.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)