Re: Radxa Orion O6

On Fri, Jan 31, 2025 at 6:47 AM Andrew Turner <andrew@fubar.geek.nz> wrote:

> On 2025-01-31 13:16, FUKAUMI Naoki wrote:
> > Hi Andrew,
> >
> > On 1/31/25 19:56, Andrew Turner wrote:
> >>> https://drive.google.com/file/d/1PKxfS7BWK4Vo41tw7YrYB1_LfHzLCN-A/
> >>> view?usp=sharing
> >>
> >> I found the DSDT you posted to the NetBSD list and think I now know
> >> the issue. The memory range in the MCFG table is not the first entry
> >> in the _CRS table for the PCI root. FreeBSD has what appears to be a
> >> bug where it assumes this memory range is first in the list _CRS
> >> returns, rather than searching for it.
> >>
> >> I also found why the ram0 driver is failing to attach. The NPU0 device
> >> is trying to reserve memory in the range 0x90000000-0x92000000. I
> >> would expect this memory is included in the memory map provided by
> >> UEFI so the kernel will ignore it.
> >
> > Sorry for the scattered information!
> > Thank you for the detailed analysis!
> >
> > By the way, what does the ram0 driver do?
>
> It's to hold the memory resources of the ram so other drivers don't try
> to use them. See the commit message in [1] where it was added.
>
> I think we could move it earlier in the boot so it holds the resource
> before the acpi device is attached. This would stop the panic, and block
> drivers from using memory that may have already been allocated by the
> system
>

That was my first thought when I saw how late the panic was. We should be
attaching ram0 almost first thing after nexus. I wanted to confirm the
conflict
before trying to move it, and then $WORK got in the way. Thanks for the
confirmation
and tracking down what the conflict is. And I agree: if that device is
expected to
be used by the system and has ram reserved for it for that purpose, it
should have
a different UEFI memory type perhaps.

Warner


> Andrew
>
> [1]
>
> https://github.com/freebsd/freebsd-src/commit/e6cf1a0826c9d7f229e41224ec7b783501636528
>