[yocto] Raspberry Pi [was Re: Kernel modules fail to compile for ARM]

[Bruce Ashfield]

On 12-05-16 03:46 AM, Tomas Frydrych wrote:
> Hi Bruce,
>
> On 15/05/12 19:07, Bruce Ashfield wrote:
>> On 12-05-15 01:36 PM, Tomas Frydrych wrote:
>>> Let me turn this question back at you then: is Yocto going to be doing
>>> thorough Q&A for all of these HW platforms? Decent Q&A is what really
>>> sets Yocto apart, and what makes it my first port of call, but I got a
>>> feeling that the scope of this is at the moment somewhat restricted as
>>> far as HW is concerned; without Q&A 'fixes' quickly turn into problems
>>> -- I'd rather be pulling kernel from somewhere that deals with the
>>> specific HW that pick up generic fixes without the Q&A.
>>
>> I spend all day every day working with targets across the spectrum of
>> arch and use case, with plenty of drivers and core infrastructure
>> in common, so those sorts of changes being monitored and being included
>> are definitely in place.
>
> Cool, but a developer working with targets does not really qualify as
> QA. QA implies testing that culminates in a formal release.

ok, I'll agree that one person's QA is another person's boot test :)
I was more meaning, unit, device testing. Performing full QA across
several machines that share an architecture and common code is something
that I've been trying to reduce for some time now.

And what I mean by that, is that machine/BSP testing should at some
level rely on the results from other arch testing (posix, ltp, etc)
being transitive to that machine. That allows the BSP testing to
focus on the drivers and configuration that are unique to the board.

When I was writing this, I was thinking of someone, anyone, running
their normal use cases with the board. Those cases + architecture
generic QA gets you a long way to full QA.

>
>
>> As for hardware specific QA, the yocto project itself runs QA on targets
>> that we've tagged as a hardware reference. The raspberry pi is one that
>> I've been considering as a new reference, so if that was the case, it would
>> get extra coverage.
>
> It is certainly an interesting / high profile enough board to be of
> interest to Yocto as a project I think.
>
>
>> That being said, it obviously doesn't scale that just because we align
>> on a kernel version, set of features, base configuration, etc, that
>> the yocto project itself would run machine/BSP specific QA. That would
>> be a place where interested parties would already be doing QA,
>
> This is where it becomes problematic. Interested parties simply cannot
> be relied on doing QA, that was pretty much why Poky came to be (BTW,
> 'git tag' provides a rudimentary insight into project QA mentality; the
> absence of release tags invariably means no QA worth mentioning and pain
> in store ... an interesting exercise when it comes to meta-*).

Agreed. That's why having a set of references boards, and extended
references boards is key. That way at least some testing and quality
is in place, even if not perfect.

>
> So, if meta-yocto contains machine/<somemachine>.conf I expect
> meta-yocto to be providing quality assured images for<somemachine>. If
> Yocto can't do that, I question the value of including it at all.

I don't disagree. I just think that having even a common base, or
common kernel version removes some of the duplication of effort,
even if it doesn't take us all the way to a full QA .. since scaling
to that for hundreds of boards might be difficult (and the 'might'
is meant to be understated :).

>
>
> But that aside, I'd very much recommend that the RPI kernel for
> meta-rasberrypi to be based on the Yocto kernel tree; as a Yocto user,
> rather than a kernel developer, the whole config fragment machinery
> provides a very clean and controlled way of managing the kernel and is
> really nice to work with. :-)

It's a start!

Cheers,

Bruce

>
> Tomas
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto