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: https://github.com/htot/meta-intel-edison/tree/morty 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 https://github.com/htot/meta-intel-edison/wiki 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:
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
Thank you for this effort, this is really interesting for me. I am adding Octoprint support to my 3D printer (Printrbot Play) by means of the Edison. Knowing there is a more recent version available is really nice! I will let you know once I move forward to use your repo.
Btw, the links on the github page (https://github.com/htot/meta-intel-edison/tree/morty GitHub - htot/meta-intel-edison at morty ) pointing to meta-intel-edison and meta-intel-iot-middleware end up in 404s.
I think you mean the links ending on .git? Those are url's of branches that you can clone, but I see how that can be confusing. I'll change that when I find time, thanks.
Yes, these are indeed the .git URLs but also the normal ones under the 'What is here' section, like https://github.com/htot/meta-intel-edison/blob/morty/URL http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-edison/
Ah I see. Yes, that is annoying. Will fix, thanks for the pointer.
But not today, going on a holiday tomorrow.
Thanks, you are right, this is an annoying bug, and probably the links are broken in the branches too. I'll fix that.
In the meanwhile a short update:
Next steps: get u-boot images to be built from within yocto, build acpi versions of u-boot and kernel, integrate with meta-acpi. In the meanwhile track new kernels and move from pyro to rocko.
I invite everybody to try out these images and provide feedback or PR's. All you need to do is upgrade u-boot, this will not break the image already present in Edison. My image will be running from an external sd card (but will mount /home inside Edison). All is relatively harmless. In case u-boot does break for whatever reason, I provide binary images to quickly flashall --recover.
Look like this bulletin board is falling apart. This post does not appear on the list after posting?
Which post are you talking about? I can see it as well as your last update...
Hmm. When I look here my post does not show (or yours).
But it does show here: /community/tech/edison/content?filterID=contentstatus%5Bpublished%5D~category%5Bbsp-yocto-linux%5D Intel® Edison
Thanks for putting the github repo together. I confirm I could build the dizzy-latest branch and successfully flash it to both of my Edisons (mini breakout, Arduino breakout board).
And thanks for integrating my pull request as well.
I'm glad to hear it is working for you.
Did you note I am working to update the github wiki on this?
And did you try building the pyro64 branch?
Did you note I am working to update the github wiki on this?
Yes, I have seen some updates on the Twiki (with just the TOC so far when I looked athttps://github.com/htot/meta-intel-edison/wiki it yesterday). That will be very useful. In particular, the steps to use prebuild.sh and then flashall.sh from the correct directories would save people some time (I got them from the README.edison in the Intel Yocto zip drops when I was building from them at the time).
And did you try building the pyro64 branch?
I did not as I am interested in a full system right now (as I said, this is to put Octoprint on the Edison) and I understand the pyro64 branch only builds a minimal system that cannot be flashed using flashall et al (is that right btw?).
I also understood that I would just update U-boot + kernel in this case, w/ userland coming from a normal installation. Now that I have such an install, I will gladly give it a try if that helps you (I have 2 Edisons and I am not concerned about trashing things out or playing w/ recovery).
Ah, no, not exactly.
1) It's a bit more than minimal. There is stuff I removed, but it can't be downloaded, or won't build. There is also stuff I removed from the edison recipies, as it had been moved to standard layers. What is being installed you can find in the image recipe. And of course you can easily add packages you need.
2) I need to fix the postbuild script, then flashall will work. But to be safe, it's best to run it from a sd card to see if there is anything important missing.
3) Pyro64 buiilds a user land (rootfs), kernel and u-boot. You need to update u-boot, or the kernel won't boot. But updating u-boot will not break your current system.
Thanks for those precisions. I have given the pyro64 branch a try (within a Ubuntu Trusty/14.04 Docker image) but mraa fails to build because it cannot find nodejs (see attached logs). Judging from the paths, it is looking for it within the sysroot and not the host so I am not sure where the issue comes from (the recipe dependency should pull it in if it needs to be in the sysroot).
Could you have a look at it? I am also including the cmake logs at the point of failure, let me know if you need more information.
Thanks for trying this. BTW pyro should be able to build on more current versions of Ubuntu, so if you have a host with Ubuntu 17.10 you can avoid using a container.
I had a quick look at you log and saw this:
meta-intel-iot-middleware = "morty-latest:fab967c35e9da426e149c95e4bd5925aa4e9dfcd"
but I created also a pyro branch. So it looks like I forgot to commit the update to setup.sh that checks that out. Sorry for that I will fix that asap. Fixed.
The only new commit in meta-intel-iot-middleware/pyro is
https://github.com/htot/meta-intel-iot-middleware/commit/c7e2547833cffd95785c4e01ba74313adcf56554 mraa: update to 1.7.0 version · htot/meta-intel-iot-middleware@c7e2547 · GitHub
I stole the new mraa recipe from meta-refkit-core. It has since been moved out of refkit-core and now into meta-oe https://github.com/intel/intel-iot-refkit/commit/e9be413031f937ce6c232eaa28df500442989319 intel-iot-refkit: move to use mraa and upm from meta-oe · intel/intel-iot-refkit@e9be413 · GitHub
So we will be able to benefit from that later when moving to rocko.
I did not manage to enable to get the nodejs bindings to build with this yet and they are disabled by default. So if you try to enable that you will find more interesting new errors.
Hi FerryT, I see this project moves on, that's wonderful!
I was looking at it a couple of months ago (found while looking to see if those earlier vanilla kernel enabling projects have yielded anything robust enough for me to bite) and based on Andy's comments in some of his repo's issues, it looked like he's not going to work on this further at all, so I ditched the idea.
But if it's alive, I'd actually like to join. By the way of introduction, though I think we crossed our paths in the past both in this forum and in mraa's repo (which I help to maintain), but just in case, I have quite some experience building images for Edison and I created and maintained (still is, just that it's been much more quiet for a while) the /message/254806# 254806 first inofficial package repository for it. I'd also be interested in helping out with kernel works, here I don't have that much experience, but that's the fun of it.
I'm getting through your repo's issues, wiki and readmes, but in case there's something missing or not updated - is there anything specific you could use help with in the immediate future? I guess pyro64 testing would be one, anything else?
AlexT_Intel Yes it's alive. Pyro64 is working pretty will. Though for mraa I had to disable node bindings, couldn't get the build errors resolved. But I'm not very good with yocto yet, so it might be a small thing. May be you know how to fix that? Or we might just upgrade to Rocko and see if that fixes it.
Actually 0andriy's work on the kernel is progressing in the direction of acpi being implemented. I am looking into a problem with the hsu right now, but after this will continue on building acpi enabled version of u-boot and kernel. And then I guess we can start enabling i2c, spi and other periferals through acpi by creating acpi tables. I don't have the big picture yet, but I am thinking to extend meta-acpi for that.
I have been looking at your work and it has helped me a lot. And we could use a binary repo, that would be nice for those who are afraid to build from scratch, or don't have the disk spacce of patience. But I must say, recent versions of yocto are working pretty good. You probably noticed I used debs, that's just because I know them better than opkg/rpm as I have always used debian and ubuntu.
So yes, please join, the more the merriier
it looked like he's not going to work on this further at all
It's not quite correct. My focus just shifted to ACPI related things. The rest is more or less working out-of-the-box. The Wiki page https://edison.internet-share.com/w/index.php?title=Using_a_vanilla_Linux_kernel_with_Intel_Edison https://edison.internet-share.com/w/index.php?title=Using_a_vanilla_Linux_kernel_with_Intel_Edison is being updated from time to time. But as said, main focus now on https://edison.internet-share.com/wiki/ACPI https://edison.internet-share.com/wiki/ACPI.