linaro-dev April 2011

linaro-dev@lists.linaro.org

101 participants
154 discussions

[PATCH android/device/linaro/beagleboard] Move the common package and benchmark definitions into common folder

by Jeremy Chang

Signed-off-by: Jeremy Chang <jeremy.chang(a)linaro.org> --- ZeroXBenchmark.mk | 96 ----------------------------------------------------- beagleboard.mk | 32 +----------------- 2 files changed, 1 insertions(+), 127 deletions(-) delete mode 100644 ZeroXBenchmark.mk diff --git a/ZeroXBenchmark.mk b/ZeroXBenchmark.mk deleted file mode 100644 index e78047d..0000000 --- a/ZeroXBenchmark.mk +++ /dev/null @@ -1,96 +0,0 @@ -UNIXBENCH_BENCH_APPS := \ - bench_ubench_hanoi \ - bench_ubench_syscall \ - bench_ubench_context1 \ - bench_ubench_pipe \ - bench_ubench_spawn \ - bench_ubench_execl \ - bench_ubench_looper \ - bench_ubench_fstime \ - bench_ubench_arithoh \ - bench_ubench_register \ - bench_ubench_short \ - bench_ubench_int \ - bench_ubench_long \ - bench_ubench_float \ - bench_ubench_double \ - bench_ubench_dhry2 \ - bench_ubench_dhry2reg \ - bench_ubench_whetstone-double - -LIBMICRO_BENCH_APPS := \ - bench_getpid \ - bench_bind \ - bench_cascade_mutex \ - bench_cascade_fcntl \ - bench_cascade_flock \ - bench_chdir \ - bench_close \ - bench_close_tcp \ - bench_connection \ - bench_dup \ - bench_exec \ - bench_exit \ - bench_exp \ - bench_fcntl \ - bench_fcntl_ndelay \ - bench_file_lock \ - bench_fork \ - bench_getenv \ - bench_gettimeofday \ - bench_getpeername \ - bench_getrusage \ - bench_getsockname \ - bench_isatty \ - bench_listen \ - bench_localtime_r \ - bench_log \ - bench_longjmp \ - bench_lrand48 \ - bench_lseek \ - bench_malloc \ - bench_memcpy \ - bench_memmove \ - bench_memrand \ - bench_memset \ - bench_mktime \ - bench_mprotect \ - bench_mmap \ - bench_msync \ - bench_munmap \ - bench_mutex \ - bench_nop \ - bench_open \ - bench_pipe \ - bench_poll \ - bench_pread \ - bench_pthread_create \ - bench_pwrite \ - bench_read \ - bench_realpath \ - bench_recurse \ - bench_select \ - bench_setsockopt \ - bench_sigaction \ - bench_siglongjmp \ - bench_signal \ - bench_sigprocmask \ - bench_socket \ - bench_socketpair \ - bench_stat \ - bench_strcasecmp \ - bench_strchr \ - bench_strcmp \ - bench_strcpy \ - bench_strftime \ - bench_strlen \ - bench_strtol \ - bench_system \ - bench_time \ - bench_times \ - bench_write \ - bench_writev - -ZEROXBENCHMARK_NATIVE_APPS := \ - $(UNIXBENCH_BENCH_APPS) \ - $(LIBMICRO_BENCH_APPS) diff --git a/beagleboard.mk b/beagleboard.mk index 015b605..2e40056 100644 --- a/beagleboard.mk +++ b/beagleboard.mk @@ -1,37 +1,7 @@ # The beagleboard product that is specialized for beagleboard. - -include $(LOCAL_PATH)/ZeroXBenchmark.mk - -PRODUCT_PACKAGES := \ - ZeroXBenchmark \ - libmicro \ - AccountAndSyncSettings \ - AlarmClock \ - AlarmProvider \ - Bluetooth \ - Calculator \ - Calendar \ - Camera \ - CertInstaller \ - DrmProvider \ - Email \ - Gallery3D \ - LatinIME \ - Mms \ - Music \ - Provision \ - Settings \ - Sync \ - Updater \ - CalendarProvider \ - SyncProvider \ - $(ZEROXBENCHMARK_NATIVE_APPS) - - -$(call inherit-product, $(SRC_TARGET_DIR)/product/core.mk) +$(call inherit-product, device/linaro/common/common.mk) $(call inherit-product, device/linaro/beagleboard/device.mk) -# Overrides PRODUCT_BRAND := beagleboard PRODUCT_DEVICE := beagleboard PRODUCT_NAME := beagleboard -- 1.7.1

13 years, 4 months

[PATCH 1/1] arm: pmu: support pmu/perf on OMAP4

by Avik Sil

This patch fixes the bug #702999 (oprofile failure on panda (omap4)). It is based on [1] that fixes the issue by enabling pmu events for omap4, which are routed from CTI. The patch attached is a modified version of [1] with removal of some CTI register reads that cause hang in the initial phase of booting. The patch has been verified on Panda board and the profile data could be generated that are shown by opreport. Although, there is a lockdep warning "possible circular locking dependency detected" when "opcontrol --start" is called for the first time. Regards, Avik [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-March/045283.html Signed-off-by: Avik Sil <avik.sil(a)linaro.org> --- arch/arm/include/asm/cti.h | 157 ++++++++++++++++++++++++++++ arch/arm/include/asm/pmu.h | 15 ++- arch/arm/kernel/perf_event.c | 15 ++- arch/arm/mach-omap2/devices.c | 82 ++++++++++++++- arch/arm/plat-omap/include/plat/omap44xx.h | 2 + 5 files changed, 262 insertions(+), 9 deletions(-) create mode 100644 arch/arm/include/asm/cti.h diff --git a/arch/arm/include/asm/cti.h b/arch/arm/include/asm/cti.h new file mode 100644 index 0000000..26e7450 --- /dev/null +++ b/arch/arm/include/asm/cti.h @@ -0,0 +1,157 @@ +#ifndef __ASMARM_CTI_H +#define __ASMARM_CTI_H + +#include <asm/io.h> + +/* The registers' definition is from section 3.2 of + * Embedded Cross Trigger Revision: r0p0 + */ +#define CTICONTROL 0x000 +#define CTISTATUS 0x004 +#define CTILOCK 0x008 +#define CTIPROTECTION 0x00C +#define CTIINTACK 0x010 +#define CTIAPPSET 0x014 +#define CTIAPPCLEAR 0x018 +#define CTIAPPPULSE 0x01c +#define CTIINEN 0x020 +#define CTIOUTEN 0x0A0 +#define CTITRIGINSTATUS 0x130 +#define CTITRIGOUTSTATUS 0x134 +#define CTICHINSTATUS 0x138 +#define CTICHOUTSTATUS 0x13c +#define CTIPERIPHID0 0xFE0 +#define CTIPERIPHID1 0xFE4 +#define CTIPERIPHID2 0xFE8 +#define CTIPERIPHID3 0xFEC +#define CTIPCELLID0 0xFF0 +#define CTIPCELLID1 0xFF4 +#define CTIPCELLID2 0xFF8 +#define CTIPCELLID3 0xFFC + +/* The below are from section 3.6.4 of + * CoreSight v1.0 Architecture Specification + */ +#define LOCKACCESS 0xFB0 +#define LOCKSTATUS 0xFB4 + +/* write this value to LOCKACCESS will unlock the module, and + * other value will lock the module + */ +#define LOCKCODE 0xC5ACCE55 + +/** + * struct cti - cross trigger interface struct + * @base: mapped virtual address for the cti base + * @irq: irq number for the cti + * @trig_out_for_irq: triger out number which will cause + * the @irq happen + * + * cti struct used to operate cti registers. + */ +struct cti { + void __iomem *base; + int irq; + int trig_out_for_irq; +}; + +/** + * cti_init - initialize the cti instance + * @cti: cti instance + * @base: mapped virtual address for the cti base + * @irq: irq number for the cti + * @trig_out: triger out number which will cause + * the @irq happen + * + * called by machine code to pass the board dependent + * @base, @irq and @trig_out to cti. + */ +static inline void cti_init(struct cti *cti, + void __iomem *base, int irq, int trig_out) +{ + cti->base = base; + cti->irq = irq; + cti->trig_out_for_irq = trig_out; +} + +/** + * cti_map_trigger - use the @chan to map @trig_in to @trig_out + * @cti: cti instance + * @trig_in: trigger in number + * @trig_out: trigger out number + * @channel: channel number + * + * This function maps one trigger in of @trig_in to one trigger + * out of @trig_out using the channel @chan. + */ +static inline void cti_map_trigger(struct cti *cti, + int trig_in, int trig_out, int chan) +{ + void __iomem *base = cti->base; + + __raw_writel(BIT(chan), base + CTIINEN + trig_in * 4); + __raw_writel(BIT(chan), base + CTIOUTEN + trig_out * 4); +} + +/** + * cti_enable - enable the cti module + * @cti: cti instance + * + * enable the cti module + */ +static inline void cti_enable(struct cti *cti) +{ + __raw_writel(0x1, cti->base + CTICONTROL); +} + +/** + * cti_disable - disable the cti module + * @cti: cti instance + * + * enable the cti module + */ +static inline void cti_disable(struct cti *cti) +{ + __raw_writel(0, cti->base + CTICONTROL); +} + +/** + * cti_irq_ack - clear the cti irq + * @cti: cti instance + * + * clear the cti irq + */ +static inline void cti_irq_ack(struct cti *cti) +{ + void __iomem *base = cti->base; + unsigned long val; + + val = __raw_readl(base + CTIINTACK); + val |= BIT(cti->trig_out_for_irq); + __raw_writel(val, base + CTIINTACK); +} + +/** + * cti_unlock - unlock cti module + * @cti: cti instance + * + * unlock the cti module, or else any writes to the cti + * module is not allowed. + */ +static inline void cti_unlock(struct cti *cti) +{ + __raw_writel(LOCKCODE, cti->base + LOCKACCESS); +} + +/** + * cti_lock - lock cti module + * @cti: cti instance + * + * lock the cti module, so any writes to the cti + * module will be not allowed. + */ +static inline void cti_lock(struct cti *cti) +{ + __raw_writel(~LOCKCODE, cti->base + LOCKACCESS); +} +#endif diff --git a/arch/arm/include/asm/pmu.h b/arch/arm/include/asm/pmu.h index 7544ce6..7ca3d15 100644 --- a/arch/arm/include/asm/pmu.h +++ b/arch/arm/include/asm/pmu.h @@ -22,13 +22,22 @@ enum arm_pmu_type { /* * struct arm_pmu_platdata - ARM PMU platform data * - * @handle_irq: an optional handler which will be called from the interrupt and - * passed the address of the low level handler, and can be used to implement - * any platform specific handling before or after calling it. + * @handle_irq: an optional handler which will be called from the + * interrupt and passed the address of the low level handler, + * and can be used to implement any platform specific handling + * before or after calling it. + * @enable_irq: an optional handler which will be called after + * request_irq and be used to handle some platform specific + * irq enablement + * @disable_irq: an optional handler which will be called before + * free_irq and be used to handle some platform specific + * irq disablement */ struct arm_pmu_platdata { irqreturn_t (*handle_irq)(int irq, void *dev, irq_handler_t pmu_handler); + void (*enable_irq)(int irq); + void (*disable_irq)(int irq); }; #ifdef CONFIG_CPU_HAS_PMU diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c index 69cfee0..86db755 100644 --- a/arch/arm/kernel/perf_event.c +++ b/arch/arm/kernel/perf_event.c @@ -426,14 +426,18 @@ armpmu_reserve_hardware(void) pr_warning("unable to request IRQ%d for ARM perf " "counters\n", irq); break; - } + } else if (plat->enable_irq) + plat->enable_irq(irq); } if (err) { for (i = i - 1; i >= 0; --i) { irq = platform_get_irq(pmu_device, i); - if (irq >= 0) + if (irq >= 0) { + if (plat->disable_irq) + plat->disable_irq(irq); free_irq(irq, NULL); + } } release_pmu(pmu_device); pmu_device = NULL; @@ -446,11 +450,16 @@ static void armpmu_release_hardware(void) { int i, irq; + struct arm_pmu_platdata *plat = + dev_get_platdata(&pmu_device->dev); for (i = pmu_device->num_resources - 1; i >= 0; --i) { irq = platform_get_irq(pmu_device, i); - if (irq >= 0) + if (irq >= 0) { + if (plat->disable_irq) + plat->disable_irq(irq); free_irq(irq, NULL); + } } armpmu->stop(); diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c index d478f53..cbd6b35 100644 --- a/arch/arm/mach-omap2/devices.c +++ b/arch/arm/mach-omap2/devices.c @@ -22,6 +22,7 @@ #include <asm/mach-types.h> #include <asm/mach/map.h> #include <asm/pmu.h> +#include <asm/cti.h> #include <plat/tc.h> #include <plat/board.h> @@ -386,20 +387,95 @@ static struct resource omap3_pmu_resource = { .flags = IORESOURCE_IRQ, }; +static struct resource omap4_pmu_resource[] = { + { + .start = OMAP44XX_IRQ_CTI0, + .end = OMAP44XX_IRQ_CTI0, + .flags = IORESOURCE_IRQ, + }, + { + .start = OMAP44XX_IRQ_CTI1, + .end = OMAP44XX_IRQ_CTI1, + .flags = IORESOURCE_IRQ, + } +}; + static struct platform_device omap_pmu_device = { .name = "arm-pmu", .id = ARM_PMU_DEVICE_CPU, .num_resources = 1, }; +static struct arm_pmu_platdata omap4_pmu_data; +static struct cti omap4_cti[2]; + +static void omap4_enable_cti(int irq) +{ + if (irq == OMAP44XX_IRQ_CTI0) + cti_enable(&omap4_cti[0]); + else if (irq == OMAP44XX_IRQ_CTI1) + cti_enable(&omap4_cti[1]); +} + +static void omap4_disable_cti(int irq) +{ + if (irq == OMAP44XX_IRQ_CTI0) + cti_disable(&omap4_cti[0]); + else if (irq == OMAP44XX_IRQ_CTI1) + cti_disable(&omap4_cti[1]); +} + +static irqreturn_t omap4_pmu_handler(int irq, void *dev, irq_handler_t handler) +{ + if (irq == OMAP44XX_IRQ_CTI0) + cti_irq_ack(&omap4_cti[0]); + else if (irq == OMAP44XX_IRQ_CTI1) + cti_irq_ack(&omap4_cti[1]); + + return handler(irq, dev); +} + +static void omap4_configure_pmu_irq(void) +{ + void __iomem *base0; + void __iomem *base1; + + base0 = ioremap(OMAP44XX_CTI0_BASE, SZ_4K); + base1 = ioremap(OMAP44XX_CTI1_BASE, SZ_4K); + if (!base0 && !base1) { + pr_err("ioremap for OMAP4 CTI failed\n"); + return; + } + + /*configure CTI0 for pmu irq routing*/ + cti_init(&omap4_cti[0], base0, OMAP44XX_IRQ_CTI0, 6); + cti_unlock(&omap4_cti[0]); + cti_map_trigger(&omap4_cti[0], 1, 6, 2); + + /*configure CTI1 for pmu irq routing*/ + cti_init(&omap4_cti[1], base1, OMAP44XX_IRQ_CTI1, 6); + cti_unlock(&omap4_cti[1]); + cti_map_trigger(&omap4_cti[1], 1, 6, 2); + + omap4_pmu_data.handle_irq = omap4_pmu_handler; + omap4_pmu_data.enable_irq = omap4_enable_cti; + omap4_pmu_data.disable_irq = omap4_disable_cti; +} + static void omap_init_pmu(void) { - if (cpu_is_omap24xx()) + if (cpu_is_omap24xx()) { omap_pmu_device.resource = &omap2_pmu_resource; - else if (cpu_is_omap34xx()) + } else if (cpu_is_omap34xx()) { omap_pmu_device.resource = &omap3_pmu_resource; - else + } else if (cpu_is_omap44xx()) { + omap_pmu_device.resource = omap4_pmu_resource; + omap_pmu_device.num_resources = 2; + omap_pmu_device.dev.platform_data = &omap4_pmu_data; + omap4_configure_pmu_irq(); + } else { return; + } platform_device_register(&omap_pmu_device); } diff --git a/arch/arm/plat-omap/include/plat/omap44xx.h b/arch/arm/plat-omap/include/plat/omap44xx.h index ea2b8a6..b127a16 100644 --- a/arch/arm/plat-omap/include/plat/omap44xx.h +++ b/arch/arm/plat-omap/include/plat/omap44xx.h @@ -57,5 +57,7 @@ #define OMAP44XX_HSUSB_OHCI_BASE (L4_44XX_BASE + 0x64800) #define OMAP44XX_HSUSB_EHCI_BASE (L4_44XX_BASE + 0x64C00) +#define OMAP44XX_CTI0_BASE 0x54148000 +#define OMAP44XX_CTI1_BASE 0x54149000 #endif /* __ASM_ARCH_OMAP44XX_H */ -- 1.7.0.4

13 years, 4 months

I'm away today.

by Zygmunt Krynicki

Hi everyone. Unfortunately I have to attend my young ones to the hospital. I will take a swap day for Saturday once we return. Best regards Zygmunt

13 years, 4 months

[PATCH 0/2] SROM config code moved to s5p-common directory

by Chander Kashyap

SROM config code is make common for S5P series boards. smdkc100.c refers to s5p_config_srom in s5p-common directory. Chander Kashyap (2): S5P: SROM config code moved to common directory s5p-common S5PC1XX: Refers to SROM config code in s5p-common directory. Header file renamed from smc.h to sromc.h. arch/arm/cpu/armv7/s5p-common/Makefile | 3 +- arch/arm/cpu/armv7/s5p-common/sromc.c | 49 ++++++++++++++++++++++++++ arch/arm/cpu/armv7/s5pc1xx/Makefile | 1 - arch/arm/cpu/armv7/s5pc1xx/sromc.c | 49 -------------------------- arch/arm/include/asm/arch-s5pc1xx/smc.h | 53 ----------------------------- arch/arm/include/asm/arch-s5pc1xx/sromc.h | 53 +++++++++++++++++++++++++++++ board/samsung/smdkc100/smdkc100.c | 4 +- 7 files changed, 106 insertions(+), 106 deletions(-) create mode 100644 arch/arm/cpu/armv7/s5p-common/sromc.c delete mode 100644 arch/arm/cpu/armv7/s5pc1xx/sromc.c delete mode 100644 arch/arm/include/asm/arch-s5pc1xx/smc.h create mode 100644 arch/arm/include/asm/arch-s5pc1xx/sromc.h

13 years, 4 months

Importance (or not) of kernel modules dynamic instrumentation through systemtap

by Frederic Turgis

Hi all, systemtap allows instrumenting dynamically kernel functions with the interest of a scripting language that gives access to function parameters or the capability to directly write C code. https://wiki.linaro.org/Platform/DevPlatform/systemtap I have backported/implemented the support of 2.6.37/2.6.38 kernels in current version of Ubuntu systemtap package (v1.3), which is now uploaded. However, I missed an issue that prevents instrumenting kernel modules on ARM. In fact, I missed it because at work, we are generally probing our drivers (and scheduler/V4L2/...), which are statically linked. We are then wondering in the group if we can live without the capability to instrument kernel modules with systemtap. Knowing that v1.4, which fixes this issue, has been recently migrated to "Debian tested". And issue and fix are documented on the wiki so you can still recompile the tool ;-) Therefore, if this capability is critical to you, please speak. Or wait for upgrade to v1.4 !!!! Regards Fred

13 years, 4 months

Linaro 11.05 Beta-2

by Jamie Bennett

Hi, Currently there is no Ubuntu-based milestone image release between the Beta (2011-03-31) and Release Candidate (2011-05-21); this is a period of 51 days. In a fast moving project like Linaro, a lot can happen in 51 days. With this in mind and to help focus our testing initiative before RC the decision has been made to introduce a Linaro 11.05 Beta-2 milestone. The Beta-2 milestone will take advantage of the fact that the Ubuntu final release happens on 2011-04-28. Linaro 11.05 Beta-2 will be released on the same day, exactly one month before final and will incorporate all the Ubuntu final goodness. It is expected that this milestone will have the greatest test coverage, both manual and automated, of any release so far and will be a dry-run of what is expected in the run up to final release. On 2011-04-26 the Beta-2 candidate images will be selected and http://qatracker.linaro.org set up accordingly. If you have the appropriate hardware please help to test the images and report your results to qatracker using the instructions at: https://wiki.linaro.org/QA/QATracker An announcement will be made on 2011-04-26 to declare the images ready for consumption. Happy Testing ! Regards, Jamie. -- Linaro Release Manager | Platform Project Manager

13 years, 4 months

Likely empty space in a processes's virtual address space

by Michael Hope

Hi there. The address space randomisation feature in 2.6.35 and above kernels breaks GCC's precompiled headers support. GCC works by compiling the header once, dumping the internal format out to disk, and then mmap()ing it back in at a fixed address. The solution for other architectures is for GCC to pick a spot in the virtual address space that is likely to be free and map the PCH in there. Most of them use 0x60000000 which from a bit of poking seems to be fine on ARM as well. Can someone point me at the typical virtual address space for a ARM Linux process? How does 0x60000000 sound? For reference, this is the code in kernel/arch/arm/mm/mmap.c that exposes the problem: /* 8 bits of randomness in 20 address space bits */ if (current->flags & PF_RANDOMIZE) addr += (get_random_int() % (1 << 8)) << PAGE_SHIFT; The GCC code with addresses for other architectures lives at: http://bazaar.launchpad.net/~linaro-toolchain-dev/gcc-linaro/4.5/view/head:… /proc/self/maps on a simple program gives: 00008000-00009000 r-xp 00000000 00:14 28747240 /home/michaelh/a.out 00010000-00011000 r--p 00000000 00:14 28747240 /home/michaelh/a.out 00011000-00012000 rw-p 00001000 00:14 28747240 /home/michaelh/a.out 00012000-00033000 rw-p 00000000 00:00 0 [heap] 2ab4c000-2ab4d000 rw-p 00000000 00:00 0 2ab5c000-2ab5e000 rw-p 00000000 00:00 0 2ab89000-2aba0000 r-xp 00000000 00:0d 26352847 /lib/ld-2.12.1.so 2aba8000-2aba9000 r--p 00017000 00:0d 26352847 /lib/ld-2.12.1.so 2aba9000-2abaa000 rw-p 00018000 00:0d 26352847 /lib/ld-2.12.1.so 2ac35000-2ac36000 rw-p 00000000 00:00 0 2ac93000-2aca0000 r-xp 00000000 00:0d 26352795 /lib/libbz2.so.1.0.4 2aca0000-2aca7000 ---p 0000d000 00:0d 26352795 /lib/libbz2.so.1.0.4 2aca7000-2aca8000 r--p 0000c000 00:0d 26352795 /lib/libbz2.so.1.0.4 2aca8000-2aca9000 rw-p 0000d000 00:0d 26352795 /lib/libbz2.so.1.0.4 2aca9000-2ad96000 r-xp 00000000 00:0d 26352832 /lib/libc-2.12.1.so 2ad96000-2ad9e000 ---p 000ed000 00:0d 26352832 /lib/libc-2.12.1.so 2ad9e000-2ada0000 r--p 000ed000 00:0d 26352832 /lib/libc-2.12.1.so 2ada0000-2ada1000 rw-p 000ef000 00:0d 26352832 /lib/libc-2.12.1.so 2ada1000-2ada4000 rw-p 00000000 00:00 0 7ed9c000-7edbd000 rw-p 00000000 00:00 0 [stack] 0x60000000 is well above the shared libraries and well below the stack. -- Michael

13 years, 4 months

Linaro 11.05 weekly image testing 2011-04-14

by Jamie Bennett

Hi, This is a message sent out once per week to call on our community to help test the Linaro evaluation builds we produce. If you have supported hardware, as found on: http://snapshots.linaro.org/11.05-daily/linaro-hwpacks/ please help our initiative by testing the official Linaro Evaluation Build (LEB): Ubuntu Desktop: http://snapshots.linaro.org/11.05-daily/linaro-ubuntu-desktop/ and our Community images: Nano: http://snapshots.linaro.org/11.05-daily/linaro-nano/ ALIP: http://snapshots.linaro.org/11.05-daily/linaro-alip/ Developer Tools: http://snapshots.linaro.org/11.05-daily/linaro-developer/ Make your way to: http://wiki.linaro.org/Releases/DailyBuilds for an explanation on 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

13 years, 4 months

[PATCH] ARM: EXYNOS4: Register HSMMC2 before HSMMC0 on SMDKV310 board

by Tushar Behera

On Exynos4210 SOC, of all the HSMMC controllers only HSMMC2 can be used as a boot media. Hence the default SD/MMC card should be connected to HSMMC2. The secondary card is connected to HSMMC0. If HSMMC0 is registered before HSMMC2, the device node for default MMC card changes depending on whether secondary card is connected or not. It creates problem in mounting the file-system present in default SD/MMC card. Hence HSMMC2 should be registered before HSMMC0. Signed-off-by: Tushar Behera <tushar.behera(a)linaro.org> --- arch/arm/mach-exynos4/mach-smdkv310.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c b/arch/arm/mach-exynos4/mach-smdkv310.c index f6b1c7e..4f34d43 100644 --- a/arch/arm/mach-exynos4/mach-smdkv310.c +++ b/arch/arm/mach-exynos4/mach-smdkv310.c @@ -168,9 +168,9 @@ static struct i2c_board_info i2c_devs1[] __initdata = { }; static struct platform_device *smdkv310_devices[] __initdata = { + &s3c_device_hsmmc2, &s3c_device_hsmmc0, &s3c_device_hsmmc1, - &s3c_device_hsmmc2, &s3c_device_hsmmc3, &s3c_device_i2c1, &s3c_device_rtc, -- 1.7.1

13 years, 4 months

[lava] Android image support

by Jeremy Chang

Hi, list: Just want to let you know, especially for the validation team members, I am trying to do Android support on lava, so I created a branch, lp:~jeremychang/lava/android-support Hi, Paul, maybe you can help me give it a review. Thanks! . I am on my personal environment, so I changed some configs to fit my environment for testing. Also I documented them here in https://wiki.linaro.org/JeremyChang/Sandbox/LavaAndroidValidation Basically I would like to a make a prototype based on the existing Lava to do the testing/Validation for Android from the deployment to submit_result. Now I already made it do the continual process of starting from the deployment, reboot to Android, do basic test and simple monkey test. Now what I thinking is, also the trickiest item seems that how to present the test results of various Android validations to dashboard [1]. Due to platform difference, abrek, python code could not run on Android target, there is a need to generate the json bundle in lava for sending to the dashboard. I think for android validation, benchmark/testing, abrek could not be used. I still need to figure out more about the powerfulness the dashboard, like when the attachment function should be used for uploading the result? Regarding to generating the bundle, I will check what's the way to generate the reasonable software_context and hardware_context for android. Hopefully soon android images can be tested by lava with the dailybuild android image tarballs [2]. Same time welcome any feedback. Thanks. Regards, -Jeremy Chang [1] http://dashboard.linaro.org/dashboard/streams/ [2] https://android-build.linaro.org/

13 years, 4 months

← Newer
1
...
6
7
8
9
10
11
12
...
16
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev April 2011