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

[Robert Crowston]

After updating to the latest dtb firmware from https://github.com/raspberrypi/firmware/tree/63b192231130f1bdd074f3ae0794889d53bdeb06/boot, and flashing the eeprom to the 2020-09-03 version, my system boots just fine.

https://dmesgd.nycbug.org/index.cgi?do=view&id=5703

All I did was remove the device_tree_address=0x4000 from config.txt.

# cat config.txt
arm_64bit=1
armstub=armstub8-gic.bin
dtoverlay=disable-bt
dtoverlay=mmc
enable_jtag_gpio=1
enable_uart=1
kernel=u-boot.bin

(I have not tried updating u-boot yet.)

Am I missing something here?

— RHC.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, 11 October 2020 14:17, Klaus Cucinauomo <maciphone2 at googlemail.com> wrote:

>
>
> > Am 11.10.2020 um 15:11 schrieb Robert Crowston crowston at protonmail.com:
> >
> > > That’s the problem, armstub8-gic should have been removed when using modern firmware because it no longer depends on it.
> >
> > So are you telling me that I could rip out all the startup logic from the armstub and just leave our CPU spin up logic?
> > — RHC.
>
> yes, exactly, even :
> $rm /Volumes/MSDOSBOOT/armstub8-gic.bin
>
> ( while I wouldn't swear that the initialization of your pcie driver from fdt will continue to run smoothly in the boot-process directly from SSD,
> I expect necessary adjustments..)
>
> K.