I think mine arrived like a year late as I recall but the hardware really appealed - a zynq dual core arm + FPGA - these are more popular now but back then this was the first I heard of these chips. The board came with the verilog for the hdmi out implemented on the fpga- as I recall there were some challenges building a bitstream like they provided from their source but it was so long ago I don’t recall the specifics, it did eventually work. I never succeeded at evolving their hdmi out into an hdmi in though, it turned out to be way more complicated to bring in an hdmi signal than to generate one - I’m not even sure if it’d be possible on the size of fpga provided.
Anyway that was all a sideshow - the real deal was the epiphany chip. I’m going from memory here so I could have this wrong but as I recall each core had a little ram and a fabric connecting it to other cores, so you could choose to use it like gpu compute - although that model wasn’t a great match because each core could branch independently without any real hassle but that then opened up the puzzzle of how to keep each core fed. Another strategy could be the deep pipeline approach like you’d take with an fpga. Treating it as you would a multi core cpu never really made much sense to me because of bandwidth limitations of the fabric.
It used to overheat quite easily but I just soldered on a tiny dc fan to the incoming barrel jack and that did the trick for me, if a little loud.
Anyway, a cool little chip. I still have the code as far as I got with my image recognition application, I was reading road speed signs and vehicle registration plates from images, I think I know what project I’ll have a play with this week!
I recall each core had a little ram and a fabric connecting it to other cores, so you could choose to use it like gpu compute
The CellBE chip used in the PS3 was like that: a full PPC 'main' processor and 8 'Synergistic Processing Element' which were (oversimplifying) stripped down processors with a lots of registers, small amount of local memory and an interconnect. Interesting idea, but in the end, not very easy to program effectively.
I do do remember seeing the Parallella and thinking 'hm, baby CellBE'. What did you create with yours?
No one remembers the GuruPlug, or better yet - the GuruPlug Server Plus,
When RPi 1 just came out this little gadget ran x86 Linux (!) and had hdmi out that could handle 1080p video, a feat that only RPi 4 can repeat.
the Sheevaplug, Guruplug, and Dreamplug are what really got me into embedded computing and linux. I still have my Sheevaplug in storage, and a Dreamplug in service as my internal DNS server. the Marvell Kirkwood SoCs they were based on were quite long lived, eventually being rebranded as lower-end Armada chipsets.
P.S. if anyone wants to tinker with that ecosystem, there's still quite a number of people dedicated to packaging up Debian for them, and if you're okay with some soldering to get UART access, you can get a brand new $18 Dell Kace M300 to try out. in a lot of ways, I still prefer them to any newer single-board computers, despite my pretty significant collection at this point.
I have a collection quite similar (in size and content) to the author, but I must have started a bit earlier as I have a bit more of the first RPIs and also a Dream plug (which is another successor to the sheeva plug, like the guru plug)
Right, it was ARMv5 too which meant toolchain support was somewhat lacking and it didn't support non-aligned memory access which meant some programs that were written with x86 assumptions tended to segfault randomly.
A bit off topic, but I have recently acquired a PCB which uses a Conexant CX92755. It is kind of supported by the Linux kernel, but I am completely unable to find a user manual / proper datasheet for this chip. If someone happens to have it stashed somewhere, I'd be super grateful as it would give me a few week ends of hacking with the board.
its a big fat arm cortex a8, i would say good luck on an english one if you hadnt looked already. at least are devicetree overlays and patches out there :/
The number of affordable still very powerful SBCs has grown to the point we probably need something like the rosettacode (.org) site, but aimed at comparing ways of obtaining the same tasks in a few chosen languages but on different hardware, for example how to flip a gpio, how to send a pwm signal to a mosfet, how to read this or that sensor, how to draw on graphics LCDs, communicate with RF modules, etc. followed then by a list of boards and method to accomplish the task on all of them using similarly named functions and variables when possible to make comparison easier. In some cases the code will likely be identical, while some lower level or optimized stuff will need to be more specific for a given hardware. A site like that could quickly become a place to go when looking for ideas and/or compare different SBCs. Opinions?
Sounds closer to the OSDev Wiki[1] than Rosettacode, but sure, that's a pretty nifty idea. I would gauge how many people are SBC collectors/hoarders before I went looking for a seed round tho. I'd guess outside of RPi's, Arduinos and a handful of other big names, there's a pretty small community that is really playing with multiple boards much less different processor archs regularly who could maximize a service like this. Most people I know focus on one or a small number of platforms, either because of budget or cognitive burden, but that's anicdata so who really knows.
I will of course suggest my obligatory pet peeve: for boards where it's applicable, indicate "can it run a stock kernel or does it rely on out-of-tree, vendor or community supplied/supported blobs" before I waste a lot of time reading further.
> indicate "can it run a stock kernel or does it rely on out-of-tree, vendor or community supplied/supported blobs" before I waste a lot of time reading further.
Seconded. At this point, unless a client is explicitly paying (a lot) for a specific processor, custom BSPs with outdated kernels are an absolute showstopper. I won't even bother evaluating the platform any further.
For SBCs that can run Linux, such information can be found on Armbian and DietPI forums where usually they discuss porting and availability of kernels and/or other software.
Let me add a requirement: Do I have to google the shit out of multiple forums to find out what it can run and how to keep it running? Also a waste of my time.
Odroids were amazing. At some point I had 16 of them spread out in various homes plugged behind routers scraping Amazon. They all reverse tunnelled their ssh ports to a public beacon for access. This went on for years until I didn't need them anymore. I still remember zeroing the sd card of odroid14 remotely because the owner had to move out and forgot about it. Sad times.
Can anyone recommend an SBC with >=16 GB of RAM that has been confirmed to run stably with the mainline kernel?
Edit: to be clear, I specifically need ARM CPUs. Headless is OK (although a basic console over HDMI would be nice). To answer myself, an Orange Pi 5 might fit the bill but I'm not sure how stable it runs at 100% continuous load (on a mainline kernel).
If you need that much ram, maybe consider n100 machines. For ~$180 you can a complete system with case, power supply, 16GB ram, 500GB ssd. The m.2 storage and amd64 distro compatibility makes it worthwhile to me.
Most of these SBCs top out at 8 GB (if you're lucky). you might be better off looking at a NUC-style tiny computer with x86 processor. There are some available on Amazon. https://www.bee-link.com/computer-73493777
My favourite will always be the C.H.I.P. by Next Thing Co[1].
I still have one. They were priced towards 9 dollars, had on-board bluetooth and wifi when the Pi didn't and was significantly smaller. Sadly the company couldn't make it work. They also had a "Pocket C.H.I.P." which was a small display and keyboard you could plug your C.H.I.P. in.
Some company did buy their work and is planning to sell the boards and some variants as as the Popcorn Computer, but it has lost quite a lot of its charm.[2]
I bought the original Raspberry Pi 2b as part of a homebrew NAS. Later I bought the Pi 3, Pi 4, Pi Compute 4 + board, Pi 5, 2 RISC-V boards, and a bunch of other boards. I don't have a need for them, I just enjoy collecting them.
I don't know why, but throwing away computers has always felt wrong to me. I have this small device, built on countless years of research and development that would have been unthinkable not too long ago and it's going straight into a garbage bag. Goodbye to all those semiconductors built on extraordinarily precise manufacturing processes and full of rare earth metals I guess. Now I got a new device with more memory and computing power that'll perform just as bad in a few years for the same tasks because a lot of software sucks ass.
I get that, but sitting in a drawer unused until you die is only a little different than land-filling it. Find a local makerspace, electronic enthusiast mailing list or other place interested people might hang out and offer it to someone who might be able to put it to work, esp someone who might not be able to afford the toy otherwise.
Wow, almost all of my SBCs are 8-bitters. uKenbak, Digirule 2U, PAL-1, 6502 Membership Card, dozens of ATMega boards. Plus the VIP2K, Altaid 8800, and 1802 Membership Card are all technically 2-board computers, but that’s only so they can fit in an Altoids tin.
EDIT: Timex-Sinclair TS1000, Commodore 64, VIC 20, Apple IIc, Apple IIgs, Macintosh SE, Macintosh LC II… do these count?
I also have a bunch of SBCs lying around waiting to be used, and also an ODROID HC2 which has been in use for years. I only dislike that it's not powerful enough for encryption--LUKS + samba could not read/write at disk speeds and was unreliable in my testing.
Really wish there would be an upgrade to the HC2 with about three to four times the performance.
I started out with Linksys NSLU2 (even ran my site off one for a lark), then moved to ODROID, Raspberry Pis, etc. These days I've got a few Rockchip variants around, and it's pretty amazing to consider how things evolved over the years (even without mainstream Linux support for some of the chips I've used).
The NSLU2 was pretty slow as a NAS, but the community that grew around it turned it into a really interesting platform for hacking, and I just love that Linksys back them didn't try to prevent hackers from repurposing it with alternate OSes etc.
Here's an archived copy of the then hacking page devoted to the NSLU2.
Fun post. I have also accumulated a huge collection of SoCs, SBCs and OTS/Custom/Production PCBs that came about from Client projects over the last 16 years. I love this space, if a project comes up, I usually support it.
Datasheet the for RK3588 used says H265 will do 8k@60fps. I assume lower than 8K resolution will be able to do 120fps, but don't know how that translates.
Maybe it's a feature that isn't often advertised (amd64 machines excepted). I find it frequently in the datasheets (and then verifying with schematics and testing).
Another non-advertised thing is "real" LVDS on the same physical pins as MIPI-DSI. Again, datasheets+schematics.
Thank you for pointing me in this direction. the RK3588 seems to have what i need, now i just have to find it in a smaller form factor/just remove the ethernet port and other large connectors from it i guess.
I think mine arrived like a year late as I recall but the hardware really appealed - a zynq dual core arm + FPGA - these are more popular now but back then this was the first I heard of these chips. The board came with the verilog for the hdmi out implemented on the fpga- as I recall there were some challenges building a bitstream like they provided from their source but it was so long ago I don’t recall the specifics, it did eventually work. I never succeeded at evolving their hdmi out into an hdmi in though, it turned out to be way more complicated to bring in an hdmi signal than to generate one - I’m not even sure if it’d be possible on the size of fpga provided.
Anyway that was all a sideshow - the real deal was the epiphany chip. I’m going from memory here so I could have this wrong but as I recall each core had a little ram and a fabric connecting it to other cores, so you could choose to use it like gpu compute - although that model wasn’t a great match because each core could branch independently without any real hassle but that then opened up the puzzzle of how to keep each core fed. Another strategy could be the deep pipeline approach like you’d take with an fpga. Treating it as you would a multi core cpu never really made much sense to me because of bandwidth limitations of the fabric.
It used to overheat quite easily but I just soldered on a tiny dc fan to the incoming barrel jack and that did the trick for me, if a little loud.
Anyway, a cool little chip. I still have the code as far as I got with my image recognition application, I was reading road speed signs and vehicle registration plates from images, I think I know what project I’ll have a play with this week!