hello Group,
I am trying to boot the Linaro-Ubuntu-13.04 release on Panda, But the
_HDMI_ display is not coming.
- I see the x-server is not started (X doesn't exit, is the window
manager changed?). I installed it and started X. But it says error
message as "no screen found"
- In Xorg.logs i see message, failed to load omap display module.
Any pointers how to get the display? got a dependency on it.
thanks,
sanjay
Hi all,
Apologies if this is the wrong list, and for the somewhat vague
description of my problem.
I've been working on porting Go (via gccgo) to aarch64 and things have
mostly been going well. However, under some circumstances, I'm seeing
crashes. What's happening is that when a signal -- SIGCHLD in this case
-- is being handled, instead of being executed on the stack passed to
sigaltstack, the signal is being handled on some *other* thread's stack,
which unsurprisingly ends badly when a signal context object is smashed
over whatever the original thread had put there.
By setting breakpoints on the signal handler in gdb and printing $sp, I
can actually see that signals are never being executed on the altstack,
but it takes a random number of signals before one is executed somewhere
that causes a crash. So I don't know if signals are always being
handled on other thread's stacks or if it's just at random-ish locations
in the heap. (Goroutines run with stacks allocated in the heap).
Writing a very simple program that calls sigaltstack does behave as
expected, but the go runtime is doing all sorts of things with multiple
threads and getcontext/makecontext/setcontext so I guess something is
getting confused.
There are some more details on this bug:
https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1279620 but I
don't have anything like a minimal example unfortunately. I'll try to
come up with one tomorrow, but in the mean time: does this ring any
bells at all with anyone? I couldn't see any obvious reasons for this
behaviour in the kernel code :/
Cheers,
mwh
Someone asked if this worked, and I thought 'that's trivial to test with
multiarch' so I did.
On Saucy (where there is no multiarch version skew issue between binary versions of packages) the
dpkg --add-architecutre armhf
apt-get update
apt-get install links:armhf
part works very nicely. Everything installs as required.
However binaries don't run - they just get killed.
Apparently no-one has tried this for a couple of years since it was
last working...(Or is it working on other platforms? - apparently it's OK
on android)
Turns out that our arm64 kernel config has:
vm.mmap_min_addr=65536
but armhf binaries tend to get mmapped at 0x8000 (32K).
On armhf that value is set to
vm.mmap_min_addr=4096
This difference is to protect page0 even if large pages are enabled
which seems sensible enough, but has this unfortunate side-effect.
So either we need to stop doing that (What would be the consequences of
setting 4096 by default on arm64?) or change something in the loader to
stop mapping things below 64K, which I think involves glibc hackery.
Running 32-bit binaries is quite seriously broken until this is fixed. I
presume this currently isn't on anyone's list to fix? I'm not sure who's
list it should go on.
part2: Once this is fixed with:
sudo sysctl -w vm.mmap_min_addr=4096
some binaries work (hello, bzip2) but fancier things still don't (links,
wget). They segfault after loading libs. I'm still investigating that,
but it looks like we have at least two issues..
So this mail is really to ask what the best fix is and thus who will
deal with it? Do I need to file a bug or a card somewhere?
Possibly more to follow when I work out what else is wrong...
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
Greetings folks
im currently a arm user and have a armv7l build im expanding this to arm8
and am bootstraping a build currently patching as i go the linaro
repositories are a
great resource [thanks for the fish], once i proceed further ill feedback.
i abandoned the "foundation" and have now loaded qemu from git and using
the linux-user bits for a "hybrid" chroot build.
besides it been a bit slow all builds are done in the method i explain
bellow and
wanted to have it all in one.
once you have a base cross toolchain [binutils/gcc/glibc] place them all in
sysroot allong with libs/bins from host [in my case x86_64] for common tasks
getttext/make/bash/..... configure binfmt_misc mount the sysroot onto
/usr/gnemul. this allows execution of programs while "building" and allows
chrooting into the sysroot and running the build cross [x86_64] for the
host [aarch64] native will be [aarch64].
problem children like perl and python build out the box now [chroot].
There some qemu errors trying to chroot build with "waf" [samba/python]
when chrooting but it does build "cross".
expect some updates and leaching off the repositories.
any one interested in further info or has comments please shout.
Greg
Hi, experts:
I plan to develop a boot loader for an ARMv8 SOC.
So, I have a few questions about booting an ARMv8 kernel image.
1. the linux kernel image's execution state when jumping to the
entrypoint of zImage.
Take Cortex-A57 as an example:
It has 2 execution state : Aarch32 / Aarch64
For example:
(1) boot loader is running at Non-Secure EL2 Aarch64 state
Does the linux kernel zImage also need run at Non-Secure EL2 Aarch64
state?
Is the kernel zImage possible to run at Non-Secure EL2 Aarch32 state?
Best wishes,
Hi Zoran,
Colin King sent me some patches to fixup memory leaks and some nits in
the error code path.
Please, pull these changes in your tree.
The following changes since commit da6a8c94a8f8124711db0ae84a3ef4e0e186b388:
Fixing improperly initialized cstate_max per-CPU. (2014-01-29
15:47:47 -0800)
are available in the git repository at:
git://git.linaro.org/people/daniel.lezcano/idlestat.git master
for you to fetch changes up to 41505eca08f1bd0f2d35733cd631be5967e38724:
Use the correct format specifier for size_t type (2014-02-18 08:51:30
+0100)
----------------------------------------------------------------
Colin Ian King (6):
Write open failure message to stderr
Free memory on realloc failure.
Fix memory leak, result is being leaked on a realloc failure
check s_cpu rather than s_core on memory allocation
Fix file and memory resource leak on error exit in idlestat_load
Use the correct format specifier for size_t type
idlestat.c | 36 ++++++++++++++++++++++++++----------
topology.c | 2 +-
2 files changed, 27 insertions(+), 11 deletions(-)
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
Hi all,
I want to remind everyone that if you wish to communicate anything to do with the Lab in Cambridge, then you should always use the “lava-lab(a)linaro.xn--org-9o0a alias. The people on that list include the three of us in the LAVA team in Cambridge, as well as Alan and Tyler, so we cover a pretty wide time zone.
Additionally, just because you get a reply off one of us, please don’t cut the mailing list out of the loop. If one of us is unavailable, someone else can pick up the thread.
Many thanks
Dave