Upstream Raspberry Pi 4 B support

[lategoodbye]

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

• LPDDR4 (1-8 GB)
• VIA Labs VL805 USB 3.0 Host controller (XHCI)
• USB bridge with 2x USB 3.0 and 2x USB 2.0 ports
• DWC2 controller with 1 USB C USB Host / Peripheral port
• Gigabit Ethernet with BCM54213PE PHY
• 2x Micro HDMI 2.0 slots
• PCIe 2.0 bus with 1 lane (USB hub)
• 40 bit DMA controller
• GICv2 interrupt controller
• new eMMC controller (support for DDR50)
• 58 GPIOs
• 6 UART
• 5 SPI
• 6 I2C (without clock stretch bug)
• 2 DSI
• 2 CSI
• 2 PWM units with 2 channels
• Cypress CYW43455 (802.11 b/g/n/ac Wifi chip via SDIO, Bluetooth 5.0 via UART)

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.

[lategoodbye]

High prio TODOs:

• clk changes
• spi controller changes
• DMA controller changes

Low prio TODOs:

• interrupt controller changes
• power changes (new driver?)
• V3D changes
• USB changes
• vchiq changes

[lategoodbye]

For pinctrl i prefer to use this patch. Since the pinctrl-bcm2835 is generic now, we should use the generic bias properties (bias-disable, bias-pull-up).

[lategoodbye]

So finally here is the first draft for minimal RPi 4 support: https://github.com/lategoodbye/rpi-zero/tree/bcm2838-initial

Beware: this is only compile tested!

Note: currently this doesn't seem to boot

Edit: multi_v7_defconfig seems to be broken

[vianpl]

Note: currently this doesn't seem to boot

Hi @lategoodbye, where you aware of this: https://github.com/raspberrypi/linux/issues/3032#issuecomment-507356208. It could be one of the reasons.

[lategoodbye]

This should be only relevant for aarch64. But thanks for the note. I tried to build the downstream kernel tree with multi_v7_defconfig and this fails to boot differently. So i think this should be fixed first: https://github.com/raspberrypi/linux/issues/3057

[lategoodbye]

The changes should boot now.

[lategoodbye]

Here is a more cleaner version, which is ready for RFC: https://github.com/lategoodbye/rpi-zero/tree/bcm2838-initial-rfc

[lategoodbye]

The RFC series is out now: https://marc.info/?l=linux-arm-kernel&m=156339329211593&w=2

[lategoodbye]

The version 1 is ready for rebase on top of 5.3-rc1: https://github.com/lategoodbye/rpi-zero/tree/bcm2711-initial

Changes:

• change BCM2838 -> BCM2711 as discussed in RFC
• update MAINTAINERS accordingly
• drop "spi: bcm2835: enable shared interrupt support" from series
• squash all pinctrl-bcm2835 changes into one patch
• introduce SoC specific clock registration as suggested by Florian
• fix watchdog probing for Raspberry Pi 4
• convert brcm,bcm2835.txt to json-schema
• move VC4 node to bcm2835-common.dtsi
• fallback to legacy pull config for Raspberry Pi 4
• revert unintended change of mailbox in bcm283x.dtsi
• add reference for arm64

[lategoodbye]

The version 2 is ready: https://github.com/lategoodbye/rpi-zero/tree/bcm2711-initial-v2

Changes:

• rebased on top of Linux 5.3-rc2
• use separate board file for BCM2711
• enable ARM_GIC for ARCH_BCM2835
• move already applied patches at the beginning
• add Acked-by and Reviewed-by
• fix arm-pmu and timer nodes for BCM2711 noticed by Marc
• enable HDMI at board level
• move HDMI and pixelvalve into bcm2835-common.dtsi as suggested by Eric
• fix DWC2 probing warning
• disable clock stretching quirk for BCM2711
• fix order of node references in bcm2711.dtsi
• mark PLLD_PER as critical clock
• make PLLH clock unavailable on BCM2711
• fix compile warning in clk-bcm2835 for arm64

[lategoodbye]

The version 3: https://github.com/lategoodbye/rpi-zero/tree/bcm2711-initial-v3

Changes:

• rebased on top of Linux 5.4-pre-rc1
• add Reviewed-by
• configure i2c pull-up in dts
• move i2c2 to bcm2835-common.dtsi
• add missing compatibles to DT schema
• fix DT schema warnings in dtsi files
• replace brcm pintrl with generic pinctrl binding
• make dma_zone_size depend on CONFIG_ZONE_DMA

[lategoodbye]

I split out the clk and the i2c changes from the original series to increase chance for Linux 5.4 merge.

Edit: i2c changes has been applied

[lategoodbye]

I prepared an initial series for the BCM2711 thermal driver (currently untested)

https://github.com/lategoodbye/rpi-zero/tree/bcm2711-thermal

[lategoodbye]

@mbgg I saw that you upstreamed the NVRAM wifi configuration for the RPi 3B+ .

Do you plan to do the same for the RPi 4B, because its different configuration?

[lategoodbye]

The V3 series is out now: https://marc.info/?l=linux-arm-kernel&m=156967248011963&w=2

[lategoodbye]

The version 4: https://github.com/lategoodbye/rpi-zero/tree/bcm2711-initial-v4

Changes:

• rebased on top of Linux 5.4-rc1
• make select CONFIG_ZONE_DMA for arm
• fix up spi reference
• drop "always-on" for armv8-timer
• add and fix comments
• fix Bluetooth
• add arm64 devicetree link

TODO:

• mention possible conflict with recent pm revert

[mbgg]

@mbgg I saw that you upstreamed the NVRAM wifi configuration for the RPi 3B+ .

Do you plan to do the same for the RPi 4B, because its different configuration?

Yes I can take care of this.

[lategoodbye]

The V4 series is out: https://marc.info/?l=linux-arm-kernel&m=157037581825574&w=2

[lategoodbye]

Based on the recent input from Florian i pushed a tested version of the thermal driver: https://github.com/lategoodbye/rpi-zero/tree/bcm2711-thermal

[lategoodbye]

New version for GENET support: https://marc.info/?l=linux-arm-kernel&m=157270222523348&w=2

and thermal support are out: https://marc.info/?l=linux-arm-kernel&m=157261586102794&w=2

[lategoodbye]

First version of PCIe support: https://marc.info/?l=linux-arm-kernel&m=157307676011376&w=2

[lategoodbye]

Currently booting a RPi 4 (linux-next, multi_v7_defconfig) on ARM32 with more RAM than 1 GB will result in a kernel crash:

[    2.994985] Unable to handle kernel paging request at virtual address bb000000
[    3.002349] pgd = (ptrval)
[    3.005101] [bb000000] *pgd=00000000
[    3.008744] Internal error: Oops: 2805 [#1] SMP ARM
[    3.013705] Modules linked in:
[    3.016816] CPU: 0 PID: 89 Comm: kworker/0:1H Not tainted 5.4.0-rc8-next-20191122-g122fbdf48 #2
[    3.025666] Hardware name: BCM2711
[    3.029139] Workqueue: mmc_complete mmc_blk_mq_complete_work
[    3.034897] PC is at v7_dma_inv_range+0x3c/0x54
[    3.039499] LR is at dma_cache_maint_page+0x108/0x11c
[    3.044628] pc : [<c032038c>]    lr : [<c0319d1c>]    psr: 80000013
[    3.050994] sp : ebaa1da8  ip : ebaa1da8  fp : ebaa1ddc
[    3.056299] r10: 00000002  r9 : c1808fc4  r8 : c19e99c0
[    3.061605] r7 : c1804e58  r6 : 00000000  r5 : ffffb000  r4 : 00010000
[    3.068236] r3 : 0000003f  r2 : 00000040  r1 : bb010000  r0 : bb000000
[    3.074868] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[    3.082117] Control: 10c5383d  Table: 0020406a  DAC: 00000051
[    3.087953] Process kworker/0:1H (pid: 89, stack limit = 0x(ptrval))
[    3.094408] Stack: (0xebaa1da8 to 0xebaa2000)
[    3.098833] 1da0:                   00000001 0000000d 60000013 00000000 c19e99c0 c1808fc4
[    3.107146] 1dc0: 00010000 ecfdaa00 00000002 00000002 ebaa1e0c ebaa1de0 c0319f2c c0319c20
[    3.115457] 1de0: c0320424 c0387dfc ed07aa00 00000001 00000000 c100153c ef3aa810 00000002
[    3.123769] 1e00: ebaa1e24 ebaa1e10 c031aa00 c0319ea4 eba49000 00000001 ebaa1e5c ebaa1e28
[    3.132081] 1e20: c031a4c4 c031a9b4 00000000 c0388088 ebaa1e9c eba15990 c031a45c c1804e48
[    3.140393] 1e40: eb99c8c4 00000000 eba158b0 eb8c2000 ebaa1e7c ebaa1e60 c0d753f4 c031a468
[    3.148705] 1e60: 00000000 c037580c eb99c808 eba15800 ebaa1e9c ebaa1e80 c0d6cbd0 c0d75394
[    3.157016] 1e80: eb99c808 eba15800 c1804e48 eb99c8c4 ebaa1ee4 ebaa1ea0 c0d6e660 c0d6cb9c
[    3.165328] 1ea0: 00000000 e4380000 eb9a0f70 00000000 00000000 1d4372e7 c0fc707c eb99c8d8
[    3.173641] 1ec0: eb962600 effa0340 effa8400 00000000 c19acb10 00000000 ebaa1ef4 ebaa1ee8
[    3.181953] 1ee0: c0d6efbc c0d6e484 ebaa1f34 ebaa1ef8 c036cf40 c0d6ef98 eb9a0c00 ffffe000
[    3.190265] 1f00: ebaa1f1c ebaa1f10 c036ed84 eb962600 effa0340 eb962614 effa0358 ffffe000
[    3.198577] 1f20: 00000008 c1803d00 ebaa1f74 ebaa1f38 c036d2dc c036cd14 00000051 c13572e0
[    3.206889] 1f40: c19ac386 effa0340 c0373970 ef52c540 eb95ff80 00000000 ebaa0000 eb962600
[    3.215201] 1f60: c036d280 ef177e74 ebaa1fac ebaa1f78 c0374b0c c036d28c ef52c55c ef52c55c
[    3.223513] 1f80: ebaa1fac eb95ff80 c037499c 00000000 00000000 00000000 00000000 00000000
[    3.231825] 1fa0: 00000000 ebaa1fb0 c03010e8 c03749a8 00000000 00000000 00000000 00000000
[    3.240137] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    3.248448] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[    3.256758] Backtrace:
[    3.259242] [<c0319c14>] (dma_cache_maint_page) from [<c0319f2c>] (__dma_page_dev_to_cpu+0x94/0x114)
[    3.268526]  r10:00000002 r9:00000002 r8:ecfdaa00 r7:00010000 r6:c1808fc4 r5:c19e99c0
[    3.276483]  r4:00000000
[    3.279054] [<c0319e98>] (__dma_page_dev_to_cpu) from [<c031aa00>] (arm_dma_unmap_page+0x58/0x5c)
[    3.288072]  r9:00000002 r8:ef3aa810 r7:c100153c r6:00000000 r5:00000001 r4:ed07aa00
[    3.295943] [<c031a9a8>] (arm_dma_unmap_page) from [<c031a4c4>] (arm_dma_unmap_sg+0x68/0x84)
[    3.304518]  r5:00000001 r4:eba49000
[    3.308150] [<c031a45c>] (arm_dma_unmap_sg) from [<c0d753f4>] (sdhci_post_req+0x6c/0x9c)
[    3.316374]  r10:eb8c2000 r9:eba158b0 r8:00000000 r7:eb99c8c4 r6:c1804e48 r5:c031a45c
[    3.324331]  r4:eba15990
[    3.326902] [<c0d75388>] (sdhci_post_req) from [<c0d6cbd0>] (mmc_blk_mq_post_req+0x40/0xc4)
[    3.335389]  r5:eba15800 r4:eb99c808
[    3.339019] [<c0d6cb90>] (mmc_blk_mq_post_req) from [<c0d6e660>] (mmc_blk_mq_complete_prev_req.part.4+0x1e8/0x244)
[    3.349537]  r7:eb99c8c4 r6:c1804e48 r5:eba15800 r4:eb99c808
[    3.355288] [<c0d6e478>] (mmc_blk_mq_complete_prev_req.part.4) from [<c0d6efbc>] (mmc_blk_mq_complete_work+0x30/0x34)
[    3.366073]  r10:00000000 r9:c19acb10 r8:00000000 r7:effa8400 r6:effa0340 r5:eb962600
[    3.374030]  r4:eb99c8d8
[    3.376602] [<c0d6ef8c>] (mmc_blk_mq_complete_work) from [<c036cf40>] (process_one_work+0x238/0x578)
[    3.385887] [<c036cd08>] (process_one_work) from [<c036d2dc>] (worker_thread+0x5c/0x5fc)
[    3.394110]  r10:c1803d00 r9:00000008 r8:ffffe000 r7:effa0358 r6:eb962614 r5:effa0340
[    3.402066]  r4:eb962600
[    3.404637] [<c036d280>] (worker_thread) from [<c0374b0c>] (kthread+0x170/0x174)
[    3.412153]  r10:ef177e74 r9:c036d280 r8:eb962600 r7:ebaa0000 r6:00000000 r5:eb95ff80
[    3.420110]  r4:ef52c540
[    3.422682] [<c037499c>] (kthread) from [<c03010e8>] (ret_from_fork+0x14/0x2c)
[    3.430021] Exception stack(0xebaa1fb0 to 0xebaa1ff8)
[    3.435151] 1fa0:                                     00000000 00000000 00000000 00000000
[    3.443463] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    3.451774] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[    3.458496]  r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c037499c
[    3.466451]  r4:eb95ff80
[    3.469021] Code: e1110003 e1c11003 1e071f3e e1500001 (3e070f36)
[    3.475236] ---[ end trace c825dfbe2d2071d8 ]---

As a temporary workaround, place the following entry to config.txt

total_mem=1024

[brenns10]

I had a lot of trouble getting serial working on the upstream kernel (from a recent linux-next build). The mini UART is recognized by the kernel as ttyS1 which I did not find obvious (I was expecting ttyS0 and spent several hours debugging). Hopefully that can save others some time!

[nullr0ute]

I had a lot of trouble getting serial working on the upstream kernel (from a recent linux-next build). The mini UART is recognized by the kernel as ttyS1 which I did not find obvious (I was expecting ttyS0 and spent several hours debugging). Hopefully that can save others some time!

That's the same on the RPi3 when using the upstream kernel DT, if you use the firmware provided DT it's ttyS0

[lategoodbye]

I had a lot of trouble getting serial working on the upstream kernel (from a recent linux-next build). The mini UART is recognized by the kernel as ttyS1 which I did not find obvious (I was expecting ttyS0 and spent several hours debugging). Hopefully that can save others some time!

AFAIK there are some hacks in the downstream tree, which also play with the naming.

[nullr0ute]

There's issues with the arm32 support in linus's tree, it doesn't boot and seems to cause issues with other devices for multiplatform support.

The aarch64 support with the upstream kernel boots fine, when used with the firmware DT I get the following errors:

[   15.398547] raspberrypi-firmware soc:firmware: Request 0x00030043 returned status 0x00000000
[   15.407319] raspberrypi-exp-gpio soc:firmware:gpio: Failed to get GPIO 0 config (-22 80)
[   15.512080] sdhci: Secure Digital Host Controller Interface driver
[   15.518377] sdhci: Copyright(c) Pierre Ossman
[   15.530967] raspberrypi-firmware soc:firmware: Request 0x00030043 returned status 0x00000000
[   15.539713] raspberrypi-exp-gpio soc:firmware:gpio: Failed to get GPIO 1 config (-22 81)
[   15.566180] sdhci-pltfm: SDHCI platform and OF driver helper
[   15.670092] raspberrypi-firmware soc:firmware: Request 0x00030043 returned status 0x00000000
[   15.678740] raspberrypi-exp-gpio soc:firmware:gpio: Failed to get GPIO 2 config (-22 82)
[   15.690442] mmc0: SDHCI controller on fe300000.mmcnr [fe300000.mmcnr] using PIO
[   15.700443] raspberrypi-firmware soc:firmware: Request 0x00030043 returned status 0x00000000
[   15.709531] raspberrypi-exp-gpio soc:firmware:gpio: Failed to get GPIO 4 config (-22 84)
[   15.709541] raspberrypi-firmware soc:firmware: Request 0x00030043 returned status 0x00000000
[   15.719630] raspberrypi-firmware soc:firmware: Request 0x00030043 returned status 0x00000000
[   15.726495] raspberrypi-exp-gpio soc:firmware:gpio: Failed to get GPIO 3 config (-22 83)
[   15.735077] raspberrypi-exp-gpio soc:firmware:gpio: Failed to get GPIO 4 config (-22 84)
[   15.751880] gpio-regulator: probe of sd_io_1v8_reg failed with error -22
[   15.774640] mmc0: queuing unknown CIS tuple 0x80 (2 bytes)
[   15.784278] raspberrypi-firmware soc:firmware: Request 0x00030043 returned status 0x00000000
[   15.785559] mmc0: queuing unknown CIS tuple 0x80 (3 bytes)
[   15.793112] raspberrypi-exp-gpio soc:firmware:gpio: Failed to get GPIO 4 config (-22 84)
[   15.800529] raspberrypi-firmware soc:firmware: Request 0x00028001 returned status 0x00000000
[   15.800939] mmc0: queuing unknown CIS tuple 0x80 (3 bytes)
[   15.804548] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
[   15.806562] mmc0: queuing unknown CIS tuple 0x80 (3 bytes)
[   15.820185] raspberrypi-firmware soc:firmware: Request 0x00030043 returned status 0x00000000
[   15.841245] raspberrypi-exp-gpio soc:firmware:gpio: Failed to get GPIO 5 config (-22 85)
[   15.860184] raspberrypi-firmware soc:firmware: Request 0x00030043 returned status 0x00000000
[   15.868907] raspberrypi-exp-gpio soc:firmware:gpio: Failed to get GPIO 6 config (-22 86)
[   15.884842] raspberrypi-firmware soc:firmware: Request 0x00030043 returned status 0x00000000
[   15.893806] raspberrypi-exp-gpio soc:firmware:gpio: Failed to get GPIO 7 config (-22 87)
[   15.917883] raspberrypi-firmware soc:firmware: Request 0x00028001 returned status 0x00000000
[   15.942544] mmc0: new high speed SDIO card at address 0001
[   16.328529] raspberrypi-firmware soc:firmware: Request 0x00028001 returned status 0x00000000
[   16.397516] vc4_hdmi fe902000.hdmi: ignoring dependency for device, assuming no driver
[   16.406567] vc4_vec fe806000.vec: ignoring dependency for device, assuming no driver
[   16.421851] raspberrypi-firmware soc:firmware: Request 0x00028001 returned status 0x00000000
[   16.444425] raspberrypi-firmware soc:firmware: Request 0x00028001 returned status 0x00000000
[   19.690193] systemd-udevd (365) used greatest stack depth: 12064 bytes left
[   19.704707] systemd-udevd (372) used greatest stack depth: 11696 bytes left
[   19.711881] systemd-udevd (379) used greatest stack depth: 11328 bytes left
[   19.722200] systemd-udevd (371) used greatest stack depth: 10912 bytes left

When I get a moment I'll try a dtdiff to see if I can see the difference.

[lategoodbye]

Please don't use this to report new issues. This is mostly to keep track of upstreaming efforts. Use the appropriate mailing lists instead.

Combining upstream kernel and downstream DT is not intended to work. We need proper solutions upstream.

Btw there is a patch to fix the multiplatform issue

[lategoodbye]

V2 of thermal support is out now: https://marc.info/?l=linux-arm-kernel&m=157807229003339&w=2

[vianpl]

@lategoodbye Could you comment on what "58 GPIO support" implies. I can't seem to find anything related.

[lategoodbye]

@vianpl According to this comment the BCM2711 supports 58 instead of 54 GPIOs. So i prepared this untested branch. There is not much benefit behind it, but it's nice to have all the GPIO labels.

[lategoodbye]

Here is the output of gpioinfo (1.4.0) with 58 GPIO and labels:

gpiochip0 - 58 lines:
    line   0:     "ID_SDA"       unused   input  active-high 
    line   1:     "ID_SCL"       unused   input  active-high 
    line   2:       "SDA1"       unused   input  active-high 
    line   3:       "SCL1"       unused   input  active-high 
    line   4:  "GPIO_GCLK"       unused   input  active-high 
    line   5:      "GPIO5"       unused   input  active-high 
    line   6:      "GPIO6"       unused   input  active-high 
    line   7:  "SPI_CE1_N"       unused   input  active-high 
    line   8:  "SPI_CE0_N"       unused   input  active-high 
    line   9:   "SPI_MISO"       unused   input  active-high 
    line  10:   "SPI_MOSI"       unused   input  active-high 
    line  11:   "SPI_SCLK"       unused   input  active-high 
    line  12:     "GPIO12"       unused   input  active-high 
    line  13:     "GPIO13"       unused   input  active-high 
    line  14:       "TXD1"       unused   input  active-high 
    line  15:       "RXD1"       unused   input  active-high 
    line  16:     "GPIO16"       unused   input  active-high 
    line  17:     "GPIO17"       unused   input  active-high 
    line  18:     "GPIO18"       unused   input  active-high 
    line  19:     "GPIO19"       unused   input  active-high 
    line  20:     "GPIO20"       unused   input  active-high 
    line  21:     "GPIO21"       unused   input  active-high 
    line  22:     "GPIO22"       unused   input  active-high 
    line  23:     "GPIO23"       unused   input  active-high 
    line  24:     "GPIO24"       unused   input  active-high 
    line  25:     "GPIO25"       unused   input  active-high 
    line  26:     "GPIO26"       unused   input  active-high 
    line  27:     "GPIO27"       unused   input  active-high 
    line  28: "RGMII_MDIO"       unused   input  active-high 
    line  29:  "RGMIO_MDC"       unused   input  active-high 
    line  30:       "CTS0"       unused   input  active-high 
    line  31:       "RTS0"       unused   input  active-high 
    line  32:       "TXD0"       unused   input  active-high 
    line  33:       "RXD0"       unused   input  active-high 
    line  34:    "SD1_CLK"       unused   input  active-high 
    line  35:    "SD1_CMD"       unused   input  active-high 
    line  36:  "SD1_DATA0"       unused   input  active-high 
    line  37:  "SD1_DATA1"       unused   input  active-high 
    line  38:  "SD1_DATA2"       unused   input  active-high 
    line  39:  "SD1_DATA3"       unused   input  active-high 
    line  40:  "PWM0_MISO"       unused   input  active-high 
    line  41:  "PWM1_MOSI"       unused   input  active-high 
    line  42: "STATUS_LED_G_CLK" "?" output active-high [used]
    line  43: "SPIFLASH_CE_N" unused input active-high 
    line  44:       "SDA0"       unused   input  active-high 
    line  45:       "SCL0"       unused   input  active-high 
    line  46: "RGMII_RXCLK" unused input active-high 
    line  47: "RGMII_RXCTL" unused input active-high 
    line  48: "RGMII_RXD0"       unused   input  active-high 
    line  49: "RGMII_RXD1"       unused   input  active-high 
    line  50: "RGMII_RXD2"       unused   input  active-high 
    line  51: "RGMII_RXD3"       unused   input  active-high 
    line  52: "RGMII_TXCLK" unused input active-high 
    line  53: "RGMII_TXCTL" unused input active-high 
    line  54: "RGMII_TXD0"       unused   input  active-high 
    line  55: "RGMII_TXD1"       unused   input  active-high 
    line  56: "RGMII_TXD2"       unused   input  active-high 
    line  57: "RGMII_TXD3"       unused   input  active-high 

Any objections?

[lategoodbye]

@mripard sends an initial (but huge) series for VC4 on the Raspberry Pi 4: https://lore.kernel.org/patchwork/project/lkml/list/?series=430943

[ikruusa]

Hi! VL805 LPM support seems to be applied for 5.7 already?

[vianpl]

Hi! VL805 LPM support seems to be applied for 5.7 already?

Yes, I updated the table. Thanks!

[aleroot]

Is the audio / sound support already in upstream ? I can't see it in the table

[lategoodbye]

Is the audio / sound support already in upstream ?

Not yet

I can't see it in the table

Added, thanks

[stapelberg]

Is another work item to add the XHCI controller to the Raspberry Pi 4 device tree in the upstream Linux kernel tree?

I can’t find it in the device tree which Linux 5.6 uses, and I’m wondering if that’s the reason for why the xhci_hcd driver does not detect any devices?

Update: adding xhci to the device-tree didn’t do the trick (or maybe I did it wrong). Maybe I’m missing a new kernel option?

[vianpl]

Hi @stapelberg there shouldn't be any device-tree entry for RPi's xHCI chip as it sits behind a PCIe bus who'll discover it automatically. Something might be wrong otherwise.

Would you mind sending your issue to the linux-rpi mailing list (https://lists.infradead.org/mailman/listinfo/linux-rpi-kernel). And please attach your dmesg output. Note that this github issue is just used as an upstream status tracker, and the fastest way to get a response is going trough the mailing list :slightly_smiling_face:.

[stapelberg]

Thanks for clarifying! Indeed, after enabling the following kernel configuration options, USB seems to work (without any device-tree changes):

• CONFIG_PCIE_BRCMSTB
• CONFIG_USB_NET_CDCETHER
• CONFIG_USB_VL600

[lategoodbye]

@vianpl I've added a recent eMMC2 bus fix on the TODO list.

[vianpl]

@lategoodbye My upstream submission doesn't have this problem :slightly_smiling_face: (it's available in linux-next BTW)

[lategoodbye]

Sorry for that noise

[ghost]

Hello, can someone please upload a running (debian/mainline) kernel or a minimal image for rpi4? I have try to build my own without success.

[lnussbaum]

Hello, can someone please upload a running (debian/mainline) kernel or a minimal image for rpi4? I have try to build my own without success.

I'm not sure this is the place for such questions, but have you seen https://lists.debian.org/debian-arm/2020/04/msg00091.html ? If this doesn't work for you, maybe reply on the list, and we can figure out what goes wrong?

[vianpl]

Hello, can someone please upload a running (debian/mainline) kernel or a minimal image for rpi4? I have try to build my own without success.

As an alternative to @lnussbaum suggestion you could try in the linux-rpi-kernel mailing lists: https://lists.infradead.org/mailman/listinfo/linux-rpi-kernel

[lategoodbye]

Hello, can someone please upload a running (debian/mainline) kernel or a minimal image for rpi4? I have try to build my own without success.

Please stop using this topic to report issues. You can open a new issue or even better report it to the mentioned mailing lists.

[dsd]

Thanks to everyone working hard on these efforts! In the table being maintained at the top of this issue, I suggest splitting the entry currently listed as "DRM" into two: "VC4 display" and "V3D GPU". Two separate DRM drivers needed for full graphics support.

VC4 display driver by Maxime Ripard is being reviewed upstream, as you know.

V3D is a separate driver, already upstream at drivers/gpu/drm/v3d. However there is currently no corresponding device node in the RPi4 upstream devicetree, and as usual there's probably a bit of prepatory clock work needed to get it up and running. I believe that task is up for grabs, if anyone is interested.

[nullr0ute]

V3D is a separate driver, already upstream at drivers/gpu/drm/v3d. However there is currently no corresponding device node in the RPi4 upstream devicetree, and as usual there's probably a bit of prepatory clock work needed to get it up and running. I believe that task is up for grabs, if anyone is interested.

A comment from Eric mentioned that for the RPi4 it should be as straightforward as adding appropriate compatibles (and enabling it for the arch): https://lists.freedesktop.org/archives/dri-devel/2020-March/258140.html

[lategoodbye]

Thanks for pointing out, but as long as we are busy with Maxime's VC4 patch series it doesn't make sense to submit such a patch.

[charlesfendt]

I supposed that the new CM4 will need a dedicated TDB, but won't need "big changes"... can someone confirm ? Wenn can we expect a "first bootable vanilla kernel" on CM4 ?