I'm trying to modify the p2041rdb.dts file to allow for a PCIe device with a very large memory mapped footprint (2GBytes).
I've changed the device tree entries as follows, but cannot get the Linux SDK V1.3 kernel to boot with the resulting device tree :
.....
rio: rapidio@ffe0c0000 {
reg = <0xf 0xfe0c0000 0 0x11000>;
port1 {
ranges = <0 0 0xc 0xc0000000 0 0x10000000>;
};
port2 {
ranges = <0 0 0xc 0xd0000000 0 0x10000000>;
};
};
.....
pci0: pcie@ffe200000 {
reg = <0xf 0xfe200000 0 0x1000>;
ranges = <0x02000000 0 0x80000000 0xc 0x00000000 0x0 0x80000000
0x01000000 0 0x00000000 0xf 0xf8000000 0x0
0x00010000>;
pcie@0 {
ranges = <0x02000000 0 0x80000000
0x02000000 0 0x80000000
0 0x80000000
0x01000000 0 0x00000000
0x01000000 0 0x00000000
0 0x00010000>;
};
};
pci1: pcie@ffe201000 {
reg = <0xf 0xfe201000 0 0x1000>;
ranges = <0x02000000 0x0 0xe0000000 0xc 0x80000000 0x0
0x20000000
0x01000000 0x0 0x00000000 0xf 0xf8010000 0x0
0x00010000>;
pcie@0 {
ranges = <0x02000000 0 0xe0000000
0x02000000 0 0xe0000000
0 0x20000000
0x01000000 0 0x00000000
0x01000000 0 0x00000000
0 0x00010000>;
};
};
pci2: pcie@ffe202000 {
reg = <0xf 0xfe202000 0 0x1000>;
ranges = <0x02000000 0 0xe0000000 0xc 0xa0000000 0 0x20000000
0x01000000 0 0x00000000 0xf 0xf8020000 0 0x00010000>;
pcie@0 {
ranges = <0x02000000 0 0xe0000000
0x02000000 0 0xe0000000
0 0x20000000
0x01000000 0 0x00000000
0x01000000 0 0x00000000
0 0x00010000>;
};
};
.....
Any suggestions on how to get this to work?
Solved! Go to Solution.
You need to update U-Boot to program the LAWs according to your new memory map (as well as update U-Boot's ATMU settings so that U-Boot's own usage of PCI doesn't break) -- or add code to Linux to reprogram the LAWs. You should probably also keep it simple by leaving rapidio alone, and picking an address range that is currently unused (it doesn't need to have 0xc as the upper 4 bits).
When you say "doesn't boot", are there any messages on the console?
You need to update U-Boot to program the LAWs according to your new memory map (as well as update U-Boot's ATMU settings so that U-Boot's own usage of PCI doesn't break) -- or add code to Linux to reprogram the LAWs. You should probably also keep it simple by leaving rapidio alone, and picking an address range that is currently unused (it doesn't need to have 0xc as the upper 4 bits).
When you say "doesn't boot", are there any messages on the console?
Thanks. I had (incorrectly) assumed the Linux initialization was remapping the LAW and ATMU settings. I'll adjust the CONFIG_SYS_PCIE?_MEM_VIRT, _BUS, _PHYS, and _SIZE settings accordingly and rebuild u-boot. We aren't using rapdio in our design, though I wasn't sure if there were any other dependencies in other modules.
Is there a map of the used and unused ranges in the default RDB configurations (our design is based on the P2041RDB configuration files, with modifications for our specific setup)? I hadn't seen one in the documentation I had read. I can see that 0xc and 0xf are used, but wasn't sure what other ranges were available.
I was able to find more on the boot issue. We are using a PCIe based SATA controller and the system was generating a 'Machine check in kernel' when we tried to access it, causing a kernel panic. I hadn't been able to see that before as those messages were lost then the serial port buad rate changed to 9600 when ttyS0 was enabled and the bootconsole was disabled.
Many thanks for the help.
I think everything other than 0xc, 0xf, and whatever is taken by RAM are free. You can double check by looking at the LAW registers. Everything other than CCSR and boot space translation should go through a LAW.
The machine check is expected if the LAWs aren't set properly.