search

lategoodbye / rpi-zero

Linux kernel source tree
Other
22 stars 3 forks source link

Upstream Raspberry Pi 4 B support #43

Open lategoodbye opened 5 years ago

lategoodbye commented 5 years ago

The Raspberry Pi 4 B has a new brand SoC BCM2711 (1.5GHz Quad A72, VideoCore 6)

Upstream status:

Component Status Assigned
pinctrl Applied for 5.4 -
sdhci Applied for 5.4 -
sdhci SD power support Applied for 5.x Nicolas Saenz Julienne
i2c Applied for 5.4 -
initial clock support Applied for 5.4 Stefan Wahren
initial devicetree Applied for 5.5 Stefan Wahren
bluetooth Applied for 5.5 Stefan Wahren
thermal Applied for 5.6 Stefan Wahren
hwrng Applied for 5.6 Stephen Brennan
spi Applied for 6.0 Martin Sperl
bcm2835-power Applied for 6.0 Stefan Wahren
GENET Applied for 5.5 Matthias Brugger, Stefan Wahren
GENET clocks tbd Unknown
GENET auto power down Applied for 5.16 Florian Fainelli
DMA arm32 WIP Nicolas Saenz Julienne
DMA arm64 Applied for 5.5 Nicolas Saenz Julienne
PCIe Applied for 5.6 James Quinlan, Nicolas Saenz Julienne
PCIe CLKREQ# mode Applied for 6.8 James Quinlan
NVRAM Wifi configuration Applied Matthias Brugger
Wifi firmware with Kr00k fixes Applied
DMA engine 40 bit support RFC Cleanup Dave Stevenson
VCHIQ camera updates Unknown
VCHIQ audio updates Unknown
VCHIQ VPU/CPU shmem (vcsm-cma) WIP Umang Jain, Laurent Pinchart
VCHIQ ISP WIP Umang Jain, Laurent Pinchart
VCHIQ codecs Unknown
clk-bcm2835 improvements Unknown
VL805 LPM support Applied for 5.7 Nicolas Saenz Julienne
built-in xHCI Applied for 6.8 Stefan Wahren
xHCI quirks Unknown
GPIO labels Applied for 5.7 Stefan Wahren
58 GPIO support Applied for 5.7 Stefan Wahren
BCM2711 get pinconf Applied for 6.10 Stefan Wahren
DVFS cpufreq support Unknown
VC4 HDMI (Display/Audio) Applied for 5.10 Maxime Ripard
V3D GPU Applied for 6.0 Nicolas Saenz Julienne, Peter Robinson
PoE Fan hat Applied for 5.13 Nicolas Saenz Julienne

Important note: This issue consolidates all the information about the upstreaming of the BCM2711 / Raspberry Pi 4. Please do not report any new issues here because it makes it very hard to track.

vianpl commented 3 years ago

@charlesfendt Yes, CM4 uses the same SoC BCM2711, and at first sight, there aren't many HW changes. That said, as @lategoodbye says, the devil is in the details. The boards aren't available yet. It's just a pre-order. Once I get my hands into one of them, I'll update this issue with more information on the actual challenges.

6by9 commented 3 years ago

@vianpl I'll ping Gordon to see if we can arrange for a CM4 (or some flavour) and CMIO4 to be sent out to you. I assume your suse.de address is the best one to contact you? We'll need a shipping address and contact phone number.

lategoodbye commented 3 years ago

Please post everything CM4 related stuff in #48 Thanks

lategoodbye commented 3 years ago

Please post everything Raspberry Pi 400 related here

Btw there are news about V3D

steev commented 3 years ago

May I ask - spi is mentioned as being Under review, but I can't seem to find where the review is being done? I have checked the linux-kernel-rpi mailing list and not finding it there?

lategoodbye commented 3 years ago

Sorry, i need to say: it's complicated.

The relevant patch spi: bcm2835: Enable shared interrupt support has been applied and reverted at the same day since it caused a regression.

But i lost track of the last discussion. I assume this is the last patch version: https://patchwork.kernel.org/project/spi-devel-general/patch/20200604212819.715-1-f.fainelli@gmail.com/

Regarding to your last question. Driver patches doesn't need to be send to linux-kernel-rpi in order to get applied. The subsystem mailing list is more relevant.

I will update the status.

steev commented 3 years ago

Ah, fair enough, thanks for the pointer. I'm used to the msm mailing list where it goes to msm as well as the subsystems. Thanks for the heads up. I guess I'll look into it a bit myself since it seems to be untouched since 2020 06.

lategoodbye commented 3 years ago

More information about DMA: https://github.com/raspberrypi/documentation/issues/1903

C-Erastus commented 3 years ago

Hi @lategoodbye . I would like to contribute; I see that the above list hasn't been updated in a while. Could you please reply with a list of things that needs to be worked on so I can pick one?

A little about myself, I'm Erastus, a software engineer at Red Hat. I work on the kernel team.

lategoodbye commented 3 years ago

Hi @chukpozohnToe, thanks for your interest. The list above represent my understanding and is up to date.

Are your contributions limited to the Raspberry Pi 4 or do they cover general Raspberry Pi topics?

What do you want to do:

nullr0ute commented 3 years ago

The latest v3d RFC patchset is here https://lists.freedesktop.org/archives/dri-devel/2021-February/297035.html but it's currently blocked due to lack of information/feedback on the power domain pieces from RPi/Broadcom.

The POE HAT pwm pieces landed upstream in 5.13.

There's new cyprus firmwares for the kr00k fixes in upstream linux-firmware that work with RPi series. Although there's no firmware for the RPi-400 in linux-firmware because it's a synaptics part.

lategoodbye commented 3 years ago

@nullr0ute Thanks for the update. Nicolas has added some points that i wasn't totally aware of.

Regarding the kr00k fixes firmware, i'm not sure that the stability issues has been fixed.

nullr0ute commented 3 years ago

Regarding the kr00k fixes firmware, i'm not sure that the stability issues has been fixed.

I'm basing it purely on Fedora uses, and we have the same brcmfmac devices across a number of devices, and we've had no complaints (and people complain quickly and often). Also note that upstream there's a newer cypress firmware (will be in the next tagged release in the next day or so) that also fixes the more recent "12 frag attacks" vulnerabilities too.

nullr0ute commented 3 years ago

@nullr0ute Thanks for the update. Nicolas has added some points that i wasn't totally aware of.

It would be really awesome if we could get some assistance to sort out the power domain v3d issues. It's probably the highest request I get.

lategoodbye commented 3 years ago

I'm sorry, i cannot help with this point.

C-Erastus commented 3 years ago

Hi @chukpozohnToe, thanks for your interest. The list above represent my understanding and is up to date.

Are your contributions limited to the Raspberry Pi 4 or do they cover general Raspberry Pi topics?

What do you want to do:

  • fixing recent regressions
  • upstream vendor patches
  • help to move drivers out of staging
  • implement new feature

My contributions cover general Raspberry pi topics. I would like to "implementing new feature" and also "fixing recent regressions". But over time, it'll be fun to venture in the others.

lategoodbye commented 3 years ago

@chukpozohnToe Regarding new features, you are little bit on your on. You can pick one topic from the list above, but it's much easier to upstream existing vendor patches. But i'm always available as reviewer.

Here are the recent critical regressions i'm aware of (5.13 & 5.14):

  1. https://www.spinics.net/lists/arm-kernel/msg905208.html (rejected workaround: https://www.spinics.net/lists/arm-kernel/msg906871.html)
  2. https://lists.freedesktop.org/archives/dri-devel/2021-July/313827.html (there is already a fix for the regression, but not for the root cause)
  3. https://lists.freedesktop.org/archives/dri-devel/2021-July/315306.html

There might be more ;-)

Update: The workaround for 1. has been applied and Maxime Ripard is working on 2.

C-Erastus commented 3 years ago

@lategoodbye I will take your word for it and upstream existing vendor patches. But it's definitely a goal of mine to implement a new feature some day. Do you have a list of vendor patches that needs to be upstreamed?

lategoodbye commented 3 years ago

Here is a list: https://github.com/lategoodbye/rpi-zero/issues/21

But it's not complete. I can add more.

Relevant candidates have status: not send yet

Be aware: some patches need commit log rewording or other improvements

C-Erastus commented 3 years ago

@lategoodbye I'm going to take a crack at "[Regression] No framebuffer console on Rpi since 5.14-rc1" https://lists.freedesktop.org/archives/dri-devel/2021-July/315306.html

If you any information on it, I'll appreciate it.

lategoodbye commented 3 years ago

Good choice (see my update above) ;-)

In my opinion the dependencies of VC4 are not correct, but i'm not sure other drm drivers are also affected. Everything else is written on the mailing list.

You said that you are in the kernel team. Did you ever submitted a kernel patch?

C-Erastus commented 3 years ago

@lategoodbye I've not submitted a kernel patch yet but I know the process.

I'm new to the team, two weeks in. (New college grad).

lategoodbye commented 3 years ago

Okay, so you work on this regression? Please ask if you have any questions.

C-Erastus commented 3 years ago

@lategoodbye sorry for the late reply but yes I've been working on the regression. I tried recreating the problem by compiling the new kernel. I had some problems compiling the kernel but I eventually got it to work. The regression doesn't seem to be an issue because my pi boot up just fine. I compiled the kernel version 5.14.0-rc3 and when I did a 'uname -r' after the process, the compiled kernel version was listed....I'm not sure if it was something I did or something someone else did in the -rc3

pi version = RPi4 B OS = ubuntu

lategoodbye commented 3 years ago

@chukpozohnToe Just to make it clear, you did the following steps: setup compiler checkout v5.14-rc3 make multi_v7_defconfig make menuconfig and enable CONFIG_ARM_LPAE make

EDIT: missing step added

C-Erastus commented 3 years ago

@lategoodbye I didn't do the "make multi_v7_deconfig" part. I compiled the kernel as I usually do. Currently doing another run with the steps you described.

lategoodbye commented 3 years ago

@chukpozohnToe I'm sorry i missed another step. Please see above.

C-Erastus commented 3 years ago

According to you notes (I came across it while doing some research) I don't need to do "make menuconfig and enable CONFIG_ARM_LPAE", my Pi is 64bit. Btw how compiled the mainline kernel's very different from how I did it. It did it on Ubuntu 20.04 focal.

https://gist.github.com/lategoodbye/c7317a42bf7f9c07f5a91baed8c68f75#raspberry-pi-how-to-cross-compile-and-use-mainline-kernel

lategoodbye commented 2 years ago

40 bit support for BCM2711 DMA controller has been send out as RFC (not functional): https://lore.kernel.org/linux-arm-kernel/1640606743-10993-1-git-send-email-stefan.wahren@i2se.com/T/#t

hamishmb commented 2 years ago

What's the current status of this, out of interest?

lategoodbye commented 2 years ago

@hamishmb What do you mean with this? The whole status of the work or the DMA controller?

I spent a lot of spare time to fix regressions for this platform. So there is not much left for "new" topics like upstreaming.

hamishmb commented 2 years ago

Oh well, it's just been a while, so I was wondering whether this was complete - I just happened across the thread.

lategoodbye commented 2 years ago

The table on top is almost up to date.

Recent i found a good article which also applies here When will mainlining be done? But as long as most of the Linux distributions use the downstream kernel this job will never be finished.

hamishmb commented 2 years ago

Yeah, it is annoying that eg Raspberry Pi OS isn't using upstream Linux.

That's why I didn't ask for an ETA, but sorry if it still came across as pestering - I know it's not an easy job.

lategoodbye commented 2 years ago

I didn't expect that the Raspberry Pi trading would use the mainline kernel, because they need to integrate new hardware fast. But Arch Linux ARM discourage users from using the mainline kernel, this makes me sad.

No, you didn't pester me. Glad to see there is still interest in this topic.

stapelberg commented 2 years ago

Glad to see there is still interest in this topic.

There definitely is interest!

https://gokrazy.org/ uses the latest version of the upstream linux kernel and hence much of your work! So thank you for all that you have made possible :)

nullr0ute commented 2 years ago

Fedora uses a purely upstream kernel.

diederikdehaas commented 1 year ago

FWIW: Debian uses the upstream kernel as well.

I wonder what the current upstream status is wrt SPI. In the table above it is listed as Rework needed and I wonder whether that has been done since (https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=89fcdd53c2528b8f0ed34553aaf9826fe63848b5 seems related)?

lategoodbye commented 1 year ago

@diederikdehaas Thanks for pointing out, i updated the table.

alien999999999 commented 1 year ago

The Raspberry Pi 4 B has a new brand SoC BCM2711 (1.5GHz Quad A72, VideoCore 6)

* LPDDR4 (1-4 GB)

So, I have an RPI 4B with 8GB ram? maybe this could be updated?

Also, from dri-devel mailinglist, someone pointed out to me that any video decoding is in SW because VCHIQ_codec seems to be the one that does this. IIRC there was a link i found sometime ago that had the sources to build these vchiq things? but i cannot find it anymore...

lategoodbye commented 1 year ago

So, I have an RPI 4B with 8GB ram? maybe this could be updated?

Done. Thanks

Also, from dri-devel mailinglist, someone pointed out to me that any video decoding is in SW because VCHIQ_codec seems to be the one that does this. IIRC there was a link i found sometime ago that had the sources to build these vchiq things? but i cannot find it anymore...

The video codecs based on VCHIQ aren't mainlined yet, because the VCHIQ driver itself is still in staging. Also there is no official BCM2711 support for VCHIQ in mainline yet.

alien999999999 commented 1 year ago

i seem to remember a link to a git with some patches that converted armv7 to aarch64 stuff where it had vchiq_arm and such for cec-client to work, but now that i'm looking for this, i can't find it anymore....

6by9 commented 1 year ago

CEC is handled through the vc4 driver in mainline - no need for VCHIQ.

cec-client doesn't handle multiple Linux kernel CEC API interfaces - it has hard defines like that at https://github.com/Pulse-Eight/libcec/blob/master/include/cectypes.h#L287

Use cec-ctl (part of v4l-utils) instead of libcec - libcec is largely abandonware.

alien999999999 commented 1 year ago

ic, it's just, in the past, i wasn't able to use cec-ctl but cec-client worked, i'll have to spend some time with cec-ctl to understand it more and see if i can get things working like that...

Headcrabed commented 1 year ago

This quirk is already upstreamed, but it is still in this table.

Headcrabed commented 1 year ago

Also, "GENET auto power down" is implemented in a different way than the downstream driver.

6by9 commented 10 months ago

Just FYI, I'm picking up your 40bit DMA patchset to get it working, and update for 2712 as well. I'd hope to be looking at early in the new year for a patch set, but it's a slightly moving target.

lategoodbye commented 10 months ago

@6by9 Thank you very much. This is great :heart:

lategoodbye commented 3 months ago

This is not specific to the Raspberry Pi 4, but i assume this is a long expected Mainline feature: GPIO output persistence

It will be rolled out with the upcoming Linux 6.10: https://github.com/torvalds/linux/commit/8ff05989b44e1a8f7d2bbe67320990ebc2fbb5e5