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] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 17 Feb 2020 13:22:22 +0100
From:   Marek Szyprowski <m.szyprowski@...sung.com>
To:     Nicolas Saenz Julienne <nsaenzjulienne@...e.de>,
        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

Hi Nicolas,

On 14.02.2020 16:14, Nicolas Saenz Julienne wrote:
> On Fri Feb 14, 2020 at 1:25 PM, Marek Szyprowski wrote:
>> On 13.02.2020 10:59, Stefan Wahren wrote:
>>> On 13.02.20 08:35, Marek Szyprowski wrote:
>>>> On 12.02.2020 19:31, Nicolas Saenz Julienne wrote:
>>>>> On Wed, 2020-02-12 at 11:20 +0100, Marek Szyprowski wrote:
>>>>>> Add drivers for the minimal set of devices needed to boot Raspberry Pi4
>>>>>> board.
>>>>>>
>>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@...sung.com>
>>>>> Just so you know, the amount of support on the RPi4 you might be able to get
>>>>> updating bcm2835_defconfig's config is very limited. Only 1GB of ram and no
>>>>> PCIe (so no USBs).
>>>> Yes, I know. A lots of core features is missing: SMP, HIGHMEM, LPAE, PCI
>>>> and so on, but having a possibility to boot RPi4 with this defconfig
>>>> increases the test coverage.
>>> in case you want to increase test coverage, we better enable all
>>> Raspberry Pi 4 relevant hardware parts (hwrng, thermal, PCI ...). This
>>> is what we did for older Pi boards.
>> Okay, I will add thermal in v2. HWRNG is already selected as module.
>> Enabling PCI without LPAE makes no sense as the driver won't be able to
>> initialize properly.
> Agree on this.
>>> SMP, HIGHMEM, LPAE are different and shouldn't be enabled in
>>> bcm2835_defconfig from my PoV.
>> Maybe it would make sense to also add bcm2711_defconfig or
>> bcm2835_lpae_defconfig?
> 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).

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ