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
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
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/
Hi,
As we come towards the end of the Linaro 11.05 cycle, Ubuntu is reaching
its release one month sooner. This provides unique challenges for our
Ubuntu-based images; Ubuntu LEB, developer, nano and ALIP. In order to
help alleviate any confusion surrounding freeze dates and archive uploads
the follow rules and dates apply:
2011-04-14 : The Ubuntu main archive and seeded packages are frozen.
Only important bug fixes will be allowed to packages that
are included in the Ubuntu images. Packages that are in
main, universe, multiverse, and overlays that are not part
of an Ubuntu image can continue to be uploaded.
2011-04-21 : Only Ubuntu release blocking bugs will be fixed from this
period onwards. Changes to non-seeded packages can
continue to be made as before.
2011-04-26 : Changes to unseeded universe and multiverse packages are
frozen. Changes to overlays can continue.
2011-04-28 : Ubuntu final release (Natty).
2011-04-29 : Changes to Natty archive packages can be made using the
natty-updates archive. Fixes first go into natty-proposed
and when tested and verified are uploaded to
natty-updates to be included in Linaro images. Both
natty-proposed and natty-updates are enabled on the
Linaro images for testing.
2011-05-19 : Linaro Release Candidate images are selected. All updates
to packages need to be tested and in the natty-updates
archive by this date. natty-proposed is disabled from the
images.
2011-05-21 : Linaro Release Candidate made. Only critical bug fixes
will be made from this period onwards using either the
natty-updates mechanism or overlays if no over solution
is available.
2011-05-28 : Linaro 11.05 final images released
This information is available on the Linaro wiki at:
http://wiki.linaro.org/Cycles/1105/Schedule
If you have further question please do not hesitate to get in contact.
Regards,
Jamie.
--
Linaro Release Manager | Platform Project Manager
Hi,
In the context of systemtap testsuite, I had some compilation issues
"invalid lvalue output in asm 1". I have root-caused that to code in
the tool that is a (old) duplicate of arch/arm/include/asm/uaccess.h
macro __put_user_asm_dword(x, __pu_addr, err) => 64bits storage.
__pu_addr is storage address
The xxx_byte/half/word versions are OK. The main difference is that
__pu_addr is only read while read and write in dword version (inline
assembly "+r" modifier)
#define __stp_put_user_asm_dword(x,__pu_addr,err) \
__asm__ __volatile__( \
"1: str " __reg_oper1 ", [%1], #4\n" \ ->
__pu_addr is read but also written for next operation
"2: str " __reg_oper0 ", [%1], #0\n" \
...
: "+r" (err), "+r" (__pu_addr) \ ->
"r" (__pu_addr) for other versions
: "r" (x), "i" (-EFAULT) \
: "cc")
As my knowledge of inline assembly is poor, I am checking if this
reminds anything to anyone (compilation option, out of date syntax,
...) before investigating deeper.
I have put most recent code version from kernel in the tool but still
it fails. However, looking again at kernel code while writing this
mail, macro may be used only if CONFIG_MMU is not defined. I will
cross-check tomorrow.
Regards
Fred
Hi Nicolas,
I could not find this changes in the latest 2.6.38 Linaro kernel. Please
merge the patch from the below
mentioned samsung maintainers next link as this is required for the PM
Linaro release.
Thanks,
Amit Daniel
On 5 April 2011 01:36, Amit Kachhap <amit.kachhap(a)linaro.org> wrote:
> Hi Nicolas,
>
> Please take this cpuidle commit from the samsung tree needed for Linaro new
> rebuilt tree.
>
>
> http://git.kernel.org/?p=linux/kernel/git/kgene/linux-samsung.git;a=commit;…
>
>
> Thanks,
> Amit Daniel
>
>
>
>