Re: [beagleboard] Re: 192.168.7.2 is NOT opening or reachable

[Jon Morss]

It is possible that you either have a bad USB cable or your PC can not 
provide enough power to properly power up the BBB.
The preference would be to upgrade you eMMC, however, this message does 
appear in your files though:




[ 8428.112630] sd 2:0:0:0: [sdb] Synchronize Cache(10) failed: Result: 
hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
[ 8428.408057] usb 2-1: new high-speed USB device number 8 using xhci_hcd
[ 8428.536147] usb 2-1: Device not responding to setup address.
[ 8428.744111] usb 2-1: Device not responding to setup address.
[ 8428.952095] usb 2-1: device not accepting address 8, error -71
[ 8429.924105] usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
[ 8429.924193] usb usb2-port1: attempt power cycle
[ 8431.272034] usb 2-1: new high-speed USB device number 10 using xhci_hcd
[ 8431.293196] usb 2-1: New USB device found, idVendor=1d6b, 
idProduct=0104, bcdDevice= 4.01
[ 8431.293200] usb 2-1: New USB device strings: Mfr=3, Product=4, 
SerialNumber=5
[ 8431.293202] usb 2-1: Product: BeagleBoneBlack
[ 8431.293205] usb 2-1: Manufacturer: Circuitco
[ 8431.293206] usb 2-1: SerialNumber: C0-5018BBBK0C2


Jon


On Wednesday, July 15, 2020 at 9:57:56 AM UTC-7, Pankaj Rai wrote:
>
> PFA for screenshots of the output message on running the command dmesg 
> with plugged in BBB.
>
> thanks.
>
> On Wed, Jul 15, 2020 at 10:15 PM Pankaj Rai  > wrote:
>
>> Hi,
>> I could see couple of errors listed out with and without BBB connected to 
>> my laptop using mini USB cable(given in box). But i couldn't figure out 
>> totally, the difference between plugged and unplugged BBB.
>>
>> I'm attaching the output file hereby for your reference. thanks for your 
>> help.
>>
>> pankaj 
>>
>> On Wed, Jul 15, 2020 at 9:35 PM jonnymo > 
>> wrote:
>>
>>> Unplug and plug the BBB back in and then check the output of running the 
>>> command : dmesg
>>>
>>> Jon
>>>
>>> On Wed, Jul 15, 2020 at 8:25 AM Pankaj Rai >> > wrote:
>>>
>>>> Hi,
>>>>
>>>> It seems I'm not getting the 192.168.6.1 or 192.168.7.1 on command 
>>>> ifconfig -a
>>>>
>>>>
>>>> Thanks
>>>>
>>>> On Wed, Jul 15, 2020, 20:19 amf > 
>>>> wrote:
>>>>
>>>>> Only way to update the emmc os without a ethernet connection is by 
>>>>> using a USB-to-SERIAL adapter, make sure to get the 3.3 volt version. 
>>>>> Not sure if you answered the prior question. does your laptop show 
>>>>> 192.168.6.1 and/or 192.168.7.1 when doing 'ifconfig -a' from a terminal 
>>>>> window? 
>>>>> If it does, I don't see any reason why you cannot at least ping the 
>>>>> BBB at 6.2 or 7.2. 
>>>>>
>>>>> On Tuesday, July 14, 2020 at 10:19:21 AM UTC-5, Pankaj Rai wrote:
>>>>>>
>>>>>> Hi,
>>>>>> Currently I'm working with my personal laptop only. And also i've 
>>>>>> ordered a 16 gb sd card for sure. But meanwhile i was trying to make it 
>>>>>> work with with preinstalled os in eMMC only.
>>>>>>
>>>>>> Is there any way we can update the eMMC OS? So that it may able to 
>>>>>> connect to 192.168.7.2 or 192.168.6.2 ( this is because somewhere i've 
>>>>>> seen 
>>>>>> that Linux system uses this ip to connect with BBB).
>>>>>>
>>>>>> Thanks
>>>>>> Pankaj
>>>>>>
>>>>>> On Tue, Jul 14, 2020, 20:25 amf  wrote:
>>>>>>
>>>>>>> connecting the ethernet to the computer will not provide you with an 
>>>>>>> IP address on the BBB. BBB wants to use dhcp to get an IP, which what 
>>>>>>> happens when connected to the router. 
>>>>>>> You should be able to ping 192.168.7.2 from the laptop, if you see 
>>>>>>> 192.168.7.1 on the laptop. 
>>>>>>> Is this your personal laptop or a company laptop? companies tend to 
>>>>>>> secure laptops such that ping and ssh aren't allowed (My personal 
>>>>>>> experience)
>>>>>>> Would recommend getting an sdcard, again if this is a company 
>>>>>>> laptop, it may not help. 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Monday, July 13, 2020 at 9:58:28 PM UTC-5, Pankaj Rai wrote:
>>>>>>>>
>>>>>

[beagleboard] Re: accessing P9.13 on Beaglebone AI

[Jon Morss]

According to the spreadsheet that Jason sent some time back, P9.13 does not 
have the gpio value highlighted in blue but I am not sure what that really 
means.  However, it seems the pins with a gpio value in blue seem to work 
fine, such as P9.12 (gpio5_0).
https://docs.google.com/spreadsheets/d/1fE-AsDZvJ-bBwzNBj1_sPDrutvEvsmARqFwvbw_HkrE/edit?usp=sharing

You could check the output of showpins to see what P9.13x is set to:
sudo /opt/scripts/device/bone/show-pins.pl |grep "P9.13"
P9.13b   160 AB10 e fast rx  gpio6_12
P9.13a   204  C17 e fastdown 

With P9.12 set, it looks as such:
sudo /opt/scripts/device/bone/show-pins.pl |grep "P9.12"
P9.12171  B14 e fast rx  gpio5_0

Also,  I do add this in the .dts file:

cape_pins: cape_pins {
compatible = "gpio-leds";
pinctrl-names = "default";
gpios = < 12 GPIO_ACTIVE_HIGH>,
< 0 GPIO_ACTIVE_HIGH>;
pinctrl-0 = <_pins_default>;
};


Perhaps there is another trick to get P9.13b to work as a GPIO pin. 

Cheers,

Jon


On Monday, May 11, 2020 at 3:25:59 PM UTC-7, John Allwine wrote:
>
> When I manually wire a pull up resistor, I still am not able to detect a 
> high signal using the methods I listed, though I can verify with a 
> multimeter that P9.13 is high. 
>
> On Monday, May 11, 2020 at 3:17:36 PM UTC-6, John Allwine wrote:
>>
>> I'm trying to configure P9.13 on the Beaglebone AI as an input pull up, 
>> but am not having any success. In the System Manual 
>> <https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual#p9.11-p9.13>
>>  
>> it lists P9.13a as not being bound to a GPIO port, but P9.13b is bound to 
>> GPIO6_12. This is the device tree overlay I'm using 
>> <https://github.com/PocketNC/BeagleBoard-DeviceTrees/blob/pocketnc-ai-test/src/arm/am5729-beagleboneai-pocketnc-pro.dts#L56>
>>  with 
>> line 56 showing how I'm attempting to configure P9.13b (and P9.13a the line 
>> above it). Am I doing something wrong in my device tree overlay? I've had 
>> success configuring many other pins, but P9.13 is giving me trouble for 
>> some reason.
>>
>> I'm testing it a couple ways:
>> 1) with sysfs
>> echo 172 > /sys/class/gpio/export
>> cat /sys/class/gpio/gpio172/value
>>
>> 2) with libgpio
>> gpioget gpiochip5 12
>>
>> Both return a value of 0, when I'd expect it to be 1 (I don't have 
>> anything wired to it). Any idea what I'm doing wrong?
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d808c9de-7abd-42bd-ab24-a697fb5f1913%40googlegroups.com.

Re: [beagleboard] Re: Enable Bluetooth?

[Jon Morss]

  Yeah, an external BT device might be the solution but if the BT/BLE 
feature is not support on the BBAI, then it should be stated as such and 
listed as WiFi only.

I've tried a few more things but still I can't get it to work or even show 
an address.

$ sudo modprobe hci_uart 
debian@beaglebone:~$ sudo lsmod |grep hci
hci_uart   69632  0
btqca  16384  1 hci_uart
bluetooth 548864  11 btsdio,hci_uart,btqca,bnep

systemctl enable bluetooth.service
systemctl start bluetooth.service


I am not sure why 'hciuart.service' is missing:
$debian@beaglebone:~$ sudo systemctl status hciuart.service
Unit hciuart.service could not be found

$ sudo ls /lib/systemd/system/hciuart.service
ls: cannot access '/lib/systemd/system/hciuart.service': No such file or 
directory


debian@beaglebone:~$ sudo lsmod |grep -i sdio
btsdio 16384  0
bluetooth 548864  9 btsdio,bnep


This is what I see from 'dmesg'

debian@beaglebone:~$ dmesg  |grep -Ei 'blue|firm'
[   23.488304] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: 
Mar  1 2015 07:29:38 version 7.45.18 (r538002) FWID 01-6a2c8ad4
[   25.046041] vpe 489d.vpe: loading firmware vpdma-1b8.bin
[   25.736322] Bluetooth: Core ver 2.22
[   25.736564] Bluetooth: HCI device and connection manager initialized
[   25.736605] Bluetooth: HCI socket layer initialized
[   25.736636] Bluetooth: L2CAP socket layer initialized
[   25.736745] Bluetooth: SCO socket layer initialized
[   25.790364] Bluetooth: Generic Bluetooth SDIO driver ver 0.1
[   30.510745] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   30.510768] Bluetooth: BNEP filters: protocol multicast
[   30.510807] Bluetooth: BNEP socket layer initialized
[ 1535.224971] Bluetooth: HCI UART driver ver 2.3
[ 1535.224998] Bluetooth: HCI UART protocol H4 registered
[ 1535.230749] Bluetooth: HCI UART protocol LL registered
[ 1535.230779] Bluetooth: HCI UART protocol ATH3K registered
[ 1535.230803] Bluetooth: HCI UART protocol Three-wire (H5) registered
[ 1535.230821] Bluetooth: HCI UART protocol QCA registered



Still, not working:
$ sudo hciconfig -a
hci0: Type: Primary  Bus: SDIO
BD Address: 00:00:00:00:00:00  ACL MTU: 0:0  SCO MTU: 0:0
DOWN 
RX bytes:0 acl:0 sco:0 events:0 errors:0
TX bytes:0 acl:0 sco:0 commands:0 errors:0
Features: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Packet type: DM1 DH1 HV1 
Link policy: 
Link mode: SLAVE ACCEPT 


debian@beaglebone:~$  sudo bluetoothd -d -n
bluetoothd[1997]: Bluetooth daemon 5.50
bluetoothd[1997]: src/main.c:parse_config() parsing /etc/bluetooth/main.conf
bluetoothd[1997]: src/main.c:parse_config() Key file does not have key “
DiscoverableTimeout” in group “General”
bluetoothd[1997]: src/main.c:parse_config() Key file does not have key “
PairableTimeout” in group “General”
bluetoothd[1997]: src/main.c:parse_config() Key file does not have key “
Privacy” in group “General”
bluetoothd[1997]: src/main.c:parse_config() Key file does not have key “Name
” in group “General”
bluetoothd[1997]: src/main.c:parse_config() class=0x020100
bluetoothd[1997]: src/main.c:parse_config() Key file does not have key “
DeviceID” in group “General”
bluetoothd[1997]: src/main.c:parse_config() Key file does not have key “
ReverseServiceDiscovery” in group “General”
bluetoothd[1997]: src/main.c:parse_config() Key file does not have key “
MinEncKeySize” in group “GATT”
D-Bus setup failed: Name already in use
bluetoothd[1997]: Unable to get on D-Bus


debian@beaglebone:~$ sudo hciconfig hci0 up 
   
 Can't init device hci0: Input/output error (5)

debian@beaglebone:~$ sudo bluetoothctl
Agent registered
[bluetooth]# list
[bluetooth]# show
No default controller available
[bluetooth]# power on
No default controller available


>From what I can gather, this is the BT device on the BBAI but I am not sure 
where to get a driver for it.
https://deviwiki.com/wiki/AzureWave_AW-CM256SM



I'm not sure what else to try.

Cheers,

Jon

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/08f3efe5-82b7-421a-87cc-a29bad3f676e%40googlegroups.com.

Re: [beagleboard] Re: Enable Bluetooth?

[Jon Morss]

Sorry to dig this up again, but has this been fixed?  I am seeing the same 
issue with the latest image , 
"am57xx-debian-10.3-iot-tidl-armhf-2020-04-06-6gb.img.xz" where the 
bluetooth device does not appear to be working.

The WiFi is working but not the bluetooth device.

debian$ hciconfig
hci0:   Type: Primary  Bus: SDIO
BD Address: 00:00:00:00:00:00  ACL MTU: 0:0  SCO MTU: 0:0
DOWN
RX bytes:0 acl:0 sco:0 events:0 errors:0
TX bytes:0 acl:0 sco:0 commands:0 errors:0

$ sudo hcitool dev
Devices:


$ sudo hcitool lescan
Could not open device: No such device



$ dmesg |grep -i brcm
[   22.472541] brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac43455
-sdio.bin for chip 0x004345(17221) rev 0x06
[   22.474228] usbcore: registered new interface driver brcmfmac
[   22.816956] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Mar 
 1 2015 07:29:38 version 7.45.18 (r538002) FWID 01-6a2c8ad4



$ dmesg |grep -i blue
[   24.843545] Bluetooth: Core ver 2.22
[   24.843753] Bluetooth: HCI device and connection manager initialized
[   24.849439] Bluetooth: HCI socket layer initialized
[   24.849474] Bluetooth: L2CAP socket layer initialized
[   24.849594] Bluetooth: SCO socket layer initialized
[   24.923314] Bluetooth: Generic Bluetooth SDIO driver ver 0.1
[   30.630971] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   30.630993] Bluetooth: BNEP filters: protocol multicast
[   30.631034] Bluetooth: BNEP socket layer initialized




Side Note: At BeagleBoard.og, the 10.3 IoT TiDL image is listed as an 8Gb 
image but the file shows 6gb
https://beagleboard.org/latest-images

  "AM5729 Debian 10.3 2020-04-06 8GB SD IoT TIDL"


Cheers,

Jon

On Thursday, January 9, 2020 at 9:51:16 AM UTC-8, RobertCNelson wrote:
>
> On Thu, Jan 9, 2020 at 11:39 AM Bryan > 
> wrote: 
> > 
> > Should the bb-bbai-firmware package work to enable Bluetooth on the BBAI 
> (not the BBB)? 
> > 
> > See my previous posts in this thread for details but I can't get it to 
> function. For now I'm using a USB bluetooth dongle as an alternative. 
>
> bb-bbai-firmware just installs the firmware for the bbai, i thought it 
> worked thru bluetoothctl, it's been a few months since i looked at it. 
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1f4a2c16-f077-4c3f-bb1d-38772b42bfe9%40googlegroups.com.

Re: [beagleboard] CLoud9 TIDL example sees CMEM Error after recent upgrade

[Jon Morss]

I am not sure and would have to look at it a bit closer.

Perhaps checking whether or not there is something attached to the video 
device or show a list of possible video devices and prompt the user to 
select one.  I suppose they would need to know which video device is the 
active one though.

Cheers,

Jon

On Friday, March 27, 2020 at 4:07:58 AM UTC-7, Jason Kridner wrote:
>
> Any thoughts on making it more generic? Select the highest index?
>
> On Thu, Mar 26, 2020 at 10:22 PM jonnymo > 
> wrote:
>
>> In the GitHub issue that was filed, I noted the following which seems to 
>> get the camera active again:
>>
>>  
>>
>> Setting '-d /dev/video1' in the common Makefile seemed to do the trick. I 
>> now have video from the camera in the TIDL example.
>>
>> This is what I changed at line 170 in the Makefile at:
>> /var/lib/cloud9/common$
>>
>> else ifeq ($(PROC),tidl)
>> ti-mct-heap-check -c
>> sudo mjpg_streamer -i "input_opencv.so -d /dev/video1 -r 640x480 
>> --filter ./$(TARGET)$(EXE)" -o "output_http.so -p 8080 -w 
>> /usr/share/mjpg-streamer/www"
>> else
>>
>>
>>
>> On Thu, Mar 26, 2020 at 9:20 AM Robert Nelson > > wrote:
>>
>>> On Thu, Mar 26, 2020 at 10:27 AM > 
>>> wrote:
>>> >
>>> > Hi,
>>> > I just came across this post that is relevant to the same problem. I 
>>> just started working on this Beaglebone AI two days ago. I got the latest 
>>> os image and updates and upgrades everything. I tried 
>>> classification.tidl.cpp and I got the same last message that Jon Morss 
>>> got.  And your latest message was about /dev/video0. On my board I got 
>>> /dev/video0, /dev/video1 and it does recognize the camera. Do you mean that 
>>> I can fix it with the change to the default dev for the camera ? And where 
>>> can I change that? I worked with OpenCV and this VideoCapture::open() 
>>> failed message seems to indicate a wrong /dev/video index?
>>>
>>> Please submit a bug to:
>>>
>>> https://github.com/beagleboard/cloud9-examples
>>>
>>> the classification demo should allow you to specify a video offset..
>>>
>>> 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 beagl...@googlegroups.com .
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/beagleboard/CAOCHtYjyA8yTBWKs-%3DFUoE4kh20XgiQNpheJLfnzHG7_ouqVNA%40mail.gmail.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 beagl...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/CAG99bko9Nkz-Jb%2BnBYd-RvhBzGhNHJMkv1%2B7bVcn6hLdaqDcTA%40mail.gmail.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/CAG99bko9Nkz-Jb%2BnBYd-RvhBzGhNHJMkv1%2B7bVcn6hLdaqDcTA%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> -- 
> https://beagleboard.org/about - a 501c3 non-profit educating around open 
> hardware computing
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/285fd1d7-e1bc-4a68-855c-a649ca5a4ac2%40googlegroups.com.

Re: [beagleboard] CLoud9 TIDL example sees CMEM Error after recent upgrade

[Jon Morss]

Yeah, I tried the Makefile in the classification example and it did not do 
anything.  I had to hunt around and found the examples originated the build 
in the common Makefile so I changed it there and it seems to work.  
I too have a Logitech C920.

Cheers,

Jon

On Friday, March 27, 2020 at 6:25:18 AM UTC-7, maste...@gmail.com wrote:
>
> That works! Thank you
> I tested out 5 webcams with both dummy.tidl and classificatin.tidl
> 1. Logitech C920 webcam works
> 2. VERY Old Creative VF0230 webcam - did not work
> 3. VERY Old trinket AMD Smarter Choice webcam -images torn up with 
> overread errors-n as n goes randomly from 1 to 8
> 4. OLD Silicon Motion SM731 webcam works
> 5. OLD EyeToy webcam  - occasional image tears
>
> check out https://elinux.org/RPi_USB_Webcams for some camera info.
>  
> I modified the common Makefile and it works. Just for curiosity I modified 
> the local Makefile as well and
> I's weird that the LOCAL Makefile is corrupted when I rebooted the board. 
> It came up with a dialog box asking if you want to reload file from disk 
> (that Makefile was modified in previous session and saved  "-r /dev/video1" 
> similar to the common Makefile) . If I clicked "Y" it showed the correct 
> mod -d/dev/video1, and if I clicked "no", it showed -d /dev/
>
>
> On Thursday, March 26, 2020 at 10:23:17 PM UTC-4, jonnymo wrote:
>>
>> In the GitHub issue that was filed, I noted the following which seems to 
>> get the camera active again:
>>
>>  
>>
>> Setting '-d /dev/video1' in the common Makefile seemed to do the trick. I 
>> now have video from the camera in the TIDL example.
>>
>> This is what I changed at line 170 in the Makefile at:
>> /var/lib/cloud9/common$
>>
>> else ifeq ($(PROC),tidl)
>> ti-mct-heap-check -c
>> sudo mjpg_streamer -i "input_opencv.so -d /dev/video1 -r 640x480 
>> --filter ./$(TARGET)$(EXE)" -o "output_http.so -p 8080 -w 
>> /usr/share/mjpg-streamer/www"
>> else
>>
>>
>>
>> On Thu, Mar 26, 2020 at 9:20 AM Robert Nelson  
>> wrote:
>>
>>> On Thu, Mar 26, 2020 at 10:27 AM  wrote:
>>> >
>>> > Hi,
>>> > I just came across this post that is relevant to the same problem. I 
>>> just started working on this Beaglebone AI two days ago. I got the latest 
>>> os image and updates and upgrades everything. I tried 
>>> classification.tidl.cpp and I got the same last message that Jon Morss 
>>> got.  And your latest message was about /dev/video0. On my board I got 
>>> /dev/video0, /dev/video1 and it does recognize the camera. Do you mean that 
>>> I can fix it with the change to the default dev for the camera ? And where 
>>> can I change that? I worked with OpenCV and this VideoCapture::open() 
>>> failed message seems to indicate a wrong /dev/video index?
>>>
>>> Please submit a bug to:
>>>
>>> https://github.com/beagleboard/cloud9-examples
>>>
>>> the classification demo should allow you to specify a video offset..
>>>
>>> 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 beagl...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/beagleboard/CAOCHtYjyA8yTBWKs-%3DFUoE4kh20XgiQNpheJLfnzHG7_ouqVNA%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/2e52e2e3-639e-48d1-b3b9-8886457b988e%40googlegroups.com.

Re: [beagleboard] CLoud9 TIDL example sees CMEM Error after recent upgrade

[Jon Morss]

Hey Robert,

Cool.  Thanks.

However, I now end up with a different error:

NOTE: I did an upgrade after the update. Also, the update_kernel bumped my 
kernel to r131 from r130.
info: you are running: [4.14.108-ti-r130], latest is: [4.14.108-ti-r131] 
updating...

The result of removing and installing the cmem modules:
debian@beaglebone:~$ sudo apt remove ti-cmem-4.15.00.02-modules-`uname -r` 
--purge
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package 'ti-cmem-4.15.00.02-modules-4.14.108-ti-r131' is not installed, so 
not removed
The following packages were automatically installed and are no longer 
required:
  bb-beaglebone-io-installer bb-johnny-five-installer
  ti-c6000-cgt-v8.2.x-installer
Use 'sudo apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.


debian@beaglebone:~$ sudo apt install ti-cmem-4.16.00.00-modules-`uname -r`
Reading package lists... Done
Building dependency tree
Reading state information... Done
ti-cmem-4.16.00.00-modules-4.14.108-ti-r131 is already the newest version 
(1stretch).
The following packages were automatically installed and are no longer 
required:
  bb-beaglebone-io-installer bb-johnny-five-installer
  ti-c6000-cgt-v8.2.x-installer
Use 'sudo apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.



Error from TIDL classification example:
 
Started /var/lib/cloud9/: classification.tidl.cpp
File path: /var/lib/cloud9/BeagleBone/AI/tidl
File: /var/lib/cloud9/BeagleBone/AI/tidl/classification.tidl.cpp
Arguments: 
File name: classification.tidl.cpp
File extension: cpp
File base name: classification.tidl
Packages: ~.c9/packages
Project path: /var/lib/cloud9/
Project name: projectname
Hostname: localhost
Hostname path: https://undefined/BeagleBone/AI/tidl/classification.tidl.cpp
URL: http://localhost
Port: 8080
IP: 0.0.0.0
Command: BeagleBone/AI/tidl/classification.tidl.cpp
Python: python3
Python path: 
/usr/lib/python3.7/dist-packages:/usr/local/lib/python3.7/dist-packages
/var/lib/cloud9/common/Makefile:28: 
MODEL=BeagleBoard.org_BeagleBone_AI,TARGET=classification.tidl,COMMON=/var/lib/cloud9/common
/var/lib/cloud9/common/Makefile:147: 
GEN_DIR=/tmp/cloud9-examples,CHIP=am57xx,PROC=tidl,PRUN=,PRU_DIR=,EXE=.so
CXX classification.tidl.cpp
LD  /tmp/cloud9-examples/classification.tidl.o
ti-mct-heap-check -c
sudo mjpg_streamer -i "input_opencv.so -r 640x480 --filter 
./classification.tidl.so" -o "output_http.so -p 8080 -w 
/usr/share/mjpg-streamer/www"
[sudo] password for debian:
MJPG Streamer Version.: 2.0
 i: device... : default
 i: Desired Resolution: 640 x 480
Unable to stop the stream: Invalid argument
 i: VideoCapture::open() failed
/var/lib/cloud9/common/Makefile:169: recipe for target 'start' failed
make: *** [start] Error 1
rm /tmp/cloud9-examples/classification.tidl.o


Process exited with code: 2



Cheers,

Jon


On Tuesday, March 24, 2020 at 3:40:47 PM UTC-7, RobertCNelson wrote:
>
> On Tue, Mar 24, 2020 at 5:31 PM Jon Morss > 
> wrote: 
> > 
> > After recently upgrading my BBAI via the link below, the Cloud9 TIDL 
> classification example fails for CMEM error. 
> > Link used to upgrade BBAI 
> > https://beagleboard.org/upgrade 
>
> > CMEM Error: init: major version mismatch between interface and driver. 
> > CMEM Error: needs driver version 0x416, got 0x4150002 
> > TIOCL FATAL: The cmemk kernel module is not installed. Consult the 
> OpenCL UserGuide at 
> http://software-dl.ti.com/mctools/esd/docs/opencl/index.html 
>
> Yeap, I've been busy upgrading both Debian Stretch & Buster to TI's 
> sdk  06.02.00.81 
>
> https://github.com/beagleboard/Latest-Images/issues/11 
>
> To fix your problem, two fixes: 
>
> Fix 1: update "./update_kernel.sh" so stretch uses cmem 4.16.00.00 on 
> kernel modules: 
>
> https://github.com/RobertCNelson/boot-scripts/commit/43e2e0e554b10d779fdbc730bb0d5d197e467d02
>  
>
> Run: 
>
> cd /opt/scripts/tools/ 
> git pull 
>
> Fix 2: switch your current version of cmem: (the kernel update script 
> will fix it going forward, but this will fix your version today) 
>
> Run: 
>
> sudo apt update 
> sudo apt remove ti-cmem-4.15.00.02-modules-`uname -r` --purge 
> sudo apt install ti-cmem-4.16.00.00-modules-`uname -r` 
> sudo depmod -a 
> sudo update-initramfs -uk `uname -r` 
>
> and reboot.. 
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1ef9bf14-ed1a-49dd-8b0a-3a5525eb7c00%40googlegroups.com.

[beagleboard] CLoud9 TIDL example sees CMEM Error after recent upgrade

[Jon Morss]

moteproc remoteproc6: 4b2b4000.pru is available
[   61.799147] remoteproc remoteproc7: 4b2b8000.pru is available
dmesg | grep pru
[   56.852898] pruss_uio_shmem 4b20.pruss_shmem: Allocating gdev
[   56.852926] pruss_uio_shmem 4b20.pruss_shmem: Allocating info
[   56.852946] pruss_uio_shmem 4b20.pruss_shmem: Requesting resource
[   56.853002] pruss_uio_shmem 4b20.pruss_shmem: Mapping resource
[   56.853415] pruss_uio_shmem 4b20.pruss_shmem: Registering with uio 
driver
[   56.855842] pruss_uio_shmem 4b20.pruss_shmem: Saving platform data
[   56.889266] pruss_uio_shmem 4b28.pruss_shmem: Allocating gdev
[   56.889294] pruss_uio_shmem 4b28.pruss_shmem: Allocating info
[   56.889317] pruss_uio_shmem 4b28.pruss_shmem: Requesting resource
[   56.889378] pruss_uio_shmem 4b28.pruss_shmem: Mapping resource
[   56.889418] pruss_uio_shmem 4b28.pruss_shmem: Registering with uio 
driver
[   56.910568] pruss_uio_shmem 4b28.pruss_shmem: Saving platform data
[   60.590938] pruss 4b20.pruss: creating PRU cores and other child 
platform devices
[   60.604803] pruss 4b28.pruss: creating PRU cores and other child 
platform devices
[   61.744815] remoteproc remoteproc4: 4b234000.pru is available
[   61.745011] pru-rproc 4b234000.pru: PRU rproc node 
/ocp/pruss_soc_bus@4b226004/pruss@0/pru@34000 probed successfully
[   61.768955] remoteproc remoteproc5: 4b238000.pru is available
[   61.769147] pru-rproc 4b238000.pru: PRU rproc node 
/ocp/pruss_soc_bus@4b226004/pruss@0/pru@38000 probed successfully
[   61.780959] remoteproc remoteproc6: 4b2b4000.pru is available
[   61.781173] pru-rproc 4b2b4000.pru: PRU rproc node 
/ocp/pruss_soc_bus@4b2a6004/pruss@0/pru@34000 probed successfully
[   61.799147] remoteproc remoteproc7: 4b2b8000.pru is available
[   61.799337] pru-rproc 4b2b8000.pru: PRU rproc node 
/ocp/pruss_soc_bus@4b2a6004/pruss@0/pru@38000 probed successfully
dmesg | grep pinctrl-single
[0.755794] pinctrl-single 4a003400.pinmux: 282 pins at pa fc003400 size 
1128
dmesg | grep gpio-of-helper
lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 046d:082d Logitech, Inc. HD Pro Webcam C920
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
END

Looks like the cmemk module is not loading:

TIOCL FATAL: The cmemk kernel module is not installed


Cheers,

Jon



-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/fd38cac7-8fdf-4b3d-968e-081f7a2438f0%40googlegroups.com.

[beagleboard] TIDL kernel 4.19 support

[Jon Morss]

I noticed some work has been on going with the BeagleBoard 4.19 branch on 
GitHub and I was wondering if TIDL will be supported with 4.19 (or later) 
anytime soon?


Cheers,

Jon 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/c607bce6-d399-4dc3-bac2-f52df7705cf7%40googlegroups.com.

Re: [beagleboard] Re: TIDL Classification example not properly identify objects

[Jon Morss]

This is the output of the commands you requested.  Note, i did make some 
changes to workaround some of the issues.
debian@beaglebone:/var/lib/cloud9$ git status 
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working directory)


 modified:   BeagleBone/AI/analogInOut.js
 modified:   BeagleBone/AI/blinkLED.js
 modified:   BeagleBone/AI/blinkLED.py


Untracked files:
  (use "git add ..." to include in what will be committed)


 BeagleBone/AI/blinkLED


no changes added to commit (use "git add" and/or "git commit -a")
debian@beaglebone:/var/lib/cloud9$ git show | head -1
commit 40f82013c3a27e4fc7e3604da3cd53b3ce05706d


Cheers,

Jon


On Tuesday, October 29, 2019 at 9:58:09 AM UTC-7, Jason Kridner wrote:
>
> Stick to 4.14.
>
> Provide me the output of:
> cd /var/lib/cloud9;git status;git show | head -1
>
> On Mon, Oct 28, 2019 at 5:19 AM > wrote:
>
>> I get the same error as well.  Updated everything and rebooted a couple 
>> of times.
>>
>> On Wednesday, October 23, 2019 at 11:37:39 PM UTC-5, jonnymo wrote:
>>>
>>> I've pulled in the changes but now I get the following error when 
>>> attempting to run the TIDL example from the Cloud9 IDE.
>>> NOTE: I've updated to the 4.19 kernel, so I am not sure if that is 
>>> causing the issue:
>>>
>>> *Command: BeagleBone/AI/tidl/classification.tidl.cpp*
>>> *Python: python3*
>>> *Python path: 
>>> /usr/lib/python3.7/dist-packages:/usr/local/lib/python3.7/dist-packages*
>>> */var/lib/cloud9/common/Makefile:27: 
>>> MODEL=BeagleBoard.org_BeagleBone_AI,TARGET=classification.tidl,COMMON=/var/lib/cloud9/common*
>>> */var/lib/cloud9/common/Makefile:145: 
>>> GEN_DIR=/tmp/cloud9-examples,CHIP=am57xx,PROC=tidl,PRUN=,PRU_DIR=,EXE=.so*
>>> *ti-mct-heap-check -c*
>>> *sudo mjpg_streamer -i "input_opencv.so -r 640x480 --filter 
>>> ./classification.tidl.so <http://classification.tidl.so>" -o 
>>> "output_http.so -p 8080 -w /usr/share/mjpg-streamer/www"*
>>> *[sudo] password for debian:*
>>> *MJPG Streamer Version.: 2.0*
>>> * i: device... : default*
>>> * i: Desired Resolution: 640 x 480*
>>> * i: filter... : ./classification.tidl.so 
>>> <http://classification.tidl.so>*
>>> * i: filter args . :*
>>> *Initializing filter*
>>> *loading configuration*
>>> *allocating execution object pipelines (EOP)*
>>> *CMEM Error: init: major version mismatch between interface and driver.*
>>> *CMEM Error: needs driver version 0x4150002, got 0x416*
>>> *TIOCL FATAL: The cmemk kernel module is not installed. Consult the 
>>> OpenCL UserGuide at 
>>> http://software-dl.ti.com/mctools/esd/docs/opencl/index.html 
>>> <http://software-dl.ti.com/mctools/esd/docs/opencl/index.html>*
>>> */var/lib/cloud9/common/Makefile:167: recipe for target 'start' failed*
>>> *make: *** [start] Error 1*
>>>
>>>
>>>
>>> Cheers,
>>>
>>> Jon
>>>
>>>
>>> On Wed, Oct 23, 2019 at 9:32 AM jonnymo  wrote:
>>>
>>>> Jason,
>>>>
>>>> I appreciate the update.  I'll update the code on me BB AI and run the 
>>>> exercise again.
>>>>
>>>> Now to get the blinkLED.py and JavaScript examples working. 
>>>>   
>>>> I'm looking forward for the Tensorflow Lite support, so I'll keep and 
>>>> eye on that.
>>>>
>>>> Thanks for the work you do on this.
>>>>
>>>> Cheers,
>>>>
>>>> Jon
>>>>
>>>> On Wed, Oct 23, 2019 at 8:20 AM Jason Kridner  
>>>> wrote:
>>>>
>>>>> Sorry about that. I broke the example. I've updated it and it should 
>>>>> work now.
>>>>>
>>>>>
>>>>> https://github.com/beagleboard/cloud9-examples/commit/210388017fcb233c2f422d54af293bb8d5c94bc2
>>>>>
>>>>> I was visiting the TI office and talking to the developers about the 
>>>>> performance of this example. According to profiles,
>>>>> it should run up to 60fps. I attempted to make some changes to speed 
>>>>> it up, but I did it wrong.
>>>>>
>>>>> You can group different layers in the network to run on different 
>>>>> processors

[beagleboard] BBAI: Assistance requested with configuring P9_15 as an output gpio

[Jon Morss]

teproc remoteproc3: 4b2b8000.pru is available
[1.210487] pru-rproc 4b2b8000.pru: PRU rproc node pru@4b2b8000 probed 
successfully
dmesg | grep pinctrl-single
[0.967269] pinctrl-single 4a003400.pinmux: 282 pins, size 1128
dmesg | grep gpio-of-helper
lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 046d:082d Logitech, Inc. HD Pro Webcam C920
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
END


Any assistance would be greatly appreciated 
.

Cheers,

Jon







-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1f6f3e04-be8c-469b-8845-3b2ce838508c%40googlegroups.com.

[beagleboard] Re: TIDL Classification example not properly identify objects

[Jon Morss]

Yeah, I always find it suspect when am example is posted and demo'd but 
does not seem to work for others.

Headbanging continues.

Jon

On Tuesday, October 22, 2019 at 4:03:38 PM UTC-7, Dobrin Alexiev wrote:
>
> In my case I also see often ping-pong_ball, or more often "segmentation 
> fault". 
> I wonder how can I debug this?
>
>
> On Sunday, October 20, 2019 at 2:11:54 AM UTC-4, Jon Morss wrote:
>>
>> I am attempting to run the TIDL example with a Beaglebone AI and the only 
>> thing it seems to report identifying is a ping-pong, although I am not 
>> presenting a ping pong to the camera.  I am using a Logitech C920 camera 
>> and have performed all of the updates to the system, so am not sure what I 
>> am missing.
>>
>> This is what I see when running the classification.tidl.cpp example:
>>
>> sudo mjpg_streamer -i "input_opencv.so -r 640x480 --filter ./
>> classification.tidl.so" -o "output_http.so -p 8080 -w 
>> /usr/share/mjpg-streamer/www"
>> [sudo] password for debian:
>> MJPG Streamer Version.: 2.0
>>  i: device... : default
>>  i: Desired Resolution: 640 x 480
>>  i: filter... : ./classification.tidl.so
>>  i: filter args . :
>> Initializing filter
>> loading configuration
>> allocating execution object pipelines (EOP)
>> allocating executors
>> allocating individual EOPs
>> allocating I/O memory for each EOP
>> Allocating input and output buffers
>> Allocating input and output buffers
>> Allocating input and output buffers
>> Allocating input and output buffers
>> num_eops=4
>> About to start ProcessFrame loop!!
>> http://localhost:8080/?action=stream
>>  o: www-folder-path..: /usr/share/mjpg-streamer/www/
>>  o: HTTP TCP port: 8080
>>  o: HTTP Listen Address..: (null)
>>  o: username:password: disabled
>>  o: commands.: enabled
>> (722)=ping-pong_ball
>> (722)=ping-pong_ball
>> (722)=ping-pong_ball
>> (722)=ping-pong_ball
>> (722)=ping-pong_ball
>> (722)=ping-pong_ball
>>
>>
>> This is what I see from dmesg:
>>
>> [20753.769040] usb 1-1: New USB device found, idVendor=046d, idProduct=
>> 082d
>> [20753.769075] usb 1-1: New USB device strings: Mfr=0, Product=2, 
>> SerialNumber=1
>> [20753.769097] usb 1-1: Product: HD Pro Webcam C920
>> [20753.769118] usb 1-1: SerialNumber: C0DB0F6F
>> [20754.099831] uvcvideo: Found UVC 1.00 device HD Pro Webcam C920 (046d:
>> 082d)
>> [20754.120146] uvcvideo 1-1:1.0: Entity type for entity Processing 3 was 
>> not initialized!
>> [20754.120179] uvcvideo 1-1:1.0: Entity type for entity Extension 6 was 
>> not initialized!
>>
>> [20754.120323] uvcvideo 1-1:1.0: Entity type for entity Extension 11 was 
>> not initialized!
>> [20754.125089] input: HD Pro Webcam C920 as /devices/platform/
>> 4400.ocp/488c.omap_dwc3_2/488d.usb/xhci-hcd.1.auto/usb1/1-1/1
>> -1:1.0/input/input3
>> [20754.135851] usbcore: registered new interface driver uvcvideo
>> [20754.135871] USB Video Class driver (1.1.1)
>> [20754.437849] usbcore: registered new interface driver snd-usb-audio
>> [20867.134498] usb 1-1: reset high-speed USB device number 3 using xhci-
>> hcd
>> [20867.558788] omap-iommu 58882000.mmu: 58882000.mmu: version 2.1
>> [20867.605127] omap_hwmod: mmu0_dsp2: _wait_target_disable failed
>> [20867.605206] omap-iommu 41501000.mmu: 41501000.mmu: version 3.0
>> [20867.605483] omap-iommu 41502000.mmu: 41502000.mmu: version 3.0
>> [20867.619103] omap_hwmod: mmu0_dsp1: _wait_target_disable failed
>>
>>
>> Am I missing a step?
>>
>> Cheers,
>>
>> Jon
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e28fe150-3638-4a56-8b34-95034d60bf0e%40googlegroups.com.

[beagleboard] TIDL Classification example not properly identify objects

[Jon Morss]

I am attempting to run the TIDL example with a Beaglebone AI and the only 
thing it seems to report identifying is a ping-pong, although I am not 
presenting a ping pong to the camera.  I am using a Logitech C920 camera 
and have performed all of the updates to the system, so am not sure what I 
am missing.

This is what I see when running the classification.tidl.cpp example:

sudo mjpg_streamer -i "input_opencv.so -r 640x480 --filter 
./classification.tidl.so" -o "output_http.so -p 8080 -w 
/usr/share/mjpg-streamer/www"
[sudo] password for debian:
MJPG Streamer Version.: 2.0
 i: device... : default
 i: Desired Resolution: 640 x 480
 i: filter... : ./classification.tidl.so
 i: filter args . :
Initializing filter
loading configuration
allocating execution object pipelines (EOP)
allocating executors
allocating individual EOPs
allocating I/O memory for each EOP
Allocating input and output buffers
Allocating input and output buffers
Allocating input and output buffers
Allocating input and output buffers
num_eops=4
About to start ProcessFrame loop!!
http://localhost:8080/?action=stream
 o: www-folder-path..: /usr/share/mjpg-streamer/www/
 o: HTTP TCP port: 8080
 o: HTTP Listen Address..: (null)
 o: username:password: disabled
 o: commands.: enabled
(722)=ping-pong_ball
(722)=ping-pong_ball
(722)=ping-pong_ball
(722)=ping-pong_ball
(722)=ping-pong_ball
(722)=ping-pong_ball


This is what I see from dmesg:

[20753.769040] usb 1-1: New USB device found, idVendor=046d, idProduct=082d
[20753.769075] usb 1-1: New USB device strings: Mfr=0, Product=2, 
SerialNumber=1
[20753.769097] usb 1-1: Product: HD Pro Webcam C920
[20753.769118] usb 1-1: SerialNumber: C0DB0F6F
[20754.099831] uvcvideo: Found UVC 1.00 device HD Pro Webcam C920 (046d:082d
)
[20754.120146] uvcvideo 1-1:1.0: Entity type for entity Processing 3 was not 
initialized!
[20754.120179] uvcvideo 1-1:1.0: Entity type for entity Extension 6 was not 
initialized!

[20754.120323] uvcvideo 1-1:1.0: Entity type for entity Extension 11 was not 
initialized!
[20754.125089] input: HD Pro Webcam C920 as /devices/platform/4400.ocp/
488c.omap_dwc3_2/488d.usb/xhci-hcd.1.auto/usb1/1-1/1-1:1.0/input/
input3
[20754.135851] usbcore: registered new interface driver uvcvideo
[20754.135871] USB Video Class driver (1.1.1)
[20754.437849] usbcore: registered new interface driver snd-usb-audio
[20867.134498] usb 1-1: reset high-speed USB device number 3 using xhci-hcd
[20867.558788] omap-iommu 58882000.mmu: 58882000.mmu: version 2.1
[20867.605127] omap_hwmod: mmu0_dsp2: _wait_target_disable failed
[20867.605206] omap-iommu 41501000.mmu: 41501000.mmu: version 3.0
[20867.605483] omap-iommu 41502000.mmu: 41502000.mmu: version 3.0
[20867.619103] omap_hwmod: mmu0_dsp1: _wait_target_disable failed


Am I missing a step?

Cheers,

Jon

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/379db11f-882e-4981-9466-3e9fa9248f84%40googlegroups.com.

[beagleboard] Re: BBBLues

[Jon Morss]

I have a BBBlue that experienced the same fate as your #1 except I get R11 
that is dimly lit and no blinky LEDs after a bit.  Trying to reflash the 
eMMC or other image install has resolved the issue.


If you find a cure for the Zombie BBBlue, I would be interested in it.

Cheers,

Jon 

On Wednesday, September 4, 2019 at 11:02:33 PM UTC, todd.c...@gmail.com 
wrote:
>
> So I have had nothing but trouble with my two BBBls. I attempted every 
> walk through I could find on both of them, every time I would get stuck at 
> a different point before I could ever get to installing ardupilot software. 
> I finally got fed up with them, bought a Pixhack, combined it with a I.MX6 
> scavenged from a 3DR Solo, and went on about my business. Due to a recent 
> operator 
> error induced gravitational field incident, the pixhack seems to have 
> developed dementia as it no longer oriented as to place time or self. 
> Therefore, I have recently found it necessary to bring the BBBls out of 
> storage and give them a second chance. 
>
>
> *Here is the problem*: both of these little beauties seem to have called 
> it quits. When I connect them to a computer, any computer (I've tried Win7, 
> Win10, and Ubuntu 18.something) with any usb cable sometimes the computer 
> will acknowledge that a device was connected, sometimes it won't. On 
> windows, when it realizes that a device is there, it tells me that I need 
> to format the SD card, as if that was the only thing I connected, Linux 
> machines will let me view the files but that's it. I no longer have the 
> "Out the box" files that came on the BBBls that used to be there, the ones 
> with the little picture of the dog and the "getting started" stuff. Where'd 
> they go? *Can I re-download the factory software somewhere? or is there a 
> Factory reset option?*
>
>
> The pictures below are included to show the lights that stay on on each 
> one. 
>
> #1 G,R,75, and the one by the 12v input light up immediately when power is 
> applied, with or without an SD card, and 0-3 light up sequentially after 
> about 5 seconds without a card, a little slower with one. 
>
> #2 goes through the same process, but eventually all lights cut off except 
> the one by the 12v plug and led zero goes into a double blink, pause 
> pattern; with or without a card. 
>
> [image: BBBLues1.jpg]
>
>
> [image: BBBLues2.jpg]
>
> When I say "card", I mean one flashed with 
> "bone-debian-9.5-iot-armhf-2018-10-07-4gb.img.xz"
>
> I have installed BONE_64 on my PCs
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/b5bf90e3-01d5-4ebb-928a-e506996f97f4%40googlegroups.com.

[beagleboard] BeagelBone AI release revision

[Jon Morss]

Hi,

I was quite excited to have received the BeagelBone AI I purchased, however 
looking at the System Reference Manual, it lists revision A1a as the the 
initial production rev yet the one I have received shows it is a A1. Is the 
one I have the wrong revision for production and should I return it?


Ref:
https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual#board-changes

2.2.2 Rev A1
Second round prototype

2.2.3 Rev A1a
Alpha pilot-run units and initial production. 



Cheers,

Jon

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/77f13324-781b-4686-8158-620d0afefba0%40googlegroups.com.

[beagleboard] BeagleBoard.org - Bad Gateway

[Jon Morss]

When attempting to access anything at BeagleBoard.org I am getting a "502 
Bad Gateway   nginx/1.12.2"  error.

Is this site down?

Cheers,

Jon

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/86f498a1-c394-4ce5-9e03-9814f43bceab%40googlegroups.com.

[beagleboard] Beagebone AI release revision

[Jon Morss]

Hi,

I was quite excited to have received the BeagleBone AI I purchased, however 
looking at the System Reference Manual it lists revision A1a as the the 
initial production rev yet the one I have received shows it is a A1. Is the 
one I have the wrong revision for production and should I return it?

Ref:
https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual#board-changes

2.2.3 Rev A1a
Alpha pilot-run units and initial production. 


Cheers,

Jon

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/73beb98c-6cff-473e-ad90-c6aa13fe1022%40googlegroups.com.

Re: [beagleboard] Re: Disabling/enabling the USB slave interface dynamically

[Jon Lundstrom]

I'm using my c-program that creates files. It uses the the USB-mass storage 
device that comes with the BBB which is created by 
/opt/scripts/boot/am335x_evm.sh (so, in that sense, you could say I use a 
script).
I've mounted the disc-image-file it uses, so my application simply writes 
its files to that device, for the host PC to copy.

The BBB with my application is a measuring device which produces result 
files (in the same way as a digital camera).
It would nice to be able to upload these files to a PC via USB. 

Scp could be a solution but I don't have control over the host PC, in the 
sence that I don't want to install programs on it. The PC usually belongs 
to somebody else. Simply put, I want to the ability to connect to any PC, 
have my application to create files on the BBB and then letting the owner 
of the PC to upload them to his domain.

Another solution is to unplug-reinsert the cable after every measurement. 
That's where I stand today  ...but it's not pretty. 
I feel I'm so close: I only need my application to toggle the USB device 
off/on, so the host will behave as if it was unplugged/reinserted, and 
update its file info.

But I don't know how. I have difficulties understanding the 
am335x_evm-script and it seems to be run once, at startup. Isn't there an 
easy way of turning the USB-mass- storage-device on and off from an 
application?

Yes, I have been thinking of buying a mechanical relay, controlled by a 
gpio, to unplug the cable from my application. That would probably do the 
job, but it feels awkward.





Den måndag 14 maj 2018 kl. 03:42:17 UTC+2 skrev Mala Dies:
>
> Hello,
>
> Are you using software to perform this action or a shell script?
>
> Seth
>
> P.S. I found that there are particular software, WinSCP, that transfers 
> files from bbb to host easily and vice versa. This may be something to look 
> into. 
>
> On Thursday, April 26, 2018 at 3:43:15 AM UTC-5, Jon Lundstrom wrote:
>>
>> Yes,
>>
>> But I haven't found the refresh option. Double-checking right now on 
>> Windows7 and Kubuntu... nope, no refresh available. However, I tried , 
>> but with no effect. I tried Windows10 before writing my question and no 
>> success there either. 
>>
>> Unplugging/reinserting the USB cable was the only remedy. 
>> It would be nice if I could do that from the SW that adds the files to 
>> the gadget.
>>
>>
>> 2018-04-25 14:49 GMT+02:00 Dennis Lee Bieber <wlf...@ix.netcom.com>:
>>
>>> On Wed, 25 Apr 2018 02:25:37 -0700 (PDT), Jon Lundstrom
>>> <j.b.lu...@gmail.com> declaimed the
>>> following:
>>>
>>> >I share files created on the BBB with a USB host (e.g. Windows PC) 
>>> using 
>>> >the USB mass storage device (almost like a digital camera). It works 
>>> fine 
>>> >except for one point: Whenever a new file is created by BBB, I need to 
>>> >unplug-reinsert the USB cable in order for the file to become visible 
>>> in 
>>> >the host (master).
>>>
>>> Just out of curiosity -- have you tried a Refresh 
>>> in the
>>> Windows FileExplorer that is opened on the "USB mass storage".
>>>
>>>
>>> -- 
>>> Wulfraed Dennis Lee Bieber AF6VN
>>> wlf...@ix.netcom.comHTTP://wlfraed.home.netcom.com/ 
>>>
>>> -- 
>>> 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/ppkuhZB0Z0M/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to 
>>> beagleboard...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/beagleboard/dft0ed9qt6kdq2jgq7aums02guboro78qt%404ax.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/4e6f345a-f7b6-410c-9b0f-f0fde83562a4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Disabling/enabling the USB slave interface dynamically

[Jon Lundstrom]

Yes,

But I haven't found the refresh option. Double-checking right now on
Windows7 and Kubuntu... nope, no refresh available. However, I tried ,
but with no effect. I tried Windows10 before writing my question and no
success there either.

Unplugging/reinserting the USB cable was the only remedy.
It would be nice if I could do that from the SW that adds the files to the
gadget.


2018-04-25 14:49 GMT+02:00 Dennis Lee Bieber <wlfr...@ix.netcom.com>:

> On Wed, 25 Apr 2018 02:25:37 -0700 (PDT), Jon Lundstrom
> <j.b.lundst...@gmail.com> declaimed the
> following:
>
> >I share files created on the BBB with a USB host (e.g. Windows PC) using
> >the USB mass storage device (almost like a digital camera). It works fine
> >except for one point: Whenever a new file is created by BBB, I need to
> >unplug-reinsert the USB cable in order for the file to become visible in
> >the host (master).
>
> Just out of curiosity -- have you tried a Refresh in
> the
> Windows FileExplorer that is opened on the "USB mass storage".
>
>
> --
> Wulfraed Dennis Lee Bieber AF6VN
> wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.com/
>
> --
> 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/ppkuhZB0Z0M/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/dft0ed9qt6kdq2jgq7aums02guboro78qt%404ax.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAO-Fnw9dy%3DmiYaDTdw%3DFbY6MtymTaAyzjYGE7NW0DVbVig09xw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Disabling/enabling the USB slave interface dynamically

[Jon Lundstrom]

Yes,

But I haven't found the refresh option. Double-checking right now on
Windows7 and Kubuntu... nope, no refresh available. However, I tried ,
but with no effect. I tried Windows10 before writing my question and no
success there either.

Unplugging/reinserting the USB cable was the only remedy.
It would be nice if I could do that from the SW that adds the files to the
gadget.


2018-04-25 14:49 GMT+02:00 Dennis Lee Bieber <wlfr...@ix.netcom.com>:

> On Wed, 25 Apr 2018 02:25:37 -0700 (PDT), Jon Lundstrom
> <j.b.lundst...@gmail.com> declaimed the
> following:
>
> >I share files created on the BBB with a USB host (e.g. Windows PC) using
> >the USB mass storage device (almost like a digital camera). It works fine
> >except for one point: Whenever a new file is created by BBB, I need to
> >unplug-reinsert the USB cable in order for the file to become visible in
> >the host (master).
>
> Just out of curiosity -- have you tried a Refresh in
> the
> Windows FileExplorer that is opened on the "USB mass storage".
>
>
> --
> Wulfraed Dennis Lee Bieber AF6VN
> wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.com/
>
> --
> 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/ppkuhZB0Z0M/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/dft0ed9qt6kdq2jgq7aums02guboro78qt%404ax.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAO-Fnw_Asqv6go%3D-mty6xqBEDPkz%2BxXfP9Pv3E%3Dx3ucPqHaRag%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Disabling/enabling the USB slave interface dynamically

[Jon Lundstrom]

I share files created on the BBB with a USB host (e.g. Windows PC) using 
the USB mass storage device (almost like a digital camera). It works fine 
except for one point: Whenever a new file is created by BBB, I need to 
unplug-reinsert the USB cable in order for the file to become visible in 
the host (master).

It would be nice if I could have my BBB-application to "unplug" the USB 
whenever it creates new files, and then reenable it again, forcing the host 
to update its file info.

But how do I do that? Is it possible to easily disable/enable the slave USB 
interface on the go? Or even better, only the mass storage device, leaving 
the other USB functions running.

Googling the issue I find a lot of solutions on how to disable it 
permanently, editing the am335x_evm.sh, but that's not what I want.

I'm running a recent Debian Stretch from the BBB distribution web page.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e27e9cd2-9280-40bd-a356-81a538460260%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Enabling SPI in BBB, Debian Stretch

[Jon Lundstrom]

Thanks again, Robert,

The display now works and I've been able to loop the SPI back to the BBB.

I'm grateful for your help,
/Jon.

Den tisdag 3 april 2018 kl. 17:32:17 UTC+2 skrev RobertCNelson:
>
> On Tue, Apr 3, 2018 at 10:26 AM, Jon Lundstrom <j.b.lu...@gmail.com 
> > wrote: 
> > 
> > Thank you Robert, 
> > 
> > That did the trick. 
> > 
> > However, it has the side-effect of turning my display all black. 
> > I use a Newhaven display cape and according to its User Guide, there 
> should 
> > be no conflict for these SPI-pins. 
> > (
> http://www.newhavendisplay.com/userguides/NHD-7.0CTP-CAPE_User_Guide.pdf) 
> > 
> > So I had a look at the assigned pins in 
> > /sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups and see that 
> following 
> > group is added (using diff): 
> > 
> >> group: pinmux_bb_spi0_pins 
> >> pin 84 (PIN84) 
> >> pin 85 (PIN85) 
> >> pin 86 (PIN86) 
> >> pin 87 (PIN87) 
> > 
> > which seems in order, but following groups were removed: 
> > 
> > < group: pinmux_bb_lcd_pwm_backlight_pins 
> > < pin 18 (PIN18) 
> > 
> > < group: pinmux_bb_lcd_lcd_pins 
> > < pin 40 (PIN40) 
> > < pin 41 (PIN41) 
> > < pin 42 (PIN42) 
> > < pin 43 (PIN43) 
> > < pin 44 (PIN44) 
> > < pin 45 (PIN45) 
> > < pin 46 (PIN46) 
> > < pin 47 (PIN47) 
> > < pin 48 (PIN48) 
> > < pin 49 (PIN49) 
> > < pin 50 (PIN50) 
> > < pin 51 (PIN51) 
> > < pin 52 (PIN52) 
> > < pin 53 (PIN53) 
> > < pin 54 (PIN54) 
> > < pin 55 (PIN55) 
> > < pin 15 (PIN15) 
> > < pin 14 (PIN14) 
> > < pin 13 (PIN13) 
> > < pin 12 (PIN12) 
> > < pin 11 (PIN11) 
> > < pin 10 (PIN10) 
> > < pin 9 (PIN9) 
> > < pin 8 (PIN8) 
> > < pin 56 (PIN56) 
> > < pin 57 (PIN57) 
> > < pin 58 (PIN58) 
> > < pin 59 (PIN59) 
> > < pin 35 (PIN35) 
> > 
> > < group: pinmux_edt_ft5x06_pins 
> > < pin 105 (PIN105) 
> > 
> > I don't know about the last group (PIN105) but the other two groups most 
> > certainly affect the display function. 
> > 
> > I haven't seen the corresponding .dts-file for BB-SPIDEV0-00A0.dtbo, but 
> I 
> > tried making my own that should not touch these pins: Still, the same 
> result 
> > (same pin groups are removed). 
> > 
> > There seems to be some mechanism that disables the display pins when 
> adding 
> > an overlay to the uEnv.txt. 
> > 
> > Robert, as an expert in BBB, do you have answer to this? 
>
> Well, addr0 -> addr3 is for eeprom detected capes, so change: 
>
> uboot_overlay_addr0=/lib/firmware/BB-SPIDEV0-00A0.dtbo 
>
> to 
>
> uboot_overlay_addr4=/lib/firmware/BB-SPIDEV0-00A0.dtbo 
>
> https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays 
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d5721165-7051-4370-ae86-f0ddc0644191%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Enabling SPI in BBB, Debian Stretch

[Jon Lundstrom]

Thank you Robert,

That did the trick.

However, it has the side-effect of turning my display all black.
I use a Newhaven display cape and according to its User Guide, there should 
be no conflict for these SPI-pins.
(http://www.newhavendisplay.com/userguides/NHD-7.0CTP-CAPE_User_Guide.pdf)

So I had a look at the assigned pins in 
/sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups and see that following 
group is added (using diff):

> group: pinmux_bb_spi0_pins
> pin 84 (PIN84)
> pin 85 (PIN85)
> pin 86 (PIN86)
> pin 87 (PIN87)

which seems in order, but following groups were removed:

< group: pinmux_bb_lcd_pwm_backlight_pins
< pin 18 (PIN18)

< group: pinmux_bb_lcd_lcd_pins
< pin 40 (PIN40)
< pin 41 (PIN41)
< pin 42 (PIN42)
< pin 43 (PIN43)
< pin 44 (PIN44)
< pin 45 (PIN45)
< pin 46 (PIN46)
< pin 47 (PIN47)
< pin 48 (PIN48)
< pin 49 (PIN49)
< pin 50 (PIN50)
< pin 51 (PIN51)
< pin 52 (PIN52)
< pin 53 (PIN53)
< pin 54 (PIN54)
< pin 55 (PIN55)
< pin 15 (PIN15)
< pin 14 (PIN14)
< pin 13 (PIN13)
< pin 12 (PIN12)
< pin 11 (PIN11)
< pin 10 (PIN10)
< pin 9 (PIN9)
< pin 8 (PIN8)
< pin 56 (PIN56)
< pin 57 (PIN57)
< pin 58 (PIN58)
< pin 59 (PIN59)
< pin 35 (PIN35)

< group: pinmux_edt_ft5x06_pins
< pin 105 (PIN105)

I don't know about the last group (PIN105) but the other two groups most 
certainly affect the display function.

I haven't seen the corresponding .dts-file for BB-SPIDEV0-00A0.dtbo, but I 
tried making my own that should not touch these pins: Still, the same 
result (same pin groups are removed). 

There seems to be some mechanism that disables the display pins when adding 
an overlay to the uEnv.txt. 

Robert, as an expert in BBB, do you have answer to this?

Best regards,
Jon Lundström.



Den torsdag 29 mars 2018 kl. 17:40:43 UTC+2 skrev RobertCNelson:
>
> On Thu, Mar 29, 2018 at 10:35 AM, Jon Lundstrom <j.b.lu...@gmail.com 
> > wrote: 
> > I'm trying to enable SPI on my BBB but constantly fail following the 
> advises 
> > I find in the forums. 
> > 
> > It seems like echoing anything into 
> /sys/devices/platform/bone_capemgr/slots 
> > is obsolete. Instead I should set up in /boot/uEnv.txt, but how? What 
> should 
> > I add in that file? 
> > 
> > I've tried: 
> > cape_enable=bone_capemgr.enable_partno=BB-SPIDEV0 
> > or: 
> > optargs=quiet drm.debug=7 capemgr.enable_partno=BB-SPI0-01 
>
> https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays 
>
> uboot_overlay_addr0=/lib/firmware/BB-SPIDEV0-00A0.dtbo 
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/c4eca54b-eb07-4e04-9eee-4d1389aff13e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Enabling SPI in BBB, Debian Stretch

[Jon Lundstrom]

I'm trying to enable SPI on my BBB but constantly fail following the 
advises I find in the forums.

It seems like echoing anything into 
/sys/devices/platform/bone_capemgr/slots is obsolete. Instead I should set 
up in /boot/uEnv.txt, but how? What should I add in that file?

I've tried:
cape_enable=bone_capemgr.enable_partno=BB-SPIDEV0
or:
optargs=quiet drm.debug=7 capemgr.enable_partno=BB-SPI0-01

...but I still don't get anything named spi* under /dev/ (yes, I've 
rebooted)

ls -l /dev/spi*
ls: cannot access '/dev/spi*': No such file or directory

I would be happy with only one SPI, like SPI0 so I wouldn't have to bother 
with disabling HDMI.

This is the state of my setup: sudo /opt/scripts/tools/version.sh
git:/opt/scripts/:[ea6ea9fca05f36f5044398884375b0231348d6e2]
eeprom:[A335BNLT000C1750BBBG0574]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Image 2018-01-28]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2018.01-2-g9aa111a004]
kernel:[4.9.78-ti-r94]
nodejs:[v6.12.3]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg:[bb-cape-overlays]:[4.4.20180126.0-0rcnee0~stretch+20180126]
pkg:[bb-wl18xx-firmware]:[1.20170829-0rcnee2~stretch+20180104]
pkg:[firmware-ti-connectivity]:[20170823-1rcnee0~stretch+20170830]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep 
admin spi tisdk weston-launch xenomai]
dmesg | grep pinctrl-single
[1.380806] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 
568
END


Anyone out there, who knows what to do?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/681dd7f2-4c17-487a-913d-f0049b843479%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Getting started: Step #2 and #3 just dont work on Windows 10 (or 8, or 7)

[Jon Lundstrom]

Well, the web sever on my BBB wasn't responding to 192.168.7.2 before I 
installed the drivers according  to step #2. My Windows 10 should be 
up-to-date.

Thank you guys, for the attention.

Den torsdag 8 februari 2018 kl. 03:43:30 UTC+1 skrev Jason Kridner:
>
> This should be the case, but some folks have reported a regression with 
> the 1709 update around the first of the year. 
> On Wed, Feb 7, 2018 at 10:57 AM Dennis Lee Bieber <wlf...@ix.netcom.com 
> > wrote:
>
>> On Wed, 7 Feb 2018 07:42:23 -0800 (PST), Jon Lundstrom
>> <j.b.lu...@gmail.com > declaimed the
>> following:
>>
>> >
>> >Ther must be more rookies having this problem out there: Try
>> >google https://youtu.be/71YAIw7_-kg to disable this feature.
>> >
>> >Or, BBB: Get this signature from MS. It seems to be a matter of $99 to 
>> get
>> >it.
>> >The 5 minutes needed to get up and started (according to your purchase
>> >text) has grown to more than 5 hrs...
>> >
>> As I recall, the newest BBB images no longer require custom 
>> drivers on
>> Win10 -- they are supposed to work using M$ distributed rndis (or 
>> whatever)
>> drivers, which are found by Win10 automatically.
>>
>> --
>> Wulfraed Dennis Lee Bieber AF6VN
>> wlf...@ix.netcom.com HTTP://wlfraed.home.netcom.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...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/3b8m7dpp4jrojmn09inc7dd3ul3jmkf81m%404ax.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
> https://beagleboard.org/about
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/9d9c2700-19e1-4691-97a2-fd724a7d6046%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Getting started: Step #2 and #3 just dont work on Windows 10 (or 8, or 7)

[Jon Lundstrom]

Actually, on the Windows 7 the symptoms were a bit different. It was an old 
machine with only 4GB RAM and the PC seemed to be overloaded during the 
installation with locked screen for most of the time. 
So the only similarity I can be sure of is the URL not responding.

Anyhow, I think I've found problem on Window 10: It won't install drivers 
lacking valid MS-signature. It doesn't tell you that, it simply tells you 
that installlation failed (thank you Microsoft).

I turned off this signature checking and now it work (even step #3). So I'm 
back on track again.

Ther must be more rookies having this problem out there: Try 
google https://youtu.be/71YAIw7_-kg to disable this feature.

Or, BBB: Get this signature from MS. It seems to be a matter of $99 to get 
it. 
The 5 minutes needed to get up and started (according to your purchase 
text) has grown to more than 5 hrs...


Den onsdag 7 februari 2018 kl. 16:06:01 UTC+1 skrev Jeff Andich:
>
> Do you still get the same driver install problems on the Windows 7 PC as 
> you see on your Windows 10 host or is that primarily a problem with 
> accessing the URL in your web browser?
>
>
> On Wednesday, February 7, 2018 at 8:19:41 AM UTC-6, Jon Lundstrom wrote:
>>
>>
>> I just unpacked a Beaglebone Black board and try to get it started as 
>> tethered to a PC via USB. I can find and read START.HTM from the BBB.
>> When it comes to Step #2, Install drivers, I start getting problems: 4 of 
>> the drivers fail to install on my Windows10 host:
>> Linux Developer Community (usbser) Ports
>> BeagleBone CDM Driver Package - Bus/D2XX Driver
>> BeagleBone CDM Driver Package - VCP Driver
>> Linux Developer Community Net
>>
>> After that step #3 fails, probably as a consequense of above. My web 
>> browser (either Firefox or Chrome) will not find http://192.168.7.2.
>>
>> I've also tried on other computers, running Windows 8 and Windows 7, with 
>> no further success.
>>
>>
>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/abddb2d7-6d72-40e2-b4d0-823c51d1c6b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Getting started: Step #2 and #3 just dont work on Windows 10 (or 8, or 7)

[Jon Lundstrom]

Den onsdag 7 februari 2018 kl. 16:06:01 UTC+1 skrev Jeff Andich:
>
> Do you still get the same driver install problems on the Windows 7 PC as 
> you see on your Windows 10 host or is that primarily a problem with 
> accessing the URL in your web browser?
>
>
> On Wednesday, February 7, 2018 at 8:19:41 AM UTC-6, Jon Lundstrom wrote:
>>
>>
>> I just unpacked a Beaglebone Black board and try to get it started as 
>> tethered to a PC via USB. I can find and read START.HTM from the BBB.
>> When it comes to Step #2, Install drivers, I start getting problems: 4 of 
>> the drivers fail to install on my Windows10 host:
>> Linux Developer Community (usbser) Ports
>> BeagleBone CDM Driver Package - Bus/D2XX Driver
>> BeagleBone CDM Driver Package - VCP Driver
>> Linux Developer Community Net
>>
>> After that step #3 fails, probably as a consequense of above. My web 
>> browser (either Firefox or Chrome) will not find http://192.168.7.2.
>>
>> I've also tried on other computers, running Windows 8 and Windows 7, with 
>> no further success.
>>
>>
>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/a3ff2a4d-e457-4ced-ad89-ba6fe378e987%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Getting started: Step #2 and #3 just dont work on Windows 10 (or 8, or 7)

[Jon Lundstrom]

I just unpacked a Beaglebone Black board and try to get it started as 
tethered to a PC via USB. I can find and read START.HTM from the BBB.
When it comes to Step #2, Install drivers, I start getting problems: 4 of 
the drivers fail to install on my Windows10 host:
Linux Developer Community (usbser) Ports
BeagleBone CDM Driver Package - Bus/D2XX Driver
BeagleBone CDM Driver Package - VCP Driver
Linux Developer Community Net

After that step #3 fails, probably as a consequense of above. My web 
browser (either Firefox or Chrome) will not find http://192.168.7.2.

I've also tried on other computers, running Windows 8 and Windows 7, with 
no further success.



-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/f3c83e68-63eb-4529-a84f-27fbc23f3faa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: bbg wireless debian 9 preinstalled on emmc -- vnc keyboard mapping error

[Jon Peterson]

After working on this for a while, I think it is a problem with LXQt. I 
installed the core of LXDE and a few LXDE apps, rebooted and then removed 
LXQt. Now I have no problem using TurboVNC. This also saved a large amount 
of eMMC space. LXDE works just fine for my purposes.

   sudo apt-get install --no-install-recommends lxde-core

sudo apt-get install gksu leafpad lxterminal lxpolkit lxsession

sudo update-alternatives --config x-session-manager

choose lxde

 sudo apt-get purge --auto-remove 'lxqt-*'


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/cf1e0850-b8af-4780-b508-71103e9b9696%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] bbg wireless debian 9 preinstalled on emmc -- vnc keyboard mapping error

[Jon Peterson]

no matter which vnc client (tight, turbo, tiger), the keyboard mapping is 
wrong when running tighvnc on the bbg wireless. 
asdf becomes abfh...
xsetup does have "export XKL_XMODMAP_DISABLE=1"
does anyone have a work-around?
Thanks.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/a2908776-c40d-4644-8ce8-a808c7caf3ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: PocketBeagal Debian internet over macOS 10.13.2 USB host? (internet over USB)

[Jon Robert Pellant]

@Tarmo, 

What you say sounds good. If that is the case, there should be a way to tell 
the BB to accept the DHCP config. On Ångstrom, that would be with udhcpc. I am 
trying to figure out how to do that with Debian. I am currently exploring 
‘connman’ but I just have not found the time. If that works, I will definitely 
post the solution here.

--jon

> On Dec 19, 2017, at 08:39, Tarmo Kuuse <tarmo.ku...@gmail.com> wrote:
> 
> On Tuesday, 19 December 2017 16:18:39 UTC+2, Jon Pellant wrote:
> @Yoda: System Preferences >> Sharing >> Internet Sharing and share with the 
> Beaglebone.local is what I am doing. This has worked for me in past releases; 
> however, not working for me in this configuration.
>> 
>> On Dec 18, 2017, at 20:49, Yoda <yo...@r2d2.org <>> wrote:
>> 
>> I have been seeing the same thing with MacOS 10.13.2.  I am able to ssh into 
>> the pocket beagle  over the USB, but when I try to turn on Internet Sharing 
>> to be able to forward to the internet then the ssh connection hangs and I 
>> can no longer work on the ssh connection I had established.  I vaguely 
>> remember something about Connection sharing on Mac but I can seem to find it.
> 
> Hi Jon,
> 
> I'm not an expert in anything Apple, however I strongly suspect that enabling 
> Internet Sharing means your Mac will do the following:
> 
> 1. create a private subnetwork on the selected interface with a semi-random 
> address space (e.g. 192.168.XXX.0/24)
> 2. start a DHCP service to serve addresses from selected address space to 
> client hosts
> 3. set the Mac up as a router doing NAT for the client hosts
> 
> Unfortunately the BeagleBone's USB network emulation has already done steps 1 
> and 2 on _its_ side with pre-determined address spaces 192.168.6.0/24 and 
> 192.168.7.0/24. This creates an address conflict between the BB and Mac which 
> makes connectivity impossible.
> 
> I'd suggest connecting your BB and Mac via Ethernet (buy a cheap USB-Ethernet 
> adapter if needed) and enabling Internet Sharing on that interface. In this 
> case the sharing feature should work as intended. Plus you'll always have the 
> same USB network emulation to ssh into the BB in a tight spot.
> 
> --
> Kind regards,
> Tarmo Kuuse
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> <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/YGo43kfc_rY/unsubscribe 
> <https://groups.google.com/d/topic/beagleboard/YGo43kfc_rY/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to 
> beagleboard+unsubscr...@googlegroups.com 
> <mailto:beagleboard+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/30549d61-697e-468c-ba12-a440a6602e4d%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/beagleboard/30549d61-697e-468c-ba12-a440a6602e4d%40googlegroups.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/EC3268D6-0C57-4E16-B4A0-E0F366C3CB32%40pellant.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PocketBeagal Debian internet over macOS 10.13.2 USB host? (internet over USB)

[Jon Pellant]

if you look at the console image, you will see the results of the 
'ifconfig' showing both a usb0: 192.168.7.1 and a usb1: 192.168.6.1. You 
will also note the added route for the default gateway. 

As I said above, there may be an issue with macOS and the network 
preferences and the IP disconnect shown there.

On Monday, December 18, 2017 at 9:23:19 AM UTC-6, RobertCNelson wrote:
>
> On a mac you should get an 192.168.6.2 address thru the usb-cdc 
> interface. (with no external 3rd party drivers installed) 
>
> the 192.168.7.2 address is given thru a rndis interface (on windows 
> systems). 
>
> This change allows us to use the built-in drivers of both systems... 
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/08863b3c-6330-4066-82c5-148200e1ef3a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PocketBeagal Debian internet over macOS 10.13.2 USB host? (internet over USB)

[Jon Pellant]

See the terminal image above. As you can see the ping times out...

I believe the issue is related to the IP address that you see in the macOS 
Network Preferences.

On Monday, December 18, 2017 at 9:17:16 AM UTC-6, Stuart Longland wrote:
>
> On 19/12/17 00:32, Jon Pellant wrote: 
> > I think the DNS issue is next; however, thanks for the tip. I still need 
> > to get internet sharing before I can apt-get anything. 
>
> Are you able to ping any nameservers from the PocketBeagle?  (e.g. 
> 8.8.8.8)? 
>
> If so, you might be able to bootstrap things: 
> # echo 'nameserver 8.8.8.8' >> /etc/resolv.conf 
> -- 
> Stuart Longland (aka Redhatter, VK4MSL) 
>
> I haven't lost my mind... 
>   ...it's backed up on a tape somewhere. 
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/4623635a-cc04-41f7-9130-33116f73e59e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PocketBeagal Debian internet over macOS 10.13.2 USB host? (internet over USB)

[Jon Pellant]

Environment: 

   - Host: MacBookPro
   - OS: macOS 10.13.2
   - board: pocketbeagle
   - boardOS: Debian 9 IoT

I am able to 'screen' into the PB (pocketbeagle). I am loosely trying to 
follow this video; however, this video  is 4+ 
years old and not my environment. For example, Debian does not have the 
'udhcpc' 
command.

After a few minutes, the macOS network preferences shows a warning 
regarding the IP self assignment of the PB:



This is not consistent with the documentation. Also, the warning explicitly 
says that due to this, the PB will not be able to connect to the internet.






Also note that I have added a default route per instructions and still not 
ability to ping Google DNS.

Thoughts?


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/87e7b462-7eca-461f-89f6-c3bfd04e994f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Issues with configuration of USB Ethernet adapter under Debian

[Jon Seymour]

On Thursday, 23 March 2017 11:21:17 UTC+11, Jon Seymour wrote:
>
>
>
> On Wednesday, 22 March 2017 16:58:35 UTC+11, Jon Seymour wrote:
>>
>>
>>
>> On Wednesday, 22 March 2017 14:58:32 UTC+11, Jon Seymour wrote:
>>>
>>>
>>>
>>> On Wednesday, 22 March 2017 11:58:26 UTC+11, Jon Seymour wrote:
>>>>
>>>>
>>>>
>>>> On Wednesday, 22 March 2017 01:08:22 UTC+11, RobertCNelson wrote:
>>>>>
>>>>> On Mon, Mar 20, 2017 at 9:37 PM, Jon Seymour <jon.s...@gmail.com> 
>>>>> wrote: 
>>>>>
>>>>> > Can anyone help me understand why this isn't working as expected? 
>>>>>
>>>>> it's systemd that's doing the rename, in /boot/uEnv.txt, find the 
>>>>> "cmdline=coherent_pool=1M quiet" option and change it to: 
>>>>>
>>>>> cmdline="coherent_pool=1M net.ifnames=0 quiet" 
>>>>>
>>>>> Starting on Dec 9th 2016, we added the "net.ifnames=0" option by 
>>>>> default. 
>>>>>
>>>>> on your next reboot, it'll show up as eth1.. 
>>>>>
>>>>> Regards, 
>>>>>
>>>>>
>>>> Robert,
>>>>
>>>> Thanks for the suggestion. However, It doesn't seem to have helped:
>>>>
>>>> from dmesg output:
>>>>
>>>> [   21.314582] ax88179_178a 1-1:1.0 eth1: register 'ax88179_178a' at 
>>>> usb-musb-hdrc.1.auto-1, D-Link DUB-1312 USB 3.0 to Gigabit Ethernet 
>>>> Adapter, e4:6f:13:f3:df:43
>>>> [   21.316347] usbcore: registered new interface driver ax88179_178a
>>>> [   21.769915] omap-aes 5350.aes: OMAP AES hw accel rev: 3.2
>>>> [   21.813675] omap-sham 5310.sham: hw accel on OMAP rev 4.3
>>>> [   23.989152] asoc-simple-card sound: i2s-hifi <-> 48038000.mcasp 
>>>> mapping ok
>>>> [   24.099140] ax88179_178a 1-1:1.0 enxe46f13f3df43: renamed from eth1
>>>>
>>>> debian@beaglebone:~$ cat /proc/cmdline
>>>> console=ttyO0,115200n8 root=UUID=74cfcc82-bdc4-483a-bcbd-cce4ad70ba00 
>>>> ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet
>>>>
>>>> Currently, I have a udev rule in place:
>>>>
>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="ax88179_178a", 
>>>> ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="enx*", NAME="eth1"
>>>>
>>>> Although I have also tried it with no udev rule. I also don't have a 
>>>> systemd.link configuration in place.
>>>>
>>>> debian@beaglebone:~$ uname -a
>>>> Linux beaglebone 4.4.26-ti-r59 #4 SMP Wed Feb 22 00:13:46 UTC 2017 
>>>> armv7l GNU/Linux
>>>>
>>>> The kernel is a kernel I built from the r59 tag with a slightly 
>>>> different UART driver configuration.
>>>>
>>>> jon.
>>>>
>>>>
>>> It turns out that the following command is sufficient to disable the 
>>> mangled interface names:
>>>
>>>  sudo ln -sf /dev/null /etc/udev/rules.d/80-net-setup-link.rules
>>>
>>> and, in fact, net.ifnames=0 didn't seem to have any effect one way or 
>>> the other.
>>>
>>> Also, with the shorter interface name, DHCP now works on the renamed 
>>> interface - I have a suspicion that it was failing previously because the 
>>> enxe46f13f3df43 was at the limit of a char array length in a structure 
>>> defined in dhclient and this ultimately caused a downstream issue in the 
>>> AF_PACKET handler within the implementation of the bind system call) 
>>> because of the lack of a trailing null - all a supposition, of course.
>>>
>>> jon
>>>
>>
>> The reason net.ifnames=0 didn't work appears to be related to this issue: 
>> http://askubuntu.com/questions/811295/73-usb-net-by-mac-rules-issue-with-net-ifnames/895533#895533
>> .
>>
>> In particular, net.ifnames=0 works if and only 
>> if /lib/udev/rules.d/73-usb-net-by-mac.rules is changed so that:
>>
>> IMPORT{cmdline}="net.ifnames", ENV{net.ifnames}=="0", 
>> GOTO="usb_net_by_mac_end"
>>
>> becomes:
>>
>> IMPORT{cmdline}="net.ifnames"
>> ENV{net.ifnames}=="0", GOTO="usb_net_by_mac_end"
>>
>> With respect to the DH

Re: [beagleboard] Issues with configuration of USB Ethernet adapter under Debian

[Jon Seymour]

On Wednesday, 22 March 2017 16:58:35 UTC+11, Jon Seymour wrote:
>
>
>
> On Wednesday, 22 March 2017 14:58:32 UTC+11, Jon Seymour wrote:
>>
>>
>>
>> On Wednesday, 22 March 2017 11:58:26 UTC+11, Jon Seymour wrote:
>>>
>>>
>>>
>>> On Wednesday, 22 March 2017 01:08:22 UTC+11, RobertCNelson wrote:
>>>>
>>>> On Mon, Mar 20, 2017 at 9:37 PM, Jon Seymour <jon.s...@gmail.com> 
>>>> wrote: 
>>>>
>>>> > Can anyone help me understand why this isn't working as expected? 
>>>>
>>>> it's systemd that's doing the rename, in /boot/uEnv.txt, find the 
>>>> "cmdline=coherent_pool=1M quiet" option and change it to: 
>>>>
>>>> cmdline="coherent_pool=1M net.ifnames=0 quiet" 
>>>>
>>>> Starting on Dec 9th 2016, we added the "net.ifnames=0" option by 
>>>> default. 
>>>>
>>>> on your next reboot, it'll show up as eth1.. 
>>>>
>>>> Regards, 
>>>>
>>>>
>>> Robert,
>>>
>>> Thanks for the suggestion. However, It doesn't seem to have helped:
>>>
>>> from dmesg output:
>>>
>>> [   21.314582] ax88179_178a 1-1:1.0 eth1: register 'ax88179_178a' at 
>>> usb-musb-hdrc.1.auto-1, D-Link DUB-1312 USB 3.0 to Gigabit Ethernet 
>>> Adapter, e4:6f:13:f3:df:43
>>> [   21.316347] usbcore: registered new interface driver ax88179_178a
>>> [   21.769915] omap-aes 5350.aes: OMAP AES hw accel rev: 3.2
>>> [   21.813675] omap-sham 5310.sham: hw accel on OMAP rev 4.3
>>> [   23.989152] asoc-simple-card sound: i2s-hifi <-> 48038000.mcasp 
>>> mapping ok
>>> [   24.099140] ax88179_178a 1-1:1.0 enxe46f13f3df43: renamed from eth1
>>>
>>> debian@beaglebone:~$ cat /proc/cmdline
>>> console=ttyO0,115200n8 root=UUID=74cfcc82-bdc4-483a-bcbd-cce4ad70ba00 ro 
>>> rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet
>>>
>>> Currently, I have a udev rule in place:
>>>
>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="ax88179_178a", 
>>> ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="enx*", NAME="eth1"
>>>
>>> Although I have also tried it with no udev rule. I also don't have a 
>>> systemd.link configuration in place.
>>>
>>> debian@beaglebone:~$ uname -a
>>> Linux beaglebone 4.4.26-ti-r59 #4 SMP Wed Feb 22 00:13:46 UTC 2017 
>>> armv7l GNU/Linux
>>>
>>> The kernel is a kernel I built from the r59 tag with a slightly 
>>> different UART driver configuration.
>>>
>>> jon.
>>>
>>>
>> It turns out that the following command is sufficient to disable the 
>> mangled interface names:
>>
>>  sudo ln -sf /dev/null /etc/udev/rules.d/80-net-setup-link.rules
>>
>> and, in fact, net.ifnames=0 didn't seem to have any effect one way or the 
>> other.
>>
>> Also, with the shorter interface name, DHCP now works on the renamed 
>> interface - I have a suspicion that it was failing previously because the 
>> enxe46f13f3df43 was at the limit of a char array length in a structure 
>> defined in dhclient and this ultimately caused a downstream issue in the 
>> AF_PACKET handler within the implementation of the bind system call) 
>> because of the lack of a trailing null - all a supposition, of course.
>>
>> jon
>>
>
> The reason net.ifnames=0 didn't work appears to be related to this issue: 
> http://askubuntu.com/questions/811295/73-usb-net-by-mac-rules-issue-with-net-ifnames/895533#895533
> .
>
> In particular, net.ifnames=0 works if and only 
> if /lib/udev/rules.d/73-usb-net-by-mac.rules is changed so that:
>
> IMPORT{cmdline}="net.ifnames", ENV{net.ifnames}=="0", 
> GOTO="usb_net_by_mac_end"
>
> becomes:
>
> IMPORT{cmdline}="net.ifnames"
> ENV{net.ifnames}=="0", GOTO="usb_net_by_mac_end"
>
> With respect to the DHCP errors, I found that dhclient fails immediately 
> if the interface name is: enxe46f13f3df43:
>
> Internet Systems Consortium DHCP Client 4.3.1
>
> Copyright 2004-2014 Internet Systems Consortium.
>
> All rights reserved.
>
> For info, please visit https://www.isc.org/software/dhcp/
>
>
> Bind socket to interface: No such device
>
>
> If you think you have received this message due to a bug rather
>
> than a configuration issue please re

Re: [beagleboard] Issues with configuration of USB Ethernet adapter under Debian

[Jon Seymour]

On Wednesday, 22 March 2017 14:58:32 UTC+11, Jon Seymour wrote:
>
>
>
> On Wednesday, 22 March 2017 11:58:26 UTC+11, Jon Seymour wrote:
>>
>>
>>
>> On Wednesday, 22 March 2017 01:08:22 UTC+11, RobertCNelson wrote:
>>>
>>> On Mon, Mar 20, 2017 at 9:37 PM, Jon Seymour <jon.s...@gmail.com> 
>>> wrote: 
>>>
>>> > Can anyone help me understand why this isn't working as expected? 
>>>
>>> it's systemd that's doing the rename, in /boot/uEnv.txt, find the 
>>> "cmdline=coherent_pool=1M quiet" option and change it to: 
>>>
>>> cmdline="coherent_pool=1M net.ifnames=0 quiet" 
>>>
>>> Starting on Dec 9th 2016, we added the "net.ifnames=0" option by 
>>> default. 
>>>
>>> on your next reboot, it'll show up as eth1.. 
>>>
>>> Regards, 
>>>
>>>
>> Robert,
>>
>> Thanks for the suggestion. However, It doesn't seem to have helped:
>>
>> from dmesg output:
>>
>> [   21.314582] ax88179_178a 1-1:1.0 eth1: register 'ax88179_178a' at 
>> usb-musb-hdrc.1.auto-1, D-Link DUB-1312 USB 3.0 to Gigabit Ethernet 
>> Adapter, e4:6f:13:f3:df:43
>> [   21.316347] usbcore: registered new interface driver ax88179_178a
>> [   21.769915] omap-aes 5350.aes: OMAP AES hw accel rev: 3.2
>> [   21.813675] omap-sham 5310.sham: hw accel on OMAP rev 4.3
>> [   23.989152] asoc-simple-card sound: i2s-hifi <-> 48038000.mcasp 
>> mapping ok
>> [   24.099140] ax88179_178a 1-1:1.0 enxe46f13f3df43: renamed from eth1
>>
>> debian@beaglebone:~$ cat /proc/cmdline
>> console=ttyO0,115200n8 root=UUID=74cfcc82-bdc4-483a-bcbd-cce4ad70ba00 ro 
>> rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet
>>
>> Currently, I have a udev rule in place:
>>
>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="ax88179_178a", 
>> ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="enx*", NAME="eth1"
>>
>> Although I have also tried it with no udev rule. I also don't have a 
>> systemd.link configuration in place.
>>
>> debian@beaglebone:~$ uname -a
>> Linux beaglebone 4.4.26-ti-r59 #4 SMP Wed Feb 22 00:13:46 UTC 2017 armv7l 
>> GNU/Linux
>>
>> The kernel is a kernel I built from the r59 tag with a slightly different 
>> UART driver configuration.
>>
>> jon.
>>
>>
> It turns out that the following command is sufficient to disable the 
> mangled interface names:
>
>  sudo ln -sf /dev/null /etc/udev/rules.d/80-net-setup-link.rules
>
> and, in fact, net.ifnames=0 didn't seem to have any effect one way or the 
> other.
>
> Also, with the shorter interface name, DHCP now works on the renamed 
> interface - I have a suspicion that it was failing previously because the 
> enxe46f13f3df43 was at the limit of a char array length in a structure 
> defined in dhclient and this ultimately caused a downstream issue in the 
> AF_PACKET handler within the implementation of the bind system call) 
> because of the lack of a trailing null - all a supposition, of course.
>
> jon
>

The reason net.ifnames=0 didn't work appears to be related to this 
issue: 
http://askubuntu.com/questions/811295/73-usb-net-by-mac-rules-issue-with-net-ifnames/895533#895533.

In particular, net.ifnames=0 works if and only 
if /lib/udev/rules.d/73-usb-net-by-mac.rules is changed so that:

IMPORT{cmdline}="net.ifnames", ENV{net.ifnames}=="0", 
GOTO="usb_net_by_mac_end"

becomes:

IMPORT{cmdline}="net.ifnames"
ENV{net.ifnames}=="0", GOTO="usb_net_by_mac_end"

With respect to the DHCP errors, I found that dhclient fails immediately if 
the interface name is: enxe46f13f3df43:

Internet Systems Consortium DHCP Client 4.3.1

Copyright 2004-2014 Internet Systems Consortium.

All rights reserved.

For info, please visit https://www.isc.org/software/dhcp/


Bind socket to interface: No such device


If you think you have received this message due to a bug rather

than a configuration issue please read the section on submitting

bugs on either our web page at www.isc.org or in the README file

before submitting a bug.  These pages explain the proper

process and the information we find helpful for debugging..


exiting.

fails in a different way if the interface name is enxe46f13f3df4 


Internet Systems Consortium DHCP Client 4.3.1

Copyright 2004-2014 Internet Systems Consortium.

All rights reserved.

For info, please visit https://www.isc.org/software/dhcp/


Listening on LPF/enxe46f13f3df4/e4:6f:13:f3:df:43

Sending on   LPF/enxe46f13f3df4/e4:6f:13:f3:d

Re: [beagleboard] Issues with configuration of USB Ethernet adapter under Debian

[Jon Seymour]

On Wednesday, 22 March 2017 11:58:26 UTC+11, Jon Seymour wrote:
>
>
>
> On Wednesday, 22 March 2017 01:08:22 UTC+11, RobertCNelson wrote:
>>
>> On Mon, Mar 20, 2017 at 9:37 PM, Jon Seymour <jon.s...@gmail.com> wrote: 
>>
>> > Can anyone help me understand why this isn't working as expected? 
>>
>> it's systemd that's doing the rename, in /boot/uEnv.txt, find the 
>> "cmdline=coherent_pool=1M quiet" option and change it to: 
>>
>> cmdline="coherent_pool=1M net.ifnames=0 quiet" 
>>
>> Starting on Dec 9th 2016, we added the "net.ifnames=0" option by default. 
>>
>> on your next reboot, it'll show up as eth1.. 
>>
>> Regards, 
>>
>>
> Robert,
>
> Thanks for the suggestion. However, It doesn't seem to have helped:
>
> from dmesg output:
>
> [   21.314582] ax88179_178a 1-1:1.0 eth1: register 'ax88179_178a' at 
> usb-musb-hdrc.1.auto-1, D-Link DUB-1312 USB 3.0 to Gigabit Ethernet 
> Adapter, e4:6f:13:f3:df:43
> [   21.316347] usbcore: registered new interface driver ax88179_178a
> [   21.769915] omap-aes 5350.aes: OMAP AES hw accel rev: 3.2
> [   21.813675] omap-sham 5310.sham: hw accel on OMAP rev 4.3
> [   23.989152] asoc-simple-card sound: i2s-hifi <-> 48038000.mcasp mapping 
> ok
> [   24.099140] ax88179_178a 1-1:1.0 enxe46f13f3df43: renamed from eth1
>
> debian@beaglebone:~$ cat /proc/cmdline
> console=ttyO0,115200n8 root=UUID=74cfcc82-bdc4-483a-bcbd-cce4ad70ba00 ro 
> rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet
>
> Currently, I have a udev rule in place:
>
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="ax88179_178a", 
> ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="enx*", NAME="eth1"
>
> Although I have also tried it with no udev rule. I also don't have a 
> systemd.link configuration in place.
>
> debian@beaglebone:~$ uname -a
> Linux beaglebone 4.4.26-ti-r59 #4 SMP Wed Feb 22 00:13:46 UTC 2017 armv7l 
> GNU/Linux
>
> The kernel is a kernel I built from the r59 tag with a slightly different 
> UART driver configuration.
>
> jon.
>
>
It turns out that the following command is sufficient to disable the 
mangled interface names:

 sudo ln -sf /dev/null /etc/udev/rules.d/80-net-setup-link.rules

and, in fact, net.ifnames=0 didn't seem to have any effect one way or the 
other.

Also, with the shorter interface name, DHCP now works on the renamed 
interface - I have a suspicion that it was failing previously because the 
enxe46f13f3df43 was at the limit of a char array length in a structure 
defined in dhclient and this ultimately caused a downstream issue in the 
AF_PACKET handler within the implementation of the bind system call) 
because of the lack of a trailing null - all a supposition, of course.

jon

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/186bbf1d-bf20-4c25-a2f9-8bf5bcff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Issues with configuration of USB Ethernet adapter under Debian

[Jon Seymour]

On Wednesday, 22 March 2017 01:08:22 UTC+11, RobertCNelson wrote:
>
> On Mon, Mar 20, 2017 at 9:37 PM, Jon Seymour <jon.s...@gmail.com 
> > wrote: 
>
> > Can anyone help me understand why this isn't working as expected? 
>
> it's systemd that's doing the rename, in /boot/uEnv.txt, find the 
> "cmdline=coherent_pool=1M quiet" option and change it to: 
>
> cmdline="coherent_pool=1M net.ifnames=0 quiet" 
>
> Starting on Dec 9th 2016, we added the "net.ifnames=0" option by default. 
>
> on your next reboot, it'll show up as eth1.. 
>
> Regards, 
>
>
Robert,

Thanks for the suggestion. However, It doesn't seem to have helped:

from dmesg output:

[   21.314582] ax88179_178a 1-1:1.0 eth1: register 'ax88179_178a' at 
usb-musb-hdrc.1.auto-1, D-Link DUB-1312 USB 3.0 to Gigabit Ethernet 
Adapter, e4:6f:13:f3:df:43
[   21.316347] usbcore: registered new interface driver ax88179_178a
[   21.769915] omap-aes 5350.aes: OMAP AES hw accel rev: 3.2
[   21.813675] omap-sham 5310.sham: hw accel on OMAP rev 4.3
[   23.989152] asoc-simple-card sound: i2s-hifi <-> 48038000.mcasp mapping 
ok
[   24.099140] ax88179_178a 1-1:1.0 enxe46f13f3df43: renamed from eth1

debian@beaglebone:~$ cat /proc/cmdline
console=ttyO0,115200n8 root=UUID=74cfcc82-bdc4-483a-bcbd-cce4ad70ba00 ro 
rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet

Currently, I have a udev rule in place:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="ax88179_178a", 
ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="enx*", NAME="eth1"

Although I have also tried it with no udev rule. I also don't have a 
systemd.link configuration in place.

debian@beaglebone:~$ uname -a
Linux beaglebone 4.4.26-ti-r59 #4 SMP Wed Feb 22 00:13:46 UTC 2017 armv7l 
GNU/Linux

The kernel is a kernel I built from the r59 tag with a slightly different 
UART driver configuration.

jon.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/cf27f26c-fa77-4a5c-8e72-eff4e81897d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Issues with configuration of USB Ethernet adapter under Debian

[Jon Seymour]

On Tuesday, 21 March 2017 14:44:45 UTC+11, Jon Seymour wrote:
>
> On Tue, Mar 21, 2017 at 2:29 PM, Jon Seymour <jon.seym...@gmail.com> 
> wrote:
>
>>
>>
>> On Tuesday, 21 March 2017 14:18:41 UTC+11, William Hermans wrote:
>>>
>>> So, it's very likely you need the driver to come up before you can bring 
>>> the interface up. So, one option would be to "inject" your driver into the 
>>> initrd( very advanced ), or to write a systemd service( a systemd timer may 
>>> also work ) that sets the device up appropriately. 
>>>
>>> My thinking is that /etc/network/interfaces is loading devices *before* 
>>> the device driver for your adapter is loaded and running. You could 
>>> experiment by duplicating the exact commands you're using to manually bring 
>>> the interface up( the commands where it works ), and run that script at 
>>> boot through a systemd service. If that works, there is a good chance that 
>>> it's still loading slower than using the /etc/network/interfaces file . . . 
>>> but if that's the way you have to get it working at boot. It'll work. 
>>> Anyway, try that, and see if that work. If not, then what I said about the 
>>> interfaces file trying ot load your network interface too fast is probably 
>>> the case.
>>>
>>>  
>> William, thanks for your reply.
>>
>> I haven't tried those steps yet, but what I have tried is systemctl stop 
>> networking which causes all intefaces but usb0 to disappear (which is 
>> fortunate, since I need that!). In particular, it removes eth0 and lo0. If 
>> I then run systemctl start networking, the other interfaces come back. My 
>> interpretation is that even if there was  race condition during boot that 
>> might prevent enxe46f13f3df43 being detected on first boot, by the time 
>> it starts the second time, it should be there.  The command I am using to 
>> bring up the interface is ifup, which does consult the 
>> /etc/network/interfaces file. It isn't clear to me why a manually invoked 
>> ifup works, but a systemctl start networking doesn't, even after the system 
>> has been booted for a while.
>>
>>
> William,
>
> I just tried the systemctl stop/start networking scenario again and found 
> that it does actually work in this case, so the problem I initially 
> reported does appear to be a startup race condition as you suggest. 
>
> I'll investigate what can be done to fix a boot race along the lines you 
> suggest. Thanks for your help!
>
> jon.
>
>
A further wrinkle is that I get "Bind socket to interface: No such device" 
errors 
if I try to configure dhcp for the interface in /etc/network/interfaces for 
reasons that are not clear to me. Configuring a static ip address works 
fine. 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/325138bf-ee33-48d5-90e5-1af60952e127%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Issues with configuration of USB Ethernet adapter under Debian

[Jon Seymour]

On Tue, Mar 21, 2017 at 2:29 PM, Jon Seymour <jon.seym...@gmail.com> wrote:

>
>
> On Tuesday, 21 March 2017 14:18:41 UTC+11, William Hermans wrote:
>>
>> So, it's very likely you need the driver to come up before you can bring
>> the interface up. So, one option would be to "inject" your driver into the
>> initrd( very advanced ), or to write a systemd service( a systemd timer may
>> also work ) that sets the device up appropriately.
>>
>> My thinking is that /etc/network/interfaces is loading devices *before*
>> the device driver for your adapter is loaded and running. You could
>> experiment by duplicating the exact commands you're using to manually bring
>> the interface up( the commands where it works ), and run that script at
>> boot through a systemd service. If that works, there is a good chance that
>> it's still loading slower than using the /etc/network/interfaces file . . .
>> but if that's the way you have to get it working at boot. It'll work.
>> Anyway, try that, and see if that work. If not, then what I said about the
>> interfaces file trying ot load your network interface too fast is probably
>> the case.
>>
>>
> William, thanks for your reply.
>
> I haven't tried those steps yet, but what I have tried is systemctl stop
> networking which causes all intefaces but usb0 to disappear (which is
> fortunate, since I need that!). In particular, it removes eth0 and lo0. If
> I then run systemctl start networking, the other interfaces come back. My
> interpretation is that even if there was  race condition during boot that
> might prevent enxe46f13f3df43 being detected on first boot, by the time
> it starts the second time, it should be there.  The command I am using to
> bring up the interface is ifup, which does consult the
> /etc/network/interfaces file. It isn't clear to me why a manually invoked
> ifup works, but a systemctl start networking doesn't, even after the system
> has been booted for a while.
>
>
William,

I just tried the systemctl stop/start networking scenario again and found
that it does actually work in this case, so the problem I initially
reported does appear to be a startup race condition as you suggest.

I'll investigate what can be done to fix a boot race along the lines you
suggest. Thanks for your help!

jon.



> --
> 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/RFbRNJCk7l8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/b8121485-46b9-43b2-a4a8-436b7a5c8454%40googlegroups.com
> <https://groups.google.com/d/msgid/beagleboard/b8121485-46b9-43b2-a4a8-436b7a5c8454%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAH3AnroH_JCP%3DZ7Atj0gL4xJcYWO%2BOyhFKY%3Dcq3KWVND3HNWcQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Issues with configuration of USB Ethernet adapter under Debian

[Jon Seymour]

On Tuesday, 21 March 2017 14:18:41 UTC+11, William Hermans wrote:
>
> So, it's very likely you need the driver to come up before you can bring 
> the interface up. So, one option would be to "inject" your driver into the 
> initrd( very advanced ), or to write a systemd service( a systemd timer may 
> also work ) that sets the device up appropriately. 
>
> My thinking is that /etc/network/interfaces is loading devices *before* 
> the device driver for your adapter is loaded and running. You could 
> experiment by duplicating the exact commands you're using to manually bring 
> the interface up( the commands where it works ), and run that script at 
> boot through a systemd service. If that works, there is a good chance that 
> it's still loading slower than using the /etc/network/interfaces file . . . 
> but if that's the way you have to get it working at boot. It'll work. 
> Anyway, try that, and see if that work. If not, then what I said about the 
> interfaces file trying ot load your network interface too fast is probably 
> the case.
>
>  
William, thanks for your reply.

I haven't tried those steps yet, but what I have tried is systemctl stop 
networking which causes all intefaces but usb0 to disappear (which is 
fortunate, since I need that!). In particular, it removes eth0 and lo0. If 
I then run systemctl start networking, the other interfaces come back. My 
interpretation is that even if there was  race condition during boot that 
might prevent enxe46f13f3df43 being detected on first boot, by the time it 
starts the second time, it should be there.  The command I am using to 
bring up the interface is ifup, which does consult the 
/etc/network/interfaces file. It isn't clear to me why a manually invoked 
ifup works, but a systemctl start networking doesn't, even after the system 
has been booted for a while.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/b8121485-46b9-43b2-a4a8-436b7a5c8454%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Issues with configuration of USB Ethernet adapter under Debian

[Jon Seymour]

 

I am trying to use d D-Link USB Ethernet with Debian 8.7 running on BBB.


The device describes itself as: "D-Link DUB-1312 USB 3.0 to Gigabit 
Ethernet Adapter".


The lsusb output is: 


"Bus 001 Device 002: ID 2001:4a00 D-Link Corp."


The driver for this device is ax88179_178a which is loaded into the kernel 
as a module.

 

The driver finds the device:


[   21.274812] ax88179_178a 1-1:1.0 eth1: register 'ax88179_178a' at 
usb-musb-hdrc.1.auto-1, D-Link DUB-1312 USB 3.0 to Gigabit Ethernet 
Adapter, e4:6f:13:f3:df:43

[   21.280951] usbcore: registered new interface driver ax88179_178a

[   21.791100] omap-sham 5310.sham: hw accel on OMAP rev 4.3

[   21.836014] omap-aes 5350.aes: OMAP AES hw accel rev: 3.2

[   23.920271] asoc-simple-card sound: i2s-hifi <-> 48038000.mcasp mapping 
ok

[   24.088282] ax88179_178a 1-1:1.0 enxe46f13f3df43: renamed from eth1


If I manually bring enxe46f13f3df43 up, then I can configure it and get a 
working connection to the internet.


I wanted to automatically bring up the device to use DHCP but when I added:


   auto enxe46f13f3df43

   iface enxe46f13f3df43 inet dhcp


to /etc/network/interfaces the interface was not brought up automatically 
(even after reboot)


I tried to statically configured the device with:


auto enxe46f13f3df43

iface enxe46f13f3df43 inet static

address 192.168.1.100

network 255.255.255.0

gateway 192.168.1.1


but the interface also did not come up automatically in this case. It would 
come up correctly configured if I manually ran ifup enxe46f13f3df43.


I also tried to change the interface name to eth1 using 
/etc/udev/rules.d/71-local-rules


# Auto generated by RootStock-NG: setup_sdcard.sh

# udevadm info -q all -p /sys/class/net/eth0 --attribute-walk


# BeagleBone: net device ()

SUBSYSTEM=="net", ACTION=="add", KERNELS=="enxe46f13f3df43", 
ATTR{dev_id}=="0x0", ATTR{type}=="1", NAME="eth1"


I also tried to use the systemd.link feature by creating a file called 
/etc/systemd/network/10-local.link with these contents:


[Match]

Driver=ax88179_178a


[Link]

Name=eth1


So, there are two problems here:


- the interface is not being configured automatically

- I can't rename the interface with either udevd or systemd.link 
configuration


Can anyone help me understand why this isn't working as expected?



-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/02c92417-7142-41c8-8564-f202658fce00%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Why is the SPI0 clock output configured as an input???

[Jon Turner]

>
>
> The pin direction is only relevant for GPIO. For subsystems like SPI, the 
> pin direction is defined by the subsystem, not the pin direction defined by 
> pinctrl-single.
>
> Regards,
> John
>
>
Hmm, ok. So do the configuration bits have some other interpretation when 
the pin is not configured
as a gpio? If so, where is this documented? 

Jon 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/96bee223-50d9-4913-9194-f4b6a3648e05%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Why is the SPI0 clock output configured as an input???

[Jon Turner]

The overlay for the SPI0 interface includes the following lines

 pinctrl-single,pins = <  
  0x150 0x30 /* spi0_sclk, INPUT_PULLUP | MODE0 */  
  0x154 0x30 /* spi0_d0, INPUT_PULLUP | MODE0 */  
  0x158 0x10 /* spi0_d1, OUTPUT_PULLUP | MODE0 */  
  0x15c 0x10 /* spi0_cs0, OUTPUT_PULLUP | MODE0 */  
 >;  


Notice the first line, which specifies that the spi0 clock signal is an 
input with a pullup enabled.
This does not make sense to me, since every diagram I have seen (for 
example in Derek Molloy's
book, Exploring Beaglebone) shows the clock signal as an *output* from the 
BeagleBone. I have checked
the BeagleBone schematic and the processor pin for this signal connects 
only to the P9 header.
So the only way it would make sense for this pin to be an input is if the 
user is expected to have
a clock generation circuit on the cape. It's hard for me to imagine that 
this is the intended usage.

I have seen this same configuration for the overlay in multiple places, so 
I am guessing it is
correct, but I cannot understand why. Can someone knowledgable out there 
please enlighten me?

Thanks,

Jon Turner

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/55a9f2a1-abf0-4225-8b55-e2cdc27eeb47%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: problems loading custom overlay and disabling BB-UART1.

[Jon Seymour]

Partially answering my own questions...

On Tuesday, 21 February 2017 16:07:22 UTC+11, Jon Seymour wrote:
>
>
>
> * what could be causing BB-UART1-RS485 to fail during boot, but succeed 
> later on when I manually load it?
>

This question is still open.
 

> * what system component might be causing BB-UART1 to load "by itself"? how 
> do I prevent this happening?
>

The configuration in /etc/default/capemgr was causing BB-UART1 to be 
loaded. If I changed that to CAPE=BB-UART1-RS485, then the 2nd attempt to 
load BB-UART1-RS485 succeeds. This probably provides me with the workaround 
I need, but I am still curious to understand why the overlay fails to load 
when I specify it as a boot argument, but loads later on.

jon.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/63209f73-684b-42a7-8a3b-3fdaba763bdc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] problems loading custom overlay and disabling BB-UART1.

[Jon Seymour]

I wanted to enable two custom overlays BB-UART1-RS485, BB-UART2-RS485 at 
boot. 

To enable BB-UART1-RS485, I need to disable BB-UART1, to I added these 
lines to /boot/uEnv.txt

cape_disable=bone_capemgr.disable_partno=BB-UART1
cape_enable=bone_capemgr.enable_partno=BB-UART1-RS485,BB-UART2-RS485

When I reboot, there are attempts to load BB-UART1-RS485 and 
BB-UART2-RS485, but
only the attempt to load BB-UART1-RS485 fails.

[2.284859] bone_capemgr bone_capemgr: Baseboard: 
'A335BNLT,00C0,2716BBBK1C19'
[2.284916] bone_capemgr bone_capemgr: 
compatible-baseboard=ti,beaglebone-black - #slots=4
[2.324923] bone_capemgr bone_capemgr: Invalid signature '' at 
slot 0
[2.332414] bone_capemgr bone_capemgr: slot #0: No cape found
[2.376837] bone_capemgr bone_capemgr: slot #1: No cape found
[2.420834] bone_capemgr bone_capemgr: slot #2: No cape found
[2.464833] bone_capemgr bone_capemgr: slot #3: No cape found
[2.470895] bone_capemgr bone_capemgr: enabled_partno PARTNO 
'BB-UART1-RS485' VER 'N/A' PR '0'
[2.470907] bone_capemgr bone_capemgr: slot #4: override
[2.470920] bone_capemgr bone_capemgr: Using override eeprom data at 
slot 4
[2.470935] bone_capemgr bone_capemgr: slot #4: 'Override Board 
Name,00A0,Override Manuf,BB-UART1-RS485'
[2.471034] bone_capemgr bone_capemgr: enabled_partno PARTNO 
'BB-UART2-RS485' VER 'N/A' PR '0'
[2.471045] bone_capemgr bone_capemgr: slot #5: override
[2.471056] bone_capemgr bone_capemgr: Using override eeprom data at 
slot 5
[2.471069] bone_capemgr bone_capemgr: slot #5: 'Override Board 
Name,00A0,Override Manuf,BB-UART2-RS485'
[2.471443] bone_capemgr bone_capemgr: initialized OK.
[2.473391] PM: bootloader does not support rtc-only!
[2.474234] omap_rtc 44e3e000.rtc: setting system clock to 2000-01-01 
00:37:50 UTC (946687070)
[2.474261] of_cfs_init
[2.474364] of_cfs_init: OK
[2.482626] omap_uart 48024000.serial: no wakeirq for uart2
[2.485050] 48024000.serial: ttyO2 at MMIO 0x48024000 (irq = 187, 
base_baud = 300) is a OMAP UART2
[2.485624] bone_capemgr bone_capemgr: slot #5: dtbo 
'BB-UART2-RS485-00A0.dtbo' loaded; overlay id #0
[2.486405] PM: Hibernation image not present or could not be loaded.
[3.489130] bone_capemgr bone_capemgr: loader: failed to load slot-4 
BB-UART1-RS485:00A0 (prio 0)
[5.589966] EXT4-fs (mmcblk1p1): mounted filesystem with ordered data 
mode. Opts: (null)

... at some time later, something (not me) tries to load BB-UART1

[9.330248] bone_capemgr bone_capemgr: part_number 'BB-UART1', version 
'N/A'
[9.330280] bone_capemgr bone_capemgr: slot #6: override
[9.330296] bone_capemgr bone_capemgr: Using override eeprom data at 
slot 6
[9.330312] bone_capemgr bone_capemgr: slot #6: 'Override Board 
Name,00A0,Override Manuf,BB-UART1'
[9.348185] omap_uart 48022000.serial: no wakeirq for uart1
[9.363130] 48022000.serial: ttyO1 at MMIO 0x48022000 (irq = 188, 
base_baud = 300) is a OMAP UART1
[9.366396] bone_capemgr bone_capemgr: slot #6: dtbo 
'BB-UART1-00A0.dtbo' loaded; overlay id #1

... I tried to load BB-UART1-RS485 while BB-UART1 was loaded, to check the 
symptoms

[  319.949361] bone_capemgr bone_capemgr: part_number 'BB-UART1-RS485', 
version 'N/A'
[  319.949397] bone_capemgr bone_capemgr: slot #7: override
[  319.949413] bone_capemgr bone_capemgr: Using override eeprom data at 
slot 7
[  319.949429] bone_capemgr bone_capemgr: slot #7: 'Override Board 
Name,00A0,Override Manuf,BB-UART1-RS485'
[  319.951146] bone_capemgr bone_capemgr: slot #7: BB-UART1-RS485 conflict 
P9.24 (#6:BB-UART1)
[  319.960040] bone_capemgr bone_capemgr: slot #7: Failed verification

... I then removed BB-UART1

[  343.829338] bone_capemgr bone_capemgr: Removed slot #6

... And tried to load BB-UART1-RS485, which succeeded

[  345.580484] bone_capemgr bone_capemgr: part_number 'BB-UART1-RS485', 
version 'N/A'
[  345.580518] bone_capemgr bone_capemgr: slot #8: override
[  345.580534] bone_capemgr bone_capemgr: Using override eeprom data at 
slot 8
[  345.580550] bone_capemgr bone_capemgr: slot #8: 'Override Board 
Name,00A0,Override Manuf,BB-UART1-RS485'
[  345.589660] omap_uart 48022000.serial: no wakeirq for uart1
[  345.593608] 48022000.serial: ttyO1 at MMIO 0x48022000 (irq = 188, 
base_baud = 300) is a OMAP UART1
[  345.594399] bone_capemgr bone_capemgr: slot #8: dtbo 
'BB-UART1-RS485-00A0.dtbo' loaded; overlay id #1

Questions: 

* what could be causing BB-UART1-RS485 to fail during boot, but succeed 
later on when I manually load it?
* what system component might be causing BB-UART1 to load "by itself"? how 
do I prevent this happening?

jon.

-- 
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...@googl

[beagleboard] some questions on linux, RS485, omap_uart, omap8250

[Jon Seymour]

 above indicative of a bug in the omap8250 
driver?
* Is there a better way to arrange for a particular driver to be bound to a 
particular device? 
* in particular, Is there a way to prevent omap8250 from automatically 
binding to the 48024000.serial device when that device is created by the 
loading of the overlay?

jon.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/8441e901-9fe9-40ab-99a2-87bc9304a5d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Building a variant of the linux-image archive used by the image-builder project

[Jon Seymour]

On Thursday, 16 February 2017 15:23:01 UTC+11, RobertCNelson wrote:
>
> On Wed, Feb 15, 2017 at 9:07 PM, Jon Seymour <jon.s...@gmail.com 
> > wrote: 
> > I have been trying to build a linux-image debian archive from the tip of 
> the 
> > 4.4 branch of https://github.com/beagleboard/linux. 
> ...
>
> use "make deb-pkg" 
>
> For, 4.4.26-ti-r59 would be: 
>
> fakeroot make -j5 ARCH=arm  LOCALVERSION=-ti-r59 CROSS_COMPILE= 
> KDEB_PKGVERSION=1jessie KDEB_SOURCENAME=linux-upstream 
> KBUILD_DEBARCH=armhf DEBEMAIL=robert...@gmail.com  
> DEBFULLNAME=rcn-ee deb-pkg 
>
> replace, DEBEMAIL, DEBFULLNAME, and KDEB_PKGVERSION with your own 
> versions.. 
>

Robert,

Thanks for your reply - that did what I expected it t do.

jon.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/408671cb-7524-4b09-9904-4fc8afa67497%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Building a variant of the linux-image archive used by the image-builder project

[Jon Seymour]

I have been trying to build a linux-image debian archive from the tip of 
the 4.4 branch of https://github.com/beagleboard/linux.

I wasn't able to find a script which seemed to do this, so I ran a command 
like this in a chroot jail on an arm build host:

 make-kpkg --initrd --revision=acme kernel_image

I used the a kernel config from 4.4.26-ti-r59 that had been edited with 
make oldconfig to add one additional module.

The command ran without error and produced a package successfully, but the 
generated archive was missing all the expected .dtb files in 
/boot/dtbs/{version}. These files ARE in the version of the linux-image 
archive that the image builder uses to build new BeagleBone jessie images.

I checked the man pages for make-kpkg and kernel-package to see if there 
were any options I needed to specify to include the device tree binaries 
but I didn't see any.

I also tried running build_deb_in_arm_chroot.sh but this doesn't seem to 
produce a debian archive.

Is the script that builds the linux-image debian archive used by the 
image-builder available somewhere? 

jon.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/6d44beed-e93f-48f6-abfb-ef2acb65bb89%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: [beaglebone] GNU Screen terminates at SSH logoff

[Jon Kloske]

Sorry for necromancing this thread, but I've just spent a little while 
trying to solve this issue and the suggestions of logind.conf didn't help. 
I'm using Angstrom from a few years ago, and I did find the solution 
finally to this problem and thought I'd share : I actually had to edit the 
dropbear config to get this to work. The basic idea is to edit 
/lib/systemd/system/dropbear\@.service and add a line right at the end that 
reads "KillMode=process" (yes this seems like it would kill processes on 
logout, but in fact it ~doesn't~ do this when you add this line, cool huh). 
Then reboot to apply.

root@beaglebone:/lib/systemd/system# cat dropbear\@.service
[Unit]
Description=SSH Per-Connection Server
Requires=dropbearkey.service
After=syslog.target dropbearkey.service

[Service]
ExecStart=-/usr/sbin/dropbear -i -r /etc/dropbear/dropbear_rsa_host_key -p 
22
ExecReload=/bin/kill -HUP $MAINPID
StandardInput=socket
KillMode=process

>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/538514e7-2ae7-483f-a131-ad934ade0f6a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PWM On Beaglebone black with Jessie

[hoffman . jon]

Have you solved the problem that you were having?  I am unsure why you are 
getting the error:

P9_42 pinmux file not found!
cape-universala overlay not found

I am currently trying to figure out how the PWM pins work in the 4.1+ 
Kernel and it appears that after each reboot the *pwmchip** links in the 
*/sys/class/pwm/* directory link to different directories in the *ocp* 
directory.  For P9.42, look for the pwmchip link that links to the 
*/sys/devices/platform/ocp/4830.epwmss/48300100.ecap/pwm/pwmchip? 
*directory and then your code works for me.

Jon


On Thursday, March 17, 2016 at 10:47:39 PM UTC-4, Walter Schilling wrote:
>
> OK, so here is where I am at:
> #1 I wrote the following script, and, well it worked great...  Until I had 
> to reboot my machine:
>
>
>
>
>
>
> *#!/bin/bash# SE3910 Real Time Systems# PWM Bash shell script.# Author: W. 
> Schilling# This script will enable PWM on the beaglebone connected to 
> ECAPPWM0.# It will set the duty cycle to the value passed in, which is a 
> value between 1 and 1.*
>
>
> *# Setup the pin as a PWM pin.config-pin P9.42 pwm*
>
>
> *# Export the control for the device, creating the directory structure 
> that we w$echo 0 > /sys/class/pwm/pwmchip0/export*
>
>
> *# Setup the period for PWM to be 1 to make things nice and easy to 
> work wit$echo  1 > /sys/class/pwm/pwmchip0/pwm0/period*
>
>
> *# Setup the duty cycle to the value passed in as $1echo $1 > 
> /sys/class/pwm/pwmchip0/pwm0/duty_cycle*
>
>
> *# Enable pwm echo 1 > /sys/class/pwm/pwmchip0/pwm0/enable*
>
> However, when I rebooted my machine, the pin failed to toggle.  I believe 
> I inadvertently did something with capes that wasn't enabled when I first 
> tried it.  I then tried this script on my home beaglebone, running Robert 
> Nelson's image bone-debian-8.3-lxqt-4gb-armhf-2016-02-21-4gb.img.  This 
> one, however, fails with the following:
>
> root@beaglebone:~# ./pwm2.sh 1000
> P9_42 pinmux file not found!
> cape-universala overlay not found
> run "config-pin overlay cape-universala" to load the cape
> ./pwm2.sh: line 12: echo: write error: Device or resource busy
> ./pwm2.sh: line 15: /sys/class/pwm/pwmchip0/pwm0/period: No such file or 
> directory
> ./pwm2.sh: line 18: /sys/class/pwm/pwmchip0/pwm0/duty_cycle: No such file 
> or directory
> ./pwm2.sh: line 21: /sys/class/pwm/pwmchip0/pwm0/enable: No such file or 
> directory
> root@beaglebone:~# 
>
> I've tried the following, which results in different errors but still 
> errors:
> root@beaglebone:~# config-pin overlay cape-universaln
> Loading cape-universaln overlay
> bash: line 0: echo: write error: File exists
> Error loading device tree overlay file: cape-universaln
> root@beaglebone:~# ./pwm2.sh 1000
> P9_42 pinmux file not found!
> cape-universala overlay not found
> run "config-pin overlay cape-universala" to load the cape
> ./pwm2.sh: line 12: echo: write error: Device or resource busy
> ./pwm2.sh: line 15: /sys/class/pwm/pwmchip0/pwm0/period: No such file or 
> directory
> ./pwm2.sh: line 18: /sys/class/pwm/pwmchip0/pwm0/duty_cycle: No such file 
> or directory
> ./pwm2.sh: line 21: /sys/class/pwm/pwmchip0/pwm0/enable: No such file or 
> directory
> root@beaglebone:~# 
>
> Ideas to try next?
>
> Walt
> -- 
> 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.
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/6c3fb83a-7fdb-4856-b218-b5766368f81d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] cmst (connman gui) fails to start on jessie (8.3)

[Jon Peterson]

this is a fairly recent install of Jessie, apt-get update/upgrade, and a 
few packages like tightvncserver, gksu, ntp, autocutsel, tightvncserver, 
leafpad, ... and I didn't ask explicitly for connman or cmst to be 
installed.

running from xterm "cmst" puts up a dialog box about installing a new icon 
definition file and then select "save".
there are two message on xterm:
Qt: XKEYBOARD extension not present on the X server.
The X11 connection broke (error 4). Did the X11 server die?
there is no system tray icon.

When I read the package details:
QT GUI for Connman with system tray icon

Graphical user interface to control the connman daemon. The connman daemon 
must be started as you normally would, this program just interfaces with 
that daemon. You can see what technologies and services connman has found, 
and for wifi services an agent is registered to assist in obtaining the 
information from you necessary to logon to the wifi service. 


I don't get a GUI window presented.


The Start/Internet/Connman UI Setup puts up the same dialog box as above, 
and then, after "save" does nothing.


I guess the question I have as a new user, is do I even need connman and 
cmst or can I remove them both and mange the network setup manually? Am I 
missing something, because trying to learn connman looks like a lot of 
learning curve for not much gain...


ps I am finding Jessie a lot harder to get going on than Wheezy. there are 
so many changes it's almost like starting over again.


-- 
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: How to enable all i2c

[Jon Peterson]

My experience is that the echo only works if you are logged on as root. it 
never worked with sudo for me.
I found uEnv.txt at /boot/uEnv.txt

For fear of opening a can of worms, the numbering of the three I2C buses 
is, for lack of a better term, illogical. From the aspect of an engineer, 
programmer or human -- especially someone new to BB and/or to embedded 
systems.

debian@beaglebone:/$ ls /sys/class/i2c-dev/ -l
total 0
lrwxrwxrwx 1 root root 0 Mar  3 19:03 i2c-0 - 
../../devices/ocp.3/44e0b000.i2c/i2c-0/i2c-dev/i2c-0
lrwxrwxrwx 1 root root 0 Mar  3 19:03 i2c-1 - 
../../devices/ocp.3/4819c000.i2c/i2c-1/i2c-dev/i2c-1
lrwxrwxrwx 1 root root 0 Mar  3 19:03 i2c-2 - 
../../devices/ocp.3/4802a000.i2c/i2c-2/i2c-dev/i2c-2

so:
i2c-0 is hardware bus 0
i2c-1 is hardware bus 2
i2c-2 is hardware bus 1

Both having to find and edit uEnv.txt and then having to deal with the 
mixed up numbering just doesn't make any sense to me...
There you have it, my bias.



-- 
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: How to enable all i2c

[Jon Peterson]

My experience is that the echo only works if you are logged on as root. it 
never worked with sudo for me.
I found uEnv.txt at /boot/uEnv.txt

For fear of opening a can of worms, the numbering of the three I2C buses 
is, for lack of a better term, illogical. From the aspect of an engineer, 
programmer or human -- especially someone new to BB and/or to embedded 
systems.

http://beaglebone.cameon.net/home/i2c-devices
debian@beaglebone:/$ ls /sys/class/i2c-dev/ -ltotal 0
lrwxrwxrwx 1 root root 0 Mar  3 19:03 i2c-0 - 
../../devices/ocp.3/44e0b000.i2c/i2c-0/i2c-dev/i2c-0
lrwxrwxrwx 1 root root 0 Mar  3 19:03 i2c-1 - 
../../devices/ocp.3/4819c000.i2c/i2c-1/i2c-dev/i2c-1
lrwxrwxrwx 1 root root 0 Mar  3 19:03 i2c-2 - 
../../devices/ocp.3/4802a000.i2c/i2c-2/i2c-dev/i2c-2

so:
i2c-0 is hardware bus 0
i2c-1 is hardware bus 2
i2c-2 is hardware bus 1

Both having to find and edit uEnv.txt and then having to deal with the 
mixed up numbering just doesn't make any sense to me...
There you have it, my bias.



-- 
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 SRM Rev C.1 page 114, Figure 70. Cape Board Dimensions

[Jon Peterson]

Does anyone know if there is an update to this figure anywhere, which 
accurately shows the locations of TP5-8?

-- 
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: Measuring frequency

[Jon E]

Hi, 

I've got a simple frequency counting PRU example on github, might give you 
some ideas. It should be trivial to change the polling / reporting 
frequency, but not sure it will run as fast as you want?

https://github.com/dresco/pru_examples/tree/master/frequency

HTH,
Jon



On Thursday, 26 February 2015 02:34:11 UTC, Rick M wrote:

 I need to accurately measure frequency from a pressure transducer, and 
 make it available on a LAN. A BBB ought to be able to do this, if the PRU 
 can be made to accurately measure the frequency. 

 The frequency range is 30 kHz to 42 kHz. I need better than 0.01% 
 accuracy. Overall latency in the reading is not too much of an issue, so 
 long as it's not more than a few seconds. 

 Does the PRU let me connect a GPIO to a counter internally? I can measure 
 some cycles and compare that to a crystal-driven counter. 

 Has anyone done this? 

 TIA, 

 -- 
 Rick Mann 
 rm...@latencyzero.com javascript: 




-- 
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] Re: how to make pwm_P8_13 low on boot?

[Jon Escombe]

Hi Jan,

I had another look at this, was able to replicate what you are seeing, 
and think I know what's going on..


The part-number 'bone_pwm_P8_13' is already included in the kernel 
build. I'm not really sure of the mechanics, but when doing a build from 
the git repository, all the .dts files in the /firmware/capes folder get 
compiled to individual .dtbo files, and from there into object files, 
and then combined into a single built-in.o file.


The end result of this appears to be that putting an overlay file for 
one of these built-in part-numbers into /lib/firmware doesn't achieve 
anything, it just doesn't get read (even if you increment the version).


Anyway, it's an easy fix - once you know what's going on!! You should 
just need to change the part-number to something else unique (and the 
file name to suit), and then the options can be set in your overlay as 
you'd expect..


Hope this helps,
Jon.


On 26/11/14 10:11, janszymanski12...@gmail.com wrote:

Good idea, thanks. I will try it. I think the positive pulse will be so
short that it will not be able to move the motor.

On Wednesday, November 26, 2014 8:29:31 PM UTC+11, Jon E wrote:

I'm not sure about that. Jan said before that it's only driven high
after loading the PWM driver, and the processor datasheet shows ball
T10 (P8_13) as driven low during/after reset.

Jan, not ideal, but to disable the output sooner you could load the
overlay through cape manager, and then write 0 to the run parameter
immedately afterwards. But I still think the correct approach is to
look at the devcetree/driver code and see why those parameters are
having no affect..

Regards,
Jon


--
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] Re: how to make pwm_P8_13 low on boot?

[Jon Escombe]

I used roughly the following process;

1) grab the original source file  copy to a local version

wget 
https://raw.githubusercontent.com/beagleboard/linux/3.8.13-bone66/firmware/capes/bone_pwm_P8_13-00A0.dts


cp bone_pwm_P8_13-00A0.dts bone_pwm_local-00A0.dts

2) change the part-number in your local version of the .dts file

part-number = bone_pwm_P8_13;
---
part-number = bone_pwm_local_P8_13;

3) compile  copy to /lib/firmware

dtc -O dtb -o bone_pwm_local-00A0.dtbo -b 0 -@ bone_pwm_local-00A0.dts

cp bone_pwm_local-00A0.dtbo /lib/firmware/

4) load the am33xx_pwm overlay, plus your local config for your pin

echo am33xx_pwm  /sys/devices/bone_capemgr.*/slots
echo bone_pwm_local /sys/devices/bone_capemgr.*/slots

Those steps should be enough;

root@beaglebone:~# ls /sys/devices/ocp.*/pwm_test_P8_13.*/
driver  duty  modalias  period  polarity  power  run  subsystem  uevent

Regards,
Jon


On 04/12/14 23:21, janszymanski12...@gmail.com wrote:

OK, I did the renaming from bone_pwm_P8_13-00A0.*  into
bone_pwm_test-00A0.* and after reboot I have:

in slots:
  0: 54:PF---
  1: 55:PF---
  2: 56:PF---
  3: 57:PF---
  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
  5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
  7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART1
  8: ff:P-O-L Override Board Name,00A0,Override Manuf,SPI-4SS
  9: ff:P-O-L Override Board Name,00A0,Override Manuf,bone_eqep2b
10: ff:P-O-L Override Board Name,00A0,Override Manuf,bone_pwm_test
11: ff:P-O-L Override Board Name,00A0,Override Manuf,am33xx_pwm

but in  /sys/devices/ocp.3/pwm_test_P8_13.16 I have only:

root@beaglebone:/sys/devices/ocp.3/pwm_test_P8_13.16# ls
modalias  power  subsystem  uevent

My bone_pwm_test-00A0.dts and bone_pwm_test-00A0.dtb0 are in /lib/firmware
Do I need to make any changes to them after all (as the renaming only
doesn't work)?

Jan


--
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] Re: how to make pwm_P8_13 low on boot?

[Jon E]

I'm not sure about that. Jan said before that it's only driven high after 
loading the PWM driver, and the processor datasheet shows ball T10 (P8_13) 
as driven low during/after reset. 

Jan, not ideal, but to disable the output sooner you could load the overlay 
through cape manager, and then write 0 to the run parameter immedately 
afterwards. But I still think the correct approach is to look at the 
devcetree/driver code and see why those parameters are having no affect..

Regards,
Jon

On Wednesday, 26 November 2014 03:43:21 UTC, William Hermans wrote:

 IN short, use external hardware or do something cleaver like Peter G, and 
 reverse polarity. *OR* have an external switch that switches the PWM line 
 off, until you tell it to turn on. simples ?


-- 
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: GPIO Header Pins that can be muxed to the PRU

[Jon E]

Hi,

I think that's from an old SRM. Section 8.1.2 of the current (rev C.1) BBB 
SRM shows different pins and there is note of a correction in the change 
history..

Regards,
Jon

-- 
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: a question about asking questions

[Jon E]

Hi,

I thought it was a perfectly fair question - though I couldn't help, as 
I've not done much with the kernel PWM driver. 

Google turned up someone else with basically the same problem (initial pin 
state not reflecting their changes to the device tree config), but no 
answers. I guess in your shoes I'd start looking through the driver source, 
and trying to figure out where these options are meant to be processed.

Good luck!

Jon


On Tuesday, 25 November 2014 07:05:28 UTC, janszyma...@gmail.com wrote:

 Hi,

  I have still unresolved issue (no answer here for how to make pwm_P8_13 
 low on boot? ) and therefore
 trying to figure out if my question is:
 - too easy
 - too difficult
 - not interesting enough
 - other?

 As I see there is generally a number of unanswered questions, would it be 
 possible for the moderator to give an indication in a simple style,
 something like: too easy, google it yourself or whatever, to avoid 
 frustration.

 Jan



-- 
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: GPIO Header Pins that can be muxed to the PRU

[Jon E]

Hi,

I believe the pins on P8 (11/12/15/16) that you've listed as used by the 
eMMC are free to use. I'd double check the schematic, but think the eMMC is 
connected as per the mode1 pinmux.

Jon.

-- 
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: PRU 2.1.0 production ready.

[Jon E]

Thanks Jason,

I recently found this PRU presentation from the Embedded Linux Conference 
Europe.

http://events.linuxfoundation.org/sites/events/files/slides/Enhancing%20RT%20Capabilities%20with%20the%20PRU%20final.pdf

Can't wait to see a bit more of this rpmsg driver framework!

Regards,
Jon

-- 
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] Multi camera project BeagleBlack

[Jon E]

Hi,

Fwiw - I've tried a few times to capture PAL or NTSC composite video over 
USB (with an easycap style adapter, various kernel versions up to the 
latest 3.14-ti branch) and have never been successful. It always chokes on 
the data transfer, and I believe it just can't handle the data rate for the 
isochronous transfer.

I've vaguely wondered about putting a decoder IC on a cape, and using the 
PRU to process the digital (BT656?) output, but haven't got further than 
just thinking about it..

Regards,
Jon


On Thursday, 9 October 2014 22:21:45 UTC+1, Peter Fearing wrote:

 Yes, and that's pretty much what we're thinking right now. The biggest 
 challenges at this point are the possibility of having to interpret ADC 
 input as a video stream (for Linux) and the need to create composite (NTSC) 
 output from the Beaglebone.



-- 
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] PRU and dts for IO definition in kernel 3.1x ?

[Jon E]

Hi,

I have some simple examples of direct reading/writing under 3.8 (setting 
mode 6, exclusive use etc)..

https://github.com/dresco/pru_examples

Have the device tree definitions have changed for 3.1x? I've not yet 
successfully built my PRU code under the new 3.14 kernel, so perhaps 
bone-pinmux-helper is no longer an option?

Regards,
Jon

On Thursday, 25 September 2014 04:12:53 UTC+1, Cedric Malitte wrote:

 Ok finally managed to build a dts using compatible='gpio-leds' for outputs 
 and I now have a 15Mhz output.

 I'll investigate why when I try to use pru code compiled from C, the 
 signal has a weird shape on the scope but using asm, it's a regular one.

 For inputs, I do not know yet if I should use compatible=gpio-keys or 
 something else, I did not find anything related to this yet.



 2014-09-24 13:17 GMT-04:00 Cedric Malitte cedric@gmail.com 
 javascript::

 Hi,

 so trying to get my things up and running, I wrote a program for the PRU 
 in asm to toggle 2 pins and read 4.

 In C, I manage to manipulate them because I'm using GPIO.
 But in asm... I try to interact with r30 and r31, and nothing really 
 happens...

 Im with kernel 3.15.

 Could someone guide me ? 
 I think I have to add a dts to declare pins and pinmux, but I feel a bit 
 lost on this point.

 In case, this is my asm source

 #include pru.h
 #include pru_macros.hp

 .origin 0
 .entrypoint MAIN


 MAIN:

  /* enable ocp wide accesses */

  LBCO r0, CONST_PRUCFG, 4, 4
  CLR r0, r0, 4
  SBCO r0, CONST_PRUCFG, 4, 4

  /* prepared pru to host shared memory */

  MOV r0, 0x00120
  MOV r1, CTPPR_0
  ST32 r0, r1

  MOV r0, 0x0010
  MOV r1, CTPPR_1
  ST32 r0, r1


  MOV r10, 0
  MOV r11, 0
  MOV r12, 0
  /* main */
 LOOP1:
 SET r30.t15  /* CLK high */ 
 MOV r10, r31.b0 /* Read in the data */ 

 QBBC CHKSENSOR2, r10.b0.t0 /* if r10.0, set r11.0 */
 SET r11, 0  
 CHKSENSOR2:
 QBBC CHKSENSOR3, r10.b0.t1 /* if r10.1, set r11.15 */
 SET r11, 15
 CHKSENSOR3:
 QBBC CHKSENSOR4, r10.b0.t2 /* if r10.2, set r12.0 */
 SET r12, 0
 CHKSENSOR4:
 QBBC ENDCHECK, r10.b0.t3 /* if r10.3, set r12.15 */
 SET r12, 15

 ENDCHECK:
 CLR r30.t15 /* CLK low  */ 
 LSL r11, r11, 1
 LSL r12, r12, 1
 ADD r0, r0, 1
 JMP LOOP1
  /* store results from r10,r11 into host memory */

  SBCO r10, CONST_PRUSHAREDRAM, 0, 8

  /* signal cpu we are done (never reached) */

  MOV r31.b0, PRU0_ARM_INTERRUPT + 16
  HALT


 Thanks,

 Cedric

 -- 
 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/DvlQWGZ5VEs/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 beagleboard...@googlegroups.com javascript:.
 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] Re: prussdrv to remoteproc

[Jon E]

Thanks,

I've also found the BeagleLogic 
https://github.com/abhishek-kakkar/BeagleLogic project that's using the 
remoteproc interface.

Am also just at the curious stage, it looks like remoteproc/rpmsg is the 
preferred interface going forward, but it seems much more complicated!

Regards,
Jon

On Saturday, 13 September 2014 22:10:48 UTC+1, Michael M wrote:

 I believe that PRUSpeak(https://github.com/deepakkarki/pruspeak/) makes 
 use of remoteproc. I haven't made the transition yet, but I'm definitely 
 curious about it. The complexity of implementing remoteproc seems much, 
 much greater than using UIO or /dev/mem mapping. What is the benefit of 
 using remoteproc over the other methods?

 On Friday, September 12, 2014 5:57:17 AM UTC-7, Cedric Malitte wrote:



 Le vendredi 12 septembre 2014 04:11:18 UTC-4, Jon E a écrit :

 Hi,

 Anyone know of example code that's using the newer remoteproc interface? 
 Also, is there a way to convert pasm binary files to elf format for the 
 firmware loader?

 Would like to play around with the latest 3.14 TI kernel, but haven't 
 been able to find much info on the PRU side..

 Thanks,
 Jon

 As I read here 
 http://processors.wiki.ti.com/index.php/PRU-ICSS_Getting_Started_Guide
 There are some examples included in the SDK.

 I'm downloading it to check that, but for now i'm still using the old 
 patch method to enable pruss :)

 Regards,
 Cedric 



-- 
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] prussdrv to remoteproc

[Jon E]

Hi,

Anyone know of example code that's using the newer remoteproc interface? 
Also, is there a way to convert pasm binary files to elf format for the 
firmware loader?

Would like to play around with the latest 3.14 TI kernel, but haven't been 
able to find much info on the PRU side..

Thanks,
Jon

-- 
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 unresponsive to VDD_5V

[Jon E]

Hi,

Similar to a couple of older threads I've found on searching, one of my 
BBB's (a rev B) has recently stopped powering up from VDD_5V (either the 
barrel jack or P9 connector).

Not sure what might have triggered this, nothing had changed in hardware 
setup for some time, power was permanently supplied from a 5V wall wart and 
it was being cleanly shutdown from software each day, and restarted from 
the on-board power button. Only things connected were ethernet, a USB RF 
dongle, and a hall effect sensor (powered from VDD_3V3B). Have since 
removed everything, and just attached a serial debug cable.

Timing to failure is a bit variable, from nothing at all, to a brief flash 
of the power LED, to getting several seconds into boot before it dies (have 
also tried running from a bench supply, but just the same results). I 
suppose the PMIC is shutting things down for a reason (it draws no current 
in this state), but it is still working fine from the USB_DC line. 

So I'm a bit stumped. Any ideas, or should I look for an RMA?

Thanks in advance,
Jon

-- 
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 unresponsive to VDD_5V

[Jon Escombe]

Thanks Gerald, have submitted a request..

Regards,
Jon

On 05/09/14 18:20, Gerald Coley wrote:

Go the RMA route so it can be looked at.

Gerald


On Fri, Sep 5, 2014 at 12:08 PM, Jon E jesco...@googlemail.com
mailto:jesco...@googlemail.com wrote:

Hi,

Similar to a couple of older threads I've found on searching, one of
my BBB's (a rev B) has recently stopped powering up from VDD_5V
(either the barrel jack or P9 connector).

Not sure what might have triggered this, nothing had changed in
hardware setup for some time, power was permanently supplied from a
5V wall wart and it was being cleanly shutdown from software each
day, and restarted from the on-board power button. Only things
connected were ethernet, a USB RF dongle, and a hall effect sensor
(powered from VDD_3V3B). Have since removed everything, and just
attached a serial debug cable.

Timing to failure is a bit variable, from nothing at all, to a brief
flash of the power LED, to getting several seconds into boot before
it dies (have also tried running from a bench supply, but just the
same results). I suppose the PMIC is shutting things down for a
reason (it draws no current in this state), but it is still working
fine from the USB_DC line.

So I'm a bit stumped. Any ideas, or should I look for an RMA?

Thanks in advance,
Jon


--
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] Simple PRU examples

[Jon E]

Hi, 

I've just been through the learning curve of getting started with PRU 
development, and have pushed some simple examples to GitHub.

Posting here in case they're of use to anyone else in the same position..

https://github.com/dresco/pru_examples

Regards,
Jon

-- 
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] Simple PRU examples

[Jon Escombe]

Hi,

No not really, not yet at least.

My immediate needs are pretty simple - just wanting to decouple any 
timing sensitive bits from my user space Linux code. Just frequency 
measurement, pwm etc..


I started off by downloading the TI PRU C compiler, but struggled a bit 
with the lack of examples (or maybe I just wasn't looking in the right 
places!). But yes, is fair to say I'd probably have used C if I'd 
stumbled across a useful library and documentation/examples sooner.


Anyway - I think it was a useful learning exercise going right back to 
basics, as all the features and peripherals of the BBB can be a bit 
overwhelming when moving from something like an AVR ;)


Regards,
Jon

On 29/08/14 15:37, Jason Kridner wrote:

Thanks! The minimalism is nice. Have you tried any of the other tools
like the PRU GCC compiler, Pruspeak or the web-based PRU debugger to see
if they are helpful?


On Fri, Aug 29, 2014 at 3:40 AM, Jon E jesco...@googlemail.com
mailto:jesco...@googlemail.com wrote:

Hi,

I've just been through the learning curve of getting started with
PRU development, and have pushed some simple examples to GitHub.

Posting here in case they're of use to anyone else in the same
position..

https://github.com/dresco/pru_examples

Regards,
Jon



--
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] Ubuntu 14.04 does not create dev/video with LI-5M03

[Jon Holcomb]

Hi all:

I am running Ubuntu 14.04 ( 3.14.5-arm7-x8) on my BB-xM.  When I attach the 
Leopard Imaging camera module ( LI5-M03) nothing is created in the /dev 
subdirectory and if I run motion it does not see the camera.  I added the 
camera = li5m03 line in the uEnv.  I tried to get this running in Quantal 
but can no longer upgrade that version and I cannot install motion under 
that version although it looks like it sees the camera. Any help will be 
appreciated!

Jon

-- 
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] Eclipse C and Remote Debugging

[Jon]

Your virtualbox network is likely just using NAT, so to the BBB it will 
appear that the traffic is coming from the host computer.

Agreeing with what Robert already said, I would start from the command line 
tools (gdb  gdbserver) and work up.

Regards,
Jon


On Thursday, 5 June 2014 07:35:03 UTC+1, Simon Platten wrote:

 Having thought about what is happening over night...I still don't 
 understand why Remote debugging from host is 192.168.1.100 ???

 I run Ubuntu 14.04 in Virtualbox on my Windows 7 x64 development system.  
 The I/P addresses for the various components are as follows:

 Ubuntu,  10.1.174.100
 Windows 7,192.168.1.100
 Beaglebone Black,  192.168.1.161


   

-- 
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] 3.15.0-rc8-bone1

[Jon]

Hi,

Was just trying out this kernel (using the update-kernel.sh script with the 
--exp-kernel option), and noticed that the uboot partition runs out of 
space during this process. 

Manually deleting the backup versions and copying the new files does the 
trick, but thought it was worth mentioning it as it's not trapped by the 
script as an error..

Regards,
Jon

-
Backing up uImage as uImage_bak...
`/boot/uboot/uImage' - `/boot/uboot/uImage_bak'
Backing up zImage as zImage_bak...
`/boot/uboot/zImage' - `/boot/uboot/zImage_bak'
Backing up uInitrd as uInitrd_bak...
`/boot/uboot/uInitrd' - `/boot/uboot/uInitrd_bak'
Backing up initrd.img as initrd.bak...
`/boot/uboot/initrd.img' - `/boot/uboot/initrd.bak'
-
Image Name:   3.15.0-rc8-bone1
Created:  Tue May  6 16:35:07 2014
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:6307664 Bytes = 6159.83 kB = 6.02 MB
Load Address: 80008000
Entry Point:  80008000
-
Image Name:   initramfs
Created:  Tue May  6 16:35:10 2014
Image Type:   ARM Linux RAMDisk Image (uncompressed)
Data Size:2934792 Bytes = 2866.01 kB = 2.80 MB
Load Address: 
Entry Point:  
-
`/boot/vmlinuz-3.15.0-rc8-bone1' - `/boot/uboot/zImage'
cp: writing `/boot/uboot/zImage': No space left on device
cp: failed to extend `/boot/uboot/zImage': No space left on device
`/boot/initrd.img-3.15.0-rc8-bone1' - `/boot/uboot/initrd.img'
cp: writing `/boot/uboot/initrd.img': No space left on device
cp: failed to extend `/boot/uboot/initrd.img': No space left on device
-

-- 
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] Beaglebone Black Ethernet Phy Not Detected on Boot.

[Jon]

fwiw, I'm seeing what *appears* to be this same issue on the latest board 
I've bought - occasionally there is no Ethernet connectivity on power-up, a 
physical power off/on always resolves it...

This is a rev B board, running the latest Debian test image with beta 3.13 
kernel, and has happened on both USB and DC power.

Regards,
Jon

On Tuesday, 11 March 2014 23:50:48 UTC, Gerald wrote:

 I know what I have seen. I know what I have replicated. And I know the SW 
 fix takes care of it.

 I also know it does not happen on every board and doe snot happen every 
 time. Do keep in mind that the board reset is not a HW reset. It is a SW 
 reset.

 The fix is in the latest image from Robert.  http://beagleboard.org/latest
 -images/

 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/d/optout.

Re: [beagleboard] Re: cannot ssh over USB Fist use of board

[Jon]

Hi, there was a problem with a corrupt key file on the Angstrom image that 
prevented SSH from working. 

Not sure if that's still the case with new boards, but if you search this group 
for 'unable to ssh' (or similar) there is a cloud9 script to fix it from the 
web interface. 

Alternatively, you could flash a recent Debian image if you've got a microSD 
card?

Regards, 
Jon

-- 
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] Best way to connect 0.5 - 4.5 vdc output sensor?

[Jon Kensy]

Hi all -

Trying to hook a pressure sensor that measures from 0 - 400 kPA up to my 
Beaglebone Black.  What is the best way to do this since the GPIO can only 
accept 1.8vdc max?  Are there any I2C sensors that measure a similar range?

Thanks!

-- 
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't SSH to the bone

[Jon Tabor]

This might be your issue.  It was with mine.

https://groups.google.com/d/msg/beagleboard/Ya2qE4repSY/q8_WkLcH5TwJ

On Tuesday, January 14, 2014 1:35:59 PM UTC-8, Steve Rayner wrote:

 I've connected the Beaglebone Black via USB cable. I'm using Windows7 and 
 I've installed the USB driver. I can get the 101 page via a web browser, 
 but I cannot connect to the beaglebone over SSH.

 If I try to connect via SSH using putty, I get; client unexpectedly closed 
 the connection.
 If I try to connect via serial COM7 9600 it just hangs
 If I try to connect using Gate One SSH in a web browser I get; Connection 
 closed by remote host.

 The bone doesn't like me. Please help.

 Steve


-- 
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: Wifi Adapter Recommendations

[Jon]

Fwiw, I'm using a TP-Link RL-WN725N (RTL8188EU chipset) with Roberts Debian 
images. Just worked out-of-the-box with his 3.12 kernels. Is only sending 
light logging traffic, but have never seen any issues over several weeks of 
uptime..

On Thursday, 26 December 2013 21:37:50 UTC, David Marquart wrote:

 Does anyone have a recommendation for a wifi adapter that works with 
 Robert Nelson's Ubuntu images?


-- 
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: Motion software / em28xx issue, fails with Watchdog timeout

[Jon]

Hi Robert,

Unfortunately 3.13-rc6 hasn't resolved my similar issues with the stk1160 
driver and an easycap dongle either.. 

Was worth a try though!

Regards,
Jon.


On Wednesday, 1 January 2014 15:48:41 UTC, RobertCNelson wrote:

 On Wed, Jan 1, 2014 at 5:08 AM, JJ jareli@gmail.com javascript: 
 wrote: 
  I confirm this issue is not only related to Arch, but also Debian 
 Wheezy. 
  They detect Easycap dongle fine, but motion doen't want to capture video 
  from it. 

 Can you retest with v3.13-rc6? 

 Regards, 

 -- 
 Robert Nelson 
 http://www.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/groups/opt_out.

Re: [beagleboard] Re: linux kernel 3.12.0-rc7 usb webcam 0bda:5801 uvcvideo hangs on beaglebone black

[Jon]

Hi Robert, 

Are there any plans for a 3.13-rc BBB kernel? USB video was still flakey for me 
with 3.12,and I think I read here that there were some more DMA fixes in 3.13?

Cheers, 
Jon 

-- 
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: linux kernel 3.12.0-rc7 usb webcam 0bda:5801 uvcvideo hangs on beaglebone black

[Jon]

On Saturday, 28 December 2013 15:04:33 UTC, RobertCNelson wrote:


 Was working on it yesterday, so far hdmi/cpufreq/usb works on teh bbb.. 

 https://github.com/RobertCNelson/linux-dev 
 am33x-v3.13 https://github.com/RobertCNelson/linux-devam33x-v3.13branch 

 as you'll find out, it's pretty minimal... 

 Regards, 

 -- 
 Robert Nelson 
 http://www.rcn-ee.com/ 


Cool thanks, will keep an eye on your site..

Regards,
Jon
 

-- 
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: Problem with microUSB connector

[Jon Tabor]

Mine has a similar issue, right out of the box.  Certain (most?) microUSB 
cables are loose in the socket, which causes the system to reset if it's 
bumped into or moved around.  It's not enough of an annoyance for me to RMA 
the unit, though.

Jon

On Wednesday, December 11, 2013 4:46:51 AM UTC-8, arunbarn...@gmail.com 
wrote:

 Hi,

 I just noticed a problem with the beaglebone black, the microUSB connector 
 wears out very quickly, I have two units which have this problem, I bought 
 these some months ago, I used a new microUSB cable but the problem remained.

 Although it is not a serious problem for me as I use the external +5VDC 
 connector and ethernet cable, I still would like to know if others have had 
 this problem.

 thanks
 a


-- 
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] NTSC/PAL video input

[Jon Escombe]

Thanks,

The defconfig for the 3.12.0-rc5-bone6 kernel does not appear to have DMA 
disabled, I was hoping this might make all the difference, but it seems not 
:(

Jon


On Monday, 21 October 2013 13:19:42 UTC+1, Brent wrote:

 As far as you did, it appears.  I was not the one who actually worked with 
 the ezcap or the USB-Live 2 devices, but the failure was attributed to the 
 BBB's inability to support isochronous transfers from the device.  Devices 
 using the uvcvideo driver seems to work just fine, but others do not.


 On Sun, Oct 20, 2013 at 12:59 PM, jesc...@googlemail.com javascript:wrote:

 Hi Brent,

 Just wondering how far you got with the ezcap device? 

 I've also got a requirement to capture some analog video, but have been 
 hitting a brick wall with my ezcap clone (STK1160 driver). Seems it's 
 failing to read a full frame each time, resulting in a corrupt picture. I 
 see the same issue with mplayer, gstreamer, and a stand-alone still capture 
 utility. Tested on 3.8  3.12-rc5.

 WARNING: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Got 
 unexpected frame size of 265434 instead of 829440.
 Additional debug info:
 gstv4l2src.c(919): gst_v4l2src_get_mmap (): 
 /GstPipeline:pipeline0/GstV4l2Src:v4l2src0

 The amount of data retrieved varies a little with each frame, but is 
 always something similar..

 Regards,
 Jon.


 On Tuesday, 15 October 2013 03:31:11 UTC+1, Brent wrote:

 I wish the USB based NTSC capture dongle were that simple.  I've tried 
 Hauppauge USB Live-2, and Easy-Cap, but neither work with the BeagleBone 
 Black.  It seems that the BBB is to slow for that.  I've considered the 
 camera capes that are available, but really need a solution that interfaces 
 with an analog camera.

  -- 
 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/iMs8S90aXzk/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 beagleboard...@googlegroups.com javascript:.
 For more options, visit https://groups.google.com/groups/opt_out.




 -- 
 -brent 


-- 
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: RCN are you listening - questions about pinmux, a newbies adventure with BBxM

[Jon Holcomb]

OK these lines added to beagle.h compiled

MUX_VAL(CP(MMC2_DAT1), (IEN | PTU | EN | M4 )) /* gpio_133 */\
MUX_VAL(CP(MMC2_DAT4),(IEN | PTD | EN | M4 )) /* gpio_136 */\
MUX_VAL(CP(MMC2_DAT5),(IEN | PTD | EN | M4 )) /* gpio_137 */\
MUX_VAL(CP(MMC2_DAT6), (IEN | PTD | EN | M4 )) /* gpio_138 */\
MUX_VAL(CP(MMC2_DAT7), (IEN | PTD | EN | M4 )) /* gpio_139 */\
MUX_VAL(CP(UART2_CTS), (IEN | PTU | EN | M2 )) /* gpt_9_pwm_evt 
*/\
MUX_VAL(CP(UART2_RTS),  (IEN | PTU | EN | M2 )) /* 
gpt_10_pwm_evt */\
MUX_VAL(CP(UART2_TX),   (IEN | PTU | EN | M2 )) /* 
gpt_11_pwm_evt */\

I put them at the bottom of the BBxM section.  I will try them in a day or 
two and see if it works







-- 
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: RCN are you listening - questions about pinmux, a newbies adventure with BBxM

[Jon Holcomb]

Gerald,
You are prolly right but I thought the xM would give me a bit more 
processing power, still learning.

liyaoshi, 
They were on ebay $50 each and I got all they had.  I am sure if you watch 
there will be more. 

On Friday, October 11, 2013 4:10:09 PM UTC-5, Jon Holcomb wrote:

 All: 
 First off, thanks to Brian Hensley and Robert Nelson for their wealth of 
 information and support. 

 I am a retiree that, after a 30+ year stint building electronic/mechanical 
 devices in the medical research field in a MS Windows centric university , 
 thought that I would expand my horizons and decided to play with the BBxM.  
 I am running Ubuntu 12.04 and have gotten to the point where I am ready to 
 try and compile a u-boot.img in order to 
 set the pinmux values.  I have downloaded and ran the TI Pinmux utility 
 and have made the mux.h and pinmux.h files. I have the u-boot source file 
 from denx.de and have expanded it and have found the board/ti/beagle and 
 evm subdirectories. 

 I have read a lot of stuff on the internet but since things change daily I 
 want to check on several things.
 Bear with me if I am asking obvious questions but I am still learning to 
 get around in the linux environment and I have seen conflicting info in 
 various posts.

 1.  Where in the tree do these files go? Do I need to make changes to 
 evm.h?
 2. I have the spidev working that RCN made available via the uEnv.txt 
 change uncommenting buddy = spidev.  Will my changes to the pinmux affect 
 this.
 i.e Do I have to set the SPI3 and SPI 4 pins as well as the I2C pins 
 in the utility?
 3. Should I assume that the baseline that is given by the pinmux utility 
 sets all of the proper pads for the correct functioning of the BBxM?
 4. Am I going dangerously wrong in any of this???  Have I missed anything?

 I bought 3 BBxMs off of eBay and gave one to my buddy that just retired as 
 Director of IT at the university where I worked. I had Ubuntu and lxde 
 already running on the BB.
 I told him the first one is free - just like crack, and yes he is addicted.

 Thanks in advance for your help
 Jon




-- 
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: RCN are you listening - questions about pinmux, a newbies adventure with BBxM

[Jon Holcomb]

OK, 
So I looked through everything again and I saw no where in the tree to put 
the files that where output from the pinmux utility.
So others have been Modifying the Beagle.h file( which I found) so can I 
add the following to the bottom of the beagle xm section in the beagle.h 
file.
MUX_VAL(CP(MMC2_DAT1), (IEN | PU | M4 )) /* gpio_133 */\ 
MUX_VAL(CP(MMC2_DAT4),(IEN | PD | M4 )) /* gpio_136 */\ 
MUX_VAL(CP(MMC2_DAT5),(IEN | PD | M4 )) /* gpio_137 */\ 
MUX_VAL(CP(MMC2_DAT6), (IEN | PD | M4 )) /* gpio_138 */\ 
MUX_VAL(CP(MMC2_DAT7), (IEN | PD | M4 )) /* gpio_139 */\
MUX_VAL(CP(UART2_CTS), (IEN | PU | M2 )) /* gpt_9_pwm_evt */\
MUX_VAL(CP(UART2_RTS),  (IEN | PU | M2 )) /* gpt_10_pwm_evt */\
MUX_VAL(CP(UART2_TX),   (IEN | PU | M2 )) /* gpt_11_pwm_evt */\
Then I should be able to cross compile the uboot and apply it to the SD 
card.

Anyone???

On Friday, October 11, 2013 4:10:09 PM UTC-5, Jon Holcomb wrote:

 All: 
 First off, thanks to Brian Hensley and Robert Nelson for their wealth of 
 information and support. 

 I am a retiree that, after a 30+ year stint building electronic/mechanical 
 devices in the medical research field in a MS Windows centric university , 
 thought that I would expand my horizons and decided to play with the BBxM.  
 I am running Ubuntu 12.04 and have gotten to the point where I am ready to 
 try and compile a u-boot.img in order to 
 set the pinmux values.  I have downloaded and ran the TI Pinmux utility 
 and have made the mux.h and pinmux.h files. I have the u-boot source file 
 from denx.de and have expanded it and have found the board/ti/beagle and 
 evm subdirectories. 

 I have read a lot of stuff on the internet but since things change daily I 
 want to check on several things.
 Bear with me if I am asking obvious questions but I am still learning to 
 get around in the linux environment and I have seen conflicting info in 
 various posts.

 1.  Where in the tree do these files go? Do I need to make changes to 
 evm.h?
 2. I have the spidev working that RCN made available via the uEnv.txt 
 change uncommenting buddy = spidev.  Will my changes to the pinmux affect 
 this.
 i.e Do I have to set the SPI3 and SPI 4 pins as well as the I2C pins 
 in the utility?
 3. Should I assume that the baseline that is given by the pinmux utility 
 sets all of the proper pads for the correct functioning of the BBxM?
 4. Am I going dangerously wrong in any of this???  Have I missed anything?

 I bought 3 BBxMs off of eBay and gave one to my buddy that just retired as 
 Director of IT at the university where I worked. I had Ubuntu and lxde 
 already running on the BB.
 I told him the first one is free - just like crack, and yes he is addicted.

 Thanks in advance for your help
 Jon




-- 
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] RCN are you listening - questions about pinmux, a newbies adventure with BBxM

[Jon Holcomb]

All: 
First off, thanks to Brian Hensley and Robert Nelson for their wealth of 
information and support. 

I am a retiree that, after a 30+ year stint building electronic/mechanical 
devices in the medical research field in a MS Windows centric university , 
thought that I would expand my horizons and decided to play with the BBxM.  
I am running Ubuntu 12.04 and have gotten to the point where I am ready to 
try and compile a u-boot.img in order to 
set the pinmux values.  I have downloaded and ran the TI Pinmux utility and 
have made the mux.h and pinmux.h files. I have the u-boot source file from 
denx.de and have expanded it and have found the board/ti/beagle and evm 
subdirectories. 

I have read a lot of stuff on the internet but since things change daily I 
want to check on several things.
Bear with me if I am asking obvious questions but I am still learning to 
get around in the linux environment and I have seen conflicting info in 
various posts.

1.  Where in the tree do these files go? Do I need to make changes to evm.h?
2. I have the spidev working that RCN made available via the uEnv.txt 
change uncommenting buddy = spidev.  Will my changes to the pinmux affect 
this.
i.e Do I have to set the SPI3 and SPI 4 pins as well as the I2C pins in 
the utility?
3. Should I assume that the baseline that is given by the pinmux utility 
sets all of the proper pads for the correct functioning of the BBxM?
4. Am I going dangerously wrong in any of this???  Have I missed anything?

I bought 3 BBxMs off of eBay and gave one to my buddy that just retired as 
Director of IT at the university where I worked. I had Ubuntu and lxde 
already running on the BB.
I told him the first one is free - just like crack, and yes he is addicted.

Thanks in advance for your help
Jon


-- 
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] RCN are you listening - questions about pinmux, a newbies adventure with BBxM

[Jon Holcomb]

$50


On Friday, October 11, 2013 4:14:20 PM UTC-5, Gerald wrote:

 Hope you didn't pay too much!

 Gerald



 On Fri, Oct 11, 2013 at 4:10 PM, Jon Holcomb 
 holcomb...@gmail.comjavascript:
  wrote:

 All: 
 First off, thanks to Brian Hensley and Robert Nelson for their wealth of 
 information and support. 

 I am a retiree that, after a 30+ year stint building 
 electronic/mechanical devices in the medical research field in a MS Windows 
 centric university , thought that I would expand my horizons and decided to 
 play with the BBxM.  I am running Ubuntu 12.04 and have gotten to the point 
 where I am ready to try and compile a u-boot.img in order to 
 set the pinmux values.  I have downloaded and ran the TI Pinmux utility 
 and have made the mux.h and pinmux.h files. I have the u-boot source file 
 from denx.de and have expanded it and have found the board/ti/beagle and 
 evm subdirectories. 

 I have read a lot of stuff on the internet but since things change daily 
 I want to check on several things.
 Bear with me if I am asking obvious questions but I am still learning to 
 get around in the linux environment and I have seen conflicting info in 
 various posts.

 1.  Where in the tree do these files go? Do I need to make changes to 
 evm.h?
 2. I have the spidev working that RCN made available via the uEnv.txt 
 change uncommenting buddy = spidev.  Will my changes to the pinmux affect 
 this.
 i.e Do I have to set the SPI3 and SPI 4 pins as well as the I2C pins 
 in the utility?
 3. Should I assume that the baseline that is given by the pinmux utility 
 sets all of the proper pads for the correct functioning of the BBxM?
 4. Am I going dangerously wrong in any of this???  Have I missed anything?

 I bought 3 BBxMs off of eBay and gave one to my buddy that just retired 
 as Director of IT at the university where I worked. I had Ubuntu and lxde 
 already running on the BB.
 I told him the first one is free - just like crack, and yes he is 
 addicted.

 Thanks in advance for your help
 Jon


  -- 
 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 javascript:.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
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.