[beagleboard] Bug, or conflict with kernels 4.x and universal IO

So this is probably more of an oversight than a bug. But when loading *some* overlays via config-pin overlay , *AFTER* already having loaded an overlay through /boot/uEnv.txt. At least one pin will still continue function correctly( electrically ) but the file that indicates the actual value of

Re: [beagleboard] Building a 2gb lxqt version

err, Samsung emmc modules can't be used with Samsung processors* On Thu, Jan 5, 2017 at 10:28 PM, William Hermans wrote: > Rick, Yes, and in fact I'm going to buy one myself very soon because it > has 2G ram quad A15's and quad A7's, GbE that's true GbE( not shar

Re: [beagleboard] Building a 2gb lxqt version

Rick, Yes, and in fact I'm going to buy one myself very soon because it has 2G ram quad A15's and quad A7's, GbE that's true GbE( not shared with another bus ) and USB 3.0. Plus, the emmc option is pretty dahmed fast in most cases. I think the Sandisk module( Samsung modules can't be used with Sams

Re: [beagleboard] InitRamFs

Oh, and for additional informational purposes. ~/dev on my system is an NFS share, I would not recommend writing files to the emmc, or an sdcard . .. On Thu, Jan 5, 2017 at 5:01 AM, William Hermans wrote: > My last worklog working with the initrd, which by the way is not requi

Re: [beagleboard] InitRamFs

On Thu, Jan 5, 2017 at 4:39 AM, William Hermans wrote: > > > On Thu, Jan 5, 2017 at 4:28 AM, Micka wrote: > >> I saw that. But was not sure. The idea is to save the state of your ram? >> >> > I don't understand your question. But an initial ram disk is a ve

Re: [beagleboard] InitRamFs

On Thu, Jan 5, 2017 at 4:28 AM, Micka wrote: > I saw that. But was not sure. The idea is to save the state of your ram? > > I don't understand your question. But an initial ram disk is a very minimalist Linux file system that is loaded at boot. Used for loading various drivers, early. So for inst

Re: [beagleboard] InitRamFs

r10 */boot/initrd.img-4.4.9-bone-rt-r10: gzip compressed data, last modified: Mon Jan 2 05:05:08 2017, from Unix* On Thu, Jan 5, 2017 at 4:14 AM, William Hermans wrote: > You should really google this Micka, > > But initrd == initial ram disk, and initramfs is a cpio archived initial

Re: [beagleboard] InitRamFs

You should really google this Micka, But initrd == initial ram disk, and initramfs is a cpio archived initial ram disk. On Thu, Jan 5, 2017 at 3:50 AM, Micka wrote: > Hi, I would like how is it initialized in the beaglebone black ? > > What is initrd.img for ? > > > Micka, > > -- > For more opt

Re: [beagleboard] hdmi audio stops at 10 minutes after boot --- always.

, but always for Ubuntu it seems. So maybe it'll cure your problems, maybe it won't. On Mon, Jan 2, 2017 at 3:24 PM, William Hermans wrote: > Ok, my bad, I completely missed the part where you said it still output, > just no sound from speakers . . . > > Well then, that will be

Re: [beagleboard] hdmi audio stops at 10 minutes after boot --- always.

, Jan 2, 2017 at 3:04 PM, William Hermans wrote: > More to the point. Try running the command I gave above *AFTER* the audio > already stops. That'll at least tell you where, and why it fails. After > that you can investigate these reason why. Perhaps providing a fruitful > goo

Re: [beagleboard] hdmi audio stops at 10 minutes after boot --- always.

Jan 2, 2017 at 2:57 PM, William Hermans wrote: > $ strace -o /path/file speaker-test > > > It'll at least tell you where it stops, and most likely why. > > On Mon, Jan 2, 2017 at 2:54 PM, John Franey wrote: > >> William, >> >> Thanks. >> >>

Re: [beagleboard] hdmi audio stops at 10 minutes after boot --- always.

sing which one is the root question anyway. > > > John > > > On Monday, January 2, 2017 at 3:05:14 PM UTC-5, William Hermans wrote: >> >> >> >> On Mon, Jan 2, 2017 at 12:28 PM, John Franey wrote: >> >>> What do you think strace would show? >

Re: [beagleboard] hdmi audio stops at 10 minutes after boot --- always.

past. I only remember seeing issues with dma in relation to SPI, but perhaps it's also an issue for sound too ? Pure speculation on my behalf. On Mon, Jan 2, 2017 at 1:05 PM, William Hermans wrote: > > > On Mon, Jan 2, 2017 at 12:28 PM, John Franey wrote: > >> What do you

Re: [beagleboard] hdmi audio stops at 10 minutes after boot --- always.

On Mon, Jan 2, 2017 at 12:28 PM, John Franey wrote: > What do you think strace would show? > > I used strace a long time ago. Back then, it traced the system calls of > an application process. What should I look for in that output? > > Thanks, > John > Ok so then you know what strace is then

Re: [beagleboard] Re: SPI on beagle bone black and beagle bone black wireless

Yeah, I dont know. For me, it's all a moot point. The biggest hurdle to understanding devices on the beaglebone, is first understanding the hardware period. Then you need to understand the subsystems for each device type - On Linux. After that, device trees, and device tree overlays all start to ma

Re: [beagleboard] hdmi audio stops 10 minutes after boot, repeatable

Any reason why you can't look at the post you made yesterday ? On Mon, Jan 2, 2017 at 12:17 PM, John Franey wrote: > Black's hdmi connected to an hdmi-2-av external powered device connected > to a power amplifier connected to speakers. > > In other words: Black -> hdmi-2-av -> amplifier -> spea

Re: [beagleboard] Re: Cape Manager for U-Boot

v/ debian@beaglebone:~$ ls /dev |grep spidev spidev1.0 spidev1.1 On Fri, Dec 30, 2016 at 5:25 PM, William Hermans wrote: > So I thought about it for a few minutes when not otherwise busy, and > figured it out on my own. > > > $ cd /opt/scripts/tools/develope

Re: [beagleboard] Re: SPI on beagle bone black and beagle bone black wireless

verlay is located in /lib/firmware On Sun, Jan 1, 2017 at 4:21 PM, William Hermans wrote: > So, if you think "ah this is confusing . . ." it does get worse. > > The new future way( I suspect) to load overlays at boot will likely be > through uboot. Robert has recently added

Re: [beagleboard] Re: SPI on beagle bone black and beagle bone black wireless

d about it some here: https://groups.google.com/forum/#!searchin/beagleboard/HERE$20THERE$20BE%7Csort:relevance/beagleboard/W0QPDee5u2s/c1cbhzN4FAAJ On Sun, Jan 1, 2017 at 4:04 PM, William Hermans wrote: > I meant to say I've not used SPI on any embedded Linux platform. I do have > plenty

Re: [beagleboard] hdmi audio stops at 10 minutes after boot --- always.

I'd probably try to run your executable through strace, and output into a file. On Sun, Jan 1, 2017 at 1:25 PM, John Franey wrote: > I have hdmi audio working up until 10 minutes from boot time. Exactly 10 > minutes.every boot. > > I test with 'speaker-test'. Running continuously. Output

Re: [beagleboard] Re: SPI on beagle bone black and beagle bone black wireless

I meant to say I've not used SPI on any embedded Linux platform. I do have plenty of experience with SPI on bare metal MCU's. On Sun, Jan 1, 2017 at 3:35 PM, Greg wrote: > Nice! I will add this as a reference to my project documentation. > > Regarding the fact that you have to run config-pin af

Re: [beagleboard] Re: SPI on beagle bone black and beagle bone black wireless

On Sun, Jan 1, 2017 at 2:08 PM, Greg wrote: > Hi William, if you could point to an easily discoverable source which says > that Universal IO is available in the latest images and encouraged to be > used, then you could be correct. > Being able to successfully manipulate the SOC multiplexer is fun

Re: [beagleboard] Re: SPI on beagle bone black and beagle bone black wireless

to at least create my own overlay based off of existing overlays. On Sun, Jan 1, 2017 at 12:12 PM, William Hermans wrote: > Just to be clear . . . The Hadron collider in Genva is the biggest > engineering "feat" in the world . . .Involving over 10,000 scientists from > over 10

Re: [beagleboard] Re: SPI on beagle bone black and beagle bone black wireless

Just to be clear . . . The Hadron collider in Genva is the biggest engineering "feat" in the world . . .Involving over 10,000 scientists from over 100 countries, and I'm not sure how many engineers. Passed that, it's not surprising the Beaglebone works at all. For instance, you do realize that mos

Re: [beagleboard] Re: SPI on beagle bone black and beagle bone black wireless

Why the repost ? Wasn't it you who alread posted this exact same information 2 days ago ? On Sat, Dec 31, 2016 at 12:39 PM, Graham wrote: > Clayton: > Thanks for taking the time to post this summary. > --- Graham > > == > > On Saturday, December 31, 2016 at 1:23:13 PM UTC-6, Clayton Gulick wrote

Re: [beagleboard] Re: Cape Manager for U-Boot

01 4b 46 7f ff 04 10 e8 : crc=e8 YES 1c 01 4b 46 7f ff 04 10 e8 t=17750 Everything working fine. On Fri, Dec 30, 2016 at 2:07 PM, William Hermans wrote: > On Fri, Dec 30, 2016 at 11:03 AM, Robert Nelson > wrote: > >> Okay, time to push it out as default... >> >> Fir

Re: [beagleboard] Re: Cape Manager for U-Boot

On Fri, Dec 30, 2016 at 11:03 AM, Robert Nelson wrote: > Okay, time to push it out as default... > > First stable build is: > > U-Boot SPL 2017.01-rc2-3-ga4c7d45040 (Dec 30 2016 - 11:30:57) > Trying to boot from MMC1 > > U-Boot 2017.01-rc2-3-ga4c7d45040 (Dec 30 2016 - 11:30:57 -0600), > B

Re: [beagleboard] Cape Manager for U-Boot

On Thu, Dec 29, 2016 at 6:25 PM, William Hermans wrote: > Robert, oh right the other bit of information I needed to let you know > about . . . > > debian@beaglebone:~$ cd /opt/scripts/tools/developers/ > debian@beaglebone:/opt/scripts/tools/developers$ git pull > Already up-

Re: [beagleboard] Cape Manager for U-Boot

#x27;d so an apt-get update. But somehow, I don't think that'd work ;) On Thu, Dec 29, 2016 at 6:12 PM, William Hermans wrote: > > On Thu, Dec 29, 2016 at 6:05 PM, Robert Nelson > wrote: > >> You just stumbled on the biggest issue... >> >> Debugging'

Re: [beagleboard] Cape Manager for U-Boot

On Thu, Dec 29, 2016 at 6:05 PM, Robert Nelson wrote: > You just stumbled on the biggest issue... > > Debugging's going to be fun.. Specially if the end user doesn't have > a usb-serial cable.. > > After u-boot patches the device-tree, the kernel will never know.. > (that's also why things, vide

Re: [beagleboard] Cape Manager for U-Boot

, Dec 29, 2016 at 5:53 PM, Robert Nelson wrote: > On Thu, Dec 29, 2016 at 6:31 PM, William Hermans > wrote: > > > > > > On Thu, Dec 29, 2016 at 3:05 PM, Robert Nelson > > wrote: > >> > >> Okay, second pass more things work, more corner cases to fix

Re: [beagleboard] Re: Cape Manager for U-Boot

e to disable the kernel / userspace cap manager, or the uboot cape manager? The later doesn't make sense to me. what who says that it needs to ? On Thu, Dec 29, 2016 at 5:36 PM, William Hermans wrote: > > > On Thu, Dec 29, 2016 at 3:16 PM, Robert Nelson > wrote: > >> >

Re: [beagleboard] Re: Cape Manager for U-Boot

On Thu, Dec 29, 2016 at 3:16 PM, Robert Nelson wrote: > > First issue... Now the Kernel Cape Manager get's in the way, i need to > > pass a global kill switch (or find the global disable), right now you > > have to "disable" capes loaded by U-Boot.. (you don't have too, it > > just looks weird wh

Re: [beagleboard] Cape Manager for U-Boot

On Thu, Dec 29, 2016 at 3:05 PM, Robert Nelson wrote: > Okay, second pass more things work, more corner cases to fix... > Does this replace the current method? Yes, I'm thinking for v4.10.x+ ;) > > What have you tested it on? Just BB-UART2-00A0.dtbo and then i wrote > this email up and got re

Re: [beagleboard] What kernel is recommended?

Not to mention that redesigning the same processor with a different GPU in it would cost a lot of money too. But that does not explain the newer processors with integrated GPU's from the same company. On Wed, Dec 28, 2016 at 6:42 PM, William Hermans wrote: > > > On Wed, Dec 28, 2

Re: [beagleboard] What kernel is recommended?

On Wed, Dec 28, 2016 at 6:20 PM, Brett Sawyer wrote: > Thank you Robert! FBDEV is exactly what I need for this project so I'll > start with option 1. I appreciate the work you have put into the > beagleboard.org projects. I remember the beagleboard-xm had similar > struggles. Why is SGX always so

Re: [beagleboard] U-Boot overlays (HERE BE EVIL DRAGONS, AND THEY BE HUNGRY) ;)

d, Dec 28, 2016 at 7:31 PM, evilwulfie wrote: > >> why does this person repost these emails without adding any comments ? ? >> >> On 12/28/2016 5:44 PM, chao.ruth via BeagleBoard wrote: >> > -------- >> > On Thu, 12/29/16,

Re: [beagleboard] U-Boot overlays (HERE BE EVIL DRAGONS, AND THEY BE HUNGRY) ;)

Anyway, this is pretty slick. How long do you figure it'll take before this functionality come into the default uboot ? On Wed, Dec 28, 2016 at 9:36 AM, William Hermans wrote: > Robert, > > Have you created a script that removes all the unnecessary kernel modules > loaded supe

Re: [beagleboard] U-Boot overlays (HERE BE EVIL DRAGONS, AND THEY BE HUNGRY) ;)

Robert, Have you created a script that removes all the unnecessary kernel modules loaded superfluously at boot ? I mean there are a lot of them, and I'd say that 99% of them in most cases will just be wasting a lot of memory . . . On Wed, Dec 28, 2016 at 9:34 AM, William Hermans wrote: &g

Re: [beagleboard] U-Boot overlays (HERE BE EVIL DRAGONS, AND THEY BE HUNGRY) ;)

test, and something I could also test in hardware > right away. > > On Wed, Dec 28, 2016 at 8:27 AM, Robert Nelson > wrote: > >> On Wed, Dec 28, 2016 at 9:25 AM, William Hermans >> wrote: >> > On Wed, Dec 28, 2016 at 8:23 AM, Robert Nelson > > >&g

Re: [beagleboard] U-Boot overlays (HERE BE EVIL DRAGONS, AND THEY BE HUNGRY) ;)

away. On Wed, Dec 28, 2016 at 8:27 AM, Robert Nelson wrote: > On Wed, Dec 28, 2016 at 9:25 AM, William Hermans > wrote: > > On Wed, Dec 28, 2016 at 8:23 AM, Robert Nelson > > wrote: > >> > >> On Wed, Dec 28, 2016 at 9:10 AM, William Hermans > >> wr

Re: [beagleboard] EQEP pin conflict with MCASP

On Wed, Dec 28, 2016 at 8:10 AM, Kevin Cox wrote: > Hello > > I am trying to enable and use eqep0 on my BBB (kernel 4.4.30-ti-r64) and > am encountering a pin conflict (pin 107) between the eqep driver and mcasp > driver > > From dmesg output: > > [ 41.150493] eqep 48300180.eqep: ver. 1.0 > [

Re: [beagleboard] U-Boot overlays (HERE BE EVIL DRAGONS, AND THEY BE HUNGRY) ;)

On Wed, Dec 28, 2016 at 8:23 AM, Robert Nelson wrote: > On Wed, Dec 28, 2016 at 9:10 AM, William Hermans > wrote: > > So what you're telling me that testing for different boards is > irrelevant ? > > That is correct. This feature has been enabled in our version of &

Re: [beagleboard] U-Boot overlays (HERE BE EVIL DRAGONS, AND THEY BE HUNGRY) ;)

t; If not, eMMC probably messing with you.. > > dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10 > Is a bit heavy handed, and perhaps a bit too overboard. On Wed, Dec 28, 2016 at 8:10 AM, William Hermans wrote: > So what you're telling me that testing for different boards is irrelev

Re: [beagleboard] U-Boot overlays (HERE BE EVIL DRAGONS, AND THEY BE HUNGRY) ;)

So what you're telling me that testing for different boards is irrelevant ? On Wed, Dec 28, 2016 at 6:14 AM, Robert Nelson wrote: > On Wed, Dec 28, 2016 at 4:07 AM, William Hermans > wrote: > > By the way, I could test with 3 different boards. and A5A, an Element14 >

Re: [beagleboard] U-Boot overlays (HERE BE EVIL DRAGONS, AND THEY BE HUNGRY) ;)

By the way, I could test with 3 different boards. and A5A, an Element14 RevC, and an BBG. On Wed, Dec 28, 2016 at 3:04 AM, William Hermans wrote: > So . . . > > On Fri, Dec 23, 2016 at 3:50 PM, Robert Nelson > wrote: > >> Okay, i have a version of u-boot with overlays en

Re: [beagleboard] U-Boot overlays (HERE BE EVIL DRAGONS, AND THEY BE HUNGRY) ;)

So . . . On Fri, Dec 23, 2016 at 3:50 PM, Robert Nelson wrote: > Okay, i have a version of u-boot with overlays enabled, ready for some > basic testing.. > > *Background*** > > in u-boot we are doing: > > dtb= is loaded at ${fdtaddr} > > We read /b

Re: [beagleboard] Re: How do I keep a program running after disconnecting from ssh?

Generally, all you need is '&' to send the process to the background. So if I had a Nodejs script called 'app.js' . . . $ node app.js & This would start app.js through node, then send the process into the background. Giving me a PID which I could use later to kill the process. On Tue, Dec 27, 2

Re: [beagleboard] Turn off VDD_5V or SYS_5V

On Mon, Dec 26, 2016 at 5:19 PM, Denis Cosmin wrote: > I wanted to power an Arduino and I didn't want to use a relay. > Technically speaking, what you're asking I do think is possible. When using a battery, the beaglebone will still continue running after the 5VDC input is removed. However, sinc

Re: [beagleboard] U-Boot overlays (HERE BE EVIL DRAGONS, AND THEY BE HUNGRY) ;)

On Fri, Dec 23, 2016 at 6:15 PM, Robert Nelson wrote: > > the cpsw/eth0 is just broken. ;) i saw on github (irc zmatt) was looking > at it: > > https://github.com/dutchanddutch/bb-kernel/commit/ > 0c720957b43a8cea423b80e9fa8772ddb41c186c hmmm, I wonder if that works ? Matthijs hehe I should h

Re: [beagleboard] U-Boot overlays (HERE BE EVIL DRAGONS, AND THEY BE HUNGRY) ;)

On Fri, Dec 23, 2016 at 5:58 PM, Robert Nelson wrote: > For those interfaces, there's not a lot of overlay loading issues on > the kernel side. The biggest change, you should see your pin's taken > earlier and more consistently at bootup. You can also optimize your > boot time more, as one of t

Re: [beagleboard] U-Boot overlays (HERE BE EVIL DRAGONS, AND THEY BE HUNGRY) ;)

Robert, So, I have a custom overlay for a physical custom cape . . . as of this moment, I have a few gpio's( I think around 22 ish ), 6 PWM's,, and eventually I can put an ADC into that same overlay. Right, now for the ADC I'm just loading the "stock" ADC overlay for ADC functionality. Additionall

Re: [beagleboard] Re: Announcement: Debian 8.6 released for all boards

On Fri, Dec 23, 2016 at 11:21 AM, John Dammeyer wrote: > Ah the vigilante police strike again with zero information and instead the > usual "you're an idiot for posting here comment". I'm sorry you don't > understand this question. If you don't have anything useful to post then > please don

Re: [beagleboard] Re: Announcement: Debian 8.6 released for all boards

On Fri, Dec 23, 2016 at 10:36 AM, John Dammeyer wrote: > My apologies Robert, > I realize now after seeing your answer (sarcastic?) that the lack of a > question mark at the end of the sentence left it as a statement rather than > a question. So I'll start with the question and then elaborate. >

Re: [beagleboard] HID on BBB with 4.9 kernel

On Wed, Dec 21, 2016 at 1:56 PM, roboknight wrote: > > > On Tuesday, December 20, 2016 at 3:27:44 PM UTC-5, William Hermans wrote: >> >> >> >> On Tue, Dec 20, 2016 at 10:02 AM, roboknight wrote: >> >> At the underlined point, I believe ep->des

Re: [beagleboard] Shutting Down PRUs via RemoteProc Framework from user-space?

terial! > > I'm wrapping up some documentation, want to get it done, RemoteProc > shutdown is a secondary issue so I will put it on the backburner until I > have another look at the kernel. > > On Wednesday, December 21, 2016 at 9:28:38 AM UTC-5, William Hermans wrote: >>

Re: [beagleboard] Shutting Down PRUs via RemoteProc Framework from user-space?

Greg, have you read the remoteproc kernel documentation ? I did like a year ago, and I do want to say there is a method to halt remoteproc. But I'm not sure, and even if I did read that. There is no telling if it's actually been implemented yet into our kernel / kernel modules . . . On Wed, Dec 21

Re: [beagleboard] 3v3 regulator bug

power input to the beaglebone. Where the power is disconnected depends on whether you're externally powering via Geralds, and mine( for that matter ) preferred method. Or via a LiPO connected directly to the beaglebone / PMIC. On Wed, Dec 21, 2016 at 7:14 AM, William Hermans wrote: > On Wed

Re: [beagleboard] 3v3 regulator bug

On Wed, Dec 21, 2016 at 7:00 AM, Jason van Belzen wrote: > I understand that an external battery cape is the best solution. > Do you know if the following is possible from linux perspective: > >- We run on battery and DC power >- If we detect DC power loss, we close all running processes

Re: [beagleboard] 3v3 regulator bug

On Wed, Dec 21, 2016 at 6:42 AM, Gerald Coley wrote: > In my experience, and external battery is the way to go. I designed a cape > for that a log time ago. That let's you support multiple types of battery > chemistry and multiple configurations. > > Gerald > > I think that is the best way to go

Re: [beagleboard] 3v3 regulator bug

On Wed, Dec 21, 2016 at 6:26 AM, Jason van Belzen wrote: > Thanks for your reply. > > How does this issue damage the processor? > > Jason > As Gerald already said, I do not believe it does either. What does happen however is that the board when in this state through the PMIC wont always reset fr

Re: [beagleboard] Supporting Ubuntu Core on BBB in the long term

t 7:37 PM, 'Luther Goh Lu Feng' via > BeagleBoard > wrote: > > > On Monday, December 19, 2016 at > 4:04:47 AM UTC+8, William Hermans wrote: > On Sun, Dec 18, 2016 at > 1:00 PM, 'Luther Goh Lu Feng' via BeagleBoard > wrote: > Noted your

Re: [beagleboard] Libpruio repository for Debian 7 or 8

On Tue, Dec 20, 2016 at 1:28 PM, Renzo Fabián wrote: > Is there a repository that allows install libpruio using "apt-get install" > in Debian 7 or 8? > > Thanks. > No. At least not form the official, or RCN repo's. -- For more options, visit http://beagleboard.org/discuss --- You received thi

Re: [beagleboard] HID on BBB with 4.9 kernel

m also not sure who would need to be contacted for this type of situation. But it's likely the maintainer for this part of the kernel. On Tue, Dec 20, 2016 at 1:27 PM, William Hermans wrote: > > > On Tue, Dec 20, 2016 at 10:02 AM, roboknight wrote: > > At the underlined p

Re: [beagleboard] HID on BBB with 4.9 kernel

On Tue, Dec 20, 2016 at 10:02 AM, roboknight wrote: At the underlined point, I believe ep->desc is NULL because using the kernel and an arm objdump variant, > > I located the assembly that is causing the NULL dereference. Inside of > usb_endpoing_dir_out, it tries to > dereference ep->desc, but

Re: [beagleboard] Load address for beagle bone.

william@beaglebone:~$ uname -r 4.4.27-ti-r62 william@beaglebone:~$ cat /etc/dogtag BeagleBoard.org Debian Image 2016-10-30 william@beaglebone:~$ head /uEnv.txt ##These are needed to be compliant with Angstrom's 2013.06.20 u-boot. loadaddr=0x8200 fdtaddr=0x8800 rdaddr=0x8808 initrd_hig

Re: [beagleboard] Re: Wireless speed issues?

On Tue, Dec 20, 2016 at 7:16 AM, Jay Doobie wrote: > Is there a power supply requirement difference between the BBB and a BBBW? > > You should get, and read the SRM for the BBBW. But there almost certainly is. > > The BBB works great outside of my machine connected to USB on a computer, > but w

Re: [beagleboard] Re: Wireless speed issues?

3d printer may > either be faulty or at it's limit of what it can supply. Going to look > into a slightly beefier supply. > > On Monday, December 19, 2016 at 3:42:01 PM UTC-5, William Hermans wrote: >> >> Well I do not have a BBBW, but I do have an rPI 3. Disabl

Re: [beagleboard] Re: BBB Ethernet stopped working.

You know, I've had my hand on 4 BBB's and well over 40 BBG's and have yet to see this problem manifest it's self. On Mon, Dec 19, 2016 at 3:17 PM, wrote: > Hi Gerald, > > I saw your comment in response to the question about another revision to > the BBB. There is a long standing issue with the

Re: [beagleboard] Console image vs IOT image

On Mon, Dec 19, 2016 at 3:02 PM, Ross Morrison wrote: > On the latest images page(https://beagleboard.org/latest-images) has > the IOT version replaced the plain jane console image? I would really > like to build from the latest basic console image then add options as > needed. > Have you actual

Re: [beagleboard] Re: How to see the beagleBone Board from a VBOX running Ubuntu14.04.02LTS

On Mon, Dec 19, 2016 at 1:40 PM, Graham wrote: > I would recommend putting the BBB directly on the Ethernet network, > Then connect to it via Ethernet. > > The USB-Bridge is useful only in certain simple connection configurations. > > --- Graham > Some people, specifically that are college stude

Re: [beagleboard] Re: Wireless speed issues?

Well I do not have a BBBW, but I do have an rPI 3. Disabling power save at boot is fairly easy. william@rpi:~$ sudo nano /etc/rc.local Add: /sbin/iw dev wlan0 set power_save off william@rpi:~$ sudo reboot william@rpi:~$ iwconfig wlan0 wlan0 IEEE 802.11bgn Mode:Master Tx-Power=31 dBm

Re: [beagleboard] Supporting Ubuntu Core on BBB in the long term

On Sun, Dec 18, 2016 at 1:00 PM, 'Luther Goh Lu Feng' via BeagleBoard < beagleboard@googlegroups.com> wrote: > Noted your comments. In case it isn't clear, I am referring to Ubuntu > Core[1], not Ubuntu. My use case, I am looking at deploying BBB as IoT > gateway devices and I am assessing Ubuntu

Re: [beagleboard] Supporting Ubuntu Core on BBB in the long term

I'm not sure I understand the rationale behind wanting to run Ubuntu on the Beaglebone hardware. Doing so would present all sort of problems for the end user attempting to replicate what others do with this platform using Debian. Also, while this hardware platform *can* run a desktop environment. I

Re: [beagleboard] are there other ARMHF repos?

beaglebones was built on a Raspberry Pi 3 running Raspbian Jessie, with gcc 4.9.x. The point I'm trying to make here, is that this package would, and does work for more than just the beaglebones. On Sun, Dec 18, 2016 at 12:15 PM, William Hermans wrote: > > > On Sun, Dec 18, 20

Re: [beagleboard] are there other ARMHF repos?

On Sun, Dec 18, 2016 at 11:56 AM, Stephane Charette < stephanechare...@gmail.com> wrote: > By default when I install a BB with one of the usual RCN builds, the repos > as defined in /etc/apt/sources.list are set to the following: > > deb http://httpredir.debian.org/debian/ jessie main contrib non-

Re: [beagleboard] Re: Ubuntu on the Beagle

On Sun, Dec 18, 2016 at 5:05 AM, Elena ``of Valhalla'' < elena.valha...@gmail.com> wrote: > > Other hardware that may be problematic of course is new hardware which > requires a new kernel, and if you're not already using testing (as > mentioned in the other email), usually there is always one in

Re: [beagleboard] Re: Ubuntu on the Beagle

On Sun, Dec 18, 2016 at 2:40 AM, Elena ``of Valhalla'' < elena.valha...@gmail.com> wrote: > On 2016-12-15 at 14:49:25 -0700, William Hermans wrote: > > Debian, and Ubuntu use different init daemons, at least the last I > > read. Although I've also read that

Re: [beagleboard] Re: pru + 4.4 kernel?

>From my own perspective, it does not matter one single bit. I suscribe to the beagleboard.org google group, i get all mails from that group. No idea of sub groups, or whatever. . . .quite honestly I don;t even care. If i know the answer or can give some clues, I'll answer, or give some clues. .

Re: [beagleboard] Re: pru + 4.4 kernel?

Jay, So keep this in mind, 99% chance, what you've done, you've somehow screwed up. Don't take this as a negative response please. But more or less a realistic response. I've done "similar" myself. the whole time, I might be thinking . .. "I'm going to let x.y.z have it on the groups . . ." only t

Re: [beagleboard] Barrel Connector on BBBWL not soldered on 5v Pin

Thats a case where you make the call. On Fri, Dec 16, 2016 at 5:12 PM, Gregg Harrington wrote: > Is this a case I should RMA it? Or should I just solder it down? > > Thanks, > > Gregg > > > On Friday, December 16, 2016 at 2:43:52 PM UTC-8, RobertCNelson wrote: >> >> On Fri, Dec 16, 2016 at 4:39

Re: [beagleboard] Re: pru + 4.4 kernel?

On Fri, Dec 16, 2016 at 11:55 AM, Jay Doobie wrote: > Ya know, I figured out what happened, I wish things were a bit better > documented, what you indicated above about creating the initramfs fixed > it. I believe what happened was I modifed the uEnv.txt file and thought it > took my changes, bu

Re: [beagleboard] Re: pru + 4.4 kernel?

> /Jason > > On Friday, December 16, 2016 at 1:41:28 PM UTC-5, William Hermans wrote: >> >> So whatever way that works for you, is the right way. But yes, in my own >>> opinion loading from uEnv.txt is the proper way. As the pin configurations >>> take

Re: [beagleboard] Re: pru + 4.4 kernel?

s$ sudo reboot > > Then your custom overlay will be "injected" into the initramfs, and > properly load at boot. > On Fri, Dec 16, 2016 at 11:39 AM, William Hermans wrote: > Jay, > > If by "updating" you mean your overlay isn't loading at boot. That woul

Re: [beagleboard] Re: pru + 4.4 kernel?

Jay, If by "updating" you mean your overlay isn't loading at boot. That would be because the overlay is not in the initramfs. Which is needed for the latest images. I actually posted on the groups about this a few days go, so I'll find my post and copy paste the procedure here. If this is not wha

Re: [beagleboard] Re: pru + 4.4 kernel?

On Thu, Dec 15, 2016 at 8:40 PM, Jay Doobie wrote: > Sadly this did not work. I'm using the default kernel/setup from the > image bone-debian-8.6-lxqt-4gb-armhf-2016-11-06-4gb.img.xz > . > It uses kernel

Re: [beagleboard] BBGW uEnv.txt: 2 lines that work on BBB fail to boot on BBGW

By the way . . . Yes, I can read the dts files fairly easily. The problem is knowing which > overlays are included for a given device. > Everything in /lib/firmware/ On Thu, Dec 15, 2016 at 6:18 PM, William Hermans wrote: > > > On Thu, Dec 15, 2016 at 3:06 PM, codemonkey w

Re: [beagleboard] BBGW uEnv.txt: 2 lines that work on BBB fail to boot on BBGW

On Thu, Dec 15, 2016 at 3:06 PM, codemonkey wrote: > Your intuition seems to be very good. After much testing, I now can see > that as soon as I enable "dtb=am335x-boneblack-emmc-overlay.dtb" and > reboot, the system does come up but wlan0 is no longer known. By that I > mean that "ifconfig -a" a

Re: [beagleboard] Overlay does not create SPI pingroups with 4.4.21 kernel

Do also keep in mind, I'm talking about recent images. The older images that use 3.8.x do not need this done that I'm aware of. I've been using 4.x for a long time now, and I do not recall off hand. On Thu, Dec 15, 2016 at 4:37 PM, William Hermans wrote: > If you load overlay

Re: [beagleboard] Overlay does not create SPI pingroups with 4.4.21 kernel

If you load overlays that are already included in your image, then you do not have to update the initramfs. But if you create your own custom overlay, it will not be included in the initramfs. On Thu, Dec 15, 2016 at 4:10 PM, Phil wrote: > Thanks for the info. I am not so sure about the need to

Re: [beagleboard] Re: Ubuntu on the Beagle

g cycle. Which by the way is why Debian is behind the curve for software, and hardware support. If something does not "make the grade" within a certain time frame, then that something does not make it into the next stable release of the distro. Which many, many people prefer. On Thu, Dec

Re: [beagleboard] Overlay does not create SPI pingroups with 4.4.21 kernel

On Thu, Dec 15, 2016 at 12:36 PM, Phil wrote: > On Thursday, December 15, 2016 at 11:20:13 AM UTC-6, Phil wrote: > I have written a device tree overlay that incorporates SPI0, SPI1 and the > PRUSS, and where SPI1 uses a GPIO for a 2nd chip select. Can I load this in > the same manner via the kern

Re: [beagleboard] BBGW uEnv.txt: 2 lines that work on BBB fail to boot on BBGW

On Thu, Dec 15, 2016 at 12:03 PM, codemonkey wrote: > Hello William, thank you for the prompt response. First of all, I have to > say that I have very little experience with the device tree, although I did > use dtb-rebuilder to enable SPI back in the linux v3.8 days. So, my first > request is: p

Re: [beagleboard] Re: How to set time automatically at power up?

There's also a software package known as fake hwclock. It's not a real time clock, and perhaps it'll even lose time over long periods. But it seems to do a reasonable job of keeping time on a system close. We actually use DS3232 on those devices that *need* to keep accurate time. On Thu, Dec 15,

Re: [beagleboard] Re: Ubuntu on the Beagle

On Thu, Dec 15, 2016 at 3:02 AM, Heinz Hummel wrote: > I don't know what the reason is but I personally prefer Ubuntu because it > is easier to use, it has a bigger community which is more responsive and > more friendly and one can choose to use a LTS version (and stay with older > software) or a

Re: [beagleboard] BBGW uEnv.txt: 2 lines that work on BBB fail to boot on BBGW

Additionally, this is a reason for you to buy a serial debug cable, or module. With such a device, you'd probably know exactly why the board fails to boot, or at minimum have a really good idea based on uboot output. On Wed, Dec 14, 2016 at 5:18 PM, William Hermans wrote: > That cape d

Re: [beagleboard] BBGW uEnv.txt: 2 lines that work on BBB fail to boot on BBGW

That cape does work on the Beaglebone green. However, the Beaglebone green, and Beaglebone black both have ethernet, where the Beaglebone green wireless has a wifi network interface. So, this is an assumption but here are two points of contention: 1. Since the BBGW has wifi and the Beaglebone

Re: [beagleboard] Difference between images available at https://rcn-ee.com/rootfs/bb.org/testing/2016-12-12/iot/

IF you're using Windows, this is most likely a Windows issue. The thing I've found in the past when dealing with the USB g_ether gadget driver. Is that when upgrading from one image to another on the Beaglebone you may have to upgrade the driver on the Windows host side. This is one place where Win

Re: [beagleboard] Re: Loading PRU overlay causes BBB to lock

You should not have to upgrade the device tree compiler( dtc ). As each kernel version, as provided with the latest images have the proper device tree compiler. However, assuming, running Wheezy, then upgrading to a newer kernel( 3.8.x to 4.x ) the device tree compiler would have to be upgraded at

Re: [beagleboard] Re: Cape for picamera

The Logitech 920C I believe it is is reported to work very well with the Beaglebone. On Tue, Dec 13, 2016 at 10:37 AM, Andrew Goh wrote: > On Sunday, July 14, 2013 at 7:08:45 PM UTC+8, James Richins wrote: >> >> Is it possible for there to be an interface board for the picamera. It is >> signifi

<    1   2   3   4   5   6   7   8   9   10   >