About 5 years ago, I was involved in a project where we purchased Intel based tablets based off a standard reference design in bulk for about $80 a piece - that included battery, cameras, screen, casing and more.
The cost of the board only was about ~$30 or so.
I really wondered why no one was selling these to compete against the Pi in the heyday.
The only problem we had and why we didn't sell to makers was because we didn't control the design and we had enormous technical problems with EFI/Bios 64 bit booting only and a headache like crazy trying to reinstall Linux which just randomly broke all the time.
Why not just use a 32bit EFI bootloader like grub? I did that with some Baytrail device some time ago and it worked without a hitch (there were other problems though). If i remember correctly you can also boot a 64bit kernel from there if that is what matters to you...
Dealing with EFI issues like this right now! It's made worse because we run Windows 10 IoT Enterprise on the devices and much of the work I did on our 64-bit OS image is mostly invalidated because our next tablet has the exact same processor but only 32-bit EFI.... Oh man, it can really screw with your logistics when you rely on consumer tablets. There's one reason to pay a premium for 'industrial' devices.
I will say this additionally though - the messaging around the Intel Atom line, IMHO has been absolutely terrible. If only our software could run on ARM. I was convinced at one stage they were discontinuing the whole thing and then suddenly they didn't? I don't even know anymore. They have a roadmap so I guess that's something.
TL;DR: Think very carefully before basing a product on consumer-grade hardware, especially with consumer-grade tablets. To the parent commenter, you're probably lucky you DIDN'T push through it :)
It's a .NET application that still potentially relies on some third-party x86 binary drivers/components that are only on Windows. Ideally in the future the whole codebase could be ported over to .NET Core, with the remaining native components being stripped out (we've somewhat worked towards this).
Really though, it's that we don't have the resources to dedicate to any porting or compatibility effort (I've toyed with the idea of QEMU on ARM) to do it, so unfortunately it's one of those things that gets very slowly pieced together in the background here and there. Too big a project to convince the higher-ups that it's worth the tradeoff of prioritizing it over new features and new customers.
I still use and maintain about ~60 Intel edisons. Such a great little device. Onboard storage, 5ghz Wifi, and super low power useage. My only gripe was the yocto linux distro they used was a bit janky.
I was really disappointed when they discontinued the project. I guess Intel wanted to invest more in the Movidius ai compute stick, since that is where most of the Edison team was moved to.
IIRC this was a major problem with the Bay Trail generation (32 bit EFI, 64 bit CPU). These are Cherry Trail generation chips (one generation newer) which did get 64 bit EFIs. That's not to say this board has a 64 bit EFI, but the vendor could avoid problems if they're smart.
I'm not surprised, EFI is a mess in general. Good old BIOS has worked for 30+ years, and is simple enough that it's not hard to get right (yet there are/were some that still did...) --- load the first sector of the boot device at 7C00 and jump to it.
And then spend then next 400,000,000 cycles progressively switching from 40 year old 8086 real mode to the present, reading some newer firmware configuration tables from that same BIOS (which are often buggy), compensating for those bugs, etc.
That's still less than a quarter of a second, granted. But the complexity goes to the OS instead of a reasonable separation of concerns.
Granted, the mess that [U]EFI is, it might still be the better option. But the old BIOS is only "good" because of the crazy (sunk and continuing) cost to effectively implement "good new bios" within the operating systems.
BIOSes have been executing mostly in "unreal"/flat-real mode since at least the 486 days, and I recall one of the later ones switching into that mode only a dozen instructions after FFFF:FFF0.
EFI is ridiculous complexity, more than that of early OSs, mostly just to do things which the OS would again do when it boots up.
I have found the [U]EFI mess to be really unbearable. It is too hard to debug. I mean, they learned nothing from the workstation or minicomputer era wrt. boot diagnostics.
The device I allude to in my other comment here is a Cherry Trail device. I did query the supplier as to why the EFI was not 64-bit and was told essentially that "The 2 GB version of the device comes with 32-bit UEFI because it doesn't support 64-bit OS". Another variant of the device with more RAM does come with a 64-bit UEFI, apparently.
I can _kind of_ see the logic -- when you have only 2 GB of RAM, you aren't really going to want to put a 64-bit OS on it.
Part of the issue there as well is, as I understand it, UEFI can only load EFI applications (of which the bootloader is) of the same bitness as the UEFI implementation -- 64-bit UEFI can _only_ load 64-bit bootloaders.
I think the fact that it will run mainline amd64 Linux [0] and is dirt cheap will make people overlook that.
Benchmarks are imperfect, but it seems to be in the same ballpark as the Raspberry Pi 4 [1] - slightly worse in single core, slightly better in multicore. So performance wise it's competitive with competing ARM boards (you get what you pay for) but the software experience should be great in comparison with most boards, even in comparison to the RPi 4.
[2]: Sidenote that the benchmark is skewed because of the AES benchmark. The Raspberry Pi 4 like the Atom has AES hardware acceleration when run in 64 bit mode, but this benchmark is run on 32-bit ARM. This is likely because the official RPi 4 distribution (Raspbian) is also still 32 bit. Software support affects benchmarks too.
RPi4's specific weak spot is heat production. It'll probably severely throttle during the benchmark if that $1 heat sink is missing. So I wonder what's the case in this benchmark? Did the test system have a heatsink or not? Low multicore results suggest not.
Another issue that can skew benchmarks is library optimization situation. On x86, most things are SSE/AVX optimized, but on ARM side NEON optimizations can be slow implementations or even completely missing.
AArch64 ISA has changes that eliminate some false dependency chains (more general purpose registers and NEON register layout changes). This blocks out-of-order engine from making optimal use of CPU resources. When you hit this issue, 64-bit ARM code can run quite a bit faster.
Raspberry Pi's weak spot has always been rather slow memory bandwidth. RPi4 improves this (DDR4 instead of DDR2), but it's still the weakest spot. Just 32-bits wide bus to SDRAM.
I mean yeah, you can split a lot of hairs there. But even so, even if you assume the RPi 4 can be optimized to be 20% faster than the Atom across the board, it's still the same ballpark. In that ballpark mainstream amd64 support is a big advantage.
People buying these computers aren't looking for performance. They're focused on cost. There are lots of reasons why you might not need something fast.
Cost plus availability. That is why a small percentage of RPis are now being used in industrial control applications where you still need the board available in 10+ years.
My client recently ordered the remaining stock from a large supplier (several hundred) as the recent design change of the RPi4 unfortunately gets too hot and will require an enclosure/pcb redesign
While this is a Atom x5-Z8300, I run a similar board (Atom x5-Z8350) and since it supports hardware encoding of H.264 video, it's a dream as a super-cheap home media server.
A 5700HQ is perfectly fine. That's a 14nm non-Atom part. Compared to a bleeding edge 9980HK, each core is only 25% slower. And you don't need more than four cores here.
More relevantly, a 5700HQ is five to six times as fast as this Atom.
Oh, sure. My point's just that a 3-4 year old design isn't a big deal, and if you're concerned about performance it's absolutely not the age to worry about.
A little tidbit, Intel still manages to sell 5(!) generations old CPUs in China, and those are not old stock.
The industry been screaming murder for the last year because Intel stopped selling low and mid-tier chips as such in China aside from "new old stock"
The new 10nm Atom line refresh has been delayed 4 times already, and will very likely be delayed for the 5th time.
AMD however does not seem too much interested in China's domestic industry at all. AMD's China reseller is a company in a tiny dusty office in Shanghai.
AMD was very interested in selling in to China. They did a deal with the Chinese government that was a little too friendly, and the US government effectively shut the operation down by listing the joint-venture as an export regulated entity.
There were times during the netbook boom when ARM notebooks were a thing. And they kept being a thing for at least next 5 years, but they saw near no exposure in the West, mostly going to places like South Asia and Africa
Seen many OpenWRT installs running upon Intel Cherry Trail, not this particular board (yet), but certainly one of the more easier chipsets to get working over some random ARM SOC for sure.
Intel Edison was an interesting product at the time -- but they cancelled it before much community could develop around it. I wish Intel could "stay the course" a little more.
Edison was pretty annoying to work with in my experience.
To use the Edison CPU (without their Arduino-like breakout board) on your own hardware you needed a fine-pitch connector that was more or less impossible to solder in a typical home workshop. The Yocto Linux was annoying from a tinker's perspective because it was focused around building static firmware images and not like Raspberry Pi where you ssh in and apt-get away.
This all didn't make much sense for a product marketed to makers/hobbyists. More or less the only benefit you got from Edison was being x86. You could compile a static binary on your laptop, scp it over and it would just work without messing with cross-compilation etc. But that really wasn't worth all the other annoyances IMHO.
More or less the only benefit you got from Edison was being x86.
...and Intel missed the point that x86 without the rest of the PC isn't that great. I suspect if the Edison was actually PC-compatible (to the point of e.g. being able to boot DOS and older Windows and run their applications) it would've had far more popularity (retro-gaming, etc.) than yet-another-maker-toy.
But then it'd need to bring in a DOS compatible RTC, a CGA/MDA/EGA/VGA output, audio out (PC speaker or Sound Blaster?), joystick port, serial port (or PS/2 emulation from the USB bus). Should the SD card pretend to be an IDE hard disk?
It just needs to have the base AT system board components at their usual places (which can easily be integrated into a SoC[1]) and a useful bus for expansion like PCI(e) or even (E)ISA. Video, audio, and other peripherals can be external.
The Edison module connector could've easily housed a PCI or
ISA (which slow, but more "maker friendly" because the speeds are low enough that standard TTL ICs can be used) bus, but all they put on it was USB and GPIO.
I get that; it's cheap and low power, two things I like (and can also get from arm devices.) But what's the appeal in x86 without expansion ports? It seems to me I can run whatever software I have on either, so the differentiating factor should be hardware support, but without a PCI slot I don't really get it.
Having an intel GPU is nice enough I guess. I might get one just for that.
For example, I use my Intel-based SBC as headless server. The only thing I need is two SATA ports available (which the SBC I own has), and the condition that's it's a small and cheap machine.
For a use case like mine, it's perfect. I don't need to think about using a certain distribution and ultimately depending on a producer. I used to have ARM boards, so I know :-)
It's important not to underestimate the dependency on the distributions. Intel x86 last virtually forever¹, ARM boards have a very short life². It's fine to use ARM if somebody wants a mid-term throwaway toy, but if one plans to have a stable [server] machine, it's a problem³.
¹=in the sense - as much as realistically possible
²=in comparison; the ARM boards tend to get discontinued quicker.
³=finally, consider that not every ARM board is [as supported as] an RPi.
"in comparison; the ARM boards tend to get discontinued quicker"
This is true though I believe it's mainly due to them being newer developments in a field (mass produced embedded boards) where everyone and their cat makes something new every month. It's a moving target that will never settle (luckily) but given enough time it will slow its pace to sustainable levels both for manufacturers and users/developers. Give it some time, the kid is young.
As an example, I'm still waiting for a cheap enough board around which I would build what I consider a vital brick in every home network: something with enough SATA ports to make a RAID enabled server, then would cut costs in all other corners. Say 4 to 5 SATA ports, no video, no audio, no WiFi, no multiple NICs (I'd use a separate board for firewalling), no more than a serial port for monitoring and few GPIOs for blinking some leds or drive fans, monitor UPSs etc. It would be the best possible platform to make cheap non trivial file servers.
My current configuration is 2+2 disks arranged as RAID1 (I don't trust anything else) kept in sleep mode when not in use for more than 2 hours plus a fifth disk used very often as temporary storage before things are being stored on the RAID. I use a cheap Atom Mini ITX board I purchased used on ebay plus a rack enclosure that weighs like a ton. Nas4Free is the OS, which is perfect for the task although RAM usage with XFS reaches the maximum available on that board (4GB), but for home use it's still ok. It works perfectly, but I would happily swap it for a lighter ARM system in a smaller box. Unfortunately it looks like there's no solution to be used to build a similar file server, except costly boards with a lot other peripherhals or much faster CPUs I wouldn't have any use for. So why nobody makes a board like that? I would guess they analyzed the market and concluded there'not enough demand.
A board like that would mean an excellent home/SOHO file server at a third of the price, but apparently the small number of people who build their own file server doesn't justify any risks in that field.
x86 ISA means you don't have to rely on community support. It really needs 8gb of onboard memory though, sbc+memory upgrade+sd card+power supply = more expensive than a dual cpu server from 9 years ago
And portable , but if it doesn't have enough resources to face the web securely, what is the point. Running your operating system from SD is just terrible, even USB is more reliable. x86 means getting a bluetooth keyboard to work doesn't involve a long walkthrough that doesn't always work.
It depends if one talks about Atoms in general or specific models.
The Celeron J4105 (which powers the ODROID H2), is technically an Atom, and it's massively faster than an RPi 4 (2-5x), but I don't know about the Z8300.
Based on Passmark (which is an arbitrary choice), Rock Pi X and RPi 4 may have comparable performance; if that was established, and I wanted a cheap SBC, I'd definitely go with the former.
Correction: as pointed out, the J4105 does not belong to the Atom, but the Celeron family (although the architecture, Goldmont Plus, may be used in the future for Atom), so the comparison is not correct.
Been keeping my eye out for something like this. I have wanted to build a cheap bare metal k8s cluster for my homelab. While ARM is nice, most containers are targeted at x86.
The ODROID H2 is finally available (it hasn't been available for a long time, due to Intel not producing enough chips (or not selling them to ODROID and others, not sure)), and you can consider it a high-end SBC or a low-end NUC.
The price for board+4GB RAM is roughly 150$ vs 80$ for the RPi 4¹.
It's the lowest priced x86 system available², and the performance is significantly superior to ARM boards (in the range 2-4x of RPi 4).
¹=very rough prices; it's hard find the lowest prices, and it's not clear if it makes sense to do so
²=please no comparisons with discontinued machines (there's always somebody popping up with such comparisons...)
Was aiming to get the system together for $500 or less, including power supplies for a five node system. So SBC/NUC systems above $100 made it less compelling. Obviously performance isn't the consideration here, but number of physical nodes.
Rebuilt - sure, most of the time. But unless you want to spend lots of time rebuilding containers, you may want Intel instead. If you have a "real" machine with ARM available you can build larger software quickly, but if you don't, building something on rpi can take tens of minutes easily.
I don't know why this has taken so long...
About 5 years ago, I was involved in a project where we purchased Intel based tablets based off a standard reference design in bulk for about $80 a piece - that included battery, cameras, screen, casing and more.
The cost of the board only was about ~$30 or so.
I really wondered why no one was selling these to compete against the Pi in the heyday.
The only problem we had and why we didn't sell to makers was because we didn't control the design and we had enormous technical problems with EFI/Bios 64 bit booting only and a headache like crazy trying to reinstall Linux which just randomly broke all the time.
Truth be told, I wish I pushed through with it.
Why not just use a 32bit EFI bootloader like grub? I did that with some Baytrail device some time ago and it worked without a hitch (there were other problems though). If i remember correctly you can also boot a 64bit kernel from there if that is what matters to you...
I can't remember the technical details and haven't touched this in years - but, it just wasn't this simple.
It was something about the handover process from EFI to bootloader and it was something really awkward...
We got it working, but, any update seemed to wipe it unless you were careful and it just wasn't "production" grade.
Dealing with EFI issues like this right now! It's made worse because we run Windows 10 IoT Enterprise on the devices and much of the work I did on our 64-bit OS image is mostly invalidated because our next tablet has the exact same processor but only 32-bit EFI.... Oh man, it can really screw with your logistics when you rely on consumer tablets. There's one reason to pay a premium for 'industrial' devices.
I will say this additionally though - the messaging around the Intel Atom line, IMHO has been absolutely terrible. If only our software could run on ARM. I was convinced at one stage they were discontinuing the whole thing and then suddenly they didn't? I don't even know anymore. They have a roadmap so I guess that's something.
TL;DR: Think very carefully before basing a product on consumer-grade hardware, especially with consumer-grade tablets. To the parent commenter, you're probably lucky you DIDN'T push through it :)
What is it about your software that it can't run on ARM?
It's a .NET application that still potentially relies on some third-party x86 binary drivers/components that are only on Windows. Ideally in the future the whole codebase could be ported over to .NET Core, with the remaining native components being stripped out (we've somewhat worked towards this).
Really though, it's that we don't have the resources to dedicate to any porting or compatibility effort (I've toyed with the idea of QEMU on ARM) to do it, so unfortunately it's one of those things that gets very slowly pieced together in the background here and there. Too big a project to convince the higher-ups that it's worth the tradeoff of prioritizing it over new features and new customers.
Intel was selling the Edison [1] until 2017. I still have one. It had WiFi and Bluetooth on board, which was nice at the time.
[1] https://en.wikipedia.org/wiki/Intel_Edison
I still use and maintain about ~60 Intel edisons. Such a great little device. Onboard storage, 5ghz Wifi, and super low power useage. My only gripe was the yocto linux distro they used was a bit janky.
I was really disappointed when they discontinued the project. I guess Intel wanted to invest more in the Movidius ai compute stick, since that is where most of the Edison team was moved to.
Before that, there was the Quark X series. I still have a Galileo board running Debian.
We had similar ideas, but the bootloaders were always problematic. These Atom chips are still probably limited to 32bit boot loaders.
IIRC this was a major problem with the Bay Trail generation (32 bit EFI, 64 bit CPU). These are Cherry Trail generation chips (one generation newer) which did get 64 bit EFIs. That's not to say this board has a 64 bit EFI, but the vendor could avoid problems if they're smart.
I have 4 different BayTrails (manufacturers/etc) running in my apartment. There is zero issue with them in Linux but they have a funky requirement:
- they must be booted into legacy i.e. on EFI mode. EFI mode boot does not work reliably.
- the boot disk must have MBR and not GPT disk label.
I'm not surprised, EFI is a mess in general. Good old BIOS has worked for 30+ years, and is simple enough that it's not hard to get right (yet there are/were some that still did...) --- load the first sector of the boot device at 7C00 and jump to it.
And then spend then next 400,000,000 cycles progressively switching from 40 year old 8086 real mode to the present, reading some newer firmware configuration tables from that same BIOS (which are often buggy), compensating for those bugs, etc.
That's still less than a quarter of a second, granted. But the complexity goes to the OS instead of a reasonable separation of concerns.
Granted, the mess that [U]EFI is, it might still be the better option. But the old BIOS is only "good" because of the crazy (sunk and continuing) cost to effectively implement "good new bios" within the operating systems.
BIOSes have been executing mostly in "unreal"/flat-real mode since at least the 486 days, and I recall one of the later ones switching into that mode only a dozen instructions after FFFF:FFF0.
EFI is ridiculous complexity, more than that of early OSs, mostly just to do things which the OS would again do when it boots up.
I have found the [U]EFI mess to be really unbearable. It is too hard to debug. I mean, they learned nothing from the workstation or minicomputer era wrt. boot diagnostics.
> That's still less than a quarter of a second, granted. But the complexity goes to the OS instead of a reasonable separation of concerns.
So? The OS already does it.
The device I allude to in my other comment here is a Cherry Trail device. I did query the supplier as to why the EFI was not 64-bit and was told essentially that "The 2 GB version of the device comes with 32-bit UEFI because it doesn't support 64-bit OS". Another variant of the device with more RAM does come with a 64-bit UEFI, apparently.
I can _kind of_ see the logic -- when you have only 2 GB of RAM, you aren't really going to want to put a 64-bit OS on it.
Part of the issue there as well is, as I understand it, UEFI can only load EFI applications (of which the bootloader is) of the same bitness as the UEFI implementation -- 64-bit UEFI can _only_ load 64-bit bootloaders.
This is discussed in the comment section. It shouldn't be a problem any longer. Tom Cubie is from Radxa
The processor in these board is about to celebrate its 4th anniversary, and its performance wasn't world-beating at the time of its release.
https://ark.intel.com/content/www/us/en/ark/products/93361/i...
I think the fact that it will run mainline amd64 Linux [0] and is dirt cheap will make people overlook that.
Benchmarks are imperfect, but it seems to be in the same ballpark as the Raspberry Pi 4 [1] - slightly worse in single core, slightly better in multicore. So performance wise it's competitive with competing ARM boards (you get what you pay for) but the software experience should be great in comparison with most boards, even in comparison to the RPi 4.
[0]: And Windows. And FreeBSD. Perhaps even OpenBSD http://openbsd-archive.7691.n7.nabble.com/Fwd-Intel-Compute-... .
[1]: https://browser.geekbench.com/v4/cpu/compare/13701853?baseli...
[2]: Sidenote that the benchmark is skewed because of the AES benchmark. The Raspberry Pi 4 like the Atom has AES hardware acceleration when run in 64 bit mode, but this benchmark is run on 32-bit ARM. This is likely because the official RPi 4 distribution (Raspbian) is also still 32 bit. Software support affects benchmarks too.
RPi4's specific weak spot is heat production. It'll probably severely throttle during the benchmark if that $1 heat sink is missing. So I wonder what's the case in this benchmark? Did the test system have a heatsink or not? Low multicore results suggest not.
Another issue that can skew benchmarks is library optimization situation. On x86, most things are SSE/AVX optimized, but on ARM side NEON optimizations can be slow implementations or even completely missing.
AArch64 ISA has changes that eliminate some false dependency chains (more general purpose registers and NEON register layout changes). This blocks out-of-order engine from making optimal use of CPU resources. When you hit this issue, 64-bit ARM code can run quite a bit faster.
Raspberry Pi's weak spot has always been rather slow memory bandwidth. RPi4 improves this (DDR4 instead of DDR2), but it's still the weakest spot. Just 32-bits wide bus to SDRAM.
I mean yeah, you can split a lot of hairs there. But even so, even if you assume the RPi 4 can be optimized to be 20% faster than the Atom across the board, it's still the same ballpark. In that ballpark mainstream amd64 support is a big advantage.
NEON optimizations can have pretty large effect (up to ~4x), just like SSE. The benchmarks with the largest differences are suspect, especially SGEMM.
Also don't underestimate how much RPi4 throttles under multicore load. Even the cheapest $1 heatsink will make a big difference.
In general I agree, though. It'll still be in the same ballpark.
Well at least it is shipping with 64bit UEFI.
Lots of these cheap Intel chips like Z3740 found in many Wintel tablets only shipped with 32bit UEFI making them un-usable on FreeBSD.
Why is 32bit UEFI unusable on FreeBSD?
People buying these computers aren't looking for performance. They're focused on cost. There are lots of reasons why you might not need something fast.
I'd even add that being slow and constrained is a feature in multiple uses.
A lab desktop cluster doesn't need to be fast, but needs to replicate the environment you want to play with.
Cost plus availability. That is why a small percentage of RPis are now being used in industrial control applications where you still need the board available in 10+ years.
My client recently ordered the remaining stock from a large supplier (several hundred) as the recent design change of the RPi4 unfortunately gets too hot and will require an enclosure/pcb redesign
The BCM2835 was already a few years old when the Raspberry Pi first came out, and it's still part of the Pi Zero.
While this is a Atom x5-Z8300, I run a similar board (Atom x5-Z8350) and since it supports hardware encoding of H.264 video, it's a dream as a super-cheap home media server.
If performance is a concern, you probably don’t want to buy a $39 SBC. It doesn’t need the latest and greatest to be useful.
How is the performance compared to the ARM processors in similar boards (RPI et al.) ?
This is the important question. How well does it compare to the ARM based alternatives?
What about new notebooks on 5700? Yes, 5700 is still sold new to Chinese resellers
A 5700HQ is perfectly fine. That's a 14nm non-Atom part. Compared to a bleeding edge 9980HK, each core is only 25% slower. And you don't need more than four cores here.
More relevantly, a 5700HQ is five to six times as fast as this Atom.
People aren't exactly buying these boards (and boards like it, such as the Raspberry Pi) to fold proteins or something.
Oh, sure. My point's just that a 3-4 year old design isn't a big deal, and if you're concerned about performance it's absolutely not the age to worry about.
You'd want to do that on a GPU anyway.
A little tidbit, Intel still manages to sell 5(!) generations old CPUs in China, and those are not old stock.
The industry been screaming murder for the last year because Intel stopped selling low and mid-tier chips as such in China aside from "new old stock"
The new 10nm Atom line refresh has been delayed 4 times already, and will very likely be delayed for the 5th time.
AMD however does not seem too much interested in China's domestic industry at all. AMD's China reseller is a company in a tiny dusty office in Shanghai.
Why is AMD not interested in selling chips in China? Seems crazy to ignore that market unless the price for access is too high.
AMD was very interested in selling in to China. They did a deal with the Chinese government that was a little too friendly, and the US government effectively shut the operation down by listing the joint-venture as an export regulated entity.
https://www.tomshardware.com/news/amd-joint-venture-partner-...
Ah yes a technology transfer joint venture
Do you know how well the Dhyana or Zhaoxin processors are doing?
Nobody saw them under the sun, maybe aside from people signing up the research grants
Sounds like a good opportunity for a local startup to take some market share.
There were times during the netbook boom when ARM notebooks were a thing. And they kept being a thing for at least next 5 years, but they saw near no exposure in the West, mostly going to places like South Asia and Africa
I guess those machines ran Linux then? Since IIRC Windows XP/7 didn’t run on ARM.
Rockchip and Allwinner seem to be doing well
I wonder if these boards could be used for a DIY 802.11s mesh implementation? Maybe the hobby alternative to an eero/Google/plume/amplify setup...
https://openwrt.org/docs/guide-user/network/wifi/mesh/80211s would be viable.
This might just be more dependent on the chipset these boards are coming with, but I'm admittedly just guessing.
Seen many OpenWRT installs running upon Intel Cherry Trail, not this particular board (yet), but certainly one of the more easier chipsets to get working over some random ARM SOC for sure.
Intel Edison was an interesting product at the time -- but they cancelled it before much community could develop around it. I wish Intel could "stay the course" a little more.
Edison was pretty annoying to work with in my experience.
To use the Edison CPU (without their Arduino-like breakout board) on your own hardware you needed a fine-pitch connector that was more or less impossible to solder in a typical home workshop. The Yocto Linux was annoying from a tinker's perspective because it was focused around building static firmware images and not like Raspberry Pi where you ssh in and apt-get away.
This all didn't make much sense for a product marketed to makers/hobbyists. More or less the only benefit you got from Edison was being x86. You could compile a static binary on your laptop, scp it over and it would just work without messing with cross-compilation etc. But that really wasn't worth all the other annoyances IMHO.
More or less the only benefit you got from Edison was being x86.
...and Intel missed the point that x86 without the rest of the PC isn't that great. I suspect if the Edison was actually PC-compatible (to the point of e.g. being able to boot DOS and older Windows and run their applications) it would've had far more popularity (retro-gaming, etc.) than yet-another-maker-toy.
But then it'd need to bring in a DOS compatible RTC, a CGA/MDA/EGA/VGA output, audio out (PC speaker or Sound Blaster?), joystick port, serial port (or PS/2 emulation from the USB bus). Should the SD card pretend to be an IDE hard disk?
It just needs to have the base AT system board components at their usual places (which can easily be integrated into a SoC[1]) and a useful bus for expansion like PCI(e) or even (E)ISA. Video, audio, and other peripherals can be external.
The Edison module connector could've easily housed a PCI or ISA (which slow, but more "maker friendly" because the speeds are low enough that standard TTL ICs can be used) bus, but all they put on it was USB and GPIO.
[1] https://en.wikipedia.org/wiki/Vortex86
All great points, but I really wish they just listened to their users instead of shelving hobbyist embedded for a few years.
And it came with WiFi and Bluetooth LE on board! I got one from google to play with Physical Web.
Without PCIe it's not clear to me what advantages x86 offers in this form factor. I guess an Intel GPU is a plus.
It’s cheap and it’s x86.
I get that; it's cheap and low power, two things I like (and can also get from arm devices.) But what's the appeal in x86 without expansion ports? It seems to me I can run whatever software I have on either, so the differentiating factor should be hardware support, but without a PCI slot I don't really get it.
Having an intel GPU is nice enough I guess. I might get one just for that.
Everybody has different use cases.
For example, I use my Intel-based SBC as headless server. The only thing I need is two SATA ports available (which the SBC I own has), and the condition that's it's a small and cheap machine.
For a use case like mine, it's perfect. I don't need to think about using a certain distribution and ultimately depending on a producer. I used to have ARM boards, so I know :-)
It's important not to underestimate the dependency on the distributions. Intel x86 last virtually forever¹, ARM boards have a very short life². It's fine to use ARM if somebody wants a mid-term throwaway toy, but if one plans to have a stable [server] machine, it's a problem³.
¹=in the sense - as much as realistically possible
²=in comparison; the ARM boards tend to get discontinued quicker.
³=finally, consider that not every ARM board is [as supported as] an RPi.
"in comparison; the ARM boards tend to get discontinued quicker"
This is true though I believe it's mainly due to them being newer developments in a field (mass produced embedded boards) where everyone and their cat makes something new every month. It's a moving target that will never settle (luckily) but given enough time it will slow its pace to sustainable levels both for manufacturers and users/developers. Give it some time, the kid is young.
As an example, I'm still waiting for a cheap enough board around which I would build what I consider a vital brick in every home network: something with enough SATA ports to make a RAID enabled server, then would cut costs in all other corners. Say 4 to 5 SATA ports, no video, no audio, no WiFi, no multiple NICs (I'd use a separate board for firewalling), no more than a serial port for monitoring and few GPIOs for blinking some leds or drive fans, monitor UPSs etc. It would be the best possible platform to make cheap non trivial file servers.
My current configuration is 2+2 disks arranged as RAID1 (I don't trust anything else) kept in sleep mode when not in use for more than 2 hours plus a fifth disk used very often as temporary storage before things are being stored on the RAID. I use a cheap Atom Mini ITX board I purchased used on ebay plus a rack enclosure that weighs like a ton. Nas4Free is the OS, which is perfect for the task although RAM usage with XFS reaches the maximum available on that board (4GB), but for home use it's still ok. It works perfectly, but I would happily swap it for a lighter ARM system in a smaller box. Unfortunately it looks like there's no solution to be used to build a similar file server, except costly boards with a lot other peripherhals or much faster CPUs I wouldn't have any use for. So why nobody makes a board like that? I would guess they analyzed the market and concluded there'not enough demand. A board like that would mean an excellent home/SOHO file server at a third of the price, but apparently the small number of people who build their own file server doesn't justify any risks in that field.
> But what's the appeal in x86 without expansion ports?
You may have easier time trying to run some alternative OS such as one of the BSDs, Haiku, ReactOS, or even Windows.
I’m specifically looking for something that can run Windows x86 programs.
The GPU is a big deal provided it comes with QuickSync hardware accelerated video encoding. Very useful for DVR-like stuff.
x86 ISA means you don't have to rely on community support. It really needs 8gb of onboard memory though, sbc+memory upgrade+sd card+power supply = more expensive than a dual cpu server from 9 years ago
This would be more power efficient though.
And portable , but if it doesn't have enough resources to face the web securely, what is the point. Running your operating system from SD is just terrible, even USB is more reliable. x86 means getting a bluetooth keyboard to work doesn't involve a long walkthrough that doesn't always work.
The Atom CPU should be faster than an Arm.
Raspberry pi 4 should be as fast as Atom x5-Z8300
Yeah but using an Intel Compute stick with the Atom and a Pi 4 both with Ubuntu the Atom is definitely faster in my experience.
Real-world comparison here:
https://openbenchmarking.org/result/1907128-HV-1907127HV99
it's hard to make an absolute conclusion; it seems that the Pi 4 is faster than the Z8300 in more cases, but not all.
I wouldn't categorize these results as "definitely faster" though.
I think disk IO makes a lot of difference and I guess (didn't look it up) the Atom might get better IO results out of the eMMC SSD than the Pi4 does.
We sure about that? If we take a common use-case, emulators are very well optimized on ARM these days (more so than PC in some situations).
It depends if one talks about Atoms in general or specific models.
The Celeron J4105 (which powers the ODROID H2), is technically an Atom, and it's massively faster than an RPi 4 (2-5x), but I don't know about the Z8300.
Based on Passmark (which is an arbitrary choice), Rock Pi X and RPi 4 may have comparable performance; if that was established, and I wanted a cheap SBC, I'd definitely go with the former.
Correction: as pointed out, the J4105 does not belong to the Atom, but the Celeron family (although the architecture, Goldmont Plus, may be used in the future for Atom), so the comparison is not correct.
What I would like to know is how the GPU compares to a n RPi4 or the latest RPi3. I wish there was a comparison of that.
Regardless, I will probly still buy one of these Rock Pi's anyways :-)
This trademark is confusing, with Rockchip and Raspberry Pi already involved in the little SoC board space.
Been keeping my eye out for something like this. I have wanted to build a cheap bare metal k8s cluster for my homelab. While ARM is nice, most containers are targeted at x86.
It depends on how much you want to spend.
The ODROID H2 is finally available (it hasn't been available for a long time, due to Intel not producing enough chips (or not selling them to ODROID and others, not sure)), and you can consider it a high-end SBC or a low-end NUC.
The price for board+4GB RAM is roughly 150$ vs 80$ for the RPi 4¹.
It's the lowest priced x86 system available², and the performance is significantly superior to ARM boards (in the range 2-4x of RPi 4).
¹=very rough prices; it's hard find the lowest prices, and it's not clear if it makes sense to do so
²=please no comparisons with discontinued machines (there's always somebody popping up with such comparisons...)
Was aiming to get the system together for $500 or less, including power supplies for a five node system. So SBC/NUC systems above $100 made it less compelling. Obviously performance isn't the consideration here, but number of physical nodes.
The RPi 4 w/ 4gb ram is $55 at my local Microcenter - and an extra $10 for the power supply.
This was my exact thinking. I wanted a pi cluster but didn't want to deal with arm. Exciting...
Just out of curiosity, what kind of issues you have with ARM?
Edit: Do you refer to this? https://blog.cloudkernels.net/posts/rpi4-64bit-virt/
Still at least some DMA issues: https://github.com/raspberrypi/linux/issues
You can also get a bunch of thin clients on eBay and use those. The AMD APU based ones even have GPUs you can play with.
Do you have a model number or something that I can use to search for?
Just saw this yesterday, shame they're sold out but I think this is what they're referencing: https://computers.woot.com/offers/hp-t620-amd-flexible-thin-...
That’s helpful actually. There are plenty on Ebay, which is fine for just playing around with.
Is there ever a time when a container can’t be rebuilt for arm? Seriously asking
Rebuilt - sure, most of the time. But unless you want to spend lots of time rebuilding containers, you may want Intel instead. If you have a "real" machine with ARM available you can build larger software quickly, but if you don't, building something on rpi can take tens of minutes easily.
You can crosscompile images for ARM on x86 using qemu, even docker hub inofficially supports it.
I think it should take a nvme card (because of its small size) for storage.
Every time I press "More Options" for the cookies and choose not to accept it just re-presents the screen...
I tried to dismiss the cookie wall and that completely breaks the page as well. I can't scroll down.