Date: Wed, 14 Oct 2020 00:22:51 -0700 From: Mark Millard <marklmi@yahoo.com> To: Klaus Cucinauomo <maciphone2@googlemail.com> Cc: freebsd-arm@freebsd.org Subject: Re: 64-bit RPi4B u-boot hangup with modern rpi firmware: some information (but investigative-toolbox limited) Message-ID: <02528C74-F23F-46BB-8028-3DE9CB2A8327@yahoo.com> In-Reply-To: <8EB23BD2-15C0-4679-87A9-87FE5906A7EA@googlemail.com> References: <290E51C0-0AF5-4C75-AA7B-BA56DF1AFDFB.ref@yahoo.com> <290E51C0-0AF5-4C75-AA7B-BA56DF1AFDFB@yahoo.com> <4114B1A0-03ED-4268-BA87-8CF196A935A4@googlemail.com> <F439DCA4-481E-4918-9ED4-2D9ECB2DD03F@yahoo.com> <D63E3FD9-72AD-4C61-BBA6-323D8FCA5775@googlemail.com> <C8A5CA35-A18A-41C0-A18E-2837CED23BB4@yahoo.com> <8EB23BD2-15C0-4679-87A9-87FE5906A7EA@googlemail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Oct-13, at 23:18, Klaus Cucinauomo <maciphone2 at = googlemail.com> wrote: > Am 14.10.2020 um 07:52 schrieb Mark Millard <marklmi@yahoo.com>: >>=20 >> =E2=80=A6...FreeBSD requires services from >> armstub8-gic.bin that are not otherwise present as things >> are (or that is my understanding). >=20 > as of today: correct understanding >=20 >>=20 >> ... I'll test vintages of start4*.elf and fixup4*.dat >> pairs and see if that identifies a specific set of changes >> to them... >=20 > IIRC =E2=80=9Ewe" can hack armstubs but we cannot hack start4*.elf & = fixup4*.dat , > but you can take a hexdump of start4*.elf to compare changes if you = feel like it, > while I doubt that will easy find the cause(s).. hexdump comparisons is not something I'm likely to do and is not what I said I was going to do. Types of changes are identified by the commit notes. It is possible with what I'm doing that a firmware problem would be identified that the rpi folks would work on. (Not claiming to know it is likely or anything.) I've already reported on the lists a patch for u-boot 2020.10 not avoiding stomping on memory owned by the armstub8-gic.bin that FreeBSD uses. (It is not guaranteed to stomp on such memory either: u-boot just does not reserve the memory area that it should and so treats it as available for potential use.) If I had only focused on armstub8-gic.bin I never would have found that problem. (Of course, if armstub8-gic.bin ends up eliminated, the problem I found goes away too.) Unfortunately, the patch does not fix the symptoms that started this effort but the defect could lead to problems. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?02528C74-F23F-46BB-8028-3DE9CB2A8327>