In article <68d84cd8d31e0de385edd96ecd39050b@netbsd.org>,
Michael Lorenz  <macallan@netbsd.org> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi Joachim,
>
>to sum things up - what's wrong with this card is that it hardwires the 
>upper 16 bit of its BARs to zero which OpenFirmware considers an error 
>and therefore refuses to configure/enable the card.
>To make it usable anyway we'd have to enable it by hand, write some 
>safe values into its BARs and figure out which interrupt to use.
>Finding he interrupt shouldn't be a problem - the bridge's 
>interrupt-map should tell us, the code is already there. The rest is 
>easy enough to do, I can write you such a patch if you want.
>What we'd need are some safe values for the BARs which are:
>- - size 0x10, naturally aligned ( as in - the 4 lower bits are zero ) - 
>mainly because OF said so
>- - <0xffff because the upper bits are hardwired to 0
>To find such values you need to look at all your PCI devices on the 
>same host bridge, jot down which IO ranges they use and then pick two 
>that don't collide with anything.
>The problem with this - it's a gross hack that won't go into the 
>official source tree. If you add new cards you may need to pick new 
>addresses for the puc since OF - being unaware of this hack - may 
>assign the ranges you picked to said new card and then things would 
>blow up.

Isn't there a way to tell OF not to use some ranges?

christos