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

[Klaus Küchemann]

> Am 16.03.2021 um 11:23 schrieb Mark Millard <marklmi at yahoo.com>:
> 
> 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.

well, of course we can override whatever we want when doing for ourselves.
But in this case it wouldn’t 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 „boot-from-SSD-killer-feature“ where I uploaded a 
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 .

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

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. 
Well, I remember that putting up reviews in this context can lead to something like  complication ,I’m sure you also remember :-) Ha Ha 

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

Well, for u-boot it’s always good to have the latest( in contrast to the firmware).

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

IIRC it’s 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 
seems to clearly mean that there’s 'official' interest to get things under control ;-)


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

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 at zyxst.net>:
> 
> 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. 
> 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. 

of course that panic really should never happen.
Having a „poisoned“ 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 
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 !
….P.S: overwriting u-boot is much less risk than overwriting firmware-files !)


K.