On 2018-May-19 11:53 , Jd Lyons wrote:

SLOF

assigned-addresses 82000830 00000000 83000000 00000000 00010000  
                                 82000810 00000000 81000000 00000000 01000000  
                                 c3000814 00002100 00000000 00000000 10000000  
                                 8200081c 00000000 82000000 00000000 01000000

That looks reasonable. It's somewhat unusual to have the ROMBAR be the first entry, but not prohibited. I'm a little startled by BAR 14; it's 64-bit memory space, starting at 2100.0000.0000 for length 10000000. Not out of question, but on SPARC I didn't see addresses assigned that high up (I recall we usually started at 2.0000.0000).

Openbios:

assigned-addresses-- 3c : 02007810 00000000 81000000 00000000 01000000 
                          c3007814 00000000 90000000 00000000 10000000 
                          8300781c 00000000 a0000000 00000000 01000000 

Obviously Openbios isn’t getting the ROM bar 0x30.

The ROMBAR absence might not be a problem - it has to be manually turned on (low order bit in the address, as I recall), so if you leave it turned off, you don't need to assign it an address. I'd generally have the framework assign it an address anyway, just so you didn't run into allocation problems at the time when you do need to turn it on.

BAR 14 is listed as 64-bit memory, starting at 9000.0000 - way down in 32-bit address space. Some FCodes may get confused by that. It generally shouldn't be a problem, but it's something to worry about.

BAR 10 in the above is listed starting with 02 instead of 82... My recollection is that the "8" is the "n" (non-relocatable) bit in the descriptor... Ah, yes, see https://www.openfirmware.info/data/docs/bus.pci.pdf section 2.2.1.1 - I'd generally expect that to be set in the assigned-addresses specification (once the framework has assigned an address, the client isn't allowed to relocate it. The bit is more intended for a "reg" specification.)

So, Openbios is doing things a bit funky, but not entirely unreasonable. I"d keep in mind the potential confusion with 32/64 bit addressing in the FCode, but aside from that, the only thing I'd worry about is the missing "n" bit on BAR 10.