[oe] [PATCH 1/5] Use common files for AT91SAM9 configuration

Mon Oct 25 17:56:51 UTC 2010

On 10/25/10, Ulf Samuelsson <ulf.samuelsson at atmel.com> wrote:
> Khem Raj skrev:
>> On Wed, Oct 20, 2010 at 4:57 PM, Ulf Samuelsson
>> <ulf.samuelsson at atmel.com> wrote:
>>> Khem Raj skrev:
>>>> On Mon, Oct 18, 2010 at 4:10 PM, Ulf Samuelsson
>>>> <ulf.samuelsson at atmel.com> wrote:
>>>>> Khem Raj skrev:
>>>>>> On Mon, Oct 18, 2010 at 10:10 AM, Ulf Samuelsson
>>>>>> <ulf.samuelsson at atmel.com> wrote:
>>>>>>> Koen Kooi skrev:
>>>>>>>> On 18-10-10 15:38, Ulf Samuelsson wrote:
>>>>>>>>> Marcin Juszkiewicz skrev:
>>>>>>>>>> Dnia sobota, 16 pazdziernika 2010 o 14:50:02
>>>>>>>>>> ulf.samuelsson at atmel.com
>>>>>>>>>> napisaB(a):
>>>>>>>>>>
>>>>>>>>>>> +++ b/conf/machine/include/at91-2.6.30.inc
>>>>>>>>>>> +++ b/conf/machine/include/at91-2.6.32.inc
>>>>>>>>>> Do you plan to duplicate that file with each kernel you will
>>>>>>>>>> produce?
>>>>>>>>>> Create include/at91-sam9.inc and put it there.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>> This is to allow different kernel versions for different AT91
>>>>>>>>> chips.
>>>>>>>>> This allows both a "stable" version, and a development kernel
>>>>>>>>> to be easily handled.
>>>>>>>>> The file defines (amongst other things) the
>>>>>>>>> * kernel version,
>>>>>>>>> * u-boot version
>>>>>>>>> * at91bootstrap version
>>>>>>>>> so you need one file per version.he
>>>>>>>> NAK! Machines don't get to decide versions! Please revert that
>>>>>>>> commit
>>>>>>>> and come up with a better way, e.g. default_preference in the
>>>>>>>> recipes
>>>>>>>> or
>>>>>>>> distro include files.
>>>>>>> If I look at the machine files, almost all of them provide
>>>>>>> a preferred kernel / u-boot. Some also provide version.
>>>>>> we should avoid pinning versions there. Choosing a type is fine.
>>>>>>
>>>>> Why ?
>>>>> Is it because it affect rebuild time?
>>>>> It would be good to understand what problems people see with this.
>>>> Well we have distro which sets policies including which recipe
>>>> versions to be pinned
>>>> machine configuration decides on various machine features. There are
>>>> different ways to do it
>>>> but if we remain consistent in what we do, we can make it more
>>>> understandable for others
>>>>
>>>> If you feel strongly that your approach is good I think it should be
>>>> decided if this is suitable
>>>> for majority of OE distro and machines, If it has technical merits
>>>> over existing approaches
>>>> people will be interested in it.
>>>>
>>>>> We are pinning the version to a specific machine, in the kernel recipe.
>>>>> If we add a new recipe, then we can, by increasing the priority
>>>>> force a different kernel to be built.
>>>>> This will not affect anything else.
>>>>>
>>>>> If the version is in the machine configuration, then a change of
>>>>> kernel version could force a total rebuild, or?
>>>>>
>>>> I dont think it will force any rebuild or anything. It will just not
>>>> be the way other machines
>>>> do things. The machine configuration tend to be version agnostic as
>>>> per current approach.
>>>>
>>>>> Any other problem?
>>>>>
>>>> what are the issues that you see in following approaches suggested in
>>>> this thread so far ?
>>> 1) Many boards do put kernel version in the machine conf file.
>>>   The patch was created to collect common stuff in an include file
>>>   to make maintenance easier.
>>>
>>> 2) I cannot assume that all Atmel chips should use the same kernel,
>>>   so a single include file will not make it.
>>>
>>> 3) I want to be able to work with two kernel versions for the same chip.
>>>   This is to have one stable kernel, and one development kernel.
>>>   The use of the develoment kernel, should not make the stable version
>>>   unbuildable.
>>
>> you want to ship with two kernel or you want to work with two kernel
>> versions?
>> if you just want to develop then you can have the stable kernel
>> version as preferred version
>> and override that in local.conf with yout dev kernel for development
>> purposes. Once you are
>> done with it and it is your next stable just add
>> DEFAULT_PREFERENCE_<machine> = "1" in that recipe
>> and it should become new default for this machine.
>>
>
> I would like to ship with two kernels.
> one "stable" kernel, and another "development" kernel
> which is accessible to others to allow shared responsibility
> for testing purposes.
>

you can either use different version of different recipe name
with different name you can just override the virtual/kernel
PREFERRED_PROVIDER_virtual/kernel = "/whatever/"

> Preferably, it should be possible to build both,
> without having to rebuild the complete root fs.
>

yes why not. One just needs to flip the PREFERRED_VERSION
in local.conf file and he should not get the kernel version he chose.
and no rebuild of rfs is needed.

>
>
>>
>> for release you can create your own pinned config file and call it
>> inside distro config you have
>> and have two distros one for dev and one for stable
>>>   If I put the preferred version in the recipe, then I can only work
>>>   with one kernel.
>>>
>>>   If I try to use the preferred version in the recipe, then I
>>>   have to have two machine files.
>>>   I.E:
>>>   at91sam9g45ek
>>>   at91sam9g45ek-devel
>>>
>>>   and I have to support both machines in the recipe.
>>>
>>>   Once I have come to a point, where the development kernel is
>>>   to become the stable version, then I have to edit the recipe
>>>   again to make this the official.
>>>   I have to remove all references to "sam9g45ek",
>>>   then I have to modify the "sam9g45ek-devel" settings to refer to
>>>   "sam9g45ek", remove the sam9g45ek.conf and rename the
>>>   sam9g45ek-devel.conf to sam9g45ek.conf.
>>>
>>>   I then have to retest everything!
>>>
>>>   As I see it, the kernel/u-boot/at91bootstrap hangs together,
>>>   and it is easier to maintain a single include file with versions
>>>   for this, than to maintain the three recipes.
>>>
>>>   If I maintain in the recipes, I have to create a lot
>>>   of preferred_version_<machine>) in multiple kernel recipes,
>>>   and with my method, I include a single file in the machine
>>>   configuration.
>>>   If I want to change kernel version, I edit a few characters.
>>>
>>> 4. This points to another weakness.
>>>   You can only build a certain machine in one way.
>>>
>>>   Today, when we specify a MACHINE, we use "$MACHINE.conf"
>>>
>>>   It would be better, if you could have several machine configuration
>>>   files referring to the same MACHINE, and specifying the MACHINE
>>>   in the configuration file.
>>>
>>>   local.conf would then contain
>>>
>>>   MACHINE_CONFIG = at91sam9g45ek-2.6.30.conf
>>>
>>>   "at91sam9g45ek-2.6.30.conf" would contain
>>>
>>>   MACHINE = at91sam9g45ek
>>>
>>>   This would allow several configuration files referring to the same
>>>   machine.
>>>   The machine configuration must support selecting separate
>>>   * linux ".config"
>>>   * uboot configuration
>>>   * boot monitor configuration.
>>
>> why not use existing MACHINE_FEATURES to steer the features you would
>> like to change in .config files.
>>
>>
>>>   Possibly, then machine configuration should support downloading such
>>>   stuff from internet.
>>>
>>>   (I don't expect the mainline OE to contain more than one "stable"
>>>    version)
>>>
>>>
>
> BR
> Ulf
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

-- 
-Khem