Re: [beagleboard] Power - shutdown

> > *Very much agree with you - even though I don't want to use a battery, it > seems more and more than a battery is a necessity for field use of the BBB, > which would explain the existing connector.* > Having a battery still does not solve two other problems. - Does not solve situations

Re: [beagleboard] nodejs

On Mon, May 2, 2016 at 9:56 PM, evilwulfie wrote: > I installed the nodejs package and noticed that on the command line > > i needed to use nodejs not the standard node command to invoke things > > i created a symlink so that nodejs pointed to node and all is well > > just

[beagleboard] nodejs

I installed the nodejs package and noticed that on the command line i needed to use nodejs not the standard node command to invoke things i created a symlink so that nodejs pointed to node and all is well just wanted to point out the discrepancy. --- This email has been checked for viruses by

[beagleboard] Custom Image advertising itself as Drive instead of USB drive

Hi, I have an issue with the current custom image(kernel_version=4.1.20) where the image advertises itself as a disk image. I didn't have this issue in the previous version of image(3.8.13-bone74.2). The previous version of image will present itself as a USB drive. The 4.1.20 Image

Re: [beagleboard] Re: [beagle-alpha] debian testing: 2016-05-01

By "installling" I mean I'll be compiling my own Nodejs 4.x from source, and creating a package. On Mon, May 2, 2016 at 5:48 PM, William Hermans wrote: > Robert, > > Nodejs 4.x is possible on these images yet ? > > I was considering getting a Jessie image and backing out of

Re: [beagleboard] Re: [beagle-alpha] debian testing: 2016-05-01

Robert, Nodejs 4.x is possible on these images yet ? I was considering getting a Jessie image and backing out of systemd, then attempting to install Nodejs 4.x lts on it. However if these images are not yet capable of Nodejs 4.x . . . then moving onward to a jessie image does not make so much

Re: [beagleboard] Trouble enabling DCAN1 on BeagleBone, think I'm close but missing something.

You're providing far too much information, and not enough of the right information. It would be good to know the output of the following commands. cat /sys/devices/platform/bone_capemgr/slots ifconfig can0 Additionally, I know nothing of the cape you mention, and knowing your circuit layout

Re: [beagleboard] Power - shutdown

On Mon, May 2, 2016 at 6:19 PM, William Hermans wrote: > Robert has had 1 or more Beagleboard's running a read only file system > since . . . What Robert ? 2011 ? But you can search this group, and find > him talking about them in a few different posts. > If you install an

Re: [beagleboard] Setting UART speed on BBB Rev C

https://groups.google.com/forum/#!searchin/beagleboard/Problemas$20para$20comunicar$20com$20o$20Baud$20Rate$205760/beagleboard/GC0rKe6rM0g/13c1ngXF7owJ Read the posts by Peter Hurley On Mon, May 2, 2016 at 1:24 PM, Pierce Nichols wrote: > Hi all, > > I posted this to

Re: [beagleboard] Power - shutdown

Robert has had 1 or more Beagleboard's running a read only file system since . . . What Robert ? 2011 ? But you can search this group, and find him talking about them in a few different posts. On Mon, May 2, 2016 at 12:09 PM, Yiannis Papelis wrote: > Mike, > > Thanks for the

Re: [beagleboard] Power - shutdown

> > *As someone already posted, this is a bit more complicated than that, but > I get the idea.* > I did not see anyone other than you, I, and Gerald post on your discussion here. But I do not get every post to this group.. But, sure . . . it is not as simple as that because while the board is

[beagleboard] Re: [beagle-alpha] debian testing: 2016-05-01

On Mon, May 2, 2016 at 4:00 PM, Robert Nelson wrote: > > > On Mon, May 2, 2016 at 3:11 PM, Jason Kridner wrote: > >> >> >> On Mon, May 2, 2016 at 10:50 AM Robert Nelson >> wrote: >> >>> Howdy! >>> >>> So there's a little

[beagleboard] Re: CCCCCCC's Debug serial port output on unsuccessful boot

I have seen this too. It is as Gerald says. Your cape is loading one or more of the boot pins. I did a cape - even though all the connections were high impedance inputs, it was still enough to twitch the boot pins. Anyway, I ended up adjusting a couple of the pullup resistors to adjust for it on

Re: [beagleboard] debian testing: 2016-05-01

On Mon, May 2, 2016 at 3:50 PM, Rick Mann wrote: > > > On May 2, 2016, at 13:48 , Robert Nelson > wrote: > > > > > > > > On Mon, May 2, 2016 at 3:17 PM, Rick Mann wrote: > > > >> Yeah, sorry. By PRUSS I meant uio_pruss. I

[beagleboard] Re: [beagle-alpha] debian testing: 2016-05-01

On Mon, May 2, 2016 at 3:11 PM, Jason Kridner wrote: > > > On Mon, May 2, 2016 at 10:50 AM Robert Nelson > wrote: > >> Howdy! >> >> So there's a little something new in this week's snapshot: >> >>

Re: [beagleboard] 1-24-16 Debian 8.3 Jessie -- not working

On Mon, May 2, 2016 at 3:01 PM, wrote: > > Hello, I am a novice when it comes to using the BBB. I have a revC and I > have just started to play around with it. I have just updated the board to > the latest image from the beagleboard.org/latest-images web site, which

[beagleboard] CCCCCCC's Debug serial port output on unsuccessful boot

Working with a BBB that has a custom hardware cape on it. Sometimes I get an unsuccessful boot out of it where when connected to the serial debug part I see the letter C printed indefinitely. I'd say 90% of the boot attempts work (serial debug looks normal) and 10% I get the infinite C

Re: [beagleboard] Re: Any difference for PIN9.15 (GPIO1_16) on new BBB

They come up as inputs. Gerald On Mon, May 2, 2016 at 2:38 PM, wrote: > So, Gerald, > Why do you think it is an acceptable condition to to have GPIO1_16 > fighting GPIO2_0 on boot up, and perhaps forever for the case that a BBB > user doesn't happen to notice this

[beagleboard] 1-24-16 Debian 8.3 Jessie -- not working

Hello, I am a novice when it comes to using the BBB. I have a revC and I have just started to play around with it. I have just updated the board to the latest image from the beagleboard.org/latest-images web site, which is the Debian 8.3 "Jessie" build from 24-Jan, and I cannot get anything to

Re: [beagleboard] Re: Any difference for PIN9.15 (GPIO1_16) on new BBB

So, Gerald, Why do you think it is an acceptable condition to to have GPIO1_16 fighting GPIO2_0 on boot up, and perhaps forever for the case that a BBB user doesn't happen to notice this condition, which violates the AM3358 recommended operating conditions? Ref: TI SPRS717J –OCTOBER

[beagleboard] Setting UART speed on BBB Rev C

Hi all, I posted this to the Beaglebone list as well, but it seems a bit dead so I'm reposting here. I would like to find a way to set the speed of the UARTs to something other than the standard speeds offered by termios. I'm running a BBB Rev C with Debian 8.3, stock kernel from

Re: [beagleboard] debian testing: 2016-05-01

> On May 2, 2016, at 13:14 , Jason Kridner wrote: > > > > On Mon, May 2, 2016 at 3:52 PM Rick Mann wrote: > > > On May 2, 2016, at 07:49 , Robert Nelson wrote: > > > > So there's a little something new in this week's

Re: [beagleboard] debian testing: 2016-05-01

On Mon, May 2, 2016 at 3:52 PM Rick Mann wrote: > > > On May 2, 2016, at 07:49 , Robert Nelson > wrote: > > > > So there's a little something new in this week's snapshot: > > > > http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2016-05-01 > >

[beagleboard] Re: [beagle-alpha] debian testing: 2016-05-01

On Mon, May 2, 2016 at 10:50 AM Robert Nelson wrote: > Howdy! > > So there's a little something new in this week's snapshot: > > http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2016-05-01 > > We've now switched from v4.1.x-ti to v4.4.x-ti by default. > With 4.4,

Re: [beagleboard] debian testing: 2016-05-01

> On May 2, 2016, at 07:49 , Robert Nelson wrote: > > So there's a little something new in this week's snapshot: > > http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2016-05-01 > > We've now switched from v4.1.x-ti to v4.4.x-ti by default. So, if I want to use

Re: [beagleboard] Power - shutdown

Mike, Thanks for the suggestion, this seems like a viable alternative. On Monday, May 2, 2016 at 3:02:57 PM UTC-4, mjc wrote: > > On 05/02/2016 02:54 PM, Yiannis Papelis wrote: > > Very much agree with you - even though I don't want to use a battery, it > > seems more and more than a battery

Re: [beagleboard] Power - shutdown

On 05/02/2016 02:54 PM, Yiannis Papelis wrote: Very much agree with you - even though I don't want to use a battery, it seems more and more than a battery is a necessity for field use of the BBB, which would explain the existing connector. In my work, the solution was to use a read-only

Re: [beagleboard] Power - shutdown

As someone already posted, this is a bit more complicated than that, but I get the idea. On Monday, May 2, 2016 at 2:09:44 PM UTC-4, William Hermans wrote: > > *Use a super capacitor.* >> > > Ok, a little abstract . . . > > Use a super capacitor, and if using a console image . . . sudo apt-get

Re: [beagleboard] Power - shutdown

William, Thank you for following up - I appreciate the responses. On Monday, May 2, 2016 at 1:47:45 PM UTC-4, William Hermans wrote: > > *I have been building embedded systems for a while now and I am >> considering using the beaglebone (BBB) for an upcoming project, but I am >> confused by

Re: [beagleboard] Power - shutdown

Very much agree with you - even though I don't want to use a battery, it seems more and more than a battery is a necessity for field use of the BBB, which would explain the existing connector. On Monday, May 2, 2016 at 2:29:18 PM UTC-4, john3909 wrote: > > You cannot just use a supercap. You

[beagleboard] wifi connects then drops during init (Debian 8.4)

Robert Nelson pointed out that the issue blocking wifi is connmand, and not systemd/rfkill. I've fixed that but have run into another issue. Wifi starts, associates and grabs a DHCP address during init. While init is coming up, wifi closes the association, and re-starts, but without

Re: [beagleboard] Power - shutdown

Gerald, Thanks for following up - do you mean that if I don't have anything writing to the file system, I can simply yank the power? I naturally have seen the expansion header usage you listed in your response, is there something specific I should be looking at? On Monday, May 2, 2016 at

Re: [beagleboard] Re: 1-Wire

On Mon, May 2, 2016 at 11:20 AM, wrote: > > > Here the result: > root@c0a80090:/sys/devices/w1_bus_master1# ls -lZ > w1_master_max_slave_count > -r--r--r-- 1 root root ? 4096 May 2 14:45 w1_master_max_slave_count > > I try to use "chmod 777 w1_master_max_slave_count"

Re: [beagleboard] Power - shutdown

You cannot just use a supercap. You have to use a boost switching regulator to keep the voltage on the processor constant while the supercap discharges. This is a lot more complicated than you suggest. You also have to deal with the case of brown outs where the power is only off for fractions

Re: [beagleboard] Power - shutdown

> > *Use a super capacitor.* > Ok, a little abstract . . . Use a super capacitor, and if using a console image . . . sudo apt-get install acpid Then the board will automatically shutdown when 5V input goes missing. I'd make sure you pick a super cap that can sustain the beaglebone for ~30

Re: [beagleboard] Power - shutdown

> > *I have been building embedded systems for a while now and I am > considering using the beaglebone (BBB) for an upcoming project, but I am > confused by everything I read regarding the shutdown requirements. As an > embedded system the only way to turn it off is to simply shutdown the power >

Re: [beagleboard] apt-get install bb-node-red-installer fail

On Sat, Apr 30, 2016 at 12:03 PM, Wally Bkg wrote: > Playing around with tail -f, it turned out the unwanted node-red behavior > was because I forgot to call fflush(). > > This didn't matter for the usage it was originally written for. After a > quick recompile of the

[beagleboard] BeagleBone Black: IPMI Cape

Hello, I've just realized that I would like to have something like IPMI cape for BeagleBone Black. At least, to export BBB TTL console to Ethernet. WizNet serial-to-ethernet chip could be used in conjunction with Davicom DM8203 three-port fast ethernet switch chip. Then I could have single one

Re: [beagleboard] Power - shutdown

On Mon, May 2, 2016 at 10:36 AM, Yiannis Papelis wrote: > I have been building embedded systems for a while now and I am considering > using the beaglebone (BBB) for an upcoming project, but I am confused by > everything I read regarding the shutdown requirements. As an

[beagleboard] Power - shutdown

I have been building embedded systems for a while now and I am considering using the beaglebone (BBB) for an upcoming project, but I am confused by everything I read regarding the shutdown requirements. As an embedded system the only way to turn it off is to simply shutdown the power with a

[beagleboard] Second 1-wire

Hello, I use 1-wire on Pin P8.11 Now I want to use a second 1-wire on Pin P8.12 I made the first 1-wire with this instructions: http://www.bonebrews.com/temperature-monitoring-with-the-ds18b20-on-a-beaglebone-black/ I wrote a new file called w2.dts changed the exclusive pin to "P8.12" and Pin

Re: [beagleboard] Re: 1-Wire

Hello! Here the result: root@c0a80090:/sys/devices/w1_bus_master1# ls -lZ w1_master_max_slave_count -r--r--r-- 1 root root ? 4096 May 2 14:45 w1_master_max_slave_count I try to use "chmod 777 w1_master_max_slave_count" and then the command again, but then I get:

[beagleboard] debian testing: 2016-05-01

Howdy! So there's a little something new in this week's snapshot: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2016-05-01 We've now switched from v4.1.x-ti to v4.4.x-ti by default. hostap/wpasuppliant saw a major upgrade: 2.3 -> 2.5 Board specific documentation: BBW/BBB =

Re: [beagleboard] error at boot in the image : bone-debian-8.4-lxqt-4gb-armhf-2016-04-25-4gb

On Mon, May 2, 2016 at 7:58 AM, Micka wrote: > this one : > > fsck: error 2 (No such file or directory) while executing fsck.ext4 for > /dev/mmcblk0p1 > > I don't understand it. > ignore it, initramfs-tools bug... > > also, how do

Re: [beagleboard] error at boot in the image : bone-debian-8.4-lxqt-4gb-armhf-2016-04-25-4gb

this one : fsck: error 2 (No such file or directory) while executing fsck.ext4 for /dev/mmcblk0p1 I don't understand it. also, how do you set the IP address on jessie ? /etc/network/interfaces ? auto eth0 iface eth0 inet static address

Re: [beagleboard] error at boot in the image : bone-debian-8.4-lxqt-4gb-armhf-2016-04-25-4gb

Hi Micka, On Mon, May 2, 2016 at 5:28 AM, Micka wrote: > Starting kernel ... > > [3.540286] wkup_m3_ipc 44e11324.wkup_m3_ipc: could not get rproc handle > [3.788349] cpu cpu0: cpu0 clock notifier not ready, retry > [3.939012] bone_capemgr bone_capemgr: slot

Re: [beagleboard] Re: Basic lock down

Yes very true but the 2 easy vectors I can see are serial debug cable and micro SD. If anything could be done to discourage it then that would be welcomed. Will look into encrypting the OS though. Good idea. On Mon, 2 May 2016 at 12:49, wrote: > Lee Armstrong

[beagleboard] Re: Basic lock down

Lee Armstrong wrote: > [-- text/plain, encoding 7bit, charset: UTF-8, 12 lines --] > > I have my BBB flashed onto the eMMC and it is feasible for someone to boot > from the SD Card and/or use the serial debug cable to gain access. > > What methods if any have people used

[beagleboard] error at boot in the image : bone-debian-8.4-lxqt-4gb-armhf-2016-04-25-4gb

Starting kernel ... [3.540286] wkup_m3_ipc 44e11324.wkup_m3_ipc: could not get rproc handle [3.788349] cpu cpu0: cpu0 clock notifier not ready, retry [3.939012] bone_capemgr bone_capemgr: slot #0: No cape found [3.999007] bone_capemgr bone_capemgr: slot #1: No cape found [

[beagleboard] unnoticed issue with weather cape

Hallo, I've found a problem with the "weather cape" that I'm planning to use in a student lab. I've bought 5 weather capes release B from Farnell. Two of them work perfectly with beaglebone black and Linux debian. The other three do not allow linux to complete the bootstrap so that it remain

Re: [beagleboard] kernel updates: 4.1.12-ti-r27 (BBB all spi/spidev users rejoice)

On Thu, Nov 5, 2015 at 3:47 PM, Robert Nelson wrote: > The journey into spi & dma.. > > So for awhile now, we've had a bug for spi users, where the system > would hardlock at the "160" byte threashold: > > debian@beaglebone:~$ sudo dd if=/dev/zero of=/dev/spidev1.0 bs=159

[beagleboard] Basic lock down

I have my BBB flashed onto the eMMC and it is feasible for someone to boot from the SD Card and/or use the serial debug cable to gain access. What methods if any have people used to prevent some access? -- For more options, visit http://beagleboard.org/discuss --- You received this message

Re: [beagleboard] Problem with eeprom of beaglebone black in my custom board

Thanks Robert, that was great help. Now everything works well. Regards, Masoud On Monday, May 2, 2016 at 8:07:45 AM UTC+4:30, RobertCNelson wrote: > > > > On Sun, May 1, 2016 at 10:23 PM, masoud hajian > wrote: > >> Dear Robert, >> >> Thanks for you reply. The board is

Re: [beagleboard] Maxim Codec and BBB a different way.

I agree. I've been trying to get a simple audio codec to work for over a year. It worked in 3.1.x, but now in 4.4.x it's marginal, at best (one channel works, not the other). I've been a bit lazy to see what the working 3.1.x version had different. But, it's really complicated, very poorly

[beagleboard] Re: Maxim Codec and BBB a different way.

Many including myself don't understand all the complexity's of the way the alsa-soc is developed. And only a few engineers really have the grasp of it. Its so complex that T.I. themselves said mixing I2C and I2S into the same code bundle makes it unnecessarily hard to develop a routine

[beagleboard] Maxim Codec and BBB a different way.

I am updating our project page for an advanced remotely controlled audio system using the BBB and a Maxim Codec 98089. We use a different method for alsa-soc than most. Our DTB driver only uses I2S and no I2C control mechanism is included in it. We think this makes the I2S routine cleaner

[beagleboard] Re: Beaglebone Black + Audio codec TLV320AIC3106

Something of this nature should work on the command line. amixer -c sset 'Left Line Mixer LLOUT' on # Line out Left enable amixer -c sset 'Right Line Mixer RLOUT' on# Line out Right enable amixer -c sset 'Line DAC' 90 # Adjust Line out volume