search

edison-fw / meta-intel-edison

Here is the meta-intel-edison that builds, tries to stay up to date. Master is based on Yocto Poky Gatesgarth LTS 5.10.yy vanilla kernels. It builds a 32bit kernel (Gatesgarth branch 64bit) with ACPI enabled and corresponding rootfs. Telegram group: https://t.me/IntelEdison Web-site:
https://edison-fw.github.io/meta-intel-edison/
MIT License
60 stars 37 forks source link

Update meta-mingw patch for SDKTAROPTS #22

Closed alext-mkrs closed 6 years ago

alext-mkrs commented 6 years ago

Okay, so looks like that meta-mingw patching problem we discussed in https://github.com/htot/meta-intel-edison/issues/6 still exists, at least in master. Here's a fix.

Master is a current branch for development and it should be stable enough to run on Edison, right? Except for ACPI being enabled by default maybe.

htot commented 6 years ago

Yes, rocko branch has 10 commits more, including something to fix this. I was workiing on other stuff (fixing hsu, i2c working on non-acpi : ugly, trying preempt_rt). I'll try to find time to review this tomorrow. Also update rocko and send you a review request. One thing not yet fixed: initramsfs might need a DEPENDS on kernel-modules. For now I just do bitbake -k a 2nd time. Also I found we should move to 32 bit. There are things not working with hsu on 64 bit that I can't seem to fix. And interrupt latency is much slower.

alext-mkrs commented 6 years ago

By "rocko branch" you mean "rocko64-acpi"? I though that one is abandoned these days. Okay, so let me wait for your merge before I proceed with that regulatory DB stuff, so that we work off of the same set of recipes.

As for 32 vs 64 bits - to be honest I thought this was unnecessary for Edison's case - having just 1 GB of RAM we are only wasting it on 64. Not sure if anything would run faster when compiled 32 vs 64, but my wild guess would be "none to marginal" difference. But I'd be curious to know if anyone actually tried and benchmarked it.

htot commented 6 years ago

Yes, that's it. It's my development branch.

In fact I know someone who has been benching: https://github.com/htot/crc32c https://github.com/htot/base64

On 64b certain instructions should be a lot faster. But also I discovered that on silvermont (Baytrail NUC, Edison) there is a severe penalty when instructions become too long. Then however, when they are used in a long (> 100 iterations) the penalty does not apply. Haven't applied applied the latter on crc32 yet, but should give a speedup of 3x on 64b on long buffers.

htot commented 6 years ago

Your patch and mine were same, but you had correct ref to original author so I took yours, thanks. Added one more to clean up the obsolete patch from utils. Now will rebase rocko64 and send PR for you to review.