Fix a bug to make a ltp test work on qemux86-64:
bug 900: [LTP] clock_nanosleep01 fails on qemux86-64

Liming Wang (1):
x86: fix a bug of wrong return erorr.

arch/x86/vdso/vclock_gettime.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)

Hi all,

We now have the mechanism for fixing bug #1096 [1] i.e. showing a
warning if the user is running a build on a distro that has not been
tested; however to make this work what we now need is a list of
distributions we want to consider tested. What distros specifically are we going to list for 1.1?

We check Ubuntu, Opensuse and Fedora in our regular testing. So at least, the 3 distros should be added as support.

Cheers,
Paul

[1] http://bugzilla.pokylinux.org/show_bug.cgi?id=1096

Best Regards,
Jiajun

On Tuesday 23 August 2011 16:30:33 Paul Eggleton wrote:

A number of minor documentation fixes; please review for sanity prior
to merging, in particular I wasn't sure if the document titles were left
blank deliberately.

These changes are against Poky but might need to be merged into yocto-docs
first.

Have spoken to Scott R, seems he's been working on the Poky reference manual
so I will need to rebase once he's pushed his changes. Feel free to review but
do not merge this set.

Thanks,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre

On 08/23/2011 07:01 PM, omalleys@msu.edu wrote:

Quoting Gordan Bobic <gordan@bobich.net>:

Unfortunately there is no way I could make it, but on the subject of 3D
support on ARM, Luke recently mentioned something that initially seemed
outlandish but upon closer examination doesn't seem like a bad idea. As
we all know, the state of openness of specifications of commonly used
ARM 3D GPUs is at best dire. What has been proposed is a bit radical,
but it doesn't actually seem that implausible. Specifically, combining
Open Graphics Project (http://wiki.opengraphics.org/tiki-index.php) and
the xilinx zynq-7000 or similar (dual core Cortex A9 + FPGA). The idea
is to have an OGP GPU in firmware in FPGA. In terms of the power budget,
it seems to work relatively sanely considering what it is, and it is as
ideal as it gets as far as openness and flexibility goes.

I just thought it's worthy of a mention.

It does seem outlandish, but it is kind of cool. Is it going to give
enough 3d speed? The next gen tegra is supposed to have a 24 core GPU.

If you can quantify what "enough 3D speed" means, then perhaps that can be assessed. There really aren't many applications around at the moment to make this an issue. I'd be more interested in it's ability to decode 1080p.

Then again - it's FPGA! You can load a different "firmware" depending on whether you need 1080p decoding or 3D rendering, or some other kind of specialized DSP offload with only bare minimal VGA. :)

Personally, I think OGP would be worth it even if just for the fact that we would no longer have to beg (in vain) the vendors for decent drivers or published specs. The added flexibility on top is just a "free extra". :)

Gordan

On Tue, Aug 23, 2011 at 02:26:06PM -0700, Saul Wold wrote:

On 08/23/2011 12:35 PM, Tom Rini wrote:

On Tue, Aug 23, 2011 at 1:36 PM, Saul Wold<sgw@linux.intel.com> wrote:

[YOCTO #1381]

lttng-ust generates an ICE when building for armv7, so change it to armv5
| vfprintf.c:956:1: error: unrecognizable insn:
| (insn 3968 3967 3969 145 (set (subreg:SI (reg/v:DI 160 [ _umax ]) 0)
| (sign_extend:SI (mem:QI (plus:SI (mult:SI (reg/v:SI 166 [ nextarg ])
| (const_int 8 [0x8]))
| (reg/f:SI 370 [ argtable.7 ])) [0 *D.6937_569+0 S1
A32]))) vfprintf.c:555 -1
| (nil))
| vfprintf.c:956:1: internal compiler error: in extract_insn, at recog.c:2109

Which version of lttng-ust is this exactly? In addition to what
Darren is saying about how this should be papered-over at the recipe
level until gcc itself is fixed...

Sorry, this was my mis-understanding of Darren's comment.

Version of lttng-ust is 0.15.

Initially I tried to do something with tcmode-default, setting lttng-ust
similar to meta-xlib which also had a ICE issue.

TARGET_CC_ARCH_arm_pn-mesa-xlib :=
"${@'${TARGET_CC_ARCH}'.replace('armv7-a','armv5')}"

That caused the compiler to complain about a mode issue, probably due to
mixing of tune parameters:

| arm-poky-linux-gnueabi-libtool: compile: ccache
arm-poky-linux-gnueabi-gcc
-march=armv5 -fno-tree-vectorize -mthumb-interwork -mfloat-abi=softfp
-mfpu=neon -mtune=cortex-a8
--sysroot=/vol/1/sgw/autobuilder/yab/yocto-slave/external/build/build/tmp/sysroots/beagleboard
-DHAVE_CONFIG_H -I. -I.. -I../include/ust -I../include -I../libustcomm
-DUST_COMPONENT=libust -fno-strict-aliasing -Wall -pipe -g
-feliminate-unused-debug-types -MT libust_la-marker-control.lo -MD -MP -MF
.deps/libust_la-marker-control.Tpo -c marker-control.c -o
libust_la-marker-control.o >/dev/null 2>&1
| mv -f .deps/libust_la-tracercore.Tpo .deps/libust_la-tracercore.Plo
| {standard input}: Assembler messages:
| {standard input}:190: Error: selected processor does not support ARM
mode `dmb'

Yes, we are trying to solve Compiler issue, when I first started working
on the last week there was not a compiler bug filed, but now there seems
to be one!

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43137

Which looks like it is resolved also!

This is better bug report:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50099

Regards,

I will move this to Nitin to see if he can incorporate the patch into gcc.

Sau!

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

--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com

On 08/23/2011 12:35 PM, Tom Rini wrote:

On Tue, Aug 23, 2011 at 1:36 PM, Saul Wold<sgw@linux.intel.com> wrote:

[YOCTO #1381]

lttng-ust generates an ICE when building for armv7, so change it to armv5
| vfprintf.c:956:1: error: unrecognizable insn:
| (insn 3968 3967 3969 145 (set (subreg:SI (reg/v:DI 160 [ _umax ]) 0)
| (sign_extend:SI (mem:QI (plus:SI (mult:SI (reg/v:SI 166 [ nextarg ])
| (const_int 8 [0x8]))
| (reg/f:SI 370 [ argtable.7 ])) [0 *D.6937_569+0 S1
A32]))) vfprintf.c:555 -1
| (nil))
| vfprintf.c:956:1: internal compiler error: in extract_insn, at recog.c:2109

Which version of lttng-ust is this exactly? In addition to what
Darren is saying about how this should be papered-over at the recipe
level until gcc itself is fixed...

Sorry, this was my mis-understanding of Darren's comment.

Version of lttng-ust is 0.15.

Initially I tried to do something with tcmode-default, setting lttng-ust similar to meta-xlib which also had a ICE issue.

TARGET_CC_ARCH_arm_pn-mesa-xlib := "${@'${TARGET_CC_ARCH}'.replace('armv7-a','armv5')}"

That caused the compiler to complain about a mode issue, probably due to mixing of tune parameters:

| arm-poky-linux-gnueabi-libtool: compile: ccache arm-poky-linux-gnueabi-gcc
-march=armv5 -fno-tree-vectorize -mthumb-interwork -mfloat-abi=softfp
-mfpu=neon -mtune=cortex-a8
--sysroot=/vol/1/sgw/autobuilder/yab/yocto-slave/external/build/build/tmp/sysroots/beagleboard
-DHAVE_CONFIG_H -I. -I.. -I../include/ust -I../include -I../libustcomm
-DUST_COMPONENT=libust -fno-strict-aliasing -Wall -pipe -g
-feliminate-unused-debug-types -MT libust_la-marker-control.lo -MD -MP -MF
.deps/libust_la-marker-control.Tpo -c marker-control.c -o
libust_la-marker-control.o >/dev/null 2>&1
| mv -f .deps/libust_la-tracercore.Tpo .deps/libust_la-tracercore.Plo
| {standard input}: Assembler messages:
| {standard input}:190: Error: selected processor does not support ARM mode `dmb'

Yes, we are trying to solve Compiler issue, when I first started working on the last week there was not a compiler bug filed, but now there seems to be one!

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43137

Which looks like it is resolved also!

I will move this to Nitin to see if he can incorporate the patch into gcc.

Sau!

On Tue, Aug 23, 2011 at 1:36 PM, Saul Wold <sgw@linux.intel.com> wrote:

   [YOCTO #1381]

   lttng-ust generates an ICE when building for armv7, so change it to armv5
   | vfprintf.c:956:1: error: unrecognizable insn:
   | (insn 3968 3967 3969 145 (set (subreg:SI (reg/v:DI 160 [ _umax ]) 0)
   |         (sign_extend:SI (mem:QI (plus:SI (mult:SI (reg/v:SI 166 [ nextarg ])
   |                         (const_int 8 [0x8]))
   |                     (reg/f:SI 370 [ argtable.7 ])) [0 *D.6937_569+0 S1
   A32]))) vfprintf.c:555 -1
   |      (nil))
   | vfprintf.c:956:1: internal compiler error: in extract_insn, at recog.c:2109

Which version of lttng-ust is this exactly? In addition to what
Darren is saying about how this should be papered-over at the recipe
level until gcc itself is fixed...

--
Tom

On 08/23/2011 11:36 AM, Saul Wold wrote:

[YOCTO #1381]

lttng-ust generates an ICE when building for armv7, so change it to armv5
| vfprintf.c:956:1: error: unrecognizable insn:
| (insn 3968 3967 3969 145 (set (subreg:SI (reg/v:DI 160 [ _umax ]) 0)
| (sign_extend:SI (mem:QI (plus:SI (mult:SI (reg/v:SI 166 [ nextarg ])
| (const_int 8 [0x8]))
| (reg/f:SI 370 [ argtable.7 ])) [0 *D.6937_569+0 S1
A32]))) vfprintf.c:555 -1
| (nil))
| vfprintf.c:956:1: internal compiler error: in extract_insn, at recog.c:2109

Signed-off-by: Saul Wold <sgw@linux.intel.com>
---
meta-yocto/conf/machine/beagleboard.conf | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/meta-yocto/conf/machine/beagleboard.conf b/meta-yocto/conf/machine/beagleboard.conf
index 0b3cebc..9ed8c59 100644
--- a/meta-yocto/conf/machine/beagleboard.conf
+++ b/meta-yocto/conf/machine/beagleboard.conf
@@ -18,6 +18,8 @@ MACHINE_EXTRA_RRECOMMENDS += "beagleboard-audio"
# Allow for MMC booting (required by the NAND-less Beagleboard XM)
EXTRA_IMAGEDEPENDS += "u-boot x-load"

+DEFAULT_TUNE = "cortexa8"
+

Sorry, I didn't mean for this to be a final solution, just a means to
determine the problem. Removing neon eliminates the vector floating
point, which we do not want to do. The correct fix for this is probably
in gcc. I'd rather not build lttng for beagleboard than change the tune
default to DEFAULT_TUNE to "cortexa8".

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

[YOCTO #1381]

lttng-ust generates an ICE when building for armv7, so change it to armv5
| vfprintf.c:956:1: error: unrecognizable insn:
| (insn 3968 3967 3969 145 (set (subreg:SI (reg/v:DI 160 [ _umax ]) 0)
| (sign_extend:SI (mem:QI (plus:SI (mult:SI (reg/v:SI 166 [ nextarg ])
| (const_int 8 [0x8]))
| (reg/f:SI 370 [ argtable.7 ])) [0 *D.6937_569+0 S1
A32]))) vfprintf.c:555 -1
| (nil))
| vfprintf.c:956:1: internal compiler error: in extract_insn, at recog.c:2109

Signed-off-by: Saul Wold <sgw@linux.intel.com>
---
meta-yocto/conf/machine/beagleboard.conf | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/meta-yocto/conf/machine/beagleboard.conf b/meta-yocto/conf/machine/beagleboard.conf
index 0b3cebc..9ed8c59 100644
--- a/meta-yocto/conf/machine/beagleboard.conf
+++ b/meta-yocto/conf/machine/beagleboard.conf
@@ -18,6 +18,8 @@ MACHINE_EXTRA_RRECOMMENDS += "beagleboard-audio"
# Allow for MMC booting (required by the NAND-less Beagleboard XM)
EXTRA_IMAGEDEPENDS += "u-boot x-load"

+DEFAULT_TUNE = "cortexa8"
+
include conf/machine/include/tune-cortexa8.inc

IMAGE_FSTYPES += "tar.bz2 jffs2"
--
1.7.6

Thanks to Darren for helping with this one.

Sau!


The following changes since commit b2266beeb357bae938830f559845f5f3deb4f916:

usermanual: The git fetcher defaults to the git protocol (or file) (2011-08-23 10:00:35 -0700)

are available in the git repository at:
git://git.yoctoproject.org/poky-contrib sgw/fix
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=sgw/fix

Saul Wold (1):
beagleboard.conf: set DEFAULT_TUNE to cortexa8

meta-yocto/conf/machine/beagleboard.conf | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)

--
1.7.6

On 08/23/2011 10:55 AM, Saul Wold wrote:

On 08/23/2011 09:59 AM, Darren Hart wrote:

On 08/21/2011 04:15 PM, Saul Wold wrote:

Tom, Darren:

This adds Bruce's changes to allow for a time limited kernel, the
default is set for 10 days.

I presume we need a linux-yocto-rt_3.0.bbappend as well?

Are we building and delivering RT images for the release? If not then
there is no need.

Given the increased interest in preempt-rt support, I think it would
make sense to do so. It certainly adds a further burden to the release
process.

Beth?

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Quoting Gordan Bobic <gordan@bobich.net>:

Unfortunately there is no way I could make it, but on the subject of 3D
support on ARM, Luke recently mentioned something that initially seemed
outlandish but upon closer examination doesn't seem like a bad idea. As
we all know, the state of openness of specifications of commonly used
ARM 3D GPUs is at best dire. What has been proposed is a bit radical,
but it doesn't actually seem that implausible. Specifically, combining
Open Graphics Project (http://wiki.opengraphics.org/tiki-index.php) and
the xilinx zynq-7000 or similar (dual core Cortex A9 + FPGA). The idea
is to have an OGP GPU in firmware in FPGA. In terms of the power budget,
it seems to work relatively sanely considering what it is, and it is as
ideal as it gets as far as openness and flexibility goes.

I just thought it's worthy of a mention.

It does seem outlandish, but it is kind of cool. Is it going to give enough 3d speed? The next gen tegra is supposed to have a 24 core GPU.

It is probably more sane then my idea of just having a test suite from digital video out -> digital video receiver/capture card to get known test results. Then you could set up a hinted genetic algorithm based on a comparison. It would only work with digital video signals though.

On 08/23/2011 09:59 AM, Darren Hart wrote:

On 08/21/2011 04:15 PM, Saul Wold wrote:

Tom, Darren:

This adds Bruce's changes to allow for a time limited kernel, the
default is set for 10 days.

I presume we need a linux-yocto-rt_3.0.bbappend as well?

Are we building and delivering RT images for the release? If not then there is no need.

Sau!

--
Darren

This layer will only be added to the meta-intel BSP on the Auto-builder.

Sau!


The following changes since commit 5c41b9b6a245664543e6ddd440d10a0696caaf7b:

n450: decouple from meta-yocto atom-pc machine config (2011-08-19 14:22:21 -0700)

are available in the git repository at:
git://git.yoctoproject.org/meta-intel sgw/tlk
http://git.yoctoproject.org/cgit.cgi/meta-intel/log/?h=sgw/tlk

Bruce Ashfield (1):
meta-tlk: initial creation

meta-tlk/README | 6 ++++++
meta-tlk/conf/layer.conf | 6 ++++++
.../linux/linux-yocto/time-limited-kernel.cfg | 3 +++
.../recipes-kernel/linux/linux-yocto_3.0.bbappend | 4 ++++
4 files changed, 19 insertions(+), 0 deletions(-)
create mode 100644 meta-tlk/README
create mode 100644 meta-tlk/conf/layer.conf
create mode 100644 meta-tlk/recipes-kernel/linux/linux-yocto/time-limited-kernel.cfg
create mode 100644 meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend

On 08/23/2011 05:38 AM, Koen Kooi wrote:

Op 20 aug. 2011, om 00:23 heeft Darren Hart het volgende geschreven:

Fixes [YOCTO #1203]

Using the hard floating point abi is incompatible with some binary libaries and
3D support for the Beagleboard. As we do not provide these in poky and
meta-yocto, we can take advantage of the hard floating point abi.

What advantage are you talking about? So far everyone has been unable to provide real-world numbers[1] that show hardfp making a difference compared to a properly configured softfp. The numbers debian and meego are showing are comparing it against completely vfpless builds, which borders on fraud.

Yocto is of course free to do what it pleases, but switching to hardfp isn't going to make beagle support better, only worse. But if that's your goal, go for it, meta-ti is still there to provide the absolute best beagle support.

[1] povray is the only outlier, but I don't think people will build beagle based renderfarms in the near future.

The big win for hard float ABI (emphasis mine) is functions that return floating point values. I personally care about this, but we also know returning floats is "bad" so we sort of avoid it.

I agree with Phil Blundell that this is not a beagle specific thing.

Long term I expect hard float to become normal, but I see no need to rush there (no matter what other distros are claiming).

Philip

On Tue, Aug 23, 2011 at 11:55 AM, Darren Hart <dvhart@linux.intel.com> wrote:

On 08/23/2011 08:34 AM, Tom Rini wrote:

On Tue, Aug 23, 2011 at 8:31 AM, Darren Hart <dvhart@linux.intel.com> wrote:

On 08/23/2011 05:38 AM, Koen Kooi wrote:

Op 20 aug. 2011, om 00:23 heeft Darren Hart het volgende geschreven:

Fixes [YOCTO #1203]

Using the hard floating point abi is incompatible with some binary
libaries and 3D support for the Beagleboard. As we do not provide
these in poky and meta-yocto, we can take advantage of the hard
floating point abi.

What advantage are you talking about? So far everyone has been unable
to provide real-world numbers[1] that show hardfp making a difference
compared to a properly configured softfp. The numbers debian and
meego are showing are comparing it against completely vfpless builds,

That's good reasoning to stick with softfp+neon. Unfortunately I can't
find the mail threads that first got me looking into adding hardfp
support. As I said, I'm not sold on the idea, but it was requested so I
looked into how to address it.

If nobody comes forward saying they would really like to have this, I'm
going to modify the patch series to disable hardfp by default, but leave
the infrastructure in place so people can enable if they like.

Well, are there some softfp related config bits we need on the yocto
side that meta-ti has, in order to bring that performance back in
line?

Are you referring to a specific performance measure?

Just the general ones that have caused people to say softfp+neon isn't
enough (outside of povray :)).

--
Tom

On 08/21/2011 04:15 PM, Saul Wold wrote:

Tom, Darren:

This adds Bruce's changes to allow for a time limited kernel, the
default is set for 10 days.

I presume we need a linux-yocto-rt_3.0.bbappend as well?

--
Darren

This layer will only be added to the meta-intel BSP on the Auto-builder.

Sau!


The following changes since commit 5c41b9b6a245664543e6ddd440d10a0696caaf7b:

n450: decouple from meta-yocto atom-pc machine config (2011-08-19 14:22:21 -0700)

are available in the git repository at:
git://git.yoctoproject.org/meta-intel sgw/tlk
http://git.yoctoproject.org/cgit.cgi/meta-intel/log/?h=sgw/tlk

Bruce Ashfield (1):
meta-tlk: initial creation

meta-tlk/README | 6 ++++++
meta-tlk/conf/layer.conf | 6 ++++++
.../linux/linux-yocto/time-limited-kernel.cfg | 3 +++
.../recipes-kernel/linux/linux-yocto_3.0.bbappend | 4 ++++
4 files changed, 19 insertions(+), 0 deletions(-)
create mode 100644 meta-tlk/README
create mode 100644 meta-tlk/conf/layer.conf
create mode 100644 meta-tlk/recipes-kernel/linux/linux-yocto/time-limited-kernel.cfg
create mode 100644 meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

On 08/23/2011 08:34 AM, Tom Rini wrote:

On Tue, Aug 23, 2011 at 8:31 AM, Darren Hart <dvhart@linux.intel.com> wrote:

On 08/23/2011 05:38 AM, Koen Kooi wrote:

Op 20 aug. 2011, om 00:23 heeft Darren Hart het volgende geschreven:

Fixes [YOCTO #1203]

Using the hard floating point abi is incompatible with some binary
libaries and 3D support for the Beagleboard. As we do not provide
these in poky and meta-yocto, we can take advantage of the hard
floating point abi.

What advantage are you talking about? So far everyone has been unable
to provide real-world numbers[1] that show hardfp making a difference
compared to a properly configured softfp. The numbers debian and
meego are showing are comparing it against completely vfpless builds,

That's good reasoning to stick with softfp+neon. Unfortunately I can't
find the mail threads that first got me looking into adding hardfp
support. As I said, I'm not sold on the idea, but it was requested so I
looked into how to address it.

If nobody comes forward saying they would really like to have this, I'm
going to modify the patch series to disable hardfp by default, but leave
the infrastructure in place so people can enable if they like.

Well, are there some softfp related config bits we need on the yocto
side that meta-ti has, in order to bring that performance back in
line?

Are you referring to a specific performance measure?

Jason, Koen, are there any such config bits? We are currently using the
cortexa8-neon tune configuration from oe-core.

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

On Tue, 23 Aug 2011 17:11:34 +0100, Steve McIntyre <steve.mcintyre@linaro.org> wrote:

On Tue, Aug 09, 2011 at 07:15:34PM +0100, Steve McIntyre wrote:

Hi folks,

Following on from the founding of the cross-distro ARM mailing list,
I'd like to propose an ARM summit at this year's Linux Plumbers
conference [1]. I'm hoping for a slot on Thursday evening, but this
remains to be confirmed at this point.

We had some lively discussion about the state of ARM Linux distros at
the Linaro Connect [2] event in Cambridge last week. It rapidly became
clear that some of the topics we discussed deserve a wider audience,
so we're suggesting a meetup at Plumbers for that bigger
discussion. The initial proposed agenda is:

* ARM hard-float
+ What is it and why does it matter?
+ How can distributions keep compatible (i.e. gcc triplet to
describe the port)?

* Adding support for ARM as an architecture to the Linux Standard
Base (LSB)
+ Does it matter?
+ What's needed?

* FHS - multi-arch coming soon, how do we proceed?

* 3D support on ARM platforms
+ Open GL vs. GLES - which is appropriate?

but I'm sure that other people will think of more issues they'd like
to discuss. :-)

If you wish to attend, please reply to the cross-distro list and let
us know to expect you. Make sure you're registered to attend Plumbers
Conf, and get your travel and accommodation organised ASAP.

[1] http://www.linuxplumbersconf.org/2011/
[2] http://connect.linaro.org/

UPDATE: we've not had many people confirm interest in this event yet,
which is a shame. If you would like to join us for this session,
please reply and let me know. If we don't get enough interest by the
end of Sunday (28th August), then we'll have to cancel the meeting.

Unfortunately there is no way I could make it, but on the subject of 3D support on ARM, Luke recently mentioned something that initially seemed outlandish but upon closer examination doesn't seem like a bad idea. As we all know, the state of openness of specifications of commonly used ARM 3D GPUs is at best dire. What has been proposed is a bit radical, but it doesn't actually seem that implausible. Specifically, combining Open Graphics Project (http://wiki.opengraphics.org/tiki-index.php) and the xilinx zynq-7000 or similar (dual core Cortex A9 + FPGA). The idea is to have an OGP GPU in firmware in FPGA. In terms of the power budget, it seems to work relatively sanely considering what it is, and it is as ideal as it gets as far as openness and flexibility goes.

I just thought it's worthy of a mention.

Gordan

On Tue, Aug 09, 2011 at 07:15:34PM +0100, Steve McIntyre wrote:

Hi folks,

Following on from the founding of the cross-distro ARM mailing list,
I'd like to propose an ARM summit at this year's Linux Plumbers
conference [1]. I'm hoping for a slot on Thursday evening, but this
remains to be confirmed at this point.

We had some lively discussion about the state of ARM Linux distros at
the Linaro Connect [2] event in Cambridge last week. It rapidly became
clear that some of the topics we discussed deserve a wider audience,
so we're suggesting a meetup at Plumbers for that bigger
discussion. The initial proposed agenda is:

* ARM hard-float
+ What is it and why does it matter?
+ How can distributions keep compatible (i.e. gcc triplet to
describe the port)?

* Adding support for ARM as an architecture to the Linux Standard
Base (LSB)
+ Does it matter?
+ What's needed?

* FHS - multi-arch coming soon, how do we proceed?

* 3D support on ARM platforms
+ Open GL vs. GLES - which is appropriate?

but I'm sure that other people will think of more issues they'd like
to discuss. :-)

If you wish to attend, please reply to the cross-distro list and let
us know to expect you. Make sure you're registered to attend Plumbers
Conf, and get your travel and accommodation organised ASAP.

[1] http://www.linuxplumbersconf.org/2011/
[2] http://connect.linaro.org/

UPDATE: we've not had many people confirm interest in this event yet,
which is a shame. If you would like to join us for this session,
please reply and let me know. If we don't get enough interest by the
end of Sunday (28th August), then we'll have to cancel the meeting.

Cheers,
--
Steve McIntyre steve.mcintyre@linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

Hi all,

We now have the mechanism for fixing bug #1096 [1] i.e. showing a warning if
the user is running a build on a distro that has not been tested; however to
make this work what we now need is a list of distributions we want to consider
tested. What distros specifically are we going to list for 1.1?

Cheers,
Paul

[1] http://bugzilla.pokylinux.org/show_bug.cgi?id=1096


--

Paul Eggleton
Intel Open Source Technology Centre