On 8/10/07, Michael Meeuwisse <[EMAIL PROTECTED]> wrote: > I don't completely get it yet. The main BIOS will write 0xFFFFFFFF to > it on boot, we set it to how much memory we want, and then the BIOS > will set a particular address in it which is then where we're > 'mapped'? That's how I understood section 6.2.5.1 of spec 2.2, which > sounds like these registers have a dual purpose. Am I right?
Yeah, sorta. The BARs don't allow all bits to get written. Let me give you an example. Let's say that the aperture is going to be 65536 bytes. (This is a demand made by the PCI target.) The BIOS will write 0xFFFFFFFF, but when it reads the register back, it'll get 0xFFFF0000 (the lowest 2 bits may not be zero). Based on that, the BIOS figures out that it needs a 64KiB area in address space. These memory spaces are always 2**N in size, and they also have to be placed on 2**N boundaries. The bits that read back 0 can never be anything else. The BIOS finds an aligned 64KiB area and writes the address of that into the BAR. Done. > Also I noticed there are 20 of them, plus another one purely for the > Expansion ROM. Makes more sense, I initially thought there was only > one. :) Not 20. I believe it's 5. Keep in mind that these are 32-bit numbers, but the addressing is byte-oriented. All cfg space registers start at multiples of 4 bytes. > > and also limit the decode to 32K. I feel like I'm missing something > > important here, though, because I know that when I did something like > > this with the i128, it was trivial. > > As I understood it we (the PCI card) can't, the BIOS and/or system > can. Although it's a bit unclear if this is tracked only in the BARs > of all devices, or shadowed somewhere else. If we make the BAR sizes configurable, then we can let them be remapped at whatever sizes dynamically. Basically, it's the target (device) that controls how much memory is allocated to a BAR. > Done. I had to LOL when I saw that the 'magic header' is 0x55AA. How > original! > Anyway, I'm going to have a look at how much work it'll be to write > this setup code for the PC platform. Hopefully next week I'll find > some time to cook up assembly. It doesn't seem to hard now that the > overall picture is getting clearer. Sweet. We have nearly enough of the VGA stuff in place that perhaps it should be the next major thing for us to do. This way, people can use unaccelerated OGD1 boards as VGA consoles. Then we can add a simple 2D blt engine, and then keep working our way up. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
