Re: [9front] 9front on Raspberry Pi 400

[cinap_lenrek@felloff.net]

> 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