Re: [beagleboard] Cranky BBB

[rattus]

Therein lies the rub. In order to delete the 
/etc/dropbear/dropbear_rsa_host_key file, I first need to log in. Going in 
through the Cloud9 console, I can only access things in the cloud9 tree. 
Cannot telnet or ssh in to the BBB via either USB or Ethernet interfaces. 
How do I get in?

On Friday, December 20, 2013 5:56:14 AM UTC-7, Gerald wrote:
>
>
> http://www.elinux.org/Beagleboard:BeagleBone_Black_FAQ#Cloud9.2C_GateOne_SSH.2C_Bonescript.2C_.26_C.2FC.2B.2B
>
> Gerald
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [beagleboard] Cranky BBB

[rattus]

Sadly, I don't have the appropriate cable.

I've tried telnet, ssh, and Cloud9 console via both USB or Ethernet, no go. 
I get the startup Web page and Cloud9 just fine. This is one of the latest 
batch (like last week?): BeagleBone Black rev 00A6 S/N 4713BBBK2106

Is perhaps my only option to burn an SD card, but then again, would that 
image be any different than that which is loaded into the EMMC? BTW, I'm on 
either a Mac or Linux host.

There's got to be a way in!

On Friday, December 20, 2013 9:07:03 AM UTC-7, Gerald wrote:
>
> Can you go in through the serial debug port?
>
> Gerald
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[beagleboard] Userspace RAM access

[rattus]

Hi - I'm looking for a way to address files in RAM only in order to 
minimize eMMC writes; there will be a lot of manipulation of contents that 
I'd like to keep away from nonvolatile storage, and then would like to save 
in full block writes if possible.

Sorry to noob this, but is there a way to ensure RAM access via /dev/xxx?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[beagleboard] Re: can no longer connect via os x

[rattus]

Is it possible that your router reassigned the DHCP address?

If so, you might access the router and see what's assigned, on my Linksys 
router the table is under Status->Local Network->DHCP Clients table; my BBB 
running Debian shows up as 'arm'. I'm assuming you're not running the 
default Angstrom with the hosed dropbear issue as you've been able to ssh 
in the past. DAMHIK ;-)

On Thursday, January 9, 2014 12:24:47 AM UTC-7, Chuck Benson wrote:
>
> Initially I was able to connect via OS X -- could launch the start page 
> from the mounted BBB, able to install drives, able to connect to 
> 192.168.7.2, and also ssh to the BBB. However, on subsequent use, I can no 
> longer connect. The board will mount and I can see the files in the Finder, 
> but the start.htm page won't render & it does not show in the Terminal 
> window (no response to ping or nmap). The board LED's appear to be behaving.
>
> Suggestions?
>
> Thanks
> Chuck
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [beagleboard] Userspace RAM access

[rattus]

Thanks, Jack. Where is this documented so that I don't have to bother the 
board next time?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[beagleboard] BBB wifi lockup

[rattus]

I'm having an issue with my USB wifi adapter, in that if there is no 
activity in an SSH session for a while (i'm guessing for an hour or so), 
the board locks up, becomes unresponsive even to ethernet requests, etc. 
and must be rebooted. If I maintain activity on the link (running top, for 
example) everything runs fine. 
I am running Debian Wheezy from the eMMC and am using an Edimax 7811 wifi 
adapter. iwconfig tells me power management is off.
I have run a watch on dmesg to see if any messages are being output before 
lockup - there are none.
Any ideas?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [beagleboard] BBB wifi lockup

[rattus]

On Sunday, January 26, 2014 8:36:29 PM UTC-7, Nuno wrote:

> On 01/26/2014 04:04 PM, rattus wrote: 
> > I am running Debian Wheezy from the eMMC and am using an Edimax 7811 
> wifi 
> > adapter. iwconfig tells me power management is off. 
>
> https://github.com/xbianonpi/xbian/issues/217 
>
> I have this (both rpi and bbb boards): 
>
> ~$ cat /etc/modprobe.d/8192cu.conf 
> # disable power management and usb auto-suspend for wireless card: 
> # https://github.com/xbianonpi/xbian/issues/217 
> options 8192cu rtw_power_mgnt=0 rtw_enusbss=0 
> # cat /sys/module/8192cu/parameters/rtw_power_mgnt 
>
> regards, 
> Nuno 
>
> -- 
> http://aeminium.org/nuno/ 
>

That didn't work for me, but the saga continues: (I'm now testing the 
Debian 2014.1.29 image)

with the following steps:

1) Using the wpa-supplicant daemon
2) turning wireless-power off (this seems to work only when I use 
wpa-supplicant)
3) pinging my router once a minute

I still lose ssh-ability after a few hours of inactivity.

I did notice this when monitoring dmesg:
...

[ 1686.041730] wlan0: deauthenticated from 00:21:29:f0:a1:b0 (Reason: 6)

[ 1686.054252] cfg80211: Calling CRDA to update world regulatory domain

[ 1686.994733] wlan0: authenticate with 00:21:29:f0:a1:b0

[ 1687.001558] wlan0: send auth to 00:21:29:f0:a1:b0 (try 1/3)

[ 1687.004305] wlan0: authenticated

[ 1687.006006] wlan0: associate with 00:21:29:f0:a1:b0 (try 1/3)

[ 1687.015077] wlan0: RX AssocResp from 00:21:29:f0:a1:b0 (capab=0x411 
status=0

aid=6)

[ 1687.016215] wlan0: associated

[ 2202.567679] wlan0: deauthenticated from 00:21:29:f0:a1:b0 (Reason: 6)

[ 2202.578226] cfg80211: Calling CRDA to update world regulatory domain

[ 2203.502671] wlan0: authenticate with 00:21:29:f0:a1:b0

[ 2203.509575] wlan0: send auth to 00:21:29:f0:a1:b0 (try 1/3)

[ 2203.511759] wlan0: authenticated

[ 2203.513860] wlan0: associate with 00:21:29:f0:a1:b0 (try 1/3)

[ 2203.535381] wlan0: RX AssocResp from 00:21:29:f0:a1:b0 (capab=0x411 
status=0

aid=6)

[ 2203.536315] wlan0: associated

...


So it looks like wlan0 is getting de -and- reauthenticated every 10 minutes 
or so. What causes this? 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[beagleboard] Re: SSH connection by wifi

[rattus]

Looks like your wifi IP address is 192.168.2.101. You should be able to ssh 
into there.

As far as the Edimax wifi adapter goes (I have the EW-7811Un) you'll be 
initially successful, but after an hour or so of inactivity, the link will 
die. The entire wlan0 link will die - no ping, no ssh, nothing. I am now 
trying the Netgear WNA1100, but am experiencing the same link lockup. I 
have disabled wifi power off. Same symptoms. I'm running one of Robert 
Nelson's latest Debian Wheezy images (01-29-14). 

I have seen some issues with acpi problems causing kworker daemons to 
multiply, (and my hungriest process is kworker) but haven't figured out a 
way to monitor that without being "live" on the wifi connection, which 
modifies the behavior, much like Schrödinger's Cat problem. Will keep 
plugging away. 

How can one prevent acpi from starting in the first place?

On Friday, February 7, 2014 8:47:45 AM UTC-7, stefanbr...@googlemail.com 
wrote:
>
> Hello there,
>
> I connected my BBB to my wifi with an edimax wireless adapter. This works 
> fine so far, i even got a connection to the internet.
>
> my problem is, I have only access to the BBB by the usb cable. I want so 
> connect by SSH with the Wifi network.
>
> I guess there's probably a problem with the non static ip adress of my 
> router because DHCP is activated.
>
>
> Now I want to connect with Putty to the BBB without an cable connection.
>
> How do i get the Ip adress of the BBB? Is this even possible as i try to 
> do?
>
> maybe this is helpfull
>
> root@beaglebone:~# ifconfig
> eth0  Link encap:Ethernet  HWaddr 90:59:AF:49:E5:F6
>   UP BROADCAST MULTICAST  MTU:1500  Metric:1
>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>   Interrupt:56
>
> loLink encap:Local Loopback
>   inet addr:127.0.0.1  Mask:255.0.0.0
>   inet6 addr: ::1/128 Scope:Host
>   UP LOOPBACK RUNNING  MTU:65536  Metric:1
>   RX packets:64 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:64 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:0
>   RX bytes:4420 (4.3 KiB)  TX bytes:4420 (4.3 KiB)
>
> usb0  Link encap:Ethernet  HWaddr A6:50:E4:64:B4:AE
>   inet addr:192.168.7.2  Bcast:192.168.7.3  Mask:255.255.255.252
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:666 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:180 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:157298 (153.6 KiB)  TX bytes:37885 (36.9 KiB)
>
> wlan0 Link encap:Ethernet  HWaddr 80:1F:02:D7:B4:4F
>   inet addr:192.168.2.101  Bcast:192.168.2.255  Mask:255.255.255.0
>   inet6 addr: fe80::821f:2ff:fed7:b44f/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:668 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:75 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:46175 (45.0 KiB)  TX bytes:12808 (12.5 KiB)
>
> Thank you very much.
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [beagleboard] sleep mode and wake modes..

[rattus]

>
> Robert, do these images support keepalive on network connections? I am 
> running your 1-29-14 image (SD version) and am unable to keep either my 
> Ethernet or wifi connections alive for more than a few hours, despite 
> pinging out once a minute on both ports. I've played with the 
> tcp_keepalive_* and have turned power management off, but stil no joy in 
> what I want to be a reliable headless application. 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [beagleboard] Re: Solved - I now have reliable WiFi on the Bone

[rattus]

Give it a couple of hours - it will die. I've tried it with the Edimax 
EW-7811Un and the Netgear WNA1100 (the biger stick) - same thing.

On Monday, January 27, 2014 6:58:06 AM UTC-7, RobertCNelson wrote:
>
> On Sat, Jan 25, 2014 at 7:06 PM, Harry May > 
> wrote: 
> > Thank you for all the information. 
> > 
> > This is my experience with reliable wifi. This took me 4 days and 4 
> > night(mares): 
> > 
> > I had all kinds of problems. Maybe the most important is that the 
> > Micro-USB-Stick N150 (Netgear) does not work reliably. It was possible 
> to 
> > setup a WiFi connection 
> > but it broke down all the time. 
> > The much more stable hardware is the stick described by Carl Johnson in 
> his 
> > first post (the bigger size netgear stick using the ath9k_htc driver). 
> > 
> > I had no luck with Angstrom, the wifi stick was recognized and a dhcp 
> > request startet, but succeeded only 1 of 10 times. 
> > 
> > So I ended up with Ubuntu saucy: 
> > 
> http://rcn-ee.net/deb/rootfs/saucy/ubuntu-13.10-console-armhf-2014-01-24.tar.xz
>  
> > and the instructions from this site: 
> > http://elinux.org/BeagleBoardUbuntu (Debian or Ubuntu is the same 
> procedure) 
> > 
> > To setup the stick I modified /etc/network/interfaces: 
> > auto wlan0 
> > iface wlan0 inet dhcp 
> > wpa-ssid "MYSSID" 
> > wpa-psk "MYPASSPHRASE" 
> > 
> > and the same for WLAN1  
> > I found out that changing from one stick to another may switch from 
> wlan0 to 
> > wlan1, even if you power off. 
> > 
> > And tested it according: 
> > 
> http://embeddedprogrammer.blogspot.de/2013/01/beaglebone-using-usb-wifi-dongle-to.html
>  
> > as Carl already suggested. 
> > 
> > Everything worked fine, so I removed the LAN cable and rebooted the 
> bone. 
> > 
> > Now comes the important thing: WAIT at least 2 to 3 minutes. 
> > It takes 2:30 minutes until the blue LED on the stick gets lit. 
> > For any reason I don't know: at a later time it booted MUCH faster. 
>

If you have an Ethernet cable connected to the router, it's less than 30 
seconds to a live network connection, either hard-wired or the wifi. I've 
found that without the RJ-45 cable, wifi takes 3 minutes or so to come up - 
waiting for the eth0 to respond? 

>
> ssh keys are generated on first bootup... It takes some time.. 
>

Seems the delay is the same every time, unless eth0 is connected.

Am I the only one that has both wlan(0 for the Edimax, 1 for the Netgear) 
and eth0 die after a few hours? AS I am trying to get a headless server set 
up, it is frustrating...

Mike

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [beagleboard] Re: Wifi hangs during SSH sessions on BBB

[rattus]

I still have the same problem as well (on Debian); mucked with the 
net.ipv4.tcp_* 
parameters, still no joy in keeping either the WiFi or hard Ethernet ports 
alive more than a few hours. This is not just SSH - the ports become 
unresponsive to ping as well. Given my application requires availability, 
this is a problem.

The connections *seemed* to say alive longer when I set up a process to 
ping the router every 5 minutes or so, but still died eventually.

Does anyone have suggestions as to how we might monitor the ports to 
determine the cause of death? I've been netstat'ing, logging and ps'ing 
every way I could imagine, with no clue as to what is causing the problem. 

Guess I could set up a cron job to kill the board every few hours, but that 
seems inelegant ;-)

On Sunday, March 16, 2014 2:05:04 PM UTC-6, Chris Shiplet wrote:
>
> Unfortunately I was never able to resolve this, although I didn't try 
> rebuilding the kernel or anything. I ended up switching to the Raspberry 
> Pi, because while it's a bit slower it seems to be much more stable for 
> longer than a few hours.
>
>
> On Sat, Mar 15, 2014 at 8:11 PM, > wrote:
>
>> I am having basically the same issue, but wired connection with debian... 
>> http://beagleboard.org/project/debian
>>
>> I will have a connection just fine then after several hours it will stop 
>> responding to all network traffic as if it were not there. The LEDs 
>> continue to flash as normal with cpu, heartbeat, etc... It's quite 
>> annoying. I'm not sure if I want to even continue using it if I cannot 
>> create reliable projects.
>>
>>
>> On Saturday, October 26, 2013 6:53:06 PM UTC-4, Chris Shiplet wrote:
>>>
>>> Hi all, I'm running the latest eMMC flasher Angstrom image, kernel 
>>> 3.8.13 on a BeagleBone Black. I'm using a 1A, 5V AC adapter. I also have 
>>> an Edimax EW-7811UN N-wifi dongle, which is apparently rtl8192cu based. I 
>>> installed the driver and added my network info to connman, and it 
>>> successfully fetches an IP from my DHCP server. The dongle lights up when 
>>> authenticated to my WPA network, and I can SSH into it and add/remove 
>>> packages. 
>>>
>>> The problem usually comes when a large stream of text is being sent over 
>>> SSH - ie compiling a large program, installing a package on NPM, or a 
>>> installing lot of packages/dependencies via opkg. The SSH session will 
>>> hang, and eventually time out with Write failed: broken pipe. The board 
>>> will not respond to ping, or any other services running on it, it basically 
>>> drops off the network. However, the light on the dongle remains on.
>>>
>>> If, rather than running one of these commands in the foreground I start 
>>> it with nohup, the process completes fine in the background with no loss of 
>>> connection and I can verify the output with tails. Also, this happens on 
>>> both Ubuntu 13.04 and Angstrom... Although I'm currently back to running 
>>> Angstrom.
>>>
>>> This hasn't happened while plugged into the same router via ethernet, 
>>> only when using the wireless. The board appears to be running fine, the 
>>> heartbeat led continues and there is occasional activity on the cpu/flash 
>>> leds. Won't have an FTDI cable to confirm this until Tuesday, but if this 
>>> is an obvious fix I'd like to take care of it sooner. 
>>>
>>  -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/beagleboard/jZ3d6_yW54s/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> beagleboard...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Long-term kernel choice

[rattus]

I'm working on a project that's due for completion in the next 3-6 months 
on the BBB with multiple instances will stay in the field for approx. 3 
years. We will have low-speed access to the devices, 1G GSM at best, but 
probably not enough to entertain onsite kernel updates during that time.
I am especially interested in solid wifi, USB and SPI implementations.
What say you, BB community - what current or soon-to-be current longterm 
kernel version would you take to your desert island?

Thanks, 

Mike

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Long-term kernel choice

[rattus]

(sorry - originally posted under (old) BeagleBoard by accident)...

I'm working on a project that's due for completion in the next 3-6 months 
on the BBB with multiple instances that will stay in the field for approx. 
3 years. We will have low-speed access to the devices, 1G GSM at best, but 
probably not enough to entertain onsite kernel updates during that time.
I am especially interested in solid wifi, USB and SPI implementations.
What say you, BB community - what current or soon-to-be current longterm 
kernel version would you take to your desert island?

Thanks, 

Mike

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Preserving flashable eMMC image

[rattus]

Hi - I'm making many changes to the contents of my eMMC, and will need to 
clone this to other BBB devices. How would I dump an eMMC-flashable image 
to SD card to be able to produce clones?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] 4.1.0-rc3-bone1.2 trapped in board - no SSH or serial

[rattus]

Hi - my weekend experiment was to build a Debian Jessie with 
4.1.0-rc3-bone1.2 kernel image to play with; sadly, while it appears to be 
running, I have no way to communicate with it. Pings to its IP address are 
responded to promptly, but SSH login attempts are rejected immediately, and 
there is no apparent serial path either.
I checked the SSH entries in /etc/init on the SD image; they appear to be 
set to enable the sshd server. 
Anyone able to coax the beast out of its shell?

Thx, Mike

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] 4.1.0-rc3-bone1.2 trapped in board - no SSH or serial

[rattus]

On Monday, May 18, 2015 at 1:35:06 AM UTC-6, William Hermans wrote:
>
> Did you build using Robert  guide on eewiki ? If so, you probably did not 
> install an ssh server such as openssh-server . . .
> ...
>
>> *Last login: Tue May 12 16:34:45 2015 from 192.168.7.1*
>> *debian@beaglebone:~$ uname -r*
>> *4.1.0-rc3-bone0*
>>
>  
> Slightly older kernel here, but it should be the same. Well actually, I'm 
> running SYSV init daemon, so I suppose that could be systemd giving you 
> "problems". e.g. A systemd service may need to be enabled to get your ssh 
> server running at boot ? Knowing the process you went through to get a 
> working image would be helpful in nailing down what your issue is . . .
>

Yes, I was running Robert's BBB instructions. I agree it's probably a 
systemd startup issue, but haven't been able to find setup instructions 
that merely altered file contents - which I can do while burning the SD - 
rather than using systemctl on a running system. Can't start SSH without 
SSH... although the full openssh-server package seems to have been 
installed in the debian-8.0-minimal... rootfs.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] 4.1.0-rc3-bone1.2 trapped in board - no SSH or serial

[rattus]

There's my question - how does one set up a systemd service to start up 
anything without running systemctl on the system?

On Monday, May 18, 2015 at 1:49:30 AM UTC-6, William Hermans wrote:
>
> *...*
>
>  

> You would possibly also have to either setup a systemd service to start up 
> an agetty or similar connection. or modify /etc/inittab to reflect that 
> change. Which ever works for your use case.
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] 4.1.0-rc3-bone1.2 trapped in board - no SSH or serial

[rattus]

I dropped back to 3.14 in the meantime; ssh is healthy there, as my main 
intent was to mess with kernel modules.

Thanks.

On Monday, May 18, 2015 at 9:36:47 AM UTC-6, RobertCNelson wrote:
>
> On Mon, May 18, 2015 at 10:30 AM, rattus > 
> wrote: 
> > There's my question - how does one set up a systemd service to start up 
> > anything without running systemctl on the system? 
>
> You just symlink the *.service. 
>
> but ssh is running by default in the image. 
>
> more then likely, you have a board that needs the phy-search patch, 
> that's currently disabled in my v4.1.0-rcX tree.. 
>
> login over serial thru the debug header to verify.. 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BeagleBone: Cross-Compiling Tool-Chain on Mac OS X?

[rattus]

If anyone's interested, I have a semi-painful flow for dumping a 
user-created image to SD under Debian running on a VirtualBox VM under Mac 
OS X. The image was created using Robert's flow in Debian. I have been 
quite happy with VirtualBox lately, far more than I can say for the crooks 
(take your money, provide zero support) at Parallels.

Here are my notes from the last time:

1) follow the instructions at eewiki.net to build a new image in the 
VirtualBox VM.

2) insert SD card into reader slot on MacBook Pro

3) shut down the Linux VM and VirtualBox

4) make sure the SD card adapter switch is in writable position. Insert 
card into SD reader slot

5) open Disk Utility, and erase the card

6) unmount the UNTITLED partition

7) cd to your VM directory (typically "$HOME/VirtualBox VMs/")

8) edit the .vbox file to remove the .vmdk entry.

9) sudo vi ~/Library/VirtualBox/VirtualBox.xml; remove lines that reference 
sd-card.vmdk

10) rm *.vmdk

11) run sudo chown  /dev/disk1*

12) run sudo chmod 777 /dev/disk1*

13) run sudo VBoxManage internalcommands createrawvmdk -filename 
./sd-card.vmdk -rawdisk /dev/disk *

15) unmount the /dev/disk<1 or 2>s1 (UNTITLED) partition

16) In the VirtualBox control Panel, select Storage, right-click and Add 
Hard Disk. Choose existing Disk. Choose sd-card.vmdk

17) in Disk Utility, unmount the UNTITLED partition again

18) Start up Linux VM

19) in  Debian, run lsblk to determine the new SD card partition (/dev/sdb1 
usually)

20) sudo dd if=/dev/zero of=/dev/sdb


21) follow instructions at 
https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-SetupmicroSD/SDcard
 
to set up the card.


22) shut down the VM in Virtualbox

23) remove the SD card from the storage category in the VirtualBox control 
panel

24) eject and remove the SD card

Good Luck - Mike

On Friday, May 29, 2015 at 8:12:08 AM UTC-6, rei_...@yahoo.fr wrote:
>
> I'm trying to cross-compile on my Mac against the BeagleBone.
>
> Surprisingly, the Linaro tool-chain is only available for Windows and 
> Linux, not Mac OS X.
>
> The only binary I've found so far comes from 
> http://www.welzels.de/blog/en/arm-cross-compiling-with-mac-os-x/comment-page-1/
>  , 
> but debugging doesn't work. The sysroots files aren't provided. 
>
> Other options include:
>
>- Mentor Graphics  —previously Sourcery Mentor 
>— but the 
>tool-chain is no longer free,
>- Carlson Minot  but it doesn't feature 
>hardware FPU, while Debian requires it.
>
> Most blogs suggest to create and host a Linux virtual machine. 
>
> But all tentatives to build the tool-chain myself end with error messages 
> and failures. 
>
> Any plan to deliver a tool-chain binary for Mac OS X?
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] BBB P8/P9 GPIO pin availability

[rattus]

Just want to verify something... I an *not* using HDMI, McASP, gpmc, UARTs, 
the ADC or I2Cs. I am using the EMMC. Just SPI0 and a bunch of GPIOs.

Can I assume that any P8/P9 pins labeled as GPIO in some mode, and *not* 
labeled "allocated for EMMC2"* on Derek Molloy's helpful P8/9 charts is 
available for GPIO purposes?

Are there any other preallocated P8/9 GPIO-potential pins I need to watch 
out for? Just checking before I commit the cape from Hell to fab.

Thanks, 

Mike

* = gpmc_be1n, gpmc_clk, gpmc_dat0-7, or P8 pins 3-6 and 20-25.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB P8/P9 GPIO pin availability

[rattus]

Thanks guys. I will not be driving anything at boot, as all the cape pins 
are initially configured as inputs.

Surprisingly, I did read sections 6.7 and 8.3. It would have been nice if 
the P8 pins had been referenced in those diagrams, rather than having to 
trace the schematics.

mike

On Saturday, September 5, 2015 at 7:44:02 AM UTC-6, Charles Steinkuehler 
wrote:
>
> On 9/4/2015 10:35 PM, rattus wrote: 
> > Just want to verify something... I an *not* using HDMI, McASP, gpmc, 
> UARTs, 
> > the ADC or I2Cs. I am using the EMMC. Just SPI0 and a bunch of GPIOs. 
> > 
> > Can I assume that any P8/P9 pins labeled as GPIO in some mode, and *not* 
> > labeled "allocated for EMMC2"* on Derek Molloy's helpful P8/9 charts is 
> > available for GPIO purposes? 
> > 
> > Are there any other preallocated P8/9 GPIO-potential pins I need to 
> watch 
> > out for? Just checking before I commit the cape from Hell to fab. 
>
> In addition to not driving the boot pins while reset is asserted 
> (unless you're intentionally trying to change the boot mode), you also 
> need to watch out for the cape EEPROM I2C lines (P9, pins 19 and 20). 
>  These pins will be in I2C mode at boot-up, and will be twiddled by 
> the cape manager as it looks for any connected capes. 
>
> -- 
> Charles Steinkuehler 
> cha...@steinkuehler.net  
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB P8/P9 GPIO pin availability

[rattus]

Got it. Sounds like a DAMHIK situation; -) 

So you're saying that VDD_3V3B does not come up quickly enough to power 
external devices before the boot configuration is read from the pins? You'd 
think we should have held off boot a little longer until supplies settle. 
Given there's no P8/9 accessible way to prolong boot, short of driving a 
tiny solenoid to hold the reset button down a little longer, how might one 
isolate the input protection diodes until bot is safely started?

I think my answer lies in that the cape is also providing the 5V to the 
BBB, so I can delay that until my own 3.3V supplies stabilize. Seems a 
waste of the 3.3V regulator on theBB though. Perhaps manipulating the 
PWR_BUT (PB_IN signal on the TPS65217C PMIC) on P9 might solve this...

My loadings are a single LVC gate on each line, so basically nothing there.

Thanks for the advice. Do you think a delayed reset via the PWR_BUT signal 
would provide the answer?

On Saturday, September 5, 2015 at 10:03:42 AM UTC-6, Graham wrote:
>
> Mike:
>
> In the case of those boot programming pins, the definition of "not-driven" 
> includes NOT LOADING the pins.
>
> If you are using CMOS inputs on I.C.s that are already powered up, then 
> O.K.
>
> If the the "inputs" that you are hanging on the boot pins are ICs that are 
> not powered up yet (because you 
> used the VDD_3V3B rail to power them), then the ESD diodes are putting a 
> short to ground on the boot pins.
>
> If the "inputs" that you are hanging on the boot pins are bipolar 
> transistors, with pull down resistors
> in the circuit, you could be over-riding the boot instruction "highs" and 
> turning them into lows.
>
> You have been warned.  :-)
>
> --- Graham
>
>
>>>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB P8/P9 GPIO pin availability

[rattus]

I went with a little LDO to provide a local 3.3V source; looks like it'll 
pop up in about 50-100uS after 5V is available.

Thanks again.

On Saturday, September 5, 2015 at 12:22:21 PM UTC-6, Graham wrote:
>
> I think the VDD_3V3B rail is deliberately held off until the unit has 
> started booting, 
> and has already read the boot instructions.  It is not a rise time issue. 
> I suspect it was done deliberately to help with the "don't drive the rest 
> of the pins" issue.
>
> A little 5V to 3.3V regulator to power your LVC "input" IC will work 
> nicely.
> Provided that it is powered at the same time the BBB is.
> That is, use VDD_5V if powered from the power jack.
>
> Relative to power appearing at the power jack:
> SYS_5V is delayed 50 ms.
> VDD_3V3B is delayed 100 ms.
> SYS_RESETn is delayed ~130 ms.
>
> I have not measured power supply sequencing when powered by USB.
>
> Or if you are dealing with both I and O on the boot pins, use something 
> like
> a 74CBTLV3126 bus switch / transmission gate to  isolate your circuitry
> from the BBB while it is booting.  Just make sure the bus-switch / 
> transmission-gate
> is powered while the BBB is booting.
>
> This issue only comes up about once a week here on the forum.  :-)
>
> --- Graham
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB P8/P9 GPIO pin availability

[rattus]

You may have seen I mentioned that no signals would be driven onto the BBB 
expansion headers until enabled to do so (if I forgot to mention that, they 
won't be); all other pins are inputs to the expansion card and thanks to 
Graham's advice will be powered first to ensure protection diodes will not 
interfere with the boot configuration.

Mike

On Saturday, September 5, 2015 at 7:10:43 PM UTC-6, Gerald wrote:
>
> Well, I think there is a better way that relying on luck. I suggest you 
> take a look at 
> http://www.elinux.org/Beagleboard:BeagleBoneBlack#Expansion_Header_Pin_Usage
>
> Gerald
>
> On Sat, Sep 5, 2015 at 7:51 PM, rattus > 
> wrote:
>
>> I went with a little LDO to provide a local 3.3V source; looks like it'll 
>> pop up in about 50-100uS after 5V is available.
>>
>> Thanks again.
>>
>>
>> On Saturday, September 5, 2015 at 12:22:21 PM UTC-6, Graham wrote:
>>>
>>> I think the VDD_3V3B rail is deliberately held off until the unit has 
>>> started booting, 
>>> and has already read the boot instructions.  It is not a rise time 
>>> issue. 
>>> I suspect it was done deliberately to help with the "don't drive the 
>>> rest of the pins" issue.
>>>
>>> A little 5V to 3.3V regulator to power your LVC "input" IC will work 
>>> nicely.
>>> Provided that it is powered at the same time the BBB is.
>>> That is, use VDD_5V if powered from the power jack.
>>>
>>> Relative to power appearing at the power jack:
>>> SYS_5V is delayed 50 ms.
>>> VDD_3V3B is delayed 100 ms.
>>> SYS_RESETn is delayed ~130 ms.
>>>
>>> I have not measured power supply sequencing when powered by USB.
>>>
>>> Or if you are dealing with both I and O on the boot pins, use something 
>>> like
>>> a 74CBTLV3126 bus switch / transmission gate to  isolate your circuitry
>>> from the BBB while it is booting.  Just make sure the bus-switch / 
>>> transmission-gate
>>> is powered while the BBB is booting.
>>>
>>> This issue only comes up about once a week here on the forum.  :-)
>>>
>>> --- Graham
>>>
>>>
>>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Gerald
>  
> ger...@beagleboard.org 
> http://beagleboard.org/
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB P8/P9 GPIO pin availability

[rattus]

This does beg one last question - as I am using expansion connector pins to 
provide chip selects for numerous peripherals, what is the default state of 
the AM335X pins at powerup, until the boot configuration is loaded? I've 
slogged through the TRM as best I could, but want to make sure we're not 
inadvertently enabling multiple chip selects that may drive competing, say, 
SDOs (peripheral) into SDI (cpu) before the boot configuration is loaded.

Ideally, they would be defaulted as inputs or tri-stated outputs, in which 
case a weak pulldown on the peripheral CSn lines should keep things quiet. 
Despite my best efforts at searching the 4K+ pages of the TRM, I have not 
found a clear answer as to the pre-boot load default pin configuration. I 
probably missed it, but my search-fu fails me.

Mike

On Monday, September 7, 2015 at 8:22:04 AM UTC-6, Gerald wrote:
>
> That would be nice as well.  But that is your call.
>
> Gerald
>
> On Sun, Sep 6, 2015 at 8:46 PM, rattus > 
> wrote:
>
>> You may have seen I mentioned that no signals would be driven onto the 
>> BBB expansion headers until enabled to do so (if I forgot to mention that, 
>> they won't be); all other pins are inputs to the expansion card and thanks 
>> to Graham's advice will be powered first to ensure protection diodes will 
>> not interfere with the boot configuration.
>>
>> Mike
>>
>> On Saturday, September 5, 2015 at 7:10:43 PM UTC-6, Gerald wrote:
>>>
>>> Well, I think there is a better way that relying on luck. I suggest you 
>>> take a look at 
>>> http://www.elinux.org/Beagleboard:BeagleBoneBlack#Expansion_Header_Pin_Usage
>>>
>>> Gerald
>>>
>>> On Sat, Sep 5, 2015 at 7:51 PM, rattus  wrote:
>>>
>>>> I went with a little LDO to provide a local 3.3V source; looks like 
>>>> it'll pop up in about 50-100uS after 5V is available.
>>>>
>>>> Thanks again.
>>>>
>>>>
>>>> On Saturday, September 5, 2015 at 12:22:21 PM UTC-6, Graham wrote:
>>>>>
>>>>> I think the VDD_3V3B rail is deliberately held off until the unit has 
>>>>> started booting, 
>>>>> and has already read the boot instructions.  It is not a rise time 
>>>>> issue. 
>>>>> I suspect it was done deliberately to help with the "don't drive the 
>>>>> rest of the pins" issue.
>>>>>
>>>>> A little 5V to 3.3V regulator to power your LVC "input" IC will work 
>>>>> nicely.
>>>>> Provided that it is powered at the same time the BBB is.
>>>>> That is, use VDD_5V if powered from the power jack.
>>>>>
>>>>> Relative to power appearing at the power jack:
>>>>> SYS_5V is delayed 50 ms.
>>>>> VDD_3V3B is delayed 100 ms.
>>>>> SYS_RESETn is delayed ~130 ms.
>>>>>
>>>>> I have not measured power supply sequencing when powered by USB.
>>>>>
>>>>> Or if you are dealing with both I and O on the boot pins, use 
>>>>> something like
>>>>> a 74CBTLV3126 bus switch / transmission gate to  isolate your circuitry
>>>>> from the BBB while it is booting.  Just make sure the bus-switch / 
>>>>> transmission-gate
>>>>> is powered while the BBB is booting.
>>>>>
>>>>> This issue only comes up about once a week here on the forum.  :-)
>>>>>
>>>>> --- Graham
>>>>>
>>>>>
>>>>> -- 
>>>> For more options, visit http://beagleboard.org/discuss
>>>> --- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "BeagleBoard" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to beagleboard...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>
>>>
>>> -- 
>>> Gerald
>>>  
>>> ger...@beagleboard.org
>>> http://beagleboard.org/
>>>
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Gerald
>  
> ger...@beagleboard.org 
> http://beagleboard.org/
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB P8/P9 GPIO pin availability

[rattus]

On Monday, September 7, 2015 at 6:52:12 PM UTC-6, Graham wrote:
>
> Well, by definition, the boot programming pins are going to have the 
> pull-ups / pull-downs, so you know what they are going to be doing, until 
> over-ridden.
>
> Most processors start up with the programmable pins as inputs, then move 
> to the configured state.
>

If it were so... but it seems with such an abundance of modes and pins, a 
number of the pins I am using are in a variety if input, output, hi-Z and 
I/O defaults at powerup, most often with pullup or pull-downs. The good 
news is, I've added enough gating and the additional fast-starting Vdd to 
avoid conflicts. SPI attached peripherals (powered early) all need commands 
shifted in to drive outputs, so that's safe too.

Now for the *next* Beaglebone, innocuous I/Os would be a great feature...

Anything else can be dangerous to the pins.  But, as Charles says, RTFM.
>

> If you are concerned, use the bus-isolation /transmission-gate  chips, 
> power them early, supply your own pull-ups/pull-downs, and switch the 
> connection on when SYS_RESETn goes high.  Then you are unconditionally 
> safe, and in-control.
>
> --- Graham
>

Thanks, 

Mike 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB P8/P9 GPIO pin availability

[rattus]

Completely understood; however, assuming one could meet board area and 
timing constraints, it might be possible to wrap the processor with a 
circuit prophylactic, as it were...

I've also been part of several ARM-based core silicon projects, and it 
would have been possible for that (i.e. consistent pre-reset I/O state) to 
have been addressed at the chip level.

Mike

On Tuesday, September 8, 2015 at 5:56:32 AM UTC-6, Gerald wrote:
>
> I/O pin functionality is a function of the processor. Not the board.
>
> Gerald
>
> On Mon, Sep 7, 2015 at 10:05 PM, rattus > 
> wrote:
>
>> On Monday, September 7, 2015 at 6:52:12 PM UTC-6, Graham wrote:
>>>
>>> Well, by definition, the boot programming pins are going to have the 
>>> pull-ups / pull-downs, so you know what they are going to be doing, until 
>>> over-ridden.
>>>
>>> Most processors start up with the programmable pins as inputs, then move 
>>> to the configured state.
>>>
>>
>> If it were so... but it seems with such an abundance of modes and pins, a 
>> number of the pins I am using are in a variety if input, output, hi-Z and 
>> I/O defaults at powerup, most often with pullup or pull-downs. The good 
>> news is, I've added enough gating and the additional fast-starting Vdd to 
>> avoid conflicts. SPI attached peripherals (powered early) all need commands 
>> shifted in to drive outputs, so that's safe too.
>>
>> Now for the *next* Beaglebone, innocuous I/Os would be a great feature...
>>
>> Anything else can be dangerous to the pins.  But, as Charles says, RTFM.
>>>
>>
>>> If you are concerned, use the bus-isolation /transmission-gate  chips, 
>>> power them early, supply your own pull-ups/pull-downs, and switch the 
>>> connection on when SYS_RESETn goes high.  Then you are unconditionally 
>>> safe, and in-control.
>>>
>>> --- Graham
>>>
>>
>> Thanks, 
>>
>> Mike 
>>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] 4.1 kernel difficulties with SPI

[rattus]

Yup - that was it - older dtc. Do you see any stability coming to that soon?

Thanks.

Mike

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Accessing SPI EEPROM (AT25 type)

[rattus]

I have set up SPI on my BBB (spidev_test works fine) and have 
compiled/installed the AT25 SPI EEPROM kernel module. I am missing the 
knowledge/piece that allows me to access the AT25 using the read/write 
calls. The at25 spi eeprom is a proxy/training ground for a much more 
complex spi device interface I need to build. Anyone have a pointer that 
can get me moving? TIA.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.