Re: [lava] Android image support

2011-04-14 Thread Jeremy Chang 
On Thu, Apr 14, 2011 at 1:19 PM, Paul Larson  wrote:
>
>
> On Wed, Apr 13, 2011 at 11:25 PM, Alexander Sack  wrote:
>> On Wed, Apr 13, 2011 at 12:52 PM, Jeremy Chang 
>> wrote:
>>> 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!
>>
>> Paul is travelling  I assume he will be able to review this on friday.
> Yes, trying to catch up with email, I'll take a look at it as soon as I can.
>  And thanks for working on this!  I'm looking forward to seeing what you've
> got!
>

Hi, Paul:
Thanks in advance! and appreciate your comments.

>>
>>> .
>>>    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
> On the partitioning... is all of that really necessary?  Is there any way to
> get this down?  To support this, we'll need to modify MMC_BLOCK_MINORS for
> the 10.11 kernels that we have for the master images on most of the boards,
> as well as on any laptop used to create these images.  Would be nice if
> there were some easy way around this.

The rootfs partition will be removed and replaced by the initial
ramdisk image soon, but it seems the sdcard partition still can not be
viewed by the master image. Thinking more about this.

>
>>  17 -MASTER_STR = "root@master:"
>>  18 +MASTER_STR = "root@linaro:"
>>  19  #Test image recognization string
>>  20  TESTER_STR = "root@linaro:"
>
> This is ill-advised, as you now can't tell which image you're booted into.
> Better to just set the hostname on you master image to "master".
>

   Right, just need to changing the host name. I updated the wiki page. Thanks!

>>>
>>>    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.
> Why is there an android version of test_abrek here?  It doesn't seem to
> belong, but filling in run_adb_shell_command looks like it would be useful.

Yes, in the end, I think the android_abrek command is not needed
for android. I think I will remove it later.
The test result conversion can be done just in test actions in lava.

Regarding to using adb shell to trigger the commands, another
thing I am inspecting is how to monitor the status of long time
running applications(either native or android java) like monkey and
0xbench from the host side, lava.

>
>> For now - to get past this point - you could just implement an
>> action/command that is "monkey_results_to_json".
> Zygmunt did some looking at conversion scripts for gcc tests a while back.
> You should talk to him as I think he has some good feelings about good and
> bad approaches to this problem since he's been through some of the pain with
> it already.  But yes, abrek will convert it, but some other conversion piece
> will be needed since we don't use abrek here.

Thanks. I will need to check the conversion scripts.

>
>> my understanding is that "attachment" should be used to "attach
>> additional information" ... the main results should be in the "main"
>> json part. basically "result" (boolean) and/or "measurement" (float)
>> from what i recall.
> Attachments can be used when you need to preserve the whole result as it
> was, logfiles, even binaries.  However, launch control can't easily tell you
> much about them... just dump them out for you.  For instance, we plan to
> store the serial log in an attachment.  It's not something we need the
> dashboard to query on, but it would be useful to have if we get a failure,
> and want to investigate further.  Parsing the test results, and storing them
> in measurements and results makes them easier to query for, so that graphs
> and reports can later be generated.

I still have no much feeling about generating the graphs and
reports from the json bundle. I just setup a launch-control/0.4 and
start to play with it.


>
>>>    Regarding to generating the bundle, I will check what's the way to
>>> generate the reasonable software_context and hardware_context for
>>> android.
> I wouldn't worry about this too much right now, it's not a critical thing to
> do.

Yes, I will try to do with a most basic forma

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

2011-04-14 Thread Angus Ainslie 
On Tue, Apr 12, 2011 at 10:38 PM, Tushar Behera
 wrote:
> 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 
> ---
>  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
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

If you use the UUID of the filesystem it doesn't matter which device
node it gets registered as.

Angus

-- 
Angus Ainslie 
Team Lead, Samsung Landing Team

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

Re: Likely empty space in a processes's virtual address space

2011-04-14 Thread Dave Martin 
On Wed, Apr 13, 2011 at 11:11 PM, Michael Hope  wrote:
> 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 0x6000 which from a bit of poking seems to be fine on ARM
> as well.

This does sound rather an alarming design ... would it be hard to make
the PCH blobs relocatable or position-independent?

How does GCC cope with multiple precompiled headers?  Making them
relocatable or position-independent might allow many to be mapped
simultaneously, which might actually be a performance win (based on
zero knowledge of the nature of this data or what GCC does with it...)

Cheers
---Dave

>
> Can someone point me at the typical virtual address space for a ARM
> Linux process?  How does 0x6000 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:/gcc/config/host-linux.c#L67
>
> /proc/self/maps on a simple program gives:
>
> 8000-9000 r-xp  00:14 28747240   /home/michaelh/a.out
> 0001-00011000 r--p  00:14 28747240   /home/michaelh/a.out
> 00011000-00012000 rw-p 1000 00:14 28747240   /home/michaelh/a.out
> 00012000-00033000 rw-p  00:00 0          [heap]
> 2ab4c000-2ab4d000 rw-p  00:00 0
> 2ab5c000-2ab5e000 rw-p  00:00 0
> 2ab89000-2aba r-xp  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  00:00 0
> 2ac93000-2aca r-xp  00:0d 26352795   /lib/libbz2.so.1.0.4
> 2aca-2aca7000 ---p d000 00:0d 26352795   /lib/libbz2.so.1.0.4
> 2aca7000-2aca8000 r--p c000 00:0d 26352795   /lib/libbz2.so.1.0.4
> 2aca8000-2aca9000 rw-p d000 00:0d 26352795   /lib/libbz2.so.1.0.4
> 2aca9000-2ad96000 r-xp  00:0d 26352832   /lib/libc-2.12.1.so
> 2ad96000-2ad9e000 ---p 000ed000 00:0d 26352832   /lib/libc-2.12.1.so
> 2ad9e000-2ada r--p 000ed000 00:0d 26352832   /lib/libc-2.12.1.so
> 2ada-2ada1000 rw-p 000ef000 00:0d 26352832   /lib/libc-2.12.1.so
> 2ada1000-2ada4000 rw-p  00:00 0
> 7ed9c000-7edbd000 rw-p  00:00 0          [stack]
>
> 0x6000 is well above the shared libraries and well below the stack.
>
> -- Michael
>
> ___
> 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

[PATCH] S5PC2XX: GPIO Macro Values Corrected.

2011-04-14 Thread Chander Kashyap 
Macro values for Pull Up and Driver Strength were wrong.

Signed-off-by: Chander Kashyap 
---
 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_1X0x0
-#define GPIO_DRV_2X0x1
-#define GPIO_DRV_3X0x2
+#define GPIO_DRV_2X0x2
+#define GPIO_DRV_3X0x1
 #define GPIO_DRV_4X0x3
 #define GPIO_DRV_FAST  0x0
 #define GPIO_DRV_SLOW  0x1
-- 
1.7.1


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

[PATCH 2/2] S5PC1XX: Refers to SROM config code in s5p-common directory. Header file renamed from smc.h to sromc.h.

2011-04-14 Thread Chander Kashyap 
Signed-off-by: Chander Kashyap 
---
 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 +-
 5 files changed, 55 insertions(+), 105 deletions(-)
 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

diff --git a/arch/arm/cpu/armv7/s5pc1xx/Makefile 
b/arch/arm/cpu/armv7/s5pc1xx/Makefile
index b182bf5..d66314e 100644
--- a/arch/arm/cpu/armv7/s5pc1xx/Makefile
+++ b/arch/arm/cpu/armv7/s5pc1xx/Makefile
@@ -32,7 +32,6 @@ SOBJS = cache.o
 SOBJS  += reset.o

 COBJS  += clock.o
-COBJS  += sromc.o

 SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
 OBJS   := $(addprefix $(obj),$(COBJS) $(SOBJS))
diff --git a/arch/arm/cpu/armv7/s5pc1xx/sromc.c 
b/arch/arm/cpu/armv7/s5pc1xx/sromc.c
deleted file mode 100644
index 044d122..000
--- a/arch/arm/cpu/armv7/s5pc1xx/sromc.c
+++ /dev/null
@@ -1,49 +0,0 @@
-/*
- * Copyright (C) 2010 Samsung Electronics
- * Naveen Krishna Ch 
- *
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- */
-
-#include 
-#include 
-#include 
-
-/*
- * s5pc1xx_config_sromc() - select the proper SROMC Bank and configure the
- * band width control and bank control registers
- * srom_bank   - SROM Bank 0 to 5
- * smc_bw_conf  - SMC Band witdh reg configuration value
- * smc_bc_conf  - SMC Bank Control reg configuration value
- */
-void s5pc1xx_config_sromc(u32 srom_bank, u32 smc_bw_conf, u32 smc_bc_conf)
-{
-   u32 tmp;
-   struct s5pc1xx_smc *srom =
-   (struct s5pc1xx_smc *)samsung_get_base_sromc();
-
-   /* Configure SMC_BW register to handle proper SROMC bank */
-   tmp = srom->bw;
-   tmp &= ~(0xF << (srom_bank * 4));
-   tmp |= smc_bw_conf;
-   srom->bw = tmp;
-
-   /* Configure SMC_BC register */
-   srom->bc[srom_bank] = smc_bc_conf;
-}
diff --git a/arch/arm/include/asm/arch-s5pc1xx/smc.h 
b/arch/arm/include/asm/arch-s5pc1xx/smc.h
deleted file mode 100644
index 88f4ffe..000
--- a/arch/arm/include/asm/arch-s5pc1xx/smc.h
+++ /dev/null
@@ -1,53 +0,0 @@
-/*
- * (C) Copyright 2010 Samsung Electronics
- * Naveen Krishna Ch 
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- *
- * Note: This file contains the register description for Memory subsystem
- *  (SROM, NAND Flash, OneNand, DDR, OneDRAM) on S5PC1XX.
- *
- *  Only SROMC is defined as of now
- */
-
-#ifndef __ASM_ARCH_SMC_H_
-#define __ASM_ARCH_SMC_H_
-
-#define SMC_DATA16_WIDTH(x)(1<<((x*4)+0))
-#define SMC_BYTE_ADDR_MODE(x)  (1<<((x*4)+1))  /* 0-> Half-word base address*/
-   /* 1-> Byte base address*/
-#define SMC_WAIT_ENABLE(x) (1<<((x*4)+2))
-#define SMC_BYTE_ENABLE(x) (1<<((x*4)+3))
-
-#define SMC_BC_TACS(x) (x << 28) /* 0clk address set-up */
-#define SMC_BC_TCOS(x) (x << 24) /* 4clk chip selection set-up */
-#define SMC_BC_TACC(x) (x << 16) /* 14clkaccess cycle */
-#define SMC_BC_TCOH(x) (x << 12) /* 1clk chip selection hold */
-#define SMC_BC_TAH(x)  (x << 8)  /* 4clk address holding time */
-#define SMC_BC_TACP(x) (x << 4)  /* 6clk page mode access cycle */
-#define SMC_BC_PMC(x)  (x << 0)  /* normal(1data)page mode configuration */
-
-#ifndef __ASSEMBLY__
-struct s5pc1xx_smc

[PATCH 1/2] S5P: SROM config code moved to common directory s5p-common

2011-04-14 Thread Chander Kashyap 
SROM configuration is same for various S5P series Boards.

Signed-off-by: Chander Kashyap 
---
 arch/arm/cpu/armv7/s5p-common/Makefile |3 +-
 arch/arm/cpu/armv7/s5p-common/sromc.c  |   49 
 2 files changed, 51 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/s5p-common/sromc.c

diff --git a/arch/arm/cpu/armv7/s5p-common/Makefile 
b/arch/arm/cpu/armv7/s5p-common/Makefile
index ce0a41e..1705399 100644
--- a/arch/arm/cpu/armv7/s5p-common/Makefile
+++ b/arch/arm/cpu/armv7/s5p-common/Makefile
@@ -27,7 +27,8 @@ LIB   = $(obj)libs5p-common.o

 COBJS-y+= cpu_info.o
 COBJS-y+= timer.o
-COBJS-$(CONFIG_PWM)+= pwm.o
+COBJS-y+= sromc.o
+COBJS-$(CONFIG_PWM)+= pwm.o

 SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
 OBJS   := $(addprefix $(obj),$(COBJS-y) $(SOBJS))
diff --git a/arch/arm/cpu/armv7/s5p-common/sromc.c 
b/arch/arm/cpu/armv7/s5p-common/sromc.c
new file mode 100644
index 000..091e8d1
--- /dev/null
+++ b/arch/arm/cpu/armv7/s5p-common/sromc.c
@@ -0,0 +1,49 @@
+/*
+ * Copyright (C) 2010 Samsung Electronics
+ * Naveen Krishna Ch 
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include 
+#include 
+#include 
+
+/*
+ * s5p_config_sromc() - select the proper SROMC Bank and configure the
+ * band width control and bank control registers
+ * srom_bank   - SROM
+ * srom_bw_conf  - SMC Band witdh reg configuration value
+ * srom_bc_conf  - SMC Bank Control reg configuration value
+ */
+void s5p_config_sromc(u32 srom_bank, u32 srom_bw_conf, u32 srom_bc_conf)
+{
+   u32 tmp;
+   struct s5p_sromc *srom =
+   (struct s5p_sromc *)samsung_get_base_sromc();
+
+   /* Configure SMC_BW register to handle proper SROMC bank */
+   tmp = srom->bw;
+   tmp &= ~(0xF << (srom_bank * 4));
+   tmp |= srom_bw_conf;
+   srom->bw = tmp;
+
+   /* Configure SMC_BC register */
+   srom->bc[srom_bank] = srom_bc_conf;
+}
--
1.7.1


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

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

2011-04-14 Thread 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


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

Re: Likely empty space in a processes's virtual address space

2011-04-14 Thread Richard Sandiford 
Dave Martin  writes:
> On Wed, Apr 13, 2011 at 11:11 PM, Michael Hope  
> wrote:
>> 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 0x6000 which from a bit of poking seems to be fine on ARM
>> as well.
>
> This does sound rather an alarming design ... would it be hard to make
> the PCH blobs relocatable or position-independent?
>
> How does GCC cope with multiple precompiled headers?  Making them
> relocatable or position-independent might allow many to be mapped
> simultaneously, which might actually be a performance win (based on
> zero knowledge of the nature of this data or what GCC does with it...)

The current PCH implementation is years old, and is really a hack
that sits on top of the garbage collector.  It basically dumps all
of GCC's internal state out at a particular point, then reads it
back in when the "precompiled header" is used.  It's therefore 
only possible to have one precompiled header per compilation.

The model is that the package using PCH should have a common set of
includes that every translation unit uses (or is at least prepared to
accept).  This common set can be put in the PCH, which must be included
before anything else.

Like I said, a hack :-)

There is an ongoing project to use a streamed form of PCH.  It's much
more work than the current implementation was, but it should avoid
the main drawbacks.

Richard

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

Linaro 11.05 weekly image testing 2011-04-14

2011-04-14 Thread 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

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

Re: Likely empty space in a processes's virtual address space

2011-04-14 Thread Dave Martin 
On Thu, Apr 14, 2011 at 12:09 PM, Richard Sandiford
 wrote:
> Dave Martin  writes:
>> On Wed, Apr 13, 2011 at 11:11 PM, Michael Hope  
>> wrote:
>>> 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 0x6000 which from a bit of poking seems to be fine on ARM
>>> as well.
>>
>> This does sound rather an alarming design ... would it be hard to make
>> the PCH blobs relocatable or position-independent?
>>
>> How does GCC cope with multiple precompiled headers?  Making them
>> relocatable or position-independent might allow many to be mapped
>> simultaneously, which might actually be a performance win (based on
>> zero knowledge of the nature of this data or what GCC does with it...)
>
> The current PCH implementation is years old, and is really a hack
> that sits on top of the garbage collector.  It basically dumps all
> of GCC's internal state out at a particular point, then reads it
> back in when the "precompiled header" is used.  It's therefore
> only possible to have one precompiled header per compilation.
>
> The model is that the package using PCH should have a common set of
> includes that every translation unit uses (or is at least prepared to
> accept).  This common set can be put in the PCH, which must be included
> before anything else.
>
> Like I said, a hack :-)

eeaarrgh

>
> There is an ongoing project to use a streamed form of PCH.  It's much
> more work than the current implementation was, but it should avoid
> the main drawbacks.

Oh well, I will await developments with interest... ;)

---Dave

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

Linaro 11.05 Beta-2

2011-04-14 Thread 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

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

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

2011-04-14 Thread 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

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

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

2011-04-14 Thread Chander Kashyap 
SROM config code is made common for S5P series of boards.
smdkc100.c now refers to s5p-common/sromc.c for SROM related
subroutines.

Signed-off-by: Chander Kashyap 
---
 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

diff --git a/arch/arm/cpu/armv7/s5p-common/Makefile 
b/arch/arm/cpu/armv7/s5p-common/Makefile
index ce0a41e..1705399 100644
--- a/arch/arm/cpu/armv7/s5p-common/Makefile
+++ b/arch/arm/cpu/armv7/s5p-common/Makefile
@@ -27,7 +27,8 @@ LIB   = $(obj)libs5p-common.o

 COBJS-y+= cpu_info.o
 COBJS-y+= timer.o
-COBJS-$(CONFIG_PWM)+= pwm.o
+COBJS-y+= sromc.o
+COBJS-$(CONFIG_PWM)+= pwm.o

 SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
 OBJS   := $(addprefix $(obj),$(COBJS-y) $(SOBJS))
diff --git a/arch/arm/cpu/armv7/s5p-common/sromc.c 
b/arch/arm/cpu/armv7/s5p-common/sromc.c
new file mode 100644
index 000..091e8d1
--- /dev/null
+++ b/arch/arm/cpu/armv7/s5p-common/sromc.c
@@ -0,0 +1,49 @@
+/*
+ * Copyright (C) 2010 Samsung Electronics
+ * Naveen Krishna Ch 
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include 
+#include 
+#include 
+
+/*
+ * s5p_config_sromc() - select the proper SROMC Bank and configure the
+ * band width control and bank control registers
+ * srom_bank   - SROM
+ * srom_bw_conf  - SMC Band witdh reg configuration value
+ * srom_bc_conf  - SMC Bank Control reg configuration value
+ */
+void s5p_config_sromc(u32 srom_bank, u32 srom_bw_conf, u32 srom_bc_conf)
+{
+   u32 tmp;
+   struct s5p_sromc *srom =
+   (struct s5p_sromc *)samsung_get_base_sromc();
+
+   /* Configure SMC_BW register to handle proper SROMC bank */
+   tmp = srom->bw;
+   tmp &= ~(0xF << (srom_bank * 4));
+   tmp |= srom_bw_conf;
+   srom->bw = tmp;
+
+   /* Configure SMC_BC register */
+   srom->bc[srom_bank] = srom_bc_conf;
+}
diff --git a/arch/arm/cpu/armv7/s5pc1xx/Makefile 
b/arch/arm/cpu/armv7/s5pc1xx/Makefile
index b182bf5..d66314e 100644
--- a/arch/arm/cpu/armv7/s5pc1xx/Makefile
+++ b/arch/arm/cpu/armv7/s5pc1xx/Makefile
@@ -32,7 +32,6 @@ SOBJS = cache.o
 SOBJS  += reset.o

 COBJS  += clock.o
-COBJS  += sromc.o

 SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
 OBJS   := $(addprefix $(obj),$(COBJS) $(SOBJS))
diff --git a/arch/arm/cpu/armv7/s5pc1xx/sromc.c 
b/arch/arm/cpu/armv7/s5pc1xx/sromc.c
deleted file mode 100644
index 044d122..000
--- a/arch/arm/cpu/armv7/s5pc1xx/sromc.c
+++ /dev/null
@@ -1,49 +0,0 @@
-/*
- * Copyright (C) 2010 Samsung Electronics
- * Naveen Krishna Ch 
- *
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- */
-
-#include 
-#include 
-#include 
-
-/*
- * s5pc1xx_config_sromc() - select the proper SROMC Bank and configure the
- * band width control and bank control r