Porting of specific Kernel/Driver into yocto.

Porting of specific Kernel/Driver into yocto.

[Om Prakash PAL]

Hi,
I want to build my local kernel/Driver code, not the default one. 
please help how can i do it ?.
any wiki/docs on this?.

Best Regards,
Om Prakash Pal

Re: Porting of specific Kernel/Driver into yocto.

[Bruce Ashfield]

On 12-04-04 04:46 AM, Om Prakash PAL wrote:
> Hi,
> I want to build my local kernel/Driver code, not the default one.
> please help how can i do it ?.
> any wiki/docs on this?.

The BSP developer guides show how to extend the yocto kernels, and
also have sections on custom/different kernel versions. Have you
seen that doc yet ? Or have you seen it, and have specific questions ?

Bruce

>
> Best Regards,
> Om Prakash Pal
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: Porting of specific Kernel/Driver into yocto.

[Om Prakash PAL]

Hi Bruce,
Thanks for your reply.
I am totally new to Yocto.
I have gone through the section BSP/Linux kernel configuration and if I am not wrong then it explains how can we configure the kernel, not the how we can add/replace a  component(driver etc). 
lets take the example of UART driver, I want to add my own UART driver code.
Should I write a separate recipe file (.bb) for UART Driver?.
if yes then I have to write the recipe files for all my drivers that will be very time consuming. 
Is there any other way that I can port all my desired drivers into Yocto kernel?.
Please help me.
Thanks a lot in advance. 

Best Regards,
Om Prakash Pal  
________________________________________
From: Bruce Ashfield [bruce.ashfield@windriver.com]
Sent: Wednesday, April 04, 2012 6:17 PM
To: Om Prakash PAL
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.

On 12-04-04 04:46 AM, Om Prakash PAL wrote:
> Hi,
> I want to build my local kernel/Driver code, not the default one.
> please help how can i do it ?.
> any wiki/docs on this?.

The BSP developer guides show how to extend the yocto kernels, and
also have sections on custom/different kernel versions. Have you
seen that doc yet ? Or have you seen it, and have specific questions ?

Bruce

>
> Best Regards,
> Om Prakash Pal
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: Porting of specific Kernel/Driver into yocto.

[Bruce Ashfield]

On 12-04-08 10:04 AM, Om Prakash PAL wrote:
> Hi Bruce,
> Thanks for your reply.
> I am totally new to Yocto.
> I have gone through the section BSP/Linux kernel configuration and if I am not wrong then it explains how can we configure the kernel, not the how we can add/replace a  component(driver etc).
> lets take the example of UART driver, I want to add my own UART driver code.
> Should I write a separate recipe file (.bb) for UART Driver?.
> if yes then I have to write the recipe files for all my drivers that will be very time consuming.
> Is there any other way that I can port all my desired drivers into Yocto kernel?.

No recipes are required per-driver, unless you are building them all
as out of tree modules.

The typical way this is done is to simply work in the extracted linux
src tree (build/tmp/work/<your board>/linux-yocto-<hashes>/linux), manually
patch, or copy your drivers into the tree. At this point, you'll port
the drivers, doing test builds (bitbake -f -c compile linux-yocto) to
ensure that your port is working. When you've completed the build phase,
boot tests would be in order. (Do not do a 'clean' or you'll lose in
progress changes).

When you are happy with the changes, the directory where you were working
is with the kernel git repository. So you can simply commit your 
changes, and generate patches.

    git format-patch -o <your directory> HEAD^ (or however many commits
you have)

Take those patches, create a layer with a bbappend and add them like
any other patch to any package. They'll be applied to subsequent builds
of the kernel.

I'm skipping a lot of detail there, but it is all found in the various
manuals, and I don't want to repeat it here.

Cheers,

Bruce

> Please help me.
> Thanks a lot in advance.
>
> Best Regards,
> Om Prakash Pal
> ________________________________________
> From: Bruce Ashfield [bruce.ashfield@windriver.com]
> Sent: Wednesday, April 04, 2012 6:17 PM
> To: Om Prakash PAL
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>
> On 12-04-04 04:46 AM, Om Prakash PAL wrote:
>> Hi,
>> I want to build my local kernel/Driver code, not the default one.
>> please help how can i do it ?.
>> any wiki/docs on this?.
>
> The BSP developer guides show how to extend the yocto kernels, and
> also have sections on custom/different kernel versions. Have you
> seen that doc yet ? Or have you seen it, and have specific questions ?
>
> Bruce
>
>>
>> Best Regards,
>> Om Prakash Pal
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>

Re: Porting of specific Kernel/Driver into yocto.

[Om Prakash PAL]

Hi Bruce,
Thanks for you help.
As you have mentioned, its working properly.
I want to know that is there any better way of doing same thing for my scenario ?:
here is my scenario:
We have development branch where we write/modify our kernel/driver code i.e. thats our local kernel repository(git rep)
and lots of driver/files being modified everyday-->so I have to take the same effect into yocto kernel also----> so except  creating patches for all modified drivers and creating .bbappend files, is there any better way of doing same thing .  

Is there anyway that  instead of using yocto-kernel tree,  can we use our local kernel-tree for building images?. (should  I create separate BSP ?)

Thanks in advance.
Best Regards,
Om Prakash Pal
________________________________________
From: Bruce Ashfield [bruce.ashfield@windriver.com]
Sent: Monday, April 09, 2012 9:32 AM
To: Om Prakash PAL
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.

On 12-04-08 10:04 AM, Om Prakash PAL wrote:
> Hi Bruce,
> Thanks for your reply.
> I am totally new to Yocto.
> I have gone through the section BSP/Linux kernel configuration and if I am not wrong then it explains how can we configure the kernel, not the how we can add/replace a  component(driver etc).
> lets take the example of UART driver, I want to add my own UART driver code.
> Should I write a separate recipe file (.bb) for UART Driver?.
> if yes then I have to write the recipe files for all my drivers that will be very time consuming.
> Is there any other way that I can port all my desired drivers into Yocto kernel?.

No recipes are required per-driver, unless you are building them all
as out of tree modules.

The typical way this is done is to simply work in the extracted linux
src tree (build/tmp/work/<your board>/linux-yocto-<hashes>/linux), manually
patch, or copy your drivers into the tree. At this point, you'll port
the drivers, doing test builds (bitbake -f -c compile linux-yocto) to
ensure that your port is working. When you've completed the build phase,
boot tests would be in order. (Do not do a 'clean' or you'll lose in
progress changes).

When you are happy with the changes, the directory where you were working
is with the kernel git repository. So you can simply commit your
changes, and generate patches.

    git format-patch -o <your directory> HEAD^ (or however many commits
you have)

Take those patches, create a layer with a bbappend and add them like
any other patch to any package. They'll be applied to subsequent builds
of the kernel.

I'm skipping a lot of detail there, but it is all found in the various
manuals, and I don't want to repeat it here.

Cheers,

Bruce

> Please help me.
> Thanks a lot in advance.
>
> Best Regards,
> Om Prakash Pal
> ________________________________________
> From: Bruce Ashfield [bruce.ashfield@windriver.com]
> Sent: Wednesday, April 04, 2012 6:17 PM
> To: Om Prakash PAL
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>
> On 12-04-04 04:46 AM, Om Prakash PAL wrote:
>> Hi,
>> I want to build my local kernel/Driver code, not the default one.
>> please help how can i do it ?.
>> any wiki/docs on this?.
>
> The BSP developer guides show how to extend the yocto kernels, and
> also have sections on custom/different kernel versions. Have you
> seen that doc yet ? Or have you seen it, and have specific questions ?
>
> Bruce
>
>>
>> Best Regards,
>> Om Prakash Pal
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>

Re: Porting of specific Kernel/Driver into yocto.

[Bruce Ashfield]

On Mon, Apr 9, 2012 at 12:31 PM, Om Prakash PAL
<omprakash.pal@stericsson.com> wrote:
> Hi Bruce,
> Thanks for you help.
> As you have mentioned, its working properly.
> I want to know that is there any better way of doing same thing for my scenario ?:
> here is my scenario:
> We have development branch where we write/modify our kernel/driver code i.e. thats our local kernel repository(git rep)
> and lots of driver/files being modified everyday-->so I have to take the same effect into yocto kernel also----> so except  creating patches for all modified drivers and creating .bbappend files, is there any better way of doing same thing .

Aha. Missed that.

Just create a simple recipe that points at your git repository in the SRC_URI.
If all the changes are in the tree, and you have a defconfig and you
are building
the master branch. Then pretty much everything you need can be specified in
the SRC_URI .. and that's the entire recipe.

If you look in oe-classic, meta-ti or any one of a number of other
layers, you'll
find recipes that do just that.

The meta-kernel-dev (in the poky extras) layer has an example of using the
kernel.org tree with the yocto kern tools, and once yocto 1.3 opens up for
submissions, I have a set of changes prep'd that make it relatively simple to
use the yocto kern tools against different types of repository.

So the summary is: Depending on the type of tooling you need, and what baseline
you need for your work .. there are a number of ways to do things.

>
> Is there anyway that  instead of using yocto-kernel tree,  can we use our local kernel-tree for building images?. (should  I create separate BSP ?)

You should definitely create a BSP, that way you can tune the system specific
to your board,

Cheers,

Bruce

>
> Thanks in advance.
> Best Regards,
> Om Prakash Pal
> ________________________________________
> From: Bruce Ashfield [bruce.ashfield@windriver.com]
> Sent: Monday, April 09, 2012 9:32 AM
> To: Om Prakash PAL
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>
> On 12-04-08 10:04 AM, Om Prakash PAL wrote:
>> Hi Bruce,
>> Thanks for your reply.
>> I am totally new to Yocto.
>> I have gone through the section BSP/Linux kernel configuration and if I am not wrong then it explains how can we configure the kernel, not the how we can add/replace a  component(driver etc).
>> lets take the example of UART driver, I want to add my own UART driver code.
>> Should I write a separate recipe file (.bb) for UART Driver?.
>> if yes then I have to write the recipe files for all my drivers that will be very time consuming.
>> Is there any other way that I can port all my desired drivers into Yocto kernel?.
>
> No recipes are required per-driver, unless you are building them all
> as out of tree modules.
>
> The typical way this is done is to simply work in the extracted linux
> src tree (build/tmp/work/<your board>/linux-yocto-<hashes>/linux), manually
> patch, or copy your drivers into the tree. At this point, you'll port
> the drivers, doing test builds (bitbake -f -c compile linux-yocto) to
> ensure that your port is working. When you've completed the build phase,
> boot tests would be in order. (Do not do a 'clean' or you'll lose in
> progress changes).
>
> When you are happy with the changes, the directory where you were working
> is with the kernel git repository. So you can simply commit your
> changes, and generate patches.
>
>    git format-patch -o <your directory> HEAD^ (or however many commits
> you have)
>
> Take those patches, create a layer with a bbappend and add them like
> any other patch to any package. They'll be applied to subsequent builds
> of the kernel.
>
> I'm skipping a lot of detail there, but it is all found in the various
> manuals, and I don't want to repeat it here.
>
> Cheers,
>
> Bruce
>
>> Please help me.
>> Thanks a lot in advance.
>>
>> Best Regards,
>> Om Prakash Pal
>> ________________________________________
>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>> Sent: Wednesday, April 04, 2012 6:17 PM
>> To: Om Prakash PAL
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> On 12-04-04 04:46 AM, Om Prakash PAL wrote:
>>> Hi,
>>> I want to build my local kernel/Driver code, not the default one.
>>> please help how can i do it ?.
>>> any wiki/docs on this?.
>>
>> The BSP developer guides show how to extend the yocto kernels, and
>> also have sections on custom/different kernel versions. Have you
>> seen that doc yet ? Or have you seen it, and have specific questions ?
>>
>> Bruce
>>
>>>
>>> Best Regards,
>>> Om Prakash Pal
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: Porting of specific Kernel/Driver into yocto.

[Om Prakash PAL]

-----Original Message-----
From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com] 
Sent: Monday, April 09, 2012 11:04 PM
To: Om Prakash PAL
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.

On Mon, Apr 9, 2012 at 12:31 PM, Om Prakash PAL
<omprakash.pal@stericsson.com> wrote:
> Hi Bruce,
> Thanks for you help.
> As you have mentioned, its working properly.
> I want to know that is there any better way of doing same thing for my scenario ?:
> here is my scenario:
> We have development branch where we write/modify our kernel/driver code i.e. thats our local kernel repository(git rep)
> and lots of driver/files being modified everyday-->so I have to take the same effect into yocto kernel also----> so except  creating patches for all modified drivers and creating .bbappend files, is there any better way of doing same thing .

Aha. Missed that.

Just create a simple recipe that points at your git repository in the SRC_URI.
If all the changes are in the tree, and you have a defconfig and you
are building
the master branch. Then pretty much everything you need can be specified in
the SRC_URI .. and that's the entire recipe.


	@Bruce, I want to add kernel dir path into SRC_URI, how can we add it ? i.e. lets imagine that my kernel is located in dir /local/kernel/*
	How we can add this kernel into SRC_URI?.(imagine that we don't have git:// and http: path, we have just dir where my kernel is located)


If you look in oe-classic, meta-ti or any one of a number of other
layers, you'll
find recipes that do just that.

The meta-kernel-dev (in the poky extras) layer has an example of using the
kernel.org tree with the yocto kern tools, and once yocto 1.3 opens up for
submissions, I have a set of changes prep'd that make it relatively simple to
use the yocto kern tools against different types of repository.

So the summary is: Depending on the type of tooling you need, and what baseline
you need for your work .. there are a number of ways to do things.

>
> Is there anyway that  instead of using yocto-kernel tree,  can we use our local kernel-tree for building images?. (should  I create separate BSP ?)

You should definitely create a BSP, that way you can tune the system specific
to your board,
	we want to create BSP for our board that is based on arm-cortex-A9 but we don't have meta/conf/machine/include/tune-armcortexa9.inc file.
	How can we create it?. 
Cheers,

Bruce

>
> Thanks in advance.
> Best Regards,
> Om Prakash Pal
> ________________________________________
> From: Bruce Ashfield [bruce.ashfield@windriver.com]
> Sent: Monday, April 09, 2012 9:32 AM
> To: Om Prakash PAL
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>
> On 12-04-08 10:04 AM, Om Prakash PAL wrote:
>> Hi Bruce,
>> Thanks for your reply.
>> I am totally new to Yocto.
>> I have gone through the section BSP/Linux kernel configuration and if I am not wrong then it explains how can we configure the kernel, not the how we can add/replace a  component(driver etc).
>> lets take the example of UART driver, I want to add my own UART driver code.
>> Should I write a separate recipe file (.bb) for UART Driver?.
>> if yes then I have to write the recipe files for all my drivers that will be very time consuming.
>> Is there any other way that I can port all my desired drivers into Yocto kernel?.
>
> No recipes are required per-driver, unless you are building them all
> as out of tree modules.
>
> The typical way this is done is to simply work in the extracted linux
> src tree (build/tmp/work/<your board>/linux-yocto-<hashes>/linux), manually
> patch, or copy your drivers into the tree. At this point, you'll port
> the drivers, doing test builds (bitbake -f -c compile linux-yocto) to
> ensure that your port is working. When you've completed the build phase,
> boot tests would be in order. (Do not do a 'clean' or you'll lose in
> progress changes).
>
> When you are happy with the changes, the directory where you were working
> is with the kernel git repository. So you can simply commit your
> changes, and generate patches.
>
>    git format-patch -o <your directory> HEAD^ (or however many commits
> you have)
>
> Take those patches, create a layer with a bbappend and add them like
> any other patch to any package. They'll be applied to subsequent builds
> of the kernel.
>
> I'm skipping a lot of detail there, but it is all found in the various
> manuals, and I don't want to repeat it here.
>
> Cheers,
>
> Bruce
>
>> Please help me.
>> Thanks a lot in advance.
>>
>> Best Regards,
>> Om Prakash Pal
>> ________________________________________
>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>> Sent: Wednesday, April 04, 2012 6:17 PM
>> To: Om Prakash PAL
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> On 12-04-04 04:46 AM, Om Prakash PAL wrote:
>>> Hi,
>>> I want to build my local kernel/Driver code, not the default one.
>>> please help how can i do it ?.
>>> any wiki/docs on this?.
>>
>> The BSP developer guides show how to extend the yocto kernels, and
>> also have sections on custom/different kernel versions. Have you
>> seen that doc yet ? Or have you seen it, and have specific questions ?
>>
>> Bruce
>>
>>>
>>> Best Regards,
>>> Om Prakash Pal
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: Porting of specific Kernel/Driver into yocto.

[Om Prakash PAL]

Hi Bruce,
	I need some more info

[1].I want to add kernel dir path into SRC_URI(in meta-<bsp_name>/recipe-kernel/linux/linux_3.0.bb), how can we add it ? i.e. lets imagine that my kernel is located in dir /local/kernel/*
How we can add this kernel into SRC_URI?.(imagine that we don't have git:// and http: path, we have just dir where my kernel is located)

[2] we want to create BSP for our board that is based on arm-cortex-A9 but we don't have meta/conf/machine/include/tune-armcortexa9.inc file in current yocto.
How can we create it?.

Thanks,

Best Regards,
Om Prakash Pal

-----Original Message-----
From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com] 
Sent: Monday, April 09, 2012 11:04 PM
To: Om Prakash PAL
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.

On Mon, Apr 9, 2012 at 12:31 PM, Om Prakash PAL
<omprakash.pal@stericsson.com> wrote:
> Hi Bruce,
> Thanks for you help.
> As you have mentioned, its working properly.
> I want to know that is there any better way of doing same thing for my scenario ?:
> here is my scenario:
> We have development branch where we write/modify our kernel/driver code i.e. thats our local kernel repository(git rep)
> and lots of driver/files being modified everyday-->so I have to take the same effect into yocto kernel also----> so except  creating patches for all modified drivers and creating .bbappend files, is there any better way of doing same thing .

Aha. Missed that.

Just create a simple recipe that points at your git repository in the SRC_URI.
If all the changes are in the tree, and you have a defconfig and you
are building
the master branch. Then pretty much everything you need can be specified in
the SRC_URI .. and that's the entire recipe.

If you look in oe-classic, meta-ti or any one of a number of other
layers, you'll
find recipes that do just that.

The meta-kernel-dev (in the poky extras) layer has an example of using the
kernel.org tree with the yocto kern tools, and once yocto 1.3 opens up for
submissions, I have a set of changes prep'd that make it relatively simple to
use the yocto kern tools against different types of repository.

So the summary is: Depending on the type of tooling you need, and what baseline
you need for your work .. there are a number of ways to do things.

>
> Is there anyway that  instead of using yocto-kernel tree,  can we use our local kernel-tree for building images?. (should  I create separate BSP ?)

You should definitely create a BSP, that way you can tune the system specific
to your board,

Cheers,

Bruce

>
> Thanks in advance.
> Best Regards,
> Om Prakash Pal
> ________________________________________
> From: Bruce Ashfield [bruce.ashfield@windriver.com]
> Sent: Monday, April 09, 2012 9:32 AM
> To: Om Prakash PAL
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>
> On 12-04-08 10:04 AM, Om Prakash PAL wrote:
>> Hi Bruce,
>> Thanks for your reply.
>> I am totally new to Yocto.
>> I have gone through the section BSP/Linux kernel configuration and if I am not wrong then it explains how can we configure the kernel, not the how we can add/replace a  component(driver etc).
>> lets take the example of UART driver, I want to add my own UART driver code.
>> Should I write a separate recipe file (.bb) for UART Driver?.
>> if yes then I have to write the recipe files for all my drivers that will be very time consuming.
>> Is there any other way that I can port all my desired drivers into Yocto kernel?.
>
> No recipes are required per-driver, unless you are building them all
> as out of tree modules.
>
> The typical way this is done is to simply work in the extracted linux
> src tree (build/tmp/work/<your board>/linux-yocto-<hashes>/linux), manually
> patch, or copy your drivers into the tree. At this point, you'll port
> the drivers, doing test builds (bitbake -f -c compile linux-yocto) to
> ensure that your port is working. When you've completed the build phase,
> boot tests would be in order. (Do not do a 'clean' or you'll lose in
> progress changes).
>
> When you are happy with the changes, the directory where you were working
> is with the kernel git repository. So you can simply commit your
> changes, and generate patches.
>
>    git format-patch -o <your directory> HEAD^ (or however many commits
> you have)
>
> Take those patches, create a layer with a bbappend and add them like
> any other patch to any package. They'll be applied to subsequent builds
> of the kernel.
>
> I'm skipping a lot of detail there, but it is all found in the various
> manuals, and I don't want to repeat it here.
>
> Cheers,
>
> Bruce
>
>> Please help me.
>> Thanks a lot in advance.
>>
>> Best Regards,
>> Om Prakash Pal
>> ________________________________________
>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>> Sent: Wednesday, April 04, 2012 6:17 PM
>> To: Om Prakash PAL
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> On 12-04-04 04:46 AM, Om Prakash PAL wrote:
>>> Hi,
>>> I want to build my local kernel/Driver code, not the default one.
>>> please help how can i do it ?.
>>> any wiki/docs on this?.
>>
>> The BSP developer guides show how to extend the yocto kernels, and
>> also have sections on custom/different kernel versions. Have you
>> seen that doc yet ? Or have you seen it, and have specific questions ?
>>
>> Bruce
>>
>>>
>>> Best Regards,
>>> Om Prakash Pal
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: Porting of specific Kernel/Driver into yocto.

[Bruce Ashfield]

On 12-04-11 11:24 AM, Om Prakash PAL wrote:
>
>
> -----Original Message-----
> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
> Sent: Monday, April 09, 2012 11:04 PM
> To: Om Prakash PAL
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>
> On Mon, Apr 9, 2012 at 12:31 PM, Om Prakash PAL
> <omprakash.pal@stericsson.com>  wrote:
>> Hi Bruce,
>> Thanks for you help.
>> As you have mentioned, its working properly.
>> I want to know that is there any better way of doing same thing for my scenario ?:
>> here is my scenario:
>> We have development branch where we write/modify our kernel/driver code i.e. thats our local kernel repository(git rep)
>> and lots of driver/files being modified everyday-->so I have to take the same effect into yocto kernel also---->  so except  creating patches for all modified drivers and creating .bbappend files, is there any better way of doing same thing .
>
> Aha. Missed that.
>
> Just create a simple recipe that points at your git repository in the SRC_URI.
> If all the changes are in the tree, and you have a defconfig and you
> are building
> the master branch. Then pretty much everything you need can be specified in
> the SRC_URI .. and that's the entire recipe.
>
>
> 	@Bruce, I want to add kernel dir path into SRC_URI, how can we add it ? i.e. lets imagine that my kernel is located in dir /local/kernel/*
> 	How we can add this kernel into SRC_URI?.(imagine that we don't have git:// and http: path, we have just dir where my kernel is located)
>
>
> If you look in oe-classic, meta-ti or any one of a number of other
> layers, you'll
> find recipes that do just that.
>
> The meta-kernel-dev (in the poky extras) layer has an example of using the
> kernel.org tree with the yocto kern tools, and once yocto 1.3 opens up for
> submissions, I have a set of changes prep'd that make it relatively simple to
> use the yocto kern tools against different types of repository.
>
> So the summary is: Depending on the type of tooling you need, and what baseline
> you need for your work .. there are a number of ways to do things.
>
>>
>> Is there anyway that  instead of using yocto-kernel tree,  can we use our local kernel-tree for building images?. (should  I create separate BSP ?)
>
> You should definitely create a BSP, that way you can tune the system specific
> to your board,
> 	we want to create BSP for our board that is based on arm-cortex-A9 but we don't have meta/conf/machine/include/tune-armcortexa9.inc file.
> 	How can we create it?.

What branch are you working from ? The yocto master branch
has such a tune file. You can check out that branch and attempt
to cherry pick the support if you dont't have it:

i.e.: meta/conf/machine/include/tune-cortexa9.inc

Bruce

> Cheers,
>
> Bruce
>
>>
>> Thanks in advance.
>> Best Regards,
>> Om Prakash Pal
>> ________________________________________
>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>> Sent: Monday, April 09, 2012 9:32 AM
>> To: Om Prakash PAL
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> On 12-04-08 10:04 AM, Om Prakash PAL wrote:
>>> Hi Bruce,
>>> Thanks for your reply.
>>> I am totally new to Yocto.
>>> I have gone through the section BSP/Linux kernel configuration and if I am not wrong then it explains how can we configure the kernel, not the how we can add/replace a  component(driver etc).
>>> lets take the example of UART driver, I want to add my own UART driver code.
>>> Should I write a separate recipe file (.bb) for UART Driver?.
>>> if yes then I have to write the recipe files for all my drivers that will be very time consuming.
>>> Is there any other way that I can port all my desired drivers into Yocto kernel?.
>>
>> No recipes are required per-driver, unless you are building them all
>> as out of tree modules.
>>
>> The typical way this is done is to simply work in the extracted linux
>> src tree (build/tmp/work/<your board>/linux-yocto-<hashes>/linux), manually
>> patch, or copy your drivers into the tree. At this point, you'll port
>> the drivers, doing test builds (bitbake -f -c compile linux-yocto) to
>> ensure that your port is working. When you've completed the build phase,
>> boot tests would be in order. (Do not do a 'clean' or you'll lose in
>> progress changes).
>>
>> When you are happy with the changes, the directory where you were working
>> is with the kernel git repository. So you can simply commit your
>> changes, and generate patches.
>>
>>     git format-patch -o<your directory>  HEAD^ (or however many commits
>> you have)
>>
>> Take those patches, create a layer with a bbappend and add them like
>> any other patch to any package. They'll be applied to subsequent builds
>> of the kernel.
>>
>> I'm skipping a lot of detail there, but it is all found in the various
>> manuals, and I don't want to repeat it here.
>>
>> Cheers,
>>
>> Bruce
>>
>>> Please help me.
>>> Thanks a lot in advance.
>>>
>>> Best Regards,
>>> Om Prakash Pal
>>> ________________________________________
>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>> Sent: Wednesday, April 04, 2012 6:17 PM
>>> To: Om Prakash PAL
>>> Cc: yocto@yoctoproject.org
>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>
>>> On 12-04-04 04:46 AM, Om Prakash PAL wrote:
>>>> Hi,
>>>> I want to build my local kernel/Driver code, not the default one.
>>>> please help how can i do it ?.
>>>> any wiki/docs on this?.
>>>
>>> The BSP developer guides show how to extend the yocto kernels, and
>>> also have sections on custom/different kernel versions. Have you
>>> seen that doc yet ? Or have you seen it, and have specific questions ?
>>>
>>> Bruce
>>>
>>>>
>>>> Best Regards,
>>>> Om Prakash Pal
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>
>

Re: Porting of specific Kernel/Driver into yocto.

[Bruce Ashfield]

On 12-04-11 11:34 AM, Om Prakash PAL wrote:
> Hi Bruce,
> 	I need some more info
>
> [1].I want to add kernel dir path into SRC_URI(in meta-<bsp_name>/recipe-kernel/linux/linux_3.0.bb), how can we add it ? i.e. lets imagine that my kernel is located in dir /local/kernel/*
> How we can add this kernel into SRC_URI?.(imagine that we don't have git:// and http: path, we have just dir where my kernel is located)

I do it this way in meta-kernel-dev:

http://git.yoctoproject.org/cgit/cgit.cgi/poky-extras/plain/meta-kernel-dev/recipes-kernel/linux/linux-yocto-dev.bbappend

In particular the protocol=file should be noticed.

>
> [2] we want to create BSP for our board that is based on arm-cortex-A9 but we don't have meta/conf/machine/include/tune-armcortexa9.inc file in current yocto.
> How can we create it?.

Answered this one previously.

Cheers,

Bruce

>
> Thanks,
>
> Best Regards,
> Om Prakash Pal
>
> -----Original Message-----
> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
> Sent: Monday, April 09, 2012 11:04 PM
> To: Om Prakash PAL
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>
> On Mon, Apr 9, 2012 at 12:31 PM, Om Prakash PAL
> <omprakash.pal@stericsson.com>  wrote:
>> Hi Bruce,
>> Thanks for you help.
>> As you have mentioned, its working properly.
>> I want to know that is there any better way of doing same thing for my scenario ?:
>> here is my scenario:
>> We have development branch where we write/modify our kernel/driver code i.e. thats our local kernel repository(git rep)
>> and lots of driver/files being modified everyday-->so I have to take the same effect into yocto kernel also---->  so except  creating patches for all modified drivers and creating .bbappend files, is there any better way of doing same thing .
>
> Aha. Missed that.
>
> Just create a simple recipe that points at your git repository in the SRC_URI.
> If all the changes are in the tree, and you have a defconfig and you
> are building
> the master branch. Then pretty much everything you need can be specified in
> the SRC_URI .. and that's the entire recipe.
>
> If you look in oe-classic, meta-ti or any one of a number of other
> layers, you'll
> find recipes that do just that.
>
> The meta-kernel-dev (in the poky extras) layer has an example of using the
> kernel.org tree with the yocto kern tools, and once yocto 1.3 opens up for
> submissions, I have a set of changes prep'd that make it relatively simple to
> use the yocto kern tools against different types of repository.
>
> So the summary is: Depending on the type of tooling you need, and what baseline
> you need for your work .. there are a number of ways to do things.
>
>>
>> Is there anyway that  instead of using yocto-kernel tree,  can we use our local kernel-tree for building images?. (should  I create separate BSP ?)
>
> You should definitely create a BSP, that way you can tune the system specific
> to your board,
>
> Cheers,
>
> Bruce
>
>>
>> Thanks in advance.
>> Best Regards,
>> Om Prakash Pal
>> ________________________________________
>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>> Sent: Monday, April 09, 2012 9:32 AM
>> To: Om Prakash PAL
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> On 12-04-08 10:04 AM, Om Prakash PAL wrote:
>>> Hi Bruce,
>>> Thanks for your reply.
>>> I am totally new to Yocto.
>>> I have gone through the section BSP/Linux kernel configuration and if I am not wrong then it explains how can we configure the kernel, not the how we can add/replace a  component(driver etc).
>>> lets take the example of UART driver, I want to add my own UART driver code.
>>> Should I write a separate recipe file (.bb) for UART Driver?.
>>> if yes then I have to write the recipe files for all my drivers that will be very time consuming.
>>> Is there any other way that I can port all my desired drivers into Yocto kernel?.
>>
>> No recipes are required per-driver, unless you are building them all
>> as out of tree modules.
>>
>> The typical way this is done is to simply work in the extracted linux
>> src tree (build/tmp/work/<your board>/linux-yocto-<hashes>/linux), manually
>> patch, or copy your drivers into the tree. At this point, you'll port
>> the drivers, doing test builds (bitbake -f -c compile linux-yocto) to
>> ensure that your port is working. When you've completed the build phase,
>> boot tests would be in order. (Do not do a 'clean' or you'll lose in
>> progress changes).
>>
>> When you are happy with the changes, the directory where you were working
>> is with the kernel git repository. So you can simply commit your
>> changes, and generate patches.
>>
>>     git format-patch -o<your directory>  HEAD^ (or however many commits
>> you have)
>>
>> Take those patches, create a layer with a bbappend and add them like
>> any other patch to any package. They'll be applied to subsequent builds
>> of the kernel.
>>
>> I'm skipping a lot of detail there, but it is all found in the various
>> manuals, and I don't want to repeat it here.
>>
>> Cheers,
>>
>> Bruce
>>
>>> Please help me.
>>> Thanks a lot in advance.
>>>
>>> Best Regards,
>>> Om Prakash Pal
>>> ________________________________________
>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>> Sent: Wednesday, April 04, 2012 6:17 PM
>>> To: Om Prakash PAL
>>> Cc: yocto@yoctoproject.org
>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>
>>> On 12-04-04 04:46 AM, Om Prakash PAL wrote:
>>>> Hi,
>>>> I want to build my local kernel/Driver code, not the default one.
>>>> please help how can i do it ?.
>>>> any wiki/docs on this?.
>>>
>>> The BSP developer guides show how to extend the yocto kernels, and
>>> also have sections on custom/different kernel versions. Have you
>>> seen that doc yet ? Or have you seen it, and have specific questions ?
>>>
>>> Bruce
>>>
>>>>
>>>> Best Regards,
>>>> Om Prakash Pal
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>
>

Re: Porting of specific Kernel/Driver into yocto.

[Om Prakash PAL]

Hi Bruce,
for porting of our local kernel,we have created an BSP layer and to change the the kernel,  we have created an linux-yocto_3.0.bbappend file inside meta<BSP>/recipes-kernel/linux/
like this:-

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

COMPATIBLE_MACHINE_<BSP_name> = "BSP_name"

# KMACHINE is the branch to build
KMACHINE_<BSP_name> = "local_branch"

SRCREV_machine_pn_linux-yocto_<BSP_name> ?= "XXXXXXXX" (here we have assign top commit ID of our local kernel)


# KSRC_linux_yocto to point to your local clone as appropriate.
KSRC_linux_yocto ?= "/path/to/local/kernel"

SRC_URI = "git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH};name=machine \
                file://defconfig"


KERNEL_REVISION_CHECKING=""
SRCREV="${AUTOREV}"
#BB_LOCALCOUNT_OVERRIDE = "1"
LOCALCOUNT = "0"


while building we are getting following Error:

NOTE: Executing RunQueue Tasks
NOTE: Running task 1341 of 1710 (ID: 513, /home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_validate_branches)
NOTE: package linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2: task do_validate_branches: Started
ERROR: Function 'do_validate_branches' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/temp/log.do_validate_branches.16792 for further information)


please tell me what we have done wrong?.
is there anything else we need to modify in .bbappend file or some other variable?.

Best Regards,
Om Prakash Pal
________________________________________
From: Bruce Ashfield [bruce.ashfield@gmail.com]
Sent: Monday, April 09, 2012 11:04 PM
To: Om Prakash PAL
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.

On Mon, Apr 9, 2012 at 12:31 PM, Om Prakash PAL
<omprakash.pal@stericsson.com> wrote:
> Hi Bruce,
> Thanks for you help.
> As you have mentioned, its working properly.
> I want to know that is there any better way of doing same thing for my scenario ?:
> here is my scenario:
> We have development branch where we write/modify our kernel/driver code i.e. thats our local kernel repository(git rep)
> and lots of driver/files being modified everyday-->so I have to take the same effect into yocto kernel also----> so except  creating patches for all modified drivers and creating .bbappend files, is there any better way of doing same thing .

Aha. Missed that.

Just create a simple recipe that points at your git repository in the SRC_URI.
If all the changes are in the tree, and you have a defconfig and you
are building
the master branch. Then pretty much everything you need can be specified in
the SRC_URI .. and that's the entire recipe.

If you look in oe-classic, meta-ti or any one of a number of other
layers, you'll
find recipes that do just that.

The meta-kernel-dev (in the poky extras) layer has an example of using the
kernel.org tree with the yocto kern tools, and once yocto 1.3 opens up for
submissions, I have a set of changes prep'd that make it relatively simple to
use the yocto kern tools against different types of repository.

So the summary is: Depending on the type of tooling you need, and what baseline
you need for your work .. there are a number of ways to do things.

>
> Is there anyway that  instead of using yocto-kernel tree,  can we use our local kernel-tree for building images?. (should  I create separate BSP ?)

You should definitely create a BSP, that way you can tune the system specific
to your board,

Cheers,

Bruce

>
> Thanks in advance.
> Best Regards,
> Om Prakash Pal
> ________________________________________
> From: Bruce Ashfield [bruce.ashfield@windriver.com]
> Sent: Monday, April 09, 2012 9:32 AM
> To: Om Prakash PAL
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>
> On 12-04-08 10:04 AM, Om Prakash PAL wrote:
>> Hi Bruce,
>> Thanks for your reply.
>> I am totally new to Yocto.
>> I have gone through the section BSP/Linux kernel configuration and if I am not wrong then it explains how can we configure the kernel, not the how we can add/replace a  component(driver etc).
>> lets take the example of UART driver, I want to add my own UART driver code.
>> Should I write a separate recipe file (.bb) for UART Driver?.
>> if yes then I have to write the recipe files for all my drivers that will be very time consuming.
>> Is there any other way that I can port all my desired drivers into Yocto kernel?.
>
> No recipes are required per-driver, unless you are building them all
> as out of tree modules.
>
> The typical way this is done is to simply work in the extracted linux
> src tree (build/tmp/work/<your board>/linux-yocto-<hashes>/linux), manually
> patch, or copy your drivers into the tree. At this point, you'll port
> the drivers, doing test builds (bitbake -f -c compile linux-yocto) to
> ensure that your port is working. When you've completed the build phase,
> boot tests would be in order. (Do not do a 'clean' or you'll lose in
> progress changes).
>
> When you are happy with the changes, the directory where you were working
> is with the kernel git repository. So you can simply commit your
> changes, and generate patches.
>
>    git format-patch -o <your directory> HEAD^ (or however many commits
> you have)
>
> Take those patches, create a layer with a bbappend and add them like
> any other patch to any package. They'll be applied to subsequent builds
> of the kernel.
>
> I'm skipping a lot of detail there, but it is all found in the various
> manuals, and I don't want to repeat it here.
>
> Cheers,
>
> Bruce
>
>> Please help me.
>> Thanks a lot in advance.
>>
>> Best Regards,
>> Om Prakash Pal
>> ________________________________________
>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>> Sent: Wednesday, April 04, 2012 6:17 PM
>> To: Om Prakash PAL
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> On 12-04-04 04:46 AM, Om Prakash PAL wrote:
>>> Hi,
>>> I want to build my local kernel/Driver code, not the default one.
>>> please help how can i do it ?.
>>> any wiki/docs on this?.
>>
>> The BSP developer guides show how to extend the yocto kernels, and
>> also have sections on custom/different kernel versions. Have you
>> seen that doc yet ? Or have you seen it, and have specific questions ?
>>
>> Bruce
>>
>>>
>>> Best Regards,
>>> Om Prakash Pal
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: Porting of specific Kernel/Driver into yocto.

[Khem Raj]

On Sun, Apr 29, 2012 at 2:58 AM, Om Prakash PAL
<omprakash.pal@stericsson.com> wrote:
> Hi Bruce,
> for porting of our local kernel,we have created an BSP layer and to change the the kernel,  we have created an linux-yocto_3.0.bbappend file inside meta<BSP>/recipes-kernel/linux/
> like this:-
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>
> COMPATIBLE_MACHINE_<BSP_name> = "BSP_name"
>
> # KMACHINE is the branch to build
> KMACHINE_<BSP_name> = "local_branch"
>
> SRCREV_machine_pn_linux-yocto_<BSP_name> ?= "XXXXXXXX" (here we have assign top commit ID of our local kernel)

that should be SRCREV_machine_pn-linux-yocto_<BSP_name>

Re: Porting of specific Kernel/Driver into yocto.

[Bruce Ashfield]

On 12-04-29 5:58 AM, Om Prakash PAL wrote:
> Hi Bruce,
> for porting of our local kernel,we have created an BSP layer and to change the the kernel,  we have created an linux-yocto_3.0.bbappend file inside meta<BSP>/recipes-kernel/linux/
> like this:-
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>
> COMPATIBLE_MACHINE_<BSP_name>  = "BSP_name"
>
> # KMACHINE is the branch to build
> KMACHINE_<BSP_name>  = "local_branch"
>
> SRCREV_machine_pn_linux-yocto_<BSP_name>  ?= "XXXXXXXX" (here we have assign top commit ID of our local kernel)
>
>
> # KSRC_linux_yocto to point to your local clone as appropriate.
> KSRC_linux_yocto ?= "/path/to/local/kernel"
>
> SRC_URI = "git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH};name=machine \
>                  file://defconfig"
>
>
> KERNEL_REVISION_CHECKING=""
> SRCREV="${AUTOREV}"
> #BB_LOCALCOUNT_OVERRIDE = "1"
> LOCALCOUNT = "0"
>
>
> while building we are getting following Error:
>
> NOTE: Executing RunQueue Tasks
> NOTE: Running task 1341 of 1710 (ID: 513, /home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_validate_branches)
> NOTE: package linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2: task do_validate_branches: Started
> ERROR: Function 'do_validate_branches' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/temp/log.do_validate_branches.16792 for further information)
>
>
> please tell me what we have done wrong?.
> is there anything else we need to modify in .bbappend file or some other variable?.

Which release are you using again ?

The diagnostics out of validate branches are about to get better in master,
but they are coupled with some other tools changes that couldn't go
into yocto 1.2.

Is there anything extra in the log file, or just what you saw on the
build log ?

Validate branches fails like this when you've provided a bad branch or
SRCREV (vs a SRCREV that is simply not the tip of the branch .. it fixes
that scenario) and the fetcher or another git command aborts.

You've output some example text from the bbappend, but what were the real
values in your situation ? i.e. what are KMACHINE/KBRANCH set to ?

There are some flags you can set to exit the branch validation early, but
I don't think setting them is the right course of action yet, since the
error you are seeing is likely hiding some other mis configuration.

Cheers,

Bruce


>
> Best Regards,
> Om Prakash Pal
> ________________________________________
> From: Bruce Ashfield [bruce.ashfield@gmail.com]
> Sent: Monday, April 09, 2012 11:04 PM
> To: Om Prakash PAL
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>
> On Mon, Apr 9, 2012 at 12:31 PM, Om Prakash PAL
> <omprakash.pal@stericsson.com>  wrote:
>> Hi Bruce,
>> Thanks for you help.
>> As you have mentioned, its working properly.
>> I want to know that is there any better way of doing same thing for my scenario ?:
>> here is my scenario:
>> We have development branch where we write/modify our kernel/driver code i.e. thats our local kernel repository(git rep)
>> and lots of driver/files being modified everyday-->so I have to take the same effect into yocto kernel also---->  so except  creating patches for all modified drivers and creating .bbappend files, is there any better way of doing same thing .
>
> Aha. Missed that.
>
> Just create a simple recipe that points at your git repository in the SRC_URI.
> If all the changes are in the tree, and you have a defconfig and you
> are building
> the master branch. Then pretty much everything you need can be specified in
> the SRC_URI .. and that's the entire recipe.
>
> If you look in oe-classic, meta-ti or any one of a number of other
> layers, you'll
> find recipes that do just that.
>
> The meta-kernel-dev (in the poky extras) layer has an example of using the
> kernel.org tree with the yocto kern tools, and once yocto 1.3 opens up for
> submissions, I have a set of changes prep'd that make it relatively simple to
> use the yocto kern tools against different types of repository.
>
> So the summary is: Depending on the type of tooling you need, and what baseline
> you need for your work .. there are a number of ways to do things.
>
>>
>> Is there anyway that  instead of using yocto-kernel tree,  can we use our local kernel-tree for building images?. (should  I create separate BSP ?)
>
> You should definitely create a BSP, that way you can tune the system specific
> to your board,
>
> Cheers,
>
> Bruce
>
>>
>> Thanks in advance.
>> Best Regards,
>> Om Prakash Pal
>> ________________________________________
>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>> Sent: Monday, April 09, 2012 9:32 AM
>> To: Om Prakash PAL
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> On 12-04-08 10:04 AM, Om Prakash PAL wrote:
>>> Hi Bruce,
>>> Thanks for your reply.
>>> I am totally new to Yocto.
>>> I have gone through the section BSP/Linux kernel configuration and if I am not wrong then it explains how can we configure the kernel, not the how we can add/replace a  component(driver etc).
>>> lets take the example of UART driver, I want to add my own UART driver code.
>>> Should I write a separate recipe file (.bb) for UART Driver?.
>>> if yes then I have to write the recipe files for all my drivers that will be very time consuming.
>>> Is there any other way that I can port all my desired drivers into Yocto kernel?.
>>
>> No recipes are required per-driver, unless you are building them all
>> as out of tree modules.
>>
>> The typical way this is done is to simply work in the extracted linux
>> src tree (build/tmp/work/<your board>/linux-yocto-<hashes>/linux), manually
>> patch, or copy your drivers into the tree. At this point, you'll port
>> the drivers, doing test builds (bitbake -f -c compile linux-yocto) to
>> ensure that your port is working. When you've completed the build phase,
>> boot tests would be in order. (Do not do a 'clean' or you'll lose in
>> progress changes).
>>
>> When you are happy with the changes, the directory where you were working
>> is with the kernel git repository. So you can simply commit your
>> changes, and generate patches.
>>
>>     git format-patch -o<your directory>  HEAD^ (or however many commits
>> you have)
>>
>> Take those patches, create a layer with a bbappend and add them like
>> any other patch to any package. They'll be applied to subsequent builds
>> of the kernel.
>>
>> I'm skipping a lot of detail there, but it is all found in the various
>> manuals, and I don't want to repeat it here.
>>
>> Cheers,
>>
>> Bruce
>>
>>> Please help me.
>>> Thanks a lot in advance.
>>>
>>> Best Regards,
>>> Om Prakash Pal
>>> ________________________________________
>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>> Sent: Wednesday, April 04, 2012 6:17 PM
>>> To: Om Prakash PAL
>>> Cc: yocto@yoctoproject.org
>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>
>>> On 12-04-04 04:46 AM, Om Prakash PAL wrote:
>>>> Hi,
>>>> I want to build my local kernel/Driver code, not the default one.
>>>> please help how can i do it ?.
>>>> any wiki/docs on this?.
>>>
>>> The BSP developer guides show how to extend the yocto kernels, and
>>> also have sections on custom/different kernel versions. Have you
>>> seen that doc yet ? Or have you seen it, and have specific questions ?
>>>
>>> Bruce
>>>
>>>>
>>>> Best Regards,
>>>> Om Prakash Pal
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end"
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: Porting of specific Kernel/Driver into yocto.

[Om Prakash PAL]

________________________________________
From: Khem Raj [raj.khem@gmail.com]
Sent: Monday, April 30, 2012 12:18 AM
To: Om Prakash PAL
Cc: Bruce Ashfield; yocto@yoctoproject.org
Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.

On Sun, Apr 29, 2012 at 2:58 AM, Om Prakash PAL
<omprakash.pal@stericsson.com> wrote:
> Hi Bruce,
> for porting of our local kernel,we have created an BSP layer and to change the the kernel,  we have created an linux-yocto_3.0.bbappend file inside meta<BSP>/recipes-kernel/linux/
> like this:-
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>
> COMPATIBLE_MACHINE_<BSP_name> = "BSP_name"
>
> # KMACHINE is the branch to build
> KMACHINE_<BSP_name> = "local_branch"
>
> SRCREV_machine_pn_linux-yocto_<BSP_name> ?= "XXXXXXXX" (here we have assign top commit ID of our local kernel)

that should be SRCREV_machine_pn-linux-yocto_<BSP_name>

yes I have done same and same Error is coming again then set 
YOCTO_KERNEL_EXTERNAL_BRANCH ="local_branch"; in conf/local.conf file and now its working bu now problem is something different:

ERROR: Function 'do_patch' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.20524 for further information)
ERROR: Logfile of failure stored in: /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.20524
Log data follows:
| ERROR. meta data not found, check upstream repo for tags and branches
| ERROR: Function 'do_patch' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.20524 for further information)
NOTE: package linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3: task do_patch: Failed
ERROR: Task 516 (/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_patch) failed with exit code '1'

Best Regards,
Om Prakash Pal

Re: Porting of specific Kernel/Driver into yocto.

[Om Prakash PAL]

>On 12-04-29 5:58 AM, Om Prakash PAL wrote:

   > Hi Bruce,
    >for porting of our local kernel,we have created an BSP layer and to change the the 
    >kernel,  we have created an linux-yocto_3.0.bbappend file inside 
    >meta<BSP>/recipes-kernel/linux/
    >like this:-

    >FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

   > COMPATIBLE_MACHINE_<BSP_name>  = "BSP_name"

    ># KMACHINE is the branch to build
    >KMACHINE_<BSP_name>  = "local_branch"

   > SRCREV_machine_pn_linux-yocto_<BSP_name>  ?= "XXXXXXXX" (here we have assign 
    >top commit ID of our local kernel)


    ># KSRC_linux_yocto to point to your local clone as appropriate.
    >KSRC_linux_yocto ?= "/path/to/local/kernel"

    >SRC_URI = 
    >"git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH};name=machine
     >\
       >              file://defconfig"


    >KERNEL_REVISION_CHECKING=""
    >SRCREV="${AUTOREV}"
    >#BB_LOCALCOUNT_OVERRIDE = "1"
    >LOCALCOUNT = "0"


    >while building we are getting following Error:

    >NOTE: Executing RunQueue Tasks
    >NOTE: Running task 1341 of 1710 (ID: 513, 
    >/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb,
     >do_validate_branches)
    >NOTE: package 
    >linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2: task 
    >do_validate_branches: Started
    >ERROR: Function 'do_validate_branches' failed (see 
    >/home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/temp/log.do_validate_branches.16792
     >for further information)


    >please tell me what we have done wrong?.
    >is there anything else we need to modify in .bbappend file or some other 
    >variable?.

>Which release are you using again ?
  I am using 6.0.0 Edision

>The diagnostics out of validate branches are about to get better in master,
>but they are coupled with some other tools changes that couldn't go
>into yocto 1.2.

>Is there anything extra in the log file, or just what you saw on the
>build log ?.
actually I have set YOCTO_KERNEL_EXTERNAL_BRANCH ="dev";(dev is my local brach)
Now this Error has gone and now I am getting 

ERROR: Function 'do_patch' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008 for further information)
ERROR: Logfile of failure stored in: /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008
Log data follows:
| ERROR. meta data not found, check upstream repo for tags and branches
| ERROR: Function 'do_patch' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008 for further information)
NOTE: package linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3: task do_patch: Failed
ERROR: Task 516 (/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_patch) failed with exit code '1'
ERROR: '/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb' failed


>Validate branches fails like this when you've provided a bad branch or
>SRCREV (vs a SRCREV that is simply not the tip of the branch .. it fixes
>hat scenario) and the fetcher or another git command aborts.

>You've output some example text from the bbappend, but what were the real
>values in your situation ? i.e. what are KMACHINE/KBRANCH set to ?.

I have not set the value of KBRANCH?. what it should be ?.

>There are some flags you can set to exit the branch validation early, but
>I don't think setting them is the right course of action yet, since the
>error you are seeing is likely hiding some other mis configuration.

>Cheers,

>Bruce

Best Regards,
Om Prakash Pal
________________________________________
From: Om Prakash PAL
Sent: Sunday, April 29, 2012 3:28 PM
To: Bruce Ashfield
Cc: yocto@yoctoproject.org
Subject: RE: [yocto] Porting of specific Kernel/Driver into yocto.

Hi Bruce,
for porting of our local kernel,we have created an BSP layer and to change the the kernel,  we have created an linux-yocto_3.0.bbappend file inside meta<BSP>/recipes-kernel/linux/
like this:-

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

COMPATIBLE_MACHINE_<BSP_name> = "BSP_name"

# KMACHINE is the branch to build
KMACHINE_<BSP_name> = "local_branch"

SRCREV_machine_pn_linux-yocto_<BSP_name> ?= "XXXXXXXX" (here we have assign top commit ID of our local kernel)


# KSRC_linux_yocto to point to your local clone as appropriate.
KSRC_linux_yocto ?= "/path/to/local/kernel"

SRC_URI = "git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH};name=machine \
                file://defconfig"


KERNEL_REVISION_CHECKING=""
SRCREV="${AUTOREV}"
#BB_LOCALCOUNT_OVERRIDE = "1"
LOCALCOUNT = "0"


while building we are getting following Error:

NOTE: Executing RunQueue Tasks
NOTE: Running task 1341 of 1710 (ID: 513, /home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_validate_branches)
NOTE: package linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2: task do_validate_branches: Started
ERROR: Function 'do_validate_branches' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/temp/log.do_validate_branches.16792 for further information)


please tell me what we have done wrong?.
is there anything else we need to modify in .bbappend file or some other variable?.

Best Regards,
Om Prakash Pal
________________________________________
From: Bruce Ashfield [bruce.ashfield@gmail.com]
Sent: Monday, April 09, 2012 11:04 PM
To: Om Prakash PAL
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.

On Mon, Apr 9, 2012 at 12:31 PM, Om Prakash PAL
<omprakash.pal@stericsson.com> wrote:
> Hi Bruce,
> Thanks for you help.
> As you have mentioned, its working properly.
> I want to know that is there any better way of doing same thing for my scenario ?:
> here is my scenario:
> We have development branch where we write/modify our kernel/driver code i.e. thats our local kernel repository(git rep)
> and lots of driver/files being modified everyday-->so I have to take the same effect into yocto kernel also----> so except  creating patches for all modified drivers and creating .bbappend files, is there any better way of doing same thing .

Aha. Missed that.

Just create a simple recipe that points at your git repository in the SRC_URI.
If all the changes are in the tree, and you have a defconfig and you
are building
the master branch. Then pretty much everything you need can be specified in
the SRC_URI .. and that's the entire recipe.

If you look in oe-classic, meta-ti or any one of a number of other
layers, you'll
find recipes that do just that.

The meta-kernel-dev (in the poky extras) layer has an example of using the
kernel.org tree with the yocto kern tools, and once yocto 1.3 opens up for
submissions, I have a set of changes prep'd that make it relatively simple to
use the yocto kern tools against different types of repository.

So the summary is: Depending on the type of tooling you need, and what baseline
you need for your work .. there are a number of ways to do things.

>
> Is there anyway that  instead of using yocto-kernel tree,  can we use our local kernel-tree for building images?. (should  I create separate BSP ?)

You should definitely create a BSP, that way you can tune the system specific
to your board,

Cheers,

Bruce

>
> Thanks in advance.
> Best Regards,
> Om Prakash Pal
> ________________________________________
> From: Bruce Ashfield [bruce.ashfield@windriver.com]
> Sent: Monday, April 09, 2012 9:32 AM
> To: Om Prakash PAL
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>
> On 12-04-08 10:04 AM, Om Prakash PAL wrote:
>> Hi Bruce,
>> Thanks for your reply.
>> I am totally new to Yocto.
>> I have gone through the section BSP/Linux kernel configuration and if I am not wrong then it explains how can we configure the kernel, not the how we can add/replace a  component(driver etc).
>> lets take the example of UART driver, I want to add my own UART driver code.
>> Should I write a separate recipe file (.bb) for UART Driver?.
>> if yes then I have to write the recipe files for all my drivers that will be very time consuming.
>> Is there any other way that I can port all my desired drivers into Yocto kernel?.
>
> No recipes are required per-driver, unless you are building them all
> as out of tree modules.
>
> The typical way this is done is to simply work in the extracted linux
> src tree (build/tmp/work/<your board>/linux-yocto-<hashes>/linux), manually
> patch, or copy your drivers into the tree. At this point, you'll port
> the drivers, doing test builds (bitbake -f -c compile linux-yocto) to
> ensure that your port is working. When you've completed the build phase,
> boot tests would be in order. (Do not do a 'clean' or you'll lose in
> progress changes).
>
> When you are happy with the changes, the directory where you were working
> is with the kernel git repository. So you can simply commit your
> changes, and generate patches.
>
>    git format-patch -o <your directory> HEAD^ (or however many commits
> you have)
>
> Take those patches, create a layer with a bbappend and add them like
> any other patch to any package. They'll be applied to subsequent builds
> of the kernel.
>
> I'm skipping a lot of detail there, but it is all found in the various
> manuals, and I don't want to repeat it here.
>
> Cheers,
>
> Bruce
>
>> Please help me.
>> Thanks a lot in advance.
>>
>> Best Regards,
>> Om Prakash Pal
>> ________________________________________
>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>> Sent: Wednesday, April 04, 2012 6:17 PM
>> To: Om Prakash PAL
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> On 12-04-04 04:46 AM, Om Prakash PAL wrote:
>>> Hi,
>>> I want to build my local kernel/Driver code, not the default one.
>>> please help how can i do it ?.
>>> any wiki/docs on this?.
>>
>> The BSP developer guides show how to extend the yocto kernels, and
>> also have sections on custom/different kernel versions. Have you
>> seen that doc yet ? Or have you seen it, and have specific questions ?
>>
>> Bruce
>>
>>>
>>> Best Regards,
>>> Om Prakash Pal
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: Porting of specific Kernel/Driver into yocto.

[Bruce Ashfield]

On 12-04-30 6:34 AM, Om Prakash PAL wrote:
>> On 12-04-29 5:58 AM, Om Prakash PAL wrote:
>
>     >  Hi Bruce,
>      >for porting of our local kernel,we have created an BSP layer and to change the the
>      >kernel,  we have created an linux-yocto_3.0.bbappend file inside
>      >meta<BSP>/recipes-kernel/linux/
>      >like this:-
>
>      >FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>
>     >  COMPATIBLE_MACHINE_<BSP_name>   = "BSP_name"
>
>      ># KMACHINE is the branch to build
>      >KMACHINE_<BSP_name>   = "local_branch"
>
>     >  SRCREV_machine_pn_linux-yocto_<BSP_name>   ?= "XXXXXXXX" (here we have assign
>      >top commit ID of our local kernel)
>
>
>      ># KSRC_linux_yocto to point to your local clone as appropriate.
>      >KSRC_linux_yocto ?= "/path/to/local/kernel"
>
>      >SRC_URI =
>      >"git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH};name=machine
>       >\
>         >               file://defconfig"
>
>
>      >KERNEL_REVISION_CHECKING=""
>      >SRCREV="${AUTOREV}"
>      >#BB_LOCALCOUNT_OVERRIDE = "1"
>      >LOCALCOUNT = "0"
>
>
>      >while building we are getting following Error:
>
>      >NOTE: Executing RunQueue Tasks
>      >NOTE: Running task 1341 of 1710 (ID: 513,
>      >/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb,
>       >do_validate_branches)
>      >NOTE: package
>      >linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2: task
>      >do_validate_branches: Started
>      >ERROR: Function 'do_validate_branches' failed (see
>      >/home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/temp/log.do_validate_branches.16792
>       >for further information)
>
>
>      >please tell me what we have done wrong?.
>      >is there anything else we need to modify in .bbappend file or some other
>      >variable?.
>
>> Which release are you using again ?
>    I am using 6.0.0 Edision
>
>> The diagnostics out of validate branches are about to get better in master,
>> but they are coupled with some other tools changes that couldn't go
>> into yocto 1.2.
>
>> Is there anything extra in the log file, or just what you saw on the
>> build log ?.
> actually I have set YOCTO_KERNEL_EXTERNAL_BRANCH ="dev";(dev is my local brach)
> Now this Error has gone and now I am getting
>
> ERROR: Function 'do_patch' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008 for further information)
> ERROR: Logfile of failure stored in: /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008
> Log data follows:
> | ERROR. meta data not found, check upstream repo for tags and branches
> | ERROR: Function 'do_patch' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008 for further information)
> NOTE: package linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3: task do_patch: Failed
> ERROR: Task 516 (/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_patch) failed with exit code '1'
> ERROR: '/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb' failed
>

This is what I was saying a few weeks ago. If you aren't using
the linux-yocto kernel repository (and hence linux-yocto branches/meta 
data) as your base, then building directly via the linux-yocto recipe
probably isn't what you want. It is a recipe that leverages the tools
and infrastructure on top of the linux-yocto repository.

That same infrastructure can build other repositories, but needs some
extra variables set. The meta-kernel-dev layer, in poky-extras has
examples of this for building korg (or any repo) with the tools.

What you re being told in this particular error is that you don't have
a meta branch in the tree, or not one that the tools can recognize.
You can prevent this by setting YOCTO_KERNEL_META_DATA="" in your
recipe (see the korg recipe as an example). (and FYI: this will no
longer be required in 1.3, but it is for any previous release).

>
>> Validate branches fails like this when you've provided a bad branch or
>> SRCREV (vs a SRCREV that is simply not the tip of the branch .. it fixes
>> hat scenario) and the fetcher or another git command aborts.
>
>> You've output some example text from the bbappend, but what were the real
>> values in your situation ? i.e. what are KMACHINE/KBRANCH set to ?.
>
> I have not set the value of KBRANCH?. what it should be ?.

It needs to be a valid branch in the repository. The 1.2 recipes
set it to be KMACHINE if it hasn't been explicitly set. But it
sounds like you are past this, and have set your branch to something
that actually exists in the tree.

Cheers,

Bruce

>
>> There are some flags you can set to exit the branch validation early, but
>> I don't think setting them is the right course of action yet, since the
>> error you are seeing is likely hiding some other mis configuration.
>
>> Cheers,
>
>> Bruce
>
> Best Regards,
> Om Prakash Pal
> ________________________________________
> From: Om Prakash PAL
> Sent: Sunday, April 29, 2012 3:28 PM
> To: Bruce Ashfield
> Cc: yocto@yoctoproject.org
> Subject: RE: [yocto] Porting of specific Kernel/Driver into yocto.
>
> Hi Bruce,
> for porting of our local kernel,we have created an BSP layer and to change the the kernel,  we have created an linux-yocto_3.0.bbappend file inside meta<BSP>/recipes-kernel/linux/
> like this:-
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>
> COMPATIBLE_MACHINE_<BSP_name>  = "BSP_name"
>
> # KMACHINE is the branch to build
> KMACHINE_<BSP_name>  = "local_branch"
>
> SRCREV_machine_pn_linux-yocto_<BSP_name>  ?= "XXXXXXXX" (here we have assign top commit ID of our local kernel)
>
>
> # KSRC_linux_yocto to point to your local clone as appropriate.
> KSRC_linux_yocto ?= "/path/to/local/kernel"
>
> SRC_URI = "git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH};name=machine \
>                  file://defconfig"
>
>
> KERNEL_REVISION_CHECKING=""
> SRCREV="${AUTOREV}"
> #BB_LOCALCOUNT_OVERRIDE = "1"
> LOCALCOUNT = "0"
>
>
> while building we are getting following Error:
>
> NOTE: Executing RunQueue Tasks
> NOTE: Running task 1341 of 1710 (ID: 513, /home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_validate_branches)
> NOTE: package linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2: task do_validate_branches: Started
> ERROR: Function 'do_validate_branches' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/temp/log.do_validate_branches.16792 for further information)
>
>
> please tell me what we have done wrong?.
> is there anything else we need to modify in .bbappend file or some other variable?.
>
> Best Regards,
> Om Prakash Pal
> ________________________________________
> From: Bruce Ashfield [bruce.ashfield@gmail.com]
> Sent: Monday, April 09, 2012 11:04 PM
> To: Om Prakash PAL
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>
> On Mon, Apr 9, 2012 at 12:31 PM, Om Prakash PAL
> <omprakash.pal@stericsson.com>  wrote:
>> Hi Bruce,
>> Thanks for you help.
>> As you have mentioned, its working properly.
>> I want to know that is there any better way of doing same thing for my scenario ?:
>> here is my scenario:
>> We have development branch where we write/modify our kernel/driver code i.e. thats our local kernel repository(git rep)
>> and lots of driver/files being modified everyday-->so I have to take the same effect into yocto kernel also---->  so except  creating patches for all modified drivers and creating .bbappend files, is there any better way of doing same thing .
>
> Aha. Missed that.
>
> Just create a simple recipe that points at your git repository in the SRC_URI.
> If all the changes are in the tree, and you have a defconfig and you
> are building
> the master branch. Then pretty much everything you need can be specified in
> the SRC_URI .. and that's the entire recipe.
>
> If you look in oe-classic, meta-ti or any one of a number of other
> layers, you'll
> find recipes that do just that.
>
> The meta-kernel-dev (in the poky extras) layer has an example of using the
> kernel.org tree with the yocto kern tools, and once yocto 1.3 opens up for
> submissions, I have a set of changes prep'd that make it relatively simple to
> use the yocto kern tools against different types of repository.
>
> So the summary is: Depending on the type of tooling you need, and what baseline
> you need for your work .. there are a number of ways to do things.
>
>>
>> Is there anyway that  instead of using yocto-kernel tree,  can we use our local kernel-tree for building images?. (should  I create separate BSP ?)
>
> You should definitely create a BSP, that way you can tune the system specific
> to your board,
>
> Cheers,
>
> Bruce
>
>>
>> Thanks in advance.
>> Best Regards,
>> Om Prakash Pal
>> ________________________________________
>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>> Sent: Monday, April 09, 2012 9:32 AM
>> To: Om Prakash PAL
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> On 12-04-08 10:04 AM, Om Prakash PAL wrote:
>>> Hi Bruce,
>>> Thanks for your reply.
>>> I am totally new to Yocto.
>>> I have gone through the section BSP/Linux kernel configuration and if I am not wrong then it explains how can we configure the kernel, not the how we can add/replace a  component(driver etc).
>>> lets take the example of UART driver, I want to add my own UART driver code.
>>> Should I write a separate recipe file (.bb) for UART Driver?.
>>> if yes then I have to write the recipe files for all my drivers that will be very time consuming.
>>> Is there any other way that I can port all my desired drivers into Yocto kernel?.
>>
>> No recipes are required per-driver, unless you are building them all
>> as out of tree modules.
>>
>> The typical way this is done is to simply work in the extracted linux
>> src tree (build/tmp/work/<your board>/linux-yocto-<hashes>/linux), manually
>> patch, or copy your drivers into the tree. At this point, you'll port
>> the drivers, doing test builds (bitbake -f -c compile linux-yocto) to
>> ensure that your port is working. When you've completed the build phase,
>> boot tests would be in order. (Do not do a 'clean' or you'll lose in
>> progress changes).
>>
>> When you are happy with the changes, the directory where you were working
>> is with the kernel git repository. So you can simply commit your
>> changes, and generate patches.
>>
>>     git format-patch -o<your directory>  HEAD^ (or however many commits
>> you have)
>>
>> Take those patches, create a layer with a bbappend and add them like
>> any other patch to any package. They'll be applied to subsequent builds
>> of the kernel.
>>
>> I'm skipping a lot of detail there, but it is all found in the various
>> manuals, and I don't want to repeat it here.
>>
>> Cheers,
>>
>> Bruce
>>
>>> Please help me.
>>> Thanks a lot in advance.
>>>
>>> Best Regards,
>>> Om Prakash Pal
>>> ________________________________________
>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>> Sent: Wednesday, April 04, 2012 6:17 PM
>>> To: Om Prakash PAL
>>> Cc: yocto@yoctoproject.org
>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>
>>> On 12-04-04 04:46 AM, Om Prakash PAL wrote:
>>>> Hi,
>>>> I want to build my local kernel/Driver code, not the default one.
>>>> please help how can i do it ?.
>>>> any wiki/docs on this?.
>>>
>>> The BSP developer guides show how to extend the yocto kernels, and
>>> also have sections on custom/different kernel versions. Have you
>>> seen that doc yet ? Or have you seen it, and have specific questions ?
>>>
>>> Bruce
>>>
>>>>
>>>> Best Regards,
>>>> Om Prakash Pal
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end"
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: Porting of specific Kernel/Driver into yocto.

[Om Prakash PAL]

Hi Bruce,
Thanks a lot for your help.
Now I am able to build the local kernel.
I have one doublt:
when I do  
bitbake -c mencuconfig virtual/kernel

then from which location it will take the config file?.
and if I want to buiild my own specific defconfig file then How can do it?.

Best Regards,
Om Prakash Pal
________________________________________
From: Bruce Ashfield [bruce.ashfield@windriver.com]
Sent: Monday, April 30, 2012 7:42 PM
To: Om Prakash PAL
Cc: Bruce Ashfield; yocto@yoctoproject.org
Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.

On 12-04-30 6:34 AM, Om Prakash PAL wrote:
>> On 12-04-29 5:58 AM, Om Prakash PAL wrote:
>
>     >  Hi Bruce,
>      >for porting of our local kernel,we have created an BSP layer and to change the the
>      >kernel,  we have created an linux-yocto_3.0.bbappend file inside
>      >meta<BSP>/recipes-kernel/linux/
>      >like this:-
>
>      >FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>
>     >  COMPATIBLE_MACHINE_<BSP_name>   = "BSP_name"
>
>      ># KMACHINE is the branch to build
>      >KMACHINE_<BSP_name>   = "local_branch"
>
>     >  SRCREV_machine_pn_linux-yocto_<BSP_name>   ?= "XXXXXXXX" (here we have assign
>      >top commit ID of our local kernel)
>
>
>      ># KSRC_linux_yocto to point to your local clone as appropriate.
>      >KSRC_linux_yocto ?= "/path/to/local/kernel"
>
>      >SRC_URI =
>      >"git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH};name=machine
>       >\
>         >               file://defconfig"
>
>
>      >KERNEL_REVISION_CHECKING=""
>      >SRCREV="${AUTOREV}"
>      >#BB_LOCALCOUNT_OVERRIDE = "1"
>      >LOCALCOUNT = "0"
>
>
>      >while building we are getting following Error:
>
>      >NOTE: Executing RunQueue Tasks
>      >NOTE: Running task 1341 of 1710 (ID: 513,
>      >/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb,
>       >do_validate_branches)
>      >NOTE: package
>      >linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2: task
>      >do_validate_branches: Started
>      >ERROR: Function 'do_validate_branches' failed (see
>      >/home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/temp/log.do_validate_branches.16792
>       >for further information)
>
>
>      >please tell me what we have done wrong?.
>      >is there anything else we need to modify in .bbappend file or some other
>      >variable?.
>
>> Which release are you using again ?
>    I am using 6.0.0 Edision
>
>> The diagnostics out of validate branches are about to get better in master,
>> but they are coupled with some other tools changes that couldn't go
>> into yocto 1.2.
>
>> Is there anything extra in the log file, or just what you saw on the
>> build log ?.
> actually I have set YOCTO_KERNEL_EXTERNAL_BRANCH ="dev";(dev is my local brach)
> Now this Error has gone and now I am getting
>
> ERROR: Function 'do_patch' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008 for further information)
> ERROR: Logfile of failure stored in: /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008
> Log data follows:
> | ERROR. meta data not found, check upstream repo for tags and branches
> | ERROR: Function 'do_patch' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008 for further information)
> NOTE: package linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3: task do_patch: Failed
> ERROR: Task 516 (/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_patch) failed with exit code '1'
> ERROR: '/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb' failed
>

This is what I was saying a few weeks ago. If you aren't using
the linux-yocto kernel repository (and hence linux-yocto branches/meta
data) as your base, then building directly via the linux-yocto recipe
probably isn't what you want. It is a recipe that leverages the tools
and infrastructure on top of the linux-yocto repository.

That same infrastructure can build other repositories, but needs some
extra variables set. The meta-kernel-dev layer, in poky-extras has
examples of this for building korg (or any repo) with the tools.

What you re being told in this particular error is that you don't have
a meta branch in the tree, or not one that the tools can recognize.
You can prevent this by setting YOCTO_KERNEL_META_DATA="" in your
recipe (see the korg recipe as an example). (and FYI: this will no
longer be required in 1.3, but it is for any previous release.
>
>> Validate branches fails like this when you've provided a bad branch or
>> SRCREV (vs a SRCREV that is simply not the tip of the branch .. it fixes
>> hat scenario) and the fetcher or another git command aborts.
>
>> You've output some example text from the bbappend, but what were the real
>> values in your situation ? i.e. what are KMACHINE/KBRANCH set to ?.
>
> I have not set the value of KBRANCH?. what it should be ?.

It needs to be a valid branch in the repository. The 1.2 recipes
set it to be KMACHINE if it hasn't been explicitly set. But it
sounds like you are past this, and have set your branch to something
that actually exists in the tree.

Cheers,

Bruce

>
>> There are some flags you can set to exit the branch validation early, but
>> I don't think setting them is the right course of action yet, since the
>> error you are seeing is likely hiding some other mis configuration.
>
>> Cheers,
>
>> Bruce
>
> Best Regards,
> Om Prakash Pal
> ________________________________________
> From: Om Prakash PAL
> Sent: Sunday, April 29, 2012 3:28 PM
> To: Bruce Ashfield
> Cc: yocto@yoctoproject.org
> Subject: RE: [yocto] Porting of specific Kernel/Driver into yocto.
>
> Hi Bruce,
> for porting of our local kernel,we have created an BSP layer and to change the the kernel,  we have created an linux-yocto_3.0.bbappend file inside meta<BSP>/recipes-kernel/linux/
> like this:-
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>
> COMPATIBLE_MACHINE_<BSP_name>  = "BSP_name"
>
> # KMACHINE is the branch to build
> KMACHINE_<BSP_name>  = "local_branch"
>
> SRCREV_machine_pn_linux-yocto_<BSP_name>  ?= "XXXXXXXX" (here we have assign top commit ID of our local kernel)
>
>
> # KSRC_linux_yocto to point to your local clone as appropriate.
> KSRC_linux_yocto ?= "/path/to/local/kernel"
>
> SRC_URI = "git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH};name=machine \
>                  file://defconfig"
>
>
> KERNEL_REVISION_CHECKING=""
> SRCREV="${AUTOREV}"
> #BB_LOCALCOUNT_OVERRIDE = "1"
> LOCALCOUNT = "0"
>
>
> while building we are getting following Error:
>
> NOTE: Executing RunQueue Tasks
> NOTE: Running task 1341 of 1710 (ID: 513, /home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_validate_branches)
> NOTE: package linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2: task do_validate_branches: Started
> ERROR: Function 'do_validate_branches' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/temp/log.do_validate_branches.16792 for further information)
>
>
> please tell me what we have done wrong?.
> is there anything else we need to modify in .bbappend file or some other variable?.
>
> Best Regards,
> Om Prakash Pal
> ________________________________________
> From: Bruce Ashfield [bruce.ashfield@gmail.com]
> Sent: Monday, April 09, 2012 11:04 PM
> To: Om Prakash PAL
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>
> On Mon, Apr 9, 2012 at 12:31 PM, Om Prakash PAL
> <omprakash.pal@stericsson.com>  wrote:
>> Hi Bruce,
>> Thanks for you help.
>> As you have mentioned, its working properly.
>> I want to know that is there any better way of doing same thing for my scenario ?:
>> here is my scenario:
>> We have development branch where we write/modify our kernel/driver code i.e. thats our local kernel repository(git rep)
>> and lots of driver/files being modified everyday-->so I have to take the same effect into yocto kernel also---->  so except  creating patches for all modified drivers and creating .bbappend files, is there any better way of doing same thing .
>
> Aha. Missed that.
>
> Just create a simple recipe that points at your git repository in the SRC_URI.
> If all the changes are in the tree, and you have a defconfig and you
> are building
> the master branch. Then pretty much everything you need can be specified in
> the SRC_URI .. and that's the entire recipe.
>
> If you look in oe-classic, meta-ti or any one of a number of other
> layers, you'll
> find recipes that do just that.
>
> The meta-kernel-dev (in the poky extras) layer has an example of using the
> kernel.org tree with the yocto kern tools, and once yocto 1.3 opens up for
> submissions, I have a set of changes prep'd that make it relatively simple to
> use the yocto kern tools against different types of repository.
>
> So the summary is: Depending on the type of tooling you need, and what baseline
> you need for your work .. there are a number of ways to do things.
>
>>
>> Is there anyway that  instead of using yocto-kernel tree,  can we use our local kernel-tree for building images?. (should  I create separate BSP ?)
>
> You should definitely create a BSP, that way you can tune the system specific
> to your board,
>
> Cheers,
>
> Bruce
>
>>
>> Thanks in advance.
>> Best Regards,
>> Om Prakash Pal
>> ________________________________________
>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>> Sent: Monday, April 09, 2012 9:32 AM
>> To: Om Prakash PAL
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> On 12-04-08 10:04 AM, Om Prakash PAL wrote:
>>> Hi Bruce,
>>> Thanks for your reply.
>>> I am totally new to Yocto.
>>> I have gone through the section BSP/Linux kernel configuration and if I am not wrong then it explains how can we configure the kernel, not the how we can add/replace a  component(driver etc).
>>> lets take the example of UART driver, I want to add my own UART driver code.
>>> Should I write a separate recipe file (.bb) for UART Driver?.
>>> if yes then I have to write the recipe files for all my drivers that will be very time consuming.
>>> Is there any other way that I can port all my desired drivers into Yocto kernel?.
>>
>> No recipes are required per-driver, unless you are building them all
>> as out of tree modules.
>>
>> The typical way this is done is to simply work in the extracted linux
>> src tree (build/tmp/work/<your board>/linux-yocto-<hashes>/linux), manually
>> patch, or copy your drivers into the tree. At this point, you'll port
>> the drivers, doing test builds (bitbake -f -c compile linux-yocto) to
>> ensure that your port is working. When you've completed the build phase,
>> boot tests would be in order. (Do not do a 'clean' or you'll lose in
>> progress changes).
>>
>> When you are happy with the changes, the directory where you were working
>> is with the kernel git repository. So you can simply commit your
>> changes, and generate patches.
>>
>>     git format-patch -o<your directory>  HEAD^ (or however many commits
>> you have)
>>
>> Take those patches, create a layer with a bbappend and add them like
>> any other patch to any package. They'll be applied to subsequent builds
>> of the kernel.
>>
>> I'm skipping a lot of detail there, but it is all found in the various
>> manuals, and I don't want to repeat it here.
>>
>> Cheers,
>>
>> Bruce
>>
>>> Please help me.
>>> Thanks a lot in advance.
>>>
>>> Best Regards,
>>> Om Prakash Pal
>>> ________________________________________
>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>> Sent: Wednesday, April 04, 2012 6:17 PM
>>> To: Om Prakash PAL
>>> Cc: yocto@yoctoproject.org
>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>
>>> On 12-04-04 04:46 AM, Om Prakash PAL wrote:
>>>> Hi,
>>>> I want to build my local kernel/Driver code, not the default one.
>>>> please help how can i do it ?.
>>>> any wiki/docs on this?.
>>>
>>> The BSP developer guides show how to extend the yocto kernels, and
>>> also have sections on custom/different kernel versions. Have you
>>> seen that doc yet ? Or have you seen it, and have specific questions ?
>>>
>>> Bruce
>>>
>>>>
>>>> Best Regards,
>>>> Om Prakash Pal
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end"
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: Porting of specific Kernel/Driver into yocto.

[Bruce Ashfield]

On 12-05-03 05:24 AM, Om Prakash PAL wrote:
> Hi Bruce,
> Thanks a lot for your help.
> Now I am able to build the local kernel.

Great!

> I have one doublt:
> when I do
> bitbake -c mencuconfig virtual/kernel
>
> then from which location it will take the config file?.
> and if I want to buiild my own specific defconfig file then How can do it?.

It will use the .config in the build directory ${B}, which if you
are using a linux-yocto recipe would be your 
linux-$MACHINE-$KERNELTYPE-build
directory.

The dependencies of menuconfig will ensure that the kernel has been fetched,
unpacked and configured before it runs. Which means a defconfig will
have already been used (if specified) to construct the .config.

Any changes you make will be saved in the .config, and you'll need to
preserve that for future builds.

Cheers,

Bruce

>
> Best Regards,
> Om Prakash Pal
> ________________________________________
> From: Bruce Ashfield [bruce.ashfield@windriver.com]
> Sent: Monday, April 30, 2012 7:42 PM
> To: Om Prakash PAL
> Cc: Bruce Ashfield; yocto@yoctoproject.org
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>
> On 12-04-30 6:34 AM, Om Prakash PAL wrote:
>>> On 12-04-29 5:58 AM, Om Prakash PAL wrote:
>>
>>      >   Hi Bruce,
>>       >for porting of our local kernel,we have created an BSP layer and to change the the
>>       >kernel,  we have created an linux-yocto_3.0.bbappend file inside
>>       >meta<BSP>/recipes-kernel/linux/
>>       >like this:-
>>
>>       >FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>
>>      >   COMPATIBLE_MACHINE_<BSP_name>    = "BSP_name"
>>
>>       ># KMACHINE is the branch to build
>>       >KMACHINE_<BSP_name>    = "local_branch"
>>
>>      >   SRCREV_machine_pn_linux-yocto_<BSP_name>    ?= "XXXXXXXX" (here we have assign
>>       >top commit ID of our local kernel)
>>
>>
>>       ># KSRC_linux_yocto to point to your local clone as appropriate.
>>       >KSRC_linux_yocto ?= "/path/to/local/kernel"
>>
>>       >SRC_URI =
>>       >"git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH};name=machine
>>        >\
>>          >                file://defconfig"
>>
>>
>>       >KERNEL_REVISION_CHECKING=""
>>       >SRCREV="${AUTOREV}"
>>       >#BB_LOCALCOUNT_OVERRIDE = "1"
>>       >LOCALCOUNT = "0"
>>
>>
>>       >while building we are getting following Error:
>>
>>       >NOTE: Executing RunQueue Tasks
>>       >NOTE: Running task 1341 of 1710 (ID: 513,
>>       >/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb,
>>        >do_validate_branches)
>>       >NOTE: package
>>       >linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2: task
>>       >do_validate_branches: Started
>>       >ERROR: Function 'do_validate_branches' failed (see
>>       >/home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/temp/log.do_validate_branches.16792
>>        >for further information)
>>
>>
>>       >please tell me what we have done wrong?.
>>       >is there anything else we need to modify in .bbappend file or some other
>>       >variable?.
>>
>>> Which release are you using again ?
>>     I am using 6.0.0 Edision
>>
>>> The diagnostics out of validate branches are about to get better in master,
>>> but they are coupled with some other tools changes that couldn't go
>>> into yocto 1.2.
>>
>>> Is there anything extra in the log file, or just what you saw on the
>>> build log ?.
>> actually I have set YOCTO_KERNEL_EXTERNAL_BRANCH ="dev";(dev is my local brach)
>> Now this Error has gone and now I am getting
>>
>> ERROR: Function 'do_patch' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008 for further information)
>> ERROR: Logfile of failure stored in: /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008
>> Log data follows:
>> | ERROR. meta data not found, check upstream repo for tags and branches
>> | ERROR: Function 'do_patch' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008 for further information)
>> NOTE: package linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3: task do_patch: Failed
>> ERROR: Task 516 (/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_patch) failed with exit code '1'
>> ERROR: '/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb' failed
>>
>
> This is what I was saying a few weeks ago. If you aren't using
> the linux-yocto kernel repository (and hence linux-yocto branches/meta
> data) as your base, then building directly via the linux-yocto recipe
> probably isn't what you want. It is a recipe that leverages the tools
> and infrastructure on top of the linux-yocto repository.
>
> That same infrastructure can build other repositories, but needs some
> extra variables set. The meta-kernel-dev layer, in poky-extras has
> examples of this for building korg (or any repo) with the tools.
>
> What you re being told in this particular error is that you don't have
> a meta branch in the tree, or not one that the tools can recognize.
> You can prevent this by setting YOCTO_KERNEL_META_DATA="" in your
> recipe (see the korg recipe as an example). (and FYI: this will no
> longer be required in 1.3, but it is for any previous release.
>>
>>> Validate branches fails like this when you've provided a bad branch or
>>> SRCREV (vs a SRCREV that is simply not the tip of the branch .. it fixes
>>> hat scenario) and the fetcher or another git command aborts.
>>
>>> You've output some example text from the bbappend, but what were the real
>>> values in your situation ? i.e. what are KMACHINE/KBRANCH set to ?.
>>
>> I have not set the value of KBRANCH?. what it should be ?.
>
> It needs to be a valid branch in the repository. The 1.2 recipes
> set it to be KMACHINE if it hasn't been explicitly set. But it
> sounds like you are past this, and have set your branch to something
> that actually exists in the tree.
>
> Cheers,
>
> Bruce
>
>>
>>> There are some flags you can set to exit the branch validation early, but
>>> I don't think setting them is the right course of action yet, since the
>>> error you are seeing is likely hiding some other mis configuration.
>>
>>> Cheers,
>>
>>> Bruce
>>
>> Best Regards,
>> Om Prakash Pal
>> ________________________________________
>> From: Om Prakash PAL
>> Sent: Sunday, April 29, 2012 3:28 PM
>> To: Bruce Ashfield
>> Cc: yocto@yoctoproject.org
>> Subject: RE: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> Hi Bruce,
>> for porting of our local kernel,we have created an BSP layer and to change the the kernel,  we have created an linux-yocto_3.0.bbappend file inside meta<BSP>/recipes-kernel/linux/
>> like this:-
>>
>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>
>> COMPATIBLE_MACHINE_<BSP_name>   = "BSP_name"
>>
>> # KMACHINE is the branch to build
>> KMACHINE_<BSP_name>   = "local_branch"
>>
>> SRCREV_machine_pn_linux-yocto_<BSP_name>   ?= "XXXXXXXX" (here we have assign top commit ID of our local kernel)
>>
>>
>> # KSRC_linux_yocto to point to your local clone as appropriate.
>> KSRC_linux_yocto ?= "/path/to/local/kernel"
>>
>> SRC_URI = "git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH};name=machine \
>>                   file://defconfig"
>>
>>
>> KERNEL_REVISION_CHECKING=""
>> SRCREV="${AUTOREV}"
>> #BB_LOCALCOUNT_OVERRIDE = "1"
>> LOCALCOUNT = "0"
>>
>>
>> while building we are getting following Error:
>>
>> NOTE: Executing RunQueue Tasks
>> NOTE: Running task 1341 of 1710 (ID: 513, /home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_validate_branches)
>> NOTE: package linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2: task do_validate_branches: Started
>> ERROR: Function 'do_validate_branches' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/temp/log.do_validate_branches.16792 for further information)
>>
>>
>> please tell me what we have done wrong?.
>> is there anything else we need to modify in .bbappend file or some other variable?.
>>
>> Best Regards,
>> Om Prakash Pal
>> ________________________________________
>> From: Bruce Ashfield [bruce.ashfield@gmail.com]
>> Sent: Monday, April 09, 2012 11:04 PM
>> To: Om Prakash PAL
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> On Mon, Apr 9, 2012 at 12:31 PM, Om Prakash PAL
>> <omprakash.pal@stericsson.com>   wrote:
>>> Hi Bruce,
>>> Thanks for you help.
>>> As you have mentioned, its working properly.
>>> I want to know that is there any better way of doing same thing for my scenario ?:
>>> here is my scenario:
>>> We have development branch where we write/modify our kernel/driver code i.e. thats our local kernel repository(git rep)
>>> and lots of driver/files being modified everyday-->so I have to take the same effect into yocto kernel also---->   so except  creating patches for all modified drivers and creating .bbappend files, is there any better way of doing same thing .
>>
>> Aha. Missed that.
>>
>> Just create a simple recipe that points at your git repository in the SRC_URI.
>> If all the changes are in the tree, and you have a defconfig and you
>> are building
>> the master branch. Then pretty much everything you need can be specified in
>> the SRC_URI .. and that's the entire recipe.
>>
>> If you look in oe-classic, meta-ti or any one of a number of other
>> layers, you'll
>> find recipes that do just that.
>>
>> The meta-kernel-dev (in the poky extras) layer has an example of using the
>> kernel.org tree with the yocto kern tools, and once yocto 1.3 opens up for
>> submissions, I have a set of changes prep'd that make it relatively simple to
>> use the yocto kern tools against different types of repository.
>>
>> So the summary is: Depending on the type of tooling you need, and what baseline
>> you need for your work .. there are a number of ways to do things.
>>
>>>
>>> Is there anyway that  instead of using yocto-kernel tree,  can we use our local kernel-tree for building images?. (should  I create separate BSP ?)
>>
>> You should definitely create a BSP, that way you can tune the system specific
>> to your board,
>>
>> Cheers,
>>
>> Bruce
>>
>>>
>>> Thanks in advance.
>>> Best Regards,
>>> Om Prakash Pal
>>> ________________________________________
>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>> Sent: Monday, April 09, 2012 9:32 AM
>>> To: Om Prakash PAL
>>> Cc: yocto@yoctoproject.org
>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>
>>> On 12-04-08 10:04 AM, Om Prakash PAL wrote:
>>>> Hi Bruce,
>>>> Thanks for your reply.
>>>> I am totally new to Yocto.
>>>> I have gone through the section BSP/Linux kernel configuration and if I am not wrong then it explains how can we configure the kernel, not the how we can add/replace a  component(driver etc).
>>>> lets take the example of UART driver, I want to add my own UART driver code.
>>>> Should I write a separate recipe file (.bb) for UART Driver?.
>>>> if yes then I have to write the recipe files for all my drivers that will be very time consuming.
>>>> Is there any other way that I can port all my desired drivers into Yocto kernel?.
>>>
>>> No recipes are required per-driver, unless you are building them all
>>> as out of tree modules.
>>>
>>> The typical way this is done is to simply work in the extracted linux
>>> src tree (build/tmp/work/<your board>/linux-yocto-<hashes>/linux), manually
>>> patch, or copy your drivers into the tree. At this point, you'll port
>>> the drivers, doing test builds (bitbake -f -c compile linux-yocto) to
>>> ensure that your port is working. When you've completed the build phase,
>>> boot tests would be in order. (Do not do a 'clean' or you'll lose in
>>> progress changes).
>>>
>>> When you are happy with the changes, the directory where you were working
>>> is with the kernel git repository. So you can simply commit your
>>> changes, and generate patches.
>>>
>>>      git format-patch -o<your directory>   HEAD^ (or however many commits
>>> you have)
>>>
>>> Take those patches, create a layer with a bbappend and add them like
>>> any other patch to any package. They'll be applied to subsequent builds
>>> of the kernel.
>>>
>>> I'm skipping a lot of detail there, but it is all found in the various
>>> manuals, and I don't want to repeat it here.
>>>
>>> Cheers,
>>>
>>> Bruce
>>>
>>>> Please help me.
>>>> Thanks a lot in advance.
>>>>
>>>> Best Regards,
>>>> Om Prakash Pal
>>>> ________________________________________
>>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>>> Sent: Wednesday, April 04, 2012 6:17 PM
>>>> To: Om Prakash PAL
>>>> Cc: yocto@yoctoproject.org
>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>
>>>> On 12-04-04 04:46 AM, Om Prakash PAL wrote:
>>>>> Hi,
>>>>> I want to build my local kernel/Driver code, not the default one.
>>>>> please help how can i do it ?.
>>>>> any wiki/docs on this?.
>>>>
>>>> The BSP developer guides show how to extend the yocto kernels, and
>>>> also have sections on custom/different kernel versions. Have you
>>>> seen that doc yet ? Or have you seen it, and have specific questions ?
>>>>
>>>> Bruce
>>>>
>>>>>
>>>>> Best Regards,
>>>>> Om Prakash Pal
>>>>> _______________________________________________
>>>>> yocto mailing list
>>>>> yocto@yoctoproject.org
>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>
>>>
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>>
>> --
>> "Thou shalt not follow the NULL pointer, for chaos and madness await
>> thee at its end"
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>

Re: Porting of specific Kernel/Driver into yocto.

[Om Prakash PAL]

Hi Bruce,
I am getting some problem in do_install:

NOTE: Running task 1535 of 1710 (ID: 517, /home/apallan/yocto/poky-edison-6.0/meta-u8500/recipes-kernel/linux/linux-u8500.bb, do_install)
NOTE: package linux-u8500-3.2+git1+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r10: task do_install: Started

and I waited for ~15hr to complete task do_install: but not completed and i am not getting any Errors/warnings.
Is there any problem?.
I have checked that my vmlinux/uImage/zImage has been created successfully but rootfs has not been created till now.

here is my .bb file that is building my local_kernel.

inherit kernel
require recipes-kernel/linux/linux-yocto.inc

KMACHINE = "dev"
YOCTO_KERNEL_EXTERNAL_BRANCH ?= "dev"

KBRANCH = "${KMACHINE}"
KMETA = "meta"

KSRC_linux_yocto ?= "/home/apallan/yocto/kernel/"

SRC_URI = "git://${KSRC_linux_yocto};protocol=file;nocheckout=1"
SRC_URI +="file://defconfig"

SRCREV="${AUTOREV}"
SRCREV_pn-linux-u8500 ="0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383"

LINUX_VERSION ?= "3.2"
LINUX_VERSION_EXTENSION = "-yoctized-${LINUX_KERNEL_TYPE}"
PR = "r10"
PV = "${LINUX_VERSION}+git${SRCPV}"

COMPATIBLE_MACHINE = "(u8500|qemuarm)"

# Functionality flags
KERNEL_REVISION_CHECKING=""
YOCTO_KERNEL_META_DATA=""

require recipes-kernel/linux/linux-tools.inc

what should be the problem?.

Best Regards,
Om Prakash Pal
________________________________________
From: Bruce Ashfield [bruce.ashfield@windriver.com]
Sent: Thursday, May 03, 2012 5:59 PM
To: Om Prakash PAL
Cc: Bruce Ashfield; yocto@yoctoproject.org
Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.

On 12-05-03 05:24 AM, Om Prakash PAL wrote:
> Hi Bruce,
> Thanks a lot for your help.
> Now I am able to build the local kernel.

Great!

> I have one doublt:
> when I do
> bitbake -c mencuconfig virtual/kernel
>
> then from which location it will take the config file?.
> and if I want to buiild my own specific defconfig file then How can do it?.

It will use the .config in the build directory ${B}, which if you
are using a linux-yocto recipe would be your
linux-$MACHINE-$KERNELTYPE-build
directory.

The dependencies of menuconfig will ensure that the kernel has been fetched,
unpacked and configured before it runs. Which means a defconfig will
have already been used (if specified) to construct the .config.

Any changes you make will be saved in the .config, and you'll need to
preserve that for future builds.

Cheers,

Bruce

>
> Best Regards,
> Om Prakash Pal
> ________________________________________
> From: Bruce Ashfield [bruce.ashfield@windriver.com]
> Sent: Monday, April 30, 2012 7:42 PM
> To: Om Prakash PAL
> Cc: Bruce Ashfield; yocto@yoctoproject.org
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>
> On 12-04-30 6:34 AM, Om Prakash PAL wrote:
>>> On 12-04-29 5:58 AM, Om Prakash PAL wrote:
>>
>>      >   Hi Bruce,
>>       >for porting of our local kernel,we have created an BSP layer and to change the the
>>       >kernel,  we have created an linux-yocto_3.0.bbappend file inside
>>       >meta<BSP>/recipes-kernel/linux/
>>       >like this:-
>>
>>       >FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>
>>      >   COMPATIBLE_MACHINE_<BSP_name>    = "BSP_name"
>>
>>       ># KMACHINE is the branch to build
>>       >KMACHINE_<BSP_name>    = "local_branch"
>>
>>      >   SRCREV_machine_pn_linux-yocto_<BSP_name>    ?= "XXXXXXXX" (here we have assign
>>       >top commit ID of our local kernel)
>>
>>
>>       ># KSRC_linux_yocto to point to your local clone as appropriate.
>>       >KSRC_linux_yocto ?= "/path/to/local/kernel"
>>
>>       >SRC_URI =
>>       >"git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH};name=machine
>>        >\
>>          >                file://defconfig"
>>
>>
>>       >KERNEL_REVISION_CHECKING=""
>>       >SRCREV="${AUTOREV}"
>>       >#BB_LOCALCOUNT_OVERRIDE = "1"
>>       >LOCALCOUNT = "0"
>>
>>
>>       >while building we are getting following Error:
>>
>>       >NOTE: Executing RunQueue Tasks
>>       >NOTE: Running task 1341 of 1710 (ID: 513,
>>       >/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb,
>>        >do_validate_branches)
>>       >NOTE: package
>>       >linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2: task
>>       >do_validate_branches: Started
>>       >ERROR: Function 'do_validate_branches' failed (see
>>       >/home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/temp/log.do_validate_branches.16792
>>        >for further information)
>>
>>
>>       >please tell me what we have done wrong?.
>>       >is there anything else we need to modify in .bbappend file or some other
>>       >variable?.
>>
>>> Which release are you using again ?
>>     I am using 6.0.0 Edision
>>
>>> The diagnostics out of validate branches are about to get better in master,
>>> but they are coupled with some other tools changes that couldn't go
>>> into yocto 1.2.
>>
>>> Is there anything extra in the log file, or just what you saw on the
>>> build log ?.
>> actually I have set YOCTO_KERNEL_EXTERNAL_BRANCH ="dev";(dev is my local brach)
>> Now this Error has gone and now I am getting
>>
>> ERROR: Function 'do_patch' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008 for further information)
>> ERROR: Logfile of failure stored in: /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008
>> Log data follows:
>> | ERROR. meta data not found, check upstream repo for tags and branches
>> | ERROR: Function 'do_patch' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008 for further information)
>> NOTE: package linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3: task do_patch: Failed
>> ERROR: Task 516 (/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_patch) failed with exit code '1'
>> ERROR: '/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb' failed
>>
>
> This is what I was saying a few weeks ago. If you aren't using
> the linux-yocto kernel repository (and hence linux-yocto branches/meta
> data) as your base, then building directly via the linux-yocto recipe
> probably isn't what you want. It is a recipe that leverages the tools
> and infrastructure on top of the linux-yocto repository.
>
> That same infrastructure can build other repositories, but needs some
> extra variables set. The meta-kernel-dev layer, in poky-extras has
> examples of this for building korg (or any repo) with the tools.
>
> What you re being told in this particular error is that you don't have
> a meta branch in the tree, or not one that the tools can recognize.
> You can prevent this by setting YOCTO_KERNEL_META_DATA="" in your
> recipe (see the korg recipe as an example). (and FYI: this will no
> longer be required in 1.3, but it is for any previous release.
>>
>>> Validate branches fails like this when you've provided a bad branch or
>>> SRCREV (vs a SRCREV that is simply not the tip of the branch .. it fixes
>>> hat scenario) and the fetcher or another git command aborts.
>>
>>> You've output some example text from the bbappend, but what were the real
>>> values in your situation ? i.e. what are KMACHINE/KBRANCH set to ?.
>>
>> I have not set the value of KBRANCH?. what it should be ?.
>
> It needs to be a valid branch in the repository. The 1.2 recipes
> set it to be KMACHINE if it hasn't been explicitly set. But it
> sounds like you are past this, and have set your branch to something
> that actually exists in the tree.
>
> Cheers,
>
> Bruce
>
>>
>>> There are some flags you can set to exit the branch validation early, but
>>> I don't think setting them is the right course of action yet, since the
>>> error you are seeing is likely hiding some other mis configuration.
>>
>>> Cheers,
>>
>>> Bruce
>>
>> Best Regards,
>> Om Prakash Pal
>> ________________________________________
>> From: Om Prakash PAL
>> Sent: Sunday, April 29, 2012 3:28 PM
>> To: Bruce Ashfield
>> Cc: yocto@yoctoproject.org
>> Subject: RE: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> Hi Bruce,
>> for porting of our local kernel,we have created an BSP layer and to change the the kernel,  we have created an linux-yocto_3.0.bbappend file inside meta<BSP>/recipes-kernel/linux/
>> like this:-
>>
>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>
>> COMPATIBLE_MACHINE_<BSP_name>   = "BSP_name"
>>
>> # KMACHINE is the branch to build
>> KMACHINE_<BSP_name>   = "local_branch"
>>
>> SRCREV_machine_pn_linux-yocto_<BSP_name>   ?= "XXXXXXXX" (here we have assign top commit ID of our local kernel)
>>
>>
>> # KSRC_linux_yocto to point to your local clone as appropriate.
>> KSRC_linux_yocto ?= "/path/to/local/kernel"
>>
>> SRC_URI = "git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH};name=machine \
>>                   file://defconfig"
>>
>>
>> KERNEL_REVISION_CHECKING=""
>> SRCREV="${AUTOREV}"
>> #BB_LOCALCOUNT_OVERRIDE = "1"
>> LOCALCOUNT = "0"
>>
>>
>> while building we are getting following Error:
>>
>> NOTE: Executing RunQueue Tasks
>> NOTE: Running task 1341 of 1710 (ID: 513, /home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_validate_branches)
>> NOTE: package linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2: task do_validate_branches: Started
>> ERROR: Function 'do_validate_branches' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/temp/log.do_validate_branches.16792 for further information)
>>
>>
>> please tell me what we have done wrong?.
>> is there anything else we need to modify in .bbappend file or some other variable?.
>>
>> Best Regards,
>> Om Prakash Pal
>> ________________________________________
>> From: Bruce Ashfield [bruce.ashfield@gmail.com]
>> Sent: Monday, April 09, 2012 11:04 PM
>> To: Om Prakash PAL
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> On Mon, Apr 9, 2012 at 12:31 PM, Om Prakash PAL
>> <omprakash.pal@stericsson.com>   wrote:
>>> Hi Bruce,
>>> Thanks for you help.
>>> As you have mentioned, its working properly.
>>> I want to know that is there any better way of doing same thing for my scenario ?:
>>> here is my scenario:
>>> We have development branch where we write/modify our kernel/driver code i.e. thats our local kernel repository(git rep)
>>> and lots of driver/files being modified everyday-->so I have to take the same effect into yocto kernel also---->   so except  creating patches for all modified drivers and creating .bbappend files, is there any better way of doing same thing .
>>
>> Aha. Missed that.
>>
>> Just create a simple recipe that points at your git repository in the SRC_URI.
>> If all the changes are in the tree, and you have a defconfig and you
>> are building
>> the master branch. Then pretty much everything you need can be specified in
>> the SRC_URI .. and that's the entire recipe.
>>
>> If you look in oe-classic, meta-ti or any one of a number of other
>> layers, you'll
>> find recipes that do just that.
>>
>> The meta-kernel-dev (in the poky extras) layer has an example of using the
>> kernel.org tree with the yocto kern tools, and once yocto 1.3 opens up for
>> submissions, I have a set of changes prep'd that make it relatively simple to
>> use the yocto kern tools against different types of repository.
>>
>> So the summary is: Depending on the type of tooling you need, and what baseline
>> you need for your work .. there are a number of ways to do things.
>>
>>>
>>> Is there anyway that  instead of using yocto-kernel tree,  can we use our local kernel-tree for building images?. (should  I create separate BSP ?)
>>
>> You should definitely create a BSP, that way you can tune the system specific
>> to your board,
>>
>> Cheers,
>>
>> Bruce
>>
>>>
>>> Thanks in advance.
>>> Best Regards,
>>> Om Prakash Pal
>>> ________________________________________
>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>> Sent: Monday, April 09, 2012 9:32 AM
>>> To: Om Prakash PAL
>>> Cc: yocto@yoctoproject.org
>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>
>>> On 12-04-08 10:04 AM, Om Prakash PAL wrote:
>>>> Hi Bruce,
>>>> Thanks for your reply.
>>>> I am totally new to Yocto.
>>>> I have gone through the section BSP/Linux kernel configuration and if I am not wrong then it explains how can we configure the kernel, not the how we can add/replace a  component(driver etc).
>>>> lets take the example of UART driver, I want to add my own UART driver code.
>>>> Should I write a separate recipe file (.bb) for UART Driver?.
>>>> if yes then I have to write the recipe files for all my drivers that will be very time consuming.
>>>> Is there any other way that I can port all my desired drivers into Yocto kernel?.
>>>
>>> No recipes are required per-driver, unless you are building them all
>>> as out of tree modules.
>>>
>>> The typical way this is done is to simply work in the extracted linux
>>> src tree (build/tmp/work/<your board>/linux-yocto-<hashes>/linux), manually
>>> patch, or copy your drivers into the tree. At this point, you'll port
>>> the drivers, doing test builds (bitbake -f -c compile linux-yocto) to
>>> ensure that your port is working. When you've completed the build phase,
>>> boot tests would be in order. (Do not do a 'clean' or you'll lose in
>>> progress changes).
>>>
>>> When you are happy with the changes, the directory where you were working
>>> is with the kernel git repository. So you can simply commit your
>>> changes, and generate patches.
>>>
>>>      git format-patch -o<your directory>   HEAD^ (or however many commits
>>> you have)
>>>
>>> Take those patches, create a layer with a bbappend and add them like
>>> any other patch to any package. They'll be applied to subsequent builds
>>> of the kernel.
>>>
>>> I'm skipping a lot of detail there, but it is all found in the various
>>> manuals, and I don't want to repeat it here.
>>>
>>> Cheers,
>>>
>>> Bruce
>>>
>>>> Please help me.
>>>> Thanks a lot in advance.
>>>>
>>>> Best Regards,
>>>> Om Prakash Pal
>>>> ________________________________________
>>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>>> Sent: Wednesday, April 04, 2012 6:17 PM
>>>> To: Om Prakash PAL
>>>> Cc: yocto@yoctoproject.org
>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>
>>>> On 12-04-04 04:46 AM, Om Prakash PAL wrote:
>>>>> Hi,
>>>>> I want to build my local kernel/Driver code, not the default one.
>>>>> please help how can i do it ?.
>>>>> any wiki/docs on this?.
>>>>
>>>> The BSP developer guides show how to extend the yocto kernels, and
>>>> also have sections on custom/different kernel versions. Have you
>>>> seen that doc yet ? Or have you seen it, and have specific questions ?
>>>>
>>>> Bruce
>>>>
>>>>>
>>>>> Best Regards,
>>>>> Om Prakash Pal
>>>>> _______________________________________________
>>>>> yocto mailing list
>>>>> yocto@yoctoproject.org
>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>
>>>
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>>
>> --
>> "Thou shalt not follow the NULL pointer, for chaos and madness await
>> thee at its end"
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>

Re: Porting of specific Kernel/Driver into yocto.

[Bruce Ashfield]

On 12-05-06 5:43 AM, Om Prakash PAL wrote:
> Hi Bruce,
> I am getting some problem in do_install:
>
> NOTE: Running task 1535 of 1710 (ID: 517, /home/apallan/yocto/poky-edison-6.0/meta-u8500/recipes-kernel/linux/linux-u8500.bb, do_install)
> NOTE: package linux-u8500-3.2+git1+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r10: task do_install: Started
>
> and I waited for ~15hr to complete task do_install: but not completed and i am not getting any Errors/warnings.
> Is there any problem?.
> I have checked that my vmlinux/uImage/zImage has been created successfully but rootfs has not been created till now.
>
> here is my .bb file that is building my local_kernel.
>
> inherit kernel
> require recipes-kernel/linux/linux-yocto.inc
>
> KMACHINE = "dev"
> YOCTO_KERNEL_EXTERNAL_BRANCH ?= "dev"
>
> KBRANCH = "${KMACHINE}"
> KMETA = "meta"
>
> KSRC_linux_yocto ?= "/home/apallan/yocto/kernel/"
>
> SRC_URI = "git://${KSRC_linux_yocto};protocol=file;nocheckout=1"
> SRC_URI +="file://defconfig"
>
> SRCREV="${AUTOREV}"
> SRCREV_pn-linux-u8500 ="0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383"
>
> LINUX_VERSION ?= "3.2"
> LINUX_VERSION_EXTENSION = "-yoctized-${LINUX_KERNEL_TYPE}"
> PR = "r10"
> PV = "${LINUX_VERSION}+git${SRCPV}"
>
> COMPATIBLE_MACHINE = "(u8500|qemuarm)"
>
> # Functionality flags
> KERNEL_REVISION_CHECKING=""
> YOCTO_KERNEL_META_DATA=""
>
> require recipes-kernel/linux/linux-tools.inc
>
> what should be the problem?.

Anything using linux-yocto has exactly the same packaging semantics as
other kernels, since they all inherit kernel.bbclass.

Maybe your description sounds familiar to others, and others that might
have better ideas about what's happening in the packaging backend ?

You don't have any special partitions configured ? You are building
on a local filesystem ? Is rpm or ipkg being used ? .. these are all
things that could impact performance (but not really 15 hours worth of
issues).

Are there any hints in the host system logs, or in the kernels do_install
log ?

Bruce

>
> Best Regards,
> Om Prakash Pal
> ________________________________________
> From: Bruce Ashfield [bruce.ashfield@windriver.com]
> Sent: Thursday, May 03, 2012 5:59 PM
> To: Om Prakash PAL
> Cc: Bruce Ashfield; yocto@yoctoproject.org
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>
> On 12-05-03 05:24 AM, Om Prakash PAL wrote:
>> Hi Bruce,
>> Thanks a lot for your help.
>> Now I am able to build the local kernel.
>
> Great!
>
>> I have one doublt:
>> when I do
>> bitbake -c mencuconfig virtual/kernel
>>
>> then from which location it will take the config file?.
>> and if I want to buiild my own specific defconfig file then How can do it?.
>
> It will use the .config in the build directory ${B}, which if you
> are using a linux-yocto recipe would be your
> linux-$MACHINE-$KERNELTYPE-build
> directory.
>
> The dependencies of menuconfig will ensure that the kernel has been fetched,
> unpacked and configured before it runs. Which means a defconfig will
> have already been used (if specified) to construct the .config.
>
> Any changes you make will be saved in the .config, and you'll need to
> preserve that for future builds.
>
> Cheers,
>
> Bruce
>
>>
>> Best Regards,
>> Om Prakash Pal
>> ________________________________________
>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>> Sent: Monday, April 30, 2012 7:42 PM
>> To: Om Prakash PAL
>> Cc: Bruce Ashfield; yocto@yoctoproject.org
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> On 12-04-30 6:34 AM, Om Prakash PAL wrote:
>>>> On 12-04-29 5:58 AM, Om Prakash PAL wrote:
>>>
>>>       >    Hi Bruce,
>>>        >for porting of our local kernel,we have created an BSP layer and to change the the
>>>        >kernel,  we have created an linux-yocto_3.0.bbappend file inside
>>>        >meta<BSP>/recipes-kernel/linux/
>>>        >like this:-
>>>
>>>        >FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>>
>>>       >    COMPATIBLE_MACHINE_<BSP_name>     = "BSP_name"
>>>
>>>        ># KMACHINE is the branch to build
>>>        >KMACHINE_<BSP_name>     = "local_branch"
>>>
>>>       >    SRCREV_machine_pn_linux-yocto_<BSP_name>     ?= "XXXXXXXX" (here we have assign
>>>        >top commit ID of our local kernel)
>>>
>>>
>>>        ># KSRC_linux_yocto to point to your local clone as appropriate.
>>>        >KSRC_linux_yocto ?= "/path/to/local/kernel"
>>>
>>>        >SRC_URI =
>>>        >"git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH};name=machine
>>>         >\
>>>           >                 file://defconfig"
>>>
>>>
>>>        >KERNEL_REVISION_CHECKING=""
>>>        >SRCREV="${AUTOREV}"
>>>        >#BB_LOCALCOUNT_OVERRIDE = "1"
>>>        >LOCALCOUNT = "0"
>>>
>>>
>>>        >while building we are getting following Error:
>>>
>>>        >NOTE: Executing RunQueue Tasks
>>>        >NOTE: Running task 1341 of 1710 (ID: 513,
>>>        >/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb,
>>>         >do_validate_branches)
>>>        >NOTE: package
>>>        >linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2: task
>>>        >do_validate_branches: Started
>>>        >ERROR: Function 'do_validate_branches' failed (see
>>>        >/home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/temp/log.do_validate_branches.16792
>>>         >for further information)
>>>
>>>
>>>        >please tell me what we have done wrong?.
>>>        >is there anything else we need to modify in .bbappend file or some other
>>>        >variable?.
>>>
>>>> Which release are you using again ?
>>>      I am using 6.0.0 Edision
>>>
>>>> The diagnostics out of validate branches are about to get better in master,
>>>> but they are coupled with some other tools changes that couldn't go
>>>> into yocto 1.2.
>>>
>>>> Is there anything extra in the log file, or just what you saw on the
>>>> build log ?.
>>> actually I have set YOCTO_KERNEL_EXTERNAL_BRANCH ="dev";(dev is my local brach)
>>> Now this Error has gone and now I am getting
>>>
>>> ERROR: Function 'do_patch' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008 for further information)
>>> ERROR: Logfile of failure stored in: /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008
>>> Log data follows:
>>> | ERROR. meta data not found, check upstream repo for tags and branches
>>> | ERROR: Function 'do_patch' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008 for further information)
>>> NOTE: package linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3: task do_patch: Failed
>>> ERROR: Task 516 (/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_patch) failed with exit code '1'
>>> ERROR: '/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb' failed
>>>
>>
>> This is what I was saying a few weeks ago. If you aren't using
>> the linux-yocto kernel repository (and hence linux-yocto branches/meta
>> data) as your base, then building directly via the linux-yocto recipe
>> probably isn't what you want. It is a recipe that leverages the tools
>> and infrastructure on top of the linux-yocto repository.
>>
>> That same infrastructure can build other repositories, but needs some
>> extra variables set. The meta-kernel-dev layer, in poky-extras has
>> examples of this for building korg (or any repo) with the tools.
>>
>> What you re being told in this particular error is that you don't have
>> a meta branch in the tree, or not one that the tools can recognize.
>> You can prevent this by setting YOCTO_KERNEL_META_DATA="" in your
>> recipe (see the korg recipe as an example). (and FYI: this will no
>> longer be required in 1.3, but it is for any previous release.
>>>
>>>> Validate branches fails like this when you've provided a bad branch or
>>>> SRCREV (vs a SRCREV that is simply not the tip of the branch .. it fixes
>>>> hat scenario) and the fetcher or another git command aborts.
>>>
>>>> You've output some example text from the bbappend, but what were the real
>>>> values in your situation ? i.e. what are KMACHINE/KBRANCH set to ?.
>>>
>>> I have not set the value of KBRANCH?. what it should be ?.
>>
>> It needs to be a valid branch in the repository. The 1.2 recipes
>> set it to be KMACHINE if it hasn't been explicitly set. But it
>> sounds like you are past this, and have set your branch to something
>> that actually exists in the tree.
>>
>> Cheers,
>>
>> Bruce
>>
>>>
>>>> There are some flags you can set to exit the branch validation early, but
>>>> I don't think setting them is the right course of action yet, since the
>>>> error you are seeing is likely hiding some other mis configuration.
>>>
>>>> Cheers,
>>>
>>>> Bruce
>>>
>>> Best Regards,
>>> Om Prakash Pal
>>> ________________________________________
>>> From: Om Prakash PAL
>>> Sent: Sunday, April 29, 2012 3:28 PM
>>> To: Bruce Ashfield
>>> Cc: yocto@yoctoproject.org
>>> Subject: RE: [yocto] Porting of specific Kernel/Driver into yocto.
>>>
>>> Hi Bruce,
>>> for porting of our local kernel,we have created an BSP layer and to change the the kernel,  we have created an linux-yocto_3.0.bbappend file inside meta<BSP>/recipes-kernel/linux/
>>> like this:-
>>>
>>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>>
>>> COMPATIBLE_MACHINE_<BSP_name>    = "BSP_name"
>>>
>>> # KMACHINE is the branch to build
>>> KMACHINE_<BSP_name>    = "local_branch"
>>>
>>> SRCREV_machine_pn_linux-yocto_<BSP_name>    ?= "XXXXXXXX" (here we have assign top commit ID of our local kernel)
>>>
>>>
>>> # KSRC_linux_yocto to point to your local clone as appropriate.
>>> KSRC_linux_yocto ?= "/path/to/local/kernel"
>>>
>>> SRC_URI = "git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH};name=machine \
>>>                    file://defconfig"
>>>
>>>
>>> KERNEL_REVISION_CHECKING=""
>>> SRCREV="${AUTOREV}"
>>> #BB_LOCALCOUNT_OVERRIDE = "1"
>>> LOCALCOUNT = "0"
>>>
>>>
>>> while building we are getting following Error:
>>>
>>> NOTE: Executing RunQueue Tasks
>>> NOTE: Running task 1341 of 1710 (ID: 513, /home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_validate_branches)
>>> NOTE: package linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2: task do_validate_branches: Started
>>> ERROR: Function 'do_validate_branches' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/temp/log.do_validate_branches.16792 for further information)
>>>
>>>
>>> please tell me what we have done wrong?.
>>> is there anything else we need to modify in .bbappend file or some other variable?.
>>>
>>> Best Regards,
>>> Om Prakash Pal
>>> ________________________________________
>>> From: Bruce Ashfield [bruce.ashfield@gmail.com]
>>> Sent: Monday, April 09, 2012 11:04 PM
>>> To: Om Prakash PAL
>>> Cc: yocto@yoctoproject.org
>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>
>>> On Mon, Apr 9, 2012 at 12:31 PM, Om Prakash PAL
>>> <omprakash.pal@stericsson.com>    wrote:
>>>> Hi Bruce,
>>>> Thanks for you help.
>>>> As you have mentioned, its working properly.
>>>> I want to know that is there any better way of doing same thing for my scenario ?:
>>>> here is my scenario:
>>>> We have development branch where we write/modify our kernel/driver code i.e. thats our local kernel repository(git rep)
>>>> and lots of driver/files being modified everyday-->so I have to take the same effect into yocto kernel also---->    so except  creating patches for all modified drivers and creating .bbappend files, is there any better way of doing same thing .
>>>
>>> Aha. Missed that.
>>>
>>> Just create a simple recipe that points at your git repository in the SRC_URI.
>>> If all the changes are in the tree, and you have a defconfig and you
>>> are building
>>> the master branch. Then pretty much everything you need can be specified in
>>> the SRC_URI .. and that's the entire recipe.
>>>
>>> If you look in oe-classic, meta-ti or any one of a number of other
>>> layers, you'll
>>> find recipes that do just that.
>>>
>>> The meta-kernel-dev (in the poky extras) layer has an example of using the
>>> kernel.org tree with the yocto kern tools, and once yocto 1.3 opens up for
>>> submissions, I have a set of changes prep'd that make it relatively simple to
>>> use the yocto kern tools against different types of repository.
>>>
>>> So the summary is: Depending on the type of tooling you need, and what baseline
>>> you need for your work .. there are a number of ways to do things.
>>>
>>>>
>>>> Is there anyway that  instead of using yocto-kernel tree,  can we use our local kernel-tree for building images?. (should  I create separate BSP ?)
>>>
>>> You should definitely create a BSP, that way you can tune the system specific
>>> to your board,
>>>
>>> Cheers,
>>>
>>> Bruce
>>>
>>>>
>>>> Thanks in advance.
>>>> Best Regards,
>>>> Om Prakash Pal
>>>> ________________________________________
>>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>>> Sent: Monday, April 09, 2012 9:32 AM
>>>> To: Om Prakash PAL
>>>> Cc: yocto@yoctoproject.org
>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>
>>>> On 12-04-08 10:04 AM, Om Prakash PAL wrote:
>>>>> Hi Bruce,
>>>>> Thanks for your reply.
>>>>> I am totally new to Yocto.
>>>>> I have gone through the section BSP/Linux kernel configuration and if I am not wrong then it explains how can we configure the kernel, not the how we can add/replace a  component(driver etc).
>>>>> lets take the example of UART driver, I want to add my own UART driver code.
>>>>> Should I write a separate recipe file (.bb) for UART Driver?.
>>>>> if yes then I have to write the recipe files for all my drivers that will be very time consuming.
>>>>> Is there any other way that I can port all my desired drivers into Yocto kernel?.
>>>>
>>>> No recipes are required per-driver, unless you are building them all
>>>> as out of tree modules.
>>>>
>>>> The typical way this is done is to simply work in the extracted linux
>>>> src tree (build/tmp/work/<your board>/linux-yocto-<hashes>/linux), manually
>>>> patch, or copy your drivers into the tree. At this point, you'll port
>>>> the drivers, doing test builds (bitbake -f -c compile linux-yocto) to
>>>> ensure that your port is working. When you've completed the build phase,
>>>> boot tests would be in order. (Do not do a 'clean' or you'll lose in
>>>> progress changes).
>>>>
>>>> When you are happy with the changes, the directory where you were working
>>>> is with the kernel git repository. So you can simply commit your
>>>> changes, and generate patches.
>>>>
>>>>       git format-patch -o<your directory>    HEAD^ (or however many commits
>>>> you have)
>>>>
>>>> Take those patches, create a layer with a bbappend and add them like
>>>> any other patch to any package. They'll be applied to subsequent builds
>>>> of the kernel.
>>>>
>>>> I'm skipping a lot of detail there, but it is all found in the various
>>>> manuals, and I don't want to repeat it here.
>>>>
>>>> Cheers,
>>>>
>>>> Bruce
>>>>
>>>>> Please help me.
>>>>> Thanks a lot in advance.
>>>>>
>>>>> Best Regards,
>>>>> Om Prakash Pal
>>>>> ________________________________________
>>>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>>>> Sent: Wednesday, April 04, 2012 6:17 PM
>>>>> To: Om Prakash PAL
>>>>> Cc: yocto@yoctoproject.org
>>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>>
>>>>> On 12-04-04 04:46 AM, Om Prakash PAL wrote:
>>>>>> Hi,
>>>>>> I want to build my local kernel/Driver code, not the default one.
>>>>>> please help how can i do it ?.
>>>>>> any wiki/docs on this?.
>>>>>
>>>>> The BSP developer guides show how to extend the yocto kernels, and
>>>>> also have sections on custom/different kernel versions. Have you
>>>>> seen that doc yet ? Or have you seen it, and have specific questions ?
>>>>>
>>>>> Bruce
>>>>>
>>>>>>
>>>>>> Best Regards,
>>>>>> Om Prakash Pal
>>>>>> _______________________________________________
>>>>>> yocto mailing list
>>>>>> yocto@yoctoproject.org
>>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>>
>>>>
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>>
>>>
>>> --
>>> "Thou shalt not follow the NULL pointer, for chaos and madness await
>>> thee at its end"
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>

Re: Porting of specific Kernel/Driver into yocto.

[Om Prakash PAL]

Hi Bruce,

[ I am using "poky-edison-6.0" ]
I am able to create my rootfs and uImage but when I flashed these on my board,
while booting I am getting below Error and console get blocked.

=========================================================
[    3.575805] EXT3-fs (mmcblk0p1): using internal journal
[    3.581054] EXT3-fs (mmcblk0p1): mounted filesystem with writeback data mode
[    3.588165] VFS: Mounted root (ext3 filesystem) on device 179:1.
[    3.594268] Freeing init memory: 312K
INIT: version 2.88 booting

Please wait: booting...
Starting udev
Starting Bootlog daemon: bootlogd: cannot deduce real console device
bootlogd.
Configuring network interfaces... ifconfig: SIOCGIFFLAGS: No such device
done.
Fri May 11 11:29:00 UTC 2012
Running postinst /etc/rpm-postinsts/*.sh...
ERROR: postinst /etc/rpm-postinsts/*.sh failed.
INIT: Entering runlevel: 5
Starting syslogd/klogd: done
Stopping Bootlog daemon: bootlogd.
[    9.737091] av8100_hdmi av8100_hdmi.3: HDMI display probed

=========================================================
and after that it got stuck, I am not getting console.

I am building rootfs/uImage with default toolchain used in yocto.
Is it problem of toolchain?.
Should I build with our toolchain( we use CodeSourcery)?.

Best Regards,
Om Prakash Pal
________________________________________
From: Bruce Ashfield [bruce.ashfield@windriver.com]
Sent: Sunday, May 06, 2012 6:00 PM
To: Om Prakash PAL
Cc: Bruce Ashfield; yocto@yoctoproject.org; Richard Purdie
Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.

On 12-05-06 5:43 AM, Om Prakash PAL wrote:
> Hi Bruce,
> I am getting some problem in do_install:
>
> NOTE: Running task 1535 of 1710 (ID: 517, /home/apallan/yocto/poky-edison-6.0/meta-u8500/recipes-kernel/linux/linux-u8500.bb, do_install)
> NOTE: package linux-u8500-3.2+git1+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r10: task do_install: Started
>
> and I waited for ~15hr to complete task do_install: but not completed and i am not getting any Errors/warnings.
> Is there any problem?.
> I have checked that my vmlinux/uImage/zImage has been created successfully but rootfs has not been created till now.
>
> here is my .bb file that is building my local_kernel.
>
> inherit kernel
> require recipes-kernel/linux/linux-yocto.inc
>
> KMACHINE = "dev"
> YOCTO_KERNEL_EXTERNAL_BRANCH ?= "dev"
>
> KBRANCH = "${KMACHINE}"
> KMETA = "meta"
>
> KSRC_linux_yocto ?= "/home/apallan/yocto/kernel/"
>
> SRC_URI = "git://${KSRC_linux_yocto};protocol=file;nocheckout=1"
> SRC_URI +="file://defconfig"
>
> SRCREV="${AUTOREV}"
> SRCREV_pn-linux-u8500 ="0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383"
>
> LINUX_VERSION ?= "3.2"
> LINUX_VERSION_EXTENSION = "-yoctized-${LINUX_KERNEL_TYPE}"
> PR = "r10"
> PV = "${LINUX_VERSION}+git${SRCPV}"
>
> COMPATIBLE_MACHINE = "(u8500|qemuarm)"
>
> # Functionality flags
> KERNEL_REVISION_CHECKING=""
> YOCTO_KERNEL_META_DATA=""
>
> require recipes-kernel/linux/linux-tools.inc
>
> what should be the problem?.

Anything using linux-yocto has exactly the same packaging semantics as
other kernels, since they all inherit kernel.bbclass.

Maybe your description sounds familiar to others, and others that might
have better ideas about what's happening in the packaging backend ?

You don't have any special partitions configured ? You are building
on a local filesystem ? Is rpm or ipkg being used ? .. these are all
things that could impact performance (but not really 15 hours worth of
issues).

Are there any hints in the host system logs, or in the kernels do_install
log ?

Bruce

>
> Best Regards,
> Om Prakash Pal
> ________________________________________
> From: Bruce Ashfield [bruce.ashfield@windriver.com]
> Sent: Thursday, May 03, 2012 5:59 PM
> To: Om Prakash PAL
> Cc: Bruce Ashfield; yocto@yoctoproject.org
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>
> On 12-05-03 05:24 AM, Om Prakash PAL wrote:
>> Hi Bruce,
>> Thanks a lot for your help.
>> Now I am able to build the local kernel.
>
> Great!
>
>> I have one doublt:
>> when I do
>> bitbake -c mencuconfig virtual/kernel
>>
>> then from which location it will take the config file?.
>> and if I want to buiild my own specific defconfig file then How can do it?.
>
> It will use the .config in the build directory ${B}, which if you
> are using a linux-yocto recipe would be your
> linux-$MACHINE-$KERNELTYPE-build
> directory.
>
> The dependencies of menuconfig will ensure that the kernel has been fetched,
> unpacked and configured before it runs. Which means a defconfig will
> have already been used (if specified) to construct the .config.
>
> Any changes you make will be saved in the .config, and you'll need to
> preserve that for future builds.
>
> Cheers,
>
> Bruce
>
>>
>> Best Regards,
>> Om Prakash Pal
>> ________________________________________
>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>> Sent: Monday, April 30, 2012 7:42 PM
>> To: Om Prakash PAL
>> Cc: Bruce Ashfield; yocto@yoctoproject.org
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> On 12-04-30 6:34 AM, Om Prakash PAL wrote:
>>>> On 12-04-29 5:58 AM, Om Prakash PAL wrote:
>>>
>>>       >    Hi Bruce,
>>>        >for porting of our local kernel,we have created an BSP layer and to change the the
>>>        >kernel,  we have created an linux-yocto_3.0.bbappend file inside
>>>        >meta<BSP>/recipes-kernel/linux/
>>>        >like this:-
>>>
>>>        >FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>>
>>>       >    COMPATIBLE_MACHINE_<BSP_name>     = "BSP_name"
>>>
>>>        ># KMACHINE is the branch to build
>>>        >KMACHINE_<BSP_name>     = "local_branch"
>>>
>>>       >    SRCREV_machine_pn_linux-yocto_<BSP_name>     ?= "XXXXXXXX" (here we have assign
>>>        >top commit ID of our local kernel)
>>>
>>>
>>>        ># KSRC_linux_yocto to point to your local clone as appropriate.
>>>        >KSRC_linux_yocto ?= "/path/to/local/kernel"
>>>
>>>        >SRC_URI =
>>>        >"git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH};name=machine
>>>         >\
>>>           >                 file://defconfig"
>>>
>>>
>>>        >KERNEL_REVISION_CHECKING=""
>>>        >SRCREV="${AUTOREV}"
>>>        >#BB_LOCALCOUNT_OVERRIDE = "1"
>>>        >LOCALCOUNT = "0"
>>>
>>>
>>>        >while building we are getting following Error:
>>>
>>>        >NOTE: Executing RunQueue Tasks
>>>        >NOTE: Running task 1341 of 1710 (ID: 513,
>>>        >/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb,
>>>         >do_validate_branches)
>>>        >NOTE: package
>>>        >linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2: task
>>>        >do_validate_branches: Started
>>>        >ERROR: Function 'do_validate_branches' failed (see
>>>        >/home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/temp/log.do_validate_branches.16792
>>>         >for further information)
>>>
>>>
>>>        >please tell me what we have done wrong?.
>>>        >is there anything else we need to modify in .bbappend file or some other
>>>        >variable?.
>>>
>>>> Which release are you using again ?
>>>      I am using 6.0.0 Edision
>>>
>>>> The diagnostics out of validate branches are about to get better in master,
>>>> but they are coupled with some other tools changes that couldn't go
>>>> into yocto 1.2.
>>>
>>>> Is there anything extra in the log file, or just what you saw on the
>>>> build log ?.
>>> actually I have set YOCTO_KERNEL_EXTERNAL_BRANCH ="dev";(dev is my local brach)
>>> Now this Error has gone and now I am getting
>>>
>>> ERROR: Function 'do_patch' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008 for further information)
>>> ERROR: Logfile of failure stored in: /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008
>>> Log data follows:
>>> | ERROR. meta data not found, check upstream repo for tags and branches
>>> | ERROR: Function 'do_patch' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008 for further information)
>>> NOTE: package linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3: task do_patch: Failed
>>> ERROR: Task 516 (/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_patch) failed with exit code '1'
>>> ERROR: '/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb' failed
>>>
>>
>> This is what I was saying a few weeks ago. If you aren't using
>> the linux-yocto kernel repository (and hence linux-yocto branches/meta
>> data) as your base, then building directly via the linux-yocto recipe
>> probably isn't what you want. It is a recipe that leverages the tools
>> and infrastructure on top of the linux-yocto repository.
>>
>> That same infrastructure can build other repositories, but needs some
>> extra variables set. The meta-kernel-dev layer, in poky-extras has
>> examples of this for building korg (or any repo) with the tools.
>>
>> What you re being told in this particular error is that you don't have
>> a meta branch in the tree, or not one that the tools can recognize.
>> You can prevent this by setting YOCTO_KERNEL_META_DATA="" in your
>> recipe (see the korg recipe as an example). (and FYI: this will no
>> longer be required in 1.3, but it is for any previous release.
>>>
>>>> Validate branches fails like this when you've provided a bad branch or
>>>> SRCREV (vs a SRCREV that is simply not the tip of the branch .. it fixes
>>>> hat scenario) and the fetcher or another git command aborts.
>>>
>>>> You've output some example text from the bbappend, but what were the real
>>>> values in your situation ? i.e. what are KMACHINE/KBRANCH set to ?.
>>>
>>> I have not set the value of KBRANCH?. what it should be ?.
>>
>> It needs to be a valid branch in the repository. The 1.2 recipes
>> set it to be KMACHINE if it hasn't been explicitly set. But it
>> sounds like you are past this, and have set your branch to something
>> that actually exists in the tree.
>>
>> Cheers,
>>
>> Bruce
>>
>>>
>>>> There are some flags you can set to exit the branch validation early, but
>>>> I don't think setting them is the right course of action yet, since the
>>>> error you are seeing is likely hiding some other mis configuration.
>>>
>>>> Cheers,
>>>
>>>> Bruce
>>>
>>> Best Regards,
>>> Om Prakash Pal
>>> ________________________________________
>>> From: Om Prakash PAL
>>> Sent: Sunday, April 29, 2012 3:28 PM
>>> To: Bruce Ashfield
>>> Cc: yocto@yoctoproject.org
>>> Subject: RE: [yocto] Porting of specific Kernel/Driver into yocto.
>>>
>>> Hi Bruce,
>>> for porting of our local kernel,we have created an BSP layer and to change the the kernel,  we have created an linux-yocto_3.0.bbappend file inside meta<BSP>/recipes-kernel/linux/
>>> like this:-
>>>
>>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>>
>>> COMPATIBLE_MACHINE_<BSP_name>    = "BSP_name"
>>>
>>> # KMACHINE is the branch to build
>>> KMACHINE_<BSP_name>    = "local_branch"
>>>
>>> SRCREV_machine_pn_linux-yocto_<BSP_name>    ?= "XXXXXXXX" (here we have assign top commit ID of our local kernel)
>>>
>>>
>>> # KSRC_linux_yocto to point to your local clone as appropriate.
>>> KSRC_linux_yocto ?= "/path/to/local/kernel"
>>>
>>> SRC_URI = "git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH};name=machine \
>>>                    file://defconfig"
>>>
>>>
>>> KERNEL_REVISION_CHECKING=""
>>> SRCREV="${AUTOREV}"
>>> #BB_LOCALCOUNT_OVERRIDE = "1"
>>> LOCALCOUNT = "0"
>>>
>>>
>>> while building we are getting following Error:
>>>
>>> NOTE: Executing RunQueue Tasks
>>> NOTE: Running task 1341 of 1710 (ID: 513, /home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_validate_branches)
>>> NOTE: package linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2: task do_validate_branches: Started
>>> ERROR: Function 'do_validate_branches' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/temp/log.do_validate_branches.16792 for further information)
>>>
>>>
>>> please tell me what we have done wrong?.
>>> is there anything else we need to modify in .bbappend file or some other variable?.
>>>
>>> Best Regards,
>>> Om Prakash Pal
>>> ________________________________________
>>> From: Bruce Ashfield [bruce.ashfield@gmail.com]
>>> Sent: Monday, April 09, 2012 11:04 PM
>>> To: Om Prakash PAL
>>> Cc: yocto@yoctoproject.org
>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>
>>> On Mon, Apr 9, 2012 at 12:31 PM, Om Prakash PAL
>>> <omprakash.pal@stericsson.com>    wrote:
>>>> Hi Bruce,
>>>> Thanks for you help.
>>>> As you have mentioned, its working properly.
>>>> I want to know that is there any better way of doing same thing for my scenario ?:
>>>> here is my scenario:
>>>> We have development branch where we write/modify our kernel/driver code i.e. thats our local kernel repository(git rep)
>>>> and lots of driver/files being modified everyday-->so I have to take the same effect into yocto kernel also---->    so except  creating patches for all modified drivers and creating .bbappend files, is there any better way of doing same thing .
>>>
>>> Aha. Missed that.
>>>
>>> Just create a simple recipe that points at your git repository in the SRC_URI.
>>> If all the changes are in the tree, and you have a defconfig and you
>>> are building
>>> the master branch. Then pretty much everything you need can be specified in
>>> the SRC_URI .. and that's the entire recipe.
>>>
>>> If you look in oe-classic, meta-ti or any one of a number of other
>>> layers, you'll
>>> find recipes that do just that.
>>>
>>> The meta-kernel-dev (in the poky extras) layer has an example of using the
>>> kernel.org tree with the yocto kern tools, and once yocto 1.3 opens up for
>>> submissions, I have a set of changes prep'd that make it relatively simple to
>>> use the yocto kern tools against different types of repository.
>>>
>>> So the summary is: Depending on the type of tooling you need, and what baseline
>>> you need for your work .. there are a number of ways to do things.
>>>
>>>>
>>>> Is there anyway that  instead of using yocto-kernel tree,  can we use our local kernel-tree for building images?. (should  I create separate BSP ?)
>>>
>>> You should definitely create a BSP, that way you can tune the system specific
>>> to your board,
>>>
>>> Cheers,
>>>
>>> Bruce
>>>
>>>>
>>>> Thanks in advance.
>>>> Best Regards,
>>>> Om Prakash Pal
>>>> ________________________________________
>>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>>> Sent: Monday, April 09, 2012 9:32 AM
>>>> To: Om Prakash PAL
>>>> Cc: yocto@yoctoproject.org
>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>
>>>> On 12-04-08 10:04 AM, Om Prakash PAL wrote:
>>>>> Hi Bruce,
>>>>> Thanks for your reply.
>>>>> I am totally new to Yocto.
>>>>> I have gone through the section BSP/Linux kernel configuration and if I am not wrong then it explains how can we configure the kernel, not the how we can add/replace a  component(driver etc).
>>>>> lets take the example of UART driver, I want to add my own UART driver code.
>>>>> Should I write a separate recipe file (.bb) for UART Driver?.
>>>>> if yes then I have to write the recipe files for all my drivers that will be very time consuming.
>>>>> Is there any other way that I can port all my desired drivers into Yocto kernel?.
>>>>
>>>> No recipes are required per-driver, unless you are building them all
>>>> as out of tree modules.
>>>>
>>>> The typical way this is done is to simply work in the extracted linux
>>>> src tree (build/tmp/work/<your board>/linux-yocto-<hashes>/linux), manually
>>>> patch, or copy your drivers into the tree. At this point, you'll port
>>>> the drivers, doing test builds (bitbake -f -c compile linux-yocto) to
>>>> ensure that your port is working. When you've completed the build phase,
>>>> boot tests would be in order. (Do not do a 'clean' or you'll lose in
>>>> progress changes).
>>>>
>>>> When you are happy with the changes, the directory where you were working
>>>> is with the kernel git repository. So you can simply commit your
>>>> changes, and generate patches.
>>>>
>>>>       git format-patch -o<your directory>    HEAD^ (or however many commits
>>>> you have)
>>>>
>>>> Take those patches, create a layer with a bbappend and add them like
>>>> any other patch to any package. They'll be applied to subsequent builds
>>>> of the kernel.
>>>>
>>>> I'm skipping a lot of detail there, but it is all found in the various
>>>> manuals, and I don't want to repeat it here.
>>>>
>>>> Cheers,
>>>>
>>>> Bruce
>>>>
>>>>> Please help me.
>>>>> Thanks a lot in advance.
>>>>>
>>>>> Best Regards,
>>>>> Om Prakash Pal
>>>>> ________________________________________
>>>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>>>> Sent: Wednesday, April 04, 2012 6:17 PM
>>>>> To: Om Prakash PAL
>>>>> Cc: yocto@yoctoproject.org
>>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>>
>>>>> On 12-04-04 04:46 AM, Om Prakash PAL wrote:
>>>>>> Hi,
>>>>>> I want to build my local kernel/Driver code, not the default one.
>>>>>> please help how can i do it ?.
>>>>>> any wiki/docs on this?.
>>>>>
>>>>> The BSP developer guides show how to extend the yocto kernels, and
>>>>> also have sections on custom/different kernel versions. Have you
>>>>> seen that doc yet ? Or have you seen it, and have specific questions ?
>>>>>
>>>>> Bruce
>>>>>
>>>>>>
>>>>>> Best Regards,
>>>>>> Om Prakash Pal
>>>>>> _______________________________________________
>>>>>> yocto mailing list
>>>>>> yocto@yoctoproject.org
>>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>>
>>>>
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>>
>>>
>>> --
>>> "Thou shalt not follow the NULL pointer, for chaos and madness await
>>> thee at its end"
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>

Re: Porting of specific Kernel/Driver into yocto.

[Darren Hart]

On 05/23/2012 05:39 AM, Om Prakash PAL wrote:
> Hi Bruce,
> 
> [ I am using "poky-edison-6.0" ]
> I am able to create my rootfs and uImage but when I flashed these on my board,
> while booting I am getting below Error and console get blocked.
> 
> =========================================================
> [    3.575805] EXT3-fs (mmcblk0p1): using internal journal
> [    3.581054] EXT3-fs (mmcblk0p1): mounted filesystem with writeback data mode
> [    3.588165] VFS: Mounted root (ext3 filesystem) on device 179:1.
> [    3.594268] Freeing init memory: 312K
> INIT: version 2.88 booting
> 
> Please wait: booting...
> Starting udev
> Starting Bootlog daemon: bootlogd: cannot deduce real console device
> bootlogd.
> Configuring network interfaces... ifconfig: SIOCGIFFLAGS: No such device
> done.
> Fri May 11 11:29:00 UTC 2012
> Running postinst /etc/rpm-postinsts/*.sh...
> ERROR: postinst /etc/rpm-postinsts/*.sh failed.

Does this error repeat if you reboot?

> INIT: Entering runlevel: 5
> Starting syslogd/klogd: done
> Stopping Bootlog daemon: bootlogd.
> [    9.737091] av8100_hdmi av8100_hdmi.3: HDMI display probed
> 
> =========================================================
> and after that it got stuck, I am not getting console.

How long do you let it sit?

> 
> I am building rootfs/uImage with default toolchain used in yocto.
> Is it problem of toolchain?.
> Should I build with our toolchain( we use CodeSourcery)?.

Nothing above suggests a toolchain problem. You have an error running
the postinst scripts from the various rpm packages. Some instrumentation
in those scripts (and the parent script) would help narrow down where it
is failing.

--
Darren

> 
> Best Regards,
> Om Prakash Pal
> ________________________________________
> From: Bruce Ashfield [bruce.ashfield@windriver.com]
> Sent: Sunday, May 06, 2012 6:00 PM
> To: Om Prakash PAL
> Cc: Bruce Ashfield; yocto@yoctoproject.org; Richard Purdie
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
> 
> On 12-05-06 5:43 AM, Om Prakash PAL wrote:
>> Hi Bruce,
>> I am getting some problem in do_install:
>>
>> NOTE: Running task 1535 of 1710 (ID: 517, /home/apallan/yocto/poky-edison-6.0/meta-u8500/recipes-kernel/linux/linux-u8500.bb, do_install)
>> NOTE: package linux-u8500-3.2+git1+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r10: task do_install: Started
>>
>> and I waited for ~15hr to complete task do_install: but not completed and i am not getting any Errors/warnings.
>> Is there any problem?.
>> I have checked that my vmlinux/uImage/zImage has been created successfully but rootfs has not been created till now.
>>
>> here is my .bb file that is building my local_kernel.
>>
>> inherit kernel
>> require recipes-kernel/linux/linux-yocto.inc
>>
>> KMACHINE = "dev"
>> YOCTO_KERNEL_EXTERNAL_BRANCH ?= "dev"
>>
>> KBRANCH = "${KMACHINE}"
>> KMETA = "meta"
>>
>> KSRC_linux_yocto ?= "/home/apallan/yocto/kernel/"
>>
>> SRC_URI = "git://${KSRC_linux_yocto};protocol=file;nocheckout=1"
>> SRC_URI +="file://defconfig"
>>
>> SRCREV="${AUTOREV}"
>> SRCREV_pn-linux-u8500 ="0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383"
>>
>> LINUX_VERSION ?= "3.2"
>> LINUX_VERSION_EXTENSION = "-yoctized-${LINUX_KERNEL_TYPE}"
>> PR = "r10"
>> PV = "${LINUX_VERSION}+git${SRCPV}"
>>
>> COMPATIBLE_MACHINE = "(u8500|qemuarm)"
>>
>> # Functionality flags
>> KERNEL_REVISION_CHECKING=""
>> YOCTO_KERNEL_META_DATA=""
>>
>> require recipes-kernel/linux/linux-tools.inc
>>
>> what should be the problem?.
> 
> Anything using linux-yocto has exactly the same packaging semantics as
> other kernels, since they all inherit kernel.bbclass.
> 
> Maybe your description sounds familiar to others, and others that might
> have better ideas about what's happening in the packaging backend ?
> 
> You don't have any special partitions configured ? You are building
> on a local filesystem ? Is rpm or ipkg being used ? .. these are all
> things that could impact performance (but not really 15 hours worth of
> issues).
> 
> Are there any hints in the host system logs, or in the kernels do_install
> log ?
> 
> Bruce
> 
>>
>> Best Regards,
>> Om Prakash Pal
>> ________________________________________
>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>> Sent: Thursday, May 03, 2012 5:59 PM
>> To: Om Prakash PAL
>> Cc: Bruce Ashfield; yocto@yoctoproject.org
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> On 12-05-03 05:24 AM, Om Prakash PAL wrote:
>>> Hi Bruce,
>>> Thanks a lot for your help.
>>> Now I am able to build the local kernel.
>>
>> Great!
>>
>>> I have one doublt:
>>> when I do
>>> bitbake -c mencuconfig virtual/kernel
>>>
>>> then from which location it will take the config file?.
>>> and if I want to buiild my own specific defconfig file then How can do it?.
>>
>> It will use the .config in the build directory ${B}, which if you
>> are using a linux-yocto recipe would be your
>> linux-$MACHINE-$KERNELTYPE-build
>> directory.
>>
>> The dependencies of menuconfig will ensure that the kernel has been fetched,
>> unpacked and configured before it runs. Which means a defconfig will
>> have already been used (if specified) to construct the .config.
>>
>> Any changes you make will be saved in the .config, and you'll need to
>> preserve that for future builds.
>>
>> Cheers,
>>
>> Bruce
>>
>>>
>>> Best Regards,
>>> Om Prakash Pal
>>> ________________________________________
>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>> Sent: Monday, April 30, 2012 7:42 PM
>>> To: Om Prakash PAL
>>> Cc: Bruce Ashfield; yocto@yoctoproject.org
>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>
>>> On 12-04-30 6:34 AM, Om Prakash PAL wrote:
>>>>> On 12-04-29 5:58 AM, Om Prakash PAL wrote:
>>>>
>>>>       >    Hi Bruce,
>>>>        >for porting of our local kernel,we have created an BSP layer and to change the the
>>>>        >kernel,  we have created an linux-yocto_3.0.bbappend file inside
>>>>        >meta<BSP>/recipes-kernel/linux/
>>>>        >like this:-
>>>>
>>>>        >FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>>>
>>>>       >    COMPATIBLE_MACHINE_<BSP_name>     = "BSP_name"
>>>>
>>>>        ># KMACHINE is the branch to build
>>>>        >KMACHINE_<BSP_name>     = "local_branch"
>>>>
>>>>       >    SRCREV_machine_pn_linux-yocto_<BSP_name>     ?= "XXXXXXXX" (here we have assign
>>>>        >top commit ID of our local kernel)
>>>>
>>>>
>>>>        ># KSRC_linux_yocto to point to your local clone as appropriate.
>>>>        >KSRC_linux_yocto ?= "/path/to/local/kernel"
>>>>
>>>>        >SRC_URI =
>>>>        >"git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH};name=machine
>>>>         >\
>>>>           >                 file://defconfig"
>>>>
>>>>
>>>>        >KERNEL_REVISION_CHECKING=""
>>>>        >SRCREV="${AUTOREV}"
>>>>        >#BB_LOCALCOUNT_OVERRIDE = "1"
>>>>        >LOCALCOUNT = "0"
>>>>
>>>>
>>>>        >while building we are getting following Error:
>>>>
>>>>        >NOTE: Executing RunQueue Tasks
>>>>        >NOTE: Running task 1341 of 1710 (ID: 513,
>>>>        >/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb,
>>>>         >do_validate_branches)
>>>>        >NOTE: package
>>>>        >linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2: task
>>>>        >do_validate_branches: Started
>>>>        >ERROR: Function 'do_validate_branches' failed (see
>>>>        >/home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/temp/log.do_validate_branches.16792
>>>>         >for further information)
>>>>
>>>>
>>>>        >please tell me what we have done wrong?.
>>>>        >is there anything else we need to modify in .bbappend file or some other
>>>>        >variable?.
>>>>
>>>>> Which release are you using again ?
>>>>      I am using 6.0.0 Edision
>>>>
>>>>> The diagnostics out of validate branches are about to get better in master,
>>>>> but they are coupled with some other tools changes that couldn't go
>>>>> into yocto 1.2.
>>>>
>>>>> Is there anything extra in the log file, or just what you saw on the
>>>>> build log ?.
>>>> actually I have set YOCTO_KERNEL_EXTERNAL_BRANCH ="dev";(dev is my local brach)
>>>> Now this Error has gone and now I am getting
>>>>
>>>> ERROR: Function 'do_patch' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008 for further information)
>>>> ERROR: Logfile of failure stored in: /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008
>>>> Log data follows:
>>>> | ERROR. meta data not found, check upstream repo for tags and branches
>>>> | ERROR: Function 'do_patch' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008 for further information)
>>>> NOTE: package linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3: task do_patch: Failed
>>>> ERROR: Task 516 (/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_patch) failed with exit code '1'
>>>> ERROR: '/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb' failed
>>>>
>>>
>>> This is what I was saying a few weeks ago. If you aren't using
>>> the linux-yocto kernel repository (and hence linux-yocto branches/meta
>>> data) as your base, then building directly via the linux-yocto recipe
>>> probably isn't what you want. It is a recipe that leverages the tools
>>> and infrastructure on top of the linux-yocto repository.
>>>
>>> That same infrastructure can build other repositories, but needs some
>>> extra variables set. The meta-kernel-dev layer, in poky-extras has
>>> examples of this for building korg (or any repo) with the tools.
>>>
>>> What you re being told in this particular error is that you don't have
>>> a meta branch in the tree, or not one that the tools can recognize.
>>> You can prevent this by setting YOCTO_KERNEL_META_DATA="" in your
>>> recipe (see the korg recipe as an example). (and FYI: this will no
>>> longer be required in 1.3, but it is for any previous release.
>>>>
>>>>> Validate branches fails like this when you've provided a bad branch or
>>>>> SRCREV (vs a SRCREV that is simply not the tip of the branch .. it fixes
>>>>> hat scenario) and the fetcher or another git command aborts.
>>>>
>>>>> You've output some example text from the bbappend, but what were the real
>>>>> values in your situation ? i.e. what are KMACHINE/KBRANCH set to ?.
>>>>
>>>> I have not set the value of KBRANCH?. what it should be ?.
>>>
>>> It needs to be a valid branch in the repository. The 1.2 recipes
>>> set it to be KMACHINE if it hasn't been explicitly set. But it
>>> sounds like you are past this, and have set your branch to something
>>> that actually exists in the tree.
>>>
>>> Cheers,
>>>
>>> Bruce
>>>
>>>>
>>>>> There are some flags you can set to exit the branch validation early, but
>>>>> I don't think setting them is the right course of action yet, since the
>>>>> error you are seeing is likely hiding some other mis configuration.
>>>>
>>>>> Cheers,
>>>>
>>>>> Bruce
>>>>
>>>> Best Regards,
>>>> Om Prakash Pal
>>>> ________________________________________
>>>> From: Om Prakash PAL
>>>> Sent: Sunday, April 29, 2012 3:28 PM
>>>> To: Bruce Ashfield
>>>> Cc: yocto@yoctoproject.org
>>>> Subject: RE: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>
>>>> Hi Bruce,
>>>> for porting of our local kernel,we have created an BSP layer and to change the the kernel,  we have created an linux-yocto_3.0.bbappend file inside meta<BSP>/recipes-kernel/linux/
>>>> like this:-
>>>>
>>>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>>>
>>>> COMPATIBLE_MACHINE_<BSP_name>    = "BSP_name"
>>>>
>>>> # KMACHINE is the branch to build
>>>> KMACHINE_<BSP_name>    = "local_branch"
>>>>
>>>> SRCREV_machine_pn_linux-yocto_<BSP_name>    ?= "XXXXXXXX" (here we have assign top commit ID of our local kernel)
>>>>
>>>>
>>>> # KSRC_linux_yocto to point to your local clone as appropriate.
>>>> KSRC_linux_yocto ?= "/path/to/local/kernel"
>>>>
>>>> SRC_URI = "git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH};name=machine \
>>>>                    file://defconfig"
>>>>
>>>>
>>>> KERNEL_REVISION_CHECKING=""
>>>> SRCREV="${AUTOREV}"
>>>> #BB_LOCALCOUNT_OVERRIDE = "1"
>>>> LOCALCOUNT = "0"
>>>>
>>>>
>>>> while building we are getting following Error:
>>>>
>>>> NOTE: Executing RunQueue Tasks
>>>> NOTE: Running task 1341 of 1710 (ID: 513, /home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_validate_branches)
>>>> NOTE: package linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2: task do_validate_branches: Started
>>>> ERROR: Function 'do_validate_branches' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/temp/log.do_validate_branches.16792 for further information)
>>>>
>>>>
>>>> please tell me what we have done wrong?.
>>>> is there anything else we need to modify in .bbappend file or some other variable?.
>>>>
>>>> Best Regards,
>>>> Om Prakash Pal
>>>> ________________________________________
>>>> From: Bruce Ashfield [bruce.ashfield@gmail.com]
>>>> Sent: Monday, April 09, 2012 11:04 PM
>>>> To: Om Prakash PAL
>>>> Cc: yocto@yoctoproject.org
>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>
>>>> On Mon, Apr 9, 2012 at 12:31 PM, Om Prakash PAL
>>>> <omprakash.pal@stericsson.com>    wrote:
>>>>> Hi Bruce,
>>>>> Thanks for you help.
>>>>> As you have mentioned, its working properly.
>>>>> I want to know that is there any better way of doing same thing for my scenario ?:
>>>>> here is my scenario:
>>>>> We have development branch where we write/modify our kernel/driver code i.e. thats our local kernel repository(git rep)
>>>>> and lots of driver/files being modified everyday-->so I have to take the same effect into yocto kernel also---->    so except  creating patches for all modified drivers and creating .bbappend files, is there any better way of doing same thing .
>>>>
>>>> Aha. Missed that.
>>>>
>>>> Just create a simple recipe that points at your git repository in the SRC_URI.
>>>> If all the changes are in the tree, and you have a defconfig and you
>>>> are building
>>>> the master branch. Then pretty much everything you need can be specified in
>>>> the SRC_URI .. and that's the entire recipe.
>>>>
>>>> If you look in oe-classic, meta-ti or any one of a number of other
>>>> layers, you'll
>>>> find recipes that do just that.
>>>>
>>>> The meta-kernel-dev (in the poky extras) layer has an example of using the
>>>> kernel.org tree with the yocto kern tools, and once yocto 1.3 opens up for
>>>> submissions, I have a set of changes prep'd that make it relatively simple to
>>>> use the yocto kern tools against different types of repository.
>>>>
>>>> So the summary is: Depending on the type of tooling you need, and what baseline
>>>> you need for your work .. there are a number of ways to do things.
>>>>
>>>>>
>>>>> Is there anyway that  instead of using yocto-kernel tree,  can we use our local kernel-tree for building images?. (should  I create separate BSP ?)
>>>>
>>>> You should definitely create a BSP, that way you can tune the system specific
>>>> to your board,
>>>>
>>>> Cheers,
>>>>
>>>> Bruce
>>>>
>>>>>
>>>>> Thanks in advance.
>>>>> Best Regards,
>>>>> Om Prakash Pal
>>>>> ________________________________________
>>>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>>>> Sent: Monday, April 09, 2012 9:32 AM
>>>>> To: Om Prakash PAL
>>>>> Cc: yocto@yoctoproject.org
>>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>>
>>>>> On 12-04-08 10:04 AM, Om Prakash PAL wrote:
>>>>>> Hi Bruce,
>>>>>> Thanks for your reply.
>>>>>> I am totally new to Yocto.
>>>>>> I have gone through the section BSP/Linux kernel configuration and if I am not wrong then it explains how can we configure the kernel, not the how we can add/replace a  component(driver etc).
>>>>>> lets take the example of UART driver, I want to add my own UART driver code.
>>>>>> Should I write a separate recipe file (.bb) for UART Driver?.
>>>>>> if yes then I have to write the recipe files for all my drivers that will be very time consuming.
>>>>>> Is there any other way that I can port all my desired drivers into Yocto kernel?.
>>>>>
>>>>> No recipes are required per-driver, unless you are building them all
>>>>> as out of tree modules.
>>>>>
>>>>> The typical way this is done is to simply work in the extracted linux
>>>>> src tree (build/tmp/work/<your board>/linux-yocto-<hashes>/linux), manually
>>>>> patch, or copy your drivers into the tree. At this point, you'll port
>>>>> the drivers, doing test builds (bitbake -f -c compile linux-yocto) to
>>>>> ensure that your port is working. When you've completed the build phase,
>>>>> boot tests would be in order. (Do not do a 'clean' or you'll lose in
>>>>> progress changes).
>>>>>
>>>>> When you are happy with the changes, the directory where you were working
>>>>> is with the kernel git repository. So you can simply commit your
>>>>> changes, and generate patches.
>>>>>
>>>>>       git format-patch -o<your directory>    HEAD^ (or however many commits
>>>>> you have)
>>>>>
>>>>> Take those patches, create a layer with a bbappend and add them like
>>>>> any other patch to any package. They'll be applied to subsequent builds
>>>>> of the kernel.
>>>>>
>>>>> I'm skipping a lot of detail there, but it is all found in the various
>>>>> manuals, and I don't want to repeat it here.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Bruce
>>>>>
>>>>>> Please help me.
>>>>>> Thanks a lot in advance.
>>>>>>
>>>>>> Best Regards,
>>>>>> Om Prakash Pal
>>>>>> ________________________________________
>>>>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>>>>> Sent: Wednesday, April 04, 2012 6:17 PM
>>>>>> To: Om Prakash PAL
>>>>>> Cc: yocto@yoctoproject.org
>>>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>>>
>>>>>> On 12-04-04 04:46 AM, Om Prakash PAL wrote:
>>>>>>> Hi,
>>>>>>> I want to build my local kernel/Driver code, not the default one.
>>>>>>> please help how can i do it ?.
>>>>>>> any wiki/docs on this?.
>>>>>>
>>>>>> The BSP developer guides show how to extend the yocto kernels, and
>>>>>> also have sections on custom/different kernel versions. Have you
>>>>>> seen that doc yet ? Or have you seen it, and have specific questions ?
>>>>>>
>>>>>> Bruce
>>>>>>
>>>>>>>
>>>>>>> Best Regards,
>>>>>>> Om Prakash Pal
>>>>>>> _______________________________________________
>>>>>>> yocto mailing list
>>>>>>> yocto@yoctoproject.org
>>>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> yocto mailing list
>>>>> yocto@yoctoproject.org
>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>
>>>>
>>>>
>>>> --
>>>> "Thou shalt not follow the NULL pointer, for chaos and madness await
>>>> thee at its end"
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>
> 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto


-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Re: Porting of specific Kernel/Driver into yocto.

[Bruce Ashfield]

On 12-05-23 08:39 AM, Om Prakash PAL wrote:
> Hi Bruce,
>
> [ I am using "poky-edison-6.0" ]
> I am able to create my rootfs and uImage but when I flashed these on my board,
> while booting I am getting below Error and console get blocked.
>
> =========================================================
> [    3.575805] EXT3-fs (mmcblk0p1): using internal journal
> [    3.581054] EXT3-fs (mmcblk0p1): mounted filesystem with writeback data mode
> [    3.588165] VFS: Mounted root (ext3 filesystem) on device 179:1.
> [    3.594268] Freeing init memory: 312K
> INIT: version 2.88 booting
>
> Please wait: booting...
> Starting udev
> Starting Bootlog daemon: bootlogd: cannot deduce real console device
> bootlogd.
> Configuring network interfaces... ifconfig: SIOCGIFFLAGS: No such device
> done.
> Fri May 11 11:29:00 UTC 2012
> Running postinst /etc/rpm-postinsts/*.sh...
> ERROR: postinst /etc/rpm-postinsts/*.sh failed.
> INIT: Entering runlevel: 5
> Starting syslogd/klogd: done
> Stopping Bootlog daemon: bootlogd.
> [    9.737091] av8100_hdmi av8100_hdmi.3: HDMI display probed
>
> =========================================================
> and after that it got stuck, I am not getting console.
>
> I am building rootfs/uImage with default toolchain used in yocto.
> Is it problem of toolchain?.


I'm just back from vacation. Is this still an ongoing investigation ? As
Darren mentioned, nothing in that error log indicates a toolchain problem.
You'd typically end up with silent boot death, or far more catastrophic
errors if the toolchain was really at fault here.

It does sound like startup script issues, but without knowing the exact
makeup of your rootfs, it's hard to say more.

Even when the board is stuck, is the networking stack up and responding ?
i.e. can you ping, or even ssh into the box ?

Bruce

> Should I build with our toolchain( we use CodeSourcery)?.
>
> Best Regards,
> Om Prakash Pal
> ________________________________________
> From: Bruce Ashfield [bruce.ashfield@windriver.com]
> Sent: Sunday, May 06, 2012 6:00 PM
> To: Om Prakash PAL
> Cc: Bruce Ashfield; yocto@yoctoproject.org; Richard Purdie
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>
> On 12-05-06 5:43 AM, Om Prakash PAL wrote:
>> Hi Bruce,
>> I am getting some problem in do_install:
>>
>> NOTE: Running task 1535 of 1710 (ID: 517, /home/apallan/yocto/poky-edison-6.0/meta-u8500/recipes-kernel/linux/linux-u8500.bb, do_install)
>> NOTE: package linux-u8500-3.2+git1+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r10: task do_install: Started
>>
>> and I waited for ~15hr to complete task do_install: but not completed and i am not getting any Errors/warnings.
>> Is there any problem?.
>> I have checked that my vmlinux/uImage/zImage has been created successfully but rootfs has not been created till now.
>>
>> here is my .bb file that is building my local_kernel.
>>
>> inherit kernel
>> require recipes-kernel/linux/linux-yocto.inc
>>
>> KMACHINE = "dev"
>> YOCTO_KERNEL_EXTERNAL_BRANCH ?= "dev"
>>
>> KBRANCH = "${KMACHINE}"
>> KMETA = "meta"
>>
>> KSRC_linux_yocto ?= "/home/apallan/yocto/kernel/"
>>
>> SRC_URI = "git://${KSRC_linux_yocto};protocol=file;nocheckout=1"
>> SRC_URI +="file://defconfig"
>>
>> SRCREV="${AUTOREV}"
>> SRCREV_pn-linux-u8500 ="0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383"
>>
>> LINUX_VERSION ?= "3.2"
>> LINUX_VERSION_EXTENSION = "-yoctized-${LINUX_KERNEL_TYPE}"
>> PR = "r10"
>> PV = "${LINUX_VERSION}+git${SRCPV}"
>>
>> COMPATIBLE_MACHINE = "(u8500|qemuarm)"
>>
>> # Functionality flags
>> KERNEL_REVISION_CHECKING=""
>> YOCTO_KERNEL_META_DATA=""
>>
>> require recipes-kernel/linux/linux-tools.inc
>>
>> what should be the problem?.
>
> Anything using linux-yocto has exactly the same packaging semantics as
> other kernels, since they all inherit kernel.bbclass.
>
> Maybe your description sounds familiar to others, and others that might
> have better ideas about what's happening in the packaging backend ?
>
> You don't have any special partitions configured ? You are building
> on a local filesystem ? Is rpm or ipkg being used ? .. these are all
> things that could impact performance (but not really 15 hours worth of
> issues).
>
> Are there any hints in the host system logs, or in the kernels do_install
> log ?
>
> Bruce
>
>>
>> Best Regards,
>> Om Prakash Pal
>> ________________________________________
>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>> Sent: Thursday, May 03, 2012 5:59 PM
>> To: Om Prakash PAL
>> Cc: Bruce Ashfield; yocto@yoctoproject.org
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> On 12-05-03 05:24 AM, Om Prakash PAL wrote:
>>> Hi Bruce,
>>> Thanks a lot for your help.
>>> Now I am able to build the local kernel.
>>
>> Great!
>>
>>> I have one doublt:
>>> when I do
>>> bitbake -c mencuconfig virtual/kernel
>>>
>>> then from which location it will take the config file?.
>>> and if I want to buiild my own specific defconfig file then How can do it?.
>>
>> It will use the .config in the build directory ${B}, which if you
>> are using a linux-yocto recipe would be your
>> linux-$MACHINE-$KERNELTYPE-build
>> directory.
>>
>> The dependencies of menuconfig will ensure that the kernel has been fetched,
>> unpacked and configured before it runs. Which means a defconfig will
>> have already been used (if specified) to construct the .config.
>>
>> Any changes you make will be saved in the .config, and you'll need to
>> preserve that for future builds.
>>
>> Cheers,
>>
>> Bruce
>>
>>>
>>> Best Regards,
>>> Om Prakash Pal
>>> ________________________________________
>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>> Sent: Monday, April 30, 2012 7:42 PM
>>> To: Om Prakash PAL
>>> Cc: Bruce Ashfield; yocto@yoctoproject.org
>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>
>>> On 12-04-30 6:34 AM, Om Prakash PAL wrote:
>>>>> On 12-04-29 5:58 AM, Om Prakash PAL wrote:
>>>>
>>>>        >     Hi Bruce,
>>>>         >for porting of our local kernel,we have created an BSP layer and to change the the
>>>>         >kernel,  we have created an linux-yocto_3.0.bbappend file inside
>>>>         >meta<BSP>/recipes-kernel/linux/
>>>>         >like this:-
>>>>
>>>>         >FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>>>
>>>>        >     COMPATIBLE_MACHINE_<BSP_name>      = "BSP_name"
>>>>
>>>>         ># KMACHINE is the branch to build
>>>>         >KMACHINE_<BSP_name>      = "local_branch"
>>>>
>>>>        >     SRCREV_machine_pn_linux-yocto_<BSP_name>      ?= "XXXXXXXX" (here we have assign
>>>>         >top commit ID of our local kernel)
>>>>
>>>>
>>>>         ># KSRC_linux_yocto to point to your local clone as appropriate.
>>>>         >KSRC_linux_yocto ?= "/path/to/local/kernel"
>>>>
>>>>         >SRC_URI =
>>>>         >"git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH};name=machine
>>>>          >\
>>>>            >                  file://defconfig"
>>>>
>>>>
>>>>         >KERNEL_REVISION_CHECKING=""
>>>>         >SRCREV="${AUTOREV}"
>>>>         >#BB_LOCALCOUNT_OVERRIDE = "1"
>>>>         >LOCALCOUNT = "0"
>>>>
>>>>
>>>>         >while building we are getting following Error:
>>>>
>>>>         >NOTE: Executing RunQueue Tasks
>>>>         >NOTE: Running task 1341 of 1710 (ID: 513,
>>>>         >/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb,
>>>>          >do_validate_branches)
>>>>         >NOTE: package
>>>>         >linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2: task
>>>>         >do_validate_branches: Started
>>>>         >ERROR: Function 'do_validate_branches' failed (see
>>>>         >/home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/temp/log.do_validate_branches.16792
>>>>          >for further information)
>>>>
>>>>
>>>>         >please tell me what we have done wrong?.
>>>>         >is there anything else we need to modify in .bbappend file or some other
>>>>         >variable?.
>>>>
>>>>> Which release are you using again ?
>>>>       I am using 6.0.0 Edision
>>>>
>>>>> The diagnostics out of validate branches are about to get better in master,
>>>>> but they are coupled with some other tools changes that couldn't go
>>>>> into yocto 1.2.
>>>>
>>>>> Is there anything extra in the log file, or just what you saw on the
>>>>> build log ?.
>>>> actually I have set YOCTO_KERNEL_EXTERNAL_BRANCH ="dev";(dev is my local brach)
>>>> Now this Error has gone and now I am getting
>>>>
>>>> ERROR: Function 'do_patch' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008 for further information)
>>>> ERROR: Logfile of failure stored in: /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008
>>>> Log data follows:
>>>> | ERROR. meta data not found, check upstream repo for tags and branches
>>>> | ERROR: Function 'do_patch' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008 for further information)
>>>> NOTE: package linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3: task do_patch: Failed
>>>> ERROR: Task 516 (/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_patch) failed with exit code '1'
>>>> ERROR: '/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb' failed
>>>>
>>>
>>> This is what I was saying a few weeks ago. If you aren't using
>>> the linux-yocto kernel repository (and hence linux-yocto branches/meta
>>> data) as your base, then building directly via the linux-yocto recipe
>>> probably isn't what you want. It is a recipe that leverages the tools
>>> and infrastructure on top of the linux-yocto repository.
>>>
>>> That same infrastructure can build other repositories, but needs some
>>> extra variables set. The meta-kernel-dev layer, in poky-extras has
>>> examples of this for building korg (or any repo) with the tools.
>>>
>>> What you re being told in this particular error is that you don't have
>>> a meta branch in the tree, or not one that the tools can recognize.
>>> You can prevent this by setting YOCTO_KERNEL_META_DATA="" in your
>>> recipe (see the korg recipe as an example). (and FYI: this will no
>>> longer be required in 1.3, but it is for any previous release.
>>>>
>>>>> Validate branches fails like this when you've provided a bad branch or
>>>>> SRCREV (vs a SRCREV that is simply not the tip of the branch .. it fixes
>>>>> hat scenario) and the fetcher or another git command aborts.
>>>>
>>>>> You've output some example text from the bbappend, but what were the real
>>>>> values in your situation ? i.e. what are KMACHINE/KBRANCH set to ?.
>>>>
>>>> I have not set the value of KBRANCH?. what it should be ?.
>>>
>>> It needs to be a valid branch in the repository. The 1.2 recipes
>>> set it to be KMACHINE if it hasn't been explicitly set. But it
>>> sounds like you are past this, and have set your branch to something
>>> that actually exists in the tree.
>>>
>>> Cheers,
>>>
>>> Bruce
>>>
>>>>
>>>>> There are some flags you can set to exit the branch validation early, but
>>>>> I don't think setting them is the right course of action yet, since the
>>>>> error you are seeing is likely hiding some other mis configuration.
>>>>
>>>>> Cheers,
>>>>
>>>>> Bruce
>>>>
>>>> Best Regards,
>>>> Om Prakash Pal
>>>> ________________________________________
>>>> From: Om Prakash PAL
>>>> Sent: Sunday, April 29, 2012 3:28 PM
>>>> To: Bruce Ashfield
>>>> Cc: yocto@yoctoproject.org
>>>> Subject: RE: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>
>>>> Hi Bruce,
>>>> for porting of our local kernel,we have created an BSP layer and to change the the kernel,  we have created an linux-yocto_3.0.bbappend file inside meta<BSP>/recipes-kernel/linux/
>>>> like this:-
>>>>
>>>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>>>
>>>> COMPATIBLE_MACHINE_<BSP_name>     = "BSP_name"
>>>>
>>>> # KMACHINE is the branch to build
>>>> KMACHINE_<BSP_name>     = "local_branch"
>>>>
>>>> SRCREV_machine_pn_linux-yocto_<BSP_name>     ?= "XXXXXXXX" (here we have assign top commit ID of our local kernel)
>>>>
>>>>
>>>> # KSRC_linux_yocto to point to your local clone as appropriate.
>>>> KSRC_linux_yocto ?= "/path/to/local/kernel"
>>>>
>>>> SRC_URI = "git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH};name=machine \
>>>>                     file://defconfig"
>>>>
>>>>
>>>> KERNEL_REVISION_CHECKING=""
>>>> SRCREV="${AUTOREV}"
>>>> #BB_LOCALCOUNT_OVERRIDE = "1"
>>>> LOCALCOUNT = "0"
>>>>
>>>>
>>>> while building we are getting following Error:
>>>>
>>>> NOTE: Executing RunQueue Tasks
>>>> NOTE: Running task 1341 of 1710 (ID: 513, /home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_validate_branches)
>>>> NOTE: package linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2: task do_validate_branches: Started
>>>> ERROR: Function 'do_validate_branches' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/temp/log.do_validate_branches.16792 for further information)
>>>>
>>>>
>>>> please tell me what we have done wrong?.
>>>> is there anything else we need to modify in .bbappend file or some other variable?.
>>>>
>>>> Best Regards,
>>>> Om Prakash Pal
>>>> ________________________________________
>>>> From: Bruce Ashfield [bruce.ashfield@gmail.com]
>>>> Sent: Monday, April 09, 2012 11:04 PM
>>>> To: Om Prakash PAL
>>>> Cc: yocto@yoctoproject.org
>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>
>>>> On Mon, Apr 9, 2012 at 12:31 PM, Om Prakash PAL
>>>> <omprakash.pal@stericsson.com>     wrote:
>>>>> Hi Bruce,
>>>>> Thanks for you help.
>>>>> As you have mentioned, its working properly.
>>>>> I want to know that is there any better way of doing same thing for my scenario ?:
>>>>> here is my scenario:
>>>>> We have development branch where we write/modify our kernel/driver code i.e. thats our local kernel repository(git rep)
>>>>> and lots of driver/files being modified everyday-->so I have to take the same effect into yocto kernel also---->     so except  creating patches for all modified drivers and creating .bbappend files, is there any better way of doing same thing .
>>>>
>>>> Aha. Missed that.
>>>>
>>>> Just create a simple recipe that points at your git repository in the SRC_URI.
>>>> If all the changes are in the tree, and you have a defconfig and you
>>>> are building
>>>> the master branch. Then pretty much everything you need can be specified in
>>>> the SRC_URI .. and that's the entire recipe.
>>>>
>>>> If you look in oe-classic, meta-ti or any one of a number of other
>>>> layers, you'll
>>>> find recipes that do just that.
>>>>
>>>> The meta-kernel-dev (in the poky extras) layer has an example of using the
>>>> kernel.org tree with the yocto kern tools, and once yocto 1.3 opens up for
>>>> submissions, I have a set of changes prep'd that make it relatively simple to
>>>> use the yocto kern tools against different types of repository.
>>>>
>>>> So the summary is: Depending on the type of tooling you need, and what baseline
>>>> you need for your work .. there are a number of ways to do things.
>>>>
>>>>>
>>>>> Is there anyway that  instead of using yocto-kernel tree,  can we use our local kernel-tree for building images?. (should  I create separate BSP ?)
>>>>
>>>> You should definitely create a BSP, that way you can tune the system specific
>>>> to your board,
>>>>
>>>> Cheers,
>>>>
>>>> Bruce
>>>>
>>>>>
>>>>> Thanks in advance.
>>>>> Best Regards,
>>>>> Om Prakash Pal
>>>>> ________________________________________
>>>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>>>> Sent: Monday, April 09, 2012 9:32 AM
>>>>> To: Om Prakash PAL
>>>>> Cc: yocto@yoctoproject.org
>>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>>
>>>>> On 12-04-08 10:04 AM, Om Prakash PAL wrote:
>>>>>> Hi Bruce,
>>>>>> Thanks for your reply.
>>>>>> I am totally new to Yocto.
>>>>>> I have gone through the section BSP/Linux kernel configuration and if I am not wrong then it explains how can we configure the kernel, not the how we can add/replace a  component(driver etc).
>>>>>> lets take the example of UART driver, I want to add my own UART driver code.
>>>>>> Should I write a separate recipe file (.bb) for UART Driver?.
>>>>>> if yes then I have to write the recipe files for all my drivers that will be very time consuming.
>>>>>> Is there any other way that I can port all my desired drivers into Yocto kernel?.
>>>>>
>>>>> No recipes are required per-driver, unless you are building them all
>>>>> as out of tree modules.
>>>>>
>>>>> The typical way this is done is to simply work in the extracted linux
>>>>> src tree (build/tmp/work/<your board>/linux-yocto-<hashes>/linux), manually
>>>>> patch, or copy your drivers into the tree. At this point, you'll port
>>>>> the drivers, doing test builds (bitbake -f -c compile linux-yocto) to
>>>>> ensure that your port is working. When you've completed the build phase,
>>>>> boot tests would be in order. (Do not do a 'clean' or you'll lose in
>>>>> progress changes).
>>>>>
>>>>> When you are happy with the changes, the directory where you were working
>>>>> is with the kernel git repository. So you can simply commit your
>>>>> changes, and generate patches.
>>>>>
>>>>>        git format-patch -o<your directory>     HEAD^ (or however many commits
>>>>> you have)
>>>>>
>>>>> Take those patches, create a layer with a bbappend and add them like
>>>>> any other patch to any package. They'll be applied to subsequent builds
>>>>> of the kernel.
>>>>>
>>>>> I'm skipping a lot of detail there, but it is all found in the various
>>>>> manuals, and I don't want to repeat it here.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Bruce
>>>>>
>>>>>> Please help me.
>>>>>> Thanks a lot in advance.
>>>>>>
>>>>>> Best Regards,
>>>>>> Om Prakash Pal
>>>>>> ________________________________________
>>>>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>>>>> Sent: Wednesday, April 04, 2012 6:17 PM
>>>>>> To: Om Prakash PAL
>>>>>> Cc: yocto@yoctoproject.org
>>>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>>>
>>>>>> On 12-04-04 04:46 AM, Om Prakash PAL wrote:
>>>>>>> Hi,
>>>>>>> I want to build my local kernel/Driver code, not the default one.
>>>>>>> please help how can i do it ?.
>>>>>>> any wiki/docs on this?.
>>>>>>
>>>>>> The BSP developer guides show how to extend the yocto kernels, and
>>>>>> also have sections on custom/different kernel versions. Have you
>>>>>> seen that doc yet ? Or have you seen it, and have specific questions ?
>>>>>>
>>>>>> Bruce
>>>>>>
>>>>>>>
>>>>>>> Best Regards,
>>>>>>> Om Prakash Pal
>>>>>>> _______________________________________________
>>>>>>> yocto mailing list
>>>>>>> yocto@yoctoproject.org
>>>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> yocto mailing list
>>>>> yocto@yoctoproject.org
>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>
>>>>
>>>>
>>>> --
>>>> "Thou shalt not follow the NULL pointer, for chaos and madness await
>>>> thee at its end"
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>
>

Re: Porting of specific Kernel/Driver into yocto.

[Om Prakash PAL]

________________________________________
From: Darren Hart [darren.hart@intel.com]
Sent: Wednesday, May 23, 2012 11:46 PM
To: Om Prakash PAL
Cc: Bruce Ashfield; yocto@yoctoproject.org; Richard Purdie
Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.

On 05/23/2012 05:39 AM, Om Prakash PAL wrote:
> Hi Bruce,
>
> [ I am using "poky-edison-6.0" ]
> I am able to create my rootfs and uImage but when I flashed these on my board,
> while booting I am getting below Error and console get blocked.
>
> =========================================================
> [    3.575805] EXT3-fs (mmcblk0p1): using internal journal
> [    3.581054] EXT3-fs (mmcblk0p1): mounted filesystem with writeback data mode
> [    3.588165] VFS: Mounted root (ext3 filesystem) on device 179:1.
> [    3.594268] Freeing init memory: 312K
> INIT: version 2.88 booting
>
> Please wait: booting...
> Starting udev
> Starting Bootlog daemon: bootlogd: cannot deduce real console device
> bootlogd.
> Configuring network interfaces... ifconfig: SIOCGIFFLAGS: No such device
> done.
> Fri May 11 11:29:00 UTC 2012
> Running postinst /etc/rpm-postinsts/*.sh...
> ERROR: postinst /etc/rpm-postinsts/*.sh failed.

Does this error repeat if you reboot?
Yes, every time.

> INIT: Entering runlevel: 5
> Starting syslogd/klogd: done
> Stopping Bootlog daemon: bootlogd.
> [    9.737091] av8100_hdmi av8100_hdmi.3: HDMI display probed
>
> =========================================================
> and after that it got stuck, I am not getting console.

How long do you let it sit?

after some time(around 10mins) got this msg;
INIT: Id "1" respawning too fast: disabled for 5 minutes
INIT: no more processes left in this runlevel

and then console got  stuck.
>
> I am building rootfs/uImage with default toolchain used in yocto.
> Is it problem of toolchain?.
> Should I build with our toolchain( we use CodeSourcery)?.

Nothing above suggests a toolchain problem. You have an error running
the postinst scripts from the various rpm packages. Some instrumentation
in those scripts (and the parent script) would help narrow down where it
is failing.

--
Darren

>
> Best Regards,
> Om Prakash Pal
> ________________________________________
> From: Bruce Ashfield [bruce.ashfield@windriver.com]
> Sent: Sunday, May 06, 2012 6:00 PM
> To: Om Prakash PAL
> Cc: Bruce Ashfield; yocto@yoctoproject.org; Richard Purdie
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>
> On 12-05-06 5:43 AM, Om Prakash PAL wrote:
>> Hi Bruce,
>> I am getting some problem in do_install:
>>
>> NOTE: Running task 1535 of 1710 (ID: 517, /home/apallan/yocto/poky-edison-6.0/meta-u8500/recipes-kernel/linux/linux-u8500.bb, do_install)
>> NOTE: package linux-u8500-3.2+git1+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r10: task do_install: Started
>>
>> and I waited for ~15hr to complete task do_install: but not completed and i am not getting any Errors/warnings.
>> Is there any problem?.
>> I have checked that my vmlinux/uImage/zImage has been created successfully but rootfs has not been created till now.
>>
>> here is my .bb file that is building my local_kernel.
>>
>> inherit kernel
>> require recipes-kernel/linux/linux-yocto.inc
>>
>> KMACHINE = "dev"
>> YOCTO_KERNEL_EXTERNAL_BRANCH ?= "dev"
>>
>> KBRANCH = "${KMACHINE}"
>> KMETA = "meta"
>>
>> KSRC_linux_yocto ?= "/home/apallan/yocto/kernel/"
>>
>> SRC_URI = "git://${KSRC_linux_yocto};protocol=file;nocheckout=1"
>> SRC_URI +="file://defconfig"
>>
>> SRCREV="${AUTOREV}"
>> SRCREV_pn-linux-u8500 ="0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383"
>>
>> LINUX_VERSION ?= "3.2"
>> LINUX_VERSION_EXTENSION = "-yoctized-${LINUX_KERNEL_TYPE}"
>> PR = "r10"
>> PV = "${LINUX_VERSION}+git${SRCPV}"
>>
>> COMPATIBLE_MACHINE = "(u8500|qemuarm)"
>>
>> # Functionality flags
>> KERNEL_REVISION_CHECKING=""
>> YOCTO_KERNEL_META_DATA=""
>>
>> require recipes-kernel/linux/linux-tools.inc
>>
>> what should be the problem?.
>
> Anything using linux-yocto has exactly the same packaging semantics as
> other kernels, since they all inherit kernel.bbclass.
>
> Maybe your description sounds familiar to others, and others that might
> have better ideas about what's happening in the packaging backend ?
>
> You don't have any special partitions configured ? You are building
> on a local filesystem ? Is rpm or ipkg being used ? .. these are all
> things that could impact performance (but not really 15 hours worth of
> issues).
>
> Are there any hints in the host system logs, or in the kernels do_install
> log ?
>
> Bruce
>
>>
>> Best Regards,
>> Om Prakash Pal
>> ________________________________________
>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>> Sent: Thursday, May 03, 2012 5:59 PM
>> To: Om Prakash PAL
>> Cc: Bruce Ashfield; yocto@yoctoproject.org
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> On 12-05-03 05:24 AM, Om Prakash PAL wrote:
>>> Hi Bruce,
>>> Thanks a lot for your help.
>>> Now I am able to build the local kernel.
>>
>> Great!
>>
>>> I have one doublt:
>>> when I do
>>> bitbake -c mencuconfig virtual/kernel
>>>
>>> then from which location it will take the config file?.
>>> and if I want to buiild my own specific defconfig file then How can do it?.
>>
>> It will use the .config in the build directory ${B}, which if you
>> are using a linux-yocto recipe would be your
>> linux-$MACHINE-$KERNELTYPE-build
>> directory.
>>
>> The dependencies of menuconfig will ensure that the kernel has been fetched,
>> unpacked and configured before it runs. Which means a defconfig will
>> have already been used (if specified) to construct the .config.
>>
>> Any changes you make will be saved in the .config, and you'll need to
>> preserve that for future builds.
>>
>> Cheers,
>>
>> Bruce
>>
>>>
>>> Best Regards,
>>> Om Prakash Pal
>>> ________________________________________
>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>> Sent: Monday, April 30, 2012 7:42 PM
>>> To: Om Prakash PAL
>>> Cc: Bruce Ashfield; yocto@yoctoproject.org
>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>
>>> On 12-04-30 6:34 AM, Om Prakash PAL wrote:
>>>>> On 12-04-29 5:58 AM, Om Prakash PAL wrote:
>>>>
>>>>       >    Hi Bruce,
>>>>        >for porting of our local kernel,we have created an BSP layer and to change the the
>>>>        >kernel,  we have created an linux-yocto_3.0.bbappend file inside
>>>>        >meta<BSP>/recipes-kernel/linux/
>>>>        >like this:-
>>>>
>>>>        >FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>>>
>>>>       >    COMPATIBLE_MACHINE_<BSP_name>     = "BSP_name"
>>>>
>>>>        ># KMACHINE is the branch to build
>>>>        >KMACHINE_<BSP_name>     = "local_branch"
>>>>
>>>>       >    SRCREV_machine_pn_linux-yocto_<BSP_name>     ?= "XXXXXXXX" (here we have assign
>>>>        >top commit ID of our local kernel)
>>>>
>>>>
>>>>        ># KSRC_linux_yocto to point to your local clone as appropriate.
>>>>        >KSRC_linux_yocto ?= "/path/to/local/kernel"
>>>>
>>>>        >SRC_URI =
>>>>        >"git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH};name=machine
>>>>         >\
>>>>           >                 file://defconfig"
>>>>
>>>>
>>>>        >KERNEL_REVISION_CHECKING=""
>>>>        >SRCREV="${AUTOREV}"
>>>>        >#BB_LOCALCOUNT_OVERRIDE = "1"
>>>>        >LOCALCOUNT = "0"
>>>>
>>>>
>>>>        >while building we are getting following Error:
>>>>
>>>>        >NOTE: Executing RunQueue Tasks
>>>>        >NOTE: Running task 1341 of 1710 (ID: 513,
>>>>        >/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb,
>>>>         >do_validate_branches)
>>>>        >NOTE: package
>>>>        >linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2: task
>>>>        >do_validate_branches: Started
>>>>        >ERROR: Function 'do_validate_branches' failed (see
>>>>        >/home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/temp/log.do_validate_branches.16792
>>>>         >for further information)
>>>>
>>>>
>>>>        >please tell me what we have done wrong?.
>>>>        >is there anything else we need to modify in .bbappend file or some other
>>>>        >variable?.
>>>>
>>>>> Which release are you using again ?
>>>>      I am using 6.0.0 Edision
>>>>
>>>>> The diagnostics out of validate branches are about to get better in master,
>>>>> but they are coupled with some other tools changes that couldn't go
>>>>> into yocto 1.2.
>>>>
>>>>> Is there anything extra in the log file, or just what you saw on the
>>>>> build log ?.
>>>> actually I have set YOCTO_KERNEL_EXTERNAL_BRANCH ="dev";(dev is my local brach)
>>>> Now this Error has gone and now I am getting
>>>>
>>>> ERROR: Function 'do_patch' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008 for further information)
>>>> ERROR: Logfile of failure stored in: /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008
>>>> Log data follows:
>>>> | ERROR. meta data not found, check upstream repo for tags and branches
>>>> | ERROR: Function 'do_patch' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008 for further information)
>>>> NOTE: package linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3: task do_patch: Failed
>>>> ERROR: Task 516 (/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_patch) failed with exit code '1'
>>>> ERROR: '/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb' failed
>>>>
>>>
>>> This is what I was saying a few weeks ago. If you aren't using
>>> the linux-yocto kernel repository (and hence linux-yocto branches/meta
>>> data) as your base, then building directly via the linux-yocto recipe
>>> probably isn't what you want. It is a recipe that leverages the tools
>>> and infrastructure on top of the linux-yocto repository.
>>>
>>> That same infrastructure can build other repositories, but needs some
>>> extra variables set. The meta-kernel-dev layer, in poky-extras has
>>> examples of this for building korg (or any repo) with the tools.
>>>
>>> What you re being told in this particular error is that you don't have
>>> a meta branch in the tree, or not one that the tools can recognize.
>>> You can prevent this by setting YOCTO_KERNEL_META_DATA="" in your
>>> recipe (see the korg recipe as an example). (and FYI: this will no
>>> longer be required in 1.3, but it is for any previous release.
>>>>
>>>>> Validate branches fails like this when you've provided a bad branch or
>>>>> SRCREV (vs a SRCREV that is simply not the tip of the branch .. it fixes
>>>>> hat scenario) and the fetcher or another git command aborts.
>>>>
>>>>> You've output some example text from the bbappend, but what were the real
>>>>> values in your situation ? i.e. what are KMACHINE/KBRANCH set to ?.
>>>>
>>>> I have not set the value of KBRANCH?. what it should be ?.
>>>
>>> It needs to be a valid branch in the repository. The 1.2 recipes
>>> set it to be KMACHINE if it hasn't been explicitly set. But it
>>> sounds like you are past this, and have set your branch to something
>>> that actually exists in the tree.
>>>
>>> Cheers,
>>>
>>> Bruce
>>>
>>>>
>>>>> There are some flags you can set to exit the branch validation early, but
>>>>> I don't think setting them is the right course of action yet, since the
>>>>> error you are seeing is likely hiding some other mis configuration.
>>>>
>>>>> Cheers,
>>>>
>>>>> Bruce
>>>>
>>>> Best Regards,
>>>> Om Prakash Pal
>>>> ________________________________________
>>>> From: Om Prakash PAL
>>>> Sent: Sunday, April 29, 2012 3:28 PM
>>>> To: Bruce Ashfield
>>>> Cc: yocto@yoctoproject.org
>>>> Subject: RE: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>
>>>> Hi Bruce,
>>>> for porting of our local kernel,we have created an BSP layer and to change the the kernel,  we have created an linux-yocto_3.0.bbappend file inside meta<BSP>/recipes-kernel/linux/
>>>> like this:-
>>>>
>>>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>>>
>>>> COMPATIBLE_MACHINE_<BSP_name>    = "BSP_name"
>>>>
>>>> # KMACHINE is the branch to build
>>>> KMACHINE_<BSP_name>    = "local_branch"
>>>>
>>>> SRCREV_machine_pn_linux-yocto_<BSP_name>    ?= "XXXXXXXX" (here we have assign top commit ID of our local kernel)
>>>>
>>>>
>>>> # KSRC_linux_yocto to point to your local clone as appropriate.
>>>> KSRC_linux_yocto ?= "/path/to/local/kernel"
>>>>
>>>> SRC_URI = "git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH};name=machine \
>>>>                    file://defconfig"
>>>>
>>>>
>>>> KERNEL_REVISION_CHECKING=""
>>>> SRCREV="${AUTOREV}"
>>>> #BB_LOCALCOUNT_OVERRIDE = "1"
>>>> LOCALCOUNT = "0"
>>>>
>>>>
>>>> while building we are getting following Error:
>>>>
>>>> NOTE: Executing RunQueue Tasks
>>>> NOTE: Running task 1341 of 1710 (ID: 513, /home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_validate_branches)
>>>> NOTE: package linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2: task do_validate_branches: Started
>>>> ERROR: Function 'do_validate_branches' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/temp/log.do_validate_branches.16792 for further information)
>>>>
>>>>
>>>> please tell me what we have done wrong?.
>>>> is there anything else we need to modify in .bbappend file or some other variable?.
>>>>
>>>> Best Regards,
>>>> Om Prakash Pal
>>>> ________________________________________
>>>> From: Bruce Ashfield [bruce.ashfield@gmail.com]
>>>> Sent: Monday, April 09, 2012 11:04 PM
>>>> To: Om Prakash PAL
>>>> Cc: yocto@yoctoproject.org
>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>
>>>> On Mon, Apr 9, 2012 at 12:31 PM, Om Prakash PAL
>>>> <omprakash.pal@stericsson.com>    wrote:
>>>>> Hi Bruce,
>>>>> Thanks for you help.
>>>>> As you have mentioned, its working properly.
>>>>> I want to know that is there any better way of doing same thing for my scenario ?:
>>>>> here is my scenario:
>>>>> We have development branch where we write/modify our kernel/driver code i.e. thats our local kernel repository(git rep)
>>>>> and lots of driver/files being modified everyday-->so I have to take the same effect into yocto kernel also---->    so except  creating patches for all modified drivers and creating .bbappend files, is there any better way of doing same thing .
>>>>
>>>> Aha. Missed that.
>>>>
>>>> Just create a simple recipe that points at your git repository in the SRC_URI.
>>>> If all the changes are in the tree, and you have a defconfig and you
>>>> are building
>>>> the master branch. Then pretty much everything you need can be specified in
>>>> the SRC_URI .. and that's the entire recipe.
>>>>
>>>> If you look in oe-classic, meta-ti or any one of a number of other
>>>> layers, you'll
>>>> find recipes that do just that.
>>>>
>>>> The meta-kernel-dev (in the poky extras) layer has an example of using the
>>>> kernel.org tree with the yocto kern tools, and once yocto 1.3 opens up for
>>>> submissions, I have a set of changes prep'd that make it relatively simple to
>>>> use the yocto kern tools against different types of repository.
>>>>
>>>> So the summary is: Depending on the type of tooling you need, and what baseline
>>>> you need for your work .. there are a number of ways to do things.
>>>>
>>>>>
>>>>> Is there anyway that  instead of using yocto-kernel tree,  can we use our local kernel-tree for building images?. (should  I create separate BSP ?)
>>>>
>>>> You should definitely create a BSP, that way you can tune the system specific
>>>> to your board,
>>>>
>>>> Cheers,
>>>>
>>>> Bruce
>>>>
>>>>>
>>>>> Thanks in advance.
>>>>> Best Regards,
>>>>> Om Prakash Pal
>>>>> ________________________________________
>>>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>>>> Sent: Monday, April 09, 2012 9:32 AM
>>>>> To: Om Prakash PAL
>>>>> Cc: yocto@yoctoproject.org
>>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>>
>>>>> On 12-04-08 10:04 AM, Om Prakash PAL wrote:
>>>>>> Hi Bruce,
>>>>>> Thanks for your reply.
>>>>>> I am totally new to Yocto.
>>>>>> I have gone through the section BSP/Linux kernel configuration and if I am not wrong then it explains how can we configure the kernel, not the how we can add/replace a  component(driver etc).
>>>>>> lets take the example of UART driver, I want to add my own UART driver code.
>>>>>> Should I write a separate recipe file (.bb) for UART Driver?.
>>>>>> if yes then I have to write the recipe files for all my drivers that will be very time consuming.
>>>>>> Is there any other way that I can port all my desired drivers into Yocto kernel?.
>>>>>
>>>>> No recipes are required per-driver, unless you are building them all
>>>>> as out of tree modules.
>>>>>
>>>>> The typical way this is done is to simply work in the extracted linux
>>>>> src tree (build/tmp/work/<your board>/linux-yocto-<hashes>/linux), manually
>>>>> patch, or copy your drivers into the tree. At this point, you'll port
>>>>> the drivers, doing test builds (bitbake -f -c compile linux-yocto) to
>>>>> ensure that your port is working. When you've completed the build phase,
>>>>> boot tests would be in order. (Do not do a 'clean' or you'll lose in
>>>>> progress changes).
>>>>>
>>>>> When you are happy with the changes, the directory where you were working
>>>>> is with the kernel git repository. So you can simply commit your
>>>>> changes, and generate patches.
>>>>>
>>>>>       git format-patch -o<your directory>    HEAD^ (or however many commits
>>>>> you have)
>>>>>
>>>>> Take those patches, create a layer with a bbappend and add them like
>>>>> any other patch to any package. They'll be applied to subsequent builds
>>>>> of the kernel.
>>>>>
>>>>> I'm skipping a lot of detail there, but it is all found in the various
>>>>> manuals, and I don't want to repeat it here.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Bruce
>>>>>
>>>>>> Please help me.
>>>>>> Thanks a lot in advance.
>>>>>>
>>>>>> Best Regards,
>>>>>> Om Prakash Pal
>>>>>> ________________________________________
>>>>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>>>>> Sent: Wednesday, April 04, 2012 6:17 PM
>>>>>> To: Om Prakash PAL
>>>>>> Cc: yocto@yoctoproject.org
>>>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>>>
>>>>>> On 12-04-04 04:46 AM, Om Prakash PAL wrote:
>>>>>>> Hi,
>>>>>>> I want to build my local kernel/Driver code, not the default one.
>>>>>>> please help how can i do it ?.
>>>>>>> any wiki/docs on this?.
>>>>>>
>>>>>> The BSP developer guides show how to extend the yocto kernels, and
>>>>>> also have sections on custom/different kernel versions. Have you
>>>>>> seen that doc yet ? Or have you seen it, and have specific questions ?
>>>>>>
>>>>>> Bruce
>>>>>>
>>>>>>>
>>>>>>> Best Regards,
>>>>>>> Om Prakash Pal
>>>>>>> _______________________________________________
>>>>>>> yocto mailing list
>>>>>>> yocto@yoctoproject.org
>>>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> yocto mailing list
>>>>> yocto@yoctoproject.org
>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>
>>>>
>>>>
>>>> --
>>>> "Thou shalt not follow the NULL pointer, for chaos and madness await
>>>> thee at its end"
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto


--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Re: Porting of specific Kernel/Driver into yocto.

[Om Prakash PAL]

________________________________________
From: Bruce Ashfield [bruce.ashfield@windriver.com]
Sent: Monday, May 28, 2012 11:25 PM
To: Om Prakash PAL
Cc: Bruce Ashfield; yocto@yoctoproject.org; Richard Purdie
Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.

On 12-05-23 08:39 AM, Om Prakash PAL wrote:
> Hi Bruce,
>
> [ I am using "poky-edison-6.0" ]
> I am able to create my rootfs and uImage but when I flashed these on my board,
> while booting I am getting below Error and console get blocked.
>
> =========================================================
> [    3.575805] EXT3-fs (mmcblk0p1): using internal journal
> [    3.581054] EXT3-fs (mmcblk0p1): mounted filesystem with writeback data mode
> [    3.588165] VFS: Mounted root (ext3 filesystem) on device 179:1.
> [    3.594268] Freeing init memory: 312K
> INIT: version 2.88 booting
>
> Please wait: booting...
> Starting udev
> Starting Bootlog daemon: bootlogd: cannot deduce real console device
> bootlogd.
> Configuring network interfaces... ifconfig: SIOCGIFFLAGS: No such device
> done.
> Fri May 11 11:29:00 UTC 2012
> Running postinst /etc/rpm-postinsts/*.sh...
> ERROR: postinst /etc/rpm-postinsts/*.sh failed.
> INIT: Entering runlevel: 5
> Starting syslogd/klogd: done
> Stopping Bootlog daemon: bootlogd.
> [    9.737091] av8100_hdmi av8100_hdmi.3: HDMI display probed
>
> =========================================================
> and after that it got stuck, I am not getting console.
>
> I am building rootfs/uImage with default toolchain used in yocto.
> Is it problem of toolchain?.


>I'm just back from vacation. Is this still an ongoing investigation ? As
>Darren mentioned, nothing in that error log indicates a toolchain problem.
>You'd typically end up with silent boot death, or far more catastrophic
>errors if the toolchain was really at fault here.

>It does sound like startup script issues, but without knowing the exact
>makeup of your rootfs, it's hard to say more.

===>I am just using makeup of "Yocto default rootfs" I am not using my own makeup of rootfs.

>Even when the board is stuck, is the networking stack up and responding ?
>i.e. can you ping, or even ssh into the box ?

No, Nothing,
we can not do anyhting. it just got stuck.
any help/idea will be appreciable.

Best Regards,
Om Prakash Pal

>Bruce

> Should I build with our toolchain( we use CodeSourcery)?.
>
> Best Regards,
> Om Prakash Pal
> ________________________________________
> From: Bruce Ashfield [bruce.ashfield@windriver.com]
> Sent: Sunday, May 06, 2012 6:00 PM
> To: Om Prakash PAL
> Cc: Bruce Ashfield; yocto@yoctoproject.org; Richard Purdie
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>
> On 12-05-06 5:43 AM, Om Prakash PAL wrote:
>> Hi Bruce,
>> I am getting some problem in do_install:
>>
>> NOTE: Running task 1535 of 1710 (ID: 517, /home/apallan/yocto/poky-edison-6.0/meta-u8500/recipes-kernel/linux/linux-u8500.bb, do_install)
>> NOTE: package linux-u8500-3.2+git1+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r10: task do_install: Started
>>
>> and I waited for ~15hr to complete task do_install: but not completed and i am not getting any Errors/warnings.
>> Is there any problem?.
>> I have checked that my vmlinux/uImage/zImage has been created successfully but rootfs has not been created till now.
>>
>> here is my .bb file that is building my local_kernel.
>>
>> inherit kernel
>> require recipes-kernel/linux/linux-yocto.inc
>>
>> KMACHINE = "dev"
>> YOCTO_KERNEL_EXTERNAL_BRANCH ?= "dev"
>>
>> KBRANCH = "${KMACHINE}"
>> KMETA = "meta"
>>
>> KSRC_linux_yocto ?= "/home/apallan/yocto/kernel/"
>>
>> SRC_URI = "git://${KSRC_linux_yocto};protocol=file;nocheckout=1"
>> SRC_URI +="file://defconfig"
>>
>> SRCREV="${AUTOREV}"
>> SRCREV_pn-linux-u8500 ="0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383"
>>
>> LINUX_VERSION ?= "3.2"
>> LINUX_VERSION_EXTENSION = "-yoctized-${LINUX_KERNEL_TYPE}"
>> PR = "r10"
>> PV = "${LINUX_VERSION}+git${SRCPV}"
>>
>> COMPATIBLE_MACHINE = "(u8500|qemuarm)"
>>
>> # Functionality flags
>> KERNEL_REVISION_CHECKING=""
>> YOCTO_KERNEL_META_DATA=""
>>
>> require recipes-kernel/linux/linux-tools.inc
>>
>> what should be the problem?.
>
> Anything using linux-yocto has exactly the same packaging semantics as
> other kernels, since they all inherit kernel.bbclass.
>
> Maybe your description sounds familiar to others, and others that might
> have better ideas about what's happening in the packaging backend ?
>
> You don't have any special partitions configured ? You are building
> on a local filesystem ? Is rpm or ipkg being used ? .. these are all
> things that could impact performance (but not really 15 hours worth of
> issues).
>
> Are there any hints in the host system logs, or in the kernels do_install
> log ?
>
> Bruce
>
>>
>> Best Regards,
>> Om Prakash Pal
>> ________________________________________
>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>> Sent: Thursday, May 03, 2012 5:59 PM
>> To: Om Prakash PAL
>> Cc: Bruce Ashfield; yocto@yoctoproject.org
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> On 12-05-03 05:24 AM, Om Prakash PAL wrote:
>>> Hi Bruce,
>>> Thanks a lot for your help.
>>> Now I am able to build the local kernel.
>>
>> Great!
>>
>>> I have one doublt:
>>> when I do
>>> bitbake -c mencuconfig virtual/kernel
>>>
>>> then from which location it will take the config file?.
>>> and if I want to buiild my own specific defconfig file then How can do it?.
>>
>> It will use the .config in the build directory ${B}, which if you
>> are using a linux-yocto recipe would be your
>> linux-$MACHINE-$KERNELTYPE-build
>> directory.
>>
>> The dependencies of menuconfig will ensure that the kernel has been fetched,
>> unpacked and configured before it runs. Which means a defconfig will
>> have already been used (if specified) to construct the .config.
>>
>> Any changes you make will be saved in the .config, and you'll need to
>> preserve that for future builds.
>>
>> Cheers,
>>
>> Bruce
>>
>>>
>>> Best Regards,
>>> Om Prakash Pal
>>> ________________________________________
>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>> Sent: Monday, April 30, 2012 7:42 PM
>>> To: Om Prakash PAL
>>> Cc: Bruce Ashfield; yocto@yoctoproject.org
>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>
>>> On 12-04-30 6:34 AM, Om Prakash PAL wrote:
>>>>> On 12-04-29 5:58 AM, Om Prakash PAL wrote:
>>>>
>>>>        >     Hi Bruce,
>>>>         >for porting of our local kernel,we have created an BSP layer and to change the the
>>>>         >kernel,  we have created an linux-yocto_3.0.bbappend file inside
>>>>         >meta<BSP>/recipes-kernel/linux/
>>>>         >like this:-
>>>>
>>>>         >FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>>>
>>>>        >     COMPATIBLE_MACHINE_<BSP_name>      = "BSP_name"
>>>>
>>>>         ># KMACHINE is the branch to build
>>>>         >KMACHINE_<BSP_name>      = "local_branch"
>>>>
>>>>        >     SRCREV_machine_pn_linux-yocto_<BSP_name>      ?= "XXXXXXXX" (here we have assign
>>>>         >top commit ID of our local kernel)
>>>>
>>>>
>>>>         ># KSRC_linux_yocto to point to your local clone as appropriate.
>>>>         >KSRC_linux_yocto ?= "/path/to/local/kernel"
>>>>
>>>>         >SRC_URI =
>>>>         >"git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH};name=machine
>>>>          >\
>>>>            >                  file://defconfig"
>>>>
>>>>
>>>>         >KERNEL_REVISION_CHECKING=""
>>>>         >SRCREV="${AUTOREV}"
>>>>         >#BB_LOCALCOUNT_OVERRIDE = "1"
>>>>         >LOCALCOUNT = "0"
>>>>
>>>>
>>>>         >while building we are getting following Error:
>>>>
>>>>         >NOTE: Executing RunQueue Tasks
>>>>         >NOTE: Running task 1341 of 1710 (ID: 513,
>>>>         >/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb,
>>>>          >do_validate_branches)
>>>>         >NOTE: package
>>>>         >linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2: task
>>>>         >do_validate_branches: Started
>>>>         >ERROR: Function 'do_validate_branches' failed (see
>>>>         >/home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/temp/log.do_validate_branches.16792
>>>>          >for further information)
>>>>
>>>>
>>>>         >please tell me what we have done wrong?.
>>>>         >is there anything else we need to modify in .bbappend file or some other
>>>>         >variable?.
>>>>
>>>>> Which release are you using again ?
>>>>       I am using 6.0.0 Edision
>>>>
>>>>> The diagnostics out of validate branches are about to get better in master,
>>>>> but they are coupled with some other tools changes that couldn't go
>>>>> into yocto 1.2.
>>>>
>>>>> Is there anything extra in the log file, or just what you saw on the
>>>>> build log ?.
>>>> actually I have set YOCTO_KERNEL_EXTERNAL_BRANCH ="dev";(dev is my local brach)
>>>> Now this Error has gone and now I am getting
>>>>
>>>> ERROR: Function 'do_patch' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008 for further information)
>>>> ERROR: Logfile of failure stored in: /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008
>>>> Log data follows:
>>>> | ERROR. meta data not found, check upstream repo for tags and branches
>>>> | ERROR: Function 'do_patch' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008 for further information)
>>>> NOTE: package linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3: task do_patch: Failed
>>>> ERROR: Task 516 (/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_patch) failed with exit code '1'
>>>> ERROR: '/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb' failed
>>>>
>>>
>>> This is what I was saying a few weeks ago. If you aren't using
>>> the linux-yocto kernel repository (and hence linux-yocto branches/meta
>>> data) as your base, then building directly via the linux-yocto recipe
>>> probably isn't what you want. It is a recipe that leverages the tools
>>> and infrastructure on top of the linux-yocto repository.
>>>
>>> That same infrastructure can build other repositories, but needs some
>>> extra variables set. The meta-kernel-dev layer, in poky-extras has
>>> examples of this for building korg (or any repo) with the tools.
>>>
>>> What you re being told in this particular error is that you don't have
>>> a meta branch in the tree, or not one that the tools can recognize.
>>> You can prevent this by setting YOCTO_KERNEL_META_DATA="" in your
>>> recipe (see the korg recipe as an example). (and FYI: this will no
>>> longer be required in 1.3, but it is for any previous release.
>>>>
>>>>> Validate branches fails like this when you've provided a bad branch or
>>>>> SRCREV (vs a SRCREV that is simply not the tip of the branch .. it fixes
>>>>> hat scenario) and the fetcher or another git command aborts.
>>>>
>>>>> You've output some example text from the bbappend, but what were the real
>>>>> values in your situation ? i.e. what are KMACHINE/KBRANCH set to ?.
>>>>
>>>> I have not set the value of KBRANCH?. what it should be ?.
>>>
>>> It needs to be a valid branch in the repository. The 1.2 recipes
>>> set it to be KMACHINE if it hasn't been explicitly set. But it
>>> sounds like you are past this, and have set your branch to something
>>> that actually exists in the tree.
>>>
>>> Cheers,
>>>
>>> Bruce
>>>
>>>>
>>>>> There are some flags you can set to exit the branch validation early, but
>>>>> I don't think setting them is the right course of action yet, since the
>>>>> error you are seeing is likely hiding some other mis configuration.
>>>>
>>>>> Cheers,
>>>>
>>>>> Bruce
>>>>
>>>> Best Regards,
>>>> Om Prakash Pal
>>>> ________________________________________
>>>> From: Om Prakash PAL
>>>> Sent: Sunday, April 29, 2012 3:28 PM
>>>> To: Bruce Ashfield
>>>> Cc: yocto@yoctoproject.org
>>>> Subject: RE: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>
>>>> Hi Bruce,
>>>> for porting of our local kernel,we have created an BSP layer and to change the the kernel,  we have created an linux-yocto_3.0.bbappend file inside meta<BSP>/recipes-kernel/linux/
>>>> like this:-
>>>>
>>>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>>>
>>>> COMPATIBLE_MACHINE_<BSP_name>     = "BSP_name"
>>>>
>>>> # KMACHINE is the branch to build
>>>> KMACHINE_<BSP_name>     = "local_branch"
>>>>
>>>> SRCREV_machine_pn_linux-yocto_<BSP_name>     ?= "XXXXXXXX" (here we have assign top commit ID of our local kernel)
>>>>
>>>>
>>>> # KSRC_linux_yocto to point to your local clone as appropriate.
>>>> KSRC_linux_yocto ?= "/path/to/local/kernel"
>>>>
>>>> SRC_URI = "git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH};name=machine \
>>>>                     file://defconfig"
>>>>
>>>>
>>>> KERNEL_REVISION_CHECKING=""
>>>> SRCREV="${AUTOREV}"
>>>> #BB_LOCALCOUNT_OVERRIDE = "1"
>>>> LOCALCOUNT = "0"
>>>>
>>>>
>>>> while building we are getting following Error:
>>>>
>>>> NOTE: Executing RunQueue Tasks
>>>> NOTE: Running task 1341 of 1710 (ID: 513, /home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_validate_branches)
>>>> NOTE: package linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2: task do_validate_branches: Started
>>>> ERROR: Function 'do_validate_branches' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/temp/log.do_validate_branches.16792 for further information)
>>>>
>>>>
>>>> please tell me what we have done wrong?.
>>>> is there anything else we need to modify in .bbappend file or some other variable?.
>>>>
>>>> Best Regards,
>>>> Om Prakash Pal
>>>> ________________________________________
>>>> From: Bruce Ashfield [bruce.ashfield@gmail.com]
>>>> Sent: Monday, April 09, 2012 11:04 PM
>>>> To: Om Prakash PAL
>>>> Cc: yocto@yoctoproject.org
>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>
>>>> On Mon, Apr 9, 2012 at 12:31 PM, Om Prakash PAL
>>>> <omprakash.pal@stericsson.com>     wrote:
>>>>> Hi Bruce,
>>>>> Thanks for you help.
>>>>> As you have mentioned, its working properly.
>>>>> I want to know that is there any better way of doing same thing for my scenario ?:
>>>>> here is my scenario:
>>>>> We have development branch where we write/modify our kernel/driver code i.e. thats our local kernel repository(git rep)
>>>>> and lots of driver/files being modified everyday-->so I have to take the same effect into yocto kernel also---->     so except  creating patches for all modified drivers and creating .bbappend files, is there any better way of doing same thing .
>>>>
>>>> Aha. Missed that.
>>>>
>>>> Just create a simple recipe that points at your git repository in the SRC_URI.
>>>> If all the changes are in the tree, and you have a defconfig and you
>>>> are building
>>>> the master branch. Then pretty much everything you need can be specified in
>>>> the SRC_URI .. and that's the entire recipe.
>>>>
>>>> If you look in oe-classic, meta-ti or any one of a number of other
>>>> layers, you'll
>>>> find recipes that do just that.
>>>>
>>>> The meta-kernel-dev (in the poky extras) layer has an example of using the
>>>> kernel.org tree with the yocto kern tools, and once yocto 1.3 opens up for
>>>> submissions, I have a set of changes prep'd that make it relatively simple to
>>>> use the yocto kern tools against different types of repository.
>>>>
>>>> So the summary is: Depending on the type of tooling you need, and what baseline
>>>> you need for your work .. there are a number of ways to do things.
>>>>
>>>>>
>>>>> Is there anyway that  instead of using yocto-kernel tree,  can we use our local kernel-tree for building images?. (should  I create separate BSP ?)
>>>>
>>>> You should definitely create a BSP, that way you can tune the system specific
>>>> to your board,
>>>>
>>>> Cheers,
>>>>
>>>> Bruce
>>>>
>>>>>
>>>>> Thanks in advance.
>>>>> Best Regards,
>>>>> Om Prakash Pal
>>>>> ________________________________________
>>>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>>>> Sent: Monday, April 09, 2012 9:32 AM
>>>>> To: Om Prakash PAL
>>>>> Cc: yocto@yoctoproject.org
>>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>>
>>>>> On 12-04-08 10:04 AM, Om Prakash PAL wrote:
>>>>>> Hi Bruce,
>>>>>> Thanks for your reply.
>>>>>> I am totally new to Yocto.
>>>>>> I have gone through the section BSP/Linux kernel configuration and if I am not wrong then it explains how can we configure the kernel, not the how we can add/replace a  component(driver etc).
>>>>>> lets take the example of UART driver, I want to add my own UART driver code.
>>>>>> Should I write a separate recipe file (.bb) for UART Driver?.
>>>>>> if yes then I have to write the recipe files for all my drivers that will be very time consuming.
>>>>>> Is there any other way that I can port all my desired drivers into Yocto kernel?.
>>>>>
>>>>> No recipes are required per-driver, unless you are building them all
>>>>> as out of tree modules.
>>>>>
>>>>> The typical way this is done is to simply work in the extracted linux
>>>>> src tree (build/tmp/work/<your board>/linux-yocto-<hashes>/linux), manually
>>>>> patch, or copy your drivers into the tree. At this point, you'll port
>>>>> the drivers, doing test builds (bitbake -f -c compile linux-yocto) to
>>>>> ensure that your port is working. When you've completed the build phase,
>>>>> boot tests would be in order. (Do not do a 'clean' or you'll lose in
>>>>> progress changes).
>>>>>
>>>>> When you are happy with the changes, the directory where you were working
>>>>> is with the kernel git repository. So you can simply commit your
>>>>> changes, and generate patches.
>>>>>
>>>>>        git format-patch -o<your directory>     HEAD^ (or however many commits
>>>>> you have)
>>>>>
>>>>> Take those patches, create a layer with a bbappend and add them like
>>>>> any other patch to any package. They'll be applied to subsequent builds
>>>>> of the kernel.
>>>>>
>>>>> I'm skipping a lot of detail there, but it is all found in the various
>>>>> manuals, and I don't want to repeat it here.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Bruce
>>>>>
>>>>>> Please help me.
>>>>>> Thanks a lot in advance.
>>>>>>
>>>>>> Best Regards,
>>>>>> Om Prakash Pal
>>>>>> ________________________________________
>>>>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>>>>> Sent: Wednesday, April 04, 2012 6:17 PM
>>>>>> To: Om Prakash PAL
>>>>>> Cc: yocto@yoctoproject.org
>>>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>>>
>>>>>> On 12-04-04 04:46 AM, Om Prakash PAL wrote:
>>>>>>> Hi,
>>>>>>> I want to build my local kernel/Driver code, not the default one.
>>>>>>> please help how can i do it ?.
>>>>>>> any wiki/docs on this?.
>>>>>>
>>>>>> The BSP developer guides show how to extend the yocto kernels, and
>>>>>> also have sections on custom/different kernel versions. Have you
>>>>>> seen that doc yet ? Or have you seen it, and have specific questions ?
>>>>>>
>>>>>> Bruce
>>>>>>
>>>>>>>
>>>>>>> Best Regards,
>>>>>>> Om Prakash Pal
>>>>>>> _______________________________________________
>>>>>>> yocto mailing list
>>>>>>> yocto@yoctoproject.org
>>>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> yocto mailing list
>>>>> yocto@yoctoproject.org
>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>
>>>>
>>>>
>>>> --
>>>> "Thou shalt not follow the NULL pointer, for chaos and madness await
>>>> thee at its end"
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>
>

Re: Porting of specific Kernel/Driver into yocto.

[Gary Thomas]

On 2012-06-21 06:27, Om Prakash PAL wrote:
> ________________________________________
> From: Darren Hart [darren.hart@intel.com]
> Sent: Wednesday, May 23, 2012 11:46 PM
> To: Om Prakash PAL
> Cc: Bruce Ashfield; yocto@yoctoproject.org; Richard Purdie
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>
> On 05/23/2012 05:39 AM, Om Prakash PAL wrote:
>> Hi Bruce,
>>
>> [ I am using "poky-edison-6.0" ]
>> I am able to create my rootfs and uImage but when I flashed these on my board,
>> while booting I am getting below Error and console get blocked.
>>
>> =========================================================
>> [    3.575805] EXT3-fs (mmcblk0p1): using internal journal
>> [    3.581054] EXT3-fs (mmcblk0p1): mounted filesystem with writeback data mode
>> [    3.588165] VFS: Mounted root (ext3 filesystem) on device 179:1.
>> [    3.594268] Freeing init memory: 312K
>> INIT: version 2.88 booting
>>
>> Please wait: booting...
>> Starting udev
>> Starting Bootlog daemon: bootlogd: cannot deduce real console device
>> bootlogd.
>> Configuring network interfaces... ifconfig: SIOCGIFFLAGS: No such device
>> done.
>> Fri May 11 11:29:00 UTC 2012
>> Running postinst /etc/rpm-postinsts/*.sh...
>> ERROR: postinst /etc/rpm-postinsts/*.sh failed.
>
> Does this error repeat if you reboot?
> Yes, every time.

What image is being used?  I've seen this with core-image-minimal, but it
goes away when the image is more complex, e.g. core-image-sato.  I believe
the init script is always present even if there are no postinst scripts to run.

>
>> INIT: Entering runlevel: 5
>> Starting syslogd/klogd: done
>> Stopping Bootlog daemon: bootlogd.
>> [    9.737091] av8100_hdmi av8100_hdmi.3: HDMI display probed
>>
>> =========================================================
>> and after that it got stuck, I am not getting console.
>
> How long do you let it sit?
>
> after some time(around 10mins) got this msg;
> INIT: Id "1" respawning too fast: disabled for 5 minutes
> INIT: no more processes left in this runlevel
>
> and then console got  stuck.

What do you have SERIAL_CONSOLE set to in your configuration?

>>
>> I am building rootfs/uImage with default toolchain used in yocto.
>> Is it problem of toolchain?.
>> Should I build with our toolchain( we use CodeSourcery)?.
>
> Nothing above suggests a toolchain problem. You have an error running
> the postinst scripts from the various rpm packages. Some instrumentation
> in those scripts (and the parent script) would help narrow down where it
> is failing.
>
> --
> Darren
>
>>
>> Best Regards,
>> Om Prakash Pal
>> ________________________________________
>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>> Sent: Sunday, May 06, 2012 6:00 PM
>> To: Om Prakash PAL
>> Cc: Bruce Ashfield; yocto@yoctoproject.org; Richard Purdie
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> On 12-05-06 5:43 AM, Om Prakash PAL wrote:
>>> Hi Bruce,
>>> I am getting some problem in do_install:
>>>
>>> NOTE: Running task 1535 of 1710 (ID: 517, /home/apallan/yocto/poky-edison-6.0/meta-u8500/recipes-kernel/linux/linux-u8500.bb, do_install)
>>> NOTE: package linux-u8500-3.2+git1+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r10: task do_install: Started
>>>
>>> and I waited for ~15hr to complete task do_install: but not completed and i am not getting any Errors/warnings.
>>> Is there any problem?.
>>> I have checked that my vmlinux/uImage/zImage has been created successfully but rootfs has not been created till now.
>>>
>>> here is my .bb file that is building my local_kernel.
>>>
>>> inherit kernel
>>> require recipes-kernel/linux/linux-yocto.inc
>>>
>>> KMACHINE = "dev"
>>> YOCTO_KERNEL_EXTERNAL_BRANCH ?= "dev"
>>>
>>> KBRANCH = "${KMACHINE}"
>>> KMETA = "meta"
>>>
>>> KSRC_linux_yocto ?= "/home/apallan/yocto/kernel/"
>>>
>>> SRC_URI = "git://${KSRC_linux_yocto};protocol=file;nocheckout=1"
>>> SRC_URI +="file://defconfig"
>>>
>>> SRCREV="${AUTOREV}"
>>> SRCREV_pn-linux-u8500 ="0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383"
>>>
>>> LINUX_VERSION ?= "3.2"
>>> LINUX_VERSION_EXTENSION = "-yoctized-${LINUX_KERNEL_TYPE}"
>>> PR = "r10"
>>> PV = "${LINUX_VERSION}+git${SRCPV}"
>>>
>>> COMPATIBLE_MACHINE = "(u8500|qemuarm)"
>>>
>>> # Functionality flags
>>> KERNEL_REVISION_CHECKING=""
>>> YOCTO_KERNEL_META_DATA=""
>>>
>>> require recipes-kernel/linux/linux-tools.inc
>>>
>>> what should be the problem?.
>>
>> Anything using linux-yocto has exactly the same packaging semantics as
>> other kernels, since they all inherit kernel.bbclass.
>>
>> Maybe your description sounds familiar to others, and others that might
>> have better ideas about what's happening in the packaging backend ?
>>
>> You don't have any special partitions configured ? You are building
>> on a local filesystem ? Is rpm or ipkg being used ? .. these are all
>> things that could impact performance (but not really 15 hours worth of
>> issues).
>>
>> Are there any hints in the host system logs, or in the kernels do_install
>> log ?
>>
>> Bruce
>>
>>>
>>> Best Regards,
>>> Om Prakash Pal
>>> ________________________________________
>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>> Sent: Thursday, May 03, 2012 5:59 PM
>>> To: Om Prakash PAL
>>> Cc: Bruce Ashfield; yocto@yoctoproject.org
>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>
>>> On 12-05-03 05:24 AM, Om Prakash PAL wrote:
>>>> Hi Bruce,
>>>> Thanks a lot for your help.
>>>> Now I am able to build the local kernel.
>>>
>>> Great!
>>>
>>>> I have one doublt:
>>>> when I do
>>>> bitbake -c mencuconfig virtual/kernel
>>>>
>>>> then from which location it will take the config file?.
>>>> and if I want to buiild my own specific defconfig file then How can do it?.
>>>
>>> It will use the .config in the build directory ${B}, which if you
>>> are using a linux-yocto recipe would be your
>>> linux-$MACHINE-$KERNELTYPE-build
>>> directory.
>>>
>>> The dependencies of menuconfig will ensure that the kernel has been fetched,
>>> unpacked and configured before it runs. Which means a defconfig will
>>> have already been used (if specified) to construct the .config.
>>>
>>> Any changes you make will be saved in the .config, and you'll need to
>>> preserve that for future builds.
>>>
>>> Cheers,
>>>
>>> Bruce
>>>
>>>>
>>>> Best Regards,
>>>> Om Prakash Pal
>>>> ________________________________________
>>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>>> Sent: Monday, April 30, 2012 7:42 PM
>>>> To: Om Prakash PAL
>>>> Cc: Bruce Ashfield; yocto@yoctoproject.org
>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>
>>>> On 12-04-30 6:34 AM, Om Prakash PAL wrote:
>>>>>> On 12-04-29 5:58 AM, Om Prakash PAL wrote:
>>>>>
>>>>>        >     Hi Bruce,
>>>>>         >for porting of our local kernel,we have created an BSP layer and to change the the
>>>>>         >kernel,  we have created an linux-yocto_3.0.bbappend file inside
>>>>>         >meta<BSP>/recipes-kernel/linux/
>>>>>         >like this:-
>>>>>
>>>>>         >FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>>>>
>>>>>        >     COMPATIBLE_MACHINE_<BSP_name>      = "BSP_name"
>>>>>
>>>>>         ># KMACHINE is the branch to build
>>>>>         >KMACHINE_<BSP_name>      = "local_branch"
>>>>>
>>>>>        >     SRCREV_machine_pn_linux-yocto_<BSP_name>      ?= "XXXXXXXX" (here we have assign
>>>>>         >top commit ID of our local kernel)
>>>>>
>>>>>
>>>>>         ># KSRC_linux_yocto to point to your local clone as appropriate.
>>>>>         >KSRC_linux_yocto ?= "/path/to/local/kernel"
>>>>>
>>>>>         >SRC_URI =
>>>>>         >"git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH};name=machine
>>>>>          >\
>>>>>            >                  file://defconfig"
>>>>>
>>>>>
>>>>>         >KERNEL_REVISION_CHECKING=""
>>>>>         >SRCREV="${AUTOREV}"
>>>>>         >#BB_LOCALCOUNT_OVERRIDE = "1"
>>>>>         >LOCALCOUNT = "0"
>>>>>
>>>>>
>>>>>         >while building we are getting following Error:
>>>>>
>>>>>         >NOTE: Executing RunQueue Tasks
>>>>>         >NOTE: Running task 1341 of 1710 (ID: 513,
>>>>>         >/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb,
>>>>>          >do_validate_branches)
>>>>>         >NOTE: package
>>>>>         >linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2: task
>>>>>         >do_validate_branches: Started
>>>>>         >ERROR: Function 'do_validate_branches' failed (see
>>>>>         >/home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/temp/log.do_validate_branches.16792
>>>>>          >for further information)
>>>>>
>>>>>
>>>>>         >please tell me what we have done wrong?.
>>>>>         >is there anything else we need to modify in .bbappend file or some other
>>>>>         >variable?.
>>>>>
>>>>>> Which release are you using again ?
>>>>>       I am using 6.0.0 Edision
>>>>>
>>>>>> The diagnostics out of validate branches are about to get better in master,
>>>>>> but they are coupled with some other tools changes that couldn't go
>>>>>> into yocto 1.2.
>>>>>
>>>>>> Is there anything extra in the log file, or just what you saw on the
>>>>>> build log ?.
>>>>> actually I have set YOCTO_KERNEL_EXTERNAL_BRANCH ="dev";(dev is my local brach)
>>>>> Now this Error has gone and now I am getting
>>>>>
>>>>> ERROR: Function 'do_patch' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008 for further information)
>>>>> ERROR: Logfile of failure stored in: /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008
>>>>> Log data follows:
>>>>> | ERROR. meta data not found, check upstream repo for tags and branches
>>>>> | ERROR: Function 'do_patch' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008 for further information)
>>>>> NOTE: package linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3: task do_patch: Failed
>>>>> ERROR: Task 516 (/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_patch) failed with exit code '1'
>>>>> ERROR: '/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb' failed
>>>>>
>>>>
>>>> This is what I was saying a few weeks ago. If you aren't using
>>>> the linux-yocto kernel repository (and hence linux-yocto branches/meta
>>>> data) as your base, then building directly via the linux-yocto recipe
>>>> probably isn't what you want. It is a recipe that leverages the tools
>>>> and infrastructure on top of the linux-yocto repository.
>>>>
>>>> That same infrastructure can build other repositories, but needs some
>>>> extra variables set. The meta-kernel-dev layer, in poky-extras has
>>>> examples of this for building korg (or any repo) with the tools.
>>>>
>>>> What you re being told in this particular error is that you don't have
>>>> a meta branch in the tree, or not one that the tools can recognize.
>>>> You can prevent this by setting YOCTO_KERNEL_META_DATA="" in your
>>>> recipe (see the korg recipe as an example). (and FYI: this will no
>>>> longer be required in 1.3, but it is for any previous release.
>>>>>
>>>>>> Validate branches fails like this when you've provided a bad branch or
>>>>>> SRCREV (vs a SRCREV that is simply not the tip of the branch .. it fixes
>>>>>> hat scenario) and the fetcher or another git command aborts.
>>>>>
>>>>>> You've output some example text from the bbappend, but what were the real
>>>>>> values in your situation ? i.e. what are KMACHINE/KBRANCH set to ?.
>>>>>
>>>>> I have not set the value of KBRANCH?. what it should be ?.
>>>>
>>>> It needs to be a valid branch in the repository. The 1.2 recipes
>>>> set it to be KMACHINE if it hasn't been explicitly set. But it
>>>> sounds like you are past this, and have set your branch to something
>>>> that actually exists in the tree.
>>>>
>>>> Cheers,
>>>>
>>>> Bruce
>>>>
>>>>>
>>>>>> There are some flags you can set to exit the branch validation early, but
>>>>>> I don't think setting them is the right course of action yet, since the
>>>>>> error you are seeing is likely hiding some other mis configuration.
>>>>>
>>>>>> Cheers,
>>>>>
>>>>>> Bruce
>>>>>
>>>>> Best Regards,
>>>>> Om Prakash Pal
>>>>> ________________________________________
>>>>> From: Om Prakash PAL
>>>>> Sent: Sunday, April 29, 2012 3:28 PM
>>>>> To: Bruce Ashfield
>>>>> Cc: yocto@yoctoproject.org
>>>>> Subject: RE: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>>
>>>>> Hi Bruce,
>>>>> for porting of our local kernel,we have created an BSP layer and to change the the kernel,  we have created an linux-yocto_3.0.bbappend file inside meta<BSP>/recipes-kernel/linux/
>>>>> like this:-
>>>>>
>>>>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>>>>
>>>>> COMPATIBLE_MACHINE_<BSP_name>     = "BSP_name"
>>>>>
>>>>> # KMACHINE is the branch to build
>>>>> KMACHINE_<BSP_name>     = "local_branch"
>>>>>
>>>>> SRCREV_machine_pn_linux-yocto_<BSP_name>     ?= "XXXXXXXX" (here we have assign top commit ID of our local kernel)
>>>>>
>>>>>
>>>>> # KSRC_linux_yocto to point to your local clone as appropriate.
>>>>> KSRC_linux_yocto ?= "/path/to/local/kernel"
>>>>>
>>>>> SRC_URI = "git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH};name=machine \
>>>>>                     file://defconfig"
>>>>>
>>>>>
>>>>> KERNEL_REVISION_CHECKING=""
>>>>> SRCREV="${AUTOREV}"
>>>>> #BB_LOCALCOUNT_OVERRIDE = "1"
>>>>> LOCALCOUNT = "0"
>>>>>
>>>>>
>>>>> while building we are getting following Error:
>>>>>
>>>>> NOTE: Executing RunQueue Tasks
>>>>> NOTE: Running task 1341 of 1710 (ID: 513, /home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_validate_branches)
>>>>> NOTE: package linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2: task do_validate_branches: Started
>>>>> ERROR: Function 'do_validate_branches' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/temp/log.do_validate_branches.16792 for further information)
>>>>>
>>>>>
>>>>> please tell me what we have done wrong?.
>>>>> is there anything else we need to modify in .bbappend file or some other variable?.
>>>>>
>>>>> Best Regards,
>>>>> Om Prakash Pal
>>>>> ________________________________________
>>>>> From: Bruce Ashfield [bruce.ashfield@gmail.com]
>>>>> Sent: Monday, April 09, 2012 11:04 PM
>>>>> To: Om Prakash PAL
>>>>> Cc: yocto@yoctoproject.org
>>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>>
>>>>> On Mon, Apr 9, 2012 at 12:31 PM, Om Prakash PAL
>>>>> <omprakash.pal@stericsson.com>     wrote:
>>>>>> Hi Bruce,
>>>>>> Thanks for you help.
>>>>>> As you have mentioned, its working properly.
>>>>>> I want to know that is there any better way of doing same thing for my scenario ?:
>>>>>> here is my scenario:
>>>>>> We have development branch where we write/modify our kernel/driver code i.e. thats our local kernel repository(git rep)
>>>>>> and lots of driver/files being modified everyday-->so I have to take the same effect into yocto kernel also---->     so except  creating patches for all modified drivers and creating .bbappend files, is there any better way of doing same thing .
>>>>>
>>>>> Aha. Missed that.
>>>>>
>>>>> Just create a simple recipe that points at your git repository in the SRC_URI.
>>>>> If all the changes are in the tree, and you have a defconfig and you
>>>>> are building
>>>>> the master branch. Then pretty much everything you need can be specified in
>>>>> the SRC_URI .. and that's the entire recipe.
>>>>>
>>>>> If you look in oe-classic, meta-ti or any one of a number of other
>>>>> layers, you'll
>>>>> find recipes that do just that.
>>>>>
>>>>> The meta-kernel-dev (in the poky extras) layer has an example of using the
>>>>> kernel.org tree with the yocto kern tools, and once yocto 1.3 opens up for
>>>>> submissions, I have a set of changes prep'd that make it relatively simple to
>>>>> use the yocto kern tools against different types of repository.
>>>>>
>>>>> So the summary is: Depending on the type of tooling you need, and what baseline
>>>>> you need for your work .. there are a number of ways to do things.
>>>>>
>>>>>>
>>>>>> Is there anyway that  instead of using yocto-kernel tree,  can we use our local kernel-tree for building images?. (should  I create separate BSP ?)
>>>>>
>>>>> You should definitely create a BSP, that way you can tune the system specific
>>>>> to your board,
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Bruce
>>>>>
>>>>>>
>>>>>> Thanks in advance.
>>>>>> Best Regards,
>>>>>> Om Prakash Pal
>>>>>> ________________________________________
>>>>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>>>>> Sent: Monday, April 09, 2012 9:32 AM
>>>>>> To: Om Prakash PAL
>>>>>> Cc: yocto@yoctoproject.org
>>>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>>>
>>>>>> On 12-04-08 10:04 AM, Om Prakash PAL wrote:
>>>>>>> Hi Bruce,
>>>>>>> Thanks for your reply.
>>>>>>> I am totally new to Yocto.
>>>>>>> I have gone through the section BSP/Linux kernel configuration and if I am not wrong then it explains how can we configure the kernel, not the how we can add/replace a  component(driver etc).
>>>>>>> lets take the example of UART driver, I want to add my own UART driver code.
>>>>>>> Should I write a separate recipe file (.bb) for UART Driver?.
>>>>>>> if yes then I have to write the recipe files for all my drivers that will be very time consuming.
>>>>>>> Is there any other way that I can port all my desired drivers into Yocto kernel?.
>>>>>>
>>>>>> No recipes are required per-driver, unless you are building them all
>>>>>> as out of tree modules.
>>>>>>
>>>>>> The typical way this is done is to simply work in the extracted linux
>>>>>> src tree (build/tmp/work/<your board>/linux-yocto-<hashes>/linux), manually
>>>>>> patch, or copy your drivers into the tree. At this point, you'll port
>>>>>> the drivers, doing test builds (bitbake -f -c compile linux-yocto) to
>>>>>> ensure that your port is working. When you've completed the build phase,
>>>>>> boot tests would be in order. (Do not do a 'clean' or you'll lose in
>>>>>> progress changes).
>>>>>>
>>>>>> When you are happy with the changes, the directory where you were working
>>>>>> is with the kernel git repository. So you can simply commit your
>>>>>> changes, and generate patches.
>>>>>>
>>>>>>        git format-patch -o<your directory>     HEAD^ (or however many commits
>>>>>> you have)
>>>>>>
>>>>>> Take those patches, create a layer with a bbappend and add them like
>>>>>> any other patch to any package. They'll be applied to subsequent builds
>>>>>> of the kernel.
>>>>>>
>>>>>> I'm skipping a lot of detail there, but it is all found in the various
>>>>>> manuals, and I don't want to repeat it here.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Bruce
>>>>>>
>>>>>>> Please help me.
>>>>>>> Thanks a lot in advance.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>> Om Prakash Pal
>>>>>>> ________________________________________
>>>>>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>>>>>> Sent: Wednesday, April 04, 2012 6:17 PM
>>>>>>> To: Om Prakash PAL
>>>>>>> Cc: yocto@yoctoproject.org
>>>>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>>>>
>>>>>>> On 12-04-04 04:46 AM, Om Prakash PAL wrote:
>>>>>>>> Hi,
>>>>>>>> I want to build my local kernel/Driver code, not the default one.
>>>>>>>> please help how can i do it ?.
>>>>>>>> any wiki/docs on this?.
>>>>>>>
>>>>>>> The BSP developer guides show how to extend the yocto kernels, and
>>>>>>> also have sections on custom/different kernel versions. Have you
>>>>>>> seen that doc yet ? Or have you seen it, and have specific questions ?
>>>>>>>
>>>>>>> Bruce
>>>>>>>
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>> Om Prakash Pal
>>>>>>>> _______________________________________________
>>>>>>>> yocto mailing list
>>>>>>>> yocto@yoctoproject.org
>>>>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> yocto mailing list
>>>>>> yocto@yoctoproject.org
>>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> "Thou shalt not follow the NULL pointer, for chaos and madness await
>>>>> thee at its end"
>>>>> _______________________________________________
>>>>> yocto mailing list
>>>>> yocto@yoctoproject.org
>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>
>>>
>>
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>
> --
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Linux Kernel
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Porting of specific Kernel/Driver into yocto.

[Om Prakash PAL]

----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Gary Thomas
Sent: Thursday, June 21, 2012 6:18 PM
To: yocto@yoctoproject.org
Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.

On 2012-06-21 06:27, Om Prakash PAL wrote:
> ________________________________________
> From: Darren Hart [darren.hart@intel.com]
> Sent: Wednesday, May 23, 2012 11:46 PM
> To: Om Prakash PAL
> Cc: Bruce Ashfield; yocto@yoctoproject.org; Richard Purdie
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>
> On 05/23/2012 05:39 AM, Om Prakash PAL wrote:
>> Hi Bruce,
>>
>> [ I am using "poky-edison-6.0" ]
>> I am able to create my rootfs and uImage but when I flashed these on my board,
>> while booting I am getting below Error and console get blocked.
>>
>> =========================================================
>> [    3.575805] EXT3-fs (mmcblk0p1): using internal journal
>> [    3.581054] EXT3-fs (mmcblk0p1): mounted filesystem with writeback data mode
>> [    3.588165] VFS: Mounted root (ext3 filesystem) on device 179:1.
>> [    3.594268] Freeing init memory: 312K
>> INIT: version 2.88 booting
>>
>> Please wait: booting...
>> Starting udev
>> Starting Bootlog daemon: bootlogd: cannot deduce real console device
>> bootlogd.
>> Configuring network interfaces... ifconfig: SIOCGIFFLAGS: No such device
>> done.
>> Fri May 11 11:29:00 UTC 2012
>> Running postinst /etc/rpm-postinsts/*.sh...
>> ERROR: postinst /etc/rpm-postinsts/*.sh failed.
>
> Does this error repeat if you reboot?
> Yes, every time.

>What image is being used?  I've seen this with core-image-minimal, but it
>goes away when the image is more complex, e.g. core-image-sato.  I believe
>the init script is always present even if there are no postinst scripts to run.

I am also building core-image-minimal.
Is there any problem with this?.
Should I build core-image-sato?.

>
>> INIT: Entering runlevel: 5
>> Starting syslogd/klogd: done
>> Stopping Bootlog daemon: bootlogd.
>> [    9.737091] av8100_hdmi av8100_hdmi.3: HDMI display probed
>>
>> =========================================================
>> and after that it got stuck, I am not getting console.
>
> How long do you let it sit?
>
> after some time(around 10mins) got this msg;
> INIT: Id "1" respawning too fast: disabled for 5 minutes
> INIT: no more processes left in this runlevel
>
> and then console got  stuck.

>What do you have SERIAL_CONSOLE set to in your configuration?

I have set SERIAL_CONSOLE="115200 ttyAMA2". As we are using ttyAMA2 for console.
>>
>> I am building rootfs/uImage with default toolchain used in yocto.
>> Is it problem of toolchain?.
>> Should I build with our toolchain( we use CodeSourcery)?.
>
> Nothing above suggests a toolchain problem. You have an error running
> the postinst scripts from the various rpm packages. Some instrumentation
> in those scripts (and the parent script) would help narrow down where it
> is failing.
>
> --
> Darren
>
>>
>> Best Regards,
>> Om Prakash Pal
>> ________________________________________
>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>> Sent: Sunday, May 06, 2012 6:00 PM
>> To: Om Prakash PAL
>> Cc: Bruce Ashfield; yocto@yoctoproject.org; Richard Purdie
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> On 12-05-06 5:43 AM, Om Prakash PAL wrote:
>>> Hi Bruce,
>>> I am getting some problem in do_install:
>>>
>>> NOTE: Running task 1535 of 1710 (ID: 517, /home/apallan/yocto/poky-edison-6.0/meta-u8500/recipes-kernel/linux/linux-u8500.bb, do_install)
>>> NOTE: package linux-u8500-3.2+git1+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r10: task do_install: Started
>>>
>>> and I waited for ~15hr to complete task do_install: but not completed and i am not getting any Errors/warnings.
>>> Is there any problem?.
>>> I have checked that my vmlinux/uImage/zImage has been created successfully but rootfs has not been created till now.
>>>
>>> here is my .bb file that is building my local_kernel.
>>>
>>> inherit kernel
>>> require recipes-kernel/linux/linux-yocto.inc
>>>
>>> KMACHINE = "dev"
>>> YOCTO_KERNEL_EXTERNAL_BRANCH ?= "dev"
>>>
>>> KBRANCH = "${KMACHINE}"
>>> KMETA = "meta"
>>>
>>> KSRC_linux_yocto ?= "/home/apallan/yocto/kernel/"
>>>
>>> SRC_URI = "git://${KSRC_linux_yocto};protocol=file;nocheckout=1"
>>> SRC_URI +="file://defconfig"
>>>
>>> SRCREV="${AUTOREV}"
>>> SRCREV_pn-linux-u8500 ="0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383"
>>>
>>> LINUX_VERSION ?= "3.2"
>>> LINUX_VERSION_EXTENSION = "-yoctized-${LINUX_KERNEL_TYPE}"
>>> PR = "r10"
>>> PV = "${LINUX_VERSION}+git${SRCPV}"
>>>
>>> COMPATIBLE_MACHINE = "(u8500|qemuarm)"
>>>
>>> # Functionality flags
>>> KERNEL_REVISION_CHECKING=""
>>> YOCTO_KERNEL_META_DATA=""
>>>
>>> require recipes-kernel/linux/linux-tools.inc
>>>
>>> what should be the problem?.
>>
>> Anything using linux-yocto has exactly the same packaging semantics as
>> other kernels, since they all inherit kernel.bbclass.
>>
>> Maybe your description sounds familiar to others, and others that might
>> have better ideas about what's happening in the packaging backend ?
>>
>> You don't have any special partitions configured ? You are building
>> on a local filesystem ? Is rpm or ipkg being used ? .. these are all
>> things that could impact performance (but not really 15 hours worth of
>> issues).
>>
>> Are there any hints in the host system logs, or in the kernels do_install
>> log ?
>>
>> Bruce
>>
>>>
>>> Best Regards,
>>> Om Prakash Pal
>>> ________________________________________
>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>> Sent: Thursday, May 03, 2012 5:59 PM
>>> To: Om Prakash PAL
>>> Cc: Bruce Ashfield; yocto@yoctoproject.org
>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>
>>> On 12-05-03 05:24 AM, Om Prakash PAL wrote:
>>>> Hi Bruce,
>>>> Thanks a lot for your help.
>>>> Now I am able to build the local kernel.
>>>
>>> Great!
>>>
>>>> I have one doublt:
>>>> when I do
>>>> bitbake -c mencuconfig virtual/kernel
>>>>
>>>> then from which location it will take the config file?.
>>>> and if I want to buiild my own specific defconfig file then How can do it?.
>>>
>>> It will use the .config in the build directory ${B}, which if you
>>> are using a linux-yocto recipe would be your
>>> linux-$MACHINE-$KERNELTYPE-build
>>> directory.
>>>
>>> The dependencies of menuconfig will ensure that the kernel has been fetched,
>>> unpacked and configured before it runs. Which means a defconfig will
>>> have already been used (if specified) to construct the .config.
>>>
>>> Any changes you make will be saved in the .config, and you'll need to
>>> preserve that for future builds.
>>>
>>> Cheers,
>>>
>>> Bruce
>>>
>>>>
>>>> Best Regards,
>>>> Om Prakash Pal
>>>> ________________________________________
>>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>>> Sent: Monday, April 30, 2012 7:42 PM
>>>> To: Om Prakash PAL
>>>> Cc: Bruce Ashfield; yocto@yoctoproject.org
>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>
>>>> On 12-04-30 6:34 AM, Om Prakash PAL wrote:
>>>>>> On 12-04-29 5:58 AM, Om Prakash PAL wrote:
>>>>>
>>>>>        >     Hi Bruce,
>>>>>         >for porting of our local kernel,we have created an BSP layer and to change the the
>>>>>         >kernel,  we have created an linux-yocto_3.0.bbappend file inside
>>>>>         >meta<BSP>/recipes-kernel/linux/
>>>>>         >like this:-
>>>>>
>>>>>         >FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>>>>
>>>>>        >     COMPATIBLE_MACHINE_<BSP_name>      = "BSP_name"
>>>>>
>>>>>         ># KMACHINE is the branch to build
>>>>>         >KMACHINE_<BSP_name>      = "local_branch"
>>>>>
>>>>>        >     SRCREV_machine_pn_linux-yocto_<BSP_name>      ?= "XXXXXXXX" (here we have assign
>>>>>         >top commit ID of our local kernel)
>>>>>
>>>>>
>>>>>         ># KSRC_linux_yocto to point to your local clone as appropriate.
>>>>>         >KSRC_linux_yocto ?= "/path/to/local/kernel"
>>>>>
>>>>>         >SRC_URI =
>>>>>         >"git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH};name=machine
>>>>>          >\
>>>>>            >                  file://defconfig"
>>>>>
>>>>>
>>>>>         >KERNEL_REVISION_CHECKING=""
>>>>>         >SRCREV="${AUTOREV}"
>>>>>         >#BB_LOCALCOUNT_OVERRIDE = "1"
>>>>>         >LOCALCOUNT = "0"
>>>>>
>>>>>
>>>>>         >while building we are getting following Error:
>>>>>
>>>>>         >NOTE: Executing RunQueue Tasks
>>>>>         >NOTE: Running task 1341 of 1710 (ID: 513,
>>>>>         >/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb,
>>>>>          >do_validate_branches)
>>>>>         >NOTE: package
>>>>>         >linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2: task
>>>>>         >do_validate_branches: Started
>>>>>         >ERROR: Function 'do_validate_branches' failed (see
>>>>>         >/home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/temp/log.do_validate_branches.16792
>>>>>          >for further information)
>>>>>
>>>>>
>>>>>         >please tell me what we have done wrong?.
>>>>>         >is there anything else we need to modify in .bbappend file or some other
>>>>>         >variable?.
>>>>>
>>>>>> Which release are you using again ?
>>>>>       I am using 6.0.0 Edision
>>>>>
>>>>>> The diagnostics out of validate branches are about to get better in master,
>>>>>> but they are coupled with some other tools changes that couldn't go
>>>>>> into yocto 1.2.
>>>>>
>>>>>> Is there anything extra in the log file, or just what you saw on the
>>>>>> build log ?.
>>>>> actually I have set YOCTO_KERNEL_EXTERNAL_BRANCH ="dev";(dev is my local brach)
>>>>> Now this Error has gone and now I am getting
>>>>>
>>>>> ERROR: Function 'do_patch' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008 for further information)
>>>>> ERROR: Logfile of failure stored in: /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008
>>>>> Log data follows:
>>>>> | ERROR. meta data not found, check upstream repo for tags and branches
>>>>> | ERROR: Function 'do_patch' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008 for further information)
>>>>> NOTE: package linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3: task do_patch: Failed
>>>>> ERROR: Task 516 (/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_patch) failed with exit code '1'
>>>>> ERROR: '/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb' failed
>>>>>
>>>>
>>>> This is what I was saying a few weeks ago. If you aren't using
>>>> the linux-yocto kernel repository (and hence linux-yocto branches/meta
>>>> data) as your base, then building directly via the linux-yocto recipe
>>>> probably isn't what you want. It is a recipe that leverages the tools
>>>> and infrastructure on top of the linux-yocto repository.
>>>>
>>>> That same infrastructure can build other repositories, but needs some
>>>> extra variables set. The meta-kernel-dev layer, in poky-extras has
>>>> examples of this for building korg (or any repo) with the tools.
>>>>
>>>> What you re being told in this particular error is that you don't have
>>>> a meta branch in the tree, or not one that the tools can recognize.
>>>> You can prevent this by setting YOCTO_KERNEL_META_DATA="" in your
>>>> recipe (see the korg recipe as an example). (and FYI: this will no
>>>> longer be required in 1.3, but it is for any previous release.
>>>>>
>>>>>> Validate branches fails like this when you've provided a bad branch or
>>>>>> SRCREV (vs a SRCREV that is simply not the tip of the branch .. it fixes
>>>>>> hat scenario) and the fetcher or another git command aborts.
>>>>>
>>>>>> You've output some example text from the bbappend, but what were the real
>>>>>> values in your situation ? i.e. what are KMACHINE/KBRANCH set to ?.
>>>>>
>>>>> I have not set the value of KBRANCH?. what it should be ?.
>>>>
>>>> It needs to be a valid branch in the repository. The 1.2 recipes
>>>> set it to be KMACHINE if it hasn't been explicitly set. But it
>>>> sounds like you are past this, and have set your branch to something
>>>> that actually exists in the tree.
>>>>
>>>> Cheers,
>>>>
>>>> Bruce
>>>>
>>>>>
>>>>>> There are some flags you can set to exit the branch validation early, but
>>>>>> I don't think setting them is the right course of action yet, since the
>>>>>> error you are seeing is likely hiding some other mis configuration.
>>>>>
>>>>>> Cheers,
>>>>>
>>>>>> Bruce
>>>>>
>>>>> Best Regards,
>>>>> Om Prakash Pal
>>>>> ________________________________________
>>>>> From: Om Prakash PAL
>>>>> Sent: Sunday, April 29, 2012 3:28 PM
>>>>> To: Bruce Ashfield
>>>>> Cc: yocto@yoctoproject.org
>>>>> Subject: RE: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>>
>>>>> Hi Bruce,
>>>>> for porting of our local kernel,we have created an BSP layer and to change the the kernel,  we have created an linux-yocto_3.0.bbappend file inside meta<BSP>/recipes-kernel/linux/
>>>>> like this:-
>>>>>
>>>>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>>>>
>>>>> COMPATIBLE_MACHINE_<BSP_name>     = "BSP_name"
>>>>>
>>>>> # KMACHINE is the branch to build
>>>>> KMACHINE_<BSP_name>     = "local_branch"
>>>>>
>>>>> SRCREV_machine_pn_linux-yocto_<BSP_name>     ?= "XXXXXXXX" (here we have assign top commit ID of our local kernel)
>>>>>
>>>>>
>>>>> # KSRC_linux_yocto to point to your local clone as appropriate.
>>>>> KSRC_linux_yocto ?= "/path/to/local/kernel"
>>>>>
>>>>> SRC_URI = "git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH};name=machine \
>>>>>                     file://defconfig"
>>>>>
>>>>>
>>>>> KERNEL_REVISION_CHECKING=""
>>>>> SRCREV="${AUTOREV}"
>>>>> #BB_LOCALCOUNT_OVERRIDE = "1"
>>>>> LOCALCOUNT = "0"
>>>>>
>>>>>
>>>>> while building we are getting following Error:
>>>>>
>>>>> NOTE: Executing RunQueue Tasks
>>>>> NOTE: Running task 1341 of 1710 (ID: 513, /home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_validate_branches)
>>>>> NOTE: package linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2: task do_validate_branches: Started
>>>>> ERROR: Function 'do_validate_branches' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/temp/log.do_validate_branches.16792 for further information)
>>>>>
>>>>>
>>>>> please tell me what we have done wrong?.
>>>>> is there anything else we need to modify in .bbappend file or some other variable?.
>>>>>
>>>>> Best Regards,
>>>>> Om Prakash Pal
>>>>> ________________________________________
>>>>> From: Bruce Ashfield [bruce.ashfield@gmail.com]
>>>>> Sent: Monday, April 09, 2012 11:04 PM
>>>>> To: Om Prakash PAL
>>>>> Cc: yocto@yoctoproject.org
>>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>>
>>>>> On Mon, Apr 9, 2012 at 12:31 PM, Om Prakash PAL
>>>>> <omprakash.pal@stericsson.com>     wrote:
>>>>>> Hi Bruce,
>>>>>> Thanks for you help.
>>>>>> As you have mentioned, its working properly.
>>>>>> I want to know that is there any better way of doing same thing for my scenario ?:
>>>>>> here is my scenario:
>>>>>> We have development branch where we write/modify our kernel/driver code i.e. thats our local kernel repository(git rep)
>>>>>> and lots of driver/files being modified everyday-->so I have to take the same effect into yocto kernel also---->     so except  creating patches for all modified drivers and creating .bbappend files, is there any better way of doing same thing .
>>>>>
>>>>> Aha. Missed that.
>>>>>
>>>>> Just create a simple recipe that points at your git repository in the SRC_URI.
>>>>> If all the changes are in the tree, and you have a defconfig and you
>>>>> are building
>>>>> the master branch. Then pretty much everything you need can be specified in
>>>>> the SRC_URI .. and that's the entire recipe.
>>>>>
>>>>> If you look in oe-classic, meta-ti or any one of a number of other
>>>>> layers, you'll
>>>>> find recipes that do just that.
>>>>>
>>>>> The meta-kernel-dev (in the poky extras) layer has an example of using the
>>>>> kernel.org tree with the yocto kern tools, and once yocto 1.3 opens up for
>>>>> submissions, I have a set of changes prep'd that make it relatively simple to
>>>>> use the yocto kern tools against different types of repository.
>>>>>
>>>>> So the summary is: Depending on the type of tooling you need, and what baseline
>>>>> you need for your work .. there are a number of ways to do things.
>>>>>
>>>>>>
>>>>>> Is there anyway that  instead of using yocto-kernel tree,  can we use our local kernel-tree for building images?. (should  I create separate BSP ?)
>>>>>
>>>>> You should definitely create a BSP, that way you can tune the system specific
>>>>> to your board,
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Bruce
>>>>>
>>>>>>
>>>>>> Thanks in advance.
>>>>>> Best Regards,
>>>>>> Om Prakash Pal
>>>>>> ________________________________________
>>>>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>>>>> Sent: Monday, April 09, 2012 9:32 AM
>>>>>> To: Om Prakash PAL
>>>>>> Cc: yocto@yoctoproject.org
>>>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>>>
>>>>>> On 12-04-08 10:04 AM, Om Prakash PAL wrote:
>>>>>>> Hi Bruce,
>>>>>>> Thanks for your reply.
>>>>>>> I am totally new to Yocto.
>>>>>>> I have gone through the section BSP/Linux kernel configuration and if I am not wrong then it explains how can we configure the kernel, not the how we can add/replace a  component(driver etc).
>>>>>>> lets take the example of UART driver, I want to add my own UART driver code.
>>>>>>> Should I write a separate recipe file (.bb) for UART Driver?.
>>>>>>> if yes then I have to write the recipe files for all my drivers that will be very time consuming.
>>>>>>> Is there any other way that I can port all my desired drivers into Yocto kernel?.
>>>>>>
>>>>>> No recipes are required per-driver, unless you are building them all
>>>>>> as out of tree modules.
>>>>>>
>>>>>> The typical way this is done is to simply work in the extracted linux
>>>>>> src tree (build/tmp/work/<your board>/linux-yocto-<hashes>/linux), manually
>>>>>> patch, or copy your drivers into the tree. At this point, you'll port
>>>>>> the drivers, doing test builds (bitbake -f -c compile linux-yocto) to
>>>>>> ensure that your port is working. When you've completed the build phase,
>>>>>> boot tests would be in order. (Do not do a 'clean' or you'll lose in
>>>>>> progress changes).
>>>>>>
>>>>>> When you are happy with the changes, the directory where you were working
>>>>>> is with the kernel git repository. So you can simply commit your
>>>>>> changes, and generate patches.
>>>>>>
>>>>>>        git format-patch -o<your directory>     HEAD^ (or however many commits
>>>>>> you have)
>>>>>>
>>>>>> Take those patches, create a layer with a bbappend and add them like
>>>>>> any other patch to any package. They'll be applied to subsequent builds
>>>>>> of the kernel.
>>>>>>
>>>>>> I'm skipping a lot of detail there, but it is all found in the various
>>>>>> manuals, and I don't want to repeat it here.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Bruce
>>>>>>
>>>>>>> Please help me.
>>>>>>> Thanks a lot in advance.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>> Om Prakash Pal
>>>>>>> ________________________________________
>>>>>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>>>>>> Sent: Wednesday, April 04, 2012 6:17 PM
>>>>>>> To: Om Prakash PAL
>>>>>>> Cc: yocto@yoctoproject.org
>>>>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>>>>
>>>>>>> On 12-04-04 04:46 AM, Om Prakash PAL wrote:
>>>>>>>> Hi,
>>>>>>>> I want to build my local kernel/Driver code, not the default one.
>>>>>>>> please help how can i do it ?.
>>>>>>>> any wiki/docs on this?.
>>>>>>>
>>>>>>> The BSP developer guides show how to extend the yocto kernels, and
>>>>>>> also have sections on custom/different kernel versions. Have you
>>>>>>> seen that doc yet ? Or have you seen it, and have specific questions ?
>>>>>>>
>>>>>>> Bruce
>>>>>>>
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>> Om Prakash Pal
>>>>>>>> _______________________________________________
>>>>>>>> yocto mailing list
>>>>>>>> yocto@yoctoproject.org
>>>>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> yocto mailing list
>>>>>> yocto@yoctoproject.org
>>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> "Thou shalt not follow the NULL pointer, for chaos and madness await
>>>>> thee at its end"
>>>>> _______________________________________________
>>>>> yocto mailing list
>>>>> yocto@yoctoproject.org
>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>
>>>
>>
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>
> --
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Linux Kernel
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

>--
>------------------------------------------------------------
>Gary Thomas                 |  Consulting for the
>MLB Associates              |    Embedded world
>------------------------------------------------------------
>_______________________________________________
>yocto mailing list
>yocto@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/yocto


Best Regards,
Om Prakash Pal

Re: Porting of specific Kernel/Driver into yocto.

[Gary Thomas]

On 2012-06-21 08:16, Om Prakash PAL wrote:
> ----Original Message-----
> From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Gary Thomas
> Sent: Thursday, June 21, 2012 6:18 PM
> To: yocto@yoctoproject.org
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>
> On 2012-06-21 06:27, Om Prakash PAL wrote:
>> ________________________________________
>> From: Darren Hart [darren.hart@intel.com]
>> Sent: Wednesday, May 23, 2012 11:46 PM
>> To: Om Prakash PAL
>> Cc: Bruce Ashfield; yocto@yoctoproject.org; Richard Purdie
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> On 05/23/2012 05:39 AM, Om Prakash PAL wrote:
>>> Hi Bruce,
>>>
>>> [ I am using "poky-edison-6.0" ]
>>> I am able to create my rootfs and uImage but when I flashed these on my board,
>>> while booting I am getting below Error and console get blocked.
>>>
>>> =========================================================
>>> [    3.575805] EXT3-fs (mmcblk0p1): using internal journal
>>> [    3.581054] EXT3-fs (mmcblk0p1): mounted filesystem with writeback data mode
>>> [    3.588165] VFS: Mounted root (ext3 filesystem) on device 179:1.
>>> [    3.594268] Freeing init memory: 312K
>>> INIT: version 2.88 booting
>>>
>>> Please wait: booting...
>>> Starting udev
>>> Starting Bootlog daemon: bootlogd: cannot deduce real console device
>>> bootlogd.
>>> Configuring network interfaces... ifconfig: SIOCGIFFLAGS: No such device
>>> done.
>>> Fri May 11 11:29:00 UTC 2012
>>> Running postinst /etc/rpm-postinsts/*.sh...
>>> ERROR: postinst /etc/rpm-postinsts/*.sh failed.
>>
>> Does this error repeat if you reboot?
>> Yes, every time.
>
>> What image is being used?  I've seen this with core-image-minimal, but it
>> goes away when the image is more complex, e.g. core-image-sato.  I believe
>> the init script is always present even if there are no postinst scripts to run.
>
> I am also building core-image-minimal.
> Is there any problem with this?.

No.  I think the error message is noise in this case.

> Should I build core-image-sato?.

Only if you want/need to - core-image-sato brings in a complete X desktop
environment, maybe not what you're after.

>
>>
>>> INIT: Entering runlevel: 5
>>> Starting syslogd/klogd: done
>>> Stopping Bootlog daemon: bootlogd.
>>> [    9.737091] av8100_hdmi av8100_hdmi.3: HDMI display probed
>>>
>>> =========================================================
>>> and after that it got stuck, I am not getting console.
>>
>> How long do you let it sit?
>>
>> after some time(around 10mins) got this msg;
>> INIT: Id "1" respawning too fast: disabled for 5 minutes
>> INIT: no more processes left in this runlevel
>>
>> and then console got  stuck.
>
>> What do you have SERIAL_CONSOLE set to in your configuration?
>
> I have set SERIAL_CONSOLE="115200 ttyAMA2". As we are using ttyAMA2 for console.

What is your target device?  Do you really have /dev/ttyAMA2 serial port??

>>>
>>> I am building rootfs/uImage with default toolchain used in yocto.
>>> Is it problem of toolchain?.
>>> Should I build with our toolchain( we use CodeSourcery)?.
>>
>> Nothing above suggests a toolchain problem. You have an error running
>> the postinst scripts from the various rpm packages. Some instrumentation
>> in those scripts (and the parent script) would help narrow down where it
>> is failing.
>>
>> --
>> Darren
>>
>>>
>>> Best Regards,
>>> Om Prakash Pal
>>> ________________________________________
>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>> Sent: Sunday, May 06, 2012 6:00 PM
>>> To: Om Prakash PAL
>>> Cc: Bruce Ashfield; yocto@yoctoproject.org; Richard Purdie
>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>
>>> On 12-05-06 5:43 AM, Om Prakash PAL wrote:
>>>> Hi Bruce,
>>>> I am getting some problem in do_install:
>>>>
>>>> NOTE: Running task 1535 of 1710 (ID: 517, /home/apallan/yocto/poky-edison-6.0/meta-u8500/recipes-kernel/linux/linux-u8500.bb, do_install)
>>>> NOTE: package linux-u8500-3.2+git1+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r10: task do_install: Started
>>>>
>>>> and I waited for ~15hr to complete task do_install: but not completed and i am not getting any Errors/warnings.
>>>> Is there any problem?.
>>>> I have checked that my vmlinux/uImage/zImage has been created successfully but rootfs has not been created till now.
>>>>
>>>> here is my .bb file that is building my local_kernel.
>>>>
>>>> inherit kernel
>>>> require recipes-kernel/linux/linux-yocto.inc
>>>>
>>>> KMACHINE = "dev"
>>>> YOCTO_KERNEL_EXTERNAL_BRANCH ?= "dev"
>>>>
>>>> KBRANCH = "${KMACHINE}"
>>>> KMETA = "meta"
>>>>
>>>> KSRC_linux_yocto ?= "/home/apallan/yocto/kernel/"
>>>>
>>>> SRC_URI = "git://${KSRC_linux_yocto};protocol=file;nocheckout=1"
>>>> SRC_URI +="file://defconfig"
>>>>
>>>> SRCREV="${AUTOREV}"
>>>> SRCREV_pn-linux-u8500 ="0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383"
>>>>
>>>> LINUX_VERSION ?= "3.2"
>>>> LINUX_VERSION_EXTENSION = "-yoctized-${LINUX_KERNEL_TYPE}"
>>>> PR = "r10"
>>>> PV = "${LINUX_VERSION}+git${SRCPV}"
>>>>
>>>> COMPATIBLE_MACHINE = "(u8500|qemuarm)"
>>>>
>>>> # Functionality flags
>>>> KERNEL_REVISION_CHECKING=""
>>>> YOCTO_KERNEL_META_DATA=""
>>>>
>>>> require recipes-kernel/linux/linux-tools.inc
>>>>
>>>> what should be the problem?.
>>>
>>> Anything using linux-yocto has exactly the same packaging semantics as
>>> other kernels, since they all inherit kernel.bbclass.
>>>
>>> Maybe your description sounds familiar to others, and others that might
>>> have better ideas about what's happening in the packaging backend ?
>>>
>>> You don't have any special partitions configured ? You are building
>>> on a local filesystem ? Is rpm or ipkg being used ? .. these are all
>>> things that could impact performance (but not really 15 hours worth of
>>> issues).
>>>
>>> Are there any hints in the host system logs, or in the kernels do_install
>>> log ?
>>>
>>> Bruce
>>>
>>>>
>>>> Best Regards,
>>>> Om Prakash Pal
>>>> ________________________________________
>>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>>> Sent: Thursday, May 03, 2012 5:59 PM
>>>> To: Om Prakash PAL
>>>> Cc: Bruce Ashfield; yocto@yoctoproject.org
>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>
>>>> On 12-05-03 05:24 AM, Om Prakash PAL wrote:
>>>>> Hi Bruce,
>>>>> Thanks a lot for your help.
>>>>> Now I am able to build the local kernel.
>>>>
>>>> Great!
>>>>
>>>>> I have one doublt:
>>>>> when I do
>>>>> bitbake -c mencuconfig virtual/kernel
>>>>>
>>>>> then from which location it will take the config file?.
>>>>> and if I want to buiild my own specific defconfig file then How can do it?.
>>>>
>>>> It will use the .config in the build directory ${B}, which if you
>>>> are using a linux-yocto recipe would be your
>>>> linux-$MACHINE-$KERNELTYPE-build
>>>> directory.
>>>>
>>>> The dependencies of menuconfig will ensure that the kernel has been fetched,
>>>> unpacked and configured before it runs. Which means a defconfig will
>>>> have already been used (if specified) to construct the .config.
>>>>
>>>> Any changes you make will be saved in the .config, and you'll need to
>>>> preserve that for future builds.
>>>>
>>>> Cheers,
>>>>
>>>> Bruce
>>>>
>>>>>
>>>>> Best Regards,
>>>>> Om Prakash Pal
>>>>> ________________________________________
>>>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>>>> Sent: Monday, April 30, 2012 7:42 PM
>>>>> To: Om Prakash PAL
>>>>> Cc: Bruce Ashfield; yocto@yoctoproject.org
>>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>>
>>>>> On 12-04-30 6:34 AM, Om Prakash PAL wrote:
>>>>>>> On 12-04-29 5:58 AM, Om Prakash PAL wrote:
>>>>>>
>>>>>>         >      Hi Bruce,
>>>>>>          >for porting of our local kernel,we have created an BSP layer and to change the the
>>>>>>          >kernel,  we have created an linux-yocto_3.0.bbappend file inside
>>>>>>          >meta<BSP>/recipes-kernel/linux/
>>>>>>          >like this:-
>>>>>>
>>>>>>          >FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>>>>>
>>>>>>         >      COMPATIBLE_MACHINE_<BSP_name>       = "BSP_name"
>>>>>>
>>>>>>          ># KMACHINE is the branch to build
>>>>>>          >KMACHINE_<BSP_name>       = "local_branch"
>>>>>>
>>>>>>         >      SRCREV_machine_pn_linux-yocto_<BSP_name>       ?= "XXXXXXXX" (here we have assign
>>>>>>          >top commit ID of our local kernel)
>>>>>>
>>>>>>
>>>>>>          ># KSRC_linux_yocto to point to your local clone as appropriate.
>>>>>>          >KSRC_linux_yocto ?= "/path/to/local/kernel"
>>>>>>
>>>>>>          >SRC_URI =
>>>>>>          >"git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH};name=machine
>>>>>>           >\
>>>>>>             >                   file://defconfig"
>>>>>>
>>>>>>
>>>>>>          >KERNEL_REVISION_CHECKING=""
>>>>>>          >SRCREV="${AUTOREV}"
>>>>>>          >#BB_LOCALCOUNT_OVERRIDE = "1"
>>>>>>          >LOCALCOUNT = "0"
>>>>>>
>>>>>>
>>>>>>          >while building we are getting following Error:
>>>>>>
>>>>>>          >NOTE: Executing RunQueue Tasks
>>>>>>          >NOTE: Running task 1341 of 1710 (ID: 513,
>>>>>>          >/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb,
>>>>>>           >do_validate_branches)
>>>>>>          >NOTE: package
>>>>>>          >linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2: task
>>>>>>          >do_validate_branches: Started
>>>>>>          >ERROR: Function 'do_validate_branches' failed (see
>>>>>>          >/home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/temp/log.do_validate_branches.16792
>>>>>>           >for further information)
>>>>>>
>>>>>>
>>>>>>          >please tell me what we have done wrong?.
>>>>>>          >is there anything else we need to modify in .bbappend file or some other
>>>>>>          >variable?.
>>>>>>
>>>>>>> Which release are you using again ?
>>>>>>        I am using 6.0.0 Edision
>>>>>>
>>>>>>> The diagnostics out of validate branches are about to get better in master,
>>>>>>> but they are coupled with some other tools changes that couldn't go
>>>>>>> into yocto 1.2.
>>>>>>
>>>>>>> Is there anything extra in the log file, or just what you saw on the
>>>>>>> build log ?.
>>>>>> actually I have set YOCTO_KERNEL_EXTERNAL_BRANCH ="dev";(dev is my local brach)
>>>>>> Now this Error has gone and now I am getting
>>>>>>
>>>>>> ERROR: Function 'do_patch' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008 for further information)
>>>>>> ERROR: Logfile of failure stored in: /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008
>>>>>> Log data follows:
>>>>>> | ERROR. meta data not found, check upstream repo for tags and branches
>>>>>> | ERROR: Function 'do_patch' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008 for further information)
>>>>>> NOTE: package linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3: task do_patch: Failed
>>>>>> ERROR: Task 516 (/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_patch) failed with exit code '1'
>>>>>> ERROR: '/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb' failed
>>>>>>
>>>>>
>>>>> This is what I was saying a few weeks ago. If you aren't using
>>>>> the linux-yocto kernel repository (and hence linux-yocto branches/meta
>>>>> data) as your base, then building directly via the linux-yocto recipe
>>>>> probably isn't what you want. It is a recipe that leverages the tools
>>>>> and infrastructure on top of the linux-yocto repository.
>>>>>
>>>>> That same infrastructure can build other repositories, but needs some
>>>>> extra variables set. The meta-kernel-dev layer, in poky-extras has
>>>>> examples of this for building korg (or any repo) with the tools.
>>>>>
>>>>> What you re being told in this particular error is that you don't have
>>>>> a meta branch in the tree, or not one that the tools can recognize.
>>>>> You can prevent this by setting YOCTO_KERNEL_META_DATA="" in your
>>>>> recipe (see the korg recipe as an example). (and FYI: this will no
>>>>> longer be required in 1.3, but it is for any previous release.
>>>>>>
>>>>>>> Validate branches fails like this when you've provided a bad branch or
>>>>>>> SRCREV (vs a SRCREV that is simply not the tip of the branch .. it fixes
>>>>>>> hat scenario) and the fetcher or another git command aborts.
>>>>>>
>>>>>>> You've output some example text from the bbappend, but what were the real
>>>>>>> values in your situation ? i.e. what are KMACHINE/KBRANCH set to ?.
>>>>>>
>>>>>> I have not set the value of KBRANCH?. what it should be ?.
>>>>>
>>>>> It needs to be a valid branch in the repository. The 1.2 recipes
>>>>> set it to be KMACHINE if it hasn't been explicitly set. But it
>>>>> sounds like you are past this, and have set your branch to something
>>>>> that actually exists in the tree.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Bruce
>>>>>
>>>>>>
>>>>>>> There are some flags you can set to exit the branch validation early, but
>>>>>>> I don't think setting them is the right course of action yet, since the
>>>>>>> error you are seeing is likely hiding some other mis configuration.
>>>>>>
>>>>>>> Cheers,
>>>>>>
>>>>>>> Bruce
>>>>>>
>>>>>> Best Regards,
>>>>>> Om Prakash Pal
>>>>>> ________________________________________
>>>>>> From: Om Prakash PAL
>>>>>> Sent: Sunday, April 29, 2012 3:28 PM
>>>>>> To: Bruce Ashfield
>>>>>> Cc: yocto@yoctoproject.org
>>>>>> Subject: RE: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>>>
>>>>>> Hi Bruce,
>>>>>> for porting of our local kernel,we have created an BSP layer and to change the the kernel,  we have created an linux-yocto_3.0.bbappend file inside meta<BSP>/recipes-kernel/linux/
>>>>>> like this:-
>>>>>>
>>>>>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>>>>>
>>>>>> COMPATIBLE_MACHINE_<BSP_name>      = "BSP_name"
>>>>>>
>>>>>> # KMACHINE is the branch to build
>>>>>> KMACHINE_<BSP_name>      = "local_branch"
>>>>>>
>>>>>> SRCREV_machine_pn_linux-yocto_<BSP_name>      ?= "XXXXXXXX" (here we have assign top commit ID of our local kernel)
>>>>>>
>>>>>>
>>>>>> # KSRC_linux_yocto to point to your local clone as appropriate.
>>>>>> KSRC_linux_yocto ?= "/path/to/local/kernel"
>>>>>>
>>>>>> SRC_URI = "git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH};name=machine \
>>>>>>                      file://defconfig"
>>>>>>
>>>>>>
>>>>>> KERNEL_REVISION_CHECKING=""
>>>>>> SRCREV="${AUTOREV}"
>>>>>> #BB_LOCALCOUNT_OVERRIDE = "1"
>>>>>> LOCALCOUNT = "0"
>>>>>>
>>>>>>
>>>>>> while building we are getting following Error:
>>>>>>
>>>>>> NOTE: Executing RunQueue Tasks
>>>>>> NOTE: Running task 1341 of 1710 (ID: 513, /home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_validate_branches)
>>>>>> NOTE: package linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2: task do_validate_branches: Started
>>>>>> ERROR: Function 'do_validate_branches' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/temp/log.do_validate_branches.16792 for further information)
>>>>>>
>>>>>>
>>>>>> please tell me what we have done wrong?.
>>>>>> is there anything else we need to modify in .bbappend file or some other variable?.
>>>>>>
>>>>>> Best Regards,
>>>>>> Om Prakash Pal
>>>>>> ________________________________________
>>>>>> From: Bruce Ashfield [bruce.ashfield@gmail.com]
>>>>>> Sent: Monday, April 09, 2012 11:04 PM
>>>>>> To: Om Prakash PAL
>>>>>> Cc: yocto@yoctoproject.org
>>>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>>>
>>>>>> On Mon, Apr 9, 2012 at 12:31 PM, Om Prakash PAL
>>>>>> <omprakash.pal@stericsson.com>      wrote:
>>>>>>> Hi Bruce,
>>>>>>> Thanks for you help.
>>>>>>> As you have mentioned, its working properly.
>>>>>>> I want to know that is there any better way of doing same thing for my scenario ?:
>>>>>>> here is my scenario:
>>>>>>> We have development branch where we write/modify our kernel/driver code i.e. thats our local kernel repository(git rep)
>>>>>>> and lots of driver/files being modified everyday-->so I have to take the same effect into yocto kernel also---->      so except  creating patches for all modified drivers and creating .bbappend files, is there any better way of doing same thing .
>>>>>>
>>>>>> Aha. Missed that.
>>>>>>
>>>>>> Just create a simple recipe that points at your git repository in the SRC_URI.
>>>>>> If all the changes are in the tree, and you have a defconfig and you
>>>>>> are building
>>>>>> the master branch. Then pretty much everything you need can be specified in
>>>>>> the SRC_URI .. and that's the entire recipe.
>>>>>>
>>>>>> If you look in oe-classic, meta-ti or any one of a number of other
>>>>>> layers, you'll
>>>>>> find recipes that do just that.
>>>>>>
>>>>>> The meta-kernel-dev (in the poky extras) layer has an example of using the
>>>>>> kernel.org tree with the yocto kern tools, and once yocto 1.3 opens up for
>>>>>> submissions, I have a set of changes prep'd that make it relatively simple to
>>>>>> use the yocto kern tools against different types of repository.
>>>>>>
>>>>>> So the summary is: Depending on the type of tooling you need, and what baseline
>>>>>> you need for your work .. there are a number of ways to do things.
>>>>>>
>>>>>>>
>>>>>>> Is there anyway that  instead of using yocto-kernel tree,  can we use our local kernel-tree for building images?. (should  I create separate BSP ?)
>>>>>>
>>>>>> You should definitely create a BSP, that way you can tune the system specific
>>>>>> to your board,
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Bruce
>>>>>>
>>>>>>>
>>>>>>> Thanks in advance.
>>>>>>> Best Regards,
>>>>>>> Om Prakash Pal
>>>>>>> ________________________________________
>>>>>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>>>>>> Sent: Monday, April 09, 2012 9:32 AM
>>>>>>> To: Om Prakash PAL
>>>>>>> Cc: yocto@yoctoproject.org
>>>>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>>>>
>>>>>>> On 12-04-08 10:04 AM, Om Prakash PAL wrote:
>>>>>>>> Hi Bruce,
>>>>>>>> Thanks for your reply.
>>>>>>>> I am totally new to Yocto.
>>>>>>>> I have gone through the section BSP/Linux kernel configuration and if I am not wrong then it explains how can we configure the kernel, not the how we can add/replace a  component(driver etc).
>>>>>>>> lets take the example of UART driver, I want to add my own UART driver code.
>>>>>>>> Should I write a separate recipe file (.bb) for UART Driver?.
>>>>>>>> if yes then I have to write the recipe files for all my drivers that will be very time consuming.
>>>>>>>> Is there any other way that I can port all my desired drivers into Yocto kernel?.
>>>>>>>
>>>>>>> No recipes are required per-driver, unless you are building them all
>>>>>>> as out of tree modules.
>>>>>>>
>>>>>>> The typical way this is done is to simply work in the extracted linux
>>>>>>> src tree (build/tmp/work/<your board>/linux-yocto-<hashes>/linux), manually
>>>>>>> patch, or copy your drivers into the tree. At this point, you'll port
>>>>>>> the drivers, doing test builds (bitbake -f -c compile linux-yocto) to
>>>>>>> ensure that your port is working. When you've completed the build phase,
>>>>>>> boot tests would be in order. (Do not do a 'clean' or you'll lose in
>>>>>>> progress changes).
>>>>>>>
>>>>>>> When you are happy with the changes, the directory where you were working
>>>>>>> is with the kernel git repository. So you can simply commit your
>>>>>>> changes, and generate patches.
>>>>>>>
>>>>>>>         git format-patch -o<your directory>      HEAD^ (or however many commits
>>>>>>> you have)
>>>>>>>
>>>>>>> Take those patches, create a layer with a bbappend and add them like
>>>>>>> any other patch to any package. They'll be applied to subsequent builds
>>>>>>> of the kernel.
>>>>>>>
>>>>>>> I'm skipping a lot of detail there, but it is all found in the various
>>>>>>> manuals, and I don't want to repeat it here.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Bruce
>>>>>>>
>>>>>>>> Please help me.
>>>>>>>> Thanks a lot in advance.
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>> Om Prakash Pal
>>>>>>>> ________________________________________
>>>>>>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>>>>>>> Sent: Wednesday, April 04, 2012 6:17 PM
>>>>>>>> To: Om Prakash PAL
>>>>>>>> Cc: yocto@yoctoproject.org
>>>>>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>>>>>
>>>>>>>> On 12-04-04 04:46 AM, Om Prakash PAL wrote:
>>>>>>>>> Hi,
>>>>>>>>> I want to build my local kernel/Driver code, not the default one.
>>>>>>>>> please help how can i do it ?.
>>>>>>>>> any wiki/docs on this?.
>>>>>>>>
>>>>>>>> The BSP developer guides show how to extend the yocto kernels, and
>>>>>>>> also have sections on custom/different kernel versions. Have you
>>>>>>>> seen that doc yet ? Or have you seen it, and have specific questions ?
>>>>>>>>
>>>>>>>> Bruce
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>> Om Prakash Pal
>>>>>>>>> _______________________________________________
>>>>>>>>> yocto mailing list
>>>>>>>>> yocto@yoctoproject.org
>>>>>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> yocto mailing list
>>>>>>> yocto@yoctoproject.org
>>>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> "Thou shalt not follow the NULL pointer, for chaos and madness await
>>>>>> thee at its end"
>>>>>> _______________________________________________
>>>>>> yocto mailing list
>>>>>> yocto@yoctoproject.org
>>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>> --
>> Darren Hart
>> Intel Open Source Technology Center
>> Yocto Project - Linux Kernel
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>> --
>> ------------------------------------------------------------
>> Gary Thomas                 |  Consulting for the
>> MLB Associates              |    Embedded world
>> ------------------------------------------------------------
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>
> Best Regards,
> Om Prakash Pal

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Porting of specific Kernel/Driver into yocto.

[McClintock Matthew-B29882]

Are you spawning a tty on a non-existent serial port?

-M

On Thu, Jun 21, 2012 at 9:28 AM, Gary Thomas <gary@mlbassoc.com> wrote:
> On 2012-06-21 08:16, Om Prakash PAL wrote:
>>
>> ----Original Message-----
>> From: yocto-bounces@yoctoproject.org
>> [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Gary Thomas
>> Sent: Thursday, June 21, 2012 6:18 PM
>> To: yocto@yoctoproject.org
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> On 2012-06-21 06:27, Om Prakash PAL wrote:
>>>
>>> ________________________________________
>>> From: Darren Hart [darren.hart@intel.com]
>>> Sent: Wednesday, May 23, 2012 11:46 PM
>>> To: Om Prakash PAL
>>> Cc: Bruce Ashfield; yocto@yoctoproject.org; Richard Purdie
>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>
>>> On 05/23/2012 05:39 AM, Om Prakash PAL wrote:
>>>>
>>>> Hi Bruce,
>>>>
>>>> [ I am using "poky-edison-6.0" ]
>>>> I am able to create my rootfs and uImage but when I flashed these on my
>>>> board,
>>>> while booting I am getting below Error and console get blocked.
>>>>
>>>> =========================================================
>>>> [    3.575805] EXT3-fs (mmcblk0p1): using internal journal
>>>> [    3.581054] EXT3-fs (mmcblk0p1): mounted filesystem with writeback
>>>> data mode
>>>> [    3.588165] VFS: Mounted root (ext3 filesystem) on device 179:1.
>>>> [    3.594268] Freeing init memory: 312K
>>>> INIT: version 2.88 booting
>>>>
>>>> Please wait: booting...
>>>> Starting udev
>>>> Starting Bootlog daemon: bootlogd: cannot deduce real console device
>>>> bootlogd.
>>>> Configuring network interfaces... ifconfig: SIOCGIFFLAGS: No such device
>>>> done.
>>>> Fri May 11 11:29:00 UTC 2012
>>>> Running postinst /etc/rpm-postinsts/*.sh...
>>>> ERROR: postinst /etc/rpm-postinsts/*.sh failed.
>>>
>>>
>>> Does this error repeat if you reboot?
>>> Yes, every time.
>>
>>
>>> What image is being used?  I've seen this with core-image-minimal, but it
>>> goes away when the image is more complex, e.g. core-image-sato.  I
>>> believe
>>> the init script is always present even if there are no postinst scripts
>>> to run.
>>
>>
>> I am also building core-image-minimal.
>> Is there any problem with this?.
>
>
> No.  I think the error message is noise in this case.
>
>> Should I build core-image-sato?.
>
>
> Only if you want/need to - core-image-sato brings in a complete X desktop
> environment, maybe not what you're after.
>
>
>>
>>>
>>>> INIT: Entering runlevel: 5
>>>> Starting syslogd/klogd: done
>>>> Stopping Bootlog daemon: bootlogd.
>>>> [    9.737091] av8100_hdmi av8100_hdmi.3: HDMI display probed
>>>>
>>>> =========================================================
>>>> and after that it got stuck, I am not getting console.
>>>
>>>
>>> How long do you let it sit?
>>>
>>> after some time(around 10mins) got this msg;
>>> INIT: Id "1" respawning too fast: disabled for 5 minutes
>>> INIT: no more processes left in this runlevel
>>>
>>> and then console got  stuck.
>>
>>
>>> What do you have SERIAL_CONSOLE set to in your configuration?
>>
>>
>> I have set SERIAL_CONSOLE="115200 ttyAMA2". As we are using ttyAMA2 for
>> console.
>
>
> What is your target device?  Do you really have /dev/ttyAMA2 serial port??
>
>
>>>>
>>>> I am building rootfs/uImage with default toolchain used in yocto.
>>>> Is it problem of toolchain?.
>>>> Should I build with our toolchain( we use CodeSourcery)?.
>>>
>>>
>>> Nothing above suggests a toolchain problem. You have an error running
>>> the postinst scripts from the various rpm packages. Some instrumentation
>>> in those scripts (and the parent script) would help narrow down where it
>>> is failing.
>>>
>>> --
>>> Darren
>>>
>>>>
>>>> Best Regards,
>>>> Om Prakash Pal
>>>> ________________________________________
>>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>>> Sent: Sunday, May 06, 2012 6:00 PM
>>>> To: Om Prakash PAL
>>>> Cc: Bruce Ashfield; yocto@yoctoproject.org; Richard Purdie
>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>
>>>> On 12-05-06 5:43 AM, Om Prakash PAL wrote:
>>>>>
>>>>> Hi Bruce,
>>>>> I am getting some problem in do_install:
>>>>>
>>>>> NOTE: Running task 1535 of 1710 (ID: 517,
>>>>> /home/apallan/yocto/poky-edison-6.0/meta-u8500/recipes-kernel/linux/linux-u8500.bb,
>>>>> do_install)
>>>>> NOTE: package
>>>>> linux-u8500-3.2+git1+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r10: task
>>>>> do_install: Started
>>>>>
>>>>> and I waited for ~15hr to complete task do_install: but not completed
>>>>> and i am not getting any Errors/warnings.
>>>>> Is there any problem?.
>>>>> I have checked that my vmlinux/uImage/zImage has been created
>>>>> successfully but rootfs has not been created till now.
>>>>>
>>>>> here is my .bb file that is building my local_kernel.
>>>>>
>>>>> inherit kernel
>>>>> require recipes-kernel/linux/linux-yocto.inc
>>>>>
>>>>> KMACHINE = "dev"
>>>>> YOCTO_KERNEL_EXTERNAL_BRANCH ?= "dev"
>>>>>
>>>>> KBRANCH = "${KMACHINE}"
>>>>> KMETA = "meta"
>>>>>
>>>>> KSRC_linux_yocto ?= "/home/apallan/yocto/kernel/"
>>>>>
>>>>> SRC_URI = "git://${KSRC_linux_yocto};protocol=file;nocheckout=1"
>>>>> SRC_URI +="file://defconfig"
>>>>>
>>>>> SRCREV="${AUTOREV}"
>>>>> SRCREV_pn-linux-u8500 ="0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383"
>>>>>
>>>>> LINUX_VERSION ?= "3.2"
>>>>> LINUX_VERSION_EXTENSION = "-yoctized-${LINUX_KERNEL_TYPE}"
>>>>> PR = "r10"
>>>>> PV = "${LINUX_VERSION}+git${SRCPV}"
>>>>>
>>>>> COMPATIBLE_MACHINE = "(u8500|qemuarm)"
>>>>>
>>>>> # Functionality flags
>>>>> KERNEL_REVISION_CHECKING=""
>>>>> YOCTO_KERNEL_META_DATA=""
>>>>>
>>>>> require recipes-kernel/linux/linux-tools.inc
>>>>>
>>>>> what should be the problem?.
>>>>
>>>>
>>>> Anything using linux-yocto has exactly the same packaging semantics as
>>>> other kernels, since they all inherit kernel.bbclass.
>>>>
>>>> Maybe your description sounds familiar to others, and others that might
>>>> have better ideas about what's happening in the packaging backend ?
>>>>
>>>> You don't have any special partitions configured ? You are building
>>>> on a local filesystem ? Is rpm or ipkg being used ? .. these are all
>>>> things that could impact performance (but not really 15 hours worth of
>>>> issues).
>>>>
>>>> Are there any hints in the host system logs, or in the kernels
>>>> do_install
>>>> log ?
>>>>
>>>> Bruce
>>>>
>>>>>
>>>>> Best Regards,
>>>>> Om Prakash Pal
>>>>> ________________________________________
>>>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>>>> Sent: Thursday, May 03, 2012 5:59 PM
>>>>> To: Om Prakash PAL
>>>>> Cc: Bruce Ashfield; yocto@yoctoproject.org
>>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>>
>>>>> On 12-05-03 05:24 AM, Om Prakash PAL wrote:
>>>>>>
>>>>>> Hi Bruce,
>>>>>> Thanks a lot for your help.
>>>>>> Now I am able to build the local kernel.
>>>>>
>>>>>
>>>>> Great!
>>>>>
>>>>>> I have one doublt:
>>>>>> when I do
>>>>>> bitbake -c mencuconfig virtual/kernel
>>>>>>
>>>>>> then from which location it will take the config file?.
>>>>>> and if I want to buiild my own specific defconfig file then How can do
>>>>>> it?.
>>>>>
>>>>>
>>>>> It will use the .config in the build directory ${B}, which if you
>>>>> are using a linux-yocto recipe would be your
>>>>> linux-$MACHINE-$KERNELTYPE-build
>>>>> directory.
>>>>>
>>>>> The dependencies of menuconfig will ensure that the kernel has been
>>>>> fetched,
>>>>> unpacked and configured before it runs. Which means a defconfig will
>>>>> have already been used (if specified) to construct the .config.
>>>>>
>>>>> Any changes you make will be saved in the .config, and you'll need to
>>>>> preserve that for future builds.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Bruce
>>>>>
>>>>>>
>>>>>> Best Regards,
>>>>>> Om Prakash Pal
>>>>>> ________________________________________
>>>>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>>>>> Sent: Monday, April 30, 2012 7:42 PM
>>>>>> To: Om Prakash PAL
>>>>>> Cc: Bruce Ashfield; yocto@yoctoproject.org
>>>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>>>
>>>>>> On 12-04-30 6:34 AM, Om Prakash PAL wrote:
>>>>>>>>
>>>>>>>> On 12-04-29 5:58 AM, Om Prakash PAL wrote:
>>>>>>>
>>>>>>>
>>>>>>>        >      Hi Bruce,
>>>>>>>         >for porting of our local kernel,we have created an BSP layer
>>>>>>> and to change the the
>>>>>>>         >kernel,  we have created an linux-yocto_3.0.bbappend file
>>>>>>> inside
>>>>>>>         >meta<BSP>/recipes-kernel/linux/
>>>>>>>         >like this:-
>>>>>>>
>>>>>>>         >FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>>>>>>
>>>>>>>        >      COMPATIBLE_MACHINE_<BSP_name>       = "BSP_name"
>>>>>>>
>>>>>>>         ># KMACHINE is the branch to build
>>>>>>>         >KMACHINE_<BSP_name>       = "local_branch"
>>>>>>>
>>>>>>>        >      SRCREV_machine_pn_linux-yocto_<BSP_name>       ?=
>>>>>>> "XXXXXXXX" (here we have assign
>>>>>>>         >top commit ID of our local kernel)
>>>>>>>
>>>>>>>
>>>>>>>         ># KSRC_linux_yocto to point to your local clone as
>>>>>>> appropriate.
>>>>>>>         >KSRC_linux_yocto ?= "/path/to/local/kernel"
>>>>>>>
>>>>>>>         >SRC_URI =
>>>>>>>
>>>>>>> >"git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH};name=machine
>>>>>>>          >\
>>>>>>>            >                   file://defconfig"
>>>>>>>
>>>>>>>
>>>>>>>         >KERNEL_REVISION_CHECKING=""
>>>>>>>         >SRCREV="${AUTOREV}"
>>>>>>>         >#BB_LOCALCOUNT_OVERRIDE = "1"
>>>>>>>         >LOCALCOUNT = "0"
>>>>>>>
>>>>>>>
>>>>>>>         >while building we are getting following Error:
>>>>>>>
>>>>>>>         >NOTE: Executing RunQueue Tasks
>>>>>>>         >NOTE: Running task 1341 of 1710 (ID: 513,
>>>>>>>
>>>>>>> >/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb,
>>>>>>>          >do_validate_branches)
>>>>>>>         >NOTE: package
>>>>>>>
>>>>>>> >linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2: task
>>>>>>>         >do_validate_branches: Started
>>>>>>>         >ERROR: Function 'do_validate_branches' failed (see
>>>>>>>
>>>>>>> >/home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/temp/log.do_validate_branches.16792
>>>>>>>          >for further information)
>>>>>>>
>>>>>>>
>>>>>>>         >please tell me what we have done wrong?.
>>>>>>>         >is there anything else we need to modify in .bbappend file
>>>>>>> or some other
>>>>>>>         >variable?.
>>>>>>>
>>>>>>>> Which release are you using again ?
>>>>>>>
>>>>>>>       I am using 6.0.0 Edision
>>>>>>>
>>>>>>>> The diagnostics out of validate branches are about to get better in
>>>>>>>> master,
>>>>>>>> but they are coupled with some other tools changes that couldn't go
>>>>>>>> into yocto 1.2.
>>>>>>>
>>>>>>>
>>>>>>>> Is there anything extra in the log file, or just what you saw on the
>>>>>>>> build log ?.
>>>>>>>
>>>>>>> actually I have set YOCTO_KERNEL_EXTERNAL_BRANCH ="dev";(dev is my
>>>>>>> local brach)
>>>>>>> Now this Error has gone and now I am getting
>>>>>>>
>>>>>>> ERROR: Function 'do_patch' failed (see
>>>>>>> /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008
>>>>>>> for further information)
>>>>>>> ERROR: Logfile of failure stored in:
>>>>>>> /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008
>>>>>>> Log data follows:
>>>>>>> | ERROR. meta data not found, check upstream repo for tags and
>>>>>>> branches
>>>>>>> | ERROR: Function 'do_patch' failed (see
>>>>>>> /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008
>>>>>>> for further information)
>>>>>>> NOTE: package
>>>>>>> linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3: task
>>>>>>> do_patch: Failed
>>>>>>> ERROR: Task 516
>>>>>>> (/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb,
>>>>>>> do_patch) failed with exit code '1'
>>>>>>> ERROR:
>>>>>>> '/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb'
>>>>>>> failed
>>>>>>>
>>>>>>
>>>>>> This is what I was saying a few weeks ago. If you aren't using
>>>>>> the linux-yocto kernel repository (and hence linux-yocto branches/meta
>>>>>> data) as your base, then building directly via the linux-yocto recipe
>>>>>> probably isn't what you want. It is a recipe that leverages the tools
>>>>>> and infrastructure on top of the linux-yocto repository.
>>>>>>
>>>>>> That same infrastructure can build other repositories, but needs some
>>>>>> extra variables set. The meta-kernel-dev layer, in poky-extras has
>>>>>> examples of this for building korg (or any repo) with the tools.
>>>>>>
>>>>>> What you re being told in this particular error is that you don't have
>>>>>> a meta branch in the tree, or not one that the tools can recognize.
>>>>>> You can prevent this by setting YOCTO_KERNEL_META_DATA="" in your
>>>>>> recipe (see the korg recipe as an example). (and FYI: this will no
>>>>>> longer be required in 1.3, but it is for any previous release.
>>>>>>>
>>>>>>>
>>>>>>>> Validate branches fails like this when you've provided a bad branch
>>>>>>>> or
>>>>>>>> SRCREV (vs a SRCREV that is simply not the tip of the branch .. it
>>>>>>>> fixes
>>>>>>>> hat scenario) and the fetcher or another git command aborts.
>>>>>>>
>>>>>>>
>>>>>>>> You've output some example text from the bbappend, but what were the
>>>>>>>> real
>>>>>>>> values in your situation ? i.e. what are KMACHINE/KBRANCH set to ?.
>>>>>>>
>>>>>>>
>>>>>>> I have not set the value of KBRANCH?. what it should be ?.
>>>>>>
>>>>>>
>>>>>> It needs to be a valid branch in the repository. The 1.2 recipes
>>>>>> set it to be KMACHINE if it hasn't been explicitly set. But it
>>>>>> sounds like you are past this, and have set your branch to something
>>>>>> that actually exists in the tree.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Bruce
>>>>>>
>>>>>>>
>>>>>>>> There are some flags you can set to exit the branch validation
>>>>>>>> early, but
>>>>>>>> I don't think setting them is the right course of action yet, since
>>>>>>>> the
>>>>>>>> error you are seeing is likely hiding some other mis configuration.
>>>>>>>
>>>>>>>
>>>>>>>> Cheers,
>>>>>>>
>>>>>>>
>>>>>>>> Bruce
>>>>>>>
>>>>>>>
>>>>>>> Best Regards,
>>>>>>> Om Prakash Pal
>>>>>>> ________________________________________
>>>>>>> From: Om Prakash PAL
>>>>>>> Sent: Sunday, April 29, 2012 3:28 PM
>>>>>>> To: Bruce Ashfield
>>>>>>> Cc: yocto@yoctoproject.org
>>>>>>> Subject: RE: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>>>>
>>>>>>> Hi Bruce,
>>>>>>> for porting of our local kernel,we have created an BSP layer and to
>>>>>>> change the the kernel,  we have created an linux-yocto_3.0.bbappend file
>>>>>>> inside meta<BSP>/recipes-kernel/linux/
>>>>>>> like this:-
>>>>>>>
>>>>>>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>>>>>>
>>>>>>> COMPATIBLE_MACHINE_<BSP_name>      = "BSP_name"
>>>>>>>
>>>>>>> # KMACHINE is the branch to build
>>>>>>> KMACHINE_<BSP_name>      = "local_branch"
>>>>>>>
>>>>>>> SRCREV_machine_pn_linux-yocto_<BSP_name>      ?= "XXXXXXXX" (here we
>>>>>>> have assign top commit ID of our local kernel)
>>>>>>>
>>>>>>>
>>>>>>> # KSRC_linux_yocto to point to your local clone as appropriate.
>>>>>>> KSRC_linux_yocto ?= "/path/to/local/kernel"
>>>>>>>
>>>>>>> SRC_URI =
>>>>>>> "git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH};name=machine
>>>>>>> \
>>>>>>>                     file://defconfig"
>>>>>>>
>>>>>>>
>>>>>>> KERNEL_REVISION_CHECKING=""
>>>>>>> SRCREV="${AUTOREV}"
>>>>>>> #BB_LOCALCOUNT_OVERRIDE = "1"
>>>>>>> LOCALCOUNT = "0"
>>>>>>>
>>>>>>>
>>>>>>> while building we are getting following Error:
>>>>>>>
>>>>>>> NOTE: Executing RunQueue Tasks
>>>>>>> NOTE: Running task 1341 of 1710 (ID: 513,
>>>>>>> /home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb,
>>>>>>> do_validate_branches)
>>>>>>> NOTE: package
>>>>>>> linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2: task
>>>>>>> do_validate_branches: Started
>>>>>>> ERROR: Function 'do_validate_branches' failed (see
>>>>>>> /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/temp/log.do_validate_branches.16792
>>>>>>> for further information)
>>>>>>>
>>>>>>>
>>>>>>> please tell me what we have done wrong?.
>>>>>>> is there anything else we need to modify in .bbappend file or some
>>>>>>> other variable?.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>> Om Prakash Pal
>>>>>>> ________________________________________
>>>>>>> From: Bruce Ashfield [bruce.ashfield@gmail.com]
>>>>>>> Sent: Monday, April 09, 2012 11:04 PM
>>>>>>> To: Om Prakash PAL
>>>>>>> Cc: yocto@yoctoproject.org
>>>>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>>>>
>>>>>>> On Mon, Apr 9, 2012 at 12:31 PM, Om Prakash PAL
>>>>>>> <omprakash.pal@stericsson.com>      wrote:
>>>>>>>>
>>>>>>>> Hi Bruce,
>>>>>>>> Thanks for you help.
>>>>>>>> As you have mentioned, its working properly.
>>>>>>>> I want to know that is there any better way of doing same thing for
>>>>>>>> my scenario ?:
>>>>>>>> here is my scenario:
>>>>>>>> We have development branch where we write/modify our kernel/driver
>>>>>>>> code i.e. thats our local kernel repository(git rep)
>>>>>>>> and lots of driver/files being modified everyday-->so I have to take
>>>>>>>> the same effect into yocto kernel also---->      so except  creating patches
>>>>>>>> for all modified drivers and creating .bbappend files, is there any better
>>>>>>>> way of doing same thing .
>>>>>>>
>>>>>>>
>>>>>>> Aha. Missed that.
>>>>>>>
>>>>>>> Just create a simple recipe that points at your git repository in the
>>>>>>> SRC_URI.
>>>>>>> If all the changes are in the tree, and you have a defconfig and you
>>>>>>> are building
>>>>>>> the master branch. Then pretty much everything you need can be
>>>>>>> specified in
>>>>>>> the SRC_URI .. and that's the entire recipe.
>>>>>>>
>>>>>>> If you look in oe-classic, meta-ti or any one of a number of other
>>>>>>> layers, you'll
>>>>>>> find recipes that do just that.
>>>>>>>
>>>>>>> The meta-kernel-dev (in the poky extras) layer has an example of
>>>>>>> using the
>>>>>>> kernel.org tree with the yocto kern tools, and once yocto 1.3 opens
>>>>>>> up for
>>>>>>> submissions, I have a set of changes prep'd that make it relatively
>>>>>>> simple to
>>>>>>> use the yocto kern tools against different types of repository.
>>>>>>>
>>>>>>> So the summary is: Depending on the type of tooling you need, and
>>>>>>> what baseline
>>>>>>> you need for your work .. there are a number of ways to do things.
>>>>>>>
>>>>>>>>
>>>>>>>> Is there anyway that  instead of using yocto-kernel tree,  can we
>>>>>>>> use our local kernel-tree for building images?. (should  I create separate
>>>>>>>> BSP ?)
>>>>>>>
>>>>>>>
>>>>>>> You should definitely create a BSP, that way you can tune the system
>>>>>>> specific
>>>>>>> to your board,
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Bruce
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks in advance.
>>>>>>>> Best Regards,
>>>>>>>> Om Prakash Pal
>>>>>>>> ________________________________________
>>>>>>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>>>>>>> Sent: Monday, April 09, 2012 9:32 AM
>>>>>>>> To: Om Prakash PAL
>>>>>>>> Cc: yocto@yoctoproject.org
>>>>>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>>>>>
>>>>>>>> On 12-04-08 10:04 AM, Om Prakash PAL wrote:
>>>>>>>>>
>>>>>>>>> Hi Bruce,
>>>>>>>>> Thanks for your reply.
>>>>>>>>> I am totally new to Yocto.
>>>>>>>>> I have gone through the section BSP/Linux kernel configuration and
>>>>>>>>> if I am not wrong then it explains how can we configure the kernel, not the
>>>>>>>>> how we can add/replace a  component(driver etc).
>>>>>>>>> lets take the example of UART driver, I want to add my own UART
>>>>>>>>> driver code.
>>>>>>>>> Should I write a separate recipe file (.bb) for UART Driver?.
>>>>>>>>> if yes then I have to write the recipe files for all my drivers
>>>>>>>>> that will be very time consuming.
>>>>>>>>> Is there any other way that I can port all my desired drivers into
>>>>>>>>> Yocto kernel?.
>>>>>>>>
>>>>>>>>
>>>>>>>> No recipes are required per-driver, unless you are building them all
>>>>>>>> as out of tree modules.
>>>>>>>>
>>>>>>>> The typical way this is done is to simply work in the extracted
>>>>>>>> linux
>>>>>>>> src tree (build/tmp/work/<your board>/linux-yocto-<hashes>/linux),
>>>>>>>> manually
>>>>>>>> patch, or copy your drivers into the tree. At this point, you'll
>>>>>>>> port
>>>>>>>> the drivers, doing test builds (bitbake -f -c compile linux-yocto)
>>>>>>>> to
>>>>>>>> ensure that your port is working. When you've completed the build
>>>>>>>> phase,
>>>>>>>> boot tests would be in order. (Do not do a 'clean' or you'll lose in
>>>>>>>> progress changes).
>>>>>>>>
>>>>>>>> When you are happy with the changes, the directory where you were
>>>>>>>> working
>>>>>>>> is with the kernel git repository. So you can simply commit your
>>>>>>>> changes, and generate patches.
>>>>>>>>
>>>>>>>>        git format-patch -o<your directory>      HEAD^ (or however
>>>>>>>> many commits
>>>>>>>> you have)
>>>>>>>>
>>>>>>>> Take those patches, create a layer with a bbappend and add them like
>>>>>>>> any other patch to any package. They'll be applied to subsequent
>>>>>>>> builds
>>>>>>>> of the kernel.
>>>>>>>>
>>>>>>>> I'm skipping a lot of detail there, but it is all found in the
>>>>>>>> various
>>>>>>>> manuals, and I don't want to repeat it here.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Bruce
>>>>>>>>
>>>>>>>>> Please help me.
>>>>>>>>> Thanks a lot in advance.
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>> Om Prakash Pal
>>>>>>>>> ________________________________________
>>>>>>>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>>>>>>>> Sent: Wednesday, April 04, 2012 6:17 PM
>>>>>>>>> To: Om Prakash PAL
>>>>>>>>> Cc: yocto@yoctoproject.org
>>>>>>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>>>>>>
>>>>>>>>> On 12-04-04 04:46 AM, Om Prakash PAL wrote:
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>> I want to build my local kernel/Driver code, not the default one.
>>>>>>>>>> please help how can i do it ?.
>>>>>>>>>> any wiki/docs on this?.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The BSP developer guides show how to extend the yocto kernels, and
>>>>>>>>> also have sections on custom/different kernel versions. Have you
>>>>>>>>> seen that doc yet ? Or have you seen it, and have specific
>>>>>>>>> questions ?
>>>>>>>>>
>>>>>>>>> Bruce
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>> Om Prakash Pal
>>>>>>>>>> _______________________________________________
>>>>>>>>>> yocto mailing list
>>>>>>>>>> yocto@yoctoproject.org
>>>>>>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> yocto mailing list
>>>>>>>> yocto@yoctoproject.org
>>>>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> "Thou shalt not follow the NULL pointer, for chaos and madness await
>>>>>>> thee at its end"
>>>>>>> _______________________________________________
>>>>>>> yocto mailing list
>>>>>>> yocto@yoctoproject.org
>>>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>>
>>>
>>> --
>>> Darren Hart
>>> Intel Open Source Technology Center
>>> Yocto Project - Linux Kernel
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>>> --
>>> ------------------------------------------------------------
>>> Gary Thomas                 |  Consulting for the
>>> MLB Associates              |    Embedded world
>>> ------------------------------------------------------------
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>>
>> Best Regards,
>> Om Prakash Pal
>
>
> --
> ------------------------------------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
> ------------------------------------------------------------
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: Porting of specific Kernel/Driver into yocto.

[Om Prakash PAL]

-----Original Message-----
From: Gary Thomas [mailto:gary@mlbassoc.com]
Sent: Thursday, June 21, 2012 7:59 PM
To: Om Prakash PAL
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.

On 2012-06-21 08:16, Om Prakash PAL wrote:
> ----Original Message-----
> From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Gary Thomas
> Sent: Thursday, June 21, 2012 6:18 PM
> To: yocto@yoctoproject.org
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>
> On 2012-06-21 06:27, Om Prakash PAL wrote:
>> ________________________________________
>> From: Darren Hart [darren.hart@intel.com]
>> Sent: Wednesday, May 23, 2012 11:46 PM
>> To: Om Prakash PAL
>> Cc: Bruce Ashfield; yocto@yoctoproject.org; Richard Purdie
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> On 05/23/2012 05:39 AM, Om Prakash PAL wrote:
>>> Hi Bruce,
>>>
>>> [ I am using "poky-edison-6.0" ]
>>> I am able to create my rootfs and uImage but when I flashed these on my board,
>>> while booting I am getting below Error and console get blocked.
>>>
>>> =========================================================
>>> [    3.575805] EXT3-fs (mmcblk0p1): using internal journal
>>> [    3.581054] EXT3-fs (mmcblk0p1): mounted filesystem with writeback data mode
>>> [    3.588165] VFS: Mounted root (ext3 filesystem) on device 179:1.
>>> [    3.594268] Freeing init memory: 312K
>>> INIT: version 2.88 booting
>>>
>>> Please wait: booting...
>>> Starting udev
>>> Starting Bootlog daemon: bootlogd: cannot deduce real console device
>>> bootlogd.
>>> Configuring network interfaces... ifconfig: SIOCGIFFLAGS: No such device
>>> done.
>>> Fri May 11 11:29:00 UTC 2012
>>> Running postinst /etc/rpm-postinsts/*.sh...
>>> ERROR: postinst /etc/rpm-postinsts/*.sh failed.
>>
>> Does this error repeat if you reboot?
>> Yes, every time.
>
>> What image is being used?  I've seen this with core-image-minimal, but it
>> goes away when the image is more complex, e.g. core-image-sato.  I believe
>> the init script is always present even if there are no postinst scripts to run.
>
> I am also building core-image-minimal.
> Is there any problem with this?.

>No.  I think the error message is noise in this case.

> Should I build core-image-sato?.

>Only if you want/need to - core-image-sato brings in a complete X desktop
>environment, maybe not what you're after.

I don't want complete X desktop environment, I just want console only.
But how to avoid this error?.
>
>>
>>> INIT: Entering runlevel: 5
>>> Starting syslogd/klogd: done
>>> Stopping Bootlog daemon: bootlogd.
>>> [    9.737091] av8100_hdmi av8100_hdmi.3: HDMI display probed
>>>
>>> =========================================================
>>> and after that it got stuck, I am not getting console.
>>
>> How long do you let it sit?
>>
>> after some time(around 10mins) got this msg;
>> INIT: Id "1" respawning too fast: disabled for 5 minutes
>> INIT: no more processes left in this runlevel
>>
>> and then console got  stuck.
>
>> What do you have SERIAL_CONSOLE set to in your configuration?
>
> I have set SERIAL_CONSOLE="115200 ttyAMA2". As we are using ttyAMA2 for console.

>What is your target device?  Do you really have /dev/ttyAMA2 serial port??.

Yes, I have /dev/ttyAMA2 serial port.

>>>
>>> I am building rootfs/uImage with default toolchain used in yocto.
>>> Is it problem of toolchain?.
>>> Should I build with our toolchain( we use CodeSourcery)?.
>>
>> Nothing above suggests a toolchain problem. You have an error running
>> the postinst scripts from the various rpm packages. Some instrumentation
>> in those scripts (and the parent script) would help narrow down where it
>> is failing.
>>
>> --
>> Darren
>>
>>>
>>> Best Regards,
>>> Om Prakash Pal
>>> ________________________________________
>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>> Sent: Sunday, May 06, 2012 6:00 PM
>>> To: Om Prakash PAL
>>> Cc: Bruce Ashfield; yocto@yoctoproject.org; Richard Purdie
>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>
>>> On 12-05-06 5:43 AM, Om Prakash PAL wrote:
>>>> Hi Bruce,
>>>> I am getting some problem in do_install:
>>>>
>>>> NOTE: Running task 1535 of 1710 (ID: 517, /home/apallan/yocto/poky-edison-6.0/meta-u8500/recipes-kernel/linux/linux-u8500.bb, do_install)
>>>> NOTE: package linux-u8500-3.2+git1+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r10: task do_install: Started
>>>>
>>>> and I waited for ~15hr to complete task do_install: but not completed and i am not getting any Errors/warnings.
>>>> Is there any problem?.
>>>> I have checked that my vmlinux/uImage/zImage has been created successfully but rootfs has not been created till now.
>>>>
>>>> here is my .bb file that is building my local_kernel.
>>>>
>>>> inherit kernel
>>>> require recipes-kernel/linux/linux-yocto.inc
>>>>
>>>> KMACHINE = "dev"
>>>> YOCTO_KERNEL_EXTERNAL_BRANCH ?= "dev"
>>>>
>>>> KBRANCH = "${KMACHINE}"
>>>> KMETA = "meta"
>>>>
>>>> KSRC_linux_yocto ?= "/home/apallan/yocto/kernel/"
>>>>
>>>> SRC_URI = "git://${KSRC_linux_yocto};protocol=file;nocheckout=1"
>>>> SRC_URI +="file://defconfig"
>>>>
>>>> SRCREV="${AUTOREV}"
>>>> SRCREV_pn-linux-u8500 ="0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383"
>>>>
>>>> LINUX_VERSION ?= "3.2"
>>>> LINUX_VERSION_EXTENSION = "-yoctized-${LINUX_KERNEL_TYPE}"
>>>> PR = "r10"
>>>> PV = "${LINUX_VERSION}+git${SRCPV}"
>>>>
>>>> COMPATIBLE_MACHINE = "(u8500|qemuarm)"
>>>>
>>>> # Functionality flags
>>>> KERNEL_REVISION_CHECKING=""
>>>> YOCTO_KERNEL_META_DATA=""
>>>>
>>>> require recipes-kernel/linux/linux-tools.inc
>>>>
>>>> what should be the problem?.
>>>
>>> Anything using linux-yocto has exactly the same packaging semantics as
>>> other kernels, since they all inherit kernel.bbclass.
>>>
>>> Maybe your description sounds familiar to others, and others that might
>>> have better ideas about what's happening in the packaging backend ?
>>>
>>> You don't have any special partitions configured ? You are building
>>> on a local filesystem ? Is rpm or ipkg being used ? .. these are all
>>> things that could impact performance (but not really 15 hours worth of
>>> issues).
>>>
>>> Are there any hints in the host system logs, or in the kernels do_install
>>> log ?
>>>
>>> Bruce
>>>
>>>>
>>>> Best Regards,
>>>> Om Prakash Pal
>>>> ________________________________________
>>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>>> Sent: Thursday, May 03, 2012 5:59 PM
>>>> To: Om Prakash PAL
>>>> Cc: Bruce Ashfield; yocto@yoctoproject.org
>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>
>>>> On 12-05-03 05:24 AM, Om Prakash PAL wrote:
>>>>> Hi Bruce,
>>>>> Thanks a lot for your help.
>>>>> Now I am able to build the local kernel.
>>>>
>>>> Great!
>>>>
>>>>> I have one doublt:
>>>>> when I do
>>>>> bitbake -c mencuconfig virtual/kernel
>>>>>
>>>>> then from which location it will take the config file?.
>>>>> and if I want to buiild my own specific defconfig file then How can do it?.
>>>>
>>>> It will use the .config in the build directory ${B}, which if you
>>>> are using a linux-yocto recipe would be your
>>>> linux-$MACHINE-$KERNELTYPE-build
>>>> directory.
>>>>
>>>> The dependencies of menuconfig will ensure that the kernel has been fetched,
>>>> unpacked and configured before it runs. Which means a defconfig will
>>>> have already been used (if specified) to construct the .config.
>>>>
>>>> Any changes you make will be saved in the .config, and you'll need to
>>>> preserve that for future builds.
>>>>
>>>> Cheers,
>>>>
>>>> Bruce
>>>>
>>>>>
>>>>> Best Regards,
>>>>> Om Prakash Pal
>>>>> ________________________________________
>>>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>>>> Sent: Monday, April 30, 2012 7:42 PM
>>>>> To: Om Prakash PAL
>>>>> Cc: Bruce Ashfield; yocto@yoctoproject.org
>>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>>
>>>>> On 12-04-30 6:34 AM, Om Prakash PAL wrote:
>>>>>>> On 12-04-29 5:58 AM, Om Prakash PAL wrote:
>>>>>>
>>>>>>         >      Hi Bruce,
>>>>>>          >for porting of our local kernel,we have created an BSP layer and to change the the
>>>>>>          >kernel,  we have created an linux-yocto_3.0.bbappend file inside
>>>>>>          >meta<BSP>/recipes-kernel/linux/
>>>>>>          >like this:-
>>>>>>
>>>>>>          >FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>>>>>
>>>>>>         >      COMPATIBLE_MACHINE_<BSP_name>       = "BSP_name"
>>>>>>
>>>>>>          ># KMACHINE is the branch to build
>>>>>>          >KMACHINE_<BSP_name>       = "local_branch"
>>>>>>
>>>>>>         >      SRCREV_machine_pn_linux-yocto_<BSP_name>       ?= "XXXXXXXX" (here we have assign
>>>>>>          >top commit ID of our local kernel)
>>>>>>
>>>>>>
>>>>>>          ># KSRC_linux_yocto to point to your local clone as appropriate.
>>>>>>          >KSRC_linux_yocto ?= "/path/to/local/kernel"
>>>>>>
>>>>>>          >SRC_URI =
>>>>>>          >"git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH};name=machine
>>>>>>           >\
>>>>>>             >                   file://defconfig"
>>>>>>
>>>>>>
>>>>>>          >KERNEL_REVISION_CHECKING=""
>>>>>>          >SRCREV="${AUTOREV}"
>>>>>>          >#BB_LOCALCOUNT_OVERRIDE = "1"
>>>>>>          >LOCALCOUNT = "0"
>>>>>>
>>>>>>
>>>>>>          >while building we are getting following Error:
>>>>>>
>>>>>>          >NOTE: Executing RunQueue Tasks
>>>>>>          >NOTE: Running task 1341 of 1710 (ID: 513,
>>>>>>          >/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb,
>>>>>>           >do_validate_branches)
>>>>>>          >NOTE: package
>>>>>>          >linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2: task
>>>>>>          >do_validate_branches: Started
>>>>>>          >ERROR: Function 'do_validate_branches' failed (see
>>>>>>          >/home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/temp/log.do_validate_branches.16792
>>>>>>           >for further information)
>>>>>>
>>>>>>
>>>>>>          >please tell me what we have done wrong?.
>>>>>>          >is there anything else we need to modify in .bbappend file or some other
>>>>>>          >variable?.
>>>>>>
>>>>>>> Which release are you using again ?
>>>>>>        I am using 6.0.0 Edision
>>>>>>
>>>>>>> The diagnostics out of validate branches are about to get better in master,
>>>>>>> but they are coupled with some other tools changes that couldn't go
>>>>>>> into yocto 1.2.
>>>>>>
>>>>>>> Is there anything extra in the log file, or just what you saw on the
>>>>>>> build log ?.
>>>>>> actually I have set YOCTO_KERNEL_EXTERNAL_BRANCH ="dev";(dev is my local brach)
>>>>>> Now this Error has gone and now I am getting
>>>>>>
>>>>>> ERROR: Function 'do_patch' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008 for further information)
>>>>>> ERROR: Logfile of failure stored in: /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008
>>>>>> Log data follows:
>>>>>> | ERROR. meta data not found, check upstream repo for tags and branches
>>>>>> | ERROR: Function 'do_patch' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3/temp/log.do_patch.22008 for further information)
>>>>>> NOTE: package linux-yocto-3.0.4+git2+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r3: task do_patch: Failed
>>>>>> ERROR: Task 516 (/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_patch) failed with exit code '1'
>>>>>> ERROR: '/home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb' failed
>>>>>>
>>>>>
>>>>> This is what I was saying a few weeks ago. If you aren't using
>>>>> the linux-yocto kernel repository (and hence linux-yocto branches/meta
>>>>> data) as your base, then building directly via the linux-yocto recipe
>>>>> probably isn't what you want. It is a recipe that leverages the tools
>>>>> and infrastructure on top of the linux-yocto repository.
>>>>>
>>>>> That same infrastructure can build other repositories, but needs some
>>>>> extra variables set. The meta-kernel-dev layer, in poky-extras has
>>>>> examples of this for building korg (or any repo) with the tools.
>>>>>
>>>>> What you re being told in this particular error is that you don't have
>>>>> a meta branch in the tree, or not one that the tools can recognize.
>>>>> You can prevent this by setting YOCTO_KERNEL_META_DATA="" in your
>>>>> recipe (see the korg recipe as an example). (and FYI: this will no
>>>>> longer be required in 1.3, but it is for any previous release.
>>>>>>
>>>>>>> Validate branches fails like this when you've provided a bad branch or
>>>>>>> SRCREV (vs a SRCREV that is simply not the tip of the branch .. it fixes
>>>>>>> hat scenario) and the fetcher or another git command aborts.
>>>>>>
>>>>>>> You've output some example text from the bbappend, but what were the real
>>>>>>> values in your situation ? i.e. what are KMACHINE/KBRANCH set to ?.
>>>>>>
>>>>>> I have not set the value of KBRANCH?. what it should be ?.
>>>>>
>>>>> It needs to be a valid branch in the repository. The 1.2 recipes
>>>>> set it to be KMACHINE if it hasn't been explicitly set. But it
>>>>> sounds like you are past this, and have set your branch to something
>>>>> that actually exists in the tree.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Bruce
>>>>>
>>>>>>
>>>>>>> There are some flags you can set to exit the branch validation early, but
>>>>>>> I don't think setting them is the right course of action yet, since the
>>>>>>> error you are seeing is likely hiding some other mis configuration.
>>>>>>
>>>>>>> Cheers,
>>>>>>
>>>>>>> Bruce
>>>>>>
>>>>>> Best Regards,
>>>>>> Om Prakash Pal
>>>>>> ________________________________________
>>>>>> From: Om Prakash PAL
>>>>>> Sent: Sunday, April 29, 2012 3:28 PM
>>>>>> To: Bruce Ashfield
>>>>>> Cc: yocto@yoctoproject.org
>>>>>> Subject: RE: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>>>
>>>>>> Hi Bruce,
>>>>>> for porting of our local kernel,we have created an BSP layer and to change the the kernel,  we have created an linux-yocto_3.0.bbappend file inside meta<BSP>/recipes-kernel/linux/
>>>>>> like this:-
>>>>>>
>>>>>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>>>>>
>>>>>> COMPATIBLE_MACHINE_<BSP_name>      = "BSP_name"
>>>>>>
>>>>>> # KMACHINE is the branch to build
>>>>>> KMACHINE_<BSP_name>      = "local_branch"
>>>>>>
>>>>>> SRCREV_machine_pn_linux-yocto_<BSP_name>      ?= "XXXXXXXX" (here we have assign top commit ID of our local kernel)
>>>>>>
>>>>>>
>>>>>> # KSRC_linux_yocto to point to your local clone as appropriate.
>>>>>> KSRC_linux_yocto ?= "/path/to/local/kernel"
>>>>>>
>>>>>> SRC_URI = "git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH};name=machine \
>>>>>>                      file://defconfig"
>>>>>>
>>>>>>
>>>>>> KERNEL_REVISION_CHECKING=""
>>>>>> SRCREV="${AUTOREV}"
>>>>>> #BB_LOCALCOUNT_OVERRIDE = "1"
>>>>>> LOCALCOUNT = "0"
>>>>>>
>>>>>>
>>>>>> while building we are getting following Error:
>>>>>>
>>>>>> NOTE: Executing RunQueue Tasks
>>>>>> NOTE: Running task 1341 of 1710 (ID: 513, /home/apallan/yocto/poky-edison-6.0/meta/recipes-kernel/linux/linux-yocto_3.0.bb, do_validate_branches)
>>>>>> NOTE: package linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2: task do_validate_branches: Started
>>>>>> ERROR: Function 'do_validate_branches' failed (see /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-yocto-3.0.4+git1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r2/temp/log.do_validate_branches.16792 for further information)
>>>>>>
>>>>>>
>>>>>> please tell me what we have done wrong?.
>>>>>> is there anything else we need to modify in .bbappend file or some other variable?.
>>>>>>
>>>>>> Best Regards,
>>>>>> Om Prakash Pal
>>>>>> ________________________________________
>>>>>> From: Bruce Ashfield [bruce.ashfield@gmail.com]
>>>>>> Sent: Monday, April 09, 2012 11:04 PM
>>>>>> To: Om Prakash PAL
>>>>>> Cc: yocto@yoctoproject.org
>>>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>>>
>>>>>> On Mon, Apr 9, 2012 at 12:31 PM, Om Prakash PAL
>>>>>> <omprakash.pal@stericsson.com>      wrote:
>>>>>>> Hi Bruce,
>>>>>>> Thanks for you help.
>>>>>>> As you have mentioned, its working properly.
>>>>>>> I want to know that is there any better way of doing same thing for my scenario ?:
>>>>>>> here is my scenario:
>>>>>>> We have development branch where we write/modify our kernel/driver code i.e. thats our local kernel repository(git rep)
>>>>>>> and lots of driver/files being modified everyday-->so I have to take the same effect into yocto kernel also---->      so except  creating patches for all modified drivers and creating .bbappend files, is there any better way of doing same thing .
>>>>>>
>>>>>> Aha. Missed that.
>>>>>>
>>>>>> Just create a simple recipe that points at your git repository in the SRC_URI.
>>>>>> If all the changes are in the tree, and you have a defconfig and you
>>>>>> are building
>>>>>> the master branch. Then pretty much everything you need can be specified in
>>>>>> the SRC_URI .. and that's the entire recipe.
>>>>>>
>>>>>> If you look in oe-classic, meta-ti or any one of a number of other
>>>>>> layers, you'll
>>>>>> find recipes that do just that.
>>>>>>
>>>>>> The meta-kernel-dev (in the poky extras) layer has an example of using the
>>>>>> kernel.org tree with the yocto kern tools, and once yocto 1.3 opens up for
>>>>>> submissions, I have a set of changes prep'd that make it relatively simple to
>>>>>> use the yocto kern tools against different types of repository.
>>>>>>
>>>>>> So the summary is: Depending on the type of tooling you need, and what baseline
>>>>>> you need for your work .. there are a number of ways to do things.
>>>>>>
>>>>>>>
>>>>>>> Is there anyway that  instead of using yocto-kernel tree,  can we use our local kernel-tree for building images?. (should  I create separate BSP ?)
>>>>>>
>>>>>> You should definitely create a BSP, that way you can tune the system specific
>>>>>> to your board,
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Bruce
>>>>>>
>>>>>>>
>>>>>>> Thanks in advance.
>>>>>>> Best Regards,
>>>>>>> Om Prakash Pal
>>>>>>> ________________________________________
>>>>>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>>>>>> Sent: Monday, April 09, 2012 9:32 AM
>>>>>>> To: Om Prakash PAL
>>>>>>> Cc: yocto@yoctoproject.org
>>>>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>>>>
>>>>>>> On 12-04-08 10:04 AM, Om Prakash PAL wrote:
>>>>>>>> Hi Bruce,
>>>>>>>> Thanks for your reply.
>>>>>>>> I am totally new to Yocto.
>>>>>>>> I have gone through the section BSP/Linux kernel configuration and if I am not wrong then it explains how can we configure the kernel, not the how we can add/replace a  component(driver etc).
>>>>>>>> lets take the example of UART driver, I want to add my own UART driver code.
>>>>>>>> Should I write a separate recipe file (.bb) for UART Driver?.
>>>>>>>> if yes then I have to write the recipe files for all my drivers that will be very time consuming.
>>>>>>>> Is there any other way that I can port all my desired drivers into Yocto kernel?.
>>>>>>>
>>>>>>> No recipes are required per-driver, unless you are building them all
>>>>>>> as out of tree modules.
>>>>>>>
>>>>>>> The typical way this is done is to simply work in the extracted linux
>>>>>>> src tree (build/tmp/work/<your board>/linux-yocto-<hashes>/linux), manually
>>>>>>> patch, or copy your drivers into the tree. At this point, you'll port
>>>>>>> the drivers, doing test builds (bitbake -f -c compile linux-yocto) to
>>>>>>> ensure that your port is working. When you've completed the build phase,
>>>>>>> boot tests would be in order. (Do not do a 'clean' or you'll lose in
>>>>>>> progress changes).
>>>>>>>
>>>>>>> When you are happy with the changes, the directory where you were working
>>>>>>> is with the kernel git repository. So you can simply commit your
>>>>>>> changes, and generate patches.
>>>>>>>
>>>>>>>         git format-patch -o<your directory>      HEAD^ (or however many commits
>>>>>>> you have)
>>>>>>>
>>>>>>> Take those patches, create a layer with a bbappend and add them like
>>>>>>> any other patch to any package. They'll be applied to subsequent builds
>>>>>>> of the kernel.
>>>>>>>
>>>>>>> I'm skipping a lot of detail there, but it is all found in the various
>>>>>>> manuals, and I don't want to repeat it here.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Bruce
>>>>>>>
>>>>>>>> Please help me.
>>>>>>>> Thanks a lot in advance.
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>> Om Prakash Pal
>>>>>>>> ________________________________________
>>>>>>>> From: Bruce Ashfield [bruce.ashfield@windriver.com]
>>>>>>>> Sent: Wednesday, April 04, 2012 6:17 PM
>>>>>>>> To: Om Prakash PAL
>>>>>>>> Cc: yocto@yoctoproject.org
>>>>>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>>>>>
>>>>>>>> On 12-04-04 04:46 AM, Om Prakash PAL wrote:
>>>>>>>>> Hi,
>>>>>>>>> I want to build my local kernel/Driver code, not the default one.
>>>>>>>>> please help how can i do it ?.
>>>>>>>>> any wiki/docs on this?.
>>>>>>>>
>>>>>>>> The BSP developer guides show how to extend the yocto kernels, and
>>>>>>>> also have sections on custom/different kernel versions. Have you
>>>>>>>> seen that doc yet ? Or have you seen it, and have specific questions ?
>>>>>>>>
>>>>>>>> Bruce
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>> Om Prakash Pal
>>>>>>>>> _______________________________________________
>>>>>>>>> yocto mailing list
>>>>>>>>> yocto@yoctoproject.org
>>>>>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> yocto mailing list
>>>>>>> yocto@yoctoproject.org
>>>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> "Thou shalt not follow the NULL pointer, for chaos and madness await
>>>>>> thee at its end"
>>>>>> _______________________________________________
>>>>>> yocto mailing list
>>>>>> yocto@yoctoproject.org
>>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>> --
>> Darren Hart
>> Intel Open Source Technology Center
>> Yocto Project - Linux Kernel
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>> --
>> ------------------------------------------------------------
>> Gary Thomas                 |  Consulting for the
>> MLB Associates              |    Embedded world
>> ------------------------------------------------------------
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>
> Best Regards,
> Om Prakash Pal
>
>--
>------------------------------------------------------------
>Gary Thomas                 |  Consulting for the
>MLB Associates              |    Embedded world
>------------------------------------------------------------

Best Regards,
Om Prakash Pal

Re: Porting of specific Kernel/Driver into yocto.

[Khem Raj]

On Thu, Jun 21, 2012 at 10:37 PM, Om Prakash PAL
<omprakash.pal@stericsson.com> wrote:
>
>>> and then console got  stuck.
>>
>>> What do you have SERIAL_CONSOLE set to in your configuration?
>>
>> I have set SERIAL_CONSOLE="115200 ttyAMA2". As we are using ttyAMA2 for console.
>
>>What is your target device?  Do you really have /dev/ttyAMA2 serial port??.
>
> Yes, I have /dev/ttyAMA2 serial port.

Can you try using say poky/master and generate root file system and
try that out ?
another option is to try core-image-core

Re: Porting of specific Kernel/Driver into yocto.

[Om Prakash PAL]

________________________________________
From: Khem Raj [raj.khem@gmail.com]
Sent: Friday, June 22, 2012 11:18 AM
To: Om Prakash PAL
Cc: Gary Thomas; yocto@yoctoproject.org
Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.

On Thu, Jun 21, 2012 at 10:37 PM, Om Prakash PAL
<omprakash.pal@stericsson.com> wrote:
>
>>> and then console got  stuck.
>>
>>> What do you have SERIAL_CONSOLE set to in your configuration?
>>
>> I have set SERIAL_CONSOLE="115200 ttyAMA2". As we are using ttyAMA2 for console.
>
>>What is your target device?  Do you really have /dev/ttyAMA2 serial port??.
>
> Yes, I have /dev/ttyAMA2 serial port.

>Can you try using say poky/master and generate root file system and
>try that out ?
>another option is to try core-image-core

While building core-image-core
$bitbake core-image-core

I am getting folowwing Error:

 checking for perl... /usr/bin/perl
| checking for perl >= 5.8.1... 5.12.4
| checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool
| + bbfatal 'oe_runconf failed'
| + echo 'ERROR: oe_runconf failed'
| ERROR: oe_runconf failed
| + exit 1
| 
| checking for gmsgfmt... /home/apallan/yocto/hello_build/tmp/sysroots/i686-linux/usr/bin/msgfmt
| checking for perl... /usr/bin/perl
| checking for perl >= 5.8.1... 5.12.4
| checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool
| + bbfatal 'oe_runconf failed'
| + echo 'ERROR: oe_runconf failed'
| ERROR: oe_runconf failed
| + exit 1
| ERROR: Function 'do_configure' failed (see /home/apallan/yocto/hello_build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/shared-mime-info-0.90-r0/temp/log.do_configure.31201 for further information)
NOTE: package shared-mime-info-0.90-r0: task do_configure: Failed
ERROR: Task 2799 (/home/apallan/yocto/poky-edison-6.0/meta/recipes-support/shared-mime-info/shared-mime-info_0.90.bb, do_configure) failed with exit code '1'
ERROR: '/home/apallan/yocto/poky-edison-6.0/meta/recipes-support/shared-mime-info/shared-mime-info_0.90.bb' failed

Any idea why is it failing and how can I resolve it?.

Best Regards,
Om Prakash Pal

Re: Porting of specific Kernel/Driver into yocto.

[Om Prakash PAL]

________________________________________
From: Om Prakash PAL
Sent: Friday, June 22, 2012 2:59 PM
To: Khem Raj
Cc: Gary Thomas; yocto@yoctoproject.org
Subject: RE: [yocto] Porting of specific Kernel/Driver into yocto.

________________________________________
From: Khem Raj [raj.khem@gmail.com]
Sent: Friday, June 22, 2012 11:18 AM
To: Om Prakash PAL
Cc: Gary Thomas; yocto@yoctoproject.org
Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.

On Thu, Jun 21, 2012 at 10:37 PM, Om Prakash PAL
<omprakash.pal@stericsson.com> wrote:
>
>>> and then console got  stuck.
>>
>>> What do you have SERIAL_CONSOLE set to in your configuration?
>>
>> I have set SERIAL_CONSOLE="115200 ttyAMA2". As we are using ttyAMA2 for console.
>
>>What is your target device?  Do you really have /dev/ttyAMA2 serial port??.
>
> Yes, I have /dev/ttyAMA2 serial port.

>Can you try using say poky/master and generate root file system and
>try that out ?
>another option is to try core-image-core

>While building core-image-core
>$bitbake core-image-core

>I am getting folowwing Error:

 >checking for perl... /usr/bin/perl
| checking for perl >= 5.8.1... 5.12.4
| checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool
| + bbfatal 'oe_runconf failed'
| + echo 'ERROR: oe_runconf failed'
| ERROR: oe_runconf failed
| + exit 1
|
| checking for gmsgfmt... /home/apallan/yocto/hello_build/tmp/sysroots/i686-linux/usr/bin/msgfmt
| checking for perl... /usr/bin/perl
| checking for perl >= 5.8.1... 5.12.4
| checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool
| + bbfatal 'oe_runconf failed'
| + echo 'ERROR: oe_runconf failed'
| ERROR: oe_runconf failed
| + exit 1
| ERROR: Function 'do_configure' failed (see /home/apallan/yocto/hello_build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/shared-mime-info-0.90-r0/temp/log.do_configure.31201 for further information)
>NOTE: package shared-mime-info-0.90-r0: task do_configure: Failed
>ERROR: Task 2799 (/home/apallan/yocto/poky-edison-6.0/meta/recipes-support/shared-mime-info/shared-mime-info_0.90.bb, do_configure) failed with exit code '1'
>ERROR: '/home/apallan/yocto/poky-edison-6.0/meta/recipes-support/shared-mime-info/shared-mime-info_0.90.bb' failed

>Any idea why is it failing and how can I resolve it?.

Actaully I solved this by modifying:
meta/recipes-support/shared-mime-info/shared-mime-info.inc :
                      -inherit autotools pkgconfig gettext
                     +inherit autotools pkgconfig gettext perlnative

Best Regards,
Om Prakash Pal

Re: Porting of specific Kernel/Driver into yocto.

[Om Prakash PAL]

Hi Khem,
I have build core-image-core. but still this Error:
======================================================>
   11.165466] EXT3-fs (mmcblk0p1): mounted filesystem with writeback data mode
[   11.172668] VFS: Mounted root (ext3 filesystem) on device 179:1.
[   11.179260] Freeing init memory: 316K
INIT: version 2.88 booting
Error Cannot open /dev/tty0: No such device or address
mknod: /dev/console: File exists

=========================================================>

I have set SERIAL_CONSOLE="115200 ttyAMA2"  then why its taking /dev/tty0 ?.
please help.

Best Regards,
Om Prakash Pal
_______________________________________
From: Khem Raj [raj.khem@gmail.com]
Sent: Friday, June 22, 2012 11:18 AM
To: Om Prakash PAL
Cc: Gary Thomas; yocto@yoctoproject.org
Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.

On Thu, Jun 21, 2012 at 10:37 PM, Om Prakash PAL
<omprakash.pal@stericsson.com> wrote:
>
>>> and then console got  stuck.
>>
>>> What do you have SERIAL_CONSOLE set to in your configuration?
>>
>> I have set SERIAL_CONSOLE="115200 ttyAMA2". As we are using ttyAMA2 for console.
>
>>What is your target device?  Do you really have /dev/ttyAMA2 serial port??.
>
> Yes, I have /dev/ttyAMA2 serial port.

Can you try using say poky/master and generate root file system and
try that out ?
another option is to try core-image-core

Re: Porting of specific Kernel/Driver into yocto.

[Bruce Ashfield]

On 12-06-25 08:53 AM, Om Prakash PAL wrote:
> Hi Khem,
> I have build core-image-core. but still this Error:
> ======================================================>
>     11.165466] EXT3-fs (mmcblk0p1): mounted filesystem with writeback data mode
> [   11.172668] VFS: Mounted root (ext3 filesystem) on device 179:1.
> [   11.179260] Freeing init memory: 316K
> INIT: version 2.88 booting
> Error Cannot open /dev/tty0: No such device or address
> mknod: /dev/console: File exists
>
> =========================================================>
>
> I have set SERIAL_CONSOLE="115200 ttyAMA2"  then why its taking /dev/tty0 ?.

I've lost some of the context on the board you are working with, but
from ttyAMA2, I'm assuming it is an arm board. Have you verified that your
bootloader can pass the kernel bootline properly to the kernel ? It is
(unfortunately) fairly common that it isn't properly passed. If you
modify your configuration to have a built in command line with your
configuration, you may be able to get better setup to debug the
problem.

Cheers,

Bruce

> please help.
>
> Best Regards,
> Om Prakash Pal
> _______________________________________
> From: Khem Raj [raj.khem@gmail.com]
> Sent: Friday, June 22, 2012 11:18 AM
> To: Om Prakash PAL
> Cc: Gary Thomas; yocto@yoctoproject.org
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>
> On Thu, Jun 21, 2012 at 10:37 PM, Om Prakash PAL
> <omprakash.pal@stericsson.com>  wrote:
>>
>>>> and then console got  stuck.
>>>
>>>> What do you have SERIAL_CONSOLE set to in your configuration?
>>>
>>> I have set SERIAL_CONSOLE="115200 ttyAMA2". As we are using ttyAMA2 for console.
>>
>>> What is your target device?  Do you really have /dev/ttyAMA2 serial port??.
>>
>> Yes, I have /dev/ttyAMA2 serial port.
>
> Can you try using say poky/master and generate root file system and
> try that out ?
> another option is to try core-image-core
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: Porting of specific Kernel/Driver into yocto.

[Gary Thomas]

On 2012-06-25 07:08, Bruce Ashfield wrote:
> On 12-06-25 08:53 AM, Om Prakash PAL wrote:
>> Hi Khem,
>> I have build core-image-core. but still this Error:
>> ======================================================>
>> 11.165466] EXT3-fs (mmcblk0p1): mounted filesystem with writeback data mode
>> [ 11.172668] VFS: Mounted root (ext3 filesystem) on device 179:1.
>> [ 11.179260] Freeing init memory: 316K
>> INIT: version 2.88 booting
>> Error Cannot open /dev/tty0: No such device or address
>> mknod: /dev/console: File exists
>>
>> =========================================================>
>>
>> I have set SERIAL_CONSOLE="115200 ttyAMA2" then why its taking /dev/tty0 ?.
>
> I've lost some of the context on the board you are working with, but
> from ttyAMA2, I'm assuming it is an arm board. Have you verified that your
> bootloader can pass the kernel bootline properly to the kernel ? It is
> (unfortunately) fairly common that it isn't properly passed. If you
> modify your configuration to have a built in command line with your
> configuration, you may be able to get better setup to debug the
> problem.

Note: if you (Om Prakash PAL) could send the entire boot log, we could make more
sense of your issues.  For example, the actual name(s) of serial devices supported
by the kernel will be listed there.

Also, I seem to recall that you had 'console=tty0' in your bootargs.

Send the complete log...

>> please help.
>>
>> Best Regards,
>> Om Prakash Pal
>> _______________________________________
>> From: Khem Raj [raj.khem@gmail.com]
>> Sent: Friday, June 22, 2012 11:18 AM
>> To: Om Prakash PAL
>> Cc: Gary Thomas; yocto@yoctoproject.org
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> On Thu, Jun 21, 2012 at 10:37 PM, Om Prakash PAL
>> <omprakash.pal@stericsson.com> wrote:
>>>
>>>>> and then console got stuck.
>>>>
>>>>> What do you have SERIAL_CONSOLE set to in your configuration?
>>>>
>>>> I have set SERIAL_CONSOLE="115200 ttyAMA2". As we are using ttyAMA2 for console.
>>>
>>>> What is your target device? Do you really have /dev/ttyAMA2 serial port??.
>>>
>>> Yes, I have /dev/ttyAMA2 serial port.
>>
>> Can you try using say poky/master and generate root file system and
>> try that out ?
>> another option is to try core-image-core
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Porting of specific Kernel/Driver into yocto.

[Om Prakash PAL]

Hi Bruce,
Yes,its arm board.
Yes, I have verified and kernel bootline is properly passed to the kernel by bootloader.

Best Regards,
Om Prakash Pal
 
-----Original Message-----
From: Bruce Ashfield [mailto:bruce.ashfield@windriver.com] 
Sent: Monday, June 25, 2012 6:38 PM
To: Om Prakash PAL
Cc: Khem Raj; yocto@yoctoproject.org
Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.

On 12-06-25 08:53 AM, Om Prakash PAL wrote:
> Hi Khem,
> I have build core-image-core. but still this Error:
> ======================================================>
>     11.165466] EXT3-fs (mmcblk0p1): mounted filesystem with writeback data mode
> [   11.172668] VFS: Mounted root (ext3 filesystem) on device 179:1.
> [   11.179260] Freeing init memory: 316K
> INIT: version 2.88 booting
> Error Cannot open /dev/tty0: No such device or address
> mknod: /dev/console: File exists
>
> =========================================================>
>
> I have set SERIAL_CONSOLE="115200 ttyAMA2"  then why its taking /dev/tty0 ?.

I've lost some of the context on the board you are working with, but
from ttyAMA2, I'm assuming it is an arm board. Have you verified that your
bootloader can pass the kernel bootline properly to the kernel ? It is
(unfortunately) fairly common that it isn't properly passed. If you
modify your configuration to have a built in command line with your
configuration, you may be able to get better setup to debug the
problem.

Cheers,

Bruce

> please help.
>
> Best Regards,
> Om Prakash Pal
> _______________________________________
> From: Khem Raj [raj.khem@gmail.com]
> Sent: Friday, June 22, 2012 11:18 AM
> To: Om Prakash PAL
> Cc: Gary Thomas; yocto@yoctoproject.org
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>
> On Thu, Jun 21, 2012 at 10:37 PM, Om Prakash PAL
> <omprakash.pal@stericsson.com>  wrote:
>>
>>>> and then console got  stuck.
>>>
>>>> What do you have SERIAL_CONSOLE set to in your configuration?
>>>
>>> I have set SERIAL_CONSOLE="115200 ttyAMA2". As we are using ttyAMA2 for console.
>>
>>> What is your target device?  Do you really have /dev/ttyAMA2 serial port??.
>>
>> Yes, I have /dev/ttyAMA2 serial port.
>
> Can you try using say poky/master and generate root file system and
> try that out ?
> another option is to try core-image-core
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: Porting of specific Kernel/Driver into yocto.

[Bruce Ashfield]

On 12-06-25 10:06 AM, Om Prakash PAL wrote:
> Hi Bruce,
> Yes,its arm board.
> Yes, I have verified and kernel bootline is properly passed to the kernel by bootloader.

And does it (the bootline) contain /dev/tty0 ? .. because if things are
properly configured, it really shouldn't be trying to open it.

Cheers,

Bruce

>
> Best Regards,
> Om Prakash Pal
>
> -----Original Message-----
> From: Bruce Ashfield [mailto:bruce.ashfield@windriver.com]
> Sent: Monday, June 25, 2012 6:38 PM
> To: Om Prakash PAL
> Cc: Khem Raj; yocto@yoctoproject.org
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>
> On 12-06-25 08:53 AM, Om Prakash PAL wrote:
>> Hi Khem,
>> I have build core-image-core. but still this Error:
>> ======================================================>
>>      11.165466] EXT3-fs (mmcblk0p1): mounted filesystem with writeback data mode
>> [   11.172668] VFS: Mounted root (ext3 filesystem) on device 179:1.
>> [   11.179260] Freeing init memory: 316K
>> INIT: version 2.88 booting
>> Error Cannot open /dev/tty0: No such device or address
>> mknod: /dev/console: File exists
>>
>> =========================================================>
>>
>> I have set SERIAL_CONSOLE="115200 ttyAMA2"  then why its taking /dev/tty0 ?.
>
> I've lost some of the context on the board you are working with, but
> from ttyAMA2, I'm assuming it is an arm board. Have you verified that your
> bootloader can pass the kernel bootline properly to the kernel ? It is
> (unfortunately) fairly common that it isn't properly passed. If you
> modify your configuration to have a built in command line with your
> configuration, you may be able to get better setup to debug the
> problem.
>
> Cheers,
>
> Bruce
>
>> please help.
>>
>> Best Regards,
>> Om Prakash Pal
>> _______________________________________
>> From: Khem Raj [raj.khem@gmail.com]
>> Sent: Friday, June 22, 2012 11:18 AM
>> To: Om Prakash PAL
>> Cc: Gary Thomas; yocto@yoctoproject.org
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> On Thu, Jun 21, 2012 at 10:37 PM, Om Prakash PAL
>> <omprakash.pal@stericsson.com>   wrote:
>>>
>>>>> and then console got  stuck.
>>>>
>>>>> What do you have SERIAL_CONSOLE set to in your configuration?
>>>>
>>>> I have set SERIAL_CONSOLE="115200 ttyAMA2". As we are using ttyAMA2 for console.
>>>
>>>> What is your target device?  Do you really have /dev/ttyAMA2 serial port??.
>>>
>>> Yes, I have /dev/ttyAMA2 serial port.
>>
>> Can you try using say poky/master and generate root file system and
>> try that out ?
>> another option is to try core-image-core
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>

Re: Porting of specific Kernel/Driver into yocto.

[Om Prakash PAL]

[-- Attachment #1: Type: text/plain, Size: 3413 bytes --]

Hi Gary,
Please find the attached log.
In bootargs, you can check it 'console=ttyAMA2'

Best Regards,
Om Prakash Pal

-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Gary Thomas
Sent: Monday, June 25, 2012 6:42 PM
To: yocto@yoctoproject.org
Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.

On 2012-06-25 07:08, Bruce Ashfield wrote:
> On 12-06-25 08:53 AM, Om Prakash PAL wrote:
>> Hi Khem,
>> I have build core-image-core. but still this Error:
>> ======================================================>
>> 11.165466] EXT3-fs (mmcblk0p1): mounted filesystem with writeback data mode
>> [ 11.172668] VFS: Mounted root (ext3 filesystem) on device 179:1.
>> [ 11.179260] Freeing init memory: 316K
>> INIT: version 2.88 booting
>> Error Cannot open /dev/tty0: No such device or address
>> mknod: /dev/console: File exists
>>
>> =========================================================>
>>
>> I have set SERIAL_CONSOLE="115200 ttyAMA2" then why its taking /dev/tty0 ?.
>
> I've lost some of the context on the board you are working with, but
> from ttyAMA2, I'm assuming it is an arm board. Have you verified that your
> bootloader can pass the kernel bootline properly to the kernel ? It is
> (unfortunately) fairly common that it isn't properly passed. If you
> modify your configuration to have a built in command line with your
> configuration, you may be able to get better setup to debug the
> problem.

Note: if you (Om Prakash PAL) could send the entire boot log, we could make more
sense of your issues.  For example, the actual name(s) of serial devices supported
by the kernel will be listed there.

Also, I seem to recall that you had 'console=tty0' in your bootargs.

Send the complete log...

>> please help.
>>
>> Best Regards,
>> Om Prakash Pal
>> _______________________________________
>> From: Khem Raj [raj.khem@gmail.com]
>> Sent: Friday, June 22, 2012 11:18 AM
>> To: Om Prakash PAL
>> Cc: Gary Thomas; yocto@yoctoproject.org
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> On Thu, Jun 21, 2012 at 10:37 PM, Om Prakash PAL
>> <omprakash.pal@stericsson.com> wrote:
>>>
>>>>> and then console got stuck.
>>>>
>>>>> What do you have SERIAL_CONSOLE set to in your configuration?
>>>>
>>>> I have set SERIAL_CONSOLE="115200 ttyAMA2". As we are using ttyAMA2 for console.
>>>
>>>> What is your target device? Do you really have /dev/ttyAMA2 serial port??.
>>>
>>> Yes, I have /dev/ttyAMA2 serial port.
>>
>> Can you try using say poky/master and generate root file system and
>> try that out ?
>> another option is to try core-image-core
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[-- Attachment #2: log.txt --]
[-- Type: text/plain, Size: 41748 bytes --]

Starting kernel ...  arch 2368

Uncompressing Linux... done, booting the kernel.
[    0.000000] Linux version 3.0.8-yoctized-standard+ (apallan@apallan-OptiPlex-GX280) (gcc version 4.6.1 20110627 (prerelease) (GCC) ) #1 SMP PREEMPT Fri Jun 22 17:17:16 IST 2012
[    0.000000] CPU: ARMv7 Processor [412fc091] revision 1 (ARMv7), cr=10c5387f
[    0.000000] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine: ST-Ericsson MOP500 platform
[    0.000000] Memory policy: ECC disabled, Data cache writealloc
[    0.000000] DB8500 v2.0 [0x008500b0]
[    0.000000] PERCPU: Embedded 7 pages/cpu @c12e4000 s7680 r8192 d12800 u32768
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 78848
[    0.000000] Kernel command line: root=/dev/mmcblk0p1 rw blkdevparts=mmcblk0:655360@101376,256@0,2048@1024 rootwait rootfstype=ext3 console=ttyAMA2,115200n8 mem=96M@0 mem_mtrace=15M@96M mem_mshared=1M@111M mem_modem=16M@112M mem=88M@128M hwmem=167M@216M mem_issw=1M@383M mem=128M@384M
[    0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Memory: 96MB 88MB 128MB = 312MB total
[    0.000000] Memory: 301272k/301272k available, 18216k reserved, 0K highmem
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     DMA     : 0xfee00000 - 0xffe00000   (  16 MB)
[    0.000000]     vmalloc : 0xe0800000 - 0xf7800000   ( 368 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .init : 0xc0008000 - 0xc0057000   ( 316 kB)
[    0.000000]       .text : 0xc0057000 - 0xc08ac8a0   (8535 kB)
[    0.000000]       .data : 0xc08ae000 - 0xc0933b88   ( 535 kB)
[    0.000000]        .bss : 0xc0933bac - 0xc0ede5c8   (5803 kB)
[    0.000000] Preemptible hierarchical RCU implementation.
[    0.000000] NR_IRQS:670
[    0.000000] PRCMU firmware: U8500, version 3.5.6
[    0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms
[    0.149993] Calibrating delay using timer specific routine.. 4.80 BogoMIPS (lpj=24043)
[    0.150024] pid_max: default: 32768 minimum: 301
[    0.150390] Mount-cache hash table entries: 512
[    0.151519] Initializing cgroup subsys cpuacct
[    0.151672] CPU: Testing write buffer coherency: ok
[    0.151733] ftrace: allocating 20829 entries in 62 pages
[    0.174896] CPU0: thread -1, cpu 0, socket 3, mpidr 80000300
[    0.175048] hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available
[    0.175170] L310 cache controller enabled
[    0.175170] l2x0: 8 ways, CACHE_ID 0x410000c5, AUX_CTRL 0x7ec60800, Cache size: 524288 B
[    0.295715] CPU1: Booted secondary processor
[    0.295745] CPU1: thread -1, cpu 1, socket 3, mpidr 80000301
[    0.315246] Brought up 2 CPUs
[    0.315277] SMP: Total of 2 processors activated (9.61 BogoMIPS).
[    0.327331] print_constraints: dummy:
[    0.327789] NET: Registered protocol family 16
[    0.331695] gpio gpio.0: Bits 0-31 at address f812e000
[    0.332214] gpio gpio.1: Bits 32-63 at address f812e080
[    0.332885] gpio gpio.2: Bits 64-95 at address f800e000
[    0.333312] gpio gpio.3: Bits 96-127 at address f800e080
[    0.333984] gpio gpio.4: Bits 128-159 at address f800e100
[    0.334503] gpio gpio.5: Bits 160-191 at address f800e180
[    0.335174] gpio gpio.6: Bits 192-223 at address f811e000
[    0.335723] gpio gpio.7: Bits 224-255 at address f811e080
[    0.336273] gpio gpio.8: Bits 256-287 at address fa3fe000
[    0.343383] hw-breakpoint: found 6 breakpoint and 1 watchpoint registers.
[    0.343383] hw-breakpoint: 1 breakpoint(s) reserved for watchpoint single-step.
[    0.343414] hw-breakpoint: maximum watchpoint size is 4 bytes.
[    0.343566] dbx500_dump: driver initialized
[    0.345764] stm stm: STM-Trace driver probed successfully
[    0.346618] print_constraints: db8500-vape:
[    0.346923] print_constraints: db8500-varm:
[    0.347198] print_constraints: db8500-vmodem:
[    0.347412] print_constraints: db8500-vpll:
[    0.347656] print_constraints: db8500-vsmps1:
[    0.347900] print_constraints: db8500-vsmps2:
[    0.348175] print_constraints: db8500-vsmps3:
[    0.348419] print_constraints: db8500-vrf1:
[    0.348663] print_constraints: db8500-sva-mmdsp:
[    0.348937] print_constraints: db8500-sva-mmdsp-ret:
[    0.349151] print_constraints: db8500-sva-pipe:
[    0.349426] print_constraints: db8500-sia-mmdsp:
[    0.349670] print_constraints: db8500-sia-mmdsp-ret:
[    0.349914] print_constraints: db8500-sia-pipe:
[    0.350189] print_constraints: db8500-sga:
[    0.350219] set_supply: db8500-sga: supplied by db8500-vape
[    0.350494] print_constraints: db8500-b2r2-mcde:
[    0.350524] set_supply: db8500-b2r2-mcde: supplied by db8500-vape
[    0.350769] print_constraints: db8500-esram12:
[    0.351043] print_constraints: db8500-esram12-ret:
[    0.351318] print_constraints: db8500-esram34:
[    0.351593] print_constraints: db8500-esram34-ret:
[    0.352325] DB8500 PRCMU initialized
[    0.352691] ab8500-i2c ab8500-i2c.0: detected chip, AB8500 rev. 2.0
[    0.352722] ab8500-i2c ab8500-i2c.0: switch off reason(s) (0x40): "Power on key 1 pressed longer than 10 seconds"
[    0.389678] bio: create slab <bio-0> at 0
[    0.390655] dma40 dma40.0: managed by runtime pm: regulator
[    0.390747] dma40 dma40.0: hardware revision: 3 @ 0x801c0000
[    0.390838] dma40 dma40.0: 6 of 8 physical DMA channels available
[    0.390838] dma40 dma40.0: [d40_phy_res_init] INFO: channel 4 is misconfigured (0)
[    0.390869] dma40 dma40.0: [d40_phy_res_init] INFO: channel 5 is misconfigured (0)
[    0.390869] dma40 dma40.0: [d40_phy_res_init] INFO: channel 6 is misconfigured (0)
[    0.402740] dma40 dma40.0: initialized
[    0.407623] print_constraints: ab8500-ext-supply1: 1800 mV
[    0.408081] print_constraints: ab8500-ext-supply2: 1360 mV
[    0.408416] print_constraints: ab8500-ext-supply3: 3400 mV
[    0.408782] print_constraints: V-DISPLAY: 2800 <--> 3300 mV at 2800 mV
[    0.408813] set_supply: V-DISPLAY: supplied by ab8500-ext-supply3
[    0.409179] print_constraints: V-eMMC1: 1100 <--> 3300 mV at 2900 mV normal idle
[    0.409210] set_supply: V-eMMC1: supplied by ab8500-ext-supply3
[    0.409545] print_constraints: V-MMC-SD: 1200 <--> 2910 mV at 2910 mV normal idle
[    0.409576] set_supply: V-MMC-SD: supplied by ab8500-ext-supply3
[    0.409881] print_constraints: V-INTCORE: 1250 <--> 1350 mV at 1250 mV normal idle
[    0.410186] print_constraints: V-TVOUT: 2000 mV
[    0.410491] print_constraints: V-AUD: 2000 mV
[    0.410766] print_constraints: V-AMIC1: 2050 mV
[    0.411041] print_constraints: V-AMIC2: 2050 mV
[    0.411346] print_constraints: V-DMIC: 1800 mV
[    0.411621] print_constraints: V-CSI-DSI: 1200 mV
[    0.411895] print_constraints: V-SYSCLKREQ-2: 0 mV
[    0.412200] print_constraints: V-SYSCLKREQ-4: 0 mV
[    0.412475] Serial: AMBA PL011 UART driver
[    0.412658] uart0: ttyAMA0 at MMIO 0x80120000 (irq = 43) is a PL011 rev3
[    0.435577] uart1: ttyAMA1 at MMIO 0x80121000 (irq = 51) is a PL011 rev3
[    0.465606] uart2: ttyAMA2 at MMIO 0x80007000 (irq = 58) is a PL011 rev3
[    1.125457] console [ttyAMA2] enabled
[    1.157562] hwmem hwmem.0: Probed OK
[    1.163909] SCSI subsystem initialized
[    1.167724] ssp-pl022 ssp0: managed by runtime pm: regulator
[    1.173522] ssp-pl022 ssp0: ARM PL022 driver, device ID: 0x01080022
[    1.179840] pl022: mapped registers from 0x80002000 to e0858000
[    1.185852] ssp-pl022 ssp0: setup for DMA on RX dma0chan0, TX dma0chan1
[    1.193725] usbcore: registered new interface driver usbfs
[    1.199432] usbcore: registered new interface driver hub
[    1.204925] usbcore: registered new device driver usb
[    1.210052] musb-ux500 musb-ux500.0: managed by runtime pm: pins
[    1.217620] ab8500-usb ab8500-usb.0: revision 0x20 driver initialized
[    1.225372] nmk-i2c nmk-i2c.0: managed by runtime pm: pins
[    1.231079] nmk-i2c nmk-i2c.0: initialize Nomadik I2C0 at 80004000 on virtual base e085a000
[    1.240234] tc3589x 0-0042: manufacturer: 0x3, version: 0x1
[    1.248229] tc3589x 0-0042: added gpio block
[    1.252777] nmk-i2c nmk-i2c.1: managed by runtime pm: pins
[    1.258453] nmk-i2c nmk-i2c.1: initialize Nomadik I2C1 at 80122000 on virtual base e085c000
[    1.267059] nmk-i2c nmk-i2c.2: managed by runtime pm: pins
[    1.272705] nmk-i2c nmk-i2c.2: initialize Nomadik I2C2 at 80128000 on virtual base e085e000
[    1.281860] nmk-i2c nmk-i2c.3: managed by runtime pm: pins
[    1.287567] nmk-i2c nmk-i2c.3: initialize Nomadik I2C3 at 80110000 on virtual base e0860000
[    1.297760] Advanced Linux Sound Architecture Driver Version 1.0.24.
[    1.305175] Bluetooth: Core ver 2.16
[    1.308929] NET: Registered protocol family 31
[    1.313385] Bluetooth: HCI device and connection manager initialized
[    1.319763] Bluetooth: HCI socket layer initialized
[    1.324615] Bluetooth: L2CAP socket layer initialized
[    1.329711] Bluetooth: SCO socket layer initialized
[    1.335174] cfg80211: Calling CRDA to update world regulatory domain
[    1.352874] Switching to clocksource dbx500-prcmu-timer
[    1.366973] Switched to NOHz mode on CPU #0
[    1.367523] Switched to NOHz mode on CPU #1
[    1.379638] MCDE subsystem init begin
[    1.383514] mcde mcde: MCDE iomap: 0xA0350000->0xE0862000
[    1.389068] mcde mcde: Probe HW
[    1.392303] mcde mcde: MCDE HW revision 0x03000800
[    1.397186] mcde mcde: db8500 V2 HW
[    1.401184] mcde mcde: MCDE_CLK is 159744000 Hz
[    1.407379] MCDE subsystem init done
[    1.411102] dsilink dsilink.0: iomap: 0xA0351000->0xE0864000
[    1.416870] dsilink dsilink.0: hw revision 0x02327457
[    1.422149] dsilink dsilink.1: iomap: 0xA0352000->0xE0866000
[    1.427978] dsilink dsilink.1: hw revision 0x02327457
[    1.433288] dsilink dsilink.2: iomap: 0xA0353000->0xE0868000
[    1.439147] dsilink dsilink.2: hw revision 0x02327457
[    1.447143] musb-hdrc: version 6.0, ux500-dma, otg (peripheral+host)
[    1.454467] musb-hdrc musb-hdrc: USB OTG mode controller at e0880000 using DMA, IRQ 55
[    1.463195] NET: Registered protocol family 2
[    1.467864] IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
[    1.475952] TCP established hash table entries: 16384 (order: 5, 131072 bytes)
[    1.483581] TCP bind hash table entries: 16384 (order: 5, 196608 bytes)
[    1.490539] TCP: Hash tables configured (established 16384 bind 16384)
[    1.497070] TCP reno registered
[    1.500244] UDP hash table entries: 256 (order: 1, 8192 bytes)
[    1.506103] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
[    1.512939] NET: Registered protocol family 1
[    1.517639] PMU: registered new PMU device of type 0
[    1.525115] Use-case governor initialized
[    1.728485] nmk-i2c nmk-i2c.0: Write to slave 0x44 timed out
[    1.734222] nmk-i2c nmk-i2c.0: no ack received after address transmission
[    1.938690] nmk-i2c nmk-i2c.0: Write to slave 0x44 timed out
[    1.944366] nmk-i2c nmk-i2c.0: no ack received after address transmission
[    2.148651] nmk-i2c nmk-i2c.0: Write to slave 0x44 timed out
[    2.154327] nmk-i2c nmk-i2c.0: no ack received after address transmission
[    2.358703] nmk-i2c nmk-i2c.3: Write to slave 0x5c timed out
[    2.364349] nmk-i2c nmk-i2c.3: no ack received after address transmission
[    2.371459] ab8500-btemp ab8500-btemp.0: Battery identified as unknown, resistance 6694 Ohm
[    2.379821] ab8500-btemp ab8500-btemp.0: failed to identify the battery
[    2.569000] nmk-i2c nmk-i2c.3: Write to slave 0x5c timed out
[    2.574676] nmk-i2c nmk-i2c.3: no ack received after address transmission
[    2.779083] nmk-i2c nmk-i2c.3: Write to slave 0x5c timed out
[    2.784729] nmk-i2c nmk-i2c.3: no ack received after address transmission
[    2.791625] mop500-uib: ST-UIB (detected)
[    2.796234] stmpe-i2c 0-0040: stmpe1601 detected, chip id: 0x212
[    2.999114] nmk-i2c nmk-i2c.2: Write to slave 0x18 timed out
[    3.004791] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    3.209167] nmk-i2c nmk-i2c.2: Write to slave 0x18 timed out
[    3.214813] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    3.419158] nmk-i2c nmk-i2c.2: Write to slave 0x18 timed out
[    3.424804] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    3.629180] nmk-i2c nmk-i2c.2: Write to slave 0x19 timed out
[    3.634857] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    3.839202] nmk-i2c nmk-i2c.2: Write to slave 0x19 timed out
[    3.844848] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    4.049224] nmk-i2c nmk-i2c.2: Write to slave 0x19 timed out
[    4.054870] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    4.061706]  Failed to get Accelerometr chip ID
[    4.068084] ux500-product: u8500 detected
[    4.072113] ux500-product: JTAG is enabled
[    4.083679] ashmem: initialized
[    4.087219] VFS: Disk quotas dquot_6.5.2
[    4.091430] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    4.098846] Installing v9fs 9p2000 file system support
[    4.104095] msgmni has been set to 588
[    4.108886] io scheduler noop registered
[    4.112823] io scheduler deadline registered (default)
[    4.118041] io scheduler cfq registered
[    4.122772] samsung_s6d16d0 samsung_s6d16d0.0: Samsung s6d16d0 display probed
[    4.262725] samsung_s6d16d0 samsung_s6d16d0.0: Framebuffer created (samsung_s6d16d0)
[    4.270843] samsung_s6d16d0 samsung_s6d16d0.0: compdev created for (samsung_s6d16d0)
[    4.279327] samsung_s6d16d0 samsung_s6d16d0.1: Samsung s6d16d0 display probed
[    4.408905] ------------[ cut here ]------------
[    4.413543] WARNING: at /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-u8500-3.2+git1+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r17/linux/drivers/video/mcde/mcde_display.c:219 mcde_display_set_rotation_default+0xac/0xb4()
[    4.435272] Modules linked in:
[    4.438385] [<c00657bc>] (unwind_backtrace+0x0/0x144) from [<c060eb74>] (dump_stack+0x20/0x24)
[    4.447021] [<c060eb74>] (dump_stack+0x20/0x24) from [<c00925f0>] (warn_slowpath_common+0x5c/0x74)
[    4.455993] [<c00925f0>] (warn_slowpath_common+0x5c/0x74) from [<c0092634>] (warn_slowpath_null+0x2c/0x34)
[    4.465698] [<c0092634>] (warn_slowpath_null+0x2c/0x34) from [<c028dd98>] (mcde_display_set_rotation_default+0xac/0xb4)
[    4.476501] [<c028dd98>] (mcde_display_set_rotation_default+0xac/0xb4) from [<c028d9c8>] (mcde_dss_enable_display+0x78/0x10c)
[    4.487823] [<c028d9c8>] (mcde_dss_enable_display+0x78/0x10c) from [<c028f508>] (mcde_fb_create+0x104/0x36c)
[    4.497680] [<c028f508>] (mcde_fb_create+0x104/0x36c) from [<c00786e8>] (display_postregistered_callback+0x8c/0x124)
[    4.508239] [<c00786e8>] (display_postregistered_callback+0x8c/0x124) from [<c00ba5c0>] (notifier_call_chain.isra.0+0x54/0x94)
[    4.519653] [<c00ba5c0>] (notifier_call_chain.isra.0+0x54/0x94) from [<c00ba7e8>] (__blocking_notifier_call_chain+0x58/0x70)
[    4.530883] [<c00ba7e8>] (__blocking_notifier_call_chain+0x58/0x70) from [<c00ba828>] (blocking_notifier_call_chain+0x28/0x30)
[    4.542297] [<c00ba828>] (blocking_notifier_call_chain+0x28/0x30) from [<c028e780>] (bus_notify_callback+0x58/0x60)
[    4.552764] [<c028e780>] (bus_notify_callback+0x58/0x60) from [<c00ba5c0>] (notifier_call_chain.isra.0+0x54/0x94)
[    4.563018] [<c00ba5c0>] (notifier_call_chain.isra.0+0x54/0x94) from [<c00ba7e8>] (__blocking_notifier_call_chain+0x58/0x70)
[    4.574279] [<c00ba7e8>] (__blocking_notifier_call_chain+0x58/0x70) from [<c00ba828>] (blocking_notifier_call_chain+0x28/0x30)
[    4.585662] [<c00ba828>] (blocking_notifier_call_chain+0x28/0x30) from [<c0300144>] (driver_bound+0x78/0xd0)
[    4.595520] [<c0300144>] (driver_bound+0x78/0xd0) from [<c0300500>] (driver_probe_device+0xd0/0x298)
[    4.604675] [<c0300500>] (driver_probe_device+0xd0/0x298) from [<c0300764>] (__driver_attach+0x9c/0xa0)
[    4.614074] [<c0300764>] (__driver_attach+0x9c/0xa0) from [<c02ff3ac>] (bus_for_each_dev+0x6c/0x98)
[    4.623138] [<c02ff3ac>] (bus_for_each_dev+0x6c/0x98) from [<c03000c8>] (driver_attach+0x2c/0x30)
[    4.632049] [<c03000c8>] (driver_attach+0x2c/0x30) from [<c02ffcec>] (bus_add_driver+0x198/0x278)
[    4.640930] [<c02ffcec>] (bus_add_driver+0x198/0x278) from [<c0300cdc>] (driver_register+0x88/0x14c)
[    4.650085] [<c0300cdc>] (driver_register+0x88/0x14c) from [<c028e70c>] (mcde_display_driver_register+0x68/0x84)
[    4.660278] [<c028e70c>] (mcde_display_driver_register+0x68/0x84) from [<c001fd80>] (samsung_s6d16d0_init+0x14/0x1c)
[    4.670837] [<c001fd80>] (samsung_s6d16d0_init+0x14/0x1c) from [<c0057700>] (do_one_initcall+0x4c/0x190)
[    4.680328] [<c0057700>] (do_one_initcall+0x4c/0x190) from [<c0008a3c>] (kernel_init+0x98/0x144)
[    4.689147] [<c0008a3c>] (kernel_init+0x98/0x144) from [<c005f248>] (kernel_thread_exit+0x0/0x8)
[    4.697937] ---[ end trace 65f8ea860415c04f ]---
[    4.702575] samsung_s6d16d0 samsung_s6d16d0.1: Failed to set rotation
[    4.711151] samsung_s6d16d0 samsung_s6d16d0.1: Framebuffer created (samsung_s6d16d0)
[    4.719146] mcde_display_sony_acx424akp_init
[    4.725555] av8100 0-0070: chip version:2
[    4.729980] b2r2_blt_init
[    4.732727] b2r2_blt b2r2_blt_init: b2r2_blt_probe start.
[    4.738342] b2r2_blt b2r2_blt_init: b2r2_blt_probe done.
[    4.743896] b2r2_init
[    4.746246] b2r2 b2r2_core: init started.
[    4.752960] b2r2 b2r2_core: b2r2_mem_init: Creating heap for size 16384 bytes
[    4.760498] b2r2 b2r2_core: b2r2_probe done.
[    4.765747] uart-pl011 uart0: no DMA platform data
[    4.770538] uart-pl011 uart1: no DMA platform data
[    4.775329] uart-pl011 uart2: no DMA platform data
[    4.781402] Mali<2>:
[    4.783660] Mali<2>: Inserting Mali v10 device driver.
[    4.788940] Mali<2>: Compiled: Jun 22 2012, time: 16:47:22.
[    4.794494] Mali<2>: Svn revision: r2p4-02rel0
[    4.798980] Mali<2>: MMU memory system initializing
[    4.803863] Mali<2>: Rendercore: subsystem global mutex initialized
[    4.810150] Mali<2>: Core: subsystem_init: Mali-400 PP
[    4.815277] Mali<2>: Core: subsystem_init: Mali-400 GP
[    4.820434] Mali<2>: Mali L2 cache system initializing
[    4.825897] Mali<2>: MMU registered
[    4.829437] Mali<2>: MMU registered
[    4.832916] Mali<2>: Mali OS memory allocator created with max allocation size of 0x7FF00000 bytes, cpu_usage_adjust 0x00000000
[    4.844421] Mali<2>: Memory Validator 'Framebuffer' installed for Mali physical address base==0x00000000, size==0x7FF00000, cpu_adjust==0x00000000
[    4.857574] Mali<2>: Creating Mali L2 cache: Mali-400 L2 cache
[    4.863433] Mali<1>: Mali memory allocators will be used in this order of preference (lowest numbered first) :
[    4.873474] Mali<1>:         5: Linux kernel memory
[    4.878479] Mali<2>: Attach mmu: 0xdf351a80 to core: Mali-400 PP in subsystem: Mali-400 PP
[    4.886901] Mali<2>: Attach mmu: 0xdf351ae0 to core: Mali-400 GP in subsystem: Mali-400 GP
[    4.895172] Mali<2>: Mali L2 cache system load complete
[    4.900482] Mali: Mali device driver r2p4-02rel0 loaded
[    4.905700] Mali<2>: malidrv:  CONFIG=ux500 USING_OS_MEMORY=1 API_VERSION=10 REPO_URL=r2p4-02rel0 REVISION=r2p4-02rel0 CHANGED_REVISION=r2p4-02rel0 CHANGE_DATE=r2p4-02rel0 BUILD_DATE=Fri Mar 23 06:31:20 IST 2012 BUILD=DEBUG CPU=ux500 USING_UMP=1 USING_HWMEM=1 USING_PMM=1 USING_MALI200=0 USING_MALI400=3 USING_MALI400_L2_CACHE=1 USING_GP2=0 KDIR= MALI_PLATFORM_FILE=platform/ux500/mali_platform.c OS_MEMORY_KERNEL_BUFFER_SIZE_IN_MB=6 USING_PROFILING=0 USING_GPU_UTILIZATION=1 USING_MALI_RUN_TIME_PM=0
[    4.959930] brd: module loaded
[    4.968292] loop: module loaded
[    4.971893] bh1780 2-0029: Ambient Light Sensor, Rev : 1
[    4.979095] dbx500_mloader_fw dbx500_mloader_fw: mloader device register
[    4.985992] compdev_init
[    4.988555] clonedev_init
[    4.993164] PPP generic driver version 2.4.2
[    4.998474] PPP MPPE Compression module registered
[    5.003295] NET: Registered protocol family 24
[    5.007751] tun: Universal TUN/TAP device driver, 1.6
[    5.013397] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[    5.020965] usbcore: registered new interface driver cdc_acm
[    5.026611] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[    5.034698] Initializing USB Mass Storage driver...
[    5.039764] usbcore: registered new interface driver usb-storage
[    5.045776] USB Mass Storage support registered.
[    5.050811] usbcore: registered new interface driver libusual
[    5.061035] android_usb gadget: Mass Storage Function, version: 2009/09/11
[    5.067901] android_usb gadget: Number of LUNs=2
[    5.072570]  lun0: LUN: removable file: (no medium)
[    5.077453]  lun1: LUN: removable file: (no medium)
[    5.082946] android_usb gadget: android_usb ready
[    5.087677] musb-hdrc musb-hdrc: MUSB HDRC host driver
[    5.093139] musb-hdrc musb-hdrc: new USB bus registered, assigned bus number 1
[    5.101379] hub 1-0:1.0: USB hub found
[    5.105133] hub 1-0:1.0: 1 port detected
[    5.109619] gpio-keys gpio-keys.0: managed by runtime pm: pins
[    5.118530] input: gpio-keys as /devices/platform/gpio-keys.0/input/input0
[    5.126831] input: ux500-ske-keypad as /devices/platform/nmk-ske-keypad/input/input1
[    5.138641] input: STMPE-keypad as /devices/platform/nmk-i2c.0/i2c-0/0-0040/stmpe-keypad.1/input/input2
[    5.190856] input: bu21013_ts as /devices/platform/nmk-i2c.3/i2c-3/3-005c/input/input3
[    5.398986] nmk-i2c nmk-i2c.3: Write to slave 0x5d timed out
[    5.404663] nmk-i2c nmk-i2c.3: no ack received after address transmission
[    5.609222] nmk-i2c nmk-i2c.3: Write to slave 0x5d timed out
[    5.614898] nmk-i2c nmk-i2c.3: no ack received after address transmission
[    5.819305] nmk-i2c nmk-i2c.3: Write to slave 0x5d timed out
[    5.824951] nmk-i2c nmk-i2c.3: no ack received after address transmission
[    5.831848] bu21013_ts 3-005d: BU21013_RESET reg write failed
[    5.837585] bu21013_ts 3-005d: error in bu21013 config
[    5.842773] bu21013_ts: probe of 3-005d failed with error -110
[    5.849029] cyttsp_spi_init: Cypress TrueTouch(R) Standard Product SPI Touchscreen Driver (Built Jun 22 2012 @ 16:49:08) returned 0
[    5.861389] input: AB8500 Hs Button as /devices/platform/ab8500-i2c.0/ab8500-acc-det.0/input/input4
[    5.871490] input: AB8500 POn(PowerOn) Key as /devices/platform/ab8500-i2c.0/ab8500-poweron-key.0/input/input5
[    5.882293] lps001wp_prs: probe start.
[    6.079223] nmk-i2c nmk-i2c.2: Read from Slave 0x5c timed out
[    6.084991] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    6.289184] nmk-i2c nmk-i2c.2: Read from Slave 0x5c timed out
[    6.294921] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    6.499206] nmk-i2c nmk-i2c.2: Read from Slave 0x5c timed out
[    6.504943] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    6.511810] lps001wp_prs 2-005c: i2c_smbus_read_byte error!!
[    6.517486] lps001wp_prs 2-005c: lps001wp_prs: Driver Init failed
[    6.523620] lps001wp_prs: probe of 2-005c failed with error -22
[    6.533966] using rtc device, ab8500-rtc, for alarms
[    6.538818] ab8500-rtc ab8500-rtc.0: rtc core: registered ab8500-rtc as rtc0
[    6.546447] i2c /dev entries driver
[    6.552001] lirc_dev: IR Remote Control driver registered, major 248
[    6.558441] IR NEC protocol handler initialized
[    6.562988] IR RC5(x) protocol handler initialized
[    6.567810] IR RC6 protocol handler initialized
[    6.572326] IR JVC protocol handler initialized
[    6.576873] IR Sony protocol handler initialized
[    6.581512] IR RC5 (streamzap) protocol handler initialized
[    6.587066] IR LIRC bridge handler initialized
[    6.591552] Linux video capture interface: v2.00
[    6.599945] ux500_wdt ux500_wdt: initialized
[    6.604553] device-mapper: uevent: version 1.0.3
[    6.609497] device-mapper: ioctl: 4.20.0-ioctl (2011-02-02) initialised: dm-devel@redhat.com
[    6.618011] Bluetooth: HCI UART driver ver 2.2
[    6.622528] dbx500-cpufreq : Available frequencies:
[    6.627410]   200 Mhz
[    6.629730]   400 Mhz
[    6.631988]   800 Mhz
[    6.634246]   1000 Mhz
[    6.636932] cpuidle: using governor ladder
[    6.641052] cpuidle: using governor menu
[    6.645202] mmci-pl18x sdi2: managed by runtime pm: pins
[    6.650909] mmci-pl18x sdi2: mmc0: PL180 manf 80 rev4 at 0x80005000 irq 73,-1 (pio)
[    6.658599] mmci-pl18x sdi2: DMA channels RX dma0chan18, TX dma0chan19
[    6.666503] mmci-pl18x sdi4: managed by runtime pm: pins
[    6.672180] mmci-pl18x sdi4: mmc1: PL180 manf 80 rev4 at 0x80114000 irq 131,-1 (pio)
[    6.679962] mmci-pl18x sdi4: DMA channels RX dma0chan20, TX dma0chan21
[    6.687805] mmci-pl18x sdi0: managed by runtime pm: pins
[    6.694305] mmci-pl18x sdi0: mmc2: PL180 manf 80 rev4 at 0x80126000 irq 92,-1 (pio)
[    6.702026] mmci-pl18x sdi0: DMA channels RX dma0chan22, TX dma0chan23
[    6.710632] mmci-pl18x sdi1: managed by runtime pm: pins
[    6.718200] mmci-pl18x sdi1: mmc3: PL180 manf 80 rev4 at 0x80118000 irq 82,-1 (pio)
[    6.725891] mmci-pl18x sdi1: DMA channels RX dma0chan24, TX dma0chan25
[    6.772125] lp5521 2-0033: lp5521 programmable led chip found
[    6.784210] mmc0: new high speed MMC card at address 0001
[    6.791900] mmcblk0: mmc0:0001 MMC01G 977 MiB
[    6.797088] mmcblk0boot0: mmc0:0001 MMC01G partition 1 512 KiB
[    6.803955] mmcblk0boot1: mmc0:0001 MMC01G partition 2 512 KiB
[    6.811523]
[    6.811553] Partition: size=655360, offset=101376
[    6.817779]
[    6.817779] Partition: size=256, offset=0
[    6.823455]
[    6.823455] Partition: size=2048, offset=1024
[    6.829650]  mmcblk0: p1 p2 p3
[    6.830474] lp5521 2-0034: lp5521 programmable led chip found
[    6.834533] hash1 hash1: managed by runtime pm: regulator
[    6.844329] hash1 hash1: [ux500_hash_probe] successfully probed
[    6.851043]  mmcblk0boot1: unknown partition table
[    6.856597] usbcore: registered new interface driver usbhid
[    6.862304] usbhid: USB HID core driver
[    6.866271]  mmcblk0boot0: unknown partition table
[    6.867523] platform cg2900.0: CG2900 initialized
[    6.867919] cg2900 cg2900.0: CG2900 Core driver started
[    6.868682] cg2900-test cg2900-test.0: CG2900 test char device driver started
[    6.868988] cg2900-chip cg2900-chip.0: CG2900 chip driver started
[    6.869262] stlc2690-chip stlc2690-chip.0: STLC2690 chip driver started
[    6.901123] Bluetooth: HCI UART driver ver 2.3
[    6.906433] logger: created 256K log 'log_main'
[    6.911376] logger: created 256K log 'log_events'
[    6.916229] logger: created 256K log 'log_radio'
[    6.921142] logger: created 256K log 'log_system'
[    6.926391] ste_timed_output_vibra ste_timed_output_vibra.0: Rotary Type Vibrators
[    7.044219] mmc1: power class selection to bus width 8 failed
[    7.050811] mmc1: new high speed MMC card at address 0001
[    7.058044] mmcblk1: mmc1:0001 MMC08G 7.45 GiB
[    7.063385] mmcblk1boot0: mmc1:0001 MMC08G partition 1 2.00 MiB
[    7.070068] mmcblk1boot1: mmc1:0001 MMC08G partition 2 2.00 MiB
[    7.077301]  mmcblk1: p1 p2
[    7.080261] mmcblk1: p2 size 8016435 extends beyond EOD, truncated
[    7.088317]  mmcblk1boot1: unknown partition table
[    7.094543]  mmcblk1boot0: unknown partition table
[    7.128906] nmk-i2c nmk-i2c.2: Write to slave 0x18 timed out
[    7.134643] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    7.154296] mmc3: card claims to support voltages below the defined range. These will be ignored.
[    7.166564] mmc3: error -110 whilst initialising MMC card
[    7.329040] nmk-i2c nmk-i2c.2: Write to slave 0x18 timed out
[    7.334747] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    7.539367] nmk-i2c nmk-i2c.2: Write to slave 0x18 timed out
[    7.545074] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    7.552246] lsm303dlh_a 2-0018: failed to read of the chip
[    7.557800] lsm303dlh_a: probe of 2-0018 failed with error -110
[    7.759613] nmk-i2c nmk-i2c.2: Write to slave 0x68 timed out
[    7.765350] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    7.969268] nmk-i2c nmk-i2c.2: Write to slave 0x68 timed out
[    7.975097] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    8.179199] nmk-i2c nmk-i2c.2: Write to slave 0x68 timed out
[    8.184906] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    8.192077] l3g4200d 2-0068: failed to read of the chip
[    8.197387] l3g4200d: probe of 2-0068 failed with error -110
[    8.399353] nmk-i2c nmk-i2c.2: Write to slave 0x1e timed out
[    8.405059] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    8.609252] nmk-i2c nmk-i2c.2: Write to slave 0x1e timed out
[    8.615112] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    8.819427] nmk-i2c nmk-i2c.2: Write to slave 0x1e timed out
[    8.825134] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    9.029327] nmk-i2c nmk-i2c.2: Write to slave 0x1e timed out
[    9.035034] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    9.239288] nmk-i2c nmk-i2c.2: Write to slave 0x1e timed out
[    9.244995] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    9.449249] nmk-i2c nmk-i2c.2: Write to slave 0x1e timed out
[    9.455078] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    9.659088] nmk-i2c nmk-i2c.2: Write to slave 0x1e timed out
[    9.664794] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    9.869415] nmk-i2c nmk-i2c.2: Write to slave 0x1e timed out
[    9.875244] nmk-i2c nmk-i2c.2: no ack received after address transmission
[   10.079864] nmk-i2c nmk-i2c.2: Write to slave 0x1e timed out
[   10.085693] nmk-i2c nmk-i2c.2: no ack received after address transmission
[   10.289001] nmk-i2c nmk-i2c.2: Write to slave 0x1e timed out
[   10.294708] nmk-i2c nmk-i2c.2: no ack received after address transmission
[   10.499023] nmk-i2c nmk-i2c.2: Write to slave 0x1e timed out
[   10.504760] nmk-i2c nmk-i2c.2: no ack received after address transmission
[   10.709259] nmk-i2c nmk-i2c.2: Write to slave 0x1e timed out
[   10.714965] nmk-i2c nmk-i2c.2: no ack received after address transmission
[   10.724090] mmio_init
[   10.726684] mmio_probe
[   10.730438] mmio_camera mmio_camera: MMIO driver initialized with minor=44
[   10.738800] i2c i2c-2: Failed to register i2c client adp1653 at 0x30 (-16)
[   10.745941] camera_flash driver initialized with minor=43
[   10.763092] Initialize NMF 2.10.123 Component Manager......
[   10.768676] [ CM Linux Driver 2.10.122 ]
[   10.775115] u8500_shrm shrm_bus: IPC_ISA BOOT_INIT
[   10.781433] u8500_shrm shrm_bus: BOOT_INFO_SYNC
[   10.786132] u8500_shrm shrm_bus: IPC_ISA BOOT_DONE
[   10.791381] u8500_shrm shrm_bus: Registered shrm netdev
[   10.797546] usbcore: registered new interface driver snd-usb-audio
[   10.804779] ab5500_init called.
[   10.808135] ab8500_codec_platform_driver_init: Enter.
[   10.813323] ab8500_codec_driver_probe: Register codec.
[   10.819549] ux500_msp_init: Register ux500-msp-dai platform driver.
[   10.825866] ux500_msp_drv_probe: Enter (pdev->name = ux500-msp-i2s).
[   10.832336] ux500_msp_drv_probe: Registering ux500-msp-dai SoC CPU-DAI.
[   10.838989] ux500_msp_drv_probe: Enter (pdev->name = ux500-msp-i2s).
[   10.845367] ux500_msp_drv_probe: Registering ux500-msp-dai SoC CPU-DAI.
[   10.852020] ux500_msp_drv_probe: Enter (pdev->name = ux500-msp-i2s).
[   10.858398] ux500_msp_drv_probe: Registering ux500-msp-dai SoC CPU-DAI.
[   10.865051] ux500_msp_drv_probe: Enter (pdev->name = ux500-msp-i2s).
[   10.871459] ux500_msp_drv_probe: Registering ux500-msp-dai SoC CPU-DAI.
[   10.878601] av8100_codec_drv_probe: Init codec private data..
[   10.884368] av8100_codec_drv_probe: Register codec.
[   10.889556] cg29xx_codec_driver_probe: Init codec private data..
[   10.895568] cg29xx_codec_driver_probe: Register codec.
[   10.901000] ux500_pcm_drv_probe: Register ux500-pcm SoC platform driver.
[   10.908233] asoc: av8100-codec-dai <-> ux500-msp-i2s.2 mapping ok
[   10.921600] asoc: ab8500-codec-dai.0 <-> ux500-msp-i2s.1 mapping ok
[   10.928466] asoc: ab8500-codec-dai.1 <-> ux500-msp-i2s.3 mapping ok
[   10.935546] asoc: cg29xx-codec-dai.1 <-> ux500-msp-i2s.0 mapping ok
[   10.943176] input: U8500-card AB8500 Hs Status as /devices/platform/soc-audio/sound/card0/input6
[   10.952636] ALSA device list:
[   10.955596]   #0: U8500-card
[   10.958648] Netfilter messages via NETLINK v0.30.
[   10.963470] nf_conntrack version 0.5.0 (4707 buckets, 18828 max)
[   10.969848] ctnetlink v0.93: registering with nfnetlink.
[   10.975189] NF_TPROXY: Transparent proxy support initialized, version 4.1.0
[   10.982147] NF_TPROXY: Copyright (c) 2006-2007 BalaBit IT Ltd.
[   10.989807] ip_tables: (C) 2000-2006 Netfilter Core Team
[   10.995361] TCP cubic registered
[   10.998718] NET: Registered protocol family 10
[   11.006195] ip6_tables: (C) 2000-2006 Netfilter Core Team
[   11.011718] NET: Registered protocol family 17
[   11.016204] NET: Registered protocol family 15
[   11.020782] Bluetooth: RFCOMM TTY layer initialized
[   11.025665] Bluetooth: RFCOMM socket layer initialized
[   11.030883] Bluetooth: RFCOMM ver 1.11
[   11.034637] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   11.039978] Bluetooth: BNEP filters: protocol multicast
[   11.045196] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[   11.051422] NET: Registered protocol family 35
[   11.056030] Installing 9P2000 support
[   11.059814] NET: Registered protocol family 37
[   11.064361] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 2
[   11.072082] Registering SWP/SWPB emulation handler
[   11.078277] l2x0-prefetch: initialized.
[   11.083099] mcde_display_hdmi_init
[   11.086639] av8100_hdmi av8100_hdmi.3: HDMI display probed
[   11.093261] regulator_init_complete: db8500-esram12: disabling
[   11.100616] ab8500-rtc ab8500-rtc.0: setting system clock to 2012-05-11 11:46:18 UTC (1336736778)
[   11.111785] cpuidle: initiated for CPU0.
[   11.117370] cpuidle: initiated for CPU1.
[   11.124389] EXT3-fs (mmcblk0p1): warning: feature flags set on rev 0 fs, running e2fsck is recommended
[   11.136016] EXT3-fs: barriers not enabled
[   11.141143] EXT3-fs (mmcblk0p1): warning: updating to rev 1 because of new feature flag, running e2fsck is recommended
[   11.151885] kjournald starting.  Commit interval 5 seconds
[   11.160186] EXT3-fs (mmcblk0p1): using internal journal
[   11.165466] EXT3-fs (mmcblk0p1): mounted filesystem with writeback data mode
[   11.172668] VFS: Mounted root (ext3 filesystem) on device 179:1.
[   11.179260] Freeing init memory: 316K
INIT: version 2.88 booting
Error Cannot open /dev/tty0: No such device or address
mknod: /dev/console: File exists

Please wait: booting...
Starting udev
Starting Bootlog daemon: start-stop-daemon: invalid option -- 'r'
BusyBox v1.18.5 (2012-04-17 20:11:46 IST) multi-call binary.

Usage: start-stop-daemon [OPTIONS] [-S|-K] ... [-- ARGS...]

bootlogd.
Configuring network interfaces... ifconfig: SIOCGIFFLAGS: No such device
done.
Starting portmap daemon...
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
Mon Jun 25 11:46:00 UTC 2012
Running postinst /etc/rpm-postinsts/avahi-daemon.sh...
 Adding system startup for /etc/init.d/avahi-daemon.
Running postinst /etc/rpm-postinsts/dbus-1.sh...
 Adding system startup for /etc/init.d/dbus-1.
Running postinst /etc/rpm-postinsts/gdk-pixbuf-loader-gif.sh...
gtk-update-icon-cache: No theme index file.
ERROR: postinst /etc/rpm-postinsts/gdk-pixbuf-loader-gif.sh failed.
Running postinst /etc/rpm-postinsts/gdk-pixbuf-loader-jpeg.sh...
gtk-update-icon-cache: No theme index file.
ERROR: postinst /etc/rpm-postinsts/gdk-pixbuf-loader-jpeg.sh failed.
Running postinst /etc/rpm-postinsts/gdk-pixbuf-loader-png.sh...
gtk-update-icon-cache: No theme index file.
ERROR: postinst /etc/rpm-postinsts/gdk-pixbuf-loader-png.sh failed.
Running postinst /etc/rpm-postinsts/gdk-pixbuf-loader-xpm.sh...
gtk-update-icon-cache: No theme index file.
ERROR: postinst /etc/rpm-postinsts/gdk-pixbuf-loader-xpm.sh failed.
Running postinst /etc/rpm-postinsts/liberation-fonts.sh...


Running postinst /etc/rpm-postinsts/matchbox-keyboard-im.sh...
Running postinst /etc/rpm-postinsts/pango-module-basic-fc.sh...
Running postinst /etc/rpm-postinsts/pango-module-basic-x.sh...
Running postinst /etc/rpm-postinsts/sudo.sh...
Running postinst /etc/rpm-postinsts/update-modules.sh...
Running postinst /etc/rpm-postinsts/xserver-nodm-init.sh...
 Adding system startup for /etc/init.d/xserver-nodm.
INIT: Entering runlevel: 5
Starting system message bus: dbus.
Starting Xserver
Starting syslogd/klogd: done

 * Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon

Fatal server error:
xf86OpenConsole: Cannot find a free VT

   ...fail!
Stopping Bootlog daemon: start-stop-daemon: option '--exec' requires an argument
BusyBox v1.18.5 (2012-04-17 20:11:46 IST) multi-call binary.

Usage: start-stop-daemon [OPTIONS] [-S|-K] ... [-- ARGS...]

bootlogd.




xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error











ls -al

INIT: Id "1" respawning too fast: disabled for 5 minutes
INIT: no more processes left in this runlevel
S^E*aQ??±­ÁÁÅ¥éÕÍ¥¹¥¹Ñ?±©½Õɹ±5ÿ[   11.165466] EXT3-fs (mmcblk0p1): mounted filesystem with writeback data mode
[   11.172668] VFS: Mounted root (ext3 filesystem) on device 179:1.
[   11.179260] Freeing init memory: 316K
INIT: version 2.88 booting
Error Cannot open /dev/tty0: No such device or address
mknod: /dev/console: File exists

Please wait: booting...
Starting udev
Starting Bootlog daemon: start-stop-daemon: invalid option -- 'r'
BusyBox v1.18.5 (2012-04-17 20:11:46 IST) multi-call binary.

Usage: start-stop-daemon [OPTIONS] [-S|-K] ... [-- ARGS...]

bootlogd.
Configuring network interfaces... ifconfig: SIOCGIFFLAGS: No such device
done.
Starting portmap daemon...
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
Mon Jun 25 11:46:00 UTC 2012
Running postinst /etc/rpm-postinsts/avahi-daemon.sh...
 Adding system startup for /etc/init.d/avahi-daemon.
Running postinst /etc/rpm-postinsts/dbus-1.sh...
 Adding system startup for /etc/init.d/dbus-1.
Running postinst /etc/rpm-postinsts/gdk-pixbuf-loader-gif.sh...
gtk-update-icon-cache: No theme index file.
ERROR: postinst /etc/rpm-postinsts/gdk-pixbuf-loader-gif.sh failed.
Running postinst /etc/rpm-postinsts/gdk-pixbuf-loader-jpeg.sh...
gtk-update-icon-cache: No theme index file.
ERROR: postinst /etc/rpm-postinsts/gdk-pixbuf-loader-jpeg.sh failed.
Running postinst /etc/rpm-postinsts/gdk-pixbuf-loader-png.sh...
gtk-update-icon-cache: No theme index file.
ERROR: postinst /etc/rpm-postinsts/gdk-pixbuf-loader-png.sh failed.
Running postinst /etc/rpm-postinsts/gdk-pixbuf-loader-xpm.sh...
gtk-update-icon-cache: No theme index file.
ERROR: postinst /etc/rpm-postinsts/gdk-pixbuf-loader-xpm.sh failed.
Running postinst /etc/rpm-postinsts/liberation-fonts.sh...


Running postinst /etc/rpm-postinsts/matchbox-keyboard-im.sh...
Running postinst /etc/rpm-postinsts/pango-module-basic-fc.sh...
Running postinst /etc/rpm-postinsts/pango-module-basic-x.sh...
Running postinst /etc/rpm-postinsts/sudo.sh...
Running postinst /etc/rpm-postinsts/update-modules.sh...
Running postinst /etc/rpm-postinsts/xserver-nodm-init.sh...
 Adding system startup for /etc/init.d/xserver-nodm.
INIT: Entering runlevel: 5
Starting system message bus: dbus.
Starting Xserver
Starting syslogd/klogd: done

 * Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon

Fatal server error:
xf86OpenConsole: Cannot find a free VT

   ...fail!
Stopping Bootlog daemon: start-stop-daemon: option '--exec' requires an argument
BusyBox v1.18.5 (2012-04-17 20:11:46 IST) multi-call binary.

Usage: start-stop-daemon [OPTIONS] [-S|-K] ... [-- ARGS...]

bootlogd.




xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error











ls -al

INIT: Id "1" respawning too fast: disabled for 5 minutes
INIT: no more processes left in this runlevel









ls -al






INIT: Id "1" respawning too fast: disabled for 5 minutes
INIT: Id "1" respawning too fast: disabled for 5 minutes
INIT: Id "1" respawning too fast: disabled for 5 minutes
INIT: Id "1" respawning too fast: disabled for 5 minutes
INIT: Id "1" respawning too fast: disabled for 5 minutes
INIT: Id "1" respawning too fast: disabled for 5 minutes
INIT: Id "1" respawning too fast: disabled for 5 minutes
INIT: Id "1" respawning too fast: disabled for 5 minutes

Re: Porting of specific Kernel/Driver into yocto.

[Om Prakash PAL]

[-- Attachment #1: Type: text/plain, Size: 3274 bytes --]

Hi Bruce,
You can check the attached log.

It does not contain /dev/tty0..its /dev/ttyAMA2.
I am not able to get why is it opening /dev/tty0?.

Best Regards,
Om Prakash Pal

-----Original Message-----
From: Bruce Ashfield [mailto:bruce.ashfield@windriver.com] 
Sent: Monday, June 25, 2012 7:39 PM
To: Om Prakash PAL
Cc: Khem Raj; yocto@yoctoproject.org
Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.

On 12-06-25 10:06 AM, Om Prakash PAL wrote:
> Hi Bruce,
> Yes,its arm board.
> Yes, I have verified and kernel bootline is properly passed to the kernel by bootloader.

And does it (the bootline) contain /dev/tty0 ? .. because if things are
properly configured, it really shouldn't be trying to open it.

Cheers,

Bruce

>
> Best Regards,
> Om Prakash Pal
>
> -----Original Message-----
> From: Bruce Ashfield [mailto:bruce.ashfield@windriver.com]
> Sent: Monday, June 25, 2012 6:38 PM
> To: Om Prakash PAL
> Cc: Khem Raj; yocto@yoctoproject.org
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>
> On 12-06-25 08:53 AM, Om Prakash PAL wrote:
>> Hi Khem,
>> I have build core-image-core. but still this Error:
>> ======================================================>
>>      11.165466] EXT3-fs (mmcblk0p1): mounted filesystem with writeback data mode
>> [   11.172668] VFS: Mounted root (ext3 filesystem) on device 179:1.
>> [   11.179260] Freeing init memory: 316K
>> INIT: version 2.88 booting
>> Error Cannot open /dev/tty0: No such device or address
>> mknod: /dev/console: File exists
>>
>> =========================================================>
>>
>> I have set SERIAL_CONSOLE="115200 ttyAMA2"  then why its taking /dev/tty0 ?.
>
> I've lost some of the context on the board you are working with, but
> from ttyAMA2, I'm assuming it is an arm board. Have you verified that your
> bootloader can pass the kernel bootline properly to the kernel ? It is
> (unfortunately) fairly common that it isn't properly passed. If you
> modify your configuration to have a built in command line with your
> configuration, you may be able to get better setup to debug the
> problem.
>
> Cheers,
>
> Bruce
>
>> please help.
>>
>> Best Regards,
>> Om Prakash Pal
>> _______________________________________
>> From: Khem Raj [raj.khem@gmail.com]
>> Sent: Friday, June 22, 2012 11:18 AM
>> To: Om Prakash PAL
>> Cc: Gary Thomas; yocto@yoctoproject.org
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> On Thu, Jun 21, 2012 at 10:37 PM, Om Prakash PAL
>> <omprakash.pal@stericsson.com>   wrote:
>>>
>>>>> and then console got  stuck.
>>>>
>>>>> What do you have SERIAL_CONSOLE set to in your configuration?
>>>>
>>>> I have set SERIAL_CONSOLE="115200 ttyAMA2". As we are using ttyAMA2 for console.
>>>
>>>> What is your target device?  Do you really have /dev/ttyAMA2 serial port??.
>>>
>>> Yes, I have /dev/ttyAMA2 serial port.
>>
>> Can you try using say poky/master and generate root file system and
>> try that out ?
>> another option is to try core-image-core
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>


[-- Attachment #2: log.txt --]
[-- Type: text/plain, Size: 41748 bytes --]

Starting kernel ...  arch 2368

Uncompressing Linux... done, booting the kernel.
[    0.000000] Linux version 3.0.8-yoctized-standard+ (apallan@apallan-OptiPlex-GX280) (gcc version 4.6.1 20110627 (prerelease) (GCC) ) #1 SMP PREEMPT Fri Jun 22 17:17:16 IST 2012
[    0.000000] CPU: ARMv7 Processor [412fc091] revision 1 (ARMv7), cr=10c5387f
[    0.000000] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine: ST-Ericsson MOP500 platform
[    0.000000] Memory policy: ECC disabled, Data cache writealloc
[    0.000000] DB8500 v2.0 [0x008500b0]
[    0.000000] PERCPU: Embedded 7 pages/cpu @c12e4000 s7680 r8192 d12800 u32768
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 78848
[    0.000000] Kernel command line: root=/dev/mmcblk0p1 rw blkdevparts=mmcblk0:655360@101376,256@0,2048@1024 rootwait rootfstype=ext3 console=ttyAMA2,115200n8 mem=96M@0 mem_mtrace=15M@96M mem_mshared=1M@111M mem_modem=16M@112M mem=88M@128M hwmem=167M@216M mem_issw=1M@383M mem=128M@384M
[    0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Memory: 96MB 88MB 128MB = 312MB total
[    0.000000] Memory: 301272k/301272k available, 18216k reserved, 0K highmem
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     DMA     : 0xfee00000 - 0xffe00000   (  16 MB)
[    0.000000]     vmalloc : 0xe0800000 - 0xf7800000   ( 368 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .init : 0xc0008000 - 0xc0057000   ( 316 kB)
[    0.000000]       .text : 0xc0057000 - 0xc08ac8a0   (8535 kB)
[    0.000000]       .data : 0xc08ae000 - 0xc0933b88   ( 535 kB)
[    0.000000]        .bss : 0xc0933bac - 0xc0ede5c8   (5803 kB)
[    0.000000] Preemptible hierarchical RCU implementation.
[    0.000000] NR_IRQS:670
[    0.000000] PRCMU firmware: U8500, version 3.5.6
[    0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms
[    0.149993] Calibrating delay using timer specific routine.. 4.80 BogoMIPS (lpj=24043)
[    0.150024] pid_max: default: 32768 minimum: 301
[    0.150390] Mount-cache hash table entries: 512
[    0.151519] Initializing cgroup subsys cpuacct
[    0.151672] CPU: Testing write buffer coherency: ok
[    0.151733] ftrace: allocating 20829 entries in 62 pages
[    0.174896] CPU0: thread -1, cpu 0, socket 3, mpidr 80000300
[    0.175048] hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available
[    0.175170] L310 cache controller enabled
[    0.175170] l2x0: 8 ways, CACHE_ID 0x410000c5, AUX_CTRL 0x7ec60800, Cache size: 524288 B
[    0.295715] CPU1: Booted secondary processor
[    0.295745] CPU1: thread -1, cpu 1, socket 3, mpidr 80000301
[    0.315246] Brought up 2 CPUs
[    0.315277] SMP: Total of 2 processors activated (9.61 BogoMIPS).
[    0.327331] print_constraints: dummy:
[    0.327789] NET: Registered protocol family 16
[    0.331695] gpio gpio.0: Bits 0-31 at address f812e000
[    0.332214] gpio gpio.1: Bits 32-63 at address f812e080
[    0.332885] gpio gpio.2: Bits 64-95 at address f800e000
[    0.333312] gpio gpio.3: Bits 96-127 at address f800e080
[    0.333984] gpio gpio.4: Bits 128-159 at address f800e100
[    0.334503] gpio gpio.5: Bits 160-191 at address f800e180
[    0.335174] gpio gpio.6: Bits 192-223 at address f811e000
[    0.335723] gpio gpio.7: Bits 224-255 at address f811e080
[    0.336273] gpio gpio.8: Bits 256-287 at address fa3fe000
[    0.343383] hw-breakpoint: found 6 breakpoint and 1 watchpoint registers.
[    0.343383] hw-breakpoint: 1 breakpoint(s) reserved for watchpoint single-step.
[    0.343414] hw-breakpoint: maximum watchpoint size is 4 bytes.
[    0.343566] dbx500_dump: driver initialized
[    0.345764] stm stm: STM-Trace driver probed successfully
[    0.346618] print_constraints: db8500-vape:
[    0.346923] print_constraints: db8500-varm:
[    0.347198] print_constraints: db8500-vmodem:
[    0.347412] print_constraints: db8500-vpll:
[    0.347656] print_constraints: db8500-vsmps1:
[    0.347900] print_constraints: db8500-vsmps2:
[    0.348175] print_constraints: db8500-vsmps3:
[    0.348419] print_constraints: db8500-vrf1:
[    0.348663] print_constraints: db8500-sva-mmdsp:
[    0.348937] print_constraints: db8500-sva-mmdsp-ret:
[    0.349151] print_constraints: db8500-sva-pipe:
[    0.349426] print_constraints: db8500-sia-mmdsp:
[    0.349670] print_constraints: db8500-sia-mmdsp-ret:
[    0.349914] print_constraints: db8500-sia-pipe:
[    0.350189] print_constraints: db8500-sga:
[    0.350219] set_supply: db8500-sga: supplied by db8500-vape
[    0.350494] print_constraints: db8500-b2r2-mcde:
[    0.350524] set_supply: db8500-b2r2-mcde: supplied by db8500-vape
[    0.350769] print_constraints: db8500-esram12:
[    0.351043] print_constraints: db8500-esram12-ret:
[    0.351318] print_constraints: db8500-esram34:
[    0.351593] print_constraints: db8500-esram34-ret:
[    0.352325] DB8500 PRCMU initialized
[    0.352691] ab8500-i2c ab8500-i2c.0: detected chip, AB8500 rev. 2.0
[    0.352722] ab8500-i2c ab8500-i2c.0: switch off reason(s) (0x40): "Power on key 1 pressed longer than 10 seconds"
[    0.389678] bio: create slab <bio-0> at 0
[    0.390655] dma40 dma40.0: managed by runtime pm: regulator
[    0.390747] dma40 dma40.0: hardware revision: 3 @ 0x801c0000
[    0.390838] dma40 dma40.0: 6 of 8 physical DMA channels available
[    0.390838] dma40 dma40.0: [d40_phy_res_init] INFO: channel 4 is misconfigured (0)
[    0.390869] dma40 dma40.0: [d40_phy_res_init] INFO: channel 5 is misconfigured (0)
[    0.390869] dma40 dma40.0: [d40_phy_res_init] INFO: channel 6 is misconfigured (0)
[    0.402740] dma40 dma40.0: initialized
[    0.407623] print_constraints: ab8500-ext-supply1: 1800 mV
[    0.408081] print_constraints: ab8500-ext-supply2: 1360 mV
[    0.408416] print_constraints: ab8500-ext-supply3: 3400 mV
[    0.408782] print_constraints: V-DISPLAY: 2800 <--> 3300 mV at 2800 mV
[    0.408813] set_supply: V-DISPLAY: supplied by ab8500-ext-supply3
[    0.409179] print_constraints: V-eMMC1: 1100 <--> 3300 mV at 2900 mV normal idle
[    0.409210] set_supply: V-eMMC1: supplied by ab8500-ext-supply3
[    0.409545] print_constraints: V-MMC-SD: 1200 <--> 2910 mV at 2910 mV normal idle
[    0.409576] set_supply: V-MMC-SD: supplied by ab8500-ext-supply3
[    0.409881] print_constraints: V-INTCORE: 1250 <--> 1350 mV at 1250 mV normal idle
[    0.410186] print_constraints: V-TVOUT: 2000 mV
[    0.410491] print_constraints: V-AUD: 2000 mV
[    0.410766] print_constraints: V-AMIC1: 2050 mV
[    0.411041] print_constraints: V-AMIC2: 2050 mV
[    0.411346] print_constraints: V-DMIC: 1800 mV
[    0.411621] print_constraints: V-CSI-DSI: 1200 mV
[    0.411895] print_constraints: V-SYSCLKREQ-2: 0 mV
[    0.412200] print_constraints: V-SYSCLKREQ-4: 0 mV
[    0.412475] Serial: AMBA PL011 UART driver
[    0.412658] uart0: ttyAMA0 at MMIO 0x80120000 (irq = 43) is a PL011 rev3
[    0.435577] uart1: ttyAMA1 at MMIO 0x80121000 (irq = 51) is a PL011 rev3
[    0.465606] uart2: ttyAMA2 at MMIO 0x80007000 (irq = 58) is a PL011 rev3
[    1.125457] console [ttyAMA2] enabled
[    1.157562] hwmem hwmem.0: Probed OK
[    1.163909] SCSI subsystem initialized
[    1.167724] ssp-pl022 ssp0: managed by runtime pm: regulator
[    1.173522] ssp-pl022 ssp0: ARM PL022 driver, device ID: 0x01080022
[    1.179840] pl022: mapped registers from 0x80002000 to e0858000
[    1.185852] ssp-pl022 ssp0: setup for DMA on RX dma0chan0, TX dma0chan1
[    1.193725] usbcore: registered new interface driver usbfs
[    1.199432] usbcore: registered new interface driver hub
[    1.204925] usbcore: registered new device driver usb
[    1.210052] musb-ux500 musb-ux500.0: managed by runtime pm: pins
[    1.217620] ab8500-usb ab8500-usb.0: revision 0x20 driver initialized
[    1.225372] nmk-i2c nmk-i2c.0: managed by runtime pm: pins
[    1.231079] nmk-i2c nmk-i2c.0: initialize Nomadik I2C0 at 80004000 on virtual base e085a000
[    1.240234] tc3589x 0-0042: manufacturer: 0x3, version: 0x1
[    1.248229] tc3589x 0-0042: added gpio block
[    1.252777] nmk-i2c nmk-i2c.1: managed by runtime pm: pins
[    1.258453] nmk-i2c nmk-i2c.1: initialize Nomadik I2C1 at 80122000 on virtual base e085c000
[    1.267059] nmk-i2c nmk-i2c.2: managed by runtime pm: pins
[    1.272705] nmk-i2c nmk-i2c.2: initialize Nomadik I2C2 at 80128000 on virtual base e085e000
[    1.281860] nmk-i2c nmk-i2c.3: managed by runtime pm: pins
[    1.287567] nmk-i2c nmk-i2c.3: initialize Nomadik I2C3 at 80110000 on virtual base e0860000
[    1.297760] Advanced Linux Sound Architecture Driver Version 1.0.24.
[    1.305175] Bluetooth: Core ver 2.16
[    1.308929] NET: Registered protocol family 31
[    1.313385] Bluetooth: HCI device and connection manager initialized
[    1.319763] Bluetooth: HCI socket layer initialized
[    1.324615] Bluetooth: L2CAP socket layer initialized
[    1.329711] Bluetooth: SCO socket layer initialized
[    1.335174] cfg80211: Calling CRDA to update world regulatory domain
[    1.352874] Switching to clocksource dbx500-prcmu-timer
[    1.366973] Switched to NOHz mode on CPU #0
[    1.367523] Switched to NOHz mode on CPU #1
[    1.379638] MCDE subsystem init begin
[    1.383514] mcde mcde: MCDE iomap: 0xA0350000->0xE0862000
[    1.389068] mcde mcde: Probe HW
[    1.392303] mcde mcde: MCDE HW revision 0x03000800
[    1.397186] mcde mcde: db8500 V2 HW
[    1.401184] mcde mcde: MCDE_CLK is 159744000 Hz
[    1.407379] MCDE subsystem init done
[    1.411102] dsilink dsilink.0: iomap: 0xA0351000->0xE0864000
[    1.416870] dsilink dsilink.0: hw revision 0x02327457
[    1.422149] dsilink dsilink.1: iomap: 0xA0352000->0xE0866000
[    1.427978] dsilink dsilink.1: hw revision 0x02327457
[    1.433288] dsilink dsilink.2: iomap: 0xA0353000->0xE0868000
[    1.439147] dsilink dsilink.2: hw revision 0x02327457
[    1.447143] musb-hdrc: version 6.0, ux500-dma, otg (peripheral+host)
[    1.454467] musb-hdrc musb-hdrc: USB OTG mode controller at e0880000 using DMA, IRQ 55
[    1.463195] NET: Registered protocol family 2
[    1.467864] IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
[    1.475952] TCP established hash table entries: 16384 (order: 5, 131072 bytes)
[    1.483581] TCP bind hash table entries: 16384 (order: 5, 196608 bytes)
[    1.490539] TCP: Hash tables configured (established 16384 bind 16384)
[    1.497070] TCP reno registered
[    1.500244] UDP hash table entries: 256 (order: 1, 8192 bytes)
[    1.506103] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
[    1.512939] NET: Registered protocol family 1
[    1.517639] PMU: registered new PMU device of type 0
[    1.525115] Use-case governor initialized
[    1.728485] nmk-i2c nmk-i2c.0: Write to slave 0x44 timed out
[    1.734222] nmk-i2c nmk-i2c.0: no ack received after address transmission
[    1.938690] nmk-i2c nmk-i2c.0: Write to slave 0x44 timed out
[    1.944366] nmk-i2c nmk-i2c.0: no ack received after address transmission
[    2.148651] nmk-i2c nmk-i2c.0: Write to slave 0x44 timed out
[    2.154327] nmk-i2c nmk-i2c.0: no ack received after address transmission
[    2.358703] nmk-i2c nmk-i2c.3: Write to slave 0x5c timed out
[    2.364349] nmk-i2c nmk-i2c.3: no ack received after address transmission
[    2.371459] ab8500-btemp ab8500-btemp.0: Battery identified as unknown, resistance 6694 Ohm
[    2.379821] ab8500-btemp ab8500-btemp.0: failed to identify the battery
[    2.569000] nmk-i2c nmk-i2c.3: Write to slave 0x5c timed out
[    2.574676] nmk-i2c nmk-i2c.3: no ack received after address transmission
[    2.779083] nmk-i2c nmk-i2c.3: Write to slave 0x5c timed out
[    2.784729] nmk-i2c nmk-i2c.3: no ack received after address transmission
[    2.791625] mop500-uib: ST-UIB (detected)
[    2.796234] stmpe-i2c 0-0040: stmpe1601 detected, chip id: 0x212
[    2.999114] nmk-i2c nmk-i2c.2: Write to slave 0x18 timed out
[    3.004791] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    3.209167] nmk-i2c nmk-i2c.2: Write to slave 0x18 timed out
[    3.214813] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    3.419158] nmk-i2c nmk-i2c.2: Write to slave 0x18 timed out
[    3.424804] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    3.629180] nmk-i2c nmk-i2c.2: Write to slave 0x19 timed out
[    3.634857] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    3.839202] nmk-i2c nmk-i2c.2: Write to slave 0x19 timed out
[    3.844848] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    4.049224] nmk-i2c nmk-i2c.2: Write to slave 0x19 timed out
[    4.054870] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    4.061706]  Failed to get Accelerometr chip ID
[    4.068084] ux500-product: u8500 detected
[    4.072113] ux500-product: JTAG is enabled
[    4.083679] ashmem: initialized
[    4.087219] VFS: Disk quotas dquot_6.5.2
[    4.091430] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    4.098846] Installing v9fs 9p2000 file system support
[    4.104095] msgmni has been set to 588
[    4.108886] io scheduler noop registered
[    4.112823] io scheduler deadline registered (default)
[    4.118041] io scheduler cfq registered
[    4.122772] samsung_s6d16d0 samsung_s6d16d0.0: Samsung s6d16d0 display probed
[    4.262725] samsung_s6d16d0 samsung_s6d16d0.0: Framebuffer created (samsung_s6d16d0)
[    4.270843] samsung_s6d16d0 samsung_s6d16d0.0: compdev created for (samsung_s6d16d0)
[    4.279327] samsung_s6d16d0 samsung_s6d16d0.1: Samsung s6d16d0 display probed
[    4.408905] ------------[ cut here ]------------
[    4.413543] WARNING: at /home/apallan/yocto/hello_build/tmp/work/u8500-poky-linux-gnueabi/linux-u8500-3.2+git1+0a81a5eaa7a5c1216cbd087bec5ec7cd8a448383-r17/linux/drivers/video/mcde/mcde_display.c:219 mcde_display_set_rotation_default+0xac/0xb4()
[    4.435272] Modules linked in:
[    4.438385] [<c00657bc>] (unwind_backtrace+0x0/0x144) from [<c060eb74>] (dump_stack+0x20/0x24)
[    4.447021] [<c060eb74>] (dump_stack+0x20/0x24) from [<c00925f0>] (warn_slowpath_common+0x5c/0x74)
[    4.455993] [<c00925f0>] (warn_slowpath_common+0x5c/0x74) from [<c0092634>] (warn_slowpath_null+0x2c/0x34)
[    4.465698] [<c0092634>] (warn_slowpath_null+0x2c/0x34) from [<c028dd98>] (mcde_display_set_rotation_default+0xac/0xb4)
[    4.476501] [<c028dd98>] (mcde_display_set_rotation_default+0xac/0xb4) from [<c028d9c8>] (mcde_dss_enable_display+0x78/0x10c)
[    4.487823] [<c028d9c8>] (mcde_dss_enable_display+0x78/0x10c) from [<c028f508>] (mcde_fb_create+0x104/0x36c)
[    4.497680] [<c028f508>] (mcde_fb_create+0x104/0x36c) from [<c00786e8>] (display_postregistered_callback+0x8c/0x124)
[    4.508239] [<c00786e8>] (display_postregistered_callback+0x8c/0x124) from [<c00ba5c0>] (notifier_call_chain.isra.0+0x54/0x94)
[    4.519653] [<c00ba5c0>] (notifier_call_chain.isra.0+0x54/0x94) from [<c00ba7e8>] (__blocking_notifier_call_chain+0x58/0x70)
[    4.530883] [<c00ba7e8>] (__blocking_notifier_call_chain+0x58/0x70) from [<c00ba828>] (blocking_notifier_call_chain+0x28/0x30)
[    4.542297] [<c00ba828>] (blocking_notifier_call_chain+0x28/0x30) from [<c028e780>] (bus_notify_callback+0x58/0x60)
[    4.552764] [<c028e780>] (bus_notify_callback+0x58/0x60) from [<c00ba5c0>] (notifier_call_chain.isra.0+0x54/0x94)
[    4.563018] [<c00ba5c0>] (notifier_call_chain.isra.0+0x54/0x94) from [<c00ba7e8>] (__blocking_notifier_call_chain+0x58/0x70)
[    4.574279] [<c00ba7e8>] (__blocking_notifier_call_chain+0x58/0x70) from [<c00ba828>] (blocking_notifier_call_chain+0x28/0x30)
[    4.585662] [<c00ba828>] (blocking_notifier_call_chain+0x28/0x30) from [<c0300144>] (driver_bound+0x78/0xd0)
[    4.595520] [<c0300144>] (driver_bound+0x78/0xd0) from [<c0300500>] (driver_probe_device+0xd0/0x298)
[    4.604675] [<c0300500>] (driver_probe_device+0xd0/0x298) from [<c0300764>] (__driver_attach+0x9c/0xa0)
[    4.614074] [<c0300764>] (__driver_attach+0x9c/0xa0) from [<c02ff3ac>] (bus_for_each_dev+0x6c/0x98)
[    4.623138] [<c02ff3ac>] (bus_for_each_dev+0x6c/0x98) from [<c03000c8>] (driver_attach+0x2c/0x30)
[    4.632049] [<c03000c8>] (driver_attach+0x2c/0x30) from [<c02ffcec>] (bus_add_driver+0x198/0x278)
[    4.640930] [<c02ffcec>] (bus_add_driver+0x198/0x278) from [<c0300cdc>] (driver_register+0x88/0x14c)
[    4.650085] [<c0300cdc>] (driver_register+0x88/0x14c) from [<c028e70c>] (mcde_display_driver_register+0x68/0x84)
[    4.660278] [<c028e70c>] (mcde_display_driver_register+0x68/0x84) from [<c001fd80>] (samsung_s6d16d0_init+0x14/0x1c)
[    4.670837] [<c001fd80>] (samsung_s6d16d0_init+0x14/0x1c) from [<c0057700>] (do_one_initcall+0x4c/0x190)
[    4.680328] [<c0057700>] (do_one_initcall+0x4c/0x190) from [<c0008a3c>] (kernel_init+0x98/0x144)
[    4.689147] [<c0008a3c>] (kernel_init+0x98/0x144) from [<c005f248>] (kernel_thread_exit+0x0/0x8)
[    4.697937] ---[ end trace 65f8ea860415c04f ]---
[    4.702575] samsung_s6d16d0 samsung_s6d16d0.1: Failed to set rotation
[    4.711151] samsung_s6d16d0 samsung_s6d16d0.1: Framebuffer created (samsung_s6d16d0)
[    4.719146] mcde_display_sony_acx424akp_init
[    4.725555] av8100 0-0070: chip version:2
[    4.729980] b2r2_blt_init
[    4.732727] b2r2_blt b2r2_blt_init: b2r2_blt_probe start.
[    4.738342] b2r2_blt b2r2_blt_init: b2r2_blt_probe done.
[    4.743896] b2r2_init
[    4.746246] b2r2 b2r2_core: init started.
[    4.752960] b2r2 b2r2_core: b2r2_mem_init: Creating heap for size 16384 bytes
[    4.760498] b2r2 b2r2_core: b2r2_probe done.
[    4.765747] uart-pl011 uart0: no DMA platform data
[    4.770538] uart-pl011 uart1: no DMA platform data
[    4.775329] uart-pl011 uart2: no DMA platform data
[    4.781402] Mali<2>:
[    4.783660] Mali<2>: Inserting Mali v10 device driver.
[    4.788940] Mali<2>: Compiled: Jun 22 2012, time: 16:47:22.
[    4.794494] Mali<2>: Svn revision: r2p4-02rel0
[    4.798980] Mali<2>: MMU memory system initializing
[    4.803863] Mali<2>: Rendercore: subsystem global mutex initialized
[    4.810150] Mali<2>: Core: subsystem_init: Mali-400 PP
[    4.815277] Mali<2>: Core: subsystem_init: Mali-400 GP
[    4.820434] Mali<2>: Mali L2 cache system initializing
[    4.825897] Mali<2>: MMU registered
[    4.829437] Mali<2>: MMU registered
[    4.832916] Mali<2>: Mali OS memory allocator created with max allocation size of 0x7FF00000 bytes, cpu_usage_adjust 0x00000000
[    4.844421] Mali<2>: Memory Validator 'Framebuffer' installed for Mali physical address base==0x00000000, size==0x7FF00000, cpu_adjust==0x00000000
[    4.857574] Mali<2>: Creating Mali L2 cache: Mali-400 L2 cache
[    4.863433] Mali<1>: Mali memory allocators will be used in this order of preference (lowest numbered first) :
[    4.873474] Mali<1>:         5: Linux kernel memory
[    4.878479] Mali<2>: Attach mmu: 0xdf351a80 to core: Mali-400 PP in subsystem: Mali-400 PP
[    4.886901] Mali<2>: Attach mmu: 0xdf351ae0 to core: Mali-400 GP in subsystem: Mali-400 GP
[    4.895172] Mali<2>: Mali L2 cache system load complete
[    4.900482] Mali: Mali device driver r2p4-02rel0 loaded
[    4.905700] Mali<2>: malidrv:  CONFIG=ux500 USING_OS_MEMORY=1 API_VERSION=10 REPO_URL=r2p4-02rel0 REVISION=r2p4-02rel0 CHANGED_REVISION=r2p4-02rel0 CHANGE_DATE=r2p4-02rel0 BUILD_DATE=Fri Mar 23 06:31:20 IST 2012 BUILD=DEBUG CPU=ux500 USING_UMP=1 USING_HWMEM=1 USING_PMM=1 USING_MALI200=0 USING_MALI400=3 USING_MALI400_L2_CACHE=1 USING_GP2=0 KDIR= MALI_PLATFORM_FILE=platform/ux500/mali_platform.c OS_MEMORY_KERNEL_BUFFER_SIZE_IN_MB=6 USING_PROFILING=0 USING_GPU_UTILIZATION=1 USING_MALI_RUN_TIME_PM=0
[    4.959930] brd: module loaded
[    4.968292] loop: module loaded
[    4.971893] bh1780 2-0029: Ambient Light Sensor, Rev : 1
[    4.979095] dbx500_mloader_fw dbx500_mloader_fw: mloader device register
[    4.985992] compdev_init
[    4.988555] clonedev_init
[    4.993164] PPP generic driver version 2.4.2
[    4.998474] PPP MPPE Compression module registered
[    5.003295] NET: Registered protocol family 24
[    5.007751] tun: Universal TUN/TAP device driver, 1.6
[    5.013397] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[    5.020965] usbcore: registered new interface driver cdc_acm
[    5.026611] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[    5.034698] Initializing USB Mass Storage driver...
[    5.039764] usbcore: registered new interface driver usb-storage
[    5.045776] USB Mass Storage support registered.
[    5.050811] usbcore: registered new interface driver libusual
[    5.061035] android_usb gadget: Mass Storage Function, version: 2009/09/11
[    5.067901] android_usb gadget: Number of LUNs=2
[    5.072570]  lun0: LUN: removable file: (no medium)
[    5.077453]  lun1: LUN: removable file: (no medium)
[    5.082946] android_usb gadget: android_usb ready
[    5.087677] musb-hdrc musb-hdrc: MUSB HDRC host driver
[    5.093139] musb-hdrc musb-hdrc: new USB bus registered, assigned bus number 1
[    5.101379] hub 1-0:1.0: USB hub found
[    5.105133] hub 1-0:1.0: 1 port detected
[    5.109619] gpio-keys gpio-keys.0: managed by runtime pm: pins
[    5.118530] input: gpio-keys as /devices/platform/gpio-keys.0/input/input0
[    5.126831] input: ux500-ske-keypad as /devices/platform/nmk-ske-keypad/input/input1
[    5.138641] input: STMPE-keypad as /devices/platform/nmk-i2c.0/i2c-0/0-0040/stmpe-keypad.1/input/input2
[    5.190856] input: bu21013_ts as /devices/platform/nmk-i2c.3/i2c-3/3-005c/input/input3
[    5.398986] nmk-i2c nmk-i2c.3: Write to slave 0x5d timed out
[    5.404663] nmk-i2c nmk-i2c.3: no ack received after address transmission
[    5.609222] nmk-i2c nmk-i2c.3: Write to slave 0x5d timed out
[    5.614898] nmk-i2c nmk-i2c.3: no ack received after address transmission
[    5.819305] nmk-i2c nmk-i2c.3: Write to slave 0x5d timed out
[    5.824951] nmk-i2c nmk-i2c.3: no ack received after address transmission
[    5.831848] bu21013_ts 3-005d: BU21013_RESET reg write failed
[    5.837585] bu21013_ts 3-005d: error in bu21013 config
[    5.842773] bu21013_ts: probe of 3-005d failed with error -110
[    5.849029] cyttsp_spi_init: Cypress TrueTouch(R) Standard Product SPI Touchscreen Driver (Built Jun 22 2012 @ 16:49:08) returned 0
[    5.861389] input: AB8500 Hs Button as /devices/platform/ab8500-i2c.0/ab8500-acc-det.0/input/input4
[    5.871490] input: AB8500 POn(PowerOn) Key as /devices/platform/ab8500-i2c.0/ab8500-poweron-key.0/input/input5
[    5.882293] lps001wp_prs: probe start.
[    6.079223] nmk-i2c nmk-i2c.2: Read from Slave 0x5c timed out
[    6.084991] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    6.289184] nmk-i2c nmk-i2c.2: Read from Slave 0x5c timed out
[    6.294921] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    6.499206] nmk-i2c nmk-i2c.2: Read from Slave 0x5c timed out
[    6.504943] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    6.511810] lps001wp_prs 2-005c: i2c_smbus_read_byte error!!
[    6.517486] lps001wp_prs 2-005c: lps001wp_prs: Driver Init failed
[    6.523620] lps001wp_prs: probe of 2-005c failed with error -22
[    6.533966] using rtc device, ab8500-rtc, for alarms
[    6.538818] ab8500-rtc ab8500-rtc.0: rtc core: registered ab8500-rtc as rtc0
[    6.546447] i2c /dev entries driver
[    6.552001] lirc_dev: IR Remote Control driver registered, major 248
[    6.558441] IR NEC protocol handler initialized
[    6.562988] IR RC5(x) protocol handler initialized
[    6.567810] IR RC6 protocol handler initialized
[    6.572326] IR JVC protocol handler initialized
[    6.576873] IR Sony protocol handler initialized
[    6.581512] IR RC5 (streamzap) protocol handler initialized
[    6.587066] IR LIRC bridge handler initialized
[    6.591552] Linux video capture interface: v2.00
[    6.599945] ux500_wdt ux500_wdt: initialized
[    6.604553] device-mapper: uevent: version 1.0.3
[    6.609497] device-mapper: ioctl: 4.20.0-ioctl (2011-02-02) initialised: dm-devel@redhat.com
[    6.618011] Bluetooth: HCI UART driver ver 2.2
[    6.622528] dbx500-cpufreq : Available frequencies:
[    6.627410]   200 Mhz
[    6.629730]   400 Mhz
[    6.631988]   800 Mhz
[    6.634246]   1000 Mhz
[    6.636932] cpuidle: using governor ladder
[    6.641052] cpuidle: using governor menu
[    6.645202] mmci-pl18x sdi2: managed by runtime pm: pins
[    6.650909] mmci-pl18x sdi2: mmc0: PL180 manf 80 rev4 at 0x80005000 irq 73,-1 (pio)
[    6.658599] mmci-pl18x sdi2: DMA channels RX dma0chan18, TX dma0chan19
[    6.666503] mmci-pl18x sdi4: managed by runtime pm: pins
[    6.672180] mmci-pl18x sdi4: mmc1: PL180 manf 80 rev4 at 0x80114000 irq 131,-1 (pio)
[    6.679962] mmci-pl18x sdi4: DMA channels RX dma0chan20, TX dma0chan21
[    6.687805] mmci-pl18x sdi0: managed by runtime pm: pins
[    6.694305] mmci-pl18x sdi0: mmc2: PL180 manf 80 rev4 at 0x80126000 irq 92,-1 (pio)
[    6.702026] mmci-pl18x sdi0: DMA channels RX dma0chan22, TX dma0chan23
[    6.710632] mmci-pl18x sdi1: managed by runtime pm: pins
[    6.718200] mmci-pl18x sdi1: mmc3: PL180 manf 80 rev4 at 0x80118000 irq 82,-1 (pio)
[    6.725891] mmci-pl18x sdi1: DMA channels RX dma0chan24, TX dma0chan25
[    6.772125] lp5521 2-0033: lp5521 programmable led chip found
[    6.784210] mmc0: new high speed MMC card at address 0001
[    6.791900] mmcblk0: mmc0:0001 MMC01G 977 MiB
[    6.797088] mmcblk0boot0: mmc0:0001 MMC01G partition 1 512 KiB
[    6.803955] mmcblk0boot1: mmc0:0001 MMC01G partition 2 512 KiB
[    6.811523]
[    6.811553] Partition: size=655360, offset=101376
[    6.817779]
[    6.817779] Partition: size=256, offset=0
[    6.823455]
[    6.823455] Partition: size=2048, offset=1024
[    6.829650]  mmcblk0: p1 p2 p3
[    6.830474] lp5521 2-0034: lp5521 programmable led chip found
[    6.834533] hash1 hash1: managed by runtime pm: regulator
[    6.844329] hash1 hash1: [ux500_hash_probe] successfully probed
[    6.851043]  mmcblk0boot1: unknown partition table
[    6.856597] usbcore: registered new interface driver usbhid
[    6.862304] usbhid: USB HID core driver
[    6.866271]  mmcblk0boot0: unknown partition table
[    6.867523] platform cg2900.0: CG2900 initialized
[    6.867919] cg2900 cg2900.0: CG2900 Core driver started
[    6.868682] cg2900-test cg2900-test.0: CG2900 test char device driver started
[    6.868988] cg2900-chip cg2900-chip.0: CG2900 chip driver started
[    6.869262] stlc2690-chip stlc2690-chip.0: STLC2690 chip driver started
[    6.901123] Bluetooth: HCI UART driver ver 2.3
[    6.906433] logger: created 256K log 'log_main'
[    6.911376] logger: created 256K log 'log_events'
[    6.916229] logger: created 256K log 'log_radio'
[    6.921142] logger: created 256K log 'log_system'
[    6.926391] ste_timed_output_vibra ste_timed_output_vibra.0: Rotary Type Vibrators
[    7.044219] mmc1: power class selection to bus width 8 failed
[    7.050811] mmc1: new high speed MMC card at address 0001
[    7.058044] mmcblk1: mmc1:0001 MMC08G 7.45 GiB
[    7.063385] mmcblk1boot0: mmc1:0001 MMC08G partition 1 2.00 MiB
[    7.070068] mmcblk1boot1: mmc1:0001 MMC08G partition 2 2.00 MiB
[    7.077301]  mmcblk1: p1 p2
[    7.080261] mmcblk1: p2 size 8016435 extends beyond EOD, truncated
[    7.088317]  mmcblk1boot1: unknown partition table
[    7.094543]  mmcblk1boot0: unknown partition table
[    7.128906] nmk-i2c nmk-i2c.2: Write to slave 0x18 timed out
[    7.134643] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    7.154296] mmc3: card claims to support voltages below the defined range. These will be ignored.
[    7.166564] mmc3: error -110 whilst initialising MMC card
[    7.329040] nmk-i2c nmk-i2c.2: Write to slave 0x18 timed out
[    7.334747] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    7.539367] nmk-i2c nmk-i2c.2: Write to slave 0x18 timed out
[    7.545074] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    7.552246] lsm303dlh_a 2-0018: failed to read of the chip
[    7.557800] lsm303dlh_a: probe of 2-0018 failed with error -110
[    7.759613] nmk-i2c nmk-i2c.2: Write to slave 0x68 timed out
[    7.765350] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    7.969268] nmk-i2c nmk-i2c.2: Write to slave 0x68 timed out
[    7.975097] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    8.179199] nmk-i2c nmk-i2c.2: Write to slave 0x68 timed out
[    8.184906] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    8.192077] l3g4200d 2-0068: failed to read of the chip
[    8.197387] l3g4200d: probe of 2-0068 failed with error -110
[    8.399353] nmk-i2c nmk-i2c.2: Write to slave 0x1e timed out
[    8.405059] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    8.609252] nmk-i2c nmk-i2c.2: Write to slave 0x1e timed out
[    8.615112] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    8.819427] nmk-i2c nmk-i2c.2: Write to slave 0x1e timed out
[    8.825134] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    9.029327] nmk-i2c nmk-i2c.2: Write to slave 0x1e timed out
[    9.035034] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    9.239288] nmk-i2c nmk-i2c.2: Write to slave 0x1e timed out
[    9.244995] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    9.449249] nmk-i2c nmk-i2c.2: Write to slave 0x1e timed out
[    9.455078] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    9.659088] nmk-i2c nmk-i2c.2: Write to slave 0x1e timed out
[    9.664794] nmk-i2c nmk-i2c.2: no ack received after address transmission
[    9.869415] nmk-i2c nmk-i2c.2: Write to slave 0x1e timed out
[    9.875244] nmk-i2c nmk-i2c.2: no ack received after address transmission
[   10.079864] nmk-i2c nmk-i2c.2: Write to slave 0x1e timed out
[   10.085693] nmk-i2c nmk-i2c.2: no ack received after address transmission
[   10.289001] nmk-i2c nmk-i2c.2: Write to slave 0x1e timed out
[   10.294708] nmk-i2c nmk-i2c.2: no ack received after address transmission
[   10.499023] nmk-i2c nmk-i2c.2: Write to slave 0x1e timed out
[   10.504760] nmk-i2c nmk-i2c.2: no ack received after address transmission
[   10.709259] nmk-i2c nmk-i2c.2: Write to slave 0x1e timed out
[   10.714965] nmk-i2c nmk-i2c.2: no ack received after address transmission
[   10.724090] mmio_init
[   10.726684] mmio_probe
[   10.730438] mmio_camera mmio_camera: MMIO driver initialized with minor=44
[   10.738800] i2c i2c-2: Failed to register i2c client adp1653 at 0x30 (-16)
[   10.745941] camera_flash driver initialized with minor=43
[   10.763092] Initialize NMF 2.10.123 Component Manager......
[   10.768676] [ CM Linux Driver 2.10.122 ]
[   10.775115] u8500_shrm shrm_bus: IPC_ISA BOOT_INIT
[   10.781433] u8500_shrm shrm_bus: BOOT_INFO_SYNC
[   10.786132] u8500_shrm shrm_bus: IPC_ISA BOOT_DONE
[   10.791381] u8500_shrm shrm_bus: Registered shrm netdev
[   10.797546] usbcore: registered new interface driver snd-usb-audio
[   10.804779] ab5500_init called.
[   10.808135] ab8500_codec_platform_driver_init: Enter.
[   10.813323] ab8500_codec_driver_probe: Register codec.
[   10.819549] ux500_msp_init: Register ux500-msp-dai platform driver.
[   10.825866] ux500_msp_drv_probe: Enter (pdev->name = ux500-msp-i2s).
[   10.832336] ux500_msp_drv_probe: Registering ux500-msp-dai SoC CPU-DAI.
[   10.838989] ux500_msp_drv_probe: Enter (pdev->name = ux500-msp-i2s).
[   10.845367] ux500_msp_drv_probe: Registering ux500-msp-dai SoC CPU-DAI.
[   10.852020] ux500_msp_drv_probe: Enter (pdev->name = ux500-msp-i2s).
[   10.858398] ux500_msp_drv_probe: Registering ux500-msp-dai SoC CPU-DAI.
[   10.865051] ux500_msp_drv_probe: Enter (pdev->name = ux500-msp-i2s).
[   10.871459] ux500_msp_drv_probe: Registering ux500-msp-dai SoC CPU-DAI.
[   10.878601] av8100_codec_drv_probe: Init codec private data..
[   10.884368] av8100_codec_drv_probe: Register codec.
[   10.889556] cg29xx_codec_driver_probe: Init codec private data..
[   10.895568] cg29xx_codec_driver_probe: Register codec.
[   10.901000] ux500_pcm_drv_probe: Register ux500-pcm SoC platform driver.
[   10.908233] asoc: av8100-codec-dai <-> ux500-msp-i2s.2 mapping ok
[   10.921600] asoc: ab8500-codec-dai.0 <-> ux500-msp-i2s.1 mapping ok
[   10.928466] asoc: ab8500-codec-dai.1 <-> ux500-msp-i2s.3 mapping ok
[   10.935546] asoc: cg29xx-codec-dai.1 <-> ux500-msp-i2s.0 mapping ok
[   10.943176] input: U8500-card AB8500 Hs Status as /devices/platform/soc-audio/sound/card0/input6
[   10.952636] ALSA device list:
[   10.955596]   #0: U8500-card
[   10.958648] Netfilter messages via NETLINK v0.30.
[   10.963470] nf_conntrack version 0.5.0 (4707 buckets, 18828 max)
[   10.969848] ctnetlink v0.93: registering with nfnetlink.
[   10.975189] NF_TPROXY: Transparent proxy support initialized, version 4.1.0
[   10.982147] NF_TPROXY: Copyright (c) 2006-2007 BalaBit IT Ltd.
[   10.989807] ip_tables: (C) 2000-2006 Netfilter Core Team
[   10.995361] TCP cubic registered
[   10.998718] NET: Registered protocol family 10
[   11.006195] ip6_tables: (C) 2000-2006 Netfilter Core Team
[   11.011718] NET: Registered protocol family 17
[   11.016204] NET: Registered protocol family 15
[   11.020782] Bluetooth: RFCOMM TTY layer initialized
[   11.025665] Bluetooth: RFCOMM socket layer initialized
[   11.030883] Bluetooth: RFCOMM ver 1.11
[   11.034637] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   11.039978] Bluetooth: BNEP filters: protocol multicast
[   11.045196] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[   11.051422] NET: Registered protocol family 35
[   11.056030] Installing 9P2000 support
[   11.059814] NET: Registered protocol family 37
[   11.064361] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 2
[   11.072082] Registering SWP/SWPB emulation handler
[   11.078277] l2x0-prefetch: initialized.
[   11.083099] mcde_display_hdmi_init
[   11.086639] av8100_hdmi av8100_hdmi.3: HDMI display probed
[   11.093261] regulator_init_complete: db8500-esram12: disabling
[   11.100616] ab8500-rtc ab8500-rtc.0: setting system clock to 2012-05-11 11:46:18 UTC (1336736778)
[   11.111785] cpuidle: initiated for CPU0.
[   11.117370] cpuidle: initiated for CPU1.
[   11.124389] EXT3-fs (mmcblk0p1): warning: feature flags set on rev 0 fs, running e2fsck is recommended
[   11.136016] EXT3-fs: barriers not enabled
[   11.141143] EXT3-fs (mmcblk0p1): warning: updating to rev 1 because of new feature flag, running e2fsck is recommended
[   11.151885] kjournald starting.  Commit interval 5 seconds
[   11.160186] EXT3-fs (mmcblk0p1): using internal journal
[   11.165466] EXT3-fs (mmcblk0p1): mounted filesystem with writeback data mode
[   11.172668] VFS: Mounted root (ext3 filesystem) on device 179:1.
[   11.179260] Freeing init memory: 316K
INIT: version 2.88 booting
Error Cannot open /dev/tty0: No such device or address
mknod: /dev/console: File exists

Please wait: booting...
Starting udev
Starting Bootlog daemon: start-stop-daemon: invalid option -- 'r'
BusyBox v1.18.5 (2012-04-17 20:11:46 IST) multi-call binary.

Usage: start-stop-daemon [OPTIONS] [-S|-K] ... [-- ARGS...]

bootlogd.
Configuring network interfaces... ifconfig: SIOCGIFFLAGS: No such device
done.
Starting portmap daemon...
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
Mon Jun 25 11:46:00 UTC 2012
Running postinst /etc/rpm-postinsts/avahi-daemon.sh...
 Adding system startup for /etc/init.d/avahi-daemon.
Running postinst /etc/rpm-postinsts/dbus-1.sh...
 Adding system startup for /etc/init.d/dbus-1.
Running postinst /etc/rpm-postinsts/gdk-pixbuf-loader-gif.sh...
gtk-update-icon-cache: No theme index file.
ERROR: postinst /etc/rpm-postinsts/gdk-pixbuf-loader-gif.sh failed.
Running postinst /etc/rpm-postinsts/gdk-pixbuf-loader-jpeg.sh...
gtk-update-icon-cache: No theme index file.
ERROR: postinst /etc/rpm-postinsts/gdk-pixbuf-loader-jpeg.sh failed.
Running postinst /etc/rpm-postinsts/gdk-pixbuf-loader-png.sh...
gtk-update-icon-cache: No theme index file.
ERROR: postinst /etc/rpm-postinsts/gdk-pixbuf-loader-png.sh failed.
Running postinst /etc/rpm-postinsts/gdk-pixbuf-loader-xpm.sh...
gtk-update-icon-cache: No theme index file.
ERROR: postinst /etc/rpm-postinsts/gdk-pixbuf-loader-xpm.sh failed.
Running postinst /etc/rpm-postinsts/liberation-fonts.sh...


Running postinst /etc/rpm-postinsts/matchbox-keyboard-im.sh...
Running postinst /etc/rpm-postinsts/pango-module-basic-fc.sh...
Running postinst /etc/rpm-postinsts/pango-module-basic-x.sh...
Running postinst /etc/rpm-postinsts/sudo.sh...
Running postinst /etc/rpm-postinsts/update-modules.sh...
Running postinst /etc/rpm-postinsts/xserver-nodm-init.sh...
 Adding system startup for /etc/init.d/xserver-nodm.
INIT: Entering runlevel: 5
Starting system message bus: dbus.
Starting Xserver
Starting syslogd/klogd: done

 * Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon

Fatal server error:
xf86OpenConsole: Cannot find a free VT

   ...fail!
Stopping Bootlog daemon: start-stop-daemon: option '--exec' requires an argument
BusyBox v1.18.5 (2012-04-17 20:11:46 IST) multi-call binary.

Usage: start-stop-daemon [OPTIONS] [-S|-K] ... [-- ARGS...]

bootlogd.




xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error











ls -al

INIT: Id "1" respawning too fast: disabled for 5 minutes
INIT: no more processes left in this runlevel
S^E*aQ??±­ÁÁÅ¥éÕÍ¥¹¥¹Ñ?±©½Õɹ±5ÿ[   11.165466] EXT3-fs (mmcblk0p1): mounted filesystem with writeback data mode
[   11.172668] VFS: Mounted root (ext3 filesystem) on device 179:1.
[   11.179260] Freeing init memory: 316K
INIT: version 2.88 booting
Error Cannot open /dev/tty0: No such device or address
mknod: /dev/console: File exists

Please wait: booting...
Starting udev
Starting Bootlog daemon: start-stop-daemon: invalid option -- 'r'
BusyBox v1.18.5 (2012-04-17 20:11:46 IST) multi-call binary.

Usage: start-stop-daemon [OPTIONS] [-S|-K] ... [-- ARGS...]

bootlogd.
Configuring network interfaces... ifconfig: SIOCGIFFLAGS: No such device
done.
Starting portmap daemon...
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
Mon Jun 25 11:46:00 UTC 2012
Running postinst /etc/rpm-postinsts/avahi-daemon.sh...
 Adding system startup for /etc/init.d/avahi-daemon.
Running postinst /etc/rpm-postinsts/dbus-1.sh...
 Adding system startup for /etc/init.d/dbus-1.
Running postinst /etc/rpm-postinsts/gdk-pixbuf-loader-gif.sh...
gtk-update-icon-cache: No theme index file.
ERROR: postinst /etc/rpm-postinsts/gdk-pixbuf-loader-gif.sh failed.
Running postinst /etc/rpm-postinsts/gdk-pixbuf-loader-jpeg.sh...
gtk-update-icon-cache: No theme index file.
ERROR: postinst /etc/rpm-postinsts/gdk-pixbuf-loader-jpeg.sh failed.
Running postinst /etc/rpm-postinsts/gdk-pixbuf-loader-png.sh...
gtk-update-icon-cache: No theme index file.
ERROR: postinst /etc/rpm-postinsts/gdk-pixbuf-loader-png.sh failed.
Running postinst /etc/rpm-postinsts/gdk-pixbuf-loader-xpm.sh...
gtk-update-icon-cache: No theme index file.
ERROR: postinst /etc/rpm-postinsts/gdk-pixbuf-loader-xpm.sh failed.
Running postinst /etc/rpm-postinsts/liberation-fonts.sh...


Running postinst /etc/rpm-postinsts/matchbox-keyboard-im.sh...
Running postinst /etc/rpm-postinsts/pango-module-basic-fc.sh...
Running postinst /etc/rpm-postinsts/pango-module-basic-x.sh...
Running postinst /etc/rpm-postinsts/sudo.sh...
Running postinst /etc/rpm-postinsts/update-modules.sh...
Running postinst /etc/rpm-postinsts/xserver-nodm-init.sh...
 Adding system startup for /etc/init.d/xserver-nodm.
INIT: Entering runlevel: 5
Starting system message bus: dbus.
Starting Xserver
Starting syslogd/klogd: done

 * Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon

Fatal server error:
xf86OpenConsole: Cannot find a free VT

   ...fail!
Stopping Bootlog daemon: start-stop-daemon: option '--exec' requires an argument
BusyBox v1.18.5 (2012-04-17 20:11:46 IST) multi-call binary.

Usage: start-stop-daemon [OPTIONS] [-S|-K] ... [-- ARGS...]

bootlogd.




xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error











ls -al

INIT: Id "1" respawning too fast: disabled for 5 minutes
INIT: no more processes left in this runlevel









ls -al






INIT: Id "1" respawning too fast: disabled for 5 minutes
INIT: Id "1" respawning too fast: disabled for 5 minutes
INIT: Id "1" respawning too fast: disabled for 5 minutes
INIT: Id "1" respawning too fast: disabled for 5 minutes
INIT: Id "1" respawning too fast: disabled for 5 minutes
INIT: Id "1" respawning too fast: disabled for 5 minutes
INIT: Id "1" respawning too fast: disabled for 5 minutes
INIT: Id "1" respawning too fast: disabled for 5 minutes

Re: Porting of specific Kernel/Driver into yocto.

[Khem Raj]

On Mon, Jun 25, 2012 at 7:12 AM, Om Prakash PAL
<omprakash.pal@stericsson.com> wrote:
> Hi Bruce,
> You can check the attached log.
>
> It does not contain /dev/tty0..its /dev/ttyAMA2.
> I am not able to get why is it opening /dev/tty0?.

whats there in /etc/securetty on target rfs ?
>
> Best Regards,
> Om Prakash Pal
>
> -----Original Message-----
> From: Bruce Ashfield [mailto:bruce.ashfield@windriver.com]
> Sent: Monday, June 25, 2012 7:39 PM
> To: Om Prakash PAL
> Cc: Khem Raj; yocto@yoctoproject.org
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>
> On 12-06-25 10:06 AM, Om Prakash PAL wrote:
>> Hi Bruce,
>> Yes,its arm board.
>> Yes, I have verified and kernel bootline is properly passed to the kernel by bootloader.
>
> And does it (the bootline) contain /dev/tty0 ? .. because if things are
> properly configured, it really shouldn't be trying to open it.
>
> Cheers,
>
> Bruce
>
>>
>> Best Regards,
>> Om Prakash Pal
>>
>> -----Original Message-----
>> From: Bruce Ashfield [mailto:bruce.ashfield@windriver.com]
>> Sent: Monday, June 25, 2012 6:38 PM
>> To: Om Prakash PAL
>> Cc: Khem Raj; yocto@yoctoproject.org
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> On 12-06-25 08:53 AM, Om Prakash PAL wrote:
>>> Hi Khem,
>>> I have build core-image-core. but still this Error:
>>> ======================================================>
>>>      11.165466] EXT3-fs (mmcblk0p1): mounted filesystem with writeback data mode
>>> [   11.172668] VFS: Mounted root (ext3 filesystem) on device 179:1.
>>> [   11.179260] Freeing init memory: 316K
>>> INIT: version 2.88 booting
>>> Error Cannot open /dev/tty0: No such device or address
>>> mknod: /dev/console: File exists
>>>
>>> =========================================================>
>>>
>>> I have set SERIAL_CONSOLE="115200 ttyAMA2"  then why its taking /dev/tty0 ?.
>>
>> I've lost some of the context on the board you are working with, but
>> from ttyAMA2, I'm assuming it is an arm board. Have you verified that your
>> bootloader can pass the kernel bootline properly to the kernel ? It is
>> (unfortunately) fairly common that it isn't properly passed. If you
>> modify your configuration to have a built in command line with your
>> configuration, you may be able to get better setup to debug the
>> problem.
>>
>> Cheers,
>>
>> Bruce
>>
>>> please help.
>>>
>>> Best Regards,
>>> Om Prakash Pal
>>> _______________________________________
>>> From: Khem Raj [raj.khem@gmail.com]
>>> Sent: Friday, June 22, 2012 11:18 AM
>>> To: Om Prakash PAL
>>> Cc: Gary Thomas; yocto@yoctoproject.org
>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>
>>> On Thu, Jun 21, 2012 at 10:37 PM, Om Prakash PAL
>>> <omprakash.pal@stericsson.com>   wrote:
>>>>
>>>>>> and then console got  stuck.
>>>>>
>>>>>> What do you have SERIAL_CONSOLE set to in your configuration?
>>>>>
>>>>> I have set SERIAL_CONSOLE="115200 ttyAMA2". As we are using ttyAMA2 for console.
>>>>
>>>>> What is your target device?  Do you really have /dev/ttyAMA2 serial port??.
>>>>
>>>> Yes, I have /dev/ttyAMA2 serial port.
>>>
>>> Can you try using say poky/master and generate root file system and
>>> try that out ?
>>> another option is to try core-image-core
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>

Re: Porting of specific Kernel/Driver into yocto.

[Om Prakash PAL]

Hi khem,
on target, etc/ does not contain securetty.

Best Regards,
Om Prakash Pal
________________________________________
From: Khem Raj [raj.khem@gmail.com]
Sent: Monday, June 25, 2012 8:43 PM
To: Om Prakash PAL
Cc: Bruce Ashfield; yocto@yoctoproject.org
Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.

On Mon, Jun 25, 2012 at 7:12 AM, Om Prakash PAL
<omprakash.pal@stericsson.com> wrote:
> Hi Bruce,
> You can check the attached log.
>
> It does not contain /dev/tty0..its /dev/ttyAMA2.
> I am not able to get why is it opening /dev/tty0?.

whats there in /etc/securetty on target rfs ?
>
> Best Regards,
> Om Prakash Pal
>
> -----Original Message-----
> From: Bruce Ashfield [mailto:bruce.ashfield@windriver.com]
> Sent: Monday, June 25, 2012 7:39 PM
> To: Om Prakash PAL
> Cc: Khem Raj; yocto@yoctoproject.org
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>
> On 12-06-25 10:06 AM, Om Prakash PAL wrote:
>> Hi Bruce,
>> Yes,its arm board.
>> Yes, I have verified and kernel bootline is properly passed to the kernel by bootloader.
>
> And does it (the bootline) contain /dev/tty0 ? .. because if things are
> properly configured, it really shouldn't be trying to open it.
>
> Cheers,
>
> Bruce
>
>>
>> Best Regards,
>> Om Prakash Pal
>>
>> -----Original Message-----
>> From: Bruce Ashfield [mailto:bruce.ashfield@windriver.com]
>> Sent: Monday, June 25, 2012 6:38 PM
>> To: Om Prakash PAL
>> Cc: Khem Raj; yocto@yoctoproject.org
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> On 12-06-25 08:53 AM, Om Prakash PAL wrote:
>>> Hi Khem,
>>> I have build core-image-core. but still this Error:
>>> ======================================================>
>>>      11.165466] EXT3-fs (mmcblk0p1): mounted filesystem with writeback data mode
>>> [   11.172668] VFS: Mounted root (ext3 filesystem) on device 179:1.
>>> [   11.179260] Freeing init memory: 316K
>>> INIT: version 2.88 booting
>>> Error Cannot open /dev/tty0: No such device or address
>>> mknod: /dev/console: File exists
>>>
>>> =========================================================>
>>>
>>> I have set SERIAL_CONSOLE="115200 ttyAMA2"  then why its taking /dev/tty0 ?.
>>
>> I've lost some of the context on the board you are working with, but
>> from ttyAMA2, I'm assuming it is an arm board. Have you verified that your
>> bootloader can pass the kernel bootline properly to the kernel ? It is
>> (unfortunately) fairly common that it isn't properly passed. If you
>> modify your configuration to have a built in command line with your
>> configuration, you may be able to get better setup to debug the
>> problem.
>>
>> Cheers,
>>
>> Bruce
>>
>>> please help.
>>>
>>> Best Regards,
>>> Om Prakash Pal
>>> _______________________________________
>>> From: Khem Raj [raj.khem@gmail.com]
>>> Sent: Friday, June 22, 2012 11:18 AM
>>> To: Om Prakash PAL
>>> Cc: Gary Thomas; yocto@yoctoproject.org
>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>
>>> On Thu, Jun 21, 2012 at 10:37 PM, Om Prakash PAL
>>> <omprakash.pal@stericsson.com>   wrote:
>>>>
>>>>>> and then console got  stuck.
>>>>>
>>>>>> What do you have SERIAL_CONSOLE set to in your configuration?
>>>>>
>>>>> I have set SERIAL_CONSOLE="115200 ttyAMA2". As we are using ttyAMA2 for console.
>>>>
>>>>> What is your target device?  Do you really have /dev/ttyAMA2 serial port??.
>>>>
>>>> Yes, I have /dev/ttyAMA2 serial port.
>>>
>>> Can you try using say poky/master and generate root file system and
>>> try that out ?
>>> another option is to try core-image-core
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>

Re: Porting of specific Kernel/Driver into yocto.

[Chris Tapp]

On 26 Jun 2012, at 06:33, Om Prakash PAL wrote:

> Hi khem,
> on target, etc/ does not contain securetty.

What about /etc/inittab? Does this contain any references to tty0?

> Best Regards,
> Om Prakash Pal
> ________________________________________
> From: Khem Raj [raj.khem@gmail.com]
> Sent: Monday, June 25, 2012 8:43 PM
> To: Om Prakash PAL
> Cc: Bruce Ashfield; yocto@yoctoproject.org
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
> 
> On Mon, Jun 25, 2012 at 7:12 AM, Om Prakash PAL
> <omprakash.pal@stericsson.com> wrote:
>> Hi Bruce,
>> You can check the attached log.
>> 
>> It does not contain /dev/tty0..its /dev/ttyAMA2.
>> I am not able to get why is it opening /dev/tty0?.
> 
> whats there in /etc/securetty on target rfs ?
>> 
>> Best Regards,
>> Om Prakash Pal
>> 
>> -----Original Message-----
>> From: Bruce Ashfield [mailto:bruce.ashfield@windriver.com]
>> Sent: Monday, June 25, 2012 7:39 PM
>> To: Om Prakash PAL
>> Cc: Khem Raj; yocto@yoctoproject.org
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>> 
>> On 12-06-25 10:06 AM, Om Prakash PAL wrote:
>>> Hi Bruce,
>>> Yes,its arm board.
>>> Yes, I have verified and kernel bootline is properly passed to the kernel by bootloader.
>> 
>> And does it (the bootline) contain /dev/tty0 ? .. because if things are
>> properly configured, it really shouldn't be trying to open it.
>> 
>> Cheers,
>> 
>> Bruce
>> 
>>> 
>>> Best Regards,
>>> Om Prakash Pal
>>> 
>>> -----Original Message-----
>>> From: Bruce Ashfield [mailto:bruce.ashfield@windriver.com]
>>> Sent: Monday, June 25, 2012 6:38 PM
>>> To: Om Prakash PAL
>>> Cc: Khem Raj; yocto@yoctoproject.org
>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>> 
>>> On 12-06-25 08:53 AM, Om Prakash PAL wrote:
>>>> Hi Khem,
>>>> I have build core-image-core. but still this Error:
>>>> ======================================================>
>>>>     11.165466] EXT3-fs (mmcblk0p1): mounted filesystem with writeback data mode
>>>> [   11.172668] VFS: Mounted root (ext3 filesystem) on device 179:1.
>>>> [   11.179260] Freeing init memory: 316K
>>>> INIT: version 2.88 booting
>>>> Error Cannot open /dev/tty0: No such device or address
>>>> mknod: /dev/console: File exists
>>>> 
>>>> =========================================================>
>>>> 
>>>> I have set SERIAL_CONSOLE="115200 ttyAMA2"  then why its taking /dev/tty0 ?.
>>> 
>>> I've lost some of the context on the board you are working with, but
>>> from ttyAMA2, I'm assuming it is an arm board. Have you verified that your
>>> bootloader can pass the kernel bootline properly to the kernel ? It is
>>> (unfortunately) fairly common that it isn't properly passed. If you
>>> modify your configuration to have a built in command line with your
>>> configuration, you may be able to get better setup to debug the
>>> problem.
>>> 
>>> Cheers,
>>> 
>>> Bruce
>>> 
>>>> please help.
>>>> 
>>>> Best Regards,
>>>> Om Prakash Pal
>>>> _______________________________________
>>>> From: Khem Raj [raj.khem@gmail.com]
>>>> Sent: Friday, June 22, 2012 11:18 AM
>>>> To: Om Prakash PAL
>>>> Cc: Gary Thomas; yocto@yoctoproject.org
>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>> 
>>>> On Thu, Jun 21, 2012 at 10:37 PM, Om Prakash PAL
>>>> <omprakash.pal@stericsson.com>   wrote:
>>>>> 
>>>>>>> and then console got  stuck.
>>>>>> 
>>>>>>> What do you have SERIAL_CONSOLE set to in your configuration?
>>>>>> 
>>>>>> I have set SERIAL_CONSOLE="115200 ttyAMA2". As we are using ttyAMA2 for console.
>>>>> 
>>>>>> What is your target device?  Do you really have /dev/ttyAMA2 serial port??.
>>>>> 
>>>>> Yes, I have /dev/ttyAMA2 serial port.
>>>> 
>>>> Can you try using say poky/master and generate root file system and
>>>> try that out ?
>>>> another option is to try core-image-core
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>> 
>> 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Chris Tapp

opensource@keylevel.com
www.keylevel.com

Re: Porting of specific Kernel/Driver into yocto.

[Om Prakash PAL]

[-- Attachment #1: Type: text/plain, Size: 4783 bytes --]

Hi Chris,
No, /etc/initab does not contain any reference to inittab.
please find the attched /etc/initab file for more information.

Best Regards,
Om Prakash Pal

=================================>
________________________________________
From: Chris Tapp [opensource@keylevel.com]
Sent: Tuesday, June 26, 2012 12:52 PM
To: Om Prakash PAL
Cc: Khem Raj; yocto@yoctoproject.org
Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.

On 26 Jun 2012, at 06:33, Om Prakash PAL wrote:

> Hi khem,
> on target, etc/ does not contain securetty.

What about /etc/inittab? Does this contain any references to tty0?

> Best Regards,
> Om Prakash Pal
> ________________________________________
> From: Khem Raj [raj.khem@gmail.com]
> Sent: Monday, June 25, 2012 8:43 PM
> To: Om Prakash PAL
> Cc: Bruce Ashfield; yocto@yoctoproject.org
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>
> On Mon, Jun 25, 2012 at 7:12 AM, Om Prakash PAL
> <omprakash.pal@stericsson.com> wrote:
>> Hi Bruce,
>> You can check the attached log.
>>
>> It does not contain /dev/tty0..its /dev/ttyAMA2.
>> I am not able to get why is it opening /dev/tty0?.
>
> whats there in /etc/securetty on target rfs ?
>>
>> Best Regards,
>> Om Prakash Pal
>>
>> -----Original Message-----
>> From: Bruce Ashfield [mailto:bruce.ashfield@windriver.com]
>> Sent: Monday, June 25, 2012 7:39 PM
>> To: Om Prakash PAL
>> Cc: Khem Raj; yocto@yoctoproject.org
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> On 12-06-25 10:06 AM, Om Prakash PAL wrote:
>>> Hi Bruce,
>>> Yes,its arm board.
>>> Yes, I have verified and kernel bootline is properly passed to the kernel by bootloader.
>>
>> And does it (the bootline) contain /dev/tty0 ? .. because if things are
>> properly configured, it really shouldn't be trying to open it.
>>
>> Cheers,
>>
>> Bruce
>>
>>>
>>> Best Regards,
>>> Om Prakash Pal
>>>
>>> -----Original Message-----
>>> From: Bruce Ashfield [mailto:bruce.ashfield@windriver.com]
>>> Sent: Monday, June 25, 2012 6:38 PM
>>> To: Om Prakash PAL
>>> Cc: Khem Raj; yocto@yoctoproject.org
>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>
>>> On 12-06-25 08:53 AM, Om Prakash PAL wrote:
>>>> Hi Khem,
>>>> I have build core-image-core. but still this Error:
>>>> ======================================================>
>>>>     11.165466] EXT3-fs (mmcblk0p1): mounted filesystem with writeback data mode
>>>> [   11.172668] VFS: Mounted root (ext3 filesystem) on device 179:1.
>>>> [   11.179260] Freeing init memory: 316K
>>>> INIT: version 2.88 booting
>>>> Error Cannot open /dev/tty0: No such device or address
>>>> mknod: /dev/console: File exists
>>>>
>>>> =========================================================>
>>>>
>>>> I have set SERIAL_CONSOLE="115200 ttyAMA2"  then why its taking /dev/tty0 ?.
>>>
>>> I've lost some of the context on the board you are working with, but
>>> from ttyAMA2, I'm assuming it is an arm board. Have you verified that your
>>> bootloader can pass the kernel bootline properly to the kernel ? It is
>>> (unfortunately) fairly common that it isn't properly passed. If you
>>> modify your configuration to have a built in command line with your
>>> configuration, you may be able to get better setup to debug the
>>> problem.
>>>
>>> Cheers,
>>>
>>> Bruce
>>>
>>>> please help.
>>>>
>>>> Best Regards,
>>>> Om Prakash Pal
>>>> _______________________________________
>>>> From: Khem Raj [raj.khem@gmail.com]
>>>> Sent: Friday, June 22, 2012 11:18 AM
>>>> To: Om Prakash PAL
>>>> Cc: Gary Thomas; yocto@yoctoproject.org
>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>
>>>> On Thu, Jun 21, 2012 at 10:37 PM, Om Prakash PAL
>>>> <omprakash.pal@stericsson.com>   wrote:
>>>>>
>>>>>>> and then console got  stuck.
>>>>>>
>>>>>>> What do you have SERIAL_CONSOLE set to in your configuration?
>>>>>>
>>>>>> I have set SERIAL_CONSOLE="115200 ttyAMA2". As we are using ttyAMA2 for console.
>>>>>
>>>>>> What is your target device?  Do you really have /dev/ttyAMA2 serial port??.
>>>>>
>>>>> Yes, I have /dev/ttyAMA2 serial port.
>>>>
>>>> Can you try using say poky/master and generate root file system and
>>>> try that out ?
>>>> another option is to try core-image-core
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Chris Tapp

opensource@keylevel.com
www.keylevel.com




[-- Attachment #2: inittab --]
[-- Type: application/octet-stream, Size: 1033 bytes --]

# /etc/inittab: init(8) configuration.
# $Id: inittab,v 1.91 2002/01/25 13:35:21 miquels Exp $

# The default runlevel.
id:5:initdefault:

# Boot-time system configuration/initialization script.
# This is run first except when booting in emergency (-b) mode.
si::sysinit:/etc/init.d/rcS

# What to do in single-user mode.
~~:S:wait:/sbin/sulogin

# /etc/init.d executes the S and K scripts upon change
# of runlevel.
#
# Runlevel 0 is halt.
# Runlevel 1 is single-user.
# Runlevels 2-5 are multi-user.
# Runlevel 6 is reboot.

l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6
# Normally not reached, but fallthrough in case of emergency.
z6:6:respawn:/sbin/sulogin
# /sbin/getty invocations for the runlevels.
#
# The "id" field MUST be the same as the last
# characters of the device (after "tty").
#
# Format:
#  <id>:<runlevels>:<action>:<process>
#

1:2345:respawn:/sbin/getty 38400 tty1

Re: Porting of specific Kernel/Driver into yocto.

[Om Prakash PAL]

Hi Chris,
No, /etc/initab does not contain any reference to tty0(wrong typed in last mail).

Best Regards,
Om Prakash Pal
________________________________________
From: Chris Tapp [opensource@keylevel.com]
Sent: Tuesday, June 26, 2012 12:52 PM
To: Om Prakash PAL
Cc: Khem Raj; yocto@yoctoproject.org
Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.

On 26 Jun 2012, at 06:33, Om Prakash PAL wrote:

> Hi khem,
> on target, etc/ does not contain securetty.

What about /etc/inittab? Does this contain any references to tty0?

> Best Regards,
> Om Prakash Pal
> ________________________________________
> From: Khem Raj [raj.khem@gmail.com]
> Sent: Monday, June 25, 2012 8:43 PM
> To: Om Prakash PAL
> Cc: Bruce Ashfield; yocto@yoctoproject.org
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>
> On Mon, Jun 25, 2012 at 7:12 AM, Om Prakash PAL
> <omprakash.pal@stericsson.com> wrote:
>> Hi Bruce,
>> You can check the attached log.
>>
>> It does not contain /dev/tty0..its /dev/ttyAMA2.
>> I am not able to get why is it opening /dev/tty0?.
>
> whats there in /etc/securetty on target rfs ?
>>
>> Best Regards,
>> Om Prakash Pal
>>
>> -----Original Message-----
>> From: Bruce Ashfield [mailto:bruce.ashfield@windriver.com]
>> Sent: Monday, June 25, 2012 7:39 PM
>> To: Om Prakash PAL
>> Cc: Khem Raj; yocto@yoctoproject.org
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> On 12-06-25 10:06 AM, Om Prakash PAL wrote:
>>> Hi Bruce,
>>> Yes,its arm board.
>>> Yes, I have verified and kernel bootline is properly passed to the kernel by bootloader.
>>
>> And does it (the bootline) contain /dev/tty0 ? .. because if things are
>> properly configured, it really shouldn't be trying to open it.
>>
>> Cheers,
>>
>> Bruce
>>
>>>
>>> Best Regards,
>>> Om Prakash Pal
>>>
>>> -----Original Message-----
>>> From: Bruce Ashfield [mailto:bruce.ashfield@windriver.com]
>>> Sent: Monday, June 25, 2012 6:38 PM
>>> To: Om Prakash PAL
>>> Cc: Khem Raj; yocto@yoctoproject.org
>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>
>>> On 12-06-25 08:53 AM, Om Prakash PAL wrote:
>>>> Hi Khem,
>>>> I have build core-image-core. but still this Error:
>>>> ======================================================>
>>>>     11.165466] EXT3-fs (mmcblk0p1): mounted filesystem with writeback data mode
>>>> [   11.172668] VFS: Mounted root (ext3 filesystem) on device 179:1.
>>>> [   11.179260] Freeing init memory: 316K
>>>> INIT: version 2.88 booting
>>>> Error Cannot open /dev/tty0: No such device or address
>>>> mknod: /dev/console: File exists
>>>>
>>>> =========================================================>
>>>>
>>>> I have set SERIAL_CONSOLE="115200 ttyAMA2"  then why its taking /dev/tty0 ?.
>>>
>>> I've lost some of the context on the board you are working with, but
>>> from ttyAMA2, I'm assuming it is an arm board. Have you verified that your
>>> bootloader can pass the kernel bootline properly to the kernel ? It is
>>> (unfortunately) fairly common that it isn't properly passed. If you
>>> modify your configuration to have a built in command line with your
>>> configuration, you may be able to get better setup to debug the
>>> problem.
>>>
>>> Cheers,
>>>
>>> Bruce
>>>
>>>> please help.
>>>>
>>>> Best Regards,
>>>> Om Prakash Pal
>>>> _______________________________________
>>>> From: Khem Raj [raj.khem@gmail.com]
>>>> Sent: Friday, June 22, 2012 11:18 AM
>>>> To: Om Prakash PAL
>>>> Cc: Gary Thomas; yocto@yoctoproject.org
>>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>>
>>>> On Thu, Jun 21, 2012 at 10:37 PM, Om Prakash PAL
>>>> <omprakash.pal@stericsson.com>   wrote:
>>>>>
>>>>>>> and then console got  stuck.
>>>>>>
>>>>>>> What do you have SERIAL_CONSOLE set to in your configuration?
>>>>>>
>>>>>> I have set SERIAL_CONSOLE="115200 ttyAMA2". As we are using ttyAMA2 for console.
>>>>>
>>>>>> What is your target device?  Do you really have /dev/ttyAMA2 serial port??.
>>>>>
>>>>> Yes, I have /dev/ttyAMA2 serial port.
>>>>
>>>> Can you try using say poky/master and generate root file system and
>>>> try that out ?
>>>> another option is to try core-image-core
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Chris Tapp

opensource@keylevel.com
www.keylevel.com