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=0.0 required=5.0 tests=none autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 21443 invoked from network); 23 Jan 2021 16:40:35 -0000 Received: from 1ess.inri.net (216.126.196.35) by inbox.vuxu.org with ESMTPUTF8; 23 Jan 2021 16:40:35 -0000 Received: from duke.felloff.net ([216.126.196.34]) by 1ess; Sat Jan 23 11:11:16 -0500 2021 Message-ID: Date: Sat, 23 Jan 2021 17:11:04 +0100 From: cinap_lenrek@felloff.net To: 9front@9front.org In-Reply-To: <0100017720d2f6b4-a93bc058-3523-49a3-99c9-41d030c74716-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: cache-based factory DOM metadata Subject: Re: [9front] 9front on Raspberry Pi 400 Reply-To: 9front@9front.org Precedence: bulk > In my many times trying different things, I have had a few other errors. > However, what I am showing is what I am getting now consistently having done the following. There might be some differences in the sdhc controller driver. I can take a look later today and see... > I’ve replaced the Pi firmware files with the latest at of today. > I then added ‘enable_gic=1’ to the config.txt file with no change. The 9front pi4 kernel is for arm64 (armv8), where the GIC is required. The firmware should have enabled the GIC when loading a 64-bit kernel. Tho i had encountered some firmware bugs before where firmware disabled the GIC (just masked interrupt routing to EL1) when the kernel image file was not a multiple of 4 bytes. But i think they fixed that. There are some mask registers in the GIC that we could check to see if this is the case. > Consistent amongst the previous attempts were the same one or two errors > repeated many times, and not keyboard or mouse response > (not surprising as the newer Pis need to have their usb firmware uploaded in the kernel). I do not know what you mean by this. The kernel does the firmware mailbox call to notify firmware that we did a reset of the pcie controller to load the XHCI firmware. This was a problem with the 8GB models of the raspberry pi4 and has been addressed. This is done in /sys/src/9/bcm64/archbcm4.c:^archbcm4link() function: void archbcm4link(void) { Pcidev *p; /* * The firmware resets PCI before starting the host OS because * without SDRAM the VL805 makes inbound requests to page-in firmware * from SDRAM. If the OS has a different PCI mapping that would all break. * There's no way to pause and move the mappings and it's not really desirable * 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) xhcireset(BUSBNO(p->tbdf)<<20 | BUSDNO(p->tbdf)<<15 | BUSFNO(p->tbdf)<<12); // addclock0link(wdogfeed, HZ); } I do not know the pi400 architecture but could it be possible that they connected the keyboard to the DesignWave usb 2.0 controller instead? The pi4 kernel does not include the dwc controller driver like the pi3, because on the pi4 it is not used. On the pi400 i do not know. > In case there were newer updates to the source, I did a sysupdate on a laptop > I have with 9 and then tried to cross-compile a new kernel. > However, I get a much smaller kernel (only 2.9MB rather than the 4.4MB in the > 9front Pi image. I don’t know if this is unexpected. When I try to boot that kernel. > The console screen comes up. But after CPU detection, the kernel panics and stops booting. The 9front kernel includes a small compressed ram filesystem with a shell environment (you can enter it by typing !rc on bootargs prompt). Before you build the kernel, you need to have all these userspace programs compiled for the kernel's architecture (arm64 in this case). I do not know how you compiled the pi4 kernel, but here is how it should work on 9front: 1) Compile userspace cd /sys/src objtype=arm64 mk install 2) Compile the kernel cd /sys/src/9/bcm64 mk 'CONF=pi4' install now, you should'v got a /arm64/9pi4 and /arm64/s9pi4. The 9pi4 file is a stripped raw flat image that can be loaded by the pi's firmware. The s9pi4 file is the same kernel with the native a.out header and debug symbols, so it can be loaded in acid and also used for /dev/reboot'ing into it from a running system. Hope this helps... -- cinap