Jump to content

PaddleStroke

Members
  • Posts

    70
  • Joined

  • Last visited

Everything posted by PaddleStroke

  1. Thanks! I went with chmod a+s /usr/bin/python And it's working now! Thanks again for your support. I think I should make a proper gamepad kernel module rather than this python script. For reference, the python script is launched as a service in systemd. By the way I made a video on the hardware part of prototyping, maybe it will interest some people
  2. Thanks! I can now read the values of the LRADC. Now I have only one issue left is that my python script does not have permission to read /dev/mem when it's started automatically at launch. I had the same permission issue when trying to read AXP209 ADC, which we solved by using a .rule file in etc/udev/rules. I tried to add one line for /dev/mem but I think I'm missing something here. ACTION=="add", SUBSYSTEM=="iio", RUN+="/bin/chmod g+w /sys/bus/iio/devices/iio:device0/in_voltage3_scale" ACTION=="add", SUBSYSTEM=="iio", RUN+="/bin/chmod g+w /sys/bus/iio/devices/iio:device0/in_voltage4_scale" ACTION=="add", SUBSYSTEM=="iio", RUN+="/bin/chmod g+w /sys/bus/iio/devices/iio:device0/in_voltage3_raw" ACTION=="add", SUBSYSTEM=="iio", RUN+="/bin/chmod g+w /sys/bus/iio/devices/iio:device0/in_voltage4_raw" ACTION=="add", RUN+="/bin/chmod g+w /dev/mem" I also tried : sudo chmod 777 /dev/men and sudo usermod -g kmem pi Then I have a different error "[Errno1] Operation not permitted: '/dev/mem' The working python script for reference : #!/usr/bin/env python from time import sleep import os, sys, mmap DZONE2 = 6 # dead zone applied to joystick (mV) VREF2 = 40 # max value read when moving joystick to max. JOYOFFVAL2 = 60 # Value reads 63 when not working #LRADC base register address = 0x01C22800 (cf A20 manual page 193) MAP_MASK = mmap.PAGESIZE -1 addr = 0x01C22800 fd = os.open("/dev/mem", os.O_RDWR | os.O_SYNC) mem = mmap.mmap(fd, mmap.PAGESIZE, mmap.MAP_SHARED, offset= addr & ~MAP_MASK) os.close(fd) #using mem.write_byte to write the 4 bytes of the control register one by one does not work. read_byte one by one also do not work. You need to read the 4 at once. So the following does not work : #mem.seek(addr & MAP_MASK) #mem.write_byte(chr(int('01111001', 2))) #mem.write_byte(chr(int('00100000', 2))) #mem.write_byte(chr(int('11000000', 2))) #mem.write_byte(chr(int('00000001', 2))) #The correct way to do it is to add the 4 bytes together as follow : mem.seek(addr & MAP_MASK) byte_data = [121, 32, 192, 1] mem.write("".join(map(chr, byte_data))) #121 = 0111 1001 is for bit 7 to 0 of the first byte (0x01C22800). Bit 6 and 5 '11' are for reference voltage to use, here 11 = 1.6V. Bit 0 is to activate the LRADC. #32 = 0010 0000 is for bit 7 to 0 of the 2nd byte (0x01C22801). Bit 13 and 12 '10' are for continuous mode. #192 = 1100 0000 is for bit 7 to 0 of the 3rd byte (0x01C22802). Bit 23 and 22 '11' are to enable both LRADC0 and LRADC1. #1 = 0000 0001 is default value. mem.seek(addr & MAP_MASK) print("bytes") ciuy = mem.read(4) print(' '.join(format(ord(x), 'b') for x in ciuy)) while True: mem.seek((0x01C2280C)& MAP_MASK) # register offset for LRADC0 = 0x0C joystick2_UD = ord(mem.read_byte()) #should be between 0 and 63 (6 bits) mem.seek((0x01C22810)& MAP_MASK) # register offset for LRADC1 = 0x10 joystick2_LR = ord(mem.read_byte()) #should be between 0 and 63 (6 bits) if (joystick2_LR > (VREF2/2 + DZONE2)) or (joystick2_LR < (VREF2/2 - DZONE2)): #print(' '.join(format(ord(x), 'b') for x in joystick2_LR)) print("Right Joystick LR : ", joystick2_LR) if (joystick2_UD > (VREF2/2 + DZONE2)) or (joystick2_UD < (VREF2/2 - DZONE2)): #print(' '.join(format(ord(x), 'b') for x in joystick2_UD)) print("Right Joystick UD : ", joystick2_UD) sleep(.2) mem.close()
  3. Could you please tell me how to do this? I don't know what is the control register nor how to initialize it.
  4. Hi! Thanks for your reply ! I had to put that on hold for some time, but I'm back on it. After checking the A20 user manual I find that the offset for LRADC1 is 0x10 and not 0x0D. So I guess you meant 0x01C22810 for LRADC1? So I should be doing something like : fd = open("/dev/mem", "r+") mem = mmap.mmap(fd.fileno(), 16, 0x01C22800 ) close(fd) while(we need to get the values): mem.seek(0x0C) LRADC0_byte = mem.read(1) mem.seek(0x10) LRADC1_byte = mem.read(1) //further process the values mem.close() Does that sounds correct to you?
  5. Hey guys, I'm trying to find a way to read the values of the LRADC0 and LRADC1 of the A20. Those ADC are usually used for android-style buttons (labeled "VOL+", "VOL-", "MENU", "SEARCH", "HOME", "ESC" and "ENTER") which are connected to a low-resolution ADC via a resistor network. But I want to use the ADC for another purpose and I just need to read values between 0 and 63. Now it seems there is already a driver which let you setup the android-style buttons in the DTS (as can be seen in this patch) But I can't find the code of this driver, which I could use as a template. Any idea how to find the driver ? Or on how to read the LRADC values from a python script directly? Thanks! Related, for reference : https://www.olimex.com/forum/index.php?topic=4281.0 https://www.olimex.com/forum/index.php?topic=2425.0 Edit: I think I found the driver : https://github.com/torvalds/linux/blob/master/drivers/input/keyboard/sun4i-lradc-keys.c To be continued.
  6. Finally it works as expected. I changed the GPIO to PC18 (which was high by default when I probed it before changing it in dts) First I tried to make modifications to match torvalds DTS with the PI12 CLK settings. But it wasn't working. In the end I just tried reset to megous settings, just changing the port to PC18 and it works. So it seems something is forcing PE1 to low.
  7. Yes if the Enable pin is connected to 3v3 directly. The issue is that the PE1 to which enable pin is connected never go high. I suspect it's because the clock is not set but I'm not sure
  8. No I did not have the clock in previous success. I think maybe because CLK is not connected the reset hang forever maybe? I think the clk is used by wifi too. The supplier of AP6210 told me so.
  9. Ok if I recall correctly armbian use the megous fork of torvals right? If so there are lot of difference in cubietruck DTS. It does not look right : Megous fork : mmc3_pwrseq: mmc3_pwrseq { compatible = "mmc-pwrseq-simple"; pinctrl-names = "default"; pinctrl-0 = <&mmc3_pwrseq_pin_cubietruck>; reset-gpios = <&pio 7 9 GPIO_ACTIVE_LOW>; /* PH9 WIFI_EN */ }; &pio { ... mmc3_pwrseq_pin_cubietruck: mmc3_pwrseq_pin@0 { pins = "PH9"; function = "gpio_out"; }; ... Torvalds github : mmc3_pwrseq: mmc3_pwrseq { compatible = "mmc-pwrseq-simple"; reset-gpios = <&pio 7 9 GPIO_ACTIVE_LOW>; /* PH9 WIFI_EN */ clocks = <&ccu CLK_OUT_A>; clock-names = "ext_clock"; }; &pio { /* Pin outputs low power clock for WiFi and BT */ pinctrl-0 = <&clk_out_a_pin>; pinctrl-names = "default"; }; Torvalds github A20 DTSI : pio: pinctrl@1c20800 { ... /omit-if-no-ref/ clk_out_a_pin: clk-out-a-pin { pins = "PI12"; function = "clk_out_a"; }; ... Why megous fork don't mention the PI12 external clock...? Now the Torvalds github also seem to have a problem. Why he makes &pio modifications like this? It should not be more like this? : &pio { clk_out_a_pin: clk-out-a-pin { pins = "PI12"; function = "clk_out_a"; } Or not &pio and something else... But doing as it's done in cubietruck dts it seems wrong. What do you think?
  10. I don't understand what is this "mmc-pwrseq-simple" I read this but still don't understand... The WL_REG_ON is not a reset pin. It seems it's just a Enable pin. So it should just be high. I tried changing the GPIO assigned to PC18. Before doing so I checked multimeter said 3.3V, this pin was high by default. Now after reboot the pin goes low right after booting kernel and stays low. If I understand correctly this : compatible = "mmc-pwrseq-simple"; reset-gpios = <&pio 7 9 GPIO_ACTIVE_LOW>; /* PH9 WIFI_EN */ Will asserted (means activate right?) the GPIO PH9 to low before powering up the MMC. Then after boot it should be deactivated. Does it means it will go back to default or that it will go back to the countrary of GPIO_ACTIVE_LOW so high? If so in my case it does not go back to high. Does it means the card is not confirmed powered ON by the SoC?
  11. I hand soldered PE1 to WIFI_EN. I wondered if I have not burned something on AP6210 side because it was really hard to solder a wire to the AP6210 pin. But because the wifi can be hand-booted by connecting a wire between 3v3 and WIFI_EN I guess the enable pin still work. On the SoC side I don't think it could have burned because it's far from SoC and trace is very small (0.127mm), so very little heat should have gone up. So overall I don't think anything burnt I wonder maybe if the PE1 is maybe setup by default to do something else. Maybe it's use is overwriten by something else? I will try to replace this PE1 by another port. PH17 maybe. About why it's low I have no clue... The DTS of cubietruck say: mmc3_pwrseq: mmc3_pwrseq { compatible = "mmc-pwrseq-simple"; pinctrl-names = "default"; pinctrl-0 = <&mmc3_pwrseq_pin_cubietruck>; reset-gpios = <&pio 7 9 GPIO_ACTIVE_LOW>; /* PH9 WIFI_EN */ }; Why GPIO_ACTIVE_LOW ? It's normal for a reset-GPIO? Btw is this the correct way to edit a dtb? Prefer double checking ! cd /boot/dtb sudo dtc -I dtb -O dts -o sun7i-a20-cubietruck.dts sun7i-a20-cubietruck.dtb // DTB to DTS nano sun7i-a20-cubietruck.dts //edit DTS sudo dtc -I dts -O dtb -o sun7i-a20-cubietruck.dtb sun7i-a20-cubietruck.dts //DTS to DTB
  12. I hand connected a wire from 3v3 to wifi_en Do you know where I can find a table of the GPIO number? Alternatively do you think problem could be in uboot ? Maybe we have not patched correctly uboot dts Or maybe it's the E gpio the problem? Maybe they are used by something else? Or maybe some hardware issue ?
  13. Ok I could get the wifi working by wiring manually the WIFI_EN pin directly to 3V3. Apparantly the PE1 was not turning on and always kept at 0V (reading from multimeter). Not sure why. Now iwconfig show the card in wlan0. I think maybe the wifi is just off by default when booting up? Then we have to enable it manually with a command? Do you know if a command enable/disable wifi?
  14. grep SDIO and BRCM don't return anything either. MMC return something though (see enclosed picture). It looks like an error what do you think? 1c12000 is the mmc3 1c0f0000 is the mmc0 (sd card) sunxi-mmc 1c12000.mmc: Linked as a consumer to regulator.2 sunxi-mmc 1c12000.mmc: Dropping the link to regulator.2 sunxi-mmc 1c12000.mmc: Linked as a consumer to regulator.2 sunxi-mmc 1c12000.mmc: Dropping the link to regulator.2 sunxi-mmc 1c12000.mmc: Linked as a consumer to regulator.2 sunxi-mmc 1c12000.mmc: Dropping the link to regulator.2 sunxi-mmc 1c12000.mmc: allocated mmc-pwrseq sunxi-mmc 1c12000.mmc: initialized, max. request size: 16384KB looks like it's trying several time something without success? About the GPIO enable, there is indeed one. On cubietruck it's PH9 and on our board it's PE1. So we modified the dts accordingly but it doesn't seem to help. About the clock we use the cubietruck image with modified DTS just to enable the PE1 instead of PH9. So the clock (PI12) should be setup correctly as schematic match. A20_Cubietruck_HW_V10_130606.pdf
  15. on my board I have not set the USB_DRV GPIO for any USB, they are always ON (enable pin of sy6280 pull up to 5V). Also ID_detect is not connected either as I'm not using OTG. So none of these are connected : &reg_usb0_vbus { gpio = <&pio 2 17 GPIO_ACTIVE_HIGH>; &usbphy { usb0_id_det-gpios = <&pio 7 4 (GPIO_ACTIVE_HIGH | GPIO_PULL_UP)>; /* PH4 */ usb0_vbus_det-gpios = <&pio 7 5 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>; /* PH5 */ Not sure if they should be removed from the DTS? Also are you sure it's PA17? Because it's writen '&pio 2 17' I thought the first number was reference to the letter, like A = 0 B = 1 ... H = 7. Do you know how those numbers 2 and 17 are used if not by letter-number index?
  16. Tried and still NOK. I have message in dmesg musb-hdrc musb-hdrc.1.1auto: vbus_error in a_wait_vrise (80, <sessEnd>, retry #3, port1 0008010c
  17. Hi! Using mainline on custom A20 board with sch very close to lime2, with 2 differences: (- EMAC of lime instead of GMAC of lime2) - AP6210 wifi/bt module on MMC3 with same schematic as cubietruck. Only difference in AP6210 schematic is that : - we use PE1 for WIFI_Enable instead of PH9. - PE0 for wifi_host_wake instead of PH10. BT works OK. Wifi doesn't work. To test the wifi part, we used cubietruck DTS, only patching the parts about PH9 and PH10. BRCMFMAC load without any messages and iwconfig / ifcongif say there is no wireless card. "dmesg | grep brcmfmac" gives no results. nor "dmesg | grep ap6210". lsmod list brcmlmac and brcmutil as loaded. Tried rmmod and modprobe again but nothing happens. After seeing this patch : https://github.com/armbian/build/blob/master/patch/kernel/sunxi-dev/ARM-dts-sun7i-Disable-OOB-IRQ-for-brcm-wifi-on-Cubietruck-and-Banana-Pro.patch?fbclid=IwAR2ySqUILAuBSjIoag8lAmnXWwsZbrAMFpfEOpA9J5YEtAbSUQtFhqnBRAQ I tried removing those 3 lines again by d /boot/dtb sudo dtc -I dtb -O dts -o sun7i-a20-cubietruck.dts sun7i-a20-cubietruck.dtb nano sun7i-a20-cubietruck.dts removed the 3 lines, then sudo dtc -I dts -O dtb -o sun7i-a20-cubietruck.dtb sun7i-a20-cubietruck.dts But still the same Any ideas ?
  18. I made a custom A20 board of which sch is very close to lime2 for a project (retrostone2) and I can't use USB0 as a classic USB port. The three USB (0 1 2) are all connected to regular USB type A connectors. No OTG used. However I can't get the USB0 to work. USB1 and USB2 works without issue. But USB0 will not recognize keyboard/any peripheral. I think it's probably because of OTG detect pins. I looked at the DTS, but I am having trouble understanding how OTG is emplemented there, how to unactivate it and just activate a classic USB port. Any ideas?
  19. If you're using mainline kernel the HDMI audio is not supported on A20.
  20. Hey guys, I see the HDMI audio is not supported in the status matrix. Do you know what is missing exactly? I read it predepends on DRM driver, do you know which part is missing? I read in #linux-sunxi IRC history that there are some patches for HDMI audio for H3 H6 H64. What about A20 ? Is there any patches available?
  21. Regarding the uboot error I discussed before. Actually the kernel driver is doing exactly the same thing : https://github.com/torvalds/linux/blob/master/drivers/mfd/axp20x.c static void axp20x_power_off(void) { if (axp20x_pm_power_off->variant == AXP288_ID) return; regmap_write(axp20x_pm_power_off->regmap, AXP20X_OFF_CTRL, AXP20X_OFF); /* Give capacitors etc. time to drain to avoid kernel panic msg. */ msleep(500); } AXP20X_OFF = bit(7) So it does the same thing. On shutdown it writes bit(7) on reg32. The problem is when you boot after on PEK press, the AXP regs are not reset. So the reg32 is not set back to default value but keep instead bit(7). Which makes that battery detection is disabled. Should be replaced by static void axp20x_power_off(void) { if (axp20x_pm_power_off->variant == AXP288_ID) return; regmap_update_bits(axp20x_pm_power_off->regmap, AXP20X_OFF_CTRL, AXP20X_OFF, AXP20X_OFF); /* Give capacitors etc. time to drain to avoid kernel panic msg. */ msleep(500); } What do you think?
  22. I tried to write to u-boot-patches@bugs.denx.de but got a automatic reply saying address is NOK.
  23. Yes you are right. I'll finish to understand everything before adding anything though. Btw do you know how to make a bug report to u-boot?
  24. Also the uboot driver has a problem I think : int do_poweroff(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) { pmic_bus_write(AXP209_SHUTDOWN, AXP209_POWEROFF); /* infinite loop during shutdown */ while (1) {} /* not reached */ return 0; } #define AXP209_POWEROFF BIT(7) AXP209_SHUTDOWN = 0x32 So actually on every power off, uboot write BIT(7) to REG 32. Now I understand why at boot the kernel AXP20x driver triggers to set battery detection ON as it's also on REG32. It does not use mask to write only bit 7, so I guess it writes 1000 0000 to the REG... I think it should use "pmic_bus_setbits" instead of "pmic_bus_write" what do you think? If someone can confirm this.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines