All,
Along with more bugs filed against Freescale kernels, I'd propose that we
use a consistent tagging rule as below (Freescale internally is using more
non-"i" prefixed version, so we're following):
mx51 - for i.MX51 specific bugs
mx53 - for i.MX53 specific bugs
mx6 - for i.MX6DQ and other i.MX6 variants
mx51evk - for i.MX51 Babbage/EVK board specific bugs
mx53loco - for i.MX53 QuickStart board specific bugs
mx6qs - for i.MX6DQ QuickStart specific bugs
linaro-android - for Android bugs
Internally, we are also using the following tags:
v3.1 - for 3.1 kernel specific bugs
ripley - for bugs of the new i.MX53 QuickStart w/ MC34708 as PMIC
Thanks
- eric
Complete status report is in :
https://wiki.linaro.org/OfficeofCTO/WeeklyReport
Last meeting minutes:
https://wiki.linaro.org/OfficeofCTO/2011-10-04
== Highlights ==
Please see the status report for more details.
* ARMHF: Benchmarking activity is going smoothly now. On the package
porting side we have reached ~8200 packages done, still 90 to do. That's
at 88-89%. You can follow the progress of this porting work -
*
http://buildd.debian-ports.org/status/architecture.php?a=armhf&suite=sid
contains a high-level view of what packages are done and what is left to do
* http://wiki.debian.org/ArmHardFloatTodo has a graph at the bottom
of the page showing what is the percentage of the packages built for
each architecture
* Boot Architecture: Regarding the scope of the work, the group created
a list of the things to be worked on (both short term - focusing on ARM
Server - and long term - strategic and design issues)
* Short term: resources are needed to cover this work - will be
defined after discussing the prioritised list with the TSC
* Support for Uboot
* Kernel update process/method should be clarified
* Making every uboot behave the same way
* How does uboot decide what kernel to load - does not have to be
uboot specific fix, could be a script for uboot
* Single zImage able to boot on multiple SOCs
* Support for grub on uboot. How will that help UEFI: distros
would be able to have a bootloader under their control and can rely upon
as expected also on x86. Could be done by adding support for syslinux
configuration files, or porting port grub on uboot (as a uboot app
called by EFI)
* Port tianocore as a uboot app - how well does the driver model
line up for that? The device model in uboot is pretty thin
* Investigate GPT support for uboot - would it be troublesome with
some SoCs (SoC specific code just to bootstrap stuff? You can have
alongside the GPT a backwards compatibility boot table so you can have
MBR and GPT happily coexisting)
* Uboot should understand which is the active partition - or
should have a mechanism to tell the user which is the active partition.
E.g. in parted there is the bios-grub flag which indicates the boot
partition. If we are booting off a block device the information of which
is the boot partition comes from the disk.
* Long term: there is a keen vendors' interest in standards process
- which the Linux community has not been extremely involved in the past.
So the long-term target would be working with the standards -
familiarise oneself with the existing standards (eg for x86 UEFI + ACPI
v.4 - we should get familiar with those), and to provide feedback on
those standards. One possible thread of work is to investigate DT
support into the ACPI spec? What are the benefits of the DT, what are
the merits of ACPI (this is already out there and we need to see how it
fits in with Linux support on ARM). Ideally we should get towards a
solution which bridges across the positive points between DT and ACPI.
Best regards,
--
Ilias Biris ilias.biris(a)linaro.org
Project Manager, Linaro
M: +358504839608, IRC: ibiris Skype: ilias_biris
Linaro.org│ Open source software for ARM SoCs
Hi,
linaro-android-media-create --dev option is now using "mx53loco" parameter for
i.MX53 boards. This changes is available on the bzr repository and will be part
of 2011.10 release. Please, update your scripts that are using the deprecated
"iMX53" value.
Cheers,
--
Fathi Boudra
Linaro Release Manager | Validation Project Manager
Linaro.org | Open source software for ARM SoCs
Hi,
A document describing how to release Linaro components has been added:
http://wiki.linaro.org/Process/ReleaseComponents
If you release Linaro components, please take a look.
Feedback is welcome to improve the document.
Cheers,
--
Fathi Boudra
Linaro Release Manager | Validation Project Manager
Linaro.org | Open source software for ARM SoCs
Hi,
This is a mail sent to remind you the coming release dates:
* Linaro 11.10 components release is October 20nd, 2011.
* Linaro 11.10 RC images is October 24th, 2011.
* Linaro 11.10 release is October 27th, 2011.
Components release will be announced this week.
The release dates and deliveries information is available from the release
dashboard: http://wiki.linaro.org/Cycles/1110/Release/Dashboard
--
David Zinman
Linaro Release Manager | Project Manager
Linaro.org | Open source software for ARM SoCs
Status report in detail
https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/WeeklyReport
Last meeting minutes:
https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Notes/2011-10-05
== Highlights ==
- Planning done for the 1110. Please check the status report link above
for details
- Upstreaming of Nux, compiz and unity should continue based on the plan
drafted at our meetings with Ubuntu and upstream maintainers. Compiz
core and plugins are already planned to be upstreamed. Nux branch which
*will* become Nux 2.0 (as part of "P") is now created and opengles work
from Travis is in line for merging. Unity also should be ok to merge,
with the agreement that the shadow effect of eg the panel will be
disabled on ARM. All the upstreaming activity also will not affect the
live Oneiric release.
- glmark2: continuing the work for 1110, with bug fixes (#842279 and
#851334 done) and starting to work on the bump-mapping with height map
benchmark
- glproxy - also started work on 1110 targets. Changing its build system
to waf, looking at bug https://bugs.launchpad.net/glproxy/+bug/855524
- UMM: dma-buf - documentation done, and revision 3 based on comments
from the list has been posted to linaro-mm-sig - patch is now ready to
post to larger lists, and to put to the test.
- Connect Hack sessions will include: 2 UMM sessions (possibly more
depending on the progress), 1 session to discuss launchpad among the
team, 1 session on the component releases for graphics
- Connect Demo: Unity 3d on panda - this is the minimum demo. RSalveti
will be adding the unity-gles packages (compiz{-plugins-main}, nux,
Unity) directly into the LEB, and the SGX packages into the hwpack for
pandaboard. So for the demo we will just need the 2011.10 Linaro release
(Ubuntu-desktop LEB + pandaboard hwpack) flashed on an sdcard. We are
also checking with Ubuntu Desktop to see if there is any extra set of
requirements - maybe we can work together for a demo of Unity on Oneiric.
- Discussed how to handle development series in LP projects
Best regards,
--
Ilias Biris ilias.biris(a)linaro.org
Project Manager, Linaro
M: +358504839608, IRC: ibiris Skype: ilias_biris
Linaro.org│ Open source software for ARM SoCs
Status report:
https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/WeeklyReport
Last meeting minutes are included as IRC logs in
https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Notes/2011-10-04
== Highlights ==
- 1110 Blueprints planned. See the status report (link above) for a
complete list. Still some headline/acceptance items are missing due to
holiday period last week for some
- Optimization: Started work on the libpng optimization (see blueprint
listed above)
- Optimization - LJT: ltj synced with upstream, work on the 565 patch,
rework of some upstream discussions on LJT lib startup
- Also on LJT: based on the thread started in -
http://lists.linaro.org/pipermail/linaro-dev/2011-October/007983.html
here are some further points
+ package libjpeg-turbo with v8 compatibility mode enabled: Quoting
from the thread: there is no benefit to v8. v7 added support for the
rarely/never used arithmetic coding option (arithmetic coding mode
defined in the JPEG spec), left out of earlier versions due to patent
issues. v8 only adds some experimental, non-standard coding options even
less relevant to any real-world uses. When *decoding* v8 actually
produces poorer results in some cases due to using dct-based upscaling
of chroma planes (this is also the cause of the slowdown).
+ benchmark on Android platform: blueprint addresses this
https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-benchm…
+ run tjbench as part of LAVA tests: this is not planned to be covered
during 11.10
- UMM: Added CMA support in rpmsg driver (syslink v3), it can give us
encoders for camera use case
- UMM: Working on dma-buf testing code, using scatterlist and aligning
with dma-buf v3, plus adding CMA support
- Benchmarking on DTS work ongoing - see thread (linaro-multimedia
threads:
http://lists.linaro.org/pipermail/linaro-multimedia/2011-September/000080.h…,
and
http://lists.linaro.org/pipermail/linaro-multimedia/2011-October/000094.html)
- Fixed some NEON functions in x264 (mru)
Also continuing to work on the requirements for next quarter -
discussion ongoing in the team taking also feedback from the rest of
Linaro. This list needs to be cleared a bit during the next few days:
-
https://linaro-public.papyrs.com/public/4157/MMWG2011-UCM-FOR-ANDROID/#
and also blueprint
https://blueprints.launchpad.net/linaro-multimedia-project/+spec/linaro-mmw…
- UMM - split discussed between Jesse Barker and Kurt Taylor. Some of
the MMedia folks will look into UMM work from the userspace point of
view in order to enable the usage of the UMM code on the various
platforms we have.
- Other requirements being looked at (missing though either blueprints
and/or requirements in papyrs at the moment)
+ Audio DTS decoding - could be tricky, involves legal aspects which
need to be carefully looked at, already done in libav?
+ Better video rendering integration in UI, like X11 proposal for
wayland, extended dri2
+ Compressed data sound support (as in
http://www.linuxplumbersconf.org/2011/ocw/proposals/633) - Note that
there's already an API from Intel which people are relatively happy with
+ Realvideo on ARM (popular in China) - needs optimization for 720p
playback, VGA is ok. Blueprint:
https://blueprints.launchpad.net/linaro-multimedia-project/+spec/linaro-mmw…
+ armv6 optimizations for vp8, and 10-bit h264 optimization, both in
libav - Blueprint:
https://blueprints.launchpad.net/linaro-multimedia-project/+spec/linaro-mmw…
+ Further enhancements and optimization for LJT - Blueprint:
https://blueprints.launchpad.net/linaro-multimedia-project/+spec/engr-multi…
+ 3D video stream
+ secure streaming (like netflix)
+ audio library optimization
+ Directfb NEON optimization - Blueprint
https://blueprints.launchpad.net/linaro-multimedia-project/+spec/engr-multi…
+ ALSA port of ST-E drivers
+ Audio testing will be handled as part of the more general
https://linaro.papyrs.com/page/4119/LINUX2011-ENABLEMENT-TESTING/#.
--
Ilias Biris ilias.biris(a)linaro.org
Project Manager, Linaro
M: +358504839608, IRC: ibiris Skype: ilias_biris
Linaro.org│ Open source software for ARM SoCs
Enclosed please find the link to the Weekly Status report
for the Toolchain working group for the week ending 2011-10-07
== Meeting Minutes ==
https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2011-10-03https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2011-10-06
== Weekly Status Report ==
https://wiki.linaro.org/WorkingGroups/ToolChain/Status/2011-10-06
== Summary ==
General:
* 64 bit atomics patch has had first round of review in GCC
* GDB: reviewing disabling address space randomisation support in gdbserver
* GDB: working on core file generation when using gdbserver
* Toolchain Panda auto builders are now running in the validation lab.
Thanks Dave!
Performance:
* Working on vectorising widening shifts
* Working on vectorising straight line (non-loop) code
* Working on cost estimation in SMS to detect regressions and disable when
likely
* Looking into improving -fsched-pressure. Tricky is the few new
regressions
* Optimising fixed to floating point conversion using VCVT
Binary toolchain:
* Decided on using crosstool-NG
* Requirements are ready
* Reviewing Windows build steps
* Prototyped up a layout
2011.10 Release:
* Next week is release week
* Launchpad branch scanning [LP: #808930] is still broken and causing pain
* No critical bugs
* Need to add headlines / acceptance criteria
Best regards,
Mounir
--
Mounir Bsaibes
Project Manager
Follow Linaro.org:
facebook.com/pages/Linaro/155974581091106http://twitter.com/#!/linaroorghttp://www.linaro.org/linaro-blog <http://www.linaro.org/linaro-blog>
Hi -
Recently at Linaro we've started a new tree
linaro-androidization-tracking, which is pretty much "common-3.1"[1] at
the moment on 3.1-rc8 basis.
http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=summary
We have already been running a kernel tree tracking Linus HEAD since
2.6.39, which has OMAP4 / Panda enablement stuff on top of Linus HEAD,
so we have some experience with the rough and tumble.
What we missed having was an "all year round" Androidization tree that
we could combine it with to casually create Android versions of the work
we were doing on Vanilla Linus HEAD basis. We used common-3.0 for that
for a while late in the kernel release cycle when it was tracking Linus
HEAD itself and that was great. But common-3.0 like the name suggests
is really a release tree, and it stops tracking at release, and a new
one starts up only late in the next kernel release cycle.
Actually, it would be a big advantage for many folks to not be doing
their Android kernel development on lagging releases, but by tracking
Linus HEAD. They would have access to latest stuff already and they
don't have to think about backport or later forwardport stuff to a new
release, it's constantly tracking HEAD and being adapted.
One side-effect of using this tracking methodology is if they want
release trees, they can just clone their tracking branch at the time
Linus HEAD is at a release point and bam, a hopefully fully working
release tree is there. Another very nice side-effect is they can do the
bulk of the work once on a Vanilla Linus HEAD basis, and get and Android
version of that work routinely by merging or rebasing in the
Androidization tree - instead of doing and validating work twice on
separate Vanilla and Android trees.
So linaro-androidization-tracking is our attempt at that Linus HEAD
Androidization tree, moving it on regularly and fixing breakage as it
happens throughout the cycle. It's generic same as common-, it should
be usable for any arch or board to Androidize a vanilla kernel that is
on the same Linus HEAD basis just by merge or rebase action.
It seemed this effort might be interesting for the guys that make the
common- trees, since if there was a tracking Androidization tree, in
fact common- releases for release trees like common-3.1 would just
naturally fall out of it when Linus HEAD was at 3.1. So I'd be very
happy to hear any opinions about that.
Another side-issue is we are also looking at refactoring the
Androidization patchset into topic branches, at the moment they're kind
of reflecting the history that they were applied on plus or minus some
munging around. So, all the net core patches for example would be
together in one series, then all the wireless ones in a series on top of
that, etc. It seems they would be easier to maintain then, opinions on
that approach are also welcome.
-Andy
[1] TI have a tree on omapzoom where we got the patches from
http://git.omapzoom.org/?p=kernel/omap.git;a=shortlog;h=refs/heads/p-androi…
--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106 -
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog