Re: ARM port(s) BoF at DebConf

2012-07-20 Thread Wookey 
+++ Luke Kenneth Casson Leighton [2012-07-20 21:27 +0100]:
> On Fri, Jul 20, 2012 at 12:54 AM, Hideki Yamane  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-devel-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

Re: [Arm-netbook] ARM port(s) BoF at DebConf

2012-07-20 Thread Nobuhiro Iwamatsu 
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 :
> * Luke Kenneth Casson Leighton (l...@lkcl.net) wrote:
>> On Fri, Jul 20, 2012 at 12:54 AM, Hideki Yamane  wrote:
>> > Hi,
>> >
>> > On Thu, 19 Jul 2012 18:35:44 +0100
>> > Steve McIntyre  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-devel-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-netbook] ARM port(s) BoF at DebConf

2012-07-20 Thread Dr. David Alan Gilbert 
* Luke Kenneth Casson Leighton (l...@lkcl.net) wrote:
> On Fri, Jul 20, 2012 at 12:54 AM, Hideki Yamane  wrote:
> > Hi,
> >
> > On Thu, 19 Jul 2012 18:35:44 +0100
> > Steve McIntyre  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

Re: ARM port(s) BoF at DebConf

2012-07-20 Thread Luke Kenneth Casson Leighton 
On Fri, Jul 20, 2012 at 12:54 AM, Hideki Yamane  wrote:
> Hi,
>
> On Thu, 19 Jul 2012 18:35:44 +0100
> Steve McIntyre  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-devel-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

2012-07-19 Thread Nobuhiro Iwamatsu 
Hi,

2012/7/20 Hideki Yamane :
> Hi,
>
> On Thu, 19 Jul 2012 18:35:44 +0100
> Steve McIntyre  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-devel-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

Re: ARM port(s) BoF at DebConf

2012-07-19 Thread Hideki Yamane 
Hi,

On Thu, 19 Jul 2012 18:35:44 +0100
Steve McIntyre  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-devel-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

2012-07-19 Thread Luke Kenneth Casson Leighton 
On Thu, Jul 19, 2012 at 9:15 PM, Adam D. Barratt
 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  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-devel-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

2012-07-19 Thread Adam D. Barratt 
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  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-devel-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

2012-07-19 Thread Luke Kenneth Casson Leighton 
On Thu, Jul 19, 2012 at 6:35 PM, Steve McIntyre  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-devel-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

ARM port(s) BoF at DebConf

2012-07-19 Thread Steve McIntyre 
[ 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 wi