RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?

[Robert Crowston]

I guess my point is, either
* we still keep the armstubs file (in some form) so we have a way to inject our CPU spin up logic in privileged mode; or,
* we implement some alternative spin up (like Linux does).

Just taking it out will not help us unless we turn off SMP.

I am surprised that you can boot without the armstub. Can you post the dmesg?

On Sun, Oct 11, 2020 at 15:23, Klaus Cucinauomo <maciphone2 at googlemail.com> wrote:

>> Am 11.10.2020 um 16:10 schrieb Klaus Cucinauomo <maciphone2 at googlemail.com>:
>>
>>
>>
>>> Am 11.10.2020 um 15:38 schrieb Robert Crowston <crowston at protonmail.com>:
>>>
>>> (I have not tried updating u-boot yet.) … All I did was remove the device_tree_address=0x4000 from config.txt.
>>
>> In boot 2020.10 the whole armstubs-stuff should or has to be removed when using modern firmware
>> so
>> ….MESS:00:00:08.221028:0: Loading ‚armstub8-gic.bin' to 0x0 size 0x1700...
>> will result in a hdmi-rainbow - screen - hang ( or console-hang)(`ve tested it with your removed device_tree_address=0x4000 also(still hangs))
>> If you want to test I`ve uploaded the u-boot2020.10 to spare you some compile-time on your nice weekend ;-) :
>> https://wiki.freebsd.org/arm/Raspberry%20Pi#RPI4
>> (Best to test directly boot from SSD because that’s the purpose to upgrade u-boot)
>>
>> Regards
>>
>> K.
>
> Ah, Rob, forgot to mention(because you couldn’t read all my crap here :-). :
> With the whole relevant msdos-partition-files of ubuntu 64-bit-server(they don’t use armstubs) copied over to our msdospartiton(but leaving armstus-gic in our config.txt),
> I was able to boot Fbsd with modern firmware directly from SSD(hangs short before initializing pcie , short after gpio or so iirc)…
> And that booted quite slow(because armstubs conflict with modern fw) …
> https://github.com/raspberrypi/firmware/issues/1340
>
> K.