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 22:34, Klaus Cucinauomo <maciphone2 at googlemail.com> wrote: > > Am 14.10.2020 um 06:43 schrieb Mark Millard <[email protected]>: >> >>> …... >> >> By contrast, what I've done can >> not even show that u-boot ever was started after it was loaded… > > I showed that even FreeBSD was started by u-boot with the modernFirmware loaded (when the armstubs are NOT loaded) : > https://dmesgd.nycbug.org/index.cgi?do=view&id=5702 I know. That too is insufficient to assign blame. u-boot and FreeBSD work just fine with armstug8-gic.bin in use with the older version of firmware: everything works. (It is how I normally run with u-boot.) > That finding is of course not a bugfix in the armstub but enough to say: u-boot(at least that version shown in dmesg) doesn`t hang up with the modernFirmware With a possibly very different memory layout and other relationships --and a guarantee that FreeBSD will fail to work as things are, since FreeBSD requires services from armstub8-gic.bin that are not otherwise present as things are (or that is my understanding). Again: the evidence for well assigning blame just is not there yet as far as I know. But you have prompted me to investigate in a different way, given my lack of being able to observe u-boot early enough. I'll test vintages of start4*.elf and fixup4*.dat pairs and see if that identifies a specific set of changes to them that seem to make the difference when varying just those 2 files. That should at least be new evidence, even if insufficient of itself. === 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]"