Closed mwallnoefer closed 4 years ago
I see, needs to be fixed to use libgpio
@htot Have you fixed also this one in your new zeus branch? So I will re-test everything in one shot.
Not yet. I looking if I fix this to use libgpiod.
BTW I am running btrfs branch on top of zeus. I hope I made the split correct. The btrfs branch creates a more or less standalone initrd that I used to manually convert ext4 partitions into a single btrfs pool with @, @home, @boot
subvolumes. That will need a script to automate the process, but it doesn't exist yet. I have documented how to send a 2nd rootfs subvolume. Other than that, it works for me but is not yet complete.
@mwallnoefer @xlla would you like to have a look at https://github.com/htot/meta-intel-edison/tree/sketch_reset_v1?
I rewrote most of galileo-reset.c to use libgpiod. This uses pin names instead of numbers, so on the command line it also changed. In the make file I had to discard some options to make errors go away, it's crazy. Now there are still many warnings, but only in the clloader
code which was probably already the case. Ugly.
I tested this by running on edison:
root@edison:~# systemctl stop sketch_reset
root@edison:~# /opt/edison/sketch_reset -i SHLD_RESET0 -o SHLD_RESET1 -s /opt/edison/sketch_reset.sh
killall: clloader: no process killed
killall: clloader: no process killed
^C
root@edison:~# /opt/edison/sketch_reset -i SHLD_RESET0 -o SHLD_RESET1 -s /opt/edison/sketch_reset.sh -vv
Toggle reset line
Select event received : from GPIO interrupt pin
Sketch Reset button released: Calling /opt/edison/sketch_reset.sh
killall: clloader: no process killed
killall: clloader: no process killed
Select event received : from GPIO interrupt pin
Sketch Reset button pressed:
Select event received : from GPIO interrupt pin
Sketch Reset button released: Calling /opt/edison/sketch_reset.sh
killall: clloader: no process killed
killall: clloader: no process killed
I find at least I got button released and button push mixed up. Line toggle on start I didn't test, may be it's even to fast and needs a timer. For the reset seems to do what it needs - except I'm not sure what it needs :-)
Will do. Please don't forget my battery-voltage service suggestions!
Error message which I get when calling bitbake:
Failed to fetch URL file://btrfs.cfg
Oops. When I rebased kernel 5.5 recipe patch it must have sneaked in that line. I'll fix that too. In the meanwhile you can remove that. It is supposed to enable btrfs in the kernel, something you don't need now.
Ok, other issue:
ERROR: oobe-1.2.1+gitAUTOINC+250de53880-r0 do_package_qa: QA Issue: /usr/bin/configure_edison contained in package oobe requires /usr/bin/python, but no providers found in RDEPENDS_oobe? [file-rdeps]
ERROR: oobe-1.2.1+gitAUTOINC+250de53880-r0 do_package_qa: QA run found fatal errors. Please consider fixing them.
ERROR: oobe-1.2.1+gitAUTOINC+250de53880-r0 do_package_qa:
ERROR: oobe-1.2.1+gitAUTOINC+250de53880-r0 do_package_qa: Function failed: do_package_qa
I see, another moved too far down. I think this will go away if you revert eadb3a8.
(actually this happened because I'm working on new oobe, which is completely based on python3, vs. python + nodejs for current version).
Okay, but now I still get a build error with perf
.
log.do_compile.31056.txt
This might be caused by an old perf? I think you are compiling using make image
? That is good as it cleans up yocto and kernel before bitbaking the reset. But you might want to try to manually clean perf too:
cd out/linux64/build
source poky/oe-init-build-env
bitbake -c cleansstate perf
In addition I created v2 taking into account your comments here and in the battery-voltage.c. This time I actually built the branch myself.
I hope it will be smoother for you now.
Did not work.
I will try checking out completely new and rebuilding all.
I found make setup
does not complete (zeus updated causing patch to fail). Then meta-acpi
compatibility not yet set for zeus. So, pushed 1 patch on meta-acpi (automatically pulled with make setup
) and one patch on meta-intel-edison.
So best is if you make clean && make setup && make image
after pulling meta-intel-edison.
~I am now at 50% (perf not yet built), need another hour.~ Everything built just fine now.
Okay will re-try the build!
perf
tool should come from the kernel sources.
it works well.
root@edison:~# systemctl status sketch_reset.service ● sketch_reset.service - Daemon to reset sketches Loaded: loaded (/lib/systemd/system/sketch_reset.service; enabled; vendor preset: enabled) Active: active (running) since Sat 2020-02-15 17:20:07 UTC; 2h 22min ago Main PID: 567 (sketch_reset) CGroup: /system.slice/sketch_reset.service └─567 /opt/edison/sketch_reset -i SHLD_RESET0 -o SHLD_RESET1 -s /opt/edison/sketch_reset.sh Feb 15 17:20:07 edison systemd[1]: Started Daemon to reset sketches. root@edison:~#
@andy-shev yes, there is a recipe for kernel and a recipe for perf. After you built both and then switch kernel and rebuild it seems some artifacts from kernel remain interfere with building perf. Cleaning everything, then building seems to help. It's a Yocto problem i think.
Tried another full rebuild, but always ending up in the perf
issue:
make: Leaving directory '/datadisk/edison-fw/out/linux64/build/tmp/work/edison-poky-linux/perf/1.0-r9/perf-1.0/tools/perf'
WARNING: exit code 1 from a shell command.
Referring to your last comment, how may I circumvent this?
That is weird. I meant bitbake -c cleansstate perf
cleans perf, while make image
cleans linux and u-boot and then starts build (all in the right directory).
But if you did make clean && make setup && make image
it doesn't get cleaner. I have done this (64 bit) and then again (32 bit) on another machine with no errors. In all cases the host is Ubuntu 19.10.
That's the bug: https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg133569.html The mentioned patch did it for me.
Yes, but strange that I can build without problem. As I understand the patch makes the native (yocto built) python to be used and not the host python?
My host is still on Ubuntu 18.04 LTS, this might make the difference (you're on Ubuntu 19.10).
Btw. is this a new service? Does it make sense to have it enabled per default?
[FAILED] Failed to start Set timezone by geolocation service.
See 'systemctl status run-timezone.service' for details.
Run once should be enough, if it succeeds. I haven't figured out what to do here exactly. I just wanted to have time zone set automatically. Did it fail for you?
root@edison:~# systemctl start run-timezone.service
root@edison:~# systemctl status run-timezone.service
● run-timezone.service - Set timezone by geolocation service
Loaded: loaded (/lib/systemd/system/run-timezone.service; disabled; vendor preset: enabled)
Active: inactive (dead)
Mar 06 18:18:54 edison systemd[1]: Starting Set timezone by geolocation service...
Mar 06 18:18:54 edison run-timezone[1136641]: PING ipapi.co (104.26.8.44): 56 data bytes
Mar 06 18:18:54 edison run-timezone[1136641]: --- ipapi.co ping statistics ---
Mar 06 18:18:54 edison run-timezone[1136641]: 1 packets transmitted, 1 packets received, 0% packet loss
Mar 06 18:18:54 edison run-timezone[1136641]: round-trip min/avg/max = 16.242/16.242/16.242 ms
Mar 06 18:18:55 edison systemd[1]: run-timezone.service: Succeeded.
Mar 06 18:18:55 edison systemd[1]: Started Set timezone by geolocation service.
root@edison:~# timedatectl
Local time: Fri 2020-03-06 18:23:45 CET
Universal time: Fri 2020-03-06 17:23:45 UTC
RTC time: Thu 2000-01-13 18:16:02
Time zone: Europe/Amsterdam (CET, +0100)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
I'll add a patch to fix perf.
It fails until you enable connectivity (wifi) with a subsequent reboot respectively service restart operation.
Also here I would not make the service fail (terminate with <>0 exit code), since it is not an exceptional behaviour when the connectivity hasn't been set up yet.
Got it. But actually I want it run once on boot without failing. Once it succeeds it can be disabled. But I haven't thought it through completely.
For now I pushed this stuff to zeus including the perf you suggest.
Okay, so back to sketch_reset.service
, this is what I get on branch zeus:
root@edison:~# /opt/edison/sketch_reset -i SHLD_RESET0 -o SHLD_RESET1 -s /opt/edison/sketch_reset.sh
Shield reset input GPIO invalid or not specified
How do I set up the pin mapping with libgpiod?
I force pushed. Are you on 443513e4?
There is nothing to map, as it is mapped already through acpi tables. You can see that using gpioinfo
.
Yes, I am on that commit. But in gpioinfo
I do not see these ports mapped:
root@edison:~# gpioinfo | grep "SHLD"
root@edison:~#
root@edison:~# gpioinfo | grep "SHLD"
line 7: "SHLD_RESET0" unused input active-high
line 15: "SHLD_RESET1" unused output active-high
Afaik these are defined in a aml in U-Boot. What do you have when you just gpioinfo
?
Wow, you are missing gpiochip1 (see mine below). It might be fixed by doing a cold boot (unplug power).
That did it, thanks!
We should disable the _sketchreset service if there is no GPIO access: