[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