Date: Sat, 15 Feb 2020 09:25:18 -0800 From: Mark Millard <marklmi@yahoo.com> To: Robert Crowston <crowston@protonmail.com>, Kyle Evans <kevans@freebsd.org>, freebsd-arm <freebsd-arm@freebsd.org> Cc: Ralf Wenk <iz-rpi03@hs-karlsruhe.de>, Andrew Turner <andrew@freebsd.org>, Oleksandr Tymoshenko <gonzo@freebsd.org>, Emmanuel Vadot <manu@freebsd.org> Subject: The aarch64 RPi* boot problems and armstub8*.bin vs. u-boot: Robert Crowston's existing-interfacing-definition notes consolidated (reports things I missed) Message-ID: <DEADD27D-0A88-4D00-A894-44A4549C48EF@yahoo.com> References: <DEADD27D-0A88-4D00-A894-44A4549C48EF.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[My investigation started from complete ignorance
of the directly relevant material and I did not
identify all the existing interfacing available.]
Quoted is material I wrote and that Robert C. replied:
>> So it may be sysutils/u-boot-rpi{3,4} that needs to
>> arrange sufficient room to prevent messing up such.
>> (Unless armstub8*.bin can adjust something that
>> u-boot's EFI interface is based on for that initial
>> "Reserved" area?)
>=20
> The area to be reserved is already passed in register x1 by armstub to =
u-boot here:
> =
https://github.com/gonzoua/rpi3-psci-monitor/blob/master/pscimon.S#L178
I missed that in my looking around for what interfaces
propagate appropriate information.
> u-boot can read this register before it does anything else in =
save_boot_params in lowlevel_init.S. (e.g., =
https://github.com/RobCrowston/u-boot/blame/7d1d1ce63c1fe50b451ef0c730e1cd=
870b5bd440/board/raspberrypi/rpi/lowlevel_init.S#L38).
Good to know for folks considering what technique
to use for a long-term fix.
> In a separate message:
>=20
>> I put in code to add a reserved memory region
>> spanning the 2 pages at the beginning of the
>> address space. This is enough to span all the
>> armstub8-gic.bin content (that is loaded to
>> address 0x0 in my test context).
>=20
> I had looked at this when I first getting the armstub to work with the =
Rpi4, and indeed I had no idea this was a problem again today.
>=20
> In Tymoshenko's u-boot patch for the pi3, we modify the dtb in memory =
to reserve these pages, before u-boot communicates the modified dtb to =
the operating system.
RPi3 contexts were the original reporters of the problem
and made the majority of the reports. (I just had access
to an RPi4B instead and so worked with that context.)
So I do not expect such a patch is currently involved
for sysutils/u-boot-rpi3 .
My understanding from other messages, is that
sysutils/u-boot-master is holding at its current
version for other fixes currently in order to avoid
breaking other contexts.
> I used the same idea =
(https://github.com/agherzan/u-boot/commit/7d1d1ce63c1fe50b451ef0c730e1cd8=
70b5bd440) when I first got the rpi4 to boot.
Cool.
> Does sysutils/u-boot-rpi4 do this as well?
sysutils/u-boot-rpi4 has a hard coded:
#ifdef CONFIG_EFI_LOADER
/* Reserve the spin table */
efi_add_memory_map(0, 1, EFI_RESERVED_MEMORY_TYPE, 0);
#endif
in ft_board_setup in board/raspberrypi/rpi/rpi.c . That is
what currently leads to the first page being avoided by
the kernel for my test context. Changing the "1" to a "2"
makes the kernel avoid 2 pages, which is currently
sufficient.
RPi3's are the primary context that started reporting the
boot problems so I expect similar for sysutils/u-boot-rpi3
but I had a RPi4B context to work with and only looked at
the sysutils/u-boot-rpi4 port that I could test.
>> I had done other investigative work earlier to
>> find for sure where armstub8-gic.bin was being
>> loaded in my example context: address 0x0.
>=20
> I am quite sure this is correct. We need the absolute addresses to be =
accurate when we spin up the other CPUs.
I had no directly relevant background knowledge and and so
had the code report where it was put. But I had no
background on how uniform the place was across RPi3's and
RPi2 v1.2's and such.
Glad to know it is uniform. Other relevant folks probably
already knew that.
> (Apologies if this was already known, the thread has been split and it =
is a little hard to follow.)
Having future communication avoid the investigative
exploration history I went through would be simpler
and better. At this point ,there is no reason for any
exchange in the subject area to target me as far as
I can tell. (Wrong background knowledge.)
Kyle E. did recently submit dtc improvements spanning
memreserve handling improvements:
=
https://lists.freebsd.org/pipermail/svn-src-head/2020-February/133765.html=
=
https://lists.freebsd.org/pipermail/svn-src-head/2020-February/133766.html=
=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?DEADD27D-0A88-4D00-A894-44A4549C48EF>