Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org>
---
Makefile | 2 +-
clocks.c | 62 +-------------------------------------------------------------
utils.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
utils.h | 22 ++++++++++++++++++++++
4 files changed, 79 insertions(+), 62 deletions(-)
create mode 100644 utils.c
create mode 100644 utils.h
diff --git a/Makefile b/Makefile
index d88b8ff..1a53121 100644
--- a/Makefile
+++ b/Makefile
@@ -4,7 +4,7 @@ MANDIR=/usr/share/man/man8
CFLAGS?=-O1 -g -Wall -Wshadow
CC?=gcc
-OBJS = powerdebug.o sensor.o clocks.o regulator.o display.o tree.o
+OBJS = powerdebug.o sensor.o clocks.o regulator.o display.o tree.o utils.o
default: powerdebug
diff --git a/clocks.c b/clocks.c
index 603ebe4..4d78910 100644
--- a/clocks.c
+++ b/clocks.c
@@ -28,6 +28,7 @@
#include "powerdebug.h"
#include "clocks.h"
#include "tree.h"
+#include "utils.h"
struct clock_info {
int flags;
@@ -75,67 +76,6 @@ static struct clock_info *clock_alloc(void)
return ci;
}
-/*
- * This functions is a helper to read a specific file content and store
- * the content inside a variable pointer passed as parameter, the format
- * parameter gives the variable type to be read from the file.
- *
- * @path : directory path containing the file
- * @name : name of the file to be read
- * @format : the format of the format
- * @value : a pointer to a variable to store the content of the file
- * Returns 0 on success, -1 otherwise
- */
-int file_read_value(const char *path, const char *name,
- const char *format, void *value)
-{
- FILE *file;
- char *rpath;
- int ret;
-
- ret = asprintf(&rpath, "%s/%s", path, name);
- if (ret < 0)
- return ret;
-
- file = fopen(rpath, "r");
- if (!file) {
- ret = -1;
- goto out_free;
- }
-
- ret = fscanf(file, format, value) == EOF ? -1 : 0;
-
- fclose(file);
-out_free:
- free(rpath);
- return ret;
-}
-
-static int file_read_from_format(const char *file, int *value,
- const char *format)
-{
- FILE *f;
- int ret;
-
- f = fopen(file, "r");
- if (!f)
- return -1;
- ret = fscanf(f, format, value);
- fclose(f);
-
- return !ret ? -1 : 0;
-}
-
-static inline int file_read_int(const char *file, int *value)
-{
- return file_read_from_format(file, value, "%d");
-}
-
-static inline int file_read_hex(const char *file, int *value)
-{
- return file_read_from_format(file, value, "%x");
-}
-
static inline const char *clock_rate(int *rate)
{
int r;
diff --git a/utils.c b/utils.c
new file mode 100644
index 0000000..e47c58e
--- /dev/null
+++ b/utils.c
@@ -0,0 +1,55 @@
+/*******************************************************************************
+ * Copyright (C) 2011, Linaro Limited.
+ *
+ * This file is part of PowerDebug.
+ *
+ * All rights reserved. This program and the accompanying materials
+ * are made available under the terms of the Eclipse Public License v1.0
+ * which accompanies this distribution, and is available at
+ * http://www.eclipse.org/legal/epl-v10.html
+ *
+ * Contributors:
+ * Daniel Lezcano <daniel.lezcano(a)linaro.org> (IBM Corporation)
+ * - initial API and implementation
+ *******************************************************************************/
+
+#define _GNU_SOURCE
+#include <stdio.h>
+#undef _GNU_SOURCE
+#include <stdlib.h>
+
+/*
+ * This functions is a helper to read a specific file content and store
+ * the content inside a variable pointer passed as parameter, the format
+ * parameter gives the variable type to be read from the file.
+ *
+ * @path : directory path containing the file
+ * @name : name of the file to be read
+ * @format : the format of the format
+ * @value : a pointer to a variable to store the content of the file
+ * Returns 0 on success, -1 otherwise
+ */
+int file_read_value(const char *path, const char *name,
+ const char *format, void *value)
+{
+ FILE *file;
+ char *rpath;
+ int ret;
+
+ ret = asprintf(&rpath, "%s/%s", path, name);
+ if (ret < 0)
+ return ret;
+
+ file = fopen(rpath, "r");
+ if (!file) {
+ ret = -1;
+ goto out_free;
+ }
+
+ ret = fscanf(file, format, value) == EOF ? -1 : 0;
+
+ fclose(file);
+out_free:
+ free(rpath);
+ return ret;
+}
diff --git a/utils.h b/utils.h
new file mode 100644
index 0000000..d4ac65a
--- /dev/null
+++ b/utils.h
@@ -0,0 +1,22 @@
+/*******************************************************************************
+ * Copyright (C) 2011, Linaro Limited.
+ *
+ * This file is part of PowerDebug.
+ *
+ * All rights reserved. This program and the accompanying materials
+ * are made available under the terms of the Eclipse Public License v1.0
+ * which accompanies this distribution, and is available at
+ * http://www.eclipse.org/legal/epl-v10.html
+ *
+ * Contributors:
+ * Daniel Lezcano <daniel.lezcano(a)linaro.org> (IBM Corporation)
+ * - initial API and implementation
+ *******************************************************************************/
+#ifndef __UTILS_H
+#define __UTILS_H
+
+extern int file_read_value(const char *path, const char *name,
+ const char *format, void *value);
+
+
+#endif
--
1.7.1
Hello,
This is my first attempt with the Linaro kernel build and I am having no
success in getting it build.
My aim is to get a kernel debian package build using the upstream changes.
I am following the instructions given at
https://wiki.linaro.org/Resources/HowTo/PackageYourOwnKernel.
I get quite a number of errors. I have attached one of them to the mail as
well.
Can someone let me know if this is the right wiki to follow the upstream
kernel packaging? Also, I dont find the arch/arm/configs/omap3_defconfig
configuration file shown in one of the steps.
Can I know how to get the same?
Is there a different approach to get the kernel debian package ?
Thanks in advance!!!
Regards,
Deepti.
Hi,
I am trying to run panda android leb using the instructions given on
wiki. Seeing a crash while formatting the SDcard using lmc. Below are
the crash logs, seems like a known issue. Any pointers on what needs to
be fixed?
Are you 100% sure, on selecting [/dev/sdc] (y/n)? y
Checking that no-one is using this disk right now ...
OK
Warning: bad partition start (earliest 1318913)
Warning: partition 1 does not end at a cylinder boundary
If you created or changed a DOS partition, /dev/foo7, say, then use
dd(1)
to zero the first 512 bytes: dd if=/dev/zero of=/dev/foo7 bs=512
count=1
(See fdisk(8).)
Traceback (most recent call last):
File "./linaro-image-tools-0.4.8/linaro-android-media-create", line
141, in <module>
args.should_align_boot_part)
File
"/play/linaro-android-leb/linaro-image-tools-0.4.8/linaro_image_tools/media_create/partitions.py", line 54, in setup_android_partitions
get_android_partitions_for_media (media, board_config)
File
"/play/linaro-android-leb/linaro-image-tools-0.4.8/linaro_image_tools/media_create/partitions.py", line 267, in get_android_partitions_for_media
media.path, 1 + board_config.mmc_part_offset)
File
"/play/linaro-android-leb/linaro-image-tools-0.4.8/linaro_image_tools/media_create/partitions.py", line 312, in _get_device_file_for_partition_number
device_path = _get_udisks_device_path(dev_file)
File
"/play/linaro-android-leb/linaro-image-tools-0.4.8/linaro_image_tools/media_create/partitions.py", line 327, in _get_udisks_device_path
return udisks.get_dbus_method('FindDeviceByDeviceFile')(device)
File "/usr/lib/pymodules/python2.6/dbus/proxies.py", line 68, in
__call__
return self._proxy_method(*args, **keywords)
File "/usr/lib/pymodules/python2.6/dbus/proxies.py", line 140, in
__call__
**keywords)
File "/usr/lib/pymodules/python2.6/dbus/connection.py", line 620, in
call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.UDisks.Error.Failed: No
such device
--
Thanks
Amit Mahajan
Hello.
Over the past two weeks I've been prototyping a new tool for managing
releases of Linaro validation deliverables. Some of the problems are
unique (we target older releases, we are upstream) some are shared
(building lots of packages together, making sure they all work,
reproducing builds).
TLDR; Skip to the bottom of the message where I list the features.
I had some prior experience in this task and I wanted to see how the old
solutions would map to the new environment. As we target Ubuntu Lucid
aka latest LTS and most of us develop on the latest Ubuntu I wanted to
ensure that all of our releases can be installed and would work
correctly on Lucid. Earlier in the cycle we decided that the delivery
method would be a PPA with multiple .debs, some of which may be
backports required for Lucid. This is unlike using pip to pull in all
the things we are interested in from various places (possibly using a
requirements file).
So having those requirements my goals were to build a tool that would be
useful for those two tasks:
1) Daily development helper as a sort of CI tool.
2) Monthly release helper
Both tasks have different requirements but involve similar actions.
Those actions are:
*) Figuring out what packages to work on (aka project definition)
*) Getting the appropriate source/revision/tag from launchpad
*) Building a source packages for the target distribution
*) Building a binary package in pbuilder
- this is where we also run all the unit tests that tells us if
something is broken.
The tricky part is where we need to build test and release *multiple*
source packages from *multiple* branches and target *multiple* target
distributions.
For some concrete example. LAVA today is composed of the following core
packages:
- lava-server
- lava-dashboard
- lava-scheduler
- lava-dispatcher
- lava-tool
- lava-test (-tool)
- lava-dashboard-tool
- lava-scheduler-tool (upcoming)
We also have a set of support libraries:
- versiontools
- linaro-django-xmlrpc
- linaro-django-pagination
- linaro-dashboard-bundle
- django-restricted-resource
- django-debian
- linaro-json
We also have some libraries that are required for testing:
- python-django-testproject
- python-django-testscenarios
- python-django-testinvariants (upcoming)
We also have some backports (for both production and testing):
- python-simplejson
- python-django 1.2 (soon 1.3)
- python-django-south
- python-testtools
- python-testscenarios
- python-fixtures
Now that's a lot of stuff to build and release manually. Granted not
everything is changing but at the very least the first group (lava-*)
will see a lot of activity each month.
Now the way I see it, each month, this list needs to be released.
Possibly some of them will be unchanged. In that case there is no need
to actually upload new packages to a PPA. Still we need to ensure that
all of them build and work on all Lucid, Maverick and so on, all up to
the latest version of Ubuntu.
Since we want to build Debian packages I decided to use bzr builder to
create source packages from a recipe files. Recipes are a simple (2-3
lines at most) text files that say how to assemble source branches to
get Debian packaging. The key feature of builder is it's ability to
create derivative packages for a particular distribution. Recipe files
are also used by launchpad for building source packages. In the future
this tool could actually push/pull the recipes to launchpad directly.
To build binary packages I used pbuilder. The configuration is a little
more complex than simple raw pbuilder or pbuilder-dist. The
configuration I made turns it into a ppa-like builder that can feed from
it's own packages. Each time you build a package it will land in a small
apt repository and can be used to feed another build. This is a critical
feature as all of our packages depend on something not available in the
main archive.
The trick is to know the right sequence of builds that would satisfy
build-dependencies. I did not find any existing tool to do this and
after a brief discussion with doko it seems there are no such tools
available. In general the problem can be simplified to a subset of real
dependencies (without conflicts, virtual packages and stuff like that)
and resolved automatically. I did not want implement that as our package
list can be managed manually. A special sequence file contains a list of
"things" to build, in order, to satisfy dependencies.
So getting everything together, lava-ci does the following:
* FEATURES *
$ ./lava-ci project help
Usage: lava-ci project [COMMAND]
Summary: Manipulate and release your project
Available commands:
- init - Prepare lava-ci to work with a particular project
- help - This message (default)
$ ./lava-ci distro help
Usage: lava-ci distro [COMMAND]
Summary: Manipulate pbuilder environments
Available commands:
- help - This message
- show - Display list of distributions and their status (default)
- enable - Enable one or more distributions
- disable - Disable one or more distributions
- update - Update one or more distributions
$ ./lava-ci package help
Usage: lava-ci package [COMMAND]
Summary: Manipulate source and binary packages
Available commands:
- srcpkg - Create a source package from a recipe
- help - This message
- show - Display list of packages and their status (default)
- wipe - Remove all source and binary packages
- sequence - Build a sequence of packages following
- binpkg - Create binary packages from a source package
A subset of the README file:
lava-ci - CI and release tools for the LAVA project (and others).
The purpose of this tool is to facilitate teamwork and monthly releases by
automating the act of creating and testing a release from source
repositories
all the way to the binary packages for various platforms.
Workflow example:
*) Prepare recipe files (bzr help builder) for each maintained source
package and put them in a bzr repository. Each recipe file *MUST* be
named like the source package it builds.
*) Use `lava-ci project init lp:BRANCH-WITH-RECIPES`. This will create
.lava-ci directory and a local checkout of you recipes in the
current directory.
*) Use `lava-ci distro` to list the distributions you wish to target.
For each one you are interested in do `lava-ci distro enable
$distro`. For example to enable lucid and maverick you could use
`lava-ci distro enable lucid maverick`.
*) Use `lava-ci package` to list available "packages" (based on
recipes). You can add/edit more just by creating additional
*.recipe files.
*) Use `lava-ci package src $package` to build source packages for
the selected recipe. There will be one source package per
distribution. You can check `lava-ci package [show]` to see what
source packages are already available.
*) Use `lava-ci package bin $package` to build binary packages for
the selected recipe. Again there will be multiple builds, one for
each distribution. Each build will result with a number of
additional debian packages being produced. You can use those
packages as build-dependencies of other packages you maintain,
similar to a Lauchpad PPA.
*) Write down a sequence of build operations to perform in and save it
as `recipe/sequence`. This file should contain one word per line
- the name of the source package to build. The order will depend on
the build-dependencies among your packages. To test that building
the whole sequence works do `lava-ci package wipe` followed by
`lava-ci package sequence`. If the build succeeds you can tag your
recipes as a working configuration and make a release.
Best regards
Zygmunt Krynicki
Hi,
I spent some more time today fixing IRC channels and it prompted me to
write-up a wiki page on how to create channels, including the specific
commands.
https://wiki.linaro.org/GettingInvolved/IRC/channelsetup
Team Leads in particular, please have a look and make sure it's understandable.
Thanks,
Joey
I just read Fathi's email about the new bots. I didn't want to hijack the
existing thread, but I have been considering setting up a new official
Linaro irc channel #linaro-multimedia with the meeting bot, etc.
As per discussions with Ilias, I would also like to set up a new service, an
IRC proxy (bip or ?) for all the multimedia team members. A stored
scrollback log might fix timezone problems we have. Would this proxy be
something that we could host on a Linaro server?
I am fully aware that we are trying to prevent "walled-gardens", but I
believe we have a very valid case why we need an irc channel specific to
multimedia. We have tried maillists and they have not worked. We would use
this channel for technical discussions across timezones, a quick access to a
multithreaded store and forward conversation with a log. We would also be
able to use this channel for meetings when the main linaro-meeting channel
was already being used, hence the need for the meeting bot. We would still
use the #linaro channel whenever possible.
These are all exploratory ideas at this point. I copied the -dev list so I
could get some feedback - Comments? Suggestions?
--
Kurt Taylor (irc krtaylor)
Linaro Multimedia Team Lead
Hi fellow ARM fans,
Linaro Developer Platform team organises every week (Wednesday 14:00 -
18:00 UTC) an ARM porting Jam. The idea is to gather all developers together to
fix userspace portability issues across the board. The list of bugs
being worked on is at launchpad:
https://bugs.launchpad.net/ubuntu/+bugs?field.tag=arm-porting-queue&orderby…
Interested in making the software in Ubuntu run better on ARM? Join us on
the #linaro channel on irc.linaro.org today!
Cheers,
Riku
I'd like to thank everyone who attended the Linaro multimedia work group
mini-summit last week, especially on such short notice. It was great to get
to meet everyone face-to-face. I think we made excellent progress on the
technical challenges for the MMWG team for the next cycle.
I have attached a consolidated and partially formatted log of the minutes
and actions from the meeting. I think they are fairly complete, please let
me know if there is anything missed that needs to be mentioned. You can also
access the individual logs from the event agenda:
http://wiki.linaro.org/Events/2011-06-MMWG
We will be working the actions of this meeting and may be contacting you for
assistance. The resulting plan will be initially reviewed at the public plan
review: http://wiki.linaro.org/Cycles/1111/PublicPlanReview
The next time we will meet to fully discuss MMWG work topics will be at the
Linaro Developer Summit at Orlando, a part of the Ubuntu Developer Summit.
Please join us if you can. More information on LDS/UDS is available here:
http://uds.ubuntu.com/ I hope to see you there!
Regards,
--
Kurt Taylor (irc krtaylor)
Linaro Multimedia Team Lead
I've been holding this back a bit as I was hoping the omap4 hdmi issue
would get resolved upstream in Nico's tree first, but with the month
half over, this needs to go out.
Anyway, the 2.6.39 based branch of the linaro-android tree is now
available:
http://git.linaro.org/gitweb?p=people/jstultz/android.git;a=shortlog;h=refs…
This tree includes Nico's 2.6.39 based tree plus the following:
o The current Android common kernel 2.6.39 branch
o android_omap3_defconfig and android_omap4_defconfig files
o The test_power driver improvements (which replaces the virtual battery
driver - already upstream in 3.0-rc1)
o Kconfig hack to fix OMAP2 DPI build issue (already sent to Nico)
Known regressions:
o OMAP4 HDMI support is broken upstream in Nico's tree.
Please let me know if you find any other issues.
thanks
-john