Showstoppers for RPI3

[Kyle Evans]

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.

Thanks,

Kyle Evans