[U-Boot] how to trigger DM rescan ?
Hannes Schmelzer
hannes at schmelzer.or.at
Sun Feb 19 10:04:34 UTC 2017
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 at 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 at schmelzer.or.at>
>> To: u-boot at lists.denx.de <u-boot at 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 at 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 at e000a000
>> i2c [ ] |-- i2c at e0004000
>> i2c [ + ] |-- i2c at e0005000
>> i2c_generic [ + ] | `-- generic_60
>> serial [ + ] |-- serial at e0000000
>> serial [ ] |-- serial at e0001000
>> spi [ + ] |-- spi at e000d000
>> spi_flash [ + ] | `-- spiflash at 0
>> eth [ ] |-- ethernet at e000b000
>> mmc [ + ] |-- sdhci at e0100000
>> blk [ ] | `-- sdhci at e0100000.blk
>> mmc [ + ] |-- sdhci at e0101000
>> blk [ ] | `-- sdhci at e0101000.blk
>> simple_bus [ ] |-- slcr at f8000000
>> usb [ ] `-- usb at 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
>
>
More information about the U-Boot
mailing list