64-bit RPi4B u-boot hangup with modern rpi firmware: some information (but investigative-toolbox limited)

[Mark Millard]

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.


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)