Re: Official support Odroid hardware and other ARM development boards.
[Re: Raspberry Pi GPU blob] On 27/02/2014, Eric Nelson eric.nel...@boundarydevices.com wrote: There's one key piece that's normally closed-source (the GPU), but there's an open-source alternative here: https://github.com/laanwj/etna_viv RPi Foundation have just (10 hours ago!) announced a 1 dollar bounty for whoever manages to get an open-source GPU driver working first. http://www.raspberrypi.org/archives/6299 earlier the same day, Broadcom announced[1] full documentation for the VideoCore IV graphics core, and a complete source release of the graphics stack under a 3-clause BSD license That only leaves the problem of having to develop a free open-source driver in secret so that someone else doesn't steal your work and clain the 1, thereby losing most of the advantages of open source development... M [1] http://blog.broadcom.com/chip-design/android-for-all-broadcom-gives-developers-keys-to-the-videocore-kingdom -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cal4-wqoc9j+13vuq20_kbvft7ydcoibds033+hjafsaoqg2...@mail.gmail.com
Re: gcc armel status and armel architecture defaults
On 13/01/2014, Wookey woo...@wookware.org wrote: +++ Matthias Klose [2014-01-13 05:51 +0100]: the gcc-4.9 in experimental fails to build while the one for armhf succeeds. If I remember correctly we had some issues with the arm soft float port already with gcc-4.7 and gcc-4.8. Are the armv4t defaults still needed, or would it better to default to some newer arm version like armv5t? The v4t default is still desired by some people, and no-one has demonstrated a speed rom changing to v5, but at some point we expect lack of toolchain support to force us to move. The same defect occurs on on armv5t, host, target and build, so that's not a solution. M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAL4-wQrohwYSTqTNJ+xr5z8AfOa0JjZeAz1cum=wcne9hc2...@mail.gmail.com
Re: Dropping support for the smallest armel machines
+1 for maintaining iop32xx support. I bought and use one for debian development and offer it as a service to open-source developers. Keeping it running with standard stable and sid is essential to this. I also remember nslu2 being the whizzo machine for hackers On 25 June 2013 04:05, Chris Wilkinson kins...@verizon.net wrote: I increased the kernel zimage flash available to 4mb on an Intel SS4000E (iop32x) by reconfiguring the flash with fconfig, deleting the unused parts used by the stock firmware. This enabled me to upgrade the kernel to v3.2. This does need serial console access as Ben says but that is true whatever kernel you want to flash. On the N2100, dpkg automatically flashes new kernels without need for serial console. Is -Os used in the kernel for armel? Or at least when compiling the small-flavour kernels? M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cal4-wqrwzeqp5jei+_eav+xmve7stf6aklpo-nkqkpyrp3z...@mail.gmail.com
Re: Debian on thecus N2100
On 12 April 2013 23:15, Brian Platt brianpl...@hotmail.com wrote: Yes this the way i've been doing it, I even did a new header on another 2100 i've got and the same thing. Hypothesis: it's the voltage levels Experiment: try it with a proper 12V RS232 serial port M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cal4-wqrho4hboyxmb8n1gnewnzxpxkrel1ungqhcmk8uuxg...@mail.gmail.com
Re: Please put me on your mailing list. I am looking for the image file (not the iso file) to write to an SD card. Preferably it would be the latest stable release (6.x). All the website I go to only
I just had to laugh out loud at this! Thankyou Philip. M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAL4-wQpE5J6612021XWLQsfxy-_=a2krgx-tmy2czkqyk_k...@mail.gmail.com
Re: ARM port(s) BoF at DebConf
On 19 July 2012 19:35, Steve McIntyre st...@einval.com wrote: armel = First released with Lenny. Soft-float EABI, Software floating point assumed by default. v4t which also runs smaller-size thumb instruction set. Targeting old hardware like openmoko. Discussed (again!) moving forwards from v4. Declared that v5 is no faster than v4t, but there are doubts elsewhere in the community. Later discussion suggests moving to v5te would be worth it. Some good benchmarks would help - volunteers welcome! Actually, supporting less machines is a move backward, not forward. The speed advantage for standard apps on v5+ machines is less than 1%, i.e. negligable. Of course, I have a vested interest in continued armv4t support, since my company has an armv4t board on the market that ships with Debian as its standard distribution. It would also impact Technologic Systems, Bluewater Systems and other small companies for similar reasons. Who is it that keeps bringing this up? I can see that ARM Ltd would want this, as it would eliminate Linux distro support for devices from which they no longer see any royalties., but I don't see any advantage for anyone else except chronic speed freaks who would kill other people's boards off to get a half of a percent faster for themselves. If somebody has a critical need to multiple two shorts with result as a long in a single instruction (which is what the E in 5TE brings), surely they can compile their own armel packages changing the cpu type, rather than making Debian do that and breaking other people's systems needlessly? Isn't Debian supposed to be the Universal Operating System, where Universal includes running on as many different computers as possible? And the speed freaks can always build their own v5t and v5te repositories and use those to install from, leaving everybody happy. M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAL4-wQqM-HGUo=zssjweon51i2t8ebsgtzfbopfb9ftl3eq...@mail.gmail.com
Re: armhf multiarch tuple
On 17 April 2012 18:36, Wookey woo...@wookware.org wrote: debian armel is currently built for v4t but is likely to move forward to v5 at some point. -1 as we have and others have products that are arm4vt and that ship with Debian as its standard system. How big is the speed advantage for v5 users when optimizing for v5 instead of v4t? Enough to warrant the exclusion of our v4t parts? M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAL4-wQqKgin23ZFPbRUQg5715LPzt==4zecge4nutdzxjie...@mail.gmail.com
Re: Help making a decision on re-basing Slackware ARM from armv4 to armv5
On 14 December 2011 21:30, Stuart Winter m-li...@biscuit.org.uk wrote: Slackware, like Debian is a general purpose OS aiming to meet most users' needs on the common denominator hardware -- which on ARM is armv4. Some instructions were added in v5E: count-leading-zeroes, 16-bit multipliers, saturating arithmetic, a preload instruction, double word loads and stores and a faster instruction to switch between ARM and Thumb modes in function returns. See Column 3 of http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001l/QRC0001_UAL.pdf where is says 5E. It's unlikely that a compiler would be able to make much use of any of these: CLZ is used in assembly-language division routines, saturating arithmetic is unusable when compiling, faster switching between ARM and Thumb is useless. The compiler may be able to make use of the preloads to reduce the memory bottleneck and of the double word load/stores. Will there be much of a performance difference for regular server-type workloads (e.g. file serving etc) as distinct from playing media and desktop usage with web browsers etc? Probably not, since that kind of application will be mainly memory-, network- and disk-bound. Also, will an OS compiled for armv5 perform better on armv7 hardware? Probably the same size gain as you get on v5 hardware. My understanding is that only certain workloads -- e.g. playing video -- would benefit from compiling for armv5. These will benefit more from the SIMD instructions, for which you can recompile the specific libraries for your actual target processor. A few applications and libraries will benefit from mandating a floating point processor such as VFP - here the speedups are a factor of three to four, and switching the hardfloat ABI gives another 30% or so I gather. However, that would also eliminate any board with no FPU. Thanks in advance for any ideas -- just rough instinctive feelings are all I'm after (unless somone does have any actual figures of running Debian armel userland compiled for armv4 vs armel compiled for armv5). Of course, that is the real answer... you could compare a Debian and a Ubuntu userland, which are build from almost identical sourves using the same mechanisms and compiler. I'd be very interested to know your measured results. My feeling is that the speed gain would be in the 5-10% range at best. For a general-purpose operating system you need to evaluate whether that's worth the effort and exclusion of low-end machines. M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cal4-wqpbw0cyy+615bp_qmfvryz1mryn9pi4sdgueupkaxv...@mail.gmail.com
Re: My progress on armhf
On 22 August 2011 22:43, Lennart Sorensen lsore...@csclub.uwaterloo.ca wrote: On Mon, Aug 22, 2011 at 06:53:49PM +, Hector Oron wrote: 2011/8/22 Lennart Sorensen lsore...@csclub.uwaterloo.ca: Any suggestions for what to fix next? Pick the one you dislike the most =) http://wiki.debian.org/ArmHardFloatTodo Some things look like the are already fixed. Who maintains the page? you do, wiki wiki! :) M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAL4-wQpi=krjwr88n0fx6uwaockvckxxj+elku_24yegkca...@mail.gmail.com
Re: wiki.debian.org/ARM - page needed - volunteer? ; gre
On 3 May 2011 04:25, giovanni_re john...@fastmail.us wrote: PS Did i miss it? http://wiki.debian.org/ArmPort doesn't have a link to http://wiki.debian.org/ArmHardFloatPort ? Your search failed to find http://wiki.debian.org/ArmEabiPort which is the main technical reference for the current main ARM port. I guess that also needs a link in ArmPort (and/or ARM if that gets created) M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktin4vs3ya2buikncqxttnpws1aq...@mail.gmail.com
notes to help with ghc6 armhf port
Hi!
I see from ArmHardFloatTodo that ghc6 is waiting to be ported. I
did this for armel and append the notes I made for my own benefit
while doing it, in case someone want to try this.
Cheers
M
-
Porting GHC to Debian armel
ghc6 cannot be autobuilt because it requires itself to build itself.
There are other haskell systems in Debian:
the nhc98 compiler and the hugs interpreter.
Versions in Debian:
nhc98 - only in sarge
ghc6 - etch:6.6-3 lenny/sid:6.6.1-2
There are two kinds of ghc ports:
- unregistered builds which are not optimised for the target CPU
- registered builds, which know about the registers available on the machine
and some assembly language constructs so that the Evil Mangler script can
edit the output assembly language giving a factor of two speed increase.
The current Debian arm port seems to be an unregistered build,
i.e. a half-finished port that generates code that runs at half speed.
Strategy:
- Cross-compile a new unregistered build via intermediate .hc files,
and install it under /usr/local
The process is described in
http://hackage.haskell.org/trac/ghc/wiki/Building/Porting
See also
http://www.haskell.org/pipermail/glasgow-haskell-users/2006-May/010164.html
and replies
- the GHC machine type arm-unknown-linux seems ok for arm-*-linux-gnueabi.
- Once source tarball is unpacked:
chmod 755 distrib/{hc-build,fake-happy}
- at make hc-file-bundle Project=ghc on the host system it complains about
missing files. Can fix all but one with:
$ cd H/rts
$ make AutoApply_thr_p.hc AutoApply_thr_debug.hc AutoApply_thr.hc
AutoApply_debug.hc
- while building, two .hc files are missing:
$ cd H/libraries/Cabal
$ make cabal-setup/{CabalSetup,Setup}.hc
$ cp -p !$ T/libraries/Cabal/cabal-setup/
- On the target system, install all of ghc6's builddeps *except* xsltproc,
because this is required for documentation only and makes a 64MB machine
thrash. Without it, the configure script just turns off building of
documentation.
Problems building bootstrap compiler:
- make -C libraries all:
The build of cabal-setup fails because Setup.o is missing from the
compile line. copy and paste and rerun that line.
- make -C compiler all:
gcc -x c parser/Parser.hc -o stage1/parser/Parser.o ...
needs 121MB VM, unlikely to fit on a 128MB box with no swap.
Removing -O doesn't help.
Use a 247MB QEMU or enable some swap.
- build the debian ghc6 using the local compiler and with all builddeps except
ghc6 installed (dpkg-buildpackage -rfakeroot -d)
(dpkg-buildpackage -B gets you nowhere: all packages are arch-dependent)
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/BANLkTikPHBf1TibyGA2DPeJfcPgqR=k...@mail.gmail.com
Re: How to upgrade old abi lenny to squeeze
On 4 April 2011 18:35, brian briandorl...@t-online.de wrote: but I thought that I dont have a choice due to the arm - armel change? My understanding was that I cannot upgrade the Lenny version I have to squeeze. If you want to keep the same installed packes and configuration files then yes, you would need to go arm-lenny-armel-lenny - armel-squeeze Sorry, I thought you were already resigned to doing a fresh installation. M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktinuoasspoxb9i17a8xn0kxana6...@mail.gmail.com
Re: How to upgrade old abi lenny to squeeze
On 3 April 2011 12:52, brian briandorl...@t-online.de wrote: On 04/01/2011 06:56 AM, Gordon Farquharson wrote: Based on my experience, I think that you'd make better use of your time by installing armel lenny and then upgrading to squeeze. If anything, it will certainly encourage you to make notes about how you customized your system (if you haven't already). So, you suggest to install armel Lenny and then upgrade to squeeze on armel. Seems Martin also has a squeeze image ready for NSLU2, why not just install that? I guess either way I will need to reinstall everything anyway. Maybe I'm missing something. Well, , the upgrade takes about 48 hours on a slow ARM box and (worse!) involves you having to poke the console every now and then for a good number of those hours, responding to configuration questions and should I really restart these daemons boxes. If you choose to do a fresh installation anyway you may as well go straight for squeeze. M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktikgsm_qsoc5nrfen9feymi4sdb...@mail.gmail.com
Debian armhf: libgsm and speex build integer fixed-point versions on arm*
Hi! Revisiting my armel patches for lenny/Crunch, I noticed that libgsm buillds its integer version on arm*: debian/rules: ifneq (,$(filter arm%,$(DEB_HOST_ARCH))) MULTYPE='' else MULTYPE='-DUSE_FLOAT_MUL' endif The same is true of speex: ifeq ($(DEB_HOST_ARCH_CPU),arm) objdir = $(objdir_fixedpoint) EXTRA_CONFIG_FLAGS = --enable-arm4-asm endif When I compiled these for MaverickCrunch FPU, I found that the fixed-point version was faster than the Crunch version (but the Crunch is a fairly slow FPU) I don't know what the speed difference would be for armhf - the more powerful FPU may win. Cheers M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTi=urA9AL2pFV-aJnL_aP=6x1Gt6F5CBJnKO5L=c...@mail.gmail.com
Re: Reports of successful Squeeze upgrades
Hi
I just upgraded a Thecus N2100, populated with lots of languages and
dev packages, from lenny to squeeze.
This worked fine, following the kernel+udev+reboot+dist-upgrade
method. Nice work, team!
Summary: the upgrade worked as described and would have given a
working system, but watching the console for four hours will let you
resolve a few problems.
In my case I noticed:
- it complained, each of the three times it flashed the kernel+initrd,
about not finding /lib/firmware/rtl8168d-{1,2}.fw. After the first
time I provided by installing firmware-realtek, but these files are
really in /lib/firmware/rtl-nic / so the complaints continued. Since
the box has rtl8169 ethernet, I didn't fancy seeing whether it would
come up without these installed...
- the dependency-based init (sysv-rc) would not go live until I had
- purged jackd (which was removed but not purged)
- deleted /etc/init.d/temper - a custom script to enable the
temperature sensors/fan speed stuff on the N2100: the init script was
not LSB compliant.
- run dpkg-reconfigure sysv-rc
These necessary steps were reported explicitly in a diagnostic window
which paused the installation and waited for a OK.
I gather from other reports that this happens also with other
removed-but-not-purged packages, so it may be well to purge all such
packages before upgrading:
# apt-get purge $(dpkg-query -l | grep '^rc' | awk '{print $2}')
- At one point it asked me to run defoma-app purge gs by hand for some reason.
- 45 broken symbolic links remain, mostly in /etc/alternatives and
under /usr/share/man.
# find -L /etc /usr -type l -print
(-L means follow symlinks, which makes -type l only match on
broken symlinks. Don't run it from / or it will go mad under /proc)
All in all, a trouble-free upgrade, but thank heaven it only has to be
done once every three years...
M
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/aanlktikxk9lxojqpcujasqljvc79jrfsf55co45ji...@mail.gmail.com
Running armel on armv4 hardware
Amother solution would be to emulate the thumb instructions linux uses by catching the illegal instruction signal in kernel space alla FPA emulators. Not that I'm volunteering to write it, mind! Not for free anyway ;) M M
Re: ARMv4-support in armel/squeeze?
On Thu, Dec 30, 2010 at 6:48 PM, Luke Kenneth Casson Leighton l...@lkcl.net wrote: Neil? I spent 2006 working to bootstrap the armel port, of which the first 6 months were getting a working EABI cross-compiler (partly because the emdebian crowd, who seemed to know more about it, urged me to; in reality you have to build Debian packages natively) and the last 6 months were spent doing exactly the circular dependency workarounding that has been described here. jeezus. what a total waste. sorry, not of your work, but a total waste that this wasn't automated back then, so that konstantinous didn't have to completely re-duplicate it, from scratch. Well, I documented my procedure as a sort of shell script. I doubt you could just run it as such, but all the steps, scripts and notes on individual packages etc are somewhere under http://martinwguy.co.uk/martin/arm There are also some archive integrity checking scripts I ran in 2008, e.g. the src-bin-arch script which runs some checks for arch inclusion in the debian/control file that can only be performed by downloading and scanning the entire source repository: specifically, whether some of the binary packages are only generated for some architectures which may need the port name included. but with the massive explosion in compiler options for ARM processors alone, the process of porting now becomes a massive headache. Not really, you can recompile your own repository for a specific CPU that is compatible with an existing ABI The fake gcc trick seems to fool almost all packages (from http://martinwguy.co.uk/martin/crunch/#UsingIt): mkdir ~/crunch cat ~/crunch/gcc EOF #! /bin/sh exec gcc-4.3-crunch -march=armv101thx $@ EOF chmod 755 ~/crunch/gcc ln -s gcc ~/crunch/cc ln -s gcc ~/crunch/gcc-4.3 ln -s gcc ~/crunch/arm-linux-gnueabi-gcc then arrange to run all the build tools with PATH=~/crunch:$PATH M M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktim2fzn3fm7gf4uy5p4w06wqdaatqev85q-eo...@mail.gmail.com
Re: emacs-snapshot for arm
On 8/20/10, Alok G. Singh alephn...@hcoop.net wrote: Martin Guy mailed me off-list to remind me about the terms of distributing GPL software. So, to clarify: 0. The binaries are NOT signed. Caveat emptor. 1. This is just an armel build of emacs-snapshot[1]. The license is in the source tree. 2. The packages are not in a repository format. It's really just a personal build. I only put it up online as a backup for me. If someone wants to use them, go ahead. It has nothing to do with these points. You are distributing a binary blob of GPL software without distributing the source code and without including the license. I think you should read the GPL and understand it if you want to work with GPL'd open source. I too break the GPL. I distribute binaries for a modified version of GCC accompanied only by source patches to well-known GCC distributions. This, too, is illegal but I can't afford to host hundreds of megabytes of GCC sources, let alone have people downloading them, and it is not against the spirit of the GPL in that the source freedom accompanied the software. Distributing binaries and patches to well-known sources is an issue that GPLv3 failed to address. I mailed you off-list to share awareness of this issue. I must say, a public rebuttal to a private message, changing nothing and just making excuses is disappointing. I don't want you to take the stuff down - it's a great public service you are doing by making them available - I just want you to understand the GPL and think about following it, since it explicitly forbids publishing binary blobs. To be legal, all you need to do is read the GPL, understand it, and follow its terms of use. To follow it to the letter, you need to either put the Debian source package next to the binaries or copy the COPYING license file there and put a README including an offer to send the sources by post (!). It would be nice to saying what commands were used to build the binaries from the sources, but requiring build instructions is a second issue that the GPLv3 failed to address. M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinqjhxvjzi0hp9wufhdsusnko9n+t0v-4zaz...@mail.gmail.com
Re: ARM ports
On 8/13/10, Mohammed Rashad mohammedrasha...@gmail.com wrote: I would like port ARM to MINIX3. But dont know where to start. If you can give me a spark to start porting of ARM I will be very grateful to you. Can I use any simulators for porting MINIX to ARM processors. I had also purchased a book related to ARM7 LPC2000 series. Do I need to buy an ARM development board. I dont have enough money to buy an ARM development board. But I will buy the development board when i complete the porting of MINIX to ARM. The hard work in an OS port is porting all the device drivers to a new OS: serial port, ethernet and so on. If you choose one of the major platforms supported by QEMU (for example, the ARM versatile range) you will find example code to work from in Linux, in NetBSD and so on). May I know which simulator you used for developing linux to ARM? I found QEMU to be very solid as a platform. You can treat it as it if were real hardware :) Can you tell me what all things I need and I should do for porting MINIX to ARM.? I need to know how you did the porting of linux to ARM processors? That's a big question! :) I suggest you start studying the structure of Minix, and the sections that differ from processor to processor. Minix only works on x86 processors :-( but http://www.minix3.org says Ports to ARM and PowerPC are underway. so your first move is to check with whoever is doing these ports, to know how far they have progressed. I am sure they will be very pleased to receive your help and to work with you! M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinnchekhtoyo4y3b22_lojt2uguh4nuxff16...@mail.gmail.com
Re: emacs-snapshot for arm
On 8/10/10, Alok G. Singh alephn...@hcoop.net wrote: Is there a repo with binary packages of the excellent emacs-snapshot[1] ? Footnotes: [1] http://emacs.orebokech.com/ If you have a debian arm box, you can add deb-src http://emacs.orebokech.com sid main to /etc/apt/sources.list and go $ apt-get source emacs-snapshot $ apt-get build-dep emacs-snapshot $ cd emacs-snapshot-* $ dpkg-buildpackage -rfakeroot -B $ cd .. $ sudo dpkg -i emacs-snapshot*.deb (and if it complains about unsatisfied dependencies) $ sudo apt-get -f install Cheers M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinwx0+tx+-zxzrw-jyhdukhn+vr3n=lg51tu...@mail.gmail.com
Re: Seeking machines for nightly builds of ITK
On 8/3/10, Steve M. Robbins st...@sumost.ca wrote: The insighttoolkit package is a large and active code base. They use a system of nightly build/test on a variety of machines [1] to ensure that the code works on all supported platforms. If you have a non-amd64 machine with spare cycles each night that you can either set up a build [2] or let me log in to do it, please reply. There's an armel box you can use via ssh with an armel-sid chroot. Mail me privately suggesting a username if this would be useful. M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktincoquae=nlfwxfw+t7=amycr8jdyq9ydckr...@mail.gmail.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
On 7/16/10, Aurelien Jarno aurel...@aurel32.net wrote: Martin Guy a écrit : users of armv4t boards, from using the universal operating system Debian? I was not aware of that. If they are some real users of an armv4t port, we should probably keep it. The most widespread is the Technologic Systems TS-72xx series of boards (see the noisy yahoo TS7200 forum for an idea of how many) and Glomation, while the Sim.One and Snapper boards are about to be marketed. All these are based on that awful Cirrus EP93xx SoC. I'm asking popcon if it's feasible to extend that package to report CPU arch, since concrete figures are always preferable to hearsay and individual impressions. Cheers M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinlqmterfztlb4v1_rghhgs_po6ys5ubie_h...@mail.gmail.com
Adding CPU arch statistics to popcon
Hi I'm wondering if its feasible to extend popcon to give statistics for the CPU architecture in use. Certainly for the ARM port this would be useful as there are often discussions of which ARM instruction set to support as a baseline. In i386 world, this would be like saying does anyone really run Debian on a 486 any more?, to know when it is feasible to increase the minimum CPU requirements to the benefit of everyone with more recent processors. I would imagine some people would be concerned about anonimity/security issues implied by identifying people's specific CPUs. In our case, the supported instruction set, and maybe whether it has an FPU, is the interesting statistic, not so much the specific silicon in use. I'm not subscribed to this list; please Cc replies Thanks M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktillnzfqhe__avpjhv2hvgkq9tqobi8_boe-_...@mail.gmail.com
Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)
On 7/15/10, Loïc Minier l...@dooz.org wrote: armel can also use vfp instructions, so I personally find it confusing. No it can't. Any binary that contains a vfp instruction will die with SIGILL on any armv4t chip that has no vfp cpu, so cannot be used in Debian armel. As far as the ABI is concerned, the new roposed one specifically uses VFP registers to pass FP arguments, so the new arch would require a VFP coprocessor. In any case, we're free to use the vendor field, but that shouldn't be used in upstream software. +1, if we must have a new GNU name. arm-hardfloat-linux-gnueabi Would probably work with most existing build scripts arm-linux-gnueabi_hf Would probably require modifying again every build script that has already been modified to recognize -gnueabi - to make it do the same as it would have done for -gnueabi, which seems like creating pointless extra work for other people... (BTW in the thread Richard Earnshaw makes the point that FPA isn't leagel in EABI and that maverick is incompatible with it, so I think this is another reason not to have vfp in our new port's name) You must have misunderstood what Richard said. I use Maverick hardlfoat in EABI and provide a repository of Maverick hardfloat debian packages for Debian armel. It all works fine. You're right that FPA hardfloat won't work with it, because the ABI specifies FP storage format and FPA's storage format is different (45670123 mixed-endian). However, since the new ABI would mandate passing floating point values in VFP registers, that knocks any other incompatible FPUs out of the water anyway. As regards what ARM Ltd want: to stamp their cortex trademark on a Debian port and to get Debian to optimise an architecture for (and mandate the use of) the very latest version of their product line, this is not necessarily in the best interests of the users or the developers of Debian. THe users would be best served by a supporting the least-common-denominator VFP instruction set that runs on as many chips as possible, which seems to mean a baseline VFP with 16 registers. I still doubt that the disruption and extra work for the community of Debian package maintainers, and the lower quality of the resulting archive, is worth the small increment in speed that is promised. I hope M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikbjxslnllwotrsk4zw0_nwpf1u-b2oic8mb...@mail.gmail.com
Re: armelfp: new architecture name for an armel variant
On 7/11/10, Bill Gatliff b...@billgatliff.com wrote: But then doesn't that mean that everything is armel, so we never have a hope of having Debian officially support more than one combination? Well, armel should be as generic as possible. In an ideal world, it would be called arm and run on pretty much all ARM processors. After all, Debian's tagline is The Universal Operating System, while cpu-specific tweaking is the speciality of Gentoo, OpenEmbedded and so on. But, since arm was already taken, and it used emulated hardfloat instructions instead of softfloat, the main advantage of facing the pain and embarassment of a new port was that it would make FP 11 times faster on all ARM CPUs, as well as permitting use of real FPUs, making it 30 or 40 times faster. That's the difference between encoding a 30-second MP3 in a minute or encoding it in 2 seconds. The argument in favour of yet another ARM Debian arch (making four so far) is the figure of another 30% being waved about. Not another factor of 30, just another 30%, and presumably that figure comes from beating some worst-case situation to death. Actual figures would be nice. I'm ok with that, actually--- an ecosystem of unofficial armel repositories cropping up containing optimized packages for specific configurations. Yes. That is the right way to go to leverage FPUs in the Debian framework, and was one of the justifications for the upheavals that the armel port caused. Where does this 30% figure that's been floated around for hardfloat ABI over softfloat ABI with VFP instructions come from? Do we have any actual measurements? Wanting to politick a fourth Debian ARM architecture into dpkg, with all the work that involves for other people, just to get a few percent speed increase in a few packages doesn't seem worth doing. You can get a 3 or 4 times speed increase with an FPU-specific armel repository, which is a mechanism well suited to supporting specific combinations. It doesn't seem worth causing all that pain again just to get an extra 30% of frames per second in glgears. It's an optimization, yes, but look at the cost. M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikcay4wm1vgdvnt-irv5b357esxpu6fyebw4...@mail.gmail.com
Re: armelfp: new architecture name for an armel variant
On 7/10/10, Hector Oron hector.o...@gmail.com wrote: 2010/7/10, Martin Guy martinw...@gmail.com: What are the effects of the name choice? If we pick up the wrong name, then we would need to start over the bootstrapping again, and we would like to avoid that. Sure. So my question was what are the technical impacts of the string chosen as an arch name? -or- What would make it 'wrong'? I also remember debian-arch =~ arm* being used in some cases, again suggesting as arch name that starts with arm I had look in a small amount of packages from base and I could not find any reference to this string you are suggesting. In anyway, this is wrong and should use `dpkg-architecture'. Could you find a case where this happens (please avoid toolchain packages)? Sorry, I didn't mean that literal string, I meant changes to build scripts where the architecture name is fished out and matched against a pattern beginning with arm, for example in shell script case statements or in Makefiles using that awful findstring syntax. The only examples of Debian arch name matching in the Debian patches that I submitted in 2008[1] are those for afnix and plplot, and both compare $DEB_BUILD_ARCH with a constant string: arm and armel respectively. Of those two, plplot will need updating to armel || armwhatever The only arm* I have is in mozart's config.guess; which, I think, is matching against the first part of the GNU triple. It then puts __ARM_EABI__ through cc -E to detect EABI usage, rather than using the DEB_BUILD_ARCH, so that one should be ok. I don't know about the patches made by others; it may be possible to fish them out of the debian bug tracker as, thanks to Riku's foresight, they should be tagged with Usertag: eabi and User: debian-arm@lists.debian.org Another check for packages patched for armel is to search the bug tracker for bugs submitted by martinw...@yahoo.it (as I was then), which will catch modifications that were made upstream, instead of in Debian. Lastly, going through the old versions of http://wiki.debian.org/ArmEabiProblems via the info link will give lists of packages that needed fixing for armel. Even once the bootstrapping is done, adding a new architecture to Debian is a lot of work. M [1] http://martinwguy.co.uk/martin/arm/debian/patches -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimx4jltfb9nnitjvqs4r3si8r6dq9kjwlago...@mail.gmail.com
Re: armelfp: new architecture name for an armel variant
On 7/9/10, Hector Oron hector.o...@gmail.com wrote: I prefer 'armhf', FWIW. Somebody against 'armhf'? Have we got it? And for the triplet, is it OK to use vendor tag as explained in the wiki page[1]? arm-hardfloat-linux-gnueabi or armhf-linux-gnueabi What are the effects of the name choice? Is it really just a matter of personal taste? Can we just as well call it sprongly? Or is, for example, armsprongly more likely to give less grief? Or is armelsprongly even better? This depends on the patterns recognized by existing config and build scripts. From the EABI port I remember build files being changed to recognize the tuple arm*-linux-gnu*, hoping to future-proof themselves, so that would seem wise to follow. I also remember debian-arch =~ arm* being used in some cases, again suggesting as arch name that starts with arm If the name really is totally arbitrary, I'd suggest using something that reflects with as much precision as possible, the target of the port, such as armv7, armvfp armvfp3. That leaves the gate open to future neon ports, vfp4-32 ports, thumb2 ports and (gak!) maverick ports, without asserting that in all cases fp means vfp means vfp3-16 There is another technical question WRT the triple: that is be a valid GCC configuration triple, for which, in FOO-linux-gnueabi, FOO be a valid argument of the -march= flag. It would be well for the vendor string to correspond to whatever the compiler returns as a version string, though I understand that it really needs to corrispond to arm-*-linux-gnueabi Cheers M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktim2bz8na8uuidyh-yuzoismmaow8cblhyrka...@mail.gmail.com
Re: armelfp: new architecture name for an armel variant
Hi if you make a new port name, remember that you'll have to submit hundreds of requests for package maintainers to modify control files and build scripts so that things are built for the new architecture and in some cases so that all binary packages are produced for that architecture. I remember that taking most of a year for the armel port and persistent mail to package maintainers and provision of test machines over ssh. It means changing every package that has an Arch: list anywhere is its control file. Worse yet, some packages build their binary packages or not in an arch-dependent way, and the only way to check that is to download and unpack every source package and run through its contents with a script. That is one argument for just calling it armel and hosting the hard FPU variants in their own separate repositories. That way you'll get a higher quality release thanks to all the QA that was done for armel and you won't have to spend a year pestering dozens of DDs. Although they were almost always cooperative (eventually) and usually polite, no one was happy to have to modify their packages just to add yet more arch names to the lists. Any mistake by users trying to mix the regular armel packages and the hardfloat ABI ones would just fail immediately. Just a thought M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinazkpasntqvqobokkqiajeuxbf5aazh0s_g...@mail.gmail.com
Re: armelfp: new architecture name for an armel variant
On 7/9/10, Martin Guy martinw...@gmail.com wrote: Any mistake by users trying to mix the regular armel packages and the hardfloat ABI ones would just fail immediately. Erm my mistake. *Should* fail immediately but don't. I just ran some tests on Maverick hardfloat in a Debian armel environment, and gcc-4.2 and 4.3 happily link -mfloat-abi=hard and -mfloat-abi=soft objects together to give executables that return complete rubbish. So it looks like a new arch name is necessary to stop people mixing the package types. :( M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimopgnbh38vofajag7vh-ymk1wckswjam6mx...@mail.gmail.com
Re: Machine similar to ancina anyone? (was: DM needs helps with build failure (yorick on armel))
On 5/7/10, Luca Niccoli lultimou...@gmail.com wrote:
On 7 May 2010 10:58, Thibaut Paumard mlotpot.n...@free.fr wrote:
This is the info I got from Stephen Gran on d-admin:
Processor : Feroceon rev 0 (v5l)
$ cat /proc/cpuinfo
Processor : Feroceon 88FR131 rev 1 (v5l)
Processor bug that was corrected in a later revision?
A search for Feroceon rev turns up a different theory:
http://old.nabble.com/Re:-gcl-and-reverse-dependencies-on-arm-td27347704.html
which suggests that it may be an old-ABI kernel system call or an
unemulated FPA floating point instruction) that would not fail on
machines with standard Debian kernels, which have old-ABI emulation
and FPA emulation) enabled.
A quick grep in the source turns up
play/unix/fpuset.c:332
#elif defined(FPU_GCC_ARM)
void
u_fpu_setup(int when)
{
if (when = 0) {
unsigned int fpucw = 0x70200;
__asm__ (wfs %0 : : r (fpucw));
/* includes bit to trap on signalling NaN (may affect libm behavior) */
}
}
#elif defined(FPU_IGNORE)
void
u_fpu_setup(int when)
{
}
where wfs is an old FPA instruction. Unfortunately, the
play/unix/config.sh chooses a GCC_FPU_* macro by testing whether this
file compiles, not whether it runs.
The change from arm to armel (old-ABI to EABI) dropped the use of
hardfloat instructions for the FPA and switched to softfloat, also
allowing the use of VFP or Maverick FPUs if the user recompiles the
package with magic runes.
A quick hack to remove the FPA instruction and just not handle
signalling NaNs on armel is
- #elif defined(FPU_GCC_ARM)
+ #elif defined(FPU_GCC_ARM) !defined(__VFP_FP__) !defined(__MAVERICK__)
but a quick look at the compaint from the build log suggests that this
removes all handling of SIGFPE, including the uses that don't depend
on signalling NaNs. Maybe you have a better idea than me of what
functionality yorick really needs from the FPU exceptions and how to
find a better compromise.
See http://wiki.debian.org/ArmEabiPort#GCCpreprocessormacrosforfloatingpoint
for the non-obvious meaning of these defines (__VFP_FP__ does not mean
you have a hardware VFP FPU, it is about floating point storage
format)
Other gurus may be able to suggest alternatives that will work when
softfloat and/or VFP are selected. No one really cares about Maverick
FPUs as they are more rare - I just mention it here to get the ifdef
right.
Sadly, the fenv(3) family of functions doesn't handle the signalling
NaN exceptions, which is what yorick really needs here.
Hope that helps
M
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/aanlktimtrctcofniz7vhhyxna7seaqcjjev3zglpz...@mail.gmail.com
Re: Thecus N2100 recovery
On 3/17/10, jl.050...@gmail.com jl.050...@gmail.com wrote: My Thecus N2100 ran well for years. Then, the hard disk failed. To prepare to install a new hard disk, I tried arping/telnet approach as per: http://www.cyrius.com/debian/iop/n2100/telnet.html but telnet times out: The page says: In old firmware versions of the N2100, no IP address is set in RedBoot so it's not possible to connect to it by telnet. So I guess you need to connect the serial console and/or put a new debian base filesystem on a new disk using some other host. M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/56d259a01003170341g12b4760fw853c006604e34...@mail.gmail.com
Re: Bug#573712: gem: FTBFS on armel (assembler erorrs)
On 3/16/10, Adam D. Barratt a...@adam-barratt.org.uk wrote: gem fails to build on armel with assembler errors. From the build log: g++ -c-I/usr/include/lqt -fopenmp -I/usr/include/ImageMagick -I/usr/include/lqt -I/usr/include/avifile-0.7 -I/usr/include/FTGL -I/usr/include/freetype2 -I.. -I/usr/include/FTGL -I/usr/include/freetype2 -g -O2 -fPIC -freg-struct-return -O3 -falign-loops=32 -falign-functions=32 -falign-jumps=32 -funroll-loops -ffast-math -g -O2 glew.cpp -o ../Objects/glew.o /tmp/ccGNAhDI.s: Assembler messages: /tmp/ccGNAhDI.s:1194: Error: bad immediate value for offset (4148) /tmp/ccGNAhDI.s:27942: Error: bad immediate value for offset (4112) Try dropping the apparently pointlessly picky options =32? M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/56d259a01003161644h116d25b0y3de02d42fc98e...@mail.gmail.com
Re: Help needed to debug an armel build/unittest failure
On 3/12/10, Iustin Pop iu...@k1024.org wrote:
I also tried two compiler versions, 4.4 (4.4.3-1) fails unittests but 4.3
(4.3.4-6) passes them.
While trying to debug this under gcc 4.4, I managed to add some code to an
inlined function that makes the problem go away. Original function version:
inline int64 WireFormatLite::ZigZagDecode64(uint64 n) {
return (n 1) ^ -static_castint64(n 1);
}
I wanted to add some ugly logging to the function, so I modified it as
follows:
inline int64 WireFormatLite::ZigZagDecode64(uint64 n) {
int64 v = (n 1) ^ -static_castint64(n 1);
printf(zzd64:%llu r:%lli\n, n, v);
return v;
}
It seems this changes something, because now the unittests pass (inline,
optimization, problems?). I honestly don't know what's happening here,
but this seems more and more like some compiler-related issue (but not
necessarily 64-bit-related).
Well, GCC 4.4 does have some code-generation bugs that 4.3 and 4.5 don't.
Example: http://gcc.gnu.org/ml/gcc/2010-03/msg00108.html
Unfortunately the gcc list archiver was broken when someone replied so
I am forwarding the whole reply here, including the original message,
but it doesn't look much like the case you have found.
If you can mangle the code so that 4.4 compiles it correctly I guess
that would do it, or you could insist on gcc-4.3 for the moment, which
is also in squeeze.
M
-- Forwarded message --
From: Richard Guenther richard.guent...@gmail.com
Date: Mar 10, 2010 10:17 AM
Subject: Re: Incorrect casting?
To: Marcin Baczyński marb...@gmail.com
Cc: g...@gcc.gnu.org
2010/3/9 Marcin Baczyński marb...@gmail.com:
Hi,
the following piece of code produces different output on svn trunk and
gcc-4_4-branch:
#include stdio.h
int main()
{
struct { unsigned bar:1; } foo;
foo.bar = 0x1;
printf(%08x\n, (unsigned char)(foo.bar * 0xfe));
printf(%08x\n, (unsigned char)(foo.bar * 0xff));
return 0;
}
monst...@yggdrasil /data/tmp $ gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-svn/configure --enable-stage1-languages-c
--enable-languages=c,c++
Thread model: posix
gcc version 4.4.4 20100309 (prerelease) (GCC)
monst...@yggdrasil /data/tmp $ ./a.out
00fe
0001
monst...@yggdrasil /data/tmp $ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-svn/configure --enable-stage1-languages-c
--enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20100309 (experimental) (GCC)
monst...@yggdrasil /data/tmp $ ./a.out
00fe
00ff
Is there something illegal in this code or is it a bug somewhere?
Probably something that was fixed for 4.5 but not backported to 4.4.
The 4.4 C frontend produces for the 2nd printf:
printf ((const char * restrict) %08x\n, (int) -foo.bar);
while 4.5 does
printf ((const char * restrict) %08x\n, (int) -(unsigned char) foo.bar);
I'm not sure where this difference comes from (and I can't convince
myself that this is a real fix). Please file a bugreport.
Btw, 4.3 produced
printf ((const char * restrict) (char *) %08x\n, (int) (unsigned
char) ((int) foo.bar * 255));
and the same runtime result as 4.5.
Thanks,
Richard.
Thanks,
Marcin
---
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/56d259a01003131309t296f748ev63cac7a02d1bc...@mail.gmail.com
Re: Help needed to debug an armel build/unittest failure
On 3/7/10, Iustin Pop iu...@k1024.org wrote: So it looks like what we're actually seeing here is one bit of corruption. I still strongly suspect a compiler bug. Probably the compiler's emulation of 64-bit arithmetic is broken in some way. First, are you aware of 64-bit arithmetic issues on arm(el)? No, I know of no 64-bit arithmetic issues in any armel GCC. OpenSSL uses 64-bit int math and its testsuite passes fine. The main ARM issue is requiring 4-byte alignment of 4-byte word accesses (and 2- of 2-) with silent data corruption if you access an unaligned word. You can test for that by going # echo 5 /proc/cpu/alignment and running your test again. On unaligned access the program will then die with SIGBUS instead of merrily going on its way with corrupted values. I thin The main ARM and armel idiosyncracies are listed at wiki.debian.org/ArmEabiFixes However, there are four versions of GCC - 4.[1234] - installed here if you'd like to probe that theory. M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/56d259a01003110436w309f5a29mbecaf4dfc10f4...@mail.gmail.com
Re: Very newbe help/pointers required about building a distribution from scratch
On 3/10/10, Luke Kenneth Casson Leighton l...@lkcl.net wrote: ... where is all this documented? has anyone actually done this - documented and automated e.g. how the debian-armel port was created, when previously there was only the debian-arm one? There is a huge difference between recompiling packages of an existing port with cpu-specific options and making a new port. I collected the closest I got to useful advice for a new port at the bottom of wiki.debian.org/ArmEabiPort I did most of the armel port in 2006, and after being pushed to cross-compile it by the emdebian crowd, it turned out this was impossible because you have to compile most packages natively on the same kind of Debian system. The armel port was mostly bootstrapped by updating Maemo, which was the first very early Debian armel system, if a bit rickety, aged and incomplete (and sometimes plain messy), repairing it as best one could then working up a spider's nest of dependencies between the 117 essential and required Debian packages, some of them circular, to get closer and closer to a full self-building native true Debian system. I got through 91 of them when in August my father was murdered in front of me. Wookey slurped up the .deb's I had built and Buytenhek completed the port in November/December - in his case by Debianizing an ARM EABI OpenEmbedded base system, as far as I can tell. I don't see how much of this could be automated, since every new port depends on the existing work in the field. However, in this case, cpu-optimization, the most effective way to build cpu-optimized packages is to make a wrapper script called gcc (and cc and gcc-4.3 and arm-linux-gnueabi-gcc) in some funny directory, which you prefix to the PATH variable passed in dpkg-buildpackage's environment. There is an example of this (for a rare FPU) at the bottom of the section http://martinwguy.co.uk/martin/crunch/#UsingIt I don't know of any tools to recursively find the runtime package dependency graph for you, but there are perl libraries that will interrogate the package lists for you. For your application you don't need to care about the order of the package build, just an unordered list of the packages that you require to populate your own local repository, then use that. Even easier, just make a rootfs for your system from the standard repository, then query the list of packages installed on that, rebuild those into your own repository, then reinstall your system from that. M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/56d259a01003110559k5e30411cv3bd13e65a59f7...@mail.gmail.com
Re: Help needed to debug an armel build/unittest failure
On 3/7/10, Iustin Pop iu...@k1024.org wrote: Second question would be if it's OK to use agricola to test this Well u can use the 600 MHz 512MB box here if that would help. You access the armel-sid chroot by saying armel-sid :) Suggest a username by private email if that would be of help M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/56d259a01003071618m519f4fccoc9424743252c9...@mail.gmail.com
Re: DM needs helps with build failure (yorick on armel)
Therefore, I don't know what happened on ancina, nor how to fix it. The sigill happens when running the newly-created yorick binary for the first time: make[2]: Entering directory `/build/buildd-yorick_2.1.05+dfsg+cvs20091202-2-armel-CvRsYS/yorick-2.1.05+dfsg+cvs20091202/doc' ../yorick/yorick -batch maked.i make[2]: *** [docs] Illegal instruction I notice that the package has been building successfully sometimes on armel: * 2.1.05+dfsg-4 (latest build at Mar 24 07:05: maybe-successful) * 2.1.05+dfsg-5 (latest build at May 23 22:55: maybe-successful) * 2.1.05+dfsg-6 (latest build at Jul 16 22:19: maybe-successful) * 2.1.05+dfsg-7 (latest build at Nov 16 14:24: maybe-failed) * 2.1.05+dfsg+cvs20091202-1 (latest build at Dec 3 10:54: maybe-successful) * 2.1.05+dfsg+cvs20091202-2 (latest build at Jan 15 11:30: maybe-failed) The successful builds are on all6500-2, muscat, allegri and arcadelt and both of the failures are on ancina, which is listed as a Marvell Development Board of unspecified CPU. Before I go off into integer alignment issues, can someone say what CPU ancina has, please? Ta M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/56d259a01002170403q1c2f903dse4c7da4643339...@mail.gmail.com
Re: genesi and open rd
On 2/8/10, Karsten König re...@gmx.net wrote: So Debian will run on both as it is built for the ARMv5 architecture ARMv4t (so it will still run on both) M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: genesi and open rd
On 2/8/10, Bill Gatliff b...@billgatliff.com wrote: OT, but has anyone looked at what gains can be had by rebuilding packages with, say, A8 or other optimizations for processors that support them? Well, it has a VFP FPU, so floating point apps will run N times faster, and GCC optimizes some kinds of integer loops into SIMD instructions for the NEON, beside the different instruction timing info and pipeline description for better instruction scheduling. The easiest way to try this is to make fake versions of gcc and put them at the start of the PATH: mkdir ~/cortex cat ~/cortex/gcc EOF #! /bin/sh exec gcc-4.3-crunch -mcpu=cortex-a8 -mfpu=vfp -mfloat-abi=softfp $@ EOF chmod 755 ~/cortex/gcc ln -s gcc ~/cortex/cc ln -s gcc ~/cortex/gcc-4.3 ln -s gcc ~/cortex/arm-linux-gnueabi-gcc and fool the build system into using them PATH=~/cortex:$PATH dpkg-buildpackage -rfakeroot -B I'd be interested to know what difference it makes to non-FP applications M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: genesi and open rd
On 2/8/10, Karsten König re...@gmx.net wrote: OT: Are there plans to raise this to ARMv5 or even higher after Squeeze? Or are the benefits not worth dropping the older devices? I hope not. armv4t is pretty widespread in single-board computers, while the v5 benefits are vanishingly small: one extra instruction that only really helps the softfloat division assembly routine. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: FPC does SIGILL in armv4t
strd/ldrd were first introduced in armv5t
Architecture v5TE and later processors provide LDRD and STRD
instructions to load/store 64-bit data, e.g. to access 64-bit
peripherals. These behave similarly to LDM/STM of two registers.
ldrd just loads 64-bit data (ok, atomically) into two registers.
LDRD r0,[r6]
seems to be equivalent to
LDM r6, {r0,r1}
Best ref I could find were
LDRD: http://www.rz.uni-karlsruhe.de/rz/docs/VTune/reference/INST_LDRD.htm
Correct me if I'm wrong.
M
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: anyone interested in grouping together to get better pricing than $130 on ARM 7in Netbooks?
On 1/31/10, Michelle Konzack linux4miche...@tamay-dogan.net wrote: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItemitem=380171647291#ht_3021wt_984 I think I should inform the eBay Staff about this Item. They are making Publicity with a VERY high quality AUO B089AW01 but selling in the describtion an inexpensive LG/Philips LP089WS1-TLA2. The AUO one is medical/industrial certified, but the LG/Philips not. This is definitively fraud. No, the advert is perfectly clear as to what part they are selling. It's normal to pack the title line with the most common search terms you think people are using. If someone buys that thinking they'll be getting an BO part, they must be unable to read. M What's this got to do with debian-arm? -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: perl: arm non-IEEE fp rounding patch obsolete?
On 1/31/10, Niko Tyni nt...@debian.org wrote: I'm looking at non-upstreamed Debian perl patches, and I figured I'd check with you before dropping this one from 5.8.7-9 (Dec 2005): http://patch-tracker.debian.org/patch/series/view/perl/5.10.1-9/debian/arm_fp.diff Subject: Skip two Math::Complex tests on the arm architectures. Some tests fail on ARM due to non-IEEE fp rounding rules in the kernel fp emulation. The skipped tests pass if I unapply the patch and run the tests on agricola.d.o. Is there a chance this is still needed on systems without a floating point coprocessor or something like that? The Debian ARM port has changed from kernel emulation of hardfloat FPA instructions to userspace softfloat which is 100% IEEE conformant, so that patch is no longer needed. M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: anyone interested in grouping together to get better pricing than $130 on ARM 7in Netbooks?
i just wish these manufacturers would get their act together and produce 9in and 10in ARM netbooks. there seems to be some sort of mis-match (of their own expectations) that a 600 or 700mhz ARM CPU somehow wouldn't be good enough to run a 1024x600 or 1280x800 LCD, It's not a CPU performance issue, but about reducing the cost of the components; the physical display panel is a pricey item; board, chips, sockets and assembly can be done fairly cheaply. Remember the early home micros, when the priciest item on the list was the keyboard? :) M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: I need fast ARM Hardware for native compile
If you just need a Debian arm/armel development environment, there is a 600MHz 512MB big-disk armv5t you can use here over ssh. If that's useful, mail me privately suggesting your preferred username M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#547503: git-core: git clone fails on armel
Hi folks git clone fails on my Debian armel system: Just to say, there's a 500MHz 512MB armel-sid box here n2100.martinwguy.co.uk that you can use for compilation and over ssh if that's useful - just suggest a username by private email. Good luck! M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: doubt
On 11/3/09, rajagopal venugopal raj3...@gmail.com wrote: my doubt is whether i can use my own kernel for for my own arm hardware and make the kernel work with debian GNU/Linux Yes. I do this all the time. You may get problems if your kernel configuration is very different from the config that debian kernels use - if it lacks things like udev for example, but in general the Debian filesystem seems quite tolerant of most config differences. If you are building a kernel with module support, you will need to add the modules under /lib/modules in your root filesystem. Example (from the kernel build directory, assuming you have your rootfs mounted on /dev/sda1)): INSTALL_MOD_PATH=/mnt/sda1 make modules_install Good luck! M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Apt alignment trap.
reassign 548842 gcc-4.3 4.3.4-2 thanks On 10/9/09, John Reiser ven...@bitwagon.com wrote: Some shared library has been built with an initialized pointer, where the storage for the pointer itself is not aligned on a 4-byte boundary. The problem is not in glibc(ld-linux); the problem lies in some shared library that the app requires. Debug this via setenv LD_DEBUG reloc ./my_app args... Thanks! It seems to affect any C++ program on armel, including hello.cc mar...@n2100:~$ LD_DEBUG=reloc ./a.out 6836: 6836: relocation processing: /lib/libc.so.6 (lazy) 6836: 6836: relocation processing: /lib/libgcc_s.so.1 (lazy) 6836: 6836: relocation processing: /lib/libm.so.6 (lazy) 6836: 6836: relocation processing: /usr/lib/libstdc++.so.6 (lazy) Bus error and libstdc++.so.6 seems to be provided by gcc-4.3, so I'm reassigning the bug... -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#546823: __thread usage in libcap-ng0 broken on armel
On 9/28/09, Pierre Chifflier pchiffl...@edenwall.com wrote: On Sat, Sep 26, 2009 at 04:28:36PM +0100, Simon McVittie wrote: ARM porters: can you shed any light on this? As I have no armel platform here (and no knowledge specific to the architecture), some help would be appreciated. There is a big fast armel box here you can use over ssh. Just suggest a username by private email. It is also set to give Bus Error on misaligned data accesses instead of the default behaviour of returning garbage values, which often helps catch mysterious bugs. M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: alignment errors on armel: what to do?
On 9/28/09, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: after dealing with #548815, i'm a little bit concerned about the behavior of the kernel in the face of alignment errors on armel. i've read http://bugs.debian.org/397616 and followed the references in there, so i think i understand why the default is to silently fail when alignment errors happen. However, it seems like we should still be filing bugs against packages which trigger alignment errors, no? Absolutely. i just turned on warnings in an NSLU2 running squeeze (a buildd for me) and note alignment warnings from several processes: should we be filing bugs for each of these? Oh yes Should we be doing anything else? Making unaligned accesses cause SIGBUS errors is even more enlightening, though I wouldn't recommend it for a production machine. For example, sid's apt-get is currently Bus erroring as soon as it starts up, which makes things a little difficult... An argument against enabling fixup is that it papers over bugs so they remain undetected, while the fixup code is incredibly slow. A recent example which should have run in under a second took three hours with fixup enabled, which makes for programs that are silently and invisibly much slower on ARM CPUs than usual. M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: alignment errors on armel: what to do?
On 9/29/09, Daniel Kahn Gillmor d...@fifthhorseman.net wrote:
char f[4];
void test(char* x, short z) {
short* y = (short*)x;
*y=z;
}
int main(int argc, const char* argv[]) {
test(f,argc);
return 0;
}
any idea why gcc would lay out the memory differently for armel than for
i386? i haven't tried it on the old arm architecture.
Well, char arrays are char-aligned, so no surprise there! If you put
an int i before the char f[] you get char f[] word-aligned.
It turns out that something in the C startup needs a byte of data, so
your array comes after that at an odd address
$ nm a.out | sort
...
000105ac A __bss_start__
000105ac A _edata
000105ac b completed.5827
000105ad B f
000105b4 A __bss_end__
000105b4 A _bss_end__
...
Though quite what completed.5827 may be I have no idea!
M
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: alignment errors on armel: what to do?
On 9/28/09, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: i just turned on warnings in an NSLU2 running squeeze (a buildd for me) and note alignment warnings from several processes: pdftex (reproducable with aptitude reinstall texlive-base-bin) aptitude (also reproducable with aptitude reinstall texlive-base-bin) apt-extracttemplates (reproducible with apt-extracttemplates /var/cache/apt/archives/patchutils_0.3.1-2_armel.deb or any .deb) grotty (reproducible with man gpgv) gpgv (reproducible during aptitude update, haven't narrowed it down further) /usr/lib/apt/methods/http (reproducible during aptitude update, also haven't narrowed it further) OK. I've added a section to http://wiki.debian.org/ArmEabiProblems listing the affected programs (the above and a couple of others I've noticed. My reason for doing this, instead of just filing bugs, is that while you're chasing one down, others pop up, so this forms a kinds todo list. The fixes are usually trivial when you find them: add __attribute__((aligned(4))) to something. Ideally I see the items in this getting annotated with the bug numbers when they're filed and removed when they are resolved. Does that sound like a reasonable way to tackle them? M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: FTBFS on armel: 'OV_CALLBACKS_STREAMONLY' undeclared
On 9/21/09, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: I should note that i have some concerns about tremor on armel in general that haven't been addressed by upstream (and i haven't been able to sort out): http://lists.xiph.org/pipermail/tremor/2009-April/001564.html Maybe this update will cover those changes as well. I just tried this, and it's doing a misaligned word access: $ gdb ./ivorbisfile_example.armel (gdb) run *ogg armel Starting program: /home/martin/cluster/arm/libvorbisidec-debug-2009-04-24/ivorbisfile_example.armel *ogg armel Bitstream is 2 channel, 44100Hz Decoded length: 324300 samples Encoded by: Xiph.Org libVorbis I 20070622 Program received signal SIGBUS, Bus error. 0x4004eaa0 in ov_read () from /usr/lib/libvorbisidec.so.1 (gdb) To get the bus error you need to have # echo 5 /proc/cpu/alignment the default setting (0) silently returns junk, specifically, the word from addr~3 rotated by (addr3)*8 bits, which is less than useful. Another setting, 3, catches the alignment trap, fakes the right thing in the kernel and returns what you would get on a byte-aligned machine; that would quickly tell you whether fixing the alignment error will fix the problem. M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: FTBFS on armel: 'OV_CALLBACKS_STREAMONLY' undeclared
On 9/21/09, Martin Guy martinw...@gmail.com wrote: I just tried this, and it's doing a misaligned word access: Sorry, my mistake. It's pumping misaligned half-word (16-bit) accesses, which again returns some form of garbage, probably either the correct value if it's from the middle of a 4-byte word or some combination of the word's top and bottom bytes if the halfword straddles a 4-byte boundary. The fixup trap is incredibly slow, so the whole test will take 3 hours but the first 65536 bytes of output are identical to the i386 output, which suggests that this is it M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: FTBFS on armel: 'OV_CALLBACKS_STREAMONLY' undeclared
On 9/20/09, Luk Claes l...@debian.org wrote: Maybe it's an option to revert using libvorbisidec-dev and use libvorbis-dev again on armel to fix the FTBFS of mpd? debian-arm and Joey Cc-ed so they can give input as I'm unsure if current ARM hardware does have floating point support to make this reasonable. armel is soft-float so yes, being able to use tremor would give a huge speed increase. M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: arm port plans for the squeeze cycle
On 8/29/09, Martin Michlmayr t...@cyrius.com wrote: * Gordon Farquharson gordonfarquhar...@gmail.com [2009-08-27 09:33]: Is anybody planning on implementing a scheme to migrate from arm installations to armel, e.g. http://wiki.debian.org/ArchTakeover? Riku was working on this but I'm not sure it got anywhere. Another way to do this possible might be to stop trying to do it in-place on a running system, but to create the new system on different media, then boot the new kernel with that as the rootfs then if that works ok, copy the new system over the old. This saves you from the cataclysmic moment when libc and other essential libraries are replaced, removes the need for a kernel that runs both old and new types of binaries (can the i386/amd64 really run powerpc binaries in emulation mode or vice versa?), doesn't make it impossible on systems with 50% disk usage on the main system and means you can test whether the migration was successful before wiping out the old one. What the person can use for the scratch rootfs I guess varies from device to device, but I wouldn't expect a nontechnical user to be attempting such a thing anyway. Does kexec work between different architectures? That would make the boot-into-scratch-system stage and copy-back phases smoother than making each person fiddle with options in the bootloader. I assume there's some standard Debian interface for installing a new kernel in the original system as part of copyback, whether that be to a grublike loader or into flash memory. M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: arm port plans for the squeeze cycle (fpc bootstrapping)
On 8/26/09, peter green plugw...@p10link.net wrote: From what i've heared gpc and fpc are far from compatible, I don't have personal experiance with gpc though. Yes, that is the impression I got from various people whose programs only compile with fpc M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: arm port plans for the squeeze cycle (fpc bootstrapping)
I looked at this in spring 2008. From http://wiki.debian.org/ArmEabiProblems#fpc --- fpc Free Pascal compiler, a.k.a. fp-compiler. Exists in sid for arm, i386, amd64 and powerpc. Requires itself to compile itself and contains cpu-specific code generators: the arm one may or may not work unmodified on armel. Porting it means cross-compiling it, installing the cross-compiled version and using that to build the package, as well as possibly modifying its code generator for EABI. An alternative is for dependent packages to move to (or also accept) gpc, the GCC-based pascal compiler (wishlist bugs have been filed where appropriate). -- M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: arm port plans for the squeeze cycle
On 8/18/09, Martin Michlmayr t...@cyrius.com wrote: Do we have anything to report here? IMHO, any release date will work fine for the ARM port since there are no major issues or transitions. Just checking, as I'm outside the Debian ARM inner circle... Is the arm port being dropped in squeeze in favour of armel as planned? Cheers The Other Martin -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: arm port plans for the squeeze cycle
On 8/18/09, Colin Tuckley co...@tuckley.org wrote: ada? An arm-linux-gnueabi native gnat-4,4 toolchain has appeared http://gcc.gnu.org/ml/gcc/2009-08/msg00282.html Just needs someone to apply the patches to the debisn gcc-4.4 and bootstrap the thing Untested, but hey! M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Newbie problem.
On 6/5/09, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: There is friendlyarm selling, using Samsung S3C2440AL-40 chip. I wonder if debian-arm supports that. Hi There are two versions of Debian for ARM processors. The old arm version of Debian runs on CPUs that support the armv4 instruction set (StrongARM devices or later). The new armel version needs armv4t instruction set (ARM7TDMI CPUs and later). In the current stable release of Debian (lenny) both are supported as we change over - the old arm arch will be not be supported in the next release of Debian, which will happen in a year or two. The S3C2440 runs the armv4t instruction set, so you can use either of the versions, but you should use the new armel version as it is much faster for some operations and will continue to be updated in the future. See wiki.debian.org/ArmEabiPort for details on the differences between Debian arm and armel Whether there is an automatic installer for your device depends on the board or device it is part of. If not, you will need to compile a kernel for your device and make (or find) a Debian root filesystem for it. See www.debian.org - Installation instructions - ARM and you will find many tutorials on the web explaining how to install Debian systems on different devices Good luck! M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Need help debugging arm application.
On 5/20/09, Dunge dun...@yahoo.com wrote: We are developing an application for a TS-TPC-7390 ARM device with Debian as the linux distribution. We are using many libraries (glibc, gdk, gtk, gtkmm, pango, cairo, etc). It also uses multiple threads. The program compiles and execute fine (a bit slow, but fine). The 7390 has an FPU that is not being used. If you can identify which libraries are using much floating point, you can get a 2.5 to 4 times speedup by recompiling them with a special, modified GCC (or asking me to). See martinwguy.co.uk/martin/crunch I'm currently in the process of fixing a bug. It only happens when executing on the arm device (works fine on x86). It happens randomly, only on user input (click on a widget), but any widgets on any page can crash it. Sometime it's the first click, sometime it takes 5mins of random clicking, and sometime it never crash until we restart the application. A favourite is a 32-bit word access that is not aligned to a 4-byte address. Setting /proc/cpu/alignment to 3 or 5 can help you see if this is the cause, but see also wiki.debian.org/ArmEabiFixes for other arm/el gotchas to watch for. M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Need help debugging arm application.
unfortunately the download link on the website is invalid ( http://simplemachines.it/tools/gcc-4.3-crunch_4.3.3-20090322_armel.deb ) Thanks for pointing that out. However there's little difference between that and the 20090319 version (see the changelog), and unless your application is FP-intensive I'd recommend sticking with the standard compiler anyway. I have yet to find out which, if any, components of X and gtk+ make extensive use of floating point, if any. I also tried to set 3 in /proc/cpu/alignment . While the crash don't seems to happens in the same time, I once had this line printed out with dmesg: Alignment trap: tmg-arm (1233) PC=0x0010ee78 Instr=0xe5932000 Address=0x000f FSR 0x013 That's the kernel trapping and fixing up a misaligned access in your program, so I guess there's your answer. If you set alignment to 5, the process will get a SIGBUS and at the instruction that performs the misaligned access. Under gdb you should be able to pinpoint the offending code. If that turns out to be in a Debian armel package, a bug report is in order. M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Cirrus MaverickCrunch FPU optimized Debian repository available
Hi
I've made a little repository of Debian armel packages available
that are compiled using real MaverickCrunch FPU instructions. The
speedups are between 2.5 and 4 times for audio codecs compared to the
standard softfloat packages.
These are only useful if you are running Debian armel lenny on a
board with a Cirrus Logic EP93{02,07,12,15} processor.
Details of how to use them and how they were built are are under
http://simplemachines.it/debian
I've added +crunch to the standard Debian package names, so they
will be installed in preference to the standard lenny versions but
will be overridden if more recent versions appear in lenny updates.
So far I've just done the floating point intensive dependencies of
Asterisk, OGG and MP3 codecs and the top FP-intensive general-purpose
libraries (the FFTWs and liboil). If anyone would like other
FP-intensive packages adding, just let me know.
M
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problem building gerris on armel: Illegal instruction
On 4/23/09, Drew Parsons dpars...@debian.org wrote: effectively what we have on armel is the situation where FPU_SETCW is NOT in fact available, so fpu_control.h should not be defining it. Thanks. I've submitted a bug report against glibc -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problem building gerris on armel: Illegal instruction
On 4/19/09, Drew Parsons dpars...@debian.org wrote: is in FPU_SETCW, so it's certainly related to Debian patch fpucontrol-bug350595.patch. Maybe The illegal instruction is generated by 274_FPU_SETCW (fpu_trap_exceptions); /usr/include/fpu_control.h: /* This is fmxr fpscr, %0. */ #define _FPU_SETCW(cw) \ __asm__ __volatile__ (mcr p10, 7, %0, cr1, cr0, 0 : : r (cw)) This is a coprocessor instruction issued to an ARM coprocessor which doesn't exist, since armel is soft-float by default and the xscale doesn't have an FP coprocessor. This instruction is for coprocessor 10, which is the VFP floating point unit. But armel defaults to So Illegal instruction is indeed correct. I'd say the bug is in the header file, which is VFP specific. I just tried the softfloat implementation and it returns +infinity for 1.0/x where x == 0.0 without raising an exception, so I would suggest that, if disabling division by zero exception is your only use for the FPU control setting, you can work around it using something like #if defined(__ARM_EABI__) defined(__SOFTFP__) /* ARM EABI soft float silently returns infinities on division by zero */ # else ... FPU_SETCW stuff ... #endif M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
libvorbis patch for armel
Of the flags that -ffast-math sets, turning -ffinite-math-only off again avoids the erroneous optimization. With the attached patch, libvorbis's examples/encoder_example produces the same (correct) output as on arm-oldabi and it makes oggenc work on armel too. M On armel, oggenc creates short output files that decode to the correct amount of silence. This is caused by an optimization bug present in gcc 4.[123] that miscompiles the MAX(x,y) macro, optimizing it away completely. Fixes: http://bugs.debian.org/515949 Analysis: https://trac.xiph.org/ticket/1526 Martin Guy martinw...@yahoo.it March 2009 --- libvorbis-1.2.0.dfsg/configure.in.old 2007-07-25 17:27:00.0 +0100 +++ libvorbis-1.2.0.dfsg/configure.in 2009-03-19 07:44:38.0 + @@ -168,6 +168,12 @@ CFLAGS=-O20 -D__NO_MATH_INLINES -fsigned-char PROFILE=-O20 -g -pg -D__NO_MATH_INLINES -fsigned-char ;; esac + + # Avoid an optimization bug in gcc-4.[123] + case $host in + arm*-*-linux-gnueabi) + CFLAGS+= -fno-finite-math-only ;; + esac fi CFLAGS=$CFLAGS $cflags_save --- libvorbis-1.2.0.dfsg/configure.old 2007-07-25 17:46:37.0 +0100 +++ libvorbis-1.2.0.dfsg/configure 2009-03-19 07:45:54.0 + @@ -19484,6 +19484,12 @@ CFLAGS=-O20 -D__NO_MATH_INLINES -fsigned-char PROFILE=-O20 -g -pg -D__NO_MATH_INLINES -fsigned-char ;; esac + + # Avoid an optimization bug in gcc-4.[123] + case $host in + arm*-*-linux-gnueabi) + CFLAGS+= -fno-finite-math-only ;; + esac fi CFLAGS=$CFLAGS $cflags_save
Re: GCC bug when -ffast-math is set on armel
Thanks for finding this out. Has a bug been filed to the GCC bugtracker? You're welcome, and yes: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39501 M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GCC bug when -ffast-math is set on armel
In case anyone's in a hurry for a working oggenc (libvorbis) or lame on armel, I've dumped fixed packages under http://martinwguy.co.uk/martin/debian/no-finite-math-only I haven't changed the version numbers on the packages, so you need to download and dpkg -i them and they will get replaced automatically by the fixed mainline versions when they are ready and you next upgrade. M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Alignement on ARM
On 3/7/09, Vincent Bernat ber...@debian.org wrote: lldpd, a program of my own, available on https://trac.luffy.cx/lldpd/ , is doing some unaligned memory access. What kind of ARM platform may I setup that would produce no error but incorrect data when reading unaligned int? It depends on the setting of /proc/cpu/alignment. It is normally set to 0, which silently ignores non-aligned accesses and returns garbled data. If you echo 5 /proc/cpu/alignment it should generate a Bus Error instead. I keep a system set up in this mode with public acess for developers. Please write privately suggesting username if access to this would be useful. M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Alignement on ARM
On 3/7/09, Vincent Bernat ber...@debian.org wrote: I have followed the howto available here: http://www.aurel32.net/info/debian_arm_qemu.php to setup an ARM system. However, I have no alignment issues with this platform. What kind of ARM platform may I setup that would produce no error but incorrect data when reading unaligned int? It turns out that qemu does not emulate the ARM misaligned word access behaviour, but has the same behaviour as the host machine's instruction set. You will need to use real ARM hardware. M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Alignement on ARM
[off list] On 3/7/09, Vincent Bernat ber...@debian.org wrote: Unfortunately, I need root access to be able to inject packets. I will try to get access to some NSLU2 platform. Mmm, not that I don't trust you but I have to guarantee the service for other users. If you get stuck, let me know, as I can copy the nfsroot for a different test board, let you rampage in that and then reboot it back into its original rootfs when you have finished. Good luck M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Update on Thecus N2100 support in Debian
On Sunday 15 February 2009, Martin Michlmayr wrote: Since Debian lenny (version 5.0) has now been released (see http://www.debian.org/News/2009/20090214), I thought I'd provide an update on Thecus N2100 support in Debian. - There's still no DMA support, but I will provide an unofficial kernel for lenny that has some DMA patches: http://www.cyrius.com/debian/iop/n2100/dma.html This has increased the measured maximum linear disk reading speed(*) from 39MB/s to 67MB/s. It's been up for a week, sometimes under a heavy workload (big compilations) and has so far proved as stable as a rock. Cheers M (*) # dd if=/dev/sda of=/dev/null bs=1M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: WOL on Thecus N2100
On 12/23/08, Marc Pignat marc.pig...@hevs.ch wrote: Unfortunatly, the only way to power on the n2100 is the button. There is even no way to turn it on after a power loss. Yeah. Even nailing the button pressed doesn't do it. You seem to need another computer, a parallel port, a transistor, a relay and some wiring :( Wookey has achieved something similar for the remote pressing of reset buttons, so maybe schematics are on the web... M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: performance information
Hi! I only get 3 MB/s on a 100Mbps network using a 200MHz ARM CPU because it runs out of CPU to run the TCP network stack. You can find out whether this is your problem by running vmstat 5 on a console while you beat the network/disks to death, watching the CPU - id column. If it goes down to 0, that is your problem. The same may be true of disk access, especially if you are using RAID. Do you have any reason to think that *debian* is particularly slow on this box, or are you just surprised that everything doesn't run at the speed of the fastest hardware specs for every device? M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: performance information
On 11/18/08, Lennert Buytenhek [EMAIL PROTECTED] wrote: Is that the Cirrus ep93xx? If yes, then you're only getting 3 MB/s because the ethernet MAC is lame Yes it is. Thanks for the info M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#503144: FTBFS on armel: gsf-scan, ** ERROR **: Compilation trouble with endianess.
-#if defined(__arm__) !defined(__vfp__) (G_BYTE_ORDER == G_LITTLE_ENDIAN) +#if defined(__arm__) !defined(__ARM_EABI__) (G_BYTE_ORDER == G_LITTLE_ENDIAN) libgsf was fixed a long time ago - before eabi stuff had any sort of plan in Debian. Using __vfp__ seemed like the best test at the time, as recommended to me by pb. I'm not sure when you end up with __ARM_EABI__ defined but __vfp__ not defined in practice, but I agree the change is now correct. I dunno if the build script is setting __vfp__ somewhere. Yes, unfortunately there is no direct test for old-ABI middle-endianness as fas as I can see - you have to test for not everthing else :-/ My best information is that if (__VFP_FP__ || __MAVERICK__) then we store as pure IEEE little-endian, otherwise FPA format. (__VFP_FP__ is also defined when EABI softfloat, because it reflects the FP format, not VFP instructions necessarily) __MAVERICK__ semantically is also an FP format, which happens to be the same. Yeah, it's all crazy. M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#503144: FTBFS on armel: gsf-scan, ** ERROR **: Compilation trouble with endianess.
On 10/29/08, Paul Brook [EMAIL PROTECTED] wrote: The correct macro is __VFP_FP__ If __MAVERICK__ is defined, __VFP_FP__ isn't, but the word order is the same. Thay may not matter much to most folks, but it does a lot to some :) M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#501970: perl: FTBFS on arm: ext/threads/shared/t/stress.t failure
On 10/17/08, Stephen Gran [EMAIL PROTECTED] wrote: This may just be too much for arm - running 50 simultaneous threads doing a million loops may take more than the 30 seconds allowed on some of the older boxes. It failed on a 600MHz armel-sid box, but when I upped the timeout from 30 to 120 seconds it succeeded. The same results hold for the old arm port (under an EABI kerne). $ perl stress.t 1..1 ok 1 (actually took 1m49 real, 58s user cpu) $ perl --version This is perl, v5.10.0 built for arm-linux-gnueabi-thread-multi M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Bug#499746: [PPL-devel] Building still fails on ARM]
On 10/13/08, Michael Tautschnig [EMAIL PROTECTED] wrote: Hi all, is it possible for a non-DD to get temporary access to some ARM machine for debugging those issues? - Forwarded message from Roberto Bagnara [EMAIL PROTECTED] - From: Roberto Bagnara [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED] yes, we received numerous messages on the subject. We are working on the issue. Would it be possible to set up an access to an ARM machine? Yes, just email me privately suggesting a username M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Recommended compile flags for Lenny armel on NSLU2
On 9/22/08, Alan Snelgrove [EMAIL PROTECTED] wrote: CFLAGS= -O4 -pipe -fomit-frame-pointer -ffast-math -mcpu=xscale -mabi=aapcs-linux -mfloat-abi=softfp -mfpu=vfp -mabi=aapcs-linux is the default for armel You may find that you get better performance from -O2, which performs all speed optimisations that do not significantly increase the size of the generated code. Or even from -Os, come to that. Looking at the GCC machine descriptions, I doubt that -ffast-math actually does anything on ARM. While the '-mfloat-abi=softfp' option compiling MPlayer OK it reported Illegal instruction when run. Xscales don't have a VFP floating point coprocessor, so that's correct. But when I used '-mfloat-abi=soft' it compiled and runs OK. -mfloat-abi=soft is also the default in armel Mplayer doesn't detect ARMv5TE unless CFLAGS contains '-mcpu=xscale' Yes, the Debian compiler has been patched to default to armv4t, so that any package you compile will run on any Debian armel system. M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Recommended compile flags for Lenny armel on NSLU2
On 9/21/08, slugmanbashi [EMAIL PROTECTED] wrote: Each time I used the CXXFLAGS settings recommended here, http://libtorrent.rakshasa.no/wiki/LibTorrentKnownIssues . Which are, CXXFLAGS=-O2 -mcpu=xscale -mtune=xscale . Are these CXXFLAGS setting still-valid/the-best for applications compiled on a Lenny NSLU2(IXP420) running armel ? As far as I know, nothing has changed unless your CPU has a hardware floating point unit, which the xscale doesn't. M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Upgrade to armel
On 9/4/08, Mikael Rudberg [EMAIL PROTECTED] wrote: I've tried searching the net for the easiest way of upgrading to my etch-nslu2 to armel-lenny. Is it possible to do a dist-upgrade or is the migration method in the debian wiki (http://wiki.debian.org/ArmEabiHowto) the only method available ? No, fiddling sources.list and doing a dist-upgrade is not an option. The two systems' binaries are incompatible. It may be easier to save your data and reinstall from scratch. In any case you should save that info in case something goes wrong during the conversion procedure. Let us know how you get on Good luck! M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: FTBFS blocking RC bug fixes
On 7/25/08, Luk Claes [EMAIL PROTECTED] wrote: * afnix: ../../../cnf/bin/afnix-aexec: line 78: 25032 Segmentation fault LD_LIBRARY_PATH=$ld_lib_path DYLD_LIBRARY_PATH=$ld_lib_path $pexe $binopt $1 needs to be compiled with g++-4.1 on arm (old-abi only). Is that an acceptable workaround? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: speakup fixes
On 6/29/08, Samuel Thibault [EMAIL PROTECTED] wrote: - install the attached speakup-source package - apt-get source -t unstable linux-modules-extra-2.6 - apply the attached patch to re-enable arm archs and just compile the speakup modules n2100:/home/martin/arm/linux-modules-extra-2.6-2.6.25# patch -p1 ../speakup.patch patching file speakup/defines Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to file speakup/defines.rej patching file defines n2100:/home/martin/arm/linux-modules-extra-2.6-2.6.25# Because it was arm armel sparc not arm armel sparc s390 (applied by hand...) - install any needed dependency - dpkg-buildpackage -B Runs to completion on armel, producing 96 .debs. I don't see a *speakup*deb among them, though - is that right? M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: speakup fixes
Mmm, you probably got the -4 version while my patch was against -5. Indeed - install any needed dependency - dpkg-buildpackage -B I don't see a *speakup*deb among them, though - is that right? Oops, no, I would have expected 8 speakup-modules-*deb packages. I forgot to say you need to run ./debian/rules setup before dpkg-buildpackage -B Oh, I'll set it off again. See you in another 24 hours... :) M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Iceweasel Source Package for armel
On 6/27/08, Joe Foster [EMAIL PROTECTED] wrote: On Fri, Jun 27, 2008 at 9:36 AM, Martin Guy [EMAIL PROTECTED] wrote: On 6/27/08, Joe Foster [EMAIL PROTECTED] wrote: First thanks for the iceweasel and xulrunner builds for armel, works great! Which ones are you using - the ones from the main repository now, I hope. Which repo? Debian (web interface) does not show armel iceweasel I am using simplemachines.it/debian armel-experimental(your's I beleive) Is there a better one to use? Yes, Riku has a later version in sid/unstable (3.0-rc2 I think). You should get it if you apt-get update and apt-get upgrade, as well as the mainline xulrunner. apt-get source iceweasel should get you the right thing from yout friendly local mirror I think. If not, try adding the experimental branch (sorry, i can;t be arsed to look for you right now :) Grabed armel iceweasel-2.0.0.14 and Noo, iceweasel-3.0-rc2 or something similar. Good luck! M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: iceweasel-3.0rc1 for armel available
Someone just pointed out that my xulrunner package had depended on libhunspell-1.1-0 which has since gone and been replaced by -1.2-0, so unless you already happened to have libhunspell-1.1-0 installed, it was not installable. I've just rebuilt it to depend on -1.2-0 M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: armel package building
On 5/22/08, Joe Foster [EMAIL PROTECTED] wrote: I am using the commands you listed below, except my CFLAGS are set in a gcc script that points to either gcc-4.1 or gcc-4.2 for easy change. I can't reproduce your problem, but from the varying messages, and the fact that it fails on all packages, it sounds like you have a shell quoting problem in your script. Can you please copy in exactly, or attach, the complete script that you mention and the exact command line(s) you use to launch it? m4 is pretty boring code that just reads/writes text as far as I know, no special kernel. What specific system are you running the chroot inside of? Do you have any funny environment variables set? Thanks M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: armel package building
configure.in:966 is the AC_OUTPUT(...) line, so would you send the output of autoconf --version too please? There are three versions floating around: 2.13, 2.50 and 2.61 and with various combinations of packages autoconf and autoconf2.13 installed in differnt orders I have seen all three version numbers emitted. However, all versions seem to work with xaos. A secondary issue is that here, with any version of autoconf, the same part of the output goes: dh_testdir ln -sf /usr/share/misc/config.sub ln -sf /usr/share/misc/config.guess autoconf CFLAGS=-g ./configure --prefix=/usr checking build system type... armv5tel-unknown-linux-gnueabi checking host system type... armv5tel-unknown-linux-gnueabi ... gcc -g -I/usr/include -fomit-frame-pointer -DSFFE_USING -DSFFE_CMPLX_GSL -I/home/martin/arm/xaos-3.3/src/include -c -o xldio.o xldio.c ... It looks like the build script is overriding CFLAGS, so this method will not give you a VFP-enabled binary anyway. In fact Debian is not even optimising the compilation of xaos on any architecture. As far as I know there is no single way to set CFLAGS (and CXXFLAGS where appropriate) in debian package builds. It may work for some packages, but you will have to hack debian/rules or other files for others, or play some trick like providing a fake gcc script that inserts extra options on the command line and calls the real compiler, like removing /usr/bin/gcc and replacing it with: #! /bin/sh exec /usr/bin/gcc-4.3 -mfpu=vfp -mfloat-abi=softfp $@ where the magic 4 characters $@ pass on all supplied arguments preserving spacing and quotation, with a similar trick for for /usr/bin/g++ M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Testing build on arm
On 5/5/08, Ludovico Cavedon [EMAIL PROTECTED] wrote: Hi all, I am co-maintaining package wengophone. At the moment it is failing build on arm because of a GCC bug [1] Is there any way for me to test the build on an arm machine before uplading a new version of the package? Yes, your can mail me privately for an account details M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Speeding up aptitude on NSLU2
On 4/28/08, Kurt Pruenner [EMAIL PROTECTED] wrote: starting aptsh is a matter of seconds, while starting aptitude is a matter of minutes... :( On a 600MHz machine with a (slow) hard disk, aptitude takes 4.5 seconds to start up and close down, while on a 200MHz NFS or USB system it takes over two minutes. A lot of this time it is I/O bound, reading the various text files containing package data, as you can see by saying # time aptitude - the real time far exceeds the user+system times, and 40% of the CPU time is spent in the kernel. Part of this is due to an over-clever optimisation of the reading of the text files in libapt-pkg (source package apt, file apt-pkg/tagfile.cc) which results in non-aligned reads of funny amounts. strace aptitude says: read(16, [EMAIL PROTECTED]\nArchitecture: ar..., 25624) = 25624 read(16, \nSHA1: cca5d43ab22967baeb5638d5c..., 25349) = 25349 read(16, BiDi viewer - command-line tool..., 25246) = 25246 read(16, orola\'s 68HC11/12 targets\n The p..., 25122) = 25122 read(16, es, and the filesystem.\n .\n This..., 24845) = 24845 read(16, ersion: 1:2.2.17.20070822-5\nDepe..., 25548) = 25548 read(16, and provides\n several new widge..., 24888) = 24888 read(16, tra\nSection: misc\nInstalled-Size..., 25692) = 25692 cos it's doing its own I/O buffering and using system calls directly to read non-aligned blocks of funny sizes, presumably written by someone who didn't know about the advantages of page-aligned reads of page-sized amounts. If they'd just used stdio it would have done this for them. So the easy answer is speed up your I/O, the hard answer is to reimplement the apt-pkg library's file-reading code to be less clever and more intelligent, followed by execution profiling to find and optimise other hot spots (like building the view). That said, the lenny version of aptitude is better, since it doesn't bother writing out databases that it has not changed M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Fwd: Upgrading from arm to armel
Well, to quote *all* of the personal mail I sent to Tobias... *sigh* -- Forwarded message -- From: Martin Guy [EMAIL PROTECTED] Date: 15.3.2008 22:03 Subject: Re: Upgrading from arm to armel To: Tobias Frost [EMAIL PROTECTED] Are there any problems to be expected because of switching to the armel? Depends what software you want. As yet some of it is missing from the archive, some uninstallable due to incoherence of arch-independent and armel packages in the unstable repository, some packages are unusably buggy. To see whether any of the apps you need are known to be broken, check wiki.debian.org/ArmEabiProblems As far as unstable archive coherence goes it is pot luck at present, though lenny has got to the point where most server-style packages are woking - unstable is currently living up to its name... M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
armel repository news
Hi armel packages are now migrating to testing, so anyone using the EABI port should add a line to /etc/apt/sources.list deb http://ftp.uk.debian.org/debian lenny main and you probably want to keep deb http://ftp.debian-ports.org/debian unstable main deb http://ftp.debian-ports.org/debian unreleased main too, until the main repository catches up with the extra packages that those repositories have. I've also created a trivial repository of the 45 armel packages that I've built but which are not present in lenny or sid or debian-ports, some because they were build dependencies I had to make to compile other things, others that had never been tried on armel and some that are the successful outcome of test builds when simply adding armel to the Architectures lines. That can be accessed by adding deb http://simplemachines.it/debian armel-sid/ and there is also an html index of the available packages under that URL Special thanks to SimpleMachines for hosting this. I've now completed systematic checks for packages that were not enabled in debian/control (or similar) for armel but should have been, including the not listed in Packages:/Architectures: lines problem, and there are now bug reports filed for all of them. All the armel-problematic source packages that I know about now have a paragraph in wiki.debian.org/ArmEabiProblems giving a first analysis of the problem together with their relative importance due to other things depending on them. Getting the armel port into shape now consists of two waiting games and one action: - waiting until all packages already known to work have been built and included in the main archive - waiting until new versions are uploaded in response to the bug reports (all pending ones are also listed in the Problems page) - fixing the package-specific problems listed. My own time on this project is limited, but I can provide access to armel hardware for anyone wishing to help with the last of these three. Bless M --- We know that all human learning occurs between the ages of eight and eighteen because at eight we have all the questions and at eighteen we have all the answers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
armel port status report
Hi I now have some more time to help progress the armel port, and first have analysed the differences between the ftp.debian-ports.org repository, which is no longer updated, and the new official version at ftp,debian.org and mirrors. The good news is that the mainline repo contains the binaries for 106 more source packages, while 22 source packages have gained extra binaries that were not present in the old repo. Of particular note is that several of the fortran-related problem packages have been solved, which enables many other [ackages to be built. The bad news is that the old repo contained binaries for 82 packages that were in sarge or etch but are not in sid, plus 5 that are not currently flagged to be built on arm* architectures. The binaries for a further 51 source packages in sid, which were included in debian-ports, are now missing from the main repo. The upshot of this is that yesterday the completeness of the armel port had dropped to 90.47%, if I remember correctly. From today the buildd admin has stopped posting the necessary stats to unstable.buildd.net, so no one can check there any more (all figures are zeroes) If I understand correctly, the fastest way to improve the mainline armel port would be to schedule the packages for building that are known to work on armel, but whose binaries are missing: Yesterday, these missing ones were already scheduled to be built: bouml clutter-cairo gcj-4.2 iceape ingimp k3b kawari8 kdemultimedia kdepimlibs libetpan washngo These were not: clutter-gst clutter-gtk clutter-perl darcs-buildpackage dballe eikazo exif flashrom gcc-snapshot gimp-plugin-registry haskell-haskell-src haskell-hsql iceweasel inkscape kerry sqlrelay And I don't know whether these were queued or not, because that info is not available today: gp2c kaa-metadata libstatgrab libxklavier liquidsoap lua-zip mailutils mathomatic python-qt4 python-scipy-core rawstudio redland redland-bindings rrootage siege skencil srtp swt-gtk specimen wmbattery wvdial wwwoffle xvmount zsh-beta Lastly, the following have now been fixed to build on armel, and need building: amiga-fdisk libinotify-ruby ltrace lua-gtk shogun spamoracle (though shogun still needs the missing octave3.0-headers from octave3.0 to build, and octave3.0 needs the missing suitesparse) That's from an analysis of the differences between the two repositories. I hope to do something a bit more thorough in the next few days, based on what the repository should be like, and what it is like, rather than on the differences between the old and the new. In the meantime, if anyone would like to suggest a better way than this to collaborate with the buildd admin I'd be pleased to hear. It would also help a lot if another DD would step up to be a second buildd admin for armel, since it seems that there is so much work to be done on a new port that it is too much for one person to handle all of it. Or, if I'm wasting my time trying to improve the efficacy of the buildds, which is where the greatest win currently lies, please feel free to suggest how else I should spend my time on this project. Thanks M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: armel port status report
2008/3/4, Riku Voipio [EMAIL PROTECTED]: On Tue, Mar 04, 2008 at 03:12:47PM +, Martin Guy wrote: plus 5 that are not currently flagged to be built on arm* architectures. please file bugs against the respectice packages if those are mistakes. Of course. If I understand correctly, the fastest way to improve the mainline armel port would be to schedule the packages for building that are known to work on armel, but whose binaries are missing: Well you don't understand correctly. There is already hundreds of out-of-date packages scheduled for building so scheduling uncompiled packages is pointless until we get more buildd's. Getting more buildd's is also being worked on, so don't worry. I don't see rebuilding yet another version of all the various gcc's as being more important than building a package that is absent from the archive. *FIXING* bugs and submitting patches to BTS. See ltrace as a great example what would be really usefull. Just listing problems or filing bugreports (without patchehs) does not get the port anywhere fast... Sure. But first we should know which are the buggy packages - I have uncovered dozens of new ones - how can we know where the most progress can be made in the least time? I know it seems nasty of me to list yet more broken things, if we are trying to make everything look nice, but the alternative is hiding problems or ignoring them, which means that they will remain broken. In the end, I presume, what is left on that list forms the agenda of a last-minute bug-squashing-party, so it's not pointless. Let me explain where I personally am coming from: I am paid a small, fixed number of working hours to increase the likelihood of armel achieving release certification before the deadline. When that number of hours is exhausted, I will go away again until July. For myself, I could happily spend all those hours fixing one small and interesting broken package, but that would do very little as far as certification is concerned. At present, I can see two bulk ways of getting many package working on armel: 1) identify the packages that are missing but known to work on armel, and prioritoze them on the buildds. Other than the lists I posted, I have found another dozen inter-dependent packages that will build if you build them in the right order. The next step would be to identify all packages that are absent by a programmatic comparison of the Sources and Packages files and the repository itself. quinn-diff should do this, but is let down by its data file from 2003, and it seems to have been abandoned by its maker. 2) After that, next greatest profit is to tackle the unfortunate practice of listing Architectures in the Binary section of each source packages' control file, which means that an unknown number of packages appear to build on armel, but do not in fact produce any binary packages (or omit some). Unknown, because the per-binary arch-specification does not appear in the main Sources file, and unfortunate because to find them one has to download every single source package, unpack it and examine the debian/control file, then for the positive matches, file bugs against the ones that have architecture lists that should include armel but don't. Thanks to the local LUG I now have the bandwidth resources to do that. There may be a less automatic strategy that uses less brute force and more eyeball-work, but I'm inclined to automate it as far as possible. These are both lots of boring work for me, but it gets a greater number of packages working on armel per hour than fixing one or two difficult ones. If there is no buildd admin who will take advantage of the info I discover to achieve our (common!) goal - armel lenny certification, then there is no point me attacking the first of the above two, so I guess I will just do the second one and hope that the buildds get round to the non-existent packages eventually. But I think the results we achieve, as far as getting closer to lenny certification is concerned, will be less than the maximum that we could obtain by working together. M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: armel port status report
*FIXING* bugs and submitting patches to BTS. See ltrace as a great example what would be really usefull. Just listing problems or filing bugreports (without patchehs) does not get the port anywhere fast... Sorry, do you mean I should fix ltrace on armel, or (what i think you mean) that someone else's fix for it that you uploaded on 3 feb 08 is the sort of thing you want to see? It seems to build fine on armel and, installing the deb, works as far as I can see, but it is not included in the debian repository... usual story! M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Access to arm box
Is it correct that arm does not support setting the FPU rounding mode via fesetround()? At least, bits/fenv.h does not define FE_UPWARD, FE_DOWNWARD and FE_TOWARDZERO. It says in that file: /* The ARM FPU basically only supports round-to-nearest. Other rounding modes exist, but you have to encode them in the actual instruction. */ #define FE_TONEAREST0 - that's talking about the ancient FPA unit that a few early ARM CPUs had, and which is supported in linux on all modern CPUs by emulating the illegal instructions in the kernel. While at it I also builded the package on armel. bits/fenv.h defines all four FE_* constants, but fegetround() always returns FE_TONEAREST. Is this a bug/not supported/...? (I didn't check the rounding mode by a computation yet.) The armel version of the file says: /* VFP supports all of the four defined rounding modes. */ ... but the implementaion you were using has no FPU, so uses the soft-float library coded in ARM assembler in glibc. It could be that either it doesn't implement rounding modes or the set/get function is broken (just guessing). I'm afraid I don't have any units with a VFP FPU here to test on. If you can make a testcase that would be interesting. however there are also other FPUs around associated with ARM processors, such as the buggy Cirrus Maverick Crunch unit, so if you are in a position to test for macro existence and possibly also run configure tests to see whether the implementation actually works, rather than relying on system-specific knowledge, that might result in more robust software. M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security buildd for armel
2008/2/8, Daniel Jacobowitz [EMAIL PROTECTED]: On Fri, Feb 08, 2008 at 06:48:18PM +0100, Moritz Muehlenhoff wrote: So, these Intel boards are _badly_ needed. Or maybe the buildd can be run in qemu on a fast amd64 machine, I don't know if that would work out. It would probably be slower than the existing buildd. It would. you lose about a factor of 12 in (32-bit) AMD MHz to ARM MHz, and that's when it's running in a straight line; configuring is slower yet. If it's just a question of money I don't mind buying the security team an N2100, but mine is giving segfaults and bus errors on long builds so you might like to consider something different. M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of armel in the archive?
2008/1/30, Luk Claes [EMAIL PROTECTED]: On Wed, Jan 02, 2008 at 10:32:55AM +0100, Marc 'HE' Brockschmidt wrote: [armel]'s quality is at least matching the current arm port Could you please comment on the current status and list outstanding issues blocking the inclusion of armel in the archive? Well, since no one else has actually answered the question... In unstable, arm is at 95.69% of the archive, while armel is at 91.94% Of the lacking packages, the lion's share is due to lack of language support. gcc-3 is not supported in armel and never will be, which excludes g77 and everything that uses it. The success of armel therefore depends on the success of the g77-gfortran transition. Objective C does not work on armel, which knocks out gnustep. ARM are now funding CodeSourcery to make the necessary modifications to gcc. It remains to be seen which mainline version this will go into - probably gcc-4.4, since 4.3 is now open only to regression fixes, while lenny's current default gcc is 4.2 with some people pressing for it to be 4.3. Debian may have to carry these modifications as patches. Other packages either don't compile or don't work on armel, including some that are included in the repository but do not work at all, of which the most high-profile are iceweasel and iceape-browser. Unfortunately there is currently no public bug tracker for issues other than the wiki pages; that would be one advantage of inclusion in lenny. The advantage of armel over arm from a normal user's point of view is the immense increase in floating point speed (a factor of 11) plus the possibility of using current hardware FPUs (for a further factor of between 2.5 and 7) The disadvantage is that it requires armv4t processors, excluding older ARMv4-based systems (CATS, NetWinder, Balloon 2). The simplest way to circumvent this would be to patch the kernel to emulate the missing BX instruction. wiki.debian.org/armelLennyReleaseRecertification summarises its certification status wiki.debian.org/ArmEabiTodo givean overview of the main issues wiki.debian.org/ArmEabiProblems is the closest we have to a public bug tracker. arm will be supported on lenny... I think that is highly desirable. The arm port is more mature and more functional at present M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
