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

MRAA needs to be adapted to acpi pin numbering/naming #50

Closed htot closed 1 year ago

htot commented 5 years ago

When we run the MRAA Example Blink-IO.js on the acpi enabled image nothing happens.

dmesg shows: edison kernel: export_store: invalid GPIO 214

This indicates MRAA is using the wrong pin numbering - and in fact it should be using the pin names. Doing gpioinfo shows TRI_STATE_ALL is on gpiochip1 line 14. You find gpiochip1 under /sys/class/gpio/gpiochip496/device/, so the base address has become 496 and the gpio is 510.

We need to modify intel_edison_fab_c.c to use either libgpiod or the new gpio chardev interface directly to get mraa working.

This is a priority task as it currently seems to be the only thing holding us back to switch to the acpi enabled image.

@alext-mkrs do you feel inspired to take this? You are without doubt the most knowledgeable of us.

alext-mkrs commented 5 years ago

I'm sorry - I've apparently [dis]missed the notification for this one. I think I could (and I'm actually willing to) take that on and being the mraa co-maintainer is sort of fitting here :D The only problem is that I haven't done much actual development there for a while, so will need to refresh myself on platform internals + find the time to actually do that - and the latter is the main problem these days.

Anyway, let me assign this to myself and see what (and when) I can do - I'll post the progress here.

To start at the beginning - what's the latest and greatest ACPI image build recipe, so that I have a live platform to work off of?

htot commented 5 years ago

@alext-mkrs take would be just great. Latest and greatest is here https://github.com/htot/meta-intel-edison .. since yesterday. But I didn't dare to ask you yet.

I sort of EOL the sumo branches, and of course immediately sumo itself got updated and broke the build. With yesterdays patches it builds again on 18.10 Cosmic. I'm hoping someone (@sjpeng) will build those to verify they still build on earlier (like 18.04). And then PR to edison-fw.

But for this effort (MRAA) the brand new thud branch (64b) or master (32b) would be nice, 4.20 kernel would be best. Tested yesterday, all seems to be working well. USB OTG (gadget) works too, but I only tested with linux hosts. I guess for windows more needs to be done, windows needing drivers and inf files. Docs also in master and therefore here: https://htot.github.io/meta-intel-edison/ (see the USB section). I am completing oobe for this (patches will follow), will not depend on Nodejs for the web server, just python3.

Edit: oh yes, blink-led works (not the MRAA Example Blink-IO.js), the ap-mode-toggle too. We can get rid of hostapd but I forgot. Actually the new kernel supports the leds through a acpi table that we have, but I haven't adapted blink led yet.

And there is one bug: after reboot usb does not work, it waits for an event (flipping the switch does the trick). But cold boot works fine.

htot commented 5 years ago

@alext-mkrs I just force push a fix to master and thud (patch for meta to enable build 4.20 kernel) that I missed.

alext-mkrs commented 5 years ago

Interesting, I can't seem to be able to checkout the commits I see in the master commit history. I do a normal git clone of the whole repo (just start anew)

me@host:~/emb_dev/edison/yocto/master$ git clone https://github.com/edison-fw/meta-intel-edison.git
Cloning into 'meta-intel-edison'...
remote: Enumerating objects: 110, done.
remote: Counting objects: 100% (110/110), done.
remote: Compressing objects: 100% (61/61), done.
remote: Total 3430 (delta 50), reused 102 (delta 47), pack-reused 3320
Receiving objects: 100% (3430/3430), 29.58 MiB | 9.85 MiB/s, done.
Resolving deltas: 100% (1680/1680), done.
me@host:~/emb_dev/edison/yocto/master$ cd meta-intel-edison/

and it gets me the following:

me@host:~/emb_dev/edison/yocto/master/meta-intel-edison$ git log
commit d0de39d612c6cb032f19acd3b89f2f4264c444b9 (HEAD -> master, origin/sumo32, origin/master, origin/HEAD)
Author: Ferry Toth <ftoth@exalondelft.nl>
Date:   Fri Jan 4 21:25:23 2019 +0100

    docs: end of line for sumo32

    Signed-off-by: Ferry Toth <ftoth@exalondelft.nl>

commit f35ccf54f5907edecd0d98de807c8e3fbc7febb9
Author: Ferry Toth <ftoth@exalondelft.nl>
Date:   Sat Oct 27 22:25:52 2018 +0200

    docs: colors

    Signed-off-by: Ferry Toth <ftoth@exalondelft.nl>
<...>

which is what GH shows for Jan 4 2019, but then there were other commits on Jan 6-19 and apparently they don't get cloned:

me@host:~/emb_dev/edison/yocto/master/meta-intel-edison$ git checkout d547a44295f8fe2899ed49f557cd290ce4210ae2
fatal: reference is not a tree: d547a44295f8fe2899ed49f557cd290ce4210ae2

(this commit is the newest one on master according to GH).

@htot, are you able to clone the current master in full?

htot commented 5 years ago

d0de.. is on edison-fw/meta-intel-edison (this is on my machine my 'origin' remote), is sumo waiting for a PR from htot/meta-intel-edison d547.. is on htot/meta-intel-edison (on my machine my 'github' remote), this is currently in development and based on thud

htot commented 5 years ago

d547.. is actually working quite well, I could send a PR now? I was just working on the oobe (which is going to be very nice, I hope you will like it), but which is not ready yet.

alext-mkrs commented 5 years ago

Okay, I must've been somehow looking at your fork instead of the edison-fw's master, false alarm then. It just looked like there are more commits on the branch that GH showed than I saw in my clone :)

alext-mkrs commented 5 years ago

While my #58-based image build is in progress I'm looking into current mraa code for Edison to see how the porting can be accomplished and looks like this isn't going to be easy. Edison (in the Arduino board case, miniboard looks better) is a wild mix of board-specific init/post-init code (so called "advance functions") and pinmuxing setup due to the ways the board HW was implemented, which would need to be heavily edited for the the situation when ACPI controls that.

Coupled with chardev-specific changes, at the first glance, this looks like near complete rewrite to me (don't quote me on this yet though, this is my first stab at it and it's quite late here already :stuck_out_tongue_winking_eye:), which may be prohibitively large of a task for me right now :unamused: We'll see...

htot commented 5 years ago

Well, Rome wasn't built in one day :relaxed:. Currently it's 1850 loc, half is initializing data structures. Maybe we can simplify it?

alext-mkrs commented 5 years ago

Well, the problem is - the old code has to stay as well (so that it works for those using old images) and it's unlikely you can merge the two as they're quite different approaches.

Assessing this better, I think I have to give this up for anyone else wishing to look into this. Sorry, but I just don't see any time in the nearest weeks/months I could spend on this. I'll try to help with reviewing if someone picks this up - just @-mention me to make sure.

htot commented 5 years ago

Yes, I thought about that. It would give a lot of conditionals. Or we need to create a 2nd platform file?

alext-mkrs commented 5 years ago

Essentially I don't see any clean way of doing that - either two files with an upper-level one that dynamically picks one vs. the other at runtime (I think that's the best that could be done) or cram it into the existing one (that would be simpler/faster, but certainly uglier).

htot commented 5 years ago

Yeah 2 files would be best. I don't know if there needs to be a 3rd upper level one, there is already platform detection, maybe that can be expanded.

andy-shev commented 4 years ago

JFYI: There is work in progress in libgpiod to allow communicate with GPIO chips via D-Bus IPC. It will help a lot in drastically increasing security for all IoT node.js and alike based solutions.

xlla commented 4 years ago

it's too hard to tinker, even use libgpiod directly, I am give up.

htot commented 4 years ago

Don't give up now :-)

In mraa for other boards they have implemented chardev interface: git log --all --grep='chardev'. i believe chardev is what libgpiod uses too. With that interface they fixup boards that you can use as example (git log): up2: added chardev map to platform arm: 96boards: Add Chardev support for relevant boards minnowboard: add chardev support

xlla commented 4 years ago

I tried to adopt gpio_chardev version mraa. compiled a simple example code to blink led on D3. program was runs, but led does not blink.

    line  12:      unnamed          "O"  output  active-high [used]
    line   2: "DIG2_PU_PD"       unused   input  active-high 
    line   3:  "MUX27_DIR"          "O"  output  active-high [used]
    line  14: "TRI_STATE_ALL" "O" output active-high [used]

and I don't know how set meaningful name instead of "O".

when I stop mraa app and use python blink-led on D3, it works, prove led was fine.

xlla commented 4 years ago

I have create an issue in mraa repo.

for temporary test, I do some hack, the consumer was set. it's not easy to echo a name of final program that link to mraa lib, so I just hard code to "mraa".

    line  12:      unnamed       "mraa"  output  active-high [used]
    line   2: "DIG2_PU_PD"       unused   input  active-high 
    line   3:  "MUX27_DIR"       "mraa"  output  active-high [used]
    line  14: "TRI_STATE_ALL" "mraa" output active-high [used]

plus other hack to mraa's api, I got a blink led work with mraa lib on D3 :)

htot commented 4 years ago

Progress :-)

Did you check the up2 andminnowboard code for examples?

xlla commented 4 years ago

yes, I have read those code, it is use brand method to define pin info, direct set line chip and line number; and those board fairly simple , no such mux/bias found in Edison arduino board. so I can't follow that code, I won't like write too much code, it will introduce too many bugs and will spend much time to debug. I believe exist code was right and have tested, and I just try to dynamic adapt chardev verision,use minimal efforts.

now, Dx out & uart0 read/write was work, I am going to check others.

xlla commented 4 years ago

after add a lot patches to mraa lib. Interrupt on D4 work.

root@edison:/mnt/study/git/mraa/examples/c# mraa-gpio version
Version v2.1.0 on Intel Edison
root@edison:/mnt/study/git/mraa/examples/c# mraa-gpio list
00         IO0: GPIO UART 
01         IO1: GPIO UART 
02         IO2: GPIO 
03         IO3: GPIO PWM  
04         IO4: GPIO 
05         IO5: GPIO PWM  
06         IO6: GPIO PWM  
07         IO7: GPIO 
08         IO8: GPIO 
09         IO9: GPIO PWM  
10        IO10: GPIO SPI  
11        IO11: GPIO SPI  
12        IO12: GPIO SPI  
13        IO13: GPIO SPI  
14          A0: GPIO AIO  
15          A1: GPIO AIO  
16          A2: GPIO AIO  
17          A3: GPIO AIO  
18          A4: GPIO I2C  AIO  
19          A5: GPIO I2C  AIO  
root@edison:/mnt/study/git/mraa/examples/c# ./gpio_advanced 
ISR triggered
xlla commented 4 years ago

@andy-shev I am confused on pinmode. I have received ISR from D4 successful, a touch button connected to it.

but through debugfs, I observe this pin are in "mode 1"

pin 120 (GP129_UART_1_RTS) mode 1 0x00003001

why it is work fine as GPIO line even through in "mode 1"/UART. is there any document about pinmode?

andy-shev commented 4 years ago

@andy-shev I am confused on pinmode. I have received ISR from D4 successful, a touch button connected to it.

How do you know that? Did you get /proc/interrupts changed?

but through debugfs, I observe this pin are in "mode 1"

If we assume that IRQ is indeed went thru, I see at least the following cases:

More info is needed (code, log dumps, etc)

pin 120 (GP129_UART_1_RTS) mode 1 0x00003001 why it is work fine as GPIO line even through in "mode 1"/UART. is there any document about pinmode?

I think there is no public documentation for that. Mode 1 is UART, mode 0 is GPIO for this pin. Only what we have is Table 4 of Edison/Arduino hardware guide.

xlla commented 4 years ago

How do you know that? Did you get /proc/interrupts changed?

I manage to compiled a mraa lib v2.1 for our edison acpi-kernel 5.5. of cause add a chardev version platform file, still in progress.

after finished basic gpio function migrate, I compile & test mraa/examples/c/gpio_advanced.c, I connected a touch button to D4, change code to "#define GPIO_PIN 4". each time I touched button, it print "ISR triggered".


root@edison:~# /mnt/study/git/mraa/examples/c/gpio_advanced
ISR triggered
ISR triggered
  • the debugfs or whatever code (MRAA?) switches somehow modes

Yes, some code switches pin mode!! I only check the pinmode before app run, and never check it again after app exit.

today, I found it was switched to GPIO mode after app exit!! (I have comment out all pinmode code in mraa platform file)

pin 119 (GP128_UART_1_CTS) mode 1 0x00003001
pin 120 (GP129_UART_1_RTS) GPIO 0x00003000
pin 121 (GP130_UART_1_RX) mode 1 0x00003001
pin 122 (GP131_UART_1_TX) mode 1 0x00003001

choice D4 is an accident. due to my lack knowledge :) I am use 2-wire uart version ssdt, so I think I can use D2,D4 for gpio, now I am known all 4 line will be mode 1 even choice 2-wire uart ssdt.

xlla commented 4 years ago

I never change the pinmode in this case, maybe kernel auto change it to GPIO mode.

xlla commented 4 years ago

benchmark report, firmware lastest 160606, mraa v2.0

  GPIO direct write 0/1, 34.9~35.71khz, 48% cpu load
  with realtime FIFO scheduling, mmap, 1.667~2.0Mhz, 46% cpu load

firmware warrior/eds-acpi-5.5.0/kernel v5.5 i686, mraa v2.1

  GPIO direct write 0/1, 96khz, 50% cpu load
  with realtime FIFO scheduling, mmap, 1.60~1.61Mhz, 50% cpu load

direct wirte, ~2.7x fast mmap, same

andy-shev commented 4 years ago

I never change the pinmode in this case, maybe kernel auto change it to GPIO mode.

Whenever pin is requested by user as GPIO it has been switched to GPIO function by the driver.

htot commented 1 year ago

With the upcoming Honister branch we are switching to libgpiod, libiio and libserialport which are in principle a full replacement for mraa. Further, development of mraa and upm has slowed down and last but not least, none of edison-fw user is complaining about missing support.