Am 13.09.19 um 10:09 schrieb Matthias Brugger: > > On 12/09/2019 21:32, Stefan Wahren wrote: >> 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. > I'm not sure I understand what you want to say. My goal is to use the upstream > kernel with the device tree blob provided by the FW. The device tree blob you are talking is defined in this repository: https://github.com/raspberrypi/linux So the word FW is misleading to me. > If you talk about the > downstream kernel, I suppose you mean we should change this in the FW DT blob > and in the downstream kernel. That would work for me. > > Did I understand you correctly? Yes So i suggest to add the upstream compatibles into the repo mentioned above. Sorry, but in case you decided as a U-Boot developer to be compatible with a unreviewed DT, we also need to make U-Boot compatible with upstream and downstream DT blobs. > >>> 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 >>
