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.

lategoodbye commented 5 years ago

High prio TODOs:

Low prio TODOs:

lategoodbye commented 5 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

The changes should boot now.

lategoodbye commented 4 years ago

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

lategoodbye commented 4 years ago

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

lategoodbye commented 4 years ago

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

Changes:

lategoodbye commented 4 years ago

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

Changes:

lategoodbye commented 4 years ago

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

Changes:

lategoodbye commented 4 years ago

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 commented 4 years ago

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

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

lategoodbye commented 4 years ago

@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 commented 4 years ago

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

lategoodbye commented 4 years ago

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

Changes:

TODO:

mbgg commented 4 years ago

@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 commented 4 years ago

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

lategoodbye commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

lategoodbye commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

vianpl commented 4 years ago

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

lategoodbye commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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

vianpl commented 4 years ago

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

Yes, I updated the table. Thanks!

aleroot commented 4 years ago

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

lategoodbye commented 4 years ago

Is the audio / sound support already in upstream ?

Not yet

I can't see it in the table

Added, thanks

stapelberg commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

lategoodbye commented 4 years ago

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

vianpl commented 4 years ago

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

lategoodbye commented 4 years ago

Sorry for that noise

ghost commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 3 years ago

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 ?