Re: [Arm-netbook] ARM port(s) BoF at DebConf
tis 2012-07-24 klockan 00:02 +0100 skrev Luke Kenneth Casson Leighton: rright. many thanks to the person on arm-netbooks who found that the netgear ReadyNAS boxes can take standard DDR3 SO-DIMMs. apparently there are lots of people who have been upgrading them from the pathetic 256mb they come with to at least 1gb, with some degree of success: http://www.readynas.com/forum/viewtopic.php?f=110t=49254 That thread is for DUO v1 only (LEON SPARC based). I have not seen any claims that DUO v2 can be upgraded before the post on this mailinglist. Only numerous claims and complaints about it not being upgradeable, and wrote it off as not interesting when it came ot due to being restricted to 256MB. Regards Henrik -- 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/1343254731.5203.28.ca...@hlaptop.hno.se
Fwd: [Arm-netbook] ARM port(s) BoF at DebConf
ughh :) *sigh* why is this so difficult for manufacturers to understand that there are people who both want and need to push the limits? don't tell me, i know the answer: they want to reduce costs in mass-volume manufacturing. *sigh*. -- Forwarded message -- From: Mehmet Mersin mmer...@gmail.com Date: Tue, Jul 24, 2012 at 12:24 PM Subject: Re: [Arm-netbook] ARM port(s) BoF at DebConf To: Linux on small ARM machines arm-netb...@lists.phcomp.co.uk On Tue, Jul 24, 2012 at 8:06 PM, lkcl luke luke.leigh...@gmail.com wrote: On Tue, Jul 24, 2012 at 12:00 PM, Gordan Bobic gor...@bobich.net wrote: ReadyNAS is DDR1, not DDR3. That's why it's limited to 1GB of RAM - DDR1 SO-DIMMs don't come in sizes 1GB. the specs on the readynas.com web site say that ReadyNas Duo v2 takes DDR3 RAM. Curious. I wonder if the postings I saw with the RAM part numbers used was for the older ReadyNAS, then. I clearly recall 333MHz DDR RAM being mentioned. wouldn't surprise me if it was a mistake on the readynas web site... It takes DDR3 RAM, but it's soldered on board. A google image search gave me this link: http://www.legionhardware.com/articles_pages/netgear_readynas_duo_v2,3.html Here is internals of ReadyNAS Duo (not v2): http://www.xbitlabs.com/articles/networking/display/netgear-readynas-duo_4.html A forum post says that only ReadyNAS Duo has SO-DIMM socket, v2 doesn't have it. Such a pity, with USB3, SATA and Gigabit Ethernet, it's a very good product for this price. But memory is not upgradeable. -mehmet mersin ___ arm-netbook mailing list arm-netb...@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk -- 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/CAPweEDyUtnvZry3wGe1WK0UA4xX9u+bbhntEEK9VjC-VWK=e...@mail.gmail.com
Re: ARM port(s) BoF at DebConf
On Thu, Jul 19, 2012 at 6:35 PM, Steve McIntyre st...@einval.com wrote: [ Please note the cross-post and Reply-To ] ... which is debian-arm [arm-netbooks cc'd to keep people there informed] buildds === Both armel and armhf are doing well, covering ~96% of the archive. We don't have any ARM server hardware yet, so we're stuck using development boards as build machines. They work, but they're a PITA for hosting and they're not designed for 24x7 usage like we're doing so they're not that reliable. armel currently using a load of Marvell Feroceon dev boards (v5), armhf on Freescale imx53 dev boards. Both sets of machines are limited in terms of memory, meaning the common large C++ apps are painful to build - linking in swap! rright. many thanks to the person on arm-netbooks who found that the netgear ReadyNAS boxes can take standard DDR3 SO-DIMMs. apparently there are lots of people who have been upgrading them from the pathetic 256mb they come with to at least 1gb, with some degree of success: http://www.readynas.com/forum/viewtopic.php?f=110t=49254 however the discussion goes on to point out that the manufacturers often have the RAM ICs changed out from under them but don't tell anyone, just release the same RAM module with the same product number but with different timing specs. the readynas duo v2 specs say, bless 'em, it's an ARM processor from marvell. http://www.readynas.com/?p=6167 however a bit more searching (thank you to gordan) it's apparently a 1.6ghz marvell CPU that has at least fully main-lined linux kernel support in upstream kernel.org. the nice thing about the readynas boxes is that they have gigabit ethernet and 2 stonking SATA-II interfaces. searching, searching... achh fiinally, reghardware has an article which actually says which ARM CPU it is. why the f*** netgear couldn't be bothered to put that on their own tech specs i really don't know. http://www.reghardware.com/2012/01/18/review_netgear_readynas_duo_v2_network_attached_storage/ ok hooray, it's an 88F6282, aka armada-300. right. so the product brief is downloadable here: http://www.marvell.com/embedded-processors/armada-300/ and it says it's a Sheeva, whatever that is, and it says it's only a 16-bit DDR3 interface, which means it's going to be rather painful to use _but_ nothing like as bad as having to do linker phases in swap. anyway, there you go: readynas duo v2. actually available, actually being sold in reasonable volume, actually having mainline linux kernel support, actually taking standard DDR3 SO-DIMMs although it's anybody's guess as to which ones will work, so you'll just have to experiment. it'd be good to know what works. /peace l. -- 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/CAPweEDybgetx4srEAdC=sdmf1ddt6o_xfwe8v8gade7xnb-...@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: ARM port(s) BoF at DebConf
Martin Guy martinw...@gmail.com writes: Who is it that keeps bringing this up? At least chromium seems to get much more testing on v5 systems so we expose new bugs when we build it fo v4t. This probably applies to some other upstreams that use hand-written assembler or JIT. -- 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/844np2w5tg@sauna.l.org
Re: ARM port(s) BoF at DebConf
On Fri, 2012-07-20 at 22:08 +0200, Martin Guy wrote: 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! Upstreams don't seem to care about armv4t anymore. http://code.google.com/p/v8/issues/detail?id=590 (reports in Debian are that this is not fixed, they are only testing with qemu, which cannot be used for this testing) 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 -- -Shawn Landden -- 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/1342815264.5910.151.camel@shawn-ssd
Re: ARM port(s) BoF at DebConf
On Fri, Jul 20, 2012 at 10:08:03PM +0200, Martin Guy wrote: 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. Right. I've asked before who's still using v4t machines, and the common response is just openmoko. Thanks for mentioning others. 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. We've been pestered several times by toolchain developers and upstreams for various other projects that generate code for ARM (e.g. JITs in browsers). It seems that Debian is about the only place where anybody still cares about v4t any more, so we'll be the only people seeing bugs related to broken (or even missing) v4 support now. 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? Even Debian moves on, dropping support for older platforms from time to time. We don't support actual i386 hardware any more, for example. And the speed freaks can always build their own v5t and v5te repositories and use those to install from, leaving everybody happy. I've asked people for benchmarks to show the improvements (or lack of them) that might come from a move to v5te. If there isn't a compelling case for moving, we won't! -- Steve McIntyre, Cambridge, UK.st...@einval.com Welcome my son, welcome to the machine. -- 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/20120720202159.ga...@einval.com
Re: ARM port(s) BoF at DebConf
On Fri, Jul 20, 2012 at 12:54 AM, Hideki Yamane henr...@debian.or.jp wrote: Hi, On Thu, 19 Jul 2012 18:35:44 +0100 Steve McIntyre st...@einval.com wrote: buildds === Both armel and armhf are doing well, covering ~96% of the archive. We don't have any ARM server hardware yet, so we're stuck using development boards as build machines. They work, but they're a PITA for hosting and they're not designed for 24x7 usage like we're doing so they're not that reliable. As I've posted during DebConf(*), Maybe OpenBlocks can solve this problem. It has 2GB RAM, reliable production use and we can buy it NOW. *) http://lists.debian.org/debian-arm/2012/07/msg7.html hideki, those look superb. summarising (in case anyone's missed it): they're armv7 compatible because they're using a marvell xp processor; they're up to dual-core 1.4ghz and the company openblocks can do them with up to 3gb of RAM, and i gather the openblocks boxes have a mini pci-e port as well as gigabit ethernet. i'm including arm-netbooks because there may almost certainly be people on that list who would be interested in a group buy. there has been quite a bit of interest in getting hold of modular computing devices for rack-mounted server usage. l. -- 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/CAPweEDxB=akchpidonavwvuon9xf0gge9cf2smyjrrgdm3+...@mail.gmail.com
Re: ARM port(s) BoF at DebConf
On Thu, Jul 19, 2012 at 08:09:53PM +0100, Luke Kenneth Casson Leighton wrote: On Thu, Jul 19, 2012 at 6:35 PM, Steve McIntyre st...@einval.com wrote: Both armel and armhf are doing well, covering ~96% of the archive. We don't have any ARM server hardware yet, so we're stuck using development boards as build machines. They work, but they're a PITA for hosting and they're not designed for 24x7 usage like we're doing so they're not that reliable. there was a post on the arm-netbook mailing list about a 7W quad-core tegra3-based mini ITX motherboard which could take up to 2gb of RAM. whether it's the usual let's-put-something-out-there-see-if-anyone-is-actually-interested style of vapourware or actual reality i'd strongly suggest someone gets onto them and considers putting together a group buy / bulk order just to make it worthwhile their time making a batch, because it's literally the first ARM-based machine i've ever heard about that can actually take 2gb of RAM. oh: also the motherboards have eSATA and uPCI-e, hm let me find the post here you go: http://lists.phcomp.co.uk/pipermail/arm-netbook/2012-July/005127.html Cool, sounds interesting maybe... But what's the rest of the system like? Is it supported already in the kernel, etc.? We really want to get standard machines where possible. btw, steve: it's not the c++ doing linking in swap that's the problem, it's trying to do *debug* builds of c++ applications that's the problem. webkit for example requires a minimum of 1.4gb of resident RAM for the linker phase if you enable debug builds. i have mentioned a number of times that it's debug builds that are the problem, and that all you have to do is disable debugging (*1) and the build will complete within 15 minutes instead of 15 hours, but as usual because it's that fucking moron lkcl telling us what the fuck to do nobody bothers to listen. well, keep on not listening for as long as you (plural) find it useful to do so: i'm not the one with a PITA for having to wait 18 hours for a debug build of a c++ app to complete, am i, eh? *eyebrows-arched* That's interesting, but we don't want to be doing non-standard builds for one architecture. That's not the way we do things in Debian... (*1) and if someone _really_ wants a debug build of that particular problematic package, on a build and distro port that's still experimental, well, surely they can compile it themselves, using their own resources, yes? As Adam pointed out, it's far from experimental at this point. In terms of popularity, I'm expecting armhf to overtake most of the other ports once it's been released as stable with Wheezy. -- Steve McIntyre, Cambridge, UK.st...@einval.com I've only once written 'SQL is my bitch' in a comment. But that code is in use on a military site... -- Simon Booth -- 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/20120720203025.gc...@einval.com
Re: [Arm-netbook] ARM port(s) BoF at DebConf
* Luke Kenneth Casson Leighton (l...@lkcl.net) wrote: On Fri, Jul 20, 2012 at 12:54 AM, Hideki Yamane henr...@debian.or.jp wrote: Hi, On Thu, 19 Jul 2012 18:35:44 +0100 Steve McIntyre st...@einval.com wrote: buildds === Both armel and armhf are doing well, covering ~96% of the archive. We don't have any ARM server hardware yet, so we're stuck using development boards as build machines. They work, but they're a PITA for hosting and they're not designed for 24x7 usage like we're doing so they're not that reliable. As I've posted during DebConf(*), Maybe OpenBlocks can solve this problem. It has 2GB RAM, reliable production use and we can buy it NOW. *) http://lists.debian.org/debian-arm/2012/07/msg7.html hideki, those look superb. summarising (in case anyone's missed it): they're armv7 compatible because they're using a marvell xp processor; they're up to dual-core 1.4ghz and the company openblocks can do them with up to 3gb of RAM, and i gather the openblocks boxes have a mini pci-e port as well as gigabit ethernet. ftp://ftp.plathome.co.jp/pub/OBSAX3/Documents/OBSA_UsersGuide_1.0.0.pdf seems to be the (Japanese) user guide for it. Now, erm I don't know any Japanese at all, but there are lots of very pretty diagrams in there. But the picture on 4/24, and table 1.4 on section 6/24 shows the OBSAX3/4/x with an Armada XP, 1.33GHz dual core, 1GB SDRAM, a SODIMM that takes 1 or 2GB (more??), SATA2, Mini PCIe, 4 () GigE, eSATA, 2xUSB2, and 2xRS-232C. Very nice! Pity it says available in japan only. i'm including arm-netbooks because there may almost certainly be people on that list who would be interested in a group buy. there has been quite a bit of interest in getting hold of modular computing devices for rack-mounted server usage. Dave -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux | Happy \ \ gro.gilbert @ treblig.org | | In Hex / \ _|_ http://www.treblig.org |___/ -- 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/20120720222832.GA637@gallifrey
Re: [Arm-netbook] ARM port(s) BoF at DebConf
Hi,
I have a spec sheet to devices for English.
I ask whether this can be distributed.
Please wait.
Nobuhiro
2012/7/21 Dr. David Alan Gilbert d...@treblig.org:
* Luke Kenneth Casson Leighton (l...@lkcl.net) wrote:
On Fri, Jul 20, 2012 at 12:54 AM, Hideki Yamane henr...@debian.or.jp wrote:
Hi,
On Thu, 19 Jul 2012 18:35:44 +0100
Steve McIntyre st...@einval.com wrote:
buildds
===
Both armel and armhf are doing well, covering ~96% of the archive. We
don't have any ARM server hardware yet, so we're stuck using
development boards as build machines. They work, but they're a PITA
for hosting and they're not designed for 24x7 usage like we're doing
so they're not that reliable.
As I've posted during DebConf(*), Maybe OpenBlocks can solve this problem.
It has 2GB RAM, reliable production use and we can buy it NOW.
*) http://lists.debian.org/debian-arm/2012/07/msg7.html
hideki, those look superb. summarising (in case anyone's missed it):
they're armv7 compatible because they're using a marvell xp processor;
they're up to dual-core 1.4ghz and the company openblocks can do them
with up to 3gb of RAM, and i gather the openblocks boxes have a mini
pci-e port as well as gigabit ethernet.
ftp://ftp.plathome.co.jp/pub/OBSAX3/Documents/OBSA_UsersGuide_1.0.0.pdf
seems to be the (Japanese) user guide for it. Now, erm I don't know
any Japanese at all, but there are lots of very pretty diagrams in there.
But the picture on 4/24, and table 1.4 on section 6/24
shows the OBSAX3/4/x with an Armada XP, 1.33GHz dual core,
1GB SDRAM, a SODIMM that takes 1 or 2GB (more??), SATA2, Mini PCIe,
4 () GigE, eSATA, 2xUSB2, and 2xRS-232C.
Very nice! Pity it says available in japan only.
i'm including arm-netbooks because there may almost certainly be
people on that list who would be interested in a group buy. there has
been quite a bit of interest in getting hold of modular computing
devices for rack-mounted server usage.
Dave
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux | Happy \
\ gro.gilbert @ treblig.org | | In Hex /
\ _|_ http://www.treblig.org |___/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120720222832.GA637@gallifrey
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
--
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/CABMQnVL9qt8_rsuFLNw_+Sp1Dp=guh2ph4drgi6qj+6qfwn...@mail.gmail.com
Re: ARM port(s) BoF at DebConf
On Fri, Jul 20, 2012 at 05:58:45PM -0400, Lennart Sorensen wrote: We've been pestered several times by toolchain developers and upstreams for various other projects that generate code for ARM (e.g. JITs in browsers). It seems that Debian is about the only place where anybody still cares about v4t any more, so we'll be the only people seeing bugs related to broken (or even missing) v4 support now. Even Debian moves on, dropping support for older platforms from time to time. We don't support actual i386 hardware any more, for example. I remember Debian had a kernel patch to try and keep i386 going even after glibc wanted to move to i486+ only. The kernel patch had a fatal security flaw which no one ever fixed. So this patch was never included in a stable release. (http://bugs.debian.org/250468) So it was not by choice that Debian dropped i386. It was dropped by the unanimous decision of every developer in Debian to not fix the security bug in the i386 emulation patch. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: ARM port(s) BoF at DebConf
+++ Luke Kenneth Casson Leighton [2012-07-20 21:27 +0100]: On Fri, Jul 20, 2012 at 12:54 AM, Hideki Yamane henr...@debian.or.jp wrote: As I've posted during DebConf(*), Maybe OpenBlocks can solve this problem. It has 2GB RAM, reliable production use and we can buy it NOW. *) http://lists.debian.org/debian-arm/2012/07/msg7.html hideki, those look superb. I saw one at debconf and it is indeed really nice mini-server hardware in a proper box and everything! Not easily rackable, but nicely stackable. The only catch seems to be the price on the spec sheet which is 79000 yen, which I make to be best part of 750 euro. I'm not sure they'll sell any at that price, so hopefully that'll change. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- 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/20120721012207.gp26...@dream.aleph1.co.uk
ARM port(s) BoF at DebConf
[ Please note the cross-post and Reply-To ] Hi folks, Here's a summary of what we discussed in the ARM ports BoF [1] last week (10th July). Thanks to the awesome efforts of the DebConf video team, the video of the session is already online [2] in case you missed it. I've also attached the Gobby notes that were taken during the session. Again, thanks to the people who took part - we had a very useful discussion. Slides are up on my website [3]. 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! armhf = First release will be Wheezy. Targets ARMv7 (latest released version of the ARM family), VFPv3-D16, hard-float version of EABI, assumes hardware floating point unit. Benchmarks show that you get anything from 0 to 20% improvement in real-life code, depending on workload. In any case, you should lose nothing. New agreed standard for ARM Linux, in use across all the distros supporting ARM. Mono does not do useful floating point (yet!), still looking for somebody to help here. libffi issues with variadic functions using floating point. buildds === Both armel and armhf are doing well, covering ~96% of the archive. We don't have any ARM server hardware yet, so we're stuck using development boards as build machines. They work, but they're a PITA for hosting and they're not designed for 24x7 usage like we're doing so they're not that reliable. armel currently using a load of Marvell Feroceon dev boards (v5), armhf on Freescale imx53 dev boards. Both sets of machines are limited in terms of memory, meaning the common large C++ apps are painful to build - linking in swap! elsewhere (starting close, moving further out) == Raspbian Unofficial Debian port for the Raspberry Pi. Built (mostly) using Debian source packages, but targeting ARMv6 hard-float. Works well and forwards-compatible with official (v7) armhf. Not being considered for inclusion into the main Debian archive - we already have two ARM ports. Great work from the folks involved, and we'd love to work with them and help wherever possible. Pi is problematic for kernel and non-free graphics drivers... Ubuntu -- Ubuntu has 2 ARM ports released with 12.04 (LTS): armhf for v7 hard-float and armel for v7 soft-float. armel is slowly being re-targeted / rebuilt for v5 instead (no point in having both ports on v7 only). OpenSUSE OpenSUSE developers are doing 2 ARM ports. Concentrating on v7 hard-float, with a lower priority v5 soft-float port. Hoping for a release with 12.2. Fedora -- Fedora developers are doing 2 ARM ports. Concentrating on v7 hard-float, with a lower priority v5 soft-float port. Did a release of F17 with ARM, but beware of linker path issues. Ongoing discussions in Fedora about whether or not ARM will end up becoming a primary architecture. As/when/if it does, expect a RedHat release for ARM. Mageia, Gentoo, ChromeOS, Android also doing ARM Linux work with varying amounts of overlap with what we're doing in Debian. New stuff = Newer versions of ARM hardware and software are coming, with new features and requirements that will be useful and we should look into supporting: * virtualisation extensions * LPAE (large physical address extensions) - allows for a 32-bit system but with larger amounts of memory available on the system. Each process still limited to 4GiB address space, but along with virtualisation could be very useful for large servers * UEFI: standard boot architecture and boot loaders. Device tree and ACPI coming too. Should be able to use a single kernel image to support most new hardware once this work filters down. Very useful as commodity ARM-powered machines become more readily available instead of application-specific setups like phones. * ARMv8 - 64-bit capable. More information in the next talk! [1] http://penta.debconf.org/dc12_schedule/events/870.en.html [2] http://meetings-archive.debian.net/pub/debian-meetings/2012/debconf12/high/870_ARM_ports_update.ogv [3] http://www.einval.com/~steve/talks/Debconf12-arm-ports/ -- Steve McIntyre, Cambridge, UK.st...@einval.com Every time you use Tcl, God kills a kitten. -- Malcolm Ray Please take notes here (not an official ARM talk) armel = First released with Lenny. soft-float EABI. v4t which also runs smaller-size thumb instruction set. Targetting old hardware like openmoko. v5 is no faster than v4t. Software floating point assumed. armhf = First release will
Re: ARM port(s) BoF at DebConf
On Thu, Jul 19, 2012 at 6:35 PM, Steve McIntyre st...@einval.com wrote: Both armel and armhf are doing well, covering ~96% of the archive. We don't have any ARM server hardware yet, so we're stuck using development boards as build machines. They work, but they're a PITA for hosting and they're not designed for 24x7 usage like we're doing so they're not that reliable. there was a post on the arm-netbook mailing list about a 7W quad-core tegra3-based mini ITX motherboard which could take up to 2gb of RAM. whether it's the usual let's-put-something-out-there-see-if-anyone-is-actually-interested style of vapourware or actual reality i'd strongly suggest someone gets onto them and considers putting together a group buy / bulk order just to make it worthwhile their time making a batch, because it's literally the first ARM-based machine i've ever heard about that can actually take 2gb of RAM. oh: also the motherboards have eSATA and uPCI-e, hm let me find the post here you go: http://lists.phcomp.co.uk/pipermail/arm-netbook/2012-July/005127.html btw, steve: it's not the c++ doing linking in swap that's the problem, it's trying to do *debug* builds of c++ applications that's the problem. webkit for example requires a minimum of 1.4gb of resident RAM for the linker phase if you enable debug builds. i have mentioned a number of times that it's debug builds that are the problem, and that all you have to do is disable debugging (*1) and the build will complete within 15 minutes instead of 15 hours, but as usual because it's that fucking moron lkcl telling us what the fuck to do nobody bothers to listen. well, keep on not listening for as long as you (plural) find it useful to do so: i'm not the one with a PITA for having to wait 18 hours for a debug build of a c++ app to complete, am i, eh? *eyebrows-arched* l. (*1) and if someone _really_ wants a debug build of that particular problematic package, on a build and distro port that's still experimental, well, surely they can compile it themselves, using their own resources, yes? -- 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/CAPweEDzD1sVfWTUFrt64=drral2fntoagjaqmm8oabyag7d...@mail.gmail.com
Re: ARM port(s) BoF at DebConf
Luke Kenneth Casson Leighton wrote: there was a post on the arm-netbook mailing list about a 7W quad-core tegra3-based mini ITX motherboard which could take up to 2gb of RAM. whether it's the usual let's-put-something-out-there-see-if-anyone-is-actually-interested style of vapourware or actual reality i'd strongly suggest someone gets onto them and considers putting together a group buy / bulk order just to make it worthwhile their time making a batch, because it's literally the first ARM-based machine i've ever heard about that can actually take 2gb of RAM. The dell copper machines can supposedly take 8gb per node. Of course when they will be available and how much they will cost is anyones guess at this point. oh: also the motherboards have eSATA and uPCI-e, hm let me find the post here you go: http://lists.phcomp.co.uk/pipermail/arm-netbook/2012-July/005127.html btw, steve: it's not the c++ doing linking in swap that's the problem, it's trying to do *debug* builds of c++ applications that's the problem. webkit for example requires a minimum of 1.4gb of resident RAM for the linker phase if you enable debug builds. i have mentioned a number of times that it's debug builds that are the problem, and that all you have to do is disable debugging (*1) and the build will complete within 15 minutes instead of 15 hours, but as usual because it's that fucking moron lkcl telling us what the fuck to do nobody bothers to listen. well, keep on not listening for as long as you (plural) find it useful to do so: i'm not the one with a PITA for having to wait 18 hours for a debug build of a c++ app to complete, am i, eh? *eyebrows-arched* l. (*1) and if someone _really_ wants a debug build of that particular problematic package, on a build and distro port that's still experimental, well, surely they can compile it themselves, using their own resources, yes? Painful as it is to build them I think we do need the debug symbols for things like webkit. Without them any bug reports will be basically useless. -- 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/50086a71.1010...@p10link.net
Re: ARM port(s) BoF at DebConf
On Thu, 2012-07-19 at 20:09 +0100, Luke Kenneth Casson Leighton wrote: On Thu, Jul 19, 2012 at 6:35 PM, Steve McIntyre st...@einval.com wrote: Both armel and armhf are doing well, covering ~96% of the archive. We [...] (*1) and if someone _really_ wants a debug build of that particular problematic package, on a build and distro port that's still experimental, well, surely they can compile it themselves, using their own resources, yes? Neither wheezy nor the armhf port contained in it are experimental. If that's not what you meant, please be clearer. Regards, Adam -- 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/1342728935.2846.16.ca...@jacala.jungle.funky-badger.org
Re: ARM port(s) BoF at DebConf
On Thu, Jul 19, 2012 at 9:13 PM, peter green plugw...@p10link.net wrote:
Luke Kenneth Casson Leighton wrote:
there was a post on the arm-netbook mailing list about a 7W quad-core
tegra3-based mini ITX motherboard which could take up to 2gb of RAM.
whether it's the usual
let's-put-something-out-there-see-if-anyone-is-actually-interested
style of vapourware or actual reality i'd strongly suggest someone
gets onto them and considers putting together a group buy / bulk order
just to make it worthwhile their time making a batch, because it's
literally the first ARM-based machine i've ever heard about that can
actually take 2gb of RAM.
The dell copper machines can supposedly take 8gb per node. Of course when
they will be available and how much they will cost is anyones guess at this
point.
... yeh, exactly. whereas kontron's tegra3 motherboards appear, if
you take their advertisement as being honest and at face value, to be
available now. 2gb of RAM is just enough, i've found from experience,
to be able to do debug builds of e.g. webkitgtk or webkitefl (not at
the same time!). that linker phase is 1.4 gb resident RAM required,
increasing to 1.6gb briefly towards the end, for the last minute or
so.
(*1) and if someone _really_ wants a debug build of that particular
problematic package, on a build and distro port that's still
experimental, well, surely they can compile it themselves, using their
own resources, yes?
Painful as it is to build them I think we do need the debug symbols for
things
like webkit. Without them any bug reports will be basically useless.
ok, so consider this process/procedure, tell me if you see any
fundamental flaws:
* maintainer (whoever) happily spends 18 hours of their personal
machine's life doing manual builds, once in a while. maybe once a
month even.
* build system creates debug-stripped automated (daily?) packages,
churns them out regularly.
* user downloads debug-stripped package, installs, gets on with it, then...
* splat, bug, reports problem, stacktrace is completely useless
* maintainer asks please download from my home directory a
debug-build i did last {insert manual delay time, week, day, month}
and try again.
or, heck, even the (painful) debug builds could be done automated
using buildd, just once a week/month and kept in a separate
location/server/repository for now. you could even rotate the pain
somewhat by scheduling all of the over-bloated packages to be built
less often but only one being done at any one time, so that they don't
interfere with the building of everything else.
if that truly does become problematic on a per-package basis - large
number of bugreports - then you could always just put that problematic
package back into hammering the build machines mode.
/peace.
l.
--
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/capweedxkfekd2_qrdirq5ajhw00qcaz_vy98nraynddpfuc...@mail.gmail.com
Re: ARM port(s) BoF at DebConf
On Thu, Jul 19, 2012 at 9:15 PM, Adam D. Barratt a...@adam-barratt.org.uk wrote: On Thu, 2012-07-19 at 20:09 +0100, Luke Kenneth Casson Leighton wrote: On Thu, Jul 19, 2012 at 6:35 PM, Steve McIntyre st...@einval.com wrote: Both armel and armhf are doing well, covering ~96% of the archive. We [...] (*1) and if someone _really_ wants a debug build of that particular problematic package, on a build and distro port that's still experimental, well, surely they can compile it themselves, using their own resources, yes? Neither wheezy nor the armhf port contained in it are experimental. If that's not what you meant, please be clearer. yes i used the wrong word: apologies. i was trying to convey the following in a concise way, and chose the word experimental, which i realise in hindsight doesn't cover half of it: doesn't yet have as many users as e.g. i386/amd64, hasn't been around as long as i386/amd64, hasn't got hardware that the average user can buy at a spec approaching that of i386/amd64 yet, and doesn't have as many packages successfully and reliably building as i386/amd64. btw continuing on the thread on debian-arm (only) i put forward a [temporary!] procedure for review which is an interactive balancing act to relieve the burden of having excessive linker-related loads, moving it down instead to later inconvenience for users. of course, if the package is perfect and there *aren't* any bugreports then the interim proposed procedure has done its job. http://lists.debian.org/debian-arm/2012/07/msg00073.html l. -- 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/CAPweEDxPpxZsPjHf7R=nzem5jibfa1snjsve5hk-b167xqu...@mail.gmail.com
Re: ARM port(s) BoF at DebConf
Hi, On Thu, 19 Jul 2012 18:35:44 +0100 Steve McIntyre st...@einval.com wrote: buildds === Both armel and armhf are doing well, covering ~96% of the archive. We don't have any ARM server hardware yet, so we're stuck using development boards as build machines. They work, but they're a PITA for hosting and they're not designed for 24x7 usage like we're doing so they're not that reliable. As I've posted during DebConf(*), Maybe OpenBlocks can solve this problem. It has 2GB RAM, reliable production use and we can buy it NOW. *) http://lists.debian.org/debian-arm/2012/07/msg7.html I'll continue to communicate with that company, so if you have any questions/ comments/suggestions/request/discount;), please tell me whether on-list or privately. -- Regards, Hideki Yamane henrich @ debian.or.jp/org http://wiki.debian.org/HidekiYamane -- 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/20120720085407.c6a160a418086d0a38d7c...@debian.or.jp
Re: ARM port(s) BoF at DebConf
Hi,
2012/7/20 Hideki Yamane henr...@debian.or.jp:
Hi,
On Thu, 19 Jul 2012 18:35:44 +0100
Steve McIntyre st...@einval.com wrote:
buildds
===
Both armel and armhf are doing well, covering ~96% of the archive. We
don't have any ARM server hardware yet, so we're stuck using
development boards as build machines. They work, but they're a PITA
for hosting and they're not designed for 24x7 usage like we're doing
so they're not that reliable.
As I've posted during DebConf(*), Maybe OpenBlocks can solve this problem.
It has 2GB RAM, reliable production use and we can buy it NOW.
Note: This device can carry 2 GB of memory at the maximum. It is 1 GB at first.
It does not necessarily have this 2 GB from first.
*) http://lists.debian.org/debian-arm/2012/07/msg7.html
I'll continue to communicate with that company, so if you have any questions/
comments/suggestions/request/discount;), please tell me whether on-list or
privately.
Well, I already taking about this.
And the kernel of this machine has not been supported by upstream yet.
We have some problems which should be solved.
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
--
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/cabmqnvkkmu9viwgyitdlgifjz2jk4izkm+5c-xdkn8pc+od...@mail.gmail.com
