Countdown To Pi 1 Loss Of Support, Activated

The older Raspberry Pi boards have had a long life, serving faithfully since 2012. Frankly, their continued support is a rarity these days — it’s truly incredible that an up-to-date OS image can still be downloaded for them in 2025. All good things must eventually come to an end though, and perhaps one of the first signs of that moment for the BCM2385 could be evident in Phoronix’s report on Debian dropping support for MIPS64EL & ARMEL architectures. Both are now long in the tooth and other than ARMEL in the Pi, rarely encountered now, so were it not for the little board from Cambridge this might hardly be news. But what does it mean for the older Pi?

It’s first important to remind readers that there’s no need to panic just yet, as the support is going not for the mainstream Debian releases, but the unstable and experimental ones. The mainstream Debian support period for the current releases presumably including the Debian-based Raspberry Pi OS extends until 2030, which tallies well with Raspberry Pi’s own end-of-life date for their earlier boards. But it’s a salutary reminder that that the clock’s ticking, should (like some of us) you be running an older Pi.  You’ve got about five years.

32 thoughts on “Countdown To Pi 1 Loss Of Support, Activated

  1. still got mine, never really used it for much of anything. i did a micro tablet with a lego case and an lcd and ran some games on it. ive since built 2 other pi tablets with 3d printed parts. i realized i wasn’t using them beyond getting them running and simply stopped buying them. but they can still be useful in a pinch.

      1. Can a Pi-1 handle streaming a camera view of the printer AND running the printer at the same time without any slowdowns? I notice that even with my Pi-2 it’s a little faster to print directly from SD than to use Octoprint. Or at least it was. I still prefer Octoprint so I haven’t really tried that way since before I upgraded from RAMPS to a 32-bit board.

      1. Gather around class… we are going to take turns watching one kid at a time hack on one Pi.

        Mmmmm… nah!

        A lot of schools already have tablets or laptops for the kids now. I think I’d rather buy a box of cheap Arduino clones, sensors, lights and other accessories for the class. Then I’d pick an easy beginner, kid-friendly dev environment for it and ask IT to make it standard on all the kids devices.

        But hey, I’m not a teacher. Maybe there is something I don’t know.

        1. You wanted to be smart but you proven yourself dumb. Linux is a UNIX-like multi-threaded, multi-user system. I see no problem if you create account for each student and they will log on to R-Pi by SSH.

          DOS era is long over bro :)

          1. So you’re suggesting that instead of just using the computer they have directly, they should each use the computer they have to SSH into the same much older, much less powerful SBC? It’s not 1970 anymore, students don’t have to timeshare on a PDP-11 to learn BASIC.

          2. Kinda hard for a child to hook up LEDs and sensors when the board is shared by 20 other students.

            Running 20 IDEs and VNC sessions and Python interpreters might be a bit much for 512mb of RAM.

            I feel like the student’s Chromebook could run a ln emulator for a crappy ARM with no I/O to real world as effectively as sharing an RPI would be.

          3. Have you used a pi? Especially a pi 1? Yes what you suggest may be possible but it really isn’t practical. Yes if this was a desktop then having multiple users working on it at once may be fine but not for a very low performance SBC.

      2. As someone with actual teaching experience, you’re right. Sure, a singular Pi isn’t going to be the basis of a curriculum, but that Pi could go into the Box of Stuff that students can pull from when working on their own projects.

        My favorite approach to STEM teaching is structured in-class teaching activities in parallel with freeform student-driven projects. It inspires creativity, lets students learn ahead of review covered concepts to learn at their own pace, and it keeps the students engaged because it is something they care about instead of just doing another boring by-the-book assignment.

        By all means, reach out to a local school and see if they have a STEM program interested in your old Pi, your extra Arduinos and random spare parts, your old soldering iron or outdated desktop scope. Even broken appliances are great because a teacher could disassemble them and explain how they work.

  2. I mean, you say “you’ve got 5 years…” but in reality if you’re running something on this, and it’s so reliable you half forgot about it, it’s unlikely to have been updated in the last 5 years, which means it can run until something fails.

    1. Depends on what you are doing with it – for a long time I ran a few simple web facing servers on my old Pi 1 for that low power 100% uptime, and that would be something you have only 5 years on if you kept it running. As web facing and not updated is just a bad bad idea.

      I have since moved on to something with more networking speed and compute so I can do a bit more on the one 100% uptime system, but that only Pi could have just kept on ticking ‘forever’ doing the old job.

      1. agreed! My central heating runs on a raspberry pi – 100% uptime required there :)

        For a few years it didn’t see very many updates, although there was only one port exposed, and some minimal security on it – enough to keep the baddies out.

        I’ve gotten better about updating now

  3. The desktop OS is too painfully slow, and for the command line I found my typing is faster than the keypolling. It can still handle a few tasks, but for this model it was assumed you woild rather r&d on an real PC and then move the files to the Pi for deployment.

  4. My impression is that ARMv6 was never successful beyond the BCM2835. There were lots of SoCs with ARM926 (ARMv5) and then the next ARM cores for Linux that saw widespread adoption were Cortex-A8/9/5/7 (ARMv7).

    If I remember correctly, the biggest difference between ARMv6 and ARMv7 from an application point of view is that you have dedicated barrier instructions instead of them being mapped to coprocessor instructions. Grepping through the ARM ARM, I see that ARMv7 also has LDREX/STREX for sizes other than 32 bits and there is a CLREX instruction. The division instructions of ARMv7 are optional. Don’t know if Debian assumes they exist. But it should be possible to handle all of this by using Glibc’s mechanism for searching libraries in different folders based on the available CPU features. The BCM2835 even has VFP, so that it should be possible to use the armhf calling conventions.

  5. My understanding is that the Pi Zero (and Zero W) use essentially the same processor as the original Pi (as does the original compute module, if anyone still has one of those), so those will also be affected by the loss of ARMEL support.

    For me, and I think probably a lot of other people, this is a much bigger deal than the loss of original pi support. I still find good uses for the zero boards I have. You wouldn’t think it’d make a huge difference, but they’re small enough to be unobtrusive or portable in places that the pi is just slightly too big. They still make nice streaming audio endpoints, USB SDR receivers, bespoke webcams, random-sensor-to-xml/MQTT servers, and even classic computer/classic emulators (if your idea of classic is itself “classic” enough – think 80s to very early 90s).

    On the bright side, most of my projects are pretty walled off from potential security risks, and if somebody does manage to hack one, the joke’s on them, because they are dog slow – Once you have a few services running, you can barely even run a bash terminal over ssh

  6. I’m a little upset by the attitude i saw in more than one comment here that seems to equate updates with security.

    The details are everything but i don’t think that security suffers bit rot as severely as people believe. Vulnerabilities are constantly being discovered but if you are at all paranoid in what software you use / expose, the vast majority don’t actually affect you. That may be a controvertial take on my part, and it could even be proven wrong for all i know..

    but!

    I hope we all know that regular updates do not guarantee security. If you aren’t paranoid and minimalist in what you expose, updates will not save you.

    1. My RPi is behind a firewall and has no external IP and I am not reaching out into the Web with a browser on it. Seems pretty low risk to me.

      The old school way of security was to simply limit what the machine is used for. Like the 1990’s advice was don’t use your DNS server as SMTP and POP/IMAP servers. Isolate everything you can.

      People are so paranoid because end-user applications are generally wide open, poorly secured, and have too many concerns to easily isolate.

    2. Plus, if you’re the sort of person that’s presumably well-represented on hackaday, the end of official Debian support doesn’t mean the system suddenly becomes un-updatable. As long as someone, somewhere, is willing to build Debian packages for the architecture, you can install them.

      I mean, I don’t think Raspberry Pi has weighed in on this, and it’s possible that raspbian/raspberry pi os will continue to release packages for their special version of armhf (which works with the oldest pis’ ARMv6/ARM11 processors) beyond 2030.

      and if they don’t, you can still compile everything yourself, use generic installers, or a third-party package manager like homebrew.

      Of course, at some point it may no longer be possible to compile the linux kernel itself, and packages that depend on it. That does put an eventual end to things, but it’s impossible to say when.

Leave a Reply to spiritplumberCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.