RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting)

[Mark Millard]

On 2020-Oct-9, at 18:54, Mark Millard <marklmi at yahoo.com> wrote:

> On 2020-Oct-9, at 18:46, Mark Millard <marklmi at yahoo.com> wrote:
> 
>> On 2020-Oct-9, at 18:08, Klaus Cucinauomo <maciphone2 at googlemail.com> wrote:
>> . . .
>> 
>>> But I  G U E S S(still can’t resist;-) that we now have to patch&compile( at least bcm2711-rpi-4-b)  to stay in touch with 2020.10

I've reproduced the "hangs during rainbow" problem
in a microsd-card-only context when modern firmware
is in use with u-boot 2020.10 . USB3/xHCI/PCIe
access-attemtps are not required for the problem to
happen.

I've sent other E-mail about it, but my hypothesis is
that the armstub8-gic.bin requirement for:

device_tree_address=0x4000

and where/how start4.elf and fixup4.dat are loading
before the device tree activity are conflicting 
for how things are kept track of in RAM for start4.elf
and fixup4.dat --and the two activities are stomping
on or using some of each other's values in memory.

I expect that the older firmware has the structural
conflict with armgstub8-gic.bin as well but just
happens to be less likely to run into a conflict
that made it obvious that there was a problem.

As far as I can tell, it would have to be
armstub8-gic.bin 's requirements that would
have to change if I'm correct about the above.
( Similarly for armstub8.bin .)

>>>> Am 10.10.2020 um 02:21 schrieb Mark Millard <marklmi at yahoo.com>:
>>>> My FreeBSD USB3 SSD is partitioned as:……..
>>>> After that it tries to boot from ethernet (which was
>>>> not connected).
>>> 
>>> Tomorrow I will look again exactly with which partition tables I booted the SSD, 
>>> for today I am completely dizzy from all that rpi-dtb stuff , I can’t remember what I did :-)
>> 
>> 
> 
> 


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