Date: Tue, 25 Feb 2020 21:08:23 -0800 From: Mark Millard <marklmi@yahoo.com> To: Kyle Evans <kevans@freebsd.org> Cc: bob prohaska <fbsd@www.zefox.net>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Showstoppers for RPI3 Message-ID: <AFCBEE2E-12C6-4BAB-AB83-72F66236C85C@yahoo.com> In-Reply-To: <CACNAnaEiv5NZZz%2BxfETkhSZ-zbjZ3Ya6z7pyteheP4zj3EK1Gg@mail.gmail.com> References: <20200225175446.GA77976@www.zefox.net> <11951E01-EC13-4FBB-938A-AEB5700C4281@yahoo.com> <CACNAnaEiv5NZZz%2BxfETkhSZ-zbjZ3Ya6z7pyteheP4zj3EK1Gg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Feb-25, at 17:57, Kyle Evans <kevans at freebsd.org> wrote: > On Tue, Feb 25, 2020 at 5:05 PM Mark Millard via freebsd-arm > <freebsd-arm@freebsd.org> wrote: >>=20 >> On 2020-Feb-25, at 09:54, bob prohaska <fbsd at www.zefox.net> wrote: >>=20 >>> There seem to be a handful of problems for -current on the RPI3 at >>> the moment. Those I've noticed include not getting multicore = operation, >>> cpu_reset failing and OOMA kills with vm.pfault_oom_attempts=3D"-1" = set >>> in /boot/loader.conf. >>=20 >> If you are seeing vm.pfault_oom_attempts=3D"-1" fail to work on or >> after head -r357253 (from 2020-Jan-29) that is likely new news. >> However, for aarch64 RPi*'s, this is after -r356767 where the >> kernel needs to be told to avoid touching all the armstub8-gic.bin >> or armstub8.bin RAM. (Previously worked only by accident, i.e., >> despite not being told to avoid all that RAM.) >>=20 >> It is messy to make judgments about aarch64 RPi*'s on or after >> -r356767 (until/unless all the armstub8*.bin is being reported to >> the kernel as RAM to avoid): too much ends up messed up by the >> kernel replacing part of armstub8*.bin's RAM content. >>=20 >> The problem -r357253 fixed was for all platforms, not just aarch64, >> much less being aarch64 RPi* specific. As far as I've seen, the >> platforms that do not have problems at -r356767 are no longer >> getting reports of vm.pfault_oom_attempts=3D"-1" problems. >>=20 >> The armstub8-gic.bin/armstub8.bin RAM not being reported to the >> kernel as RAM to avoid touching is a known problem for aarch64 >> RPi*'s. But, as far as I know, no one has indicated that they are >> working on getting such RPi*'s to well report armstub8*.bin RAM >> to the kernel --or that they are planning to do so. >>=20 >=20 > I've forwarded your patch on to some relevant U-Boot folk to try and > get some feedback from them, since they likely understand the process > better -- I would suspect reserving the second page in U-Boot as well > is the proper solution. Cool. Thanks. I'll note that compared to my replacement of one magic number by another one that also would not track future armstub8*.bin page-count changes, Robert Crowston reported the following about the size of the area to reserve and what the armstub8*.bin are doing to try to provide it: QUOTE 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 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). END QUOTE Being able to build u-boot to make use of such sounds like it would give armstub8*.bin some self-control without further u-boot changes also being needed for any armstub8*.bin page-count change. (If I remember right, when I looked armstub8-gic.bin was listing 4 pages as the size in x1, despite not needing that much currently. But that is definitely in the direction of being sufficient. As I remember, the x1 figure was in Bytes, not pages.) =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?AFCBEE2E-12C6-4BAB-AB83-72F66236C85C>