• Content Count

  • Joined

  • Last visited

About barish

  • Rank

Recent Profile Visitors

305 profile views
  1. barish

    I2C busses changed with update?

    This is indeed the case. Thanks for this information, the change must have crept in lately. If I had the energy I could find out which of the i2c adapters on the Olinuxino were labeled as "hdmi", but right now, since I don't need to know, I won't...
  2. I did the following upgrades this morning libcurl3:armhf (7.52.1-5+deb9u8, 7.52.1-5+deb9u9), libgd3:armhf (2.2.4-2+deb9u3, 2.2.4-2+deb9u4), armbian-config:armhf (5.72, 5.74), linux-headers-next-sunxi:armhf (5.70, 5.73), linux-image-next-sunxi:armhf (5.70, 5.73), curl:armhf (7.52.1-5+deb9u8, 7.52.1-5+deb9u9), libcurl3-gnutls:armhf (7.52.1-5+deb9u8, 7.52.1-5+deb9u9), linux-dtb-next-sunxi:armhf (5.70, 5.73), base-files:armhf (9.9+deb9u6, 9.9+deb9u7) and found my I2C bus not working anymore. I did a scan on the 4 buses (Olinuxino Micro A20) and found a device on i2c-1 instead of i2c-0, changed my settings and all worked again, so I guess one of the updates must have changed the labeling of the busses? Is this by accident or on purpuse?
  3. Ok, I get the RUN instad of PROGRAM part, but where's $DEVPATH set? This variable is nonexistent/empty on my system.
  4. Hi @lagerschaden, you're right, for each user of a specific machine, it's easy to find out. But I was thinking about a more general udev rule that could be integrated into Armbian. In that case, the path would need to be set correctly for each board and kernel or whatever the path depends on.
  5. @lagerschaden, I did the same with my Olinuxino Micro A20, and had to change one path in the udev rule: SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c '\ chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio;\ chown -R root:gpio /sys/devices/platform/soc@01c00000/1c20800.pinctrl/gpiochip0/gpio && chmod -R 770 /sys/devices/platform/soc@01c00000/1c20800.pinctrl/gpiochip0/gpio;\ '" This seems to work well, I tested with GPIO pins 1, 2, 3 and 112, 114, 116, 118. As a pure user of GPIO (and not really a programmer) I've no idea on what the path name depends, why it's sunxi-pinctrl in your case and soc@01c20800.pinctrl/gpiochip0 in my case (I am using mainline kernel).
  6. So would it do any harm, if by default a udev rule is added to armbian which creates a group "gpio" and allows access to /sys/class/gpio to this group? It would save me some work, and other users of openHAB , which by default adds the user "openhab" to group "gpio" (if it exists), would have a working service out of the box.
  7. barish

    safe GPIO access (no root)

    Thanks, @tkaiser, of course I hadn't, it's exactly what I was talking about. I will move over to that thread then.
  8. Hi there, I noticed that current Raspbian distributions use an extra group called "gpio" for /dev/sys/gpio access. Somewhere I read that this coud be accomplished via udev but I also read that /sys is not affected by udev (only /dev). Anyhow, what can I do to permanently set gpio permissions to a group e.g. "gpio"? Would it be of general interest to include this in Armbian?
  9. I found out now that on GPIO port 3, the PH0 works when addressed as GPIO224. Could it be that the LCD is activated by default and thus PGxxx are not working? If so, how could I deactivate LCD? Thanks for any help.
  10. Could this be due to configuration differences between Olinuxino A20 Lime and A20 Micro?
  11. Hi there, I've been trying for a few hours now to get the GPIOs working with the mainline kernel (ARMBIAN Debian GNU/Linux 8 (jessie) 4.5.2-sunxi). According to the board layout photo, I am using PG0, PG1, PG2 and PG3. With the legacy kernel, they export as GPIO1-PG0 a.s.o. accordingly and work perfectly. So I calculate the GPIO pin number: G is 7th letter, 7 - 1 is 6, 6 * 32 is 192. GPIO192 exports fine, I can set it to output, change the value to 1 but there's no voltage! Can anyone help me, please?
  12. Sorry for not testing for so much time, it was quite a bad situation with the Olinuxino at work all the time. But I have good news: I just downloaded the latest Jessie-image, and the problem seems to be solved, I can boot with attached SATA drive without any issues. Thanks a lot for the ongoing development!
  13. I'm sorry, I double checked, but this is what I did: I opened boot.cmd with nano and changed (in the setenv bootargs line) console=tty1 to console=ttyS0 and loglevel=1 to loglevel=7, saved the changes, then I entered "mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr" resulting in: Image Name: Created: Thu Jan 1 10:01:13 2015 Image Type: ARM Linux Script (uncompressed) Data Size: 1911 Bytes = 1.87 kB = 0.00 MB Load Address: 00000000 Entry Point: 00000000 Contents: Image 0: 1903 Bytes = 1.86 kB = 0.00 MB and did a reboot.
  14. Ok, I finally connected with UART, and there I get a login. Only ethernet doesn't work. The console output during boot: U-Boot SPL 2015.07-armbian-sun7i (Oct 11 2015 - 17:51:25) DRAM: 1024 MiB CPU: 912000000Hz, AXI/AHB/APB: 3/2/2 U-Boot 2015.07-armbian-sun7i (Oct 11 2015 - 17:51:25 +0200) Allwinner Technology CPU: Allwinner A20 (SUN7I) I2C: ready DRAM: 1 GiB MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 *** Warning - bad CRC, using default environment Setting up a 1024x768 vga console Error: no valid bmp image at 66000000 In: serial Out: vga Err: vga SCSI: SUNXI SCSI INIT Target spinup took 0 ms. AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode flags: ncq stag pm led clo only pmp pio slum part ccc apst Net: eth0: ethernet@01c50000 starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: USB EHCI 1.00 USB3: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found Hit any key to stop autoboot: 2 1 0 6944 bytes read in 162 ms (41 KiB/s) switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 1973 bytes read in 201 ms (8.8 KiB/s) ## Executing script at 43100000 0 bytes read in 121 ms (0 Bytes/s) 27924 bytes read in 343 ms (79.1 KiB/s) 5535136 bytes read in 607 ms (8.7 MiB/s) Kernel image @ 0x46000000 [ 0x000000 - 0x5475a0 ] ## Flattened Device Tree blob at 49000000 Booting using the fdt blob at 0x49000000 Using Device Tree in place at 49000000, end 49009d13 Starting kernel ... Uncompressing Linux... done, booting the kernel. Does this help? Is there an easier way to make the SD card working again (with ethernet) then to restore the whole /boot from the image? Via the UART connection?
  15. Thanks for quick reply. The power is fine. I've been running the board with Olimex kernel and SATA system drive for more than half a year now (I've had problems with corrupted storage though so I want to try out a different kernel). Your image on the SD card is working fine as long as I don't boot with connected SATA drive. I am not sure if I can plug in the SATA on a running board, I believe I shouldn't? This would be another approach though. I have now put the original /boot content onto the SD card and could boot with this again. So I have access to all the logs, maybe you have an idea where to look? The onboard LED (green) came on normally, so I think the boot process at least started (but didn't arrive at ssh-deamon start?) BTW, on the SATA HDD, there's a complete debian wheezy installed, but this shouldn't affect the boot process, should it? I ordered a UART-USB interface yesterday, but haven't got it yet, so I have no serial access so far. If I find time I can pull out the board and try to connect it to a screen/keyboard, but at the moment I only have remote access.