>> Guessing should not be relevant; how BARs work is part of the PCI
>> definition.
> What I was meaning is that it seems counterintuitive that a single 32
> bit register can at the same time specify a 32 bit physical memory
> address and a memory region extent.
Yes. It is clever - but I wish the PCI designers had chosen a bit less
cleverness.
> In the example of the output of `pcictl' for my test device, this is
> exactly the case: only 1 non-zero BAR,
> Base address register at 0x10
> type: 32-bit nonprefetchable memory
> base: 0x10110000
> I am stuck in trying to interpret this value, and to use it both for
> an address and a range.
You can't. If you have read-only access to the BAR - which is what
pcictl gives you - then all you can get is the base address. You need
read/write access to get the range as well. (In case you haven't yet
seen the trick: you read the value and save it, then you write all-1s
and read it back, to see which bits are read-only, then you write back
the value you saved. Yes, this implies that the size of the range is
always a power of two. As I said, clever, but I wish they'd kept their
cleverness a bit more in check.)
> Yes, this may change according to the architecture. Here it's not
> x86. If you remember some source, or documentation, I would check it
> out.
I don't. I have never worked with a cobalt and I don't know whether
there is a de-facto standard for how MIPS interfaces to PCI.
> This makes me wonder if the tutorial is correct and why.
> The main fact here (at least, for a beginner) is that it's extremely
> difficult to make multiple attempts, check and verify, as you would
> with a normal C program (print something, do anything useful to let
> you know how it works).
Can't you print things? I've done that often enough with kernel code.
If -current has broken "printf from the driver" debugging, I'd call
that a crippling regression.
> Here, for example, I wonder what (in detail) makes pci_mapreg_map
> fail, what kind of space actually needs the PCI test device: in other
> words, some more information about this mapping.
You could always do something like
(in your driver's .c file)
extern int mapreg_debug;
..._attach(...)
{
...
mapreg_debug = 1;
... pci_mapreg_map(...) ...
mapreg_debug = 0;
...
}
(in the implementation of pci_mapreg_map)
int mapreg_debug = 0;
...
if (mapreg_debug) printf("...", ...);
It's a horrible thing to do for "permanent" (production) code, but I
see nothing at all wrong with it for experimental debugging.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
