Jump to content

sbc_chrisb

Members
  • Posts

    20
  • Joined

  • Last visited

Reputation Activity

  1. Like
    sbc_chrisb got a reaction from cman122887 in Le Potato GPIO pins on /sys   
    Hello, I'm new to this world of SBC. I'm trying to learn as much as possible, and I realize maybe I should have started with a better documented board like the rPI. I guess I just like learning the hard way.
     
    I'm trying to use the GPIO pins on the board. Starting with baby steps, I'm looking to just simply turn on/off an LED via GPIO. I've been searching and poking around the /sys filesystem to try to understand how this works, but I'm having a hard time understanding which pins to expose via the export file, and what physical pins those map to.
     
    I see /sys/class/gpio/ has two chips, 0 and 10. I see gpiochip0 has 10 pins, and gpiochip10 has 101. Is there a document which maps which of these corresponds to the physical pins available? If I write "8" to the export file /sys/class/gpio/export, does that expose pin 8 on the board (UART_A_TX)? Am I understanding this right or am I way off? For my purpose, which pin would be the right one to start with to turn an LED on?
     
    Side note: I also noticed on the schematic for the board that several of the pins are labelled WIFI, are these interface pins for the SOC wifi module? 
     
    Apologies if these are dumb questions. I'm just trying to find the info to learn what does what on this board.
  2. Like
    sbc_chrisb reacted to mboehmer in Thanks for the fish!   
    Hi guys,
     
    finally, paper is finished, and for anyone interested it can be found here on the arXiv site
    Be warned, it concentrates on the physics, not the electronics
     
    Michael
  3. Like
    sbc_chrisb reacted to TonyMac32 in Le Potato - writing armbian to eMMC   
    I have a CoCo 2 and a Model 100 Portable. 
  4. Like
    sbc_chrisb reacted to TonyMac32 in Le Potato - writing armbian to eMMC   
    OK, so, for you/anyone doing this before it's officially baked in:
     
    Download 4.18 image
    Build newest 4.18 kernel/u-boot
    update boot script with the one currently in our repo
    reboot (because of superstition)
    run nand-sata-install
     
    I would recommend being on the moderately advanced side before attempting it, unless you really want to experiment.
     
     
  5. Like
    sbc_chrisb got a reaction from TonyMac32 in Le Potato - writing armbian to eMMC   
    Yes, sorry that statement is correct, it would still boot from SD which allowed me to go back in and fix it. I don't have the exact logs of that point but I believe that was when it was hanging at trying to remount the rootfs and failing, so it just sat there hung until I inserted the SD card. 
  6. Like
    sbc_chrisb got a reaction from TonyMac32 in Le Potato - writing armbian to eMMC   
    Whew. Okay, so that was a fun ride. 
     
    My suspicions about the kernel were correct. I followed the docs to do a new kernel build for armbian, 4.18.19. I hadn't built a kernel or anything large like that in a while, really stress tested my AMD 8350. Either way, I got the new packages over onto the Potato, installed them (with a --force-all to get uboot to update, since it refuses initially). Then after another reboot, nand-sata-install completed successfully.
     
    First boot without an SD card failed hard. Went back in with the SD card, mounted the emmc and mv'd the boot.cmd and scr files out of the way and put in the one Tony provided me above. Rebuilt the scr with mkimage. That did the trick, I'm now running on emmc now. Thanks for the help, Tony. 
     
    To recap, the stock image is fine to install to emmc *if* you:
     
    1. build a new 4.18 kernel, hopefully the next armbian release will be fine
    2. run nand-sata-install
    3. mount the emmc and modify the boot.cmd command *in the emmc boot dir* with the updated file linked above, then rebuild the scr with mkimage. NOTE: don't use the command in the bottom of the file directly, as it gives absolute paths for the files and since you're on the SD card the path is different. Use the following while in the boot dir of the emmc:
    mkimage -C none -A arm -T script -d boot.cmd boot.scr  
     
  7. Like
    sbc_chrisb got a reaction from Da Xue in Le Potato GPIO pins on /sys   
    So, I still need to verify some of the later pins, going to work on that tomorrow with a bash walker loop while I swap wires on the header to an LED. This is yet another table that maps the 40 pins to libgpio, for reference. Maybe someone will find it useful. GC0 is gpiochip0 and GC1 is gpiochip1 in libgpio. 
     



     
    Quick bash variable list for importing into scripts, so you can just think in terms of header pins rather than the mappings.
     
    P01=NA P02=NA P03=0:5 P04=NA P05=0:4 P06=NA P07=1:98 P08=1:91 P09=NA P10=1:92 P11=0:8 P12=0:6 P13=0:9 P14=NA P15=1:100 P16=1:93 P17=NA P18=1:94 P19=1:87 P20=NA P21=1:88 P22=1:79 P23=1:90 P24=1:89 P25=NA P26=1:80 P27=1:75 P28=1:76 P29=1:96 P30=NA P31=1:97 P32=1:95 P33=1:85 P34=NA P35=1:86 P36=1:81 P37=1:84 P38=1:82 P39=NA P40=1:83  
    Example bash script:
     
    #!/bin/bash . pinheaders #This is the above variable list as a separate file print() { for i in {01..40}; do var=P${i} printf "Pin $i: ${!var}\n"; done } walk() { for i in {01..40}; do var=P${i} if [[ ! ${!var} = "NA" ]]; then chip=gpiochip$(echo ${!var} | cut -f1 -d:) pin=$(echo ${!var} | cut -f2 -d:) gpioset $chip ${pin}=1 sleep .5 gpioset $chip ${pin}=0 fi done }  
    You get the idea. If you're working with just pins 27 and 28 you can source the pinheader file, then use $P27 and $P28 to get the chip and pin from that variable.
     
    Hopefully this info is useful to someone searching the forum like I was.
  8. Like
    sbc_chrisb got a reaction from Tido in Le Potato GPIO pins on /sys   
    So, I did some more testing and crashed my board. I hooked up wire to what I'm calling pin 3. Honestly I'm completely confused how to number these pins now. I was referencing this page
    http://wiki.loverpi.com/sbc-brand:libre-computer and the pinout link there: http://wiki.loverpi.com/pinouts
     
    which has two pins labelled 2: the pin right next to 3v3, and also first 5v. Anyway I wired up the pin next to 3v3 to an LED, and also ground. I then ran a bash loop to use gpioset gpiochip1 like so:
     
    chris@lepotato:~/Projects/libgpiod$ for i in {1..25}; do echo $i; sudo gpioset gpiochip1 $i'=1'; read; sudo gpioset gpiochip1 $i'=0'; done 1 gpioset: error setting the GPIO line values: Invalid argument gpioset: error setting the GPIO line values: Invalid argument 2 gpioset: error setting the GPIO line values: Invalid argument gpioset: error setting the GPIO line values: Invalid argument 3 gpioset: error setting the GPIO line values: Invalid argument gpioset: error setting the GPIO line values: Invalid argument 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 gpioset: error setting the GPIO line values: Device or resource busy gpioset: error setting the GPIO line values: Device or resource busy 20 21 22 23 24 25  
    And yeah, the LED never lit up. From that spreadsheet linked above, it should have been lighting up at 5, but it wasn't. When I tried doing the above loop all the way to 100, it eventually completely crashed my board and I had to hard reset it. 
     
    Is libgpio just busted or something? 
     
    I confirmed the LED works by connecting it to the ground pin and 5v, then 3v3, then the second 5v, and it lights up fine on those three. I hooked it to "pin 3" and while it gives a very slight dim light by default (not sure it's supposed to do that or what), and then never changes when I run the above loop to send it to 1 or 0.  
     
    I must be doing something wrong here...
     
    EDIT: Okay, so I can't get this to actually change any values anyway. 
     
    l_chip=gpiochip1 chris@lepotato:~$ sudo gpioget $l_chip 5 1 chris@lepotato:~$ sudo gpioset $l_chip 5=0 chris@lepotato:~$ sudo gpioget $l_chip 5 1  
    I think these tools are broken.
     

    EDIT2: Okay, I think I figured this out thanks to Neil's spreadsheet up there. I noticed pin 3 is GPIOAO_5 and gpiochip0 is called AOBUS in /sys/class/gpio:
    chris@lepotato:~$ ls -l /sys/class/gpio/ total 0 --w------- 1 root root 4096 Jan 1 1970 export lrwxrwxrwx 1 root root 0 Jan 1 1970 gpiochip0 -> ../../devices/platform/soc/c8100000.aobus/c8100000.aobus:pinctrl@14/gpio/gpiochip0 lrwxrwxrwx 1 root root 0 Jan 1 1970 gpiochip10 -> ../../devices/platform/soc/c8834000.periphs/c8834000.periphs:pinctrl@4b0/gpio/gpiochip10 --w------- 1 root root 4096 Jan 1 1970 unexport  
    So I tried switching my gpioset to use gpiochip0 and turning pin 5 off turned this off. I think I can work with this now. Thanks to Neil for providing that spreadsheet, that info seems good. 
     
    Now trying to figure out how to control the pins on GPIOX on that spreadsheet. They don't map to the other chip from what I can tell.
     
    EDIT3: Just going to keep updating this post for my notes in case it's helpful to anyone, and if anyone has any suggestions they can chime in.
     
    I might have found my crash. I was doing a read loop on the pins of chip1, and apparently reading pin 53 triggers the filesystem to go read-only and everything goes bonkers with I/O errors after that, requiring pulling the power.
     
    chris@lepotato:~$ for i in {30..60}; do printf "$i: "; sudo gpioget $l_chip2 $i; done 30: 0 31: 0 32: 0 33: 0 34: 0 35: gpioget: error reading GPIO values: Device or resource busy 36: 0 37: 0 38: 0 39: 0 40: 0 41: 0 42: 1 43: 1 44: 0 45: 1 46: 1 47: 1 48: gpioget: error reading GPIO values: Device or resource busy 49: 1 50: 1 51: 1 52: 1 53: sudo: unable to write to /var/lib/sudo/ts/chris: Read-only file system 1 54: sudo: unable to open /var/lib/sudo/ts/chris: Read-only file system  
    Eh, maybe not. I don't think the reads triggered it specifically, I tried reading those pins again after reboot and it was fine. This time, I triggered some kind of I/O issue up near pin 80? It finished the loop up to 80 and then wouldn't take any more input from my ssh session. Network completely shut off at that point, another hard reboot and I can't trigger the condition again manually. Weird.
     
    EDIT: Merging the info from Tido and Neil, I think I have it now. I'll try to make a new spreadsheet (yeah I know, another?) mapping the pins to libgpiod commands.
     
    Basically, I realized Tido's info was shifted by 10 from what was in gpioinfo. IE, 7J1 Pin8 is listed as gpio-101, but in gpioinfo it's 91. Thanks to both of y'all for this info. This is what I was looking for.
     
    And sorry for the super long multi-edits. I don't know what this forum's etiquette for that kind of thing is.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines