2011/7/25 Jim Huang <jserv(a)0xlab.org>:
[...]
> Recently, Kito Cheng (in Cc. list) is improving the support of Android
> prelink, and hopefully we would submit patches to AOSP soon.
It is pitty that we can not submit to AOSP still. However, the
patches are already public:
https://gitorious.org/+0xlab
Please check team activity during Oct 28 to Nov 6:
bionic/
GNU-style hash support for linker
build/
Update link script for gnu-sytle hash
Build library and executable with gnu-sytle hash table
GNU-sytle hash support for soslim
GNU-sytle hash support for apriori
Build with partial global prelink
Support partial global prelink for apriori
Build with prelinking executable
Support prelink executable with '-e/--prelink-executable' flag
Reorder DT_NEEDED entries in apriori
Build with incremental global prelink
Support incremental global prelink mode for apriori
external/elfcopy/
Basic GNU-sytle hash support for elfcopy
external/elfutil/
Add SHT_GNU_HASH, DT_GNU_HASH in libelf/elf.h
Sincerely,
Jim Huang (jserv)
http://0xlab.org/
Hello list,
Recently, we already released 0xbench version 1.1.5, and you can get
the latest binary/source here:
http://code.google.com/p/0xbench/downloads/listhttp://gitorious.org/0xbench
Changes since version 1.1.1:
- Add SunSpider JavaScript benchmark
- Allow customized result output path
- Support dashboard bundle format used in Linaro Automated Validation
Architecture
- Enable detailed report of libmicro and UnixBench
- Android 2.3+ build fixes
Also, you can install 0xbench on your Android devices through Android Market.
NOTE: due to the expiration of previous key for Android Market, we
have to rename the package and then upload to Marketplace again.
Therefore, the package namespace is now changed from
org.zeroxlab.benchmark to org.zeroxlab.zeroxbenchmark. We feel sorry
for inconvenience.
The next version will be 1.2.x, and glmark2 [*] is known to be part of
test cases.
Sincerely,
Jim Huang (jserv)
http://0xlab.org/
[*] https://launchpad.net/glmark2
2010/8/18 Jim Huang <jserv(a)0xlab.org>:
> Hello list,
>
> We are proud to announce the release of 0xBench, an open source
> Android benchmarking app developed by 0xlab.
>
> 0xBench comes with several built-in benchmarks, such as Linpack,
> Scimark2, and LibMicro. 0xBench itself could be extended as well.
> Developers can add their own benchmarks (either in native C or Java)
> to suit their needs. Please check the project page for details:
> http://code.google.com/p/0xbench/
>
> Documentation in Wiki: http://code.google.com/p/0xbench/w/list
>
> As usual, 0xBench GIT repository is hosted in Gitorious:
> http://gitorious.org/0xbench/
>
> 0xBench is now on the Android Market. If you wish to try it on your
> phone, please search for “0xBench” in the Market. In addition to
> 0xBench, we are also introducing a website called 0xBenchWeb, a simple
> web service that stores and visualizes your benchmarking results.
> After finish running benchmarks on your phone, you can choose to
> upload your results to 0xBenchWeb.
> http://0xbenchmark.appspot.com/
Hi All,
I was migrating changes from GB(K 2.6.35) to K 3.0 but every
time my PMEM allocation in board file leads to crash the kernel before
serial up. Now I am
taking CAF kernel as reference but the
change in MACHINE_START structure(addition of init_early) in CAF code is
working fine.Please
tell why it is crashing without init_early
which is not present in K 2.6.35 and it was working fine and also the
associated changes to this.
regards
sandeep
The sched_mc feature has been originally designed to improve power
consumption of multi-package system and several architecture functions
are available to tune the topology and the scheduler's parameters when
scheduler rebuilds the sched_domain hierarchy (change the
sched_mc_power_savings level). This patches series is a trial to
improve the power consumption of dual and quad cortex-A9 when the
sched_mc_power_savings is set to 2. The following patch's policy is to
accept up to 4 threads (can be configured) in the run queue of a core
before starting to load balance if cpu runs at low frequencies but to
accept only 1 thread for high frequencies, which is the normal
behaviour. The goal is to use only one cpu in light load situation and
both cpu in heavy load situation
Patches [1-3] modify the ARM cpu topology according to
sched_mc_power_savings value and Cortex id
Patch [4] enables ARCH_POWER feature of the scheduler
Patch [5] adds ARCH_POWER function for ARM platform
Patches [6-7] modify the cpu_power of CA-9 according to
sched_mc_power_savings' level and current frequency. The main goal is
to increase the capacity of a core when using low cpu frequency in
order to pull tasks on this core. Note that this behaviour is not
really advised but it can be seen as an intermediate step between the
use of cpu hotplug (which is not a power saving feature) and a new
load balancer which will take into account low load situation on dual
core.
Patch [8] ensures that cpu0 is used in priority when only one CPU is running
Patch [9] adds some debugfs interface for test purpose
Patch [10] ensures that the cpu_power will be update periodically
Patch [11] fixes an issue around the trigger of ilb.
TODO list:
-remove useless start of ilb when the core has capacity.
-add a method (DT, sysfs, ...) to set threshold for using 1 or 2 cpus
for dual CA-9
-irq balancing
The tests hereafter have been done on a u8500 with kernel linaro-3.1.
They check that there is no obvious lost of performance when
sched_mc=2.
sysbench --test=cpu --num-threads=12 --max-time=20 run
Test execution summary: sched_mc=0 sched_mc=2 cpu hotplug
total number of events: 665 664
336
per-request statistics:
min: 92.68ms 70.53ms 618.89ms
avg: 361.75ms 361.38ms 725.29ms
max: 421.08ms 420.73ms 840.74ms
approx. 95 percentile: 402.28ms 390.53ms 760.17ms
sysbench --test=threads --thread-locks=9 --num-threads=12 --max-time=20 run
Test execution summary: sched_mc=0 sched_mc=2 cpu hotplug
total number of events: 10000 10000 3129
per-request statistics:
min: 1.62ms 1.70ms
13.16ms
avg: 22.23ms 21.87ms
76.77ms
max: 153.52ms 133.99ms 173.82ms
approx. 95 percentile: 54.12ms 52.65ms 136.32ms
sysbench --test=threads --thread-locks=2 --num-threads=3 --max-time=20 run
Test execution summary: sched_mc=0 sched_mc=2 cpu hotplug
total number of events: 10000 10000 10000
per-request statistics:
min: 1.38ms 1.38ms
5.70ms
avg: 4.67ms 5.37ms
11.85ms
max: 36.84ms 32.42ms 32.58ms
approx. 95 percentile: 14.34ms 12.89ms 21.30ms
cyclictest -q -t -D 20
Only one cpu is used during this test when sched_mc=2 whereas both cpu
are used when sched_mc=0
Test execution summary: sched_mc=0 sched_mc=2 cpu hotplug
Avg, Max: 15, 434 19, 2145 17, 3556
Avg, Max: 14, 104 19, 1686 17, 3593
Regards,
Vincent
Hi,
Snowball V2 boards are no longer supported. Daily builds are now disabled.
Linaro engineers, please go through your support channels for a
replacement board.
Cheers,
--
Fathi Boudra
Linaro Release Manager | Validation Project Manager
Linaro.org | Open source software for ARM SoCs
Greetings,
Here is the post-mortem and lessons learned review for Linaro release 11.10.
Thanks to the teams who have contributed to this.
====================
Release Review 11.10
====================
Android
=======
Highlights
* Gerrit CI was well tested when deployed.
* Making test results visible created quality awareness across the
organization.
Issues
* Infrastructure capacity (git server) was inadequate and affected developer
performance.
* The one-month cycle leaves no room for events like Connect and ELC-E.
* Heavy reliance on landing teams as most issues are theirs.
* Bugs fixed in Developer are marked fixed even if not working on Android.
* Landing teams seem to get too little support from member company developers.
* The manual test frenzy at release time should be reduced or better shared.
* Engineers that also have interrupt type duties struggle with Milestone
delivery accuracy.
* Daily test errors did not get immediate attention.
Developer Platform
==================
Highlights
* Successful release on Oneiric ahead of schedule
* CI on packaged kernels working
* Communications need to be examined
* John released U-Boot in time! That's great and keep up :)
* Release process went fairly well
Issues
* Blueprints were not updated very well.
* Launchpad issues blocked many blueprints
* builders in LP were blocking some blueprints
* Offspring and LP related issues take time to resolve
* Lauchpad: to many bugs on derived distro support
* testing was not done well on the LP side
* Issues with the WGs: some did not release on time
* communications were not smooth or even non-existent
* transparency of plans is the problem; platform teams need to be aligned
about plans
* Unity tree not available on time, released only on Friday
* Once tested, it did not work on Panda - it seems that Unity is not tested
on Panda
* The working group should continuously push to public
* lack of communication and support for hardware problems
* LAVA interface very slow - needs rework
* requires better error reporting of the LAVA web service (error on job
submission with wrong hardware pack)
* Need better navigation of job from build to result in the dashboard UI
* Linux-linaro quality isn't really good (no strict tracking of features etc.)
* device tree is missing regularly.
* Test cases should be provided well in advance of testing
* Test cases in spreadsheet are vague, some not valid to test
Lessons Learned
* set up a point of contact with working groups for any issues during the
release.
* establish a best-practice process for the graphics group to continuously
push to public
* tests could have been better defined; next step is developing it.
Kernel
======
Highlights
* Pinctrl core and pinmux are now in linux-next. currently, answering late
review comments and merging smaller patches.
* Continued to implement Device Tree support for Linaro member platforms,
focusing on changes to drivers and subsystems inlcuding IRQ controllers,
GPIO, serial devices, MMC devices, and regulators across various SOCs. All
i.MX basic drivers are ready, audio and usb are still big missing pieces.
* omap-hsmmc dt conversion completed. Prepared single device tree enabled
board file for smdkv310 and Origen boards and tested device tree support for
the following modules: UART, SDHCI, Keypad, GPIO keys, DMA, RTC, I2C, WDT,
GPIO, IRQ.
* Continued with SoC Tree maintenance, code review, merging and verifying
patches.
* Continued work on fixes and changes to the config fragment merge_config.sh
script, resubmitted merge_config.sh script to lkml.
* Continued the cleanup and consolidation of various kernel headers that will
allow for building of a single kernel across multiple SOCs the work
included: patches to rework the low level UART debugging code on OMAP1,
OMAP2 and Davinci, patches for mach/memory.h removal, patches for appending
of a device tree binary to the kernel zImage and patches for removing all
instances of mach/vmalloc.h.
Multimedia
==========
Highlights
* There was a speedy reaction to get headlines andacceptance defined faster.
Teams had those in place (90% of the BPs) by the deadline.
* Managed to move ahead with some of the issues we have been facing eg Unity
upstreaming in GFX.
Issues
* Quite a few blueprints did not complete. This can be attributed to a few
possible reasons:
* work was larger than initially thought
* assignee was distracted to other activities
* trees needed to be more carefully constructed at times to avoid mistakes
from being based on old versions of upstream
* assignee not "gardening" blueprints diligently
* Sometimes the work is done but the blueprint doesn't reflect the reality
General lessons learned
* Maintain a tree always available. If tree is broken we should have a good
idea when it will be available again.
* Always work on the tip and fix things as they appear - that is easier said
than done for some projects. So we check the cases one by one on the
projects involved
* Raise the risk flag early: kudos to those of you who did so this month.
Perhaps an improvement next would be to try and anticipate the risk with
each work item rather than on the blueprint level.
* Even if you think that the release is not worth the effort, for example an
optimization in performance did not show up, it is always good to make the
release if you have patches which do not break the component. You will get
more eyeballs looking at the components this way maybe that will help
unearth other issues or suggest new ideas.
Power Management
================
Highlights
* Thermal management is working on Samsumg platform. However, the code is not
pushed to mainline yet.
* OMAP Thermal management integrated and delivered to TI. But, still under
testing and not completely working.
* PM QA testsuite now includes tests for hotplug integrated with LAVA,
studying LAVA test runs for accuracy.
Issues
Toolchain
=========
Highlights
* Released Linaro GDB 7.3 11.10
* Released Linaro GCC 4.6 2011.10 and Linaro GCC 4.5 2011.10
* Released Linaro QEMU 2011.10
Issues
Validation
==========
Highlights
* Initial release of bundle format documentation * Ability to display reports
on the front page.
Issues
* Oneiric complicated packaging, weakened testing and development focus.
Infrastructure
==============
Highlights
* Released linaro-image-tools 2011.10
* Didn't have to keep up with board changes due to hwpacks v2, already a
success for that project.
Issues
* Had to change to cope with a breaking change in the format of rootfs created
by live-build. We should add metadata to the rootfs to avoid this problem in
future. Session registered at Connect to discuss it.
https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-p-ima…
Lessons Learned
Headlines
* Headlines assumptions did not come true
* To be ahead of the curb, in the PMWG, we created the monthly headline one
week ahead of time
* Not all headlines completed
* wait until after the release to do the headline
Quality
* Quality status not known at all times
* Important to ensure quality awareness across the organization
* Less quality focus
* Document what we test and then keep testing it
Blueprints
* Blueprints do not reflect reality
* Invalid functionality
* Work in small chunks on the days up to the release. Plan to release early
and often as work items are done. Do not wait to have some mad dash in the
hours before the release
--
David Zinman
Linaro Release Manager | Project Manager
Linaro.org | Open source software for ARM SoCs
Hi, Linaro guys
I'm using Origenboard, and your ubuntu LEB helps a lot.
Now, I need to patch the kernel, but I can't find the guide for building image from source code.
Could you help me?
Thanks!
Sen.
Hi,
The attached test intermittently fails on my panda running the 11.09
(3.0.0-1404-linaro-lt-omap) kernel;
but it works on guinep and Michael's ursa and pavo running much older
kernels; I'd appreciate it if
people could try it on whatever machine with whatever kernel they
have and report the result to me
so I can try and nail down what it fails on. (It fails in both natty
and oneiric chroots for me)
To compile:
gcc pthreadtest.c -o pthreadtest -lpthread
To run:
for SEQ in `seq 1 1000`
do
./pthreadtest
done
if it finishes then its fine, for me it'll fail sooner or later with:
Start thread test 0x110dc 0x110dc
and just stop.
(It sits there in a futex inside pthread_cond_wait on cond_wait's
internal structure)
Dave
