[yocto] Correct way to use a custom bsp .scc file in morty

[Bruce Ashfield]

On 2017-01-20 09:19 AM, George McCollister wrote:
> On Thu, Jan 19, 2017 at 5:24 PM, Bruce Ashfield
> <bruce.ashfield at windriver.com> wrote:
>> On 2017-01-19 6:20 PM, George McCollister wrote:
>>>
>>> What's the correct way to use a custom bsp .scc file located in my
>>> custom bsp layer? For purposes of this email let's say it's name is
>>> myplatform-preempt-rt.scc. If I specifically add it to the
>>> yocto-linux-rt_4.4 SRC_URI it appears to get processed twice by scc
>>> according to the meta-series output file. It then tries to apply
>>> patches to standard/preempt-rt/base that don't apply. When building on
>>> a intel-core2-32 platform, intel-core2-32-preempt-rt.scc only gets
>>> processed once and no incorrect patches are applied.
>>
>>
>> Something could have broken, I never rule out bugs!
>>
>> Morty had some different semantics than the newer branches (which
>> are simplified compared to the auto-resume logic in old releases).
>>
>> That being said, the capability to have a BSP description in the
>> SRC_URI is there, and did work during that release cycle. To have
>> it work, you do need the right format in the BSP .scc file, in
>> particular something with the KMACHINE and KTYPE descriptions will
>> be seen as an entry point, and not trigger the re-application of
>> the inherited patches.
>>
>> Is there any way that I can see the contents of that .scc file ?
>> Otherwise, I can spin up a morty build and mock something up
>> myself.
>
> Bruce,
>
> I stripped down my bsp later and pushed it github. You can find the
> BSP .scc (and the files it includes) here:
> https://github.com/gmccollister/meta-orion-minimal-bsp/tree/master/recipes-kernel/linux/linux-yocto/orion-io
>
> The linux-yocto-rt_4.4.bbappend that adds orion-io-preempt-rt.scc to
> the SRC_URI is here:
> https://github.com/gmccollister/meta-orion-minimal-bsp/blob/master/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend
>

Thanks, this helped .. and did show me the behaviour that you were
mentioning.

I had to scratch my head for minute, since I tested this scenario
myself when doing the major re-work in morty for how the kernel
meta data s processed.

In morty I was able to delete about 40% of all the code and simplified
the processing. There used to be logic that would process the patch
series, resume processing, wrap .cfg/.scc files, detect BSP definitions
and do special processing .. etc, etc. It was a rats nest of corner
cases.

In morty, if something is on the SRC_URI .. it is applied to the
tree. No exceptions. Hence why when your BSP definition is on the
SRC_URI .. it tries to reapply all the patches to the tree.

The way that out of tree/recipe space meta data is handled is now
the same as the way the core linux-yocto 'kernel-meta' is handled.
You specify either a git repo or a directory on the SRC_URI and
tag it as having meta-data. Those directories are searched for
a BSP that matches the machine that is being built. Once found,
it is processed like any other BSP .. no special cases.

What looks to have been missed was documenting *how* this should
be done with a directory in a layer, versus a separate git
repository. If you'd like to open a bug against me, I'll make sure
that it is documented in the upcoming release (and hopefully on
morty as well).

The following change to your bbappend triggered the right processing
in my case:

  SRC_URI_append_orion-io = " \
-       file://orion-io-preempt-rt.scc \
+       file://orion-io;type=kmeta;destsuffix=orion-io \
  "

All that says, is that the directory orion-io (where you had the
.scc/.cfg files) is kernel meta data, and that it can be found
in the directory called 'orion-io' after the fetcher pulls it
into WORKDIR.

 From there, it is found, and the configuration, etc, applied to
the build.

Bruce


> -George
>
>>
>> Bruce
>>
>>
>>>
>>> If I don't include it in the yocto-linux-rt_4.4 SRC_URI it's never
>>> applied at all. I'm wondering if this a new problem with the last big
>>> push to morty since I didn't notice this before.
>>>
>>> I also verified that I can make myplatform-preempt-rt.scc work by
>>> doing the following (only shows as processed once in meta-series and
>>> no incorrect patches applied):
>>> bitbake -c cleanall linux-yocto-rt
>>> bitbake -c unpack linux-yocto-rt
>>> Manually copy myplatform-preempt-rt.scc and related .scc, .cfg files
>>> to the following path:
>>>
>>> work/myplatform-oe-linux-gnueabi/linux-yocto-rt/4.4.36+gitAUTOINC+b846fc6436_61d7bf47fe-r0/kernel-meta/bsp/myplatform/
>>> bitbake -c compile linux-yocto-rt
>>>
>>> Regards,
>>> George McCollister
>>>
>>