Re: [beagleboard] I2C GPIO expanders and the BeagleBoneBlack and PocketBeagle...

[Robert Nelson]

> “bone kernel”
>
> That’s important.   The TI kernels are not usable for my application.  I need 
> to use the bone kernel.   (At least for the 4.9 and 4.14 series… haven’t had 
> time to test with the TI 4.19 series kernels)
>
>
> Ah.  I see.  What sorts of differences are there between the TI kernels and
> the Bone kernels?  Is there some reason the Bone don't have the MCP23S08
> module enabled?  Wondering if a bug/feature request might make sense…

Just added..

> Honestly, I have no idea what the “official” differences are and why some 
> modules are available in one and not the other.   Likely just someone 
> requested something.At some point, a “diff” of the configs and unifying 
> the optional modules of it may make sense, not really sure.

They've just evolved differently, from the same 3.8.x-bone base..
keeping them in-sync has been... The bone series goes thru
every kernel release, and i like to merge the good stuff back into the
-ti kernel, which it self has to deal with ti modules that don't like
optimizations (thumb2)

3.8.x-bone -> 3.9.x-bone -> .. -> 4.9.x-bone -> . ->
4.14.x-bone -> ... 4.19.x-bone -> 4.20.x-bone...
 -> 3.14.x-ti -> 4.1.x-ti -> 4.4.x-ti -> 4.9.x-ti -> 4.14.x-ti -> 4.19.x-ti

>
> In my particular case, I *believe* the power management stuff that is in the 
> TI kernel is screwing up the timing to access anything in the L4_WKUP 
> interconnect (which includes GPIO0).   For folks that value the power 
> management stuff, the TI kernel is much better.  It contains the cpu IDLE 
> driver and a bunch of other things that allow it to lower the power usage.  
> In my case, I don’t care about any of that.  Even with the bone kernel, I 
> lock the CPU at 1ghz.   I need more predictable and consistent access to the 
> gpio pins (all of them).   With the TI kernel, access to GPIO1-3 (via the 
> PRU) is very consistent, but access to GPIO0 can have several hundred ns 
> delays which I cannot have (relatively infrequent, once or twice a second, 
> but still too often).   I KNOW the CPU idle stuff in the TI kernel plays a 
> large part of the problem. If I use cpupower to turn off the idle states, 
> 90% of the delays go away (so once every 10 seconds or so).   Anyway, the 
> bone kernel doesn’t have a bunch of the PM things so I don’t see any of the 
> issues with it. Of course, it might not be PM at all.  Could be something 
> else completely different between the kernels.

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYi1ybcJ_7-gm5wrTogQ5_7dnfeKmwdDysdWF4E6GY_ngQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] I2C GPIO expanders and the BeagleBoneBlack and PocketBeagle...

[Daniel Kulp]

> On Jun 10, 2019, at 7:36 PM, Robert Heller  wrote:
> 
> At Mon, 10 Jun 2019 18:29:33 -0400 Daniel Kulp  > wrote:
>> 
>> “bone kernel”
>> 
>> That’s important.   The TI kernels are not usable for my application.  I 
>> need to use the bone kernel.   (At least for the 4.9 and 4.14 series… 
>> haven’t had time to test with the TI 4.19 series kernels)
> 
> Ah.  I see.  What sorts of differences are there between the TI kernels and 
> the Bone kernels?  Is there some reason the Bone don't have the MCP23S08 
> module enabled?  Wondering if a bug/feature request might make sense…

Honestly, I have no idea what the “official” differences are and why some 
modules are available in one and not the other.   Likely just someone requested 
something.At some point, a “diff” of the configs and unifying the optional 
modules of it may make sense, not really sure.

In my particular case, I *believe* the power management stuff that is in the TI 
kernel is screwing up the timing to access anything in the L4_WKUP interconnect 
(which includes GPIO0).   For folks that value the power management stuff, the 
TI kernel is much better.  It contains the cpu IDLE driver and a bunch of other 
things that allow it to lower the power usage.  In my case, I don’t care about 
any of that.  Even with the bone kernel, I lock the CPU at 1ghz.   I need more 
predictable and consistent access to the gpio pins (all of them).   With the TI 
kernel, access to GPIO1-3 (via the PRU) is very consistent, but access to GPIO0 
can have several hundred ns delays which I cannot have (relatively infrequent, 
once or twice a second, but still too often).   I KNOW the CPU idle stuff in 
the TI kernel plays a large part of the problem. If I use cpupower to turn 
off the idle states, 90% of the delays go away (so once every 10 seconds or 
so).   Anyway, the bone kernel doesn’t have a bunch of the PM things so I don’t 
see any of the issues with it. Of course, it might not be PM at all.  Could 
be something else completely different between the kernels.


-- 
Daniel Kulp
d...@kulp.com  - http://dankulp.com/blog 


-- 
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/6F907568-CC97-42FA-BBBC-E84C28203ADD%40kulp.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] I2C GPIO expanders and the BeagleBoneBlack and PocketBeagle...

[Robert Heller]

At Mon, 10 Jun 2019 18:29:33 -0400 Daniel Kulp  wrote:

> 
> 
> 
> 
> > On Jun 10, 2019, at 6:08 PM, Robert Heller  wrote:
> > At Mon, 10 Jun 2019 16:34:53 -0400 Daniel Kulp  wrote:
> >> On Jun 10, 2019, at 4:26 PM, Robert Heller  wrote:
> >>> 
> >>> At Mon, 10 Jun 2019 12:48:56 -0700 (PDT) beagleboard@googlegroups.com 
> >>> wrote:
>  It's not enabled in the bone kernels:
>  
>  
>  # CONFIG_PINCTRL_MCP23S08 is not set
> >>> 
> >>> In the updated kernel is is enabled.
> >> 
> >> I don't see a bone kernel with it enabled, either 4.14 or 4.19:
> 
> “bone kernel”
> 
> That’s important.   The TI kernels are not usable for my application.  I need 
> to use the bone kernel.   (At least for the 4.9 and 4.14 series… haven’t had 
> time to test with the TI 4.19 series kernels)

Ah.  I see.  What sorts of differences are there between the TI kernels and 
the Bone kernels?  Is there some reason the Bone don't have the MCP23S08 
module enabled?  Wondering if a bug/feature request might make sense...

> 
> My initial reply was to RobertCNelson’s response that it’s enabled in the 
> newer kernels to point out that it’s not enabled in ALL the newer kernels, 
> just the “ti” channel kernels.
> 
> I’ve been playing around with a pcf8574 i2c gpio expander as that module is 
> available in the bone kernel.   The main problem with the pcf8574 is it only 
> supports the 100khz i2c speed which sucks when you also have an i2c OLED on 
> the bus.Updating to 400khz is important with that thing.  Your mention of 
> the MCP23008 is very timely as I was just beginning to start looking at other 
> options.   Just kind of hoping that future bone kernels would have the driver 
> built in.  Would be a big help if I don’t have to rebuild kernels.  


> 
> 

-- 
Robert Heller -- 978-544-6933
Deepwoods Software-- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
hel...@deepsoft.com   -- Webhosting Services

   

-- 
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/20190610233607.6561526C0006%40sharky3.deepsoft.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] GHI Comms cape - no overlay file in /lib/firmware

[Jason Kridner]

On Thu, Jun 6, 2019 at 2:59 PM  wrote:

> We recently purchased the GHI Comms cape, in order to have a nice RS485
> port available.
> However, even the latest Debian image for the BeagleBone black does not
> have the required overlay dtbo file!
> When the BeagleBone Black boots, I get this:
> [ *1.493924] bone_capemgr bone_capemgr: loader: failed to load slot-2
> BBORG_COMMS:00A2 (prio 0)*
> The cause is that the file BBORG_COMMMS-00A2.dtbo is missing.
> And sure enough, there is no overlay written for this cape in:
>
> https://github.com/beagleboard/bb.org-overlays
>

I just did a pull request to add it:
https://github.com/beagleboard/bb.org-overlays/pull/122


>
> I am guessing that there is an alternative way to get this Cape up and
> running. I’m moderately OK with linux as a user and admin, but rather new
> to IoT.
>
For the RS485, you just need
config-pin p9.11 uart
config-pin p9.13 uart
...and then use /dev/ttyS4

For the CAN, you just need
config-pin p9.24 can
config-pin p9.26 can
...and then you can use something like
https://gist.github.com/jadonk/90d3462c8569d11fa3f7caf14f4769f1, but
replace can0 with can1

For the 4-20mA loop, the ADC overlay should already be loaded and you can
cat /sys/bus/iio/devices/iio\:device0/in_voltage5_raw
cat /sys/bus/iio/devices/iio\:device0/in_voltage6_raw
...but you'll need to do the voltage to data conversion

For the sink drivers, you can do:
# Sink A
config-pin p9.15 gpio
echo out > /sys/class/gpio/gpio48/direction
echo 1 > /sys/class/gpio/gpio48/value
# Sink B
config-pin p9.23 gpio
echo out > /sys/class/gpio/gpio49/direction
echo 1 > /sys/class/gpio/gpio49/value
...and that should turn them on.


>
> Best,
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/12c383d2-80a0-45d5-b0d5-452eb2b49437%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
https://beagleboard.org/about - a 501c3 non-profit educating around open
hardware computing

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

Re: [beagleboard] I2C GPIO expanders and the BeagleBoneBlack and PocketBeagle...

[Daniel Kulp]

> On Jun 10, 2019, at 6:08 PM, Robert Heller  wrote:
> At Mon, 10 Jun 2019 16:34:53 -0400 Daniel Kulp  wrote:
>> On Jun 10, 2019, at 4:26 PM, Robert Heller  wrote:
>>> 
>>> At Mon, 10 Jun 2019 12:48:56 -0700 (PDT) beagleboard@googlegroups.com wrote:
 It's not enabled in the bone kernels:
 
 
 # CONFIG_PINCTRL_MCP23S08 is not set
>>> 
>>> In the updated kernel is is enabled.
>> 
>> I don't see a bone kernel with it enabled, either 4.14 or 4.19:

“bone kernel”

That’s important.   The TI kernels are not usable for my application.  I need 
to use the bone kernel.   (At least for the 4.9 and 4.14 series… haven’t had 
time to test with the TI 4.19 series kernels)

My initial reply was to RobertCNelson’s response that it’s enabled in the newer 
kernels to point out that it’s not enabled in ALL the newer kernels, just the 
“ti” channel kernels.

I’ve been playing around with a pcf8574 i2c gpio expander as that module is 
available in the bone kernel.   The main problem with the pcf8574 is it only 
supports the 100khz i2c speed which sucks when you also have an i2c OLED on the 
bus.Updating to 400khz is important with that thing.  Your mention of the 
MCP23008 is very timely as I was just beginning to start looking at other 
options.   Just kind of hoping that future bone kernels would have the driver 
built in.  Would be a big help if I don’t have to rebuild kernels.  


-- 
Daniel Kulp
d...@kulp.com  - http://dankulp.com/blog 


-- 
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/A4F5BF3A-2EB9-498F-818B-6948C4DF2E11%40kulp.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] I2C GPIO expanders and the BeagleBoneBlack and PocketBeagle...

[Robert Heller]

At Mon, 10 Jun 2019 16:34:53 -0400 Daniel Kulp  wrote:

> 
> 
> 
> 
> > On Jun 10, 2019, at 4:26 PM, Robert Heller  wrote:
> > 
> > At Mon, 10 Jun 2019 12:48:56 -0700 (PDT) beagleboard@googlegroups.com wrote:
> >> It's not enabled in the bone kernels:
> >> 
> >> 
> >> # CONFIG_PINCTRL_MCP23S08 is not set
> > 
> > In the updated kernel is is enabled.
> 
> I don't see a bone kernel with it enabled, either 4.14 or 4.19:
> 
> config-4.14.108-ti-r104:CONFIG_PINCTRL_MCP23S08=m
  ^  
  It is in the 4.14.108 kernel.
> config-4.14.109-bone21:# CONFIG_PINCTRL_MCP23S08 is not set
> config-4.14.115-bone22:# CONFIG_PINCTRL_MCP23S08 is not set
> config-4.19.31-bone31:# CONFIG_PINCTRL_MCP23S08 is not set
> config-4.19.37-bone33:# CONFIG_PINCTRL_MCP23S08 is not set
  
I just did:

sudo /opt/scripts/tools/update_kernel.sh

and it updated to 4.14.108-ti-r106 by default:

snoopy% grep MCP23 /boot/config-4.14.*
/boot/config-4.14.108-ti-r106:CONFIG_PINCTRL_MCP23S08=m
/boot/config-4.14.71-ti-r80:# CONFIG_PINCTRL_MCP23S08 is not set
snoopy% uname -a
Linux snoopy 4.14.108-ti-r106 #1 SMP PREEMPT Fri May 24 22:12:34 UTC 2019 
armv7l GNU/Linux
snoopy% dir 
/lib/modules/4.14.108-ti-r106/kernel/drivers/pinctrl/pinctrl-mcp23s08.ko.xz 
/lib/modules/4.14.108-ti-r106/kernel/drivers/pinctrl/pinctrl-mcp23s08.ko.xz


> 
> I believe the 115-bone22 and 37-bone33 are the latest on the two branches.

Then someone needs to rebuild them...  Maybe you can file a bug report or 
feature request?

Just because the BBB has 128 on-board GPIO lines (obviously not all of them
are on the headers), does not mean one could not build a Cape with a MCP23017
for 16 more GPIO lines. To quote Billy Idle: "Too much is never enough." (from
an old MTV promo).

> 
> 

-- 
Robert Heller -- 978-544-6933
Deepwoods Software-- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
hel...@deepsoft.com   -- Webhosting Services
   

-- 
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/20190610220820.D350226C0006%40sharky3.deepsoft.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] I2C GPIO expanders and the BeagleBoneBlack and PocketBeagle...

[Daniel Kulp]

> On Jun 10, 2019, at 4:26 PM, Robert Heller  wrote:
> 
> At Mon, 10 Jun 2019 12:48:56 -0700 (PDT) beagleboard@googlegroups.com wrote:
>> It's not enabled in the bone kernels:
>> 
>> 
>> # CONFIG_PINCTRL_MCP23S08 is not set
> 
> In the updated kernel is is enabled.

I don’t see a bone kernel with it enabled, either 4.14 or 4.19:

config-4.14.108-ti-r104:CONFIG_PINCTRL_MCP23S08=m
config-4.14.109-bone21:# CONFIG_PINCTRL_MCP23S08 is not set
config-4.14.115-bone22:# CONFIG_PINCTRL_MCP23S08 is not set
config-4.19.31-bone31:# CONFIG_PINCTRL_MCP23S08 is not set
config-4.19.37-bone33:# CONFIG_PINCTRL_MCP23S08 is not set

I believe the 115-bone22 and 37-bone33 are the latest on the two branches.


-- 
Daniel Kulp
d...@kulp.com  - http://dankulp.com/blog 


-- 
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/6894AD8B-F0A2-4DC9-82E6-D4F78C6B0A81%40kulp.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] I2C GPIO expanders and the BeagleBoneBlack and PocketBeagle...

[Robert Heller]

At Mon, 10 Jun 2019 12:48:56 -0700 (PDT) beagleboard@googlegroups.com wrote:

> 
> 
> 
> It's not enabled in the bone kernels:
> 
> 
> # CONFIG_PINCTRL_MCP23S08 is not set

In the updated kernel is is enabled.

> 
> 
> While I'm pointing some of this out, is there any way to get CONFIG_SND_DUMMY 
> added to bone kernel as well as getting a few of the more readily available 
> sound codecs added to both kernels?   Probably the PCM512X, SGTL5000, and 
> WM8960 as there are a bunch of hats/addons available on Amazon that have 
> those.
> 
> Dan
> 
> 
> On Sunday, June 9, 2019 at 8:23:46 PM UTC-4, RobertCNelson wrote:
> >
> > On Sun, Jun 9, 2019 at 7:19 PM Robert Heller  > > wrote: 
> > > 
> > > OK, I have made use of the MCP23008 and MCP23017, 8 bit and 16 bit GPIO 
> > > expanders that are I2C connected on Raspberry Pis.  The Raspberry Pi 
> > kernels 
> > > include both an overlay (Device Tree Blob) and a driver module for the 
> > > MCP23008 and MCP23017 chips.  I would also like to make use of these 
> > chips on 
> > > my beagle boards (a BeagleBoneBlack and a PocketBeagle). 
> > > 
> > > I just did some poking around on my BBB, and there are neither Device 
> > Tree 
> > > Blobs nor driver modules for the MCP23008 and MCP23017 chips. 
> > > 
> > > So, my question is:  What is involved in building the missing driver 
> > modules 
> > > and Device Tree Blobs -- I have built driver modules and even rebuilt 
> > whole 
> > > kernels on x86 Linux boxen, so I have passing knowledge of how that 
> > goes, what 
> > > I am really wondering: is there a repo with .deb files containing the 
> > "extra" 
> > > ko files?  Or tarballs containing the additional sources?  I realize the 
> > BBB 
> > > and PB are rather slow, so maybe I should cross build this on one of my 
> > Pis? 
> > > Or is there an alternitive kernel I can upgrade to that includes these 
> > > modules? 
> > > 
> > > Right now my two Beagles are running 4.14.71-ti-r80, Debian GNU/Linux 9, 
> > > BeagleBoard.org Debian Image 2018-10-07.  I did do a apt-get 
> > update/apt-get 
> > > dist-upgrade about a month ago (May 14). 
> >
> > it's enabled, just after r80 came out..  Just run, and then reboot.. 
> >
> > sudo /opt/scripts/tools/update_kernel.sh 
> >
> > Regards, 
> >
> > -- 
> > Robert Nelson 
> > https://rcn-ee.com/ 
> >
> 

-- 
Robert Heller -- 978-544-6933
Deepwoods Software-- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
hel...@deepsoft.com   -- Webhosting Services


-- 
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/20190610202657.6689426C0008%40sharky3.deepsoft.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Pocketbeagle Techlab

[Jason Kridner]

Sorry for my delay in noticing this post. I hope you will read my below 
replies and see if it provides you with some success.

On Wednesday, May 15, 2019 at 8:41:06 AM UTC-5, P B wrote:
>
> Good morning,
>
> For the past two months I've been trying to learn how to use the BBB & PB 
> using Derek Molloy's book. 
>
> I got pretty excited just being able to light a led and read a push button 
> at the beginning of chapter 6.
>
> But I've gotten stuck in chapter 6 where he introduces device-tree 
> overlays because it seems those have been done away with in favor of uboot 
> overlays.  It appears both of these are compiled the same way, but I've let 
> myself get confused.
>
> I found his updated video on gpio's but that also appears obsolete.
>
> As a result I switched to trying to use the Pocketbeagle techcape to get 
> unstuck, but I've been fighting with learning how to control pins and even 
> work through the basic confirmation of functions.
>
> I've tried loading the images from both techlab-workshop-2019-01-24 
> & bone-debian-buster-iot-armhf-2019-03-03-4gb.
>
> I've been updating the kernel to Linux beaglebone 4.19.37-bone32 #1stretch 
> PREEMPT Tue Apr 30 19:17:06 UTC 2019 armv7l GNU/Linux.
>
> Afterwards I apt-get update, apt-get upgrade, git clone bb.org-overlays 
> from RCN, and download the latest cloud9 examples from J Krider.
>

In my examples at 
https://github.com/beagleboard/cloud9-examples/tree/master/PocketBeagle/TechLab

I suggest enabling a number of overlays via /boot/uEnv.txt via:

sudo sed -i -e 
"s/#?uboot_overlay_addr0=.*$/uboot_overlay_addr0=\/lib\/firmware\/PB-I2C2-ACCEL-TECHLAB-CAPE.dtbo/;"
 /boot/uEnv.txt
sudo sed -i -e 
"s/#?uboot_overlay_addr1=.*$/uboot_overlay_addr1=\/lib\/firmware\/PB-PWM-RGB-TECHLAB-CAPE.dtbo/;"
 /boot/uEnv.txt
sudo sed -i -e 
"s/#?uboot_overlay_addr2=.*$/uboot_overlay_addr2=\/lib\/firmware\/PB-SPI1-7SEG-TECHLAB-CAPE.dtbo/;"
 /boot/uEnv.txt
sudo sed -i -e 
"s/#?uboot_overlay_pru=.*RPROC.*$/uboot_overlay_pru=\/lib\/firmware\/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo/;"
 /boot/uEnv.txt
sudo shutdown -r now

 

Enabling the PB-PWM-RGB-TECHLAB-CAPE overlay should add 3 LEDs after the 
reboot is complete, techlab::red, techlab::green and techlab::blue.

See 
https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/PB-PWM-RGB-TECHLAB-CAPE.dts
 for 
the content of the overlay.

Enabling the PB-SPI1-7SEG-TECHLAB-CAPE overlay should enable 16 more LEDs, 
techlab::seg*, 
where * is 0-15.

See 
https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/PB-SPI1-7SEG-TECHLAB-CAPE.dts
 for 
the content of the overlay.

Doing a "dmesg > /var/lib/cloud9/dmesg.txt" and then copy-and-paste the 
contents of dmesg.txt here. Also, provide a copy-and-paste of 
/boot/uEnv.txt as well as the output of `sudo 
/opt/scripts/tools/version.sh`. These will help in providing feedback on 
steps you might not be executing as intended.


> Unfortunate, for all of these methods the only led files are as listed in 
> the posted screen shot.
>
> beaglebone:green:usr0
> beaglebone:green:usr1
> beaglebone:green:usr2
> beaglebone:green:usr3
>
> No segment 7 files and no rgb files to use.
>
> Maybe I'm just confused, but have been stuck here for a couple of weeks & 
> have just been going back & forth between fighting the PB & BBB on the next 
> steps.
>

Really sorry to hear you've been stuck for so long. If the responses here 
don't get you going, be sure to reach out to me under the instructions at 
https://beagleboard.org/support. I'm also 'jkridner' on the #beagle IRC 
channel.
 

>
> I've searched the net extensively looking for additional resources but 
> just end up working in circles.
>
> Does anyone have any tips or any recommendations for learning resources to 
> get over this hurdle?
>

Have you tried watching the e-ALE videos? They can be a bit advanced, but, 
if you are patient, you might pick up the missing piece to the puzzle.
 

>
> Thank you in advance for any assistance.
>
> Best Regards,
>
> Patrick
>

-- 
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/1257c89b-beb2-48f3-9d95-f7248b811d57%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] I2C GPIO expanders and the BeagleBoneBlack and PocketBeagle...

[Daniel Kulp]

It's not enabled in the bone kernels:


# CONFIG_PINCTRL_MCP23S08 is not set


While I'm pointing some of this out, is there any way to get CONFIG_SND_DUMMY 
added to bone kernel as well as getting a few of the more readily available 
sound codecs added to both kernels?   Probably the PCM512X, SGTL5000, and 
WM8960 as there are a bunch of hats/addons available on Amazon that have 
those.

Dan


On Sunday, June 9, 2019 at 8:23:46 PM UTC-4, RobertCNelson wrote:
>
> On Sun, Jun 9, 2019 at 7:19 PM Robert Heller  > wrote: 
> > 
> > OK, I have made use of the MCP23008 and MCP23017, 8 bit and 16 bit GPIO 
> > expanders that are I2C connected on Raspberry Pis.  The Raspberry Pi 
> kernels 
> > include both an overlay (Device Tree Blob) and a driver module for the 
> > MCP23008 and MCP23017 chips.  I would also like to make use of these 
> chips on 
> > my beagle boards (a BeagleBoneBlack and a PocketBeagle). 
> > 
> > I just did some poking around on my BBB, and there are neither Device 
> Tree 
> > Blobs nor driver modules for the MCP23008 and MCP23017 chips. 
> > 
> > So, my question is:  What is involved in building the missing driver 
> modules 
> > and Device Tree Blobs -- I have built driver modules and even rebuilt 
> whole 
> > kernels on x86 Linux boxen, so I have passing knowledge of how that 
> goes, what 
> > I am really wondering: is there a repo with .deb files containing the 
> "extra" 
> > ko files?  Or tarballs containing the additional sources?  I realize the 
> BBB 
> > and PB are rather slow, so maybe I should cross build this on one of my 
> Pis? 
> > Or is there an alternitive kernel I can upgrade to that includes these 
> > modules? 
> > 
> > Right now my two Beagles are running 4.14.71-ti-r80, Debian GNU/Linux 9, 
> > BeagleBoard.org Debian Image 2018-10-07.  I did do a apt-get 
> update/apt-get 
> > dist-upgrade about a month ago (May 14). 
>
> it's enabled, just after r80 came out..  Just run, and then reboot.. 
>
> sudo /opt/scripts/tools/update_kernel.sh 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/57ea6b63-70ed-4d28-bb4b-e63233c43905%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] I2C GPIO expanders and the BeagleBoneBlack and PocketBeagle...

[Robert Nelson]

> > it's enabled, just after r80 came out..  Just run, and then reboot..
> >
> > sudo /opt/scripts/tools/update_kernel.sh
>
> OK, I did the above and did a apt-get dist-upgrade.
>
> The kernel module is there, but there isn't a Device Tree Blob for the *I2C*
> mcp23* chips, just a Device Tree Blob
> (/lib/firmware/BB-SPI0-MCP23S08-00A0.dtbo) for the SPI interface.

Sorry, i don't have all the hardware, please feel free to fork the
repo and submit a merge request:

https://github.com/beagleboard/bb.org-overlays/

> During the kernel update the package linux-firmware-image-4.14.108-ti-r106 was
> suggested, but apt-get install is complaining when I try to install it:
>
> snoopy% sudo apt-get install linux-firmware-image-4.14.108-ti-r106
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Package linux-firmware-image-4.14.108-ti-r106 is not available, but is 
> referred to by another package.
> This may mean that the package is missing, has been obsoleted, or is only 
> available from another source
>
> E: Package 'linux-firmware-image-4.14.108-ti-r106' has no installation 
> candidate

The "firmware" packages is not needed for us, all the device firmware
is packaged in a separate deb package.

> I do have device tree blobs on the RPi and can get a device tree blob source
> file from the RPi device tree source repo.  I guess it is *possible* to
> compile a device tree blob for the beagles, but want to be sure and would
> rather get a device tree blob properly built for the Beagles.

That can also be done:

https://github.com/beagleboard/BeagleBoard-DeviceTrees/tree/v4.14.x-ti

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYgo-v6ja-wKZeq9FmOFkA2s5kG-NWhMTU7--8j0V-tKTg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] I2C GPIO expanders and the BeagleBoneBlack and PocketBeagle...

[Robert Heller]

At Sun, 9 Jun 2019 19:23:12 -0500 Robert Nelson  wrote:

> 
> On Sun, Jun 9, 2019 at 7:19 PM Robert Heller  wrote:
> >
> > OK, I have made use of the MCP23008 and MCP23017, 8 bit and 16 bit GPIO
> > expanders that are I2C connected on Raspberry Pis.  The Raspberry Pi kernels
> > include both an overlay (Device Tree Blob) and a driver module for the
> > MCP23008 and MCP23017 chips.  I would also like to make use of these chips 
> > on
> > my beagle boards (a BeagleBoneBlack and a PocketBeagle).
> >
> > I just did some poking around on my BBB, and there are neither Device Tree
> > Blobs nor driver modules for the MCP23008 and MCP23017 chips.
> >
> > So, my question is:  What is involved in building the missing driver modules
> > and Device Tree Blobs -- I have built driver modules and even rebuilt whole
> > kernels on x86 Linux boxen, so I have passing knowledge of how that goes, 
> > what
> > I am really wondering: is there a repo with .deb files containing the 
> > "extra"
> > ko files?  Or tarballs containing the additional sources?  I realize the BBB
> > and PB are rather slow, so maybe I should cross build this on one of my Pis?
> > Or is there an alternitive kernel I can upgrade to that includes these
> > modules?
> >
> > Right now my two Beagles are running 4.14.71-ti-r80, Debian GNU/Linux 9,
> > BeagleBoard.org Debian Image 2018-10-07.  I did do a apt-get update/apt-get
> > dist-upgrade about a month ago (May 14).
> 
> it's enabled, just after r80 came out..  Just run, and then reboot..
> 
> sudo /opt/scripts/tools/update_kernel.sh

OK, I did the above and did a apt-get dist-upgrade.

The kernel module is there, but there isn't a Device Tree Blob for the *I2C* 
mcp23* chips, just a Device Tree Blob 
(/lib/firmware/BB-SPI0-MCP23S08-00A0.dtbo) for the SPI interface.

During the kernel update the package linux-firmware-image-4.14.108-ti-r106 was 
suggested, but apt-get install is complaining when I try to install it:

snoopy% sudo apt-get install linux-firmware-image-4.14.108-ti-r106
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Package linux-firmware-image-4.14.108-ti-r106 is not available, but is referred 
to by another package.
This may mean that the package is missing, has been obsoleted, or is only 
available from another source

E: Package 'linux-firmware-image-4.14.108-ti-r106' has no installation candidate

I do have device tree blobs on the RPi and can get a device tree blob source 
file from the RPi device tree source repo.  I guess it is *possible* to 
compile a device tree blob for the beagles, but want to be sure and would 
rather get a device tree blob properly built for the Beagles.

> 
> Regards,
> 

-- 
Robert Heller -- 978-544-6933
Deepwoods Software-- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
hel...@deepsoft.com   -- Webhosting Services
  

-- 
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/20190610145657.5C03E26C0006%40sharky3.deepsoft.com.
For more options, visit https://groups.google.com/d/optout.

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

[Robert Nelson]

On Mon, Jun 10, 2019 at 6:39 AM  wrote:
>
> hi, RobertCNelson
>  i am having same problem , but links are not working can you update them? 
> plz help me

Please go into more detail of what problem/issue you are having.

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYgqNg2kvRXQwckvFh5WWMb-33bzfFJ2QXrRLCM4pPDY2g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Tuning the watchdog timer - correct place?

[Hugh Frater]

An update - I haven't got round to testing new PRU code. However, this:

Setting and getting the timeout:
For some drivers it is possible to modify the watchdog timeout on the
fly with the SETTIMEOUT ioctl, those drivers have the WDIOF_SETTIMEOUT
flag set in their option field. The argument is an integer
representing the timeout in seconds. The driver returns the real
timeout used in the same variable, and this timeout might differ from
the requested one due to limitation of the hardware. 
>From 
here: 
https://github.com/philenotfound/beagleboneblack-kernel/blob/master/Documentation/watchdog/watchdog-api.txt

Looks relevant. Does anyone know if the Watchdog driver supports on the fly 
timeout adjustment?

On Tuesday, 4 June 2019 10:57:40 UTC+1, Hugh Frater wrote:

My experience of working directly with the i2c and eqep parts of the 
> silicon from within the PRU suggest that register access to the watchdog 
> peripheral would be both easy and reliable. It's simply a #define and you 
> can then access the register contents directly from within the PRU. 
>
> I will write some test code to reconfigure the watchdog and report back.
>
> On Tuesday, 4 June 2019 02:02:37 UTC+1, lazarman wrote:
>>
>> I'd ask the question are these register's accessable from the PRU my 
>> experience is dated and I'm not a Linux guy but most OS protect Access to 
>> certain registers I briefly looked at TRM the WDOG is enabled by default 
>> probably during boot. To set it or change the clock source you disable it 
>> which I doubt Linux would like from PRU side  but maybe I'm wrong. I'd look 
>> at the interconnect block diagram to see if PRU has access to the 
>> registers. Google am335x watchdog c code I see discussion about Kernel 
>> configuration. Typically on non Linux ARM side project TI provided quite a 
>> bit of example code for customer boot code options that's where I always 
>> start but that code isn't always in the public  domain and in your case 
>> isn't relavent after Linux takes over you may have to let ARM Linux side 
>> handle it. I'd look at PRU register memory map unless someone in here has 
>> done it from PRU. 
>> Good luck
>>
>> Sent from Yahoo Mail on Android 
>> 
>>
>> On Mon, Jun 3, 2019 at 7:07 AM, Hugh Frater
>>  wrote:
>> Where does one go to tune the watchdog timer? Is it a 
>> kernel-recompilation-required thing, or can it be done through uBoot?
>>
>> Or should I just use my PRU code to tune the watchdog control 
>> register when it boots? This would be the easiest option for me, if someone 
>> can point me at the correct area if the AM335XTRM? I had a look in there 
>> and couldn't find the correct registers.
>>
>> I'd like it to run about 10 seconds if possible for my application.
>>
>> -- 
>> 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 beagl...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/2d6c30bf-484e-49e6-ab9d-582535f60a84%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/d5001fc4-3965-407f-8146-77c07a3a2718%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[gim910220]

hi, RobertCNelson
 i am having same problem , but links are not working can you update them? 
plz help me
2017년 6월 28일 수요일 오후 10시 54분 28초 UTC+9, RobertCNelson 님의 말:
>
> On Wed, Jun 28, 2017 at 1:40 AM,  > 
> wrote: 
> > 
> >  i am having same problem , but links are not working can you update 
> them? 
> > That would be great help! 
>
> Those links where from last year...  The images are generated weekly: 
>
> https://rcn-ee.net/rootfs/bb.org/testing/2017-06-25/console/ 
>
> Regards, 
>
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/346de940-2923-445a-867f-f63da71b1863%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.