Kernel modules fail to compile for ARM

Kernel modules fail to compile for ARM

[Chris Tapp]

I'm trying to put a BSP together for an ARM system (Raspberry Pi, ARM1176JZF-S CPU). However, when I try and build the kernel I am getting a build failure when the kernel modules are compiled:

|   CC [M]  net/core/pktgen.o
| /media/SSD-RAID/build-edison-pi/tmp/work/pi-poky-linux-gnueabi/linux-yocto-3.0.18+git1+d386e09f316e03061c088d2b13a48605c20fb3a6_1+2bba211297d10047637b8f49abd2c5415480ce4d-r3/linux/net/core/pktgen.c: In function 'pktgen_if_show':
| /media/SSD-RAID/build-edison-pi/tmp/work/pi-poky-linux-gnueabi/linux-yocto-3.0.18+git1+d386e09f316e03061c088d2b13a48605c20fb3a6_1+2bba211297d10047637b8f49abd2c5415480ce4d-r3/linux/net/core/pktgen.c:682:2: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
| /media/SSD-RAID/build-edison-pi/tmp/work/pi-poky-linux-gnueabi/linux-yocto-3.0.18+git1+d386e09f316e03061c088d2b13a48605c20fb3a6_1+2bba211297d10047637b8f49abd2c5415480ce4d-r3/linux/net/core/pktgen.c:682:2: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
| /media/SSD-RAID/build-edison-pi/tmp/work/pi-poky-linux-gnueabi/linux-yocto-3.0.18+git1+d386e09f316e03061c088d2b13a48605c20fb3a6_1+2bba211297d10047637b8f49abd2c5415480ce4d-r3/linux/net/core/pktgen.c:682:2: error: 'asm' operand has impossible constraints
| /media/SSD-RAID/build-edison-pi/tmp/work/pi-poky-linux-gnueabi/linux-yocto-3.0.18+git1+d386e09f316e03061c088d2b13a48605c20fb3a6_1+2bba211297d10047637b8f49abd2c5415480ce4d-r3/linux/net/core/pktgen.c:682:2: error: 'asm' operand has impossible constraints
| make[4]: *** [net/core/pktgen.o] Error 1

As a test, I __think__ I've modified my machine configuration so that it is the same as the BeagleBoard, but that also get the same even though the use of the BeagleBoard machine itself compiles. The only difference is I am trying to use the 3.0 kernel.

I see that the 3.0.bbappend doesn't list beagleboard as a 'compatible' machine but 2.6.37 does (under 6.0.1). Is what I see a known issue with the 3.0 kernel, or is there something else I can check?

Chris Tapp

opensource@keylevel.com
www.keylevel.com

Re: Kernel modules fail to compile for ARM

[Bruce Ashfield]

On 12-05-14 02:52 PM, Chris Tapp wrote:
> I'm trying to put a BSP together for an ARM system (Raspberry Pi, ARM1176JZF-S CPU). However, when I try and build the kernel I am getting a build failure when the kernel modules are compiled:
>
> |   CC [M]  net/core/pktgen.o
> | /media/SSD-RAID/build-edison-pi/tmp/work/pi-poky-linux-gnueabi/linux-yocto-3.0.18+git1+d386e09f316e03061c088d2b13a48605c20fb3a6_1+2bba211297d10047637b8f49abd2c5415480ce4d-r3/linux/net/core/pktgen.c: In function 'pktgen_if_show':
> | /media/SSD-RAID/build-edison-pi/tmp/work/pi-poky-linux-gnueabi/linux-yocto-3.0.18+git1+d386e09f316e03061c088d2b13a48605c20fb3a6_1+2bba211297d10047637b8f49abd2c5415480ce4d-r3/linux/net/core/pktgen.c:682:2: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
> | /media/SSD-RAID/build-edison-pi/tmp/work/pi-poky-linux-gnueabi/linux-yocto-3.0.18+git1+d386e09f316e03061c088d2b13a48605c20fb3a6_1+2bba211297d10047637b8f49abd2c5415480ce4d-r3/linux/net/core/pktgen.c:682:2: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
> | /media/SSD-RAID/build-edison-pi/tmp/work/pi-poky-linux-gnueabi/linux-yocto-3.0.18+git1+d386e09f316e03061c088d2b13a48605c20fb3a6_1+2bba211297d10047637b8f49abd2c5415480ce4d-r3/linux/net/core/pktgen.c:682:2: error: 'asm' operand has impossible constraints
> | /media/SSD-RAID/build-edison-pi/tmp/work/pi-poky-linux-gnueabi/linux-yocto-3.0.18+git1+d386e09f316e03061c088d2b13a48605c20fb3a6_1+2bba211297d10047637b8f49abd2c5415480ce4d-r3/linux/net/core/pktgen.c:682:2: error: 'asm' operand has impossible constraints
> | make[4]: *** [net/core/pktgen.o] Error 1
>
> As a test, I __think__ I've modified my machine configuration so that it is the same as the BeagleBoard, but that also get the same even though the use of the BeagleBoard machine itself compiles. The only difference is I am trying to use the 3.0 kernel.
>
> I see that the 3.0.bbappend doesn't list beagleboard as a 'compatible' machine but 2.6.37 does (under 6.0.1). Is what I see a known issue with the 3.0 kernel, or is there something else I can check?

It was a matter of time and energy and the lack of an urgent need to
update things.

The board does work on the newer kernels (obviously), so trying the
same thing against the 3.2+ kernel would be a good starting point.

Bruce

>
> Chris Tapp
>
> opensource@keylevel.com
> www.keylevel.com
>
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: Kernel modules fail to compile for ARM

[Chris Tapp]

On 14 May 2012, at 20:05, Bruce Ashfield wrote:

> On 12-05-14 02:52 PM, Chris Tapp wrote:
>> I'm trying to put a BSP together for an ARM system (Raspberry Pi, ARM1176JZF-S CPU). However, when I try and build the kernel I am getting a build failure when the kernel modules are compiled:
>> 
>> |   CC [M]  net/core/pktgen.o
>> | /media/SSD-RAID/build-edison-pi/tmp/work/pi-poky-linux-gnueabi/linux-yocto-3.0.18+git1+d386e09f316e03061c088d2b13a48605c20fb3a6_1+2bba211297d10047637b8f49abd2c5415480ce4d-r3/linux/net/core/pktgen.c: In function 'pktgen_if_show':
>> | /media/SSD-RAID/build-edison-pi/tmp/work/pi-poky-linux-gnueabi/linux-yocto-3.0.18+git1+d386e09f316e03061c088d2b13a48605c20fb3a6_1+2bba211297d10047637b8f49abd2c5415480ce4d-r3/linux/net/core/pktgen.c:682:2: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
>> | /media/SSD-RAID/build-edison-pi/tmp/work/pi-poky-linux-gnueabi/linux-yocto-3.0.18+git1+d386e09f316e03061c088d2b13a48605c20fb3a6_1+2bba211297d10047637b8f49abd2c5415480ce4d-r3/linux/net/core/pktgen.c:682:2: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
>> | /media/SSD-RAID/build-edison-pi/tmp/work/pi-poky-linux-gnueabi/linux-yocto-3.0.18+git1+d386e09f316e03061c088d2b13a48605c20fb3a6_1+2bba211297d10047637b8f49abd2c5415480ce4d-r3/linux/net/core/pktgen.c:682:2: error: 'asm' operand has impossible constraints
>> | /media/SSD-RAID/build-edison-pi/tmp/work/pi-poky-linux-gnueabi/linux-yocto-3.0.18+git1+d386e09f316e03061c088d2b13a48605c20fb3a6_1+2bba211297d10047637b8f49abd2c5415480ce4d-r3/linux/net/core/pktgen.c:682:2: error: 'asm' operand has impossible constraints
>> | make[4]: *** [net/core/pktgen.o] Error 1
>> 
>> As a test, I __think__ I've modified my machine configuration so that it is the same as the BeagleBoard, but that also get the same even though the use of the BeagleBoard machine itself compiles. The only difference is I am trying to use the 3.0 kernel.
>> 
>> I see that the 3.0.bbappend doesn't list beagleboard as a 'compatible' machine but 2.6.37 does (under 6.0.1). Is what I see a known issue with the 3.0 kernel, or is there something else I can check?
> 
> It was a matter of time and energy and the lack of an urgent need to
> update things.
> 
> The board does work on the newer kernels (obviously), so trying the
> same thing against the 3.2+ kernel would be a good starting point.


I'm seeing the same under 7.0.0 if I use the 3.2 kernel. Note - if I set MACHINE = "beagleboard" then it builds ok, so it must be something I'm doing, but ...

Chris Tapp

opensource@keylevel.com
www.keylevel.com

Re: Kernel modules fail to compile for ARM

[Khem Raj]

On Mon, May 14, 2012 at 11:52 AM, Chris Tapp <opensource@keylevel.com> wrote:
> |   CC [M]  net/core/pktgen.o
> | /media/SSD-RAID/build-edison-pi/tmp/work/pi-poky-linux-gnueabi/linux-yocto-3.0.18+git1+d386e09f316e03061c088d2b13a48605c20fb3a6_1+2bba211297d10047637b8f49abd2c5415480ce4d-r3/linux/net/core/pktgen.c: In function 'pktgen_if_show':
> | /media/SSD-RAID/build-edison-pi/tmp/work/pi-poky-linux-gnueabi/linux-yocto-3.0.18+git1+d386e09f316e03061c088d2b13a48605c20fb3a6_1+2bba211297d10047637b8f49abd2c5415480ce4d-r3/linux/net/core/pktgen.c:682:2: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
> | /media/SSD-RAID/build-edison-pi/tmp/work/pi-poky-linux-gnueabi/linux-yocto-3.0.18+git1+d386e09f316e03061c088d2b13a48605c20fb3a6_1+2bba211297d10047637b8f49abd2c5415480ce4d-r3/linux/net/core/pktgen.c:682:2: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
> | /media/SSD-RAID/build-edison-pi/tmp/work/pi-poky-linux-gnueabi/linux-yocto-3.0.18+git1+d386e09f316e03061c088d2b13a48605c20fb3a6_1+2bba211297d10047637b8f49abd2c5415480ce4d-r3/linux/net/core/pktgen.c:682:2: error: 'asm' operand has impossible constraints
> | /media/SSD-RAID/build-edison-pi/tmp/work/pi-poky-linux-gnueabi/linux-yocto-3.0.18+git1+d386e09f316e03061c088d2b13a48605c20fb3a6_1+2bba211297d10047637b8f49abd2c5415480ce4d-r3/linux/net/core/pktgen.c:682:2: error: 'asm' operand has impossible constraints
> | make[4]: *** [net/core/pktgen.o] Error 1

interesting. This is gcc puking with some insane inline assembly. Can
you post preprocessed pktgen.c and cmdline arguments used to compile
it ?
and is it using gcc 4.7 or 4.6 ?

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

[Tomas Frydrych]

On 14/05/12 19:52, Chris Tapp wrote:
> I'm trying to put a BSP together for an ARM system (Raspberry Pi, ARM1176JZF-S CPU). 

I got the feeling that there might be multiple OE/RPI efforts going on
at the same time unaware of each other, e.g., I noticed this
meta-raspberrypi layer on github that seems to be well on the way,
https://github.com/djwillis/meta-raspberrypi ... perhaps getting various
folk interested in this together would be beneficial.

Tomas

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

[John Willis]

Hi Tomas,

> On 14/05/12 19:52, Chris Tapp wrote:
> > I'm trying to put a BSP together for an ARM system (Raspberry Pi,
> ARM1176JZF-S CPU).
> 
> I got the feeling that there might be multiple OE/RPI efforts going on at the
> same time unaware of each other, e.g., I noticed this meta-raspberrypi layer
> on github that seems to be well on the way,
> https://github.com/djwillis/meta-raspberrypi ... perhaps getting various
> folk interested in this together would be beneficial.

If anyone wants to pitch in with patches that would be great. There is also a little more information on the layer from a post of mine a few weeks back - http://blogs.distant-earth.com/wp/?p=377.

I tend to build my layers using Angstrom as the distro (in fact it is now referenced in the Angstrom setup scripts) or straight OE-core and no distro so I can't claim this layer is well tested on Yocto but there are very few, if any, reasons it will not work well. Pull requests are great ;).

There are a few things missing at the moment, mainly the binary GPU libs but as the proprietary licence has now been sorted for the blobs I'll push the recipe in the next few days. 

Other than that it works pretty well on both variants of the hardware but there is always room for improvement.

Regards,

John

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

[Osier-mixon, Jeffrey]

There do seem to be multiple efforts. The Qt on Pi folks are also
putting together a BSP. I'd like to find a way to put everyone
together to make sure effort is not being duplicated. Is there
interest in a meeting of interested parties, perhaps on Thursday?

On Tue, May 15, 2012 at 7:51 AM, John Willis
<John.Willis@distant-earth.com> wrote:
> Hi Tomas,
>
>> On 14/05/12 19:52, Chris Tapp wrote:
>> > I'm trying to put a BSP together for an ARM system (Raspberry Pi,
>> ARM1176JZF-S CPU).
>>
>> I got the feeling that there might be multiple OE/RPI efforts going on at the
>> same time unaware of each other, e.g., I noticed this meta-raspberrypi layer
>> on github that seems to be well on the way,
>> https://github.com/djwillis/meta-raspberrypi ... perhaps getting various
>> folk interested in this together would be beneficial.
>
> If anyone wants to pitch in with patches that would be great. There is also a little more information on the layer from a post of mine a few weeks back - http://blogs.distant-earth.com/wp/?p=377.
>
> I tend to build my layers using Angstrom as the distro (in fact it is now referenced in the Angstrom setup scripts) or straight OE-core and no distro so I can't claim this layer is well tested on Yocto but there are very few, if any, reasons it will not work well. Pull requests are great ;).
>
> There are a few things missing at the moment, mainly the binary GPU libs but as the proprietary licence has now been sorted for the blobs I'll push the recipe in the next few days.
>
> Other than that it works pretty well on both variants of the hardware but there is always room for improvement.
>
> Regards,
>
> John
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



-- 
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org

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

[John Willis]

> There do seem to be multiple efforts. The Qt on Pi folks are also putting
> together a BSP. I'd like to find a way to put everyone together to make
sure
> effort is not being duplicated. Is there interest in a meeting of
interested
> parties, perhaps on Thursday?

I have quite a few commitments on Thursday (oe hacking is not my day job)
but pulling everyone together sounds like a very good idea. I'll try and
make a meeting if someone else wants to pull it together.

It's also worth pushing http://www.openembedded.org/wiki/LayerIndex again as
people (me included) often seem to forget to add layers to this so it can be
hard to find out if pre-existing work is being carried out.

Regards,

John

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

[Chris Tapp]

On 15 May 2012, at 16:05, Osier-mixon, Jeffrey wrote:

> There do seem to be multiple efforts. The Qt on Pi folks are also
> putting together a BSP. I'd like to find a way to put everyone
> together to make sure effort is not being duplicated. Is there
> interest in a meeting of interested parties, perhaps on Thursday?


I would be interested, but ideally have to do it out of working hours. I'm uk-based, so I would prefer it to be outside of 08:00 to 16:30 UTC. If that's not possible, then I can try and arrange some time off.

Chris Tapp

opensource@keylevel.com
www.keylevel.com

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

[Bruce Ashfield]

On 12-05-15 05:15 AM, Tomas Frydrych wrote:
> On 14/05/12 19:52, Chris Tapp wrote:
>> I'm trying to put a BSP together for an ARM system (Raspberry Pi, ARM1176JZF-S CPU).
>
> I got the feeling that there might be multiple OE/RPI efforts going on
> at the same time unaware of each other, e.g., I noticed this
> meta-raspberrypi layer on github that seems to be well on the way,
> https://github.com/djwillis/meta-raspberrypi ... perhaps getting various
> folk interested in this together would be beneficial.

I'll jump in and ask my obvious question, if we want to pull in some
extra BSP/kernel developers, is there a fundamental reason why a
different kernel/kernel version than one of the linux-yocto ones is
being used ?

If you line up with one of those, there's a chance to pickup fixes,
features and have someone like me help maintain things where it
makes sense.

Collecting kernels and BSPs in trees all over the place is one of the
things that I'd like to try and help with going forward in 2012.

Cheers,

Bruce

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

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

[Chris Tapp]

On 15 May 2012, at 16:44, Bruce Ashfield wrote:

> On 12-05-15 05:15 AM, Tomas Frydrych wrote:
>> On 14/05/12 19:52, Chris Tapp wrote:
>>> I'm trying to put a BSP together for an ARM system (Raspberry Pi, ARM1176JZF-S CPU).
>> 
>> I got the feeling that there might be multiple OE/RPI efforts going on
>> at the same time unaware of each other, e.g., I noticed this
>> meta-raspberrypi layer on github that seems to be well on the way,
>> https://github.com/djwillis/meta-raspberrypi ... perhaps getting various
>> folk interested in this together would be beneficial.
> 
> I'll jump in and ask my obvious question, if we want to pull in some
> extra BSP/kernel developers, is there a fundamental reason why a
> different kernel/kernel version than one of the linux-yocto ones is
> being used ?

That's certainly the way I'm trying to go. I would like to see a full-feature BSP as the 'default' for the board that can easily be customized to reduce the size / boot times for 'full embedded' use. If only I could work out how to get it to work ;-)

It also needs some extra 'stuff' to pull the image together - there's a Broadcom-provided binary that has to be used as the first stage when booting, but the first step (as I see it) is to get a working kernel image based on linux-yocto 3.0/3.2.

> If you line up with one of those, there's a chance to pickup fixes,
> features and have someone like me help maintain things where it
> makes sense.

That would be really nice.

> Collecting kernels and BSPs in trees all over the place is one of the
> things that I'd like to try and help with going forward in 2012.

Chris Tapp

opensource@keylevel.com
www.keylevel.com

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

[Tomas Frydrych]

Hi Bruce,

On 15/05/12 16:44, Bruce Ashfield wrote:
> On 12-05-15 05:15 AM, Tomas Frydrych wrote:
>> On 14/05/12 19:52, Chris Tapp wrote:
>>> I'm trying to put a BSP together for an ARM system (Raspberry Pi,
>>> ARM1176JZF-S CPU).
>>
>> I got the feeling that there might be multiple OE/RPI efforts going on
>> at the same time unaware of each other, e.g., I noticed this
>> meta-raspberrypi layer on github that seems to be well on the way,
>> https://github.com/djwillis/meta-raspberrypi ... perhaps getting various
>> folk interested in this together would be beneficial.
> 
> I'll jump in and ask my obvious question, if we want to pull in some
> extra BSP/kernel developers, is there a fundamental reason why a
> different kernel/kernel version than one of the linux-yocto ones is
> being used ?
> 
> If you line up with one of those, there's a chance to pickup fixes,
> features and have someone like me help maintain things where it
> makes sense.

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.

(Though admittedly working with some silicon vendors specific meta
layers can be real PITA :) ).

Tomas

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

[Bruce Ashfield]

On 12-05-15 01:36 PM, Tomas Frydrych wrote:
> Hi Bruce,
>
> On 15/05/12 16:44, Bruce Ashfield wrote:
>> On 12-05-15 05:15 AM, Tomas Frydrych wrote:
>>> On 14/05/12 19:52, Chris Tapp wrote:
>>>> I'm trying to put a BSP together for an ARM system (Raspberry Pi,
>>>> ARM1176JZF-S CPU).
>>>
>>> I got the feeling that there might be multiple OE/RPI efforts going on
>>> at the same time unaware of each other, e.g., I noticed this
>>> meta-raspberrypi layer on github that seems to be well on the way,
>>> https://github.com/djwillis/meta-raspberrypi ... perhaps getting various
>>> folk interested in this together would be beneficial.
>>
>> I'll jump in and ask my obvious question, if we want to pull in some
>> extra BSP/kernel developers, is there a fundamental reason why a
>> different kernel/kernel version than one of the linux-yocto ones is
>> being used ?
>>
>> If you line up with one of those, there's a chance to pickup fixes,
>> features and have someone like me help maintain things where it
>> makes sense.
>
> 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.

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.

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, so doing
that on top of the QA's arch and general base would be logical/incremental.
Rather than something completely different which isn't incremental at
all.

Cheers,

Bruce

>
> (Though admittedly working with some silicon vendors specific meta
> layers can be real PITA :) ).
>
> Tomas

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

[Tomas Frydrych]

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.


> 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-*).

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.


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. :-)

Tomas

Re: 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@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto