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

[Mark Millard]

On 2020-Oct-13, at 22:34, Klaus Cucinauomo <maciphone2 at googlemail.com> wrote:
> 
> Am 14.10.2020 um 06:43 schrieb Mark Millard <marklmi at yahoo.com>:
>> 
>>> …...
>> 
>> By contrast, what I've done can
>> not even show that u-boot ever was started after it was loaded…
> 
> I showed that even FreeBSD was started by u-boot with the modernFirmware loaded (when the armstubs are NOT loaded) :
> https://dmesgd.nycbug.org/index.cgi?do=view&id=5702

I know. That too is insufficient to assign blame. u-boot and FreeBSD work
just fine with armstug8-gic.bin in use with the older version of firmware:
everything works. (It is how I normally run with u-boot.)

> That finding is of course not a bugfix in the armstub but enough to say: u-boot(at least that version shown in dmesg) doesn`t hang up with the modernFirmware 

With a possibly very different memory layout and other
relationships --and a guarantee that FreeBSD will fail to
work as things are, since FreeBSD requires services from
armstub8-gic.bin that are not otherwise present as things
are (or that is my understanding).

Again: the evidence for well assigning blame just is not
there yet as far as I know.


But you have prompted me to investigate in a different way,
given my lack of being able to observe u-boot early
enough. I'll test vintages of start4*.elf and fixup4*.dat
pairs and see if that identifies a specific set of changes
to them that seem to make the difference when varying just
those 2 files. That should at least be new evidence, even
if insufficient of itself.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)