Re: Radxa Orion O6

On 2025-01-30 14:45, FUKAUMI Naoki wrote:
> Hi Andrew,
> 
> On 1/30/25 23:14, Andrew Turner wrote:
>>>>> PCIe is not working yet. Any idea?
>>>> 
>>>> I suspect there is a conflict where two devices both try to allocate 
>>>> the same memory resource.
>>>> 
>>>> Can you try booting with “debug.rman_debug=1” set from the loader 
>>>> prompt? It will print a lot of logging about different memory and 
>>>> interrupt resources being allocated so you will likely need 
>>>> something to save the output, e.g. reading the serial output under 
>>>> script. It’s will also likely be too much for the list, so you can 
>>>> email it to me directly.
>>> 
>>> I uploaded dmesg here:
>>> 
>>> https://drive.google.com/file/d/1HzZFFIaBu2gyDHF7oPnNLuzU_CBMF5dC/ 
>>> view?usp=sharing
>> 
>> Hello,
>> 
>> The follow lines indicate another device has reserved the PCIe memory, 
>> however the details of which device has the reservation has been lost 
>> from the top of output.
>> 
>> considering [0x2c000000, 0x2fffffff]
>> region is allocated
>> 
>> Is it possible to get the data from earlier in the boot?
> 
> Sorry, I didn't realise the log was incomplete.
> 
> This should be complete...
>  
> 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.

Andrew