Efika MX Smartbook + serial dongle needed at Linaro Connect
Hi Looks like I managed to break serial port on my Efika MX Smartbook today. As there are people in Linaro with this device I am asking for help. For this I need someone with Efika MX Smartbook and debug board to be present at conference. I will take my netbook and dongle so will be able to check is it dongle or Efika which broke for me. If you have both and have no use for them I can take it from you - will have no problems finding someone here wanting to play & hack on Efika ;) ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Efika MX Smartbook + serial dongle needed at Linaro Connect
W dniu 01.02.2012 14:10, Marcin Juszkiewicz pisze: Hi Looks like I managed to break serial port on my Efika MX Smartbook today. As there are people in Linaro with this device I am asking for help. For this I need someone with Efika MX Smartbook and debug board to be present at conference. I will take my netbook and dongle so will be able to check is it dongle or Efika which broke for me. If you have both and have no use for them I can take it from you - will have no problems finding someone here wanting to play & hack on Efika ;) Update: looks like flex cable was faulty - after few reconnections it started working again. I have serial working now YAY! :) ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: trouble building linux-linaro-3.0-2011.08-0
W dniu 21.02.2012 04:37, Matt Sealey pisze: I'm kind of languishing in gcc 4.4 hell right now and would quite like an updated toolchain for 4.6.2 or thereabouts (synced with the 2012.12 Linaro release). Is this available as a package or PPA somewhere or am I going to spend the night compilercompiling? I have to update toolchain backport ppa with something more up to date. Will do this week. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Cross toolchain for lucid updated
Linaro cross toolchain backport PPA [1] got updated to recent Ubuntu 12.04 versions: - gcc 4.5.3 - gcc 4.6.2 - binutils 2.22 - eglibc 2.15 - linux 3.2 I tested both compiler versions against few packages, U-Boot and Linux 2.6.32. Those packages may also work under Ubuntu 10.10 'maverick' and 11.04 'natty' but it was not tested. Users of Ubuntu 11.10 'oneiric' may install libmpfr1ldbl package [2] and then use 'lucid' repository to install cross compiler while I will prepare packages for their version of Ubuntu. Please report any problems with those backported packages in launchpad [3][4][5]. 1. https://launchpad.net/~linaro-maintainers/+archive/toolchain 2. http://packages.ubuntu.com/lucid/libmpfr1ldbl 3. https://launchpad.net/ubuntu/+source/gcc-4.5-armel-cross/+bugs 4. https://launchpad.net/ubuntu/+source/gcc-4.5-armel-cross/+bugs 5. https://launchpad.net/ubuntu/+source/armel-cross-toolchain-base/+bugs ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Cross toolchain for lucid updated
W dniu 29.02.2012 14:23, Marcin Juszkiewicz pisze: Those packages may also work under Ubuntu 10.10 'maverick' and 11.04 'natty' but it was not tested. Users of Ubuntu 11.10 'oneiric' may install libmpfr1ldbl package [2] and then use 'lucid' repository to install cross compiler while I will prepare packages for their version of Ubuntu. Packages for 11.10 'oneiric' were built. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Slow/broken USB and Ethernet on Snowballs/Origen boards?
W dniu 15.03.2012 11:31, Jassi Brar pisze: > Cool. You might also want to take a look at 'netperf', a small yet > powerful tool. Or iperf which I use for bandwidth tests. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
ARM porting jam on Wednesday
Dear ARM fans, Linaro Developer Platform team organises every week an ARM porting Jam. Next one will be on Wednesday 11th April (we moved from Friday cause weekend does not help in remembering which patches are still to send upstream). The idea is to gather all developers together to fix user space portability issues across the board. There are several things to work on: - the list of bugs being worked on is at launchpad [1] with more useful web interface at [2] 1. https://bugs.launchpad.net/ubuntu/+bugs?field.tag=arm-porting-queue&orderby;=-id 2. http://people.linaro.org/~rsalveti/arm-porting-queue/arm-porting-queue-report.html - list from 'make multiarch cross-building work' process which is described at [3][4] with logfiles available at [5] - now that the release is close non-trivial fixes should rather go into Debian than Ubuntu. As this is cross compiler related you do not even have to use ARM devices. 3. http://wiki.linaro.org/Platform/DevPlatform/CrossCompile/MultiarchCrossBuildStatus 4. http://wiki.debian.org/Multiarch/CrossDependencies 5. http://people.linaro.org/~wookey/buildd/precise/sbuild-ma/status.html - You can also help with libffi related issues if you can - list is available at Debian wiki [6] 6. http://wiki.debian.org/ArmHardFloatTodo#libffi Interested in making the software in Ubuntu run better on ARM? Join us on the #linaro channel on irc.linaro.org (aka freenode) today! ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Installing the armel libc on armhf
W dniu 06.05.2012 16:06, Michael Hope pisze:
Hi there. Hopefully an easy question but I'm stumped. How do I
install the armel softfp libc6 on a new Precise armhf install?
I set APT::Architectures to { "armel" } and then tried a apt-get
install libc6:armel but I get errors about the package not matching
the host architecture.
echo 'foreign-architecture armel' >>/etc/dpkg/dpkg.cfg.d/multiarch
echo 'deb [arch=armel] http://ports.ubuntu.com/ precise main universe'
>/etc/apt/sources.list.d/armel.list
apt-get update
apt-get install libc6:armel
not tested, should work
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: new IRC channel: linaro-lava
W dniu 10.05.2012 09:34, John Rigby pisze: We need an irc aggregator to flatten all the channels to one on rx and broadcast on tx for those of use who want to live in a flat world (only half kidding:) You mean ircII/epic when by default all was in one window and Ctrl-x was used to switch channels before saying anything? ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[Linaro Connect] Session about packaging Linaro components
Hi all. During Linaro Connect there will be a session [1] about packaging tools and other components produced by Linaro teams. Goals: - Review the current set of components/projects create and maintained by Linaro - Identify the ones that are not yet part of Ubuntu and Ubuntu LEB - Discuss how to make the Linaro changes upstream at the distro-level as soon they are updated I want to get Linaro to the point where most of our tools will be available in Debian and Ubuntu distributions instead of random set of PPAs. Whom I would like to see there? Everyone who has written any packaged (or not yet) tool useful for other developers. Nevermind is it host or target, native or cross tool. 1. http://summit.linaro.org/lcq2-12/meeting/20859/review-the-missing-packages-for-components-produced-and-maintained-by-linaro/ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Lava images improvement idea
Hi LAVA is good for doing some tests but every time I use it I wonder why it is so slow. So I looked more at problem. Job which I started is going on pandaboard for 48 minutes already. So far it did nothing related with tests which I want to run. Instead if fetched some image, booted and started installing lot of Python packages... This got me to idea - why not make *-lava variants of images which would have all packages needed by LAVA infrastructure preinstalled? It would take some minutes of Jenkins but less then LAVA one probably. Especially when bigger set of jobs is to be run. Opinions? ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Can we use mmcblk0p8?
W dniu 18.06.2012 15:02, YongQin Liu pisze: > Hi, Saugata > > We have a problem to use the mmcblk0p8 partition, do you know if we > can use it, and how can we use it? > > I created the 8th partition with fdisk command and the 8th partition > is listed in the output of fdisk -l command but it is not listed in > /proc/partitions file, even after reboot And also I can't use > mkfs.vfat -n sdcard /dev/mmcblk0p8 to format. > > Could you give me some help about this? Check /dev/mmcblk1p0 node number for answer. IIRC there is limited amount of partitions on MMC cards which Linux handles (a bit stupid limit imho). ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Can we use mmcblk0p8?
W dniu 18.06.2012 16:20, Paul Larson pisze: > It's worked for us so far, but it's been tight on the lava side due > to the number of partitions that android wants, and especially with > the annoying hardcoded partition numbers that android uses. I do wonder why Linaro Android team did not tried to make /data /system parts of one filesystem instead of moving them to separate ones. Or maybe I do not know something ;) ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Powertop] [PATCH] conditionally disable pci support on ARM platforms
W dniu 22.06.2012 22:01, Arjan van de Ven pisze: > On 6/22/2012 11:42 AM, Rajagopal Venkat wrote: >> +case "$host" in >> +arm*) >> +AC_DEFINE([HAVE_NO_PCI],[1],[Define if host platform is ARM]) >> +;; >> +*) >> +PKG_CHECK_MODULES([PCIUTILS], [libpci],[],[ >> +AC_SEARCH_LIBS([pci_get_dev], [pci], [], AC_MSG_ERROR([libpci >> is required but was not found]), []) >> +]) >> +;; >> +esac >> + > > I don't like this part. > > if libpci is option, it is optional. > > being arm or not is completely irrelevant in this regard. > (and there will undoubtedly ARM systems at some point that will have PCI > in them) Already there are ARM devices with PCI(e) support. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Nexus 7/Jellybean Kernel Config
W dniu 04.07.2012 22:19, Christian Robottom Reis pisze: > Hey there, > > I stumbled onto a thread on xdadevelopers where they are looking at > the Nexus 7; apart from partition and df output, there's a 3.1.10 kernel > config, which I'm attaching here for convenience and analysis. > > ls -l /dev/block/platform/sdhci-tegra.3/by-name/ .. > lrwxrwxrwx root root 2012-06-28 11:51 MDA -> /dev/block/mmcblk0p8 > lrwxrwxrwx root root 2012-06-28 11:51 UDA -> /dev/block/mmcblk0p9 Patched kernel to have 9 partitions on mmc... ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Cross compiler backport for Ubuntu 12.04 'precise' is available
Hello I would like to announce backport of cross compiler for Ubuntu 12.04 LTS distribution. Release contains: - binutils 2.22.52 snapshot - gcc 4.6.3 (Linaro 12.06) - gcc 4.7.1 (Linaro 12.07) - eglibc 2.15 - linux 3.5.0 headers Packages are available for amd64 and i386 architectures and support building for both armel and armhf targets. PPA: https://launchpad.net/~linaro-maintainers/+archive/toolchain Previous Ubuntu releases are not supported - please upgrade to 12.04 LTS. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Updated armel cross toolchains for lucid/maverick/natty releases
Hi Linaro backport PPA [1] got updated to latest versions of armel cross toolchains -- oneiric packages were used as a base. What got changed: - gcc 4.4 was updated to 4.4.6-3ubuntu1 - gcc 4.5 was updated to 4.5.3-1ubuntu2 - binutils was updated to 2.21.52.20110606-1ubuntu1 - eglibc was updated to 2.13-6ubuntu2 - gcc 4.6 was provided as 4.6.0-14ubuntu1 in Maverick, Natty - gcc-defaults-armel-cross was updated to 1.6 in Maverick, Natty (uses gcc-4.6 as default) There is no gcc-4.6 for Lucid currently as it requires newer versions of few libraries (mpfr, mpc) and one of rule of this PPA is "do not update packages which may affect other packages". Please test them and report any bugs found. 1. https://launchpad.net/~linaro-maintainers/+archive/toolchain/ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Updated armel cross toolchains for lucid/maverick/natty releases
On 08.07.2011 00:11, Michael Hope wrote: > On Thu, Jul 7, 2011 at 1:36 AM, Marcin Juszkiewicz >> There is no gcc-4.6 for Lucid currently as it requires newer versions of >> few libraries (mpfr, mpc) and one of rule of this PPA is "do not update >> packages which may affect other packages". > > Hi Marcin. The versions included with Lucid are OK for 4.6. Lucid > includes libmpc 0.8.1 (GCC's configure.ac marks it as 'buggy but > acceptable) and libmpfr 2.4.2. There is a difference in package names > - it's libmpfr1ldbl in Lucid and libmpfr4 in Natty. Thanks Michael. I do not remember why I though that. Anyway gcc-4.6 got built for Lucid too. Enjoy. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Generic Linux cross toolchain for tests
Hi Some time ago we agreed that not everyone here uses Ubuntu distribution and decided to provide so called 'generic linux' cross toolchain. Recently I managed to get it done and now need brave testers to tell is it working or not. Get it here: http://people.linaro.org/~hrw/generic-linux/ (64bit only) Needed files are toolchain-11.07.tar.xz and init.sh script. Unpack tarball from / so /opt/linaro/11.07/ will be populated and put init.sh anywhere you want (it will be integrated into tarball later). How to use: $ source init.sh this will add cross toolchain into PATH and also set LD_LIBRARY_PATH to two directories: - one with binutils libraries - second with all extra libraries which may be needed Feel free to experiment with second dir by removing files from there and checking are system provided libs are fine too. So far I checked this toolchain under few distributions: - Ubuntu 10.04 'lucid' LTS - Ubuntu 11.04 'natty' - Fedora 14 - OpenSUSE 11.4 - CentOS 5.6 It failed only under CentOS (which was expected due to it's age). How did I checked? So far compilation of 'gpm' and 'zlib' were tested. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: ARM porting Jam today 14:00 - 18:00 UTC
My queue from today: traverso: https://bugs.launchpad.net/bugs/823708 - added preprocessed source from g++ 4.5, 4.6, 4.7(gcc-snapshot) - subscribed Linaro toolchain developers gtk-gnutella: https://bugs.launchpad.net/bugs/823709 - checked 0.97-2 from Debian - requested sync: https://bugs.launchpad.net/bugs/832692 oss4: https://bugs.launchpad.net/bugs/809761/ - added preprocessed source from gcc 4.6 - fails also under gcc-4.5 and gcc-snapshot - subscribed Linaro toolchain developers unison2.27.57: https://bugs.launchpad.net/bugs/809760 - built fine in pbuilder tcc: https://bugs.launchpad.net/bugs/823716 - confirmed ftfbs - checked Debian 'sid' version - ftfbs as expected - checked Debian 'experimental' version - builds xen: https://bugs.launchpad.net/bugs/823714 - just looked - needs to set i386/amd64 as only working archs probably ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Android Tools
W dniu 25.08.2011 21:20, Christian Robottom Reis pisze: > On Thu, Aug 25, 2011 at 04:15:37PM -0300, Ricardo Salveti wrote: >> On Thu, Aug 25, 2011 at 4:04 PM, Zach Pfeffer >> wrote: >>> One thing to keep in mind is that developers will get these tools from >>> Google during their SDK install. Are we going to wrap that install? >> >> The idea was to make some of the tools available at Ubuntu directly, >> so that's why it'd be good to know which tools are the most important >> ones first. > Another criteria is if it allows for more opportunistic Android hacking > -- i.e. I have an Ubuntu system and an Android device and am scared of > this big opaque third-party-provided Android SDK; can I install some > tools (adb etc) from the Ubuntu archive that let me start hacking right > away? That was my initial idea when I made android-tools package (which was not announced anywhere). As owner of few Android devices I want to have utilities like: - adb, - fastboot (to download images to my phone), - nvflash (ask #ac100 and/or Ubuntu/ARM guys do they have it) would be nice to download images to my Tegra2 tablet - mkbootimg (and related) so I can prepare kernel image to flash device (abootimg iirc does that) ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: ARM porting Jam today 14:00 - 18:00 UTC
My queue from yesterday/today: https://bugs.launchpad.net/ubuntu/+source/xtrs/+bug/835768 https://bugs.launchpad.net/ubuntu/+source/van.testing/+bug/835765 https://bugs.launchpad.net/ubuntu/+source/python-ldap-doc/+bug/835763 https://bugs.launchpad.net/ubuntu/+source/simple-ccsm/+bug/835743 https://bugs.launchpad.net/ubuntu/+source/martian/+bug/833901 https://bugs.launchpad.net/ubuntu/+source/mythbuntu-log-grabber/+bug/833892 https://bugs.launchpad.net/ubuntu/+source/lo-menubar/+bug/833889 https://bugs.launchpad.net/ubuntu/+source/mythbuntu-control-centre/+bug/833884 https://bugs.launchpad.net/ubuntu/+source/mush/+bug/833880 All those bugs got debdiffs and sponsors subscribed. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: ARM CPU part numbers
W dniu 01.09.2011 12:20, Pawel Moll pisze: >> Does anybody have a list of such numbers? ARM926 - 0x926 (atmel at91sam9263) ARM920 - 0x920 (atmel at91rm9200) I have some armv4t/v5t/v6 systems here but none of them under power. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: ARM CPU part numbers
W dniu 02.09.2011 06:40, David Brown pisze: > Processor : ARMv7 Processor rev 1 (v7l) > BogoMIPS: 191.69 > Features: swp half thumb fastmult vfp edsp neon vfpv3 > CPU implementer : 0x41 > CPU architecture: 7 > CPU variant : 0x0 > CPU part: 0xc05 > CPU revision: 1 > > Hardware: QCT MSM9615 CDP > Revision: > Serial : wow - finally A5 in other form then ARM FPGA :) ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: ARM CPU part numbers
W dniu 05.09.2011 11:28, Andrew Stubbs pisze: > Next question ... is /proc/cpuinfo really the best way to detect this? > > I mean, is auxv a better approach? Or something else? What's the most > efficient, and most stable API to read the CPU architecture, CPU model, > and FPU/NEON availability? > > There's some worry among the toolchain team that /proc/cpuinfo is a > somewhat fragile and inefficient way to achieve this goal. Some insight > from the kernel experts would be helpful! Remember that there are cpus like imx51 to2 which have broken neon and this is shown in /proc/cpuinfo (no neon flag for them). So using own tests should also check what kernel has to say. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro Boot up times.
W dniu 14.09.2011 14:18, David Gilbert pisze: > Be a bit careful; given that the boot speed might be limited by SD card > performance, writing a lot more to /var/log might not help. Then mount /tmp as tmpfs and write there? ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ANNOUNCE] android-tools-(adb,fastboot}
W dniu 29.09.2011 20:28, Tom Gall pisze: > The development platforms team would like to announce the availability > of the android-tools-adb and android-tools-fastboot packages. This > allows one to have access to these tools without having to go through > all the steps involved with the AndroidSDK and can be useful > especially in situations where you just need the one or two tools. Yay! Android-tools package got used, updated and released! I have to install it and remove two more binaries from /usr/local/bin ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: BUGREPORTED work item state
W dniu 03.10.2011 04:48, Zach Pfeffer pisze: > On 30 September 2011 13:22, Fathi Boudra wrote: >> Hi Zach, >> >> I noticed that you introduced BUGREPORTED on Android blueprints for >> the work items. >> It raised a couple of questions: >> 1. what does BUGREPORTED means ? > > When David Zinmann and I were going through each WI and closing out > 11.09, a few BPs were done, except for one or two issues. These issues > were bugs, so instead of filing a new WI in 11.10 we just marked the > WI as BUGREPORTED and linked the bug to the 11.09. BUGREPORTED seemed > to unambiguously mark a hand off between the BP tracking and the bug > system. You know that linked bug counts as work item too? So if you have work item for each you reported a bug you can drop it from whiteboard once it got linked. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Proposal : New Linaro Desktop Wallpaper
W dniu 01.12.2011 23:56, Tom Gall pisze: > Towards that end (and given that time is short if this is to make > 11.12) I'd like to propose the following graphic be our new wallpaper > image. This would be the image displayed in the background on a > graphical desktop by default. Lovely! ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: omapconf tool publicly released
W dniu 21.09.2012 22:24, Zach Pfeffer pisze: > On 21 September 2012 15:07, Mike Turquette wrote: >> https://github.com/omapconf/omapconf > > Is there an Android.mk? Looking at > https://github.com/omapconf/omapconf it says it works on Android, but > I don't see an Android.mk to compile it with. It is on page: Build instructions and installation via ADB (Android): Make sure your Android device is connected to host via ADB: # adb kill-server # adb devices * daemon not running. starting it now * * daemon started successfully * List of devices attached emulator-5554 device # adb root To build and install ompaconf for Android via ADB: make CROSS_COMPILE=arm-none-linux-gnueabi- install_android OMAPCONF binary will be copied to /data directory (known writable directory) on your Android device. You may get it copied to a different directory by updating Makefile at your convenience. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 2/3] kernel-arch.bblass: add AArch64 support
Signed-off-by: Marcin Juszkiewicz
---
meta/classes/kernel-arch.bbclass |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/classes/kernel-arch.bbclass b/meta/classes/kernel-arch.bbclass
index 6446504..b3b78b6 100644
--- a/meta/classes/kernel-arch.bbclass
+++ b/meta/classes/kernel-arch.bbclass
@@ -8,7 +8,7 @@ valid_archs = "alpha cris ia64 \
i386 x86 \
m68knommu m68k ppc powerpc powerpc64 ppc64 \
sparc sparc64 \
- arm \
+ arm aarch64 \
m32r mips \
sh sh64 um h8300 \
parisc s390 v850 \
@@ -22,6 +22,7 @@ def map_kernel_arch(a, d):
if re.match('(i.86|athlon|x86.64)$', a): return 'x86'
elif re.match('armeb$', a): return 'arm'
+elif re.match('aarch64$', a): return 'arm64'
elif re.match('mips(el|64|64el)$', a): return 'mips'
elif re.match('p(pc|owerpc)(|64)', a): return 'powerpc'
elif re.match('sh(3|4)$', a): return 'sh'
--
1.7.10.4
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Add AArch64 support into OE-Core
This patchset adds support for AArch64 in all required classes: - insane - kernel-arch - siteinfo Everything is from public available information (binutils, linux). ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 1/3] siteinfo.bbclass: add AArch64 support
Signed-off-by: Marcin Juszkiewicz
---
meta/classes/siteinfo.bbclass |2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/classes/siteinfo.bbclass b/meta/classes/siteinfo.bbclass
index 8c256ce..aab0867 100644
--- a/meta/classes/siteinfo.bbclass
+++ b/meta/classes/siteinfo.bbclass
@@ -18,6 +18,7 @@
def siteinfo_data(d):
archinfo = {
"allarch": "endian-little bit-32", # bogus, but better than
special-casing the checks below for allarch
+"aarch64": "endian-little bit-64 arm-common",
"arm": "endian-little bit-32 arm-common",
"armeb": "endian-big bit-32 arm-common",
"avr32": "endian-big bit-32 avr32-common",
@@ -60,6 +61,7 @@ def siteinfo_data(d):
"mingw32": "common-mingw",
}
targetinfo = {
+"aarch64-linux-gnu": "aarch64-linux",
"arm-linux-gnueabi": "arm-linux",
"arm-linux-uclibceabi": "arm-linux-uclibc",
"armeb-linux-gnueabi": "armeb-linux",
--
1.7.10.4
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 3/3] insane.bbclass: add AArch64 support
Signed-off-by: Marcin Juszkiewicz
---
meta/classes/insane.bbclass |1 +
1 file changed, 1 insertion(+)
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 1fb8970..b390242 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -44,6 +44,7 @@ def package_qa_get_machine_dict():
"arm" : (40, 0,0, True,
32),
},
"linux" : {
+"aarch64" : (183,0,0, True,
64),
"arm" : (40,97,0, True,
32),
"armeb": (40,97,0, False,
32),
"powerpc":(20, 0,0, False,
32),
--
1.7.10.4
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Add AArch64 support into util-linux
Attached patch fixed build problem when util-linux is built for AArch64 architecture. --- fdisk/fdiskbsdlabel.h |1 + 1 file changed, 1 insertion(+) --- util-linux-2.21.2.orig/fdisk/fdiskbsdlabel.h +++ util-linux-2.21.2/fdisk/fdiskbsdlabel.h @@ -46,10 +46,11 @@ #define BSD_LINUX_BOOTDIR "/usr/ucb/mdec" #if defined (__i386__) || defined (__sparc__) || defined (__arm__) || \ defined (__mips__) || defined (__s390__) || defined (__sh__) || \ +defined (__aarch64__) || \ defined(__x86_64__) || defined (__avr32__) || defined(__cris__) #define BSD_LABELSECTOR 1 #define BSD_LABELOFFSET 0 #elif defined (__alpha__) || defined (__powerpc__) || defined (__ia64__) || defined (__hppa__) #define BSD_LABELSECTOR 0 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Exynos5 binary blobs situation on devices running GNU/Linux
Hello everybody
This time I want to post some information and questions about binary
blobs situation on Exynos5 devices. It means Samsung Chromebook and
Andale Board (I do not have data about other Exynos5 powered devices).
Chromebook ships with Chromium OS and under it has working OpenGL ES and
OpenMAX based video acceleration. I was able to play 1080p YouTube
videos both on internal and external screen without any slowdown.
But under normal GNU/Linux systems (Debian, Fedora, OpenSUSE, Ubuntu)
there is none of it...
We got OpenGL ES running by copying libmali and all symlinks pointing to
it (lib{EGL,GLES} etc) and taking care of /dev/mali* permissions. But we
can not make packages with it for our distibutions because of lack of
any license for it. Normal "this is proprietary binary, do not hack it
etc but you can distribute it freely" kind of license will be enough.
Android binaries for OpenGL ES are available for Andale Board. GNU/Linux
ones can be extracted from Chromebook recovery image (363MB download
extracting to ~1GB file). But lack of license anyway.
I know that we have ARM Ltd. people here, same with Samsung - maybe
someone can tell us what is going on in this area?
Other thing is video acceleration. I do not know is there a source for
it available or not. This is area where I do not have knowledge needed
to get it running. All I know is that Exynos5 itself is able to play
480p DivX encoded movie - did not yet tried 720p or 1080p ones but do
not think it will make it on it own.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Bug Fix for ARMv8 bootup in Foundation_v8pkg
W dniu 27.11.2012 14:56, Sagar Kadam pisze: > Hello, > > We are using ARM foundation models for evaluation of ARMv8 architecture. > We are able to boot the prebuilt images as provided and directed by > Linaro on the following link. > http://www.linaro.org/engineering/armv8/#tab > <http://www.linaro.org/engineering/armv8/#tab>1 > > But if we try to recompile the kernel as directed on following link > (https://wiki.linaro.org/HowTo/BuildArm64Kernel > <https://wiki.linaro.org/HowTo/BuildArm64Kernel>) > we observed that Foundation model is not able to boot the kernel > completely. > The following is the error message "Starting Boolog daemon: bootlogd: > cannot find console device 204:64 under /dev" > I screened throughout the linaro site as well as on Google but didn't > get any fix suitable for it. > I have fixed this bug and would like to submit the patch to linaro > upstream branch. > > Could you please review the patch and let me know how I can upload it to > Linaro so that other developers can also use it. We use "devtmpfs.mount=1" in kernel cmdline to force devtmpfs to be mounted. But it would be nice to have it integrated as well. Acked-by: Marcin Juszkiewicz ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
New layout for OpenEmbedded layers
Hello Now at Linaro we have two layers for our OpenEmbedded work: - meta-aarch64 - meta-linaro First one contains everything we need to get AArch64 booted in fastmodels: toolchain, kernel and few recipes which needed changes to build for AArch64. I am working on merging those changes into main OpenEmbedded layers. Second one is gcc-linaro from Toolchain WG and some recipes and changes from Platform team. Those who do OE builds with our toolchain have some components changed due to our metadata (like Busybox with dpkg-deb) and I decided to fix it. Today I pushed "new-layout" branch of meta-linaro repository. It contains all Linaro layers: - meta-aarch64 - meta-linaro - meta-linaro-toolchain First one was merged from meta-aarch64 repository and moved to own directory. Third one contains only toolchain bits. Second one has all that left. I have to do some test builds with this layout and once they will confirm that it works I will change all CI builds. This will also deprecate meta-aarch64 repository - it will not have any updates and will be dropped in ~month. Opinions? ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] configure: Support QEMU cross-compiling for ARM64 host
W dniu 08.01.2013 12:05, Anup Patel pisze: > We should be able to cross compile QEMU for ARM64 host. > > This is required for trying out ARM 32-bit guest on ARM64 host using QEMU + > KVM ARM64. Which version you got built with this patch? 1.3.0 failed for me. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Where to report Mali OpenGLES bugs?
Hello As some of you know I created a team of ARM Chromebook hackers on Launchpad. We concentrate on getting misc things working on those devices. One is Mali T604 OpenGLES driver. It works but there are some bugs in it. The problem is: where to report them? As Chromium OS bugtracker is not proper place as our use cases are different than their. https://bugs.launchpad.net/chromebook-arm/+bug/1085596 is an example showing that if you run two applications using OpenGLES then you have screen artifacts. Or if you run WM with compositing and any OpenGLES application (glgears-es2 is enough). Can someone from Linaro Multimedia team or ARM Multimedia team suggest option? ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: OpenEmbedded runlevels empty?
W dniu 23.01.2013 10:46, Tim Northover pisze: > Hi again, > > Sorry for spamming this list with what are essentially support questions, but > now that bug #1099896 has been fixed, I'm trying to build an OpenEmbedded > filesystem with it, following the instructions at > https://wiki.linaro.org/HowTo/ARMv8/OpenEmbedded. > > What comes out seems amazingly close to a functional system, except that > nothing gets put into runlevel 5 so none of the actual programs get started on > boot (mainly sshd and a console login obviously, I could work around anything > else). > > Has anyone seen this before or know where I should start looking? I've not > really used OpenEmbedded before. I am working on it today. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: OpenEmbedded runlevels empty?
W dniu 23.01.2013 10:46, Tim Northover pisze:
> Hi again,
>
> Sorry for spamming this list with what are essentially support questions, but
> now that bug #1099896 has been fixed, I'm trying to build an OpenEmbedded
> filesystem with it, following the instructions at
> https://wiki.linaro.org/HowTo/ARMv8/OpenEmbedded.
>
> What comes out seems amazingly close to a functional system, except that
> nothing gets put into runlevel 5 so none of the actual programs get started on
> boot (mainly sshd and a console login obviously, I could work around anything
> else).
edit build/conf/site.conf and change DISTRO_FEATURES to this (in one line):
'DISTRO_FEATURES = "x11 alsa argp ext2 largefile usbgadget usbhost xattr
nfs zeroconf ${DISTRO_FEATURES_LIBC} ${DISTRO_FEATURES_INITMAN}"
Then it will work again.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: OpenEmbedded runlevels empty?
W dniu 23.01.2013 14:30, Tim Northover pisze: > There's just one other thing I had to do, which it might be worth > either documenting or automating. I had to switch eth0 over to dhcp > for networking to work. It depends how you run model. OE images are setup for LAVA setup: https://wiki.linaro.org/Platform/QA/TestCases/OpenEmbedded#Setup_Instructions ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: builds unstable - IOERROR: BUILD-INFO.txt is not present in build.
W dniu 26.02.2013 07:50, Fathi Boudra pisze: > Several builds became "unstable" (in jenkins term) without changes in the > jobs: > IOERROR: BUILD-INFO.txt is not present in build. > > Obviously, it seems BUILD-INFO.txt is now enforced and some jobs are > still using EULA.txt mechanism. > > While I don't have any issues with (en)forcing users to use > BUILD-INFO.txt, I would have expected some notifications to allow job > maintainers to adjust the builds as appropriate. > Once again, it isn't the kind of changes to deploy the release week. Fully agree on that. As CI is used a lot and we depend on it's results any changes which affect builds should be done in first 1-2 weeks of month - in a week after monthly release and with enough time left before components release. Otherwise it makes releases harder as now I have to find out WTH that build-info.txt is, what should be there (pointer to docs anyone?) and migrate jobs to use it. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: arm64 Debian/Ubuntu port image available
W dniu 27.02.2013 03:10, Wookey pisze: > State of the Debian/Ubuntu arm64 port > = > > *** Arm64 lives! *** Congratulations Wookey (and everyone involved)! > * There is now a bootable (raring) image to download and run > Once you've created a tarball chroot builds are simply done with > sbuild -c quantal-amd64-sbuild -d quantal --host=arm64 or > sbuild -c quantal-amd64-sbuild -d quantal --host=arm64 _ > (I'd love it s/quantal/raring/ I think. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Corrupt git archive?
W dniu 08.03.2013 14:13, Tim Northover pisze: > Hi, > > I'm trying to build the OpenEmbedded AArch64 system again, and it > looks like the file: > > http://snapshots.linaro.org/openembedded/sources/git2_git.linaro.org.kernel.linux- > > linaro-tracking.git.tar.gz > > is corrupt. gzip thinks it ends unexpectedly. Shall I file some kind > of ticket for this or is it something that's fixed out-of-line? I am working on it. > -- IMPORTANT NOTICE: The contents of this email and any attachments > are confidential and may also be privileged. If you are not the > intended recipient, please notify the sender immediately and do not > disclose the contents to any other person, use it for any purpose, or > store or copy the information in any medium. Thank you. Should I go Greg KH's way and remove your email without even reading? ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Corrupt git archive?
W dniu 09.03.2013 20:02, Marcin Juszkiewicz pisze: > W dniu 08.03.2013 14:13, Tim Northover pisze: >> Hi, >> >> I'm trying to build the OpenEmbedded AArch64 system again, and it >> looks like the file: >> >> http://snapshots.linaro.org/openembedded/sources/git2_git.linaro.org.kernel.linux- >> >> > linaro-tracking.git.tar.gz >> >> is corrupt. gzip thinks it ends unexpectedly. Shall I file some kind >> of ticket for this or is it something that's fixed out-of-line? > > I am working on it. fixed ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
ATTENTION: OpenEmbedded layers from Linaro have new structure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Today I made several changes to OpenEmbedded layers hosted on git.linaro.org: - - meta-aarch64 - - meta-linaro Meta-aarch64 is now empty and is obsolete. Probably will be removed from server in about month or two. Meta-linaro repository got new structure based on meta-openembedded one and contains three layers: - - meta-aarch64 - - meta-linaro - - meta-linaro-toolchain Today meta-aarch64 is just a copy of old one but everything not related to ARMv8 will be moved from it to meta-linaro. Meta-linaro-toolchain contains just gcc-linaro and support for external Linaro cross toolchains (armv7a and armv8 ones). I considered creation of meta-aarch64-arm-toolchain one with ARM Ltd. version of gcc but it is not often used option so can stay where it is now (meta-aarch64). Instructions how to start building for ARMv8 (with OE) are in wiki: https://wiki.linaro.org/HowTo/ARMv8/OpenEmbedded Note that any scripts present in 'meta-aarch64' got dropped. If you want easy way then use 'jenkins-setup' scripts like it is described in wiki. They are written to be as easy to use as possible. If you have any problems/questions: reply to this email. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJRQJERAAoJECbKqQEReiUeKFgQAMUYDB1ymQs8ZspWVynJVJMQ InFsFQUd/QZCgNB9GcG6IepzmViHeMlIxNQ7u+KFABGV8uAz8gwdgcPtWwa/dc1b wu8u84mmwy77WBIMuX087AiXdg8WhJDJz5sztBoK2PL8Ljn1TFB/R17Ew90eN3zn o1DpPnbgMGs67phNiTy8GiQxyaaLZub0ZZZ5v00tWdt7x4vazw6n2r8/o+wzGLj2 536KI13Sepso2dg2mrpqzrwVH8KFP7S/rRiDdKI4Gw9FlTPiaiEEadX7OPKx8YC5 j1WIR0u66LCSe+F3NsfNfEgTOXPGVUNgqvemwGYXQuOLUKz7nnnkEdVRUegSuEVj +bZsgzFunghOsvEgX4ynxLVXgOrkiH4PPMhD+OWcB1pso9+ZdVFTVO2oGOnDg9pK ov7lidEoUDDIZqHxjy5cV36jDnXt8BTI9uEIjVo9gH/0g/67QImXHVONcppg2MfM GDfhYorkah3VTo9zgHZKCDEIstT1OsCSg+PNeKCAN6fDUdmnzGxCJNEj2CaRAzaI vJekxAK0+ptscJ9c+bUmAtcBK+XRvJ9K3naN+apUm13Y6INwKuS68knWzOJc0xhd rpPQ2EcYd8FP1gspjNJPyQKWr2pAUGQkOGkhHrsrb4nj6mkMDDgZ2ET1x8uxI056 vMRn7PKF7x3bItUP9NzA =GNf7 -END PGP SIGNATURE- ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: API to download from snapshots and releases is live
W dniu 26.03.2013 15:18, James Tunnicliffe pisze:
> There are many scripts in use that parse the web interface for
> snapshots and releases.linaro.org. This is far from ideal because
> changes to the web interface can result in the scripts breaking. To
> alleviate this problem an API has been introduced. The API is very
> simple, just two new URLs and a new header when downloading files.
Thanks for API - it will make live easier.
I tried it today and have few suggestions:
> http://snapshots.linaro.org/api/ls/quantal/hwpacks/snowball/latest
> {
> "files": [
> {
> "mtime": "15-Mar-2013 08:29",
> "name":
> "hwpack_linaro-snowball_20130315-269_armhf_supported.manifest.txt",
> "size": "762",
> "type": "text",
> "url":
> "/quantal/hwpacks/snowball/latest/hwpack_linaro-snowball_20130315-269_armhf_supported.manifest.txt"
> },
1. Please return 'mtime' as timestamp so we do not have to parse date.
2. Similar with 'size' which should be in bytes.
3. Can 'type' entry be MIME data? text/plain, text/html,
application/x-tgz etc. Now it is 'text' or 'other'.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Repo for Managing Git Repositories
W dniu 02.04.2013 18:09, Christopher Covington pisze: > Hi Marcin, > > I notice you've created a number of shell scripts to manage checking out > multiple git repositories, specific revisions of git repositories for a > release, etc. Repo [1] does this stuff pretty well that you might want to > consider as an eventual alternative. I was considering repo few times but jenkins-setup scripts are used not only to fetch/update/freeze git repositories but mostly to handle build jobs (at CI or any other machine). When you look at openembedded/jenkins-setup.git repo [1] you will notice that there are scripts which take care of build dependencies, clean up previous builds, generate image manifests and take care of uploading used sources to our source mirror. And this is a way I am used to work during all my years with OpenEmbedded ;D 1. http://git.linaro.org/gitweb?p=openembedded/jenkins-setup.git;a=summary ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: how to build arm64 kernel which can be downloaded from www.kernel.org (此邮件代吴小科转发)
W dniu 25.04.2013 11:07, zhanqing Zhan(Qing) pisze: > So, i want to build arm64 kernel according to the steps of > HowTo/BuildArm64Kernel.Then i use Foundatin_v8 with args such as > linux-system-foundation.axf,vexpress64-openembedded_lam-armv8_20130320-274.img. > > But kernel cannot run correctly. The information is described as following. "FATAL: kernel too old" is clean message. > I also tried to create images and got sd.img. The result is also > prompted above. The I tried to build kernel of linux-3.7rc1. Because > some files of linux-3.6 don’t exist in linux-3.7rc1. So i copied the > files of linux-3.6 to linux-3.7rc1 and completed the building. Use AT LEAST 3.7 kernel but better would be to use 3.9-rc even. > Meanwhile i cannot find the source code of Foundation model. It is closed source propertiary software. > Now, i want to ask for help. For example: how to build arm64 kernel > which can be downloaded from www.kernel.org(linux-3.8.tar.gz) Same way as you build older one. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ANN] snapshots.linaro.org migrated to Linaro Cloud
W dniu 29.04.2013 10:21, Paul Sokolovsky pisze: > by our Continuous Integration systems, has been migrated to Linaro > EC2 Cloud, managed by our IT team. So uploads from Jenkins should be faster now? YAY! ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Changes in Linaro layers for OpenEmbedded
NOTE: I skipped "openembedded-devel" ML cause most of users of Linaro layers also read OE Core ML. As I will leave Linaro at the end of May I would like to write some kind of summary of current state of Linaro layers for OpenEmbedded. At Linaro we have 3 layers: 1. meta-aarch64 2. meta-linaro 3. meta-linaro-toolchain First one is BSP kind. I know that it had some issues which affected each build which had it in BBLAYERS but I fixed those issues. I would like to thank Khem Raj for pointing me at those. We have git version of binutils there due to some changes which were not present in 2.23 line. But use of this version is not required as builds are fine with OE Core one. We have "tune-armv8.inc" in this layer as well. There was attempt to merge that into OE Core but "/lib or /lib64" discussion started and at that time I decided to skip it. There are similar discussions at GCC and Glibc mailing lists. Once they sort that out OE tune file will be adapted by someone (I hope). Rest of recipes can be split into 2-3 types. Few (like sysprof, emacs) just disable recipes for AArch64. Other have extra patches to add missing functionality or defines. And we have Linaro kernel for AArch64 there. Second layer contains ARMv7a(b) machine definitions used for our machine independent builds and some recipes. There are no patches for OE recipes here. The only exception is busybox where we enable "dpkg(-deb)" command which we need for our tools used to merge rootfs with hardware support. We have "recipes-extra" where we keep new recipes which may not be in a nicest state so are not yet merged into OpenEmbedded (or have no use there like "meta-toolchain-hhvm" one). "recipes-linaro" is for our stuff. Images, automatic root shell on serial port etc. And last but not least is toolchain layer. Everything here is related to gcc-linaro and Linaro binary cross toolchains (armv7a and aarch64 ones). GCC 4.6 and 4.7 is there but 4.6 one will be removed when 4.8 will be added into OE Core. Who will maintain those layers after my leave? This was not decided yet. There are few guys at Linaro who know how to use OpenEmbedded but most of them is outside of Builds and Baselines team. If you have any questions then better ask now. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [OE-core] Changes in Linaro layers for OpenEmbedded
W dniu 09.05.2013 20:42, Trevor Woerner pisze: > On Thu, May 9, 2013 at 12:57 PM, Marcin Juszkiewicz > wrote: >> Who will maintain those layers after my leave? This was not decided >> yet. There are few guys at Linaro who know how to use OpenEmbedded >> but most of them is outside of Builds and Baselines team. > To me this implies that these layers and this effort of yours isn't > part of any "official" Linaro build process/procedure. Would this > assumption be correct? No. First Linaro layer for OpenEmbedded was created by Ken Werner from Toolchain Working Group as they considered OE as a test tool. Then AArch64 bootstrap was needed so I stepped in and took maintenance of it (Ken was not at Linaro at that time), added meta-aarch64, cleaned up etc. Those layers are used as part of official Linaro build process. All AArch64 rootfs images are built using OpenEmbedded. Note that this excludes kernels which (for some reasons) were cross built as Ubuntu packages. At Linaro we have many teams and some of them are using OpenEmbedded or will do it soon. One of reasons is lack of ARM big-endian distributions on a market. Look at numbers from "git shortlog": Marcin Juszkiewicz (341): Ken Werner (28): Riku Voipio (17): Khem Raj (7): Ricardo Salveti de Araujo (5): Fathi Boudra (2): Ken is not at Linaro, Khem never was and those commits are fixes from him, Ricardo is back at Canonical. Riku has OE knowledge but also lot of other duties. And so far only OpenSUSE has packages for AArch64 mass built while all Linaro tools were made for Ubuntu repositories... ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [OE-core] Changes in Linaro layers for OpenEmbedded
W dniu 10.05.2013 14:20, Paul Sherwood pisze: > On 10/05/2013 13:00, linaro-dev-requ...@lists.linaro.org wrote: >> At Linaro we have many teams and some of them are using >> OpenEmbedded or will do it soon. One of reasons is lack of ARM >> big-endian distributions on a market. > > I don't normally comment here, but I'm confused by the above > statement... why does lack of big-endian distributions lead Linaro to > use OpenEmbedded? Debian, Fedora, OpenSUSE, Ubuntu - none of them has big-endian ARMv7a support which we could use as source of binary packages. > fwiw we believe that Baserock is currently the only commercial ARM > big-endian solution, but arguably baserock is not exactly a > "distribution". >From Baserock website: "Welcome to the Baserock open source project. Baserock aims to be a great way to build appliance systems with Linux. The current releases target x86_32 and x86_64 for ease of development, but we're working on support for ARM based devices as well" "we're working on support for ARM based devices as well" does not convince me to try yet-another-build-system. I saw too many of them during last few years and some of them disappeared after a year. I use OpenEmbedded because I know it and we have other engineers at Linaro familiar with it. It can build whatever combination of ARM (v4-v8) with many tuning combinations and already covers our needs when it comes to source packages. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Hwpacks for OE builds?
W dniu 23.05.2013 12:00, Riku Voipio pisze: > It's not a big deal since LAVA started supporting prebuilt images. For > ARMv8 the only problem I had is that LAVA digs some files from the > rootfs partition, and due to hwpack/linaro-media-create LAVA expects > the rootfs to be the second partition, while the OE image doesn't have > a partition table. We can switch OE to generate same style images as linaro-media-create does but it was never a priority. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
State of cross compiler packages
I think that it is easier to describe situation in email then on irc. Currently there are 4 packages related to cross compilation support: - armel-cross-toolchain-base (a-c-t-base in short) - gcc-4.4-armel-cross - gcc-4.5-armel-cross - gcc-defaults-armel-cross Each of them got into archive but they need to be updated to get installable packages. Status of each package: 1. a-c-t-base is at 1.47 in archive and was built from gcc-4.5-source 4.5.1-6ubuntu1 version. This package is used to bootstrap armel cross toolchain and generates: - binutils-arm-linux-gnueabi (from binutils-source) - libc6(-dev,-dbg)-armel-cross (from eglibc-source) - linux-libc-dev-armel-cross (from linux-source-2.6.35) - gcc-4.5-arm-linux-gnueabi-base, libgcc1(-dbg)-armel-cross (from gcc-4.5-source) libgcc1* packages have /usr/share/doc/ directories as symlinks to /usr/share/doc/gcc-4.5-arm-linux-gnueabi-base/ I have a version which does not provide gcc-4.5-arm-linux-gnueabi-base package, libgcc(-dbg)-armel-cross depends on gcc-4.5-base and have /usr/share/doc/ directories pointing into gcc-4.5-base one. Need to fix this symlink by providing those files in libgcc1 package instead. 2. gcc-4.4-armel-cross is at 1.36 in archive and was built with gcc-4.4-source 4.4.4-14ubuntu4 version. This package provides compilers, libstc++6-4.4-(dev,dbg,pic)-armel-cross, libmudflap0-4.4-dev-armel-cross and gcc-4.4-arm-linux-gnueabi-base packages. I have 1.38 version ready to upload which fixes #637454 #640298 bugs. 3. gcc-4.5-armel-cross is at 1.35 in archive and was built with gcc-4.5-source 4.5.1-7ubuntu1 version. This package provides compilers and runtime libraries. But it does not provide libgcc1(-dbg)-armel-cross and gcc-4.5-arm-linux-gnueabi-base because they are in a-c-t-base source package. All resulting packages have /usr/share/doc/ directories pointing into gcc-4.5-arm-linux-gnueabi-base one which is policy violation. I have 1.37 version ready to upload which fixes #637454 #640298 bugs and provides gcc-4.5-arm-linux-gnueabi-base package so policy violation is removed. 4. gcc-defaults-armel-cross is at 1.3 in archive and does not require any changes. Main problem is that packages generated from gcc-4.5-source are split into two packages: armel-cross-toolchain-base (libgcc1(-dbg)-armel-cross) and gcc-4.5-armel-cross (all the rest). This was required to allow to bootstrap cross compiler but gives problems when one is built with other version of gcc-4.5-source then other - resulting packages are not installable (we have it now in archive). It is also a thing which Matthias does not like and I understand it. For now my only solution is to build both with one version of gcc-4.5-source. What are your opinions? http://marcin.juszkiewicz.com.pl/download/ubuntu/ is download link for mentioned versions. Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: State of cross compiler packages
Dnia czwartek, 16 września 2010 o 22:35:30 Steve Langasek napisał(a): > On Thu, Sep 16, 2010 at 06:19:28PM +0200, Marcin Juszkiewicz wrote: > > 1. a-c-t-base is at 1.47 in archive and was built from gcc-4.5-source > >I have a version which does not provide gcc-4.5-arm-linux-gnueabi-base > >package, libgcc(-dbg)-armel-cross depends on gcc-4.5-base and have > >/usr/share/doc/ directories pointing into gcc-4.5-base one. Need to > >fix this symlink by providing those files in libgcc1 package instead. done in 1.48 > I'm not really in favor of pointing at gcc-4.5-base, because I think > ultimately we want the version number of the binary packages to be able to > tell us at a glance what version of a-c-t-b they came from, and we want the > changelogs to give information about changes to the a-c-t-b packaging and > not just information about the gcc-4.5 source package. Dropping > gcc-4.5-arm-linux-gnueabi-base and symlinking to gcc-4.5-base instead moves > us away from that goal because it leaves us with no place to ship the > a-c-t-b changelog. > > This isn't a blocker, and if we're doing multiarch next cycle it should go > away because we don't need libgcc1-cross any more; this is just my soft > impression. But ideally, yes, these files would be shipped in the > libgcc1-armel-cross package instead of pointing at gcc-4.5-base. 1.48 version has it sorted. > > 2. gcc-4.4-armel-cross is at 1.36 in archive and was built with > Bug #637454 is a low-priority bug which currently only has the affect on > armel of pulling in redundant build-dependencies. We would be fine to not > fix that in maverick - but if you have the fix available, I'm also happy to > review that. > > Bug #640298 is a fix that we pretty obviously need in for these packages to > be useful in maverick. In cases such as this, please upload directly to > the freeze queue! There's no need for review by email for such a > straightforward and high-priority bugfix. 1.40 ready for upload > > 3. gcc-4.5-armel-cross is at 1.35 in archive and was built with > > > >gcc-4.5-source 4.5.1-7ubuntu1 version. This package provides > >compilers and runtime libraries. But it does not provide > >libgcc1(-dbg)-armel-cross and gcc-4.5-arm-linux-gnueabi-base because > >they are in a-c-t-base source package. All resulting packages have > >/usr/share/doc/ directories pointing into > >gcc-4.5-arm-linux-gnueabi-base one which is policy violation. > > > >I have 1.37 version ready to upload which fixes #637454 #640298 bugs > >and provides gcc-4.5-arm-linux-gnueabi-base package so policy > >violation is removed. > > But you're only moving the policy violation from one package to the other: > you say that the binary packages from a-c-t-b will have to point across > source packages to gcc-4.5-base, which is the same policy violation in a > different package. 1.38 has it solved > > Main problem is that packages generated from gcc-4.5-source are split > > into two packages: armel-cross-toolchain-base > > (libgcc1(-dbg)-armel-cross) and gcc-4.5-armel-cross (all the rest). > > This was required to allow to bootstrap cross compiler but gives > > problems when one is built with other version of gcc-4.5-source then > > other - resulting packages are not installable (we have it now in > > archive). It is also a thing which Matthias does not like and I > > understand it. For now my only solution is to build both with one > > version of gcc-4.5-source. > > Well, I think this is a red herring anyway. Pointing at gcc-4.5-base > should *also* mean uninstallability when you have out-of-sync versions, > because we should be pointing at the matching version to ensure the > correct changelog; and more importantly, we need to have all of these > packages built from the matching version of gcc-4.5-source at release > time, to ensure we're complying with GPL provisions regarding source code > availability. Having out-of-sync packages turn up as uninstallability > problems every time is inconvenient for the user trying to track the devel > release, but it's also a very pointed reminder to rebuild the packages - a > reminder that we won't accidentally overlook. > > I appreciate that Matthias may not like the frequent uninstallability of > these packages, but license compatibility is a higher concern. And > besides, while I am grateful for Matthias's help sponsoring these > cross-compiler packages into the archive, it's not his responsibility to > maintain them, it's ours - so if we have to step up our game to keep the > packages usable in the face
Re: Weekly Linaro image testing
Dnia poniedziałek, 27 września 2010 o 22:56:10 Jamie Bennett napisał(a): > As an experiment, we will be setting up the Linaro qatracker each Thursday > morning, UTC, with the information for that days images. If you find it > useful, please report your testing results at: > > http://qatracker.linaro.org/ Would be nicer if system would send mails after registration. Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Weekly Linaro image testing
Dnia czwartek, 30 września 2010 o 15:15:43 Marcin Juszkiewicz napisał(a): > Would be nicer if system would send mails after registration. Got email, filled report against headless on beagleboard C3. Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Armel cross compilers for lucid
Hi I finally built armel cross compiler packages for Ubuntu 10.04 'Lucid' LTS. They are available in unsigned APT repository: deb http://people.canonical.com/~hrw/ubuntu-lucid-armel-cross-compilers/ ./ They are built from Maverick packages: - binutils-source - eglibc-source - gcc-4.4-source - gcc-4.5-source - linux-source-2.6.35 - armel-cross-toolchain-base - gcc-4.4-armel-cross - gcc-4.5-armel-cross So they do not give exactly same versions as compilers used in 10.04 - please remember about it while doing cross builds. Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Armel cross compilers for lucid
Dnia poniedziałek, 4 października 2010 o 14:17:36 Tim Gardner napisał(a): > Is there any reason not to get these packages in universe ala Maverick? > I'm finding the Maverick packages to be real handy for cross compiling > ARM stuff, but Lucid will be around for a lot longer. Those packages require lot of backporting to be done properly for Lucid. Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Flavoured toolchains anyone?
Some of Linaro developers works with ARM devices older then ARMv7-a architecture. Other people experiments with hard-float ABI. Each of them has to rebuild toolchain for own use and that means playing with components to have them build properly. But it is no more - I made some patches and armel-cross-toolchain-base since 1.53 version + newer source packages for gcc-4.[45]-armel-cross have support for "debian/flavour" file which allows to set some flags related to toolchain build. So far supported things are: - ARM architecture - float ABI - FPU mode - Thumb mode This feature is not merged into regular Ubuntu packages yet as this is work in progress which needs to be cleaned first. http://people.linaro.org/~hrw/armel-cross-toolchain/ has all source packages needed. Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Flavoured toolchains anyone?
Some of Linaro developers works with ARM devices older then ARMv7-a architecture. Other people experiments with hard-float ABI. Each of them has to rebuild toolchain for own use and that means playing with components to have them build properly. But it is no more - I made some patches and armel-cross-toolchain-base since 1.53 version + newer source packages for gcc-4.[45]-armel-cross have support for "debian/flavour" file which allows to set some flags related to toolchain build. So far supported things are: - ARM architecture - float ABI - FPU mode - Thumb mode This feature is not merged into regular Ubuntu packages yet as this is work in progress which needs to be cleaned first. http://people.linaro.org/~hrw/armel-cross-toolchain/ has all source packages needed. Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: nano-headless
Dnia poniedziałek, 8 listopada 2010 o 09:36:52 Arnd Bergmann napisał(a): > I've had a few conversations at Plumbers Conf about the new "yocto" > project of the Linux Foundation. I think going to the really small > sizes (certainly below 64 MB), it would be much easier to build on > this than the Ubuntu archive. > The yocto folks are very interested in using the Linaro kernel and tool > chain to build their images for ARM, at least as one of the options. > > Having a yocto-headless image below a nano-headless image seems to also > fit in with the naming ;-) If we will decide to work on Yocto Project then I would like to be one of such persons due to fact that I am OpenEmbedded developer since 2004 and developed Poky in 2007-2009 (as part of main development team in 2007-2008 and as one of main contributors in 2008-2009). Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: QT4 and atomics
Dnia niedziela, 14 listopada 2010 o 23:26:46 Michael Hope napisał(a): > Hi there. I've been looking into updating the QT4 atomic operations > as an alternative to working around it in GCC. There's ARM specific > code in: > There are bigger problems here though: > * There's code in corelib/arch/armv6/qatomic*.c that may also being used > * qatomic_armv6.h includes code for RVCT which should be updated for > Thumb-2 by someone > * The code may not work on multi-processor systems like Panda due to > the lack of DMB instructions This is also tracked in https://bugs.launchpad.net/ubuntu/+source/qt4- x11/+bug/490371 Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: QT4 and atomics
Dnia niedziela, 14 listopada 2010 o 23:26:46 Michael Hope napisał(a): > Hi there. I've been looking into updating the QT4 atomic operations > as an alternative to working around it in GCC. There's ARM specific > code in: > There are bigger problems here though: > * There's code in corelib/arch/armv6/qatomic*.c that may also being used > * qatomic_armv6.h includes code for RVCT which should be updated for > Thumb-2 by someone > * The code may not work on multi-processor systems like Panda due to > the lack of DMB instructions This is also tracked in https://bugs.launchpad.net/ubuntu/+source/qt4- x11/+bug/490371 Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] Packaging for PowerDebug (a new tool)
Dnia wtorek, 16 listopada 2010 o 12:46:39 Amit Arora napisał(a):
> As part of the Power Management Work Group, I have been developing a
> new tool called PowerDebug which can show users/developers information
> on regulators, senors and clock tree. Its time now to package it for
> Ubuntu (since, Linaro will pick up the package from Ubuntu repo.). We
> also plan to host a project in LaunchPad for this tool.
> I am new to Ubuntu and debian way of packaging. Still, have given a
> shot at packaging PowerDebug and have put it in my git tree hosted at
>
> : git://git.linaro.org/people/amitarora/powerdebug.git in the branch
>
> called "debian". The "master" branch has only the source code for the
> tool.
> If you have fare idea about .deb packaging, I will request you to
> please review these files and suggest any changes that may be
> required. I have also uploaded this under my ppa
> (ppa:amitarora/pm-utils).
I had a look at packaging. My changes are small and nearly cosmetic:
23:02 h...@home:powerdebug$ git diff
diff --git a/debian/changelog b/debian/changelog
index 9b8774e..feadc7f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,4 +1,5 @@
powerdebug (0.5) maverick; urgency=low
+
* Fix coding style issues and some more cleanups
* Discover debugfs mount point and remove hard coded path
* Display clock tree in ncurses mode using in-memory data structures
@@ -6,6 +7,7 @@ powerdebug (0.5) maverick; urgency=low
-- Amit Arora Tue, 16 Nov 2010 16:24:07 +0530
powerdebug (0.4) maverick; urgency=low
+
* Read clocks into memory and add dump support
* Show all regulators and clocks by default
* Discover debugfs mount point at runtime
I do not know does empty line after version is required but most of packages
which I was working with had them. It also makes changelogs easier to read.
diff --git a/debian/control b/debian/control
index 311a527..d69f6ed 100644
--- a/debian/control
+++ b/debian/control
@@ -2,13 +2,13 @@ Source: powerdebug
Section: utils
Priority: optional
Maintainer: Amit Arora
-Build-Depends: cdbs, debhelper (>= 7), libncursesw5-dev, libncurses5-dev
-Standards-Version: 3.8.4
-Homepage:
+Build-Depends: cdbs, debhelper (>= 7), libncurses5-dev
+Standards-Version: 3.9.1
Package: powerdebug
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
-Description: This tool displays regulator, sensor and clock information.
- PowerDebug refreshes this information every few seconds. You can
- also use dump option to display the information just once.
+Description: tool to display regulator, sensor and clock information
+ PowerDebug is a tool to display regulator, sensor and clock information.
+ Information are refreshed every few seconds. You can also use dump option to
+ display the information just once.
1. libncursesw5-dev build time dependency is bogus - you link with "-lncurses"
which I think is fine until you will get CJKV translation.
2. Homepage got dropped, but if there is any then add it.
3. Standards-version 3.8.4 is old and lintian complains about it.
4. Description does not have to be a sentence. And some tools shows only
extended one so there is a bit of repeating...
5. Consider syncing README with debian/control - descriptions in both differ.
Regards,
--
JID: h...@jabber.org
Website: http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Situation of armel cross compiler in Ubuntu
Hi During Ubuntu 'natty' cycle I am working on backporting armel cross compiler to 10.04 'lucid' and 10.10 'maverick' releases. I have a spec [1] for it and go though steps. Cross compiler is built from two source packages: armel-cross-toolchain-base and gcc-4.5-armel-cross. There are two additional ones: gcc-4.4-armel-cross (may be dropped when gcc 4.6 get released) and gcc-defaults-armel-cross. For now 'natty' is using same versions as maverick but I am working [2][3][4] on updates. Next step is to get rid of update-alternatives use from packages as this is what gcc-defaults-armel-cross has to do. I have new version of this package ready [5] but it has to wait until I will drop u-a from toolchain packages (this can be tracked in bug 676454). Then next step will be providing backports for lucid and maverick releases. For now I have unsigned manually created repository for lucid [6]. Maverick has small update (in proposed) which fixes few bugs. To make backports I need first to patch all components (binutils, eglibc, gcc-4.5, linux) to have a way to build just *-source package from them (who wants libc6 upgrade in LTS?). I have patches [7][8][9][10] for it. I also need advice how to provide backported cross compiler packages. For now there are two ways: - Linaro maintainers PPA - ubuntu-backports repository First one requires less work as there is no cooperation required with Ubuntu backports team [11]. And there will be usually monthly updates as Linaro has montly releases which are taken by Ubuntu packaging (during development cycle) This week I will test lucid/maverick/natty builds of recent cross compiler and can provide packages for testing (no warranty that it works). Where do I need help: - review my gcc-4.[45]-armel-cross branches - review my patches in [7][8][9][10] - test my packages 1. https://blueprints.launchpad.net/ubuntu/+spec/other-linaro-n-cross- compilers 2. https://code.launchpad.net/~hrw/ubuntu/natty/gcc-4.4-armel-cross/1.37-for- review/+merge/41582 3. https://code.launchpad.net/~hrw/ubuntu/natty/gcc-4.5-armel-cross/1.41-for- review/+merge/41583 4. https://code.launchpad.net/~hrw/ubuntu/natty/armel-cross-toolchain- base/1.53-fixed/+merge/41577 5. https://code.launchpad.net/~hrw/ubuntu/natty/gcc-defaults-armel-cross/use- proper-symlinks/+merge/41040 676454. https://bugs.launchpad.net/ubuntu/+source/gcc-4.4-armel- cross/+bug/676454 6. https://wiki.linaro.org/WorkingGroups/ToolChain/CrossCompilerOnLucid 7. https://bugs.launchpad.net/ubuntu/+source/gcc-4.4/+bug/682650 8. https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/682648 9. https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/682646 10. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/682681 11. https://help.ubuntu.com/community/UbuntuBackports Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v2 2/3] ARM: omap4: Correct definition of do_wfi() forCONFIG_THUMB2_KERNEL
Dnia wtorek, 7 grudnia 2010 o 17:50:50 Dave Martin napisał(a): > You can't built a kernel for pre-v7 platforms with > CONFIG_THUMB2_KERNEL: the code can't run on those platforms because > they don't support Thumb-2. > > So anything inside #ifdef CONFIG_THUMB2_KERNEL can assume v7/Thumb-2 > capable (and hence reasonably new) tools. Wasn't Thumb2 available in arm1176 cores? So it would be v6 too. Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Freescale Linux BSP review
Dnia niedziela, 12 grudnia 2010 o 21:45:37 Linus Walleij napisał(a): > Is the AMD GPU exposing all functionality in its kernel driver or > is there some userspace blob somewhere with lots of e.g. GL > goodies? There is libgsl.so which do glue between kernel and X11 driver. closed source. Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Freescale Linux BSP review
Dnia wtorek, 14 grudnia 2010 o 03:35:20 Eric Miao napisał(a): > > I think it is beneficial for us to integrate the kernel part into our > > Linaro tree, so that we can build/use it together with the kernel image. > > As for the user space libraries, how about adding them into the hwpack? > > (Is there any legal issue for this?) > > I think so, there's normally a rule if free redistribution is allowed > or not, even it's closed source. Binary is named libgsl.so and conflicts with GNU Scientific Library package. I noticed it ~month ago when played with 2d/3d acceleration for EfikaMX Smartbook (i.mx515) and shared that info with Genesi (vendor of netbook). They sent that information to Freescale so library will be renamed. Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
ARM cross compiler backport available for Lucid and Maverick
I would like to announce new Linaro PPA available for all users of Ubuntu 10.04 Lucid and 10.10 Maverick releases: https://launchpad.net/~linaro-maintainers/+archive/toolchain What is inside? Packages with current (gcc-linaro 2011.01-1 based on 4.5.2 release) cross toolchain backported from Ubuntu 11.04 Natty. Please test them and report any problems. Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: ARM cross compiler backport available for Lucid and Maverick
Dnia wtorek, 18 stycznia 2011 o 12:36:33 Marcin Juszkiewicz napisał(a): > I would like to announce new Linaro PPA available for all users of Ubuntu > 10.04 Lucid and 10.10 Maverick releases: > > https://launchpad.net/~linaro-maintainers/+archive/toolchain > > What is inside? Packages with current (gcc-linaro 2011.01-1 based on 4.5.2 > release) cross toolchain backported from Ubuntu 11.04 Natty. Please test > them and report any problems. As some people already noticed - packages with libraries are not installable due to repeated "Provides" line in package control data. I found issue and tomorrow new packages will be available. Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: ARM cross compiler backport available for Lucid and Maverick
Dnia środa, 19 stycznia 2011 o 12:20:02 Michael Opdenacker napisał(a): > We now recommend these packages in my company's embedded Linux training > materials. See p. 25 of http://free-electrons.com/doc/toolchains.pdf > (and correct me if I wrote anything wrong!). Since maverick Ubuntu users do not need to use external repositories to get cross toolchain. This PPA provides binaries of current (natty) cross toolchain for lucid (which lacked them) and maverick (which has older version). Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: ARM cross compiler backport available for Lucid and Maverick
Dnia wtorek, 18 stycznia 2011 o 18:26:17 Marcin Juszkiewicz napisał(a): > Dnia wtorek, 18 stycznia 2011 o 12:36:33 Marcin Juszkiewicz napisał(a): > > I would like to announce new Linaro PPA available for all users of Ubuntu > > 10.04 Lucid and 10.10 Maverick releases: > > > > https://launchpad.net/~linaro-maintainers/+archive/toolchain > > > > What is inside? Packages with current (gcc-linaro 2011.01-1 based on > > 4.5.2 release) cross toolchain backported from Ubuntu 11.04 Natty. > > Please test them and report any problems. > > As some people already noticed - packages with libraries are not > installable due to repeated "Provides" line in package control data. I > found issue and tomorrow new packages will be available. Sorry, I forgot to send update. PPA is operational now. During compilation of C++ files there can be warning: $ arm-linux-gnueabi-g++ hrm.cpp /usr/lib/gcc/arm-linux-gnueabi/4.5.2/../../../../arm-linux-gnueabi/bin/ld: warning: libc.so, needed by /usr/lib/gcc/arm-linux- gnueabi/4.5.2/libgcc_s.so.1, not found (try using -rpath or -rpath-link) Binary is created anyway. I plan to take a look at this. Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: New dial-in number for conference calls
Dnia poniedziałek, 24 stycznia 2011 o 17:45:04 Loïc Minier napisał(a): > The conference system for phone calls moved to new dial-in numbers this > week; the conf room numbers remain the same as well as leader pins, but > the dial in change; this is a non-exhaustive list: I hope that list will be expanded this week - there is no number for Poland and each operators which I use will rather charge me for international calls. Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: cpu supported
"Raffaele Recalcati" napisał: >Anyway, I'll go on with Openembedded for armv5. Good choice ;) You will get Linaro gcc 4.5 patches in OE by default. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Nice tool: chdist
Dnia niedziela, 20 lutego 2011 o 23:56:05 Michael Hope napisał(a): > I use from my Maverick host to grab the source packages from Natty > when trying to track down a bug. You can get same without it. Add "deb-src" for natty into sources.list(.d) and do apt-get update + apt-get source libc6/natty or apt-get source -t natty libc6 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Instructions for building Linaro GCC with crosstool-NG
Dnia 2011-03-10, czw o godzinie 14:28 +1300, Michael Hope pisze: > Linaro GCC is already available in a bunch of places including > OpenBricks, crosstool-NG, OpenEmbedded, OpenWRT, and (of course) > Ubuntu. I hope to write a short page on each so people know where to > find our toolchain in the distribution of their choice. In OpenEmbedded you just need to use gcc 4.5 to get Linaro changes. There are no 4.5.x versions available as Khem Raj maintains this version as SVN snapshot + (OE + Linaro) patches. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Cross toolchain source packages status
Ubuntu/natty got some cross toolchain updates recently so it is installable again. This gave me some free time to work on improvements. And this mail is an attempt to summary it and to provide some ideas/questions. = Introduction = During Emdebian sprint it was decided that my source packages will be used in Debian to provide cross toolchains for users in archive itself (as now Emdebian team autobuilds them into separate archive). We created crosstoolchain project [1] at Alioth and plan to keep Debian branches in git.debian.org repository [2]. = Existing branches = Speaking of branches - there are several ones in my git repository [3] and some of them are also present as Bazaar branches on Launchpad. This list follows: debian/experimental/armel-cross-toolchain-base debian/experimental/gcc-4.5-armel-cross debian/experimental/gcc-4.6-armel-cross debian/unstable/gcc-4.4-armel-cross Those ones can be used to provide cross toolchain for Debian. First one is really ugly as for now it contains a copy of eglibc and linux-2.6 packaging. I have to report few patches [4][5][6] for both components to get this situation sorted. GCC ones do not have any such problems. ubuntu/natty/armel-cross-toolchain-base ubuntu/natty/gcc-4.4-armel-cross ubuntu/natty/gcc-4.5-armel-cross Those ones will be soon sent for review/merge/upload into Ubuntu. ubuntu/not-used/gdb-armel-cross Superseeded by gdb-multiarch package - gdb 7.2-1ubuntu8 or newer required. ubuntu/ppa-backport/armel-cross-toolchain-base ubuntu/ppa-backport/gcc-4.5-armel-cross ubuntu/ppa-backport/patches Those branches are used to generate packages in Linaro toolchain backport PPA [7]. "/patches" branch keeps all patches which I use to alter components. = Status = During sprint I merged 3 branches of armel-cross-toolchain-base into one set of rules so today there are not differences between Ubuntu ones and Debian one contains extra debian/packaging directory with copies of eglibc/debian and linux-2.6/debian dirs. Generation of debian/control file is now inside of debian/rules so differences in build dependencies are handled. Switch between Ubuntu and Debian is sorted by using "lsb_release" (idea taken from gcc-4.5) and PPA build can be enabled by "touch debian/ppa". = Ideas = There was idea to generate just one source package from this (so it would be debian/experimental/armel-cross-toolchain-base branch) and generate all versions from it. I think that this will work but first we need to get Debian version into state which will be acceptable for inclusion into archive. = Problems = Main problem is debian/packaging/ directory in Debian version. I need review of [4] patch and then will report a bug against eglibc. = Multiarch versions (future) = When cross build dependencies will be working then we will get rid of armel-cross-toolchain-base package and replace it with binutils-armel-cross (or extend binutils-multiarch to contain "as" and rest of missing binaries). 1. http://alioth.debian.org/projects/crosstoolchain/ 2. http://git.debian.org/?p=collab-maint/cross-toolchain.git;a=summary 3. http://git.linaro.org/gitweb?p=people/hrw/cross-toolchain-packaging.git;a=summary 4. http://42.pl/u/2zj4 5. http://42.pl/u/2zj5 6. http://bugs.debian.org/611382 (merged into http://bugs.debian.org/550776 one) 7. https://launchpad.net/~linaro-maintainers/+archive/toolchain ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making linaro-nano smaller or Give Up Disk Space for Lent
Dnia 2011-03-10, czw o godzinie 17:43 +0100, Loïc Minier pisze: > I think there is a way for APT to keep compressed versions of these > files; it's the Acquire::GzipIndexes option And all those files can be recreated by APT when needed so there is no need to keep them in image which has to be really minimal. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: ARM cross compiler backport available for Lucid and Maverick
Dnia 2011-01-21, pią o godzinie 16:44 +0100, Marcin Juszkiewicz pisze: > > > I would like to announce new Linaro PPA available for all users of Ubuntu > > > 10.04 Lucid and 10.10 Maverick releases: > > > > > > https://launchpad.net/~linaro-maintainers/+archive/toolchain > > > > > > What is inside? Packages with current (gcc-linaro 2011.01-1 based on > > > 4.5.2 release) cross toolchain backported from Ubuntu 11.04 Natty. > > > Please test them and report any problems. PPA got updated to following components: - eglibc 2.13-0ubuntu4 - binutils 2.21.0.20110302-1ubuntu1 - gcc 4.5.2-5ubuntu2 - gdb 7.2-1ubuntu9 - gcc-defaults-armel-cross 1.4 Users of Lucid and Maverick editions can now cross compile applications for ARM targets running Natty. To install cross compilers you can use "apt-get install gcc-arm-linux-gnueabi" command. Replace gcc with g++, gfortran, gobjc, gobjc++ if you need any of those languages. To debug your cross binaries please install gdb-multiarch as it knows how to handle ARM code properly. Please report any problems against "armel-cross-toolchain-base" and "gcc-4.5-armel-cross" packages at launchpad. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Getting rid of update-alternative in cross toolchain packages
Some time ago I looked at cross toolchain packages to find how they handle installation of several versions at same time. It was done by using 'update-alternatives' tool and was broken. We fixed it during Ubuntu/Maverick cycle but "u-a" is still in use (just versions are used now to take care of priority so latest gcc is default one). But this is different then native gcc which is selected by gcc-defaults package - /usr/bin/gcc is symlink to /usr/bin/gcc-DEFAULTVERSION (where DEFAULTVERSION value depends on architecture and distribution). Ok, we have gcc-defaults-armel-cross in Ubuntu but it takes care only of depending on default versions of cross toolchain components. I filled a bug [1] about it and discussed it with Matthias Klose. The proper way would consists those steps: - new cross packages will use "u-a remove" to get rid of old alternative stuff (in postinst and prerm) - new gcc-defaults-armel-cross package will provide /usr/bin/arm-linux-gnueabi-APP symlinks - new gcc-defaults-armel-cross will also conflicts with older versions of cross toolchain packages Getting rid of symlinks was accepted during Emdebian sprint so such change will be done in gcc-4.[3456] source packages. gcc-defaults for other cross architectures then armel will need to be done for Emdebian. What do you think about such plan? 1. https://bugs.launchpad.net/bugs/676454 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH] dpkg-cross: handle multi-arch packages too
Hi
Ubuntu 'natty' switched to multiarch recently and my cross toolchain
packages started to fail to build. Most of problems were fixed but then
dpkg-cross hit us.
Today I looked at dpkg-cross and made attached patch to handle problem.
What patch does is converting multiarch packages into old style ones.
There is no extra switch like "--force-even-when-multiarch" and
"--convert-anyway -A" is used instead. This is change against latest CVS
code (dpkg-cross r1.83).
>From my tests it looks like it does proper job.
Index: dpkg-cross
===
RCS file: /cvsroot/dpkg-cross/dpkg-cross/dpkg-cross,v
retrieving revision 1.83
diff -u -r1.83 dpkg-cross
--- dpkg-cross 23 Feb 2011 14:46:33 - 1.83
+++ dpkg-cross 23 Mar 2011 14:32:35 -
@@ -507,7 +507,7 @@
}
close(CONTROL);
- if (defined ($control{'multi-arch'})) {
+ if (defined ($control{'multi-arch'}) and !$anyway) {
my $output = basename ($package);
warn sprintf(_g("%s: Skipping the '%s' Multi-Arch package.\n"), $progname, $output);
if (not -f $output) {
@@ -775,6 +775,16 @@
} elsif ((m:^/emul/ia32-linux/usr/lib/([^/]+\.[ao])$:)) {
# regular .a or .o file under /emul/ia32-linux/ for #463588
link_file("$src$_", "$dst$crosslib32/$1") or goto fail;
+ } elsif (m:^(/usr)?/lib/$crosstype/([^/]+\.[ao])$:) {
+ # regular .a or .o file under /lib or /usr/lib/TRIPLET/
+ link_file("$src$_", "$dst$crosslib/$crosstype/$2") or goto fail;
+ } elsif (m:^(/usr)?/lib/$crosstype/([^/]+\.so[^/]*)$:) {
+ # regular .so* file under /lib/TRIPLET or /usr/lib/TRIPLET
+ if (is_ldscript("$src$_")) {
+fix_ldscript("$src$_", "$dst$crosslib/$crosstype/$2") or goto fail;
+ } else {
+link_file("$src$_", "$dst$crosslib/$crosstype/$2") or goto fail;
+ }
} elsif (m:^(/usr(/X11R6)?)?/lib/([^/]+\.so[^/]*)$:) {
# regular .so* file under /lib, /usr/lib or /usr/X11R6/lib
if (is_ldscript("$src$_")) {
@@ -914,7 +924,18 @@
# useful or packaged in the -cross package, basically anything
# in a directory beneath /usr/lib/. See #499292
# except pkgconfig symlinks, see #506956
- next if (($lv =~ m:$crosslib/.*/:) and ($lv !~ m:$crosslib/pkgconfig/:));
+ # also handle multiarch packages with /usr/lib/TRIPLET/ directory
+ next if (
+ (
+ ($lv =~ m:$crosslib/$crosstype/.*/:) and
+ ($lv !~ m:$crosslib/$crosstype/pkgconfig/:)
+ ) or
+ (
+ ($lv =~ m:$crosslib/.*/:) and
+ ($lv !~ m:$crosslib/pkgconfig/:) and
+ ($lv !~ m:$crosslib/$crosstype/:)
+ )
+ );
$lv =~ m:$crosslib/(.*)$:;
# Translators, retain the -> to indicate the direction of the link.
printf (_g("Creating symlink %s -> %s\n"), $_, $1) if ($verbose >= 2);
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Anyone has idea of this - http://www.openbricks.org/?
Dnia 2011-04-07, czw o godzinie 16:36 +0100, Wookey pisze: > +++ Eric Miao [2011-04-07 23:13 +0800]: > > It looks like openwrt, though not sure how much they have done. > > Anyone has any insight? > Openbricks has evolved from the geexbox project, which was an > extremely slick mini-distro for loading itself into RAM and watching > DVDs back in about 2004ish. The build-system was well-engineered even > back then. > > It seems that they have realised they had quite a nice build system so > they have split that out and made it into a project. The main > developer gave a talk at FOSDEM ths year. I attended that talk too. For me it looks like Yet Another Build System and I do not see great future for them - last time I checked it was still geexbox + just few addons to make it not look like 'lets build media center from sources instead of packages'. > I'm not sure that the world actually needs any more embedded build > systems based on kbuild (ptxdist, buildroot, yocto, openembedded is > probably sufficient), OpenEmbedded and Yoctoproject are not kbuild based - we wrote own tools ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Panda boards and 1GB of RAM.
Dnia 2011-04-27, śro o godzinie 17:45 +0100, Ramana Radhakrishnan pisze: > Please note that the cmdline I have at the minute has the following line : > > mem=456M@0x8000 mem=512M@0xA000 > > Thus I would expect there to be atleast 968M of RAM rather than just 662M ! hrw@panda:~$ cat /proc/cmdline ro elevator=cfq vram=32M mem=463M@0x8000 mem=512M@0xA000 fixrtc rootwait root=/dev/sda3 console=ttyO2,115200 console=tty1 hrw@panda:~$ free -m total used free sharedbuffers cached Mem: 921865 55 0476 117 -/+ buffers/cache:271649 Swap:0 0 0 hrw@panda:~$ head /proc/meminfo MemTotal: 943112 kB MemFree: 59924 kB Buffers: 483868 kB Cached: 120564 kB SwapCached:0 kB Active: 348128 kB Inactive: 330912 kB Active(anon): 75292 kB Inactive(anon): 708 kB Active(file): 272836 kB hrw@panda:~$ [0.00] Reserving 33554432 bytes SDRAM for VRAM [0.00] Memory: 463MB 480MB = 943MB total [0.00] Memory: 934628k/934628k available, 63772k reserved, 229376K highmem Where 22MB vanished? No idea. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Help on general file sharing
Dnia 2011-04-29, pią o godzinie 15:23 +0800, Shawn Guo pisze: > I have one 35MB tarball to share with Linaro folks. It's too big to > distribute through email. Is there any infrastructural solution for > such general file sharing purpose? (The launchpad PPA is for package > than general file sharing, and I do not want to bother.) Thanks. Dropbox? UbuntuOne? ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Linaro Ubuntu/Android LEB Star rating documentation blueprint
Hi As some of you know we have something called "Star rating" for supported boards. There are [1][2][3] pages on Linaro wiki which can be used as kind of base for understanding what is all about. We need to discuss what exactly our requirements mean and how to check are they supported - for that I have a blueprint [4] when we can gather and talk about it. Would be nice to have people from working groups and landing teams there as you guys know best what is to be supported and what is done already. 1. https://wiki.linaro.org/Cycles/1105/BoardSupportStatus 2. https://wiki.linaro.org/Platform/Requirements 3. https://wiki.linaro.org/Platform/Ubuntu/ReleaseCycle 4. https://blueprints.launchpad.net/ubuntu/+spec/linaro-platforms-o-ubuntu-leb-star-rating ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Display setups on your work desks
Hi I would like to ask about your display setups on work desks because recent changes in pandaboard kernel moves me into 'lets buy another lcd' direction... Now I have two displays on my desk: - 24" 1920x1080 - DVI port is main display of my desktop - VGA port was used with some boards in past - HDMI port was never used - 20" 1680x1050 - DVI (with HDMI->DVI adapter) is main display of pandaboard - VGA is secondary display of desktop or primary display of other (rarely used) PC But Pandaboard has two video outputs: DVI and HDMI. For most of time I used HDMI output but it was with Ubuntu 11.04 kernel. Now I am testing Linaro WIP kernel and it has working DVI output rather then HDMI one... Switching ports on panda requires powering it off in order to not damage it. Guessing which port works is not a way. Connecting panda HDMI to 24" HDMI is also no solution cause this will leave me without display for my desktop. How you people solve that in other way then buying yet-another-lcd? ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: approaching a final kernel for 11.05
Dnia 2011-05-18, śro o godzinie 12:31 -0600, John Rigby pisze: > Thanks to the heroic efforts of rsalveti the packaged > linux-linaro-omap kernel now greatly improved omap4 display > functionality. There is a .deb in the linaro-maintainers kernel ppa. > If you have a panda board and have time to try it out your feedback > would be much appreciated: > > https://launchpad.net/~linaro-maintainers/+archive/kernel/+files/linux-image-2.6.38-1003-linaro-omap_2.6.38-1003.4~ppa2_armel.deb root@linaro:/boot# flash-kernel Kernel /boot/vmlinuz-2.6.38-1003-linaro-omap does not match your subarchitecture omap4, therefore not writing it to flash. Anyway after booting status is: Good: - HDMI output works and sets screen according to EDID - DVI output sets 1280x960 (EDID: 1680x1050) - USB devices are recognized properly and work (mouse, keyboard) - SD gets 17MB/s read in hdparm Bad: - networking is totally broken - bug 785739 (ifconfig, 'ip addr', 'iwlist scan' hangs) - only 662MB ram available ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: OMAP3 IGEPv2: kworker/0:0:1030 blocked on latest snapshots
Dnia 2011-05-23, pon o godzinie 10:10 -0300, Christian Robottom Reis pisze: > Hi there, > > I'm playing around with the latest snapshots on my IGEPv2 and I'm > seeing a recurring message posted to the console while using it: > > [ 1561.340942] INFO: task kworker/0:0:1030 blocked for more than 120 > seconds. > [ 1561.350860] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > disables this message. > [ 1681.356597] INFO: task kworker/0:0:1030 blocked for more than 120 > seconds. > [ 1681.367187] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > disables this message. > > root@linaro:~# uname -a > Linux linaro 2.6.38-1002-linaro-omap #3-Ubuntu SMP Fri Apr 15 14:00:54 > UTC 2011 armv7l armv7l armv7l GNU/Linux > > I'd like to find out what that task is meant to be doing and why it is > getting blocked. I haven't been able to notice anything negative in my > use of the system (downloading and installing packages, editing files, > running cpuburn and stress). Same happens from time to time on PandaBoard. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The need for more verbose work item updates
Each time when I spoke with Launchpad team I got a feeling that blueprint part of it is unwanted child which no one want to talk about. Adding workitems as bug links allows to work around lack of history but they people which are subscribed to BP does not get updates from bugs. Anyone with permissions can edit whiteboard and there is no way to check changes in other way then go through emails which many people delete just after reading. I do not like this system but can accept it work. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Boot sanity testing of release candidate kernel
On czw, 2011-05-26 at 15:08 +0530, Jassi Brar wrote: > BTW, SDHC cards are SD cards with >2GB capacity. There are 4GB SD cards on market - very popular in WinCE based car navigation systems with lack of SDHC support. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Boot sanity testing of release candidate kernel
On czw, 2011-05-26 at 16:52 +0530, Jassi Brar wrote: > On Thu, May 26, 2011 at 4:24 PM, Marcin Juszkiewicz > wrote: > > On czw, 2011-05-26 at 15:08 +0530, Jassi Brar wrote: > > > >> BTW, SDHC cards are SD cards with >2GB capacity. > > > > There are 4GB SD cards on market - very popular in WinCE based car > > navigation systems with lack of SDHC support. > > IIRC official maximum size of SD was specified to be 2GB Who cares about specifications... ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 2 cross-development toochain quesions
On pią, 2011-06-03 at 16:02 +0100, Bernard Ogden wrote: > I was asked to take a look at the blueprints relating to > cross-toolchain development (e.g. > https://blueprints.launchpad.net/ubuntu/+spec/linaro-platforms-o-linaro-cross-toolchain-stories) > in advance of Monday's 'Android and Developer Platform' plan review > call. I just have two questions to ask for now: > 1) I would like confirmation that the Windows binaries will be > 'windows native' and standalone i.e. customer does not need to install > MSYS/cygwin/etc. I got the impression that this is the intention, but > am not 100% clear that it's a requirement. Did not yet checked which options exist. Probably mingw runtime will be used but my goal is to provide self-contained tarball. > 2) Will Linaro test the toolchains on Red Hat Enterprise? RHEL 5 is > one the supported platforms for DS-5, so it would be useful to know if > the toolchain will be validated on that platform, or if we need to > test ourselves. CentOS 5.6 is one of distributions which I have in VirtualBox locally. Tarball for this system will have to contain lot of native Ubuntu libraries probably or will have to find other way to build for it. > I'm also interested in how users get/work with sysroots, especially > for the Windows case, but I understand that that's an issue for a > future release cycle. For now it is /opt/linaro/gcc-DATE/sysroot/ where users can unpack one of sysroot tarballs they want. I built minimalistic one (libc6-dev) for now and it passed compilation of helloworld.c which was a goal for first step. Will use linaro-hwpack-create or multistrap to generate sysroot archives. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 0/2] Make PowerTOP generic
Dnia czwartek, 29 lipca 2010 o 13:57:21 Amit Arora napisał(a): > I have tested this only on my desktop. I am yet to receive an ARM based > board, and hence couldn't test it there. So, any kind of testing and/or > feedback are most welcome! Thanks! I fetched 9f4efd1c7cc0bc9a9078fa6b83a98763a7637e2f revision, applied both patches and built it for my desktop. Segfaulted on first run. Desktop is Core2Quad q6600, powertop without your changes works. C-states are not available, frequencies are listed. Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 0/2] Make PowerTOP generic
Dnia czwartek, 29 lipca 2010 o 13:57:21 Amit Arora napisał(a): > I have tested this only on my desktop. I am yet to receive an ARM based > board, and hence couldn't test it there. So, any kind of testing and/or > feedback are most welcome! Thanks! I fetched 9f4efd1c7cc0bc9a9078fa6b83a98763a7637e2f revision, applied both patches and built it for my desktop. Segfaulted on first run. Desktop is Core2Quad q6600, powertop without your changes works. C-states are not available, frequencies are listed. Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 0/2] Make PowerTOP generic
Dnia poniedziałek, 2 sierpnia 2010 o 18:54:11 Amit Kucheria napisał(a): > pcre3 does not show in 'apt-rdepends grep', so I am not sure what is > going on here... Thats other direction: 19:02 h...@home:rules.d$ LC_ALL=C apt-cache showsrc grep Package: grep Binary: grep Version: 2.6.3-3 Priority: required Section: utils Maintainer: Anibal Monsalve Salazar Build-Depends: autotools-dev, debhelper (>= 7), gettext, libpcre3-dev (>= 7.7), quilt Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Adding packages to image seeds
Dnia poniedziałek, 9 sierpnia 2010 o 15:56:18 Amit Kucheria napisał(a): > As a followup to a conversation I had with Alexander (asac) on IRC, i'd > like to request the addition of some packages to the headless image. This > is to make the images more useful out-of-the-box. > > - ifplugd (dhcp networking) Check what is installed in ubuntu-server instead of N-M and use it. Probably ifupdown + something to generate /etc/network/interfaces file. > - openssh (atleast server) Or dropbear when space is limited. > More useful tools to consider (but might be more insteresting only to > kernel devs) I would also add: - evtest - lsof - strace - devmem2 - i2c-tools Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
