Re: [U-Boot] [EXT] Re: Issues with driver binding and probing
Hi Simon,
From: Simon Glass
Sent: Friday, October 11, 2019 4:42 PM
To: Aaron Williams
Cc: Bin Meng ; u-boot@lists.denx.de
Subject: Re: [EXT] Re: [U-Boot] Issues with driver binding and probing
Hi Aaron,
On Wed, 25 Sep 2019 at 22:08, Aaron Williams wrote:
>
> Hi Simon,
>
> On Wednesday, September 25, 2019 8:40:48 PM PDT Bin Meng wrote:
> > External Email
> >
> > --
> > +Simon
> >
> > Hi Aaron,
> >
> > On Thu, Sep 26, 2019 at 11:10 AM Aaron Williams
> wrote:
> > > Hi all,
> > >
> > > I have an issue where I have a nexus driver and a sub serial driver on top
> > > of it. The base nexus driver is getting bound and probed properly,
> > > however the serial drivers (pci-console) below it are not.
> > >
> > > My device tree looks something like this:
> > > pci-console-nexus@0x0300 {
> > >
> > > /* Remote PCI console buffer location */
> > > compatible = "marvell,pci-console-nexus";
> >
> > Is this a PCI controller node?
> >
> No, actually it points to a location in memory which is shared by a PCI host
> with the software. It is a software only structure with no actual hardware
> behind it. We use this as a serial console across the PCI bus, but it's just
> shared memory. There is a nexus device then multiple consoles underneath it.
> U-Boot will initialize the data structures (if needed) and claim one of the
> consoles while it is use. The data structures may or may not already be
> initialized by earlier bootloaders or the ATF. The ATF may also claim one of
> the consoles.
What uclass is this node? Does that uclass have a post_bind method
that calls dm_scan_fdt_dev()?
The console is uclass-serial. I'm actually calling dm_scan_fdt_dev() in the
bind method. I will move it to a post-bind method.
>
> > > status = "okay";
> > > #address-cells = <2>;
> > > #size-cells = <1>;
> > > skip-init;
> > > num-consoles = <8>;
> > > reg = <0 0x0300 0 0x4>;
> > > ranges = <0 0 0 0x3000100 0x4000>,
> > >
> > > <1 0 0 0x3004100 0x4000>,
> > > <2 0 0 0x3008100 0x4000>,
> > > <3 0 0 0x300c100 0x4000>,
> > > <4 0 0 0x3010100 0x4000>,
> > > <5 0 0 0x3014100 0x4000>,
> > > <6 0 0 0x3018100 0x4000>,
> > > <7 0 0 0x301c100 0x4000>;
> > >
> > > console@0 {
> > >
> > > compatible = "marvell,pci-console";
> >
> > If this is a PCI device, it can be handled by the PCI codes.
> >
> > > status = "okay";
> > > reg = <0 0 0x4000>;
> > > tx-buffer-size = <0x2f80>;
> > > rx-buffer-size = <0x1000>;
> > >
> > > };
> > >
> > > ...
> > >
> > > console@7 {
> > >
> > > compatible = "marvell,pci-console";
> > > status = "okay";
> > > reg = <7 0 0x4000>;
> > > tx-buffer-size = <0x2f80>;
> > > rx-buffer-size = <0x1000>;
> > >
> > > };
> > >
> > > };
> > >
> > > When U-Boot binds the drivers it sees and binds pci-console-nexus but it
> > > never even attempts to go any deeper in the device tree. Both drivers are
> > > used. The nexus datastructure is a shared resouce that can be used by
> > > ATF.
> > >
> > > I added a bind function in the nexus driver that basically does:
> > > dev_for_each_subnode(node, parent) {
> > >
> > > ret = device_bind_driver_to_node(parent, DRIVER_NAME,
> > >
> > > ofnode_get_name(node), node,
> > > &dev);
> > >
> > > get_uclass(UCLASS_SERIAL, &uc);
> > > dev->uclass = uic;
> > >
> > > }
> > >
> > > With this I see the consoles in the dm tree and uclass list, but the
> > > sequences don't seem to be getting set.
> > >
> > > What I notice when I type dm uclass is:
> > > uclass 60: serial
> > > - * serial@87e02800 @ 7fbeb3360, seq 0, (req 0)
> > > - serial@87e02900 @ 7fbeb3430, seq -1, (req 1)
> > > - console@0 @ 7fbeb3660
> > > - console@1 @ 7fbeb3780
> > > - console@2 @ 7fbeb38a0
> > > - console@3 @ 7fbeb39c0
> > > - console@4 @ 7fbeb3ae0
> > > - console@5 @ 7fbeb3c00
> > > - console@6 @ 7fbeb3d20
> > > - console@7 @ 7fbeb3e40
> > > - * pci-bootcmd@0x03fff000 @ 7fbeb3f60, seq 1, (req -1)
> > >
> > > Does anyone have any ideas on how I should properly handle this? It seems
> > > that whatever I'm doing is overly complicated and I'm missing something
> > > for the DM layer to not go deeper into the tree past the nexus layer.
> > >
>
Re: [U-Boot] [EXT] Re: Issues with driver binding and probing
Hi Aaron,
On Wed, 16 Oct 2019 at 11:56, Aaron Williams wrote:
>
> Hi Simon,
>
> On Friday, October 11, 2019 4:42:55 PM PDT Simon Glass wrote:
> > Hi Aaron,
> >
> > On Wed, 25 Sep 2019 at 22:08, Aaron Williams wrote:
> > > Hi Simon,
> > >
> > > On Wednesday, September 25, 2019 8:40:48 PM PDT Bin Meng wrote:
> > > > External Email
> > > >
> > > > --
> > > > +Simon
> > > >
> > > > Hi Aaron,
> > > >
> > > > On Thu, Sep 26, 2019 at 11:10 AM Aaron Williams
> > >
> > > wrote:
> > > > > Hi all,
> > > > >
> > > > > I have an issue where I have a nexus driver and a sub serial driver on
> > > > > top
> > > > > of it. The base nexus driver is getting bound and probed properly,
> > > > > however the serial drivers (pci-console) below it are not.
> > > > >
> > > > > My device tree looks something like this:
> > > > > pci-console-nexus@0x0300 {
> > > > >
> > > > > /* Remote PCI console buffer location */
> > > > > compatible = "marvell,pci-console-nexus";
> > > >
> > > > Is this a PCI controller node?
> > >
> > > No, actually it points to a location in memory which is shared by a PCI
> > > host with the software. It is a software only structure with no actual
> > > hardware behind it. We use this as a serial console across the PCI bus,
> > > but it's just shared memory. There is a nexus device then multiple
> > > consoles underneath it. U-Boot will initialize the data structures (if
> > > needed) and claim one of the consoles while it is use. The data
> > > structures may or may not already be initialized by earlier bootloaders
> > > or the ATF. The ATF may also claim one of the consoles.
> >
> > What uclass is this node? Does that uclass have a post_bind method
> > that calls dm_scan_fdt_dev()?
> >
> > > > > status = "okay";
> > > > > #address-cells = <2>;
> > > > > #size-cells = <1>;
> > > > > skip-init;
> > > > > num-consoles = <8>;
> > > > > reg = <0 0x0300 0 0x4>;
> > > > > ranges = <0 0 0 0x3000100 0x4000>,
> > > > >
> > > > > <1 0 0 0x3004100 0x4000>,
> > > > > <2 0 0 0x3008100 0x4000>,
> > > > > <3 0 0 0x300c100 0x4000>,
> > > > > <4 0 0 0x3010100 0x4000>,
> > > > > <5 0 0 0x3014100 0x4000>,
> > > > > <6 0 0 0x3018100 0x4000>,
> > > > > <7 0 0 0x301c100 0x4000>;
> > > > >
> > > > > console@0 {
> > > > >
> > > > > compatible = "marvell,pci-console";
> > > >
> > > > If this is a PCI device, it can be handled by the PCI codes.
> > > >
> > > > > status = "okay";
> > > > > reg = <0 0 0x4000>;
> > > > > tx-buffer-size = <0x2f80>;
> > > > > rx-buffer-size = <0x1000>;
> > > > >
> > > > > };
> > > > >
> > > > > ...
> > > > >
> > > > > console@7 {
> > > > >
> > > > > compatible = "marvell,pci-console";
> > > > > status = "okay";
> > > > > reg = <7 0 0x4000>;
> > > > > tx-buffer-size = <0x2f80>;
> > > > > rx-buffer-size = <0x1000>;
> > > > >
> > > > > };
> > > > >
> > > > > };
> > > > >
> > > > > When U-Boot binds the drivers it sees and binds pci-console-nexus but
> > > > > it
> > > > > never even attempts to go any deeper in the device tree. Both drivers
> > > > > are
> > > > > used. The nexus datastructure is a shared resouce that can be used by
> > > > > ATF.
> > > > >
> > > > > I added a bind function in the nexus driver that basically does:
> > > > > dev_for_each_subnode(node, parent) {
> > > > >
> > > > > ret = device_bind_driver_to_node(parent, DRIVER_NAME,
> > > > >
> > > > > ofnode_get_name(node), node,
> > > > > &dev);
> > > > >
> > > > > get_uclass(UCLASS_SERIAL, &uc);
> > > > > dev->uclass = uic;
> > > > >
> > > > > }
> > > > >
> > > > > With this I see the consoles in the dm tree and uclass list, but the
> > > > > sequences don't seem to be getting set.
> > > > >
> > > > > What I notice when I type dm uclass is:
> > > > > uclass 60: serial
> > > > > - * serial@87e02800 @ 7fbeb3360, seq 0, (req 0)
> > > > > - serial@87e02900 @ 7fbeb3430, seq -1, (req 1)
> > > > > - console@0 @ 7fbeb3660
> > > > > - console@1 @ 7fbeb3780
> > > > > - console@2 @ 7fbeb38a0
> > > > > - console@3 @ 7fbeb39c0
> > > > > - console@4 @ 7fbeb3ae0
> > > > > - console@5 @ 7fbeb3c00
> > > > > - console@6 @ 7fbeb3d20
> > > > > - console@7 @ 7fbeb3e40
> > > > > - * pci-bootcmd@0x03
Re: [U-Boot] [EXT] Re: Issues with driver binding and probing
Hi Simon,
On Friday, October 11, 2019 4:42:55 PM PDT Simon Glass wrote:
> Hi Aaron,
>
> On Wed, 25 Sep 2019 at 22:08, Aaron Williams wrote:
> > Hi Simon,
> >
> > On Wednesday, September 25, 2019 8:40:48 PM PDT Bin Meng wrote:
> > > External Email
> > >
> > > --
> > > +Simon
> > >
> > > Hi Aaron,
> > >
> > > On Thu, Sep 26, 2019 at 11:10 AM Aaron Williams
> >
> > wrote:
> > > > Hi all,
> > > >
> > > > I have an issue where I have a nexus driver and a sub serial driver on
> > > > top
> > > > of it. The base nexus driver is getting bound and probed properly,
> > > > however the serial drivers (pci-console) below it are not.
> > > >
> > > > My device tree looks something like this:
> > > > pci-console-nexus@0x0300 {
> > > >
> > > > /* Remote PCI console buffer location */
> > > > compatible = "marvell,pci-console-nexus";
> > >
> > > Is this a PCI controller node?
> >
> > No, actually it points to a location in memory which is shared by a PCI
> > host with the software. It is a software only structure with no actual
> > hardware behind it. We use this as a serial console across the PCI bus,
> > but it's just shared memory. There is a nexus device then multiple
> > consoles underneath it. U-Boot will initialize the data structures (if
> > needed) and claim one of the consoles while it is use. The data
> > structures may or may not already be initialized by earlier bootloaders
> > or the ATF. The ATF may also claim one of the consoles.
>
> What uclass is this node? Does that uclass have a post_bind method
> that calls dm_scan_fdt_dev()?
>
> > > > status = "okay";
> > > > #address-cells = <2>;
> > > > #size-cells = <1>;
> > > > skip-init;
> > > > num-consoles = <8>;
> > > > reg = <0 0x0300 0 0x4>;
> > > > ranges = <0 0 0 0x3000100 0x4000>,
> > > >
> > > > <1 0 0 0x3004100 0x4000>,
> > > > <2 0 0 0x3008100 0x4000>,
> > > > <3 0 0 0x300c100 0x4000>,
> > > > <4 0 0 0x3010100 0x4000>,
> > > > <5 0 0 0x3014100 0x4000>,
> > > > <6 0 0 0x3018100 0x4000>,
> > > > <7 0 0 0x301c100 0x4000>;
> > > >
> > > > console@0 {
> > > >
> > > > compatible = "marvell,pci-console";
> > >
> > > If this is a PCI device, it can be handled by the PCI codes.
> > >
> > > > status = "okay";
> > > > reg = <0 0 0x4000>;
> > > > tx-buffer-size = <0x2f80>;
> > > > rx-buffer-size = <0x1000>;
> > > >
> > > > };
> > > >
> > > > ...
> > > >
> > > > console@7 {
> > > >
> > > > compatible = "marvell,pci-console";
> > > > status = "okay";
> > > > reg = <7 0 0x4000>;
> > > > tx-buffer-size = <0x2f80>;
> > > > rx-buffer-size = <0x1000>;
> > > >
> > > > };
> > > >
> > > > };
> > > >
> > > > When U-Boot binds the drivers it sees and binds pci-console-nexus but
> > > > it
> > > > never even attempts to go any deeper in the device tree. Both drivers
> > > > are
> > > > used. The nexus datastructure is a shared resouce that can be used by
> > > > ATF.
> > > >
> > > > I added a bind function in the nexus driver that basically does:
> > > > dev_for_each_subnode(node, parent) {
> > > >
> > > > ret = device_bind_driver_to_node(parent, DRIVER_NAME,
> > > >
> > > > ofnode_get_name(node), node,
> > > > &dev);
> > > >
> > > > get_uclass(UCLASS_SERIAL, &uc);
> > > > dev->uclass = uic;
> > > >
> > > > }
> > > >
> > > > With this I see the consoles in the dm tree and uclass list, but the
> > > > sequences don't seem to be getting set.
> > > >
> > > > What I notice when I type dm uclass is:
> > > > uclass 60: serial
> > > > - * serial@87e02800 @ 7fbeb3360, seq 0, (req 0)
> > > > - serial@87e02900 @ 7fbeb3430, seq -1, (req 1)
> > > > - console@0 @ 7fbeb3660
> > > > - console@1 @ 7fbeb3780
> > > > - console@2 @ 7fbeb38a0
> > > > - console@3 @ 7fbeb39c0
> > > > - console@4 @ 7fbeb3ae0
> > > > - console@5 @ 7fbeb3c00
> > > > - console@6 @ 7fbeb3d20
> > > > - console@7 @ 7fbeb3e40
> > > > - * pci-bootcmd@0x03fff000 @ 7fbeb3f60, seq 1, (req -1)
> > > >
> > > > Does anyone have any ideas on how I should properly handle this? It
> >
Re: [U-Boot] [EXT] Re: Issues with driver binding and probing
Hi Aaron,
On Wed, 25 Sep 2019 at 22:08, Aaron Williams wrote:
>
> Hi Simon,
>
> On Wednesday, September 25, 2019 8:40:48 PM PDT Bin Meng wrote:
> > External Email
> >
> > --
> > +Simon
> >
> > Hi Aaron,
> >
> > On Thu, Sep 26, 2019 at 11:10 AM Aaron Williams
> wrote:
> > > Hi all,
> > >
> > > I have an issue where I have a nexus driver and a sub serial driver on top
> > > of it. The base nexus driver is getting bound and probed properly,
> > > however the serial drivers (pci-console) below it are not.
> > >
> > > My device tree looks something like this:
> > > pci-console-nexus@0x0300 {
> > >
> > > /* Remote PCI console buffer location */
> > > compatible = "marvell,pci-console-nexus";
> >
> > Is this a PCI controller node?
> >
> No, actually it points to a location in memory which is shared by a PCI host
> with the software. It is a software only structure with no actual hardware
> behind it. We use this as a serial console across the PCI bus, but it's just
> shared memory. There is a nexus device then multiple consoles underneath it.
> U-Boot will initialize the data structures (if needed) and claim one of the
> consoles while it is use. The data structures may or may not already be
> initialized by earlier bootloaders or the ATF. The ATF may also claim one of
> the consoles.
What uclass is this node? Does that uclass have a post_bind method
that calls dm_scan_fdt_dev()?
>
> > > status = "okay";
> > > #address-cells = <2>;
> > > #size-cells = <1>;
> > > skip-init;
> > > num-consoles = <8>;
> > > reg = <0 0x0300 0 0x4>;
> > > ranges = <0 0 0 0x3000100 0x4000>,
> > >
> > > <1 0 0 0x3004100 0x4000>,
> > > <2 0 0 0x3008100 0x4000>,
> > > <3 0 0 0x300c100 0x4000>,
> > > <4 0 0 0x3010100 0x4000>,
> > > <5 0 0 0x3014100 0x4000>,
> > > <6 0 0 0x3018100 0x4000>,
> > > <7 0 0 0x301c100 0x4000>;
> > >
> > > console@0 {
> > >
> > > compatible = "marvell,pci-console";
> >
> > If this is a PCI device, it can be handled by the PCI codes.
> >
> > > status = "okay";
> > > reg = <0 0 0x4000>;
> > > tx-buffer-size = <0x2f80>;
> > > rx-buffer-size = <0x1000>;
> > >
> > > };
> > >
> > > ...
> > >
> > > console@7 {
> > >
> > > compatible = "marvell,pci-console";
> > > status = "okay";
> > > reg = <7 0 0x4000>;
> > > tx-buffer-size = <0x2f80>;
> > > rx-buffer-size = <0x1000>;
> > >
> > > };
> > >
> > > };
> > >
> > > When U-Boot binds the drivers it sees and binds pci-console-nexus but it
> > > never even attempts to go any deeper in the device tree. Both drivers are
> > > used. The nexus datastructure is a shared resouce that can be used by
> > > ATF.
> > >
> > > I added a bind function in the nexus driver that basically does:
> > > dev_for_each_subnode(node, parent) {
> > >
> > > ret = device_bind_driver_to_node(parent, DRIVER_NAME,
> > >
> > > ofnode_get_name(node), node,
> > > &dev);
> > >
> > > get_uclass(UCLASS_SERIAL, &uc);
> > > dev->uclass = uic;
> > >
> > > }
> > >
> > > With this I see the consoles in the dm tree and uclass list, but the
> > > sequences don't seem to be getting set.
> > >
> > > What I notice when I type dm uclass is:
> > > uclass 60: serial
> > > - * serial@87e02800 @ 7fbeb3360, seq 0, (req 0)
> > > - serial@87e02900 @ 7fbeb3430, seq -1, (req 1)
> > > - console@0 @ 7fbeb3660
> > > - console@1 @ 7fbeb3780
> > > - console@2 @ 7fbeb38a0
> > > - console@3 @ 7fbeb39c0
> > > - console@4 @ 7fbeb3ae0
> > > - console@5 @ 7fbeb3c00
> > > - console@6 @ 7fbeb3d20
> > > - console@7 @ 7fbeb3e40
> > > - * pci-bootcmd@0x03fff000 @ 7fbeb3f60, seq 1, (req -1)
> > >
> > > Does anyone have any ideas on how I should properly handle this? It seems
> > > that whatever I'm doing is overly complicated and I'm missing something
> > > for the DM layer to not go deeper into the tree past the nexus layer.
> > >
> > > static const struct udevice_id octeontx_pcie_console_nexus_serial_id[] = {
> > >
> > > { .compatible = "marvell,pci-console-nexus", },
> > > { },
> > >
> > > };
> > >
> > > U_BOOT_DRIVER(octeontx_pcie_console_nexus) = {
> > >
> > > .name = DRIVER_NAME "-nexus",
> > > .id = UCLASS_MISC,
> > > .flags = DM_FLAG_PRE_RE
Re: [U-Boot] [EXT] Re: Issues with driver binding and probing
Hi Simon,
On Wednesday, September 25, 2019 8:40:48 PM PDT Bin Meng wrote:
> External Email
>
> --
> +Simon
>
> Hi Aaron,
>
> On Thu, Sep 26, 2019 at 11:10 AM Aaron Williams
wrote:
> > Hi all,
> >
> > I have an issue where I have a nexus driver and a sub serial driver on top
> > of it. The base nexus driver is getting bound and probed properly,
> > however the serial drivers (pci-console) below it are not.
> >
> > My device tree looks something like this:
> > pci-console-nexus@0x0300 {
> >
> > /* Remote PCI console buffer location */
> > compatible = "marvell,pci-console-nexus";
>
> Is this a PCI controller node?
>
No, actually it points to a location in memory which is shared by a PCI host
with the software. It is a software only structure with no actual hardware
behind it. We use this as a serial console across the PCI bus, but it's just
shared memory. There is a nexus device then multiple consoles underneath it.
U-Boot will initialize the data structures (if needed) and claim one of the
consoles while it is use. The data structures may or may not already be
initialized by earlier bootloaders or the ATF. The ATF may also claim one of
the consoles.
> > status = "okay";
> > #address-cells = <2>;
> > #size-cells = <1>;
> > skip-init;
> > num-consoles = <8>;
> > reg = <0 0x0300 0 0x4>;
> > ranges = <0 0 0 0x3000100 0x4000>,
> >
> > <1 0 0 0x3004100 0x4000>,
> > <2 0 0 0x3008100 0x4000>,
> > <3 0 0 0x300c100 0x4000>,
> > <4 0 0 0x3010100 0x4000>,
> > <5 0 0 0x3014100 0x4000>,
> > <6 0 0 0x3018100 0x4000>,
> > <7 0 0 0x301c100 0x4000>;
> >
> > console@0 {
> >
> > compatible = "marvell,pci-console";
>
> If this is a PCI device, it can be handled by the PCI codes.
>
> > status = "okay";
> > reg = <0 0 0x4000>;
> > tx-buffer-size = <0x2f80>;
> > rx-buffer-size = <0x1000>;
> >
> > };
> >
> > ...
> >
> > console@7 {
> >
> > compatible = "marvell,pci-console";
> > status = "okay";
> > reg = <7 0 0x4000>;
> > tx-buffer-size = <0x2f80>;
> > rx-buffer-size = <0x1000>;
> >
> > };
> >
> > };
> >
> > When U-Boot binds the drivers it sees and binds pci-console-nexus but it
> > never even attempts to go any deeper in the device tree. Both drivers are
> > used. The nexus datastructure is a shared resouce that can be used by
> > ATF.
> >
> > I added a bind function in the nexus driver that basically does:
> > dev_for_each_subnode(node, parent) {
> >
> > ret = device_bind_driver_to_node(parent, DRIVER_NAME,
> >
> > ofnode_get_name(node), node,
> > &dev);
> >
> > get_uclass(UCLASS_SERIAL, &uc);
> > dev->uclass = uic;
> >
> > }
> >
> > With this I see the consoles in the dm tree and uclass list, but the
> > sequences don't seem to be getting set.
> >
> > What I notice when I type dm uclass is:
> > uclass 60: serial
> > - * serial@87e02800 @ 7fbeb3360, seq 0, (req 0)
> > - serial@87e02900 @ 7fbeb3430, seq -1, (req 1)
> > - console@0 @ 7fbeb3660
> > - console@1 @ 7fbeb3780
> > - console@2 @ 7fbeb38a0
> > - console@3 @ 7fbeb39c0
> > - console@4 @ 7fbeb3ae0
> > - console@5 @ 7fbeb3c00
> > - console@6 @ 7fbeb3d20
> > - console@7 @ 7fbeb3e40
> > - * pci-bootcmd@0x03fff000 @ 7fbeb3f60, seq 1, (req -1)
> >
> > Does anyone have any ideas on how I should properly handle this? It seems
> > that whatever I'm doing is overly complicated and I'm missing something
> > for the DM layer to not go deeper into the tree past the nexus layer.
> >
> > static const struct udevice_id octeontx_pcie_console_nexus_serial_id[] = {
> >
> > { .compatible = "marvell,pci-console-nexus", },
> > { },
> >
> > };
> >
> > U_BOOT_DRIVER(octeontx_pcie_console_nexus) = {
> >
> > .name = DRIVER_NAME "-nexus",
> > .id = UCLASS_MISC,
> > .flags = DM_FLAG_PRE_RELOC,
> > .of_match = of_match_ptr(octeontx_pcie_console_nexus_serial_id),
> > .ofdata_to_platdata =
> >
> > octeontx_pcie_console_nexus_ofdata_to_platdata,
> >
> >
