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

Klaus Küchemann maciphone2 at googlemail.com
Tue Mar 16 06:26:12 UTC 2021



> 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.

masterdir-upgrades usually come relatively slow in FreeBSD, sometimes weeks after the upstream.
So if we want u-boot release-candidates (-rc) , faster ports-upgrades or add own features, upstream-patches: we have to compile them ourselves. 
That’s why I upload them sometimes to somewhere for some reason(testing, patches, whatever). 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 :-) ….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.

K.



More information about the freebsd-arm mailing list