linaro-dev August 2011

linaro-dev@lists.linaro.org

126 participants
239 discussions

Erro "make: *** /lib/modules/2.6.38-1003-linaro-omap/build: No such file or directory."

by Juan Gao

Dear Linaro team, I have a problem when I try to make a module. To make the module file xx.c, I have the following command line in my Makefile: make -C /lib/modules/$(shell uname -r)/build M=$(pwd) modules an error occured: make: *** /lib/modules/2.6.38-1003-linaro-omap/build: No such file or directory. I looked up the /lib/modules/ folder, there are two sub folders: /lib/modules/2.6.38-1003-linaro-omap /lib/modules/2.6.38-1208-omap4 Under /lib/modules/2.6.38-1003-linaro-omap, there is not a 'build' folder, but under /lib/modules/2.6.38-1208-omap4, there is the 'build' folder that is needed for building the modules. Please could you kindly let me know why this happens, and how to resolve this issue? Many thanks, Juan ------------------------------------------------------------------ Juan Gao Software Applications Engineer--Compiler tools UK Support Team: +44(0)1223 400600 ARM Ltd. US Support Team: +1 512 381 2928 110 Fulbourn Road Direct Dial: +44(0)1223 406988 Cambridge CB1 9NJ Fax: +44(0)1223 400410 England E-Mail: Juan.Gao(a)arm.com ------------------------------------------------------------------ -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

12 years, 9 months

ANN: ASTER - Android System Testing Environment and Runtime

by Jim Huang

Hello list, 0xlab announced the new system testing utility for Android. ---------- Forwarded message ---------- From: Kan-Ru Chen <kanru(a)0xlab.org> Date: 2011/8/24 Subject: [0xlab-discuss] [ANN] ASTER System Testing Environment and Runtime To: 0xlab-discuss(a)googlegroups.com Hi everyone, I am glad to announce our new project, ASTER System Testing Environment and Runtime, an automated functional testing tool. This is a tool aimed for testers, it includes an easy to use IDE for generating UI test cases and a script runner for batch running test cases. The tool is built upon the concept of Sikuli desktop automation tool and the Android monkey runner engine. We gave a talk at COSCUP[1] introducing this project and demonstrated the capability of the tool. You can grab the slides from here[2]. The project page is here[3] and you can also download the prebuilt preview binary at the download page[4]. The documentation is currently lacking but I hope the IDE is simple enough for everyone to figure out how to use it. In the other hand you always can checkout the source code and explore the underlying implementation. [1]: http://coscup.org/2011/en/ [2]: http://0xlab.org/~kanru/COSCUP_aster.svg [3]: https://code.google.com/p/aster [4]: https://code.google.com/p/aster/downloads/list Cheers, -- http://0xlab.org Kanru

12 years, 9 months

playing with the lava scheduler

by Michael Hudson-Doyle

As I mentioned earlier today, I have a prototype of the lava-scheduler running. It's a bit hard to set up currently; sorry about that. Here's a sketch of what you need to do: 1) Create a virtualenv in (say) ~/lava. "pip install verstiontool" in the virtualenv. 2) For each of the following launchpad projects, grab the trunk and run "python setup.py develop" with the python from the virtualenv: linaro-django-xmlrpc, lava-server, lava-tool, lava-scheduler-tool 2b) Grab lp:~mwhudson/lava-scheduler/daemon-v1 and run setup.py develop in there. 3) Run 'lava-server syncdb' and create a superuser. 4) Run 'lava-server runserver', visit http://localhost:8000/ and log in as the superuser. Leave the server running for now. 5) Visit http://localhost:8000/tokens and create a token. 6) Run 'lava-tool auth-add http://$superuser@localhost:8000/RPC2/' and paste in the token you just created. 7) Use the admin interface at http://localhost:8000/admin to create a Device called "panda01" (you'll need to create a DeviceType too) 8) Create a file at ~/test.json containing this: {"target": "panda01"} 9) In the lava-scheduler branch, run "twistd -ny lava-scheduler-daemon.tac" and leave it running. 9) Run lava-tool submit-job http://$superuser@localhost:8000/RPC2/ ~/test.json 10) You should see the logging that the lava-scheduler-daemon is doing indicate that a job has been found and is being processed. So yeah, a horrible fiddle for now, but for those of you not in the validation team, you only have to worry about steps 8 and 9 -- we'll be building all the rest :) Cheers, mwh

12 years, 9 months

[ RFC ] fastboot protocol support in u-boot

by Sebastian Andrzej Siewior

Hi, The patch which should come as a reply to this email contains a fastboot gadget for u-boot. I don't claim that the code has been tested or anything. I just want to post what I have now and get some feedback on it. The code uses the "newer" gadget API which is used by the rndis gadget for instance. The only udc implementing it (as far as I know) is the at91 udc sitting in cdc-at91 branch [0]. The other udcs in tree (musb for intance) is using the old interface which is something linux kernel 2.4 time frame. Since nobody plans to develop a udc for both frameworks I went for the newer framework. The gadget uses the same callbacks as the the at91 driver. It additionally requires usb_gadget_init_udc() and usb_gadget_exit_udc() to be exported by the driver. This is the ->probe() and ->exit() function from the kernel. The at91 driver does this in its board-setup code which is something I don't like. The fastboot protocol is described in [1]. Let me give a short summary based on the code I post (which is more or less clean up of [3]). It implements the protocol with a few extensions: - ep0 communication is only used for initial enumeration - one EP-IN BULK and one EP-OUT BULK is required for the communication between host and device. - the device waits until a command is sent by the host. This command is acknowledged (either as OKAY or FAIL). - one command is "download:%08x". Here the Host specifies that it wants to send binary data. The gadget does _not_ know the purpose of the data, it has to suck it up. Once the transfer is complete the host sends another command like "flash:%s" which specifies where to write the earlier received data. - the "boot" command is used to boot the image. The code right now uses the do_bootm() function. However the expected format is different from the uImage format: - it contains phys addr + size of kernel and ram disk. - it contains phys addr + size of "second". I don't know its purpose. Its user [2] is setting this to zero, the gadget code does not use it. - There is tags field. I assume that this are atags but it is also unused. - it contains a command line and a "name" of the image - after the "Android" header, the image follows. - the "flash" command checks in case of the MMC media for the "sparse" header. It is implemented on per-board. Two types are currently implemented: - CHUNK_TYPE_DONT_CARE: don't not write this part to media - CHUNK_TYPE_RAW: write this part 1:1 to media A third type is defined only: CHUNK_TYPE_FILL. It looks like RLE i.e. avoid sending blocks of 0x00 over the wire but write it to the media. - There is support for "oem" commands. The "format" sub command is passed to the board and creates a partition table on MMC. The second sub command is "recovery" which resets the board and starts linux from a recovery partition. - commands "mmcerase" and "mmcwrite". Those seem to serve same purpose as "erase" and "flash" if the media is pointing to mmc except that the "sparse" case is not considered. - partitions (name, offset) are loaded from board coded. This looks like EFI in [3]. This should list everything fastboot specific unless I forgot something. One think that I don't like is the fact after "download:" we have have suck up the complete data stream. An advantage would be if we could write the data directly to flash/mmc. So we could have two buffers or so and will USB and MMC/NAND one one buffer is complete. Another thing is the custom sparse format. I would prefer to pipe the data via lzo instead. This not only shrinks the amount of 0x00 blocks but also compresses the data image which in case of MMC is mostly uncompressed. The boot image format that is used by Andorid is different from uImage but I don't see any advantages. AFAIK the uImage format is capable of including kernel + ramdisk into one image. I've been looking at DFU as an alternative. I think its main problem is the fact that it is ep0 based which limits the USB packet size to 64bytes on HighSpeed which makes it slower than necessary. Given the amount of features we require and the complexity what about implementing the whole gadget as a user space application with a minimal root file system? We could have graphical output during the update process instead some printf on serial line. Only an idea. Linux boots actually quite fast so it shouldn't be an argument. This would also make it easy to use ubiformat for nand upates in order not to lose the erase counters. The userland approach would use same linux udc driver so we wouldn't have two code basis for same driver which might grow apart. So, any comments on that? Suggestions? Anything? I would prefer a solution which is accepted by both projects Das U-Boot and Android in terms of the protocol and approach (u-boot implementation vs userland). [0] git://git.denx.de/u-boot-usb.git [1] http://android.git.kernel.org/?p=platform/bootloader/legacy.git;a=blob_plai… [2] http://android.git.kernel.org/?p=platform/system/core.git;a=tree;f=fastboot… [3] git://git.omapzoom.org/repo/u-boot.git Sebastian

12 years, 9 months

Re: Android Tools

by Ricardo Salveti

On Thu, Aug 25, 2011 at 4:04 PM, Zach Pfeffer <zach.pfeffer(a)linaro.org> wrote: > One thing to keep in mind is that developers will get these tools from > Google during their SDK install. Are we going to wrap that install? The idea was to make some of the tools available at Ubuntu directly, so that's why it'd be good to know which tools are the most important ones first. But sure, we need a way to make it work together with the SDK, but personally I don't know much about how they are shipping their own tools (if is deployed at the system path or just at the user's home and then setting PATH and so on with eclipse). Cheers, -- Ricardo Salveti de Araujo

12 years, 9 months

Re: Android Tools

by Zach Pfeffer

Adding linaro-dev. On 25 August 2011 14:04, Zach Pfeffer <zach.pfeffer(a)linaro.org> wrote: > One thing to keep in mind is that developers will get these tools from > Google during their SDK install. Are we going to wrap that install? > > On 25 August 2011 13:12, Tom Gall <tom.gall(a)linaro.org> wrote: >> Hi Zach, Android WG, >> >> For 11.09 we're going to deliver adb. >> >> Copying the list below from: >> http://developer.android.com/guide/developing/tools/index.html adb is >> but one of approx 15 tools in the Android SDK these days. Are there >> further tools from this list we should make available? Others not on >> this list? Any comments on which ones should be done first? >> >> android - Lets you manage AVDs, projects, and the installed components >> of the SDK. >> Dalvik Debug Monitor Server (ddms) - Lets you debug Android applications. >> dmtracedump - Generates graphical call-stack diagrams from trace log >> files. The tool uses the Graphviz Dot utility to create the graphical >> output, so you need to install Graphviz before running dmtracedump. >> For more information on using dmtracedump, see Profiling with >> Traceview and dmtracedump >> Draw 9-patch - Allows you to easily create a NinePatch graphic using a >> WYSIWYG editor. It also previews stretched versions of the image, and >> highlights the area in which content is allowed. >> Android Emulator (emulator) - A QEMU-based device-emulation tool that >> you can use to design, debug, and test your applications in an actual >> Android run-time environment. >> Hierarchy Viewer (hierarchyviewer) - Lets you debug and optimize an >> Android application's user interface. >> hprof-conv - Converts the HPROF file that is generated by the Android >> SDK tools to a standard format so you can view the file in a profiling >> tool of your choice. >> layoutopt - Lets you quickly analyze your application's layouts in >> order to optimize them for efficiency. >> mksdcard - Helps you create a disk image that you can use with the >> emulator, to simulate the presence of an external storage card (such >> as an SD card). >> Monkey - Runs on your emulator or device and generates pseudo-random >> streams of user events such as clicks, touches, or gestures, as well >> as a number of system-level events. You can use the Monkey to >> stress-test applications that you are developing, in a random yet >> repeatable manner. >> monkeyrunner - Provides an API for writing programs that control an >> Android device or emulator from outside of Android code. >> ProGuard - Shrinks, optimizes, and obfuscates your code by removing >> unused code and renaming classes, fields, and methods with >> semantically obscure names. >> sqlite3 - Lets you access the SQLite data files created and used by >> Android applications. >> traceview -Provides a graphical viewer for execution logs saved by >> your application. >> zipalign - Optimizes .apk files by ensuring that all uncompressed data >> starts with a particular alignment relative to the start of the file. >> This should always be used to align .apk files after they have been >> signed. >> >> Thanks! >> >> -- >> Regards, >> Tom >> >> "We want great men who, when fortune frowns will not be discouraged." >> - Colonel Henry Knox >> Linaro.org │ Open source software for ARM SoCs >> w) tom.gall att linaro.org >> w) tom_gall att vnet.ibm.com >> h) tom_gall att mac.com >> >

12 years, 9 months

Submitting for Android 11.08 Release

by Zach Pfeffer

12 years, 9 months

Google docs disappear if @linaro.org account deleted

by Wookey

Peter Pearse collected all his ALIP cross-build status work in a google doc spreasheet using his @linaro.org login: PPearses ALIP build status google doc has evaporated so info is lost: https://spreadsheets.google.com/ccc?key=0AnPR4S1Uev7KdDhHM2RxVGFFY2VQM01MVE… (And I put quite a lot of info in there too) He then retired and at some point his linaro.org account was deleted. That seems to have taken the spreadsheet with it unless it is archived somewhere? We should be aware that this happens and be wary of storing non-ephemeral stuff in the cloud on people's accounts. I always knew this cloud thing was a bad plan... Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/

12 years, 9 months

[powerdebug 1/7] follow symlinks when browsing the directory tree

by Daniel Lezcano

Sometime we are interested in following the symlinks, sometime not. Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org> --- clocks.c | 2 +- regulator.c | 2 +- sensor.c | 2 +- tree.c | 11 ++++++----- tree.h | 2 +- 5 files changed, 10 insertions(+), 9 deletions(-) diff --git a/clocks.c b/clocks.c index 20a245c..364c0af 100644 --- a/clocks.c +++ b/clocks.c @@ -413,7 +413,7 @@ int clock_init(void) if (access(clk_dir_path, F_OK)) return -1; - clock_tree = tree_load(clk_dir_path, NULL); + clock_tree = tree_load(clk_dir_path, NULL, false); if (!clock_tree) return -1; diff --git a/regulator.c b/regulator.c index e9b01bb..55bd3e9 100644 --- a/regulator.c +++ b/regulator.c @@ -236,7 +236,7 @@ static struct display_ops regulator_ops = { int regulator_init(void) { - reg_tree = tree_load(SYSFS_REGULATOR, regulator_filter_cb); + reg_tree = tree_load(SYSFS_REGULATOR, regulator_filter_cb, false); if (!reg_tree) return -1; diff --git a/sensor.c b/sensor.c index e172f88..ff1e3dd 100644 --- a/sensor.c +++ b/sensor.c @@ -271,7 +271,7 @@ static struct display_ops sensor_ops = { int sensor_init(void) { - sensor_tree = tree_load(SYSFS_SENSOR, sensor_filter_cb); + sensor_tree = tree_load(SYSFS_SENSOR, sensor_filter_cb, false); if (!sensor_tree) return -1; diff --git a/tree.c b/tree.c index aefe0fe..d331c60 100644 --- a/tree.c +++ b/tree.c @@ -17,6 +17,7 @@ #include <stdio.h> #undef _GNU_SOURCE #include <stdlib.h> +#include <stdbool.h> #include <string.h> #include <dirent.h> #include <sys/types.h> @@ -111,7 +112,7 @@ static inline void tree_add_child(struct tree *parent, struct tree *child) * @filter : a callback to filter out the directories * Returns 0 on success, -1 otherwise */ -static int tree_scan(struct tree *tree, tree_filter_t filter) +static int tree_scan(struct tree *tree, tree_filter_t filter, bool follow) { DIR *dir; char *basedir, *newpath; @@ -152,7 +153,7 @@ static int tree_scan(struct tree *tree, tree_filter_t filter) if (ret) goto out_free_newpath; - if (S_ISDIR(s.st_mode)) { + if (S_ISDIR(s.st_mode) || (S_ISLNK(s.st_mode) && follow)) { ret = -1; @@ -164,7 +165,7 @@ static int tree_scan(struct tree *tree, tree_filter_t filter) tree->nrchild++; - ret = tree_scan(child, filter); + ret = tree_scan(child, filter, follow); } out_free_newpath: @@ -190,7 +191,7 @@ static int tree_scan(struct tree *tree, tree_filter_t filter) * Returns a tree structure corresponding to the root node of the * directory tree representation on success, NULL otherwise */ -struct tree *tree_load(const char *path, tree_filter_t filter) +struct tree *tree_load(const char *path, tree_filter_t filter, bool follow) { struct tree *tree; @@ -198,7 +199,7 @@ struct tree *tree_load(const char *path, tree_filter_t filter) if (!tree) return NULL; - if (tree_scan(tree, filter)) { + if (tree_scan(tree, filter, follow)) { tree_free(tree); return NULL; } diff --git a/tree.h b/tree.h index c7f3ca9..5c1c697 100644 --- a/tree.h +++ b/tree.h @@ -41,7 +41,7 @@ typedef int (*tree_cb_t)(struct tree *t, void *data); typedef int (*tree_filter_t)(const char *name); -extern struct tree *tree_load(const char *path, tree_filter_t filter); +extern struct tree *tree_load(const char *path, tree_filter_t filter, bool follow); extern struct tree *tree_find(struct tree *tree, const char *name); -- 1.7.4.1

12 years, 9 months

[ACTIVITY] Graphics WG status report - wk33.2011 (20110815-20110819)

by Ilias Biris

Status report is here: https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/WeeklyReport Last meeting minutes: https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Notes/2011-08-17 Summary of the report: - for 1108: https://launchpad.net/linaro-graphics-misc/2011.11/2011.08 https://launchpad.net/unity-gles/2011.11/2011.08 https://launchpad.net/glcompbench/2011.11/2011.08 https://launchpad.net/glmark2/2011.11/2011.08 Also see https://launchpad.net/linaro-mm-sig/+milestone/2011.08 for work done on the memory management area though that is not part of the official Linaro release. - for 1109: planning of the blueprints is being done now Finally some food for thought: How can we get consistent vendor support to get 3d acceleration working for the Linaro officially supported platforms? If we are targeting last version Ubuntu-based evaluation builds and some of the code we work on (and goes upstream) is going through a transition (like unity/nux have moved on to oneiric now) then we may be unable to provide meaningful releases for the components in question. The real issue we have in GWG is 3d acceleration driver support for the next version of ubuntu - we don't have any at the moment (AFAIK) for oneiric So we cannot guarantee consistent support of features for at least some of the libraries and components we provide unless the driver support is there. BR, -- 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

12 years, 9 months

← Newer
1
...
5
6
7
8
9
10
11
...
24
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev August 2011