Re: [U-Boot] [PATCH v2 1/2] ARMV7: Add support for Samsung SMDKV310 Board

2011-05-18 Thread Wolfgang Denk 
Dear Minkyu Kang,

In message  you wrote:
>
> > diff --git a/boards.cfg b/boards.cfg
> > index 554e06c..01edb79 100644
> > --- a/boards.cfg
> > +++ b/boards.cfg
...
> Please use space instead of tab.

No!

Indentation / vertical alignment SHALL be done using TABs!

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
While money can't buy happiness, it certainly lets  you  choose  your
own form of misery.

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

Re: [U-Boot] [PATCH v2 1/2] ARMV7: Add support for Samsung SMDKV310 Board

2011-05-18 Thread Wolfgang Denk 
Dear Minkyu Kang,

In message  you wrote:
> 
> Hm, but everyone is using the space on "boards.cfg".

I will eventually run "unexpand -a" on the file again...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
This cultural mystique surrounding the  biological  function  --  you
realize humans are overly preoccupied with the subject.
-- Kelinda the Kelvan, "By Any Other Name", stardate 4658.9

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

Re: [U-Boot] [PATCH] S5P:SROM config code moved to s5p-common directory

2011-05-18 Thread Minkyu Kang 
Dear Wolfgang Denk,

On 17 May 2011 17:46, Wolfgang Denk  wrote:
> Dear Chander Kashyap,
>
> In message <1302843918-1105-1-git-send-email-chander.kash...@linaro.org> you 
> wrote:
>> SROM config code is made common for S5P series of boards.
>> smdkc100.c now refers to s5p-common/sromc.c for SROM related
>> subroutines.
>>
>> Signed-off-by: Chander Kashyap 
>
> It appears this is missing arch/arm/include/asm/arch-s5pc2xx/sromc.h
>
> Please squash with patch submitted here:
>
> 05/17 Minkyu Kang        [U-Boot] [PATCH] S5PC2XX: add the sromc header file
>             http://article.gmane.org/gmane.comp.boot-loaders.u-boot/99965

OK. done.

Thanks
Minkyu Kang
-- 
from. prom.
www.promsoft.net

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

Re: [U-Boot] [PATCH v2 1/2] ARMV7: Add support for Samsung SMDKV310 Board

2011-05-18 Thread Minkyu Kang 
Dear Wolfgang Denk,

On 18 May 2011 16:49, Wolfgang Denk  wrote:
> Dear Minkyu Kang,
>
> In message  you wrote:
>>
>> > diff --git a/boards.cfg b/boards.cfg
>> > index 554e06c..01edb79 100644
>> > --- a/boards.cfg
>> > +++ b/boards.cfg
> ...
>> Please use space instead of tab.
>
> No!
>
> Indentation / vertical alignment SHALL be done using TABs!
>

Hm, but everyone is using the space on "boards.cfg".

Minkyu Kang.
-- 
from. prom.
www.promsoft.net

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

Re: [U-Boot] [PATCH v2 1/2] ARMV7: Add support for Samsung SMDKV310 Board

2011-05-18 Thread Minkyu Kang 
Dear Chander Kashyap,

On 21 April 2011 16:02, Chander Kashyap  wrote:
> 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.
>
>  MAINTAINERS                               |    4 +
>  arch/arm/include/asm/arch-s5pc2xx/sromc.h |   51 +++

This file is added by other patch for fix build error.
Please make this patch.

>  board/samsung/smdkv310/Makefile           |   46 +++
>  board/samsung/smdkv310/lowlevel_init.S    |  577 
> +
>  board/samsung/smdkv310/mem_setup.S        |  365 ++
>  board/samsung/smdkv310/smdkv310.c         |  136 +++
>  boards.cfg                                |    1 +
>  include/configs/smdkv310.h                |  172 +
>  8 files changed, 1352 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm/include/asm/arch-s5pc2xx/sromc.h
>  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/boards.cfg b/boards.cfg
> index 554e06c..01edb79 100644
> --- a/boards.cfg
> +++ b/boards.cfg
> @@ -128,6 +128,7 @@ omap4_sdp4430                arm         armv7       
> sdp4430             ti
>  s5p_goni                     arm         armv7       goni                
> samsung        s5pc1xx
>  smdkc100                     arm         armv7       smdkc100            
> samsung        s5pc1xx
>  s5pc210_universal            arm         armv7       universal_c210      
> samsung        s5pc2xx
> +smdkv310                    arm         armv7       smdkv310            
> samsung        s5pc2xx

Please use space instead of tab.

>  harmony                      arm         armv7       harmony             
> nvidia         tegra2
>  seaboard                     arm         armv7       seaboard            
> nvidia         tegra2
>  actux1                       arm         ixp

Thanks
Minkyu Kang
-- 
from. prom.
www.promsoft.net

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

Re: Better reviews for the same cost in gcc-linaro

2011-05-18 Thread Andrew Stubbs 

On 17/05/11 17:01, Martin Pool wrote:

I wanted to share with you some numbers on our changes in bzr 2.4 (final
in August), based on the much-appreciated feedback from Linaro.The
details are in

but the short story is that local operations like uncommit, revert, and
update take a few seconds rather than the multi-minutes that were
originally reported.  There is still more to do and if you hit other
problems please tell us.


Thanks Martin, those figures are very promising! :)

You say that 2.4 is due in August, but 2.3.2 already shows some useful 
improvements, so can you say when that's likely to be available? I 
believe the PPA stable release is currently still on 2.3.1.


Thanks again

Andrew

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

Re: Gerrit userstory for multi-branch development

2011-05-18 Thread Per Forlin 
On 16 May 2011 17:52, Paul Sokolovsky  wrote:
> Hello Arnd,
>
> I'd like to follow up to the discussion which took place during
> "Android Code Review" session at LDS
> (https://wiki.linaro.org/Platform/Android/Specs/AndroidCodeReview).
>
> You expressed concern that Gerrit is not too flexible for working with
> multiple topic branches, in particular, that it enforces work
> against single (master) branch (as far as I understood).
>
> Well, looking at AOSP's Gerrit instance,
> https://review.source.android.com/ one can see that there's a "branch"
> field present, and shown in the list of patches, and there're patches
> which reference non-master branches (here's list for "froyo" branch
> for example:
> https://review.source.android.com/#q,status:open+branch:froyo,n,z ).
> So, it at least allows to label a patch with a branch it is submitted
> against.
>
> So, can you please elaborate on the concerns you expressed? A
> generalized user story and specific example would be very helpful. (And
> please keep in mind that I still know little about Gerrit, so if the
> above doesn't relate directly to your concerns, I'm sorry, that's why
> I'd like to collect more detailed info on Gerrit's
> features/misfeatures people know).
>
A patch belongs to a branch even in Gerrit.
One user story is moving patches from branch B to branch A. I believe
the only way to handle this in Gerrit is to resubmit as new commits.
Another one is how to perform rebase in Gerrit, reorder/remove/squash
commits on a branch. How is this described in Gerrit?

Regards,
Per

> ___
> 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: [U-Boot] [PATCH v2 2/2] ARMV7: MMC SPL Boot support for SMDKV310 board

2011-05-18 Thread Chander Kashyap 
Dear Minkyu Kang,

On 17 May 2011 13:56, Minkyu Kang  wrote:
> Dear Chander Kashyap,
>
> Sorry to late review.
>
> On 21 April 2011 16:02, Chander Kashyap  wrote:
>> Added MMC SPL boot support for SMDKV310. This framework design is
>> based on nand_spl support.
>>
>> Signed-off-by: Chander Kashyap 
>> ---
>>  Makefile                                        |    9 ++
>>  spl/board/samsung/smdkv310/Makefile             |  103 
>> +++
>>  spl/board/samsung/smdkv310/mmc_boot.c           |   82 ++
>>  spl/board/samsung/smdkv310/tools/mkv310_image.c |  103 
>> +++
>>  spl/board/samsung/smdkv310/u-boot.lds           |   86 +++
>>  5 files changed, 383 insertions(+), 0 deletions(-)
>>  create mode 100644 spl/board/samsung/smdkv310/Makefile
>>  create mode 100644 spl/board/samsung/smdkv310/mmc_boot.c
>>  create mode 100644 spl/board/samsung/smdkv310/tools/mkv310_image.c
>>  create mode 100644 spl/board/samsung/smdkv310/u-boot.lds
>>
>> diff --git a/Makefile b/Makefile
>> index 713dba1..a298221 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -321,6 +321,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)spl/v310_mmc_spl.bin
>
> NAK.
> This naming is SoC specific.
Renamed to u-boot-mmc-spl.bin
> And binary is should be located in root directory, I think..
> e.g) ALL += $(obj)u-boot-mmc.bin
I think, as this in spl  image in addition to u-boot image it should
be in mmc_spl directory.

>> +endif
>> +
>>  all:           $(ALL)
>>
>>  $(obj)u-boot.hex:      $(obj)u-boot
>> @@ -412,6 +416,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
>>
>> +spl:           $(TIMESTAMP_FILE) $(VERSION_FILE) depend
>
> mmc_spl is better.
done
>
>> +               $(MAKE) -C spl/board/$(BOARDDIR) all
>> +
>> +$(obj)spl/v310_mmc_spl.bin:    spl
>> +
>>  $(VERSION_FILE):
>>                @( localvers='$(shell $(TOPDIR)/tools/setlocalversion 
>> $(TOPDIR))' ; \
>>                   printf '#define PLAIN_VERSION "%s%s"\n' \
>
> And you missed clean and clobber sections.
Added the same.
>
>> diff --git a/spl/board/samsung/smdkv310/Makefile 
>> b/spl/board/samsung/smdkv310/Makefile
>> new file mode 100644
>> index 000..fdede6b
>> --- /dev/null
>> +++ b/spl/board/samsung/smdkv310/Makefile
>> @@ -0,0 +1,103 @@
>> +#
>> +# (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)/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
>
> Please add -DCONFIG_PRELOADER also.
Testing with this option
>
>> +
>> +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)/spl/board/$(BOARDDIR)
>> +
>> +mmcobj := $(OBJTREE)/spl/
>> +
>> +
>> +MKBIN_V310_MMC_SPL_BIN = mkv310_mmc_spl_bin
>> +MMC_SPL_BIN = v310_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):  $(mmcobj)u-boot-spl.bin 
>> tools/$(MKBIN_V310_MMC_SPL_BIN)
>> +       ./tools/$(MKBIN_V310_MMC_SPL_BIN) $(mmcobj)u-boot-spl.bin 
>> $(mmcobj)$(MMC_SPL_BIN)
>> +
>> +tools/$(MKBIN_V310_MMC_SPL_BIN): tools/mkv310_image.c
>> +       $(HOSTCC) tools/mkv310_image.c -o tools/$(MKBIN_V310_MMC_SPL_BIN)
>> +
>> +$(mmcobj)u-boot-spl.bin:       $(mmcobj)u-boot-spl
>> +       $(OBJCOPY) ${

Re: Better reviews for the same cost in gcc-linaro

2011-05-18 Thread Martin Pool 
On 18 May 2011 10:23, Andrew Stubbs  wrote:
> On 17/05/11 17:01, Martin Pool wrote:
>>
>> I wanted to share with you some numbers on our changes in bzr 2.4 (final
>> in August), based on the much-appreciated feedback from Linaro.    The
>> details are in
>> 
>> but the short story is that local operations like uncommit, revert, and
>> update take a few seconds rather than the multi-minutes that were
>> originally reported.  There is still more to do and if you hit other
>> problems please tell us.
>
> Thanks Martin, those figures are very promising! :)
>
> You say that 2.4 is due in August, but 2.3.2 already shows some useful
> improvements, so can you say when that's likely to be available? I believe
> the PPA stable release is currently still on 2.3.1.

2.3.3 is now in ppa:bzr/proposed
 just waiting for a bit
of smoke testing before it goes into the main ppa, probably next week.
 If you would like to install from there and let us know whether there
are any regressions or not that would be great.

It will probably also go into maverick-updates in the next couple of
weeks.  

Martin

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

Re: Gerrit userstory for multi-branch development

2011-05-18 Thread Linus Walleij 
2011/5/16 Paul Sokolovsky :

> You expressed concern that Gerrit is not too flexible for working with
> multiple topic branches, in particular, that it enforces work
> against single (master) branch (as far as I understood).

It was mainly me blathering about Gerrit in that session so don't
go after Arnd...

I take a step back: there is nothing technical wrong with
Gerrit really, the problem is how it is used.

And the problem is that Gerrit is often used (also by Google)
as a one-stop shop for integration.

This means: you don't have what the kernel developers refer
to as topic branches. Instead, in the Google case, look for
example here:

http://android.git.kernel.org/?p=kernel/experimental.git;a=summary
(...)
4 months agoandroid-goldfish-2.6.35
7 months agoandroid-msm-2.6.35-wip
8 months agolinux-tegra-2.6.36-wip
10 months ago   android-2.6.34-test2

These are indeed branches, but *what* is the topic
actually?

Well, it turs out the topic is: "branch to rebase an big
whole shebang mega-patchset on top of a new kernel
upstream realease".

That's not what kernel developers mean by "topic branch".
which is for example:
http://git.kernel.org/?p=linux/kernel/git/tip/linux-2.6-tip.git;a=summary

With examples like this it is not strange that Gerrit is
used as it is in companies doing Android development.

I think it basically boils down to the fact that a single
Gerrit branch is seen as "the place to integrate", whereas
in kernel terms, you should integrate a single topic
(such as "i2c updates", "boardfiles", "regulators" etc)
and the system integrator should use plain git (no web
interface!) to integrate the result with an octopus merge
to produce a complete product. The result of the
octopus merge should be frozen, i.e. it is not allowed
to be used as a starting point for further development.

On most companies where I know the details, nobody
even has a clue what an octopus merge is. Eevrything
is integrated in Gerrit directly, on a single branch.

One reason is that I think you have to configure Gerrit
for each new branch you create or delete, and that
means a real bad fit with the kernel model of quickly
creating/deleting and rebasing branches.

So: Gerrit is indeed a good review system and has the
ability to use (topic) branches. But the examples from
companies like Google are not very good models of
what to do with them.

Now there may be a reason why everything is still
integrated on a single branch, and that is
cross-subsystem dependency hell. If all drivers you
develop are cross-dependent on other drivers, you
end up in this place, such as you want to develop a
driver for I2C peripheral X but you don't have a driver
for the I2C bus yet (and a hundre times more complex
examples). What you need to do in that case is
to create  new topic branch based on top of the
i2c-driver topic branch and so on, and then you have
to use just git, using Gerrit at the same time will
make it necessary to add/remove/rebase branches at
neckbreaking speed. If you just use a singe branch
the integration seems simpler to the organization.

Yours,
Linus Walleij

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

Re: Gerrit userstory for multi-branch development

2011-05-18 Thread Patrik Ryd 
On 18 May 2011 13:07, Linus Walleij  wrote:

> 2011/5/16 Paul Sokolovsky :
>
> > You expressed concern that Gerrit is not too flexible for working with
> > multiple topic branches, in particular, that it enforces work
> > against single (master) branch (as far as I understood).
>
> It was mainly me blathering about Gerrit in that session so don't
> go after Arnd...
>
> I take a step back: there is nothing technical wrong with
> Gerrit really, the problem is how it is used.
>
> And the problem is that Gerrit is often used (also by Google)
> as a one-stop shop for integration.
>
> This means: you don't have what the kernel developers refer
> to as topic branches. Instead, in the Google case, look for
> example here:
>
> http://android.git.kernel.org/?p=kernel/experimental.git;a=summary
> (...)
> 4 months agoandroid-goldfish-2.6.35
> 7 months agoandroid-msm-2.6.35-wip
> 8 months agolinux-tegra-2.6.36-wip
> 10 months ago   android-2.6.34-test2
>
> These are indeed branches, but *what* is the topic
> actually?
>
> Well, it turs out the topic is: "branch to rebase an big
> whole shebang mega-patchset on top of a new kernel
> upstream realease".
>
> That's not what kernel developers mean by "topic branch".
> which is for example:
> http://git.kernel.org/?p=linux/kernel/git/tip/linux-2.6-tip.git;a=summary
>
> With examples like this it is not strange that Gerrit is
> used as it is in companies doing Android development.
>
> I think it basically boils down to the fact that a single
> Gerrit branch is seen as "the place to integrate", whereas
> in kernel terms, you should integrate a single topic
> (such as "i2c updates", "boardfiles", "regulators" etc)
> and the system integrator should use plain git (no web
> interface!) to integrate the result with an octopus merge
> to produce a complete product. The result of the
> octopus merge should be frozen, i.e. it is not allowed
> to be used as a starting point for further development.
>

If we have gerrit, build servers and test farm set up and we have managed to
get the whole continuous integration process going is there the anything
that prevents that we push to a topic branch for review and that the first
step before the build starts it to do a merge of all topic branches for the
kernel.


> On most companies where I know the details, nobody
> even has a clue what an octopus merge is. Eevrything
> is integrated in Gerrit directly, on a single branch.
>
> One reason is that I think you have to configure Gerrit
> for each new branch you create or delete, and that
> means a real bad fit with the kernel model of quickly
> creating/deleting and rebasing branches.
>

Branches are "configured" in the same way as in git. :) You do a git push to
the branch you want to create. The difference is that when you do your git
push gerrit will check if you have the permission to create branches.

 /Patrik

>
> So: Gerrit is indeed a good review system and has the
> ability to use (topic) branches. But the examples from
> companies like Google are not very good models of
> what to do with them.
>
> Now there may be a reason why everything is still
> integrated on a single branch, and that is
> cross-subsystem dependency hell. If all drivers you
> develop are cross-dependent on other drivers, you
> end up in this place, such as you want to develop a
> driver for I2C peripheral X but you don't have a driver
> for the I2C bus yet (and a hundre times more complex
> examples). What you need to do in that case is
> to create  new topic branch based on top of the
> i2c-driver topic branch and so on, and then you have
> to use just git, using Gerrit at the same time will
> make it necessary to add/remove/rebase branches at
> neckbreaking speed. If you just use a singe branch
> the integration seems simpler to the organization.
>
> Yours,
> Linus Walleij
>
> ___
> 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: Bootchart analysis

2011-05-18 Thread Dave Martin 
Hi,

On Tue, May 17, 2011 at 5:53 PM, Tom Gall  wrote:
> Hi All,
>
> From UDS last week I was inspired to run bootchart on our Linaru
> Ubuntu-desktop LEB.
>
> I collected the data on my panda board using the daily snapshot from last 
> week.
>
> From a very quick examination of the output, it would seem we are IO bound.
>
> I've created a quick wiki page about BootChart and attached the data
> I've gathered.
>
> https://wiki.linaro.org/BootChart

Interesting.

Due to the poor I/O throughput, it looks a bit like we might be
hitting the known SD card write behaviour issues; mounting with
noatime and/or journaling disabled (noload for ext4) might also make a
difference.

I wonder how a rotary disk attached to USB would compare...

---Dave

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

Re: Bootchart analysis

2011-05-18 Thread Christian Robottom Reis 
On Wed, May 18, 2011 at 02:53:22PM +0100, Dave Martin wrote:
> Hi,
> 
> On Tue, May 17, 2011 at 5:53 PM, Tom Gall  wrote:
> > Hi All,
> >
> > From UDS last week I was inspired to run bootchart on our Linaru
> > Ubuntu-desktop LEB.
> >
> > I collected the data on my panda board using the daily snapshot from last 
> > week.
> >
> > From a very quick examination of the output, it would seem we are IO bound.
> >
> > I've created a quick wiki page about BootChart and attached the data
> > I've gathered.
> >
> > https://wiki.linaro.org/BootChart
> 
> Interesting.
> 
> Due to the poor I/O throughput, it looks a bit like we might be
> hitting the known SD card write behaviour issues; mounting with
> noatime and/or journaling disabled (noload for ext4) might also make a
> difference.

Um, why are we writing to anything on boot up?

(Or is it an artifact of recording the BootChart data?)
-- 
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

Re: Bootchart analysis

2011-05-18 Thread Riku Voipio 
On 18 May 2011 16:53, Dave Martin  wrote:
> On Tue, May 17, 2011 at 5:53 PM, Tom Gall  wrote:

>> https://wiki.linaro.org/BootChart

> Due to the poor I/O throughput, it looks a bit like we might be
> hitting the known SD card write behaviour issues; mounting with
> noatime and/or journaling disabled (noload for ext4) might also make a
> difference.

The long time of "mount" looks fishy. Are you sure you are booting
with a clean filesystem?

Other than that we see that

1) we start too much (cron, gdm, ...) for our use case
2) too many shells started to parse shell scripts

As for finding files writes to on boot, using a "find / -mtime -2" or
some variation to pick up files modified since boot is easiest.

___
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

2011-05-18 Thread Dave Martin 
On Tue, May 17, 2011 at 5:30 PM, Nicolas Pitre  wrote:
> On Tue, 17 May 2011, Dave Martin wrote:
>
>> On Fri, May 6, 2011 at 10:39 PM, Nicolas Pitre  
>> wrote:
>> > On Fri, 6 May 2011, Ramana Radhakrishnan wrote:
>> >
>> >> On 6 May 2011 16:06, Ken Werner  wrote:
>> >> >
>> >> > Currently the GCC ARM backend doesn't provide a pattern to inline 64bit
>> >> > __sync_* functions but the compiler emits __sync_*_8 function calls 
>> >> > [1]. The
>> >> > libgcc does not provide these symbols via the usual thin wrapper around 
>> >> > the
>> >> > kernel helper [2] because the ARM Linux __kernel_cmpxchg supports 32bit 
>> >> > only.
>> >> > My understanding is that for ARMv7 the GCC backend could be enhanced to 
>> >> > inline
>> >> > the __sync_* functions by using the LDREXD and STREXD instructions. But 
>> >> > for
>> >> > ARMv5 we would still rely on a new kernel helper.
>> >>
>> >> It's a bit tricky with when you want to use the kernel helper for v5t,
>> >> so we've got to find a way of turning this on only with special knobs
>> >> and not by default and that's a bit tricky.
>> >
>> > What is the problem with v5t?
>> >
>> >> Think new user space and old kernel and a jump into never-never land.
>> >
>> > The kernel helpers are "versioned".  At 0x0ffc you can read the
>> > number of helpers currently available.  If a program uses a new helper
>> > then when it is started this value can be verified to equal or exceed
>> > the expected value and bail out otherwise.
>>
>> To what extent do we think that userspace code is actually checking this?
>
> I think right now it is none of it simply because most of the helpers
> were added almost all at once.  But if future helpers are added then it
> would be a good idea to check this but only if the new helper is
> actually invoked for a given application.
>
>> I may suggest a patch to the documentation text in entry-armv.S to
>> make this requirement clearer, as well as getting rid of the example
>> assembler code (which I consider to be mis-educative, but more
>> importantly it's also Thumb-incompatible and will likely suffer poor
>> branch-prediction on recent CPUs.
>
> If you have suggestions for improving this then please do so.

I have a patch which I'll suggest at some point, but it's not high priority.

>
>> This code was the source of a TLS
>> bug in bionic, and may have been inappropriately pasted elsewhere
>> too...)
>
> What bug?

Actually, to be fair I think I may be mis-remembering here... I can't
seem to find the exact bug now.

Cheers
---Dave

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

Re: Bootchart analysis

2011-05-18 Thread Dave Martin 
On Wed, May 18, 2011 at 3:32 PM, Christian Robottom Reis
 wrote:
> On Wed, May 18, 2011 at 02:53:22PM +0100, Dave Martin wrote:
>> Hi,
>>
>> On Tue, May 17, 2011 at 5:53 PM, Tom Gall  wrote:
>> > Hi All,
>> >
>> > From UDS last week I was inspired to run bootchart on our Linaru
>> > Ubuntu-desktop LEB.
>> >
>> > I collected the data on my panda board using the daily snapshot from last 
>> > week.
>> >
>> > From a very quick examination of the output, it would seem we are IO bound.
>> >
>> > I've created a quick wiki page about BootChart and attached the data
>> > I've gathered.
>> >
>> > https://wiki.linaro.org/BootChart
>>
>> Interesting.
>>
>> Due to the poor I/O throughput, it looks a bit like we might be
>> hitting the known SD card write behaviour issues; mounting with
>> noatime and/or journaling disabled (noload for ext4) might also make a
>> difference.
>
> Um, why are we writing to anything on boot up?

I'm just guessing there might be _some_ writes -- from atime updates,
logfile writes and corresponding journal writes for example -- and if
so there then it may be having a significant impact.  We could check
the actual I/O to be sure.

On graphical login, various daemons may scribble in dot dirs and
databases -- find -mmin could help here.

>
> (Or is it an artifact of recording the BootChart data?)

Possible ... I would hope that the boothchart data goes into a ramfs
to avoid that.  Worth checking, though.

Cheers
---Dave

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

Re: Bootchart analysis

2011-05-18 Thread Dave Martin 
On Wed, May 18, 2011 at 3:39 PM, Riku Voipio  wrote:
> On 18 May 2011 16:53, Dave Martin  wrote:
>> On Tue, May 17, 2011 at 5:53 PM, Tom Gall  wrote:
>
>>> https://wiki.linaro.org/BootChart
>
>> Due to the poor I/O throughput, it looks a bit like we might be
>> hitting the known SD card write behaviour issues; mounting with
>> noatime and/or journaling disabled (noload for ext4) might also make a
>> difference.
>
> The long time of "mount" looks fishy. Are you sure you are booting
> with a clean filesystem?
>
> Other than that we see that
>
> 1) we start too much (cron, gdm, ...) for our use case
> 2) too many shells started to parse shell scripts

perf can do system-wide profiling to find how much time is spent in
different libraries / binaries.

---Dave

>
> As for finding files writes to on boot, using a "find / -mtime -2" or
> some variation to pick up files modified since boot is easiest.
>

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

Re: Bootchart analysis

2011-05-18 Thread Constantine Shulyupin 
> The long time of "mount" looks fishy. Are you sure you are booting
> with a clean filesystem?
>
> Other than that we see that
>
> 1) we start too much (cron, gdm, ...) for our use case
> 2) too many shells started to parse shell scripts
>
> As for finding files writes to on boot, using a "find / -mtime -2" or
> some variation to pick up files modified since boot is easiest.

You can also to keep rootfs read only (ro in cmdline and don't remount
it with rw) to track redundant writes.


-- 
Constantine Shulyupin
http://www.MakeLinux.com/
Embedded Linux Systems,
Device Drivers, TI DaVinci

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

Re: Gerrit userstory for multi-branch development

2011-05-18 Thread Linus Walleij 
2011/5/18 Patrik Ryd :
> On 18 May 2011 13:07, Linus Walleij  wrote:
>> I think it basically boils down to the fact that a single
>> Gerrit branch is seen as "the place to integrate", whereas
>> in kernel terms, you should integrate a single topic
>> (such as "i2c updates", "boardfiles", "regulators" etc)
>> and the system integrator should use plain git (no web
>> interface!) to integrate the result with an octopus merge
>> to produce a complete product. The result of the
>> octopus merge should be frozen, i.e. it is not allowed
>> to be used as a starting point for further development.
>
> If we have gerrit, build servers and test farm set up and we have managed to
> get the whole continuous integration process going is there the anything
> that prevents that we push to a topic branch for review and that the first
> step before the build starts it to do a merge of all topic branches for the
> kernel.

Well occasionally there are merge conflicts. Which need
to be resolved manually :-P

But there is nothing stopping you from testing each topic
branch in isolation I guess. The problem appears when
you want to continously test "the whole product", i.e. a
mergedown of all topic branches.

So in this particular case the agile programming axiom to
always have a running build every night clashes with the
idea of working in isolated topic branches - the former
really benefit from all integration being done on a single
branch.

>> One reason is that I think you have to configure Gerrit
>> for each new branch you create or delete, and that
>> means a real bad fit with the kernel model of quickly
>> creating/deleting and rebasing branches.
>
> Branches are "configured" in the same way as in git. :) You do a git push to
> the branch you want to create. The difference is that when you do your git
> push gerrit will check if you have the permission to create branches.

Yes I was completely wrong on this, Gerrit is really flexible
with branches, Ian Kumlien also taught me this...

Thanks,
Linus Walleij

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

Re: Bootchart analysis

2011-05-18 Thread Wookey 
+++ Christian Robottom Reis [2011-05-18 11:32 -0300]:
> On Wed, May 18, 2011 at 02:53:22PM +0100, Dave Martin wrote:
> > Hi,
> 
> Um, why are we writing to anything on boot up?

Daemons writing their pids to /var/run, is one example. One advantage of
plan to move /run to root and make it a tmpfs.

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: Bootchart analysis

2011-05-18 Thread Ricardo Salveti 
On Wed, May 18, 2011 at 11:39 AM, Riku Voipio  wrote:
> On 18 May 2011 16:53, Dave Martin  wrote:
>> On Tue, May 17, 2011 at 5:53 PM, Tom Gall  wrote:
>
>>> https://wiki.linaro.org/BootChart
>
>> Due to the poor I/O throughput, it looks a bit like we might be
>> hitting the known SD card write behaviour issues; mounting with
>> noatime and/or journaling disabled (noload for ext4) might also make a
>> difference.
>
> The long time of "mount" looks fishy. Are you sure you are booting
> with a clean filesystem?
>
> Other than that we see that
>
> 1) we start too much (cron, gdm, ...) for our use case

That's because we're using the ubuntu-netbook task, that brings a lot
of additional daemons.

> 2) too many shells started to parse shell scripts

I can see a lot of 'sh', 'cat', 'rm', 'sleep', 'run-parts', I think
this could all be optimized.

> As for finding files writes to on boot, using a "find / -mtime -2" or
> some variation to pick up files modified since boot is easiest.

Yeah, would be good to see what was actually changed at the
filesystem. Having the bootchart with a usb driver can also help
comparing the results.

Cheers,
-- 
Ricardo Salveti de Araujo

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

approaching a final kernel for 11.05

2011-05-18 Thread John Rigby 
Thanks to the heroic efforts of rsalveti the packaged
linux-linaro-omap kernel now greatly improved omap4 display
functionality.  There is a .deb in the linaro-maintainers kernel ppa.
If you have a panda board and have time to try it out your feedback
would be much appreciated:

https://launchpad.net/~linaro-maintainers/+archive/kernel/+files/linux-image-2.6.38-1003-linaro-omap_2.6.38-1003.4~ppa2_armel.deb

--john

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

[NOTES] Linaro Developer Platform Weekly Status Meeting 5/18

2011-05-18 Thread Tom Gall 
Enclosed you'll find a link to the agenda, notes and actions from the
Linaro Developer Platforms Weekly Status meeting held on May 18th
in #linaro-meeting on irc.freenode.net at 15:00 UTC.

https://wiki.linaro.org/Platform/DevPlatform/Meetings/2011-05-18

New Actions:
* None

Regards,
Tom
Developer Platforms Team

"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
IRC) Dr_Who, tgall_foo

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

Re: approaching a final kernel for 11.05

2011-05-18 Thread Ricardo Salveti 
On Wed, May 18, 2011 at 3:31 PM, John Rigby  wrote:
> Thanks to the heroic efforts of rsalveti the packaged
> linux-linaro-omap kernel now greatly improved omap4 display
> functionality.  There is a .deb in the linaro-maintainers kernel ppa.
> If you have a panda board and have time to try it out your feedback
> would be much appreciated:
>
> https://launchpad.net/~linaro-maintainers/+archive/kernel/+files/linux-image-2.6.38-1003-linaro-omap_2.6.38-1003.4~ppa2_armel.deb

This kernel should bring a lot of improvements for OMAP 4, like better
wlan, drm driver, hdmi audio and some other interesting fixes.

We should now be at least as good as the current Ubuntu kernel.

Please give it a try and let us know if you face any issue with it.

Thanks,
-- 
Ricardo Salveti de Araujo

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

[STATUS] Android Platform Team 2011-05-18

2011-05-18 Thread Zach Pfeffer 
See:

https://wiki.linaro.org/Platform/Android/Status/2011-05-18

Highlights:

1. Android Panda LEB GFX being debugged.
2. Android BPs getting defined and work-items drafted.
3. Finishing validation integration.
4. Need Android PoC's from all landing teams and WGs.

-Zach

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

Re: approaching a final kernel for 11.05

2011-05-18 Thread Christian Robottom Reis 
On Wed, May 18, 2011 at 05:58:22PM -0300, Ricardo Salveti wrote:
> On Wed, May 18, 2011 at 3:31 PM, John Rigby  wrote:
> > Thanks to the heroic efforts of rsalveti the packaged
> > linux-linaro-omap kernel now greatly improved omap4 display
> > functionality.  There is a .deb in the linaro-maintainers kernel ppa.
> > If you have a panda board and have time to try it out your feedback
> > would be much appreciated:
> >
> > https://launchpad.net/~linaro-maintainers/+archive/kernel/+files/linux-image-2.6.38-1003-linaro-omap_2.6.38-1003.4~ppa2_armel.deb
> 
> This kernel should bring a lot of improvements for OMAP 4, like better
> wlan, drm driver, hdmi audio and some other interesting fixes.

Is it built from Andy's TILT tree or Nico's upstream tree? If the
latter, then wow, how did TI get all this stuff upstreamable so soon?
-- 
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

Re: approaching a final kernel for 11.05

2011-05-18 Thread Nicolas Pitre 
On Wed, 18 May 2011, Christian Robottom Reis wrote:

> On Wed, May 18, 2011 at 05:58:22PM -0300, Ricardo Salveti wrote:
> > On Wed, May 18, 2011 at 3:31 PM, John Rigby  wrote:
> > > Thanks to the heroic efforts of rsalveti the packaged
> > > linux-linaro-omap kernel now greatly improved omap4 display
> > > functionality.  There is a .deb in the linaro-maintainers kernel ppa.
> > > If you have a panda board and have time to try it out your feedback
> > > would be much appreciated:
> > >
> > > https://launchpad.net/~linaro-maintainers/+archive/kernel/+files/linux-image-2.6.38-1003-linaro-omap_2.6.38-1003.4~ppa2_armel.deb
> > 
> > This kernel should bring a lot of improvements for OMAP 4, like better
> > wlan, drm driver, hdmi audio and some other interesting fixes.
> 
> Is it built from Andy's TILT tree or Nico's upstream tree? If the
> latter, then wow, how did TI get all this stuff upstreamable so soon?

I trust this is going to be upstreamed, or made upstreamable, by all the 
parties involved in the near future.  In the mean time this work from 
Ricardo makes the Panda kernel a bit more useful without breaking 
support for Beagle (or so I'm told).

Of course this stuff _not_ being all in mainline yet means that this 
integration work will have to be done again when linaro-2.6.39 is 
opened (hint hint).


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

reorganzing the lava projects on launchpad

2011-05-18 Thread Michael Hudson-Doyle 
Hi there,

Some of you know about this already as it was discussed a bit at LDS,
but probably not very inclusively.

We have a slightly strange arrangement of projects on Launchpad, with
the main ones being "launch-control" and "lava".  AIUI, Zygmunt really
wanted to call "launch-control" "dashboard" from day 1, but that was
clearly an overly generic name.  Since then, we've come up with the
"lava" name to cover our automated validation efforts, but currently the
"lava" project just contains code to do with the validation farm in
Cambridge, which is only part of the story.

So.  We have a plan to reorganize the projects like so (also documented on
https://blueprints.launchpad.net/linaro-validation-misc/+spec/linaro-platforms-o-reorganize-lava-projects):

 - lava -- project group containing:
   - lava-server -- contains the django settings file and templates
 - this well mostly be extracted from what is lp:launch-control today
   - lava-scheduler -- django application for scheduling jobs
 - what exists for this is in lp:lava currently
   - lava-dispatcher -- tool that runs tests on hardware
 - this is also in lp:lava currently
   - lava-dashboard -- django application for showing test results
 - this is lp:launch-control currently
   - lava-tool -- command line entry point and framework
 - this actually exists already and has the right name!
   - lava-dashboard-tool
 - new name for launch-control-tool
   - lava-test-tool -- plugin for lava-tool that adds commands for running tests
 - new name and refactoring for abrek
   - lava-auth-tool -- plugin for lava-tool that adds commands for 
authenticating against validation.linaro.org
   - lava-scheduler-tool -- plugin for lava-tool that adds commands for 
interacting with the scheduler
 - these last two don't actually exist yet

It's possible there are too many lava-tool plugins here, but we can see
how that goes when it comes to implementing those bits.

There will be a certain amount of churn and broken links during the
reorganization, so this is mostly a heads up and apologies in advance.
Bike shedding on the details of the rearrangement will probably be
ignored :)

I'll probably do this on Monday morning my time, which should be nice
and quiet.

Cheers,
mwh

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