linaro-dev April 2011

linaro-dev@lists.linaro.org

101 participants
154 discussions

Improvements to the Android Build Service

by Paul Sokolovsky

Hello, There were some improvements to the Linaro Android Build Service (aka linaro-cloud-buildd), https://android-build.linaro.org/ . The Jenkins EC2 plugin was upgraded to the latest version 1.11, which should improve EC2 instance management. There was also fixed a bug which caused unreliable build process in case an instance was reused to build different configurations. While working towards completely disposable build instances (which would require patching Jenkins/EC2 plugin), these changes should allow for sustainable build reliability in the meantime. There were around a dozen builds since these changes, and none of them showed infrastructure failures. I hope it now will be easier to concentrate on actual build failures where they happen. The Android Build Service documentation is available at https://wiki.linaro.org/Platform/Android/LinaroAndroidBuildService Thanks, Paul

15 years

[Android: device/linaro/pandaboard.git] The init.omap4.sh file should be in the system partition.

by Patrik Ryd

Bug #770389 --- AndroidBoard.mk | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/AndroidBoard.mk b/AndroidBoard.mk index 941416a..c417cac 100644 --- a/AndroidBoard.mk +++ b/AndroidBoard.mk @@ -30,7 +30,7 @@ ALL_PREBUILT += $(file) $(file) : $(LOCAL_PATH)/init.omap4.rc | $(ACP) $(transform-prebuilt-to-target) -file := $(TARGET_ROOT_OUT)/system/etc/init.omap4.sh +file := $(PRODUCT_OUT)/system/etc/init.omap4.sh ALL_PREBUILT += $(file) $(file) : $(LOCAL_PATH)/init.omap4.sh | $(ACP) $(transform-prebuilt-to-target) -- 1.7.1

15 years

Call for testing: Linaro 11.05 Beta-2 Candidate

by Jamie Bennett

Hi, In preparation for the release of Linaro 11.05 Beta-2 images on Thursday a suitable candidate has been selected for testing. The Beta-2 release is expected to be tested heavily and provide the most stable and feature-rich images to date this cycle. If you have supported hardware, as found at: http://releases.linaro.org/platform/linaro-n/hwpacks/latest/ please help our initiative by testing the official Linaro Evaluation Build (LEB): Ubuntu Desktop: http://releases.linaro.org/platform/linaro-n/ubuntu-desktop/latest/ and our Developer images: Nano: http://releases.linaro.org/platform/linaro-n/nano/latest/ ALIP: http://releases.linaro.org/platform/linaro-n/alip/latest/ Developer Tools: http://releases.linaro.org/platform/linaro-n/developer/latest/ As a side note, hwpacks that have an -lt- in their name are outputs from the Linaro Landing teams, using some of their components. Make your way to: http://wiki.linaro.org/Releases/MilestoneBuilds for an explanation of how to test and submit your results to the QA tracker at: http://qatracker.linaro.org For an explanation of how to use the qatracker please see: https://wiki.linaro.org/QA/QATracker Regards, Jamie. -- Linaro Release Manager | Platform Project Manager

15 years

u8500 does not build in current linux-linaro-2.6.38/master

by John Rigby

Not sure who to send this to so including Nicolas and Linus. make u8500_defconfig make uImage produces some undefined reference errors. Tail of the build log attached. Thanks, John

15 years

[RFF] Patch tracking/metrics

by Guilherme Salgado

Hi folks, I've been working on this app[1] (based on Patchwork) to track patches submitted/accepted upstream by Linaro engineers. It's still a work in progress and we're waiting for IS to deploy it but I wanted to show you what I have so far and ask for feedback, so I've deployed it on an ec2 instance: http://ec2-184-73-78-92.compute-1.amazonaws.com/ As you'll notice, that's the same front page you get on a regular Patchwork instance, which allows you to browse the patches of every project. You probably won't have to use that often, as everything you need to deal with should be on the page below: http://ec2-184-73-78-92.compute-1.amazonaws.com/user/submitted/ This one contains all patches you submitted that haven't received feedback yet. We want that to reflect reality to make sure our metrics are accurate, so we already have a script to mark the ones that are committed upstream and may use a similar approach to track rejected/superseded ones, but for now we'll need to manually mark the rejected/superseded ones. The script mentioned above will scan a git repo for each project and update the state of patches that are found to be committed there, but it's not running yet as first I need to know the git (http works too) URL of every project listed there. if you know it for any of them, please do let me know. Finally, the page below has some basic metrics to demo how we'll be using this data http://ec2-184-73-78-92.compute-1.amazonaws.com/metrics/ Some things to notice: - This is a temporary deployment, so don't bother making changes (other than those when playing around) as those will probably be lost - Login via OpenID using the Launchpad login service, so there's no need to register - Not all of your patches may be shown under /user/submitted. if that's the case, make sure all your email addresses are registered in Launchpad as we're sucking that data from there periodically and the next time we do so we'll merge all your email addresses under a single user - Some numbers in /metrics are skewed because of patches that have multiple versions; you'll be asked to flag superseded versions so that they're not included in the counts, and you're encouraged to do so for some of them to see how it works, but given that changes will be lost, don't bother doing it for more than a few - The other-unknown project is where we put patches for which we can't guess a project. - in some cases this is because the patches are sent only to patches(a)linaro.org so they need to be manually moved to the appropriate project (there's a form at the bottom of every patch list which allow you to do that). - in other cases it's because we're missing a project in patchwork. if that's the case we can register that project and there's a script which runs periodically and will move these patches to the new project [1] https://wiki.linaro.org/Platform/Infrastructure/Specs/PatchTracking -- Guilherme Salgado <https://launchpad.net/~salgado>

15 years

LPC2011 Scaling Micro Conf

by Paul E. McKenney

Hello! Given the increasing numbers of CPUs on low-cost servers as well as the appearance of SMP hand-held battery-powered devices, Linux Plumbers 2011 will feature a Scaling track, with topics including the following: - What can the kernel do to help applications perform and scale better? - What can applications do to help the kernel perform and scale better? - Memory footprint: + 100MB here, 100MB there, pretty soon you are talking real memory! + Improving performance by decreasing icache and dcache footprint. - Limits to scalability: + Technological limitations, especially hardware. + Complexity/maintainability limitations. - Handling of non-CPU computational hardware (GPGPUs, crypto HW, etc.) + Can the kernel make good use of non-CPU computational hardware? + How best to enable user applications to use them? - Dealing with the numerous remaining "little kernel locks" The intended audience is developers interested in performance and scalability throughout the Linux plumbing. The deadline is April 30th. Please submit your proposals, whether to Scaling or to other microconferences, at: http://www.linuxplumbersconf.org/2011/ocw/events/LPC2011MC/proposals The general track is also open for submissions until April 30th: http://www.linuxplumbersconf.org/2011/ocw/events/LPC2011/proposals Either way, we look forward to seeing your submissions! Thanx, Paul

15 years

Do we have a standardized kernel driver framework for video acceleration?

by Eric Miao

Hi All, Not really sure how this is being discussed in the Multimedia WG. But do we yet have a standardized kernel driver framework for video acceleration? A bit investigation showed a chaos in this area: 1. Different SoC vendors are using their specific APIs 2. The freescale case, there is a proposed driver from Sascha using V4L2 interface, yet our analysis showed some issues with this API to support a full featured usage, and the API itself doesn't just seem to be right for this (thanks for Jason for a detailed analysis) 3. XvMC (obsolete I believe) 4. nVidia's VDPAU, which is supported by XBMC and many others though 5. VA API (Intel proposed and currently available on Intel graphics), can use VDPAU as a backend 6. XvBA - AMD is proposing this for the ATI video HW - eric

15 years

[PATCH] ARM: Add dtbuImage target

by Stephen Warren

U-Boot wrapped dtbImage; useful for testing DT with an unmodified U-Boot. Signed-off-by: Stephen Warren <swarren(a)nvidia.com> --- This patch is based on: git://kernel.ubuntu.com/jk/dt/linux-2.6.git dtbimage However, I actually developed and tested it only on: git://git.secretlab.ca/git/linux-2.6 devicetree/test plus the following commits from jk's dtbimage branch: 4c2eddb89542f73fe626813e3cdafc789f931aec arm: dtbImage support 4cb80ac96489220554d28f6fde527aeef83e628b arm/dtbimage: copy dtb blob to offset from image base I wonder if rather than simply applying my patch below to jk's dtbimage branch, perhaps it would be better to cherry-pick the two commits I mentioned above into the devicetree/test tree, after which I can submit the original change I wrote there? arch/arm/Makefile | 2 +- arch/arm/boot/Makefile | 8 ++++++++ 2 files changed, 9 insertions(+), 1 deletions(-) diff --git a/arch/arm/Makefile b/arch/arm/Makefile index dab066a..3ce1751 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -264,7 +264,7 @@ archprepare: # Convert bzImage to zImage bzImage: zImage -zImage Image xipImage bootpImage uImage dtbImage: vmlinux +zImage Image xipImage bootpImage uImage dtbImage dtbuImage: vmlinux $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/$@ zinstall install: vmlinux diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile index c608c98..a8f4251 100644 --- a/arch/arm/boot/Makefile +++ b/arch/arm/boot/Makefile @@ -66,15 +66,19 @@ quiet_cmd_uimage = UIMAGE $@ ifeq ($(CONFIG_ZBOOT_ROM),y) $(obj)/uImage: LOADADDR=$(CONFIG_ZBOOT_ROM_TEXT) +$(obj)/dtbuImage: LOADADDR=$(CONFIG_ZBOOT_ROM_TEXT) else $(obj)/uImage: LOADADDR=$(ZRELADDR) +$(obj)/dtbuImage: LOADADDR=$(ZRELADDR) endif ifeq ($(CONFIG_THUMB2_KERNEL),y) # Set bit 0 to 1 so that "mov pc, rx" switches to Thumb-2 mode $(obj)/uImage: STARTADDR=$(shell echo $(LOADADDR) | sed -e "s/.$$/1/") +$(obj)/dtbuImage: STARTADDR=$(shell echo $(LOADADDR) | sed -e "s/.$$/1/") else $(obj)/uImage: STARTADDR=$(LOADADDR) +$(obj)/dtbuImage: STARTADDR=$(LOADADDR) endif $(obj)/uImage: $(obj)/zImage FORCE @@ -97,6 +101,10 @@ $(obj)/dtbImage: $(obj)/dt/dtb FORCE $(call if_changed,objcopy) @echo ' Kernel: $@ is ready' +$(obj)/dtbuImage: $(obj)/dtbImage FORCE + $(call if_changed,uimage) + @echo ' Image $@ is ready' + PHONY += initrd FORCE initrd: @test "$(INITRD_PHYS)" != "" || \ -- 1.7.1

15 years

[PATCH] ARM: Tegra: dt: HACK: Support Seaboard not Harmony

by Stephen Warren

(Do not apply) This is only necessary at present since the devicetree support relies on some aspects of some existing hard-coded board file for some parts of initialization. In the long run, that code can be ported to devicetree too. Signed-off-by: Stephen Warren <swarren(a)nvidia.com> --- I needed to test devicetree support on Tegra Seaboard rather than Harmony. This patch is the changes I needed to make to have that work. It builds on the previous patches I recently posted. It's only an FYI just in case anyone else finds it useful. arch/arm/boot/dts/tegra-harmony.dts | 14 ++++++-------- arch/arm/mach-tegra/board-dt.c | 14 ++------------ 2 files changed, 8 insertions(+), 20 deletions(-) diff --git a/arch/arm/boot/dts/tegra-harmony.dts b/arch/arm/boot/dts/tegra-harmony.dts index 82fa0c2..6fe09d7 100644 --- a/arch/arm/boot/dts/tegra-harmony.dts +++ b/arch/arm/boot/dts/tegra-harmony.dts @@ -9,7 +9,8 @@ interrupt-parent = <&intc>; chosen { - bootargs = "vmalloc=192M video=tegrafb console=ttyS0,115200n8 root=/dev/mmcblk0p2 rw rootdelay=2"; + /*bootargs = " vmalloc=192M video=tegrafb console=ttyS0,115200n8 root=/dev/mmcblk0p2 rw rootdelay=2";*/ + bootargs = "earlyprintk console=ttyS0,115200n8 root=/dev/mmcblk1p3 ro rootwait noinitrd lp0_vec=0x2000@0x1C406000 loglevel=8 kcrashmem=0x100000@0x02000000 mem=384M@0M nvmem=128M@384M mem=512M@512M"; }; memory { @@ -90,24 +91,21 @@ compatible = "nvidia,tegra250-sdhci"; reg = <0xc8000200 0x200>; interrupts = < 47 >; - gpios = <&gpio 69 0>, /* cd, gpio PI5 */ - <&gpio 57 0>, /* wp, gpio PH1 */ - <&gpio 155 0>; /* power, gpio PT3 */ + status = "disabled"; }; sdhci@c8000400 { compatible = "nvidia,tegra250-sdhci"; reg = <0xc8000400 0x200>; interrupts = < 51 >; - status = "disabled"; + gpios = <&gpio 69 0>, /* cd, gpio PI5 */ + <&gpio 57 0>, /* wp, gpio PH1 */ + <&gpio 70 0>; /* power, gpio PI6 */ }; sdhci@c8000600 { compatible = "nvidia,tegra250-sdhci"; reg = <0xc8000600 0x200>; interrupts = < 63 >; - gpios = <&gpio 58 0>, /* cd, gpio PH2 */ - <&gpio 59 0>, /* wp, gpio PH3 */ - <&gpio 70 0>; /* power, gpio PI6 */ }; }; diff --git a/arch/arm/mach-tegra/board-dt.c b/arch/arm/mach-tegra/board-dt.c index 7b9d469..b67c382 100644 --- a/arch/arm/mach-tegra/board-dt.c +++ b/arch/arm/mach-tegra/board-dt.c @@ -36,7 +36,7 @@ #include <mach/irqs.h> #include "board.h" -#include "board-harmony.h" +#include "board-seaboard.h" #include "clock.h" static struct resource sdhci_resource1[] = { @@ -126,16 +126,6 @@ static struct platform_device *harmony_devices[] __initdata = { &tegra_sdhci_device4, }; -static void __init tegra_dt_fixup(struct machine_desc *desc, - struct tag *tags, char **cmdline, struct meminfo *mi) -{ - mi->nr_banks = 2; - mi->bank[0].start = PHYS_OFFSET; - mi->bank[0].size = 448 * SZ_1M; - mi->bank[1].start = SZ_512M; - mi->bank[1].size = SZ_512M; -} - static __initdata struct tegra_clk_init_table tegra_dt_clk_init_table[] = { /* name parent rate enabled */ { "uartd", "pll_p", 216000000, true }, @@ -158,7 +148,7 @@ static void __init tegra_dt_init(void) tegra_clk_init_from_table(tegra_dt_clk_init_table); - harmony_pinmux_init(); + seaboard_pinmux_init(); platform_add_devices(harmony_devices, ARRAY_SIZE(harmony_devices)); -- 1.7.1

15 years

IMPORTANT: Upgrade instructions for launch-control 0.3~c10

by Zygmunt Krynicki

IMPORTANT: If you have your own instance of 0.3 deployed from .debs please read on. Hello. This email contains upgrade instructions for 0.3~c9 -> 0.3~c10 upgrade. The upgrade process is not automatic due to django-debian maintainer script backwards-incompatible change. This had to be done because of design bug I discovered while attempting to implement south support. UPGRADE INSTRUCTIONS: 0) Optional step: backup your database (pgdump or copy the sqlite file) 1) Backup database settings: /etc/dbconfig-common/launch-control.conf /etc/launch-control/default-database.conf 2) Upgrade maintainer script support library from the PPA. Install 0.5~c1 of django-debian and python-django-debian 3) Upgrade launch-control to transitional 0.3~c10 from the PPA. First install 0.3~c10 of launch-control and launch-control-$backend (where backend is sqlite or pgsql) Maintainer script will ask you if you want to reinstall database, SAY NO here. At this stage your database settings are lost due to, unfortunately mandatory, django-debian redesign (due to design flaw). 4) Recover two files you backed up earlier. Just copy them over. 5) Reconfigure launch-control. Run sudo dpkg-reconfigure launch-control, this should not ask anything, syslog should have a lot of details about what's happened. 6) Remove legacy configuration directory: rm -rf /etc/django-debian/ Verify that everything works as before. If you encounter any problems please let me know, thanks Best regards Zygmunt Krynicki

15 years

← Newer
1
2
3
4
5
6
7
...
16
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev April 2011