linaro-dev April 2011

linaro-dev@lists.linaro.org

101 participants
154 discussions

[Android: build.git] Create uInitrd instead of ramdisk.img

by Patrik Ryd

In the Linaro set up u-boot will look for uImage and uInitrd. This patch is Linaro specific and should not be contibuted to AOSP. --- core/Makefile | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/core/Makefile b/core/Makefile index 857dd20..f75832a 100644 --- a/core/Makefile +++ b/core/Makefile @@ -309,13 +309,14 @@ INTERNAL_RAMDISK_FILES := $(filter $(TARGET_ROOT_OUT)/%, \ $(ALL_GENERATED_SOURCES) \ $(ALL_DEFAULT_INSTALLED_MODULES)) -BUILT_RAMDISK_TARGET := $(PRODUCT_OUT)/ramdisk.img +BUILT_RAMDISK_TARGET := $(PRODUCT_OUT)/uInitrd # We just build this directly to the install location. INSTALLED_RAMDISK_TARGET := $(BUILT_RAMDISK_TARGET) $(INSTALLED_RAMDISK_TARGET): $(MKBOOTFS) $(INTERNAL_RAMDISK_FILES) | $(MINIGZIP) $(call pretty,"Target ram disk: $@") - $(hide) $(MKBOOTFS) $(TARGET_ROOT_OUT) | $(MINIGZIP) > $@ + $(hide) $(MKBOOTFS) $(TARGET_ROOT_OUT) | $(MINIGZIP) > $(PRODUCT_OUT)/obj/temp_ramdisk.img + mkimage -A arm -O linux -T ramdisk -n "Android Ramdisk Image" -d $(PRODUCT_OUT)/obj/temp_ramdisk.img $@ ifneq ($(strip $(TARGET_NO_KERNEL)),true) -- 1.7.1

15 years, 1 month

[PATCH v2] S5P: GPIO Macro Values Corrected.

by Chander Kashyap

S5PC2XX: Macro values for Pull Up and Driver Strength were wrong. S5PC1XX: Macro values for Driver Strength were wrong. Signed-off-by: Chander Kashyap <chander.kashyap(a)linaro.org> --- Changes for V2: - Macro value order fixed. - Added Changes for S5PC1XX. arch/arm/include/asm/arch-s5pc1xx/gpio.h | 4 ++-- arch/arm/include/asm/arch-s5pc2xx/gpio.h | 7 +++---- 2 files changed, 5 insertions(+), 6 deletions(-) diff --git a/arch/arm/include/asm/arch-s5pc1xx/gpio.h b/arch/arm/include/asm/arch-s5pc1xx/gpio.h index 2df33a6..485b9bf 100644 --- a/arch/arm/include/asm/arch-s5pc1xx/gpio.h +++ b/arch/arm/include/asm/arch-s5pc1xx/gpio.h @@ -149,8 +149,8 @@ void gpio_set_rate(struct s5p_gpio_bank *bank, int gpio, int mode); /* Drive Strength level */ #define GPIO_DRV_1X 0x0 -#define GPIO_DRV_2X 0x1 -#define GPIO_DRV_3X 0x2 +#define GPIO_DRV_3X 0x1 +#define GPIO_DRV_2X 0x2 #define GPIO_DRV_4X 0x3 #define GPIO_DRV_FAST 0x0 #define GPIO_DRV_SLOW 0x1 diff --git a/arch/arm/include/asm/arch-s5pc2xx/gpio.h b/arch/arm/include/asm/arch-s5pc2xx/gpio.h index 05e5b3e..38303e4 100644 --- a/arch/arm/include/asm/arch-s5pc2xx/gpio.h +++ b/arch/arm/include/asm/arch-s5pc2xx/gpio.h @@ -99,14 +99,13 @@ void gpio_set_rate(struct s5p_gpio_bank *bank, int gpio, int mode); /* Pull mode */ #define GPIO_PULL_NONE 0x0 #define GPIO_PULL_DOWN 0x1 -#define GPIO_PULL_UP 0x2 +#define GPIO_PULL_UP 0x3 /* Drive Strength level */ #define GPIO_DRV_1X 0x0 -#define GPIO_DRV_2X 0x1 -#define GPIO_DRV_3X 0x2 +#define GPIO_DRV_3X 0x1 +#define GPIO_DRV_2X 0x2 #define GPIO_DRV_4X 0x3 #define GPIO_DRV_FAST 0x0 #define GPIO_DRV_SLOW 0x1 - #endif -- 1.7.1

15 years, 1 month

Working around a Tegra 2 errata for Natty

by Michael Hope

Hi there. There's a problem with the thread local storage register in the Tegra 2 which is exposed by Ubuntu switching to GCC 4.5. The fault is quite serious and causes many applications to segfault. There's more details in LP: #739374. The problem is Tegra 2 specific and is caused by bit 20 of the CP15 thread pointer register always reading as zero. With GCC 4.4, access to the thread pointer always goes through the GLIBC helper function '__aeabi_read_tp' which calls into the kernel which then reads and returns CP15. Either GLIBC or the kernel[1] itself swaps bit 20 and bit 0 which works around the problem. This doesn't work in GCC 4.5 as it reads CP15 directly instead. There are a few solutions: Change GCC to swap bits 20 and 0 as well. This is a hack and requires rebuilding the archive. The performance should be small. Change GCC to always call the helper function. The helper function can detect the processor and call into the kernel on Tegra devices, or return CP15 directly on others. IFUNC could be used to reduce the overhead. The archive would have to be rebuilt. Worse performance than above, but still better than 4.4. Change GLIBC to allocate thread local storage on a 2 M boundary. Bit 20 would always be zero. The thread pointer is a base address so the thread could still have more than 2 M of thread local data. GLIBC would have to be rebuilt and this limits the maximum number of threads. No runtime performance hit. I prefer changing GLIBC. Any thoughts? Linaro doesn't support this chip. Who should do the work? Linaro? Ubuntu? The EGLIBC community? -- Michael [1] Dave and I disagree where it is but neither have tracked it down

15 years, 1 month

[NOTES] 4/13 Linaro Developer Platform Weekly Status Meeting

by Tom Gall

Enclosed you'll find a link to the agenda, notes and actions from the Linaro Developer Platforms Weekly Status meeting held on April 13th in #linaro-meeting on irc.freenode.net at 15:00 UTC. https://wiki.linaro.org/Platform/DevPlatform/Meetings/2011-04-13 Actions from the meeting where as follows: * tgall_foo to check with GrueMaster for recommendations on checking minimal audio functionality on armel * fturgis to ask linaro-dev whether systemtap support for probing kernel modules is wanted * slangasek to check why armel-cross-toolchain-base FTBFS wasn't caught in lucas's archive rebuild * slangasek to review/merge/upload armel-cross-toolchain-base 1.62 Regards, Tom (tgall_foo) 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

15 years, 1 month

Embedded memory management interest group list

by Jesse Barker

Hi all, One of the big issues we've been faced with at Linaro is around GPU and multimedia device integration, in particular the memory management requirements for supporting them on ARM. This next cycle, we'll be focusing on driving consensus around a unified memory management solution for embedded systems that support multiple architectures and SoCs. This is listed as part of our working set of requirements for the next six-month cycle (in spite of the URL, this is not being treated as a graphics-specific topic - we also have participation from multimedia and kernel working group folks): https://wiki.linaro.org/Cycles/1111/TechnicalTopics/Graphics I am working on getting the key technical decision makers to provide input and participate in the requirements collection and design for a unified solution. We had an initial birds-of-a-feather discussion at the Embedded Linux Conference in San Francisco this past week to kick off the effort in preparation for the first embedded-memory-management mini-sprint in Budapest week of May 9th at Linaro@UDS. One of the outcomes of the BoF was the need for a mailing list to coordinate ideas, planning, etc. The subscription management for the list is located at http://lists.linaro.org/mailman/listinfo/linaro-mm-sig. The mini-summit in Budapest will have live audio and an IRC channel for those that want to participate (details to go out on the list). We expect to have additional summits over the course of the cycle, with the next one likely at Linux Plumbers in September (though, I would like to try for one more before then). cheers, Jesse

15 years, 1 month

Embedded memory management interest group list

by Jesse Barker

15 years, 1 month

Do we have a memory footprint evaluation of ubuntu-desktop?

by Eric Miao

All, It was found that the ubuntu-desktop is a bit memory hungry on this i.MX53 QuickStart board. There is a large chunk of memory being reserved for the graphics/video drivers, and the memory size reserved has to consider the worst case. And we have to live with this before the unified memory allocator is available. I don't yet have a /proc/meminfo after system is right up, I'll get some statistics a bit later. However, I do want to know if we have some memory footprint evaluation of the existing ubuntu-desktop (we are using unity-2d)? And what can we do to improve on that? - eric

15 years, 2 months

Notes & Actions: Linaro Graphics Working Group - Apr 13, 2011

by Alexandros Frantzis

Hi, notes and actions from our Wednesday graphics working group call are available on the wiki: + https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Notes/2011-04-13 Details about when and where of this meeting can be found here: + https://wiki.linaro.org/WorkingGroups/Middleware/Graphics#Weekly%20Public%2… Summary ======= * cairo-gles2 * Ported cairo-clock and cairogears to cairo-gles2. * Uploaded gles2 enabled packages for cairo, cairogears and cairo-clock to ppa:linaro-graphics-wg/ppa * Validated on OMAP4 (cairogears/cairoclock don't use any the repeat functionality missing in GL_IMG_texture_npot). * Benchmarks * Spandex unix-x11 branch merged in current upstream development tree. * Found issue with glcompbench rendering on ARM (coding error due to working with Mesa GLES spec violation - bug to be filed). * GLproxy - packages pushed to graphics working group ppa. * DRM/Mali - new Mali device driver drop (released 2011-04-01) integrated into git repository on git.linaro.org. * compiz work basically done (modulo some bug fixing), nux work underway. Thanks, -- - Alexandros

15 years, 2 months

[PATCH 0/2] Modified Powertop2.0 to support ARM processor

by amit.kachhap＠linaro.org

The following set of patches modify the powertop version 2.0 to work for ARM platform. The C states and P states was measured after doing these changes in powertop. Amit Daniel Kachhap (2): Modified Powertop to support ARM processor Added an arm compiler flag cpu/cpu.cpp | 8 +++++++- 1 files changed, 7 insertions(+), 1 deletions(-) [PATCH 1/2] Modified Powertop to support ARM processor [PATCH 2/2] Added an arm compiler flag

15 years, 2 months

[PATCH] S5PC2XX: GPIO Macro Values Corrected.

by Chander Kashyap

Macro values for Pull Up and Driver Strength were wrong. Signed-off-by: Chander Kashyap <chander.kashyap(a)linaro.org> --- arch/arm/include/asm/arch-s5pc2xx/gpio.h | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/include/asm/arch-s5pc2xx/gpio.h b/arch/arm/include/asm/arch-s5pc2xx/gpio.h index 05e5b3e..7bfa8e8 100644 --- a/arch/arm/include/asm/arch-s5pc2xx/gpio.h +++ b/arch/arm/include/asm/arch-s5pc2xx/gpio.h @@ -99,12 +99,12 @@ void gpio_set_rate(struct s5p_gpio_bank *bank, int gpio, int mode); /* Pull mode */ #define GPIO_PULL_NONE 0x0 #define GPIO_PULL_DOWN 0x1 -#define GPIO_PULL_UP 0x2 +#define GPIO_PULL_UP 0x3 /* Drive Strength level */ #define GPIO_DRV_1X 0x0 -#define GPIO_DRV_2X 0x1 -#define GPIO_DRV_3X 0x2 +#define GPIO_DRV_2X 0x2 +#define GPIO_DRV_3X 0x1 #define GPIO_DRV_4X 0x3 #define GPIO_DRV_FAST 0x0 #define GPIO_DRV_SLOW 0x1 -- 1.7.1

15 years, 2 months

← Newer
1
...
4
5
6
7
8
9
10
...
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