RAM And EMMC Prices Are So High, Pine64 Has Stopped Linux Device Production

We all know that the price of RAM and storage has shot up due to demand from the AI industry and other factors. In most cases that means we grumble about the price, but if we really need the part we can fork out for it. [CNX Software] are reporting that rather than continue to push up their prices, Pine64 are responding to the crisis by halting production of their Linux boards for the time being.

We’ve seen online comment over the now-exorbitant cost of other boards such as a fully-loaded Raspberry Pi, and this follows in that vein. If we had to guess we’d speculate that the high prices have resulted in too little in the way of sales, which considering the knock-on impact on our community if other vendors follow suit, could be concerning.

If there’s one bright spot in the current situation, it’s that for many applications where a single-board computer might be used, a microcontroller might now be a better choice for the job than something running Linux. We’re in a very different situation from that we were in when cheap Linux boards appeared, the current generation of high-power microcontrollers have significantly closed the gap between the two. Given that microcontrollers have onboard memory and storage, their immunity from the price hikes makes them even more attractive. As to Pine64, we hope that sales of their other products make up for it.


Header image: BasilicumTree, CC0.

35 thoughts on “RAM And EMMC Prices Are So High, Pine64 Has Stopped Linux Device Production

  1. FreeDOS and PC-MOS/386 have lower hardware requirements anyway.
    Will we see a comeback for x86 based single-board computers, maybe? :)
    Many NICs have DOS drivers and the AT platform was well standardized.

      1. Good point. On a second thought, I often think maybe people should simply get what they deserve.
        If someone is used to eating fast food, for example, why wasting all the energy and time to produce a good meal for that person.
        It may not value it, anyway. Each to his own.

    1. x86 is largely a dead-end in the power efficienct SBC market, because Intel owns patents on basically everything that’s the definition of x86, and AMD has the rest.

      And if Intel had its way, even AMD wouldn’t be making x86 processors.

      There’s a reason almost everything in that regard is predominantly ARM, with some ancient MIPS ones floating around + Risc-V starting to take off in the lower-end, and maybe some positively ancient x86 SoC’s that basically exists because the patents for the bits of them have expired.

      In a ironic fashion, Intel itself is holding x86 back…

      1. It looks like haven’t heard of the new Wildcat Lake Intel CPUs. Their power efficiency can only be compared to the M4, which demonstrates power efficiency is unrelated with the instruction set. In fact ARM since the Thumb extension is considered CISC too.

      2. Hm, I see. I would have had assumed that the remaining patents for 8086-80486 processors must have been expired by now (the generations that still were general-purpose CPUs; used SCSI controller boards to servers).
        Secondly, I thought there used to be a flood of 486 compatibles in the 90s made by a dozen manufacturers.
        I’m not sure by whom where their patents currently are being owned by, however.

        1. AMD were originally a licensed second source for producing Intel’s designs. (Back in the early days manufacturers were hesitant to select a CPU for use in their computer designs if they didn’t have an option for an alternative suplier in the event of production shortages.) The other x86 manufacturers like Cyrix, NexGen, Centaur, Teansmeta, etc were all unlicensed clean sheet reimplantations. Over the decades most of those manufacturers got gobbled up in acquisitions (some by AMD) and the only remaining one is VIA who bought both Cyrix (from National Semiconductor after they originally acquired them) and Centaur and is now a wholly owned subsidiary of TSMC.

    2. Zephyr OS is nice too, and runs on ARM, RISC-V, and x86 families. Only needs around 16kB RAM and 256kB flash, depending on what you’re doing. I’m not sure what FreeDOS would buy you when you soon won’t be able to find an x86 that boots into 16-bit real mode. But it was difficult back in the day to get DOS working on an IBM PC with less than 64 KB (I’m not even talking about 640 KB, which was quite a luxury initially)

      1. I admit I didn’t have tested current FreeDOS or MOS in low RAM..

        However, DOS 2.11 was available in ROM in the Tandy 1000 in 1984 or so.
        It could be run from ROM directly (no RAM copy needed).
        MS-DOS 5.00 and Datalight ROM-DOS had this ability, too, I guess.

        I myself ran MS-DOS 6.2 in 256 KB on an 80286 board once, I remember.

        But it was difficult back in the day to get DOS working on an IBM PC with less than 64 KB (I’m not even talking about 640 KB, which was quite a luxury initially).

        I do lack experience here, I didn’t use DOS until 512 KB/640 KB were considered a minimum standard for PCs without extended memory.
        PCs and clones before 1985 must have been equipped with 256 KB of RAM or less, I guess.
        An Sanyo MBC 550 in the DOS 1.25 to 2.11 days or something along these lines.
        Not sure how 8088/8086, 80188/80186 or V20+ SBCs were equipped back then.

    3. The hardware requirements don’t matter. The interface requirements do. Right now even the smallest DDR4 is dumb expensive, and older memory interfaces aren’t made at the same scale and long-term availability is always a question anyway.

      As others have mentioned you’re probably best off with a microcontroller if you want to go lowest cost. At this point many microcontrollers are scale-wise the same as DOS-level PCs anyway.

      1. As others have mentioned you’re probably best off with a microcontroller if you want to go lowest cost.

        Hey! They want fast food, not me. :)
        (Just kidding. I understand that “you” often refers to someone.)

        “Lowest cost” is always a two-folded sword, I’m afraid.
        Being cheap can backfire in several ways.
        There are hidden costs or headaches that may not be apparent at first.

        At this point many microcontrollers are scale-wise the same as DOS-level PCs anyway.

        DOS PCs and DOS based SBCs can run their own suite of develepment tools, at very least.
        It allows developing in-circuit in a much more intense way.
        Even if merly a serial port or ethernet port is available, DOS can be remotely operated (CTTY, remote desktop software).

    4. Jokes aside, what I think is (was) notable about DOS platform besides its openness is (was) its large software library.
      There are (was) a huge number of professional development tools and programming samples for various programming languages and purposes.

      I remember there used to be many, many utilities being written by individuals in the days of shareware CD-ROMs and personal homepages (old web).
      On commercial side, manufacturers of x86 SBCs used to sell DOS-bassd development kits, too..

      So a come back for x86 SBCs is not an unreasonable consideration from a technical point of view, I think.
      – They were just commonly sold until recently.
      A DOS-based SBC can do same thing in a few hundred KBs/few MBs of RAM
      that a modern Linux would require about a few hundred MBs for.
      In a serious global RAM shortage, 64 MB of RAM are plenty to any DOS based system, while a standard Linux kernal barely fits into 64 MB of RAM anymore.

      1. “if all you have is a hammer, everything looks like a nail.”

        Do you really think there are hundreds of megabytes RAM in all embedded Linux devices?

        DOS is mostly an application loader. It offers very little OS services not related to filesystem. No multitasking, no memory management, no protection, not re-entrant. Making an embedded application to an x86 SBC running DOS would be an instant jump back to 1980’s.

        Also chip count would be higher. You would need separate UART, parallel I/O, timer etc. (80186 has those but is hopelessly obsolete e.g. because of low maximum clock frequency.)

        1. Do you really think there are hundreds of megabytes RAM in all embedded Linux devices?

          Did a Raspberry Pi with less than 256nMB of RAM ever ship?

          I’m sorry, but I refuse to answer such questions, they lead to nowhere.

          DOS is mostly an application loader. It offers very little OS services not related to filesystem. No multitasking, no memory management, no protection, not re-entrant. Making an embedded application to an x86 SBC running DOS would be an instant jump back to 1980’s.

          Hello Old Man, I recommend to have a look at Novell DOS 7, which was popular in the OS/2 Warp days.
          It has multitasking, it has DPMI and DPMS services etc.
          https://en.wikipedia.org/wiki/DR-DOS#History

          Then there’s the category of multitasking/multiuser DOSes.
          They are true preemtive OSes, but are binary compatible to MS-DOS applications.
          To them do belong: PC-MOS/386, MPM, Wendin DOS, Multiuser DOS and its successors (Real/32)..
          https://en.wikipedia.org/wiki/Multiuser_DOS

          73s.

        2. DOS is mostly an application loader. It offers very little OS services not related to filesystem.

          I forgot to mention, in the “dark ages”, 1980s, there were several business solutions to multitask on ordinary DOS.

          There was Quaterdeck’s DESQview, for example.
          It ran DOS applications preemptively side-by-side in text windows, on an 8088/8086 PC (EMS board was being recommended).
          It was a spiritual successor to IBM TopView (1984).

          Then there also were DESQview/386 and DESQview/X.
          One was designed around QEMM, the other one had an X server with Windows 3.1 support.

          DESQview also was historically important for introducing useful APIs to DOS world.
          DOS applications that were DESQview aware could be better integrated into multitasking environments (they emulated some DESQview APIs).

          A simpler tool was Borland’s Sidekick, also.
          It was a pop-up TSR with useful utilities (PIM).

          More information:
          https://en.wikipedia.org/wiki/TopView
          https://en.wikipedia.org/wiki/Borland_Sidekick
          https://en.wikipedia.org/wiki/DESQview

          1. So be it. We have a dissimilar view of micro OS – you are thinking of a desktop OS, with self hosting toolchain and I’m thinking about embedded systems. I see your points, and mostly accept your views. We both appreciate old systems.

  2. Did you mean “we’d speculate that the high prices have resulted in too little in the way of sales” instead of “we’d speculate that the high process have resulted in too little in the way of sales”?

  3. MRAM has been less affected by the so-called RAMpocalypse, and SBCs and MCUs generally don’t need huge amounts of memory anyway. There’s also the possibility that increased DRAM production from CXMT and YMTC could help relieve some of the overall strain. Even if much of that capacity ends up serving foreign demand, it could still free up Korean and Western supply for markets increasingly shaped by geopolitics.

    At the same time, China is developing its own MRAM and HBM technologies, although much of that production is likely to remain focused on its domestic market. All of this is pushing the industry to look beyond simply producing more memory and toward using the memory we already have more efficiently.

    That’s where the software side becomes interesting. Minimalist distributions are gaining traction again as embedded developers and enterprise software teams move toward bare-metal architectures, lean Linux environments such as Alpine and tuned Yocto builds, and custom container images instead of bloated default OS installations. Software stacks themselves are being reconsidered, with memory-hungry runtimes and enormous Electron applications increasingly giving way to compiled, resource-efficient languages such as Rust and C++.

    Memory optimization is becoming a design requirement rather than something developers worry about after the fact. Hardware is moving in the same direction. CXL allows modern servers to use memory pooling and dynamic allocation over PCIe, improving compute-to-memory efficiency instead of simply stuffing every host with as much fixed RAM as possible. Meanwhile, smarter SoCs and MCUs are integrating dense SRAM caches and technologies such as eMRAM directly on-chip, reducing dependence on expensive external DRAM and NAND.

    So the response to the memory crunch isn’t going to be just “build more RAM.” It’s becoming a broader shift toward making hardware, operating systems, applications, and even system architecture more memory-efficient. The RAMpocalypse may ultimately push the industry into building systems that were overdue for optimization anyway.

    1. I’m not sure if this has happened at all on consumer apps yet. I really hope it happens though… stuff like the Whatsapp UWP is an atrocity.

      AI could be a valid way to write lower level code.

  4. Something that is not as visible is also going on because of the high prices of RAM.
    The foundries that are capable of making RAM have shifted their production to produce only RAM and neglecting the other type of devices that demand lower prices. There is only so much capacity at the foundries, so all semiconductors are increasing in price, while available stock is reducing to the levels we have seen during Covid.

  5. So, at some point (my best guess is shortly after the POTUS elections when all the props get kicked away), the AI bubble will burst.

    Spectacularly. You can’t predict a $30 trillion in revenue (NVDA) or budget for $1 trillion in spend (OpenAI) and think that those numbers are real. Seriously. It’s not different this time.

    Anyway, at that point the glut of ram and gpu production will be overwhelming as manufacturers who had previously presold years worth of production desperately look for new (old) markets. At the same time 1/2 built or already obsolete data centers will try to recoup some of their enormous sunk costs.

    It will be a magical time for hackers and gamers.

    You know, assuming there are people and an economy left to enjoy those things.

    1. We might not even have to wait that long. The CAPE ratio has been in the low 40s since early this year. Echoes of the dot com crash are echoing.

      1. It will implode faster and louder than ever before. Prediction models have advanced a lot since the dotcom bubble and stock trading is mostly automated nowadays. If just one pension funds decides to dump their shares of one of the AI players others will follow and the house of cards will collapse. Within milliseconds.

  6. In less than 2 years from now RAM production will shift from Korea to China and in quantities never seen before. Prices will drop accordingly. Not only that, I bet China will be the first fabricating sub-nm chips and its going to be soon (2-3 years).

    1. Expansive claims there.

      More good RAM will increasingly come out of China, which I’m excited about. But it’s not like RAM production will slow (at least not significantly, it might go down or reprioritize a bit if AI demand drops) in Korea.

      Also, process node size-based names have been silly for a little while now. Sure, China might be able to claim first sub-nm on some chips, but it’s really about transistor density, power delivery, and packaging it in a useful way. China’s been doing a great job catching up, but it’s had a hard time at the bleeding edge and doubt it will catch up to TSMC or even Intel in the next decade, even if they call it sub-nm. Then again, I think bleeding edge process nodes are a bit overrated.

      1. basically that, I suspect we may stop pursuing density particularly when removing heat becomes the limiting factor of scaling, and resume when the materials become rare again.

        you can pack a lot of compute at wafer scale, and its a damn sight easier to remove the

  7. Pine64 wasn’t really worth buying anyway, when a few years ago they decided to kill a great ecosystem of different Linux distros the community was developing in favor of just Manjaro and caused Martijn Braam to quit.

    Their decision here I’m guessing is related to the effects of that move as much as it is the RAM cost. So even if you could buy the hardware, software support for it is terrible because of this hostile move against the Pine64 dev community.

    https://blog.brixit.nl/why-i-left-pine64/

Leave a 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.