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