Showstoppers for RPI3
Mark Millard
marklmi at yahoo.com
Wed Feb 26 05:08:37 UTC 2020
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 at freebsd.org> wrote:
>>
>> On 2020-Feb-25, at 09:54, bob prohaska <fbsd at www.zefox.net> wrote:
>>
>>> 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="-1" set
>>> in /boot/loader.conf.
>>
>> If you are seeing vm.pfault_oom_attempts="-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.)
>>
>> 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.
>>
>> 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="-1" problems.
>>
>> 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.
>>
>
> 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/7d1d1ce63c1fe50b451ef0c730e1cd870b5bd440/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.)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
More information about the freebsd-arm
mailing list