Patchwork [meta-fsl-arm,v2,3/3] linux-fslc: Refactor to use linux-imx.inc and avoid duplication of code

login
register
mail settings
Submitter Otavio Salvador
Date April 18, 2013, 6:59 p.m.
Message ID <1366311579-29067-3-git-send-email-otavio@ossystems.com.br>
Download mbox | patch
Permalink /patch/48537/
State Accepted
Delegated to: Otavio Salvador
Headers show

Comments

Otavio Salvador - April 18, 2013, 6:59 p.m.
Provides a new linux-fslc.inc file which abstracts the specific
changes for the linux-fslc based kernels. A new variable has been add
to linux-imx.inc to allow to skip the 'imx-test' specific hacks after
kernel install as 'imx-test' is not supported for Linux mainline.

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
Changes in v2:
- Reuse linux-imx.inc
- Add linux-fslc.inc

 recipes-kernel/linux/linux-fslc.inc    | 20 ++++++++++++++++++++
 recipes-kernel/linux/linux-fslc_3.8.bb | 25 +------------------------
 recipes-kernel/linux/linux-imx.inc     | 17 +++++++++++------
 3 files changed, 32 insertions(+), 30 deletions(-)
 create mode 100644 recipes-kernel/linux/linux-fslc.inc
Daiane Angolini - April 18, 2013, 7:51 p.m.
On 04/18/2013 03:59 PM, Otavio Salvador wrote:
> Provides a new linux-fslc.inc file which abstracts the specific
> changes for the linux-fslc based kernels. A new variable has been add
> to linux-imx.inc to allow to skip the 'imx-test' specific hacks after
> kernel install as 'imx-test' is not supported for Linux mainline.
>
> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
> ---
I understand what you did, but it's not yet a common place for both 
kernel recipes.

If it is needed for *any* kernel, poky is wrong in not providing this 
for *any* kernel.

If poky is right, we are setting this in the wrong way.

Daiane
Otavio Salvador - April 18, 2013, 7:58 p.m.
On Thu, Apr 18, 2013 at 4:51 PM, Daiane Angolini
<daiane.angolini@freescale.com> wrote:
> On 04/18/2013 03:59 PM, Otavio Salvador wrote:
>>
>> Provides a new linux-fslc.inc file which abstracts the specific
>> changes for the linux-fslc based kernels. A new variable has been add
>> to linux-imx.inc to allow to skip the 'imx-test' specific hacks after
>> kernel install as 'imx-test' is not supported for Linux mainline.
>>
>> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
>> ---
>
> I understand what you did, but it's not yet a common place for both kernel
> recipes.
>
> If it is needed for *any* kernel, poky is wrong in not providing this for
> *any* kernel.

Usually kernel would do the right thing but not in our case. Some
entry point are even not in the kernel code from FSL branch.

> If poky is right, we are setting this in the wrong way.

Both seems right. Poky is doing the general assumption, we're doing
what we need specific for the support of the kernels.

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
Fabio Estevam - April 18, 2013, 11:46 p.m.
On Thu, Apr 18, 2013 at 4:58 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:

> Usually kernel would do the right thing but not in our case. Some

I don't understand. Why 'usually'? In what sense is our case different?

> entry point are even not in the kernel code from FSL branch.

What does it mean?

>
>> If poky is right, we are setting this in the wrong way.
>
> Both seems right. Poky is doing the general assumption, we're doing
> what we need specific for the support of the kernels.

I agree with Daiane here. I am OK with your patch, but I also see it
as workaround.
Eric BENARD - April 19, 2013, 8:03 a.m.
Le Thu, 18 Apr 2013 20:46:48 -0300,
Fabio Estevam <festevam@gmail.com> a écrit :

> On Thu, Apr 18, 2013 at 4:58 PM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
> 
> > Usually kernel would do the right thing but not in our case. Some
> 
> I don't understand. Why 'usually'? In what sense is our case different?
> 
maybe most defconfig support only one machine when those in
meta-fsl-arm support several machines sometimes with different LOADADDR
requirements and thus need the precision to get a working kernel on a
specific platform at compile time.

Eric
Daiane Angolini - April 19, 2013, 11:23 a.m.
On 04/18/2013 04:58 PM, Otavio Salvador wrote:
> On Thu, Apr 18, 2013 at 4:51 PM, Daiane Angolini
> <daiane.angolini@freescale.com> wrote:
>> On 04/18/2013 03:59 PM, Otavio Salvador wrote:
>>>
>>> Provides a new linux-fslc.inc file which abstracts the specific
>>> changes for the linux-fslc based kernels. A new variable has been add
>>> to linux-imx.inc to allow to skip the 'imx-test' specific hacks after
>>> kernel install as 'imx-test' is not supported for Linux mainline.
>>>
>>> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
>>> ---
>>
>> I understand what you did, but it's not yet a common place for both kernel
>> recipes.
>>
>> If it is needed for *any* kernel, poky is wrong in not providing this for
>> *any* kernel.
>
> Usually kernel would do the right thing but not in our case. Some
> entry point are even not in the kernel code from FSL branch.

I would accept this argument if we only faced this problem with FSL kernel.

But, as we faced exactly the same with kernel mainline, I can't accept that.

If kernel mainline is wrong, we must fix it.

Daiane
Daiane Angolini - April 19, 2013, 11:26 a.m.
On 04/19/2013 05:03 AM, Eric Bénard wrote:
> Le Thu, 18 Apr 2013 20:46:48 -0300,
> Fabio Estevam <festevam@gmail.com> a écrit :
>
>> On Thu, Apr 18, 2013 at 4:58 PM, Otavio Salvador
>> <otavio@ossystems.com.br> wrote:
>>
>>> Usually kernel would do the right thing but not in our case. Some
>>
>> I don't understand. Why 'usually'? In what sense is our case different?
>>
> maybe most defconfig support only one machine when those in
> meta-fsl-arm support several machines sometimes with different LOADADDR
> requirements and thus need the precision to get a working kernel on a
> specific platform at compile time.

I'm OK to accept the meta-fsl-arm workaround for this LOADADDR error. At 
least until we figure out a better way to properly fix that.

Otavio, what do you think about adding KERNEL_EXTRA_ARGS += 
"LOADADDR=${UBOOT_ENTRYPOINT}" in mxc-base.inc and mxs-base.inc instead?


Daiane
Otavio Salvador - April 19, 2013, noon
On Fri, Apr 19, 2013 at 8:23 AM, Daiane Angolini
<daiane.angolini@freescale.com> wrote:
> On 04/18/2013 04:58 PM, Otavio Salvador wrote:
>>
>> On Thu, Apr 18, 2013 at 4:51 PM, Daiane Angolini
>> <daiane.angolini@freescale.com> wrote:
>>>
>>> On 04/18/2013 03:59 PM, Otavio Salvador wrote:
>>>>
>>>>
>>>> Provides a new linux-fslc.inc file which abstracts the specific
>>>> changes for the linux-fslc based kernels. A new variable has been add
>>>> to linux-imx.inc to allow to skip the 'imx-test' specific hacks after
>>>> kernel install as 'imx-test' is not supported for Linux mainline.
>>>>
>>>> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
>>>> ---
>>>
>>>
>>> I understand what you did, but it's not yet a common place for both
>>> kernel
>>> recipes.
>>>
>>> If it is needed for *any* kernel, poky is wrong in not providing this for
>>> *any* kernel.
>>
>>
>> Usually kernel would do the right thing but not in our case. Some
>> entry point are even not in the kernel code from FSL branch.
>
>
> I would accept this argument if we only faced this problem with FSL kernel.
>
> But, as we faced exactly the same with kernel mainline, I can't accept that.
>
> If kernel mainline is wrong, we must fix it.

mainline this is even worse as it is multi SOC vendor so  we do need to pass it.

Eric is right and if you check FSL kernel, it doesn't know the MX6SL
entry point in the makefile, for example.

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
Otavio Salvador - April 19, 2013, 12:01 p.m.
On Fri, Apr 19, 2013 at 8:26 AM, Daiane Angolini
<daiane.angolini@freescale.com> wrote:
> On 04/19/2013 05:03 AM, Eric Bénard wrote:
>>
>> Le Thu, 18 Apr 2013 20:46:48 -0300,
>> Fabio Estevam <festevam@gmail.com> a écrit :
>>
>>> On Thu, Apr 18, 2013 at 4:58 PM, Otavio Salvador
>>> <otavio@ossystems.com.br> wrote:
>>>
>>>> Usually kernel would do the right thing but not in our case. Some
>>>
>>>
>>> I don't understand. Why 'usually'? In what sense is our case different?
>>>
>> maybe most defconfig support only one machine when those in
>> meta-fsl-arm support several machines sometimes with different LOADADDR
>> requirements and thus need the precision to get a working kernel on a
>> specific platform at compile time.
>
>
> I'm OK to accept the meta-fsl-arm workaround for this LOADADDR error. At
> least until we figure out a better way to properly fix that.
>
> Otavio, what do you think about adding KERNEL_EXTRA_ARGS +=
> "LOADADDR=${UBOOT_ENTRYPOINT}" in mxc-base.inc and mxs-base.inc instead?

This is even worse IMO as we'd be changing something without being
clear we're doing. This would just make it harder to understand IMO.

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
Eric BENARD - April 19, 2013, 12:10 p.m.
Hi Daiane,

Le Fri, 19 Apr 2013 08:23:27 -0300,
Daiane Angolini <daiane.angolini@freescale.com> a écrit :

> On 04/18/2013 04:58 PM, Otavio Salvador wrote:
> > On Thu, Apr 18, 2013 at 4:51 PM, Daiane Angolini
> > <daiane.angolini@freescale.com> wrote:
> >> On 04/18/2013 03:59 PM, Otavio Salvador wrote:
> >>>
> >>> Provides a new linux-fslc.inc file which abstracts the specific
> >>> changes for the linux-fslc based kernels. A new variable has been add
> >>> to linux-imx.inc to allow to skip the 'imx-test' specific hacks after
> >>> kernel install as 'imx-test' is not supported for Linux mainline.
> >>>
> >>> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
> >>> ---
> >>
> >> I understand what you did, but it's not yet a common place for both kernel
> >> recipes.
> >>
> >> If it is needed for *any* kernel, poky is wrong in not providing this for
> >> *any* kernel.
> >
> > Usually kernel would do the right thing but not in our case. Some
> > entry point are even not in the kernel code from FSL branch.
> 
> I would accept this argument if we only faced this problem with FSL kernel.
> 
> But, as we faced exactly the same with kernel mainline, I can't accept that.
> 
> If kernel mainline is wrong, we must fix it.
> 
when compiling manually a mainline kernel out of OE, you may have to do
the same thing if the .config includes several platforms which have a
different LOADADDR (example : i.MX51 where RAM is at 0x90000000 and
i.MX53 where it is at 0x70000000). That's not a bug that's the
consequence of having different architectures enabled at the same time
in the same defconfig.

Eric
Fabio Estevam - April 19, 2013, 12:26 p.m.
On Fri, Apr 19, 2013 at 5:03 AM, Eric Bénard <eric@eukrea.com> wrote:

> maybe most defconfig support only one machine when those in
> meta-fsl-arm support several machines sometimes with different LOADADDR
> requirements and thus need the precision to get a working kernel on a
> specific platform at compile time.

Sure, understood. So if we always build uImage as "make uImage
LOADADDR=0xxxxx" then it will always work. No matter if you are in a
single machine defconfig or on a multiple machine defconfig.

What I think it is strange is the need to pass the UBOOT_ENTRYPOINT to
poky and then we need to force "LOADADDR=${UBOOT_ENTRYPOINT}" again in
our layer. Why can't poke just always pass
LOADADDR=${UBOOT_ENTRYPOINT} itself? If UBOOT_ENTRYPOINT is not passed
then it does the usual "make uImage" method.

We could call it OUR_UBOOT_ENTRYPOINT instead and use this
OUR_UBOOT_ENTRYPOINT in our layer, no?

Or maybe in the next release we could just switch to zImage and no
need to worry about such things ;-)
Daiane Angolini - April 19, 2013, 12:34 p.m.
On 04/19/2013 09:10 AM, Eric Bénard wrote:
> Hi Daiane,
>
> Le Fri, 19 Apr 2013 08:23:27 -0300,
> Daiane Angolini <daiane.angolini@freescale.com> a écrit :
>
>> On 04/18/2013 04:58 PM, Otavio Salvador wrote:
>>> On Thu, Apr 18, 2013 at 4:51 PM, Daiane Angolini
>>> <daiane.angolini@freescale.com> wrote:
>>>> On 04/18/2013 03:59 PM, Otavio Salvador wrote:
>>>>>
>>>>> Provides a new linux-fslc.inc file which abstracts the specific
>>>>> changes for the linux-fslc based kernels. A new variable has been add
>>>>> to linux-imx.inc to allow to skip the 'imx-test' specific hacks after
>>>>> kernel install as 'imx-test' is not supported for Linux mainline.
>>>>>
>>>>> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
>>>>> ---
>>>>
>>>> I understand what you did, but it's not yet a common place for both kernel
>>>> recipes.
>>>>
>>>> If it is needed for *any* kernel, poky is wrong in not providing this for
>>>> *any* kernel.
>>>
>>> Usually kernel would do the right thing but not in our case. Some
>>> entry point are even not in the kernel code from FSL branch.
>>
>> I would accept this argument if we only faced this problem with FSL kernel.
>>
>> But, as we faced exactly the same with kernel mainline, I can't accept that.
>>
>> If kernel mainline is wrong, we must fix it.
>>
> when compiling manually a mainline kernel out of OE, you may have to do
> the same thing if the .config includes several platforms which have a
> different LOADADDR (example : i.MX51 where RAM is at 0x90000000 and
> i.MX53 where it is at 0x70000000). That's not a bug that's the
> consequence of having different architectures enabled at the same time
> in the same defconfig.

Which only ensure that FSL kernel is not wrong the same way mainline is 
not wrong.
Eric BENARD - April 19, 2013, 12:36 p.m.
Hi Fabio,

Le Fri, 19 Apr 2013 09:26:30 -0300,
Fabio Estevam <festevam@gmail.com> a écrit :

> On Fri, Apr 19, 2013 at 5:03 AM, Eric Bénard <eric@eukrea.com> wrote:
> 
> > maybe most defconfig support only one machine when those in
> > meta-fsl-arm support several machines sometimes with different LOADADDR
> > requirements and thus need the precision to get a working kernel on a
> > specific platform at compile time.
> 
> Sure, understood. So if we always build uImage as "make uImage
> LOADADDR=0xxxxx" then it will always work. No matter if you are in a
> single machine defconfig or on a multiple machine defconfig.
> 
> What I think it is strange is the need to pass the UBOOT_ENTRYPOINT to
> poky and then we need to force "LOADADDR=${UBOOT_ENTRYPOINT}" again in
> our layer. Why can't poke just always pass
> LOADADDR=${UBOOT_ENTRYPOINT} itself? If UBOOT_ENTRYPOINT is not passed
> then it does the usual "make uImage" method.
> 
because if you look at kernel.bbclass, it's only using
UBOOT_LOADADDRESS ?= "${UBOOT_ENTRYPOINT}"
in 
do_uboot_mkimage() {}
which is executed once the kernel is compiled :
addtask uboot_mkimage before do_install after do_compile

So the uImage is generated once the kernel is compiled (without using
make uImage).

So the LOADADDR need is specific to some platforms and not generic
at the oe-core level.

Eric
Daiane Angolini - April 19, 2013, 12:36 p.m.
On 04/19/2013 09:26 AM, Fabio Estevam wrote:
> On Fri, Apr 19, 2013 at 5:03 AM, Eric Bénard <eric@eukrea.com> wrote:
>
>> maybe most defconfig support only one machine when those in
>> meta-fsl-arm support several machines sometimes with different LOADADDR
>> requirements and thus need the precision to get a working kernel on a
>> specific platform at compile time.
>
> Sure, understood. So if we always build uImage as "make uImage
> LOADADDR=0xxxxx" then it will always work. No matter if you are in a
> single machine defconfig or on a multiple machine defconfig.
>
> What I think it is strange is the need to pass the UBOOT_ENTRYPOINT to
> poky and then we need to force "LOADADDR=${UBOOT_ENTRYPOINT}" again in
> our layer. Why can't poke just always pass
> LOADADDR=${UBOOT_ENTRYPOINT} itself? If UBOOT_ENTRYPOINT is not passed
> then it does the usual "make uImage" method.
>
> We could call it OUR_UBOOT_ENTRYPOINT instead and use this
> OUR_UBOOT_ENTRYPOINT in our layer, no?

Thanks Fabio.

I make your words mine.
Otavio Salvador - April 19, 2013, 12:38 p.m.
On Fri, Apr 19, 2013 at 9:26 AM, Fabio Estevam <festevam@gmail.com> wrote:
> On Fri, Apr 19, 2013 at 5:03 AM, Eric Bénard <eric@eukrea.com> wrote:
>
>> maybe most defconfig support only one machine when those in
>> meta-fsl-arm support several machines sometimes with different LOADADDR
>> requirements and thus need the precision to get a working kernel on a
>> specific platform at compile time.
>
> Sure, understood. So if we always build uImage as "make uImage
> LOADADDR=0xxxxx" then it will always work. No matter if you are in a
> single machine defconfig or on a multiple machine defconfig.
>
> What I think it is strange is the need to pass the UBOOT_ENTRYPOINT to
> poky and then we need to force "LOADADDR=${UBOOT_ENTRYPOINT}" again in
> our layer. Why can't poke just always pass
> LOADADDR=${UBOOT_ENTRYPOINT} itself? If UBOOT_ENTRYPOINT is not passed
> then it does the usual "make uImage" method.

It'd not be need if we had KEEPUIMAGE as 'no' Yocto would generate it
without the workaround but we'd end generation two images.

> We could call it OUR_UBOOT_ENTRYPOINT instead and use this
> OUR_UBOOT_ENTRYPOINT in our layer, no?
>
> Or maybe in the next release we could just switch to zImage and no
> need to worry about such things ;-)

Yes, this would be an option as well ;-)

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
Daiane Angolini - April 19, 2013, 12:38 p.m.
On 04/19/2013 09:36 AM, Eric Bénard wrote:
> Hi Fabio,
>
> Le Fri, 19 Apr 2013 09:26:30 -0300,
> Fabio Estevam <festevam@gmail.com> a écrit :
>
>> On Fri, Apr 19, 2013 at 5:03 AM, Eric Bénard <eric@eukrea.com> wrote:
>>
>>> maybe most defconfig support only one machine when those in
>>> meta-fsl-arm support several machines sometimes with different LOADADDR
>>> requirements and thus need the precision to get a working kernel on a
>>> specific platform at compile time.
>>
>> Sure, understood. So if we always build uImage as "make uImage
>> LOADADDR=0xxxxx" then it will always work. No matter if you are in a
>> single machine defconfig or on a multiple machine defconfig.
>>
>> What I think it is strange is the need to pass the UBOOT_ENTRYPOINT to
>> poky and then we need to force "LOADADDR=${UBOOT_ENTRYPOINT}" again in
>> our layer. Why can't poke just always pass
>> LOADADDR=${UBOOT_ENTRYPOINT} itself? If UBOOT_ENTRYPOINT is not passed
>> then it does the usual "make uImage" method.
>>
> because if you look at kernel.bbclass, it's only using
> UBOOT_LOADADDRESS ?= "${UBOOT_ENTRYPOINT}"
> in
> do_uboot_mkimage() {}
> which is executed once the kernel is compiled :
> addtask uboot_mkimage before do_install after do_compile
>

And, if you follow what happens when our kernel is built, you will see 
that uboot_mkimage is never called


Daiane
Otavio Salvador - April 19, 2013, 12:41 p.m.
On Fri, Apr 19, 2013 at 9:38 AM, Daiane Angolini
<daiane.angolini@freescale.com> wrote:
> On 04/19/2013 09:36 AM, Eric Bénard wrote:
>>
>> Hi Fabio,
>>
>> Le Fri, 19 Apr 2013 09:26:30 -0300,
>> Fabio Estevam <festevam@gmail.com> a écrit :
>>
>>> On Fri, Apr 19, 2013 at 5:03 AM, Eric Bénard <eric@eukrea.com> wrote:
>>>
>>>> maybe most defconfig support only one machine when those in
>>>> meta-fsl-arm support several machines sometimes with different LOADADDR
>>>> requirements and thus need the precision to get a working kernel on a
>>>> specific platform at compile time.
>>>
>>>
>>> Sure, understood. So if we always build uImage as "make uImage
>>> LOADADDR=0xxxxx" then it will always work. No matter if you are in a
>>> single machine defconfig or on a multiple machine defconfig.
>>>
>>> What I think it is strange is the need to pass the UBOOT_ENTRYPOINT to
>>> poky and then we need to force "LOADADDR=${UBOOT_ENTRYPOINT}" again in
>>> our layer. Why can't poke just always pass
>>> LOADADDR=${UBOOT_ENTRYPOINT} itself? If UBOOT_ENTRYPOINT is not passed
>>> then it does the usual "make uImage" method.
>>>
>> because if you look at kernel.bbclass, it's only using
>> UBOOT_LOADADDRESS ?= "${UBOOT_ENTRYPOINT}"
>> in
>> do_uboot_mkimage() {}
>> which is executed once the kernel is compiled :
>> addtask uboot_mkimage before do_install after do_compile
>>
>
> And, if you follow what happens when our kernel is built, you will see that
> uboot_mkimage is never called

As I said, because KEEPUIMAGE is 'yes' so it is supposed to keep the
uImage generated during kernel build.

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
Daiane Angolini - April 19, 2013, 1:25 p.m.
On 04/19/2013 09:41 AM, Otavio Salvador wrote:

> As I said, because KEEPUIMAGE is 'yes' so it is supposed to keep the
> uImage generated during kernel build.


So, I think the conclusion is that the patch was ACKED.


Daiane
Otavio Salvador - April 19, 2013, 1:33 p.m.
On Fri, Apr 19, 2013 at 10:25 AM, Daiane Angolini
<daiane.angolini@freescale.com> wrote:
> On 04/19/2013 09:41 AM, Otavio Salvador wrote:
>
>> As I said, because KEEPUIMAGE is 'yes' so it is supposed to keep the
>> uImage generated during kernel build.
>
>
>
> So, I think the conclusion is that the patch was ACKED.

Applied.

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
Daiane Angolini - April 19, 2013, 1:45 p.m.
On 04/19/2013 10:33 AM, Otavio Salvador wrote:
> On Fri, Apr 19, 2013 at 10:25 AM, Daiane Angolini
> <daiane.angolini@freescale.com> wrote:
>> On 04/19/2013 09:41 AM, Otavio Salvador wrote:
>>
>>> As I said, because KEEPUIMAGE is 'yes' so it is supposed to keep the
>>> uImage generated during kernel build.
>>
>>
>>
>> So, I think the conclusion is that the patch was ACKED.
>
> Applied.

now imx6slevk kernel is loaded. (board is booting now)


Daiane
Otavio Salvador - April 19, 2013, 1:47 p.m.
On Fri, Apr 19, 2013 at 10:45 AM, Daiane Angolini
<daiane.angolini@freescale.com> wrote:
> On 04/19/2013 10:33 AM, Otavio Salvador wrote:
>>
>> On Fri, Apr 19, 2013 at 10:25 AM, Daiane Angolini
>> <daiane.angolini@freescale.com> wrote:
>>>
>>> On 04/19/2013 09:41 AM, Otavio Salvador wrote:
>>>
>>>> As I said, because KEEPUIMAGE is 'yes' so it is supposed to keep the
>>>> uImage generated during kernel build.
>>>
>>>
>>>
>>>
>>> So, I think the conclusion is that the patch was ACKED.
>>
>>
>> Applied.
>
>
> now imx6slevk kernel is loaded. (board is booting now)

Finally! :-D

\m/

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Patch

diff --git a/recipes-kernel/linux/linux-fslc.inc b/recipes-kernel/linux/linux-fslc.inc
new file mode 100644
index 0000000..6ebf833
--- /dev/null
+++ b/recipes-kernel/linux/linux-fslc.inc
@@ -0,0 +1,20 @@ 
+# Copyright (C) 2012-2013 O.S. Systems Software LTDA.
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+DESCRIPTION = "Freescale Community mainline based Linux kernel"
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
+DEPENDS += "lzop-native"
+PROVIDES = "virtual/kernel linux-mainline"
+
+inherit kernel
+
+require recipes-kernel/linux/linux-imx.inc
+require recipes-kernel/linux/linux-dtb.inc
+
+# Avoid imx-test installation hacks
+IMX_TEST_SUPPORT = "n"
+
+SRC_URI = "git://github.com/Freescale/linux-mainline.git \
+           file://defconfig"
+LOCALVERSION = "-fslc"
diff --git a/recipes-kernel/linux/linux-fslc_3.8.bb b/recipes-kernel/linux/linux-fslc_3.8.bb
index 06f6dfb..68fa8e1 100644
--- a/recipes-kernel/linux/linux-fslc_3.8.bb
+++ b/recipes-kernel/linux/linux-fslc_3.8.bb
@@ -1,15 +1,7 @@ 
 # Copyright (C) 2012-2013 O.S. Systems Software LTDA.
 # Released under the MIT license (see COPYING.MIT for the terms)
 
-DESCRIPTION = "Linux mainline kernel"
-LICENSE = "GPLv2"
-LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
-DEPENDS += "lzop-native"
-PROVIDES = "virtual/kernel linux-mainline"
-
-inherit kernel
-
-require recipes-kernel/linux/linux-dtb.inc
+include linux-fslc.inc
 
 PV = "3.8+git${SRCPV}"
 PR = "r5"
@@ -17,19 +9,4 @@  PR = "r5"
 # patches-3.8
 SRCREV = "9674b8d96fca62bc47be48fd857591dcfca874b1"
 
-SRC_URI = "git://github.com/Freescale/linux-mainline.git \
-           \
-           file://defconfig"
-
-S = "${WORKDIR}/git"
-
-do_configure_append () {
-    # Ensure we have a proper GIT hash in kernel version
-    rm ${S}/.scmversion
-}
-
-# We need to pass it as param since kernel might support more then one
-# machine, with different entry points
-EXTRA_OEMAKE += "LOADADDR=${UBOOT_ENTRYPOINT}"
-
 COMPATIBLE_MACHINE = "(mxs|mx3|mx5|mx6)"
diff --git a/recipes-kernel/linux/linux-imx.inc b/recipes-kernel/linux/linux-imx.inc
index 9020f57..6a8eeb8 100644
--- a/recipes-kernel/linux/linux-imx.inc
+++ b/recipes-kernel/linux/linux-imx.inc
@@ -13,6 +13,9 @@  inherit kernel
 LOCALVERSION ?= "+yocto"
 SCMVERSION ?= "y"
 
+# Add imx-test support hacks
+IMX_TEST_SUPPORT ?= "y"
+
 SRC_URI = "git://git.freescale.com/imx/linux-2.6-imx.git \
            file://defconfig \
 "
@@ -51,13 +54,15 @@  do_configure_prepend() {
 
 # install nedded headers for imx-test compilation
 do_install_append() {
-	# bounds.h may be used by a module and is currently missing
-	if [ -d include/generated ]; then
-		cp include/generated/* $kerneldir/include/generated/
-	fi
+	if [ "${IMX_TEST_SUPPORT}" = "y" ]; then
+		# bounds.h may be used by a module and is currently missing
+		if [ -d include/generated ]; then
+			cp include/generated/* $kerneldir/include/generated/
+		fi
 
-	# Host architecture object file
-	rm -f $kerneldir/scripts/kconfig/kxgettext.o
+		# Host architecture object file
+		rm -f $kerneldir/scripts/kconfig/kxgettext.o
+	fi
 }
 
 sysroot_stage_all_append() {