linaro-dev October 2011

linaro-dev@lists.linaro.org

107 participants
156 discussions

iPhone 4S Preliminary Benchmarks - Very impressive

by Eric Miao

http://www.anandtech.com/show/4951/iphone-4s-preliminary-benchmarks-800mhz-a Apple's hardware doesn't look like to have very high spec, however, the results are a bit impressive, does that necessarily mean there is a big gap in software optimization? - eric

14 years

Proposal of tagging rules for Freescale bugs

by Eric Miao

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

14 years

[ACTIVITY] OCTO status report - wk40 (20111003-20111007)

by Ilias Biris

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

14 years

linaro-android-media-create --dev mx53loco for i.MX53 boards

by Fathi Boudra

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

14 years

Process - How to release Linaro components

by Fathi Boudra

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

14 years

[REMINDER] Linaro 11.10 release dates and deliveries

by David Zinman

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

14 years

[ACTIVITY] Graphics WG weekly status report - wk40.2011 (20111003-20111007)

by Ilias Biris

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

14 years

[ACTIVITY] MMWG - weekly status report - wk40.2011 (20111003-20111007)

by Ilias Biris

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

14 years

[Activity] Toolchain WG Weekly Status report for week ending 2011-10-07

by Mounir Bsaibes

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-03 https://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/155974581091106 http://twitter.com/#!/linaroorg http://www.linaro.org/linaro-blog <http://www.linaro.org/linaro-blog>

14 years

Linaro and common- tree

by Andy Green

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

14 years

← Newer
1
...
9
10
11
12
13
14
15
16
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev October 2011