On Thu, Nov 30, 2017 at 2:53 AM, Ryan Harkin <ryan.harkin@linaro.org> wrote:
>
>
> On 30 November 2017 at 09:31, Ryan Harkin <ryan.harkin@linaro.org> wrote:
>>
>>
>>
>> On 30 November 2017 at 09:18, Koen Kooi <koen.kooi@linaro.org> wrote:
>>>
>>>
>>>
>>> > Op 30 nov. 2017, om 10:08 heeft Ryan Harkin <ryan.harkin@linaro.org>
>>> > het volgende geschreven:
>>> >
>>> >
>>> >
>>> > On 30 November 2017 at 08:34, Koen Kooi <koen.kooi@linaro.org> wrote:
>>> > Op 30 nov. 2017, om 09:26 heeft Ryan Harkin <ryan.harkin@linaro.org>
>>> > het volgende geschreven:
>>> > >
>>> > > Here's another question:
>>> > >
>>> > > When I build for MACHINE=imx7s-warp, should meta-raspberrypi's
>>> > > linux-firmware recipe be running or not? Is there something in
>>> > > meta-raspberrypi that makes it only run on MACHINE=raspberrypi?
>>> >
>>> > Looking at
>>> > https://github.com/agherzan/meta-raspberrypi/blob/master/recipes-kernel/linux-firmware/linux-firmware_%25.bbappend
>>> > it should be included
>>> >
>>> > > In an OE-RPB based build, it doesn't run. I put a bbwarn statement
>>> > > into the bbappend file's do_install and it didn't output anything.
>>> > >
>>> > > But when I run it in the "other" distro, meta-raspberrypi's
>>> > > linux-firmware_%.bbappend is running during a warp7 build and outputting the
>>> > > bbwarn from meta-raspberrypi.
>>> > >
>>> > > Is this expected?
>>> >
>>> > It depends on the order and content of the other linux-firmware
>>> > bbappend files, if one that sorts higher does:
>>> >
>>> > do_install() {
>>> >   something
>>> > }
>>> >
>>> > all the lower sorted appends will not get their do_install_append in.
>>> >
>>> > Anyway, try doing ‘bitbake -e linux-firmware > firmware-e.txt’ and
>>> > inspecting the result, that should list the overrides and their order for
>>> > every variable and method.
>>> >
>>> > OK, thanks for that top tip.
>>> >
>>> > So rpi and warp7 are both being included in the final do_install
>>> > function in both OE-RPB and my other distro.
>>> >
>>> > Why I didn't see the bbwarn from meta-raspberrypi on OE-RPB is a
>>> > different matter, especially as I'm no longer seeing either bbwarn when I
>>> > build right now.
>>>
>>> Code in methods only gets executed when that method runs and *doesn’t*
>>> run if bitbake uses sstate to restore it. So you might not see it due to
>>> caching working as intended.
>>
>>
>> Yes, I tried unsuccessfully to clean, I guess...
>>
>> Eg:
>> bitbake -c do_cleanall linux-firmware
>>
>>>
>>>
>>>
>>> >
>>> > But because the rpi layer is included in the manifest after/later than
>>> > my layer, the rpi do_install appended commands run after the warp7 ones, so
>>> > there's no way I'll ever get my firmware into the disk image with this
>>> > mechanism.
>>>
>>> Both appends touch the same file(s)?
>>
>>
>> Yes, identical filenames and locations, but different versions.
>>
>> :-(
>
>
> I'm trying to work out what I can to here to stop WaRP7
> linux-firmware_%.bbappend corrupting RPi3 and vice versa.
>
> In my recipe, I can use do_install_append_imx7s-warp() to prevent it from
> including during an RPi build. But RPi will still trample over my WaRP7
> build.
>
> I could move my meta-layer to be higher than RPi's, but I don't think that's
> a good solution.
>
> Would it be a good idea to submit a patch to meta-raspberrypi to change
> their do_install_append() to do_install_append_raspberrypi()?
>

I think yes you can. rpi layer is adding specific firmware and making
it universally
applicable, this is not multi-bsp friendly. So please turn that whole
bbappend to
act under _rpi override.

> (I assume the SRC_URI and other variables would need their machine tags
> added too).
>
> I'll try to create a new clone of oe-rpb-manifest.xml and a fresh meta layer
> with only this recipe so I can isolate this problem and share it publicly.