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