linux-kernel - Re: [PATCH 2/2] arm64: dts: ti: Add basic support for phyBOARD-Lyra-AM625

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:   Fri, 5 May 2023 15:38:14 +0200
From:   Wadim Egorov <w.egorov@...tec.de>
To:     Tony Lindgren <tony@...mide.com>, Nishanth Menon <nm@...com>
CC:     <linux-kernel@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-hardening@...r.kernel.org>, <upstream@...ts.phytec.de>,
        <vigneshr@...com>, <kristo@...nel.org>, <robh+dt@...nel.org>,
        <krzysztof.kozlowski+dt@...aro.org>, <keescook@...omium.org>,
        <tony.luck@...el.com>, <gpiccoli@...lia.com>
Subject: Re: [PATCH 2/2] arm64: dts: ti: Add basic support for
 phyBOARD-Lyra-AM625

Am 05.05.23 um 11:39 schrieb Tony Lindgren:
> * Nishanth Menon <nm@...com> [230504 14:33]:
>> Just wondering: if the carrier board can easily work with different
>> SoMs.. in which case, we could do overlay to create the som + carrier
>> overlay to create rdk dtb - this might allow the scheme to scale to
>> additional SoMs and carrier combinations.. and the SoM dtb could be
>> sufficient for something like a bootloader.
> It might be best to limit the overlay usage to devices that might see
> dual use on the carrier board.. Not sure if setting up the entire
> carrier board makes sense as an overlay :) Not sure if folks want to
> debug boot issues on a remote server for example if an overlay is
> needed to boot with Ethernet :)

Our idea is to create overlays for SoM variants, e.g. an overlay for a SoM 
without SPI NOR flash populated.
If we want to reuse a carrier board, we could factor out the carrier board dts 
into a dtsi file and provide the needed combinations in form of different dts files.

In the bootloader world the situation is a bit different.
Here we would like to have a universal phycore_am62x "board" that should be able 
to handle most carrier board designs using that SoM. And since u-boot is moving 
towards having a single source of device trees, this concept will probably no 
longer work anymore. So your idea with a SoM dtb sounds interesting.
I wonder what ideas other SoM vendors have or how it is handled on other 
architectures.

Regards,
Wadim

>
> Regards,
>
> Tony