[beagleboard] Re: Best way to build a large array for access by PRU0 ?

[TJF]

The main reasons for a failing prussdrv_open() are

   1. the driver uio_pruss didn't load
  1. check lsmod if uio_pruss is listed
  2. check dmesg for errors
   2. the user has no write access to the interupts /dev/uio[0-7]
  1. check your write access by ls -l /dev/uio*
  2. Use ether sudo for your operation or adapt the uio* devices by 
  chmod (ie. in a boot script)
  
BR

Am Freitag, 23. März 2018 02:37:59 UTC+1 schrieb evan@cyvision.com:
>
> Hi TJF,
>
> Thank you for such a direct and concise solution! As I mentioned in one my 
> earlier replies today, I had some trouble getting libprussdrv to work on 
> 4.9 because prussdrv_open() failed everytime I tried to use it. But It's 
> been a while and I'm game to try it again with a fresh image and 
> everything, so I'll try all this tonight and hopefully I get somewhere :)
>
> Thank you!
> Evan
>
> On Thursday, March 1, 2018 at 11:27:01 AM UTC-8, TJF wrote:
>>
>> Hi Evan, I'm still with you!
>>
>> The solution is drop rproc and use libprussdrv instead. You'll find 
>> everything you need, just use it out-of-the-shelf. Everything is explained 
>> in the docs. The steps are:
>>
>>1. compile your PRU code by pasm assembler
>>2. load the uio_pruss driver with suiting parameter extram_pool_sz=
>>3. adapt your C code
>>
>>
>>- make a code frame to load the pasm binary to PRU (copy/paste from 
>>one of the examples)
>>- get ERam pointer by function prussdrv_map_extmem()
>>- write your integer data to that pointer from ARM side
>>- use function prussdrv_get_phys_addr() to get the physical address
>>- pass the physical address to PRU (ie via DRam)
>>- read the integers from there from PRU side
>>
>> Everything gets easy when you use the matching tools.
>>
>

-- 
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/f077429a-277b-4a51-997a-8a465e25b7a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Reading encoder using PRU

[TJF]

No change! In order to use the eQEP in the PWMSS, you have to go over OCP 
port with at least 3 cycles latency. The latency may get bigger, it depends 
on the trafic -> not realtime.

I see a chance to realize the task by counting by the PRU eCAP module or 
directly by a PRU-GPIO-IN, and controlling the laser by a PRU-GPIO-OUT.

BR

-- 
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/c66d6957-62dc-4e15-8c02-c93dd5fed30c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: i2c bus speed

[yassyass]

I was on the IRC a little while ago and was told to modify the 
am335x-boneblack-uboot.dtb file instead as these newer releases are Uboot 
releases.
Doing so actually solved my issue of not being able to change the i2c 
frequency of i2c-2.

Big shout out to zmatt for the help!



On Friday, March 23, 2018 at 2:37:48 PM UTC+13, yassyass wrote:
>
>
> Heres the boot log:
> https://pastebin.com/fgkRkCRv
>
> It seems to say that the I2C busses are set at 100 kHz because "could not 
> find pctldev for node 
> /ocp/l4_wkup@44c0/scm@21/pinmux@800/pinmux_i2c2_pins"
>
> On Thursday, March 22, 2018 at 2:49:01 AM UTC+13, RobertCNelson wrote:
>>
>> On Wed, Mar 21, 2018 at 12:47 AM,   wrote: 
>> > I am having the same issue with my BBB. Modifying the device tree with 
>> > values that should run the I2C clock to 400 kHz does not seem to change 
>> the 
>> > speed upon rebooting. I validated that the .dtb was modified by 
>> unpacking it 
>> > into a .dts again to check if the value was 400 kHz. 
>> > 
>> > Is this method of modifying the device tree not effective anymore in 
>> the 
>> > latest images of Debian? 
>>
>> Check your serial boot log, are you booting what you expect? 
>>
>> 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/2edb8939-5a19-47b9-8e1a-2cf6f5ed0d64%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Best way to build a large array for access by PRU0 ?

[evan . carter]

Hello? Is anyone seeing my replies to these suggestions? I'm not seeing my 
own replies :(

Evan

On Thursday, March 1, 2018 at 11:27:01 AM UTC-8, TJF wrote:
>
> Hi Evan, I'm still with you!
>
> The solution is drop rproc and use libprussdrv instead. You'll find 
> everything you need, just use it out-of-the-shelf. Everything is explained 
> in the docs. The steps are:
>
>1. compile your PRU code by pasm assembler
>2. load the uio_pruss driver with suiting parameter extram_pool_sz=
>3. adapt your C code
>
>
>- make a code frame to load the pasm binary to PRU (copy/paste from 
>one of the examples)
>- get ERam pointer by function prussdrv_map_extmem()
>- write your integer data to that pointer from ARM side
>- use function prussdrv_get_phys_addr() to get the physical address
>- pass the physical address to PRU (ie via DRam)
>- read the integers from there from PRU side
>
> Everything gets easy when you use the matching tools.
>

-- 
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/55882eaf-b325-4107-83d7-6497b0a632eb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Best way to build a large array for access by PRU0 ?

[evan . carter]

Hi TJF,

Thank you for such a direct and concise solution! As I mentioned in one my 
earlier replies today, I had some trouble getting libprussdrv to work on 
4.9 because prussdrv_open() failed everytime I tried to use it. But It's 
been a while and I'm game to try it again with a fresh image and 
everything, so I'll try all this tonight and hopefully I get somewhere :)

Thank you!
Evan

On Thursday, March 1, 2018 at 11:27:01 AM UTC-8, TJF wrote:
>
> Hi Evan, I'm still with you!
>
> The solution is drop rproc and use libprussdrv instead. You'll find 
> everything you need, just use it out-of-the-shelf. Everything is explained 
> in the docs. The steps are:
>
>1. compile your PRU code by pasm assembler
>2. load the uio_pruss driver with suiting parameter extram_pool_sz=
>3. adapt your C code
>
>
>- make a code frame to load the pasm binary to PRU (copy/paste from 
>one of the examples)
>- get ERam pointer by function prussdrv_map_extmem()
>- write your integer data to that pointer from ARM side
>- use function prussdrv_get_phys_addr() to get the physical address
>- pass the physical address to PRU (ie via DRam)
>- read the integers from there from PRU side
>
> Everything gets easy when you use the matching tools.
>

-- 
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/e4728d4f-71ef-4256-a7ef-6c1b5bebad3c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Problem with capes

[marcozamboni2013107]

Thanks very much,
erasing eMMC partition solved the problem

Marco Zamboni

Il giorno giovedì 22 marzo 2018 17:32:22 UTC+1, RobertCNelson ha scritto:
>
> On Thu, Mar 22, 2018 at 10:31 AM,  > 
> wrote: 
> > HI all, 
> > I have some problems enabling capes on my BBB. When I query config-pin 
> -q 
> > "pin_name" I get: 
> > 
> > "pin_name pinmux file not found! 
> > Pin has no cape: "pin_name" 
> > 
> > on every pin except the one not modifyable i.e.: 
> > #config-pin -q p9.04 
> > Pin is not modifyable: P9_04 3V3 
> > 
> > There is the uncommented lines  in /boot/uEnv.txt: 
> > 
> > uname_r=4.9.82-ti-r102 
> > enable_uboot_overlays=1 
> > enable_uboot_cape_universal=1 
> > cmdline=coherent_pool=1M net.ifnames=0 quiet 
> > 
> > There the result of /opt/scripts/tools/version.sh 
> > 
> > git:/opt/scripts/:[9d965a5f40ae00774c81164f87a450a678ab79f6] 
> > eeprom:[A335BNLT00C04417BBBK196C] 
> > model:[TI_AM335x_BeagleBone_Black] 
> > dogtag:[BeagleBoard.org Debian Image 2018-03-05] 
> > bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
> > 2018.01-2-ge9ff418fb8]:[location: dd MBR] 
> > bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
> > 2016.01-1-g4eb802e]:[location: dd MBR] 
>
> Your u-boot installed to the eMMC is breaking things... 
>
> sudo dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10 
>
> 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/b7975e1a-22e5-4efd-b309-376987255260%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Best way to build a large array for access by PRU0?

[evan . carter]

Hello! Yes you are right! Something was wrong with my client and I only 
just now saw all of these replies!

I don't understand why, but I was not receiving emails with updates on this 
post of mine :/ I was getting email updates with daily summaries of other 
questions getting answered right away and I was beginning to feel 
discouraged. But somehow I just found all of these ! Thank you for all the 
replies everyone. 

As far as using kmalloc and vmalloc inside kernel space, it definitely 
looks challenging, but kernel space programming is something I think I will 
want to learn someday so I'm not too intimidated to consider it. I read 
Derek Molloy's 3 articles about loadable kernel modules on the beaglebone, 
and I thought they were really well done, but I wasn't sure if I really 
knew everything I needed to know to make a kernel module that uses 
kmalloc/vmalloc. Does a kernel module that allocates this kind of memory in 
external ram need to happen in the boot up process? or will a run-time 
Loadable Kernel Module be able to do it? Any one have any good resources 
for a beginner to learn kernel space memory allocation?

I was originally trying to program the PRU using libprussdrv, but I was 
unable to make it work on 4.9... :( prussdrv_open() would always fail me no 
matter what I tried. If anyone could tell me what I was doing wrong, I 
would definitely go back to libprussdrv because it made more intuitive 
sense to me than pru_rproc, but as of now pru_rproc (using 4.4) is the only 
way I've been able to get at my beaglebone's PRUs! So I gotta ask, is there 
anything like the "sudo modprobe uio_pruss extram_pool_sz=0x12500" 
solution that would work with pru_rproc? I definitely think that kind of 
command is idealic, I'm willing to switch to uio_pruss if I can use it and 
it works... but is there anything similar that works with pru_rproc? 
because that would save me a lot o f time and backtracking.

Thank you so much for reading!
Evan


On Tuesday, February 27, 2018 at 12:19:58 PM UTC-8, Evan Carter wrote:
>
> Hello,
>
> I've been working with PRU0 on the Beaglebone Black for a couple weeks now 
> (only a beginner) and have made some hopeful progress towards developing a 
> real time system that will change gpio logic states based on given location 
> data from a pupil tracking system. 
>
> So far I've been using the examples given in the BeagleScope project 
> (found here 
> ) to 
> program the PRU using pru_rpmsg, and I'm currently using: Linux beaglebone 
> 4.4.113-ti-r147 #1 SMP Tue Feb 20 20:58:22 UTC 2018 armv7l GNU/Linux
>
> Things are going well! 
> *But I wanted to ask the community about the simplest way to build a large 
> 1-D array (look up table of ~310,000 indexes of just integers) that can be 
> accessed by PRU0 on the fly* to know how to set the gpios when it 
> receives a new set of pupil location values. Previously I've built this 
> array in userspace from an existing .txt file that is read byte by byte 
> from a C script that builds the array, but I need that array to be 
> accessible from PRU0. What is the simplest way to do this?
>
> I've looked into trying to build the array in DDR memory (which could in 
> theory be accessed by the PRU using address pointers), but allocating that 
> kind of space to be available to a user space program looks pretty 
> complicated (especially to ME who has never done any kernel space 
> programming). I'm hoping that someone out there can give me inspiration for 
> a simpler way to get this array to PRU0.
>
> Please get back to me soon! Thank you for reading
>

-- 
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/c863cf7e-ab16-49ea-bbf9-c3056f73fd43%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: i2c bus speed

[yasirhilali]

Heres the boot log:
https://pastebin.com/fgkRkCRv

It seems to say that the I2C busses are set at 100 kHz because "could not 
find pctldev for node 
/ocp/l4_wkup@44c0/scm@21/pinmux@800/pinmux_i2c2_pins"

On Thursday, March 22, 2018 at 2:49:01 AM UTC+13, RobertCNelson wrote:
>
> On Wed, Mar 21, 2018 at 12:47 AM,  > 
> wrote: 
> > I am having the same issue with my BBB. Modifying the device tree with 
> > values that should run the I2C clock to 400 kHz does not seem to change 
> the 
> > speed upon rebooting. I validated that the .dtb was modified by 
> unpacking it 
> > into a .dts again to check if the value was 400 kHz. 
> > 
> > Is this method of modifying the device tree not effective anymore in the 
> > latest images of Debian? 
>
> Check your serial boot log, are you booting what you expect? 
>
> 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/f6740f70-0b6e-47f1-ae01-01e7c9f05d71%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Unable to configure pins

[jackw2050]

Hi,

I am working with the latest release for the Beagle Bone Black
and using the configuration commands found here 
https://github.com/cdsteinkuehler/beaglebone-universal-io to configure 
the PWM

Configuration seems to fail for every pin I have tried.

When I attempt to configure the PWM  using config-pin -q P8.07
 the response is P8_13 pinmux file not found!
Pin has no cape: P8_13


I have searched the group for others with similar issues and the solutions 
have not worked for me.
Everything seems to be up to date and the uEnv.txt looks correct.

What am I missing?

Any help with this issue is greatly appreciated.  



System information is:



bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
2018.01-2-g9aa111a004]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2016.11-rc3-2-g73df7f]:[location: dd MBR]

BeagleBoard.org Debian Image 2018-02-11
Debian version: 9.3
cmdline: console=ttyO0,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 
rootwait coherent_pool=1M net.ifnames=0 quiet
debian@beaglebone:/var/lib/cloud9$ cat 
/sys/devices/platform/bone_capemgr/slots
 0: PF  -1
 1: PF  -1
 2: PF  -1
 3: PF  -1





uEnv.txt



#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0

uname_r=4.9.80-ti-r98
#uuid=
#dtb=


###U-Boot Overlays###
###Documentation: 
http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
###Master Enable
enable_uboot_overlays=1
###
###Overide capes with eeprom
#uboot_overlay_addr0=/lib/firmware/.dtbo
#uboot_overlay_addr1=/lib/firmware/.dtbo
#uboot_overlay_addr2=/lib/firmware/.dtbo
#uboot_overlay_addr3=/lib/firmware/.dtbo
###
###Additional custom capes
#uboot_overlay_addr4=/lib/firmware/.dtbo
#uboot_overlay_addr5=/lib/firmware/.dtbo
#uboot_overlay_addr6=/lib/firmware/.dtbo
#uboot_overlay_addr7=/lib/firmware/.dtbo
###
###Custom Cape
#dtb_overlay=/lib/firmware/.dtbo
###
###Disable auto loading of virtual capes (emmc/video/wireless/adc)
disable_uboot_overlay_emmc=1
disable_uboot_overlay_video=1
disable_uboot_overlay_audio=1
#disable_uboot_overlay_wireless=1
#disable_uboot_overlay_adc=1
###
###PRUSS OPTIONS
###pru_rproc (4.4.x-ti kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo
###pru_uio (4.4.x-ti & mainline/bone kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
###
###Cape Universal Enable
enable_uboot_cape_universal=1
###
###Debug: disable uboot autoload of Cape
#disable_uboot_overlay_addr0=1
#disable_uboot_overlay_addr1=1
#disable_uboot_overlay_addr2=1
#disable_uboot_overlay_addr3=1
###
###U-Boot fdt tweaks... (6 = 384KB)
#uboot_fdt_buffer=0x6
###U-Boot Overlays###


cmdline=coherent_pool=1M net.ifnames=0 quiet

#In the event of edid real failures, uncomment this next line:
#cmdline=coherent_pool=1M net.ifnames=0 quiet video=HDMI-A-1:1024x768@60e

##enable Generic eMMC Flasher:
##make sure, these tools are installed: dosfstools rsync
#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh
 




Regards,


Jack Walker

   

-- 
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/e6b878b0-430c-4e3a-80ba-80dc7dd90ecc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: I2S Audio on the BBB

[Stuart Longland]

On 22/03/18 19:12, jithunai...@gmail.com wrote:
> Its an elaborate and very well explained post. I wanted to use same
> CODEC to play an audio on BBB but on the latest Debian version 9.3.
> Device tree overlay structure is very different in the latest images.
> Will these same commands work on recent images as well? If you have
> tried it on any recent image,can you please guide?

The device tree stuff might change, but I'd imagine everything beyond
"You can check the existence of a soundcard…" should be near identical.

-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

-- 
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/0d1c4c9a-7fa2-dc4c-9f89-f614e816773c%40longlandclan.id.au.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: cannot enable pru pins (uBoot/cape/pinmux mismatch issue?)

[ags]

I'm back to working on getting all 10 pru0 pins working for my final 
design. Rather than loading a new version and hoping for the best, I'd like 
to use this as a learning opportunity for better understanding of how 
device trees, overlays, pin-config, uBoot all work together.

* Is there a recommended (organized) source for this type of information? I 
find that currently I'm finding fragmented information requiring me to 
piece it together for a complete understanding (which I sometimes do 
incorrectly). I'd be very happy to be able to read and learn on my own 
rather than ask for help - questions which may be obvious or simple for 
those that have the complete picture.

* on the elinux.org BeagleBone pages I read that "kernel overlays are going 
bye-bye" and "too many bugs, no dev interest...". So does this mean that 
exactly one dtb is loaded at boot and is immutable? Or that a "base" dtb 
with additional overlays can be used, but all must be specified at boot 
time and cannot change thereafter? I thought there was a lot of excitement 
about (and promotion of) the concept of using a cape overlay system to 
change the system configuration. (Piecing together fragments here) was the 
final analysis that on-the-fly hardware configuration changes are not 
really frequent, so boot-time reconfiguration was a reasonable trade-off 
for simplifying the overall system?

* I still don't know why my current configuration only allows me to 
configure some pru pins using config-pin. (Example: I can configure P9-27 
and P9-30 as pruout but not P9-25.) I've looked at the config-pin output, 
and the tables/information contained in the script itself, and all seem to 
show the pins properly defined as having a pruout mode - yet it doesn't 
work. I'm using the reference by Derek Molloy compiled to a convenient 
table format 
(here: 
http://exploringbeaglebone.com/wp-content/uploads/resources/BBBP9Header.pdf) 
which indicates each of these pins are allocated for use by mcasp_0.

* I looked at the source RCN linked below (bb.org-overlays) but don't know 
what I need to build: is it a new .dtb, or config-pin script? On my system 
I see that there is no "state" file for the pins I cannot configure for 
pruout. I see cape-universala (and cape-universaln and cape-universal) in 
/lib/firmware, but when I use config-pin attempting to load it that fails. 
It seems my system is incorrectly configured...

Note that I am using uio_pruss drivers and a workable solution must be 
compatible with this.


On Wednesday, December 20, 2017 at 2:34:48 PM UTC-8, RobertCNelson wrote:
>
> On Wed, Dec 20, 2017 at 4:29 PM, ags > 
> wrote: 
> > Thank you Robert. In the long term I will certainly do as you suggest. 
> Is 
> > there no way to "downgrade" or use an overlay for pin configuration that 
> is 
> > in sync with my current (4.4.30) kernel version? 
>
> Yes, source is available: 
>
> https://github.com/beagleboard/bb.org-overlays 
>
> > 
> > If that is not possible, will the 4.4.91 version you recommend support 
> > uio_pruss? I will have to review my notes, but my recollection is the 
> > remoteproc/uio driver debate was raging when I decided on this route, 
> and it 
> > took some effort for me to figure out how to make it work. 
>
> You said you were using uio_pruss, so i gave you specific directions 
> for uio_pruss with v4.4.x-ti. ;) 
>
> > 
> > Finally, if I must move to 4.4.91, would you kindly state how I can 
> > accomplish this with all pinmux/helper/config/overlay items also being 
> > synced without disrupting uio_pruss? 
> > I presume this: 
> > 
> > cd /opt/scripts/tools/ 
> > git pull 
> > sudo ./update_kernel.sh 
> > sudo reboot 
> > 
> > 
> > will result in the latest kernel version (4.9.x??) which is not what I 
> > want... 
>
> Nope, if you have v4.4.x-ti installed, that ^ will install the latest 
> v4.4.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/fef93045-439c-4fd8-b7a2-5d431067dc7a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] USB networking

[clarkbriggs101]

(my apologies. I originally posted this under Beagle Board. If you can 
clean that up, please delete it.)
Did it ever get figured out how to make a network via USB?  That is, I'd 
use a USB hub to lash up several (BBBs which I have passel of) as a single 
subnet.  This is in lieu of either a real Enet or wifi subnet. It seems the 
formula has to do with who (BBB or PC) owns the DHCP server and feels like 
a gateway. Where is that stuff configured on the BBB side. I might leave 1 
BBB doing that, and config the others to be clients. I never figured out 
how to configure the PC side, but maybe that isn't an issue.  For example, 
I don't expect to get the PC to do routing for the USB subnet out to the 
bigwideworld.  Getting a BBB with WiFi also to do routing might be a worth 
while follow on exercise.
Clark

-- 
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/4e6cc91f-a0d3-4131-a05d-cf4d0da8391b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Does not detect RTC (ds1307)

[Jeff Andich]

Also, I saw something really weird on my board with an uninitialized RTC:

On one of my boards with an uninitialized RTC, the RTC kernel message 
("hctosys: unable to read the hardware clock") went away when I "hot 
plugged" a USB<->serial converter into one of our USB ports on our board.  
The USB HUB isn't connected to the I2C3 bus...

Does the USB hub device driver or the USB bus driver initialize the RTC if 
it's uninitialized???  What could this be due to?

I'm running kernel 4.4.110-ti-r142 and debian 8.10 for the BB-X15..

Thanks!!

On Thursday, March 22, 2018 at 5:38:03 PM UTC-5, Jeff Andich wrote:
>
> I'm working with the RTC (MCP794110) at the moment, but on a "BB-X15 - 
> like" custom board platform.
>
> I'm not sure I follow. your post.. What's the I2C tool? Are you talking 
> about attaching the RTC to the BBB via the I2C tool or a problem with 
> reading the RTC on the BBB? Pardon my ignorance but does the BBB come with 
> an RTC (e.g. MCP794110) installed?  The BB-X15 does..
>
> Did you enable the I2C bus the RTC is attached to in the dev. tree? On my 
> platform, I had to enable the I2C bus (I2C3) in the dev. tree before the 
> drivers for the RTC would load.
>
> Then with some "new" RTC's on some of my boards, but not all, I got 
> "unable to read the hardware clock, I think, when the kernel is attempting 
> to set the system clock from the hardware clock (see the following):
>
> ebian@BeagleBoard-X15:~$ dmesg|grep rtc
> [1.551522] rtc-ds1307 2-006f: rtc core: registered mcp7941x as rtc0
> [1.551652] rtc-ds1307 2-006f: 64 bytes nvram
> [1.554511] omap_rtc 48838000.rtc: rtc core: registered 48838000.rtc as 
> rtc2
> [1.558261] palmas-rtc 4807.i2c:tps659038@58:tps659038_rtc: rtc 
> core: registered 4807.i2c:tps659 as rtc1
> [1.997160] rtc-ds1307 2-006f: hctosys: unable to read the hardware 
> clock.
>
> From what I've read on posts involving the RTC the following messages:
>
> 1) "unable to read the hardware clock" message and  the 
> 2) hwclock: ioctl(RTC_RD_TIME) to /dev/rtc to read the time failed: 
> Invalid argument.
>
> are due to the RTC's time being not initialized or (?invalid?).  I've been 
> able to work-around this by setting the clock, but initially I get warning 
> #2 when I initialize the clock with a valid date/time.  I'm wondering if 
> anyone can confirm if this is the correct fix for this scenario...
>
> Also, when PTC builds the BB-X15, and the BBB manufacture builds the 
> BBB's  (assuming BBB's have a RTC installed), do they ensure that the RTC 
> is correctly initialized prior to shipping to the distributors ?
>
>
> On Wednesday, March 21, 2018 at 6:18:27 PM UTC-5, Graham wrote:
>>
>> Do you have pull-up resistors?
>>
>> --- Graham
>>
>> ==
>>
>>
>> On Monday, March 19, 2018 at 8:28:51 AM UTC-5, Paco Velasco wrote:
>>>
>>> When I connect the rtc it does not detect the 68 address (I2C Tool).
>>>
>>> I have test with 2 RTC diferent,and with the BBB I have no problem.
>>>
>>> Anybody knows what could be the problem? 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/7d997b9f-0c6f-410c-be13-77bd0de8f1e8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Does not detect RTC (ds1307)

[Jeff Andich]

Also, I saw something really weird on my platform.

On one of my boards with an initialized RTC, the RTC kernel message 
("hctosys: unable to read the hardware clock") went away when I "hot 
plugged" a USB<->serial converter into one of our USB ports on our board.  
The USB HUB isn't connected to the I2C3 bus...

Does the USB hub device driver or the USB bus driver initialize the RTC if 
it's uninitialized???

Thanks!!


On Thursday, March 22, 2018 at 5:38:03 PM UTC-5, Jeff Andich wrote:
>
> I'm working with the RTC (MCP794110) at the moment, but on a "BB-X15 - 
> like" custom board platform.
>
> I'm not sure I follow. your post.. What's the I2C tool? Are you talking 
> about attaching the RTC to the BBB via the I2C tool or a problem with 
> reading the RTC on the BBB? Pardon my ignorance but does the BBB come with 
> an RTC (e.g. MCP794110) installed?  The BB-X15 does..
>
> Did you enable the I2C bus the RTC is attached to in the dev. tree? On my 
> platform, I had to enable the I2C bus (I2C3) in the dev. tree before the 
> drivers for the RTC would load.
>
> Then with some "new" RTC's on some of my boards, but not all, I got 
> "unable to read the hardware clock, I think, when the kernel is attempting 
> to set the system clock from the hardware clock (see the following):
>
> ebian@BeagleBoard-X15:~$ dmesg|grep rtc
> [1.551522] rtc-ds1307 2-006f: rtc core: registered mcp7941x as rtc0
> [1.551652] rtc-ds1307 2-006f: 64 bytes nvram
> [1.554511] omap_rtc 48838000.rtc: rtc core: registered 48838000.rtc as 
> rtc2
> [1.558261] palmas-rtc 4807.i2c:tps659038@58:tps659038_rtc: rtc 
> core: registered 4807.i2c:tps659 as rtc1
> [1.997160] rtc-ds1307 2-006f: hctosys: unable to read the hardware 
> clock.
>
> From what I've read on posts involving the RTC the following messages:
>
> 1) "unable to read the hardware clock" message and  the 
> 2) hwclock: ioctl(RTC_RD_TIME) to /dev/rtc to read the time failed: 
> Invalid argument.
>
> are due to the RTC's time being not initialized or (?invalid?).  I've been 
> able to work-around this by setting the clock, but initially I get warning 
> #2 when I initialize the clock with a valid date/time.  I'm wondering if 
> anyone can confirm if this is the correct fix for this scenario...
>
> Also, when PTC builds the BB-X15, and the BBB manufacture builds the 
> BBB's  (assuming BBB's have a RTC installed), do they ensure that the RTC 
> is correctly initialized prior to shipping to the distributors ?
>
>
> On Wednesday, March 21, 2018 at 6:18:27 PM UTC-5, Graham wrote:
>>
>> Do you have pull-up resistors?
>>
>> --- Graham
>>
>> ==
>>
>>
>> On Monday, March 19, 2018 at 8:28:51 AM UTC-5, Paco Velasco wrote:
>>>
>>> When I connect the rtc it does not detect the 68 address (I2C Tool).
>>>
>>> I have test with 2 RTC diferent,and with the BBB I have no problem.
>>>
>>> Anybody knows what could be the problem? 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/ee0c29f8-4363-4837-92db-4630986fda1c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] USB networking

[clarkbriggs101]

Did it ever get figured out how to make a network via USB?  That is, I'd 
use a USB hub to lash up several (BBBs which I have passel of) as a single 
subnet.  This is in lieu of either a real Enet or wifi subnet. It seems the 
formula has to do with who (BBB or PC) owns the DHCP server and feels like 
a gateway. Where is that stuff configured on the BBB side. I might leave 1 
BBB doing that, and config the others to be clients. I never figured out 
how to configure the PC side, but maybe that isn't an issue.  For example, 
I don't expect to get the PC to do routing for the USB subnet out to the 
bigwideworld.  Getting a BBB with WiFi also to do routing might be a worth 
while follow on exercise.
Clark

-- 
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/9baede1d-e30d-4443-b59b-09e57e70b4fd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Does not detect RTC (ds1307)

[Jeff Andich]

I'm working with the RTC (MCP794110) at the moment, but on a "BB-X15 - 
like" custom board platform.

I'm not sure I follow. your post.. What's the I2C tool? Are you talking 
about attaching the RTC to the BBB via the I2C tool or a problem with 
reading the RTC on the BBB? Pardon my ignorance but does the BBB come with 
an RTC (e.g. MCP794110) installed?  The BB-X15 does..

Did you enable the I2C bus the RTC is attached to in the dev. tree? On my 
platform, I had to enable the I2C bus (I2C3) in the dev. tree before the 
drivers for the RTC would load.

Then with some "new" RTC's on some of my boards, but not all, I got "unable 
to read the hardware clock, I think, when the kernel is attempting to set 
the system clock from the hardware clock (see the following):

ebian@BeagleBoard-X15:~$ dmesg|grep rtc
[1.551522] rtc-ds1307 2-006f: rtc core: registered mcp7941x as rtc0
[1.551652] rtc-ds1307 2-006f: 64 bytes nvram
[1.554511] omap_rtc 48838000.rtc: rtc core: registered 48838000.rtc as 
rtc2
[1.558261] palmas-rtc 4807.i2c:tps659038@58:tps659038_rtc: rtc 
core: registered 4807.i2c:tps659 as rtc1
[1.997160] rtc-ds1307 2-006f: hctosys: unable to read the hardware 
clock.

>From what I've read on posts involving the RTC the following messages:

1) "unable to read the hardware clock" message and  the 
2) hwclock: ioctl(RTC_RD_TIME) to /dev/rtc to read the time failed: Invalid 
argument.

are due to the RTC's time being not initialized or (?invalid?).  I've been 
able to work-around this by setting the clock, but initially I get warning 
#2 when I initialize the clock with a valid date/time.  I'm wondering if 
anyone can confirm if this is the correct fix for this scenario...

Also, when PTC builds the BB-X15, and the BBB manufacture builds the BBB's  
(assuming BBB's have a RTC installed), do they ensure that the RTC is 
correctly initialized prior to shipping to the distributors ?


On Wednesday, March 21, 2018 at 6:18:27 PM UTC-5, Graham wrote:
>
> Do you have pull-up resistors?
>
> --- Graham
>
> ==
>
>
> On Monday, March 19, 2018 at 8:28:51 AM UTC-5, Paco Velasco wrote:
>>
>> When I connect the rtc it does not detect the 68 address (I2C Tool).
>>
>> I have test with 2 RTC diferent,and with the BBB I have no problem.
>>
>> Anybody knows what could be the problem? 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/e88753fa-9c7d-4f64-bf6d-b2a52a009907%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Does not detect RTC (ds1307)

[Jeff Andich]

I'm working with the RTC (MCP794110) at the moment, but on a "BB-X15 - 
like" custom board platform.

I'm not sure I follow. your post.. What's the I2C tool? Are you talking 
about attaching the RTC to the BBB via the I2C tool or a problem with 
reading the RTC on the BBB? Pardon my ignorance but does the BBB come with 
an RTC (e.g. MCP794110) installed?  The BB-X15 does..

Did you enable the I2C bus the RTC is attached to in the dev. tree? On my 
platform, I had to enable the I2C bus (I2C3) in the dev. tree before the 
drivers for the RTC would load.

Then with some "new" RTC's on some of my boards, but not all, I got "unable 
to read the hardware clock, I think, when the kernel is attempting to set 
the system clock from the hardware clock (see the following):

ebian@BeagleBoard-X15:~$ dmesg|grep rtc
[1.551522] rtc-ds1307 2-006f: rtc core: registered mcp7941x as rtc0
[1.551652] rtc-ds1307 2-006f: 64 bytes nvram
[1.554511] omap_rtc 48838000.rtc: rtc core: registered 48838000.rtc as 
rtc2
[1.558261] palmas-rtc 4807.i2c:tps659038@58:tps659038_rtc: rtc 
core: registered 4807.i2c:tps659 as rtc1
[1.997160] rtc-ds1307 2-006f: hctosys: unable to read the hardware 
clock.

>From what I've read on posts involving the RTC the following messages:

1) "unable to read the hardware clock" message and  the 
2) hwclock: ioctl(RTC_RD_TIME) to /dev/rtc to read the time failed: Invalid 
argument.

are due to the RTC's time being not initialized or (?invalid?).  I've been 
able to work-around this by setting the clock, but initially I get warning 
#2 when I initialize the clock with a valid date/time.  I'm wondering if 
anyone can confirm if this is the correct fix for this scenario...

Also, when PTC builds the BB-X15, and BBB's (assuming BBB's have a RTC 
installed), do they ensure that the RTC is correctly initialized prior to 
shipping?


On Wednesday, March 21, 2018 at 6:18:27 PM UTC-5, Graham wrote:

> Do you have pull-up resistors?
>
> --- Graham
>
> ==
>
>
> On Monday, March 19, 2018 at 8:28:51 AM UTC-5, Paco Velasco wrote:
>>
>> When I connect the rtc it does not detect the 68 address (I2C Tool).
>>
>> I have test with 2 RTC diferent,and with the BBB I have no problem.
>>
>> Anybody knows what could be the problem? 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/1c4360ca-fbcb-45f9-9dfe-ececb8da4cda%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] BBB USB WiFi

[clarkbriggs101]

Yes I know this is an old topic, or chronic. I am trying to revive a batch 
of BBBs. I got the current image and am running them off an SD card. I have 
the USB Wifi dongles from back in the day. By memory we got them to work ok 
enough. Where can I find the current BBB wifi setup instructions? This has 
changed a number of times over the migration to current Debian. The dongle 
isn't technically on the supported list. It is labeled Comfast CF-WU720N. 
The manufacturer's web site says it uses the Raylink 5370 chipset. On boot 
it is identified and invokes the rt2800usb kernel module. The dongle has a 
little blue activity or power light that doesn't come on now. By memory, 
this all worked but we had some initial issues with power management or 
something that controlled turning it on. I'd really like to use them. 
Pointers would be appreciated.
Clark

-- 
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/7eae76ad-7110-4d68-af59-f63a32953008%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Running off an SD card

[clarkbriggs101]

Folks,
I am trying to revive a batch of old BBBs. I put the current image on an SD 
card for it to live on. The original handshake of hold the user button 
while booting is required to make it boot from the SD card. It does that 
and I expanded the fs to the whole card size, etc.
But on most boots, I still have to hold that button.  Back when they were 
fresh, it seemed like it let go of that behavior. How do I get it to just 
boot the SD card automatically?
Clark
Clark Briggs

-- 
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/a3abbc59-d03d-478f-b679-7fa3fe42e963%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Two (or more) nrf24l01 on a single PocketBeagle

[Fred Kerr]

Hi, I've looked around and seen various code and libraries for nrf24l01. 
I'd like to wire up a couple to a single PocketBeagle and try transmitting 
from one to the other. Is this possible?

Thanks,
Fred

-- 
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/980ae2dd-51f6-4f3d-9474-4b66bb0ac7a5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PocketBeagle and TSA :)

[Jeff Andich]

Recently on an outbound flight I traveled with the PocketBeagle attached to 
the Baconbits Cape in the package it came in (with a plastic window), and 
placed it in a bin and on the belt.  No issues there.  Ironically on the 
inbound flight, before I had the PocketBeagle, that wasn't the case.



On Thursday, March 22, 2018 at 9:58:02 AM UTC-5, Sai Yamanoor wrote:
>
> There is micro center in St. Louis MO. They are better than Fry's when it 
> comes to stocking DIY stuff. If I am not wrong, the Pocket beagle used to 
> be stocked for 19.99 on some days.
>
> Sai
>
> On Thu, Mar 22, 2018 at 10:52 AM, Philip Polstra  > wrote:
>
>> I do this all the time.  Never had any trouble.
>>
>> On Thu, Mar 22, 2018 at 10:47 AM Fred Kerr > > wrote:
>>
>>> Hello!
>>>
>>> I am traveling soon to Illinois from Portland, OR and have a few 
>>> questions.
>>>
>>> Are there good HW stores like Fry's near St. Louis, MO or Jacksonville, 
>>> IL? :)
>>>
>>> What's the best way to not freak out TSA if I travel with a Pocket 
>>> Beagle or two and some prototyping things? :)
>>>
>>> I know lithium batteries need to be in carry-on. I just have a couple 
>>> standard cell phone chargers and external batteries that I intend to bring.
>>>
>>> Has anyone traveled with equipment like this? (Solderless breadboards, 
>>> pocket beagle, some cables, wires)
>>>
>>> Thanks!
>>>
>>> Fred Kerr
>>>
>>> -- 
>>> 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/0d6c473d-3e0c-4524-ba5c-f8c5f3dae257%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...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/CANt-8McgcB9ufk4sJyPyzu_VZTqS6XuEsuOAAmAYaNpZk0Ef1A%40mail.gmail.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
>
> http://saiyamanoor.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/008ce78d-9e85-49d0-96eb-2901715b302d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Pocket Beagle - USB tether networking and microsd resizing

[Fred Kerr]

Hello,

I have to do a couple steps each time I boot my pocket beagle (USB tether 
to debian ubuntu 16.04  host). Is there a better way?

debian@beaglebone:~$ source doroute.sh 
debian@beaglebone:~$ cat doroute.sh 
sudo route add default gw 192.168.7.1
sudo cp /home/debian/resolv.conf /run/connman/resolv.conf
debian@beaglebone:~$ cat resolv.conf 
nameserver 8.8.8.8

I have also had success with these instructions to resize a microSD 
partition. It seems a raspberry pi 3 b (raspian stretch desktop) may 
automatically resize the file system? Of course, automagic things have 
automagic results.

https://elinux.org/Beagleboard:Expanding_File_System_Partition_On_A_microSD

Are there any other "gotchas"?

Thanks!
Fred

-- 
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/3dc95b73-d010-459c-849c-928501848f49%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Problem with capes

[Robert Nelson]

On Thu, Mar 22, 2018 at 10:31 AM,   wrote:
> HI all,
> I have some problems enabling capes on my BBB. When I query config-pin -q
> "pin_name" I get:
>
> "pin_name pinmux file not found!
> Pin has no cape: "pin_name"
>
> on every pin except the one not modifyable i.e.:
> #config-pin -q p9.04
> Pin is not modifyable: P9_04 3V3
>
> There is the uncommented lines  in /boot/uEnv.txt:
>
> uname_r=4.9.82-ti-r102
> enable_uboot_overlays=1
> enable_uboot_cape_universal=1
> cmdline=coherent_pool=1M net.ifnames=0 quiet
>
> There the result of /opt/scripts/tools/version.sh
>
> git:/opt/scripts/:[9d965a5f40ae00774c81164f87a450a678ab79f6]
> eeprom:[A335BNLT00C04417BBBK196C]
> model:[TI_AM335x_BeagleBone_Black]
> dogtag:[BeagleBoard.org Debian Image 2018-03-05]
> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot
> 2018.01-2-ge9ff418fb8]:[location: dd MBR]
> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot
> 2016.01-1-g4eb802e]:[location: dd MBR]

Your u-boot installed to the eMMC is breaking things...

sudo dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10

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

Re: [beagleboard] BeagleBone Black Obsolete Micro SD Connector

[evilwulfie]

 guess you are out of luck
they make a new and improved one
 
https://www.mouser.com/ProductDetail/ALPS/SCHA4B0419?qs=%2fha2pyFadujzBzBPamTRjkUGzPSTLFKYyOM93b0OMDAhr7xe6hPfKnecwTu9HPED
old ones are available on ebay
https://www.ebay.com/itm/50pc-Micro-SD-Memory-Card-Push-push-Type-Connector-SCHA-Series-SCHA5B0200-Alps/131878424380?epid=1718065306&hash=item1eb4910f3c:g:eiQAAOSwiCRUkajw


On 3/22/2018 8:53 AM, JaredH wrote:
> The BOM for the BeagleBone Black calls out SCHA5B0200 from Alps Electronics 
> for the micro SD connector. This part number was discontinued in September 
> 2016 with a last time buy in March 2017. This part has a unique pin layout, 
> and I have not been able to find a compatible replacement. 
> Does anyone have any information about a replacement connector or a redesign 
> to support a new connector? Any information would be appreciated.
>

-- 
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/028c54fc-bf52-9c2c-5cb1-da2c2f17561e%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Latest Debian Image(Specifics Below) Black Soundcard not recognized.

[jithunair91]

Hey hi Cad soft.
 I have the exactly same issue as yours. I have built a custom audio DAC 
based on PCM5101A. So from so many discussions i found that on earlier 
versions of image till 3.8 it worked smoothly by loading the .dtbo file to 
/sys/devices/platform/bone_capemgr/slots  and when we do cat slots,we can 
see our audio cape successfully loaded. But when i try on kernel versions 
4.1.x or above, the device tree structure has changed and i guess now it 
works on uboot-overlay method. so i came across your post telling you also 
faced similar issue.I know its been a quite long time after you posted but 
i am totally stuck with this new overlay method and couldnt get solution. I 
am not an expert in linux . So can you please suggest if you got it working 
on new versions later? It will be really helpful . By the way just now i 
noticed i think i was following your github page only suggested by SHABAZ 
and trying to load jorge-audio-cape to the slots file. But ya it is not 
working on new images as i told already.waiting for your response.
thanks in advance.
Jithu 

On Thursday, November 19, 2015 at 4:49:56 AM UTC+5:30, Cad Soft wrote:
>
>
> login as: root
> Debian GNU/Linux 7
>
> BeagleBoard.org Debian Image 2015-11-03
>
> Support/FAQ: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian
>
> default username:password is [debian:temppwd]
>
> Last login: Wed Nov 18 21:36:53 2015 from 192.168.7.1
> root@beaglebone:~# ls /proc/asound
> cards  devices  oss  pcm  seq  timers  version
> root@beaglebone:~# uname -a
> Linux beaglebone 3.8.13-bone79 #1 SMP Tue Oct 13 20:44:55 UTC 2015 armv7l 
> GNU/Linux
>
> Hello All,
>
> This is my first post so I apologize if I ask anything that should be 
> obvious.
>
> I built a custom audio cape based on the PCM5102A audio DAC from TI. With 
> an older version of the image I could direct the sound output from mplayer 
> or ffmpeg to the Black soundcard which is just straight I2S coming out of 
> the pins and it worked beautifully. Now my project requires the use of a 4D 
> systems 4DCape-70T so I updated to the latest Debian image. Now this image 
> doesn't have the Black soundcard, so I can't get audio working.
>
> I've tried doing an apt-get install of alsa-base and alsa-utils but it 
> didn't make a difference.
>
>
> Any pointers would be greatly appreciated.
>
> Best Regards,
> Jorge Garcia
>

-- 
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/90e5e1df-1d08-4d11-976b-764a8e3607c5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: I2S Audio on the BBB

[jithunair91]

Hey hi Graham,
Its an elaborate and very well explained post. I wanted to use same CODEC 
to play an audio on BBB but on the latest Debian version 9.3. Device tree 
overlay structure is very different in the latest images. Will these same 
commands work on recent images as well? If you have tried it on any recent 
image,can you please guide?
Thanks,
Jithu.

On Wednesday, December 27, 2017 at 2:24:04 AM UTC+5:30, Graham wrote:
>
> ags:
> Here it is.
> --- Graham
>
> ==
>
>
> **
> *Making the Audio Cape Work  2017 
> MAY 15*
>
> **
>
> *Notes: *
> *My goal was specifically to make a CircuitCo Audio Cape Rev.B work, 
> driving an*
> *amplified speaker system, and then operate the BBB as an "Internet 
> Radio."*
>
> *The CircuitCo Audio Cape is no longer in production, so may be difficult 
> to*
> *find.  It uses a Texas Instruments TLV320AIC3104 Codec.  The same driver 
> may*
> *work with other cards that use the same CODEC, or other CODECs in the 
> same*
> *TI family that use the identical I2C commands to configure the CODEC.*
>
> *If you want to use a different CODEC, then you will need to research 
> whether *
> *there is a Linux driver for that specific CODEC, and figure out how to 
> invoke*
> *it from the device tree. If you are lucky, there may be one.  If you are 
> not *
> *lucky, then you will have to learn about writing your own Linux device 
> driver.*
>
>
> **
> *Hardware Note:*
> *The CircuitCo card does not appear to have any supersonic filtering.*
> *It needs a supersonic RC low pass.*
> *The noise starts about 150 kHz, peaking at 625 kHz*
>
> *If you put a scope on the output, with the audio at reasonable volume 
> level,*
> *you will see a bunch of Delta-Sigma leakage that is louder than the 
> desired audio.  *
> *You can not hear it with your ears, but could cause problems with 
> circuits that*
> *are sensitive in that frequency region, with the chance of unexpected 
> amplifier*
> *overload and distortion, for no apparent reason.*
>
>
> **
>
> *I used Debian 8.6 Release 2016-05-11, iot, SDcard resident, in case I 
> wanted to*
> *store a lot of music files.*
>
> *rm /uEnv.txt# backwards compatibility*
>
> *edit uEnv.txt:*
> *dtb=am335x-boneblack-audio.dtb*
> *cmdline=coherent_pool=1M verbose*
> *cape_enable=bone_capemgr.enable_partno=BB-BONE-AUDI-02*
>
> *apt-get update*
> *apt-get install git alsa-base alsa-utils mpd mpc*
>
>
> *Expanding partition to full card size*
> *cd /opt/scripts/tools/*
> *git pull*
> *sudo ./grow_partition.sh*
>
>
> **
>
> *sudo update-initramfs -uk `uname -r` *
>
> *to make sure the *.dtbo get's copied to the intrd. (it'll still read *
> *it from the /lib/firmware) *
>
> *otherwise, dmesg | grep cape *
>
>
> **
>
> *You can check the existence of a soundcard by looking in 
> /proc/asound/cards. *
> *For example:*
>
> * bash$ cat /proc/asound/cards*
>
> *or *
> *aplay -l  or  aplay -L*
>
>
> **
> *Get Robert's asound.state file from*
> *https://github.com/RobertCNelson/boot-scripts/tree/master/device/bone/capes/BBB_Audio_Cape_RevB
>  
> *
> *Download the asound.state file to  /var/lib/alsa/asound.state*
>
> *cat /var/lib/alsa/asound.state*
>
> **
> *check to see that the 'cape' is loading:*
> *look in the boot 'spew' for*
> *[   ] bone_capemgr bone_capemgr: enabled_partno PARTNO 'BB-BONE-AUDI-02' 
> VER 'N/A' PR '0'*
>
> **
>
> *check if the CODEC can be accessed via I2C interface:*
> *i2cdetect -y -r 2*
> *should show the chip at address 0x18 for Audio Cape Rev.2*
>
> *If all the device tree files loaded, will show 0x18 as protected 'UU'*
> *Meaning the kernel has claimed the CODEC, and is now in control.*
> *You can no longer access the CODEC from user space*
>
> *If you want to dump the CODEC I2C configuration (I2C page 0)*
> *i2cdump -f -r 0x00-0x7F -y 2 0x18*
>
>
> **
> *When I first got to this point, I thought the CODEC was not working, but 
> it*
> *turns out the default gain levels are extremely low, and it was actually 
> working.*
> *Turn up the volume before you get discouraged.*
>
> *=

[beagleboard] Re: BeagleBone Black Wireless and I2S audio output

[jithunair91]

 Hi adrien,

I also wanted to play I2S output audio on BBB. I have 2 DACs ,one based on 
PCM5101A,other based on TLV320AIC23 CODEC. But the device tree overlays are 
handled differently in newer Debian images.  which is the DAC which you 
used and can you please guide how to add the audio cape to the device tree 
and make it working? I am not an expert in linux. any help will be very 
useful.
Thanks in advance.
Jithu

On Friday, September 22, 2017 at 9:17:33 PM UTC+5:30, 
adrien.co...@gmail.com wrote:
>
> Hello everyone,
>
> I need your help.
>
> I have a BeagleBone Black Wireless, on which I installed the standard 
> Jessie Debian distribution.
> I want to add an audio output with the I2S, and i wish to keep HDMI 
> working.
>
> I also have a DAC (Phat DAC) which is originally made for the Raspberry pi 
> zero.
>
> I'm aware that the HDMI chip is receiving the I2S data that is generated 
> by the processor. (see this [article](
> https://hifiduino.wordpress.com/2014/03/10/beaglebone-black-for-audio/) 
> for details)
>
> I have use the BBBW [shematics](
> https://github.com/beagleboard/beaglebone-black-wireless/blob/master/BeagleBone_Black_Wireless_SCH.pdf)
>  
> and the Ohat DAC pinout (did not find the schematics) to connect the 2 
> boards.
>
> connections:
> - GND (phat pin 6, 39 <-> BBB P9_1 )
> - 5V (phat pin 2 & 4 <-> BBB P9_5 & P9_6)
> - 3.3V (phat pin 1 <-> BBB P9_3)
> - I2S LRCLOCK (phat pin 12 <-> BBB P9_28)
> - I2S SCLK / bitclock (phat pin 35 <-> BBB P9_31)
> - I2S data (phat pin 40 <-> BBB P9_29)
>
> To test my speaker output i run
> `$ speaker-test -F S32_LE -f 48000 -c 2`
>
> I have no sound (i also tried with aplay to read WAV files and mplayer 
> just in case)
>
>
> Does anyone has any idea if:
> - my connections are bad
> - if i must connect the HDMI screen to get the audio output on the I2S bus 
> (because of OS settings) *i tried with and without the screen without 
> success*
> - if i have to change the drivers (I've read about the botic driver but 
> the HDMI should send audio on I2S)
>
> ALso in the future i expect to use GPIO3_21 to add a Master clock (as 
> apparently the BBBW is limited to 48kHz sample rate family)
>
> Thank you in advance for any help
>
> Best
>

-- 
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/725becda-20e6-4539-8266-852597491900%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Beaglebone Black and tlv320aic32x4 No Audio Out or In

[jithunair91]

Hi ed,
I am also trying to play audio on BBB using TLV320AIC23 CODEC on 9.3 Debian 
version. But it seems device tree overlay structure has changed a lot in 
recent images. ?sys/devices/platform/bone_capemgr/slots is not available in 
latest debian. on which debian version did u try and can you please guide 
how did you add the audio cape to device tree. waiting for your response.
Thanks in advance.
Jithu



On Monday, July 25, 2016 at 9:07:18 PM UTC+5:30, ed wrote:
>
>
> I am currently working on getting a board designed after the BBB to work 
> with the tlv320aic3254 audio codec.  Currently i have the driver being 
> recognized by alsa with the included overlay.  I modified the driver to use 
> the 24.576 clock which we carried over from the BBB and when i hook up the 
> device to our saleae logic analizer the bitclock, wordclock, and data look 
> perfect when running speaker-test -t sine -f 1000.  As in the overlay the 
> AM335x is the slave device TLV320AIC3254 
>  and the output data is 
> correct.  When using alsamixer i am able to configure the channels and the 
> reg data changes but i get no sound out of either line out or headphone 
> when the channels are enabled.  I suspect there is either an overlay or 
> configuration issue preventing the output of audio data as when i do 
> arecord with a 1khz sine wave as input i get no data out as well.  At this 
> point i am at a loss as to why this is not working.  I have included for 
> reference my overlay, the register dump while speaker-test is running for 
> page one and two and the updated driver with the MCLK patch and my 
> additional clocking entries.  Any help would be greatly appreciated
>
>
> /*
>  * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
>  *
>  * This program is free software; you can redistribute it and/or modify
>  * it under the terms of the GNU General Public License version 2 as
>  * published by the Free Software Foundation.
>  */
> /dts-v1/;
> /plugin/;
>
> #include 
> #include 
>
> / {
> compatible = "ti,beaglebone", "ti,beaglebone-black", 
> "ti,beaglebone-green";
>
> /* identification */
> part-number = "BB-BONE-AUDI-02";
> version = "00A0", "A0";
>
> /* state the resources this cape uses */
> exclusive-use =
> /* the pin header uses */
> "P9.31",/* mcasp0: mcasp0_aclkx */
> "P9.29",/* mcasp0: mcasp0_fsx */
> "P9.28",/* mcasp0: mcasp0_axr2 */
> "P9.25",/* mcasp0: mcasp0_ahclkx */
> "P9.30",/* mcasp0: mcasp0_axr0 */
> /* the hardware ip uses */
> "gpio3_21",
> "mcasp0";
>
> fragment@0 {
> target = <&am33xx_pinmux>;
> __overlay__ {
> bone_audio_cape_audio_pins: pinmux_bone_audio_cape_audio_pins 
> {
> pinctrl-single,pins = <
> 0x190 (PIN_INPUT_PULLDOWN | MUX_MODE0)/* 
> mcasp0_aclkx.mcasp0_aclkx */
> 0x194 (PIN_INPUT_PULLDOWN | MUX_MODE0)/* 
> mcasp0_fsx.mcasp0_fsx, INPUT */
> 0x198 (PIN_INPUT_PULLDOWN | MUX_MODE0)/* 
> mcasp0_axr0.mcasp0_axr0 */
> 0x19c (PIN_INPUT_PULLDOWN | MUX_MODE2)/* 
> mcasp0_ahclkr.mcasp0_axr2 */
> 0x1ac (PIN_INPUT_PULLDOWN | MUX_MODE0)/* 
> MCASP0_AHCLKX -> MCASP0_AHCLKX (I2S_MCLK_OUT)- in */
> 0x06c ( PIN_OUTPUT_PULLUP | MUX_MODE7 ) /* 
> mcasp0_axr1 GPIO1_27 | OUTPUT | PULLUP */
> >;
> };
> };
> };
>
> fragment@1 {
> target = <&i2c0>;
> __overlay__ {
> #address-cells = <1>;
> #size-cells = <0>;
> clock-frequency = <10>;
> status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <&i2c0_pins>;
>
> tlv320aic32x4: tlv320aic32x4@18 {
> #sound-dai-cells = <0>;
> compatible = "ti,tlv320aic32x4";
> reg = <0x18>;
> };
> };
> };
>
> fragment@2 {
> target = <&mcasp0>;
> __overlay__ {
> #sound-dai-cells = <0>;
> compatible = "ti,am33xx-mcasp-audio";
> pinctrl-names = "default";
> pinctrl-0 = <&bone_audio_cape_audio_pins>;
> status = "okay";
> op-mode = <0>;  /* MCASP_IIS_MODE */
> tdm-slots = <2>;
> serial-dir = <  /* 0: INACTIVE, 1: TX, 2: RX */
> 2 0 1 0
> 0 0 0 0
> 0 0 0 0
> 0 0 0 0
> >;
> tx-num-evt = <1>;
> rx-num-evt = <1>;
> };
> };
>
> fragment@3 {
> target-path="/";
> __overlay__ {
> sound {
> compatible = "simple-audio-card";
> simple-audio-card,name = "Nyquist Dev Kit";
> simple-audio-card,format = "dsp_b";
>

[beagleboard] Problem with capes

[marcozamboni2013107]

HI all,
I have some problems enabling capes on my BBB. When I query config-pin -q 
"pin_name" I get:

"pin_name pinmux file not found!
Pin has no cape: "pin_name"

on every pin except the one not modifyable i.e.: 
#config-pin -q p9.04
Pin is not modifyable: P9_04 3V3

There is the uncommented lines  in /boot/uEnv.txt:

uname_r=4.9.82-ti-r102
enable_uboot_overlays=1
enable_uboot_cape_universal=1
cmdline=coherent_pool=1M net.ifnames=0 quiet

There the result of /opt/scripts/tools/version.sh

git:/opt/scripts/:[9d965a5f40ae00774c81164f87a450a678ab79f6]
eeprom:[A335BNLT00C04417BBBK196C]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Image 2018-03-05]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
2018.01-2-ge9ff418fb8]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2016.01-1-g4eb802e]:[location: dd MBR]
kernel:[4.9.82-ti-r102]
nodejs:[v6.13.1]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg:[bb-cape-overlays]:[4.4.20180322.0-0rcnee0~stretch+20180322]
pkg:[bb-wl18xx-firmware]:[1.20170829-0rcnee2~stretch+20180104]
pkg:[firmware-ti-connectivity]:[20170823-1rcnee0~stretch+20170830]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep 
admin spi tisdk weston-launch xenomai]
cmdline:[console=ttyO0,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 
rootwait coherent_pool=1M net.ifnames=0 quiet]
dmesg | grep pinctrl-single
[1.395598] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 
568
dmesg | grep gpio-of-helper
[1.396683] gpio-of-helper ocp:cape-universal: ready
END


Thanks
Marco Zamboni

PS: My objective is to enable all UART, PWM, I2C and let every other pin as 
available GPIO. (Disabling eMMC,HDMI...)

-- 
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/6491b5ab-8d48-43d2-80df-9a86aa3b8b34%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] BeagleBone Black Obsolete Micro SD Connector

[JaredH]

The BOM for the BeagleBone Black calls out SCHA5B0200 from Alps Electronics for 
the micro SD connector. This part number was discontinued in September 2016 
with a last time buy in March 2017. This part has a unique pin layout, and I 
have not been able to find a compatible replacement. 
Does anyone have any information about a replacement connector or a redesign to 
support a new connector? Any information would be appreciated.

-- 
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/2b163564-3701-4fe2-b065-32f3a21b122a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Beaglebone Black CPU Frequency

[Filip Kotouček]

Hello again,

I have similar issue here. I use:
root@beaglebone:~# cat /etc/dogtag
BeagleBoard.org Debian Image 2018-03-09
root@beaglebone:~# uname -a
Linux beaglebone 4.4.120-bone22 #1 Tue Mar 6 23:59:09 UTC 2018 armv7l 
GNU/Linux
I need UIO driver so I chose this kernel I cannot use TI based. Could it be 
set in device tree?

Thanks
 

Dne pondělí 3. srpna 2015 15:47:22 UTC+2 RobertCNelson napsal(a):
>
> On Mon, Aug 3, 2015 at 5:02 AM, Axel Barkow  > wrote: 
> > Hi everyone, 
> > 
> > I'm using the Beaglebone Black and wanted to increase the performance by 
> > setting the govenor to performance mode. After installing the 
> cpufrequtils 
> > in bone-debian-8.1-console-armhf-2015-07-19-2gb.img I found a maximum 
> > frequency of 720MHz where I was expecting 1GHz: 
> > 
> > debian@beaglebone:~$ cat /etc/dogtag 
> > BeagleBoard.org Debian Image 2015-07-19 
> > debian@beaglebone:~$ uname -a 
> > Linux beaglebone 4.1.2-ti-r4 #1 SMP PREEMPT Thu Jul 16 20:48:37 UTC 2015 
> > armv7l GNU/Linux 
> > debian@beaglebone:~$ cpufreq-info 
> > cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 
> > Report errors and bugs to cpu...@vger.kernel.org , please. 
> > analyzing CPU 0: 
> >   driver: cpufreq-dt 
> >   CPUs which run at the same hardware frequency: 0 
> >   CPUs which need to have their frequency coordinated by software: 0 
> >   maximum transition latency: 300 us. 
> >   hardware limits: 275 MHz - 720 MHz 
> >   available frequency steps: 275 MHz, 500 MHz, 600 MHz, 720 MHz 
> >   available cpufreq governors: conservative, ondemand, userspace, 
> powersave, 
> > performance 
> >   current policy: frequency should be within 275 MHz and 720 MHz. 
> >   The governor "performance" may decide which speed to 
> use 
> >   within this range. 
> >   current CPU frequency is 720 MHz. 
> >   cpufreq stats: 275 MHz:0.00%, 500 MHz:0.00%, 600 MHz:0.00%, 720 
> > MHz:100.00% 
> > 
> > Any explanation or is this some misunderstanding from my side? 
>
> Upgrade your kernel.. linux-image-4.1.3-ti-r7 
>
> 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/13914f07-c89e-4ee3-8b1c-28c681759958%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PocketBeagle and TSA :)

[Sai Yamanoor]

There is micro center in St. Louis MO. They are better than Fry's when it
comes to stocking DIY stuff. If I am not wrong, the Pocket beagle used to
be stocked for 19.99 on some days.

Sai

On Thu, Mar 22, 2018 at 10:52 AM, Philip Polstra  wrote:

> I do this all the time.  Never had any trouble.
>
> On Thu, Mar 22, 2018 at 10:47 AM Fred Kerr  wrote:
>
>> Hello!
>>
>> I am traveling soon to Illinois from Portland, OR and have a few
>> questions.
>>
>> Are there good HW stores like Fry's near St. Louis, MO or Jacksonville,
>> IL? :)
>>
>> What's the best way to not freak out TSA if I travel with a Pocket Beagle
>> or two and some prototyping things? :)
>>
>> I know lithium batteries need to be in carry-on. I just have a couple
>> standard cell phone chargers and external batteries that I intend to bring.
>>
>> Has anyone traveled with equipment like this? (Solderless breadboards,
>> pocket beagle, some cables, wires)
>>
>> Thanks!
>>
>> Fred Kerr
>>
>> --
>> 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/0d6c473d-3e0c-4524-ba5c-f8c5f3dae257%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/CANt-8McgcB9ufk4sJyPyzu_VZTqS6XuEsuOAAmAYaNpZk0Ef1A%
> 40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 

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

Re: [beagleboard] PocketBeagle and TSA :)

[Philip Polstra]

I do this all the time.  Never had any trouble.

On Thu, Mar 22, 2018 at 10:47 AM Fred Kerr  wrote:

> Hello!
>
> I am traveling soon to Illinois from Portland, OR and have a few questions.
>
> Are there good HW stores like Fry's near St. Louis, MO or Jacksonville,
> IL? :)
>
> What's the best way to not freak out TSA if I travel with a Pocket Beagle
> or two and some prototyping things? :)
>
> I know lithium batteries need to be in carry-on. I just have a couple
> standard cell phone chargers and external batteries that I intend to bring.
>
> Has anyone traveled with equipment like this? (Solderless breadboards,
> pocket beagle, some cables, wires)
>
> Thanks!
>
> Fred Kerr
>
> --
> 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/0d6c473d-3e0c-4524-ba5c-f8c5f3dae257%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/CANt-8McgcB9ufk4sJyPyzu_VZTqS6XuEsuOAAmAYaNpZk0Ef1A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PocketBeagle and TSA :)

[Fred Kerr]

Hello!

I am traveling soon to Illinois from Portland, OR and have a few questions.

Are there good HW stores like Fry's near St. Louis, MO or Jacksonville, IL? 
:)

What's the best way to not freak out TSA if I travel with a Pocket Beagle 
or two and some prototyping things? :)

I know lithium batteries need to be in carry-on. I just have a couple 
standard cell phone chargers and external batteries that I intend to bring.

Has anyone traveled with equipment like this? (Solderless breadboards, 
pocket beagle, some cables, wires)

Thanks!

Fred Kerr

-- 
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/0d6c473d-3e0c-4524-ba5c-f8c5f3dae257%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.