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  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <d9833996-3163-fc82-3d0a-673fd5d1bd80@gmail.com>
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ