lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 17 Feb 2020 13:44:13 -0800 From: Florian Fainelli <f.fainelli@...il.com> To: Nicolas Saenz Julienne <nsaenzjulienne@...e.de>, Marek Szyprowski <m.szyprowski@...sung.com>, Stefan Wahren <stefan.wahren@...e.com>, linux-rpi-kernel@...ts.infradead.org, linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH] ARM: bcm2835_defconfig: add minimal support for Raspberry Pi4 On 2/17/2020 12:18 PM, Nicolas Saenz Julienne wrote: > [ Adding Florian to the coversation ] > > On Mon, 2020-02-17 at 13:22 +0100, Marek Szyprowski wrote: >> Hi Nicolas, >> On 14.02.2020 16:14, Nicolas Saenz Julienne wrote: >>> IMO bcm2711_defconfig if the last resort solution. I don't think you can >>> do bcm2835_lpae_defconfig as RPi and RPi2 SoCs don't support LPAE. >> >> Okay, if you want I can send a patch adding bcm2711_defconfig. >> >>> An intemediate solution is being discussed here: >>> https://lkml.org/lkml/2020/1/10/694 >> >> Right, I also agree that multi_v7_lpae_defconfig is needed. Best would >> be to have both (bcm2711 for quick tests of board-dedicated kernel and >> multi for distributions). > > So I understand you'd be creating a new bcm2711_defconfig based on > bcm2835_defconfig plus whatever is needed. Sounds OK to me. It'd be nice to > have a small kernel config to do bisects with. > > Any comments Florian, Stefan? If we can make bcm2711_defconfig a fragment that applies to bcm2835_defconfig then we are not maintaining a completely new configuration file and we take advantage of all existing coverage from bcm2835_defconfig. A completely new bcm2711_defconfig would be hard to justify IMHO when multi_v7_lpae_defconfig is sort of what we would prefer. BTW, if you register the PCI outbound window as part of 2711's machine descriptor map_io callback, you should have it trickled down from iotable_init() -> create_mapping() -> __create_mapping() -> create_36bit_mapping which should allow the creation of such a mapping into the 32-bit virtual address space of the kernel. You would not quite be able to use the entire 4GB of DRAM in such a configuration because your virtual address space already needs ~41MB of register space + 64MB of PCIe outbound space but at least bcm2835_defconfig would keep working. NB: this only works AFAICT if you do this at map_io() time, not sure if ioremap() will accept a >= 4GB physical address. -- Florian
Powered by blists - more mailing lists