[kogepathic]

tl;dr - due to a CPU bug, you can't run normal i686 distributions on the Quark anyway, and support in mainline Linux is still shit 3 years after release.

> Also, I wonder what this means for the Intel Quark SoC (found in Intel Edison and Intel Galileo boards). Does this mean Arch Linux wont be an option for these devices?

I have a device based on the Quark SoC. Support is abysmal for this SoC, especially considering it's been on the market for 3 years (2014). Intel has clearly abandoned this market segment since their repeated headlines of new Quark SoCs has totalled exactly 0 new product launches since 2014.

In mainline Linux I can't use the onboard Ethernet because of some modifications Intel made to the stmmaceth module that weren't pushed upstream. The internet is full of people trying to run newer versions of Linux on their Quark hardware and Intel telling them to use old Yocto Linux BSPs [0] because they can't be bothered to clean up and push their code upstream (or upstream refused to merge it, I don't know and haven't checked).

Also the Quark is affected by the F0 0F bug, so you can't run normal distributions on it because processes will segfault. [1]

> It might solve this issue for Intel Quark, but it would break for any multicore processors. This is not something acceptable.

Honestly I'm not sure why anyone would want to buy a Quark based system. Support is bad, performance is terribad, and power consumption is also terrible (my Quark system idles at 7W, and consumes 2W when in S5 "off" state). You would be very wise to look for an ARM instead of choosing this dumpster fire of a CPU.

[0] https://communities.intel.com/thread/105047

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738575

[akoster]

Thanks for your post (and tl;dr comment too - I need to work on being more concise :-). I own no Quark powered boards but have some friends who do. It's a shame that they fall into the category of boards with poor software support (and even more of a shame since they are based off the Intel architecture). I own a few raspberry pi's and have been extremely pleased that even my rPi model B+ from 2012 still gets support and updates (and hopefully will for a while longer now that the rPi zero exists with similar hardware). Friends would brag about the faster or cheaper O-droid, Pine-64 or Banana-pi, but with dismal software support, I couldn't justify even a descent performance boost. This reminds me of the little I know of the Android ecosystem, where a tablet I bought in 2013 is still stuck on Jelly Bean, while my 2012 iPhone 5 still gets updates. I wish there was some sort of regulatory label put on these devices (or boards) that would clearly state how many years of support they would commit to.

[kogepathic]

> I wish there was some sort of regulatory label put on these devices (or boards) that would clearly state how many years of support they would commit to.

As someone who owns a Raspberry Pi, PandaBoard, BananaPi, Orange Pi, and Intel DK200 I've learned this important life lesson:

Always assume that the most support you'll ever receive for the board is on the day you buy it.

Apart from the Raspberry Pi, no one else gives half a shit to fix bugs or even provide distro updates for their hardware.

Cheap Chinese boards are even worse for this. They'll typically take the SoC kernel (an ancient version several years out of date with the worst patches you've ever seen) and roll some shitty old distro around it (e.g. Ubuntu 14.04, Android 4.4).

A good recommendation for people looking to buy a board is to look at the Armbian [0] or Arch Linux ARM [1] supported hardware (read the notices!!!) and buy that.

[0] http://armbian.com

[1] https://archlinuxarm.org/

[scandox]

Supporting this view. Got given a Quark SoC based box by someone at Intel. Tried to get something going with it, only to realise I had to use WindRiver Linux. Tried to obtain toolchain for building even simple software for it online, couldn't find it. Asked contacts at Intel: radio silence.

[kogepathic]

If it's a DK200, then I've built grub to bypass secure boot.

You can boot other Linuxes on it (e.g. Yocto) but as per my parent comment, not much will work.

I have an SPI image and instructions to flash if you're interested. You'll need an SPI programmer like the ch341a.

I think Intel is violating the GPL by not providing sources, since they include a written offer and GPL requires source availability for 3 years.

I tried to download the WindRiver SDK using the code in the box, and Intel told me the product was no longer receiving support...

[scandox]

Honestly this all occurred over a year ago and I just ditched it

[kogepathic]

Smart choice. Bypassing signature verification in grub was an interesting challenge, but I'll be binning mine soon. Can't be bothered to keep something without mainline support and crap performance.