Device tree modifications for PCIe on P2041

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Device tree modifications for PCIe on P2041

Jump to solution
2,549 Views
matthewh
Contributor I

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?


Labels (1)
0 Kudos
1 Solution
1,142 Views
scottwood
NXP Employee
NXP Employee

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?

View solution in original post

0 Kudos
3 Replies
1,143 Views
scottwood
NXP Employee
NXP Employee

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?

0 Kudos
1,142 Views
matthewh
Contributor I

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.

0 Kudos
1,142 Views
scottwood
NXP Employee
NXP Employee

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.

0 Kudos