Intel stops development and sales of Edison, Galileo and Joule

[Kjelt]

Seems like Intel is stopping with its IoT dev board venture, they stop the development and sales of Edison, Galileo and Joule:

Product Change Notifications:
Galileo: http://qdms.intel.com/dm/i.aspx/F79ED317-6EF3-4293-8752-9C4E7B3C11C5/PCN115581-00.pdf
Joule: http://qdms.intel.com/dm/i.aspx/C3391A8F-693F-418B-B9B5-03A75113F08B/PCN115580-00.pdf
Edison: http://qdms.intel.com/dm/i.aspx/C5E58142-4E04-4CBD-A7A6-BF330573055D/PCN115579-00.pdf

[ataradov]

How unexpected. This is one of the products, that was known to fail from the very start.

[westfw]

Curie and "Arduino 101" still going?

[CopperCone]

what do these people have to do with processors?

LED, Space Probe and Capacitor.. why not call it a aristotle, clark and boyle if your going for random scientists?

they should just make an obama core

[igendel]

How unexpected. This is one of the products, that was known to fail from the very start.

That. The average makers had no idea what to do with these boards (or how), and the advanced developers didn't need them. 

[tszaboo]

...It will probably fail badly on the market they targeting, and even it would be good for something else, that will not matter...

I would never touch Intel ... for embedded system, for any serious business.

OK, Intel, here, I announce, you can officially hire me as a consultant for the embedded division. My rate is 10.000 USD/hour. I could tell you on day 1 that your platform is going to fail. It would have saved you millions, maybe billions.

[nctnico]

It seems Intel isn't even going to do a last production run to fullfill all orders. They just sell what they have and when stock runs out it is bad luck for the customer.

[igendel]

OK, Intel, here, I announce, you can officially hire me as a consultant for the embedded division. My rate is 10.000 USD/hour. I could tell you on day 1 that your platform is going to fail. It would have saved you millions, maybe billions.

But... but... how could you possibly know?! The Galileo had Arduino pin compatibility-- it was even blue, for heaven's sake! How can that fail?   

[technix]

AMD is finally putting pressure on Intel and they are getting workforces concentrated in beating Zen.

[kfnight]

I've got access to like 200 Galileo boards. They are just sitting in a locked closet.

[technix]

I've got access to like 200 Galileo boards. They are just sitting in a locked closet.

I’d like to buy one or two.

[G33KatWork]

The Galileo was awesome to learn about x86-firmware and bootstrapping. The CPU was simple and yet complicated enough to learn a lot. And all components of UEFI are completely open source and you could easily hack on them. Intel even published guides on how to compile all the stuff. That's not existent for any other board. And the CPU supports JTAG with a simple FT2232 adapter and OpenOCD. Try to get JTAG access to any other Intel CPU...

Also it's nice to play around with PCIe. It's small, so you can put it with your FPGA board and take it to a hackerspace, a friend or somewhere else.

These are very niche applications I have to admit, but that's why I bought one. And I hope it doesn't break anytime soon.

[julian1]

I was interested in x86/64 stuff at a hobbiest level because bios standardizes peripheral support, while arm has a lot of fragmentation and it is a lot more difficult to run mainline uboot/kernels. But the pricing was just absurd.

[technix]

The Galileo was awesome to learn about x86-firmware and bootstrapping. The CPU was simple and yet complicated enough to learn a lot. And all components of UEFI are completely open source and you could easily hack on them. Intel even published guides on how to compile all the stuff. That's not existent for any other board. And the CPU supports JTAG with a simple FT2232 adapter and OpenOCD. Try to get JTAG access to any other Intel CPU...

Also it's nice to play around with PCIe. It's small, so you can put it with your FPGA board and take it to a hackerspace, a friend or somewhere else.

These are very niche applications I have to admit, but that's why I bought one. And I hope it doesn't break anytime soon.

Maybe Intel thinks that QEMU + KVM is good enough a development platform for kernel code...?

[Gavin Melville]

Just shows...

Make it hard to use, slow, don't document it, expensive, unstable, non standard....   No doubt Intel is wondering why it failed.

From a discussion on Hackaday, even those who spend millions with Intel couldn't get all the documents.

[technix]

Is Joule the shortest lived Intel product in after Y2K (available from Mouser from late last year, and NRND now)? I feel VERY bad for using Joule on a test gear I'm developing.
And of course, I won't trust Intel Aero or Euclid or any IoT things from Intel anymore.
Ironically I got Joule board right after launching and it will become deprecated before my design goes to test run.

Maybe it is time to migrate off Joule now before it became too late... Raspberry Pi Zero W should be a good approximation feature wise. Or aybe some MT7688 or AR9331 based solutions.

[G33KatWork]

Maybe Intel thinks that QEMU + KVM is good enough a development platform for kernel code...?

For kernel code alone that might even be true, but it just isn't the real thing. Sooner or later with these embedded boards you need an interface to some piece of special hardware. And I don't want to implement that in qemu. Especially when I interface my custom hardware like an FPGA via PCIe. I absolutely need real hardware for that.

The firmware stuff with UEFI and Coreboot is special. At least UEFI can run in qemu, but you are replacing huge chunks with vastly different components. If you are interested in really early boot stuff like the basic chipset or memory controller configuration, you need hardware. Also security related stuff like flash write protection or system Management mode is going to behave differently in software environments than on hardware. Even real chipsets differ a lot there.

I just like to tinker around and try to figure out what makes things tick. The Galileo was perfect for more advanced stuff on a very low level without spending thousands of dollars for "real" reference devboards which you don't even get as a private nerd.

[technix]

Maybe Intel thinks that QEMU + KVM is good enough a development platform for kernel code...?

For kernel code alone that might even be true, but it just isn't the real thing. Sooner or later with these embedded boards you need an interface to some piece of special hardware. And I don't want to implement that in qemu. Especially when I interface my custom hardware like an FPGA via PCIe. I absolutely need real hardware for that.

QEMU + KVM supports PCIe passthrough using Intel VT-d. Even if your own FPGA does not support VT-d directly, adding a VT-d aware PCIe to PCIe bridge chip works around the limitations. Oh VT-d are only available on higher end chips like Core i7/i9 and Xeons.

The firmware stuff with UEFI and Coreboot is special. At least UEFI can run in qemu, but you are replacing huge chunks with vastly different components. If you are interested in really early boot stuff like the basic chipset or memory controller configuration, you need hardware. Also security related stuff like flash write protection or system Management mode is going to behave differently in software environments than on hardware. Even real chipsets differ a lot there.

They don't even bother thinking about true early bootloader or SMM stuff that is highly dependent on (NDA encumbered) datasheets of the chips used.

UEFI application themselves are supposed to be portable, and QEMU + KVM is supposed to provide a compatible solution.

I just like to tinker around and try to figure out what makes things tick. The Galileo was perfect for more advanced stuff on a very low level without spending thousands of dollars for "real" reference devboards which you don't even get as a private nerd.

Well they are reverting their decisions facing the stiff competition from AMD.

[coppice]

I feel VERY bad for using Joule on a test gear I'm developing.

You must have been the only person who didn't see this coming. Its nice to stand out. 

[G33KatWork]

Maybe Intel thinks that QEMU + KVM is good enough a development platform for kernel code...?

For kernel code alone that might even be true, but it just isn't the real thing. Sooner or later with these embedded boards you need an interface to some piece of special hardware. And I don't want to implement that in qemu. Especially when I interface my custom hardware like an FPGA via PCIe. I absolutely need real hardware for that.

QEMU + KVM supports PCIe passthrough using Intel VT-d. Even if your own FPGA does not support VT-d directly, adding a VT-d aware PCIe to PCIe bridge chip works around the limitations. Oh VT-d are only available on higher end chips like Core i7/i9 and Xeons.

Also doesn't work on mobile setups which was my point. My current notebook doesn't have an express card slot or thunderbolt port.

The firmware stuff with UEFI and Coreboot is special. At least UEFI can run in qemu, but you are replacing huge chunks with vastly different components. If you are interested in really early boot stuff like the basic chipset or memory controller configuration, you need hardware. Also security related stuff like flash write protection or system Management mode is going to behave differently in software environments than on hardware. Even real chipsets differ a lot there.

They don't even bother thinking about true early bootloader or SMM stuff that is highly dependent on (NDA encumbered) datasheets of the chips used.

That's what I am trying to say all the time: The Quark X1000 on the Galileo is fully documented. That thing is better documented and more open than a stupid Raspberry Pi! The datasheet has almost 900 pages full of register descriptions.
The Intel FSP which is closed for all other chips is available as source code. The UEFI EDK2 which alao contains all the platform code as well. So you can either build your own UEFI or even cooler: Build your own custom firmware which uses the FSP for platform init just because it's possible. Ffs you can even read the code and configure the memory controller and chipset by yourself and ditch all the Intel code.
The SoC doesn't have an ME or TXE. You control the very first instruction and you have all the code and documentation.
https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/quark-x1000-datasheet.pdf
https://github.com/feizwang/quarkfsp

UEFI application themselves are supposed to be portable, and QEMU + KVM is supposed to provide a compatible solution.

I don't care about applications.

[technix]

Maybe Intel thinks that QEMU + KVM is good enough a development platform for kernel code...?

For kernel code alone that might even be true, but it just isn't the real thing. Sooner or later with these embedded boards you need an interface to some piece of special hardware. And I don't want to implement that in qemu. Especially when I interface my custom hardware like an FPGA via PCIe. I absolutely need real hardware for that.

QEMU + KVM supports PCIe passthrough using Intel VT-d. Even if your own FPGA does not support VT-d directly, adding a VT-d aware PCIe to PCIe bridge chip works around the limitations. Oh VT-d are only available on higher end chips like Core i7/i9 and Xeons.

Also doesn't work on mobile setups which was my point. My current notebook doesn't have an express card slot or thunderbolt port.

If your laptop have an internal M.2 or miniPCIe slot you can build your FPGA board in there, if it can work headless. miniPCIe and M.2 connectors have both PCIe and USB 2.0 pins available, so you can build a FPGA miniPCIe board with the FPGA, the PCIe to PCIe bridge (so your FPGA don't have to support VT-d by itself) and the USB-based programmer all on one module.

The firmware stuff with UEFI and Coreboot is special. At least UEFI can run in qemu, but you are replacing huge chunks with vastly different components. If you are interested in really early boot stuff like the basic chipset or memory controller configuration, you need hardware. Also security related stuff like flash write protection or system Management mode is going to behave differently in software environments than on hardware. Even real chipsets differ a lot there.

They don't even bother thinking about true early bootloader or SMM stuff that is highly dependent on (NDA encumbered) datasheets of the chips used.

That's what I am trying to say all the time: The Quark X1000 on the Galileo is fully documented. That thing is better documented and more open than a stupid Raspberry Pi! The datasheet has almost 900 pages full of register descriptions.
The Intel FSP which is closed for all other chips is available as source code. The UEFI EDK2 which alao contains all the platform code as well. So you can either build your own UEFI or even cooler: Build your own custom firmware which uses the FSP for platform init just because it's possible.
The SoC doesn't have an ME or TXE. You control the very first instruction and you have all the code and documentation.
https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/quark-x1000-datasheet.pdf
https://github.com/feizwang/quarkfsp

Wait the Galileo is discontinued but not the Quark...

UEFI application themselves are supposed to be portable, and QEMU + KVM is supposed to provide a compatible solution.

I don't care about applications.

They don't want you to care about the low level stuff - get the application up and leave all the low level stuff to them and you are supposed to be happy about it.

[abraxa]

AMD is finally putting pressure on Intel and they are getting workforces concentrated in beating Zen.

I doubt it because of https://www.theregister.co.uk/2017/06/09/intel_sends_arm_a_shot_across_bow/ - they're imo scared to lose the x86 platform in the low-cost desktop/notebook segment to ARM, so they may have realized that they don't really have anything to compete. The IoT processors are too slow and don't have the right peripherals, Atom is dead, anything "real" is too expensive in comparison to the Qualcomm snapdragon.

Qualcomm, however, was unfazed by the warning. The chip designer pretty much told Intel to go fsck itself.

That should be a much bigger pain in the neck for Intel than AMD could possibly ever be.

[Jeroen3]

How unexpected. This is one of the products, that was known to fail from the very start.

They are expensive, they are high end, but they were advertised as low end.
You would have needed at least $70 for a proprietary board with a small board-to-board interconnected, compared to, for exmaple, a Particle Photon that is $20 and fits right into your breadboard! Added bonus is that you could take the chip off the Photon and run your own double sided board.

For the application where Intel boards become interesting you'd need a lot of time and skill, you don't advertise there with "arduino compatible".

[CJay]

These were the horrendously expensive 'Arduino killer' boards Intel tried to get into the maker market?

Hardly a surprise they didn't take off, quite ironic really as one of applications they touted was as a controller for a quadcopter, something that could be done and done pretty well with a $10 Arduino clone.

[legacy]

controller for a quadcopter, something that could be done and done pretty well with a $10 Arduino clone.

Arduino itself has always been embarrassing example of shitty marketing, things for people full of ignorance which believe they make their personal RoboGundam in their garage just asking for a few tricks on forums and with a couple of bucks for budget ... but those intel-boards were even worse.

A true epic fail. I am not surprised. It was just a matter of time.

[janoc]

The niche of Intel Joule is the capability of running Windows, and the power of Windows is you can develop on one computer, and run on another one with no libraries or whatsoever installed. Just copy and paste, no apt-get, no ldconfig.

That's actually the problem. A lot of people believed exactly this - and then they discovered that that "full Windows" is in fact Windows 10 IoT Core - which doesn't even have a gui and many standard APIs don't work there because it is a Windows UWP platform, not normal "desktop" Win32. A totally locked down sandbox using its own incompatible set of APIs. Essentially what the Hololens is running. Standard "desktop" Windows doesn't run on it and neither do standard applications (not even .NET stuff unless it is specifically targeting UWP). For all practical needs and purposes it is a completely different OS (think Windows Phone vs. normal Windows).

It is the same idiocy as to what Microsoft did with their Windows RT - there they have also claimed that it "runs Windows" so everyone expected their Windows applications to work on it. Except they didn't - ARM CPUs, totally locked down system.

If you have to deal with UWP and port/write everything from scratch, you can run Linux as well - and then Joule has no advantage over the common ARM boards. You even have to cross-compile, either for ARM or Windows, because apps for UWP need to be built in a special way, you certainly can't just "copy & paste" (first hand experience building apps for Hololens here ...).

This is pretty much a "me too" effort from Microsoft and Intel so that they can claim in their marketing that they are supporting the IoT that nobody has bought into, apart from a few very niche applications.

[Jeroen3]

...

...
Another benefit even for Linux is that those x86 boards can run any distribution designed for computers. I don't have to f* around with yocto or use an ARM distribution. I can use whatever I have, and develop just like for native.

If you run only simple C programs or shell scripts, this may not be so important. But if you run programs depending on platform specific features (poorly implemented byte manipulations, closed source binary blobs, assembly code, etc.), x86 is sometimes the only cheap option.
...

You've described there, a legacy codebase in corporate environment. Again, not where these boards were targeted for.

[CJay]

controller for a quadcopter, something that could be done and done pretty well with a $10 Arduino clone.

Arduino itself has always been embarrassing example of shitty marketing, things for people full of ignorance which believe they make their personal RoboGundam in their garage just asking for a few tricks on forums and with a couple of bucks for budget ... but those intel-boards were even worse.

A true epic fail. I am not surprised. It was just a matter of time.

I'm no Arduino fan but it was intended as a maker platform with minimal coding so I'd not expect much more than that from it or the users, it's a nice gateway introduction I think but as you say, it's not really up to the high end stuff that the Edison etc. is and they require an *awful* lot more knowledge and skill to use effectively.

[bitwelder]

Marketing error. They should have named the board Tesla, not Edison.

[legacy]

Marketing error. They should have named the board Tesla, not Edison.

LOL 

[janoc]

I've never tried to install a full Windows on Joule, but I can install a full desktop Ubuntu, and from previous experience with Intel E3815 board and Intel E645C boards (customized boards for Intel Embedded Design Cup in China, hosted by Intel and Chinese Ministry of Education), I don't think a full Windows installation on Joule is impossible.

Actually on E3815 board from Intel, I was able to run some demanding games like Need for Speed 19 (2012) at lowest settings.

Big difference - Ubuntu is officially supported on that machine by Intel. Windows  (the non-UWP one) is not. So even if you somehow managed to get it work despite the lack of driver support, you would be running a totally unsupported OS with no source code access, so you can't even fix problems yourself. Really great platform to base a product on.

[janoc]

But for one off projects, it's a great way of migrating your desktop program to an embedded platform.

Which part of the "it is a Windows UWP platform" did you not understand?

Unless your desktop program is an UWP application already (which apart from a few "Metro" apps and some games that target also Xbox pretty much none are), you can't migrate it to the Joule. You can't even recompile it, because the APIs are totally different. Even basic stuff like opening and reading a file uses different functions when working in the UWP sandbox, the usual ones will not compile.

So your "migration" becomes a rewrite/port. I fail to see a benefit of doing that vs. doing it to an actually supported ARM platform instead.

Or are you still going about the hypothetical desktop Windows 10 install on it that nobody has managed so far? Not for lack of trying, though:
https://communities.intel.com/thread/113677

If you really want Windows on an SBC, despite the limited RAM and weak CPUs that will make it run like molasses, there is Latte Panda with very similar specs to Joule:
http://makezine.com/2016/08/18/lattepanda-puts-windows-10-on-a-single-board-computer/

And costs $80 ...

[janoc]

I code under Linux. I install exactly the same distribution and version of Ubuntu (no, not snappy core) on both, and code on my desktop, copy the binary to Joule.

That's a pretty limited use case, especially given the price and the hassle with the Joule. Cross-compiling for ARM is not that hard to set up, neither are various virtual machines. E.g. a premade setup for RPi:
https://forum.openframeworks.cc/t/pre-built-environment-for-raspberry-pi-cross-compiling-and-nfs-booting/16206

[janoc]

I know. I work with Yocto too (on iMX6 ULL), let along RPi cross compiling. I'm just lazy, and since it's funding money, not my private money -- the more time I can save, the better I feel, and the better my boss feels. Cost is put aside as the embedded system costs next to nothing in out system.

Fair enough, but that's a very specific situation. I somehow doubt Intel has created the board only for this purpose

[anovickis]

It seems Intel isn't even going to do a last production run to fullfill all orders. They just sell what they have and when stock runs out it is bad luck for the customer.

Likely there were no orders, hence no need for that