[beagleboard] Gigabit Ethernet on X-15?

[Rick Mann]

I'm pretty sure the BBB only has 100 Mbps Ethernet. Does the X-15 support 1Gbps?

Does anyone know of a small SBC that can sustain 1 Gbps? I'm thinking of making 
a speed test appliance.

Thanks!

-- 
Rick Mann
rm...@latencyzero.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/9FEDF260-0662-439C-853C-7D81F02768B6%40latencyzero.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Anyone using 4D System's 7in LCD cape?

[esreyna95]

Can anyone help me understand how to change brightness setting of the the 
LCD cape?

-- 
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/dc461049-9847-42fc-b0ee-1d53bf5b6df4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Anyone have LXDE running with Ubuntu 16.04 correctly?

[esreyna95]

So I just recently installed LXDE to get a desktop environment for my BBB 
on Ubuntu 16.04 distro. It works, (when I use 4D system's 7'in LCD cape I 
can see the desktop gui) *but* now I noticed I cannot access the internet 
connection anymore whether I connect to the BBB serially, when I ssh, and 
when I use the gui. I noticed this happened right after I installed LXDE. I 
have tried all sort of workarounds like even trying to share my Mac's 
internet connection but all attempts failed. Any ideas or comments?

-- 
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/c426b747-65a2-4944-a512-3ca8bb0318d3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] After installing LXDE on Ubuntu 16.04, cannot connect to internet

[esreyna95]

I installed LXDE desktop environment so I could get desktop version instead 
of terminal. All was well (I could ping and do sudo apt-get) when I just 
had ubuntu 16.04 running but then I wanted to use LXDE so I could get a gui 
and make things easier but know now I cannot ping anymore. I can ssh to 
192.168.7.2 from my mac and serial connect to the UART debug controller but 
I cannot use anything that uses the internet to work. I even tried to share 
my Mac's internet connection but that does not work as well! (It used to, *ONLY 
ONCE* when I first setup the board. I had to connect serially to 
/dev/tty.usbmodem1423 but now that doesn't even show up!) I don't know 
what's going on with these boards.

-- 
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/06a4a15f-17bb-4a01-9b3f-fd669fa11698%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Cannot ssh into usb connection on Mac anymore

[esreyna95]

So I used to be able to login to BBB through serially through usb on my Mac 
on tty.USB0 (the BBB used to show up as a removable drive and I was able to 
browse the web on my BBB) after doing the all the steps provided on the 
Getting Started Page.  After the first time, all other attempts never 
worked.  When I tried a few days later to connect again, I could not 
connect as it never showed up as a removable drive. I was only able to 
connect serially again via USB to UART connector. *It doesn't even work on 
windows and it used to!* I'm having troubles trying to reconnect to my usb, 
because now I need to access internet (which just recently stopped working 
as well, I could still ping from the BBB even after the usb stopped working 
but now that stopped working as of today). What is happening???

-- 
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/1ddfe275-48e9-49d3-8f38-5229cb0ec69b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] About the DDR3 memory in Rev C BOM (D2516EC4BXGGB)

[Gerald Coley]

The die is made by Micron.
Kingston buys the die from Micron.
Kingston packages and puts their name on it.
It is the same part as Micron.
Not timing changes required.

Gerald

On Thu, Sep 8, 2016 at 4:12 PM,  wrote:

> I have noticed that Rev C BOM mentions a Kingston DDR3 D2516EC4BXGGB.
> Any explanations for that?
>
> Is this part a direct replacement of current Micron memory? Does it require
> timing (bootloader) changes?
>
> Thanks,
> Ezequiel
>
> --
> 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/7e42e0c2-d998-4580-8891-2b6ceaf7caf1%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Gerald

ger...@beagleboard.org
http://beagleboard.org/
gcol...@emprodesign.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/CAHK_S%2Be7Hw2ZXqFHqeGcLovETXcEmhhCEH7cufNkJwn1BVP2%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] About the DDR3 memory in Rev C BOM (D2516EC4BXGGB)

[ezequiel]

I have noticed that Rev C BOM mentions a Kingston DDR3 D2516EC4BXGGB.
Any explanations for that?

Is this part a direct replacement of current Micron memory? Does it require
timing (bootloader) changes?

Thanks,
Ezequiel

-- 
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/7e42e0c2-d998-4580-8891-2b6ceaf7caf1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: "invalid ELF header" error in latest RCN image?

[Stephane Charette]

>
> I tried to create myself a backup user account on my BBGW, but I'm getting 
> a "invalid ELF header" error:
>
> debian@beaglebone:~$ *sudo useradd --create-home --shell /bin/bash 
> --user-group --groups sudo backupuser*
> useradd: error while loading shared libraries: 
> /usr/lib/arm-linux-gnueabihf/libustr-1.0.so.1: invalid ELF header
>


Good news.  I've managed to fix a bunch of problems I was having, including 
this one last night with the "invalid ELF header".  Turns out there were 
some problems on my eMMC.  With the serial debug cable, I observed quite a 
few of these errors during the installation:

[  117.320212] blk_update_request: I/O error, dev mmcblk1, sector 4720648
[  117.326810] blk_update_request: I/O error, dev mmcblk1, sector 4720656
[  117.333405] blk_update_request: I/O error, dev mmcblk1, sector 4720664


The way I solved it was to do the following:


   1. insert the micro SD card with the installation image into a laptop or 
   desktop computer before using it on the BB device
   2. edit the file /opt/scripts/tools/eMMC/init-eMMC-flasher-v3-bbgw.sh on 
   the micro SD card (or whatever script is appropriate for your device)
   3. search for all instances of mkfs -- there are 3, all around lines 
   300-320
   4. add the extra parameter "-c -c" -- this calls badblocks(8) which will 
   run a lengthy test to discover and mark bad blocks

The three individual mkfs lines will look something like this:

LC_ALL=C mkfs.vfat -c -c -F 16 ${destination}p1 -n ${boot_label}
LC_ALL=C mkfs.ext4 -c -c ${ext4_options} ${destination}p2 -L ${rootfs_label}
LC_ALL=C mkfs.ext4 -c -c ${ext4_options} ${destination}p1 -L ${boot_label}

The installation takes much longer (an hour?) because it checks the eMMC 
for bad blocks, but in my case it resurrected a device that was no longer 
working.

Stéphane

-- 
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/0ba42f7c-a6e1-4b21-bd85-bb490fb05d33%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Header files for non PRU peripherals

[William Hermans]

*25.4.1.18 GPIO_DATAOUT Register (offset = 13Ch) [reset = 0h]*

*GPIO_DATAOUT is shown in Figure 25-24 and described in Table 25-23.*

The GPIO_DATAOUT register is used for setting the value of the GPIO output
pins. Data is written to the
GPIO_DATAOUT register synchronously with the interface clock. This register
can be accessed with
direct read/write operations or using the alternate Set/Clear feature. This
feature enables to set or clear
specific bits of this register with a single write access to the set data
output register
(GPIO_SETDATAOUT) or to the clear data output register (GPIO_CLEARDATAOUT)
address.

Ok thats confusing . . .but I guess I read this and understood the opposite
of what it's saying ? e.g. I was thinking DATAOUT would be fast ?

On Thu, Sep 8, 2016 at 1:56 PM, William Hermans  wrote:

> Oh...while we're on the subject, there's one more significant reason
>> the set/clear registers are helpful even if you're not worried about
>> multi-threaded operation:  They're *FAST*
>>
>
> I did notice that it seemed to be that way from your description. But the
> way I read the TRM. TO me it seems that the SETDATA(direction) registers
> actually write to DATAOUT. did I read that wrong ?
>
> On Thu, Sep 8, 2016 at 1:51 PM, Charles Steinkuehler <
> char...@steinkuehler.net> wrote:
>
>> On 9/8/2016 3:35 PM, Charles Steinkuehler wrote:
>> > On 9/8/2016 12:41 PM, William Hermans wrote:
>> >>
>> >> It has long been programing technique to use DATAOUT |= BITx to set a
>> register
>> >> bit DATAOUT &= (~BITx) to clear a register bit, or something like
>> if(DATAOUT &
>> >> BITx){} or if((DATAOUT ) == 0 or 1) to read a bit from a register.
>> >
>> > Yes, it has.  But those short-hand snippits of C code are hiding an
>> > implicit read-modify-write cycle:
>> >
>> > DATAOUT |= BITx
>> >
>> > ...turns into:
>> >
>> > Read  :  = DATAOUT
>> > Modify:  =  | BITx
>> > Write : DATAOUT = 
>> >
>> > ...where  is probably a CPU register (unless your C compiler is
>> > _really_ bad!).  But if you use the set/clear registers it's just:
>> >
>> > Write : SETDATAOUT = BITx
>>
>> Oh...while we're on the subject, there's one more significant reason
>> the set/clear registers are helpful even if you're not worried about
>> multi-threaded operation:  They're *FAST*
>>
>> The ARM core on the BBB is running at 1 GHz, but the I/O is only
>> running at about 100 MHz.  So that simple DATAOUT |= BITx stalls the
>> CPU until the system can provide the current value of DATAOUT to the
>> processor core, which likely takes a couple hundred nanoseconds (based
>> on the time it takes for the PRU to read a GPIO register).
>>
>> The write, however, is very fast (for both the set/clear case and for
>> writing directly to DATAOUT).  Writes are posted and the ARM has weak
>> memory ordering, so as long as you're not saturating the on-chip
>> interconnect fabric, the write will appear to complete instantly, the
>> ARM core will carry on executing instructions, and about 100 nS later
>> the GPIO register will update with the new value once the write
>> transaction has worked it's way through the on-chip interconnect fabric.
>>
>> --
>> Charles Steinkuehler
>> char...@steinkuehler.net
>>
>> --
>> 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/ms
>> gid/beagleboard/66e45786-85b9-2302-bef4-3213f6848a8d%40steinkuehler.net.
>> 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/CALHSORrCVVmifF_V1KyUFwpGb-X%3D0j8o%3DeGMQwOtXHawK%2Bx-Vg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Header files for non PRU peripherals

[William Hermans]

>
> Oh...while we're on the subject, there's one more significant reason
> the set/clear registers are helpful even if you're not worried about
> multi-threaded operation:  They're *FAST*
>

I did notice that it seemed to be that way from your description. But the
way I read the TRM. TO me it seems that the SETDATA(direction) registers
actually write to DATAOUT. did I read that wrong ?

On Thu, Sep 8, 2016 at 1:51 PM, Charles Steinkuehler <
char...@steinkuehler.net> wrote:

> On 9/8/2016 3:35 PM, Charles Steinkuehler wrote:
> > On 9/8/2016 12:41 PM, William Hermans wrote:
> >>
> >> It has long been programing technique to use DATAOUT |= BITx to set a
> register
> >> bit DATAOUT &= (~BITx) to clear a register bit, or something like
> if(DATAOUT &
> >> BITx){} or if((DATAOUT ) == 0 or 1) to read a bit from a register.
> >
> > Yes, it has.  But those short-hand snippits of C code are hiding an
> > implicit read-modify-write cycle:
> >
> > DATAOUT |= BITx
> >
> > ...turns into:
> >
> > Read  :  = DATAOUT
> > Modify:  =  | BITx
> > Write : DATAOUT = 
> >
> > ...where  is probably a CPU register (unless your C compiler is
> > _really_ bad!).  But if you use the set/clear registers it's just:
> >
> > Write : SETDATAOUT = BITx
>
> Oh...while we're on the subject, there's one more significant reason
> the set/clear registers are helpful even if you're not worried about
> multi-threaded operation:  They're *FAST*
>
> The ARM core on the BBB is running at 1 GHz, but the I/O is only
> running at about 100 MHz.  So that simple DATAOUT |= BITx stalls the
> CPU until the system can provide the current value of DATAOUT to the
> processor core, which likely takes a couple hundred nanoseconds (based
> on the time it takes for the PRU to read a GPIO register).
>
> The write, however, is very fast (for both the set/clear case and for
> writing directly to DATAOUT).  Writes are posted and the ARM has weak
> memory ordering, so as long as you're not saturating the on-chip
> interconnect fabric, the write will appear to complete instantly, the
> ARM core will carry on executing instructions, and about 100 nS later
> the GPIO register will update with the new value once the write
> transaction has worked it's way through the on-chip interconnect fabric.
>
> --
> Charles Steinkuehler
> char...@steinkuehler.net
>
> --
> 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/66e45786-85b9-2302-bef4-3213f6848a8d%40steinkuehler.net.
> 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/CALHSORqzEj8dmkmxmpftnCY5RTGVg5f9HKzoAeZhR%3DdE_xH2TA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Header files for non PRU peripherals

[Charles Steinkuehler]

On 9/8/2016 3:35 PM, Charles Steinkuehler wrote:
> On 9/8/2016 12:41 PM, William Hermans wrote:
>>
>> It has long been programing technique to use DATAOUT |= BITx to set a 
>> register 
>> bit DATAOUT &= (~BITx) to clear a register bit, or something like if(DATAOUT 
>> & 
>> BITx){} or if((DATAOUT ) == 0 or 1) to read a bit from a register.
> 
> Yes, it has.  But those short-hand snippits of C code are hiding an
> implicit read-modify-write cycle:
> 
> DATAOUT |= BITx
> 
> ...turns into:
> 
> Read  :  = DATAOUT
> Modify:  =  | BITx
> Write : DATAOUT = 
> 
> ...where  is probably a CPU register (unless your C compiler is
> _really_ bad!).  But if you use the set/clear registers it's just:
> 
> Write : SETDATAOUT = BITx

Oh...while we're on the subject, there's one more significant reason
the set/clear registers are helpful even if you're not worried about
multi-threaded operation:  They're *FAST*

The ARM core on the BBB is running at 1 GHz, but the I/O is only
running at about 100 MHz.  So that simple DATAOUT |= BITx stalls the
CPU until the system can provide the current value of DATAOUT to the
processor core, which likely takes a couple hundred nanoseconds (based
on the time it takes for the PRU to read a GPIO register).

The write, however, is very fast (for both the set/clear case and for
writing directly to DATAOUT).  Writes are posted and the ARM has weak
memory ordering, so as long as you're not saturating the on-chip
interconnect fabric, the write will appear to complete instantly, the
ARM core will carry on executing instructions, and about 100 nS later
the GPIO register will update with the new value once the write
transaction has worked it's way through the on-chip interconnect fabric.

-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
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/66e45786-85b9-2302-bef4-3213f6848a8d%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] analogRead in bonescript fails on first attempt after reboot

[Todd Hitt]

Thanks for the reply. (For some reason, I didn't get a notification from 
google groups so I had to do some searching just to find my own message!)

I'll look into following your suggestion. I'm not too savvy on device 
trees, so it'll be a learning experience.


On Monday, September 5, 2016 at 5:08:10 PM UTC-4, William Hermans wrote:
>
> What i mean by the above is that the library seems as though it does load 
> the device tree, or export the ADC pin correctly. But it's still sending 
> the exception message to stderr, and then halting the application for some 
> odd reason.
>
> I'd have to read the code to be 100%, but right now I do not have the 
> time. . .  
>
> On Mon, Sep 5, 2016 at 2:03 PM, William Hermans  > wrote:
>
>> Yeah it sound like bonescript, or the newer refactored version may not 
>> correctly handle the "file does not exist" exception correctly. As it 
>> currently sits. 
>>
>> Ideally, in code you would check that the file you're about to use 
>> exists, and if it does not then you load the appropriate device tree file, 
>> or similar, then just carry on about your marry way. Silently.
>>
>> On Mon, Sep 5, 2016 at 11:02 AM, Todd Hitt > > wrote:
>>
>>> Hello all,
>>>
>>> I have a problem that mystifies me. After I boot my BB, the first time I 
>>> try to issue an analogRead via node.js, I get the following error:
>>>
>>> fs.js:549
>>>   return binding.open(pathModule._makeLong(path), stringToFlags(flags), 
>>> mode);
>>>  ^
>>>
>>> Error: ENOENT: no such file or directory, open 
>>> '/sys/bus/iio/devices/iio:device0/in_voltage0_raw'
>>> at Error (native)
>>> at Object.fs.openSync (fs.js:549:18)
>>> at Object.fs.readFileSync (fs.js:397:15)
>>> at Object.exports.readAIN 
>>> (/var/lib/cloud9/node_modules/bonescript/src/hw_mainline.js:211:30)
>>> at Object.f.analogRead 
>>> (/var/lib/cloud9/node_modules/bonescript/src/index.js:271:19)
>>> at null._repeat (/var/lib/cloud9/autorun/app.js:86:13)
>>> at wrapper [as _onTimeout] (timers.js:275:11)
>>> at Timer.listOnTimeout (timers.js:92:15)
>>>
>>>
>>> When I run my app again, immediately without changing anything else, it 
>>> works fine.  Any ideas?
>>>
>>> Thanks in advance.
>>>
>>> --Todd
>>>
>>> -- 
>>> 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/7c5a641a-57b7-44c6-9498-bcbd809550d4%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/4ed8d597-5071-448b-8d06-4f032ed24af5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] gpio1_16 and gpio2_0 issues on beaglebone green.

[William Hermans]

So, what is bothering me about this is that I do not know if this
particular problem has been discussed before, and is a known issue or not.
To me it truly seems to be a bug, but other than what I've done, I know no
way of confirming this.

So just to keep things clear. The behavior I talked about above only
effects the Beaglebone Green. There is not such issue with the Beaglebone
Black. But I do not know why, nor do I know how to correct this.

Shouldn't this be an important issue ? Or does everyone feel that is should
be necessary to configure this pin via a device tree overlay file in order
for this 1 pin to be usable ?

On Wed, Sep 7, 2016 at 8:35 PM, William Hermans  wrote:

> So, I still do not know what exactly the problem *is*. So for those of you
> who need to use this pin, I guess you, and everyone else who is using a 4.x
> kernel will have to load a device tree overlay *just* for gpio1_16 to work
> correctly under sysfs. kernels 3.8.x I'm not sure about.
>
> On Wed, Sep 7, 2016 at 6:09 PM, William Hermans  wrote:
>
>> Let me rephrase that. The board seems to boot and come up, but I was
>> unable to ssh into the board. For whatever reason. Did not care to look why.
>>
>> On Wed, Sep 7, 2016 at 6:08 PM, William Hermans 
>> wrote:
>>
>>> So, booting and loading am335x-bonegreen-overlay.dtb on a beaglebone
>>> green will render the board unbootable.
>>>
>>> On Wed, Sep 7, 2016 at 5:24 PM, William Hermans 
>>> wrote:
>>>
 Just for clarity

 *debian@beaglebone:~$* sudo sh -c "echo '1' >
 /sys/class/gpio/gpio51/value"
 *debian@beaglebone:~$* cat /sys/class/gpio/gpio48/value
 0
 *debian@beaglebone:~$* sudo sh -c "echo '0' >
 /sys/class/gpio/gpio51/value"
 *debian@beaglebone:~$* cat /sys/class/gpio/gpio48/value
 1

 So, I'm not experiencing an "off by 1" issue. But for some reason
 gpio1_16 *only* works if a universal IO overlay that deals with gpio1_16
 appropriately - *somehow*. I'm not sure what I'm missing. Is this a
 software bug of some sort ?


 On Wed, Sep 7, 2016 at 4:39 PM, William Hermans 
 wrote:

> Ah, but the "Drama" continues . . .
>
> *debian@beaglebone:~$* sudo sh -c "echo '0' >
> /sys/class/gpio/gpio51/value"
> *debian@beaglebone:~$* cat /sys/class/gpio/gpio48/value
> 0
> *debian@beaglebone:~$* sudo sh -c "echo '1' >
> /sys/class/gpio/gpio51/value"
> *debian@beaglebone:~$* cat /sys/class/gpio/gpio48/value
> 0
>
> Ok, that's wrong . . . so. . .
>
> *debian@beaglebone:~$* wget https://raw.githubusercontent.
> com/cdsteinkuehler/beaglebone-universal-io/master/config-pin
> *debian@beaglebone:~$ *chmod +x config-pin
> *debian@beaglebone:~$* sudo ./config-pin overlay univ-all
> Loading univ-all overlay
> *debian@beaglebone:~$* sudo ./config-pin P9.16 hi
> *debian@beaglebone:~$* cat /sys/class/gpio/gpio48/value
> 0
> *debian@beaglebone:~$* sudo ./config-pin P9.16 low
> *debian@beaglebone:~$* cat /sys/class/gpio/gpio48/value
> 1
>
> So, Robert, Charles, anyone ? What gives ?
>
>
>
>
>
>
> On Wed, Sep 7, 2016 at 4:17 PM, William Hermans 
> wrote:
>
>> So, I think *maybe* I might have narrowed down the problem. My
>> assumption is that gpio64(gpio2_0) is perhaps set
>>  default by the processor to an output. Until the pin is exported via
>> the sysfs gpio mechanism. One only need to export the pin and then
>> everything works fine. I'll confirm this later with an oscilloscope 
>> reading
>> later to backup my assumption.  With that said I dug through all the
>> include files, headers, and whatnot. Conspicuously there was mention of
>> emmc_pins for the green overlay file, but gpio2_0 was not muxed in the 
>> file
>> am335x-bone-common.dtsi.
>>
>> Worklog below, and yes this did physically toggle an LED on our test
>> fixture.
>>
>> *debian@beaglebone:~$* ls /sys/class/gpio
>> export  gpio115  gpiochip0  gpiochip32  gpiochip64  gpiochip96
>> unexport
>> *debian@beaglebone:~$* sudo sh -c "echo '64' >
>> /sys/class/gpio/export"
>> *debian@beaglebone:~$* ls /sys/class/gpio
>> export  gpio115  gpio64  gpiochip0  gpiochip32  gpiochip64
>> gpiochip96  unexport
>> *debian@beaglebone:~$* cat /sys/class/gpio/gpio64/direction
>> in
>> *debian@beaglebone:~$* cat /sys/devices/platform/
>> alarmtimer/   fixedregulator@0/ omap-pcm-audio/
>> pmu/  serial8250/   ti-cpufreq.0/
>> bone_capemgr/ leds/ opp_table0/
>> power/snd-soc-dummy/uevent
>> cpufreq-dt/   ocp/  pm33xx.0/
>> reg-dummy/soc/
>> *debian@beaglebone:~$* cat /sys/devices/platform/
>> alarmtimer/   

[beagleboard] Re: Expanding Root Partition - Bad magic number in super-block while trying to open /dev/mmcblk0p2

[i . law . yu]

This worked for me as well on BBB Jessie. The thought of deleting the one 
and only partition freaked me out at first but apparently fdisk works like 
that. 

On Monday, July 4, 2016 at 1:54:05 PM UTC-7, mailbot...@gmail.com wrote:
>
> I had the same issue as you. So, what I did is to remove all partitions (/
> dev/mmcblk0p*) and create a new partition that uses all the available 
> space. Write the changes and reboot BBB. Run resize2fs on the only 
> partition. Do a "df -h" to confirm.
>
>

-- 
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/44711d11-82a4-4c3d-8780-3947be9ea042%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Header files for non PRU peripherals

[William Hermans]

On Thu, Sep 8, 2016 at 6:36 AM, Charles Steinkuehler <
char...@steinkuehler.net> wrote:

> On 9/7/2016 7:50 PM, William Hermans wrote:
> >
> > SETDATAOUT -> |= BITx
> > CLEARDATAOUT -> &=(~BITx)
> >
> > I gues I'll have to reread the TRM again.
>
> The set/clear registers only affect the bits that are written with a
> '1' value, all other bits remain unchanged, while writing directly to
> the DATAOUT register affects the value of all 32 bits in the GPIO
> bank.  Using the set/clear registers allows a single atomic write
> operation to affect the specific bit(s) you want to change without
> having to perform a non-atomic read-modify-write cycle.
>
> Since the write to the set or clear register is atomic, if both the
> ARM and the PRU both use this method, no locks or other hand-shaking
> is required to prevent corruption.
>
> --
> Charles Steinkuehler
> char...@steinkuehler.net


It has long been programing technique to use DATAOUT |= BITx to set a
register bit DATAOUT &= (~BITx) to clear a register bit, or something like
if(DATAOUT & BITx){} or if((DATAOUT ) == 0 or 1) to read a bit from a
register.

So I'm having a very hard time taking what you're saying without a grain of
salt. Especially after having read that section of the TRM in detail, and
not getting what you got from it. But I do feel that if you read a gpio
register bit first, before writing to it there should be no contention as
to what the register should be.

With that said, I've only ever used /dev/mem + mmap(), but have never done
this with a PRU to date. So, while I do firmly believe in what I say above,
I do have respect for what you're saying. Plus I do know you have hands on
with the PRU . . . I wonder if anyone could whip up a test case for others
to play around with- to demonstrate this ?

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

[beagleboard] about ADC in BBB(with word format)

[tohidkardgar]

hello
i want some information about ADC in BBB with word format.
do anyone have this information??
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/a51a56f4-8745-43b8-bae0-3c388a00933d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Header files for non PRU peripherals

[Charles Steinkuehler]

On 9/7/2016 7:50 PM, William Hermans wrote:
> 
> SETDATAOUT -> |= BITx
> CLEARDATAOUT -> &=(~BITx)
> 
> I gues I'll have to reread the TRM again.

The set/clear registers only affect the bits that are written with a
'1' value, all other bits remain unchanged, while writing directly to
the DATAOUT register affects the value of all 32 bits in the GPIO
bank.  Using the set/clear registers allows a single atomic write
operation to affect the specific bit(s) you want to change without
having to perform a non-atomic read-modify-write cycle.

Since the write to the set or clear register is atomic, if both the
ARM and the PRU both use this method, no locks or other hand-shaking
is required to prevent corruption.

-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
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/4db8f6f0-f70a-0d28-29f9-3d0aba8dd690%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Using CANopen on BBB

[laurits . triple]

On my debian installation, to use CAN on P9_24 and P9_26 I used the 
provided BB-CAN1-00A0.dts file in /lib/firmware (source: 
https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-CAN1-00A0.dts).
 
Enable it on startup by adding 
"cape_enable=bone_capemgr.enable_partno=BB-CAN1" to /boot/uEnv.txt

This was a couple of weeks ago, so correct me if I am wrong, but i also 
used one of these commands to get it online:
ip set dev can0 up
ip link set can0 up type can bitrate 50

Note that you need an external transceiver like SN65HVD231 or mcp2551 to 
actually connect it to a can-network.

I had another candevice send some messages and used the following to dump 
all traffic to the terminal:
candump -cae can0,0:0,#

I dont remember if I had to load the kernel modules or if they where 
automatically loaded, but just in case, if nothing is working, try this:
sudo modprobe can
sudo modprobe can-dev
sudo modprobe can-raw




mandag 1. august 2016 16.29.48 UTC+2 skrev Dror Lugasi følgende:
>
> Hello everyone,
> I am searching for information on how to use CAN on the BBB across the 
> internet and all the guides i could find won't work for me. 
> I do all the installation and all, but when i check to see the slots i 
> don't get anything, it's like the beagle hasn't configured the ports.
> the virtual can bus works, so the drivers are ok.. i did the overlay for 
> the BB-DCAN1, compiled it, and still nothing.
> the closest i came to know something is right is when i  use "dmesg | tail 
> -n15" and get:
>
> [ 2860.034007] [drm:output_poll_execute], [CONNECTOR:5:HDMI-A-1] status 
> updated from 1 to 1
> [ 2870.064202] [drm:output_poll_execute], [CONNECTOR:5:HDMI-A-1] status 
> updated from 1 to 1
> [ 2880.095569] [drm:output_poll_execute], [CONNECTOR:5:HDMI-A-1] status 
> updated from 1 to 1
> [ 2890.126698] [drm:output_poll_execute], [CONNECTOR:5:HDMI-A-1] status 
> updated from 1 to 1
> [ 2900.157938] [drm:output_poll_execute], [CONNECTOR:5:HDMI-A-1] status 
> updated from 1 to 1
> [ 2907.178285] bone-capemgr bone_capemgr.9: part_number 'BB-DCAN1', 
> version 'N/A'
> [ 2907.178475] bone-capemgr bone_capemgr.9: slot #11: generic override
> [ 2907.178526] bone-capemgr bone_capemgr.9: bone: Using override eeprom 
> data at slot 11
> [ 2907.178579] bone-capemgr bone_capemgr.9: slot #11: 'Override Board 
> Name,00A0,Override Manuf,BB-DCAN1'
> [ 2907.178850] bone-capemgr bone_capemgr.9: slot #11: Requesting part 
> number/version based 'BB-DCAN1-00A0.dtbo
> [ 2907.182418] bone-capemgr bone_capemgr.9: slot #11: Requesting firmware 
> 'BB-DCAN1-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
> [ 2907.182517] bone-capemgr bone_capemgr.9: slot #11: dtbo 
> 'BB-DCAN1-00A0.dtbo' loaded; converting to live tree
> [ 2907.183160] bone-capemgr bone_capemgr.9: slot #11: #2 overlays
> [ 2907.183385] bone-capemgr bone_capemgr.9: slot #11: Applied #2 overlays.
> [ 2910.189201] [drm:output_poll_execute], [CONNECTOR:5:HDMI-A-1] status 
> updated from 1 to 1
>
> this is half right as far as i could see in the installation guides.
>
> my goal is to set up the DCAN1 with pins P9_24 and P9_26 permanently so i 
> wouldn't have to go to the terminal and do the "echo" thing every time i 
> boot the beagle.
> does anyone have a simple guide for beginner like me? or could talk to me 
> via the email (my mail is: jackson...@gmail.com )  and guide 
> me? that would be awesome.
>
> by the way, i am going to send and receive that data with python-can. 
> anyone has experience with it? how to init the can bus before using the 
> send and recv of CAN messages? 
>
> any help would be blessed, i am stuck after trying everything and not 
> succeeding.. i couldn't get it to work.
>
> 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/e9288018-44d3-455c-af3d-343f717d479a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Trying to run the ADC from the PRU

[TJF]

Hi Phil!

After boot the ADC subsystem is disabled by default. You have to enable the 
CM_WKUP_ADC_TSC_CLKCTRL register in the CONTROL MODULE before you can use 
it:

mov  r0, 0x44E004BC
mov  r1, 2
sbbo r1, r0, 0, 4

Place this snippet after OCP enbled and before any ADC register access.

Regards

-- 
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/57ee532e-6921-424c-b9c7-3d053446c713%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] error messages on serial console during BBGW bootup

[Stephane Charette]

The serial debug cable I ordered for my BBGW finally got here.  I 
downloaded RCN's most recent 
build, BBGW-blank-debian-8.5-seeed-iot-armhf-2016-09-04-4gb.img.

I did see a few errors on the serial console during the installation:

Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done 
Formatting: /dev/mmcblk1 complete
...cut...
[  116.630830] 6144 pages cma reserved
[  116.634355] edma 4900.edma: edma_prep_slave_sg: Failed to allocate a 
descriptor
[  116.642061] omap_hsmmc 481d8000.mmc: prep_slave_sg() failed
[  116.647671] omap_hsmmc 481d8000.mmc: MMC start dma failure
[  117.305788] mmcblk1: unknown error -1 sending read/write command, card 
status 0x900
[  117.313590] blk_update_request: I/O error, dev mmcblk1, sector 4720640
[  117.320212] blk_update_request: I/O error, dev mmcblk1, sector 4720648
[  117.326810] blk_update_request: I/O error, dev mmcblk1, sector 4720656
[  117.333405] blk_update_request: I/O error, dev mmcblk1, sector 4720664

The installation does seem to continue, and it shuts down cleanly at the 
end.  Not sure if those I/O errors are important.

When I reboot it without the micro SD card, things seem OK, though I see 
this:

[2.169781] PM: Cannot get wkup_m3_ipc handle
[2.289107] bone_capemgr bone_capemgr: slot #0: No cape found
[2.333102] bone_capemgr bone_capemgr: slot #1: No cape found
[2.377098] bone_capemgr bone_capemgr: slot #2: No cape found
[2.421098] bone_capemgr bone_capemgr: slot #3: No cape found
Loading, please wait...
fsck: error 2 (No such file or directory) while executing fsck.ext4 for 
/dev/mmcblk1p1
fsck exited with status code 8

I'm then presented with the usual login prompt.  When I login and run 
ifconfig, I see no wireless device.  But if I wait a minute or so and try 
again, the wireless eventually does show up.

Is this par for the course?  Should I be worried about any of these errors?

Stéphane

-- 
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/5ccc31a6-ca03-42a0-ab2c-5e2e133dde01%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] "invalid ELF header" error in latest RCN image?

[Stephane Charette]

Image: 
 
https://rcn-ee.com/rootfs/bb.org/testing/2016-09-04/seeed-iot/BBGW-blank-debian-8.5-seeed-iot-armhf-2016-09-04-4gb.img.xz

I tried to create myself a backup user account on my BBGW, but I'm getting 
a "invalid ELF header" error:

debian@beaglebone:~$ *sudo useradd --create-home --shell /bin/bash 
--user-group --groups sudo backupuser*
useradd: error while loading shared libraries: 
/usr/lib/arm-linux-gnueabihf/libustr-1.0.so.1: invalid ELF header
debian@beaglebone:~$ *file /usr/lib/arm-linux-gnueabihf/libustr-1.0.so.1*
/usr/lib/arm-linux-gnueabihf/libustr-1.0.so.1: symbolic link to 
libustr-1.0.so.1.0.4
debian@beaglebone:~$ *file 
/usr/lib/arm-linux-gnueabihf/libustr-1.0.so.1.0.4 *
/usr/lib/arm-linux-gnueabihf/libustr-1.0.so.1.0.4: data
debian@beaglebone:~$ ls -l 
/usr/lib/arm-linux-gnueabihf/libustr-1.0.so.1.0.4 
-rw-r--r-- 1 root root 108708 Dec  9  2014 
/usr/lib/arm-linux-gnueabihf/libustr-1.0.so.1.0.4

Looking at the library in question, it is 106 KiB of NULLs.  It is not a 
valid library:

debian@beaglebone:~$ *hexdump -vx 
/usr/lib/arm-linux-gnueabihf/libustr-1.0.so.1.0.4 *
000
010
020
...etc...

Can someone else confirm if they see the same thing, or is my device hosed?

Stéphane

-- 
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/f66ab0fb-dc07-4154-9ad2-6094049f690a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] dtb/dts file configuration

[Jane]

Hi, 
For beagle bone black or beagleboard you can follow this link to build the 
kernel and the device tree.

to modify the device tree for beagleboneblack you have to edit 
KERNEL/arch/arm/boot/dts/am335x-boneblack.dts and run the tools/rebuild.sh 
, this will not only compiles the kernel but also the modules and the dtbs.

in order to change the default gpio you cab do this like this : 

mycustom-gpio = < 17 GPIO_ACTIVE_HIGH>;
or 
mycustom-gpio = < 17 0>;
0 = GPIO_ACTIVE_HIGH while 1 = GPIO_ACTIVE_LOW


above code will set the 17 pin of gpio bank 1 as active low , this is 
basically 32*1+17 = 49th Gpio that is 23rd pin on the P9 header.

you can google begaleboneblack P9 header or P8 header 
: http://www.siue.edu/~gengel/bbbWebStuff/BeagleboneBlackP9HeaderTable.pdf

Hope it helps !
Thanks and Regards,
Saurabh



On Tuesday, August 30, 2016 at 11:15:57 PM UTC+5:30, El Smiedro wrote:
>
> And do you know how to adapt it to the boot time?
>
> Am Dienstag, 30. August 2016 16:45:47 UTC+2 schrieb Wulf Man:
>>
>> to test what you want use a device overlay first.
>> then you can adapt the overlay to be loaded at boot time
>>
>> On 8/30/2016 7:24 AM, 'El Smiedro' via BeagleBoard wrote:
>>
>>
>> Hello everyone,
>>
>> currently I am using a BBB with debian 3.8.13 and I would like to change 
>> the dtb file to get some GPIO-pins with pulldown by default. I searched 
>> many sites, but I think many information are not up to date (read something 
>> about the device tree is not used anymore?!). Is somewhere a good and 
>> current documentation/tutorial for this topic? Thank you very much for your 
>> help.
>>
>> Best regards
>>eric
>> -- 
>> 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/2f1505e9-2308-46e2-b00d-d46e58345ecd%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/e8d58af2-d90e-45cc-9037-fc78453f0bc1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Trying to run the ADC from the PRU

[TJF]

Hi Phil!

After boot the ADC subsystem is disabled by default. You have to enable the 
CM_WKUP_ADC_TSC_CLKCTRL register in the CONTROL MODULE before you can use 
it:

mov  r0, 0x44E004BC
mov  r1, 2
sbbo r1, r0, 0, 4

Place this snippet after OCP enabled and before any ADC register access.

Regards

-- 
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/b61d4fa1-5ced-432e-a2e9-3a79617ef7e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.