Rocko64 acpi

[htot]

Switched to Rocko on this branch. Needed to upgrade nodejs to 7 as 6 wouldn't build (8 will as is provided by rocko). Then had to disable mraa nodejs bindings as they don't work with nodejs >= 7.

I don't know how to fix this.

Added libgpiod as we are going to need this with acpi enabled versions.

[htot]

From rocko we gain: + libgpiod + gcc7

We loose: - nodejs mraa bindings (I can either build nodejs or mraa binding sbut not both), maybe caused by new gcc? - btattach is missing (we need this to power bt on non-acpi. But on acpi it's not needed and bt works fine) . But maybe it's missing because I need to install bluez-tools. I will check.

I put gpioinfo on openwrt wiki here https://edison.internet-share.com/wiki/ACPI

[alext-mkrs]

Node versions 7+ are not supported by SWIG, used to generate mraa bindings, that's the reason. There's no solution yet as that part if swig lost a maintainer a while ago. The only way is to downgrade Node, or do not build JS bindings.

[htot]

@alext-mkrs I tried with an earlier nodejs (6.??, same as the one you made work for pyro), but then get errors compiling node itself. Could it be because of newer gcc?

[htot]

@alext-mkrs Indeed, compiling nodejs_6.10.3 fails on rocko because gcc 7. However, I located the patch that fixes this and is applied to 6.11.2 and bbappend it. Now it builds and also mraa/upm with nodejs bindings.

[alext-mkrs]

Thumbs up :) Do you want me to test and/or review this one?

[htot]

Yes please :-) Things for which I could use advice: 1) acpi-tables service recipe still not using YP systemd system 2) mraa gpio numbering completely changed, fix up intel_edison_fab or use libgpiod to use pin names?

[alext-mkrs]

Sure, I'll check this out. As for mraa pin numbering - that may be a problem, chardev support is not merged yet and the old sysfs way of accesing gpios is no longer supported on kernels 4.8+ AFAIU.

[htot]

I think the sysfs interface still works (I use it to set the TRI_STATE_ALL pin) but you need to know the gpiochip number + pin number on the chip, see openwrt wiki.

root@edison:~# gpiofind "TRI_STATE_ALL"
gpiochip1 14

root@edison:~# gpiodetect 
gpiochip4 [INT3491:03] (16 lines)
gpiochip3 [INT3491:02] (16 lines)
gpiochip2 [INT3491:01] (16 lines)
gpiochip1 [INT3491:00] (16 lines)
gpiochip0 [0000:00:0c.0] (192 lines)

root@edison:~# cat /sys/class/i2c-adapter/i2c-1/i2c-INT3491:00/gpio/gpiochip496/base
496

So "TRI_STATE_ALL" can be accessed by exporting (496 + 14) = 510

[alext-mkrs]

I was talkingabout /sys/class/gpio thing, which is a bit different, but indeed looks like it's deprecated, but not yet fully dropped (link).

[htot]

BTW I was talking about /sys/class/gpio too: echo 510 > /sys/class/gpio/export # export TRI_STATE_ALL pin is used in /usr/bin/acpi-tables-load and works. The problem (for now) is that the numbering changed. So that breaks mraa. And the current numbering is not guaranteed to stay this way. So I was thinking to fill the tables in intel_edison_fab using libgpiod, to keep backwards compatibility.

[alext-mkrs]

If going there, I'd rather advise to look into chardevmerge2 branch - that's where the new code for supporting the new way of accessing lives right now. That could help the project with testing, increasing the confidence for the merge.

As for my build of this PR - my overnight build on Wed failed (ran out of disk space) and I haven't had normal access to my dev machine since then to fix and rebuild. I'll take care of this over the weekend and post back.

[alext-mkrs]

I have the build still running, but there's an error, looks like a stale git commit hash again:

ERROR: u-boot-1_2018.01-r0 do_fetch: Fetcher failure: Unable to find revision 1e974c4d2b3a6ee292c8ff22ffe4994efc1fdf23 in branch acpi even from upstream
ERROR: u-boot-1_2018.01-r0 do_fetch: Fetcher failure for URL: 'git://github.com/andy-shev/u-boot.git;branch=acpi;protocol=https'. Unable to fetch URL from any source.
ERROR: u-boot-1_2018.01-r0 do_fetch: Function failed: base_do_fetch
ERROR: Logfile of failure stored in: /edison_dev/yocto/vanilla-rocko/out/linux64/build/tmp/work/edison-poky-linux/u-boot/1_2018.01-r0/temp/log.do_fetch.14946
ERROR: Task (/edison_dev/yocto/vanilla-rocko/meta-intel-edison/meta-intel-edison-bsp/recipes-bsp/u-boot/u-boot_2018.01.bb:do_fetch) failed with exit code '1'

[htot]

Oops, sorry. But it's not like last time. In this case I see that (as you have acpi enabled) u-boot is pulled from Andy's gh and it appears he has rebased on u-boot 2018.03. I see he dropped some patches that got upstreamed and added one new "x86: tangier: Add Fast IRQ support for Wi-Fi card"

Not sure how to best prevent this from happening: 1) fetch HEAD from Andy's gh instead of specific sha (but I don't know how to fetch HEAD) 2) clone Andy's gh and branch off the different versions, so make the transition to a new version controlled (same as I do with the kernel) 3) get u-boot from upstream and apply patches in the recipe (same as with non-acpi version of u-boot)

What do you prefer?

[alext-mkrs]

I would say either 2 or 3 - to control things and make builds repeatable. Fetching tip of the repo is possible, but then from build to build the results may differ as Andy may be pushing stuff in the meanwhile.

As ACPI U-Boot version for Edison is still WIP, I'd say let's go with number 2 to avoid redoing the work Andy is doing, but still control what's getting into the build.

[htot]

I forked and created a branch acpi-v2018.01. I will branch off acpi-v2018.03 with Andy's latest changes when it get's released and after testing. Modified commit 'u-boot: switch to 2018.01 and select acpi by DISTRO_FEATURES' which was in pyro64, so rewriting history for both pyro64, pyro64-acpi (maybe should drop this one?) and rock64-acpi.

[htot]

I had look at chardevmerge2 and it looks like the implementation is not using libgpiod. In the joule implementation I see that gpio_chip and _line are added as fixed numbers. That confuses me, I thought these are not guaranteed to stay the same across boot / kernel updates. I was expecting the pin name to be used to lookup _chip and _line.

Do you understand what the intention is here?

[alext-mkrs]

As for the "no libgpiod" - that's on purpose, to avoid surplus dependencies. As for the numbering - I'd need to refresh my memory on that as I did the review quite a while ago and don't recall that piece.

[alext-mkrs]

So I went through that branch again and I think that was only a matter of introducing some example, without changing Joule's DT and stuff to use the fully dynamic discovery.

I'm building the latest incantation of this PR, will post back when it's done or if there are problems.

[alext-mkrs]

Builds fine, so it's good to merge IMHO.

[htot]

Thanks for testing. I found one problem, if you switch to building a 32b image the kernel needs a patch otherwise building perf fails. I will commit that maybe tomorrow.

Question remains: where to merge it to? This actually is rocko. My pref: to master. Currently master is the original factory branch, is suggest we branch that of to 'original'.

In master we can then have a docs directory and store updated documentation there and have that on a github pages site. I have been playing with my repo test that generates https://htot.github.io/test/. I can't get github to generate this, but can generate locally and commit the whole thing. What do you think?

[alext-mkrs]

Yes, using master sounds good to me. Haven't used the GH sites feature, but I guess you may need to use Travis to build and deploy it, if gh doesn't do that automatically.

[htot]

Created original from master and pushed rocko-acpi to master.