From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=DATE_IN_PAST_03_06 autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 9240 invoked from network); 26 Jan 2021 14:50:08 -0000 Received: from 1ess.inri.net (216.126.196.35) by inbox.vuxu.org with ESMTPUTF8; 26 Jan 2021 14:50:08 -0000 Received: from duke.felloff.net ([216.126.196.34]) by 1ess; Tue Jan 26 06:21:35 -0500 2021 Message-ID: Date: Tue, 26 Jan 2021 12:21:23 +0100 From: cinap_lenrek@felloff.net To: 9front@9front.org In-Reply-To: <010001773cc26554-a456b631-4a33-4832-a4b0-ee187a34411d-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: generic firewall proxy-based enhancement Subject: Re: [9front] 9front on Raspberry Pi 400 Reply-To: 9front@9front.org Precedence: bulk > xhci 600000000: controller not ready before reset: 00000815 > xhci 600000000: controller not halted after reset: 00000815 > xhci 600000000: controller not ready after run: 0000080d ok, this means the controller never clears the "Host Controller Halted" and "Host Controller Not Ready" bits in the status register. so it is possible the xhcireset() firmware command is not having the desired effect on the pi400? the mailbox command xhcireset() is run right after our pcie controller reset, after we enumerated the pci bus, but before we attempt to reset the xhci controller. see in autogenerated pi4.c: void links(void){ bootlinks(); gisblink(); pcibcmlink(); <- pcie controller reset and enumeration archbcm4link(); <- here we do the xhcireset call to firmware usbxhcilink(); <- registers the xhci driver, will attempt to reset later ethergenetlink(); ethermediumlink(); loopbackmediumlink(); } i know that richard put the xhcireset() call directly in the xhci driver init function. the reason i did not do that was because my xhci driver is portable and shared with the pc and pc64 kernels and i do not want to clutter it with work arounds for raspberry pi. the effects that these differences might have is that we do not enable the pci device before the xhcireset() call, and that we do not do the xhci handoff. well... and timing differences... so the simplest thing to try first would be to put a pcienable() call before the xhcireset() like: diff -r 5c327eddc496 sys/src/9/bcm64/archbcm4.c --- a/sys/src/9/bcm64/archbcm4.c Sat Jan 23 20:36:09 2021 -0800 +++ b/sys/src/9/bcm64/archbcm4.c Tue Jan 26 12:01:03 2021 +0100 @@ -183,8 +183,10 @@ * for the firmware to dictate the PCI configuration. Consequently, the mailbox * is required so that the OS can reset the VLI after asserting PCI chip reset. */ - if((p = pcimatch(nil, 0x1106, 0x3483)) != nil) + if((p = pcimatch(nil, 0x1106, 0x3483)) != nil){ + pcienable(p); xhcireset(BUSBNO(p->tbdf)<<20 | BUSDNO(p->tbdf)<<15 | BUSFNO(p->tbdf)<<12); + } // addclock0link(wdogfeed, HZ); } it is unclear to me why the code works fine on the pi4 8GB model tho. another possibility is you have the wrong firmware files for the pi400 in the image. if that also fails, i can put in a hook in the xhci driver and we execute the xhcireset magic function in the exact same place as with richards driver next. the other difference we have is that our kernel is 64 bit one, and firmware loader takes different codepaths for these kernel types, so might leave the machine in a different state when handing control to the kernel. anyway, can you also provide me with the GIC debug prints i put? -- cinap