Date: Sat, 10 Oct 2020 00:14:32 -0700 From: Mark Millard <marklmi@yahoo.com> To: Klaus Cucinauomo <maciphone2@googlemail.com> Cc: freebsd-arm@freebsd.org Subject: Re: RPi4B: emmc2bus dma-range handling does not track the boot-time-FDT (u-boot based booting) Message-ID: <F3D2652C-C3B2-4F46-AF0C-576710CCCBD1@yahoo.com> In-Reply-To: <5B658E5E-C438-4A05-99F5-8E4B67A89488@yahoo.com> References: <D8BDF95A-D6A8-4E95-A0CE-D53068E8355B.ref@yahoo.com> <D8BDF95A-D6A8-4E95-A0CE-D53068E8355B@yahoo.com> <ABE16EA6-49F1-461F-9B8A-6DAA7ED6A18D@googlemail.com> <98BC985D-EAAB-4AFB-AA8F-7391A45C4EBF@yahoo.com> <91324D35-B66A-4674-AE37-45F3DDB736FD@yahoo.com> <2B3F0409-88F2-4EBD-9C39-37929F973C77@yahoo.com> <B3133D77-FA24-4F42-B529-D0B56F48E790@yahoo.com> <CCEEC0AD-B874-4753-AAA1-B3B5B302A30C@googlemail.com> <E82AE086-837C-4CEA-92D5-78A39412F964@yahoo.com> <803EF261-1407-4331-AC56-1D49E05F8382@googlemail.com> <2FAA304E-045B-4B10-AA14-1E869FB6FD00@yahoo.com> <27E7A6A9-04A4-4B15-96CB-84AE478ED755@googlemail.com> <93E411FA-6024-4E2F-AAFF-C051AF4F35EE@yahoo.com> <7CB99D94-6F37-4150-9D1B-9488D4FE83EF@googlemail.com> <A4434A74-1D46-4372-9936-E794410C128B@yahoo.com> <5B658E5E-C438-4A05-99F5-8E4B67A89488@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Oct-9, at 18:54, Mark Millard <marklmi at yahoo.com> wrote: > On 2020-Oct-9, at 18:46, Mark Millard <marklmi at yahoo.com> wrote: >=20 >> On 2020-Oct-9, at 18:08, Klaus Cucinauomo <maciphone2 at = googlemail.com> wrote: >> . . . >>=20 >>> But I G U E S S(still can=E2=80=99t resist;-) that we now have to = patch&compile( at least bcm2711-rpi-4-b) to stay in touch with 2020.10 I've reproduced the "hangs during rainbow" problem in a microsd-card-only context when modern firmware is in use with u-boot 2020.10 . USB3/xHCI/PCIe access-attemtps are not required for the problem to happen. I've sent other E-mail about it, but my hypothesis is that the armstub8-gic.bin requirement for: device_tree_address=3D0x4000 and where/how start4.elf and fixup4.dat are loading before the device tree activity are conflicting=20 for how things are kept track of in RAM for start4.elf and fixup4.dat --and the two activities are stomping on or using some of each other's values in memory. I expect that the older firmware has the structural conflict with armgstub8-gic.bin as well but just happens to be less likely to run into a conflict that made it obvious that there was a problem. As far as I can tell, it would have to be armstub8-gic.bin 's requirements that would have to change if I'm correct about the above. ( Similarly for armstub8.bin .) >>>> Am 10.10.2020 um 02:21 schrieb Mark Millard <marklmi at yahoo.com>: >>>> My FreeBSD USB3 SSD is partitioned as:=E2=80=A6=E2=80=A6.. >>>> After that it tries to boot from ethernet (which was >>>> not connected). >>>=20 >>> Tomorrow I will look again exactly with which partition tables I = booted the SSD,=20 >>> for today I am completely dizzy from all that rpi-dtb stuff , I = can=E2=80=99t remember what I did :-) >>=20 >>=20 >=20 >=20 =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?F3D2652C-C3B2-4F46-AF0C-576710CCCBD1>