David Van Cleef

Members
  • Content Count

    17
  • Joined

  • Last visited

About David Van Cleef

  • Rank
    Member

Recent Profile Visitors

745 profile views
  1. I need to hook up a console before I can try that. Maybe this weekend.
  2. Like most people that have consumer ipv6 service, I have NATted ipv4 + global ipv6. I'm trying to get my v4 to be a static address and my v6 to be slaac with privext 2. However if I try to set this, I end up with the ipv6 configuration not enabled. As a workaround, I've set both v4 + v6 static, but would really like to get slaac working, as my global /64 has not changed to date but is not guaranteed to remain the same. This works: iface wlan0 inet static address 192.168.0.100 netmask 255.255.255.0 gateway 192.168.0.1 wpa-ssid my-essid wpa-psk <my-hash-here> iface wlan0 inet6 static address 240x:xx:yy:zz:dead:beef:cafe:babe netmask 64 gateway fe80::aa:bbff:fecc:dd privext 2 This does not: iface wlan0 inet static address 192.168.0.100 netmask 255.255.255.0 gateway 192.168.0.1 wpa-ssid my-essid wpa-psk <my-hash-here> iface wlan0 inet6 auto privext 2 (Its not an inherent problem with ipv6 slaac, an ipv6-only slaac configuration works)
  3. Its had a history of corrupting data that predates that too. Earlier versions of the xfs fsck-equivalent would take anything that looked like inode information regardless of position in the filesystem and would happily "repair" data inside of disk images, etc.
  4. If something happens (physical damage, difference in chemistry) to one of the cells to change its internal resistance to different than the other, the TP4056 chip can end up overcharging one of the cells in the pair (since its reading information from the combination of the cells), and its not unknown for a lithium cell to react rather violently when this happens. One TP4056 per cell if you want to play it safe. At the very least charge at no more than 1C of a single cell of the pair.
  5. You really shouldn't do that. Unless you really want to risk burning your house down.
  6. Just a note, received mine today, along with some ws2812b bars I'd been meaning to order from china anyhow. Packaging was identical to one from Xunlong.
  7. Armbian is not a distro as such. Its unmodified Debian/Ubuntu for the most part. The value-add is in the compilation system and the collection of kernel patches.
  8. At the moment I'm just using exec nodes to manipulate GPIO at shell level. A 5-month-old in the house doesn't leave me with a huge amount of free time these days. I looked at the raspi-gpio stuff at one point but didn't get beyond fixing the raspian-dependent install stuff.
  9. Update to Jessie, its pretty much out of box after that. Don't use the nodejs package from armbian, use the one from nodejs's own repo. Debian/armbian version is too old to deal with current stuff.
  10. Just to confirm the behaviour in previous 3.4 kernels and properly correct the sunxi wiki. Incorrect/incomplete documentation is very frustrating and we should attempt to fix it if at all possible.
  11. Well, it was disabled by default, but when I found the gpio class not working according to the documents I went looking for alternate access methods and then returned to revisit the export interface after I was sure that I didn't have a wiring or hardware problem. I have some more sd cards arriving soon, once they're here I'll check if loboris kernels exhibit the same behavior.
  12. Worked it out, the gpio_sunxi module had control of things. After rmmod-ing it everything started working exporting pin 110. The information on the sunxi-linux wiki about what number is passed to the export is incorrect for the armbian legacy kernel.
  13. The Python and the WiringOP C libraries work fine, as does the gpio_sw sys class. I'm using the 3.4 kernel.
  14. I had already tried that. # echo "110" >/sys/class/gpio/export bash: echo: write error: Device or resource busy
  15. I've started playing around with gpio, and thus far I don't have problems with any of the following: Access via the WiringOP C or Python bindings Access via /sys/class/gpio_sw However I can't seem to get the access via /sys/class/gpio to work. According to http://linux-sunxi.org/GPIOI need to write the pin number as defined in the fex file to /sys/class/gpio/export for 3.4 kernel (mainline kernel codes the pin number). For WiringOP pin #1 (physical pin #12 on the header), this is PD14, which is gpio_pin_5 according to the fex file, however the following does not light an LED connected to the pin: # echo "5" >/sys/class/gpio/export # echo "out" >/sys/class/gpio/gpio5/direction # echo "1" > /sys/class/gpio/gpio5/value