[Letux-kernel] Integrating proper Pyra support

H. Nikolaus Schaller hns at goldelico.com
Mon Feb 3 08:58:13 CET 2020


Hi Andreas,

> Am 03.02.2020 um 07:13 schrieb Andreas Kemnade <andreas at kemnade.info>:
> 
> On Sun, 2 Feb 2020 13:07:40 +0100
> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
> 
>> Hi,
>> 
>>> Am 01.02.2020 um 21:25 schrieb Nick Elsmore <nicholaselsmore at gmail.com>:
>>> 
>>> Hey all,
>>> 
>>> I'm working to integrate proper Pyra support into the Letux kernel.  I've been doing work in a fork, but am trying to become synchronized with Letux.  This thread is dedicated to stabilizing base Pyra support within Letux, starting with:
>>> - standalone Pyra defconfig  
>> 
>> yes, that is good to have and manage a specific Pyra defconfig.
>> 
>> The letux_defconfig builds a lot of modules which are not needed for the Pyra. And by configuring some stuff into the kernel instead of loading modules, boot time can drastically be reduced.
>> 
> hmm, that pyra_defconfig contains:
> CONFIG_ARCH_BCM
> CONFIG_ARCH_MXC

> 
> so it is something generic.

I think this is by accident and not intended.

Yes, it certainly needs review and updates to become "Pyra only".

Basically we have conflicting goals:
- letux_defconfig is a Distro config (of same processor architecture) which should cover many devices as good as possible but is suboptimal
- pyra_defconfig is a Device config which should be optimal for one specific device and not cover any other
- omap2plus_defconfig is a SoC config which should cover all omap based devices as good as possible but is suboptimal

>  I am still wondering whether is would be more
> maintainable to use
> make savedefconfig
> output and manually edit things and sort like
> 
> # Pyra hw
> 
> CONFIG_ARCH_OMAP5=y
> 
> # GTA04 hw
> 
> CONFIG_ARCH_OMAP3=y
> CONFIG_GNSS_SIRF=m
> 
> # Kobolino
> 
> CONFIG_ARCH_IMX6SLL=y
> ...
> 
> # special requirements of distro X
> ...
> 
> # common stuff
> 
> ...
> 
> I guess things can be duplicated

That is how omap2plus_defconfig is done (more or less).

Well, each approach has its pros and cons.

The savedefconfig has IMHO a problem if CONFIG options are removed/renamed upstream. We never will notice.

Running make savedefconfig after each merge of upstream would remove them as well, but then we loose
the manual editing.

So that is more difficult to automate the update process.

BR,
Nikolaus



More information about the Letux-kernel mailing list