request for testing: qemu-linaro git tree
Hi; I've just completed a tricky rebase of qemu-linaro on upstream; there were several invasive upstream changes which have landed recently and which meant that I had to tweak a lot of the qemu-linaro patches as I did the rebase. I've tested the results but it's possible that some breakage may have slipped through... So if you're a regular user of qemu-linaro's system mode and feel like checking the sources out of git: git://git.linaro.org/qemu/qemu-linaro.git building them and testing that the things you regularly do with it haven't regressed, then I'd appreciate it, and you can help us avoid any nasty surprises in the next (2011.09) release. Thanks! -- Peter Maydell ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] 22nd - 27th August
Booked hotel and travel for Linaro Connect in Orlando.
Fixed a couple of bugs in my thumb2 constants patch and retested. The
test results came back clean, so I've committed it upstream.
Bernd claimed he has found some test failures that might be caused by my
patch, but I couldn't reproduce them at first. I've now got the failure,
but I've not yet investigated the cause. Next week ...
Committed my widening multiplies patches to Linaro GCC, after first
convincing Richard Sandiford that it wasn't totally bonkers.
Started work on ARM GCC tuning options:
* Submitted a patch for -m{arch,cpu,tune}=native
http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg14225.html
* Submitted a patch for -m{arch,cpu,tune}=generic-armv7-a
http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg14231.html
Joseph found an issue with those patches, but that was easily resolved
and I've reposted both.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: GCC trunk fails to build
On 29/08/11 21:22, Michael Hope wrote: See: http://builds.linaro.org/toolchain/gcc-4.7~svn178154 The problem is -Werror triggering on: ../../../gcc-4.7~/gcc/config/arm/arm.c: In function 'int optimal_immediate_sequence_1(rtx_code, long long unsigned int, four_ints*, int)': ../../../gcc-4.7~/gcc/config/arm/arm.c:2690:46: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] Oh, that's my patch. :( I'll fix it. Andrew ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Trip report: KVM Forum/LinuxCon NA 2011
Trip report: KVM Forum/LinuxCon NA 2011
KVM Forum is an annual conference; this year it was colocated with
LinuxCon NA in Vancouver. There were about 150 attendees; many of them
are simply users of KVM and so many of the talks are aimed at KVM
users. However it's also an opportunity for the KVM and QEMU developer
community to get together, with a number of informal BoF sessions and
an all-day hackathon later in the week.
The talk schedule is here, together with the slides for all talks:
http://www.linux-kvm.org/page/KVM_Forum_2011
Some brief highlights:
* Keynotes
ARM/Linaro got positive mentions in both keynotes; Avi Kivity said of
the ARM/A15 KVM work that he had "every reason to expect it to be very
successful". Anthony Liguori's keynote summarising the year in QEMU
development included some statistics about commits: Linaro came third
in the list of "companies with most commits", behind only Red Hat and
IBM; I came top of the "individual authors with most commits" list,
being apparently responsible for 7% of all QEMU patches this year :-)
* KVM on POWER/PPC
There were several talks about KVM on PPC architectures; interestingly
this is seeing use not just on the server end but also in the
embedded/realtime space (including a talk from Freescale where they
said they are working on KVM on embedded PPC because of customer
demand for KVM). It was also reassuring to see that another
architecture has preceded us in shaking out x86-isms from KVM.
* KVM Tool
This has got headlines recently as a potential replacement for the
userspace launcher/device model role which QEMU currently plays when
starting guest OSes under KVM. It's intended to be minimal and
lightweight and only to run Linux guests (with paravirtualised devices
for most purposes). The general reaction seemed to be that although
the implementation is currently minimal it will become larger and
bloatier as they add features off their wishlist. There's also some
ill-feeling about the effective namespace grab of calling the
userspace binary "kvm". From an ARM-centric point of view we can just
wait and see whether it gets much traction. Possibly it may turn into
a testbed for technology which is easier to develop on than the
'mature' QEMU which has to deal with backwards compatibility and
supporting users.
* QEMU Object Model and Device Model issues and redesign
For me one of the most important strands of conversation at the
conference was replacing QEMU's device model abstraction with
something better. QEMU's current device model abstraction is "qdev";
this is the (vaguely object-oriented) framework which lets you create
devices, configure them and connect them together. It models the world
as a tree: a root device exposes a bus, to which child devices can
connect; those child devices may expose further buses, and so on.
This works quite well in the PC world where mostly you're interested
in plugging in USB devices, PCI cards, etc; it is rather less well
matched to the embedded board models where things are much less
hierarchical. qdev's major flaws include:
+ insists on bus hierarchy, but not everything is a bus, and in any
case there are often several trees (memory transactions, clock,
interrupts) which don't necessarily coincide
+ no support for composition ("device foo is actually devices bar
and baz glued into one box")
+ just barely supports having devices expose signal (gpio/irq) lines
and memory regions (typically registers), but doesn't let you give
them useful names, so you have to access them by index number
We spent just about all of Thursday's hacking session going through
this. I felt we got good agreement on the problems, and perhaps
80-90% agreement on Anthony Liguori's proposed new QEMU Object Model
as a solution to them; some loose ends still need to be worked
through.
* LinuxCon NA
KVM Forum was colocated with LinuxCon NA this year. My opinion (which
seemed to be shared with the other Linaro attendees I talked to about it)
was that LinuxCon NA suffered from being not very technical and not
very focused -- it wasn't clear to me who they thought their target
audience was. A few points of interest:
+ Linus Torvalds' keynote was reported in some places as more
complaints about ARM hardware but I actually thought it was pretty
positive about the progress we're making in sorting out the issues
+ Matthew Garrett's talk about x86 platform drivers (those things that
deal with LEDs, funny keys, batteries and other odd laptop hardware)
revealed that actually PC hardware manufacturers do just as much
random non-standard undocumented silliness, it's just that accident
of history has limited them to only doing so in the minor bits at
the edges...
-- PMM
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: request for testing: qemu-linaro git tree
On Tue, Aug 30, 2011 at 11:07:25AM +0100, Peter Maydell wrote: > Hi; I've just completed a tricky rebase of qemu-linaro on upstream; > there were several invasive upstream changes which have landed > recently and which meant that I had to tweak a lot of the qemu-linaro > patches as I did the rebase. I've tested the results but it's possible > that some breakage may have slipped through... > > So if you're a regular user of qemu-linaro's system mode and feel > like checking the sources out of git: > git://git.linaro.org/qemu/qemu-linaro.git > building them and testing that the things you regularly do with it > haven't regressed, then I'd appreciate it, and you can help us avoid > any nasty surprises in the next (2011.09) release. Could we get a daily package built to aid people testing this continuously. -- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: request for testing: qemu-linaro git tree
On 30 August 2011 16:20, Christian Robottom Reis wrote: > On Tue, Aug 30, 2011 at 11:07:25AM +0100, Peter Maydell wrote: >> So if you're a regular user of qemu-linaro's system mode and feel >> like checking the sources out of git: >> git://git.linaro.org/qemu/qemu-linaro.git >> building them and testing that the things you regularly do with it >> haven't regressed, then I'd appreciate it, and you can help us avoid >> any nasty surprises in the next (2011.09) release. > > Could we get a daily package built to aid people testing this > continuously. At the moment hudson will always do a test build and boot so we get a minimal level of continuous integration testing. However this is not exactly very exhaustive. Improving the test coverage and CI story for qemu is on both my and the validation team's todo list but is alas not very high up either list. -- PMM ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: how to properly enable multilib builds?
Matthias, does the solution below work for you? On Tue, Aug 23, 2011 at 03:03:03PM +0100, Andrew Stubbs wrote: > On 22/08/11 11:33, Matthias Klose wrote: > >the current gcc-4.6 packages build for both softfp and hard, so that the > >armel > >and (not yet existing) armhf packages can be installed together in the > >system. > >To enable multilib, I currently use the rather complicated arm-multilib.diff, > >which works, but doesn't seem to be correct. With the much simpler > >arm-ml2.diff, > >the directory for the default multilib is not resolved to . (as done for e.g. > >amd64). > > Ok, I *think* I see the problem: you're not supposed to list the > default library as a multilib. > > Try this: > > --8<>8-- > ifeq ($(with_float),hard) > MULTILIB_OPTIONS = mfloat-abi=softfp > MULTILIB_DIRNAMES = sf > > else > MULTILIB_OPTIONS = mfloat-abi=hard > MULTILIB_DIRNAMES = hf > > endif > --8<>8-- > > Andrew > > ___ > linaro-toolchain mailing list > linaro-toolchain@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-toolchain -- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
