[coreboot] Interrupt mapping with NetBSD

[Andrey Korolyov]

On Sat, Jun 27, 2015 at 4:58 PM, Andrey Korolyov <andrey at xdel.ru> wrote:
> On Sat, Jun 27, 2015 at 4:28 PM, Jonathan A. Kollasch
> <jakllsch at kollasch.net> wrote:
>> On Sat, Jun 27, 2015 at 04:09:08PM +0300, Andrey Korolyov wrote:
>>> Hello,
>>>
>>> can anyone please provide a solid pointer for a 'patch' mentioned in
>>> http://www.coreboot.org/NetBSD#Interrupt_routing? It looks like that
>>> the even recent MPBIOS code in NetBSD kernel is not able to place all
>>> interrupts correctly if coreboot is used with SeaBIOS payload, my
>>> 82577 does not work exactly because of that under this OS. The target
>>> hardware is a well-supported X201 platform, if this can add more
>>> sense.
>>
>> The patch is unnecessary if the payload is SeaBIOS, which is the payload
>> you want to use to boot NetBSD anyway.  I barely remember the details of
>> the patch at this point, and I have no idea if I still have it laying
>> around.
>>
>> Anyway, you almost certainly don't want to be relying on anything other
>> than the DSDT for interrupt routing on a modern machine with a modern OS.
>>
>
> Thanks, disabling MPBIOS and therefore relying purely on what was
> populated by ACPI didn`t help with issue. Just to mention - Linux
> kernel works just fine with same device numbers, so the nature of the
> problem is a bit unclear to me (driver`s code for 'unable to map
> interrupt' suggests that there was no interrupt number provided at
> all). Sadly the wireless driver behaves very poorly with 6250, leaving
> no alternative for remote connection than a temporarily broken
> ethernet link:
>
> 64 bytes from 192.168.1.36: icmp_seq=2 ttl=255 time=14.0 ms
> 64 bytes from 192.168.1.36: icmp_seq=5 ttl=255 time=3.50 ms
> 64 bytes from 192.168.1.36: icmp_seq=7 ttl=255 time=13.5 ms

Ultra-short post-mortem: out of three top BSDs only FreeBSD stable was
able to handle all hardware from very beginning, OpenBSD decided to
not work with media layer of 82577 as well as NetBSD, though OpenBSD
reported no driver issues. Hopefully I`ll have enough time to figure
out and patch the difference.