[beagleboard] Latest Jessie: cannot write to disk, cannot connect Eth over USB, could before

2016-06-08 Thread Vladimir Gusiatnikov 

Two glaring issues have occurred seemingly without cause and neither of 
which was present a few hours ago. The issues are only present when booting 
from an SD card with the latest Jessie/Debian 8.4 image (Linux beaglebone 
4.4.9-ti-r25 #1 SMP Thu May 5 23:08:13 UTC 2016 armv7l GNU/Linux).

1. I am unable to write to disk. E.g. vi: "E297: Write error in swap file", 
"E514: Write error (file system full?)"

2. I am unable to connect over Ethernet-over-USB. On a host machine, I have

Ethernet adapter Local Area Connection 3:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Linux USB Ethernet/RNDIS Gadget #2
   Physical Address. . . . . . . . . : A0-F6-FD-3C-F7-FF
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes

Cannot ping. The USB disk still shows up as USB storage on the host, I can 
access it without problems.

I still have the TTY: a keyboard and output to the BB-View cape with LCD4 
attached, these function.

When I boot from the eMMC with Wheezy/Debian 7.9, neither of the issues is 
present.

Would anyone have a suggestion on how I should debug this? 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/5d417ebe-22f9-4dd7-8181-23e6f429aa5f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Latest Jessie: all of a sudden cannot write to disk, cannot connect Eth over USB

2016-06-08 Thread Vladimir Gusiatnikov 
Two glaring issues have occurred seemingly without cause and neither of 
which was present a few hours ago. The issues are only present when booting 
from an SD card with the latest Jessie/Debian 8.4 image (Linux beaglebone 
4.4.9-ti-r25 #1 SMP Thu May 5 23:08:13 UTC 2016 armv7l GNU/Linux).

1. I am unable to write to disk. E.g. vi: "E297: Write error in swap file", 
"E514: Write error (file system full?)"

2. I am unable to connect over Ethernet-over-USB. On a host machine, I have

Ethernet adapter Local Area Connection 3:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Linux USB Ethernet/RNDIS Gadget #2
   Physical Address. . . . . . . . . : A0-F6-FD-3C-F7-FF
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes

Cannot ping. The USB disk still shows up as USB storage on the host, I can 
access it without problems.

I still have the TTY: a keyboard and output to the BB-View cape with LCD4 
attached, these function.

When I boot from the eMMC with Wheezy/Debian 7.9, neither of the issues is 
present.

Would anyone have a suggestion on how I should debug this? 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/968448e2-6ec6-4cc1-a00e-b1e96466f443%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Debian Jessie USB drive problem

2016-06-08 Thread Peter Hendricks 
On 9 June 2016 at 01:47, Wally Bkg  wrote:
>
> What is the reason for the nofail option in /etc/fstab?

Without it the boot process hangs if the drive is not plugged in.

> Any reason you can't format the drive as ext4?

I would have to buy another drive to backup the data first.
Performance is adequate, the bottleneck is the 100Mb/s ethernet i/f.

> I'm doing similar on a Raspberry Pi2 with Jessie and have had no such issues, 
> but I have a weird one in that the system immediately crashes back to 
> "emergency" mode if I try to run it headless (no mouse/keyboard).

I don't know what emergency mode is. The BBG has no video output, so
it's always headless.

> Is the USB drive powered separately or from the USB bus?

Yes, it has its own power brick. I have also a USB printer connected
to the same hub and it doesn't seem to have this problem.

> One more thing,  since you are mounting by UUID why/how does the code writing 
> to the drive "know" its sda1?  As long as its mounted at  /mnt/usbdrive it 
> shouldn't matter if its sda1 or sdb1.  you could try mounting /dev/sda1 
> instead of UUID=.  Have you verified that the usb/drive is really mounted at 
> /mnt/usbdrive after it "switches" to /dev/sdb1?

It is because the uuid is nothing but a symlink:

root@beaglebone:/dev/disk/by-uuid# ls -l
total 0
lrwxrwxrwx 1 root root 10 Jun  8 10:35 F250C93950C904F7 -> ../../sda1
lrwxrwxrwx 1 root root 15 Jun  8 08:54
c1d24650-2c0c-4272-8762-56158468bbfb -> ../../mmcblk0p1

The only code using the device file is mount.ntfs (I think that is a
hard link to ntfs-3g). mount.ntfs runs as a background process,
keeping the device file locked. As far as the file system is
concerned, the drive stays mounted on /dev/usbdrive, but any attempt
to access it gives an I/O error.

I have been banging my head against a wall, trying to write a udev
rule. Then I realised that udev is not the problem: the /dev/sdx block
dev files are managed by the kernel. This means that even if I
uninstall udev, ntfs-3g and try to mount it as ntfs the kernel will
still change the dev files.

I have since found this topic:
http://www.nslu2-linux.org/wiki/FAQ/DealWithAutoSpinDownOnSeagateFreeAgent

I have connected the drive to my Windows laptop and used Seagate's s/w
to disable sleep mode. It can't be that, either.

My unix experience dates back to the days of floppy disks and parallel
ports. This has me stumped.

Thanks for trying to help, Wally.

Regards,
Peter.

-- 
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/CAKGPEhq2tSm4Pi-ndn2wL7xPFDqC85L2sv61Lv1rC0cb3dtFHw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Web page button press to run exe, without page reload

2016-06-08 Thread 'AndyS' via BeagleBoard 

Hi All,

I am trying to write a little web interface for controlling my BBB leds.

I would really like the button press to call 'leds.exe 0 0' with 
parameters, without the web page refreshing.
is there some way I can use javascript to do this?  I have used the php 
exec() function before but all examples require the page to reload.

Thanks in advance.

Andy
 

-- 
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/46403694-bcd2-4138-a228-f63c26ed310a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Debian 8.4. Kernel Files Missing

2016-06-08 Thread Robert Nelson 
On Wed, Jun 8, 2016 at 11:05 AM,   wrote:
>
> After flashing Debian 8.4 image to BeagleBone Black, I have update the
> kernel through script tool '/opt/scripts/tools/update_kernel.sh' to
> "4.4.12-bone11" kernel version.
>
> Then, I have built a new kernel from 4.7 branch with RobertCNelson tools
> 'build_kernel.sh'. Now, I have all files (*.dtb, zImage) and modules, so I
> want to upgrade the kernel.
>
> Before trying the tftp server via serial port, or brute-force changing the
> files directly, I have checked at '/boot/uboot' path for the dtb and zImage
> files, but there is no file into this path (dtb files are at '/boot/dtbs').
>
> How can the kernel be upgraded to any version at Debian 8.4?
> Isn't it necessary to change uImage, zImage or dtb? Which is the best way to
> upgrade the kernel now?
>
> * I would like to prefer not having to use serial port this time, but I can
> use it if it is needed.

see this section:

https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-InstallKernelandRootFileSystem

you already have the rootfs, so you can skip that..

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/CAOCHtYje_gNUdi-LhN9j6zR238d7y%3DNx2W2jKTzzf0dxLCWTTg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] unable to power up

2016-06-08 Thread Robert Nelson 
On Wed, Jun 8, 2016 at 1:58 PM,   wrote:
> I have formatted emmc of beaglebone black im unable to power up

I'm not sure what you were expecting to happen..

Reflash: http://beagleboard.org/latest-images

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/CAOCHtYjesDuJS_wOaSAeoNuQZmHNaKF%2BjPOGj28H7aBGxJ5j1A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Getting UART2 to operate on BBG

2016-06-08 Thread Mr Al 
Hello guys,

I have the same issue, indeed all the UARTs coming disabled with this 
image, even though all the /dev/ttyOx are available. My solution maybe is 
not the best one, but I just change the version of Debian 7 release 
2015-07-13, and everything works like we expect, I mean like books and 
tutorials about how to enable ports, and these stuff. Later I will try the 
RobertCNelson solution, it looks very well, maybe is a more reliable 
solution.

Regards


El lunes, 25 de abril de 2016, 10:26:00 (UTC-5), Jean-Sebastien Stoezel 
escribió:
>
> Hi:
>
> I have a BeagleBone Green running Linux version 4.1.15-ti-rt-r43 and 
> Debian 8.3 (Jessie). I am cannot seem to send or receive data on UART2.
>
> What I can see see is that UART2 is enabled:
>
> *[4.368638] 48024000.serial: ttyS2 at MMIO 0x48024000 (irq = 160, 
> base_baud = 300) is a 8250).*
>
> I have used minicom, a C++ QT application, and an online script (
> http://jsfiddle.net/AjnJs/67/) to try and send data over UART2 but 
> nothing seems to get to the pins.
>
> I feel confident in the hardware I use to verify that no data is sent over 
> the UART2 pins (I have yet to get an oscilloscope out though).
>
> Looking at the BBG schematic, it seems the UART2 pins are shared with the 
> SPI. I am wondering if by default SPI might be configured, which might 
> prevent UART2 from operating.
>
> Has anybody ever gotten UART2 to work on the BBG? If so, what steps did 
> you take?
> What software check can I perform to verify UART2 is effectively ready to 
> operate?
>
> Regards,
> JS
>
>  
>

-- 
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/3ed757b7-65b8-4c69-858a-308d9a255ba8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] unable to power up

2016-06-08 Thread suri . swamy1456 
I have formatted emmc of beaglebone black im unable to power up

-- 
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/a3bd31f3-017c-4cc2-8e65-169ae8a25ec6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: pru remoteproc development examples for debian?

2016-06-08 Thread David Good 
To clarify question 1 of my original post, I'm checking the pin mode
settings with 'cat $PINS' and the PRU pins always show 0x27.  I'm asking
whether there are any other PRUSS specific requirements in the device tree
itself or if the load order of the device tree overlay and firmware matter
in order for the '$PINS' file to show that the mode was changed to
pru_r30_blah_blah.

Thanks!

On Wed, Jun 8, 2016 at 12:07 PM, David Good  wrote:

> Good suggestions Greg!  I didn't know about rmmod -f.  You learn something
> new every day!
>
> I didn't even know about config-pin until yesterday, since I've only ever
> used device trees in the past.  I guess config-pin might actually be the
> best option for my stage of development, but I would like to get the PRU
> pins configured with device trees eventually, since that feels more like
> the right "embedded" thing to do ;)
>
> --David
>
> On Wed, Jun 8, 2016 at 9:18 AM, Greg  wrote:
>
>> Regarding the device tree, I'm using the "Universal IO" and the
>> accompanying shell script config-pin and I haven't had any configuration
>> problems with the PRU pins.
>> There is an option for config-pin which reads a file and sets all of the
>> pins per a list of the pins in the file.  It works very well.  You can put
>> this command in your .profile or
>> whatever you do at boot time to set up the pins.  I've found this system
>> works flawlessly and saves a lot of time and confusion.
>>
>> I have had to tweak the device tree source if a different pull-up/down
>> resistor is required on a PRU input pin.
>>
>> Regarding the rmmod problem, use the "force" option -f.  This is actually
>> recommended by TI.
>>
>> I highly recommend creating simple bash scripts or aliases called
>> "prumodout" and "prumodin" which execute the rmmod and insmod commands to
>> remove
>> and insert your PRU firmwares.  Taking it to the next step, you can use
>> your prumod and prumodin commands in your build script so that the firmwares
>> are copied to the /lib/firmware directory, old firmwares removed and new
>> firmwares loaded and started all in a single command.
>>
>> You should be able to go through a modify-build cycle without reboot, and
>> very quickly.
>>
>> Regards,
>> Greg
>>
>>
>> On Wednesday, June 8, 2016 at 1:25:20 AM UTC-4, David Good wrote:
>>
>>> Alright, I'm making some progress, but am having some issues:
>>>
>>> 1. I can't seem to get my device tree to change the mode of pins
>>> associated with the pruss, but other pins are configured correctly.  Is
>>> there some kind of order that the PRU firmware and device tree has to load
>>> in?
>>>
>>> /* Start EBB-PRU-Example.dts */
>>> /dts-v1/;
>>> /plugin/;
>>>
>>> / {
>>>compatible = "ti,beaglebone", "ti,beaglebone-black";
>>>
>>>part-number = "EBB-PRU-Example";
>>>version = "00A0";
>>>
>>>/* This overlay uses the following resources */
>>>exclusive-use =
>>>  "P9.11", "P9.13", "P9.27", "P9.28", "pru0";
>>>
>>>fragment@0 {
>>>   target = <_pinmux>;
>>>   __overlay__ {
>>>
>>>  gpio_pins: pinmux_gpio_pins { // The GPIO pins
>>> pinctrl-single,pins = <
>>>0x070 0x07  // P9_11 MODE7 | OUTPUT | GPIO pull-down
>>>0x074 0x27  // P9_13 MODE7 | INPUT | GPIO pull-down
>>> >;
>>>  };
>>>
>>>  pru_pru_pins: pinmux_pru_pru_pins {   // The PRU pin modes
>>> pinctrl-single,pins = <
>>>0x1a4 0x05  // P9_27 pr1_pru0_pru_r30_5, MODE5 | OUTPUT |
>>> PRU
>>>0x19c 0x26  // P9_28 pr1_pru0_pru_r31_3, MODE6 | INPUT |
>>> PRU
>>> >;
>>>  };
>>>   };
>>>};
>>>
>>>fragment@1 { // Enable the PRUSS
>>>   target = <>;
>>>   __overlay__ {
>>>  status = "okay";
>>>  pinctrl-names = "default";
>>>  pinctrl-0 = <_pru_pins>;
>>>   };
>>>};
>>>
>>>fragment@2 { // Enable the GPIOs
>>>   target = <>;
>>>   __overlay__ {
>>>  gpio_helper {
>>> compatible = "gpio-of-helper";
>>> status = "okay";
>>> pinctrl-names = "default";
>>> pinctrl-0 = <_pins>;
>>>  };
>>>   };
>>>};
>>> };
>>> /* End EBB-PRU-Example.dts */
>>>
>>>
>>> 2. I've got one of the TI examples compiled running as
>>> /lib/firmware/am335x-pru0-fw
>>> dmesg seems to show that it loads successfully, without errors.
>>>
>>> #include 
>>> #include 
>>> #include "resource_table_empty.h"
>>>
>>> volatile register uint32_t __R30;
>>> volatile register uint32_t __R31;
>>>
>>> void main(void)
>>> {
>>>
>>> uint32_t gpio;
>>>
>>> /* Clear SYSCFG[STANDBY_INIT] to enable OCP master port */
>>> CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;
>>>
>>> /* gpio = 0x000F; */
>>> /* gpio = (1 << 5); */
>>> gpio = 0x0010;
>>>
>>> __R30 = 0x0;
>>>
>>> /* Toggle the LEDs */
>>> /* TODO: Create stop condition, else it

Re: [beagleboard] BBGW First Impressions

2016-06-08 Thread Peter Hurley 
On 06/07/2016 06:21 AM, Robert Nelson wrote:
> On Tue, Jun 7, 2016 at 7:51 AM, Carl Johnson  wrote:
>> For those of you using this board with either the 5/13/2016 or 5/31/2016
>> images (bone-debian-8.4-lxqt-4gb-armhf-2016-05-13-4gb.img.xz or
>> bone-debian-8.4-seeed-lxqt-4gb-armhf-2016-05-31-4gb.img.xz), I've noticed
>> that the bluetooth device doesn't appear until you manually run
>> "bb-wl18xx-bluetooth" ("hcitool dev" comes up empty until you do this).
> 
> This is a fun issue, it varies between board's but we need about a
> 20-25 second delay on startup before bluetooth can be loaded.. ;)

The ti-st driver is junk and not required for bluetooth only.
Sorry but that's really all I can say about it.

-- 
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/5758523C.6030404%40hurleysoftware.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: pru remoteproc development examples for debian?

2016-06-08 Thread David Good 
Good suggestions Greg!  I didn't know about rmmod -f.  You learn something
new every day!

I didn't even know about config-pin until yesterday, since I've only ever
used device trees in the past.  I guess config-pin might actually be the
best option for my stage of development, but I would like to get the PRU
pins configured with device trees eventually, since that feels more like
the right "embedded" thing to do ;)

--David

On Wed, Jun 8, 2016 at 9:18 AM, Greg  wrote:

> Regarding the device tree, I'm using the "Universal IO" and the
> accompanying shell script config-pin and I haven't had any configuration
> problems with the PRU pins.
> There is an option for config-pin which reads a file and sets all of the
> pins per a list of the pins in the file.  It works very well.  You can put
> this command in your .profile or
> whatever you do at boot time to set up the pins.  I've found this system
> works flawlessly and saves a lot of time and confusion.
>
> I have had to tweak the device tree source if a different pull-up/down
> resistor is required on a PRU input pin.
>
> Regarding the rmmod problem, use the "force" option -f.  This is actually
> recommended by TI.
>
> I highly recommend creating simple bash scripts or aliases called
> "prumodout" and "prumodin" which execute the rmmod and insmod commands to
> remove
> and insert your PRU firmwares.  Taking it to the next step, you can use
> your prumod and prumodin commands in your build script so that the firmwares
> are copied to the /lib/firmware directory, old firmwares removed and new
> firmwares loaded and started all in a single command.
>
> You should be able to go through a modify-build cycle without reboot, and
> very quickly.
>
> Regards,
> Greg
>
>
> On Wednesday, June 8, 2016 at 1:25:20 AM UTC-4, David Good wrote:
>
>> Alright, I'm making some progress, but am having some issues:
>>
>> 1. I can't seem to get my device tree to change the mode of pins
>> associated with the pruss, but other pins are configured correctly.  Is
>> there some kind of order that the PRU firmware and device tree has to load
>> in?
>>
>> /* Start EBB-PRU-Example.dts */
>> /dts-v1/;
>> /plugin/;
>>
>> / {
>>compatible = "ti,beaglebone", "ti,beaglebone-black";
>>
>>part-number = "EBB-PRU-Example";
>>version = "00A0";
>>
>>/* This overlay uses the following resources */
>>exclusive-use =
>>  "P9.11", "P9.13", "P9.27", "P9.28", "pru0";
>>
>>fragment@0 {
>>   target = <_pinmux>;
>>   __overlay__ {
>>
>>  gpio_pins: pinmux_gpio_pins { // The GPIO pins
>> pinctrl-single,pins = <
>>0x070 0x07  // P9_11 MODE7 | OUTPUT | GPIO pull-down
>>0x074 0x27  // P9_13 MODE7 | INPUT | GPIO pull-down
>> >;
>>  };
>>
>>  pru_pru_pins: pinmux_pru_pru_pins {   // The PRU pin modes
>> pinctrl-single,pins = <
>>0x1a4 0x05  // P9_27 pr1_pru0_pru_r30_5, MODE5 | OUTPUT |
>> PRU
>>0x19c 0x26  // P9_28 pr1_pru0_pru_r31_3, MODE6 | INPUT |
>> PRU
>> >;
>>  };
>>   };
>>};
>>
>>fragment@1 { // Enable the PRUSS
>>   target = <>;
>>   __overlay__ {
>>  status = "okay";
>>  pinctrl-names = "default";
>>  pinctrl-0 = <_pru_pins>;
>>   };
>>};
>>
>>fragment@2 { // Enable the GPIOs
>>   target = <>;
>>   __overlay__ {
>>  gpio_helper {
>> compatible = "gpio-of-helper";
>> status = "okay";
>> pinctrl-names = "default";
>> pinctrl-0 = <_pins>;
>>  };
>>   };
>>};
>> };
>> /* End EBB-PRU-Example.dts */
>>
>>
>> 2. I've got one of the TI examples compiled running as
>> /lib/firmware/am335x-pru0-fw
>> dmesg seems to show that it loads successfully, without errors.
>>
>> #include 
>> #include 
>> #include "resource_table_empty.h"
>>
>> volatile register uint32_t __R30;
>> volatile register uint32_t __R31;
>>
>> void main(void)
>> {
>>
>> uint32_t gpio;
>>
>> /* Clear SYSCFG[STANDBY_INIT] to enable OCP master port */
>> CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;
>>
>> /* gpio = 0x000F; */
>> /* gpio = (1 << 5); */
>> gpio = 0x0010;
>>
>> __R30 = 0x0;
>>
>> /* Toggle the LEDs */
>> /* TODO: Create stop condition, else it will toggle indefinitely */
>> while (1) {
>> __R30 ^= gpio;
>>
>> __delay_cycles(1);
>>
>> }
>> }
>>
>> As you can see, main is an infinite loop.  This means that if I try to
>> rmmod pru-rproc, I get the following error:
>> rmmod: ERROR: Module pru_rproc is in use
>>
>> This means that I have to reboot in order to update the code.  How do I
>> either force the pru to unload or send it signals to stop so I don't have
>> to reboot everytime?
>>
>> Thanks again!
>>
>> --David
>>
>>
>> On Wed, May 11, 2016 at 5:57 PM, Greg  wrote:
>>
>>> Ok, thanks-- no

[beagleboard] Re: SDI 12 for beaglebone black

2016-06-08 Thread Benjamín Carriquiry 

Old thread, but I would love to know the way people have implemented SDI-12 
communication between BB and SDI12-enabled sensors.

-- 
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/0ec2de6b-cc71-4014-9d5a-f45b6cb3febf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Debian 8.4. Kernel Files Missing

2016-06-08 Thread yolcopc 

After flashing Debian 8.4 image to BeagleBone Black, I have update the 
kernel through script tool '*/opt/scripts/tools/update_kernel.sh*' to "
*4.4.12-bone11*" kernel version.

Then, I have built a new kernel from 4.7 branch with RobertCNelson tools '
*build_kernel.sh*'. Now, I have all files (*.dtb, zImage) and modules, so I 
want to upgrade the kernel.

Before trying the *tftp* server via serial port, or *brute-force* changing 
the files directly, I have checked at '*/boot/uboot*' path for the dtb and 
zImage files, but there is no file into this path (dtb files are at 
'/boot/dtbs').

*How can the kernel be upgraded to any version at Debian 8.4*?
Isn't it necessary to change uImage, zImage or dtb? Which is the best way 
to upgrade the kernel now?

* I would like to prefer not having to use serial port this time, but I can 
use it if it is needed.

-- 
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/6c50840a-49de-498e-b569-8b0350908c67%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Debian 8.4. Upgrading kernel.

2016-06-08 Thread yolcopc 
After flashing Debian 8.4 image to BeagleBone Black, I have update the 
kernel through script tool '*/opt/scripts/tools/update_kernel.sh*' to "
*4.4.12-bone11*" kernel version.

Then, I have built a new kernel from 4.7 branch with RobertCNelson tools '
*build_kernel.sh*'. Now, I have all files (*.dtb, zImage) and modules, so I 
want to upgrade the kernel.

Before trying the *tftp* server via serial port, or *brute-force* changing 
the files directly, I have checked at '*/boot/uboot*' path for the dtb and 
zImage files, but there is no file into this path (dtb files are at 
'/boot/dtbs').

*How can the kernel be upgraded to any version at Debian 8.4*?
Isn't it necessary to change uImage, zImage or dtb? Which is the best way 
to upgrade the kernel now?

* I would like to prefer not having to use serial port this time, but I can 
work with it if it is nec

-- 
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/08855ebd-c20c-4b75-a2e4-109d07607577%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Ubuntu 16.04 changes the way interfaces are named

2016-06-08 Thread arnvid 
Hello

We've been using BBB's for a long time now and our configuration have been 
quite dependent on interface naming - since the dongles tend to be swapped 
around and when they die we need to be able to quick replace the dongle 
with new ones. In the Ubuntu 14.04 image everything works as we have 
experienced since the 12.04 image.

Ubuntu 14.04:
Udev: 204-5ubuntu20.15
Kernel: 4.1.15-ti-rt-r40

Ubuntu 16.04:
Udev 229-4ubuntu5 
Kernel: 4.4.9-ti-r25

In 16.04 the device names get named eth0, usb0, and the 
wireless wlx100d7fb73f66 - 

The documentation suggest the following to add the following to cmdline :
net.ifnames=0 biosdevname=0

By adding these to /boot/uEnv.txt one can clearly see it's added:
[0.00] Kernel command line: console=ttyO0,115200n8 
root=UUID=b32c4e38-221c-4cf5-b6c5-71ce64770caa ro rootfstype=ext4 rootwait 
coherent_pool=1M quiet cape_universal=enable net.ifnames=0 biosdevname=0

But this does not change the outcome.

Also the old way of :
echo -n > /etc/udev/rules.d/70-persistent-net.rules
echo -n > /lib/udev/rules.d/75-persistent-net-generator.rules

Does not work either.

>From 
>https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

I find that this were changed in udev 197 - but this did not happen in 
14.04 which also had an newer udev.

With systemd 197 we have added native support for a number of different 
naming policies into systemd/udevd proper and made a scheme similar to 
biosdevname's (but generally more powerful, and closer to kernel-internal 
device identification schemes) the default. The following different naming 
schemes for network interfaces are now supported by udev natively:

   1. Names incorporating Firmware/BIOS provided index numbers for on-board 
   devices (example: eno1)
   2. Names incorporating Firmware/BIOS provided PCI Express hotplug slot 
   index numbers (example: ens1)
   3. Names incorporating physical/geographical location of the connector 
   of the hardware (example: enp2s0)
   4. Names incorporating the interfaces's MAC address (example: 
   enx78e7d1ea46da)
   5. Classic, unpredictable kernel-native ethX naming (example: eth0)

By default, systemd v197 will now name interfaces following policy 1) if 
that information from the firmware is applicable and available, falling 
back to 2) if that information from the firmware is applicable and 
available, falling back to 3) if applicable, falling back to 5) in all 
other cases. Policy 4) is not used by default, but is available if the user 
chooses so.

So from my understanding policy 4 would usually not be on. So why does it 
kick in for the wireless on Ubuntu 16.04?


Br

Arnvid


-- 
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/1dadbef4-f4a2-4739-a052-9fca029af6c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB doesn´t boot sometimes

2016-06-08 Thread evilwulfie 
Try a different power supply.


On 6/8/2016 12:31 AM, hoerting.busin...@gmx.at wrote:
> Hello,
>
> I have sometimes the problem, when I power up the BBB with the power
> jack, the power LED is on, the USR LED never go on and the BBB did not
> boot.
>
> The Network LED are flashing.
>
> I disconnect the power supply, connect again and all is fine.
>
> This happens only sometimes and did not see any reason for this.
> I see this issue on several BBB ... so not just one.
>
> Is this a hardware issue?
>
> (I never use USB power)
>
> Thank you!
> -- 
> 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/247ecba3-2187-4f90-b399-40b4b3a38221%40googlegroups.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/15a4a9c4-9739-0cb4-45f0-cec94440a3af%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: pru remoteproc development examples for debian?

2016-06-08 Thread Greg 
Regarding the device tree, I'm using the "Universal IO" and the 
accompanying shell script config-pin and I haven't had any configuration 
problems with the PRU pins.
There is an option for config-pin which reads a file and sets all of the 
pins per a list of the pins in the file.  It works very well.  You can put 
this command in your .profile or 
whatever you do at boot time to set up the pins.  I've found this system 
works flawlessly and saves a lot of time and confusion.

I have had to tweak the device tree source if a different pull-up/down 
resistor is required on a PRU input pin.

Regarding the rmmod problem, use the "force" option -f.  This is actually 
recommended by TI.

I highly recommend creating simple bash scripts or aliases called 
"prumodout" and "prumodin" which execute the rmmod and insmod commands to 
remove
and insert your PRU firmwares.  Taking it to the next step, you can use 
your prumod and prumodin commands in your build script so that the firmwares
are copied to the /lib/firmware directory, old firmwares removed and new 
firmwares loaded and started all in a single command.

You should be able to go through a modify-build cycle without reboot, and 
very quickly.

Regards,
Greg

On Wednesday, June 8, 2016 at 1:25:20 AM UTC-4, David Good wrote:
>
> Alright, I'm making some progress, but am having some issues:
>
> 1. I can't seem to get my device tree to change the mode of pins 
> associated with the pruss, but other pins are configured correctly.  Is 
> there some kind of order that the PRU firmware and device tree has to load 
> in?
>
> /* Start EBB-PRU-Example.dts */
> /dts-v1/;
> /plugin/;
>
> / {
>compatible = "ti,beaglebone", "ti,beaglebone-black";
>
>part-number = "EBB-PRU-Example";
>version = "00A0";
>
>/* This overlay uses the following resources */
>exclusive-use =
>  "P9.11", "P9.13", "P9.27", "P9.28", "pru0";
>
>fragment@0 {
>   target = <_pinmux>;
>   __overlay__ {
>
>  gpio_pins: pinmux_gpio_pins { // The GPIO pins
> pinctrl-single,pins = <
>0x070 0x07  // P9_11 MODE7 | OUTPUT | GPIO pull-down
>0x074 0x27  // P9_13 MODE7 | INPUT | GPIO pull-down
> >;
>  };
>
>  pru_pru_pins: pinmux_pru_pru_pins {   // The PRU pin modes
> pinctrl-single,pins = <
>0x1a4 0x05  // P9_27 pr1_pru0_pru_r30_5, MODE5 | OUTPUT | 
> PRU
>0x19c 0x26  // P9_28 pr1_pru0_pru_r31_3, MODE6 | INPUT | PRU
> >;
>  };
>   };
>};
>
>fragment@1 { // Enable the PRUSS
>   target = <>;
>   __overlay__ {
>  status = "okay";
>  pinctrl-names = "default";
>  pinctrl-0 = <_pru_pins>;
>   };
>};
>
>fragment@2 { // Enable the GPIOs
>   target = <>;
>   __overlay__ {
>  gpio_helper {
> compatible = "gpio-of-helper";
> status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <_pins>;
>  };
>   };
>};
> };
> /* End EBB-PRU-Example.dts */
>
>
> 2. I've got one of the TI examples compiled running as 
> /lib/firmware/am335x-pru0-fw
> dmesg seems to show that it loads successfully, without errors.
>
> #include 
> #include 
> #include "resource_table_empty.h"
>
> volatile register uint32_t __R30;
> volatile register uint32_t __R31;
>
> void main(void)
> {
>
> uint32_t gpio;
>
> /* Clear SYSCFG[STANDBY_INIT] to enable OCP master port */
> CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;
>
> /* gpio = 0x000F; */
> /* gpio = (1 << 5); */
> gpio = 0x0010;
>
> __R30 = 0x0;
>
> /* Toggle the LEDs */
> /* TODO: Create stop condition, else it will toggle indefinitely */
> while (1) {
> __R30 ^= gpio;
>
> __delay_cycles(1);
>
> }
> }
>
> As you can see, main is an infinite loop.  This means that if I try to 
> rmmod pru-rproc, I get the following error:
> rmmod: ERROR: Module pru_rproc is in use
>
> This means that I have to reboot in order to update the code.  How do I 
> either force the pru to unload or send it signals to stop so I don't have 
> to reboot everytime?
>
> Thanks again!
>
> --David
>
>
> On Wed, May 11, 2016 at 5:57 PM, Greg  
> wrote:
>
>> Ok, thanks-- no insurmountable legal issues for sharing your own PRU 
>> code.  Beagleboard PRU fans, please start your code sharing engines!
>>
>> Greg
>>
>>
>> -- 
>> 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/566d5ab7-7b0d-4445-8c2c-0ed6004d1242%40googlegroups.com
>>  
>>

Re: [beagleboard] Re: Burned out BBB with AIN0 > 1.8V

2016-06-08 Thread el huitzilo 
Thanks, Harvey, that's an awesome explanation! 


> So firstly, let's feed all the sensors from 1.8 volts.  Now this 
> works, and can work well.  The question is how to get the 1.8 volts. A 
> switching converter, while efficient, generates noise, is relatively 
> complex, and is moderately large.


I was planning to use a 3-pin Recom device (R781.8-1.0) which supposedly 
has very low ripple voltage. The idea was to smooth the ripples down to an 
acceptable magnitude using an adequately sized capacitor.

 An easier way to get 1.8 volts is 
> to use a simple 3 terminal regulator.  There are some very small ones 
> available.  They generate little electrical noise.  A typical current 
> limit is about 100 ma, which should power a number of sensors. 
>

Yeah, I thought about that too, but 100 mA is a little too skimpy for my 
application, unfortunately. Also, I'm concerned about efficiency since at 
some point it would be cool to run the whole thing on batteries. With a 
regulator I would churn out 2/3rds of the power used in the measuring 
circuit into heat. 

Another thing that I should probably mention is that I really want the 
measurements to allow for a (more or less) precise estimation of the sensor 
resistance. Hence it's not so much about just protecting the input from 
overvoltage - I'd rather avoid any nonlinear attenuation in the signal 
path, e.g. by a diode that starts conducting when the voltage approaches 
the upper limit.  

>
> Putting an op amp in allows several possibilities.  Op amps can be 
> inverting or non-inverting.  By running the op-amp from 1.8 volts and 
> ground, the maximum output voltage that the op-amp can put out is 
> limited to these values.  You will need a chip that outputs rail to 
> rail (ground to positive power supply voltage). 
>

I'd personally recommend the op-amp for the most general solution, and 
> the resistive divider ONLY if the application can be guaranteed to 
> never exceed the voltage limits of the chip under any reasonable 
> conditions. 
>

After reading up a bit on rail-to-rail capable op-amps I have the 
impression that they'll be outside their linear range once the signal 
approaches either rail. Since linear behavior is important in my case, an 
op-amp is probably not the best way to do things in my case, is it? 


-- 
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/4807ad2a-726e-4b6c-9270-4c6bbc4ff772%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] BBB doesn´t boot sometimes

2016-06-08 Thread hoerting . business 
Hello,

I have sometimes the problem, when I power up the BBB with the power jack, 
the power LED is on, the USR LED never go on and the BBB did not boot.

The Network LED are flashing.

I disconnect the power supply, connect again and all is fine.

This happens only sometimes and did not see any reason for this.
I see this issue on several BBB ... so not just one.

Is this a hardware issue?

(I never use USB power)

Thank you!

-- 
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/247ecba3-2187-4f90-b399-40b4b3a38221%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: CADSTAR Schematic and PCB Layout for BeagleboardXM A2 now available

2016-06-08 Thread pixsys_19 
I'd like a copy too. Do you have also have files for Beaglebone Black?
Thanks for your work!

Il giorno domenica 10 luglio 2011 21:38:25 UTC+2, cdbintexas ha scritto:
>
> ANNOUNCEMENT:For those of you who want to do hardware modification, I 
> have converted the original design data into CADSTAR format.  This 
> universally recognized system is about 1/4 the cost of the original 
> design tools.  The CAD files are available free  upon request. Doug 
> Boone

-- 
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/13d32943-7fac-44bf-90a6-cfd6f604526e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Debian Jessie USB drive problem

2016-06-08 Thread Wally Bkg 
One more thing,  since you are mounting by UUID why/how does the code 
writing to the drive "know" its sda1?  As long as its mounted at 
 /mnt/usbdrive it shouldn't matter if its sda1 or sdb1.  you could try 
mounting /dev/sda1 instead of UUID=.  Have you verified that the usb/drive 
is really mounted at /mnt/usbdrive after it "switches" to /dev/sdb1?

-- 
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/c9346312-3092-4c55-b414-31592e2f5198%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Debian Jessie USB drive problem

2016-06-08 Thread Wally Bkg 
What is the reason for the nofail option in /etc/fstab?

Any reason you can't format the drive as ext4?  I've seen articles claiming 
serious performance benefits for USB drives as ext4 instead of ntfs.

I'm doing similar on a Raspberry Pi2 with Jessie and have had no such 
issues, but I have a weird one in that the system immediately crashes back 
to "emergency" mode if I try to run it headless (no mouse/keyboard).

Is the USB drive powered separately or from the USB bus?  It could be a 
power glitch issue as I don't think the Beaglebones can supply a lot of USB 
power.


On Thursday, May 26, 2016 at 1:46:57 AM UTC-5, Peter Hendricks wrote:
>
> I recently bought a BBG for use as a tiny NAS and print server. I 
> installed a Debian Jessie image (for BBB) and ran updates. All X stuff was 
> removed to save space and Samba installed.
>
> When I plug in the external USB disk it is recognised and /dev/sda1 
> appears. I added this to /etc/fstab:
>
> UUID=F250C93950C904F7   /mnt/usbdrive   ntfs-3g exec,noatime,nofail 
> 0   0
>
> This seems to work, the drive is mounted at boot time:
>
> /dev/sda1 on /mnt/usbdrive type fuseblk 
> (rw,noatime,user_id=0,group_id=0,allow_other,blksize=4096)
>
> However, after a random period of time and without touching the USB bus, 
> the drive suddenly switches to /dev/sdb1. This is while the drive is online 
> and an IP camera is continuously recording to it. Needless to say, it all 
> comes to a sudden halt, as /dev/sda1 disappears.
>
> This must be something I am doing wrong. I have some experience running 
> Linux systems as servers, but never had to deal with USB. I thought that 
> perhaps the drive going to sleep when idle was a problem, so I hooked it up 
> to my laptop and turned the sleep function off. It didn't help.
>
> Thanks for any light you may be able to shed on my problem.
>
> Kind regards,
> Peter.
>

-- 
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/937d956f-403f-42f9-8013-6f4e99b4c2a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] ssh not working on beaglebone after flashing eMMC

2016-06-08 Thread malkowki 
Hi William,

thanks for replying. Indeed something went wrong with some driver update as 
a consequence that my system completely has been screwed up.
I have just rebuild another image from the native Kernel source and booting 
the board from SD card.

Cheers,

Beninio

Le mardi 7 juin 2016 21:41:58 UTC+2, William Hermans a écrit :
>
> The problem is not openssh-server, the problem is your system is somehow 
> corrupt. Which can happen from a bad install. It ended prematurely for a 
> number of reasons. *OR* you started screwing around with a good install, 
> and messed it up.
>
> Start over again, and if the image you have does the same thing again, get 
> a different image.
>
> On Tue, Jun 7, 2016 at 12:19 AM, malkowki  > wrote:
>
>> I have tried 
>>
>> sudo apt-get update && sudo apt-get -f install
>>
>>
>> and I goy issue like below:
>> Saisissez le code ici...Hit http://repos.rcn-ee.com jessie InRelease
>> Ign http://ftp.us.debian.org jessie InRelease 
>> Hit http://security.debian.org jessie/updates InRelease 
>> Hit http://ftp.us.debian.org jessie-updates InRelease   
>> Get:1 http://repos.rcn-ee.com jessie/main armhf Packages [477 kB]   
>>
>> Get:2 http://security.debian.org jessie/updates/main armhf Packages [299 
>> kB]   
>> Hit http://ftp.us.debian.org jessie Release.gpg 
>>
>> Get:3 http://ftp.us.debian.org jessie-updates/main armhf Packages [17.4 
>> kB]
>> Get:4 http://ftp.us.debian.org jessie-updates/contrib armhf Packages [20 
>> B]
>> Get:5 http://ftp.us.debian.org jessie-updates/non-free armhf Packages 
>> [450 B]
>> Get:6 http://security.debian.org jessie/updates/contrib armhf Packages 
>> [994 B]
>> Hit http://ftp.us.debian.org jessie Release 
>> 
>> Get:7 http://security.debian.org jessie/updates/non-free armhf Packages 
>> [20 B]
>> Get:8 http://ftp.us.debian.org jessie/main armhf Packages [8,832 kB] 
>>  
>> Get:9 http://ftp.us.debian.org jessie/contrib armhf Packages [44.7 kB]   
>>   
>> Get:10 http://ftp.us.debian.org jessie/non-free armhf Packages [74.6 kB] 
>>   
>> Fetched 9,747 kB in 31s (307 kB/s)   
>>   
>> Reading package lists... Done
>> Reading package lists... Done
>> Building dependency tree   
>> Reading state information... Done
>> Correcting dependencies... Done
>> The following extra packages will be installed:
>>   perl perl-base perl-modules
>> Suggested packages:
>>   perl-doc libterm-readline-gnu-perl libterm-readline-perl-perl libb-lint
>> -perl
>>   libcpanplus-dist-build-perl libcpanplus-perl libfile-checktree-perl
>>   liblog-message-simple-perl liblog-message-perl libobject-accessor-perl
>> Recommended packages:
>>   rename libarchive-extract-perl libmodule-pluggable-perl libpod-latex-
>> perl
>>   libterm-ui-perl libtext-soundex-perl libcgi-pm-perl libmodule-build-
>> perl
>> The following packages will be REMOVED:
>>   openssh-server
>> The following NEW packages will be installed:
>>   perl-base
>> The following packages will be upgraded:
>>   perl perl-modules
>> 2 upgraded, 1 newly installed, 1 to remove and 42 not upgraded.
>> 1 not fully installed or removed.
>> Need to get 5,724 kB of archives.
>> After this operation, 3,255 kB of additional disk space will be used.
>> Do you want to continue? [Y/n] y
>> Get:1 http://ftp.us.debian.org/debian/ jessie/main perl-modules all 
>> 5.20.2-3+deb8u5 [2,546 kB]
>> Get:2 http://ftp.us.debian.org/debian/ jessie/main perl armhf 
>> 5.20.2-3+deb8u5 [2,052 kB]
>> Get:3 http://ftp.us.debian.org/debian/ jessie/main perl-base armhf 
>> 5.20.2-3+deb8u5 [1,127 kB]
>> Fetched 5,724 kB in 7s (756 kB/s)   
>>
>> /usr/sbin/dpkg-preconfigure: 6: /usr/sbin/dpkg-preconfigure: BEGIN: not 
>> found
>> /usr/sbin/dpkg-preconfigure: 1: eval: qq{: not found
>> /usr/sbin/dpkg-preconfigure: 8: /usr/sbin/dpkg-preconfigure: use: not 
>> found
>> /usr/sbin/dpkg-preconfigure: 9: /usr/sbin/dpkg-preconfigure: use: not 
>> found
>> /usr/sbin/dpkg-preconfigure: 10: /usr/sbin/dpkg-preconfigure: Syntax 
>> error: "(" unexpected
>> (Reading database ... 249884 files and directories currently installed.)
>> Removing openssh-server (1:6.7p1-5+deb8u2) ...
>> /usr/bin/perl: 1: /usr/bin/perl: ELF : not found
>> /usr/bin/perl: 3: /usr/bin/perl: Syntax error: "(" unexpected
>> dpkg: error processing package openssh-server (--remove):
>>  subprocess installed post-removal script returned error exit status 2
>> Errors were encountered while processing:
>>  openssh-server
>>
>>
>>
>>
>> Le mardi 7 juin 2016 09:06:27 UTC+2, malkowki a écrit :
>>>
>>> Hi Robert,
>>>
>>> I have tried the command line as you advise but this time I got the 
>>> followng error:
>>>
>>> /usr/sbin/dpkg-reconfigure: line 6: syntax error near unexpected token 
>>> `{'
>>> /usr/sbin/dpkg-reconfigure: line 6: `if (exists $ENV{
>>>

[beagleboard] Re: Burned out BBB with AIN0 > 1.8V

2016-06-08 Thread Chris Green 
Doyle S  wrote:
> 
> Any suggestions or part numbers are much appreciated!  Please, if it's not 
> to difficult, let me know which op-amps you've used.
> 
After a little looking I found it.  I'm using LM10CN op-amps.


> I've worked with the LM324 in the past for another project so I'm 
> relatively comfortable with this one.
> 
> Thanks again all!
> 
N.B. *Please* don't E-Mail me as well as the list.

-- 
Chris Green
·

-- 
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/2b8l2d-snr.ln1%40esprimo.zbmc.eu.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] 9 of the best cloud platform for Beaglebone series product! Find out Which one is yours!

2016-06-08 Thread Mushi Zeng 




Here are nine of the most popular cloud platform for IOT development.All of 
them can be used on beaglebone series products and linkit series products.

See the platforms HERE !

and Share your analysis to all the hackers ! Let's find our which one is 
the most popular for all the IOT developers!

-- 
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/22da35ce-cfb6-45db-9031-543eb95b07ab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Burned out BBB with AIN0 > 1.8V

2016-06-08 Thread Chris Green 
el huitzilo  wrote:
> [-- multipart/alternative, encoding 7bit, 89 lines --]
> 
> [-- text/plain, encoding 7bit, charset: UTF-8, 35 lines --]
> 
> Hi,
> 
> chiming in here because I'm about to build my first circuit that uses ADCs 
> on BBB...
> 
> >   My standard advice 
> >> > would be to run the analog voltage through a non-inverting op amp 
> >> > configured as a gain stage.  You run the op-amp (and have to pick one 
> >> > that does rail to rail and also runs from 1.8 volts) from the 1.8 volt 
> >> > supply.   
> >> > 
> >> Yes, that's what I do.  There are quite a few very low power op-amps 
> >> suitable for running from the 1.8 volt rail on the BBB.  If OP is 
> >> interested I can look up the device, it's from TI if I remember. 
> >>
> >
> In my somewhat amateurish approach to this I was planning to use a DC-DC 
> converter to provide 1.8 VCC for my sensors. I'm still learning about 
> op-amps and anything more advanced than a transistor, so I wonder whether 
> there are any advantages to using an op-amp compared to providing 1.8 V 
> from a switching DC-DC converter? 
> 
The op-amp is to use as a buffer to protect the inputs, not to provide
1.8 volts.  The LM10CN op-amps I'm using are such low power devices
that one can use the 1.8 volt ADC reference from the BBB to supply
them. 

-- 
Chris Green
·

-- 
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/ve8l2d-snr.ln1%40esprimo.zbmc.eu.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] AM335x SGX driver issue (pvrsrvctl: no such file or directory)

2016-06-08 Thread Matthew Remfrey 
I've been struggling with this for a few days now and it feels like it's 
time to ask for some help :) I originally posted this to the Ti e2e forum, 
but they have told me they do not provide support assistance for Angstrom :(

I would like to use the OpenGLES SDK for software development. I am 
targeting a Chipsee 1000 x 600 7" BBB cape, using an Angstrom build 
provided by Chipsee, which I'm trying to modify to include the SGX driver.

I've followed the installation guide carefully, but at the end of 
installing the am335x demo on the target device, i get this error:
./rc.pvr: line 52: /usr/local/bin/pvrsrvctl: No such file or directory

Weirdly, pvrsrvctl does seem to be in that directory, but it doesn't 
execute. When I try, I get the same error as above! I also get this error 
if I try and execute any of the demos, even after a reboot, after doing 
depmod -a. 

Running lsmod after executing the am335x demo program does seem to indicate 
pvrsrvkm is running, but there's no sign of omapflb:

The steps i'm following to modify the Chipsee build i have are:


*1. Build the custom Chipsee Angstrom kernel with module support* 
This includes a "make 0=am335x am335x_evm" command that creates the MLO and 
u-boot.img files

*2. Build and install the SGX module*
Using "make OMAPES=8.x all" and "make OMAPES=8.x install"... having 
modified the Rules.make paths first... it complains if i haven't already 
built the kernel with module support...

*3. Rebuild and install the modules* 
In the root of the kernel source directory, "make modules 
INSTALL_MOD_PATH=/path/to/filesystem" and "make modules_install 
INSTALL_MOD_PATH=/path/to/filesystem"




*4. Package it up and flash it to the target5. Boot into new image, disable 
Window Manager and then run /etc/init.d/335x-demo*

 

I transferred gfx_check.sh onto the target and have executed that, with 
these results:

 

WSEGL settings
[default]
WindowSystem=libpvrPVR2D_FRONTWSEGL.so
#WindowSystem=libpvrPVR2D_FLIPWSEGL.so

--
ARM CPU information
processor: 0
model name: ARMv7 Processor rev 2 (v7l)
BogoMIPS: 993.47
Features: swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls 
CPU implementer: 0x41
CPU architecture: 7
CPU variant: 0x3
CPU part: 0xc08
CPU revision: 2

Hardware: Generic AM33XX (Flattened Device Tree)
Revision: 
Serial: 
--
SGX driver information
Version SGX_DDK_Linux_CustomerTI sgxddk 1.10@2359475 (release) 
/home/user/Code/angstrom/source/GraphicsSDK/GFX_Linux_KM
System Version String: None
--
Framebuffer settings
--
Rotation settings
0
--
Kernel Module information
Module  Size  Used by
pvrsrvkm  139675  0 
ip_tables   8294  0 
x_tables   15072  1 ip_tables
libcomposite   15228  0 
rfcomm 25106  0 
ircomm_tty 14503  0 
ircomm  8846  1 ircomm_tty
irda   89958  2 ircomm_tty,ircomm
ipv6  229989  12 
hidp   10112  0 
bluetooth 146123  4 hidp,rfcomm
rfkill 16510  2 bluetooth
autofs417432  2 
--
Boot settings
console=ttyO0,115200n8 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait quiet ;
--
Linux Kernel version
Linux beaglebone-exp 3.8.13 #1 SMP Tue Jun 7 06:25:56 BST 2016 armv7l 
GNU/Linux

Any help would be greatly appreciated. I'm probably missing something 
stupid.


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/a7a86b44-63e1-4b51-813f-7ed91318e3fb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Hardware Security of Beagleboard

2016-06-08 Thread Muhammad Faisal 
Hi,
I'm a completely newbie to the world of IoT and embedded systems. For one 
of my project which involves extensive research and software coding using 
RPI2 but there is no way to secure the board from misused or prevent the 
software in SD not to run on other similar board. Also there is no on board 
memory/storage.

Then I came across Beagleboards which are having on board memory this mean 
when i burn the OS image it will reside on the boards not on the SD by 
default. This mean i can ensure the software and hardware security to some 
extent. 

Is this understanding of mine is correct?

Thanks
Faisal.

-- 
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/0ce54609-8090-4adc-b604-7cd5b5dec754%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.