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: Dropping support for the smallest armel machines
Martin Guy wrote: +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 Has anybody investigated using something like OpenFirmware as an intermediate boot loader? If that were in internal Flash then it should be possible to load the kernel from external storage- or in principle over TFTP etc. Another issue for tiny devices is the amount of RAM the Debian installer assumes is available, which now appears to be 256Mb. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] -- 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/kqeaut$ld$1...@pye-srv-01.telemetry.co.uk
Re: Using /usr/lib/gcc-cross/ for triples
On 06/19/2013 06:49 PM, Wookey wrote: +++ Stephen Kelly [2013-06-19 15:48 +0200]: Hi there, In attempting to use clang as a cross compiler, clang needed to be able to find some c runtime files etc which are part of gcc it seems. However, clang only looks in /usr/lib/gcc/$$TRIPLE for such files. It does not look in /usr/lib/gcc-cross/$$TRIPLE , which is where the files are on my ubuntu system at least. I assume it is the same on debian. Maybe. This was a relatively recent change make by the gcc maintainer (I.e they used to be in /usr/lib/gcc/$$TRIPLE but were moved to /usr/lib/gcc-cross/$$TRIPLE. I don't actually know why. Presumably to avoid some sort of potential files clash/version-skew issue between native and cross compilers. But as you say, given theat there are already triplet and version qualifiers in the path for the files in there, one might think that was sufficient. Thanks for the confirmation. Doko - why did this path get changed? Ping? Doko, any response? Can you point to the patch where the change was introduced? I have no idea how to find the patch. Is the package in a repo somewhere? Thanks, Steve. -- 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/51cac2e9.6060...@gmail.com
Re: Dropping support for the smallest armel machines
Dropping support for nslu2 is fine with me. As noted above, I can continue running it with an older kernel and be equally happy. Or I could retire it and get (another) rpi. What would be (a little) worse for me though is dropping orion5 support. I rely on security updates for my ts-209. OTOH, by 2016 it may well be ready to be replaced by something faster. /B On Wed, Jun 26, 2013 at 11:29 AM, Martin Guy martinw...@gmail.com wrote: On 26 June 2013 11:06, Mark Morgan Lloyd markmll.debian-...@telemetry.co.uk wrote: Another issue for tiny devices is the amount of RAM the Debian installer assumes is available, which now appears to be 256Mb. I just debootstrapped wheezy onto an armel board with 64MB RAM and no swap. Everything worked fine with the single exception of packages that contain files compressed with .xz, which died for lack of RAM - there were were one or two. Enabling a few MB of swap made the second stage run smoothly to completion. M Ignore my -Os stupidity. Of course it is already enabled in linux through CONFIG_OPTIMIZE_FOR_SIZE. -- 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-wqpbepv4cke+ceg11rccu2qgcctox0p+5ytpcwdsqso...@mail.gmail.com
Re: Dropping support for the smallest armel machines
On Wed, Jun 26, 2013, Mark Morgan Lloyd wrote: Has anybody investigated using something like OpenFirmware as an intermediate boot loader? If that were in internal Flash then it should be possible to load the kernel from external storage- Yeah; I didn't have time to try it out, but there's also a WIP GRUB port for U-Boot done by Leif Lindholm which might be suitable for U-Boot platforms (N2100 is RedBoot based though). That is, you load GRUB as an n-stage bootloader instead of loading a kernel. or in principle over TFTP etc. The RedBoot build on N2100 has TFTP and even (basic) HTTP support! -- Loïc Minier -- 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/20130626120819.ga8...@bee.dooz.org
Re: Dropping support for the smallest armel machines
On Wed, Jun 26, 2013 at 02:08:19PM +0200, Loïc Minier wrote: On Wed, Jun 26, 2013, Mark Morgan Lloyd wrote: Has anybody investigated using something like OpenFirmware as an intermediate boot loader? If that were in internal Flash then it should be possible to load the kernel from external storage- Yeah; I didn't have time to try it out, but there's also a WIP GRUB port for U-Boot done by Leif Lindholm which might be suitable for U-Boot platforms (N2100 is RedBoot based though). That is, you load GRUB as an n-stage bootloader instead of loading a kernel. Leif says it depends on the u-boot API being configured in for GRUB to be able to use it. Worth checking if it's available on the smaller systems... -- Steve McIntyre, Cambridge, UK.st...@einval.com The problem with defending the purity of the English language is that English is about as pure as a cribhouse whore. We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary. -- James D. Nicoll -- 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/20130626123625.ga18...@einval.com
Re: Dropping support for the smallest armel machines
* Björn Wetterbom bj...@wetterbom.se [2013-06-26 13:28]: What would be (a little) worse for me though is dropping orion5 support. I rely on security updates for my ts-209. OTOH, by 2016 it may well be ready to be replaced by something faster. Ben didn't propose dropping Orion altogether -- it would only impact the D-Link DNS-323, not the QNAP devices (which have a 2 MB kernel partition). -- Martin Michlmayr http://www.cyrius.com/ -- 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/20130626124922.ge28...@jirafa.cyrius.com
Re: Dropping support for the smallest armel machines
Ben Hutchings b...@decadent.org.uk writes: We have a recurring problem with building kernels for armel: three flavours (iop32x, ixp4xx, orion5x) require the kernel image size to be less than 1.4-1.5 MB in order to fit into a fixed flash partition. As more features continue to be added to Linux and cannot always configurable as a module, it is necessary to override and disable them on these three configurations[1]. I don't think this is sustainable unless someone who particularly cares about these older platforms steps up to take on this task. The iop32x and ixp4xx hardware appears to been discontinued in 2008. If we remove these flavours now, they will still be supported in Debian 7 until 2016. I think 8 years of support is pretty good. btw, iop32x is used on n2100 which are used on buildd/porter boxes. If we stop supporting it, I'm not sure how the DSA people will react about that. According to comments in the current configuration, the current size limit of 1.5 MB for orion5x is due to the DNS-323, while other models have a ~2 MB flash partition for the kernel. Dropping support for the DNS-323 would make it possible to raise this limit. However, this model was only discontinued in 2012[2]. Perhaps it could be supported by putting a second stage uboot in flash which would load the kernel and initramfs from disk, as suggested in [3]? afaik, there's work upstream to get the same binary kernel running on armel Marvell SoCs (with DT) so if we merge the corresponding flavours, it may result in bigger kernels (it may result in smallers kernels but it's unlikely). We'll know that when it'll be working/available. Arnaud -- 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/87bo6t816b@lebrac.rtp-net.org
Re: Dropping support for the smallest armel machines
On Wed, Jun 26, 2013 at 03:13:48PM +0200, Arnaud Patard wrote: Ben Hutchings b...@decadent.org.uk writes: We have a recurring problem with building kernels for armel: three flavours (iop32x, ixp4xx, orion5x) require the kernel image size to be less than 1.4-1.5 MB in order to fit into a fixed flash partition. As more features continue to be added to Linux and cannot always configurable as a module, it is necessary to override and disable them on these three configurations[1]. I don't think this is sustainable unless someone who particularly cares about these older platforms steps up to take on this task. The iop32x and ixp4xx hardware appears to been discontinued in 2008. If we remove these flavours now, they will still be supported in Debian 7 until 2016. I think 8 years of support is pretty good. btw, iop32x is used on n2100 which are used on buildd/porter boxes. If we stop supporting it, I'm not sure how the DSA people will react about that. [...] Bet they're slower than QEMU versatile emulation on an x86. And DSA loves virtual machines. :-) Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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/20130626153915.gf4...@decadent.org.uk
