* mapping a PCI bus
@ 2009-03-09 10:42 Nicolas Lavocat
[not found] ` <49B4F27C.7040007-s/S/64wAxt+H1Tvi1vFFB9BPR1lH4CV8@public.gmane.org>
0 siblings, 1 reply; 4+ messages in thread
From: Nicolas Lavocat @ 2009-03-09 10:42 UTC (permalink / raw)
To: devicetree-discuss
Hy everybody!
I’m working on a project:
On a proprietary board, (with a PowerPC 7448), a minimal Linux has been
embedded. My first aim consist in using a graphic chipset on the board,
that is to say make work the PCI bus. For the address mapping, I try to
write a dts, using the dts of the mpc7448hpc2 board as a model. My
problem is that I don’t understand how to fill the field “range” of the
PCI. The “width” used and the number of range is different from on board
to an other where PCI is used. I read the PCI specification, and don’t
find anything about it.
Here is an extract of my dts, where the field in question is indicated
thanks to commentaries:
pci@70000000 { compatible = "abac-pci";
device_type = "pci";
#size-cells = <2>;
#address-cells = <3>;
#interrupt-cells = <1>;
reg = <0x70000000 0x1000>;
bus-range = <0 0>;
/* how can I know how to chose the number of range and their width?*/
ranges = <0x2000000 0x0 0xe0000000 0xe0000000 0x0 0x1a000000
0x1000000 0x0 0x0 0xfa000000 0x0 0x10000>;
…
};
Then, I have a second question: why PCI’s addresses seem to be
implemented on 96 bits, whereas the addressing is done on 32 bits?
Thanks for Your attention !
Nicolas Lavocat
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: mapping a PCI bus
[not found] ` <49B4F27C.7040007-s/S/64wAxt+H1Tvi1vFFB9BPR1lH4CV8@public.gmane.org>
@ 2009-03-09 17:25 ` Mitch Bradley
0 siblings, 0 replies; 4+ messages in thread
From: Mitch Bradley @ 2009-03-09 17:25 UTC (permalink / raw)
To: Nicolas Lavocat; +Cc: devicetree-discuss
The reason why the ranges property for PCI is so complicated is because
PCI addressing is complicated, so it's tricky to fit the PCI address
information into a generic framework. I'll explain how it works
in-line, below.
> Hy everybody!
>
> I’m working on a project:
>
> On a proprietary board, (with a PowerPC 7448), a minimal Linux has
> been embedded. My first aim consist in using a graphic chipset on the
> board, that is to say make work the PCI bus. For the address mapping,
> I try to write a dts, using the dts of the mpc7448hpc2 board as a
> model. My problem is that I don’t understand how to fill the field
> “range” of the PCI. The “width” used and the number of range is
> different from on board to an other where PCI is used. I read the PCI
> specification, and don’t find anything about it.
>
> Here is an extract of my dts, where the field in question is indicated
> thanks to commentaries:
>
> pci@70000000 { compatible = "abac-pci";
> device_type = "pci";
> #size-cells = <2>;
> #address-cells = <3>;
> #interrupt-cells = <1>;
> reg = <0x70000000 0x1000>;
> bus-range = <0 0>;
> /* how can I know how to chose the number of range and their width?*/
The "ranges" property describes how the bus bridge translates between
the "parent" address space (typically the main system bus) and the
"child" address space (the PCI bus address space). For the full details
of the generic "ranges" property, consult page 172 of
ftp://playground.sun.com/pub/1275/coredoc/1275-1994/1275.ps.gz
The number of ranges entries is equal to the number of disjoint
translation regions. Typically you need at least two for PCI bus, one
for the PCI memory space and another for the PCI I/O space.
>
> Then, I have a second question: why PCI’s addresses seem to be
> implemented on 96 bits, whereas the addressing is done on 32 bits?
I have moved this question up, as the answer is helpful for later.
PCI bus addressing can be either 32 bits or 64 bits, depending on the
hardware implementation. The Open Firmware binding to PCI uses 64 bits
so it can accommodate the full PCI spec. In addition to the 64 address
bits, you need bits to indicate other information, such as which address
space (I/O or memory) you are talking about, which Base Address Register
is involved, and other information as described on page 4 (pdf page 9)
of ftp://playground.sun.com/pub/1275/bindings/pci/pci2_1.pdf . Much of
that other information is irrelevant in the context of the "ranges"
property - but the address space identifier is relevant. Numeric values
in the device tree are represented in units of 32 bits, so you need a
total of 96 bits for the basic 64-bit address plus the extra info.
>
> ranges = <0x2000000 0x0 0xe0000000 0xe0000000 0x0 0x1a000000
Okay, now we can start to parse this ranges property. I added spaces
above to show grouping.
0x2000000 0x0 0xe0000000
is the base PCI address of one of the ranges entries. 0x2000000 is the
"phys.hi" cell that contains the "extra" information - in particular the
"2" is in the "ss" field that indicates the address space - 2 means "PCI
memory space". The rest of the bits in that word are irrelevant to the
ranges property. 0x0 0xe0000000 is a 64-bit offset, indicating that
the mapped-through range begins at e0000000 in PCI memory address space.
0xe0000000
is the entry's base address in the parent (system bus) address space.
Apparently this bus bridge is a very simple one - probably just wires
and a decoder - because the parent address and child address are
identical. That's not always the case.
0x0 0x1a000000
is the size of this range. It's a 64-bit number because PCI has
#size-cells = 2. So the range goes from 0xe0000000 to 0xf9ffffff.
>
> 0x1000000 0x0 0x0 0xfa000000 0x0 0x10000>;
Similarly - 0x1000000 means I/O space, 0x0 0x0 means PCI I/O space
beginning at 0, 0xfa000000 means that the PCI I/O space appears at
0xfa000000 in the system bus address space, and 0x0 0x10000 means the
mapping is 64Kbytes long.
>
> …
>
> };
>
> Thanks for Your attention !
>
> Nicolas Lavocat
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: mapping a PCI bus
@ 2009-03-12 10:35 Nicolas Lavocat
[not found] ` <49B8E583.3070108-s/S/64wAxt+H1Tvi1vFFB9BPR1lH4CV8@public.gmane.org>
0 siblings, 1 reply; 4+ messages in thread
From: Nicolas Lavocat @ 2009-03-12 10:35 UTC (permalink / raw)
To: devicetree-discuss-mnsaURCQ41sdnm+yROfE0A
Hello!
Thanks a lot for all these explanations! they are very helpful! I have
understood the meaning of each fields of "ranges", but I don't know
where find informations to fill it... I don't find any reference about
memory space and iopace ranges in my datasheets. I have read in the PCI
specification that the base address register (BAR) permit to get the
memory range needed by each device on the PCI bus. Have I to get the
memory range of every device in order to fill the range property ? I
feel that I missed something...
To finish, I have a question about the "reg" field. I have read in
documentations that it must contain the address of the PCI bridge's
configuration space: am I wrong?
Thanks for Your attention !
Nicolas Lavocat
Mitch Bradley a écrit :
> The reason why the ranges property for PCI is so complicated is
> because PCI addressing is complicated, so it's tricky to fit the PCI
> address information into a generic framework. I'll explain how it
> works in-line, below.
>
>> Hy everybody!
>>
>> I’m working on a project:
>>
>> On a proprietary board, (with a PowerPC 7448), a minimal Linux has
>> been embedded. My first aim consist in using a graphic chipset on the
>> board, that is to say make work the PCI bus. For the address mapping,
>> I try to write a dts, using the dts of the mpc7448hpc2 board as a
>> model. My problem is that I don’t understand how to fill the field
>> “range” of the PCI. The “width” used and the number of range is
>> different from on board to an other where PCI is used. I read the PCI
>> specification, and don’t find anything about it.
>>
>> Here is an extract of my dts, where the field in question is
>> indicated thanks to commentaries:
>>
>> pci@70000000 { compatible = "abac-pci";
>> device_type = "pci";
>> #size-cells = <2>;
>> #address-cells = <3>;
>> #interrupt-cells = <1>;
>> reg = <0x70000000 0x1000>;
>> bus-range = <0 0>;
>> /* how can I know how to chose the number of range and their width?*/
> The "ranges" property describes how the bus bridge translates between
> the "parent" address space (typically the main system bus) and the
> "child" address space (the PCI bus address space). For the full
> details of the generic "ranges" property, consult page 172 of
> ftp://playground.sun.com/pub/1275/coredoc/1275-1994/1275.ps.gz
>
> The number of ranges entries is equal to the number of disjoint
> translation regions. Typically you need at least two for PCI bus, one
> for the PCI memory space and another for the PCI I/O space.
>
>>
>> Then, I have a second question: why PCI’s addresses seem to be
>> implemented on 96 bits, whereas the addressing is done on 32 bits?
>
> I have moved this question up, as the answer is helpful for later.
>
> PCI bus addressing can be either 32 bits or 64 bits, depending on the
> hardware implementation. The Open Firmware binding to PCI uses 64 bits
> so it can accommodate the full PCI spec. In addition to the 64 address
> bits, you need bits to indicate other information, such as which
> address space (I/O or memory) you are talking about, which Base
> Address Register is involved, and other information as described on
> page 4 (pdf page 9) of
> ftp://playground.sun.com/pub/1275/bindings/pci/pci2_1.pdf . Much of
> that other information is irrelevant in the context of the "ranges"
> property - but the address space identifier is relevant. Numeric
> values in the device tree are represented in units of 32 bits, so you
> need a total of 96 bits for the basic 64-bit address plus the extra info.
>
>>
>> ranges = <0x2000000 0x0 0xe0000000 0xe0000000 0x0 0x1a000000
>
> Okay, now we can start to parse this ranges property. I added spaces
> above to show grouping.
>
> 0x2000000 0x0 0xe0000000
>
> is the base PCI address of one of the ranges entries. 0x2000000 is the
> "phys.hi" cell that contains the "extra" information - in particular
> the "2" is in the "ss" field that indicates the address space - 2
> means "PCI memory space". The rest of the bits in that word are
> irrelevant to the ranges property. 0x0 0xe0000000 is a 64-bit offset,
> indicating that the mapped-through range begins at e0000000 in PCI
> memory address space.
>
> 0xe0000000
>
> is the entry's base address in the parent (system bus) address space.
> Apparently this bus bridge is a very simple one - probably just wires
> and a decoder - because the parent address and child address are
> identical. That's not always the case.
>
> 0x0 0x1a000000
>
> is the size of this range. It's a 64-bit number because PCI has
> #size-cells = 2. So the range goes from 0xe0000000 to 0xf9ffffff.
>
>
>>
>> 0x1000000 0x0 0x0 0xfa000000 0x0 0x10000>;
>
> Similarly - 0x1000000 means I/O space, 0x0 0x0 means PCI I/O space
> beginning at 0, 0xfa000000 means that the PCI I/O space appears at
> 0xfa000000 in the system bus address space, and 0x0 0x10000 means the
> mapping is 64Kbytes long.
>
>
>>
>> …
>>
>> };
>>
>> Thanks for Your attention !
>>
>> Nicolas Lavocat
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: mapping a PCI bus
[not found] ` <49B8E583.3070108-s/S/64wAxt+H1Tvi1vFFB9BPR1lH4CV8@public.gmane.org>
@ 2009-03-12 18:20 ` Mitch Bradley
0 siblings, 0 replies; 4+ messages in thread
From: Mitch Bradley @ 2009-03-12 18:20 UTC (permalink / raw)
To: Nicolas Lavocat; +Cc: devicetree-discuss-mnsaURCQ41sdnm+yROfE0A
> Hello!
> Thanks a lot for all these explanations! they are very helpful! I have
> understood the meaning of each fields of "ranges", but I don't know
> where find informations to fill it... I don't find any reference about
> memory space and iopace ranges in my datasheets.
The information should be in the documentation for the chip that
implements the host-to-PCI bridge function - a chip like Tundra Tsi110 .
The host bridge chip is probably programmable. If so you must choose a
range of system bus addresses to use for PCI. The firmware will need to
program the host bridge chip registers that control that address
assignment. The dts ranges property will then report that information.
> I have read in the PCI specification that the base address register
> (BAR) permit to get the memory range needed by each device on the PCI
> bus. Have I to get the memory range of every device in order to fill
> the range property ? I feel that I missed something...
No, the ranges property is independent of BAR assignments on PCI devices.
The value of the ranges property is established once, as part of the
system design process. The values of individual device BARs can change
from boot to boot, depending on which cards are plugged in.
>
> To finish, I have a question about the "reg" field. I have read in
> documentations that it must contain the address of the PCI bridge's
> configuration space: am I wrong?
For a PCI host bridge (the "/pci" node itself): the "reg" property
contains the address of the bridge's register bank *in the system bus
address space*. In general, that is not a configuration space address,
because the main system bus is usually not a PCI bus. For PPC 74xx
processors, the main system bus is the "60x bus" that comes out of the
CPU chip.
For a PCI device (something that plugs into a PCI bus, with a name like
/pci/ethernet): the reg property includes the device's PCI configuration
address. That configuration address depends on the PCI slot, so for
plug-in cards, the reg property must be created dynamically during the
probing process.
For a PCI-to-PCI bridge (a node like /pci/pci): the reg property of the
lower bridge contains its configuration address in the upper PCI address
space.
As you can see, the general rule is that the "reg" property specifies an
address in the "parent" address space, whatever that is. So a PCI host
bridge's "reg" property does not have a PCI configuration address,
because its parent is not a PCI bus, but rather the main system bus.
> Thanks for Your attention !
>
> Nicolas Lavocat
>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-03-12 18:20 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-03-09 10:42 mapping a PCI bus Nicolas Lavocat
[not found] ` <49B4F27C.7040007-s/S/64wAxt+H1Tvi1vFFB9BPR1lH4CV8@public.gmane.org>
2009-03-09 17:25 ` Mitch Bradley
-- strict thread matches above, loose matches on Subject: below --
2009-03-12 10:35 Nicolas Lavocat
[not found] ` <49B8E583.3070108-s/S/64wAxt+H1Tvi1vFFB9BPR1lH4CV8@public.gmane.org>
2009-03-12 18:20 ` Mitch Bradley
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.