Hi there,
As discussed with Loïc, please find attached my slides to the ELCE presentation related to our implementation of linux-awareness for JTAG debugging. I still need a formal clearance of my organization on my contribution patch, but I (and my managers) will be happy to see some or all of this work benefit to-and-from the community. If you are interested, I will try to upload a self-contained qemu-based demo to a public ftp.
Cheers,
Marc Titinger.
> -----Original Message-----
> From: Loïc Minier [mailto:lool@dooz.org]
> Sent: Wednesday, November 02, 2011 3:19 PM
> To: Marc TITINGER
> Cc: Michael Hope; Ulrich Weigand
> Subject: Re: contribution Linux Kernel Debugger
>
> On Wed, Nov 02, 2011, Marc TITINGER wrote:
> > J'ai été content de vous rencontrer toi et Nicolas à la suite de ma
> > présentation pour discuter de l'opportunité de la contribution de
> > notre debugger linux. J'ai une question: dans la mesure ou STMicro ne
> > fait pas partie des membres de linaro, aurais-je un accès restreint
> > aux outils et discussions si je souhaite contribuer? Quels serons les
> > blueprints correspondant à ce projet ?
>
> Most things Linaro does are public; concerning the toolchain,
> benchmarks are kept private due to licensing constraints. Even if
> STMicro is not a member, you're welcome to present your ideas and code
> to us (we don't mind if STMicro joins as a member though ;-).
>
> We covered topics similar to your ELC-Europe talk this week:
> https://blueprints.launchpad.net/linaro-toolchain-misc/+spec/linaro-
> toolchain-kernel-debugging
>
> Ulrich Weigand and Michael Hope will continue discussions around where
> we will go in terms of helping kernel debugging next cycle, it might
> be
> that we end up working on similar areas than the ones you and I
> discussed (special handling for linux in GDB -- tasks, backtracing
> across kernelspace/userspace; OpenOCD fixes...).
>
> Your slides don't seem to be at
> https://events.linuxfoundation.org/events/embedded-linux-conference-
> europe/titinger
> yet, so perhaps you could share a link with Michael and Ulrich? or
> post on the linaro-toolchain@ mailing-list
>
> We'll be a bit busy this week, but if you want to discuss your
> patches,
> upstreaming, further developments, I would think Michael can arrange
> for you to join a Toolchain WG call in the next weeks -- Michael, I'll
> let you comment once you get to see the slides :-)
>
> --
> Loïc Minier
Summary:
* Add zlib and libiconv support in crosstool-ng and repack embedded
toolchain source package.
Details:
* Read crosstool-ng scripts, configs and document to learn on how it works.
* Try mkedwards's extensions for crosstool-ng at
https://github.com/mkedwards/crosstool-ng. It does have lots of
extensions, the GDB-cross can build. But zlib and libiconv do not meet
our requirement.
* Add config, patch and build scripts for zlib and update the binutils
build scripts to use the prebuilt zlib.
* Add config and build scripts for libiconv and update the build
scripts of gcc and gdb.
* Write scripts to patch and repack embedded toolchain source packages
to the standard format.
Plans:
* Linaro connect: Oct. 31 - Nov. 4.
* Integrate the repack scripts with crosstool-ng.
Thanks!
-Zhenqiang
RAG:
Red:
Amber:
Green:
Current Milestones:
|| || Planned || Estimate || Actual ||
||upstream-omap3-cleanup || 2011-11-10 || 2011-11-10 || ||
Historical Milestones:
||add-omap3-networking || 2011-10-13 || 2011-10-13 || 2011-10-13 ||
||a15-systemmode-planning || 2011-10-13 || 2011-10-13 || 2011-09-22 ||
||a15-usermode-support || 2011-11-10 || 2011-11-10 || 2011-10-27 ||
== other ==
* Linaro Connect week. Included an extremely useful double-length
session about KVM on A15, which should turn into blueprints/plans
in due course
* Found out a bit more about UEFI -- I'm leaning towards having QEMU
for vexpress run UEFI by default as a way of letting you just pass
it a disk image rather than having to feed it a separatekernel/initrd.
(Will look into this more when the ARM landing team have it all
building and working on hardware.)
* I have a working prototype of the QEMU virtio-mmio transport (written
to Pawel's spec). However to get this upstream we will first need to
properly refactor the qemu virtio code so the link between the
transport and the blk/net/etc backends is a qdev bus.
-- PMM
Continue working on the regsiter pressure estimation implementation -
testing the implementation on libav micro benchmarks.
With the patch some SMSed kernels in put-h264-qpel8-hv-lowpass-8,
swscale-rgb24ToY_c mjpegenc benchmarks are identified as having
register pressure.
I'm looking at the kernels which still have regressions with SMS and
it seems the reason is not related to register pressure.
Hi All,
This is a brain dump of what I learned about running LAVA today.
Dave will probably find a place for this in the Validation wiki, but
I'll pass it round in the meantime.
Hope it helps
Andrew
Hi,
* libunwind
* posted small bug fixes
* noticed the unwinding on Android is broken somehow
(need to track down the commit that broke it)
* linaro android
* repo sync fails due invalid bionic commit id (#885792)
* tried to remotely attend the Connect
* +1 for having live streams of the plenaries
(http://video.ubuntu.com/live/)
* -1 for pointing us to the wrong grand sierra irc channels
(http://uds.ubuntu.com/participate/remote)
* icecast streams worked most of the time
(* public holiday on tuesday)
Regards
Ken
=== 64 bit atomics
* I got the race in membase down to a futex issue, and asking dmart
pointed me at a kernel bug that
affects recent kernels where a fix had gone in about a month ago.
That was a nasty one!
* I've still got a few bugs left; most are turning out to be timing
races in the test code (e.g. one that
times out after 2seconds but the code takes around 1.7 seconds ish -
but if something else gets
in trips over the line, and another one where it did a recv_from on a
socket but only got
the start of a message, presumably because the sender had used
multiple sends). It's tricky going
because the tests are a combination of most scripting languages (perl,
python, ruby with a splash of Erlang).
I've so far found no bugs in the atomic code.
* I looked at apr and SDL-1.3; both of which use atomics; but end up
not using 64bit atomics;
the tendency is for them to ensure they can do atomics on long and on
a void*; both of which
for us are 32bit.
=== String routines
* I've got the Newlib A15 optimised memcpy running in a test harness
at the moment for
comparison.
=== Listening to connect
* I listened in to a few connect sessions each day; the 1st day or
so was 3/4 lost on
audio systems that didn't work (I'm especially annoyed at not being
able to hear the QEMU for A15/KVM session
and toolchain support for kernel). The Rypple session was rather lost
through the lack of any screen share
or slides.
Hello all,
I've been playing around with linaro and have it working on my
Pandaboard locally. I have a couple of questions about the linaro
environment; if this is the wrong forum, I'm happy to take it elsewhere.
I see that Linaro makes monthly releases of the hwpacks and images.
How are the packages/binaries in those images created? Are they
cross-compiled, or compiled natively on the target platform? If they
are cross-compiled, how is the environment created?
The reason I ask is that we've been looking at cross-compiling some
packages ourselves, and have been running into issues. So we were
wondering what toolchain the linaro community uses.
Thanks in advance,
--
Chris Lalancette
Hello all,
I've been playing around with linaro and have it working on my
Pandaboard locally. I have a couple of questions about the linaro
environment; if this is the wrong forum, I'm happy to take it elsewhere.
I see that Linaro makes monthly releases of the hwpacks and images.
How are the packages/binaries in those images created? Are they
cross-compiled, or compiled natively on the target platform? If they
are cross-compiled, how is the environment created?
The reason I ask is that we've been looking at cross-compiling some
packages ourselves, and have been running into issues. So we were
wondering what toolchain the linaro community uses.
Thanks in advance,
--
Chris Lalancette
