Re: rpi4b main-n245392-8423f5d4c12 won't boot due to microsd timeout [FIXED]
Klaus Küchemann via freebsd-arm <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.arm |
|---|---|
| Message-ID | <[email protected]> |
> Am 16.03.2021 um 02:50 schrieb Mark Millard via freebsd-arm <[email protected]>: > > 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. _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "[email protected]"