Re: RPi4B: modern firmware vs. Device tree loaded to 0x4000 (size 0xbe0c) [fails] vs. to 0x1f0000 (size 0xbd90) [works]?
Robert Crowston via freebsd-arm <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.arm |
|---|---|
| Message-ID | <cbC3hMQdQvaguB9vLBwvByx3_6cRzhxoJrMKL56_7RBNdwwPBudHiZpwfDEqUz2w34Ksv-fuo-5Iq-_0L_lfNdR5YEZDYudY1YGvshFl3Co=@protonmail.com> |
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 <[email protected]> wrote: > > > > Am 11.10.2020 um 15:11 schrieb Robert Crowston [email protected]: > > > > > 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. _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "[email protected]"