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

[Ulf Samuelsson]

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.

    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.
    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