Before this forum gets locked down, I wanted to let you know that a lot of hard work from some (0andriy in particular, and many many kernel and yocto and other developers) and a little bit from me has lead to a new yocto layer based on Yocto Morty and Linux 4.112. The layers build a complete image for the Edison and a SDK.
You can find it here: GitHub - htot/meta-intel-edison at morty
A lot can be said, about how to build this and what it brings, so I'll like to keep that on the wiki here Home · htot/meta-intel-edison Wiki · GitHub
When this forum gets taken down, we might want to move the discussion to the wiki/issues/pull request pages on github.
But in short:
- A lot of stuff has been removed compared to the Intel Edison 3.5 image. The reason is, the yocto layer is built on the published layer that more or less build the 2.1 image, which builds with Yocto dizzy. As a lot of content was just patching bugs or upgrading recipes to newer versions which was not needed anymore for morty, I just removed these.
- Some stuff just wouldn't easily build, or does not seem to belong into a layer that is intended to be a more or less bare bones linux distribution. So if you really depend on something, please check this manifest in advance https://raw.githubusercontent.com/wiki/htot/meta-intel-edison/edison-image-edison.manifest
- If you are missing something really important, check here OpenEmbedded Layer Index - recipes chances are the recipe is already in the layers but just needs to be enabled here meta-intel-edison/edison-image.bb at morty · htot/meta-intel-edison · GitHub. And otherwise, a new layer is easily added.
- I have switched to using deb's instead of ipk. So when you find you need an additional package, add it to edison-image.bb, bitbake, find the built package under /out/linux64/build/tmp/deploy/deb/, copy to the Edison and dpkg -i package.deb
- The Morty version will build on Ubuntu 17.04 (with a needless warning). Also there is some dependency missing causing `bitbake -k edison-image` to fail the first run. This is harmless (but annoying), just run `bitbake -k edison-image` a second time and it will complete.
- UPDATE: switched to kernel 4.12
- NEW: There is now also a morty-64 branch. This builds a 64 bit kernel + rootfs. I have disabled building U-Boot in this branch as that fails to link with 64 bit tools. I can use help fixing the U-Boot recipe, but for now this is not a problem, you can easily build U-Boot manually. You must update your U-Boot following the instructions on my wiki or from here https://edison.internet-share.com/wiki/U-Boot, otherwise none of -morty or morty-64 will work. Thanks again to 0andriy
root@edison:~# uname -a
Linux edison 4.12.0-edison-standard #2 SMP Mon Jul 17 00:02:17 CEST 2017 x86_64 x86_64 x86_64 GNU/Linux
root@edison:~# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 74
model name : Genuine Intel(R) CPU 4000 @ 500MHz
stepping : 8
microcode : 0x81f
cpu MHz : 500.000
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss
ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology tsc_reliable nonstop_tsc cpuid aperf
mperf nonstop_tsc_s3 tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe po
pcnt tsc_deadline_timer aes rdrand lahf_lm 3dnowprefetch epb tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms dtherm
bogomips : 998.40
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
- mraa has been updated to v1.7.0, upm has been updated v1.3.0
- as pinmuxing on vanilla linux is supposed to be done by devicetree or acpi, I have disabled that in mraa. However, DT and ACPI or not yet available, so for now enabling is done in the platform code in the kernel.
- bluetooth, wifi works, they are using the latest firmware available (from kernel.org and android-x86)
- ethernet cards based on USB work (smsc95xx built-in the kernel, as well as intel)
- hsu high speed uart works, and very well I must say, the results with the non-rt kernel is just as good as with the 3.10.14 kernel with preempt-rt enabled, so below.
- i2c6 bus is not yet enabled, this needs a patch in the kernel. This means that Arduino shields that rely on i2c will not work for now.
- I haven't tested spi, pwm and a/d converters, feel free to test your existing mraa based software and let me know
- If you are afraid to damage your Edison: the only permanent change will be to update u-boot. The new kernel needs to be installed on a free partition (formerly used for OTA) and the rootfs will be on an externel sd card. Instruction are provided how to interrupt the boot process and boot the new image. Your home partition will be used by both original and new image, take care. If you don't interrupt the boot process, your original image will start. If you break u-boot, instructions are available to recover, you might loose data in this case. If that is a problem, backup in advance.
- The kernel is on a separate partition with initramfs built-in allowing to load sd card drivers. With the rootfs on the sd card is much more convenient for development to update the image than flashing the Edison.
I am not really familiar with the development tools that Intel promoted (xdk and what not) that didn't want to run on higher than 14.04 Ubuntu. The support for those in Edison are probable missing now. What I am doing and is pretty straightforward:
- just copy files from your host with scp, or mount the remote machine with sshfs
- build the sdk which allows you to cross compile for the Edison on your host (really, you don't want to build on the Edison) and then copy.
- if you need something that already exists, find the layer on layers.openembedded.org/layerindex/branch/morty/recipes add it, bitbake and copy the deb to the Edison, dpkg -i, and if it works well, add to the image permanently.
Where is this going? Pretty much anywhere we want it to. Let me know. My plan is:
- Follow kernels as released (tomorrow 4.12?)
- PREEMPT_RT kernel
- Switch to 64 bit (done)
- I know 0andriy would like to have ACPI, here help is badly needed to put ACPI support for the Edison into u-boot
This was taken with 4.11 i686 kernel (I hope to be able to provide comparison between 4.12 i686 and x86_64 soon):
The new kernel is really very good and responsive, and doesn't crash as easily as the 3.10.14 kernel. Following statistics (histograms) taken with TX looped back to RX and measuring time to encode a 1024 byte payload (base64 encoded, with crc32, parity odd, total 1388 bytes / 15268 bits, 2Mb/s ) and push to the transmit buffer, then to receive and decode. The y-axis is log, so a normal distribution would shows as a parabola. The blue bars with iperf3 have been taken with iperf3 as artificial load (communicating constantly over ethernet at 95Mb/s) which seems a realistic worst case load for a iot edge device. Transmission takes 7.634ms at this baud rate. As you can see, even under heavy load latency is less than 1.1ms. Compare this to 3.10.14 kernel (up to 60ms latency) and 3.10.14-preempt-rt (1ms).
These graphs have a long history, see Re: PREEMPT RT on Intel Edison and Mid message gap (interchar gap) with 2Mb/s serial communication on the HSU if you interested in serial communication.