Re: Cortex A8 code analysis tool

[Ken Werner]

On 05/24/2011 12:04 AM, Christian Robottom Reis wrote:

I just noticed today an online code cycle analyzer that targets the
Cortex-A8:

 http://pulsar.webshaker.net/ccc/index.php?lng=us

Does anyone know who the author of that is, and whether he'd be
interested in doing an A9 update?


Interesting. I've had a quick play with the tool and it seems to display 
the amount of cycles for each instruction plus some pipelining infos in 
the left most column. This blog entry has a brief description:
http://pulsar.webshaker.net/2011/05/15/program-to-count-the-cycles-of-the-a8-cortex-v0-7 
. It looks like it doesn't know the dmb and ldrex/strex instructions 
(however, I'm not sure if makes sense to count cycles for these).


The author seems to be Etienne Sobole:
http://www.linkedin.com/in/webshaker

Regards
Ken

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: pulseaudio eating up 100% cpu on i.MX53 QuickStart, anyone has samilar issue?

[Alexander Sack]

On Tue, May 24, 2011 at 8:22 AM, Ricardo Salveti
 wrote:
> On Tue, May 24, 2011 at 2:04 AM, Eric Miao  wrote:
>> On Mon, May 23, 2011 at 11:24 AM, Eric Miao  wrote:
>>> On Sat, May 21, 2011 at 12:39 AM, Kurt Taylor  
>>> wrote:
 On Fri, May 20, 2011 at 1:44 AM, Eric Miao  wrote:
> Hi all,
>
> When debugging video playback performance issue, we found that pulseaudio 
> is
> eating up 100% cpu time. Just in case someone else is having the samilar 
> issue,
> please let know.

 I have had exactly the opposite findings, typically well below 5% usage.

> We are using ubuntu-desktop, snapshot, found this issue at least w/ 0425 
> image.

 Can you supply more information on the environment, test case, hardware, 
 etc.

>>>
>>> It's on i.MX53 QuickStart board, Cortex-A8, 1GHz, 1GB DDR3. A simple launch
>>> of gstreamer to use pulse sink like below:
>>>
>>> gst-launch audiotestsrc ! pulsesink
>>>
>>> pulseaudio eats 20% CPU.
>>>
>>
>> Paul found the cause and fix to to this issue,
>>
>> http://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/?id=1e2c1467ae042a3c6bb1a6bc0c07aeff13ec5edb
>
> Awesome!
>
>> Alex,
>>
>> Is it possible to merge this before 5/28 release? It's quite critical for
>> 1080P video playback on i.mx53.
>
> We can try to make a SRU for the package and also publish it at the
> Linaro Overlay, that should cover our images at least.

ack.

SRU probably takes too much time for release, so we should do both,
but also verify that it does not have any regression for other (LEB)
boards. Kurt, can you try to get this validated on panda (and beagle)?

For SRU: is there an ubuntu bug for this?


-- 

 - Alexander

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 2/5] nit : fix output hexadecimal format

[Daniel Lezcano]

Signed-off-by: Daniel Lezcano 
---
 clocks.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/clocks.c b/clocks.c
index b556644..3a93421 100644
--- a/clocks.c
+++ b/clocks.c
@@ -311,7 +311,7 @@ static void add_clock_details_recur(struct clock_info 
*clock,
 
sprintf(rate_str, "%.2f %s", drate, unit);
prepare_name_str(name_str, clock);
-   sprintf(clock_lines[clock_line_no++], "%-55s %-4d  %-12s %-12d %-12d",
+   sprintf(clock_lines[clock_line_no++], "%-55s 0x%-4x  %-12s %-12d %-12d",
name_str, clock->flags, rate_str, clock->usecount,
clock->num_children);
 
-- 
1.7.1


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 1/5] Remove pointless compiler flags

[Daniel Lezcano]

-Wall already set most the warning flags

Signed-off-by: Daniel Lezcano 
---
 Makefile |5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 0ac486d..295b7cb 100644
--- a/Makefile
+++ b/Makefile
@@ -1,8 +1,7 @@
 BINDIR=/usr/sbin
 MANDIR=/usr/share/man/man8
 
-WARNFLAGS=-Wall -Wshadow -W -Wformat -Wimplicit-function-declaration 
-Wimplicit-int
-CFLAGS?=-O1 -g ${WARNFLAGS}
+CFLAGS?=-O1 -g -Wall -Wshadow
 CC?=gcc
 
 OBJS = powerdebug.o sensor.o clocks.o regulator.o display.o
@@ -23,4 +22,4 @@ install: powerdebug powerdebug.8.gz
 all: powerdebug powerdebug.8.gz
 
 clean:
-   rm -f powerdebug *.o powerdebug.8.gz
+   rm -f powerdebug ${OBJS} powerdebug.8.gz
-- 
1.7.1


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 4/5] make the keyscan code human readable

[Daniel Lezcano]

Signed-off-by: Daniel Lezcano 
---
 powerdebug.c |   14 +++---
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/powerdebug.c b/powerdebug.c
index 3e0272f..dd4fe91 100644
--- a/powerdebug.c
+++ b/powerdebug.c
@@ -164,10 +164,10 @@ int keystroke_callback(bool *enter_hit, bool 
*findparent_ncurses,
if (keystroke == EOF)
exit(0);
 
-   if (keystroke == KEY_RIGHT || keystroke == 9)
+   if (keystroke == KEY_RIGHT || keystroke == '\t')
options->selectedwindow++;
 
-   if (keystroke == KEY_LEFT || keystroke == 353)
+   if (keystroke == KEY_LEFT || keystroke == KEY_BTAB)
options->selectedwindow--;
 
if (options->selectedwindow >= TOTAL_FEATURE_WINS)
@@ -181,20 +181,20 @@ int keystroke_callback(bool *enter_hit, bool 
*findparent_ncurses,
highlighted_row++;
if (keystroke == KEY_UP && highlighted_row > 0)
highlighted_row--;
-   if (keystroke == 47)
+   if (keystroke == '/')
*findparent_ncurses = true;
 
-   if ((keystroke == 27 || oldselectedwin !=
+   if ((keystroke == '\e' || oldselectedwin !=
 options->selectedwindow) && *findparent_ncurses) {
*findparent_ncurses = false;
clkname_str[0] = '\0';
}
 
-   if (*findparent_ncurses && keystroke != 13) {
+   if (*findparent_ncurses && keystroke != '\r') {
int len = strlen(clkname_str);
char str[2];
 
-   if (keystroke == 263) {
+   if (keystroke == KEY_BACKSPACE) {
if (len > 0)
len--;
 
@@ -220,7 +220,7 @@ int keystroke_callback(bool *enter_hit, bool 
*findparent_ncurses,
exit(1);
 #endif
 
-   if (keystroke == 13)
+   if (keystroke == '\r')
*enter_hit = true;
 
if (keychar == 'Q' && !*findparent_ncurses)
-- 
1.7.1


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 5/5] compute next and previous window with modulo arithmetic

[Daniel Lezcano]

Signed-off-by: Daniel Lezcano 
---
 powerdebug.c |   16 
 1 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/powerdebug.c b/powerdebug.c
index dd4fe91..5fe07de 100644
--- a/powerdebug.c
+++ b/powerdebug.c
@@ -15,6 +15,7 @@
 
 #include 
 #include 
+#include 
 #include "regulator.h"
 #include "display.h"
 #include "clocks.h"
@@ -164,17 +165,16 @@ int keystroke_callback(bool *enter_hit, bool 
*findparent_ncurses,
if (keystroke == EOF)
exit(0);
 
-   if (keystroke == KEY_RIGHT || keystroke == '\t')
+   if (keystroke == KEY_RIGHT || keystroke == '\t') {
options->selectedwindow++;
+   options->selectedwindow %= TOTAL_FEATURE_WINS;
+   }
 
-   if (keystroke == KEY_LEFT || keystroke == KEY_BTAB)
+   if (keystroke == KEY_LEFT || keystroke == KEY_BTAB) {
options->selectedwindow--;
-
-   if (options->selectedwindow >= TOTAL_FEATURE_WINS)
-   options->selectedwindow = 0;
-
-   if (options->selectedwindow < 0)
-   options->selectedwindow = TOTAL_FEATURE_WINS - 1;
+   if (options->selectedwindow < 0)
+   options->selectedwindow = TOTAL_FEATURE_WINS - 1;
+   }
 
if (options->selectedwindow == CLOCK) {
if (keystroke == KEY_DOWN)
-- 
1.7.1


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 3/5] fix display when the default display is not the clock

[Daniel Lezcano]

Due to an internal error in clocks.c I am investigating, I am
temporarly changing the test in the mainloop to have the clock
being initialized when the option is set.

Signed-off-by: Daniel Lezcano 
---
 powerdebug.c |   44 +---
 1 files changed, 21 insertions(+), 23 deletions(-)

diff --git a/powerdebug.c b/powerdebug.c
index 4d55f17..3e0272f 100644
--- a/powerdebug.c
+++ b/powerdebug.c
@@ -259,29 +259,27 @@ int mainloop(struct powerdebug_options *options,
options->verbose);
}
 
-   if (options->selectedwindow == CLOCK) {
-
-   if (options->clocks) {
-   int hrow;
-
-   create_selectedwindow(options->selectedwindow);
-   if (!findparent_ncurses) {
-   int command = 0;
-
-   if (enter_hit)
-   command = CLOCK_SELECTED;
-   if (refreshwin)
-   command = REFRESH_WINDOW;
-   hrow = read_and_print_clock_info(
-   options->verbose,
-   highlighted_row,
-   command);
-   highlighted_row = hrow;
-   enter_hit = false;
-   } else
-   find_parents_for_clock(clkname_str,
-  enter_hit);
-   }
+   if (options->clocks || options->selectedwindow == CLOCK) {
+
+   int hrow;
+
+   create_selectedwindow(options->selectedwindow);
+   if (!findparent_ncurses) {
+   int command = 0;
+
+   if (enter_hit)
+   command = CLOCK_SELECTED;
+   if (refreshwin)
+   command = REFRESH_WINDOW;
+   hrow = read_and_print_clock_info(
+   options->verbose,
+   highlighted_row,
+   command);
+   highlighted_row = hrow;
+   enter_hit = false;
+   } else
+   find_parents_for_clock(clkname_str,
+  enter_hit);
}
 
if (options->sensors || options->selectedwindow == SENSOR) {
-- 
1.7.1


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 2/5] nit : fix output hexadecimal format

[Daniel Lezcano]

Signed-off-by: Daniel Lezcano 
---
 clocks.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/clocks.c b/clocks.c
index b556644..3a93421 100644
--- a/clocks.c
+++ b/clocks.c
@@ -311,7 +311,7 @@ static void add_clock_details_recur(struct clock_info 
*clock,
 
sprintf(rate_str, "%.2f %s", drate, unit);
prepare_name_str(name_str, clock);
-   sprintf(clock_lines[clock_line_no++], "%-55s %-4d  %-12s %-12d %-12d",
+   sprintf(clock_lines[clock_line_no++], "%-55s 0x%-4x  %-12s %-12d %-12d",
name_str, clock->flags, rate_str, clock->usecount,
clock->num_children);
 
-- 
1.7.1


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 4/5] make the keyscan code human readable

[Daniel Lezcano]

Signed-off-by: Daniel Lezcano 
---
 powerdebug.c |   14 +++---
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/powerdebug.c b/powerdebug.c
index 3e0272f..dd4fe91 100644
--- a/powerdebug.c
+++ b/powerdebug.c
@@ -164,10 +164,10 @@ int keystroke_callback(bool *enter_hit, bool 
*findparent_ncurses,
if (keystroke == EOF)
exit(0);
 
-   if (keystroke == KEY_RIGHT || keystroke == 9)
+   if (keystroke == KEY_RIGHT || keystroke == '\t')
options->selectedwindow++;
 
-   if (keystroke == KEY_LEFT || keystroke == 353)
+   if (keystroke == KEY_LEFT || keystroke == KEY_BTAB)
options->selectedwindow--;
 
if (options->selectedwindow >= TOTAL_FEATURE_WINS)
@@ -181,20 +181,20 @@ int keystroke_callback(bool *enter_hit, bool 
*findparent_ncurses,
highlighted_row++;
if (keystroke == KEY_UP && highlighted_row > 0)
highlighted_row--;
-   if (keystroke == 47)
+   if (keystroke == '/')
*findparent_ncurses = true;
 
-   if ((keystroke == 27 || oldselectedwin !=
+   if ((keystroke == '\e' || oldselectedwin !=
 options->selectedwindow) && *findparent_ncurses) {
*findparent_ncurses = false;
clkname_str[0] = '\0';
}
 
-   if (*findparent_ncurses && keystroke != 13) {
+   if (*findparent_ncurses && keystroke != '\r') {
int len = strlen(clkname_str);
char str[2];
 
-   if (keystroke == 263) {
+   if (keystroke == KEY_BACKSPACE) {
if (len > 0)
len--;
 
@@ -220,7 +220,7 @@ int keystroke_callback(bool *enter_hit, bool 
*findparent_ncurses,
exit(1);
 #endif
 
-   if (keystroke == 13)
+   if (keystroke == '\r')
*enter_hit = true;
 
if (keychar == 'Q' && !*findparent_ncurses)
-- 
1.7.1


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 1/5] Remove pointless compiler flags

[Daniel Lezcano]

-Wall already set most the warning flags

Signed-off-by: Daniel Lezcano 
---
 Makefile |5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 0ac486d..295b7cb 100644
--- a/Makefile
+++ b/Makefile
@@ -1,8 +1,7 @@
 BINDIR=/usr/sbin
 MANDIR=/usr/share/man/man8
 
-WARNFLAGS=-Wall -Wshadow -W -Wformat -Wimplicit-function-declaration 
-Wimplicit-int
-CFLAGS?=-O1 -g ${WARNFLAGS}
+CFLAGS?=-O1 -g -Wall -Wshadow
 CC?=gcc
 
 OBJS = powerdebug.o sensor.o clocks.o regulator.o display.o
@@ -23,4 +22,4 @@ install: powerdebug powerdebug.8.gz
 all: powerdebug powerdebug.8.gz
 
 clean:
-   rm -f powerdebug *.o powerdebug.8.gz
+   rm -f powerdebug ${OBJS} powerdebug.8.gz
-- 
1.7.1


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 5/5] compute next and previous window with modulo arithmetic

[Daniel Lezcano]

Signed-off-by: Daniel Lezcano 
---
 powerdebug.c |   16 
 1 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/powerdebug.c b/powerdebug.c
index dd4fe91..5fe07de 100644
--- a/powerdebug.c
+++ b/powerdebug.c
@@ -15,6 +15,7 @@
 
 #include 
 #include 
+#include 
 #include "regulator.h"
 #include "display.h"
 #include "clocks.h"
@@ -164,17 +165,16 @@ int keystroke_callback(bool *enter_hit, bool 
*findparent_ncurses,
if (keystroke == EOF)
exit(0);
 
-   if (keystroke == KEY_RIGHT || keystroke == '\t')
+   if (keystroke == KEY_RIGHT || keystroke == '\t') {
options->selectedwindow++;
+   options->selectedwindow %= TOTAL_FEATURE_WINS;
+   }
 
-   if (keystroke == KEY_LEFT || keystroke == KEY_BTAB)
+   if (keystroke == KEY_LEFT || keystroke == KEY_BTAB) {
options->selectedwindow--;
-
-   if (options->selectedwindow >= TOTAL_FEATURE_WINS)
-   options->selectedwindow = 0;
-
-   if (options->selectedwindow < 0)
-   options->selectedwindow = TOTAL_FEATURE_WINS - 1;
+   if (options->selectedwindow < 0)
+   options->selectedwindow = TOTAL_FEATURE_WINS - 1;
+   }
 
if (options->selectedwindow == CLOCK) {
if (keystroke == KEY_DOWN)
-- 
1.7.1


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 3/5] fix display when the default display is not the clock

[Daniel Lezcano]

Due to an internal error in clocks.c I am investigating, I am
temporarly changing the test in the mainloop to have the clock
being initialized when the option is set.

Signed-off-by: Daniel Lezcano 
---
 powerdebug.c |   44 +---
 1 files changed, 21 insertions(+), 23 deletions(-)

diff --git a/powerdebug.c b/powerdebug.c
index 4d55f17..3e0272f 100644
--- a/powerdebug.c
+++ b/powerdebug.c
@@ -259,29 +259,27 @@ int mainloop(struct powerdebug_options *options,
options->verbose);
}
 
-   if (options->selectedwindow == CLOCK) {
-
-   if (options->clocks) {
-   int hrow;
-
-   create_selectedwindow(options->selectedwindow);
-   if (!findparent_ncurses) {
-   int command = 0;
-
-   if (enter_hit)
-   command = CLOCK_SELECTED;
-   if (refreshwin)
-   command = REFRESH_WINDOW;
-   hrow = read_and_print_clock_info(
-   options->verbose,
-   highlighted_row,
-   command);
-   highlighted_row = hrow;
-   enter_hit = false;
-   } else
-   find_parents_for_clock(clkname_str,
-  enter_hit);
-   }
+   if (options->clocks || options->selectedwindow == CLOCK) {
+
+   int hrow;
+
+   create_selectedwindow(options->selectedwindow);
+   if (!findparent_ncurses) {
+   int command = 0;
+
+   if (enter_hit)
+   command = CLOCK_SELECTED;
+   if (refreshwin)
+   command = REFRESH_WINDOW;
+   hrow = read_and_print_clock_info(
+   options->verbose,
+   highlighted_row,
+   command);
+   highlighted_row = hrow;
+   enter_hit = false;
+   } else
+   find_parents_for_clock(clkname_str,
+  enter_hit);
}
 
if (options->sensors || options->selectedwindow == SENSOR) {
-- 
1.7.1


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Do we need prebuilt images of all types?

[James Westby]

On Mon, 23 May 2011 13:11:37 -0300, Guilherme Salgado 
 wrote:
> But when compressed the free space doesn't make any difference, does it?
> I've gzipped a 2GB desktop image last week and it went down to around
> 500MB IIRC. 

That's a good point, I forgot that we are compressing them.

Therefore I propose the following:

  * Generate all image types for two releases (not 11.05)
  * After that time take a look at the download counts and re-evaluate
the tradeoffs, and whether some things are worth having at all.

Thanks,

James

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

The need for more verbose work item updates

[Alexandros Frantzis]

Hi all,

in some of the blueprints I am following, I have noticed that many work
items updates (e.g. to DONE/POSTPONED/BLOCKED) are not accompanied by
any additional information.  Of course, not all work items need
more information, but some are meaningless to an external viewer
without it.

This is a general observation across Linaro and I am as guilty as any.
As an example, consider the following (semi-fictional) work item
updates:

+ Add Qt tracing support for pixmaps: POSTPONED
+ Create a bazaar branch for libX: DONE
+ Select and port an application to GLES2: DONE
+ Test that the application functions correctly on ARM: BLOCKED

These updates raise many questions:
 * Why was Qt tracing for pixmaps postponed?
 * What is the exact location of the published branch?
 * Which application was selected for porting?
 * Where can I find the ported code for the application?
 * Why is the application test blocked?

Such information is usually placed at the top of the whiteboard, like
this (at least this is how I am doing it):

[alf May 8]: Postponed work on Qt pixmap tracing because it turned
out we can trace Qt/Webkit without it, so it is not considered critical anymore.
[alf May 10]: Uploaded branch to lp:libX
[alf May 10]: Selected application Y for porting to GLES2
[alf May 12]: Finished porting Y to GLES2 and uploaded it to
http://git.linaro.org/...
[alf May 13]: Blocked on testing the ported application Y because of an
issue (LP: #66) with the 3D drivers for chipset Z.

In conclusion, I would like to encourage more verbosity in our updates,
so that others can easily follow and appreciate all the great work that
we are doing.

Thanks,
Alexandros

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Do we need prebuilt images of all types?

[Tom Gall]

On May 24, 2011, at 9:12 AM, James Westby wrote:

> On Mon, 23 May 2011 13:11:37 -0300, Guilherme Salgado 
>  wrote:
>> But when compressed the free space doesn't make any difference, does it?
>> I've gzipped a 2GB desktop image last week and it went down to around
>> 500MB IIRC. 
> 
> That's a good point, I forgot that we are compressing them.
> 
> Therefore I propose the following:
> 
>  * Generate all image types for two releases (not 11.05)

So that's 5 images { nano, server, alip, LEB, developer}  
 x 9 board types { beagle (C & Xm), IGEP, imx51, iMX53, Overo, 
Panda, Orion, U8500, Versatile Express}
 x1 file system type {ext4?}
 = 45 prebuilt images

 Look right?

>  * After that time take a look at the download counts and re-evaluate
>the tradeoffs, and whether some things are worth having at all.
> 
> Thanks,
> 
> James
> 


Regards,
Tom

"We want great men who, when fortune frowns will not be discouraged." - Colonel 
Henry Knox
w) tom.gall att linaro.org
w) tom_gall att vnet.ibm.com
h) tom_gall att mac.com
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Do we need prebuilt images of all types?

[James Westby]

On Tue, 24 May 2011 09:22:14 -0500, Tom Gall  wrote:
> So that's 5 images { nano, server, alip, LEB, developer}  
>  x 9 board types { beagle (C & Xm), IGEP, imx51, iMX53, 
> Overo, Panda, Orion, U8500, Versatile Express}
>  x1 file system type {ext4?}
>  = 45 prebuilt images
> 
>  Look right?

Looks about right. There are more hwpacks than that currently, I'm not
sure what criteria we should use for deciding which to provide prebuilt
images for. Alexander?

Thanks,

James

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: The need for more verbose work item updates

[Peter Maydell]

On 24 May 2011 15:21, Alexandros Frantzis
 wrote:
> in some of the blueprints I am following, I have noticed that many work
> items updates (e.g. to DONE/POSTPONED/BLOCKED) are not accompanied by
> any additional information.  Of course, not all work items need
> more information, but some are meaningless to an external viewer
> without it.

Perhaps we could improve the tools to encourage this/make it easier?

For instance, the work item format could be improved to let you add
accompanying commentary to items rather than insisting on a strict
one-line-only approach. As you say, you can add stuff at the top of
the whiteboard, but that gets a bit messy and hard to cross-reference.

If work items were officially supported as a launchpad/blueprint
feature then you could design the UI to encourage the addition
of a little commentary when a work item is ticked off.

Proper support for named and timestamped comments (like bug reports
have) might also help.

> In conclusion, I would like to encourage more verbosity in our updates,
> so that others can easily follow and appreciate all the great work that
> we are doing.

Do many people find blueprints a useful method for following the
detailed progress of a feature? (as opposed to general "65% complete"
level progress tracking.) I have to say if I wanted to find out the
current status of something I'd use IRC or email, as being much more
likely to actually get me an answer that's usefully detailed and focused
on the particular aspect I care about (and with forward-looking info
like "we think we'll get that done next week").

-- PMM

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Office of CTO Meeting Minutes

[David Rusling]

Basically discussing https://wiki.linaro.org/OfficeofCTO/Schedules/, 
https://wiki.linaro.org/OfficeofCTO/2011-05-24, getting our act together for 
the public plan review

Dave


David Rusling, CTO
http://www.linaro.org

Linaro
Lockton House
Clarendon Rd
Cambridge
CB2 8FH





___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: pulseaudio eating up 100% cpu on i.MX53 QuickStart, anyone has samilar issue?

[Eric Miao]

On Tue, May 24, 2011 at 5:36 PM, Alexander Sack  wrote:
> On Tue, May 24, 2011 at 8:22 AM, Ricardo Salveti
>  wrote:
>> On Tue, May 24, 2011 at 2:04 AM, Eric Miao  wrote:
>>> On Mon, May 23, 2011 at 11:24 AM, Eric Miao  wrote:
 On Sat, May 21, 2011 at 12:39 AM, Kurt Taylor  
 wrote:
> On Fri, May 20, 2011 at 1:44 AM, Eric Miao  wrote:
>> Hi all,
>>
>> When debugging video playback performance issue, we found that 
>> pulseaudio is
>> eating up 100% cpu time. Just in case someone else is having the samilar 
>> issue,
>> please let know.
>
> I have had exactly the opposite findings, typically well below 5% usage.
>
>> We are using ubuntu-desktop, snapshot, found this issue at least w/ 0425 
>> image.
>
> Can you supply more information on the environment, test case, hardware, 
> etc.
>

 It's on i.MX53 QuickStart board, Cortex-A8, 1GHz, 1GB DDR3. A simple launch
 of gstreamer to use pulse sink like below:

 gst-launch audiotestsrc ! pulsesink

 pulseaudio eats 20% CPU.

>>>
>>> Paul found the cause and fix to to this issue,
>>>
>>> http://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/?id=1e2c1467ae042a3c6bb1a6bc0c07aeff13ec5edb
>>
>> Awesome!
>>
>>> Alex,
>>>
>>> Is it possible to merge this before 5/28 release? It's quite critical for
>>> 1080P video playback on i.mx53.
>>
>> We can try to make a SRU for the package and also publish it at the
>> Linaro Overlay, that should cover our images at least.
>
> ack.
>
> SRU probably takes too much time for release, so we should do both,
> but also verify that it does not have any regression for other (LEB)
> boards. Kurt, can you try to get this validated on panda (and beagle)?
>
> For SRU: is there an ubuntu bug for this?
>

Hi David,

Please let know if there is an existing ubuntu bug entry for your patch?

Thanks

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: pulseaudio eating up 100% cpu on i.MX53 QuickStart, anyone has samilar issue?

[David Henningsson]

On 2011-05-24 17:40, Eric Miao wrote:

On Tue, May 24, 2011 at 5:36 PM, Alexander Sack  wrote:

On Tue, May 24, 2011 at 8:22 AM, Ricardo Salveti
  wrote:

On Tue, May 24, 2011 at 2:04 AM, Eric Miao  wrote:

On Mon, May 23, 2011 at 11:24 AM, Eric Miao  wrote:

On Sat, May 21, 2011 at 12:39 AM, Kurt Taylor  wrote:

On Fri, May 20, 2011 at 1:44 AM, Eric Miao  wrote:

Hi all,

When debugging video playback performance issue, we found that pulseaudio is
eating up 100% cpu time. Just in case someone else is having the samilar issue,
please let know.


I have had exactly the opposite findings, typically well below 5% usage.


We are using ubuntu-desktop, snapshot, found this issue at least w/ 0425 image.


Can you supply more information on the environment, test case, hardware, etc.



It's on i.MX53 QuickStart board, Cortex-A8, 1GHz, 1GB DDR3. A simple launch
of gstreamer to use pulse sink like below:

gst-launch audiotestsrc ! pulsesink

pulseaudio eats 20% CPU.



Paul found the cause and fix to to this issue,

http://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/?id=1e2c1467ae042a3c6bb1a6bc0c07aeff13ec5edb


Awesome!


Alex,

Is it possible to merge this before 5/28 release? It's quite critical for
1080P video playback on i.mx53.


We can try to make a SRU for the package and also publish it at the
Linaro Overlay, that should cover our images at least.


ack.

SRU probably takes too much time for release, so we should do both,
but also verify that it does not have any regression for other (LEB)
boards. Kurt, can you try to get this validated on panda (and beagle)?

For SRU: is there an ubuntu bug for this?



Hi David,

Please let know if there is an existing ubuntu bug entry for your patch?

Thanks



It's bug 644644. It should be in Natty already, and I provided a debdiff 
for SRU into Maverick more than a month ago, I would like someone to 
sponsor it some time soon...


644644 is actually two patches, both to help performance, one in 
PulseAudio and one in GStreamer.


That said, the actual patch for Gstreamer was later reverted upstream 
for reasons I don't understand / agree with.


--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: The need for more verbose work item updates

[Dave Martin]

On Tue, May 24, 2011 at 04:04:11PM +0100, Peter Maydell wrote:
> On 24 May 2011 15:21, Alexandros Frantzis
>  wrote:
> > in some of the blueprints I am following, I have noticed that many work
> > items updates (e.g. to DONE/POSTPONED/BLOCKED) are not accompanied by
> > any additional information.  Of course, not all work items need
> > more information, but some are meaningless to an external viewer
> > without it.
> 
> Perhaps we could improve the tools to encourage this/make it easier?
> 
> For instance, the work item format could be improved to let you add
> accompanying commentary to items rather than insisting on a strict
> one-line-only approach. As you say, you can add stuff at the top of
> the whiteboard, but that gets a bit messy and hard to cross-reference.
> 
> If work items were officially supported as a launchpad/blueprint
> feature then you could design the UI to encourage the addition
> of a little commentary when a work item is ticked off.
> 
> Proper support for named and timestamped comments (like bug reports
> have) might also help.

It really feels like it could be time to promote the work items
to a real entity in launchpad.  Has this been discussed before?

Many of the things we seem to want (ability to attach metadata,
a proper audit trail, ability to mine) are natural database
features, so it seems unfortunate that this all has to be achieved
with scripts and obscurely formatted text buried inside text fields
in launchpad.

But this situation has existed for a long time, so maybe it's
not so simple as that... ?

> 
> > In conclusion, I would like to encourage more verbosity in our updates,
> > so that others can easily follow and appreciate all the great work that
> > we are doing.

As a bodge, you can add extra text to the work item itself
when changing its state, though this will quickly get unwieldy.

---Dave

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Linaro Porting Jam tomorrow!

[Riku Voipio]

Hi,

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

Interested in making the software in Ubuntu run better on ARM? Join us on
the #linaro channel on irc.linaro.org tomorrow!

Cheers,
Riku

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Linaro Porting Jam tomorrow!

[Guilherme Salgado]

On Tue, 2011-05-24 at 20:47 +0300, Riku Voipio wrote:
> Hi,
> 
> 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
> 

Some people have noticed that there's a bug in Launchpad which
occasionally causes searches by tag to timeout[1], but it looks like
limiting the number of results per page avoids that timeout. To do so,
just append an extra "&batch=20" to the URL above:

 https://bugs.launchpad.net/ubuntu/+bugs?field.tag=arm-porting-queue&batch=20

[1] https://launchpad.net/bugs/735977

-- 
Guilherme Salgado 


signature.asc
Description: This is a digitally signed message part
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: The need for more verbose work item updates

[James Westby]

On Tue, 24 May 2011 18:36:18 +0100, Dave Martin  wrote:
> It really feels like it could be time to promote the work items
> to a real entity in launchpad.  Has this been discussed before?

Many times.

It's not something that the Launchpad team is likely to work on at all
this year, even if there was consensus on what should be done.

The Infastructure team could work on it, if it is high enough priority,
but it doesn't seem to me that we have reached that point yet.

A better solution may be to stop using the whiteboards and just have
everyone manipulate status.linaro.org directly. That's a fair chunk of
work itself though, and again it needs to be high enough priority to
beat out other things.

In addition, I'm wary of adding lots of extra features to workitems, as
I feel they tend to be symptomatic of trying to load up engineers with
too much process. We should always be careful to balance the desire for
more information with the overhead that it causes. You can say that the
features are optional, but having them there will always push people
towards using them.

Thanks,

James

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: pulseaudio eating up 100% cpu on i.MX53 QuickStart, anyone has samilar issue?

[Kurt Taylor]

On Tue, May 24, 2011 at 4:36 AM, Alexander Sack  wrote:
> On Tue, May 24, 2011 at 8:22 AM, Ricardo Salveti
>  wrote:
>> On Tue, May 24, 2011 at 2:04 AM, Eric Miao  wrote:
>>> On Mon, May 23, 2011 at 11:24 AM, Eric Miao  wrote:
 On Sat, May 21, 2011 at 12:39 AM, Kurt Taylor  
 wrote:
> On Fri, May 20, 2011 at 1:44 AM, Eric Miao  wrote:
>> Hi all,
>>
>> When debugging video playback performance issue, we found that 
>> pulseaudio is
>> eating up 100% cpu time. Just in case someone else is having the samilar 
>> issue,
>> please let know.
>
> I have had exactly the opposite findings, typically well below 5% usage.
>
>> We are using ubuntu-desktop, snapshot, found this issue at least w/ 0425 
>> image.
>
> Can you supply more information on the environment, test case, hardware, 
> etc.
>

 It's on i.MX53 QuickStart board, Cortex-A8, 1GHz, 1GB DDR3. A simple launch
 of gstreamer to use pulse sink like below:

 gst-launch audiotestsrc ! pulsesink

 pulseaudio eats 20% CPU.

>>>
>>> Paul found the cause and fix to to this issue,
>>>
>>> http://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/?id=1e2c1467ae042a3c6bb1a6bc0c07aeff13ec5edb
>>
>> Awesome!
>>
>>> Alex,
>>>
>>> Is it possible to merge this before 5/28 release? It's quite critical for
>>> 1080P video playback on i.mx53.
>>
>> We can try to make a SRU for the package and also publish it at the
>> Linaro Overlay, that should cover our images at least.
>
> ack.
>
> SRU probably takes too much time for release, so we should do both,
> but also verify that it does not have any regression for other (LEB)
> boards. Kurt, can you try to get this validated on panda (and beagle)?


Rob or Wei can you help validate the fix for this problem? See above
defect and 644644 ->
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/644644

>
> For SRU: is there an ubuntu bug for this?
>
>
> --
>
>  - Alexander
>

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Minutes from platform leads call 2011-05-24

[Fathi Boudra]

Hi,

Available at https://wiki.linaro.org/Platform/2011-05-24

== Attendees ==

 * Alexander Sack (asac)
 * Fathi Boudra (fabo)
 * Ilias Biris (ibiris)
 * James Westby (james_w)
 * Paul Larson (plars)
 * Ricardo Salveti (rsalveti)
 * Zach Pfeffer (pfefferz)

== Blueprints drafting and review ==

 * rsalveti: it's going well. a review could start tomorrow.
 * ACTION: rsalveti/asac/fabo to review the blueprints (4PM UTC).

 * plars: he needs to review the drafts of the team members.
 * ACTION: plars/asac/fabo to review the blueprints (3PM UTC).

 * james_w: everything on track.
 * ACTION: james/asac/fabo to review the blueprints (1PM UTC).

 * pfefferz: he created work items. Some WIs are missing.
 * ACTION: pfefferz/asac/fabo to review the blueprints (2PM UTC).

== Public plan review discussion ==

 * REMINDER: slides should be sent to the TSC one week before the PPR
(2011-05-30).

 * Q: how to handle cross team dependencies?
 * e.g. validation and infrastructure are sharing TRs or android

 * Q: organization by TR or team?
 * A: team. TL presents team planned work.

 * ACTION: james to make a chart how the cross team TRs lead to
individual team work.

 * AGREED: share a common format for the presentation to get a
consistent layout across the platform teams. listing TRs, sorted by
priority.
 * ACTION: whoever finishes first few slides to send around to agree
on common format/layout. DEADLINE: 2011-05-25

== Release ==

 * rsalveti: going well but some issues to fix.
  * final kernel for 11.05 to deliver
  * memory missing caused by device tree
  * omap3-X11 hwpack misrenders LP: #787054

 * ACTION: fabo to mention the memory issue on the release notes.

 * asac: release LEB for panda only. Ubuntu and Android should refer
to latest stable release for LEB platforms and to latest daily for LEB
platforms.

 * ACTION: fabo to update the main website download page.

 * plars: validation team is going to release the source code for their work.
 * james_w: infrastructure is going to release the source code for their work.

 * ACTION: plars/james/asac/fabo to plan when and how. The discussion
will continue after 11.05 release.

 * asac: presentation of the release website layout proposal.

 * ACTION: fabo to send a mail presenting the layout and get feedback.

Cheers,

Fathi
-- 
Linaro Release Manager   |   Platform Project Manager

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: The need for more verbose work item updates

[Zach Pfeffer]

My solution to this is to file a bug and link it to the BP if it needs
more than one line of info. This seems to work because anything that
needs more than one line is probably not 2 days of work - which is
what should go in the BP (which is my understanding). The bugs get
picked up by status, so it all seems to work out.

On 24 May 2011 13:55, James Westby  wrote:
> On Tue, 24 May 2011 18:36:18 +0100, Dave Martin  
> wrote:
>> It really feels like it could be time to promote the work items
>> to a real entity in launchpad.  Has this been discussed before?
>
> Many times.
>
> It's not something that the Launchpad team is likely to work on at all
> this year, even if there was consensus on what should be done.
>
> The Infastructure team could work on it, if it is high enough priority,
> but it doesn't seem to me that we have reached that point yet.
>
> A better solution may be to stop using the whiteboards and just have
> everyone manipulate status.linaro.org directly. That's a fair chunk of
> work itself though, and again it needs to be high enough priority to
> beat out other things.
>
> In addition, I'm wary of adding lots of extra features to workitems, as
> I feel they tend to be symptomatic of trying to load up engineers with
> too much process. We should always be careful to balance the desire for
> more information with the overhead that it causes. You can say that the
> features are optional, but having them there will always push people
> towards using them.
>
> Thanks,
>
> James
>
> ___
> linaro-dev mailing list
> linaro-dev@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
>

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Minutes from platform leads call 2011-05-24

[Michael Hope]

On Wed, May 25, 2011 at 7:19 AM, Fathi Boudra  wrote:
> Hi,
>
> Available at https://wiki.linaro.org/Platform/2011-05-24
>  * AGREED: share a common format for the presentation to get a
> consistent layout across the platform teams. listing TRs, sorted by
> priority.
>  * ACTION: whoever finishes first few slides to send around to agree
> on common format/layout. DEADLINE: 2011-05-25

I'd like to do the same.  Could you send me a copy please?

-- Michael

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: The need for more verbose work item updates

[Michael Hope]

On Wed, May 25, 2011 at 2:21 AM, Alexandros Frantzis
 wrote:
> Hi all,
>
> in some of the blueprints I am following, I have noticed that many work
> items updates (e.g. to DONE/POSTPONED/BLOCKED) are not accompanied by
> any additional information.  Of course, not all work items need
> more information, but some are meaningless to an external viewer
> without it.
>
> This is a general observation across Linaro and I am as guilty as any.
> As an example, consider the following (semi-fictional) work item
> updates:
>
> + Add Qt tracing support for pixmaps: POSTPONED
> + Create a bazaar branch for libX: DONE
> + Select and port an application to GLES2: DONE
> + Test that the application functions correctly on ARM: BLOCKED
>
> These updates raise many questions:
>  * Why was Qt tracing for pixmaps postponed?
>  * What is the exact location of the published branch?
>  * Which application was selected for porting?
>  * Where can I find the ported code for the application?
>  * Why is the application test blocked?
>
> Such information is usually placed at the top of the whiteboard, like
> this (at least this is how I am doing it):
>
> [alf May 8]: Postponed work on Qt pixmap tracing because it turned
> out we can trace Qt/Webkit without it, so it is not considered critical 
> anymore.
> [alf May 10]: Uploaded branch to lp:libX
> [alf May 10]: Selected application Y for porting to GLES2
> [alf May 12]: Finished porting Y to GLES2 and uploaded it to
> http://git.linaro.org/...
> [alf May 13]: Blocked on testing the ported application Y because of an
> issue (LP: #66) with the 3D drivers for chipset Z.

I've been thinking of using square bracket footnotes to add a bit more
detail to things:

---
Work items:
Design extension foo[1]: TODO
Add support for Thumb-2: DONE
Add to project bar[2]: POSTPONED

[1] will involve the kernel guys.  Need to start this early.
[2] postponed as it's been merged with blueprint X for next cycle.
---

To bikeshed a bit, I prefer sortable dates with the year like 2011-05-25.

-- Michael

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: The need for more verbose work item updates

[Peter Maydell]

On 24 May 2011 20:31, Zach Pfeffer  wrote:
> My solution to this is to file a bug and link it to the BP if it needs
> more than one line of info. This seems to work because anything that
> needs more than one line is probably not 2 days of work - which is
> what should go in the BP (which is my understanding). The bugs get
> picked up by status, so it all seems to work out.

I found trying to link bugs to blueprints didn't work very well
for me/qemu, so I'm avoiding it this cycle:
 * the linked bugs are listed in a different part of the blueprint
   page to the work items, so the todo list for the blueprint isn't
   in one convenient list
 * you can't mark a bug as 'postponed' to the next cycle (short
   of marking it wontfix) so you have to just unlink it, which
   means the entry just vanishes from the blueprint and status
 * also as you imply it's easy for a single linked bug to hide a
   big chunk of non-broken-down work

But I think the underlying thing I was hitting was that my bugs
were generally user-reported ones that came in randomly during
the cycle, so often only tenuously connected to the blueprints
anyway. So linking bugs might well work better for the approach
you suggest.

-- PMM

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: The need for more verbose work item updates

[Wookey]

+++ James Westby [2011-05-24 14:55 -0400]:

> In addition, I'm wary of adding lots of extra features to workitems, as
> I feel they tend to be symptomatic of trying to load up engineers with
> too much process. We should always be careful to balance the desire for
> more information with the overhead that it causes. 

Very true.

I don't like blueprints either. Indeed I find them approximately
useless and just another annoying thing one has to update from time to
time along with weekly reports, etc. So far as I can tell they aren't
for engineers - they are for managers to track progress, so from that
point of view the current system does at least have the benefit of
simplicity.

Making them more complicated _might_ make them more useful (which
would encourage updating if engineers found them useful for day-to-day
work), but more likely it'd just make them more tiresome to update,
but still essentially uninteresting.

I'm afraid I don't know what the 'right' answer is, but I'm not
convinced that 'more emphasis on, and process encoded in, blueprints' is it.

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: The need for more verbose work item updates

[Zygmunt Krynicki]

W dniu 24.05.2011 20:55, James Westby pisze:

On Tue, 24 May 2011 18:36:18 +0100, Dave Martin  wrote:

It really feels like it could be time to promote the work items
to a real entity in launchpad.  Has this been discussed before?


Many times.

It's not something that the Launchpad team is likely to work on at all
this year, even if there was consensus on what should be done.


And this is why we should not keep being stuck with Launchpad.


The Infastructure team could work on it, if it is high enough priority,
but it doesn't seem to me that we have reached that point yet.

A better solution may be to stop using the whiteboards and just have
everyone manipulate status.linaro.org directly. That's a fair chunk of
work itself though, and again it needs to be high enough priority to
beat out other things.


Or we could just deploy Redmine and wait, less painfully, till Launchpad 
becomes a better productivity suite for teams of developers that are NOT 
working on a distribution.



In addition, I'm wary of adding lots of extra features to workitems, as
I feel they tend to be symptomatic of trying to load up engineers with
too much process. We should always be careful to balance the desire for
more information with the overhead that it causes. You can say that the
features are optional, but having them there will always push people
towards using them.


While I agree with you completely about not throwing too much process at 
developers I need to stress not having a first-class work item "object" 
means we have no real tool, just a gimmick.


We should absolutely have work item history, we should also be allowed 
to "grow" from a simple one-line work item to something more resembling 
real tasks, with comments, code references, rich state changes, full 
history and participation of any number of people.


I know I'm biased here but Redmine provided all of that one year ago 
when we started and it still does today. Let's use it! It has all the 
right APIs for talking to status.linaro.org so we could retain our 
custom tools.


(shameless advertisement below)

If anyone is interested in Redmine (or just heard of it now) feel free 
to access my personal instance at http://fracture.suxx.pl/. In 
particular I would encourage *everyone* to look at my work item 
"rooster" at: http://fracture.suxx.pl/rb/taskboards/11


Each item there is a full-fledged task with all the features of a 
"launchpad bug" and more. I can just drag them around to indicate I'm 
done working on something. I can click on the task number to access the 
full rich state. If anyone is interested in _experimenting_ with this 
feel free to sign-in with your launchpad and either start a new project 
or ping me for being added to a group to work on validation projects).


Note: Redmine is not perfect by any means but it's hands down _better_ 
at solving blueprints + work items than Launchpad ever was.


Best regards
Zygmunt Krynicki.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: http git access?

[James Westby]

On Sat, 14 May 2011 23:45:35 +0200, Jeremiah Foster 
 wrote:
> It certainly is technically possible. The git-http-backend file allows
> one to use http and https as transports. Whoever is the admin for the
> Linaro git repos would need to make some changes to the apache config
> files for the git repo. See
> http://www.kernel.org/pub/software/scm/git/docs/git-http-backend.html
> and http://progit.org/2010/03/04/smart-http.html

Hi,

Thanks to Eric Miao and Paul Collins this is now enabled on
git.linaro.org and gitweb should now be publishing the http urls too.

Would someone please test and let me know the outcome of that test?

Thanks,

James

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: OMAP3 IGEPv2: kworker/0:0:1030 blocked on latest snapshots

[Christian Robottom Reis]

On Mon, May 23, 2011 at 09:51:04AM -0600, John Rigby wrote:
> I have only seen this with the wireless problem already noted.  Can
> you see if blacklisting the wireless driver fixes the problem?

Hmmm. What wireless problem?

> echo blacklist wl12xx_sdio > /etc/modeprobe.d/blacklist-wireless.conf
> reboot

The IGEPv2 doesn't use wl12xx; it uses the libertas (it's got a Marvell
88w8686 onboard).

Just to be clear, wifi works fine on this device, out of the box.

Isn't there a way to trigger a backtrace or dump of the hung kworker task?

PS: I just boot-tested the latest 1003 kernel and it's working fine; in
fact, I now get a flashing green light when the box is on, whereas
before I used to get a dead led. The U-Boot issues I pointed out earlier
are still there, though.
-- 
Christian Robottom Reis   | [+55] 16 9112 6430 | http://launchpad.net/~kiko
Linaro Engineering VP | [ +1] 612 216 4935 | http://async.com.br/~kiko

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Boot sanity testing of release candidate kernel

[Deepak Saxena]

Hi all,

The Kernel Working Group is getting ready to release the first of our new
monthly development snapshot in a few days and we would like folks
to do some quick sanity boot testing on their boards. Please
grab or update the kernel from
git://git.linaro.org/kernel/linux-linaro-2.6.38.git,
and checkout the linaro-11.05-2.6.38 tag (which happens to be same
as master at this moment) and give it a quick spin. Note that this is just
the stock Linaro kernel and does not include any binary graphics drivers
or other bits provided by Linaro's landing team kernels, so we just
need the basic build and boot tested along with some simple
testing of devices that can be used w/o extra drivers.

Thanks!
~Deepak

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Usefulness of GCC's 64bit __sync_* ops on ARM

[Nicolas Pitre]

On Tue, 24 May 2011, Michael Hope wrote:

> On Tue, May 24, 2011 at 10:33 AM, Michael Casadevall
>  wrote:
> > On 05/19/2011 10:56 AM, David Gilbert wrote:
> >> On 19 May 2011 16:49, Ken Werner  wrote:
> >>> On 05/19/2011 12:40 PM, David Rusling wrote:
> 
>  Is this going to end up in a blueprint?   This is the last loose end of
>  SMP / atomic memory operations work and I'd like to see it happen
> >>>
> >>> Hi,
> >>>
> >>> Yep, there is one (kind of a skeleton) in place at:
> >>> https://blueprints.launchpad.net/linaro-toolchain-misc/+spec/64-bit-sync-primitives
> >>
> >> Which I'll be filling out in the next few days.
> >>
> >> Dave
> >
> > Is there a timeline for this feature? It's been requested by members of
> > the ARM Server Club to have this implemented, and its important that
> > this makes it into the Ubuntu 11.10 release.
> > Michael
> 
> Hi Michael.  The topics for this planning cycle are listed here:
>  https://wiki.linaro.org/Cycles//TechnicalTopics/Toolchain
> 
> 64 bit sync primitives are medium priority so they will be achieved in
> the next six months.
> 
> A draft of what is in whos queue is at:
>  https://wiki.linaro.org/Cycles//TechnicalTopics/Toolchain/Planning
> 
> The primitives are second in Dave's queue so should be started in the
> next three months.

FWIW, here's what the kernel part might look like, i.e. for 
compatibility with pre ARMv6k systems (beware, only compile tested):

diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index e8d8856..53830a7 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -383,7 +383,7 @@ ENDPROC(__pabt_svc)
.endm
 
.macro  kuser_cmpxchg_check
-#if __LINUX_ARM_ARCH__ < 6 && !defined(CONFIG_NEEDS_SYSCALL_FOR_CMPXCHG)
+#if !defined(CONFIG_CPU_32v6K) && !defined(CONFIG_NEEDS_SYSCALL_FOR_CMPXCHG)
 #ifndef CONFIG_MMU
 #warning "NPTL on non MMU needs fixing"
 #else
@@ -392,7 +392,7 @@ ENDPROC(__pabt_svc)
@ perform a quick test inline since it should be false
@ 99.% of the time.  The rest is done out of line.
cmp r2, #TASK_SIZE
-   blhskuser_cmpxchg_fixup
+   blhskuser_cmpxchg64_fixup
 #endif
 #endif
.endm
@@ -797,6 +797,139 @@ __kuser_helper_start:
 /*
  * Reference prototype:
  *
+ * int __kernel_cmpxchgd64(int64_t *oldval, int64_t *newval, int64_t *ptr)
+ *
+ * Input:
+ *
+ * r0 = pointer to oldval
+ * r1 = pointer to newval
+ * r2 = pointer to target value
+ * lr = return address
+ *
+ * Output:
+ *
+ * r0 = returned value (zero or non-zero)
+ * C flag = set if r0 == 0, clear if r0 != 0
+ *
+ * Clobbered:
+ *
+ * r3, flags
+ *
+ * Definition and user space usage example:
+ *
+ * typedef int (__kernel_cmpxchg64_t)(const int64_t *oldval,
+ *const int64_t *newval,
+ *volatile int64_t *ptr);
+ * #define __kernel_cmpxchg64 (*(__kernel_cmpxchg64_t *)0x0f60)
+ *
+ * Atomically store newval in *ptr if *ptr is equal to oldval for user space.
+ * Return zero if *ptr was changed or non-zero if no exchange happened.
+ * The C flag is also set if *ptr was changed to allow for assembly
+ * optimization in the calling code.
+ *
+ * Notes:
+ *
+ *- This routine already includes memory barriers as needed.
+ *
+ *- Due to the length of some sequences, this spans 2 regular kuser
+ *  "slots" so 0x0f80 is not used as a valid entry point.
+ */
+
+__kuser_cmpxchg64: @ 0x0f60
+
+#if defined(CONFIG_NEEDS_SYSCALL_FOR_CMPXCHG)
+
+   /*
+* Poor you.  No fast solution possible...
+* The kernel itself must perform the operation.
+* A special ghost syscall is used for that (see traps.c).
+*/
+   stmfd   sp!, {r7, lr}
+   ldr r7, 1f  @ it's 20 bits
+   swi __ARM_NR_cmpxchg64
+   ldmfd   sp!, {r7, pc}
+1: .word   __ARM_NR_cmpxchg64
+
+#elif defined(CONFIG_CPU_32v6K)
+
+   stmfd   sp!, {r4, r5, r6, r7}
+   ldrdr4, r5, [r0]@ load old val
+   ldrdr6, r7, [r1]@ load new val
+   smp_dmb arm
+1: ldrexd  r0, r1, [r2]@ load current val
+   eorsr3, r0, r4  @ compare with oldval (1)
+   eoreqs  r3, r1, r5  @ compare with oldval (2)
+   strexdeq r3, r6, r7, [r2]   @ store newval if eq
+   teqeq   r3, #1  @ success?
+   beq 1b  @ if no then retry
+   smp_dmb arm
+   rsbsr0, r3, #0  @ set returned val and C flag
+   ldmfd   sp!, {r4, r5, r6, r7}
+   usr_ret lr
+
+#elif !defined(CONFIG_SMP)
+
+#ifdef CONFIG_MMU
+
+   /*
+* The only thing that can break atomicity in this cmpxchg64
+* implementation is either an IRQ or a data abort excep

Re: OMAP3 IGEPv2: kworker/0:0:1030 blocked on latest snapshots

[Ricardo Salveti]

On Tue, May 24, 2011 at 10:03 PM, Christian Robottom Reis
 wrote:
> On Mon, May 23, 2011 at 09:51:04AM -0600, John Rigby wrote:
>> I have only seen this with the wireless problem already noted.  Can
>> you see if blacklisting the wireless driver fixes the problem?
>
> Hmmm. What wireless problem?
>
>> echo blacklist wl12xx_sdio > /etc/modeprobe.d/blacklist-wireless.conf
>> reboot
>
> The IGEPv2 doesn't use wl12xx; it uses the libertas (it's got a Marvell
> 88w8686 onboard).
>
> Just to be clear, wifi works fine on this device, out of the box.
>
> Isn't there a way to trigger a backtrace or dump of the hung kworker task?
>
> PS: I just boot-tested the latest 1003 kernel and it's working fine; in
> fact, I now get a flashing green light when the box is on, whereas
> before I used to get a dead led. The U-Boot issues I pointed out earlier
> are still there, though.

It seems that this issue was fixed with 1003 as soon as we disabled
cpu_freq for both Omap 3 and Omap 4. Didn't confirm, but that would be
the main change regarding Omap 3.

For Omap 4 the wlan driver was also causing similar issues.

Cheers,
-- 
Ricardo Salveti de Araujo

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH v5 0/2] SMDKV310 Board Support

[Chander Kashyap]

Hi,
This patchset adds support for a new board SMDKV310, based on S5PV310 SOC.
This SOC is very similar to S5PC210 SOC, hence we are re-using this SOC code.

Specific changes in patch versions are mentioned in specific patch files.

Chander Kashyap (2):
  ARMV7: Add support for Samsung SMDKV310 Board
  ARMV7: MMC SPL Boot support for SMDKV310 board

 MAINTAINERS|4 +
 Makefile   |   11 +
 board/samsung/smdkv310/Makefile|   46 ++
 board/samsung/smdkv310/lowlevel_init.S |  470 
 board/samsung/smdkv310/mem_setup.S |  365 +++
 board/samsung/smdkv310/smdkv310.c  |  136 ++
 boards.cfg |1 +
 include/configs/smdkv310.h |  169 +++
 mmc_spl/board/samsung/smdkv310/Makefile|  105 +
 mmc_spl/board/samsung/smdkv310/mmc_boot.c  |   85 
 .../board/samsung/smdkv310/tools/mkv310_image.c|  116 +
 mmc_spl/board/samsung/smdkv310/u-boot.lds  |   86 
 12 files changed, 1594 insertions(+), 0 deletions(-)
 create mode 100644 board/samsung/smdkv310/Makefile
 create mode 100644 board/samsung/smdkv310/lowlevel_init.S
 create mode 100644 board/samsung/smdkv310/mem_setup.S
 create mode 100644 board/samsung/smdkv310/smdkv310.c
 create mode 100644 include/configs/smdkv310.h
 create mode 100644 mmc_spl/board/samsung/smdkv310/Makefile
 create mode 100644 mmc_spl/board/samsung/smdkv310/mmc_boot.c
 create mode 100644 mmc_spl/board/samsung/smdkv310/tools/mkv310_image.c
 create mode 100644 mmc_spl/board/samsung/smdkv310/u-boot.lds

-- 
1.7.4.1


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH v5 1/2] ARMV7: Add support for Samsung SMDKV310 Board

[Chander Kashyap]

SMDKV310 board is based on Samsung S5PV310 SOC. This SOC is very much
similar to S5PC210.

Signed-off-by: Chander Kashyap 
Signed-off-by: Tushar Behera 
---
Changes for v2:
- Coding Style Cleanup
- Removed unwanted macros from board config file.
- Ethernet controllor configuration is done using gpio structures.
- MMC Controllor gpio configuration corrected.
- Added MAINTAINERS entry.
- Removed unwanted code from mem_setup.S.
Changes for v3:
- Comment style fixed
- Added New macro in board config file.
Changes for v4:
- Fixed line with more than 80 characters in board config file
 
 MAINTAINERS|4 +
 board/samsung/smdkv310/Makefile|   46 +++
 board/samsung/smdkv310/lowlevel_init.S |  470 
 board/samsung/smdkv310/mem_setup.S |  365 +
 board/samsung/smdkv310/smdkv310.c  |  136 +
 boards.cfg |1 +
 include/configs/smdkv310.h |  169 
 7 files changed, 1191 insertions(+), 0 deletions(-)
 create mode 100644 board/samsung/smdkv310/Makefile
 create mode 100644 board/samsung/smdkv310/lowlevel_init.S
 create mode 100644 board/samsung/smdkv310/mem_setup.S
 create mode 100644 board/samsung/smdkv310/smdkv310.c
 create mode 100644 include/configs/smdkv310.h

diff --git a/MAINTAINERS b/MAINTAINERS
index e2c48a8..a3f6ef2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -702,6 +702,10 @@ Minkyu Kang 
s5p_goniARM ARMV7 (S5PC110 SoC)
s5pc210_universal   ARM ARMV7 (S5PC210 SoC)
 
+Chander Kashyap 
+
+   SMDKV310ARM ARMV7 (S5PC210 SoC)
+
 Frederik Kriewitz 
 
devkit8000  ARM ARMV7 (OMAP3530 SoC)
diff --git a/board/samsung/smdkv310/Makefile b/board/samsung/smdkv310/Makefile
new file mode 100644
index 000..8e9b703
--- /dev/null
+++ b/board/samsung/smdkv310/Makefile
@@ -0,0 +1,46 @@
+#
+# Copyright (C) 2011 Samsung Electronics
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+SOBJS  := mem_setup.o
+SOBJS  += lowlevel_init.o
+COBJS  += smdkv310.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS) $(SOBJS))
+
+all:$(obj).depend $(LIB)
+
+$(LIB):$(OBJS)
+   $(AR) $(ARFLAGS) $@ $(OBJS)
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/samsung/smdkv310/lowlevel_init.S 
b/board/samsung/smdkv310/lowlevel_init.S
new file mode 100644
index 000..359cff4
--- /dev/null
+++ b/board/samsung/smdkv310/lowlevel_init.S
@@ -0,0 +1,470 @@
+/*
+ * Lowlevel setup for SMDKV310 board based on S5PC210
+ *
+ * Copyright (C) 2011 Samsung Electronics
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include 
+#include 
+#include 
+
+/*
+ * Register usages:
+ *
+ * r5 has zero always
+ * r7 has GPIO part1 base 0x1140
+ * r6 has GPIO part2 base 0x1100
+ */
+
+#define MEM_DLLl_ON
+
+_TEXT_BASE:
+   .word   CONFIG_SYS_TEXT_BASE
+
+   .globl lowlevel_init
+lowlevel_init:
+   push{lr}
+
+   /* r5 has always zero */
+   mov r5, #0
+   ldr r7, =S5PC210_GPIO_PART1_BASE
+   ldr r6, =S5PC210_GPIO_PART2_B

[PATCH v5 2/2] ARMV7: MMC SPL Boot support for SMDKV310 board

[Chander Kashyap]

Added MMC SPL boot support for SMDKV310. This framework design is
based on nand_spl support.

Signed-off-by: Chander Kashyap 
---
Changes for v3:
- spl file renamed to u-boot-mmc-spl.bin
- spl directory renamed to mmc_spl
- comments added in mkv310_image.c file
Changes for v5:
- Compilation warning
mmc_boot.c: In function 'board_init_r':
mmc_boot.c:51: warning: 'noreturn' function does return
fixed.

 Makefile   |   11 ++
 mmc_spl/board/samsung/smdkv310/Makefile|  105 ++
 mmc_spl/board/samsung/smdkv310/mmc_boot.c  |   85 ++
 .../board/samsung/smdkv310/tools/mkv310_image.c|  116 
 mmc_spl/board/samsung/smdkv310/u-boot.lds  |   86 +++
 5 files changed, 403 insertions(+), 0 deletions(-)
 create mode 100644 mmc_spl/board/samsung/smdkv310/Makefile
 create mode 100644 mmc_spl/board/samsung/smdkv310/mmc_boot.c
 create mode 100644 mmc_spl/board/samsung/smdkv310/tools/mkv310_image.c
 create mode 100644 mmc_spl/board/samsung/smdkv310/u-boot.lds

diff --git a/Makefile b/Makefile
index 384a59e..25b87b0 100644
--- a/Makefile
+++ b/Makefile
@@ -322,6 +322,10 @@ ALL += $(obj)u-boot-onenand.bin
 ONENAND_BIN ?= $(obj)onenand_ipl/onenand-ipl-2k.bin
 endif
 
+ifeq ($(CONFIG_MMC_U_BOOT),y)
+ALL += $(obj)mmc_spl/u-boot-mmc-spl.bin
+endif
+
 all:   $(ALL)
 
 $(obj)u-boot.hex:  $(obj)u-boot
@@ -413,6 +417,11 @@ onenand_ipl:   $(TIMESTAMP_FILE) $(VERSION_FILE) 
$(obj)include/autoconf.mk
 $(obj)u-boot-onenand.bin:  onenand_ipl $(obj)u-boot.bin
cat $(ONENAND_BIN) $(obj)u-boot.bin > $(obj)u-boot-onenand.bin
 
+mmc_spl:   $(TIMESTAMP_FILE) $(VERSION_FILE) depend
+   $(MAKE) -C mmc_spl/board/$(BOARDDIR) all
+
+$(obj)mmc_spl/u-boot-mmc-spl.bin:  mmc_spl
+
 $(VERSION_FILE):
@( localvers='$(shell $(TOPDIR)/tools/setlocalversion 
$(TOPDIR))' ; \
   printf '#define PLAIN_VERSION "%s%s"\n' \
@@ -1123,6 +1132,7 @@ clean:
@rm -f $(obj)lib/asm-offsets.s
@rm -f $(obj)nand_spl/{u-boot.lds,u-boot-spl,u-boot-spl.map,System.map}
@rm -f $(obj)onenand_ipl/onenand-{ipl,ipl.bin,ipl.map}
+   @rm -f 
$(obj)mmc_spl/{u-boot.lds,u-boot-spl,u-boot-spl.map,u-boot-spl.bin,u-boot-mmc-spl.bin}
@rm -f $(ONENAND_BIN)
@rm -f $(obj)onenand_ipl/u-boot.lds
@rm -f $(TIMESTAMP_FILE) $(VERSION_FILE)
@@ -1147,6 +1157,7 @@ clobber:  clean
@rm -fr $(obj)include/generated
@[ ! -d $(obj)nand_spl ] || find $(obj)nand_spl -name "*" -type l 
-print | xargs rm -f
@[ ! -d $(obj)onenand_ipl ] || find $(obj)onenand_ipl -name "*" -type l 
-print | xargs rm -f
+   @[ ! -d $(obj)mmc_spl ] || find $(obj)mmc_spl -name "*" -type l -print 
| xargs rm -f
 
 ifeq ($(OBJTREE),$(SRCTREE))
 mrproper \
diff --git a/mmc_spl/board/samsung/smdkv310/Makefile 
b/mmc_spl/board/samsung/smdkv310/Makefile
new file mode 100644
index 000..f1ce066
--- /dev/null
+++ b/mmc_spl/board/samsung/smdkv310/Makefile
@@ -0,0 +1,105 @@
+#
+# (C) Copyright 2006-2007
+# Stefan Roese, DENX Software Engineering, s...@denx.de.
+#
+# (C) Copyright 2008
+# Guennadi Liakhovetki, DENX Software Engineering, 
+#
+# (C) Copyright 2011
+# Chander Kashyap, Samsung Electronics, 
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+CONFIG_MMC_SPL = y
+
+include $(TOPDIR)/config.mk
+
+LDSCRIPT= $(TOPDIR)/mmc_spl/board/$(BOARDDIR)/u-boot.lds
+LDFLAGS= -Bstatic -T $(mmcobj)u-boot.lds -Ttext 
$(CONFIG_SYS_TEXT_BASE) $(PLATFORM_LDFLAGS)
+AFLAGS += -DCONFIG_MMC_SPL
+CFLAGS += -DCONFIG_MMC_SPL
+CFLAGS += -DCONFIG_PRELOADER
+
+SOBJS  = start.o mem_setup.o lowlevel_init.o
+COBJS  = mmc_boot.o
+
+SRCS   := $(addprefix $(obj),$(SOBJS:.o=.S) $(COBJS:.o=.c))
+OBJS   := $(addprefix $(obj),$(SOBJS) $(COBJS))
+__OBJS := $(SOBJS) $(COBJS)
+LNDIR  := $(OBJTREE)/mmc_spl/board/$(BOARDDIR)
+
+mmcobj := $(OBJTREE)/mmc_spl/
+
+
+MKV310_MMC_SPL_EXEC = mkv310_mmc_spl_exec
+MMC_SPL_BIN = u-boot-mmc-spl.bin
+
+ALL = $(mmcobj)u-boot-spl $(mmcobj)u-boot-spl.bin $(mmcobj)$(MMC_SPL_BIN)
+
+all:$(obj).depend $(ALL)
+
+$(mmcobj)$(MMC_SPL_BIN):  

Re: http git access?

[Shawn Guo]

On Tue, May 24, 2011 at 06:40:28PM -0400, James Westby wrote:
> On Sat, 14 May 2011 23:45:35 +0200, Jeremiah Foster 
>  wrote:
> > It certainly is technically possible. The git-http-backend file allows
> > one to use http and https as transports. Whoever is the admin for the
> > Linaro git repos would need to make some changes to the apache config
> > files for the git repo. See
> > http://www.kernel.org/pub/software/scm/git/docs/git-http-backend.html
> > and http://progit.org/2010/03/04/smart-http.html
> 
> Hi,
> 
> Thanks to Eric Miao and Paul Collins this is now enabled on
> git.linaro.org and gitweb should now be publishing the http urls too.
> 
> Would someone please test and let me know the outcome of that test?
> 
Seems not working yet for me:

$ git clone http://git.linaro.org/kernel/linux-linaro-2.6.38.git
Cloning into linux-linaro-2.6.38...
fatal: http://git.linaro.org/kernel/linux-linaro-2.6.38.git/info/refs not 
found: did you run git update-server-info on the server?

-- 
Regards,
Shawn


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev