On 2018-May-19 11:53 , Jd Lyons wrote:
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).
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
section 184.108.40.206 -
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"
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.