From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from duke.felloff.net ([216.126.196.34]) by ewsd; Thu Jun 4 13:21:55 EDT 2020 Message-ID: <8E4C3147C1267DCDC62534C942FF1A46@felloff.net> Date: Thu, 4 Jun 2020 19:21:44 +0200 From: cinap_lenrek@felloff.net To: 9front@9front.org Subject: Re: [9front] 9front and raspberry pi 4 8gb model In-Reply-To: <5cf90fb3-af57-15ce-ff44-68cf884a7d2a@gmail.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: full-stack YAML core property realtime-java metadata-based backend i do know as much as you about this issue. maybe you also need to update bootcode.bin in the image? or it needs another device tree file? or some new file we dont know about? the next steps would be to print the return value of xhcireset()... maybe that can give us a hint if the command was supported by the firmware or not. you can also ask richard miller about this... maybe download his image and see if this works. and see what firmware and device tree files he has there. we could also to take a look at raspbian image. and in see what they do in the linux kernel. the diff i send is based on richard millers patch. i only tested that it doesnt break my raspberry pi 4 with 1gb ram. i had to move the xhcireset() call to archinit() tho which is basically just after pci controller reset and after we mapped the bus and programmed the membars. originally, the xhcireset() call was after firmware handoff in the usbxhci driver itself, but i asked richard if he could try to do the reset earlier because our xhci driver is in port/, and this is very raspberry pi specific quirk that doesnt belong into the portable driver. richard confirmed that it still works when doing the firmware call before the pcienable(), but maybe theres some other side effect. could even be just timing. good luck. -- cinap