Am 12.09.19 um 19:18 schrieb Matthias Brugger: > > On 10/09/2019 11:27, Matthias Brugger wrote: >> >> On 09/09/2019 21:33, Stefan Wahren wrote: >>> Hi Nicolas, >>> >>> Am 09.09.19 um 11:58 schrieb Nicolas Saenz Julienne: >>>> Hi all, >>>> this series attempts to address some issues we found while bringing up >>>> the new Raspberry Pi 4 in arm64 and it's intended to serve as a follow >>>> up of these discussions: >>>> v4: https://lkml.org/lkml/2019/9/6/352 >>>> v3: https://lkml.org/lkml/2019/9/2/589 >>>> v2: https://lkml.org/lkml/2019/8/20/767 >>>> v1: https://lkml.org/lkml/2019/7/31/922 >>>> RFC: https://lkml.org/lkml/2019/7/17/476 >>>> >>>> The new Raspberry Pi 4 has up to 4GB of memory but most peripherals can >>>> only address the first GB: their DMA address range is >>>> 0xc0000000-0xfc000000 which is aliased to the first GB of physical >>>> memory 0x00000000-0x3c000000. Note that only some peripherals have these >>>> limitations: the PCIe, V3D, GENET, and 40-bit DMA channels have a wider >>>> view of the address space by virtue of being hooked up trough a second >>>> interconnect. >>>> >>>> Part of this is solved on arm32 by setting up the machine specific >>>> '.dma_zone_size = SZ_1G', which takes care of reserving the coherent >>>> memory area at the right spot. That said no buffer bouncing (needed for >>>> dma streaming) is available at the moment, but that's a story for >>>> another series. >>>> >>>> Unfortunately there is no such thing as 'dma_zone_size' in arm64. Only >>>> ZONE_DMA32 is created which is interpreted by dma-direct and the arm64 >>>> arch code as if all peripherals where be able to address the first 4GB >>>> of memory. >>>> >>>> In the light of this, the series implements the following changes: >>>> >>>> - Create both DMA zones in arm64, ZONE_DMA will contain the first 1G >>>> area and ZONE_DMA32 the rest of the 32 bit addressable memory. So far >>>> the RPi4 is the only arm64 device with such DMA addressing limitations >>>> so this hardcoded solution was deemed preferable. >>>> >>>> - Properly set ARCH_ZONE_DMA_BITS. >>>> >>>> - Reserve the CMA area in a place suitable for all peripherals. >>>> >>>> This series has been tested on multiple devices both by checking the >>>> zones setup matches the expectations and by double-checking physical >>>> addresses on pages allocated on the three relevant areas GFP_DMA, >>>> GFP_DMA32, GFP_KERNEL: >>>> >>>> - On an RPi4 with variations on the ram memory size. But also forcing >>>> the situation where all three memory zones are nonempty by setting a 3G >>>> ZONE_DMA32 ceiling on a 4G setup. Both with and without NUMA support. >>>> >>> i like to test this series on Raspberry Pi 4 and i have some questions >>> to get arm64 running: >>> >>> Do you use U-Boot? Which tree? >> If you want to use U-Boot, try v2019.10-rc4, it should have everything you need >> to boot your kernel. >> > Ok, here is a thing. In the linux kernel we now use bcm2711 as SoC name, but the > RPi4 devicetree provided by the FW uses mostly bcm2838. Do you mean the DTB provided at runtime? You mean the merged U-Boot changes, doesn't work with my Raspberry Pi series? > U-Boot in its default > config uses the devicetree provided by the FW, mostly because this way you don't > have to do anything to find out how many RAM you really have. Secondly because > this will allow us, in the near future, to have one U-boot binary for both RPi3 > and RPi4 (and as a side effect one binary for RPi1 and RPi2). > > Anyway, I found at least, that the following compatibles need to be added: > > "brcm,bcm2838-cprman" > "brcm,bcm2838-gpio" > > Without at least the cprman driver update, you won't see anything. > > "brcm,bcm2838-rng200" is also a candidate. > > I also suppose we will need to add "brcm,bcm2838" to > arch/arm/mach-bcm/bcm2711.c, but I haven't verified this. How about changing this in the downstream kernel? Which is much easier. > > Regards, > Matthias > >> Regards, >> Matthias >> >>> Are there any config.txt tweaks necessary? >>> >>> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel@xxxxxxxxxxxxxxxxxxx >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >> > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
