Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Honored Contributor II
4 Views

Re: (update) Unofficial new Edison image based on Morty, Linux 4.12, 64bit kernel + image available

That's good It was just some comment in one of the repos, either yours or 01org/edison-linux, devoted to the new kernel discussion, where you made a comment like "alas no more time for this" and I took it as the whole "new kernel for edison" thing, but probably that was just for that issue's matter. Anyway - I'm glad it is as it is and I'm going to participate. Went through the ACPI page, I'll see what I can do to help out after I get the basic build up and running.

FerryT, I'll check the mraa build out right after I have the pyro branch building, which hopefully would be today-tomorrow. Had to update my VM and do some dev system housekeeping before diving in

0 Kudos
Highlighted
Valued Contributor I
4 Views

Re: (update) Unofficial new Edison image based on Morty, Linux 4.12, 64bit kernel + image available

AlexT_Intel That's great! 4 more things I haven't tried or need attention:

  • Building under windows (that would save you working from a virtual machine). Note that building from Ubuntu 17.10 works fine as is.
  • Most people will be expecting to use flashall, but you can't at this point. The postbuild script needs to be updated first (when run now it complains it can't find some files, which actually just have a different name), and the env needs to be updated. At this point I like booting from the sd card too much to fix this. Although booting from (and writing to) usb would probably be a lot faster and shorten the build/debug cycle.
  • It would probably be useful to have a recipe build xfstk so recovery works without hassles when needed (I provide binaries right now).
  • I removed the meta-arduino layer, but some recipies may be essential for certain use cases.
0 Kudos
Highlighted
Honored Contributor II
4 Views

Re: (update) Unofficial new Edison image based on Morty, Linux 4.12, 64bit kernel + image available

So I have both UPM and mraa building with NodeJS bindings, that was a matter of setting a proper NodeJS version for the image - I'll have the PR ready shortly. I've used the occassion and updated recipes using the current meta-oe versions, they look the most sane to me. I've also updated mraa and UPM to the latest releases, mraa specifically got quite a few stability fixes/code cleanups between 1.7.0 and 1.8.0, so that makes sense to me.

Building under windows (that would save you working from a virtual machine). Note that building from Ubuntu 17.10 works fine as is.

TBH I don't think this is possible, not natively at least. While some pieces of the Yocto framework do support running on Windows, unless we talk about Windows 10 and WSL (which is in its infancy and there are reported problems with Yocto anyway), I don't think anyone ever targeted Windows as the Yocto build host. One can generate Windows version of an SDK for a Linux distro produced by Yocto, but that's a different story.

And to be honest (and speaking of myself), VM is not only the way to have Linux on Windows - it allows me to have a clean environment separation, albeit at the cost of a performance hit. I'm using Ubuntu 16.04, by the way - also works fine.

Most people will be expecting to use flashall, but you can't at this point. The postbuild script needs to be updated first (when run now it complains it can't find some files, which actually just have a different name), and the env needs to be updated. At this point I like booting from the sd card too much to fix this. Although booting from (and writing to) usb would probably be a lot faster and shorten the build/debug cycle.

Yeah, I believe it would need to be decided, what's the approach we want to have. I can see where running off of the SD card comes in handy (and we can make postbuild write the SD card instead/in addition to flashing) as it allows people to have the official setup as a fallback. I probably would leave this at SD card for now, until the image is stable enough to offer it as a flashable thing.

I would probably focus first on having u-boot and kernel building as a part of the image, I see right now both require separate actions, which looks a bit unnatural (and running "bitbake edison-image" still gets a non-initramfs version of the kernel built).

It would probably be useful to have a recipe build xfstk so recovery works without hassles when needed (I provide binaries right now).

+1 on that - do you think an "issue" on GH would help track it?

I removed the meta-arduino layer, but some recipies may be essential for certain use cases.

Indeed, though I'd be curious whether anyone from the target audience for our images would be interested in running this. Maybe an issue on GH + a call for upvoting? That would help us gauge the interest [of those who find it, anyway].

0 Kudos
Highlighted
New Contributor I
4 Views

Re: (update) Unofficial new Edison image based on Morty, Linux 4.12, 64bit kernel + image available

Hi,

Watching this thread with a lot of interest, just a note here:

Most people will be expecting to use flashall, but you can't at this point. The postbuild script needs to be updated first (when run now it complains it can't find some files, which actually just have a different name), and the env needs to be updated. At this point I like booting from the sd card too much to fix this. Although booting from (and writing to) usb would probably be a lot faster and shorten the build/debug cycle.

Yeah, I believe it would need to be decided, what's the approach we want to have. I can see where running off of the SD card comes in handy (and we can make postbuild write the SD card instead/in addition to flashing) as it allows people to have the official setup as a fallback. I probably would leave this at SD card for now, until the image is stable enough to offer it as a flashable thing.

In my case, my production Edison is using the mini breakout board so I have no SD at all, only internal flash (I have another one with the Arduino breakout board to test with) so I am interested in having flashall working. I don't know exactly what to change as of now as I don't have enough insight into the build system but with guidance I am willing to do the mods myself if you want.

Thanks again for keeping the Edison SW distro alive!

0 Kudos
Highlighted
Valued Contributor I
4 Views

Re: (update) Unofficial new Edison image based on Morty, Linux 4.12, 64bit kernel + image available

AlexT_Intel Thanks for looking into the MRAA issue, I tried another NodeJS, without any change, and tried finding the exact issue, then decided to leave it for now as I wasn't using node myself. The MRAA in meta-openembedded rocko (here http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-extended/mraa/mraa_git.bb?h=rock... http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-extended/mraa/mraa_git.bb?h=rock...) is at 1.7.0 btw.

I thought the make file supported building under windows and OSX, but we never tried. I did try under win10 WSL, but that doesn't work. Apparently the file system emulation does not support certain things that Yocto needs.

On postbuild/flashall: I think we can have the cake an eat it. Currently we have a manual installation, but it is convenient for development: it leaves a working image on the device, it leaves your home partition intact, it leaves env intact (which then requires a one time modification to boot from sd card). I think this should not change.

But with postbuild we can generate images that will flashall, replacing everything by the new image. And indeed, it better be a stable image then.

On building: You are right, I didn't find a way to get the initramfs built in one step. The kernel is actually builds bitbake edison-image, because it needs the modules that then get copied into the cpio that then is built into the initramsfs kernel. I didn't find another way to do this. Other problems with u-boot, we are building for a 64 bit target, and u-boot is 32/64 bit. Because of some bug afaik in u-boot itself it won't build u-boot, only lib32-u-boot, but only when you have multilib. And when you build edison-image with multilib (larger, longer build time, but more similar to your desktop), the sdk won't build. This needs some work.

xfstk / meta-arduino: issue on gh is fine, I'll mark it as wishlist.

0 Kudos
Highlighted
Valued Contributor I
4 Views

Re: (update) Unofficial new Edison image based on Morty, Linux 4.12, 64bit kernel + image available

VincentR If only for no other reason than to show Intel what a good device this is, and how wrong the decision to EOL it.

After doing all the bitbaking the iamges are in the deploy directory. Postbuild.sh is normally called from the make file, but you can call it manually to. It copies files from /deploy to /toFlash and fails because some file names changed. The env file is here https://github.com/htot/meta-intel-edison/blob/pyro64/meta-intel-edison-bsp/recipes-bsp/u-boot/files... https://github.com/htot/meta-intel-edison/blob/pyro64/meta-intel-edison-bsp/recipes-bsp/u-boot/files.... As you can see it still refers to ttyMFD2. The 4 lines that you need to manually boot the sd card are at the end:

edsboot=setenv bootargs ${bootargs_edsboot}; run load_edsboot; run boot_edsboot

bootargs_edsboot=tty1 console=ttyS2,115200n8 root=/dev/mmcblk1 rootfstype=ext4 systemd.unit=multi-user.target hardware_id=00

load_edsboot=load mmc 0:9 0x100000 bzImage-initramfs

boot_edsboot=zboot 0x100000

We might need to do something to the partition sizes at the top too.

0 Kudos
Highlighted
New Contributor I
4 Views

Re: (update) Unofficial new Edison image based on Morty, Linux 4.12, 64bit kernel + image available

Hi there,

 

I am back working on this but I have issues building the latest pyro64 branch (in an Ubuntu 14.04 Docker container). The 'make setup' step fails :

Your branch is up-to-date with 'origin/1.6.x'.

Applying patch on poky

Setting up yocto configuration file (in build/conf/local.conf)

./meta-intel-edison/setup.sh: line 67: /yocto/out/linux64/build/conf/bblayers.conf: No such file or directory

make: *** [setup] Error 1

It looks like this is because https://github.com/htot/meta-intel-edison/commit/255d35ad3d0d10ee9dc66d5bb35c39a64047e789 https://github.com/htot/meta-intel-edison/commit/255d35ad3d0d10ee9dc66d5bb35c39a64047e789 moved the spot where oe-init-build-env is called in the setup script and it is oe-init-build-env which creates the tree under out/linux64/build/conf. If I do a 'source oe-init-build-env' after the error and retry 'make setup', then it successfully passes.

Now, with that fix done, I still cannot move any further. After 'make setup' has completed and I source oe-init-env and call 'bitbake -k edison-image', it fails because of a lot of RDEPEND issues. Among lots of other related RDEPENDS issue, I have this one, which I think it why the build cannot proceed:

ERROR: Nothing RPROVIDES 'edison-image'

ERROR: No eligible RPROVIDERs exist for 'edison-image'

NOTE: Runtime target 'edison-image' is unbuildable, removing...

Missing or unbuildable dependency chain was: ['edison-image']

Could you shed some light here? That would greatly help me proceed and test what your mentioned in your previous post.

Thanks!

0 Kudos
Highlighted
Valued Contributor I
4 Views

Re: (update) Unofficial new Edison image based on Morty, Linux 4.12, 64bit kernel + image available

I'll have a look tonight. I thought I fixed this. I'll check out new and replay.

0 Kudos
Highlighted
New Contributor I
4 Views

Re: (update) Unofficial new Edison image based on Morty, Linux 4.12, 64bit kernel + image available

Thanks! Also note that I don't have the problem when I updated my existing repo using the new 'make update'.

After the update, I had an issue with ncurses.h not being able to be removed because of a permission issue when the package was to be rebuilt. I had to manually delete it.

Other than that, the updated repo seems to be building fine (the build is stil ongoing but no RDEPEND issues showed up like on the brand new repo)

Edit: confirm that the 'make update' build completed successfully so thie really looks like an issue with the new repos.

0 Kudos
Highlighted
Valued Contributor I
4 Views

Re: (update) Unofficial new Edison image based on Morty, Linux 4.12, 64bit kernel + image available

Thanks for reporting. Sorry, I messed up here. I'm afraid that local.conf got completely messed up after you fixed the first problem (with paths and other stuff from my setup), causing the next.

Please pull my patches (I am assuming you have 'pyro64-acpi' checkout out) and 'make clean'

If you want to build with acpi support add 'acpi' to DISTRO_FEATURES in meta-intel-edison/meta-intel-edison-distro/conf/distro/poky-edison.conf

Then 'make setup'

I haven't done a full build yet (building now, will take 2 1/2 hours), just enough to test the setup script. I think it's good now. Let me know how it goes.

0 Kudos
Highlighted
New Contributor I
4 Views

Re: (update) Unofficial new Edison image based on Morty, Linux 4.12, 64bit kernel + image available

Hi Ferry,

Thanks for your fast answer. I am using the pyro64 branch. Can you backport in there as well? I'll try the patch once it lands in there.

0 Kudos
Highlighted
Valued Contributor I
4 Views

Re: (update) Unofficial new Edison image based on Morty, Linux 4.12, 64bit kernel + image available

I'm afraid that 'make update' could not clean up the mess I made.

But with yesterdays patches it pyro64-acpi builds fine starting clean.

Pyro64-acpi is just a few patches on top of pyro64. It will go into pyro64 soon, but why wait 🙂 Note that acpi is disabled by

default. So you will get by default the same but a newer u-boot and kernel.

0 Kudos
Highlighted
New Contributor I
4 Views

Re: (update) Unofficial new Edison image based on Morty, Linux 4.12, 64bit kernel + image available

Hi there,

Thanks for your continued updates. I was able to successfully build the pyro64-acpi branch, and have successfully flashed u-boot to the version I built. I am busy with trying to install the resultant binaries, preferrably using flashall.sh (it looks like this is possible now, cf https://github.com/htot/meta-intel-edison/issues/6# issuecomment-354181861 Installation from scratch after build / fix postbuild · Issue # 6 · htot/meta-intel-edison · GitHub so I am looking into that.

I have spotted a few things on the Wiki (many thanks for it, this is really useful btw) that would need updates. I was about to ask how to submit fixes but I have used the following thread instead: https://github.com/htot/meta-intel-edison/issues/12 Move wiki to /docs directory · Issue # 12 · htot/meta-intel-edison · GitHub.

Edit: I have hit some roadblocks and put some information in issue # 6 above.

0 Kudos
Highlighted
Novice
4 Views

Re: (update) Unofficial new Edison image based on Morty, Linux 4.12, 64bit kernel + image available

H Ferry,

I wish to use x64 system for .net core application. the branches sumo64-acpi is the only one can be built at moment. However, it missing wifi driver. not sure if you have comment on it? Also, when I try to build pyro64, it show some link issues. not sure if you could fix it?

*********************

ERROR: linux-yocto-4.15.0-r0 do_fetch: Fetcher failure: Unable to find revision 5a8af845894982590bdde0f625547fdcf79dd374 in branch eds-4.15.0-unified even from upstream

ERROR: linux-yocto-4.15.0-r0 do_fetch: Fetcher failure for URL: 'git://github.com/htot/linux.git;protocol=https;branch=eds-4.15.0-unified'. Unable to fetch URL from any source.

ERROR: linux-yocto-4.15.0-r0 do_fetch: Function failed: base_do_fetch

ERROR: Logfile of failure stored in: /home/peter/my_Edison_Workspace/out/linux64/build/tmp/work/edison-poky-linux/linux-yocto/4.15.0-r0/temp/log.do_fetch.18303

ERROR: Task (/home/peter/my_Edison_Workspace/meta-intel-edison/meta-intel-edison-bsp/recipes-kernel/linux/linux-yocto_4.15.0.bb:do_fetch) failed with exit code '1'

***********************

Thank you very much

Peter

0 Kudos