[yocto] Patch failures

[Bruce Ashfield]

On 2017-04-19 12:24 PM, Bruce Ashfield wrote:
> On 2017-04-17 2:18 AM, Paul D. DeRocco wrote:
>>> From: Bruce Ashfield [mailto:bruce.ashfield at windriver.com]
>>>
>>> I can't say from what you've provided why the BSP description isn't
>>> valid, but if the kernel recipe and layers are something I
>>> can look at,
>>> I can debug more.
>>>
>>> There were some changes between those releases that tweaked the kernel
>>> meta-data processing .. and that could be the issue, but
>>> again, I can't
>>> say without seeing all the details.
>>
>> I've attached a zip containing the stuff I've added. It also includes the
>> log file showing the patch errors. It also shows a log of a few thousand
>> identical errors from grub-efi, having to do with a 32 vs 64 mismatch. In
>> the past, my system has always booted via Syslinux, not Grub, so I don't
>> know what changed between Fido and Morty, or if Syslinux doesn't support
>> 64-bit booting. So there's another unrelated question.
>>
>
> I finally got a chance to look at the layers, and I can see that the
> processing code would in fact pick/generate a generic board description
> and that could lead you into the failures you are seeing.
>
> I assume you are building for MACHINE="chroma-bsp" and the linux-yocto-rt
> kernel recipe ?
>
> If you can confirm the details, and anything else, I can mock up a
> recipe space BSP description that should work.

I take that back. After debugging, I see that you did have a recipe
space BSP definition, and it is in fact being picked up.

What you are seeing is an optimization and simplification in the way
that patches are processed (that I introduced in morty). That
simplication is:

   - if a patch is listed on the SRC_URI or in a .scc on the SRC_URI
     it is always applied.

Sounds simple, since it is. And that replaced the logic that was capable
of looking into a patch queue, comparing it to the branch being built
and would determine if anything needed to be pushed by walking the
commits. That process was slow, and error prone, since similarly named
commits could trigger an early start to patching and hence a patch
failure that wasn't easy to catch.

Since your BSP definition is on the SRC_URI, and is including the
preempt-rt kernel type, the rule I stated above applies and it tries
to (re)push all the patches.

The fix is simple, change the line to this:

   include ktypes/preempt-rt/preempt-rt.scc nopatch

And you'll inherit the preempt-rt branch + configurations, but not
the patches.

Honestly, I can't say if that was documented, so I'll go dig around
and see if it was.

Cheers,

Bruce

>
> Bruce
>
>> The history is this: I originally developed this as a 32-bit OS under
>> Danny, then updated it with no problems to Fido. I wanted to try the x32
>> ABI, since the extra registers could be very useful (lots of SSE SIMD in
>> the application). Perhaps I should have first tried updating to Morty
>> without x32. I had to change some version numbers (the kernel, systemd,
>> Samba), and of course add the x32 tune. For Samba, I added a few layers
>> from OE.
>>
>