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.