> On Thu, 15 Apr 1999, Gerard Roudier wrote:
> >
> > A PCI base address register that maps I/O space must have bit 0
> > _hardwired_ to 1 by the device. The same way, bit 0 must be hardwired to 0
> > for base address registers that map into memory space.
>
> Ok, I don't know whether this "hardwires" these bits inside our PCI
> bridge (which is from PLX), but the EEPROM on the board programs the PCI
> bridge to request a 32-bit non-prefetchable memory address from the
> system. I think that if the system BIOS / O.S. are operating properly,
> this should be enough in order to get that register programmed correctly
> as requested.
We can imagine that this bit is writable, but set to 0 on reset and then
the PCI BIOS will consider the device needs a memory mapped window, and,
for obscure reasons, this bit has just been written to 1 by some other
piece of code. (Just some guessing perhaps quite wrong). Anyway, the PCI
specs 2.1 says that this bit must be hardwired.
> > It is indeed quite weird to read 1 as bit 0 from a register that should
> > have bit 0 hardwired to 0.
>
> Really weird.
>
> > Could it be possible that bit 0 is just writable for this base address
> > register.
>
> I don't think this is the case, because the address asginment works
> correctly in other systems, and even in the same system, yet in a
> different OS (DOS in this case). Without problem consistency within OS's,
> I wouldn't point the problem to the hardware.
>
> > You can verify that by hacking appropriately the Cyclades driver
> > in its detection routine. You may try for example:
> >
> > - Read the value of the offending base address reg. and save it.
> > - Write 1 to that base address reg., then read it and print the value.
> > - Write 0 to that base address, then read it and print the value.
> > - Restore the value of that base address.
>
> I can't do that right now, as:
>
> - this is a customer's production server;
> - the problem _only_ happens on that system;
How much are you sure that other systems, that donnot have this problem,
use same pieces of hardware of same revision?
> > Note that if bit 0 is writable, the device may just be bogus and not
> > conformant to PCI specs, but it could be trivial to work around the
> > problem.
>
> So, do you think that if I _force_ that bit to be 0 by inserting the
If you can do that, then, I will recommend you to do at least:
- Read this base address register
- Warn if any of bit 1, 2 or 3 is set.
- Mask all the bits that should have read zero (bit 0,1,2,3)
- Rewrite this base address register
- Read it again and warn if any bit 0, 1, 2 or 3 is still set.
> appropriate code in the driver, it would make everything work ?? My
> question is: wouldn't this affect other parts of the system that have
> detected that address as an I/O address before ?!?!? If not, the solution,
Normally, only the device driver has to access the device.
> although "dirty", is really trivial. The fact is that I always thought
> that these PCI base register contents should (must) NOT be changed
> manually.
Normally, the PCI BIOS must have assigned to PCI devices all needed
resources prior to allowing to boot the machine. So, we should never need
to change any of the base address registers at boot. :)
What you may want to check could be that the resulted memory mapped
window after the fix-up of bit 0 is not already allocated to another
device, or maps real memory.
Regards,
Gérard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/