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

Mark Millard via freebsd-arm <[email protected]>
Newsgroups gmane.os.freebsd.devel.arm
Message-ID <[email protected]>
On 2020-Oct-13, at 23:18, Klaus Cucinauomo <maciphone2 at googlemail.com> wrote:

> Am 14.10.2020 um 07:52 schrieb Mark Millard <[email protected]>:
>> 
>> …...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...
> 
> 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.)

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)

_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[email protected]"
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.