Hi,
According to the 11.05 release schedule [1] the Linaro Alpha-1 release
will be made next
Thursday. To help prepare and test the images developers are asked to
refrain from
uploading changes to the archive from Tuesday 30th November until Thursday 2nd
December.
>From Tuesday onwards the release candidate image for Alpha-1 will be
selected and
available for testing. The Linaro QA tracking tool [2] will be
available for submission of results
at the same time so please test, submit your results and report bugs
either in the project
the bug occurs or if in doubt, to the Linaro project at
http://bugs.launchpad.net/linaro.
For more information on the Linaro 11.05 release please see the wiki page at:
http://wiki.linaro.org/Releases/1105/
Regards,
Jamie.
--
Linaro Release Manager
[1] http://wiki.linaro.org/Releases/1105/Schedule
[2] http://qatracker.linaro.org
All,
The weekly report for the Linaro Infrastructure team may be found at:-
Status report: https://wiki.linaro.org/Platform/Infrastructure/Status/2010-11-25
Burndown chart: This link is awaiting the production of new burndown charts.
The Infrastructure related blueprints from the maverick cycle, of which currently there are 4 active ones (4 from the last report), are showing that there are 8 work items in progress (8 last report), and 11 work items to undertake (11 last report). These are to be moved into the natty cycle if still required.
arm-m-validation-dashboard; 0 work items completed since last report; 3 in progress; 7 to do
arm-m-image-building-console; 0 work items completed since last report; 3 in progress; 3 to do
arm-m-automated-testing-framework; no change in status from last report; 1 in progress; 0 to do
arm-m-testsuites-and-profilers; no change in status from last report; 1 in progress; 1 to do
In the natty cycle, the following lists the current active Blueprints, or Blueprints planned and not started:-
other-linaro-n-improve-linaro-media-create: 2 work items completed; 4 work items in progress; 7 work items to do.
other-linaro-n-test-result-display-in-launch-control: 1 work item completed; 1 work item in progress; 14 work items to do
other-linaro-n-patch-tracking: 1 work item completed; 2 work items in progress; 9 work items to do
other-linaro-n-image-building: 7 work items to do.
other-linaro-n-continuous-integration: Not started - awaiting a Hudson build server (RT#42278).
other-linaro-n-package-development-tools: Not Started; 9 work items to do
Specifics accomplished this week include:-
* ImproveLinaroMediaCreate: Two work items completed - porting of the create_boot_cmd and planning to ensure new python functions are accessible to the system LinaroMediaCreate.
* ImageBuilding: The initial branch of "Multiple hwpacks" is in review.
* TestResultTracking: Work has been ongoing for the pre-requisites for this development and a demonstration report seems to work well under engineer test. Code reviews should start shortly.
Please let me know if you have any comments or questions.
Kind Regards,
Ian
Hi there,
In power management group, we have a working item of exposing thermal
information to user space through sysfs. However, so far, the thermal
sensor drivers under 'drivers/hwmon' expose their information in
various nodes under sysfs, which makes information collection
difficult.
Intel's thermal framework is located under 'drivers/thermal', but all
the thermal drivers under hwmon don't make use of it due to some
reason (part of the reason for this situation may be that intel's
thermal framework is comparatively new therefore when those sensor
drivers were implemented they did not have a framework to register
themselves.)
We like to find out a simple and unified way to expose thermal related
information, intel's thermal interface could be a choice. Using
thermal framework is straightforward, below is a sample driver for
this purpose. Thus all the information goes to /sys/class/thermal,
like temperature, mode...
...
#include <linux/module.h>
#include <linux/device.h>
#include <linux/thermal.h>
#include <linux/hwmon.h>
static int thermal_get_temp(struct thermal_zone_device *thermal,
unsigned long *temp)
{
*temp = xxx;
return 0;
}
static struct device *hwmon;
static struct thermal_zone_device *thermal;
static struct thermal_zone_device_ops ops = {
.get_temp = thermal_get_temp,
};
static int __init sensor_init(void)
{
...
thermal = thermal_zone_device_register("sample", 0, 0,
&ops, 0, 0, 0, 0);
}
static void __exit sensor_cleanup(void)
{
...
}
module_init(sensor_init);
module_exit(sensor_cleanup);
Are there any better ideas about this? Your comments are highly appreciated.
Yong
On 11/24/2010 09:30 PM, kan hu wrote:
> Blueprint changed by kan hu:
> +
Looks like these work are related to toolchain. Here are some my cents,
> + GDB and Oprofiler on Cortex a9(required for profiling or look for a workaround) : TODO
> +
We plan to improve the correctness of GDB and Oprofile on cortex-a9. If
you find bugs on them, please file tickets in launchpad, and we can have
a look.
> + Check FFMpeg test application or write a new one to measure performance: TODO
> + Select contents with different parameter setting for using measure performance. TODO
> + Check current performance result and find a reasonable target performance: TODO
Speed performance improvement is one of our task also. Feedback on GCC
performance on cortex-a9 are welcome.
> + Measure and record performance increased by NEON optimize method: TODO
Recent Linaro GCC release includes some NEON improvements. This may be
helpful to this task.
Hi there,
Scott James Remnant, author of the upstart boot daemon, will be
doing a tech talk on it today at 16:30 UTC; it will be streamed live at:
http://www.ustream.tv/channel/upstart-tech-talk
Upstart has an interesting architecture, and Scott's a pretty engaging
character, so I think it's worth watching if you have that hour free.
See you there!
--
Christian Robottom Reis | [+55] 16 9112 6430 | http://launchpad.net/~kiko
Linaro Engineering VP | [ +1] 612 216 4935 | http://async.com.br/~kiko