9front - general discussion about 9front
 help / color / mirror / Atom feed
From: cinap_lenrek@felloff.net
To: 9front@9front.org
Subject: Re: [9front] 9front on Raspberry Pi 400
Date: Sat, 23 Jan 2021 17:11:04 +0100	[thread overview]
Message-ID: <AC97A2D26CB65CE23E2C07919A088644@felloff.net> (raw)
In-Reply-To: <0100017720d2f6b4-a93bc058-3523-49a3-99c9-41d030c74716-000000@email.amazonses.com>

> 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

  reply	other threads:[~2021-01-23 16:40 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-20 17:23 Mack Wallace
2021-01-23 16:11 ` cinap_lenrek [this message]
2021-01-23 21:08   ` Mack Wallace
2021-01-23 21:13   ` Mack Wallace
2021-01-23 23:42     ` cinap_lenrek
2021-01-24 15:01       ` cinap_lenrek
2021-01-26  3:33         ` Mack Wallace
2021-01-26  3:35         ` Mack Wallace
2021-01-26 11:21           ` cinap_lenrek
2021-01-26 12:09           ` cinap_lenrek
2021-01-27  2:32             ` Mack Wallace
2021-01-27 14:30               ` cinap_lenrek
2021-01-27 17:04               ` cinap_lenrek
2021-01-27 17:57               ` cinap_lenrek
2021-01-29 14:58               ` cinap_lenrek
2021-01-30  2:43                 ` Mack Wallace
2021-01-30  5:54                   ` cinap_lenrek
2021-01-30 19:23                     ` Mack Wallace
2021-01-30 19:41                       ` cinap_lenrek
2021-01-30 19:46                       ` cinap_lenrek
2021-02-01  1:16                         ` Mack Wallace

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AC97A2D26CB65CE23E2C07919A088644@felloff.net \
    --to=cinap_lenrek@felloff.net \
    --cc=9front@9front.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).