Re: GCC Explorer.. on ARM?
On 24 May 2012 16:11, Christian Robottom Reis k...@linaro.org wrote: http://xania.org/201205/gcc-explorer Could we get Matt to provide a cross-compiler environment too? He's already using gcc-linaro anyway.. ;-) He appears to provide a 4.5 version of our cross-compiler environment ? Click on compiler and you see arm-linux-gnueabi-g++-4.5.3 Remove -march=native from the command line and then assembler output appears for simple programs . Actually this reminds me of mbed.org where there is a full fledged online IDE for a baremetal cross-development environment. Ramana We could also host a version ourselves under a cool linaro.org hostname. -- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Golly, is that the dual SD card you and David from tincantools have been working on?
On 15 May 2012 13:45, Mans Rullgard mans.rullg...@linaro.org wrote: On 15 May 2012 13:05, Ramana Radhakrishnan ramana.radhakrish...@linaro.org wrote: On 15 May 2012 12:54, Alexander Sack a...@linaro.org wrote: Basically a gadget that allows you to use one sd card shared by two computers. Power off computer A and computer B will see the sdcard. Power on computer A and sd card will get unplugged from computer B; computer A can use it exclusively until it gets powered off again. (Assuming that computer B is powered off at the same time that Computer A comes on) Interesting though I'm not sure where I'd use it and how it would work if I had a running computer B and it was using that device :) No, computer B can remain powered on all the time. Imagine computer A being a Pandaboard with power controlled by computer B, a PC. Now the PC can power off the Pandaboard, write an image to the card, and power on the Panda again. This allows fully automatic recovery from a bad boot loader/kernel. Ah thanks - that makes a lot more sense now. Ramana -- Mans Rullgard / mru ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Cross Compiling Firefox with Multiarch
Riku, On 24 November 2011 13:32, Riku Voipio riku.voi...@linaro.org wrote: Hi, Just to let you all know, due to the ongoing multiarch work, it is not possible to cross-compile relatively complex packages in ubuntu. For example, following the instructions[1], Firefox. Out of curiosity and having a few minutes right now, I tried following the instructions in an oneiric chroot on an amd64 host and I hit the following issues. 1. /etc/apt.conf.d does not really exist. so I had to create one and put 10local into it. 2. While following the instructions as in Drag-in build dependencies for firefox (oneiric)root@e102742:~# cat firefox-deps.sh apt-get install libx11-dev:armel libxt-dev:armel libgtk2.0-dev:armel liborbit2-dev:armel libidl-dev:armel libxft-dev:armel libfreetype6-dev:armel libxrender-dev:armel libxinerama-dev:armel libgnome2-dev:armel libgconf2-dev:armel libgnomeui-dev:armel libstartup-notification0-dev:armel libasound2-dev:armel libcurl4-openssl-dev:armel libdbus-glib-1-dev:armel libiw-dev:armel mesa-common-dev:armel libnotify-dev:armel libgnomevfs2-dev:armel libdbusmenu-gtk-dev:armel (oneiric)root@e102742:~# sh firefox-deps.sh Reading package lists... Done Building dependency tree Reading state information... Done libasound2-dev:armel is already the newest version. libcurl4-openssl-dev:armel is already the newest version. libdbus-glib-1-dev:armel is already the newest version. libfreetype6-dev:armel is already the newest version. libgtk2.0-dev:armel is already the newest version. libnotify-dev:armel is already the newest version. libx11-dev:armel is already the newest version. libxft-dev:armel is already the newest version. libxinerama-dev:armel is already the newest version. libxrender-dev:armel is already the newest version. libxt-dev:armel is already the newest version. mesa-common-dev:armel is already the newest version. libdbusmenu-gtk-dev:armel is already the newest version. liborbit2-dev:armel is already the newest version. libiw-dev:armel is already the newest version. libstartup-notification0-dev:armel is already the newest version. libgnome2-dev:armel is already the newest version. libgnomeui-dev:armel is already the newest version. libgnomevfs2-dev:armel is already the newest version. libgconf2-dev:armel is already the newest version. libidl-dev:armel is already the newest version. You might want to run 'apt-get -f install' to correct these: The following packages have unmet dependencies: libgnutls26:armel : Depends: libtasn1-3:armel (= 1.6-0) but it is not going to be installed libtasn1-3-dev:armel : Depends: libtasn1-3:armel (= 2.9-4) but it is not going to be installed E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution). (oneiric)root@e102742:~# apt-get install libtasn1-3-dev:armel Reading package lists... Done Building dependency tree Reading state information... Done libtasn1-3-dev:armel is already the newest version. You might want to run 'apt-get -f install' to correct these: The following packages have unmet dependencies: libgnutls26:armel : Depends: libtasn1-3:armel (= 1.6-0) but it is not going to be installed libtasn1-3-dev:armel : Depends: libtasn1-3:armel (= 2.9-4) but it is not going to be installed E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution). (oneiric)root@e102742:~# apt-get install libtasn1-3:armel Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: x11proto-record-dev libcairo-script-interpreter2 libssl-doc libglib2.0-dev zlib1g-dev libxtst6 libglobus-openssl Use 'apt-get autoremove' to remove them. The following NEW packages will be installed: libtasn1-3:armel 0 upgraded, 1 newly installed, 0 to remove and 23 not upgraded. 235 not fully installed or removed. Need to get 0 B/37.7 kB of archives. After this operation, 139 kB of additional disk space will be used. debconf: delaying package configuration, since apt-utils is not installed (Reading database ... 44963 files and directories currently installed.) Unpacking libtasn1-3:armel (from .../libtasn1-3_2.9-4_armel.deb) ... dpkg: error processing /var/cache/apt/archives/libtasn1-3_2.9-4_armel.deb (--unpack): './usr/share/doc/libtasn1-3/NEWS.gz' is different from the same file on the system Errors were encountered while processing: /var/cache/apt/archives/libtasn1-3_2.9-4_armel.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Is there something I might be doing wrong ? Cheers, Ramana ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Epic Battle and substantial speed ups with Skia on 4.6
a double check that this doesn't result in there being a spike in the results for 2011.10 would be good. If not, historical data needs to be measured for this change given that the said options weren't used while measuring the historical data. Neither the 2011.09 nor the soon to be published 2011.10 benchmarking was done using these flags. I'm not sure if I'll have the cycles to try this out this month or not. However, I'll add this to next month's testing. That is good news. Err - I was actually suggesting not adding it or making sure that the new numbers you get with these options aren't used to plot the historical performance of the toolchain. Ramana ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Android gcc 4.6 1107 optimization benchmark
On 19 August 2011 13:40, Christian Robottom Reis k...@linaro.org wrote: On Fri, Aug 19, 2011 at 03:40:26AM +0100, Chao Yang wrote: The image size increases significantly when -O3 is enabled for thumb files, Size goes /up/ when enabling thumb? That's definitely unexpected. The size increas is probably more driven by O3 rather than Thumb I suspect. If there are where ARM state is smaller than Thumb state but we should look at those but then you've got to be comparing O3 and -marm and O3 and -mthumb to be comparing apples and apples. cheers Ramana ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: What are the chances of a phone based developer image
. Would you be interested in adding a Firefox-based benchmark? As a large application it is a good testbed for LTO, FDO and other aggressive optimizations. Sorry about the delayed response. I did notice your mail last week but I was busy with our conference and then the first couple of days this week have just disappeared with some internal training. I would be interested in hearing how you get on with LTO and FDO on ARM. Listening to Honza talking at the GCC unconference in London about the memory usage for full LTO with trunk I did wonder what would happen if we tried it on the ARM target to see what we got, but I never managed to get around to trying anything there :) . We did look at getting FDO working with Linaro GCC last cycle but there are still a couple of issues with PGO in Linaro GCC 4.5. With respect to LTO , the one problem we have currently is that the Neon intrinsics aren't streamed out and streamed back in. So you might have a few issues if your code uses arm_neon.h . https://bugs.launchpad.net/gcc-linaro/+bug/823548 is an example of this problem. This was fixed upstream and we probably just need to backport that into our 4.6 tree. I've tried a backport this morning and I think I have this right finally. If you could do a build and a firefox benchmark run in about 30-60 minutes by all means please do let us know how you get on and what you find. We've been steadily trying to improve the performance of the ARM toolchain and the biggest improvements you'll notice will be with the vectorizer but there will be other small improvements that you'll notice in other general areas of code generation. We would be interested in feedback about what can be done and to add to our queue of things to look at and improve for the ARM port of GCC. With respect to the images, Kiko's probably answered that bit. cheers Ramana ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: What do we want our hwpack sources
On 01/06/11 19:41, Christian Robottom Reis wrote: Hello there, This week I initiated a confused conversation during the techleads call about having a way to describe what the hardware pack was built from. We had a couple of false starts but I think we agreeing that there needs to be some form of manifest that describes what the hardware pack contains. Sorry I'm getting into this conversation a bit late but is there also a need to figure out what toolchain was used to build this hwpack and the way in which the toolchain was configured (v7-a, neon, vfp , vfpv3-d16) and what version of the toolchain was used. If this information is already captured or there is an easy way of getting back to this. This is if you think there is a use-case of regenerating the hwpack to investigate any issues that might come up cheers Ramana ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: How to remove –with-mode=thumb from linaro
On Thursday, 12 May 2011, AKS aungk...@gmail.com wrote: What flag I have to pass in making? I mean what to type in after CCFLAGS= in make or what to be added in Makefile. Thanks! Try using -marm. Ramana ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Usefulness of GCC's 64bit __sync_* ops on ARM
On 6 May 2011 16:06, Ken Werner ken.wer...@linaro.org wrote: Currently the GCC ARM backend doesn't provide a pattern to inline 64bit __sync_* functions but the compiler emits __sync_*_8 function calls [1]. The libgcc does not provide these symbols via the usual thin wrapper around the kernel helper [2] because the ARM Linux __kernel_cmpxchg supports 32bit only. My understanding is that for ARMv7 the GCC backend could be enhanced to inline the __sync_* functions by using the LDREXD and STREXD instructions. But for ARMv5 we would still rely on a new kernel helper. It's a bit tricky with when you want to use the kernel helper for v5t, so we've got to find a way of turning this on only with special knobs and not by default and that's a bit tricky. Think new user space and old kernel and a jump into never-never land. For v7-a you could inline the function using ldrexd / strexd. cheers Ramana ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Panda boards and 1GB of RAM.
On 28/04/11 09:01, Marcin Juszkiewicz wrote: 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 ! ramrad01@liliput-panda:~$ cat /proc/cmdline console=tty0 console=ttyO2,115200n8 root=UUID=85fea80e-b5fa-41c5-97a7-cedfaaa15ea2 rootwait ro earlyprintk fixrtc nocompcache vram=32M omapfb.vram=0:8M mem=463M@0x8000 mem=512M@0xA000 ramrad01@liliput-panda:~$ free -m total used free sharedbuffers cached Mem: 669162506 0 26110 -/+ buffers/cache: 25644 Swap:0 0 0 Not sure why I seem to have very different kernel cmdline in this case. Ramana 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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Panda boards and 1GB of RAM.
On 28/04/11 09:01, Marcin Juszkiewicz wrote: 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 Ok based on a conversation that Marcin and I had on IRC , it turns out that the kernel I'm running is a linux-1002-2.6.38-omap4 kernel while Marcin is running a 1024-2.6.38-omap4 kernel ? Why is it that the daily hwpacks either from haven't been updated with a kernel after 1002 in this case ? cheers Ramana Where 22MB vanished? No idea. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Panda boards and 1GB of RAM.
Hi, https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/633227 seems to suggest we can now use 1GB of RAM on a Panda board. Creating a new image using the following images and hwpacks for my Panda : BOARD=panda linaro-media-create --rootfs ext4 --mmc /dev/mmcblk1 --binary linaro-n-developer-tar-20110426-0.tar.gz --hwpack hwpack_linaro-panda_20110426-0_armel_supported.tar.gz --dev panda I see that : root@linaro:~# uname -a Linux liliput-panda 2.6.38-1002-linaro-omap #3-Ubuntu SMP Fri Apr 15 14:00:54 UTC 2011 armv7l armv7l armv7l GNU/Linux root@linaro:~# free -m total used free sharedbuffers cached Mem: 662538123 0 14494 -/+ buffers/cache: 30631 Swap:0 0 0 Is there something else that I'm missing here ? cheers Ramana ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Panda boards and 1GB of RAM.
https://bugs.launchpad.net/linaro-image-tools/+bug/707047 This bug has been marked fix released for linaro-image-tools, but there has not been an update of linaro-image-tools in Ubuntu natty since February. If you use linaro-media-create from the bzr branch when writing to the SD card, you should see more memory available. I am using linaro-media-create from the PPA - given that my host is a Maverick system and this was updated to this mornings version which appears to be 0.4.4 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 ! cheers Ramana ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro PPAs and backports / release cycles
Agreed. I'd like an easy way of getting pre-built binaries of all the stable enough Linaro outputs. On the toolchain side this would include the latest monthly releases of Linaro GCC, GDB, and QEMU in native and cross versions as appropriate. A single PPA for the whole of Linaro would be nice. I'm curious to hear what packaging methods would be used for things like the toolchain which have consumers beyond ubuntu. Are we saying this will only be Ubuntu packages or is there consensus around providing static tarballs ? I ask this because I've seen a number of requests about getting hold of a binary Linaro toolchain release and not everyone uses Ubuntu as their host distribution. Ramana -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Maverick armel cross toolchain
arm-linux-gnueabi-gcc -g -DDEBUG -Os -fno-strict-aliasing -fno-common -ffixed-r8 -ffunction-sections -msoft-float -Wcast-align -Wall -D__KERNEL__ -DTEXT_BASE= -fno-builtin -ffreestanding -isystem /usr/lib/gcc/arm-linux-gnueabi/4.5.1/include -pipe -march=armv4t -mlong-calls -mtune=arm7tdmi-s -DCONFIG_ARM -D__ARM__ -mthumb-interwork -Wall -Wstrict-prototypes -Wcast-align -Wextra -Werror -Iobj_redbee-econotag_board -I../board -DBOARD=redbee-econotag -I../lib/include -I../src -I. -mthumb -mcallee-super-interworking -MMD -c -o obj_redbee-econotag_board/sleep.o sleep.c sleep.c:1:0: error: AAPCS does not support -mcallee-super-interworking This sounds like a missing implementation rather than just a toolchain flag; or perhaps it's not needed at all with AAPCS? -mcallee-super-interworking is ancient and need not be used with AAPCS toolchains. The linker will deal with interworking issues on AAPCS toolchains by inserting stubs at appropriate locations and arranging for correct control and state transfer at the required interfaces. cheers Ramana ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
