Re: [beagleboard] Re: how to unfreeze my BBB?

On Wed, Feb 15, 2017 at 10:13 AM, mzimmers <mzimm...@gmail.com> wrote: > On Tuesday, February 14, 2017 at 7:58:39 PM UTC-7, William Hermans wrote: >> >> (some excellent directions on modifying boot arguments) >> > > Thanks, William. But, given that the BBB

Re: [beagleboard] Re: how to unfreeze my BBB?

when working with system files. So I don't accidentally modify anything on the live system . . . root@beaglebone:~/a# cd .. root@beaglebone:~# umount /root/a root@beaglebone:~# rm -rf a/ On Tue, Feb 14, 2017 at 8:03 PM, William Hermans <yyrk...@gmail.com> wrote: > By the way, DR. Mol

Re: [beagleboard] Re: how to unfreeze my BBB?

at 7:58 PM, William Hermans <yyrk...@gmail.com> wrote: > > > On Tue, Feb 14, 2017 at 7:02 PM, mzimmers <mzimm...@gmail.com> wrote: > >> >> William: I do in fact own a debug cable. I'll try plugging it in and see >> if I can see anything. I've never work

Re: [beagleboard] Re: how to unfreeze my BBB?

On Tue, Feb 14, 2017 at 7:02 PM, mzimmers wrote: > > William: I do in fact own a debug cable. I'll try plugging it in and see > if I can see anything. I've never worked with boot arguments; can you tell > me where they're kept? > > mz > root@beaglebone:~# lsblk NAME

Re: [beagleboard] how to unfreeze my BBB?

On Tue, Feb 14, 2017 at 4:34 PM, mzimmers wrote: > So, in an attempt to upgrade the OS on my BBB, I managed to get it to lock > up. > > When I try to boot, the LEDs look like normal for a few seconds, but then > LED2 comes on solid, and the others are off. > > This occurs

Re: [beagleboard] Re: Analog input cape/wiring scheme

simply read from the "buffer file". If you're still unconvinced. Google "beaglebone ADC" and learn how simple the software side really is. There are many blogposts out there on the subject. One of which is mine, but seems to be down at this moment. On Mon, Feb 13, 2017 at 6:37

Re: [beagleboard] Re: Analog input cape/wiring scheme

On Mon, Feb 13, 2017 at 11:44 AM, Rob van der Putten wrote: > Hi there > Why is I2C a better choice then SPI? > The BBB has both. > > > Regards, > Rob > >From a software developers perspective, I2C is far simpler. One call to ioctl() to set the mode of the file descriptor, then

Re: [beagleboard] Re: Analog input cape/wiring scheme

On Mon, Feb 13, 2017 at 5:20 AM, Rob van der Putten wrote: > Hi there > > > On 13/02/17 13:01, evilwulfie wrote: > > I use a single rail opamp to level convert and protect the analog input. >> > > It's probably easier to use an SPI ADC (EG: MCP3201) running on 5V and > then do the

Re: [beagleboard] Re: Why use PRU shared DRAM (12k) over individual core DRAM (8k)?

) side of things ? On Thu, Feb 9, 2017 at 7:16 PM, William Hermans <yyrk...@gmail.com> wrote: > > > On Thu, Feb 9, 2017 at 6:56 PM, Charles Steinkuehler < > char...@steinkuehler.net> wrote: > > >You cannot "broadside" store the register file into the

Re: [beagleboard] Re: Why use PRU shared DRAM (12k) over individual core DRAM (8k)?

On Thu, Feb 9, 2017 at 6:56 PM, Charles Steinkuehler < char...@steinkuehler.net> wrote: >You cannot "broadside" store the register file into the 8k or 12k data > > rams, only into one of the three scratch pad locations or directly > into the other PRU's register file. Table 4-21 (of the AM335x

Re: [beagleboard] Re: Why use PRU shared DRAM (12k) over individual core DRAM (8k)?

On Thu, Feb 9, 2017 at 4:20 PM, ags wrote: > Continued review of documentation has caused me to wonder if I've missed a > fundamental error in my thinking about what is and isn't deterministic when > using the PRUs. The PRU-local 32-bit interconnect bus is itself a

Re: [beagleboard] Desired existing open source cape recommendation

s a wide range power supply input without the >> optional UPS battery. >> >> --- Graham >> >> == >> >> >> On Tuesday, February 7, 2017 at 2:17:55 PM UTC-6, William Hermans wrote: >> >> I'd recommend just about any decent UPS type cape with go

Re: [beagleboard] Re: PRU SPI ADC communication

> I dont know if u can answer me, but i have another two question. What is the max RAM i can allocate to the samples from PRU, and if is possible to write directly to an uSDcard working as external > memory from the PRU. If not, i can do the a discuss about this. Theoretically, you should be able

Re: [beagleboard] Re: HELP! - I can't access my BBB any more.

On Wed, Feb 8, 2017 at 3:16 PM, evilwulfie wrote: > ME and a software buddy have a nice watchdog timer powered from the BBB > battery holds up the BBB till it shuts down then removes power > draws 400uA from the battery while waiting for the power to be reapplied. > So, in

Re: [beagleboard] Desired existing open source cape recommendation

I'd recommend just about any decent UPS type cape with good power management features. e.g. Features that addressed the Beaglebone's inability to function remotely( well ). On Tue, Feb 7, 2017 at 1:00 PM, Jason Kridner wrote: > Anyone want to nominate an open source cape to

Re: [beagleboard] Re: No LED light, My BBB perhaps died while running a PocketNC machine

One fast blink of the power LED is a good indication that the processor is shot. On Tue, Feb 7, 2017 at 1:59 AM, wrote: > So I have now removed the board from the machine and plugged it in to the > computer USB again. One fast LED blink happens when it is connected. I have >

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

On Mon, Feb 6, 2017 at 11:00 AM, wrote: > I got the solutio (i think.. hehe) > If you're happy with the code you've got, who am I to argue about it ? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are

Re: [beagleboard] Re: Video image shifts right randomly

On Mon, Feb 6, 2017 at 1:52 PM, William Hermans <yyrk...@gmail.com> wrote: >> >> Something I noticed is that if I pipe /dev/urandom to /dev/fb0, I get all the random colors, even in the left blank area when the image is shifted. Then I started our app and the top left 10 or

Re: [beagleboard] Re: Video image shifts right randomly

> > Something I noticed is that if I pipe /dev/urandom to /dev/fb0, I get all > the random colors, even in the left blank area when the image is shifted. > Then I started our app and the top left 10 or so pixels remained the random > colors. If I then using dd fill /dev/fb0 with zero from

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

you're running from. On Mon, Feb 6, 2017 at 10:52 AM, William Hermans <yyrk...@gmail.com> wrote: > Thinking about how to "throttle" reading from the ADC to get correct > values. A little more. One way you could potentially deal with that > situation could be to change bot

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

echnically htis is a system call, and in addition to adding a hard coded delay, you're likely to also have some system( between user space and kernel space ) non deterministic delay penalty inured. On Mon, Feb 6, 2017 at 10:06 AM, William Hermans <yyrk...@gmail.com> wrote: > > On Mon,

Re: [beagleboard] Configuration GPIO during Linux start up

On Mon, Feb 6, 2017 at 9:49 AM, Shimon Filtzer wrote: > Hello, guys! > For my application I need, that pin P8-13(GPIO23), will get output high > level as soon as possible. As I understand, I need to change both uboot and > kernel. (is it correct?) > But I can not find some

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

, or not. The rest of your code looks like it should work, so I'd clean up your code a bit, throttle the ADC reading loop how TJF suggests, and check your application output. On Mon, Feb 6, 2017 at 8:50 AM, William Hermans <yyrk...@gmail.com> wrote: > > > On Mon, Feb 6, 2017 at 4

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

On Mon, Feb 6, 2017 at 4:21 AM, wrote: > Hello Mr. TJF > > First of All, thank you so much for providing support on real-time tasks > using a low cost plataform. > I'm trying to apply the libary "libpruio" to make a system for energy > meansurement using the

Re: [beagleboard] Re: No LED light, My BBB perhaps died while running a PocketNC machine

> > As the beaglebone is only 3.3v tolerant, and the ADC pins have a max > tolerance of 1.8v. Should read: Most pins on the beaglebone are only 3.3v tolerant with the exception of the ADC pins which are only 1.8v tolerant. On Sun, Feb 5, 2017 at 7:30 PM, William Hermans <yyrk.

Re: [beagleboard] Re: No LED light, My BBB perhaps died while running a PocketNC machine

glebone is only 3.3v tolerant, and the ADC pins have a max tolerance of 1.8v. On Sun, Feb 5, 2017 at 6:38 PM, William Hermans <yyrk...@gmail.com> wrote: > Or as Gerald already eluded to in his first post. Voltage levels on the > GPIO's, or other periphery was too high. > > On Sun, Feb

Re: [beagleboard] Re: No LED light, My BBB perhaps died while running a PocketNC machine

Or as Gerald already eluded to in his first post. Voltage levels on the GPIO's, or other periphery was too high. On Sun, Feb 5, 2017 at 5:18 PM, Dennis Lee Bieber wrote: > On Sun, 5 Feb 2017 07:55:47 -0800 (PST), > mic...@cyto365.com declaimed the following: > > >It

[beagleboard] the-iot-beaglebone-beagle-treat-feeder

The link is not to anything I've done. I only saw the material, and though others might enjoy the link as well.

Re: [beagleboard] i2c read block

On Fri, Feb 3, 2017 at 3:06 AM, Francis wrote: > Hi, > > I am trying to create an application on top/based on the i2c tools. > Everything was working well, except the i2c_smbus_block_process_call(), > which returns an error when called. > > Below is the output of i2cdetect -F:

Re: [beagleboard] Re: [beagle-alpha] v4.9.x-ti now open for testing...

Thanks Drew. On Tue, Jan 31, 2017 at 9:08 PM, Drew Fustini <pdp7p...@gmail.com> wrote: > On Tue, Jan 31, 2017 at 9:28 PM, William Hermans <yyrk...@gmail.com> > wrote: > > Drew, do you have a complete gist on how you set this all up ? Mark Yoder > > was interested i

Re: [beagleboard] Re: [beagle-alpha] v4.9.x-ti now open for testing...

On Tue, Jan 31, 2017 at 4:47 AM, Drew Fustini wrote: > On Mon, Jan 30, 2017 at 8:40 PM, Robert Nelson > wrote: > > Once you enable the power control, it's it acting the same as v4.4.x was? > > Yes, it does read position ok. > > # uname -r >

Re: [beagleboard] Re: Of SPI and such

On Tue, Jan 31, 2017 at 8:08 PM, William Hermans <yyrk...@gmail.com> wrote: > No way in hell CANBUS is going to keep up with multi channel ADC samples > at faster sample rates. If one needs fast, or super fast sampling, the only > real option is going to be SPI. > Sorry, I mea

Re: [beagleboard] BBBwireless Wifi disabled with LiPo

I have no idea what voltage is required by the wifi module is. But if it requires more than 3.7v, it won't get it when you're running off the onboard PMIC battery circuit. So if you need a constant 5v uninterrupted, you would be better off setting up your own external "UPS" type of system. On

Re: [beagleboard] Re: Of SPI and such

No way in hell CANBUS is going to keep up with multi channel ADC samples at faster sample rates. If one needs fast, or super fast sampling, the only real option is going to be SPI. So using the on die ADC last year I did a bit of a test to see how much data really would be written out to "disk"

Re: [beagleboard] Prevent overheating BeagleBone?

you'd care to use. Doing something similar in C++ I think I did in less than 75 lines of code, using no special libraries: root@beaglebone:~# cat /sys/bus/w1/devices/28-*/w1_slave f2 00 4b 46 7f ff 0e 10 f8 : crc=f8 YES f2 00 4b 46 7f ff 0e 10 f8 t=15125 On Thu, Jan 26, 2017 at 11:19 PM, William

Re: [beagleboard] Prevent overheating BeagleBone?

HI Drew, I have not used a thermocouple on the beaglebone it's self. I have however used a SPI interface MAX31855, and they ramp up fairly quickly, and are reasonably accurate. We used this for a convection oven to reflow oven conversion. In testing, it seemed to work really well, but we never

Re: [beagleboard] Re: Syntax highlighter for pasm in Sublime Text 3

On Mon, Jan 23, 2017 at 6:59 PM, Justin Pearson wrote: > > Thanks William & TJF. Following your advice I wrote my own syntax > highlighting file for pasm (for Sublime Text 3): > > https://github.com/justinpearson/pasm-sublime-text-syntax-highlight > > Best, > Justin

Re: [beagleboard] Re: Filesystem read-only

On Mon, Jan 23, 2017 at 3:01 AM, Tarmo Kuuse wrote: > > Actually, that's a relevant question for me too. I got as far as mounting /tmp and /var as ramdisks and configuring logrotate to aggressively compress and prune logs (so they don't swamp the RAM). That's not a very

Re: [beagleboard] Devicetree with IoT Images 4.4.36

With the 4.x kernels the path has changed to: /sys/devices/platform/bone_capemgr/slots On Sun, Jan 22, 2017 at 4:09 AM, Fohnbit wrote: > Hello, > > I setup a new BBB with the image IoT 4.4.36. > > But there I miss the /sys/devices/bone_capemgr.9/slots folder. > > I need

Re: [beagleboard] Re: Beagle expertise needed

On Sat, Jan 21, 2017 at 6:16 PM, Richard Maurer wrote: > > BTW, your .service file had the same bug with a small 'i' in Install, so it would not have worked anyway. That was not my script, that was your service edited, with all the unnecessary stuff removed. Copy-pasted.

Re: [beagleboard] Re: Beagle expertise needed

going to stop caring if they find a solution or not. On Sat, Jan 21, 2017 at 5:06 PM, William Hermans <yyrk...@gmail.com> wrote: > On Sat, Jan 21, 2017 at 5:03 PM, Richard Maurer <maure...@gmail.com> > wrote: > > > > okay, fair enough, although everything on line states

Re: [beagleboard] Re: Beagle expertise needed

On Sat, Jan 21, 2017 at 5:03 PM, Richard Maurer wrote: > > okay, fair enough, although everything on line states to create a symlink. Anyway, I found the error -- if you look at my cut/paste, you'll notice {install] -- should be [Install]. > I was manually copying from my

Re: [beagleboard] Re: Beagle expertise needed

On Sat, Jan 21, 2017 at 4:29 PM, Richard Maurer <maure...@gmail.com> wrote: > > William Hermans, I can assure you that I started with a simple unit file nearly exactly as you had offered. Knowing little about Linux, I somewhat blindly added guesses on additional commands, but with no

Re: [beagleboard] Re: Beagle expertise needed

rt=/usr/bin/imuout.sh > WorkingDirectory=/home/tinkerforge/Example_project/ > StandardOutput=null > > [install] > WantedBy=multi-user.target > Alias=imuout.service > > > > with the same error with various options above attempted and commented out > > > On Sat, Jan

Re: [beagleboard] Re: Syntax highlighter for pasm in Sublime Text 3

You can write your own syntax highlighter for Sublime Text3. I say this, because I've never seen any assembly language highlighting for Sublime text period. And yes, I do use Sublime text myself( for the last 4-5 years ). You might try using C highlighting, to see if the standard C highlighting

Re: [beagleboard] Re: Beagle expertise needed

If you're trying to enable, thus "install" a service with systemctl You need a Wantedby target. But just google: "how to systemd" + and you'll probably be greated by way more hits than you'll ever need. On Sat, Jan 21, 2017 at 12:40 PM, Richard Maurer wrote: > FYI, I ended

Re: [beagleboard] Re: BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

Awesome. So here is a decent reference for all things USB network related: http://www.linux-usb.org/usbnet/ Which I had forgotten that using USB-A to USB-A cables is electrically unsound. E.g. you can destroy USB equipment using these. The cables I was probably remembering was the USB

Re: [beagleboard] Re: BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

On Fri, Jan 20, 2017 at 5:30 PM, William Hermans <yyrk...@gmail.com> wrote: > Bert, So it a distinct possibility you're running into the "wall" that > Robert mentioned in his first post. The OTG interface in the device tree > board overlay file is configured in periphe

Re: [beagleboard] Re: BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

n 20, 2017 at 5:26 PM, William Hermans <yyrk...@gmail.com> wrote: > On Fri, Jan 20, 2017 at 5:20 PM, Bert Beckmann <bertb...@gmail.com> wrote: > > > > using ethernet would be simpler but we need the ethernet ports on each > BBB for another purpose (isolated networks). &

Re: [beagleboard] Re: BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

On Fri, Jan 20, 2017 at 5:20 PM, Bert Beckmann wrote: > > using ethernet would be simpler but we need the ethernet ports on each BBB for another purpose (isolated networks). > > I think this will work - the host side of things seems to be behaving properly, the client is not

Re: [beagleboard] Re: BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

Mask:255.255.255.252 ^^ Will be a problem. This mask means you have the ability to use 3 address, of which one is reserved for the broadcast "IP" Which is not usable by an interface. 192.168.7.0. Which, I'm not a network guru, and I could be remembering incorrectly. You could try loosing that

Re: [beagleboard] Re: BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

serial. On Fri, Jan 20, 2017 at 5:01 PM, William Hermans <yyrk...@gmail.com> wrote: > > > On Fri, Jan 20, 2017 at 4:41 PM, Bert Beckmann <bertb...@gmail.com> wrote: > > > > thanks for the quick replies > > > > so I need to rebuild the kernel in order to cha

Re: [beagleboard] Re: BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

On Fri, Jan 20, 2017 at 4:41 PM, Bert Beckmann wrote: > > thanks for the quick replies > > so I need to rebuild the kernel in order to change 'dr_mode' to 'otg'? (it would be much more useful if we didn't have to do this) > > when I boot as is - usb0 comes up ready to

Re: [beagleboard] Re: BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

Bert, Show us the output of the command: *root@beaglebone:~#* ifconfig -a On Fri, Jan 20, 2017 at 4:41 PM, Bert Beckmann wrote: > thanks for the quick replies > > so I need to rebuild the kernel in order to change 'dr_mode' to 'otg'? > (it would be much more useful if

Re: [beagleboard] BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

On Fri, Jan 20, 2017 at 4:20 PM, Robert Nelson wrote: > > The whole musb/otg setup is just weird.. > > I revisited this again last week on the xM, when setting up a > production tester.. > > To use the port as a host, and plug in a (usb flash drive for > example), you

Re: [beagleboard] BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

would have to run on the host board. It's been a while since I've messed with all this though . . . On Fri, Jan 20, 2017 at 4:10 PM, William Hermans <yyrk...@gmail.com> wrote: > This should just work. However, you should be aware this technically is > not peer to peer OTG. This is one O

Re: [beagleboard] BBB USB (OTG) peer to peer (connect 2 BBB's using USB)

This should just work. However, you should be aware this technically is not peer to peer OTG. This is one OTG to host USB. Anyway, this should be no different than connecting a beaglebone to an x86 PC. With the obvious architecture difference as an exception. When you have both connected together

Re: [beagleboard] SPI Woes with different Kernel Versions

> > Now I can use the board with its user space software (no kernel driver > whatsoever involved). > The setup *works* with 3.8 and 4.1 kernels but *not* with 4.4 and 4.9. > Below I have the output of > So maybe if you're a bit more verbose with what you mean by "it doesn't work". What you're

Re: [beagleboard] SPI Woes with different Kernel Versions

Thomas, I don't rightly know. I've done plenty of bare metal SPI, or enough of it anyway. The only thing I've done with SPI on the beaglebone, is a lot of reading. No actual hands on, Honestly I'm not sure if the edma fix would work for your situation or not. I think the edma fix was more or less

Re: [beagleboard] Which script allocates /var/swap.img on second boot?

On Thu, Jan 19, 2017 at 7:44 AM, Robert Nelson wrote: > > > Me too... > > It's definitely not something i added to the default images by default.. > > Are you sure you didn't enable it yourself? > > (doesn't even run swap on my debian x86 development machine) > > Regards,

Re: [beagleboard] BBB SPI throwing ioctl errors

e a copy of the board overlay file I needed. Decompile it with dtc, make my changes to the output file. Then recompile the source with these changes in place. Finally, move the "old" overlay out of the way, and replace with the newly recompiled overlay binary. On Thu, Jan 19, 2017 at

Re: [beagleboard] Which script allocates /var/swap.img on second boot?

By the way, if you use USB networking. Don't disable this service, and don't move, or delete any of the scripts in /opt/scripts/boot On Thu, Jan 19, 2017 at 7:12 AM, William Hermans <yyrk...@gmail.com> wrote: > So . . . > > root@beaglebone:~# systemctl status generic-board-

Re: [beagleboard] BBB SPI throwing ioctl errors

It's not your code, that should be obvious when it work in 3.8.x kernels, and not so well on 4.x. But the first thing that pops into my mind is that this is related to DMA. However about pasting a full output of the error messages you're getting. On Thu, Jan 19, 2017 at 3:41 AM, Gregor Steiner

Re: [beagleboard] Which script allocates /var/swap.img on second boot?

So . . . root@beaglebone:~# systemctl status generic-board-startup.service ● generic-board-startup.service - Generic Board Startup Loaded: loaded (/lib/systemd/system/generic-board-startup.service; disabled; vendor preset: enabled) Active: inactive (dead) This service is responsible for

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

. Worklog and testing output: http://pastebin.com/YkHnZ4f2 On Wed, Jan 18, 2017 at 1:57 PM, William Hermans <yyrk...@gmail.com> wrote: > Yet more information I noticed, sorry for the multiple posts . . . But > notice how the custom cape is attempted to load first, but the actual >

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

, William Hermans <yyrk...@gmail.com> wrote: > Just for informational purposes here is that one pin in my custom overlay: > > . . . >> exclusive-use = >> /* the pin header uses */ >> "P8.11", >> . . . >> /* P8_11 (ZCZ ball R12) */ >

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

gt; input; > dir-changeable; > }; > . . . Then the P8.26 1-wire overlay is exactly the same as the one example 1-wire overlay included with the stock image. But I changed the pin configuration to match P8.26 instead of what was

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

fine since it's already loaded, but . . .I'm not 100% positive. On Wed, Jan 18, 2017 at 1:29 PM, Robert Nelson <robertcnel...@gmail.com> wrote: > On Wed, Jan 18, 2017 at 2:24 PM, William Hermans <yyrk...@gmail.com> > wrote: > > Not enough memory allocated ? > > C

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

Not enough memory allocated ? On Wed, Jan 18, 2017 at 11:30 AM, Robert Nelson wrote: > So adding a couple more fdt commits from u-boot mainline: (to actually > report what failed) > > loading /boot/vmlinuz-4.9.4-bone4 ... > 8225160 bytes read in 543 ms (14.4 MiB/s) >

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

By the way, the kernel I failed with was: linux-image-4.4.43-bone-rt-r16 On Wed, Jan 18, 2017 at 9:32 AM, William Hermans <yyrk...@gmail.com> wrote: > So, I've tested this a few times over the last . . . since announcement >, and I have found that loading a single overlay seems >

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

So, I've tested this a few times over the last . . ., and I have found that loading a single overlay seems to work really good. Attempting multiple overlays however, seems to be an exercise in frustration. e.g. It's not ready. It's possible that I got something wrong, but I do not usually do that

Re: [beagleboard] Beaglebone black bricked... May be???

OK. Be aware, that it should be possible to adapt that course, *somewhat* to work with the beaglebone hardware. But you'll need to understand Llinux, and several other things very well before making that leap. But anything pertaining to the beaglebone hardware, and the boot process will be

Re: [beagleboard] SPI Woes with different Kernel Versions

actually work fine on Jessie images, but I did personally run into troubles trying to update to a 4.x kernel on Wheezy images. On Wed, Jan 18, 2017 at 3:33 AM, William Hermans <yyrk...@gmail.com> wrote: > *root@beaglebone:~#* cat /etc/dogtag > BeagleBoard.org Debian Image 2016-06-

Re: [beagleboard] SPI Woes with different Kernel Versions

*root@beaglebone:~#* cat /etc/dogtag BeagleBoard.org Debian Image 2016-06-19 *root@beaglebone:~#* uname -r 4.4.43-bone-rt-r16 *root@beaglebone:~#* ls /lib/firmware/ |grep SPI BB-SPI0-MCP3008-00A0.dtbo BB-SPIDEV0-00A0.dtbo BB-SPIDEV1-00A0.dtbo BB-SPIDEV1A1-00A0.dtbo *root@beaglebone:~#* ls /dev

Re: [beagleboard] Beaglebone black bricked... May be???

That free electrons course does not seem to revolve around the same hardware. At least at a glance it seems to revolve around an Atmel dev board. So right off, that course won't work for this board. As far as the latest debian images for the beaglebone boards they can be had here:

Re: [beagleboard] Beaglebone black bricked... May be???

By the way that boot loader is ancient. It's around 2 years, and 8 months old. Which also means the image you're trying to flash is also dated, and likely not much in the way for support with it any more. On Wed, Jan 18, 2017 at 2:36 AM, William Hermans <yyrk...@gmail.com> wrote: > Fi

Re: [beagleboard] Beaglebone black bricked... May be???

First. it's impossible to brick the beaglebone in this manner. Even assuming you'd had written to the emmc millions of times, and rendered the emmc unworkable. Since the board can also boot from sdcard, as well as serial. Second, why are you flashing a new image onto the beaglebone ? Meaning what

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

n 16, 2017 at 12:46 PM, Robert Nelson <robertcnel...@gmail.com> wrote: > On Mon, Jan 16, 2017 at 1:19 PM, William Hermans <yyrk...@gmail.com> > wrote: > > > > > > On Mon, Jan 16, 2017 at 10:06 AM, Robert Nelson <robertcnel...@gmail.com > > > > wrot

Re: [beagleboard] Re: Figure out how to configure correctly modules, pins, and PRU to blink a led

On Mon, Jan 16, 2017 at 9:55 AM, Greg wrote: > There was nothing particularly practical about that PRU-ADC project. It > was a means of learning PRU C programming, SPI bus, RemoteProc framework, > and user-space C code (and others). > It was an extremely good learning

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

On Mon, Jan 16, 2017 at 10:06 AM, Robert Nelson wrote: > the issue is 4.4.9-bone-rt-r10... > > grab 4.4.39-bone-rt-r16 or later, which includes a dtc resync: > > https://github.com/RobertCNelson/bb-kernel/blob/ > 722d8ee587bc6573c01136ef18dc14d0de903f46/patches/dtc/0001-

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

, William Hermans <yyrk...@gmail.com> wrote: > > > On Mon, Jan 9, 2017 at 3:12 PM, Robert Nelson <robertcnel...@gmail.com> > wrote: > >> >> Use this in /boot/uEnv.txt >> >> enable_uboot_overlays=1 >> uboot_overlay_addr0=/lib/firmware/BB-CAPE-1

Re: [beagleboard] Issues With I2C and Beagle Board Black?

George, how about you give us step by step of exactly what you're doing to try to get this working. Assuming Gerald's suggestion does not work out for you. On Wed, Jan 11, 2017 at 9:02 AM, Gerald Coley wrote: > What is the value of your pull up resistors on SCL and SDA?

Re: [beagleboard] Re: Beagle expertise needed

I'd like to point out, that if you want / need reliability. Wireless is probably not the vehicle to get you there. On Wed, Jan 11, 2017 at 10:12 AM, Richard Maurer wrote: > Here is some additional info that was requested: > > Message size is small (< 20 bits probably no more

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

On Mon, Jan 9, 2017 at 3:12 PM, Robert Nelson wrote: > > Use this in /boot/uEnv.txt > > enable_uboot_overlays=1 > uboot_overlay_addr0=/lib/firmware/BB-CAPE-1-00A0.dtbo > uboot_overlay_addr1=/lib/firmware/BB-CAPE-2-00A0.dtbo >

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

I should also add, that I have only tested this "fix" on a beaglebone green. I seem to recall that this problem does not exist when using a beaglebone black. On Mon, Jan 9, 2017 at 3:05 PM, William Hermans <yyrk...@gmail.com> wrote: > So this is probably more of an oversight t

[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

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 <yyrk...@gmail.com> 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

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

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 <yyrk...@gmail.com> wrote: > My last worklog working with the initrd, which b

Re: [beagleboard] InitRamFs

On Thu, Jan 5, 2017 at 4:39 AM, William Hermans <yyrk...@gmail.com> wrote: > > > On Thu, Jan 5, 2017 at 4:28 AM, Micka <mickamus...@gmail.com> wrote: > >> I saw that. But was not sure. The idea is to save the state of your ram? >> >> > I don't unde

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

Re: [beagleboard] InitRamFs

/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 <yyrk...@gmail.com> wrote: > You should really google this Micka, > > But initrd == initial ram disk, and initramfs is a cpio a

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

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 <yyrk...@gmail.com> wrote: > Ok, my bad, I completely missed the part where you said it still output, > just no sound from speakers .

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

, Jan 2, 2017 at 3:04 PM, William Hermans <yyrk...@gmail.com> 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 fr

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

, 2017 at 2:57 PM, William Hermans <yyrk...@gmail.com> 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 <jjfra...@gmail.com> wrote: > >> William,

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

d. > Guessing 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 <jjfr...@gmail.com> wrote: >> >>&g

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

in the 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 <yyrk...@gmail.com> wrote: > > > On Mon, Jan 2, 2017 at 12:28 PM, John Franey <jjfra..

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

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

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