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
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
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
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
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
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
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
