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