64-bit RPi4B u-boot hangup with modern rpi firmware: some information (but investigative-toolbox limited)
Mark Millard
marklmi at yahoo.com
Wed Oct 14 21:14:24 UTC 2020
On 2020-Oct-14, at 05:22, Mark Millard <marklmi at yahoo.com> wrote:
> On 2020-Oct-14, at 01:08, Mark Millard <marklmi at yahoo.com> wrote:
>
>> On 2020-Oct-14, at 00:22, Mark Millard <marklmi at yahoo.com> wrote:
>>
>>> On 2020-Oct-13, at 23:18, Klaus Cucinauomo <maciphone2 at googlemail.com> wrote:
>>>
>>>> Am 14.10.2020 um 07:52 schrieb Mark Millard <marklmi at yahoo.com>:
>>>>>
>>>>> …...FreeBSD requires services from
>>>>> armstub8-gic.bin that are not otherwise present as things
>>>>> are (or that is my understanding).
>>>>
>>>> as of today: correct understanding
>>>>
>>>>>
>>>>> ... I'll test vintages of start4*.elf and fixup4*.dat
>>>>> pairs and see if that identifies a specific set of changes
>>>>> to them...
>
> The 2020-07-17 firmware commit activity (either place's
> copies):
>
> https://github.com/raspberrypi/firmware/commits/542aceb
> and:
> https://github.com/Hexxeh/rpi-firmware/commits/7059841
>
> appear to be the last firmware update to work with
> armstub8-gic.bin and u-boot.bin . Everything more recent
> that I've tried fails by hanging with the rainbow showing.
>
> This matches up with the:
>
> https://github.com/raspberrypi/firmware/issues/1445
>
> reference.
The comments for that issue from one of the fedorapeople.org
people note that Fedora is having problems as well. Fedora
does not use an armstub*.bin but uses u-boot and grub2.
Basically, it looks like all firmware versions after the
2020-07-17 firmware referenced above are problematical and
until the firmware has various issues adjusted/fixed, not
having a problem is somewhat more accidental than one would
hope.
At this point, for the known issues, elimination of
armstub8-gic.bin is not a general solution to the specific
problems. (That need not have long term implications,
however.)
> A side note is that the ubuntu 2020.04.1 LTS firmware
> are actually from 2020-06-01 firmware commit activity:
>
> https://github.com/raspberrypi/firmware/commits/f382cc1
> and:
> https://github.com/Hexxeh/rpi-firmware/commits/b2aabc3
>
>>>> IIRC „we" can hack armstubs but we cannot hack start4*.elf & fixup4*.dat ,
>>>> but you can take a hexdump of start4*.elf to compare changes if you feel like it,
>>>> while I doubt that will easy find the cause(s)..
>>>
>>> hexdump comparisons is not something I'm likely to do and is
>>> not what I said I was going to do.
>>>
>>> Types of changes are identified by the commit notes. It is
>>> possible with what I'm doing that a firmware problem would
>>> be identified that the rpi folks would work on. (Not
>>> claiming to know it is likely or anything.)
>>
>> Turns out that FreeBSD is not the only context with problems,
>> others not involving armstub8-gic.bin or FreeBSD at all are
>> also having (a sequence of) problems. See, for example, the
>> sequence of notes in:
>>
>> https://github.com/raspberrypi/firmware/issues/1445
>>
>> where problems showed up in contexts using edk2's uefi
>> for RPi4's and, separately, for RPi3's.
>>
>> The known issues are being worked on. (I've no evidence
>> at this point relative to sufficiency for FreeBSD's context.)
>>
>>> I've already reported on the lists a patch for u-boot 2020.10
>>> not avoiding stomping on memory owned by the armstub8-gic.bin
>>> that FreeBSD uses. (It is not guaranteed to stomp on such
>>> memory either: u-boot just does not reserve the memory area
>>> that it should and so treats it as available for potential
>>> use.)
>>>
>>> If I had only focused on armstub8-gic.bin I never would have
>>> found that problem. (Of course, if armstub8-gic.bin ends up
>>> eliminated, the problem I found goes away too.)
>>>
>>> Unfortunately, the patch does not fix the symptoms that
>>> started this effort but the defect could lead to problems.
>>
>
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
More information about the freebsd-arm
mailing list