New Part Day: A $6 Linux Computer You Might Be Able To Write Code For

The latest news from the world of cheap electronics is a single board computer running Linux. It costs six dollars, and you can buy it right now. You might even be able to compile code for it, too.

The C-Sky Linux development board is listed on Taobao as an ‘OrangePi NanoPi Raspberry Pi Linux Development Board” and despite some flagrant misappropriation of trademarks, this is indeed a computer running Linux, available for seven American dollars.

This board is based on a NationalChip GX6605S SoC, a unique chip with an ISA that isn’t ARM, x86, RISC-V, MIPS, or anything else that would be considered normal. The chip itself was designed for set-top boxes, but there are a surprising number of build tools that include buildroot, GCC and support for qemu. The company behind this chip is maintaining a kernel, and support for this chip has been added to the mainline kernel. Yes, unlike many other single board computers out there, you might actually be able to compile something for this chip.

The features for this board include 64 MB of DDR2 RAM, HDMI out (with a 1280 x 720 framebuffer, upscaled to 1080p, most likely), and a CPU running at just about 600 MHz. There are a few buttons connected to the GPIO pins, two USB host ports, a USB-TTL port for a serial console, and a few more pins for additional GPIOs. There does not appear to be any networking, and we have no idea what the onboard storage is.

If you want a challenge to get something compiled, this is the chip for you.

81 thoughts on “New Part Day: A $6 Linux Computer You Might Be Able To Write Code For

      1. look at the specifications of the board. there is not much power and memory available. running linux will already use most of this power. there is not much left for python. micropython is “a lean and efficient implementation of Python 3 […] optimised to run on microcontrollers and in constrained environments. […] giving you a low-level Python operating system. […] It is compact enough to fit and run within just 256k of code space and 16k of RAM”

          1. Sheer luxury…

            I had one of those awkward bastards that you couldn’t claim back the 128KB ROM shadow area or whatever it was, so had 3.9 ish MB…. that took a bit of wrangling to get any distro running on it.

          2. My slackware 10.1 system with kde was consuming 64MB after start. I managed to run the same system on p200mmx with 32MB but was slow and swapping a lot. We moved forward with better compilers, optimization and nowdays 64MB is considered barely enough for some console work. Wirth’s law seems to be true as never.

          3. I have MenuetOS as a netboot option for the machines on my LAN, it sure comes up fast, but it had issues that left me thinking hmmm has promise but not there yet. Will take a look at the others… All I really need is enough OS to start a SSH tunnel and pipe an X session through it, all the compute work can be done on whatever machines I can get a session on. The embedded side of things is very different though, would be handy for a smart hub in each room that runs everything IOT in that area then feeds traffic to the rest of the LAN. So many options, and that is one of the problems.

          4. It turns out that you can netboot directly via http from the 16MB TinyCore linux .iso file.

            From there you have a desktop and all of the software you need downloaded on demand. This is the smallest and fastest option I have found that basically gives you everything you need, else you can netboot a full Debian, and wait a long time for the LiveCD desktop.

          5. Talking of a distro that ran off 2x floppy disks…

            Now, if only something a little modern in that size range: 2.88MB +/-
            Also it was a very usable system on an old pentium-MMX laptop with 16MB RAM I purchased for the challenge of masochistically bodging Windows XP to install on: It installed but was too slow to boot to desktop.
            There was even support for PCMCIA and I found an ethernet card that worked at the boot sale, so I managed to get Hackaday retro site up with the craptop and Linux distro.

            All that’s needed is a distro-defat down to the size of the linked distro for this $6 SoC, chuck in a few lightweight media libraries and a few media players, this would make for a great MP3/portable-media-player project.

          6. Nowadays, getting Linux to boot with 4MB of RAM is a feat worthy of a talk at a conference :)

            Ryan Fairfax, “Azure Sphere: Fitting Linux Security in 4 MiB of RAM”

          7. Replying to John S. Sir, if you are going to use the marketing abomination that is “MiB”, please use it correctly. For memory, MByte is correct, MiByte is used for storage.

          1. Because Python is cool and trendy. No one gives a flying duck that it’s too big and heavy and slow for systems with limited resources. Who needs fast program execution anyway?

          2. horses for courses. Some people like all of the libraries n stuff you can use with Python and the more streamlined syntax, and the way you don’t need to declare variables, which is all well and good when you have a lot of power and memory. For microcontrollers though, probably not so good?

      2. My first linux system was slackware installed from 23 floppy disks on a 486 dx2/66 with 8MB or ram 260MB IDE HDD, 80MB tape drive connected to the floppy controller with a patched kernel 1.1.18 and supported multiple terminal logins and SVGA GUI with 8 windows with a 2MB trident card – now people complain that a 600MHz processor with 64Meg ram is slow…….Jeeeze I got more fun compiling updates of libc, binutils, gcc, etc on that system than using any of the latest distributions. I had more control and understanding of my system with a 2004 Mandrake distribution than the latest Ubuntu releases.

          1. i remember the era. those were the times where you needed to use a calculator to figure out the disk partitioning, and there were no distribution files, just crude tarballs…

          2. we had to cross-compile kernel on mips based SGI boxes runing irix to get a bearable compile time… the 486dx33 i first used linux on and tried compiling the kernel sources was like a snail trying to cross a bucket of glue

  1. FYI specs from:

    * SoC – Nationalchip GX6605S C-SKY ISA V1 CK610M 32-bit processor @ 574 MHz with 64MB DDR2 RAM, built-in DVB-S2/S demodulator
    * Storage – 4MB SPI flash for bootloader and media player program
    * Video Output – HDMI output up to 1080p; framebuffer resolution (for UI): 1280×720
    * Video Playback – H.264 up to 1080p
    * USB – 2x USB2.0 host ports
    * Expansion – 5-pin header with 3x GPIOs, 3.3V, GND
    – JTAG via XX32F103C8T6 USB-JTAG chip (micro USB port)
    – UART console via CH340g USB-UART chip (micro USB port)
    *Misc – 5 user buttons, reset button, 4x LEDs
    *Power Supply – 5V/1A via micro USB port (JTAG or UART)

    1. XX32F103C8T6, eh? I wonder whose slightly unauthorized tribute to the STM32F103C8T6 that is. And whose USB-JTAG firmware it’s running, and whether or not any of the pins wired to the CPU can be muxed to non-JTAG roles. A companion STM32 could be handy for a lot of things, but I don’t expect that they provided enough connections to realize that potential.

      1. JTAG usually have access to internal R/W to target memory and registers. It may support self hosting and the firmware can be modify to emulate some mail box style of message passing for controlling the board. F103 without any I/O connections beyond the USB device means that there are only limited things it could do.

      2. I can’t read the markings on the photo above, but that LQFP on the right looks like it’s about the right size. My guess is that it’s a GD32F103, i.e. the slightly-faster/cheaper and mostly-compatible Chinese clone.

        It might even be running a pirated copy of the STlink v2 firmware :)

    1. Yup. Not considering the video-related features, this is the kind of horsepower one used to run OpenWRT (and not a full Linux distro) a few years ago. There’s a reason nobody buys a Linux board with less than 512M RAM and multiple cores anymore, even for a headless server…

      1. I’m still using a hacked pogoplug running full Debian with 256MB of RAM as a network adblocker (pihole) / netatalk file server for 12 users in TYOOL 2018. Stop making excuses for your ineptitude.

    2. You haven’t experienced a slow and laggy UI until you’ve tried a Philips TV.

      But i do have to ask, if this board is featured here, how come not the AVR and STM32 (and perhaps others) compatible MCUs, which have been sold for few years now?

    3. Still quite powerful for the price range and footprint of the SoC… and it reminds me of an old “pocket PC” machine of mine:

      This has almost the specs of an Archos 605, the Wifi version being preferred for the linux-hacks and homebrew back in the day as they made for a great PDA hack at the time.

      This would be nice for I to tinker around with and maybe getting a cheap touchscreen LCD running on it with a lightweight Linux and minimal X-like system.

      By today’s standard is agreeably a little lacking, but still looks fun to tinker with.

  2. …Yes, unlike many other single board computers out there, you might actually be able to compile something for this chip…

    A lot of the readers and hackers of Hackaday are not aware of some of the limitations which come with their favorite single-board computer, whatever that device might be.
    In the interests of increasing the general knowledge of our reader base, how about commenting on the limitations of some of the more popular single-board computers?
    I’m not talking about, “It doesn’t have enough I/O” as much as I’m referring to, “You can’t compile…”; or, “A computer like this ought to have…”.
    Let’s keep this positive; you can disagree with someone (design decisions) without being disagreeable.

    1. Think it mostly just boils down to binary blobs. HAD has covered those in the past;

      In contract, this little Chinese board has no black box of binary mystery.

      tl;dr You don’t program the hardware on a RPi to do a thing, You program to politely ask the binary blob in firmware to a thing in hardware. If the binary blob says “no”, tough cookies. (See also OpenGL implementation on RPi)

  3. Considering that GX6605S is around 4.3eur/pcs on aliexpress, something Allwinner V3s based would have a faster core, ethernet MAC&PHY a +1GHz core and best of all, have an ARM core.

    Tho the whole “article” is rather detail free. At least buy the cheap baord to verify that it can be bought.

    Raspberry Pi Zero and all the banana pi and orange pi boards exist.

  4. How about–

    It really, really bugs me when I can’t get I/O 8-bits wide; i.e., one BYTE-at-a-time.
    The computing world is byte-oriented (DON’T counter with your 64-bit processor example–ALL its memory is byte-oriented). One bit at a time is is useless for serious work. I’m surprised that this “speed-killer”, that this “capability-killer”, has never been the subject of any on-going discussion.
    Want to output any data–at high speed–from the Raspberry Pi, or any of its ‘work-alikes’ with their 40 ‘bit-banging’ pins to a communications device? Good luck.

      1. Don’t waste your valuable time ‘checking the datasheet’. If it were as easy to do as it is with other micros–Arduino, Microchip, ANYbody’s single-chip micro–you wouldn’t have to check the data sheet; it would be common knowledge.
        THE common knowledge is that it’s not possible. But you can blink an LED by performing ‘bit-banging’ under control of a high-level operating system–almost as fast as with a 555.

        Just think about how fast the Raspberry Pi and all its ‘work-alike’ cousins would be if you could output one (or two, as some micros can) bytes at a time,

        For that matter, just think about how fast the Raspberry Pi and all its ‘work-alike’ cousins would be if you didn’t have to load a high-level operating system in order to make them do anything.

        1. These are for an entirely different market, though. Chips like this are designed to run an OS and do “desktop-like” things, not for real-time low-level IO. Chips like what you are talking about do exist, with e.g. the PRU coprocessors in the chips that power the Beaglebone, and you could argue that FGPA hybrid chips like Xilinx’s Zynq also provide the same capability.

          It also *is* actually possible to program the Pi bare-metal, it’s just that not that many people do it because they are ludicrously overpowered for most uses. To write code that actually utilizes the resources of the chip in bare metal your code is gonna be pretty complex.

          And you’re example of memory being byte-oriented is extremely misleading. Modern memory does tend to physically be organized into 8-bit blocks internally, but their bus connecting them to the processor is definitely not.

        2. It should be possible to output 8 ore more bits via GPIO on a Raspberry Pi. The BCM2835 for example (I assume the same goes for the BMC2836 and 2837) has two GPIO banks and Output Set/Clear registers for both. The only annoyance I can see from a quick glance at the datasheet is that there’s no register to directly set/unset the pins, you’d need two register accesses (one for setting the required pins and one for clearing the others). Accessing the registers in Linux should only require a quick memory mapping.

          I’d be more curious as to what other device you want to talk to via an 8-bit bus. Unless it’s a memory chip, display controller or a DAC/ADC most peripherals nowadays seem to prefer serial connections…

      2. The TI Sitara ARM-Cortex-A8 processors, which can e.g. be found on the Beagle Bone Boards, have 32bit GPIO registers, i.e. you can set and read up to 32 pins at the same time. They also have atomic set and clear registers to avoid non-atomic read-modify-write cycles. Whether drivers support it is a different question, but the hardware does.

    1. Meh, there isn’t much call for parallel ports these days. Most peripherals you want to attach to something like this will have an I2C or SPI interface (or UART if it’s old-school) and you use the built-in DMA to pump streams of bytes to/from it.

      Ain’t nobody attaching 8-bit parallel RAMs/ROMs/ADCs designed for use on an 8051 anymore.

      You wanna live in the 20th century, go buy an MCP23017 and plug it in.

  5. With a Buildroot distro, I wouldn’t expect to be able to install stuff pre-compiled (.deb or .rpm), everything would need to be compiled from source. 64MB of RAM, isn’t very much when you’re compiling modern languages like C++ so it would need much of the software cross-compiled, which for packages not already supported by buildroot is going to be a lot of work. I concede that some like to do the most they can with the minimum of resources, but if you’re a hobbyist it may be worth spending $20 more and getting a system with some memory.

    1. Ahahaha “modern languages”. If you want a memory hog, try JS.

      You know that we all started using linux with like 4MB of RAM and gcc?

      Sure, you don’t get to run ubuntu on this, but that’s not the point. The important thing is that you *can* actually build a complete and working linux on this thing from source without any black-box binary dependencies. If you’re trying to make a product, that’s critical to ensure you have no dependencies you don’t control. Mainstream kernel support is also *huge*.

      PS: buildroot is a cross-compilation system…

  6. I want a little SBC with four SATA ports on a RAID controller that’s properly connected to the rest of it instead of through USB. Also give it a gigabit ethernet port and preload it with RAID/NAS software and a mini webserver for configuration via any web browser.

  7. I thought the name “OrangePi NanoPi Raspberry Pi Linux Development Board” is for SEOs with original Chinese, the online translation result has a little misunderstanding.

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.