Re: [PATCH] ARM: S5P: Fix compilation error for exynos4_defconfig
Hi Marek, Thanks for your review. On Friday 03 June 2011 11:23 AM, Marek Szyprowski wrote: Hello, On Friday, June 03, 2011 7:07 AM Tushar Behera wrote: EHCI requires that USB support be enabled in kernel config. Selecting USB_SUPPORT with S5P_DEV_USB_EHCI fixes the problem. Signed-off-by: Tushar Behera --- arch/arm/plat-s5p/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-s5p/Kconfig b/arch/arm/plat-s5p/Kconfig index e98f5c5..c7e7419 100644 --- a/arch/arm/plat-s5p/Kconfig +++ b/arch/arm/plat-s5p/Kconfig @@ -87,6 +87,7 @@ config S5P_DEV_CSIS1 config S5P_DEV_USB_EHCI bool + select USB_SUPPORT IMHO this is not the best way to solve this issue. The main problem is the fact that usb-phy.c file depends on CONFIG_USB_SUPPORT not it's own Kconfig entry. Please check arch/arm/mach-exynos4/Makefile. To match the style of other helper functions, usb-phy.c should be renamed to setup-usb-phy.c and get it's own Kconfig entry like CONFIG_EXYNOS4_SETUP_USB_PHY. Also the machine that uses it should select this new entry. This is really not related to CONFIG_USB_SUPPORT at all (one might want to have a kernel without USB support for some reason). Ok. I will re-submit the patch. help Compile in platform device definition for USB EHCI -- Best regards -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The linaro-2.6.39 kernel repository is now alive
On Thu, Jun 2, 2011 at 8:55 PM, Nicolas Pitre wrote: > On Thu, 2 Jun 2011, John Rigby wrote: > >> I noticed all the fine AndyDoan/Ricardo fixes that make panda >> wonderful are missing. My question now is should that stuff go back >> in or should we plan on a LT/BSP kernel for full functionality. I >> presume if those patches were headed upstream they would be headed >> upstream:). If not they they should not be in linux-linaro. > > This is the strategy of this game. If it isn't going upstream you lose. > > In practice this means that AndyDoan/Ricardo will have to do their work > again on top of this tree, and then I might merge it. Yup, that's the plan. I believe Rob Clark is targeting the DRM changes for OMAP for 3.1, so I'll check with him and rebase the patches to be in a better shape for upstream. Once done will send the pull request to Nicolas. Cheers, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH] ARM: S5P: Fix compilation error for exynos4_defconfig
Hi, Typo error in writing the mailing address during git-send-email .. hence resending. -- Tushar Original Message Subject: [PATCH] ARM: S5P: Fix compilation error for exynos4_defconfig Date: Fri, 3 Jun 2011 10:37:19 +0530 From: Tushar Behera To: linux-samsung-...@vger.kernel.org CC: linaro-...@linaro.org, kgene@samsung.com, nicolas.pi...@linaro.org, patc...@linaro.org, jy0922.s...@samsung.com EHCI requires that USB support be enabled in kernel config. Selecting USB_SUPPORT with S5P_DEV_USB_EHCI fixes the problem. Signed-off-by: Tushar Behera --- arch/arm/plat-s5p/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-s5p/Kconfig b/arch/arm/plat-s5p/Kconfig index e98f5c5..c7e7419 100644 --- a/arch/arm/plat-s5p/Kconfig +++ b/arch/arm/plat-s5p/Kconfig @@ -87,6 +87,7 @@ config S5P_DEV_CSIS1 config S5P_DEV_USB_EHCI bool + select USB_SUPPORT help Compile in platform device definition for USB EHCI -- 1.7.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH] SMDKV310: MMC_SPL: Fix building when using "make O="
Fixes dependency build error with "make O=" option. "make O=" option is used to specify output directory. Signed-off-by: Chander Kashyap --- mmc_spl/board/samsung/smdkv310/Makefile | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/mmc_spl/board/samsung/smdkv310/Makefile b/mmc_spl/board/samsung/smdkv310/Makefile index f1ce066..d4d7ad7 100644 --- a/mmc_spl/board/samsung/smdkv310/Makefile +++ b/mmc_spl/board/samsung/smdkv310/Makefile @@ -40,7 +40,7 @@ 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)) +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS)) __OBJS := $(SOBJS) $(COBJS) LNDIR := $(OBJTREE)/mmc_spl/board/$(BOARDDIR) @@ -76,25 +76,25 @@ $(mmcobj)u-boot.lds: $(LDSCRIPT) # create symbolic links for common files # from cpu directory -$(obj)start.S: +start.S: @rm -f $@ @ln -s $(TOPDIR)/arch/arm/cpu/armv7/start.S $@ # from board directory -$(obj)mem_setup.S: +mem_setup.S: @rm -f $@ @ln -s $(TOPDIR)/board/samsung/smdkv310/mem_setup.S $@ -$(obj)lowlevel_init.S: +lowlevel_init.S: @rm -f $@ @ln -s $(TOPDIR)/board/samsung/smdkv310/lowlevel_init.S $@ # -$(obj)%.o: $(obj)%.S +$(obj)%.o: %.S $(CC) $(AFLAGS) -c -o $@ $< -$(obj)%.o: $(obj)%.c +$(obj)%.o: %.c $(CC) $(CFLAGS) -c -o $@ $< # defines $(obj).depend target -- 1.7.4.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The linaro-2.6.39 kernel repository is now alive
On 2 June 2011 21:39, Christian Robottom Reis wrote: > On Thu, Jun 02, 2011 at 09:01:01PM -0500, Zach Pfeffer wrote: >> On 2 June 2011 18:55, Nicolas Pitre wrote: >> > On Thu, 2 Jun 2011, John Rigby wrote: >> > >> >> I noticed all the fine AndyDoan/Ricardo fixes that make panda >> >> wonderful are missing. My question now is should that stuff go back >> >> in or should we plan on a LT/BSP kernel for full functionality. I >> >> presume if those patches were headed upstream they would be headed >> >> upstream:). If not they they should not be in linux-linaro. >> > >> > This is the strategy of this game. If it isn't going upstream you lose. >> >> First, please don't take offense to this feedback. I know kernel >> banter can have a harsh undertone. >> >> I'd like to suggest this kind of feedback isn't appropriate. The >> issues concerning what can't be upstreamed are well known. > > Zach, in this case, Nicolas is completely right. The task within the > Kernel WG is to maintain a consolidation tree with a pretty clear > criteria of carrying only upstreamable patches. When the tree is > rebased, the patches that aren't upstream (and not trivially portable, > AIUI) get dropped, and the authors need to refresh them. > > The job of maintaining a working consolidation tree is already hard > enough. Let's not make it any harder. > > (And I don't find tone inappropriate at all, but maybe that's because I > can see his well-meaning grin when I read it ) Yeah. I see that now. I'm sorry for not getting clarification. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The linaro-2.6.39 kernel repository is now alive
On 2 June 2011 22:12, Nicolas Pitre wrote: > On Thu, 2 Jun 2011, Zach Pfeffer wrote: > >> On 2 June 2011 18:55, Nicolas Pitre wrote: >> > On Thu, 2 Jun 2011, John Rigby wrote: >> > >> >> I noticed all the fine AndyDoan/Ricardo fixes that make panda >> >> wonderful are missing. My question now is should that stuff go back >> >> in or should we plan on a LT/BSP kernel for full functionality. I >> >> presume if those patches were headed upstream they would be headed >> >> upstream:). If not they they should not be in linux-linaro. >> > >> > This is the strategy of this game. If it isn't going upstream you lose. >> >> First, please don't take offense to this feedback. I know kernel >> banter can have a harsh undertone. > > Am I really harsh? Perhaps not. The 'you lose' comment kind of struck a cord with me. Its hard to tell tone in a email though. >> I'd like to suggest this kind of feedback isn't appropriate. The >> issues concerning what can't be upstreamed are well known. > > I'm not talking about what can't be upstreamed. I'm talking about what > _can_ be upstreamed and still isn't. Sure. I was reacting to the 'you lose' comment. I thought, "well I don't lose, maybe I need to try again, but I'd like some constructive feedback." >> > In practice this means that AndyDoan/Ricardo will have to do their work >> > again on top of this tree, and then I might merge it. >> >> I'd like to further suggest that in the interest of cooperation that >> we take a more constructive tone. We're all going to need to work >> closely to accomplish our goals of upstreaming support for these >> boards and unifying implementations. > > Isn't that what we're all doing? > > Anyway I don't understand why you need to talk about "constructive tone" > here, unless you read something different in my words than I actually > meant. But mind you, that wouldn't be the first time this happened to > me. Yeah. I think I just read the above you lose comment wrong. I'm sorry for jumping to conclusions and not asking you privately about it. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The linaro-2.6.39 kernel repository is now alive
On Thu, 2 Jun 2011, Zach Pfeffer wrote: > On 2 June 2011 18:55, Nicolas Pitre wrote: > > On Thu, 2 Jun 2011, John Rigby wrote: > > > >> I noticed all the fine AndyDoan/Ricardo fixes that make panda > >> wonderful are missing. My question now is should that stuff go back > >> in or should we plan on a LT/BSP kernel for full functionality. I > >> presume if those patches were headed upstream they would be headed > >> upstream:). If not they they should not be in linux-linaro. > > > > This is the strategy of this game. If it isn't going upstream you lose. > > First, please don't take offense to this feedback. I know kernel > banter can have a harsh undertone. Am I really harsh? > I'd like to suggest this kind of feedback isn't appropriate. The > issues concerning what can't be upstreamed are well known. I'm not talking about what can't be upstreamed. I'm talking about what _can_ be upstreamed and still isn't. > > In practice this means that AndyDoan/Ricardo will have to do their work > > again on top of this tree, and then I might merge it. > > I'd like to further suggest that in the interest of cooperation that > we take a more constructive tone. We're all going to need to work > closely to accomplish our goals of upstreaming support for these > boards and unifying implementations. Isn't that what we're all doing? Anyway I don't understand why you need to talk about "constructive tone" here, unless you read something different in my words than I actually meant. But mind you, that wouldn't be the first time this happened to me. Confused. Nicolas___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The linaro-2.6.39 kernel repository is now alive
On Thu, Jun 02, 2011 at 09:01:01PM -0500, Zach Pfeffer wrote: > On 2 June 2011 18:55, Nicolas Pitre wrote: > > On Thu, 2 Jun 2011, John Rigby wrote: > > > >> I noticed all the fine AndyDoan/Ricardo fixes that make panda > >> wonderful are missing. My question now is should that stuff go back > >> in or should we plan on a LT/BSP kernel for full functionality. I > >> presume if those patches were headed upstream they would be headed > >> upstream:). If not they they should not be in linux-linaro. > > > > This is the strategy of this game. If it isn't going upstream you lose. > > First, please don't take offense to this feedback. I know kernel > banter can have a harsh undertone. > > I'd like to suggest this kind of feedback isn't appropriate. The > issues concerning what can't be upstreamed are well known. Zach, in this case, Nicolas is completely right. The task within the Kernel WG is to maintain a consolidation tree with a pretty clear criteria of carrying only upstreamable patches. When the tree is rebased, the patches that aren't upstream (and not trivially portable, AIUI) get dropped, and the authors need to refresh them. The job of maintaining a working consolidation tree is already hard enough. Let's not make it any harder. (And I don't find tone inappropriate at all, but maybe that's because I can see his well-meaning grin when I read it ) -- 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: The linaro-2.6.39 kernel repository is now alive
On 2 June 2011 19:01, Zach Pfeffer wrote: > On 2 June 2011 18:55, Nicolas Pitre wrote: >> On Thu, 2 Jun 2011, John Rigby wrote: >> >>> I noticed all the fine AndyDoan/Ricardo fixes that make panda >>> wonderful are missing. My question now is should that stuff go back >>> in or should we plan on a LT/BSP kernel for full functionality. I >>> presume if those patches were headed upstream they would be headed >>> upstream:). If not they they should not be in linux-linaro. >> >> This is the strategy of this game. If it isn't going upstream you lose. > > First, please don't take offense to this feedback. I know kernel > banter can have a harsh undertone. > > I'd like to suggest this kind of feedback isn't appropriate. The > issues concerning what can't be upstreamed are well known I think the issues are well known but if developers are not working on cleaning up the code to make it upstreamable, we have to continue to push back and provide them whatever guidance is needed on how to make it acceptable until they get it upstream. Until it is upstream, the developers of out-of-tree code need to be 100% responsible for rebasing and moving their code forward to newer kernels or there's no motivation for developers to change their ways. By they I don't mean to single out Andy/Ricardo in anyway, this applies to anyone developing code that is meant to go into the linaro-linux base kernel. ~Deepak ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The linaro-2.6.39 kernel repository is now alive
On 2 June 2011 18:55, Nicolas Pitre wrote: > On Thu, 2 Jun 2011, John Rigby wrote: > >> I noticed all the fine AndyDoan/Ricardo fixes that make panda >> wonderful are missing. My question now is should that stuff go back >> in or should we plan on a LT/BSP kernel for full functionality. I >> presume if those patches were headed upstream they would be headed >> upstream:). If not they they should not be in linux-linaro. > > This is the strategy of this game. If it isn't going upstream you lose. First, please don't take offense to this feedback. I know kernel banter can have a harsh undertone. I'd like to suggest this kind of feedback isn't appropriate. The issues concerning what can't be upstreamed are well known. > In practice this means that AndyDoan/Ricardo will have to do their work > again on top of this tree, and then I might merge it. I'd like to further suggest that in the interest of cooperation that we take a more constructive tone. We're all going to need to work closely to accomplish our goals of upstreaming support for these boards and unifying implementations. > Nicolas > > ___ > linaro-kernel mailing list > linaro-ker...@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-kernel > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[ANNOUNCE] dh_splitpackage 0.1
Hello everyone. I wrote dh_splitpackage, a helper script that unambiguously splits the files of a binary package into multiple packages based on a configuration file. The configuration file may point the primary package (the one that gets leftover files by default) as well as any number of additional packages with any number of inclusion and exclusion patterns. The new script can be called instead of dh_install (assuming all the files you are interested in are already in debian/tmp/) or afterwards. The biggest advantage compared to existing tools is clear and not-that-error-prone classification of files to packages. Any file that would be classified to more than one package (hitting patterns in both files) is clearly reported and prevents the package from building properly. In addition running the script displays each file from debian/tmp and the package it was classified to. Using this script could greatly simplify many packages that currently rely on numerous *.install files and custom dh_install overrides in debian/rules. You can find the code at lp:~zkrynicki/+junk/dh_splitpackage (tag: release-0.1) The source tree also includes debian packaging that makes use of the new script. Best regards Zygmunt Krynicki ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The linaro-2.6.39 kernel repository is now alive
On Thu, 2011-06-02 at 01:12 -0400, Nicolas Pitre wrote: > Time to leave 2.6.38 behind and move on! We now have a 2.6.39 based > Linaro kernel which can be viewed here: > > http://git.linaro.org/gitweb?p=kernel/linux-linaro-2.6.39.git;a=summary > > or cloned from either of those: > > git://git.linaro.org/kernel/linux-linaro-2.6.39.git > > http://git.linaro.org/git/kernel/linux-linaro-2.6.39.git > > This will continue to evolve as this is just the beginning for that > tree, so more stuff will be merged. Only smoke tested on a Dove board, > and compile tested for OMAP so far. Hit a compile issue with your tree: drivers/video/omap2/dss/dpi.c: In function 'dpi_set_dsi_clk': drivers/video/omap2/dss/dpi.c:61: error: implicit declaration of function 'dsi_pll_calc_clock_div_pck' drivers/video/omap2/dss/dpi.c:66: error: implicit declaration of function 'dsi_pll_set_clock_div' drivers/video/omap2/dss/dpi.c: In function 'omapdss_dpi_display_enable': drivers/video/omap2/dss/dpi.c:192: error: implicit declaration of function 'dsi_pll_init' drivers/video/omap2/dss/dpi.c:209: error: implicit declaration of function 'dsi_pll_uninit' Looks like enabling CONFIG_OMAP2_DSS_DPI tries to access bits only available with CONFIG_OMAP2_DSS_DSI enabled. Vanilla 2.6.39 doesn't seem to have this issue. thanks -john ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The linaro-2.6.39 kernel repository is now alive
On Thu, 2 Jun 2011, John Rigby wrote: > I noticed all the fine AndyDoan/Ricardo fixes that make panda > wonderful are missing. My question now is should that stuff go back > in or should we plan on a LT/BSP kernel for full functionality. I > presume if those patches were headed upstream they would be headed > upstream:). If not they they should not be in linux-linaro. This is the strategy of this game. If it isn't going upstream you lose. In practice this means that AndyDoan/Ricardo will have to do their work again on top of this tree, and then I might merge it. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The linaro-2.6.39 kernel repository is now alive
I noticed all the fine AndyDoan/Ricardo fixes that make panda wonderful are missing. My question now is should that stuff go back in or should we plan on a LT/BSP kernel for full functionality. I presume if those patches were headed upstream they would be headed upstream:). If not they they should not be in linux-linaro. On the config issue, I am going to strip down the omap config to be closer to the others. I want to make the different flavours more consistant with one another and the default kernel configs. I intend to only turn on stuff required to be "Ubuntu". Once I have something we will test and see if anyone notices stuff missing (like a parallel port driver:). John On Thu, Jun 2, 2011 at 2:40 PM, Andy Doan wrote: > On 06/02/2011 12:12 AM, Nicolas Pitre wrote: > >> This will continue to evolve as this is just the beginning for that >> tree, so more stuff will be merged. Only smoke tested on a Dove board, >> and compile tested for OMAP so far. >> > > I just tried some testing of my Overo with the omap2plus_defconfig and > my hack for what John Rigby uses for Linaro builds. > > The "Linaro config" produces a compiler error. I'm assuming the config > will be changing, so I haven't really looked into patching the issue. > John - let me know if this is something you need my help with. > > The omap2plus_defconfig comes up but I'm not getting DVI video and I'm > also seeing these problems from the kernel: > > Uncompressing Linux... done, booting the kernel. > [ 0.00] Linux version 2.6.39-00910-g3818181-dirty > (doanac@storage) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu3) ) #4 > SMP Thu Jun 2 14:43:32 CDT 2011 > [ 0.00] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), > cr=10c53c7f > [ 0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing > instruction cache > [ 0.00] Machine: Gumstix Overo > [ 0.00] Reserving 12582912 bytes SDRAM for VRAM > [ 0.00] Memory policy: ECC disabled, Data cache writeback > [ 0.00] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp ) > [ 0.00] SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x1 > [ 0.00] Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz > [ 0.00] Reprogramming SDRC clock to 33200 Hz > [ 0.00] PERCPU: Embedded 7 pages/cpu @c0f85000 s8160 r8192 d12320 > u32768 > [ 0.00] Built 1 zonelists in Zone order, mobility grouping on. > Total pages: 126976 > [ 0.00] Kernel command line: console=ttyO2,115200n8 mpurate=720 > vram=12M omapfb.mode=dvi:1024x768MR-16@60 omapfb.debug=y > omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait > > > > [ 0.228179] Registering NAND on CS0 > [ 0.231536] Could not obtain gpio for TS PenDown: -16 > [ 0.231567] kobject (c05eae78): tried to init an initialized object, > something is seriously wrong. > [ 0.231628] [] (unwind_backtrace+0x0/0xe0) from > [] (kobject_init+0x34/0x90) > [ 0.231689] [] (kobject_init+0x34/0x90) from [] > (device_initialize+0x20/0x90) > [ 0.231719] [] (device_initialize+0x20/0x90) from > [] (platform_device_register+0x10/0x1c) > [ 0.231781] [] (platform_device_register+0x10/0x1c) from > [] (overo_init+0x80/0x228) > [ 0.231811] [] (overo_init+0x80/0x228) from [] > (customize_machine+0x1c/0x28) > [ 0.231872] [] (customize_machine+0x1c/0x28) from > [] (do_one_initcall+0x90/0x164) > [ 0.231903] [] (do_one_initcall+0x90/0x164) from > [] (kernel_init+0xa4/0x154) > [ 0.231933] [] (kernel_init+0xa4/0x154) from [] > (kernel_thread_exit+0x0/0x8) > [ 0.232055] [ cut here ] > [ 0.232086] WARNING: at > /home/doanac/linaro/code/linux-linaro-2.6.39/fs/sysfs/dir.c:455 > sysfs_add_one+0x6c/0x94() > [ 0.232116] sysfs: cannot create duplicate filename > '/devices/platform/reg-fixed-voltage.1' > [ 0.232116] Modules linked in: > [ 0.232177] [] (unwind_backtrace+0x0/0xe0) from > [] (warn_slowpath_common+0x4c/0x64) > [ 0.232208] [] (warn_slowpath_common+0x4c/0x64) from > [] (warn_slowpath_fmt+0x2c/0x3c) > [ 0.232269] [] (warn_slowpath_fmt+0x2c/0x3c) from > [] (sysfs_add_one+0x6c/0x94) > [ 0.232299] [] (sysfs_add_one+0x6c/0x94) from [] > (create_dir+0x5c/0xb4) > [ 0.232330] [] (create_dir+0x5c/0xb4) from [] > (sysfs_create_dir+0xa4/0xbc) > [ 0.232360] [] (sysfs_create_dir+0xa4/0xbc) from > [] (kobject_add_internal+0xd0/0x1e8) > [ 0.232421] [] (kobject_add_internal+0xd0/0x1e8) from > [] (kobject_add+0x68/0x8c) > [ 0.232452] [] (kobject_add+0x68/0x8c) from [] > (device_add+0xa0/0x50c) > [ 0.232482] [] (device_add+0xa0/0x50c) from [] > (platform_device_add+0x108/0x164) > [ 0.232543] [] (platform_device_add+0x108/0x164) from > [] (overo_init+0x80/0x228) > [ 0.232574] [] (overo_init+0x80/0x228) from [] > (customize_machine+0x1c/0x28) > [ 0.232604] [] (customize_machine+0x1c/0x28) from > [] (do_one_initcall+0x90/0x164) > [ 0.232635] [] (do_one_initcall+0x90/0x164) from > [] (kernel_init+0xa4/0x154) > [ 0.2
Re: What do we want our hwpack sources
On 01/06/11 19:41, Christian Robottom Reis wrote: > Hello there, > > This week I initiated a confused conversation during the techleads > call about having a way to describe what the hardware pack was built > from. We had a couple of false starts but I think we agreeing that there > needs to be some form of manifest that describes what the hardware pack > contains. > Sorry I'm getting into this conversation a bit late but is there also a need to figure out what toolchain was used to build this hwpack and the way in which the toolchain was configured (v7-a, neon, vfp , vfpv3-d16) and what version of the toolchain was used. If this information is already captured or there is an easy way of getting back to this. This is if you think there is a use-case of regenerating the hwpack to investigate any issues that might come up cheers Ramana ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: What do we want our hwpack sources
I went through Kiko's request: - What kernel tree it was built from (A URL to the git tree) - What revision (A revision ID) - What patches were applied on top of it (A URL to the patchset, maybe?) - What kernel config was used to build it (A separate file in the hwpack directory?) and the spdx spec: http://spdx.org/system/files/spdx-draft20110516_0.pdf And wrote this: PackageName: linux-linaro-omap 2.6.38-1002.3 #https://launchpad.net/ubuntu/+source/linux-linaro-omap PackageDownloadLocation: https://launchpad.net/ubuntu/+archive/primary/+files/linux-linaro-omap_2.6.38.orig.tar.gz PackageChecksum: SHA1: cf0b587742611328f095da4b329e9fc7 # from https://launchpad.net/ubuntu/+source/linux-linaro-omap/2.6.38-1002.3 SourceInfo: uses Linux v2.6.38.1 SourceInfo: uses linaro-linux-2.6.38-upstream-29Mar2011 SourceInfo: uses (fill in patch1) SourceInfo: uses (fill in patch2) SourceInfo: uses (fill in patch3) SourceInfo: uses CONFIG_ etc... FileName: file1 FileName: file2 FileName: file3 FileChecksum: SHA1: calculated SPDXVersion: SPDX-1.0 Creator: Person: Zach Pfeffer (zach.pfef...@linaro.org) Created: 2011-06-02T13:18:00Z PackageLicenseDeclared: GPL-2.0 PackageVerificationCode: (fill in SHA1 of all souyrce files) LicenseConcluded: GPL-2.0 LicenseInfoFromFiles: GPL-2.0 PackageCopyrightText: Copyright 2008-2010 John Smith I think this generally adheres to the spec (I put all the licensing info below the packaging into and also used # comment) I've added Kate to the thread to tell me I'm wrong... :) I can't really express how important it is for Linaro to get its legal house in order now. With binary blobs and various components coming together, we can get in front of this issue instead of "creating our own thing." Right now things are in Beta so if we have feed back we should give it. -Zach On 1 June 2011 13:41, Christian Robottom Reis wrote: > Hello there, > > This week I initiated a confused conversation during the techleads > call about having a way to describe what the hardware pack was built > from. We had a couple of false starts but I think we agreeing that there > needs to be some form of manifest that describes what the hardware pack > contains. > > I seem to be hung up on having a way of saying "this hardware pack's > kernel was built from this git tree with this config", so I wanted to > explore the use cases a bit more: > > - My #1 use case is, once I've installed a hardware pack, running > into a problem and then being able to verify whether it contains a > certain patch or was built with a certain config option. I'd like > to know that because it's the first thing the KWG and LT people > ask me when I go to report the bug. > > - I think there's also a use case of wanting to know how to get that > hwpack rebuilt with slightly updated kernel code or configs. If > it's much easier to just document how to build and replace a > kernel for a running image, that may cater for most of that use > case, the exception being weird bugs caused by our build process > and/or toolchain. > > - I wonder if there's a use case for understanding and/or replacing > the other contents of the hardware pack. I normally think of the > hardware pack as "a built kernel and not much else" XXX. > > Zach suggested SPDX (as in spdx.org) as a solution to this problem; I'm > not sure I understand enough about it (Loïc's provided a sample file at > http://spdx.org/wiki/sample-partial-spdx-file-geronimo) but here's my > strawman proposal of what data we should give people quick access to: > > - What kernel tree it was built from > (A URL to the git tree) > - What revision > (A revision ID) > - What patches were applied on top of it > (A URL to the patchset, maybe?) > - What kernel config was used to build it > (A separate file in the hwpack directory?) > > How does that sound? Too simplistic? > -- > 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 > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Toolchain WG Weekly Status report 2011-06-03
== Weekly Status report == https://wiki.linaro.org/WorkingGroups/ToolChain/Status/2011-06-02 == Weekly Meetings minutes == https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2011-05-30 https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2011-06-02 == Summary == * Public plan review complete * More investigation into hot functions in SPEC 2006 * EEMBC benchmarks have arrived * Dave is profiling the memcpy() variants across the benchmarks * Planning on the sync primitives is under way. Backwards compatibility is the hard one. * Peter has started pushing the OMAP2 patches upstream, which starts to clear the backlog * Other performance work is going on: * Working on vectoriser widening multiplication * Improving auto increment/decrement for memory accesses * Talked with ARM's RVDS group re: sharing benchmarks and infrastructure Regards, Mounir ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Issues with repo --mirror
Paul On Thu, Jun 2, 2011 at 9:24 AM, Paul Sokolovsky wrote: > > This is even more interesting, with Google people confirming that repo > --mirror works within some bounds and limitations: > > > http://groups.google.com/group/repo-discuss/browse_thread/thread/401656c3ad0a4a0c > > Finally, here's typical usage scenario for repo --mirror (which is > pretty underdocumented): > > http://www.excentral.org/archives/2011/02/24/android-repo-mirroring > > So, like "repo help init" says, mirror created with repo --mirror > should later be used with repo --reference, with both mirror and > checkout using it to be located on local filesystem. I couldn't find > referenced that repo --mirror is intended for use like we do - to serve > it using git-daemon. > > My next step was trying to do real git mirror (git clone --mirror), and > already did it and prepared to move it into intended location, when I > did ls -l in the mirror directory: > > drwxr-xr-x 7 git-mirror nogroup 4096 2011-06-02 00:11 kernel-tilt.git > drwxr-xr-x 7 git-mirror nogroup 4096 2011-06-01 12:30 kernel-tilt.git.git > > Once I moved that ".git.git" repo away, original issue with repo sync > resolved. I have no idea that double-.git repo was created. Based on > the timestamp, it was created first, and later barely updated, with > mirror and just git clone using the proper repo, while repo sync on the > build slave managing to pick up wrong one. I wonder, if that (creation > of 2 repos) could be a result of some race condition. > > And I wish this issue could be called resolved, but as quoted above, > there're (more) issues are known with git --mirror, so I decided to put > up this mail with the links, for the next time such issues may come. > I have spent some time in the past with repo --mirror (we have internal mirrors within TI). After several attempts my conclusion was that it was not the best approach. the main problem is that repo --mirror expects that you give a manifest tree. If you have several branches in your manifest tree (like it's the case for the omapmanifest on git.omapzoom.org), repo sync will only sync the branch you've used initially. So if you have new or different trees on other branches they aren't sync'd. that pretty much means that you need 1 mirror for each manifest branch. (in fact I am the one that asked the repo --mirror question you've found!) so i ended it doing a git mirror, and I wrote this simple helper script https://github.com/ndechesne/git-mirror which can be used to mirror a complete 'git server' using gitweb. for example, you just need to add this in a cron: git-mirror -o /data/git/repositories/ -s http://git.omapzoom.org -g git:// git.omapzoom.org and the script will mirror the server locally. everytime it runs: - it creates new trees that have appeared on the remote - updates all existing trees - removed trees that have disappeared from the remote. i have been using this script on several mirror (1 at every site) quite reliably for ~2 years. prior to that I was using repo sync and frequently had failures... hope this helps. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The linaro-2.6.39 kernel repository is now alive
On 06/02/2011 12:12 AM, Nicolas Pitre wrote: > This will continue to evolve as this is just the beginning for that > tree, so more stuff will be merged. Only smoke tested on a Dove board, > and compile tested for OMAP so far. > I just tried some testing of my Overo with the omap2plus_defconfig and my hack for what John Rigby uses for Linaro builds. The "Linaro config" produces a compiler error. I'm assuming the config will be changing, so I haven't really looked into patching the issue. John - let me know if this is something you need my help with. The omap2plus_defconfig comes up but I'm not getting DVI video and I'm also seeing these problems from the kernel: Uncompressing Linux... done, booting the kernel. [0.00] Linux version 2.6.39-00910-g3818181-dirty (doanac@storage) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu3) ) #4 SMP Thu Jun 2 14:43:32 CDT 2011 [0.00] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7f [0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [0.00] Machine: Gumstix Overo [0.00] Reserving 12582912 bytes SDRAM for VRAM [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp ) [0.00] SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x1 [0.00] Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz [0.00] Reprogramming SDRC clock to 33200 Hz [0.00] PERCPU: Embedded 7 pages/cpu @c0f85000 s8160 r8192 d12320 u32768 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 126976 [0.00] Kernel command line: console=ttyO2,115200n8 mpurate=720 vram=12M omapfb.mode=dvi:1024x768MR-16@60 omapfb.debug=y omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait [0.228179] Registering NAND on CS0 [0.231536] Could not obtain gpio for TS PenDown: -16 [0.231567] kobject (c05eae78): tried to init an initialized object, something is seriously wrong. [0.231628] [] (unwind_backtrace+0x0/0xe0) from [] (kobject_init+0x34/0x90) [0.231689] [] (kobject_init+0x34/0x90) from [] (device_initialize+0x20/0x90) [0.231719] [] (device_initialize+0x20/0x90) from [] (platform_device_register+0x10/0x1c) [0.231781] [] (platform_device_register+0x10/0x1c) from [] (overo_init+0x80/0x228) [0.231811] [] (overo_init+0x80/0x228) from [] (customize_machine+0x1c/0x28) [0.231872] [] (customize_machine+0x1c/0x28) from [] (do_one_initcall+0x90/0x164) [0.231903] [] (do_one_initcall+0x90/0x164) from [] (kernel_init+0xa4/0x154) [0.231933] [] (kernel_init+0xa4/0x154) from [] (kernel_thread_exit+0x0/0x8) [0.232055] [ cut here ] [0.232086] WARNING: at /home/doanac/linaro/code/linux-linaro-2.6.39/fs/sysfs/dir.c:455 sysfs_add_one+0x6c/0x94() [0.232116] sysfs: cannot create duplicate filename '/devices/platform/reg-fixed-voltage.1' [0.232116] Modules linked in: [0.232177] [] (unwind_backtrace+0x0/0xe0) from [] (warn_slowpath_common+0x4c/0x64) [0.232208] [] (warn_slowpath_common+0x4c/0x64) from [] (warn_slowpath_fmt+0x2c/0x3c) [0.232269] [] (warn_slowpath_fmt+0x2c/0x3c) from [] (sysfs_add_one+0x6c/0x94) [0.232299] [] (sysfs_add_one+0x6c/0x94) from [] (create_dir+0x5c/0xb4) [0.232330] [] (create_dir+0x5c/0xb4) from [] (sysfs_create_dir+0xa4/0xbc) [0.232360] [] (sysfs_create_dir+0xa4/0xbc) from [] (kobject_add_internal+0xd0/0x1e8) [0.232421] [] (kobject_add_internal+0xd0/0x1e8) from [] (kobject_add+0x68/0x8c) [0.232452] [] (kobject_add+0x68/0x8c) from [] (device_add+0xa0/0x50c) [0.232482] [] (device_add+0xa0/0x50c) from [] (platform_device_add+0x108/0x164) [0.232543] [] (platform_device_add+0x108/0x164) from [] (overo_init+0x80/0x228) [0.232574] [] (overo_init+0x80/0x228) from [] (customize_machine+0x1c/0x28) [0.232604] [] (customize_machine+0x1c/0x28) from [] (do_one_initcall+0x90/0x164) [0.232635] [] (do_one_initcall+0x90/0x164) from [] (kernel_init+0xa4/0x154) [0.232696] [] (kernel_init+0xa4/0x154) from [] (kernel_thread_exit+0x0/0x8) [0.233123] ---[ end trace 1b75b31a2719ed1c ]--- [0.233184] kobject_add_internal failed for reg-fixed-voltage.1 with -EEXIST, don't try to register things with the same name in the same directory. [0.233215] [] (unwind_backtrace+0x0/0xe0) from [] (kobject_add_internal+0x1bc/0x1e8) [0.233276] [] (kobject_add_internal+0x1bc/0x1e8) from [] (kobject_add+0x68/0x8c) [0.233306] [] (kobject_add+0x68/0x8c) from [] (device_add+0xa0/0x50c) [0.27] [] (device_add+0xa0/0x50c) from [] (platform_device_add+0x108/0x164) [0.233398] [] (platform_device_add+0x108/0x164) from [] (overo_init+0x80/0x228) [0.233428] [] (overo_init+0x80/0x228) from [] (customize_machine+0x1c/0x28) [0.233459] [] (customize_machine+0x1c/0x28) from [] (do_one_initcall+0x90/0x164) [0.233489] [] (do_one_initcall+0x90/0x164) from [] (kernel_i
Re: The linaro-2.6.39 kernel repository is now alive
On Thu, 2 Jun 2011, Dave Martin wrote: > vexpress > > > linux-linaro-2.6.39/master doesn't seem to work on vexpress using the > linux-linaro-natty configuration (I get "starting the kernel", then > nothing). > > Upstream v2.6.39 does appear to work fully on vexpress in both ARM and > Thumb-2. > > The bad commit is: 6e7c40e473c1f0553175efff64cf30288c1bc9f4 > (clockevents: ARM sp804: obtain sp804 timer rate via clks) > > Rob Herring proposed a patch to fix this issue (below). Note that the > last hunk of the patch affecting libata is not relevant (Rob subsequently > retracted it.) > > http://article.gmane.org/gmane.linux.ports.arm.kernel/118249 > > That additional patch seems to fix the problem for me. Applied. > imx51 > - > > I get a booting kernel from linux-linaro-2.6.39/master in mx51evk, so > long as I boot without an fdt blob. > > If I build a Thumb-2 kernel, it does not boot, but a Thumb-2 kernel > built from linux-linaro-natty/master does boot; i.e. I get no messages > at all after "Starting kernel ..." > > I haven't investigated what the problem is yet. I might not have carried over all the Thumb2 patches yet, if any of them are still relevant which is something I still need to figure out. However those would only affect build issues if I remember right. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PowerManagement] Cpufreq tests scenarii
On 06/02/2011 06:14 PM, Paul Larson wrote: On Wed, Jun 1, 2011 at 4:10 AM, Daniel Lezcanowrote: On 06/01/2011 09:59 AM, Paul Larson wrote: I have a board at home I can try to reproduce with if someone on the pm team doesn't. I probably won't be able to get to it until later in the week though. Ok, thanks very much. I will discuss with the PM team and I will try to get a beagleboardXM. That will probably take more than one week for me. Do you confirm this problem happens only on the beagleXM ? The only other place I was able to test it was panda, and it worked fine there - no problen Thanks for checking. I ran the tests on a igepv2 and I had no problem but the cpufreq driver is not complete with the linaro-2.6.38 kernel. On the panda board it is still work in progress AFAIK. I will try with the latest 2.6.39 linaro kernel. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The linaro-2.6.39 kernel repository is now alive
On Thu, Jun 02, 2011 at 01:12:29AM -0400, Nicolas Pitre wrote: > Time to leave 2.6.38 behind and move on! We now have a 2.6.39 based > Linaro kernel which can be viewed here: > > http://git.linaro.org/gitweb?p=kernel/linux-linaro-2.6.39.git;a=summary > > or cloned from either of those: > > git://git.linaro.org/kernel/linux-linaro-2.6.39.git > > http://git.linaro.org/git/kernel/linux-linaro-2.6.39.git > > This will continue to evolve as this is just the beginning for that > tree, so more stuff will be merged. Only smoke tested on a Dove board, > and compile tested for OMAP so far. Great ... I've just been playing with the new tree. The following comments assume that linux-linaro-2.6.39/master = 570728d7678e788e4a0e2c19ad5f932e3c29a73c vexpress linux-linaro-2.6.39/master doesn't seem to work on vexpress using the linux-linaro-natty configuration (I get "starting the kernel", then nothing). Upstream v2.6.39 does appear to work fully on vexpress in both ARM and Thumb-2. The bad commit is: 6e7c40e473c1f0553175efff64cf30288c1bc9f4 (clockevents: ARM sp804: obtain sp804 timer rate via clks) Rob Herring proposed a patch to fix this issue (below). Note that the last hunk of the patch affecting libata is not relevant (Rob subsequently retracted it.) http://article.gmane.org/gmane.linux.ports.arm.kernel/118249 That additional patch seems to fix the problem for me. imx51 - I get a booting kernel from linux-linaro-2.6.39/master in mx51evk, so long as I boot without an fdt blob. If I build a Thumb-2 kernel, it does not boot, but a Thumb-2 kernel built from linux-linaro-natty/master does boot; i.e. I get no messages at all after "Starting kernel ..." I haven't investigated what the problem is yet. Cheers ---Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PowerManagement] Cpufreq tests scenarii
On Wed, Jun 1, 2011 at 4:10 AM, Daniel Lezcano wrote: > On 06/01/2011 09:59 AM, Paul Larson wrote: > >> I have a board at home I can try to reproduce with if someone on the pm >> team >> doesn't. I probably won't be able to get to it until later in the week >> though. >> > > Ok, thanks very much. I will discuss with the PM team and I will try to get > a beagleboardXM. > That will probably take more than one week for me. > > Do you confirm this problem happens only on the beagleXM ? > The only other place I was able to test it was panda, and it worked fine there - no problem. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PM] 01/06/2011 - Minutes for the Power Management WG weekly call
Hi All, The minutes of the power management weekly call can be found at : https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2011-06-01 Summary: * A block diagram has been added to the thermal wiki page. A 1st port of thermal framework is ongoing on panda. * Powerdebug code has been modified to prepare the addition of new features (gpio, thermal) * Some issues with cpufreq tests have been raised. Vishwa is going to check if all patches for omap3 cpufreq have been pushed into the linaro kernel * a 1st version of arm cpu topo definition based on MPIDR is running. We are also going to study the interest of using FDT for the definition of the cpu topology * A 1st version of a common cpu context save/restore for cpuidle should be proposed soon. Vincent ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[ACTIVITY] Graphics WG weekly status - wk22.2011
For links and details check: https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Status/2011-06-01 == Key Points for wider discussion == * Training material request: how to release wiki page for work groups - with instructions that can be followed. Indicate which routes to take in common cases (when to release as a tarball etc). Action item to Fathi, Ricardo and Tom Gall - perhaps need to start a discussion in the mailing list also to get the feedback from the teams * Managing our monthly releases - level of quality testing may need to be tackled on a component per component basis especially for components where the correctness testing is not really there (or is challenging to implement completely). Validation team should participate as well as perhaps others (landing teams - to get some crisp baselines from teams actually using our components) == Team Highlights == * Review for the GWG cycle public plans 20110602 (today!). Check the [[https://wiki.linaro.org/Cycles//PublicPlanReview|PublicPlanReview]] page! * Memory management: Jesse sent out a status report after the UDS mini-summit discussions. Jesse will coordinate these activities with Sumit and Rob. * NUX work: daily sync ups with Alexandros, Travis and Jesse trying to get NUX working. Latest big thing was the fact that NUX is trying to support the openGL shading language but in a way that would not even work on desktop. The implementation of the shading language in NUX is not correct - Alexandros to file a bug. We believe we have a solid fix coming up. * Compiz: Blur plugin is the only thing missing Travis is testing now, merge branch from our team will need to be packaged for some testing. * Validation - out of tree tests registration and providing the tests to validation team: Alexandros worked with Zygmunt and defined 2 ways to proceed. If a test does not require something special we can push it into abrek and it will be put in tree. For out of tree packages we need to inform the validation team which PPA it is going to be and what it enables so they can pull it into validation. * Managing our monthly releases: Alexandros started the discussion on how to manage the release of the GWG components. Cycles are being refactored, to use monthly releases of our components, so we may or may not have interesting work to go into the monthly release EVERY MONTH, but we should have a good process to make sure that we are enabled to release the components as needed. Automatic testing for the components, and also testing the other components for possible breakages prior to merging something in order to know how well the changes work and what they break is a challenge. Not everything we work on has built-in support for the automatic tests especially how to do the correctness testing. We will have the challenge to check component-by-component what human element of testing can be automated. NUX has a standalone test, but the tests do not cover visuals let alone that there are lots of combinations in plugins used and configurations - the task of writing tests for 100% coverage would be a real challenge, and manual testing is right now the only one applied for just the default configuration (which amounts for desktop functionality). Other possible ideas: a basic compiz functionality automatic validation may be doable (example of a screensaver plugin which could be used) eg by poking compiz via D-BUS and testing the window manager functionality of Compiz (for example, moving windows around) and using some tool to check if the drawing is as should be. * Related to the packaging, for the monthly release, a question rose what kind of setup should we have in order to release good quality tarballs. Alexandros commented that a day or two prior to the release for some testing is good enough now. Also trying to build daily packages and using the test reports from those components that have self-testing could be useful for the team. Alexandros will write up a description of what he does on the wiki * Developing further the blueprints, activities for 11.06 to be targeted (action for all) * Training request - how to do the release components for a group. We need to collect the material and make sure that all in the team have some cross-training on how to release components for the group. Maybe later push the wiki page to a general howto. == Upcoming Deliverables == * Working now to define the targets for the 11.06 release == Miscellaneous == * Sumit Semwal (TI) presented himself for the first time to the group. Welcome Sumit!! -- Ilias Biris, Aallonkohina 2D 19, 02320 Espoo, Finland Tel: +358 50 4839608 (mobile) Email: ilias dot biris at linaro dot org Skype: ilias_biris ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Issues with repo --mirror
Hello Michael, On Thu, 02 Jun 2011 21:18:44 +1200 Michael Hudson-Doyle wrote: [] > > Once I moved that ".git.git" repo away, original issue with repo > > sync resolved. I have no idea that double-.git repo was created. > > Based on the timestamp, it was created first, and later barely > > updated, with mirror and just git clone using the proper repo, > > while repo sync on the build slave managing to pick up wrong one. I > > wonder, if that (creation of 2 repos) could be a result of some > > race condition. > > I bet it is. And it's not the only case, but at least not regular: ubuntu@android-build:/mnt/mirror$ find -type d -name '*.git.git' ./git.omapzoom.org/kernel/omap.git.git What's interesting is that this is again a kernel repository. I'm not sure what to do about it now, considering just to set up a cronjob which will use that find command (need to figure out how to send mail from ec2). > > > And I wish this issue could be called resolved, but as quoted above, > > there're (more) issues are known with git --mirror, so I decided to > > put up this mail with the links, for the next time such issues may > > come. > > As you pointed out to me fairly soon after you started, we don't > actually need to run "repo sync" on the server at all -- it's not hard > to figure out the "git clone" commands we need to run, and so maybe we > (well, you :-p) should just do that. Yes, I still keep that in mind, wanted to try it for this case, when it suddenly resolved. All in all, current mirror system seems to work (even though sometimes workarounds are required), while some stuff still missing, so I guess this will need to wait a bit... > > Cheers, > mwh -- Best Regards, Paul ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Issues with repo --mirror
On Thu, 2 Jun 2011 10:24:12 +0300, Paul Sokolovsky wrote: > Hello, > > There was weird problem with android git mirror again > (https://android-build.linaro.org/jenkins/job/patrik-ryd_lt-panda/4/consoleFull): > > error: revision tilt-linaro-android.38 in > git.linaro.org/people/andygreen/kernel-tilt not found Archiving > artifacts Finished: FAILURE > > This was 100% reproducible, but that revision exists in the git > repository on git.linaro.org, and actually it's being mirrored, as > > git clone > git://us-east-1.ec2-git-mirror.linaro.org/git.linaro.org/people/andygreen/kernel-tilt > > Worked pretty well. But "repo sync" gave the error above, which well, > pointed at some repo peculiarity. > > There were similar issues already, with newly added git repos which > lacked master branch. Adding master branch seemed to solve the issue. > But kernel-tilt had master branch. > > So, I for some time suspected that repo --mirror we use for mirroring > doesn't make faithful enough mirror of git forest, and this time > decided to dig out what is known about it. > > First of all, while there's no --verbose or --debug switch for the > repo, it's possible to make it dump git commands it executes by setting > "REPO_TRACE=1" in the environment. I verified that very same git > command, when run directly against git.linaro.org, works well, but > leads to repo error quoted above if run against mirror. > > I then googled for known issues with repo --mirror, couldn't find much, > but there're few reports of obscure issues: > > http://groups.google.com/group/repo-discuss/browse_thread/thread/b97524988360b029 > > This is even more interesting, with Google people confirming that repo > --mirror works within some bounds and limitations: > > http://groups.google.com/group/repo-discuss/browse_thread/thread/401656c3ad0a4a0c > > Finally, here's typical usage scenario for repo --mirror (which is > pretty underdocumented): > > http://www.excentral.org/archives/2011/02/24/android-repo-mirroring > > So, like "repo help init" says, mirror created with repo --mirror > should later be used with repo --reference, with both mirror and > checkout using it to be located on local filesystem. I couldn't find > referenced that repo --mirror is intended for use like we do - to serve > it using git-daemon. > > My next step was trying to do real git mirror (git clone --mirror), and > already did it and prepared to move it into intended location, when I > did ls -l in the mirror directory: > > drwxr-xr-x 7 git-mirror nogroup 4096 2011-06-02 00:11 kernel-tilt.git > drwxr-xr-x 7 git-mirror nogroup 4096 2011-06-01 12:30 kernel-tilt.git.git ! > Once I moved that ".git.git" repo away, original issue with repo sync > resolved. I have no idea that double-.git repo was created. Based on > the timestamp, it was created first, and later barely updated, with > mirror and just git clone using the proper repo, while repo sync on the > build slave managing to pick up wrong one. I wonder, if that (creation > of 2 repos) could be a result of some race condition. I bet it is. > And I wish this issue could be called resolved, but as quoted above, > there're (more) issues are known with git --mirror, so I decided to put > up this mail with the links, for the next time such issues may come. As you pointed out to me fairly soon after you started, we don't actually need to run "repo sync" on the server at all -- it's not hard to figure out the "git clone" commands we need to run, and so maybe we (well, you :-p) should just do that. Cheers, mwh ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Images vs installers
On Wed, Jun 01, 2011 at 11:37:30PM +0100, Wookey wrote: > +++ Dave Martin [2011-06-01 15:56 +0100]: > > Separate question how big is Debian-installer, in terms of filesystem > > and RAM footprint? > > There are various flavours. Primarily: > > 1) a 'full' image which is 160MB and includes the base system that is >installed (so you can get a system without network access), > > 2) a minimal image which is 33MB and needs a network to download the > packages to be installed. > > 3) initrd-based headless installers for various arm boxes which vary > from 4.5 to 18Mb (including kernel) e.g: > http://ftp.debian.org/debian/dists/stable/main/installer-armel/current/images/kirkwood/netboot/marvell/openrd/ > > The D-I system is very flexible. But it does depend on the building of > udebs (minimal versions of debs which are used to make installed > bootable images). You could make a rather fatter installer out of > normal debs, but that would preclude the initrd flavour. > > I don't know how much ram is needed, but it works on the 32Mb NSLU2 so > 'not much', at least in headless form. More for the GUI version. > > > If we can move the entire installation system to a ramfs on boot, we can > > unmount and free up the boot device, allowing the system to be installed > > in-place. > > This is possible. On most of the currently-supported-by-debian arm devices a > console and some uboot runes are required to get things installed and > defaulting to booting off the desired device. Some (such as thecus > n2100) support a web+ssh install: > http://www.cyrius.com/debian/iop/n2100/install.html > > Things are somewhat simplified if we are only worrying about devices > which already boot from USB or SD/MMC. > > > This might also require Linux's idea of which devices are "removable" > > to be overridden though, so that they can be repartitioned > > without a reboot. I think the kernel hard-codes this for some of our > > boards currently; i.e., the boot SD slot may be considered non- > > removable. I don't know how easy it is do get around this. > > This is only a problem if repartitioning is needed. Partitioning is normally at least desirable during install, no? ---Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Images vs installers
On Wed, Jun 01, 2011 at 07:32:10PM +0200, Arnd Bergmann wrote: > On Wednesday 01 June 2011 16:56:07 Dave Martin wrote: > > On Wed, Jun 01, 2011 at 03:36:47PM +0100, Wookey wrote: > > > +++ Arnd Bergmann [2011-06-01 16:11 +0200]: > > > > On Wednesday 01 June 2011, Wookey wrote: > > > > > > > I absolutely agree that we should consequently think beyond image > > > > generation, but that doesn't necessarily mean that a CD image > > > > to perform an unattended installation is a better answer. > > > > > > > > My main question to this is "install from where?". > > > > > > I'd say the default case (at least for current hardware) is booting > > > from SD or USB stick and installing from the network. (Which is how I > > > install PCs these days too - it's a very long time since I got a CD > > > out :-)). > > Yes, me too. > > > > > but that doesn't necessarily mean that a CD image > > > > to perform an unattended installation is a better answer > > > > > > I'm not sure I follow you here. Are you suggesting that there is some > > > third way between a locally-bootable installer image and pre-built > > > images? (In which case what - I don't see this), or just that CDs are > > > no longer the default media (agreed). > > One approach that seems to be getting more popular these days is > to have a bootable system as a USB image, with a way to clone that > installation to another drive. This is arguably a bit different i.e., "live CD"? Ubuntu's installers for ARM have followed this approach. The complication for ARM is that you can probably only boot from one device, which can complicate things like bootloader installation. > from the classic installer where you boot a very small image > (not made of regular packages but e.g. udeb instead of deb, > or purely busybox based) that installs a system to the final > destination from scratch. > > > If we can move the entire installation system to a ramfs on boot, we can > > unmount and free up the boot device, allowing the system to be installed > > in-place. > > This is probably the main question: If we want an installer, should > it be something that boots as an initramfs and is able to install in > a very flexible way, or do we instead build a minimal image that > basically includes everything needed to add more stuff through > apt-get, possibly with a way to clone itself to another drive? Option two is certainly the thing we are closest to right now (i.e., nano). We don't have "clonability" yet, though when the installed system is removable storace (MMC/SD/USB) it's pertty easy to clone offline anyway. A self-contained installer which runs from initramfs (or whatever) would be more effort, so the feasibility really depends on whether there's something available which can already nearly do this. Cheers ---Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Gerrit userstory for multi-branch development
Hello Arnd, [] > > No, sorry for the confusion and not making this clear - I wrote the > > original mail as a follow-up to "Android Code Review" session, > > https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-o-code-review > > > > http://summit.linaro.org/uds-o/meeting/linaro-android-o-code-review/ , > > where Arnd expression concerns which were discussed. I look at > > Gerrit from viewpoint of Android/Infrastructure team, and collect > > and appreciate feedback and usecases from wider audience. > > Sorry for the late follow-up, too many things kept coming up at once > in the last few weeks. Here is what I had in mind, tell me if I > should add this to the blueprint or how else you want to proceed. Thanks, I've added link to this in linaro-dev list archive to Android's blueprint, https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-o-code-review If there's a blueprint for kernel code review, I guess it makes sense to add it there too. (I also consider starting a wiki page with code review tools comparison/issues, I'll add it there to when I get to it) > > == User Stories == > [] -- Best Regards, Paul ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: What do we want our hwpack sources
On 06/01/2011 10:21 PM, Somebody in the thread at some point said: Another cheap thing to do would be to dump the config from the kernel package in to the output dir, so you can see the config without having to download the hwpack or produce an image. This can be useful, much like the new .manifest that lists the packages included and their versions is useful if you want to know if the new hwpack build picked up the fix for some bug in the latest upload. At least for the config, CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y gets you a gzip of the config used in the kernel body readable by scripts/extract-ikconfig externally, and readable at runtime down /proc/config.gz. (static extract script is useful in the case the kernel doesn't boot or stay up long enough to query at runtime). That's more tightly bound to the actual kernel than doing it in packaging only. My build scripts put the git branch in the uname -r, the make process already puts the git HEAD hash in there; packaging can do the same. Nowhere says which repo was used at the moment. However a lot of bug reports just talk about packagenames like blah-1003 leaving the reader clueless about where to get the package let alone what it was built from. If CONFIG_IKCONFIG_PROC was used everywhere, we / the packaging process could leverage that to add a dummy Kconfig like CONFIG_BUILD_SOURCE="git://..." and have it all available cleanly just from the uImage or at runtime. -Andy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Issues with repo --mirror
Hello, There was weird problem with android git mirror again (https://android-build.linaro.org/jenkins/job/patrik-ryd_lt-panda/4/consoleFull): error: revision tilt-linaro-android.38 in git.linaro.org/people/andygreen/kernel-tilt not found Archiving artifacts Finished: FAILURE This was 100% reproducible, but that revision exists in the git repository on git.linaro.org, and actually it's being mirrored, as git clone git://us-east-1.ec2-git-mirror.linaro.org/git.linaro.org/people/andygreen/kernel-tilt Worked pretty well. But "repo sync" gave the error above, which well, pointed at some repo peculiarity. There were similar issues already, with newly added git repos which lacked master branch. Adding master branch seemed to solve the issue. But kernel-tilt had master branch. So, I for some time suspected that repo --mirror we use for mirroring doesn't make faithful enough mirror of git forest, and this time decided to dig out what is known about it. First of all, while there's no --verbose or --debug switch for the repo, it's possible to make it dump git commands it executes by setting "REPO_TRACE=1" in the environment. I verified that very same git command, when run directly against git.linaro.org, works well, but leads to repo error quoted above if run against mirror. I then googled for known issues with repo --mirror, couldn't find much, but there're few reports of obscure issues: http://groups.google.com/group/repo-discuss/browse_thread/thread/b97524988360b029 This is even more interesting, with Google people confirming that repo --mirror works within some bounds and limitations: http://groups.google.com/group/repo-discuss/browse_thread/thread/401656c3ad0a4a0c Finally, here's typical usage scenario for repo --mirror (which is pretty underdocumented): http://www.excentral.org/archives/2011/02/24/android-repo-mirroring So, like "repo help init" says, mirror created with repo --mirror should later be used with repo --reference, with both mirror and checkout using it to be located on local filesystem. I couldn't find referenced that repo --mirror is intended for use like we do - to serve it using git-daemon. My next step was trying to do real git mirror (git clone --mirror), and already did it and prepared to move it into intended location, when I did ls -l in the mirror directory: drwxr-xr-x 7 git-mirror nogroup 4096 2011-06-02 00:11 kernel-tilt.git drwxr-xr-x 7 git-mirror nogroup 4096 2011-06-01 12:30 kernel-tilt.git.git Once I moved that ".git.git" repo away, original issue with repo sync resolved. I have no idea that double-.git repo was created. Based on the timestamp, it was created first, and later barely updated, with mirror and just git clone using the proper repo, while repo sync on the build slave managing to pick up wrong one. I wonder, if that (creation of 2 repos) could be a result of some race condition. And I wish this issue could be called resolved, but as quoted above, there're (more) issues are known with git --mirror, so I decided to put up this mail with the links, for the next time such issues may come. -- Best Regards, Paul ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
