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

[Ulf Samuelsson]

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.

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?

Any other problem?

BR
Ulf Samuelsson



>> The patch will move the definition from the machine file to the include
>> file for a few board, so reverting the patch will not solve the problem,
>> just spread it out into multiple files.
>> The patch also adds some boards.
> 
> it pins a kernel version thats not ok IMO. You should pin this in the
> kernel recipes
> instead for the machines that should use it using PREFERRED_VERSIONS
> 
>> Having default preference in recipes is not going to make it easy to
>> switch between version so I don't like that method at all.
>>
> 
> what do you mean by easy here ? Its not difficult to change two
> priority numbers. I think we should try to remain inline with our
> policies
> whatever they are otherwise it will create confusion.
> 
>> Using the distro to select boot and kernel, seems flawed since none of
>> the stuff will reside in the file system (my file system)
>> but at least this is easily maintainable.
>>
> 
> usually in OE distros set policy with sufficient knowledge of machine
> characteristics
> you can think of ways to use this approach. distro does not decide on
> which kernel or u-boot
> these are machine specific recipes and you decide which one to feed
> for which machine in the recipe.
> 
>> The best right now seems to be to make a new distro file for each kernel
>> version, which just includes Angstrom and adds version info for kernel,
>> u-boot and at91bootstrap.
>>
>> Long term, I think that there should be something equivalent to DISTRO
>> for the files outside the file system, and that you should be able to
>> select between multiple variants like you select a DISTRO today,
>> but I am not yet into bitbake, so I can't tell where to start.
>>
>> Since the reversal of the patch, wont solve anything,
>> I suggest we agree on how to proceed, and then do the fixes.
>> Is including Angstrom from a kernel specific distro file OK?
> 
> 
> 
>> If a distro file is to include another file, then
>> you have to be able to tell different kernels for
>>
>>
>> I guess we could do:
>>
>> require   conf/distro/include/$(SOC_FAMILY).inc
>>
>> conf/distro/include/at91.inc would contain:
>>
>>
>> PREFERRED_VERSION_at91bootstrap = "2.13"
>> PREFERRED_VERSION_u-boot = "2009.11"
> 
> why is all this needed ?
> 
>> Not sure how to do machine dependent kernel version
>>
>> PREFERRED_VERSION_linux_at91sam9g45ek = "2.6.30"
>> does not feel like it would work.
>> Ideas?
>>
>>