== String routines ==
* Copied an improvement I'd previously made to memchr (removing a
branch using a big IT block) to strlen
* Modified benchmark setup to build everything as a library to
fairly give everything a PLT overhead.
* Pushed optimised memchr and strlen and simple strchr into
cortex-strings bzr repo
* Patched eglibc to use memchr and strchr code - although currently
fighting to get appropriate .changes file
== ffi ==
* Kicked off TSC request for license permissions
== bugs ==
* Built and recreated the qt4-x11 bug, produced all the dumps and
boiled it down to a few lines of suspicious RTL for Richard.
** Away next week.
== GCC ==
* Finished testing fix for lp:709329 and got that merged.
* Wrote up a plan for GCC performance improvements based on what we
discussed at the sprint.
* Internal ARM tasks that kept me busy for most of last week and this week.
Plans:
* still stuck on some ARM internal tasks for next week.
== This week ==
* Got the STT_GNU_IFUNC work ready to submit. Split out some preparatory
patches, including fixes for some general ARM inefficiencies that I
noticed this week. Ran the EGLIBC testsuite (including ifunc tests)
and they passed.
* Discussed ideas for representing permuted vector loads with Ira.
I'm still um-ing and ah-ing about the various possible approaches,
but I think I understand the constraints a bit more now.
* Fixed Qt miscompilation (lp #705689).
* Fixed PC-relative load bug in the assembler (lp #716967).
== Next week ==
Holiday!
Richard
RAG:
Red:
Amber: DATE/QEMU conference still hasn't confirmed I have a place...
Green: qemu-linaro first release made!
Current Milestones:
| Planned | Estimate | Actual |
first qemu-linaro release | 2011-02-08 | 2011-02-08 | 2011-02-08 |
Historical Milestones:
finish virtio-system | 2010-08-27 | postponed | |
finish testing PCI patches | 2010-10-01 | 2010-10-22 | 2010-10-18 |
successful ARM qemu pull req | 2010-12-16 | 2010-12-16 | 2010-12-16 |
finish qemu-cont-integration | 2011-01-25 | 2011-01-25 | handed off |
* maintain-beagle-models:
+ first qemu-linaro release (2011.02-0) made on time
+ fixed OMAP3 MMC controller model bug that was causing the kernel
to hang when enabling a swapfile; pushed fix to qemu and meego trees
+ rebased qemu-linaro on new upstream
* merge-correctness-fixes
+ reviewed some softfloat patches from Christophe; testing of
the half-precision floating point conversion instructions
showed up a number of other bugs which I submitted patches for:
http://patchwork.ozlabs.org/patch/82594/ (n/6)
+ reviewed and tested Christophe's patches for VQMOVUN and
VSLI.64/VSRI.64; these have been committed upstream
+ fix compile failure if !CONFIG_USE_GUEST_BASE
http://patchwork.ozlabs.org/patch/82630/
+ remove stray #include halfway through source file
http://patchwork.ozlabs.org/patch/82661/
+ improved vmull.p8 implementation over the meego version, sent
upstream: http://patchwork.ozlabs.org/patch/82657/
+ upstreamed patch to fix VQDMLSL:
http://patchwork.ozlabs.org/patch/82752/
+ upstreamed patch fixing thumb-to-arm neon dp insn conversion:
http://patchwork.ozlabs.org/patch/82757/
+ upstreamed patches fixing Neon VZIP and VUZP
* other
+ did a quick estimate of required effort to do vexpress model
(answer: 2 weeks if we don't want audio/USB/compact flash)
+ usual crop of standing meetings
Current qemu patch status is tracked here:
https://wiki.linaro.org/PeterMaydell/QemuPatchStatus
Absences:
17/18 March: QEMU Users Forum, Grenoble
Holiday: 22 Apr - 2 May
9-13 May: UDS, Budapest
(maybe) ~17-19 August: QEMU/KVM strand at LinuxCon NA, Vancouver
Hi,
* moved from Ubuntu Maverick to Natty on the PandaBoard
* investigation on the LTTng User Space Tracer:
https://wiki.linaro.org/KenWerner/Sandbox/LTTng
* started to look into latrace:
https://wiki.linaro.org/KenWerner/Sandbox/latrace
The idea is neat but there are issues in case the users code does dlclose
on a shared object. I'll investigate further when time permits.
* spent some time on IBM internal process work
Regards
Ken
Hi Will,
> > - It seems odd that the kernel says it doesn't support the debug
> > architecture, but then reports to user space that 1 watchpoint and 6
> > breakpoints are supported ... GDB will never use the watchpoint,
because
> > the maximum watchpoint size is reported as zero, but GDB will attempt
to
> > use the breakpoints. Setting a breakpoint will appear to succeed, but
then
> > the breakpoint just never triggers. The kernel should IMO be more
> > consistent in how unsupported configurations are handled ...
>
> Agreed. This is an artifact of how the ptrace info register is populated.
> I'll work on a fix tomorrow so that we don't report any resources when
> the architecture is unsupported.
Great, thanks!
> > - Why is architecture 0x4 not supported? This seems to be the variant
of
> > the v7 debug architecture with memory-mapped registers. Apparently the
> > IGEP only supports this version ... Do you know what the
> > Beagle-/Pandaboard and other clones do? What would it take to support
this
> > architecture variant? Given the widespread use of those boards, it
would
> > be really nice if we could support hardware debugging on them ...
>
> The memory-mapped interface is hugely unreliable in real hardware because
> you have to calculate the address of the memory-mapped debug registers by
> using a base and offset, which are hardcoded in some information
registers.
> Unfortunately, I've never found a board where these registers have been
> programmed correctly so (a) I had nothing to test my code with (b) few
people
> would be able to use it and (c) there's not really a safe way to go
around
> poking random areas of memory.
Huh, I see. I have no idea whether those information registers contain
correct values on IGEP ..
> > - Which hardware *is* supported? Can you recommend a board I should be
> > using to verify GDB support is working?
>
> The simple rule is Cortex-A8 is unsupported and Cortex-A9 is supported.
> The A5 should work (untested) and the A15 will need a bit of hacking to
> get it supported.
OK. I guess I can try on our Versatile Express.
> > Thanks for your help in getting this working!
>
> No problem. If you find anybody with working memory-mapped debug and some
> spare time, I'd be happy to review patches :)
Thanks! I'll try and see if I can figure out where the MM area is
on the IGEP ...
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
Hello,
* Analyzing DENBench benchmarks.
* Running mp3 player on Crotex A9 with gcc-linaro -r99463 using SMS flags
(*) gives 21% improvement in execution time compared to using only base
flags(**).
(*) -fmodulo-sched -fmodulo-sched-allow-regmoves
(**) -mcpu=cortex-a9 -mtune=cortex-a9 -mthumb -static --fast-math
Thanks,
Revital
Hi,
* regtested vzip/vuzp patch
* looked into big-endian build
* applied all the required patches and checked that Viterbi gets
vectorized giving ~2x performance improvement (compiled with
cross-compiler)
* looked into vld/vst implementation - mostly discussions with Richard
* DenBench analysis:
- there are loops that should get vectorized with vzip/vuzp patch,
I'll check them next week
- sad8_c (hot function from mp4encode) needs reduction SLP (which I
implemented several weeks ago), and an ability to jump unknown stride
in loop SLP - I am looking into this
Ira
On Wednesday 09 February 2011 20:25:32 Will Deacon wrote:
> > - Why is architecture 0x4 not supported? This seems to be the variant of
> > the v7 debug architecture with memory-mapped registers. Apparently the
> > IGEP only supports this version ... Do you know what the
> > Beagle-/Pandaboard and other clones do? What would it take to support this
> > architecture variant? Given the widespread use of those boards, it would
> > be really nice if we could support hardware debugging on them ...
>
> The memory-mapped interface is hugely unreliable in real hardware because
> you have to calculate the address of the memory-mapped debug registers by
> using a base and offset, which are hardcoded in some information registers.
> Unfortunately, I've never found a board where these registers have been
> programmed correctly so (a) I had nothing to test my code with (b) few people
> would be able to use it and (c) there's not really a safe way to go around
> poking random areas of memory.
So the only problem is that it's board specific? That's something we
know how to deal with -- all I/O components have some random board
specific address, and we put them in a platform device that is
listed in the board file. This should be easy enough to do for another
register area, though it means we have to do it separately for each board.
> > - Which hardware is supported? Can you recommend a board I should be
> > using to verify GDB support is working?
>
> The simple rule is Cortex-A8 is unsupported and Cortex-A9 is supported.
> The A5 should work (untested) and the A15 will need a bit of hacking to
> get it supported.
Is that because A8 is memory mapped and A9 uses CP14, or is there another
problem with A8?
Arnd
Hello Will,
I've been trying to get GDB support for hardware watchpoints/breakpoints
going. I've ported Matthew's GDB patch to current mainline, and am running
this under a 2.6.37-1002-linaro-omap kernel on an IGEPv2 board.
However, something seems to be not quite working: I'm seeing this kernel
message on boot:
hw-breakpoint: debug architecture 0x4 unsupported.
and then at runtime, the result of a PTRACE_GETHBPREGS call for register 0
is 0x04000106:
debug architecture: 4
watchpoint size: 0
nr. watchpoints: 1
nr. breakpoints: 6
This leads me to a couple of questions:
- It seems odd that the kernel says it doesn't support the debug
architecture, but then reports to user space that 1 watchpoint and 6
breakpoints are supported ... GDB will never use the watchpoint, because
the maximum watchpoint size is reported as zero, but GDB will attempt to
use the breakpoints. Setting a breakpoint will appear to succeed, but then
the breakpoint just never triggers. The kernel should IMO be more
consistent in how unsupported configurations are handled ...
- Why is architecture 0x4 not supported? This seems to be the variant of
the v7 debug architecture with memory-mapped registers. Apparently the
IGEP only supports this version ... Do you know what the
Beagle-/Pandaboard and other clones do? What would it take to support this
architecture variant? Given the widespread use of those boards, it would
be really nice if we could support hardware debugging on them ...
- Which hardware *is* supported? Can you recommend a board I should be
using to verify GDB support is working?
Thanks for your help in getting this working!
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
