Re: Testing pci_mvebu.c with Kirkwood SoCs
On Tuesday 14 December 2021 14:36:48 Tony Dinh wrote: > Hi Pali, > > On Tue, Dec 14, 2021 at 6:33 AM Pali Rohár wrote: > > > > On Saturday 11 December 2021 13:24:07 Tony Dinh wrote: > > > Hi Pali, > > > > > > On Sat, Dec 11, 2021 at 7:39 AM Pali Rohár wrote: > > > > > > > > On Tuesday 16 November 2021 15:02:48 Tony Dinh wrote: > > > > > Hi Pali, > > > > > > > > > > On Tue, Nov 16, 2021 at 2:37 PM Pali Rohár wrote: > > > > > > > > > > > > On Tuesday 16 November 2021 14:26:56 Tony Dinh wrote: > > > > > > > Hi Pali, > > > > > > > > > > > > > > While we are at it, this default should be changed in > > > > > > > drivers/usb/host/Kconfig. > > > > > > > > > > > > > > config USB_XHCI_MVEBU > > > > > > > bool "MVEBU USB 3.0 support" > > > > > > > default y > > > > > > > > > > > > > > Setting this default correctly will save a couple Kbytes for > > > > > > > other boards. > > > > > > > default y if ARCH_MVEBU > > > > > > > > > > > > Hello! USB_XHCI_MVEBU has currently "depends on ARCH_MVEBU" which > > > > > > means > > > > > > that USB_XHCI_MVEBU cannot be enabled when ARCH_MVEBU is disabled. > > > > > > So > > > > > > "default y if ARCH_MVEBU" is same as "default y". > > > > > > > > > > Ah, thanks. This "depends on ARCH_MVEBU" was added in the latest > > > > > master tree. I'm switching back and forth between the 2021.10 tag and > > > > > master so I did not see this in the 2021.10 tree. > > > > > > > > Hello! Are you planning to send patches which add support for your > > > > kirkwood board into mainline U-Boot? > > > > > > > > I would like to know if we should take care about that PCIe kirkwood > > > > support as currently there is no board in mainline U-Boot which use PCIe > > > > on kirkwood SoC. > > > > > > Yes, I plan to submit patches for the Pogoplug V4 (new board), and the > > > Iomega iConnect board (update). So far the Pogoplug V4 PCIe is working > > > perfectly with your in-progress patches. > > > > Ok! Because I'm going to do more changes in pci_mvebu.c driver and > > kirkwood patch which I have sent to you would not work anymore. > > OK! I have been testing my Pogoplug V4 patch series (almost done). > Sounds like I should wait for your new patch to do more testing? Well, you do not need to wait. If you know that it is working fine, you can send patches. I will then modify both mvebu and kirkwood code and send you my new modifications / cleanups. > Thanks, > Tony > > > > > > > > > > > If you have mvebu board when mvebu xhci controller is unused, you > > > > > > can > > > > > > disable this option and save some space. I see that other xhci > > > > > > drivers > > > > > > have also "default y" so seems that this is the standard default > > > > > > option.
Re: Testing pci_mvebu.c with Kirkwood SoCs
Hi Pali, On Tue, Dec 14, 2021 at 6:33 AM Pali Rohár wrote: > > On Saturday 11 December 2021 13:24:07 Tony Dinh wrote: > > Hi Pali, > > > > On Sat, Dec 11, 2021 at 7:39 AM Pali Rohár wrote: > > > > > > On Tuesday 16 November 2021 15:02:48 Tony Dinh wrote: > > > > Hi Pali, > > > > > > > > On Tue, Nov 16, 2021 at 2:37 PM Pali Rohár wrote: > > > > > > > > > > On Tuesday 16 November 2021 14:26:56 Tony Dinh wrote: > > > > > > Hi Pali, > > > > > > > > > > > > While we are at it, this default should be changed in > > > > > > drivers/usb/host/Kconfig. > > > > > > > > > > > > config USB_XHCI_MVEBU > > > > > > bool "MVEBU USB 3.0 support" > > > > > > default y > > > > > > > > > > > > Setting this default correctly will save a couple Kbytes for other > > > > > > boards. > > > > > > default y if ARCH_MVEBU > > > > > > > > > > Hello! USB_XHCI_MVEBU has currently "depends on ARCH_MVEBU" which > > > > > means > > > > > that USB_XHCI_MVEBU cannot be enabled when ARCH_MVEBU is disabled. So > > > > > "default y if ARCH_MVEBU" is same as "default y". > > > > > > > > Ah, thanks. This "depends on ARCH_MVEBU" was added in the latest > > > > master tree. I'm switching back and forth between the 2021.10 tag and > > > > master so I did not see this in the 2021.10 tree. > > > > > > Hello! Are you planning to send patches which add support for your > > > kirkwood board into mainline U-Boot? > > > > > > I would like to know if we should take care about that PCIe kirkwood > > > support as currently there is no board in mainline U-Boot which use PCIe > > > on kirkwood SoC. > > > > Yes, I plan to submit patches for the Pogoplug V4 (new board), and the > > Iomega iConnect board (update). So far the Pogoplug V4 PCIe is working > > perfectly with your in-progress patches. > > Ok! Because I'm going to do more changes in pci_mvebu.c driver and > kirkwood patch which I have sent to you would not work anymore. OK! I have been testing my Pogoplug V4 patch series (almost done). Sounds like I should wait for your new patch to do more testing? Thanks, Tony > > > > > > > > > If you have mvebu board when mvebu xhci controller is unused, you can > > > > > disable this option and save some space. I see that other xhci drivers > > > > > have also "default y" so seems that this is the standard default > > > > > option.
Re: Testing pci_mvebu.c with Kirkwood SoCs
On Saturday 11 December 2021 13:24:07 Tony Dinh wrote: > Hi Pali, > > On Sat, Dec 11, 2021 at 7:39 AM Pali Rohár wrote: > > > > On Tuesday 16 November 2021 15:02:48 Tony Dinh wrote: > > > Hi Pali, > > > > > > On Tue, Nov 16, 2021 at 2:37 PM Pali Rohár wrote: > > > > > > > > On Tuesday 16 November 2021 14:26:56 Tony Dinh wrote: > > > > > Hi Pali, > > > > > > > > > > While we are at it, this default should be changed in > > > > > drivers/usb/host/Kconfig. > > > > > > > > > > config USB_XHCI_MVEBU > > > > > bool "MVEBU USB 3.0 support" > > > > > default y > > > > > > > > > > Setting this default correctly will save a couple Kbytes for other > > > > > boards. > > > > > default y if ARCH_MVEBU > > > > > > > > Hello! USB_XHCI_MVEBU has currently "depends on ARCH_MVEBU" which means > > > > that USB_XHCI_MVEBU cannot be enabled when ARCH_MVEBU is disabled. So > > > > "default y if ARCH_MVEBU" is same as "default y". > > > > > > Ah, thanks. This "depends on ARCH_MVEBU" was added in the latest > > > master tree. I'm switching back and forth between the 2021.10 tag and > > > master so I did not see this in the 2021.10 tree. > > > > Hello! Are you planning to send patches which add support for your > > kirkwood board into mainline U-Boot? > > > > I would like to know if we should take care about that PCIe kirkwood > > support as currently there is no board in mainline U-Boot which use PCIe > > on kirkwood SoC. > > Yes, I plan to submit patches for the Pogoplug V4 (new board), and the > Iomega iConnect board (update). So far the Pogoplug V4 PCIe is working > perfectly with your in-progress patches. Ok! Because I'm going to do more changes in pci_mvebu.c driver and kirkwood patch which I have sent to you would not work anymore. > Thanks, > Tony > > > > Thanks, > > > Tony > > > > > > > If you have mvebu board when mvebu xhci controller is unused, you can > > > > disable this option and save some space. I see that other xhci drivers > > > > have also "default y" so seems that this is the standard default option.
Re: Testing pci_mvebu.c with Kirkwood SoCs
Hi Pali, On Sat, Dec 11, 2021 at 7:39 AM Pali Rohár wrote: > > On Tuesday 16 November 2021 15:02:48 Tony Dinh wrote: > > Hi Pali, > > > > On Tue, Nov 16, 2021 at 2:37 PM Pali Rohár wrote: > > > > > > On Tuesday 16 November 2021 14:26:56 Tony Dinh wrote: > > > > Hi Pali, > > > > > > > > While we are at it, this default should be changed in > > > > drivers/usb/host/Kconfig. > > > > > > > > config USB_XHCI_MVEBU > > > > bool "MVEBU USB 3.0 support" > > > > default y > > > > > > > > Setting this default correctly will save a couple Kbytes for other > > > > boards. > > > > default y if ARCH_MVEBU > > > > > > Hello! USB_XHCI_MVEBU has currently "depends on ARCH_MVEBU" which means > > > that USB_XHCI_MVEBU cannot be enabled when ARCH_MVEBU is disabled. So > > > "default y if ARCH_MVEBU" is same as "default y". > > > > Ah, thanks. This "depends on ARCH_MVEBU" was added in the latest > > master tree. I'm switching back and forth between the 2021.10 tag and > > master so I did not see this in the 2021.10 tree. > > Hello! Are you planning to send patches which add support for your > kirkwood board into mainline U-Boot? > > I would like to know if we should take care about that PCIe kirkwood > support as currently there is no board in mainline U-Boot which use PCIe > on kirkwood SoC. Yes, I plan to submit patches for the Pogoplug V4 (new board), and the Iomega iConnect board (update). So far the Pogoplug V4 PCIe is working perfectly with your in-progress patches. Thanks, Tony > > Thanks, > > Tony > > > > > If you have mvebu board when mvebu xhci controller is unused, you can > > > disable this option and save some space. I see that other xhci drivers > > > have also "default y" so seems that this is the standard default option.
Re: Testing pci_mvebu.c with Kirkwood SoCs
On Tuesday 16 November 2021 15:02:48 Tony Dinh wrote: > Hi Pali, > > On Tue, Nov 16, 2021 at 2:37 PM Pali Rohár wrote: > > > > On Tuesday 16 November 2021 14:26:56 Tony Dinh wrote: > > > Hi Pali, > > > > > > While we are at it, this default should be changed in > > > drivers/usb/host/Kconfig. > > > > > > config USB_XHCI_MVEBU > > > bool "MVEBU USB 3.0 support" > > > default y > > > > > > Setting this default correctly will save a couple Kbytes for other boards. > > > default y if ARCH_MVEBU > > > > Hello! USB_XHCI_MVEBU has currently "depends on ARCH_MVEBU" which means > > that USB_XHCI_MVEBU cannot be enabled when ARCH_MVEBU is disabled. So > > "default y if ARCH_MVEBU" is same as "default y". > > Ah, thanks. This "depends on ARCH_MVEBU" was added in the latest > master tree. I'm switching back and forth between the 2021.10 tag and > master so I did not see this in the 2021.10 tree. Hello! Are you planning to send patches which add support for your kirkwood board into mainline U-Boot? I would like to know if we should take care about that PCIe kirkwood support as currently there is no board in mainline U-Boot which use PCIe on kirkwood SoC. > Thanks, > Tony > > > If you have mvebu board when mvebu xhci controller is unused, you can > > disable this option and save some space. I see that other xhci drivers > > have also "default y" so seems that this is the standard default option.
Re: Testing pci_mvebu.c with Kirkwood SoCs
Hi Pali, On Tue, Nov 16, 2021 at 2:37 PM Pali Rohár wrote: > > On Tuesday 16 November 2021 14:26:56 Tony Dinh wrote: > > Hi Pali, > > > > While we are at it, this default should be changed in > > drivers/usb/host/Kconfig. > > > > config USB_XHCI_MVEBU > > bool "MVEBU USB 3.0 support" > > default y > > > > Setting this default correctly will save a couple Kbytes for other boards. > > default y if ARCH_MVEBU > > Hello! USB_XHCI_MVEBU has currently "depends on ARCH_MVEBU" which means > that USB_XHCI_MVEBU cannot be enabled when ARCH_MVEBU is disabled. So > "default y if ARCH_MVEBU" is same as "default y". Ah, thanks. This "depends on ARCH_MVEBU" was added in the latest master tree. I'm switching back and forth between the 2021.10 tag and master so I did not see this in the 2021.10 tree. Thanks, Tony > If you have mvebu board when mvebu xhci controller is unused, you can > disable this option and save some space. I see that other xhci drivers > have also "default y" so seems that this is the standard default option.
Re: Testing pci_mvebu.c with Kirkwood SoCs
On Tuesday 16 November 2021 14:26:56 Tony Dinh wrote: > Hi Pali, > > While we are at it, this default should be changed in > drivers/usb/host/Kconfig. > > config USB_XHCI_MVEBU > bool "MVEBU USB 3.0 support" > default y > > Setting this default correctly will save a couple Kbytes for other boards. > default y if ARCH_MVEBU Hello! USB_XHCI_MVEBU has currently "depends on ARCH_MVEBU" which means that USB_XHCI_MVEBU cannot be enabled when ARCH_MVEBU is disabled. So "default y if ARCH_MVEBU" is same as "default y". If you have mvebu board when mvebu xhci controller is unused, you can disable this option and save some space. I see that other xhci drivers have also "default y" so seems that this is the standard default option.
Re: Testing pci_mvebu.c with Kirkwood SoCs
Hi Pali, While we are at it, this default should be changed in drivers/usb/host/Kconfig. config USB_XHCI_MVEBU bool "MVEBU USB 3.0 support" default y Setting this default correctly will save a couple Kbytes for other boards. default y if ARCH_MVEBU Thanks, Tony On Fri, Nov 12, 2021 at 3:24 PM Tony Dinh wrote: > > On Fri, Nov 12, 2021 at 2:42 PM Pali Rohár wrote: > > > > On Friday 12 November 2021 13:46:29 Tony Dinh wrote: > > > Hi Stefan & Pali, > > > > > > On Fri, Nov 12, 2021 at 7:06 AM Pali Rohár wrote: > > > > > > > > On Friday 12 November 2021 15:36:31 Stefan Roese wrote: > > > > > On 11/11/21 22:10, Pali Rohár wrote: > > > > > > On Wednesday 10 November 2021 16:04:20 Tony Dinh wrote: > > > > > > > I've also tried mdelay(3000), just to be sure. The result was the > > > > > > > same > > > > > > > hang in 'usb start'. > > > > > > > > > > > > Ok. So put pci_init() into board_late_init(). > > > > > > > > > > > > There are some more cleanup and fixes patches for pci_mvebu.c on > > > > > > mailing > > > > > > list. After they are merged I will prepare and send final PCI > > > > > > Kirkwood > > > > > > patch for testing. > > > > > > > > > > Chiming in a bit late in this discussion: > > > > > > > > > > Is an explicit call to pci_init() necessary in this Kirwood case? > > > > > IIRC, > > > > > the DM infrastructure should make sure that all device are probed - > > > > > but > > > > > only when really needed. So if you don't need PCI in the boot process > > > > > at all, then it's not probed at all. Or if you set CONFIG_PCI_PNP this > > > > > will be done always. Then there should be no need for the additional > > > > > "pci enum". > > > > > > > > CONFIG_PCI_PNP probe and initialize all devices behind host bridge. > > > > CONFIG_PCI_INIT_R probe and initialize host bridge (this is done by > > > > calling pci_init()). Based on tests (see discussion in this thread) it > > > > looks like that CONFIG_PCI_INIT_R calls pci_init() too early and > > > > initialization is failing. So unsetting CONFIG_PCI_INIT_R and calling > > > > pci_init() manually from board_late_init() (which is called later than > > > > CONFIG_PCI_INIT_R) seems to fix these issues. No idea why... > > > > > I might be missing something - did not check in depth. > > > > > > I think this must be the problem. Sorry I've missed this: > > > > > > config USB_XHCI_MVEBU > > > bool "MVEBU USB 3.0 support" > > > default y > > > depends on ARCH_MVEBU > > > select DM_REGULATOR > > > help > > > Choose this option to add support for USB 3.0 driver on mvebu > > > SoCs, which includes Armada8K, Armada3700 and other Armada > > > family SoCs. > > > > This is used for native USB 3.0 controller in Marvell SoC (connected via > > serdes). > > > > But you wrote and sent pci output, that you have PCIe-based USB > > controller connected via PCIe. > > Ah, got it. > > Thanks, > Tony > > > > So I'll need rebuild with "depends on (ARCH_MVEBU || ARCH_KIRKWOOD)" > > > and do some more testing. > > > > > > Thanks, > > > Tony > > > > > > > > > > > > > Thanks, > > > > > Stefan
Re: Testing pci_mvebu.c with Kirkwood SoCs
On Fri, Nov 12, 2021 at 2:42 PM Pali Rohár wrote: > > On Friday 12 November 2021 13:46:29 Tony Dinh wrote: > > Hi Stefan & Pali, > > > > On Fri, Nov 12, 2021 at 7:06 AM Pali Rohár wrote: > > > > > > On Friday 12 November 2021 15:36:31 Stefan Roese wrote: > > > > On 11/11/21 22:10, Pali Rohár wrote: > > > > > On Wednesday 10 November 2021 16:04:20 Tony Dinh wrote: > > > > > > I've also tried mdelay(3000), just to be sure. The result was the > > > > > > same > > > > > > hang in 'usb start'. > > > > > > > > > > Ok. So put pci_init() into board_late_init(). > > > > > > > > > > There are some more cleanup and fixes patches for pci_mvebu.c on > > > > > mailing > > > > > list. After they are merged I will prepare and send final PCI Kirkwood > > > > > patch for testing. > > > > > > > > Chiming in a bit late in this discussion: > > > > > > > > Is an explicit call to pci_init() necessary in this Kirwood case? IIRC, > > > > the DM infrastructure should make sure that all device are probed - but > > > > only when really needed. So if you don't need PCI in the boot process > > > > at all, then it's not probed at all. Or if you set CONFIG_PCI_PNP this > > > > will be done always. Then there should be no need for the additional > > > > "pci enum". > > > > > > CONFIG_PCI_PNP probe and initialize all devices behind host bridge. > > > CONFIG_PCI_INIT_R probe and initialize host bridge (this is done by > > > calling pci_init()). Based on tests (see discussion in this thread) it > > > looks like that CONFIG_PCI_INIT_R calls pci_init() too early and > > > initialization is failing. So unsetting CONFIG_PCI_INIT_R and calling > > > pci_init() manually from board_late_init() (which is called later than > > > CONFIG_PCI_INIT_R) seems to fix these issues. No idea why... > > > > I might be missing something - did not check in depth. > > > > I think this must be the problem. Sorry I've missed this: > > > > config USB_XHCI_MVEBU > > bool "MVEBU USB 3.0 support" > > default y > > depends on ARCH_MVEBU > > select DM_REGULATOR > > help > > Choose this option to add support for USB 3.0 driver on mvebu > > SoCs, which includes Armada8K, Armada3700 and other Armada > > family SoCs. > > This is used for native USB 3.0 controller in Marvell SoC (connected via > serdes). > > But you wrote and sent pci output, that you have PCIe-based USB > controller connected via PCIe. Ah, got it. Thanks, Tony > > So I'll need rebuild with "depends on (ARCH_MVEBU || ARCH_KIRKWOOD)" > > and do some more testing. > > > > Thanks, > > Tony > > > > > > > > > > Thanks, > > > > Stefan
Re: Testing pci_mvebu.c with Kirkwood SoCs
On Friday 12 November 2021 13:46:29 Tony Dinh wrote: > Hi Stefan & Pali, > > On Fri, Nov 12, 2021 at 7:06 AM Pali Rohár wrote: > > > > On Friday 12 November 2021 15:36:31 Stefan Roese wrote: > > > On 11/11/21 22:10, Pali Rohár wrote: > > > > On Wednesday 10 November 2021 16:04:20 Tony Dinh wrote: > > > > > I've also tried mdelay(3000), just to be sure. The result was the same > > > > > hang in 'usb start'. > > > > > > > > Ok. So put pci_init() into board_late_init(). > > > > > > > > There are some more cleanup and fixes patches for pci_mvebu.c on mailing > > > > list. After they are merged I will prepare and send final PCI Kirkwood > > > > patch for testing. > > > > > > Chiming in a bit late in this discussion: > > > > > > Is an explicit call to pci_init() necessary in this Kirwood case? IIRC, > > > the DM infrastructure should make sure that all device are probed - but > > > only when really needed. So if you don't need PCI in the boot process > > > at all, then it's not probed at all. Or if you set CONFIG_PCI_PNP this > > > will be done always. Then there should be no need for the additional > > > "pci enum". > > > > CONFIG_PCI_PNP probe and initialize all devices behind host bridge. > > CONFIG_PCI_INIT_R probe and initialize host bridge (this is done by > > calling pci_init()). Based on tests (see discussion in this thread) it > > looks like that CONFIG_PCI_INIT_R calls pci_init() too early and > > initialization is failing. So unsetting CONFIG_PCI_INIT_R and calling > > pci_init() manually from board_late_init() (which is called later than > > CONFIG_PCI_INIT_R) seems to fix these issues. No idea why... > > > I might be missing something - did not check in depth. > > I think this must be the problem. Sorry I've missed this: > > config USB_XHCI_MVEBU > bool "MVEBU USB 3.0 support" > default y > depends on ARCH_MVEBU > select DM_REGULATOR > help > Choose this option to add support for USB 3.0 driver on mvebu > SoCs, which includes Armada8K, Armada3700 and other Armada > family SoCs. This is used for native USB 3.0 controller in Marvell SoC (connected via serdes). But you wrote and sent pci output, that you have PCIe-based USB controller connected via PCIe. > So I'll need rebuild with "depends on (ARCH_MVEBU || ARCH_KIRKWOOD)" > and do some more testing. > > Thanks, > Tony > > > > > > > Thanks, > > > Stefan
Re: Testing pci_mvebu.c with Kirkwood SoCs
Also probably a new Kirkwood udevice is needed in
drivers/usb/host/xhci-mvebu.c (if armada-380-xhci is not appropriate).
static const struct udevice_id xhci_usb_ids[] = {
{ .compatible = "marvell,armada3700-xhci" },
{ .compatible = "marvell,armada-380-xhci" },
{ .compatible = "marvell,armada-8k-xhci" },
{ }
};
But I guess the fact that it works during board_late_init must be
because of a generic USB_XHCI driver being used?
Thanks,
Tony
On Fri, Nov 12, 2021 at 1:46 PM Tony Dinh wrote:
>
> Hi Stefan & Pali,
>
> On Fri, Nov 12, 2021 at 7:06 AM Pali Rohár wrote:
> >
> > On Friday 12 November 2021 15:36:31 Stefan Roese wrote:
> > > On 11/11/21 22:10, Pali Rohár wrote:
> > > > On Wednesday 10 November 2021 16:04:20 Tony Dinh wrote:
> > > > > I've also tried mdelay(3000), just to be sure. The result was the same
> > > > > hang in 'usb start'.
> > > >
> > > > Ok. So put pci_init() into board_late_init().
> > > >
> > > > There are some more cleanup and fixes patches for pci_mvebu.c on mailing
> > > > list. After they are merged I will prepare and send final PCI Kirkwood
> > > > patch for testing.
> > >
> > > Chiming in a bit late in this discussion:
> > >
> > > Is an explicit call to pci_init() necessary in this Kirwood case? IIRC,
> > > the DM infrastructure should make sure that all device are probed - but
> > > only when really needed. So if you don't need PCI in the boot process
> > > at all, then it's not probed at all. Or if you set CONFIG_PCI_PNP this
> > > will be done always. Then there should be no need for the additional
> > > "pci enum".
> >
> > CONFIG_PCI_PNP probe and initialize all devices behind host bridge.
> > CONFIG_PCI_INIT_R probe and initialize host bridge (this is done by
> > calling pci_init()). Based on tests (see discussion in this thread) it
> > looks like that CONFIG_PCI_INIT_R calls pci_init() too early and
> > initialization is failing. So unsetting CONFIG_PCI_INIT_R and calling
> > pci_init() manually from board_late_init() (which is called later than
> > CONFIG_PCI_INIT_R) seems to fix these issues. No idea why...
> > > I might be missing something - did not check in depth.
>
> I think this must be the problem. Sorry I've missed this:
>
> config USB_XHCI_MVEBU
> bool "MVEBU USB 3.0 support"
> default y
> depends on ARCH_MVEBU
> select DM_REGULATOR
> help
> Choose this option to add support for USB 3.0 driver on mvebu
> SoCs, which includes Armada8K, Armada3700 and other Armada
> family SoCs.
>
> So I'll need rebuild with "depends on (ARCH_MVEBU || ARCH_KIRKWOOD)"
> and do some more testing.
>
> Thanks,
> Tony
>
> > >
> > > Thanks,
> > > Stefan
Re: Testing pci_mvebu.c with Kirkwood SoCs
Hi Stefan & Pali, On Fri, Nov 12, 2021 at 7:06 AM Pali Rohár wrote: > > On Friday 12 November 2021 15:36:31 Stefan Roese wrote: > > On 11/11/21 22:10, Pali Rohár wrote: > > > On Wednesday 10 November 2021 16:04:20 Tony Dinh wrote: > > > > I've also tried mdelay(3000), just to be sure. The result was the same > > > > hang in 'usb start'. > > > > > > Ok. So put pci_init() into board_late_init(). > > > > > > There are some more cleanup and fixes patches for pci_mvebu.c on mailing > > > list. After they are merged I will prepare and send final PCI Kirkwood > > > patch for testing. > > > > Chiming in a bit late in this discussion: > > > > Is an explicit call to pci_init() necessary in this Kirwood case? IIRC, > > the DM infrastructure should make sure that all device are probed - but > > only when really needed. So if you don't need PCI in the boot process > > at all, then it's not probed at all. Or if you set CONFIG_PCI_PNP this > > will be done always. Then there should be no need for the additional > > "pci enum". > > CONFIG_PCI_PNP probe and initialize all devices behind host bridge. > CONFIG_PCI_INIT_R probe and initialize host bridge (this is done by > calling pci_init()). Based on tests (see discussion in this thread) it > looks like that CONFIG_PCI_INIT_R calls pci_init() too early and > initialization is failing. So unsetting CONFIG_PCI_INIT_R and calling > pci_init() manually from board_late_init() (which is called later than > CONFIG_PCI_INIT_R) seems to fix these issues. No idea why... > > I might be missing something - did not check in depth. I think this must be the problem. Sorry I've missed this: config USB_XHCI_MVEBU bool "MVEBU USB 3.0 support" default y depends on ARCH_MVEBU select DM_REGULATOR help Choose this option to add support for USB 3.0 driver on mvebu SoCs, which includes Armada8K, Armada3700 and other Armada family SoCs. So I'll need rebuild with "depends on (ARCH_MVEBU || ARCH_KIRKWOOD)" and do some more testing. Thanks, Tony > > > > Thanks, > > Stefan
Re: Testing pci_mvebu.c with Kirkwood SoCs
On Friday 12 November 2021 15:36:31 Stefan Roese wrote: > On 11/11/21 22:10, Pali Rohár wrote: > > On Wednesday 10 November 2021 16:04:20 Tony Dinh wrote: > > > I've also tried mdelay(3000), just to be sure. The result was the same > > > hang in 'usb start'. > > > > Ok. So put pci_init() into board_late_init(). > > > > There are some more cleanup and fixes patches for pci_mvebu.c on mailing > > list. After they are merged I will prepare and send final PCI Kirkwood > > patch for testing. > > Chiming in a bit late in this discussion: > > Is an explicit call to pci_init() necessary in this Kirwood case? IIRC, > the DM infrastructure should make sure that all device are probed - but > only when really needed. So if you don't need PCI in the boot process > at all, then it's not probed at all. Or if you set CONFIG_PCI_PNP this > will be done always. Then there should be no need for the additional > "pci enum". CONFIG_PCI_PNP probe and initialize all devices behind host bridge. CONFIG_PCI_INIT_R probe and initialize host bridge (this is done by calling pci_init()). Based on tests (see discussion in this thread) it looks like that CONFIG_PCI_INIT_R calls pci_init() too early and initialization is failing. So unsetting CONFIG_PCI_INIT_R and calling pci_init() manually from board_late_init() (which is called later than CONFIG_PCI_INIT_R) seems to fix these issues. No idea why... > I might be missing something - did not check in depth. > > Thanks, > Stefan
Re: Testing pci_mvebu.c with Kirkwood SoCs
On 11/11/21 22:10, Pali Rohár wrote: On Wednesday 10 November 2021 16:04:20 Tony Dinh wrote: I've also tried mdelay(3000), just to be sure. The result was the same hang in 'usb start'. Ok. So put pci_init() into board_late_init(). There are some more cleanup and fixes patches for pci_mvebu.c on mailing list. After they are merged I will prepare and send final PCI Kirkwood patch for testing. Chiming in a bit late in this discussion: Is an explicit call to pci_init() necessary in this Kirwood case? IIRC, the DM infrastructure should make sure that all device are probed - but only when really needed. So if you don't need PCI in the boot process at all, then it's not probed at all. Or if you set CONFIG_PCI_PNP this will be done always. Then there should be no need for the additional "pci enum". I might be missing something - did not check in depth. Thanks, Stefan
Re: Testing pci_mvebu.c with Kirkwood SoCs
On Wednesday 10 November 2021 16:04:20 Tony Dinh wrote: > I've also tried mdelay(3000), just to be sure. The result was the same > hang in 'usb start'. Ok. So put pci_init() into board_late_init(). There are some more cleanup and fixes patches for pci_mvebu.c on mailing list. After they are merged I will prepare and send final PCI Kirkwood patch for testing.
Re: Testing pci_mvebu.c with Kirkwood SoCs
Hi Pali, I've tried the test with mdelay(200) at the end of mvebu_pcie_probe(). Please see below. On Tue, Nov 9, 2021 at 7:17 PM Tony Dinh wrote: > > Hi Pali, > > On Tue, Nov 9, 2021 at 3:05 PM Pali Rohár wrote: > > > > Hello! > > > > On Tuesday 09 November 2021 14:51:33 Tony Dinh wrote: > > > Hi Pali, > > > > > > On Tue, Nov 9, 2021 at 7:08 AM Pali Rohár wrote: > > > > > > > > On Monday 08 November 2021 22:34:51 Tony Dinh wrote: > > > > > The above log was the build with the following configs: > > > > > CONFIG_CMD_PCI=y > > > > > CONFIG_PCI=y > > > > > CONFIG_PCI_MVEBU=y > > > > > CONFIG_PCI_PNP=y > > > > > CONFIG_USB_XHCI_HCD=y > > > > > CONFIG_USB_XHCI_PCI=y > > > > > CONFIG_USB_XHCI_MVEBU=y > > > > > CONFIG_PCI_INIT_R=y > > > > > CONFIG_SYS_EARLY_PCI_INIT=y > > > > > > > > > > > > > > > Any idea how to debug this? there must be some differences between the > > > > > pci_init call early on, and much later with "pci enum". > > > > > > > > Hello! The only difference is when pci_init() function is called. So it > > > > looks like that it needs to be called later (perhaps because PCIe needs > > > > some other steps for initialization?). > > > > > > > > Could you try to disable CONFIG_SYS_EARLY_PCI_INIT option if it helps? > > > > > > Please correct me if I'm wrong. It is a compound condition in > > > board_r.c, so it would not be executed anyway? > > > > > > #if defined(CONFIG_PCI_INIT_R) && defined(CONFIG_SYS_EARLY_PCI_INIT) > > > > > > > And few lines below is section: > > > > #if defined(CONFIG_PCI_INIT_R) && !defined(CONFIG_SYS_EARLY_PCI_INIT) > > /* > > * Do pci configuration > > */ > > pci_init, > > #endif > > > > So CONFIG_SYS_EARLY_PCI_INIT controls if pci_init() is called earlier or > > later. > > > > > > And could you try to put pci_init() into board_early_init_r() and > > > > disable both CONFIG_SYS_EARLY_PCI_INIT and CONFIG_PCI_INIT_R if it > > > > helps? > > > > > > This did not help. I've added board_early_init_r to the board file, > > > and called pci_init() there. In the debug output, I can see pci_init() > > > executed early. But later, "usb start" still hangs at EHCI enumeration > > > like before. > > > > > > scanning bus ehci@5 for devices... Bound device usb_hub to ehci@5 > > > > > > Strangely, on a hunch, I ran it a second time and then did "pci enum" > > > and "usb start", I got a bit further. Now it scans the XHCI bus, and > > > gets 3 USB devices, but then hangs. > > > > > > scanning bus ehci@5 for devices... Bound device usb_hub to ehci@5 > > > Bound device usb_hub to usb_hub > > > Bound device usb_mass_storage to usb_hub > > > Bound device usb_mass_storage.lun0 to usb_mass_storage > > > 3 USB Device(s) found > > > scanning bus xhci_pci for devices... Bound device usb_hub to xhci_pci > > > > > > So it seems that after the board has finished initialization, calling > > > pci_init() again from "pci enum" will result in more probing > > > processing. > > > > So it means that there are some timing issues. > > > > Could you try to add "mdelay(200);" at the end of mvebu_pcie_probe() > > function? For mdelay you probably need also "#include ". I've tried the mdelay(200) at the end of mvebu_pcie_probe(). In this test I set the configs is back to: CONFIG_CMD_PCI=y CONFIG_PCI=y CONFIG_PCI_MVEBU=y CONFIG_PCI_PNP=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_PCI=y CONFIG_USB_XHCI_MVEBU=y CONFIG_PCI_INIT_R=y CONFIG_SYS_EARLY_PCI_INIT=y The behavior is the same as before. It hangs at "usb start". U-Boot 2022.01-rc1-00054-g52207514ba-dirty (Nov 10 2021 - 13:56:09 -0800) Pogoplug V4 SoC: Kirkwood 88F6192_A1 DRAM: 128 MiB device_probe: device_probe: exit 0 mvebu_pcie_bind: begin mvebu_pcie_bind: got an available node Bound device to pcie@8200 mvebu_pcie_bind: bound mvebu_pcie_bind: exit 0 Bound device pcie@8200 to mbus@f100 Bound device mbus@f100 to root_driver Bound device ehci@5 to ocp@f100 Bound device ethernet-controller@72000 to ocp@f100 Bound device sata@8 to ocp@f100 Bound device mvs...@9.blk to mvsdio@9 Bound device mvsdio@9 to ocp@f100 Bound device ocp@f100 to root_driver NAND: 128 MiB MMC: device_probe: device_probe: device_probe: device_probe: exit 0 device_probe: exit 0 device_probe: device_probe: mvsdio@9: 0 Loading Environment from NAND... *** Warning - bad CRC, using default environment pci_init: device_probe: device_probe: device_probe: device_probe: device_probe: exit 0 device_probe: exit 0 mvebu_pcie_probe: mvebu_pcie_probe: exit 0 Bound device pci_0:0.0 to pcie0.0 device_probe: device_probe: Bound device xhci_pci to pci_0:0.0 device_probe: exit 0 device_probe: exit 0 device_probe: pci_init: exit 0 In:serial Out: serial Err: serial Net: device_probe: device_probe: Warning: ethernet-controller@72000 (eth0) using random MAC address - a2:f2:2b:f9:74:ac device_probe: exit 0 eth0: ethernet-controller@72000 Hit any key to stop autoboot: 0 Pogo_V4> pci 0
Re: Testing pci_mvebu.c with Kirkwood SoCs
Hi Pali,
On Tue, Nov 9, 2021 at 3:05 PM Pali Rohár wrote:
>
> Hello!
>
> On Tuesday 09 November 2021 14:51:33 Tony Dinh wrote:
> > Hi Pali,
> >
> > On Tue, Nov 9, 2021 at 7:08 AM Pali Rohár wrote:
> > >
> > > On Monday 08 November 2021 22:34:51 Tony Dinh wrote:
> > > > The above log was the build with the following configs:
> > > > CONFIG_CMD_PCI=y
> > > > CONFIG_PCI=y
> > > > CONFIG_PCI_MVEBU=y
> > > > CONFIG_PCI_PNP=y
> > > > CONFIG_USB_XHCI_HCD=y
> > > > CONFIG_USB_XHCI_PCI=y
> > > > CONFIG_USB_XHCI_MVEBU=y
> > > > CONFIG_PCI_INIT_R=y
> > > > CONFIG_SYS_EARLY_PCI_INIT=y
> > > >
> > > >
> > > > Any idea how to debug this? there must be some differences between the
> > > > pci_init call early on, and much later with "pci enum".
> > >
> > > Hello! The only difference is when pci_init() function is called. So it
> > > looks like that it needs to be called later (perhaps because PCIe needs
> > > some other steps for initialization?).
> > >
> > > Could you try to disable CONFIG_SYS_EARLY_PCI_INIT option if it helps?
> >
> > Please correct me if I'm wrong. It is a compound condition in
> > board_r.c, so it would not be executed anyway?
> >
> > #if defined(CONFIG_PCI_INIT_R) && defined(CONFIG_SYS_EARLY_PCI_INIT)
> >
>
> And few lines below is section:
>
> #if defined(CONFIG_PCI_INIT_R) && !defined(CONFIG_SYS_EARLY_PCI_INIT)
> /*
> * Do pci configuration
> */
> pci_init,
> #endif
>
> So CONFIG_SYS_EARLY_PCI_INIT controls if pci_init() is called earlier or
> later.
>
> > > And could you try to put pci_init() into board_early_init_r() and
> > > disable both CONFIG_SYS_EARLY_PCI_INIT and CONFIG_PCI_INIT_R if it
> > > helps?
> >
> > This did not help. I've added board_early_init_r to the board file,
> > and called pci_init() there. In the debug output, I can see pci_init()
> > executed early. But later, "usb start" still hangs at EHCI enumeration
> > like before.
> >
> > scanning bus ehci@5 for devices... Bound device usb_hub to ehci@5
> >
> > Strangely, on a hunch, I ran it a second time and then did "pci enum"
> > and "usb start", I got a bit further. Now it scans the XHCI bus, and
> > gets 3 USB devices, but then hangs.
> >
> > scanning bus ehci@5 for devices... Bound device usb_hub to ehci@5
> > Bound device usb_hub to usb_hub
> > Bound device usb_mass_storage to usb_hub
> > Bound device usb_mass_storage.lun0 to usb_mass_storage
> > 3 USB Device(s) found
> > scanning bus xhci_pci for devices... Bound device usb_hub to xhci_pci
> >
> > So it seems that after the board has finished initialization, calling
> > pci_init() again from "pci enum" will result in more probing
> > processing.
>
> So it means that there are some timing issues.
>
> Could you try to add "mdelay(200);" at the end of mvebu_pcie_probe()
> function? For mdelay you probably need also "#include ".
>
I have not tried this, given we are successful with board_late_init now.
> Or could you try to add "int board_late_init(void) { pci_init(); return 0; }"
> into your board code?
board_late_init is working! Here is the log.
U-Boot 2022.01-rc1-00054-g52207514ba-dirty (Nov 09 2021 - 18:28:37 -0800)
Pogoplug V4
SoC: Kirkwood 88F6192_A1
DRAM: 128 MiB
device_probe:
device_probe: exit 0
mvebu_pcie_bind: begin
mvebu_pcie_bind: got an available node
Bound device to pcie@8200
mvebu_pcie_bind: bound
mvebu_pcie_bind: exit 0
Bound device pcie@8200 to mbus@f100
Bound device mbus@f100 to root_driver
Bound device ehci@5 to ocp@f100
Bound device ethernet-controller@72000 to ocp@f100
Bound device sata@8 to ocp@f100
Bound device mvs...@9.blk to mvsdio@9
Bound device mvsdio@9 to ocp@f100
Bound device ocp@f100 to root_driver
NAND: 128 MiB
MMC: device_probe:
device_probe:
device_probe:
device_probe: exit 0
device_probe: exit 0
device_probe:
device_probe:
mvsdio@9: 0
Loading Environment from NAND... *** Warning - bad CRC, using default
environment
In:serial
Out: serial
Err: serial
pci_init:
device_probe:
device_probe:
device_probe:
device_probe:
device_probe: exit 0
device_probe: exit 0
mvebu_pcie_probe:
mvebu_pcie_probe: exit 0
Bound device pci_0:0.0 to pcie0.0
device_probe:
device_probe:
Bound device xhci_pci to pci_0:0.0
device_probe: exit 0
device_probe: exit 0
device_probe:
pci_init: exit 0
Net: device_probe:
device_probe:
Warning: ethernet-controller@72000 (eth0) using random MAC address -
4a:8f:e6:9d:8b:79
device_probe: exit 0
eth0: ethernet-controller@72000
Hit any key to stop autoboot: 0
Pogo_V4> pci 0
device_probe:
Scanning PCI devices on bus 0
BusDevFun VendorId DeviceId Device Class Sub-Class
_
00.00.00 0x11ab 0x6281 Bridge device 0x04
Pogo_V4> pci 1
device_probe:
Scanning PCI devices on bus 1
BusDevFun VendorId DeviceId Device Class Sub-Class
_
01.00.00 0x1b73
Re: Testing pci_mvebu.c with Kirkwood SoCs
Hello!
On Tuesday 09 November 2021 14:51:33 Tony Dinh wrote:
> Hi Pali,
>
> On Tue, Nov 9, 2021 at 7:08 AM Pali Rohár wrote:
> >
> > On Monday 08 November 2021 22:34:51 Tony Dinh wrote:
> > > The above log was the build with the following configs:
> > > CONFIG_CMD_PCI=y
> > > CONFIG_PCI=y
> > > CONFIG_PCI_MVEBU=y
> > > CONFIG_PCI_PNP=y
> > > CONFIG_USB_XHCI_HCD=y
> > > CONFIG_USB_XHCI_PCI=y
> > > CONFIG_USB_XHCI_MVEBU=y
> > > CONFIG_PCI_INIT_R=y
> > > CONFIG_SYS_EARLY_PCI_INIT=y
> > >
> > >
> > > Any idea how to debug this? there must be some differences between the
> > > pci_init call early on, and much later with "pci enum".
> >
> > Hello! The only difference is when pci_init() function is called. So it
> > looks like that it needs to be called later (perhaps because PCIe needs
> > some other steps for initialization?).
> >
> > Could you try to disable CONFIG_SYS_EARLY_PCI_INIT option if it helps?
>
> Please correct me if I'm wrong. It is a compound condition in
> board_r.c, so it would not be executed anyway?
>
> #if defined(CONFIG_PCI_INIT_R) && defined(CONFIG_SYS_EARLY_PCI_INIT)
>
And few lines below is section:
#if defined(CONFIG_PCI_INIT_R) && !defined(CONFIG_SYS_EARLY_PCI_INIT)
/*
* Do pci configuration
*/
pci_init,
#endif
So CONFIG_SYS_EARLY_PCI_INIT controls if pci_init() is called earlier or
later.
> > And could you try to put pci_init() into board_early_init_r() and
> > disable both CONFIG_SYS_EARLY_PCI_INIT and CONFIG_PCI_INIT_R if it
> > helps?
>
> This did not help. I've added board_early_init_r to the board file,
> and called pci_init() there. In the debug output, I can see pci_init()
> executed early. But later, "usb start" still hangs at EHCI enumeration
> like before.
>
> scanning bus ehci@5 for devices... Bound device usb_hub to ehci@5
>
> Strangely, on a hunch, I ran it a second time and then did "pci enum"
> and "usb start", I got a bit further. Now it scans the XHCI bus, and
> gets 3 USB devices, but then hangs.
>
> scanning bus ehci@5 for devices... Bound device usb_hub to ehci@5
> Bound device usb_hub to usb_hub
> Bound device usb_mass_storage to usb_hub
> Bound device usb_mass_storage.lun0 to usb_mass_storage
> 3 USB Device(s) found
> scanning bus xhci_pci for devices... Bound device usb_hub to xhci_pci
>
> So it seems that after the board has finished initialization, calling
> pci_init() again from "pci enum" will result in more probing
> processing.
So it means that there are some timing issues.
Could you try to add "mdelay(200);" at the end of mvebu_pcie_probe()
function? For mdelay you probably need also "#include ".
Or could you try to add "int board_late_init(void) { pci_init(); return 0; }"
into your board code?
In every test ensure that pci_init() is called only once. So if adding
pci_init() in board code then disable CONFIG_PCI_INIT_R.
Re: Testing pci_mvebu.c with Kirkwood SoCs
Hi Pali, On Tue, Nov 9, 2021 at 7:08 AM Pali Rohár wrote: > > On Monday 08 November 2021 22:34:51 Tony Dinh wrote: > > The above log was the build with the following configs: > > CONFIG_CMD_PCI=y > > CONFIG_PCI=y > > CONFIG_PCI_MVEBU=y > > CONFIG_PCI_PNP=y > > CONFIG_USB_XHCI_HCD=y > > CONFIG_USB_XHCI_PCI=y > > CONFIG_USB_XHCI_MVEBU=y > > CONFIG_PCI_INIT_R=y > > CONFIG_SYS_EARLY_PCI_INIT=y > > > > > > Any idea how to debug this? there must be some differences between the > > pci_init call early on, and much later with "pci enum". > > Hello! The only difference is when pci_init() function is called. So it > looks like that it needs to be called later (perhaps because PCIe needs > some other steps for initialization?). > > Could you try to disable CONFIG_SYS_EARLY_PCI_INIT option if it helps? Please correct me if I'm wrong. It is a compound condition in board_r.c, so it would not be executed anyway? #if defined(CONFIG_PCI_INIT_R) && defined(CONFIG_SYS_EARLY_PCI_INIT) > And could you try to put pci_init() into board_early_init_r() and > disable both CONFIG_SYS_EARLY_PCI_INIT and CONFIG_PCI_INIT_R if it > helps? This did not help. I've added board_early_init_r to the board file, and called pci_init() there. In the debug output, I can see pci_init() executed early. But later, "usb start" still hangs at EHCI enumeration like before. scanning bus ehci@5 for devices... Bound device usb_hub to ehci@5 Strangely, on a hunch, I ran it a second time and then did "pci enum" and "usb start", I got a bit further. Now it scans the XHCI bus, and gets 3 USB devices, but then hangs. scanning bus ehci@5 for devices... Bound device usb_hub to ehci@5 Bound device usb_hub to usb_hub Bound device usb_mass_storage to usb_hub Bound device usb_mass_storage.lun0 to usb_mass_storage 3 USB Device(s) found scanning bus xhci_pci for devices... Bound device usb_hub to xhci_pci So it seems that after the board has finished initialization, calling pci_init() again from "pci enum" will result in more probing processing. Thanks, Tony
Re: Testing pci_mvebu.c with Kirkwood SoCs
On Monday 08 November 2021 14:48:03 Tony Dinh wrote: > This Pogoplug V4 board is still out-of-tree. I have not submitted > patches to add support for it. I plan to do that in the near future, > and it will be under board/cloudengines/. > > However, there is a show stopper right now that prevents me from going > ahead to add this Pogoplug V4 board. A previous fdt patch has not been > accepted, because Simon wanted this to be implemented with livetree > calls: > https://lists.denx.de/pipermail/u-boot/2021-August/457311.html > It is working fine as a flat tree implementation. You can at least send patches which adds base code for this board, even without network support, which can be added later. > The other 2 Kirkwood boards that could be useful in PCIe testing are > the Iomega iConnect (in mainline at board/iomega/iconnect/), and the > Zyxel NAS325 (still out-of-tree). I am also stuck on this NAS325 board > because of the fdt_support flattree vs. livetree implementation.
Re: Testing pci_mvebu.c with Kirkwood SoCs
On Monday 08 November 2021 22:34:51 Tony Dinh wrote: > The above log was the build with the following configs: > CONFIG_CMD_PCI=y > CONFIG_PCI=y > CONFIG_PCI_MVEBU=y > CONFIG_PCI_PNP=y > CONFIG_USB_XHCI_HCD=y > CONFIG_USB_XHCI_PCI=y > CONFIG_USB_XHCI_MVEBU=y > CONFIG_PCI_INIT_R=y > CONFIG_SYS_EARLY_PCI_INIT=y > > > Any idea how to debug this? there must be some differences between the > pci_init call early on, and much later with "pci enum". Hello! The only difference is when pci_init() function is called. So it looks like that it needs to be called later (perhaps because PCIe needs some other steps for initialization?). Could you try to disable CONFIG_SYS_EARLY_PCI_INIT option if it helps? And could you try to put pci_init() into board_early_init_r() and disable both CONFIG_SYS_EARLY_PCI_INIT and CONFIG_PCI_INIT_R if it helps?
Re: Testing pci_mvebu.c with Kirkwood SoCs
Hi Marek and Pali, On Mon, Nov 8, 2021 at 3:04 PM Marek Behún wrote: > > On Mon, 8 Nov 2021 14:48:03 -0800 > Tony Dinh wrote: > > > > So to avoid calling 'pci enum' manually, you need to put pci_init(); > > > function call into your board board_early_init_r() function. > > > > Thanks! will do that. > > Don't do that. > > Instead enable CONFIG_PCI_INIT_R and CONFIG_SYS_EARLY_PCI_INIT, and the > code in common/board_r.c will do it itself. > > Look at: > > https://source.denx.de/u-boot/u-boot/-/blob/f8ed9059001d803b0eae4b49178789aa0e29edec/common/board_r.c#L675 Thanks for that advice. I also compared this code with the "pci enum" command. Indeed, like Pali said, it just calls pci_init() like in board_r.c. However, after enabling CONFIG_PCI_INIT_R and CONFIG_SYS_EARLY_PCI_INIT, it hit a bug-on while scanning the USB bus! U-Boot 2022.01-rc1-00054-g52207514ba-dirty (Nov 08 2021 - 22:17:10 -0800) Pogoplug V4 SoC: Kirkwood 88F6192_A1 DRAM: 128 MiB device_probe: device_probe: exit 0 mvebu_pcie_bind: begin mvebu_pcie_bind: got an available node Bound device to pcie@8200 mvebu_pcie_bind: bound mvebu_pcie_bind: exit 0 Bound device pcie@8200 to mbus@f100 Bound device mbus@f100 to root_driver Bound device ehci@5 to ocp@f100 Bound device ethernet-controller@72000 to ocp@f100 Bound device sata@8 to ocp@f100 Bound device mvs...@9.blk to mvsdio@9 Bound device mvsdio@9 to ocp@f100 Bound device ocp@f100 to root_driver NAND: 128 MiB MMC: device_probe: device_probe: device_probe: device_probe: exit 0 device_probe: exit 0 device_probe: device_probe: mvsdio@9: 0 Loading Environment from NAND... *** Warning - bad CRC, using default environment device_probe: device_probe: device_probe: device_probe: device_probe: exit 0 device_probe: exit 0 mvebu_pcie_probe: mvebu_pcie_probe: exit 0 Bound device pci_0:0.0 to pcie0.0 device_probe: device_probe: Bound device xhci_pci to pci_0:0.0 device_probe: exit 0 device_probe: exit 0 device_probe: In:serial Out: serial Err: serial Net: device_probe: device_probe: Warning: ethernet-controller@72000 (eth0) using random MAC address - 82:09:1e:66:49:21 device_probe: exit 0 eth0: ethernet-controller@72000 Hit any key to stop autoboot: 0 Pogo_V4> pci 0 device_probe: Scanning PCI devices on bus 0 BusDevFun VendorId DeviceId Device Class Sub-Class _ 00.00.00 0x11ab 0x6281 Bridge device 0x04 Pogo_V4> pci 1 device_probe: Scanning PCI devices on bus 1 BusDevFun VendorId DeviceId Device Class Sub-Class _ 01.00.00 0x1b73 0x1009 Serial bus controller 0x03 Pogo_V4> usb start starting USB... Bus ehci@5: device_probe: device_probe: USB EHCI 1.00 device_probe: exit 0 Bus xhci_pci: device_probe: device_probe: Register 400081f NbrPorts 4 Starting the controller USB XHCI 1.00 device_probe: exit 0 scanning bus ehci@5 for devices... Bound device usb_hub to ehci@5 device_probe: device_probe: Bound device usb_hub to usb_hub device_probe: device_probe: device_probe: exit 0 Bound device usb_mass_storage to usb_hub device_probe: device_probe: Bound device usb_mass_storage.lun0 to usb_mass_storage device_probe: exit 0 device_probe: exit 0 3 USB Device(s) found scanning bus xhci_pci for devices... Bound device usb_hub to xhci_pci device_probe: device_probe: XHCI timeout on event type 33... cannot recover. BUG at drivers/usb/host/xhci-ring.c:481/xhci_wait_for_event()! BUG! resetting ... The above log was the build with the following configs: CONFIG_CMD_PCI=y CONFIG_PCI=y CONFIG_PCI_MVEBU=y CONFIG_PCI_PNP=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_PCI=y CONFIG_USB_XHCI_MVEBU=y CONFIG_PCI_INIT_R=y CONFIG_SYS_EARLY_PCI_INIT=y Any idea how to debug this? there must be some differences between the pci_init call early on, and much later with "pci enum". Thanks, Tony > > Marek
Re: Testing pci_mvebu.c with Kirkwood SoCs
On Mon, 8 Nov 2021 14:48:03 -0800 Tony Dinh wrote: > > So to avoid calling 'pci enum' manually, you need to put pci_init(); > > function call into your board board_early_init_r() function. > > Thanks! will do that. Don't do that. Instead enable CONFIG_PCI_INIT_R and CONFIG_SYS_EARLY_PCI_INIT, and the code in common/board_r.c will do it itself. Look at: https://source.denx.de/u-boot/u-boot/-/blob/f8ed9059001d803b0eae4b49178789aa0e29edec/common/board_r.c#L675 Marek
Re: Testing pci_mvebu.c with Kirkwood SoCs
Hi Pali,
On Mon, Nov 8, 2021 at 2:02 PM Pali Rohár wrote:
>
> On Monday 08 November 2021 12:54:39 Tony Dinh wrote:
> > On Mon, Nov 8, 2021 at 3:11 AM Pali Rohár wrote:
> > > On Sunday 07 November 2021 18:08:56 Tony Dinh wrote:
> ...
> > > > > I think some more investigation is needed. Why did we need to do "pci
> > > > > enum", and then "usb reset", in that order, to get the PCI bus and the
> > > > > XHCI controller probed? there must be something missing in the process
> > > > > somewhere between the Device uclass, the PCI uclass, and the pci_mvebu
> > > > > uclass?
> > > >
> > > > I think I can see the order of enumeration. PCI must be enumerated
> > > > first, and then XHCI being the controller on this host bus would come
> > > > alive? I think we can live with 'pci enum' and 'usb reset' to get the
> > > > USB 3.0 drives enumerated. However, it seems just a little bit
> > > > unintuitive.
> > >
> > > 'pci enum' should be called internally by U-Boot during loading. So only
> > > 'usb start' would be needed.
> > >
> > > But from your boot log it looks like that PCI enumaration was not done
> > > and so calling 'pci enum' manually is needed.
> > >
> > > I will look into U-Boot code why it happens...
>
> Ok. Command 'pci enum' is just calling pci_init() function.
>
> So to avoid calling 'pci enum' manually, you need to put pci_init();
> function call into your board board_early_init_r() function.
Thanks! will do that.
> Which files in board/** are you using for your Kirkwood board? I do not
> see any 6281 in board/Marvell/*.
This Pogoplug V4 board is still out-of-tree. I have not submitted
patches to add support for it. I plan to do that in the near future,
and it will be under board/cloudengines/.
However, there is a show stopper right now that prevents me from going
ahead to add this Pogoplug V4 board. A previous fdt patch has not been
accepted, because Simon wanted this to be implemented with livetree
calls:
https://lists.denx.de/pipermail/u-boot/2021-August/457311.html
It is working fine as a flat tree implementation.
The other 2 Kirkwood boards that could be useful in PCIe testing are
the Iomega iConnect (in mainline at board/iomega/iconnect/), and the
Zyxel NAS325 (still out-of-tree). I am also stuck on this NAS325 board
because of the fdt_support flattree vs. livetree implementation.
Thanks,
Tony
> > > Anyway, based on your test, PCIe must work correctly :)
> >
> > Indeed, it's working perfectly :) I've also commented out the 2 calls
> > to mvebu_mbus_add_window_by_id(), and no longer see the conflicts
> > error.
>
> Perfect!
>
> >
> > - if (mvebu_mbus_add_window_by_id(pcie->mem_target, pcie->mem_attr,
> > - (phys_addr_t)pcie->mem.start,
> > - PCIE_MEM_SIZE)) {
> >
> > - if (mvebu_mbus_add_window_by_id(pcie->io_target, pcie->io_attr,
> > - (phys_addr_t)pcie->io.start,
> > - MBUS_PCI_IO_SIZE)) {
> >
> >
> > > Could you send config space dump of PCIe Root Port? Following U-Boot
> > > command prints it on terminal: 'pci display.b 0.0.0 0 200'
> >
> > Sure, here is the log with the dump.
>
> Thanks! Checked and seems to be correct.
Re: Testing pci_mvebu.c with Kirkwood SoCs
On Monday 08 November 2021 12:54:39 Tony Dinh wrote:
> On Mon, Nov 8, 2021 at 3:11 AM Pali Rohár wrote:
> > On Sunday 07 November 2021 18:08:56 Tony Dinh wrote:
...
> > > > I think some more investigation is needed. Why did we need to do "pci
> > > > enum", and then "usb reset", in that order, to get the PCI bus and the
> > > > XHCI controller probed? there must be something missing in the process
> > > > somewhere between the Device uclass, the PCI uclass, and the pci_mvebu
> > > > uclass?
> > >
> > > I think I can see the order of enumeration. PCI must be enumerated
> > > first, and then XHCI being the controller on this host bus would come
> > > alive? I think we can live with 'pci enum' and 'usb reset' to get the
> > > USB 3.0 drives enumerated. However, it seems just a little bit
> > > unintuitive.
> >
> > 'pci enum' should be called internally by U-Boot during loading. So only
> > 'usb start' would be needed.
> >
> > But from your boot log it looks like that PCI enumaration was not done
> > and so calling 'pci enum' manually is needed.
> >
> > I will look into U-Boot code why it happens...
Ok. Command 'pci enum' is just calling pci_init() function.
So to avoid calling 'pci enum' manually, you need to put pci_init();
function call into your board board_early_init_r() function.
Which files in board/** are you using for your Kirkwood board? I do not
see any 6281 in board/Marvell/*.
> > Anyway, based on your test, PCIe must work correctly :)
>
> Indeed, it's working perfectly :) I've also commented out the 2 calls
> to mvebu_mbus_add_window_by_id(), and no longer see the conflicts
> error.
Perfect!
>
> - if (mvebu_mbus_add_window_by_id(pcie->mem_target, pcie->mem_attr,
> - (phys_addr_t)pcie->mem.start,
> - PCIE_MEM_SIZE)) {
>
> - if (mvebu_mbus_add_window_by_id(pcie->io_target, pcie->io_attr,
> - (phys_addr_t)pcie->io.start,
> - MBUS_PCI_IO_SIZE)) {
>
>
> > Could you send config space dump of PCIe Root Port? Following U-Boot
> > command prints it on terminal: 'pci display.b 0.0.0 0 200'
>
> Sure, here is the log with the dump.
Thanks! Checked and seems to be correct.
Re: Testing pci_mvebu.c with Kirkwood SoCs
Hi Pali, On Mon, Nov 8, 2021 at 3:11 AM Pali Rohár wrote: > > Hello! > > On Sunday 07 November 2021 18:08:56 Tony Dinh wrote: > > Hi Pali, > > > > On Sun, Nov 7, 2021 at 4:58 PM Tony Dinh wrote: > > > > > > Hi Pali, > > > > > > Looks like it is working! But in a weird way. Please see my responses > > > in between, and also in the test log below. > > > > > > On Sun, Nov 7, 2021 at 3:45 PM Pali Rohár wrote: > > > > > > > > Hello! > > > > > > > > On Sunday 07 November 2021 12:56:37 Tony Dinh wrote: > > > > > Hi Pali, > > > > > > > > > > I've applied your patch, and ran some tests. Looks like we got to the > > > > > bind, but it was not probing (or the probe died silently). Later, I > > > > > tried pci enum and got some errors during probing. > > > > > > > > It looks like that arch/arm/mach-kirkwood/cpu.c already setup PCIe > > > > windows. Therefore when pci_mvebu.c tries it too, it fails on error > > > > "conflicts with another window" which you see in the log. > > > > > > > > Could you try to comment calling of "mvebu_mbus_add_window_by_id" > > > > function in pci_mvebu.c? As PCIe window setup should be done exactly > > > > once. > > > > > > > > Also try to call 'pci 0' and 'pci 1' after the 'pci enum'. > > > > > ... > > > > > > > > > > - These are relevant configs used in the build (not sure if I need to > > > > > use CONFIG_DM_PCI_COMPAT?) > > > > > > > > > > CONFIG_DM=y > > > > > CONFIG_CMD_PCI=y > > > > > CONFIG_PCI=y > > > > > CONFIG_PCI_MVEBU=y > > > > > CONFIG_PCI_ENDPOINT=y > > > > > CONFIG_DM_PCI_COMPAT=y > > > > > CONFIG_USB_XHCI_HCD=y > > > > > CONFIG_USB_XHCI_PCI=y > > > > > CONFIG_USB_XHCI_MVEBU=y > > > > > > > > Following options should be enough: > > > > > > > > CONFIG_CMD_PCI=y > > > > CONFIG_PCI=y > > > > # CONFIG_DM_PCI_COMPAT is not set > > > > CONFIG_PCI_PNP=y > > > > CONFIG_PCI_MVEBU=y > > > > > > Since the PCI bus in this box is used for USB 3.0, I've included > > > various XHCI configs to see if I can probe this USB 3.0 flash drive > > > also (that's the ultimate test). > > OK! > > > > > > > > > Option CONFIG_PCI_PNP=y is required to see endpoint cards. Without it > > > > U-Boot would see only PCIe Root Ports. But for first basic tests it > > > > should be enough. > > > > > > > > > BTW, the topic is no longer kwboot, should we move this to another new > > > > > thread? i.e. Testing PCI MVEBU with Kirkwood SoCs. > > > > > > > > Changed :-) > > > > > > Thanks :) > > > > > > Here is the log of a successful spin up for the PCI bus and USB 3.0 > > > drive. Please see my commentary ### in between the logs. > > > > > > U-Boot 2022.01-rc1-00054-g52207514ba-dirty (Nov 07 2021 - 16:03:46 -0800) > > > Pogoplug V4 > > > > > > SoC: Kirkwood 88F6281_A1 > > > DRAM: 128 MiB > > > device_probe: > > > device_probe: exit 0 > > > > > > > > > ### The device_probe above seems to have nothing happening. > > > > > > > > > mvebu_pcie_bind: begin > > > mvebu_pcie_bind: got an available node > > > Bound device to pcie@8200 > > > mvebu_pcie_bind: bound > > > mvebu_pcie_bind: exit 0 > > > Bound device pcie@8200 to mbus@f100 > > > Bound device mbus@f100 to root_driver > > > Bound device ehci@5 to ocp@f100 > > > Bound device ethernet-controller@72000 to ocp@f100 > > > Bound device sata@8 to ocp@f100 > > > Bound device mvs...@9.blk to mvsdio@9 > > > Bound device mvsdio@9 to ocp@f100 > > > Bound device ocp@f100 to root_driver > > > NAND: 128 MiB > > > MMC: device_probe: > > > device_probe: > > > device_probe: > > > device_probe: exit 0 > > > device_probe: exit 0 > > > device_probe: > > > device_probe: > > > mvsdio@9: 0 > > > Loading Environment from NAND... *** Warning - bad CRC, using default > > > environment > > > > > > In:serial > > > Out: serial > > > Err: serial > > > Net: device_probe: > > > device_probe: > > > > > > Warning: ethernet-controller@72000 (eth0) using random MAC address - > > > 86:b8:84:ee:a9:a5 > > > device_probe: exit 0 > > > eth0: ethernet-controller@72000 > > > Hit any key to stop autoboot: 0 > > > Pogo_V4> usb reset > > > resetting USB... > > > Bus ehci@5: device_probe: > > > device_probe: > > > USB EHCI 1.00 > > > device_probe: exit 0 > > > scanning bus ehci@5 for devices... Bound device usb_hub to ehci@5 > > > device_probe: > > > device_probe: > > > Bound device usb_hub to usb_hub > > > device_probe: > > > device_probe: > > > device_probe: exit 0 > > > Bound device usb_mass_storage to usb_hub > > > device_probe: > > > device_probe: > > > Bound device usb_mass_storage.lun0 to usb_mass_storage > > > device_probe: exit 0 > > > device_probe: exit 0 > > > 3 USB Device(s) found > > >scanning usb for storage devices... 1 Storage Device(s) found > > > > > > > > > ### Try to bring up both USB drives (2.0 and 3.0). But only the USB > > > 2.0 was up as shown above. > > > > > > > > > Pogo_V4> pci enum > > > device_probe: > > > device_probe: > > > device_probe: > > > device_probe: > > > device_probe:
Re: Testing pci_mvebu.c with Kirkwood SoCs
Hello! On Sunday 07 November 2021 18:08:56 Tony Dinh wrote: > Hi Pali, > > On Sun, Nov 7, 2021 at 4:58 PM Tony Dinh wrote: > > > > Hi Pali, > > > > Looks like it is working! But in a weird way. Please see my responses > > in between, and also in the test log below. > > > > On Sun, Nov 7, 2021 at 3:45 PM Pali Rohár wrote: > > > > > > Hello! > > > > > > On Sunday 07 November 2021 12:56:37 Tony Dinh wrote: > > > > Hi Pali, > > > > > > > > I've applied your patch, and ran some tests. Looks like we got to the > > > > bind, but it was not probing (or the probe died silently). Later, I > > > > tried pci enum and got some errors during probing. > > > > > > It looks like that arch/arm/mach-kirkwood/cpu.c already setup PCIe > > > windows. Therefore when pci_mvebu.c tries it too, it fails on error > > > "conflicts with another window" which you see in the log. > > > > > > Could you try to comment calling of "mvebu_mbus_add_window_by_id" > > > function in pci_mvebu.c? As PCIe window setup should be done exactly > > > once. > > > > > > Also try to call 'pci 0' and 'pci 1' after the 'pci enum'. > > > ... > > > > > > > > - These are relevant configs used in the build (not sure if I need to > > > > use CONFIG_DM_PCI_COMPAT?) > > > > > > > > CONFIG_DM=y > > > > CONFIG_CMD_PCI=y > > > > CONFIG_PCI=y > > > > CONFIG_PCI_MVEBU=y > > > > CONFIG_PCI_ENDPOINT=y > > > > CONFIG_DM_PCI_COMPAT=y > > > > CONFIG_USB_XHCI_HCD=y > > > > CONFIG_USB_XHCI_PCI=y > > > > CONFIG_USB_XHCI_MVEBU=y > > > > > > Following options should be enough: > > > > > > CONFIG_CMD_PCI=y > > > CONFIG_PCI=y > > > # CONFIG_DM_PCI_COMPAT is not set > > > CONFIG_PCI_PNP=y > > > CONFIG_PCI_MVEBU=y > > > > Since the PCI bus in this box is used for USB 3.0, I've included > > various XHCI configs to see if I can probe this USB 3.0 flash drive > > also (that's the ultimate test). OK! > > > > > > Option CONFIG_PCI_PNP=y is required to see endpoint cards. Without it > > > U-Boot would see only PCIe Root Ports. But for first basic tests it > > > should be enough. > > > > > > > BTW, the topic is no longer kwboot, should we move this to another new > > > > thread? i.e. Testing PCI MVEBU with Kirkwood SoCs. > > > > > > Changed :-) > > > > Thanks :) > > > > Here is the log of a successful spin up for the PCI bus and USB 3.0 > > drive. Please see my commentary ### in between the logs. > > > > U-Boot 2022.01-rc1-00054-g52207514ba-dirty (Nov 07 2021 - 16:03:46 -0800) > > Pogoplug V4 > > > > SoC: Kirkwood 88F6281_A1 > > DRAM: 128 MiB > > device_probe: > > device_probe: exit 0 > > > > > > ### The device_probe above seems to have nothing happening. > > > > > > mvebu_pcie_bind: begin > > mvebu_pcie_bind: got an available node > > Bound device to pcie@8200 > > mvebu_pcie_bind: bound > > mvebu_pcie_bind: exit 0 > > Bound device pcie@8200 to mbus@f100 > > Bound device mbus@f100 to root_driver > > Bound device ehci@5 to ocp@f100 > > Bound device ethernet-controller@72000 to ocp@f100 > > Bound device sata@8 to ocp@f100 > > Bound device mvs...@9.blk to mvsdio@9 > > Bound device mvsdio@9 to ocp@f100 > > Bound device ocp@f100 to root_driver > > NAND: 128 MiB > > MMC: device_probe: > > device_probe: > > device_probe: > > device_probe: exit 0 > > device_probe: exit 0 > > device_probe: > > device_probe: > > mvsdio@9: 0 > > Loading Environment from NAND... *** Warning - bad CRC, using default > > environment > > > > In:serial > > Out: serial > > Err: serial > > Net: device_probe: > > device_probe: > > > > Warning: ethernet-controller@72000 (eth0) using random MAC address - > > 86:b8:84:ee:a9:a5 > > device_probe: exit 0 > > eth0: ethernet-controller@72000 > > Hit any key to stop autoboot: 0 > > Pogo_V4> usb reset > > resetting USB... > > Bus ehci@5: device_probe: > > device_probe: > > USB EHCI 1.00 > > device_probe: exit 0 > > scanning bus ehci@5 for devices... Bound device usb_hub to ehci@5 > > device_probe: > > device_probe: > > Bound device usb_hub to usb_hub > > device_probe: > > device_probe: > > device_probe: exit 0 > > Bound device usb_mass_storage to usb_hub > > device_probe: > > device_probe: > > Bound device usb_mass_storage.lun0 to usb_mass_storage > > device_probe: exit 0 > > device_probe: exit 0 > > 3 USB Device(s) found > >scanning usb for storage devices... 1 Storage Device(s) found > > > > > > ### Try to bring up both USB drives (2.0 and 3.0). But only the USB > > 2.0 was up as shown above. > > > > > > Pogo_V4> pci enum > > device_probe: > > device_probe: > > device_probe: > > device_probe: > > device_probe: exit 0 > > device_probe: exit 0 > > mvebu_pcie_probe: > > Cannot add window '4:e8', conflicts with another window > > PCIe unable to add mbus window for mem at 9000+1000 > > Cannot add window '4:e0', conflicts with another window > > PCIe unable to add mbus window for IO at c000+0001 Error is still there... Have you tried to comment and disable calling
Re: Testing pci_mvebu.c with Kirkwood SoCs
Hi Pali, On Sun, Nov 7, 2021 at 4:58 PM Tony Dinh wrote: > > Hi Pali, > > Looks like it is working! But in a weird way. Please see my responses > in between, and also in the test log below. > > On Sun, Nov 7, 2021 at 3:45 PM Pali Rohár wrote: > > > > Hello! > > > > On Sunday 07 November 2021 12:56:37 Tony Dinh wrote: > > > Hi Pali, > > > > > > I've applied your patch, and ran some tests. Looks like we got to the > > > bind, but it was not probing (or the probe died silently). Later, I > > > tried pci enum and got some errors during probing. > > > > It looks like that arch/arm/mach-kirkwood/cpu.c already setup PCIe > > windows. Therefore when pci_mvebu.c tries it too, it fails on error > > "conflicts with another window" which you see in the log. > > > > Could you try to comment calling of "mvebu_mbus_add_window_by_id" > > function in pci_mvebu.c? As PCIe window setup should be done exactly > > once. > > > > Also try to call 'pci 0' and 'pci 1' after the 'pci enum'. > > > > > Here is the log (I added some debug printf to drivers/pci/pci_mvebu.c > > > and drivers/core/device.c to see the progress). > > > > > > - U-Boot boot log: > > > > > > U-Boot 2022.01-tld-1-00054-g52207514ba-dirty (Nov 06 2021 - 18:11:41 > > > -0700) > > > Pogoplug V4 > > > > > > SoC: Kirkwood 88F6281_A1 > > > DRAM: 128 MiB > > > mvebu_pcie_bind: begin > > > mvebu_pcie_bind: got an available node > > > Bound device to pcie@8200 > > > mvebu_pcie_bind: bound > > > mvebu_pcie_bind: exit 0 > > > Bound device pcie@8200 to mbus@f100 > > > Bound device mbus@f100 to root_driver > > > Bound device ehci@5 to ocp@f100 > > > Bound device ethernet-controller@72000 to ocp@f100 > > > Bound device sata@8 to ocp@f100 > > > Bound device mvs...@9.blk to mvsdio@9 > > > Bound device mvsdio@9 to ocp@f100 > > > Bound device ocp@f100 to root_driver > > > NAND: 128 MiB > > > MMC: mvsdio@9: 0 > > > Loading Environment from NAND... *** Warning - bad CRC, using default > > > environment > > > > > > In:serial > > > Out: serial > > > Err: serial > > > Net: > > > Warning: ethernet-controller@72000 (eth0) using random MAC address - > > > 66:43:1f:50:f0:e7 > > > eth0: ethernet-controller@72000 > > > Hit any key to stop autoboot: 0 > > > > > > Pogo_V4> pci > > > No such bus > > > Pogo_V4> pci 0 > > > No such bus > > > Pogo_V4> pci 1 > > > No such bus > > > > > > Pogo_V4> pci enum > > > mvebu_pcie_probe: > > > Cannot add window '4:e8', conflicts with another window > > > PCIe unable to add mbus window for mem at 9000+1000 > > > Cannot add window '4:e0', conflicts with another window > > > PCIe unable to add mbus window for IO at c000+0001 > > > mvebu_pcie_probe: exit 0 > > > Bound device pci_0:0.0 to pcie0.0 > > > Bound device xhci_pci to pci_0:0.0 > > > > > > Pogo_V4> pci regions > > > # Bus start Phys start SizeFlags > > > 0 0x9000 0x9000 0x1000 mem > > > 1 0x 0x 0x0800 mem sysmem > > > 2 0xc000 0xc000 0x0001 io io > > > > > > - Linux dmesg (grep for pci and xhci) > > > > > > [ 13.163011][T1] mvebu-pcie mbus@f100:pcie@8200: host > > > bridge /mbus@f100/pcie@8200 ranges: > > > [ 13.163147][T1] mvebu-pcie mbus@f100:pcie@8200: > > > MEM 0x00f104..0x00f1041fff -> 0x04 > > > [ 13.163217][T1] mvebu-pcie mbus@f100:pcie@8200: > > > MEM 0x..0x00fffe -> 0x01 > > > [ 13.163268][T1] mvebu-pcie mbus@f100:pcie@8200: > > > IO 0x..0x00fffe -> 0x01 > > > [ 13.163754][T1] mvebu-pcie mbus@f100:pcie@8200: PCI > > > host bridge to bus :00 > > > [ 13.163791][T1] pci_bus :00: root bus resource [bus 00-ff] > > > [ 13.163829][T1] pci_bus :00: root bus resource [mem > > > 0xf104-0xf1041fff] (bus address [0x0004-0x00041fff]) > > > [ 13.163862][T1] pci_bus :00: root bus resource [mem > > > 0xe000-0xefff] > > > [ 13.163892][T1] pci_bus :00: root bus resource [io > > > 0x1000-0xe] > > > [ 13.164075][T1] pci :00:01.0: [11ab:6281] type 01 class > > > 0x060400 > > > [ 13.164133][T1] pci :00:01.0: reg 0x38: [mem > > > 0x-0x07ff pref] > > > [ 13.165893][T1] PCI: bus0: Fast back to back transfers disabled > > > [ 13.165949][T1] pci :00:01.0: bridge configuration invalid > > > ([bus 00-00]), reconfiguring > > > [ 13.166276][T1] pci :01:00.0: [1b73:1009] type 00 class > > > 0x0c0330 > > > [ 13.166334][T1] pci :01:00.0: reg 0x10: [mem > > > 0x-0x 64bit] > > > [ 13.166381][T1] pci :01:00.0: reg 0x18: [mem > > > 0x-0x0fff 64bit] > > > [ 13.166424][T1] pci :01:00.0: reg 0x20: [mem > > > 0x-0x0fff 64bit] > > > [
Re: Testing pci_mvebu.c with Kirkwood SoCs
Hi Pali, Looks like it is working! But in a weird way. Please see my responses in between, and also in the test log below. On Sun, Nov 7, 2021 at 3:45 PM Pali Rohár wrote: > > Hello! > > On Sunday 07 November 2021 12:56:37 Tony Dinh wrote: > > Hi Pali, > > > > I've applied your patch, and ran some tests. Looks like we got to the > > bind, but it was not probing (or the probe died silently). Later, I > > tried pci enum and got some errors during probing. > > It looks like that arch/arm/mach-kirkwood/cpu.c already setup PCIe > windows. Therefore when pci_mvebu.c tries it too, it fails on error > "conflicts with another window" which you see in the log. > > Could you try to comment calling of "mvebu_mbus_add_window_by_id" > function in pci_mvebu.c? As PCIe window setup should be done exactly > once. > > Also try to call 'pci 0' and 'pci 1' after the 'pci enum'. > > > Here is the log (I added some debug printf to drivers/pci/pci_mvebu.c > > and drivers/core/device.c to see the progress). > > > > - U-Boot boot log: > > > > U-Boot 2022.01-tld-1-00054-g52207514ba-dirty (Nov 06 2021 - 18:11:41 -0700) > > Pogoplug V4 > > > > SoC: Kirkwood 88F6281_A1 > > DRAM: 128 MiB > > mvebu_pcie_bind: begin > > mvebu_pcie_bind: got an available node > > Bound device to pcie@8200 > > mvebu_pcie_bind: bound > > mvebu_pcie_bind: exit 0 > > Bound device pcie@8200 to mbus@f100 > > Bound device mbus@f100 to root_driver > > Bound device ehci@5 to ocp@f100 > > Bound device ethernet-controller@72000 to ocp@f100 > > Bound device sata@8 to ocp@f100 > > Bound device mvs...@9.blk to mvsdio@9 > > Bound device mvsdio@9 to ocp@f100 > > Bound device ocp@f100 to root_driver > > NAND: 128 MiB > > MMC: mvsdio@9: 0 > > Loading Environment from NAND... *** Warning - bad CRC, using default > > environment > > > > In:serial > > Out: serial > > Err: serial > > Net: > > Warning: ethernet-controller@72000 (eth0) using random MAC address - > > 66:43:1f:50:f0:e7 > > eth0: ethernet-controller@72000 > > Hit any key to stop autoboot: 0 > > > > Pogo_V4> pci > > No such bus > > Pogo_V4> pci 0 > > No such bus > > Pogo_V4> pci 1 > > No such bus > > > > Pogo_V4> pci enum > > mvebu_pcie_probe: > > Cannot add window '4:e8', conflicts with another window > > PCIe unable to add mbus window for mem at 9000+1000 > > Cannot add window '4:e0', conflicts with another window > > PCIe unable to add mbus window for IO at c000+0001 > > mvebu_pcie_probe: exit 0 > > Bound device pci_0:0.0 to pcie0.0 > > Bound device xhci_pci to pci_0:0.0 > > > > Pogo_V4> pci regions > > # Bus start Phys start SizeFlags > > 0 0x9000 0x9000 0x1000 mem > > 1 0x 0x 0x0800 mem sysmem > > 2 0xc000 0xc000 0x0001 io io > > > > - Linux dmesg (grep for pci and xhci) > > > > [ 13.163011][T1] mvebu-pcie mbus@f100:pcie@8200: host > > bridge /mbus@f100/pcie@8200 ranges: > > [ 13.163147][T1] mvebu-pcie mbus@f100:pcie@8200: > > MEM 0x00f104..0x00f1041fff -> 0x04 > > [ 13.163217][T1] mvebu-pcie mbus@f100:pcie@8200: > > MEM 0x..0x00fffe -> 0x01 > > [ 13.163268][T1] mvebu-pcie mbus@f100:pcie@8200: > > IO 0x..0x00fffe -> 0x01 > > [ 13.163754][T1] mvebu-pcie mbus@f100:pcie@8200: PCI > > host bridge to bus :00 > > [ 13.163791][T1] pci_bus :00: root bus resource [bus 00-ff] > > [ 13.163829][T1] pci_bus :00: root bus resource [mem > > 0xf104-0xf1041fff] (bus address [0x0004-0x00041fff]) > > [ 13.163862][T1] pci_bus :00: root bus resource [mem > > 0xe000-0xefff] > > [ 13.163892][T1] pci_bus :00: root bus resource [io > > 0x1000-0xe] > > [ 13.164075][T1] pci :00:01.0: [11ab:6281] type 01 class 0x060400 > > [ 13.164133][T1] pci :00:01.0: reg 0x38: [mem > > 0x-0x07ff pref] > > [ 13.165893][T1] PCI: bus0: Fast back to back transfers disabled > > [ 13.165949][T1] pci :00:01.0: bridge configuration invalid > > ([bus 00-00]), reconfiguring > > [ 13.166276][T1] pci :01:00.0: [1b73:1009] type 00 class 0x0c0330 > > [ 13.166334][T1] pci :01:00.0: reg 0x10: [mem > > 0x-0x 64bit] > > [ 13.166381][T1] pci :01:00.0: reg 0x18: [mem > > 0x-0x0fff 64bit] > > [ 13.166424][T1] pci :01:00.0: reg 0x20: [mem > > 0x-0x0fff 64bit] > > [ 13.166561][T1] pci :01:00.0: supports D1 > > [ 13.166588][T1] pci :01:00.0: PME# supported from D0 D1 D3hot > > [ 13.166685][T1] pci :01:00.0: 2.000 Gb/s available PCIe > > bandwidth, limited by 2.5 GT/s PCIe x1 link at :00:01.0 (capable > > of 4.000 Gb/s with 5.0 GT/s PCIe x1 link) > > [
Testing pci_mvebu.c with Kirkwood SoCs
Hello! On Sunday 07 November 2021 12:56:37 Tony Dinh wrote: > Hi Pali, > > I've applied your patch, and ran some tests. Looks like we got to the > bind, but it was not probing (or the probe died silently). Later, I > tried pci enum and got some errors during probing. It looks like that arch/arm/mach-kirkwood/cpu.c already setup PCIe windows. Therefore when pci_mvebu.c tries it too, it fails on error "conflicts with another window" which you see in the log. Could you try to comment calling of "mvebu_mbus_add_window_by_id" function in pci_mvebu.c? As PCIe window setup should be done exactly once. Also try to call 'pci 0' and 'pci 1' after the 'pci enum'. > Here is the log (I added some debug printf to drivers/pci/pci_mvebu.c > and drivers/core/device.c to see the progress). > > - U-Boot boot log: > > U-Boot 2022.01-tld-1-00054-g52207514ba-dirty (Nov 06 2021 - 18:11:41 -0700) > Pogoplug V4 > > SoC: Kirkwood 88F6281_A1 > DRAM: 128 MiB > mvebu_pcie_bind: begin > mvebu_pcie_bind: got an available node > Bound device to pcie@8200 > mvebu_pcie_bind: bound > mvebu_pcie_bind: exit 0 > Bound device pcie@8200 to mbus@f100 > Bound device mbus@f100 to root_driver > Bound device ehci@5 to ocp@f100 > Bound device ethernet-controller@72000 to ocp@f100 > Bound device sata@8 to ocp@f100 > Bound device mvs...@9.blk to mvsdio@9 > Bound device mvsdio@9 to ocp@f100 > Bound device ocp@f100 to root_driver > NAND: 128 MiB > MMC: mvsdio@9: 0 > Loading Environment from NAND... *** Warning - bad CRC, using default > environment > > In:serial > Out: serial > Err: serial > Net: > Warning: ethernet-controller@72000 (eth0) using random MAC address - > 66:43:1f:50:f0:e7 > eth0: ethernet-controller@72000 > Hit any key to stop autoboot: 0 > > Pogo_V4> pci > No such bus > Pogo_V4> pci 0 > No such bus > Pogo_V4> pci 1 > No such bus > > Pogo_V4> pci enum > mvebu_pcie_probe: > Cannot add window '4:e8', conflicts with another window > PCIe unable to add mbus window for mem at 9000+1000 > Cannot add window '4:e0', conflicts with another window > PCIe unable to add mbus window for IO at c000+0001 > mvebu_pcie_probe: exit 0 > Bound device pci_0:0.0 to pcie0.0 > Bound device xhci_pci to pci_0:0.0 > > Pogo_V4> pci regions > # Bus start Phys start SizeFlags > 0 0x9000 0x9000 0x1000 mem > 1 0x 0x 0x0800 mem sysmem > 2 0xc000 0xc000 0x0001 io io > > - Linux dmesg (grep for pci and xhci) > > [ 13.163011][T1] mvebu-pcie mbus@f100:pcie@8200: host > bridge /mbus@f100/pcie@8200 ranges: > [ 13.163147][T1] mvebu-pcie mbus@f100:pcie@8200: > MEM 0x00f104..0x00f1041fff -> 0x04 > [ 13.163217][T1] mvebu-pcie mbus@f100:pcie@8200: > MEM 0x..0x00fffe -> 0x01 > [ 13.163268][T1] mvebu-pcie mbus@f100:pcie@8200: > IO 0x..0x00fffe -> 0x01 > [ 13.163754][T1] mvebu-pcie mbus@f100:pcie@8200: PCI > host bridge to bus :00 > [ 13.163791][T1] pci_bus :00: root bus resource [bus 00-ff] > [ 13.163829][T1] pci_bus :00: root bus resource [mem > 0xf104-0xf1041fff] (bus address [0x0004-0x00041fff]) > [ 13.163862][T1] pci_bus :00: root bus resource [mem > 0xe000-0xefff] > [ 13.163892][T1] pci_bus :00: root bus resource [io 0x1000-0xe] > [ 13.164075][T1] pci :00:01.0: [11ab:6281] type 01 class 0x060400 > [ 13.164133][T1] pci :00:01.0: reg 0x38: [mem > 0x-0x07ff pref] > [ 13.165893][T1] PCI: bus0: Fast back to back transfers disabled > [ 13.165949][T1] pci :00:01.0: bridge configuration invalid > ([bus 00-00]), reconfiguring > [ 13.166276][T1] pci :01:00.0: [1b73:1009] type 00 class 0x0c0330 > [ 13.166334][T1] pci :01:00.0: reg 0x10: [mem > 0x-0x 64bit] > [ 13.166381][T1] pci :01:00.0: reg 0x18: [mem > 0x-0x0fff 64bit] > [ 13.166424][T1] pci :01:00.0: reg 0x20: [mem > 0x-0x0fff 64bit] > [ 13.166561][T1] pci :01:00.0: supports D1 > [ 13.166588][T1] pci :01:00.0: PME# supported from D0 D1 D3hot > [ 13.166685][T1] pci :01:00.0: 2.000 Gb/s available PCIe > bandwidth, limited by 2.5 GT/s PCIe x1 link at :00:01.0 (capable > of 4.000 Gb/s with 5.0 GT/s PCIe x1 link) > [ 13.197158][T1] PCI: bus1: Fast back to back transfers disabled > [ 13.197208][T1] pci_bus :01: busn_res: [bus 01-ff] end is > updated to 01 > [ 13.197538][T1] pci :00:01.0: BAR 14: assigned [mem > 0xe000-0xe00f] > [ 13.197581][T1] pci :00:01.0: BAR 6: assigned [mem > 0xe010-0xe01007ff pref] > [ 13.197624][T1] pci :01:00.0: BAR 0: assigned [mem >
