eSDK errors and sstate signature issues

eSDK errors and sstate signature issues

[Manjukumar Harthikote Matha]

All,


I am trying to build Yocto eSDK with OE_core and meta-xilinx layers.

Having issues while extracting the eSDK, it warns quite a bit on 
signature mismatch. Can this happen due to the fact that I am using 
external tool chain??

And eventually bails stating
ERROR: Unexpected tasks or setscene left over to be executed:

meta-xilinx/recipes-kernel/linux/linux-xlnx_4.6.bb, do_fetch
meta-xilinx/recipes-kernel/linux/linux-xlnx_4.6.bb, do_unpack
meta-xilinx/recipes-kernel/linux/linux-xlnx_4.6.bb, do_kernel_configme
....

How do I go about investigating why set scene was corrupted or not 
executed correctly while building kernel?

Any help is appreciated

Thanks
Manju

Re: eSDK errors and sstate signature issues

[Paul Eggleton]

Hi Manju,

Sorry for the delayed reply.

On Mon, 15 Aug 2016 17:43:23 Manjukumar Harthikote Matha wrote:
> I am trying to build Yocto eSDK with OE_core and meta-xilinx layers.
> 
> Having issues while extracting the eSDK, it warns quite a bit on
> signature mismatch. Can this happen due to the fact that I am using
> external tool chain??
> 
> And eventually bails stating
> ERROR: Unexpected tasks or setscene left over to be executed:
> 
> meta-xilinx/recipes-kernel/linux/linux-xlnx_4.6.bb, do_fetch
> meta-xilinx/recipes-kernel/linux/linux-xlnx_4.6.bb, do_unpack
> meta-xilinx/recipes-kernel/linux/linux-xlnx_4.6.bb, do_kernel_configme
> ....
> 
> How do I go about investigating why set scene was corrupted or not
> executed correctly while building kernel?

So it looks like linux-xlnx is attempting to build for some reason and yet we 
don't expect it to be because it's locked. It may or may not be related to the 
use of an external toolchain - I'm not sure because it's not a scenario I have 
tested.

Are the layers / toolchain you are using downloadable, i.e. could I reproduce 
the issue here?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: eSDK errors and sstate signature issues

[Manjukumar Harthikote Matha]

Hi Paul.

On 08/22/2016 09:47 AM, Paul Eggleton wrote:
> Hi Manju,
>
> Sorry for the delayed reply.
>
No worries.
> On Mon, 15 Aug 2016 17:43:23 Manjukumar Harthikote Matha wrote:
>> I am trying to build Yocto eSDK with OE_core and meta-xilinx layers.
>>
>> Having issues while extracting the eSDK, it warns quite a bit on
>> signature mismatch. Can this happen due to the fact that I am using
>> external tool chain??
>>
>> And eventually bails stating
>> ERROR: Unexpected tasks or setscene left over to be executed:
>>
>> meta-xilinx/recipes-kernel/linux/linux-xlnx_4.6.bb, do_fetch
>> meta-xilinx/recipes-kernel/linux/linux-xlnx_4.6.bb, do_unpack
>> meta-xilinx/recipes-kernel/linux/linux-xlnx_4.6.bb, do_kernel_configme
>> ....
>>
>> How do I go about investigating why set scene was corrupted or not
>> executed correctly while building kernel?
>
> So it looks like linux-xlnx is attempting to build for some reason and yet we
> don't expect it to be because it's locked. It may or may not be related to the
> use of an external toolchain - I'm not sure because it's not a scenario I have
> tested.
>
Thanks YP masters for having bitbake-diffsig. This enabled us to 
identify the distro settings that were incorrect, specially on 
UNINATIVE. After we corrected our distro(meta-petalinux) to use this 
concept, the error disappeared.

We also had to remove some INITRAMFS and IMAGEFSTYPES from the machine 
as well. We are working on krogoth branch, but I did notice a patch on 
master to correct this in populate_sdk_ext.

We are able to build and test SDK using external toolchain now and its 
super cool :)

Is there a way to make tasks for a recipe ARCH specific instead of 
MACHINE ARCH? For ex: Kernel is packaged as machine specific, however if 
you do_fetch (and maybe do_patch) could use ARCH specific, then multiple 
machines belonging to the same ARCH can use it from sstate, instead of 
downloading it again.

> Are the layers / toolchain you are using downloadable, i.e. could I reproduce
> the issue here?
>
Layers and toolchain are available but not for the dev branch which we 
are working on. It is going through legal-sweep, hence I am unable to 
share it :(

Thanks
Manju