I've had a go with running the QEMU release candidate. Short story is
that it boots to a prompt against the 11.05 alpha2 release so I'm
happy.
It was a messy road so I've written up my train of though here:
https://wiki.linaro.org/MichaelHope/Sandbox/QEMU
Note that if you follow the instructions on:
https://wiki.linaro.org/Releases/GettingInstallingTesting
and turn on a swap file then it halts during boot.
-- Michael
== String routines ==
* After some discussions about IT semantics managed to shave a
couple of instructions out of a couple of routines
* Got around to trying a suggestion that was made some months ago,
that LDM is faster than LDRD on A9's; and indeed
it does seem to be in some cases; those cases seem pretty hard to
define though - it's no slower than LDRD, so it seems
best to avoid LDRD.
* Digging around eglibc's build/configure system to see how to add
assembler routines to only get used on certain build
conditions (i.e. v7 & up)
== SPEC ==
* Compiled lbm -O2 and ran it on our local panda and on Michael's
ursa1 - it seems happy (with a drop of swap); so I'd say that
confirms the issues I previously had were local to something on canis.
That's a bit of a pain since it's the only machine with enough
RAM to run the rest of the suite.
== Other ==
* Tested a headless Alpha-2 install on our Beagle C4 - mostly worked
* Tested qemu-linaro release on the realview-pbx kernel/nfs setup I had
* A simple smoke test for pldw on qemu
* Tripped over ltrace not working while trying to profile git's use
of memcpy and memcmp; it does some _very_ odd things;
it's predominant size of memcpy seems to be 1 byte.
== GDB ==
* Prepared Linaro GDB 7.2-2011-02.0 release
* Committed two patches to implement LP #661253 (Improve
backtrace by using ARM exception tables) to mainline and
Linaro GDB 7.2
* Provided two follow-on fixes to the patch for LP #616000
(Handle -fstack-protector prologue code); both applied to
mainline and Linaro GDB 7.2
* Backported mainline fix for LP #685494
(gdb.xml/tdesc-regs.exp failure) to Linaro GDB 7.2
* Identified root cause of LP #711375 (gdb internal error
in inline_frame_this_id trying to debug a qemu target);
committed fix to mainline and Linaro GDB 7.2
* Worked on re-implementation of fix for LP #615978 (Failure
to software single-step into signal handler)
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
RAG:
Red:
Amber: DATE/QEMU conference still hasn't confirmed I have a place...
Green: qemu-linaro RC2 prerelease uploaded
Current Milestones:
| Planned | Estimate | Actual |
first qemu-linaro release | 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 | 2010-01-25 | 2010-01-25 | handed off |
* maintain-beagle-models:
+ RC1 packaging flushed out some bugs:
++ we include some binary blobs which we're better not distributing:
https://bugs.launchpad.net/qemu-linaro/+bug/709965
++ a couple of array overruns don't compile with our picky armel gcc:
https://bugs.launchpad.net/qemu-linaro/+bug/709711https://bugs.launchpad.net/qemu-linaro/+bug/711272
(both fixes sent and applied upstream)
++ we ought to include a fix for the "swp" in qemu-lock.h:
http://patchwork.ozlabs.org/patch/81205/
(patch sent upstream, no comment on it yet)
+ ...so I have rolled an RC2 tarball with these fixed
+ investigated why USB keyboard model doesn't work: it turns out
that the OMAP host USB model is basically just a stub
+ some warnings from qemu about bad width accesses are a symptom of
a nasty disagreement between gcc and the kernel about getting atomic
32 bit accesses:
http://www.spinics.net/lists/arm-kernel/msg113002.html
+ warnings from qemu about access to a nonexistent i2c register
appear to be a kernel bug in the i2c driver for OMAP36xx:
https://bugs.edge.launchpad.net/linux-linaro/+bug/645324
+ investigated a hang running images built with linaro-media-create's
--swap_file option. Still digging but I suspect the Linux driver
doesn't cope with an MMC card which can erase in zero time...
* merge-correctness-fixes
+ the usual upstream mailing list monitoring and code review
+ sent patch for PLI and hint space decoding fixes:
http://patchwork.ozlabs.org/patch/81711/
* misc
+ some non-Linaro time this week; may be more next week
+ some advance planning of what we might want to do with QEMU
in the future
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,
* I continued to setup the pandaboad but ran into #708883
- tested vaious various hwpacks and headless images
- used different power supplies and several SD cards
- built various test kernels from the linux-linaro-natty.git
* looked into the crash utility
* https://wiki.linaro.org/KenWerner/Sandbox/crash-utility#future%20areas
Regards
Ken
Trying to build qemu on a beagle board:
CC sparc64-linux-user/translate.o
cc1: out of memory allocating 26975704 bytes after a total of 70742016 bytes
# ls -lh target-sparc/translate.c
-rw-r--r-- 1 root root 191K Jan 31 12:05 target-sparc/translate.c
ie gcc wants (at least) 100M of RAM trying to compile a 190K sourcefile.
(and probably more overall since the board has 500MB RAM total and
it hit the out-of-memory condition).
This seems a bit excessive to me, but do we consider it enough of
a bug to be worth looking into?
(I believe this source file has caused compile failures on the buildds
too, which have rather more RAM/swap than my beagle.)
-- PMM
Hello,
Profiling Denbech:
* The profiling information on x86 indicate that some benchmarks might need
to run longer as helper functions such as t_run_test are reported to be
hot.
So I've increased the time each benchmark is executed and will continue to
experiment with that for the problematic benchmarks until I start to see
more reasonable results.
* Opened PR711819 after having an ICE running DENbench with trunk (natively
built on ARM machine).
- I've started to look at an old patch for SMS that was written in 2005 by
colleague; Mostafa Hagog; to place the register moves in free slots.
Currently, they are placed greedily before each def thats needs them.
Thanks,
Revital
