Steve's blog
   


Steve About
Steve's blog,
The Words of the Sledge
steve@einval.com

Subscribe
Subscribe to the RSS feed.

Links

  • Home
  • Debian
  • PlanetDebian
  • Search PlanetDebian
  • Friends

  • Matthew Garrett
  • Jonathan McDowell
  • Jo McIntyre
  • Martin Michlmayr
  • Andrew Mobbs
  • Mike Pitt
  • Daniel Silverstone
  • Andy Simpkins
  • Neil Williams

  •        
    Tuesday, 19 May 2015

    Easier installation of Jessie on the Applied Micro X-Gene

    As shipped, Debian Jessie (8.0) did not include kernel support for the USB controller on APM X-Gene based machines like the Mustang. In fact, at the time of writing this that support has not yet gone upstream into the mainline Linux kernel either but patches have been posted by Mark Langsdorf from Red Hat.

    This means that installing Debian is more awkward than it could be on these machines. They don't have optical drives fitted normally, so the neat isohybrid CD images that we have made in Debian so far won't work very well at all. Booting via UEFI from a USB stick will work, but then the installer won't be able to read from the USB stick at all and you're stuck. :-( The best way so far for installing Debian is to do a network installation using tftp etc.

    Well, until now... :-)

    I've patched the Debian Jessie kernel, then re-built the installer and a netinst image to use them. I've put a copy of that image up at http://cdimage.debian.org/cdimage/unofficial/arm64-mustang/ with more instructions on how to use it. I'm just submitting the patch for inclusion into the Jessie stable kernel, hopefully ready to go into the 8.1 point release.

    12:18 :: # :: /debian/arm :: 0 comments

    Wednesday, 08 April 2015

    More arm64 hardware for Debian - Applied Micro X-Gene

    As a follow-up to my post about bootstrapping arm64 in Debian, we've had more hardware given to Debian for us to use in porting and building packages for arm64. Applied Micro sent me an X-Gene development machine to set up and use. Unfortunately, the timing was unlucky and the machine sat on my desk unopened for a few weeks while I was on long holiday in Australia. Once I was back, I connected it up and got it working. Out of the box, a standard Jessie arm64 installation worked using network boot (dhcp and tftp). I ran through d-i as normal and installed a working system, then handed it over to the DSA and buildd folks to get the machine integrated into our systems. Easy! The machine is now up and running as arm-arm-03.debian.org and has been building packages for a few weeks now. You can see the stats here on the buildd.debian.org site.

    In terms of installation, I also got the machine to boot using one of our netinst images on a USB stick, but that path didn't get very far. The USB drivers for this hardware have only quite recently gone into the mainline kernel, and haven't been backported to the Debian Jessie kernel yet. I'm hoping to get those included shortly. There's also an option to replace the U-Boot firmware that came with the X-Gene with UEFI instead, which would be much more helpful for a server platform like this. I'll look into doing that upgrade soon too, but probably after the Jessie release is done. I don't want to jinx things just now. *grin*

    Thanks to APM for their generous donation here, and particularly to Richard Zenkert for his help in getting this machine shipped to us.

    17:09 :: # :: /debian/arm :: 0 comments

    Monday, 09 January 2012

    Armhf buildds and status in Debian

    Current status

    Back in September, I wrote about the machines that I set up to help bootstrap the new armhf port in Debian. Basing on Konstantinos' huge efforts in bringing up the new "architecture" in debian-ports, we started importing armhf into the main Debian archive on the 24th of November. Since then, those builders have been churning away night and day to build the huge collection of software that makes up the Debian archive. The current state can be seen on the armhf buildd status page, and there's a nice graph showing how quickly we've managed to run from 0 to over 90% of the archive here. (Click on the image for a larger version, or visit https://buildd.debian.org/stats/ for other versions. We overtook hurd-i386 quickly and are now ahead of the kfreebsd-* architectures.

    armhf bootstrap graph

    We've recently brought 3 more similar build machines online (hildegard, howells and hummel), again sponsored by the nice folks at Linaro but now hosted at the York NeuroImaging Centre at the University of York. This gives us both more build horsepower to keep up with building more different bits of Debian (experimental, updates etc.) and more redundancy in case of problems.

    We now have the vast majority of the archive built, and now a number of us are concentrating on fixing the remaining issues: language bootstraps and bugs. Also, on the 7th of January we were just added into testing, the next step on our path for inclusion as a Debian release architecture.

    Setting up the machines

    A lot of people have been asking me about the physical setup I showed in my last blog about these machines, so here's more details for those who are interested.

    • 3U mini-rack
      • Schroff model 24563-192 subrack (3U, 235mm deep), ordered from Farnell in the UK.
      • Added some 24560-353 220mm guide rails (Farnell link).

      Lovely kit, which fits together easily for a rigid enclosure.

    • ATX PSU
      • Ideally with lots of old-style Molex power connectors. I bought the cheapest one I could find from my supplier, and dismantled it. I cannibalised another old PSU and soldered on some extra Molex connectors.
      • In theory, the 6 boards and disks I'm using here could use up to 15W each on the 5V rail (but in practice much less); any current PSU on the market should handle that easily.
      • While I had the case open, I drilled holes and put some bolts through so I could mount it to the mini-rack.
      • Finally, connect together pins 15 and 16 on the ATX power connector so that the PSU will come on without needing to be connected to a PC motherboard (details on wikipedia).
    • Freescale iMX53 Quickstart boards
      • These are the little 3-inch square dev boards I'm using. I bought them from Mouser here, but there are quite a few other companies selling them too. Apparently this exact part has just gone EOL, but there is a replacement that I would hope to work in its place.
    • 2.5 inch SATA hard drives
      • I just bought what looked reasonably priced from my local supplier, 320 GB on the first machines and 250 GB on the next three after the recent rise in disk prices.
    • Cables and connectors
      • 45cm right-angle SATA cable with one right-angled end like this
      • Molex to twin SATA-power cable like this
      • 2.1mm/5.0mm power plug like here (L48AY at Maplin)

      The downside of the Quickstart board is that it doesn't include a SATA power connector on the board, just a SATA data connector. So, what I've done for my boards is modify Molex to SATA power splitters. This way I get a single power input for the board/drive combination as a whole.

      • The Molex socket will connect to the Molex plug from the PSU
      • The first SATA power connector goes to the laptop drive
      • Cut off the second SATA connector
      • Using the red and black (5V and ground) wires remaining, solder on a power plug to drive the board itself
    • Perspex board
      • I found a supplier near Cambridge for some perspex. Each machine has a base card measuring 220mm x 100mm, 2mm thick. I drilled holes and mounted each board with a drive and its cables as shown here.

    Mount the 6 boards into the mini-rack, connect up the Molex power connectors to each board, attach ethernet cables and turn it all on! Each board comes with a micro-SD card containing uboot and an Ubuntu installation. I've configured uboot to boot off the hard drive directly, but leaving configuration available to use the Ubuntu on the micro-SD as a simple rescue system should the need arise.

    The Quickstart boards are not ideal physically for two reasons: the lack of SATA power, plus you need to push a power button on each board to boot it - they don't boot automatically the moment power is applied. However, they're quite inexpensive little machines and have done a great job of building the Debian archive so far! The ideal machines for us would also include more RAM at this point. CPU on these is adequate, but the larger C++ packages (yay webkit!) use a huge amount of memory at link time. Linking in swap is not the best thing, performance-wise... :-(

    UPDATE 2012-01-12: Ian tells me that the newer Quickstart-R boards apparently have a different power controller; these now boot up straight away without needing you to push a button. That sounds useful.

    17:11 :: # :: /debian/arm :: 0 comments

    Monday, 05 September 2011

    Armhf buildds and porter box hosted at ARM

    I'm in the middle of setting up new build machines for the armhf port (see the wiki for more details). We'll shortly have six machines set up in the machine room here at ARM in Cambridge:

    • harris as a porter box
    • hartmann, hasse, hebden and henze running buildd software
    • hoiby as a hot spare

    hartmann

    All of these machines are Freescale i.MX53 Quickstart (aka "loco") development boards. They include a 1GHz i.MX53 CPU (based around the ARM Cortex A8, one of the ARMv7-A family). They have 1GB of RAM and native SATA. They're lovely little machines, measuring just 3 inches square. To mount them usefully in a machine room, I've mounted each board with a 320GB notebook hard drive and the necessary cabling onto a small perspex card as you can see here. Then we can fit 6 such machines and a normal PC-style ATX PSU into a 3U mini-rack. Well, it almost fits - the power supply pokes out a little so we'll need 4U of space when we come to mount it.

    armhf mini rack

    The Quickstart boards have been sponsored by Linaro, and ditto my time setting up these machines. Thanks!

    As is common with new development boards, these machines are not quite fully supported in Debian yet. The kernels we're using are locally-built, using the sources supplied by Freescale. For now, that means a heavily-patched "2.6.35" kernel but we're expecting to be able to switch to mainline very soon. The .config I'm using is kernel.config, and I've built it natively on harris using

    fakeroot make -j2 deb-pkg DEBEMAIL=93sam@debian.org DEBFULLNAME="Steve McIntyre" KDEB_PKGVERSION=1buildd1

    Similarly to the setup for the armel machines, for now I've tweaked things when installing the kernel:

    • depmod:
      • Need to make sure that depmod is run so the new kernel can find and load modules at boot. Added trivial script in /etc/kernel/postinst.d/depmod to do this.
    • initramfs-tools:
      • Needed to copy the file /etc/kernel/postinst.d/initramfs-tools into place from my amd64 machine; I'm guessing this would be there automatically on a new-enough version of initramfs-tools on the armel machines, but we're still using Lenny as a base system for now even if I'm using a Squeeze-based kernel.
    • flash-kernel:
      • Add support for these boards
      • #550584: kernel postinst hook script (/etc/kernel/postinst.d/zz-flash-kernel) to create uImage and uInitrd files from the kernel zImage and the initramfs.

    Finally, I've tweaked the uboot config on the machines to use the uImage and uInitrd files that are generated by flash-kernel:

    MX53-LOCO U-Boot > setenv loadaddr 0x70800000
    MX53-LOCO U-Boot > setenv initrdaddr 0x71000000
    MX53-LOCO U-Boot > setenv bootargs_sata set bootargs \$\{bootargs\} root=/dev/sda2 rw rootwait
    MX53-LOCO U-Boot > setenv load_sata_kernel ext2load sata 0:1 \$\{loadaddr\} /uImage
    MX53-LOCO U-Boot > setenv load_sata_initrd ext2load sata 0:1 \$\{initrdaddr\} /uInitrd
    MX53-LOCO U-Boot > setenv load_sata run load_sata_kernel load_sata_initrd
    MX53-LOCO U-Boot > setenv bootcmd_sata sata init\; run bootargs_base bootargs_sata load_sata\; bootm \$\{loadaddr\} \$\{initrdaddr\}
    MX53-LOCO U-Boot > setenv bootcmd run bootcmd_sata
    

    And I've added extra config into uboot to use the pre-installed Ubuntu system on the micro SD card as a fall-back:

    MX53-LOCO U-Boot > setenv bootcmd_rescue sata init\; run bootargs_base bootargs_sata\; mmc read 0 \$\{loadaddr\} 0x800 0x1800\; bootm
    

    17:15 :: # :: /debian/arm :: 3 comments

    Monday, 27 September 2010

    Armel buildds and porter box hosted at ARM

    One of the nice things that I've been involved with since starting to work at ARM in Cambridge is setting up newer, faster machines to help with the armel port. We have six machines hosted in the machine room here now:

    • abel is a porter box
    • arnold, alain, alwyn and antheil are running buildd software
    • arne is a hot spare (currently on my desk, but ready to go back in the rack any minute now)

    arne

    All of these machines are Marvell DB-78x00-BP development boards, each configured with a 1GHz Feroceon processor (ARM v5t), 1.5GB of RAM and a 250GB drive attached via SATA. They're nice machines, reasonably powerful yet (as with many ARM-based machines) they draw very very little electrical power even when working hard. These very boards were used for a while by the folks at Canonical to help build the Ubuntu armel port, but now we've got them.

    In terms of configuration, these machines are not quite fully supported in Debian yet, though. The kernels we're using are locally-built, based on the Debian linux-source-2.6.32 package but with a .config (marvell.config) that's tweaked slightly to add the support for these boards. There aren't any source changes needed, so I'm hoping to get support added directly in Debian, either as a new kernel flavour or (preferred) as a patch to an existing flavour. I've had conflicting advice about whether the latter is possible, so I'm going to have to experiment and find out for myself.

    UPDATE 2010-09-28: I've tested, and it seems that the boards will need a new flavour after all, as the config is incompatible with the closest other config (kirkwood). Ah well...

    I had no end of trouble trying to get make-kpkg do the right thing, so on advice from Ben I built the kernel using "make deb-pkg", a standard target in the Linux kernel's build system:

    fakeroot make -j2 deb-pkg DEBEMAIL=93sam@debian.org DEBFULLNAME="Steve McIntyre" KDEB_PKGVERSION=buildd23

    Annoyingly, that wouldn't work when cross-compiling either so I had to build the kernel natively.

    To make the resulting kernel image package install properly (and, just as importantly, allow for future easy upgrades for the DSA folks), I also needed the following tweaks to the Debian system:

    • depmod:
      • Need to make sure that depmod is run so the new kernel can find and load modules at boot. Added trivial script in /etc/kernel/postinst.d/depmod to do this.
    • initramfs-tools:
      • Needed to copy the file /etc/kernel/postinst.d/initramfs-tools into place from my amd64 machine; I'm guessing this would be there automatically on a new-enough version of initramfs-tools on the armel machines, but we're still using Lenny as a base system for now even if I'm using a Squeeze-based kernel.
    • flash-kernel:
      • #594878: support for these boards. Hector did most of the work, and I've worked on it a little more.
      • #550584: kernel postinst hook script (/etc/kernel/postinst.d/zz-flash-kernel) to create uImage and uInitrd files from the kernel zImage and the initramfs.

    Finally, I've tweaked the uboot config on the machines to use the uImage and uInitrd files that are generated:

    Marvell>> setenv IDE ide reset
    Marvell>> setenv loadkernel ext2load ide 0:1 0x2000000 /uImage
    Marvell>> setenv loadinitramfs ext2load ide 0:1 0x3000000 /uInitrd
    Marvell>> setenv bootboth bootm 0x2000000 0x3000000
    Marvell>> setenv bootcmd setenv bootargs \$\(bootargs\)\;$(IDE)\;$(loadkernel)\;$(loadinitramfs)\;$(bootboth)
    Marvell>> saveenv
    

    And that's it, as far as I can see.

    I'll now wait for people to tell me what I've got wrong above... :-)

    13:59 :: # :: /debian/arm :: 0 comments