[U-Boot] how to trigger DM rescan ?
Hello,
i've following trouble on a new custom zynq board:
There is a axi4pcie root-complex implemented within the FPGA, i added this to my devicetree:
pci_express: axi-pcie@90000000 { #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; status = "disabled"; compatible = "xlnx,axi-pcie-host-1.00.a"; reg = < 0x90000000 0x1000000 >; device_type = "pci"; interrupts = < 0 116 4 >; interrupt-map-mask = <0 0 0 7>; interrupt-map = <0 0 0 1 &pcie_intc 1>, <0 0 0 2 &pcie_intc 2>, <0 0 0 3 &pcie_intc 3>, <0 0 0 4 &pcie_intc 4>; ranges = < 0x02000000 0 0x80000000 0x80000000 0 0x10000000 >;
pcie_intc: interrupt-controller { interrupt-controller; #address-cells = <0>; #interrupt-cells = <1>; }; };
As you can see the node is "disabled". For me this makes sense since during very first come up of u-boot the FPGA is not configured yet and the registers of the root-complex aren't accessible. Later on, during "board_init(...)" i bring up the FPGA (load bitstream from spi flash into FPGA) and set the fdt-node property status to "okay".
Trouble is that dm-scan, probe, ... is already done at this point and the root-complex is left ofter uninitialized and is not in the dm-tree at all (since it was disabled through first scan).
=> dm tree Class Probed Name ---------------------------------------- root [ + ] root_driver simple_bus [ + ] `-- amba gpio [ + ] |-- gpio@e000a000 i2c [ ] |-- i2c@e0004000 i2c [ + ] |-- i2c@e0005000 i2c_generic [ + ] | `-- generic_60 serial [ + ] |-- serial@e0000000 serial [ ] |-- serial@e0001000 spi [ + ] |-- spi@e000d000 spi_flash [ + ] | `-- spiflash@0 eth [ ] |-- ethernet@e000b000 mmc [ + ] |-- sdhci@e0100000 blk [ ] | `-- sdhci@e0100000.blk mmc [ + ] |-- sdhci@e0101000 blk [ ] | `-- sdhci@e0101000.blk simple_bus [ ] |-- slcr@f8000000 usb [ ] `-- usb@e0003000 =>
Is there a possibility to trigger a dm-scan after bringing up such new devices ? Or is it the wrong way having the node "disabled" first and enabled it later ? are there better ways to prevent accessing not yet ready devices from access ?
many thanks for your help and best regards, Hannes
Hi Simon,
forwarding this directly to you since nobody did response on the mailinglist. Maybe you have some suggestion to me.
many thanks, Hannes
-------- Forwarded Message -------- Subject: how to trigger DM rescan ? Date: Wed, 8 Feb 2017 08:05:31 +0100 From: Hannes Schmelzer hannes@schmelzer.or.at To: u-boot@lists.denx.de u-boot@lists.denx.de
Hello,
i've following trouble on a new custom zynq board:
There is a axi4pcie root-complex implemented within the FPGA, i added this to my devicetree:
pci_express: axi-pcie@90000000 { #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; status = "disabled"; compatible = "xlnx,axi-pcie-host-1.00.a"; reg = < 0x90000000 0x1000000 >; device_type = "pci"; interrupts = < 0 116 4 >; interrupt-map-mask = <0 0 0 7>; interrupt-map = <0 0 0 1 &pcie_intc 1>, <0 0 0 2 &pcie_intc 2>, <0 0 0 3 &pcie_intc 3>, <0 0 0 4 &pcie_intc 4>; ranges = < 0x02000000 0 0x80000000 0x80000000 0 0x10000000 >;
pcie_intc: interrupt-controller { interrupt-controller; #address-cells = <0>; #interrupt-cells = <1>; }; };
As you can see the node is "disabled". For me this makes sense since during very first come up of u-boot the FPGA is not configured yet and the registers of the root-complex aren't accessible. Later on, during "board_init(...)" i bring up the FPGA (load bitstream from spi flash into FPGA) and set the fdt-node property status to "okay".
Trouble is that dm-scan, probe, ... is already done at this point and the root-complex is left ofter uninitialized and is not in the dm-tree at all (since it was disabled through first scan).
=> dm tree Class Probed Name ---------------------------------------- root [ + ] root_driver simple_bus [ + ] `-- amba gpio [ + ] |-- gpio@e000a000 i2c [ ] |-- i2c@e0004000 i2c [ + ] |-- i2c@e0005000 i2c_generic [ + ] | `-- generic_60 serial [ + ] |-- serial@e0000000 serial [ ] |-- serial@e0001000 spi [ + ] |-- spi@e000d000 spi_flash [ + ] | `-- spiflash@0 eth [ ] |-- ethernet@e000b000 mmc [ + ] |-- sdhci@e0100000 blk [ ] | `-- sdhci@e0100000.blk mmc [ + ] |-- sdhci@e0101000 blk [ ] | `-- sdhci@e0101000.blk simple_bus [ ] |-- slcr@f8000000 usb [ ] `-- usb@e0003000 =>
Is there a possibility to trigger a dm-scan after bringing up such new devices ? Or is it the wrong way having the node "disabled" first and enabled it later ? are there better ways to prevent accessing not yet ready devices from access ?
many thanks for your help and best regards, Hannes
Hi Hannes,
On 13 February 2017 at 05:53, Hannes Schmelzer hannes@schmelzer.or.at wrote:
Hi Simon,
forwarding this directly to you since nobody did response on the mailinglist. Maybe you have some suggestion to me.
Yes, I tend to notice things that are cc'd to me :-)
many thanks, Hannes
-------- Forwarded Message -------- Subject: how to trigger DM rescan ? Date: Wed, 8 Feb 2017 08:05:31 +0100 From: Hannes Schmelzer hannes@schmelzer.or.at To: u-boot@lists.denx.de u-boot@lists.denx.de
Hello,
i've following trouble on a new custom zynq board:
There is a axi4pcie root-complex implemented within the FPGA, i added this to my devicetree:
pci_express: axi-pcie@90000000 { #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; status = "disabled"; compatible = "xlnx,axi-pcie-host-1.00.a"; reg = < 0x90000000 0x1000000 >; device_type = "pci"; interrupts = < 0 116 4 >; interrupt-map-mask = <0 0 0 7>; interrupt-map = <0 0 0 1 &pcie_intc 1>, <0 0 0 2 &pcie_intc 2>, <0 0 0 3 &pcie_intc 3>, <0 0 0 4 &pcie_intc 4>; ranges = < 0x02000000 0 0x80000000 0x80000000 0 0x10000000 >; pcie_intc: interrupt-controller { interrupt-controller; #address-cells = <0>; #interrupt-cells = <1>; }; };As you can see the node is "disabled". For me this makes sense since during very first come up of u-boot the FPGA is not configured yet and the registers of the root-complex aren't accessible. Later on, during "board_init(...)" i bring up the FPGA (load bitstream from spi flash into FPGA) and set the fdt-node property status to "okay".
Trouble is that dm-scan, probe, ... is already done at this point and the root-complex is left ofter uninitialized and is not in the dm-tree at all (since it was disabled through first scan).
=> dm tree Class Probed Name
root [ + ] root_driver simple_bus [ + ] `-- amba gpio [ + ] |-- gpio@e000a000 i2c [ ] |-- i2c@e0004000 i2c [ + ] |-- i2c@e0005000 i2c_generic [ + ] | `-- generic_60 serial [ + ] |-- serial@e0000000 serial [ ] |-- serial@e0001000 spi [ + ] |-- spi@e000d000 spi_flash [ + ] | `-- spiflash@0 eth [ ] |-- ethernet@e000b000 mmc [ + ] |-- sdhci@e0100000 blk [ ] | `-- sdhci@e0100000.blk mmc [ + ] |-- sdhci@e0101000 blk [ ] | `-- sdhci@e0101000.blk simple_bus [ ] |-- slcr@f8000000 usb [ ] `-- usb@e0003000 =>
Is there a possibility to trigger a dm-scan after bringing up such new devices ? Or is it the wrong way having the node "disabled" first and enabled it later ? are there better ways to prevent accessing not yet ready devices from access ?
You can call lists_bind_fdt() to handle this manually. Perhaps we should have a function like dm_node_enable() ?
many thanks for your help and best regards, Hannes
Regards, Simon
Hi Simon,
many thanks for the tip ... from actually point of view i think i can work with this. My PCIe root-complex now gets probed, but on enumeration of busses i get a data-abort, but thats a different story on which i have to debug.
best regards, Hannes
On 02/14/2017 06:23 AM, Simon Glass wrote:
Hi Hannes,
On 13 February 2017 at 05:53, Hannes Schmelzer hannes@schmelzer.or.at wrote:
Hi Simon,
forwarding this directly to you since nobody did response on the mailinglist. Maybe you have some suggestion to me.
Yes, I tend to notice things that are cc'd to me :-)
many thanks, Hannes
-------- Forwarded Message -------- Subject: how to trigger DM rescan ? Date: Wed, 8 Feb 2017 08:05:31 +0100 From: Hannes Schmelzer hannes@schmelzer.or.at To: u-boot@lists.denx.de u-boot@lists.denx.de
Hello,
i've following trouble on a new custom zynq board:
There is a axi4pcie root-complex implemented within the FPGA, i added this to my devicetree:
pci_express: axi-pcie@90000000 { #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; status = "disabled"; compatible = "xlnx,axi-pcie-host-1.00.a"; reg = < 0x90000000 0x1000000 >; device_type = "pci"; interrupts = < 0 116 4 >; interrupt-map-mask = <0 0 0 7>; interrupt-map = <0 0 0 1 &pcie_intc 1>, <0 0 0 2 &pcie_intc 2>, <0 0 0 3 &pcie_intc 3>, <0 0 0 4 &pcie_intc 4>; ranges = < 0x02000000 0 0x80000000 0x80000000 0 0x10000000 >; pcie_intc: interrupt-controller { interrupt-controller; #address-cells = <0>; #interrupt-cells = <1>; }; };As you can see the node is "disabled". For me this makes sense since during very first come up of u-boot the FPGA is not configured yet and the registers of the root-complex aren't accessible. Later on, during "board_init(...)" i bring up the FPGA (load bitstream from spi flash into FPGA) and set the fdt-node property status to "okay".
Trouble is that dm-scan, probe, ... is already done at this point and the root-complex is left ofter uninitialized and is not in the dm-tree at all (since it was disabled through first scan).
=> dm tree Class Probed Name
root [ + ] root_driver simple_bus [ + ] `-- amba gpio [ + ] |-- gpio@e000a000 i2c [ ] |-- i2c@e0004000 i2c [ + ] |-- i2c@e0005000 i2c_generic [ + ] | `-- generic_60 serial [ + ] |-- serial@e0000000 serial [ ] |-- serial@e0001000 spi [ + ] |-- spi@e000d000 spi_flash [ + ] | `-- spiflash@0 eth [ ] |-- ethernet@e000b000 mmc [ + ] |-- sdhci@e0100000 blk [ ] | `-- sdhci@e0100000.blk mmc [ + ] |-- sdhci@e0101000 blk [ ] | `-- sdhci@e0101000.blk simple_bus [ ] |-- slcr@f8000000 usb [ ] `-- usb@e0003000 =>
Is there a possibility to trigger a dm-scan after bringing up such new devices ? Or is it the wrong way having the node "disabled" first and enabled it later ? are there better ways to prevent accessing not yet ready devices from access ?
You can call lists_bind_fdt() to handle this manually. Perhaps we should have a function like dm_node_enable() ?
many thanks for your help and best regards, Hannes
Regards, Simon
participants (2)
-
Hannes Schmelzer -
Simon Glass