Re: [beagleboard] Re: wl18xx warning - any resolution?

[ags]

Does that mean that everyone running 4.14.x had these problems? I didn't 
find an outpouring of posts about this problem (although possibly simply a 
benign log entry) so thought it was a rarer problem that few others had.

Is it reasonable to update just the radio firmware(s), or would that pose a 
risk (greater than the upgrade)?

On Thursday, December 10, 2020 at 11:39:37 AM UTC-7, RobertCNelson wrote:
>
> On Thu, Dec 10, 2020 at 12:29 PM ags > 
> wrote: 
> > 
> > Posted the results of the script, curious as to what "the different 
> issue" is. I am hoping to avoid an upgrade to 4.19 at the moment, if 
> possible -- and particularly if the problem is known and has another fix 
> available. 
>
> Before you upgrade to 4.19, first step would be to "upgrade" the os.. 
>
> sudo apt update 
> sudo apt upgrade 
>
> All your firmware *.deb blob packages are at least 2 years out of date.. 
>
> 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/4ce6ef92-cd37-473d-b1a2-2746f5444719o%40googlegroups.com.

Re: [beagleboard] Re: wl18xx warning - any resolution?

[ags]

Posted the results of the script, curious as to what "the different issue" 
is. I am hoping to avoid an upgrade to 4.19 at the moment, if possible -- 
and particularly if the problem is known and has another fix available.


On Monday, December 7, 2020 at 1:53:24 PM UTC-7, RobertCNelson wrote:
>
> On Mon, Dec 7, 2020 at 2:43 PM ags > 
> wrote: 
> > 
> > @RobertCNelson are there any plans to provide this update as part of a 
> BBBW package? (any reason to believe it addresses the issue cited above?) 
> > 
>
> ps you have a different issue: 
>
> Please run and report this output: 
>
> sudo /opt/scripts/tools/version.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/8ab357d1-cfe0-4085-ba5d-e8bf302ab0a9o%40googlegroups.com.

Re: [beagleboard] Re: wl18xx warning - any resolution?

[ags]

git:/opt/scripts/:[109f74fb87e6034ae1a8971a244064a8d5e090a5]

eeprom:[A335BNLTBWA51650BBWG0378]

model:[TI_AM335x_BeagleBone_Black_Wireless]

dogtag:[BeagleBoard.org Debian Image 2019-08-03]

bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2019.04-2-gbb4af0f50f]:[location: dd MBR]

kernel:[4.14.108-ti-r113]

nodejs:[v6.17.0]

uboot_overlay_options:[enable_uboot_overlays=1]

uboot_overlay_options:[disable_uboot_overlay_audio=1]

uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]

uboot_overlay_options:[enable_uboot_cape_universal=1]

pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
]

pkg:[bb-cape-overlays]:[4.4.20190801.0-0rcnee0~stretch+20190801]

pkg:[bb-wl18xx-firmware]:[1.20190227.1-0rcnee0~stretch+20190227]

pkg:[kmod]:[23-2rcnee1~stretch+20171005]

pkg:[librobotcontrol]:[1.0.4-git20190227.1-0rcnee0~stretch+20190327]

pkg:[firmware-ti-connectivity]:[20180825+dfsg-1rcnee1~stretch+20181217]

groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
plugdev users systemd-journal i2c bluetooth netdev gpio pwm eqep remoteproc 
admin spi tisdk weston-launch xenomai cloud9ide]

cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
net.ifnames=0 rng_core.default_quality=100 quiet]

dmesg | grep remote

[1.313264] remoteproc remoteproc0: wkup_m3 is available

[1.528468] remoteproc remoteproc0: powering up wkup_m3

[1.528581] remoteproc remoteproc0: Booting fw image 
am335x-pm-firmware.elf, size 217168

[1.532865] remoteproc remoteproc0: remote processor wkup_m3 is now up

dmesg | grep pru

[ 5566.578557] Modules linked in: xt_conntrack ipt_MASQUERADE 
nf_nat_masquerade_ipv4 aes_arm_bs crypto_simd cryptd wl18xx wlcore mac80211 
rfcomm bnep hci_uart btqca bluetooth cfg80211 ecdh_generic uio_pruss 
usb_f_mass_storage usb_f_acm u_serial usb_f_ecm usb_f_rndis u_ether 
libcomposite bc_example(O) pvrsrvkm(O) iptable_nat nf_conntrack_ipv4 
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle 
iptable_filter snd_usb_audio snd_hwdep snd_usbmidi_lib snd_rawmidi 
snd_seq_device wlcore_sdio evdev uio_pdrv_genirq uio spidev pruss_soc_bus 
pru_rproc pruss pruss_intc ip_tables x_tables

[39794.273196] Modules linked in: xt_conntrack ipt_MASQUERADE 
nf_nat_masquerade_ipv4 aes_arm_bs crypto_simd cryptd wl18xx wlcore mac80211 
rfcomm bnep hci_uart btqca bluetooth cfg80211 ecdh_generic uio_pruss 
usb_f_mass_storage usb_f_acm u_serial usb_f_ecm usb_f_rndis u_ether 
libcomposite bc_example(O) pvrsrvkm(O) iptable_nat nf_conntrack_ipv4 
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle 
iptable_filter snd_usb_audio snd_hwdep snd_usbmidi_lib snd_rawmidi 
snd_seq_device wlcore_sdio evdev uio_pdrv_genirq uio spidev pruss_soc_bus 
pru_rproc pruss pruss_intc ip_tables x_tables

dmesg | grep pinctrl-single

[0.949178] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 
568

dmesg | grep gpio-of-helper

[0.961436] gpio-of-helper ocp:cape-universal: ready

lsusb

Bus 001 Device 002: ID 0d8c:0014 C-Media Electronics, Inc.

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

END

~  
 

~  
 


  26,592All

On Monday, December 7, 2020 at 1:53:24 PM UTC-7, RobertCNelson wrote:
>
> On Mon, Dec 7, 2020 at 2:43 PM ags > 
> wrote: 
> > 
> > @RobertCNelson are there any plans to provide this update as part of a 
> BBBW package? (any reason to believe it addresses the issue cited above?) 
> > 
>
> ps you have a different issue: 
>
> Please run and report this output: 
>
> sudo /opt/scripts/tools/version.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/c3f754f7-a008-40d0-b668-0fcee908ef2bo%40googlegroups.com.

[beagleboard] Re: wl18xx warning - any resolution?

[ags]

@RobertCNelson are there any plans to provide this update as part of a BBBW 
package? (any reason to believe it addresses the issue cited above?)


On Monday, December 7, 2020 at 8:22:38 AM UTC-7, jose...@gmail.com wrote:
>
> TI has released recently an updated driver and firmware:
>
> https://github.com/beagleboard/Latest-Images/issues/73
>
> A segunda-feira, 7 de dezembro de 2020 à(s) 11:12:52 UTC, ags escreveu:
>
>> Has there been any progress in understanding the cause, and cure, for the 
>> warning message being written to the system log every second (BBBW)?
>>
>> kernel: *wlcore: WARNING no fw rx ba on tid *
>>>
>>
>> Is there a firmware/driver update available? I just re-flashed my eMMC on 
>> a
>>
>> uname -a
>>
>> Linux beaglebone 4.14.108-ti-r113 #1 SMP PREEMPT Wed Jul 31 00:01:10 UTC 
>> 2019 armv7l GNU/Linux
>>
>>
>>

-- 
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/2526ca04-4963-4311-8388-937ed3dbec9fo%40googlegroups.com.

[beagleboard] wl18xx warning - any resolution?

[ags]

Has there been any progress in understanding the cause, and cure, for the 
warning message being written to the system log every second (BBBW)?

kernel: *wlcore: WARNING no fw rx ba on tid *
>

Is there a firmware/driver update available? I just re-flashed my eMMC on a

uname -a

Linux beaglebone 4.14.108-ti-r113 #1 SMP PREEMPT Wed Jul 31 00:01:10 UTC 
2019 armv7l GNU/Linux


-- 
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/634d464c-0364-42d0-9558-6094514d60deo%40googlegroups.com.

[beagleboard] Re: BBBW first boot - no WiFi/BT

[ags]

Thanks for that info. Now that I have a "modern" uboot installed, I'll pay 
attention to how it works without holding the boot button.


On Tuesday, December 17, 2019 at 8:54:52 AM UTC-8, Dennis Bieber wrote:
>
> On Mon, 16 Dec 2019 23:54:41 -0800 (PST), in 
> gmane.comp.hardware.beagleboard.user ags 
>
>
> >The device was purchased in Dec 2018, and just now put into service; it 
> is 
> >a year (at least) out of date. 
>
> Based on the u-boot version -- much further out of date  
>
> >I was holding the boot-select button, and it did act as expected, 
> selecting 
> >between booting from the eMMC (not pushed) and the SD card (pushed) at 
> >power-up/start. 
> >It seems that the forced directive in uEnv.txt was ignored, though, so I 
> >presume that uboot did not read the uEnv.txt from the SD card even if 
> >booting from it. 
> > 
>
> My point was that, for some time now, my BBBs have not needed the 
> boot-select. They transition from eMMC to complete the boot using the SD 
> card, so long as a bootable SD card is in place. 
>
> The boot-select seems only required now to force the use of the SD 
> card 
> u-boot image. 
>
> Granted -- none of this appears to have an effect on your WiFi 
> matter... 'tis just an observation on booting behavior based upon my 
> collection... 
> -- 
> Dennis L Bieber 
>
>

-- 
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/e285dd93-20c8-4e97-abac-0e27b4b41ea8%40googlegroups.com.

[beagleboard] Re: BBBW first boot - no WiFi/BT

[ags]

The device was purchased in Dec 2018, and just now put into service; it is 
a year (at least) out of date.
I was holding the boot-select button, and it did act as expected, selecting 
between booting from the eMMC (not pushed) and the SD card (pushed) at 
power-up/start.
It seems that the forced directive in uEnv.txt was ignored, though, so I 
presume that uboot did not read the uEnv.txt from the SD card even if 
booting from it.

On Monday, December 16, 2019 at 6:43:22 PM UTC-8, Dennis Bieber wrote:
>
> {Blast -- my original response went to the dead submittal route, a belated 
> resend} 
>
> On Sun, 15 Dec 2019 23:00:05 -0800 (PST), in 
> gmane.comp.hardware.beagleboard.user ags wrote: 
>
> > 
> >bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
> >2019.04-2-gbb4af0f50f]:[location: dd MBR] 
> > 
> >bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
> >2016.11-rc3-2-g73df7f]:[location: dd MBR] 
> > 
>
> That's getting rather old... When was the last time you reflashed 
> the 
> entire eMMC? Does the board behave differently if you hold the boot-select 
> button down while applying power? (I believe the eMMC u-boot is used even 
> if it later transfers to the SD card for actual OS unless the boot-select 
> was held; then it uses the SD card u-boot for everything) 
>
> I don't have the wireless, but... 
>
> debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh 
> [sudo] password for debian: 
>
> eeprom:[A335BNLT000C0615BBBK0412] 
> model:[TI_AM335x_BeagleBone_Black] 
> dogtag:[BeagleBoard.org Debian Image 2019-08-03] 
>
> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
> 2019.04-2-gbb4af0f50f]:[location: dd MBR] 
>
> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
> 2019.04-2-gbb4af0f50f]:[location: dd MBR] 
>
> kernel:[4.14.108-ti-r113] 
>
> ... I tend to flash the eMMC whenever a new "standard" release shows up on 
> http://beagleboard.org/latest-images (given how fat the LXQT image is, I 
> think I've started using the IoT image for eMMC and reserve the LXQT image 
> for SD cards). 
> -- 
> Dennis L Bieber 
>
>

-- 
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/d7ec6059-c6ad-4648-8456-a0c2ef32cac8%40googlegroups.com.

Re: [beagleboard] Re: BBBW first boot - no WiFi/BT

[ags]

For future reference by others, I think instead of

"if=/opt/scripts/device/bone/bbgw-eeprom.dump"


it should have been stated as:
 

"if=/opt/scripts/device/bone/bbbw-eeprom.dump"

 
since I have a BeagleBone Black Wireless (but it is manufactured by GHI as 
you said). I first updated using the first file, and my device type was 
shows as BeagleBone Green Wireless. The WiFi would not work (using 
connmanctl for setup). I then flashed using the second file, and my device 
displayed as BeagleBone Black Wireless, and I was then successful in 
setting up WiFi connectivity.


On Monday, December 16, 2019 at 2:27:17 PM UTC-8, RobertCNelson wrote:
>
> On Mon, Dec 16, 2019 at 3:58 PM ags > 
> wrote: 
> > 
> > My next question was going to be "what should the EEPROM ID be... or 
> what form should it take"? 
>
> An even better, answer, look on side of the board, there is a bar code 
> with the coded: BWA5* that's what the device tester was supposed 
> to write to the eeprom. ;) 
>
> > This (non-functioning) BBBW was purchased in Dec 2018 (just now putting 
> it into service). I have another BBBW purchased in Feb 2017 that worked 
> out-of-box (almost... it had a different issue with the "out-of-box 
> configuration" that you also helped me with) and it shows: 
> > 
> > eeprom:[A335BNLTBWA51650BBWG0378] 
> > 
> > model:[TI_AM335x_BeagleBone_Black_Wireless] 
> > 
> > 
> > So does a "correct" BBB Wireless EEPROM ID follow the A335BNLT BWA51*** 
> BBWG0***] format, with the first wildcard digits some form of version of 
> the wireless chip and the second wildcard digits the board or SoC rev? 
> (spaces mine to separate the different fields) 
>
> The first Wild card, is the year in 2 digits and the week in 2 digits. 
> The last wildcard is incremental units of that week.. 
>
> BWA5 = BeagleBone Black Wireless 
>
> BBWG = BeagleBone Black Wireless, Manufactured by GHI 
>
> > 
> > Finally, was my expectation/understanding incorrect that using 
> /boot/uEnv.txt to override the EEPROM setting and force loading the 
> wireless dtb would also work, without changing the EEPROM? (My thinking was 
> to try that first, then if it worked it would validate the idea the the 
> EEPROM was bad and then reflash the EEPROM). 
>
> Well, you did have this old version of u-boot installed to the eMMC: 
>
> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
> 2016.11-rc3-2-g73df7f]:[location: dd MBR] 
>
> So the overide probably just didn't work.. 
>
> 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/1a93972a-7f2c-492e-a95a-e0c367d3dbcc%40googlegroups.com.

Re: [beagleboard] Re: BBBW first boot - no WiFi/BT

[ags]

My next question was going to be "what *should* the EEPROM ID be... or what 
form should it take"?
This (non-functioning) BBBW was purchased in Dec 2018 (just now putting it 
into service). I have another BBBW purchased in Feb 2017 that worked 
out-of-box (almost... it had a different issue with the "out-of-box 
configuration" that you also helped me with) and it shows:

eeprom:[A335BNLTBWA51650BBWG0378]

model:[TI_AM335x_BeagleBone_Black_Wireless]


So does a "correct" BBB Wireless EEPROM ID follow the A335BNLT BWA51*** 
BBWG0***] format, with the first wildcard digits some form of version of 
the wireless chip and the second wildcard digits the board or SoC rev? 
(spaces mine to separate the different fields)

Finally, was my expectation/understanding incorrect that using 
/boot/uEnv.txt to override the EEPROM setting and force loading the 
wireless dtb would also work, without changing the EEPROM? (My thinking was 
to try that first, then if it worked it would validate the idea the the 
EEPROM was bad and *then* reflash the EEPROM).

Thanks for your help, Robert.


On Monday, December 16, 2019 at 1:07:04 PM UTC-8, RobertCNelson wrote:
>
> On Mon, Dec 16, 2019 at 2:26 PM ags > 
> wrote: 
> > 
> > More: I tried overriding the dtb in uEnv.txt to force wireless operation 
> without reflashing eeprom - this was reported to work in some cases. 
> > How can I tell from the version.sh output if my eeprom is corrupt or 
> incorrect for a BBB Wireless? 
>
> >eprom:[A335BNLTBBWG2331?O] 
> >model:[TI_AM335x_BeagleBone_Black] 
>
> Oh, it's corrupt..  It's coming up as a normal BeagleBone Black.. 
>
> It should be: 
>
> eeprom:[A335BNLTBWA51919BBWG0600] 
> model:[TI_AM335x_BeagleBone_Black_Wireless] 
>
> So when you compare yours with mine, notice how I have the "BWA51919" 
> between A335BNLT and BBWG, well that's the "Wireless" identifier.. 
>
> So taking a wire, Ground TP1, (TP1 is between barrel plug and the J1 
> interface) 
>
> Then as root run this "one" line command: 
> * 
> dd if=/opt/scripts/device/bone/bbgw-eeprom.dump 
> of=/sys/devices/platform/ocp/44e0b000.i2c/i2c-0/0-0050/eeprom 
> * 
> ^ Yes this is one line, that gmail/etc will wordwrap into two lines.. 
>
> Then reboot.. 
>
> 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/841ed1c5-27a8-458c-acda-a997e8865a34%40googlegroups.com.

[beagleboard] Re: BBBW first boot - no WiFi/BT

[ags]

More: I tried overriding the dtb in uEnv.txt to force wireless operation 
without reflashing eeprom - this was reported to work in some cases.
How can I tell from the version.sh output if my eeprom is corrupt or 
incorrect for a BBB Wireless?


On Sunday, December 15, 2019 at 11:00:05 PM UTC-8, ags wrote:
>
> I've had a BBBW for 1+ years. Just booted, and can't get WiFi working.
>
> using connmanctl:
>
> connmanctl>  enable wifi
> Error wifi: Method "SetProperty" with signature "sv" on interface 
> "net.connman.Technology" doesn't exist
>
> Researched and saw convo about "corrupt EEPROM"; tried using 
> "dtb=am335x-boneblack-wireless.dtb" in /boot/uEnv.txt - no help
>
> downloaded newer image (4.14.108-ti-r113) to SDcard and booted. Still no 
> wlan0
> BT and WL LEDs are not illuminated
>
> ifconfig -a does not show wlan0
>
> /opt/scripts/tools/version.sh output:
>
> debian@beaglebone:/opt/scripts/tools$ sudo ./version.sh
>
> git:/opt/scripts/:[109f74fb87e6034ae1a8971a244064a8d5e090a5]
>
> ]eprom:[A335BNLTBBWG2331?O
>
> model:[TI_AM335x_BeagleBone_Black]
>
> dogtag:[BeagleBoard.org Debian Image 2019-08-03]
>
> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
> 2019.04-2-gbb4af0f50f]:[location: dd MBR]
>
> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
> 2016.11-rc3-2-g73df7f]:[location: dd MBR]
>
> kernel:[4.14.108-ti-r113]
>
> nodejs:[v6.17.0]
>
> uboot_overlay_options:[enable_uboot_overlays=1]
>
>
> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]
>
> uboot_overlay_options:[enable_uboot_cape_universal=1]
>
> pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
> ]
>
> pkg:[bb-cape-overlays]:[4.4.20190801.0-0rcnee0~stretch+20190801]
>
> pkg:[bb-wl18xx-firmware]:[1.20190227.1-0rcnee0~stretch+20190227]
>
> pkg:[kmod]:[23-2rcnee1~stretch+20171005]
>
> pkg:[librobotcontrol]:[1.0.4-git20190227.1-0rcnee0~stretch+20190327]
>
> pkg:[firmware-ti-connectivity]:[20180825+dfsg-1rcnee1~stretch+20181217]
>
> groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
> plugdev users systemd-journal i2c bluetooth netdev gpio pwm eqep remoteproc 
> admin spi tisdk weston-launch xenomai cloud9ide]
>
> cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
> root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
> net.ifnames=0 rng_core.default_quality=100 quiet]
>
> dmesg | grep remote
>
> [1.221200] remoteproc remoteproc0: wkup_m3 is available
>
> [1.441065] remoteproc remoteproc0: powering up wkup_m3
>
> [1.441181] remoteproc remoteproc0: Booting fw image 
> am335x-pm-firmware.elf, size 217168
>
> [1.445381] remoteproc remoteproc0: remote processor wkup_m3 is now up
>
> [9.891469] remoteproc remoteproc1: 4a334000.pru is available
>
> [9.896369] remoteproc remoteproc2: 4a338000.pru is available
>
> dmesg | grep pru
>
> [9.863842] pruss 4a30.pruss: creating PRU cores and other child 
> platform devices
>
> [9.891469] remoteproc remoteproc1: 4a334000.pru is available
>
> [9.891589] pru-rproc 4a334000.pru: PRU rproc node 
> /ocp/pruss_soc_bus@4a326004/pruss@0/pru@34000 probed successfully
>
> [9.896369] remoteproc remoteproc2: 4a338000.pru is available
>
> [9.896486] pru-rproc 4a338000.pru: PRU rproc node 
> /ocp/pruss_soc_bus@4a326004/pruss@0/pru@38000 probed successfully
>
> dmesg | grep pinctrl-single
>
> [0.930034] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 
> size 568
>
> dmesg | grep gpio-of-helper
>
> [0.942098] gpio-of-helper ocp:cape-universal: ready
>
> lsusb
>
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
> END
>
>
> I'm really stuck.
>

-- 
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/2738b831-a4fe-41b2-9b60-868f4f1fb17c%40googlegroups.com.

[beagleboard] BBBW first boot - no WiFi/BT

[ags]

I've had a BBBW for 1+ years. Just booted, and can't get WiFi working.

using connmanctl:

connmanctl>  enable wifi
Error wifi: Method "SetProperty" with signature "sv" on interface 
"net.connman.Technology" doesn't exist

Researched and saw convo about "corrupt EEPROM"; tried using 
"dtb=am335x-boneblack-wireless.dtb" in /boot/uEnv.txt - no help

downloaded newer image (4.14.108-ti-r113) to SDcard and booted. Still no 
wlan0
BT and WL LEDs are not illuminated

ifconfig -a does not show wlan0

/opt/scripts/tools/version.sh output:

debian@beaglebone:/opt/scripts/tools$ sudo ./version.sh

git:/opt/scripts/:[109f74fb87e6034ae1a8971a244064a8d5e090a5]

]eprom:[A335BNLTBBWG2331?O

model:[TI_AM335x_BeagleBone_Black]

dogtag:[BeagleBoard.org Debian Image 2019-08-03]

bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
2019.04-2-gbb4af0f50f]:[location: dd MBR]

bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2016.11-rc3-2-g73df7f]:[location: dd MBR]

kernel:[4.14.108-ti-r113]

nodejs:[v6.17.0]

uboot_overlay_options:[enable_uboot_overlays=1]

uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]

uboot_overlay_options:[enable_uboot_cape_universal=1]

pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
]

pkg:[bb-cape-overlays]:[4.4.20190801.0-0rcnee0~stretch+20190801]

pkg:[bb-wl18xx-firmware]:[1.20190227.1-0rcnee0~stretch+20190227]

pkg:[kmod]:[23-2rcnee1~stretch+20171005]

pkg:[librobotcontrol]:[1.0.4-git20190227.1-0rcnee0~stretch+20190327]

pkg:[firmware-ti-connectivity]:[20180825+dfsg-1rcnee1~stretch+20181217]

groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
plugdev users systemd-journal i2c bluetooth netdev gpio pwm eqep remoteproc 
admin spi tisdk weston-launch xenomai cloud9ide]

cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
net.ifnames=0 rng_core.default_quality=100 quiet]

dmesg | grep remote

[1.221200] remoteproc remoteproc0: wkup_m3 is available

[1.441065] remoteproc remoteproc0: powering up wkup_m3

[1.441181] remoteproc remoteproc0: Booting fw image 
am335x-pm-firmware.elf, size 217168

[1.445381] remoteproc remoteproc0: remote processor wkup_m3 is now up

[9.891469] remoteproc remoteproc1: 4a334000.pru is available

[9.896369] remoteproc remoteproc2: 4a338000.pru is available

dmesg | grep pru

[9.863842] pruss 4a30.pruss: creating PRU cores and other child 
platform devices

[9.891469] remoteproc remoteproc1: 4a334000.pru is available

[9.891589] pru-rproc 4a334000.pru: PRU rproc node 
/ocp/pruss_soc_bus@4a326004/pruss@0/pru@34000 probed successfully

[9.896369] remoteproc remoteproc2: 4a338000.pru is available

[9.896486] pru-rproc 4a338000.pru: PRU rproc node 
/ocp/pruss_soc_bus@4a326004/pruss@0/pru@38000 probed successfully

dmesg | grep pinctrl-single

[0.930034] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 
568

dmesg | grep gpio-of-helper

[0.942098] gpio-of-helper ocp:cape-universal: ready

lsusb

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

END


I'm really stuck.

-- 
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/5ebb29c5-ec1c-4787-b5b3-83314cbf4ab9%40googlegroups.com.

[beagleboard] Is the XCHG operation broken? unimplemented?

[ags]

I have struggled with the PRU scratchpad, persisting because it seems that 
it could be a very powerful feature. In particular, the XCHG instruction 
(pseudo-op) has caused me hours of frustration to identify and diagnose a 
problem. It seems that XCHG (swapping current PRU register values for those 
in a specified scratchpad bank) does not work - it is effectively an XIN 
op. I researched and found only one bit of content about this, here 
: The 
accepted answer was provided by a (supposed) TI employee. I find it hard to 
believe...

Is it possible that he PASM compiler accepts the XCHG instruction, and all 
the PRU documentation from TI documents this instruction, but it is not 
even implemented? I understand the "PRU is not officially supported" claim.

-- 
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/42441994-13c9-4309-80f3-16b61c2f6e77%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: broke something with wlan when trying to reduce connection drops

[ags]

So are you saying that using the old method of setting MAC address, for the 
initial boot the MAC value was read (from where?) and then incremented 
and/or modified in some way? If every BBB started with the same initial 
value, how did that not end up in collisions? (Clearly I'm 
misunderstanding).

On Monday, April 16, 2018 at 12:48:58 PM UTC-7, RobertCNelson wrote:
>
> On Mon, Apr 16, 2018 at 2:41 PM, ags <alfred.g...@gmail.com > 
> wrote: 
> > @RobertCNelson thanks for that info. IMO it is preferable to use a 
> built-in 
> > (guaranteed unique and immutable??) MAC address so I will stay with the 
> new 
> > method. I've configured my router for the new address anyway. 
>
> So the nice thing about using the built-in wl1835 mac address, on 
> "first" bootup it saves around 30 seconds. 
>
> With the old mac, we'd have to read it, +1/etc to the value, patch the 
> firmware, update the initramfs, then load the module.. 
>
> With the new mac method, the kernel knows how to load it from the 
> wl1835.. (the trick was patching the firmware with a mac of 00:00...00 
> and the kernel knew what to do, it just wasn't documented very well) 
>
> On 2nd/3rd/++ boot no change. 
>
> > 
> > Any insight or ideas where to look on the continued dropped connection 
> > problem? This ... 
> > 
> > $ arp 192.168.1.12 
> > bbbw (192.168.1.12) at (incomplete) on en0 ifscope [ethernet] 
> > 
> > I can't figure out why the arp table entry would expire so quickly. Some 
> > references I found on the subject say the default is 20 minutes. Even if 
> the 
> > entry expires, an ARP packet should be able to quickly reestablish the 
> > IP/MAC binding. 
>
> This might be power-managment related.. 
>
> i'd try: 
>
> sudo iwconfig wlan0 power off 
>
> 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/01d8bc46-29ec-46e5-85ef-0b0dfcc267a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: broke something with wlan when trying to reduce connection drops

[ags]

@RobertCNelson thanks for that info. IMO it is preferable to use a built-in 
(guaranteed unique and immutable??) MAC address so I will stay with the new 
method. I've configured my router for the new address anyway.

Any insight or ideas where to look on the continued dropped connection 
problem? This ...

$ arp 192.168.1.12
bbbw (192.168.1.12) at (incomplete) on en0 ifscope [ethernet]

I can't figure out why the arp table entry would expire so quickly. Some 
references I found on the subject say the default is 20 minutes. Even if 
the entry expires, an ARP packet should be able to quickly reestablish the 
IP/MAC binding.


On Monday, April 16, 2018 at 11:44:41 AM UTC-7, RobertCNelson wrote:
>
> On Mon, Apr 16, 2018 at 1:12 PM, ags <alfred.g...@gmail.com > 
> wrote: 
> > 
> > Update: I realized that the MAC address for wlan0 had changed - didn't 
> > expect that. Will it remain the same until another firmware upgrade? 
>
> Yes the mac address did change (for new installs)..  For old installs 
> with package updates, thru apt there is no change.. 
>
> It turns out the wl1835 has a built-in mac address.. So instead of 
> generating our own unique mac address on first boot-up and using 
> custom one, we use the wl1835 one.. 
>
> You can disable this new mac address via editing: 
>
> /etc/default/bb-wl18xx 
>
> Change: 
>
> USE_INTERNAL_WL18XX_MAC_ADDRESS=yes 
> to 
>
> #USE_INTERNAL_WL18XX_MAC_ADDRESS=yes" 
>
> and reboot and it will return to the old address. 
>
> 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/c2be902b-404c-48af-9cc6-12dbd0976b99%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: broke something with wlan when trying to reduce connection drops

[ags]

Update: I realized that the MAC address for wlan0 had changed - didn't 
expect that. Will it remain the same until another firmware upgrade?

debian@BBB:~$ connmanctl

connmanctl> tether wifi disable

connmanctl> enable wifi

connmanctl> scan wifi

connmanctl> services

connmanctl> agent on

connmanctl> connect 

connmanctl> quit


#are these settings "sticky" or do I need to put them in 
/etc/network/interfaces to persist past a reboot?


and modified router settings with the new wlan0 MAC address. So now I can 
connect...


...but the connection remains unreliable. Once a connection is established, 
if not active (e.g. ssh with command line being used or constant pinging) 
it is dropped. A subsequent ping will fail - but then waiting a few minutes 
and trying again will succeed.


When the connection is up, arp on another machine on the same network 
reports:


$ arp 192.168.1.12

bbbw (192.168.1.12) at  on en0 ifscope [ethernet]


and when down:


$ arp 192.168.1.12

bbbw (192.168.1.12) at (incomplete) on en0 ifscope [ethernet]



-- 
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/76bb6224-0517-4b45-881a-d2e78982%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] broke something with wlan when trying to reduce connection drops

[ags]

I updated wl18xx firmware/packages in an attempt to reduce the high 
frequency of dropped WiFi connections. That didn't go smoothly and I had to 
take a few passes at it.

I now have no (WiFi) connectivity at all. I rebooted after the troublesome 
package upgrade and the wlan0 interface worked - but now it does not, 
despite many subsequent reboots (and days of trying to think what could 
have happened - but no action taken).

The only thing other than the package upgrade that was changed was removing 
some unneeded packages (reported by apt-get) using "*apt-get autoremove*"* - 
*and removal of some packages to free up eMMC space. I didn't document 
this, but my recollection is that the only packages removed were 
chrome-related.

I have been able to access the BBBW using the USB interface for debugging. 
It seems the wlan0 interface is up but not active:


debian@BBB:~$ ifconfig -v wlan0

wlan0 Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx  

  UP BROADCAST MULTICAST DYNAMIC  MTU:1500  Metric:1

  RX packets:0 errors:0 dropped:0 overruns:0 frame:0

  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

  collisions:0 txqueuelen:1000 

  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)


debian@BBB:~$ sudo /opt/scripts/tools/version.sh

...

pkg:[bb-wl18xx-firmware]:[1.20180328-0rcnee2~jessie+20180328]

pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~jessie+20180328]

...


Rather than trying to bind the adapter or manually configure with an IP 
address, I'm looking to understand what has gone wrong to prevent the 
expected auto-configuration and acquisition of a valid IP address (which my 
router is configured to specify as the network DHCP server).


Ideas where to look next?

-- 
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/19f6a612-2259-4951-8ad2-5c7ff4ce47cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB Wireless frequently drops connection

[ags]

looks like I have a lot of partially installed packages...

debian@BBB:/$ apt-get -f install --dry-run

NOTE: This is only a simulation!

  apt-get needs root privileges for real execution.

  Keep also in mind that locking is deactivated,

  so don't depend on the relevance to the real current situation!

Reading package lists... Done

Building dependency tree   

Reading state information... Done

Correcting dependencies... Done

The following packages were automatically installed and are no longer 
required:

  libpci3 libspeechd2

Use 'apt-get autoremove' to remove them.

The following extra packages will be installed:

  chromium-browser

Suggested packages:

  webaccounts-chromium-extension unity-chromium-extension adobe-flashplugin

The following packages will be upgraded:

  chromium-browser

1 upgraded, 0 newly installed, 0 to remove and 84 not upgraded.

133 not fully installed or removed.

Inst chromium-browser [53.0.2785.143-0ubuntu1.1307~bpo80+20161016+1] 
(59.0.3071.109-0ubuntu0.16.04.1289rcnee0~jessie+20170705 
rcn-ee.net:repos.rcn-ee.com [armhf])

Conf libssl1.0.0 (1.0.1t-1+deb8u7 Debian:8.10/oldstable, 
Debian-Security:8/oldstable [armhf])

Conf openssl (1.0.1t-1+deb8u7 Debian:8.10/oldstable, 
Debian-Security:8/oldstable [armhf])

Conf ca-certificates (20141019+deb8u3 Debian:8.10/oldstable [all])

Conf nodejs (6.14.0-1nodesource1 Node Source:deb.nodesource.com [armhf])

Conf libapt-inst1.5 (1.0.9.8.4 Debian:8.10/oldstable, 
Debian-Security:8/oldstable [armhf])

Conf libncursesw5 (5.9+20140913-1+deb8u2 Debian:8.10/oldstable [armhf])

Conf libevent-2.0-5 (2.0.21-stable-2+deb8u1 Debian:8.10/oldstable, 
Debian-Security:8/oldstable [armhf])

Conf libnettle4 (2.7.1-5+deb8u2 Debian:8.10/oldstable [armhf])

Conf libhogweed2 (2.7.1-5+deb8u2 Debian:8.10/oldstable [armhf])

Conf libtasn1-6 (4.2-3+deb8u3 Debian:8.10/oldstable, 
Debian-Security:8/oldstable [armhf])

Conf libgnutls-deb0-28 (3.3.8-6+deb8u7 Debian:8.10/oldstable [armhf])

Conf libgnutls-openssl27 (3.3.8-6+deb8u7 Debian:8.10/oldstable [armhf])

Conf libkrb5support0 (1.12.1+dfsg-19+deb8u4 Debian:8.10/oldstable [armhf])

Conf libk5crypto3 (1.12.1+dfsg-19+deb8u4 Debian:8.10/oldstable [armhf])

Conf libkrb5-3 (1.12.1+dfsg-19+deb8u4 Debian:8.10/oldstable [armhf])

Conf libgssapi-krb5-2 (1.12.1+dfsg-19+deb8u4 Debian:8.10/oldstable [armhf])

Conf libldap-2.4-2 (2.4.40+dfsg-1+deb8u3 Debian:8.10/oldstable, 
Debian-Security:8/oldstable [armhf])

Conf libmagic1 (1:5.22+15-2+deb8u3 Debian:8.10/oldstable [armhf])

Conf libxml2 (2.9.1+dfsg1-5+deb8u6 Debian-Security:8/oldstable [armhf])

Conf perl-modules (5.20.2-3+deb8u9 Debian:8.10/oldstable, 
Debian-Security:8/oldstable [all])

Conf perl (5.20.2-3+deb8u9 Debian:8.10/oldstable, 
Debian-Security:8/oldstable [armhf])

Conf apache2-bin (2.4.10-10+deb8u11 Debian:8.10/oldstable, 
Debian-Security:8/oldstable [armhf])

Conf apache2-utils (2.4.10-10+deb8u11 Debian:8.10/oldstable, 
Debian-Security:8/oldstable [armhf])

Conf apache2-data (2.4.10-10+deb8u11 Debian:8.10/oldstable, 
Debian-Security:8/oldstable [all])

Conf apache2 (2.4.10-10+deb8u11 Debian:8.10/oldstable, 
Debian-Security:8/oldstable [armhf])

Conf libatomic1 (4.9.2-10+deb8u1 Debian-Security:8/oldstable [armhf])

Conf libpng12-0 (1.2.50-2+deb8u3 Debian:8.10/oldstable [armhf])

Conf libfreetype6 (2.5.2-3+deb8u2 Debian:8.10/oldstable, 
Debian-Security:8/oldstable [armhf])

Conf libx11-data (2:1.6.2-3+deb8u1 Debian:8.10/oldstable [all])

Conf libx11-6 (2:1.6.2-3+deb8u1 Debian:8.10/oldstable [armhf])

Conf libcairo2 (1.14.0-2.1+deb8u2 Debian:8.10/oldstable [armhf])

Conf libcups2 (1.7.5-11+deb8u2 Debian:8.10/oldstable [armhf])

Conf libdbus-1-3 (1.8.22-0+deb8u1 Debian:8.10/oldstable [armhf])

Conf libexpat1 (2.1.0-6+deb8u4 Debian:8.10/oldstable, 
Debian-Security:8/oldstable [armhf])

Conf libgdk-pixbuf2.0-common (2.31.1-2+deb8u7 Debian-Security:8/oldstable 
[all])

Conf libjasper1 (1.900.1-debian1-2.4+deb8u3 Debian:8.10/oldstable, 
Debian-Security:8/oldstable [armhf])

Conf libtiff5 (4.0.3-12.3+deb8u5 Debian-Security:8/oldstable [armhf])

Conf libgdk-pixbuf2.0-0 (2.31.1-2+deb8u7 Debian-Security:8/oldstable 
[armhf])

Conf libnss3 (2:3.26-1+debu8u3 Debian:8.10/oldstable, 
Debian-Security:8/oldstable [armhf])

Conf libx11-xcb1 (2:1.6.2-3+deb8u1 Debian:8.10/oldstable [armhf])

Conf libxfixes3 (1:5.0.1-2+deb8u1 Debian:8.10/oldstable [armhf])

Conf libxcursor1 (1:1.1.14-1+deb8u1 Debian-Security:8/oldstable [armhf])

Conf libxi6 (2:1.7.4-1+deb8u1 Debian:8.10/oldstable [armhf])

Conf libxrandr2 (2:1.4.2-1+deb8u1 Debian:8.10/oldstable [armhf])

Conf libxtst6 (2:1.2.2-1+deb8u1 Debian:8.10/oldstable [armhf])

Conf chromium-codecs-ffmpeg-extra 
(59.0.3071.109-0ubuntu0.16.04.1289rcnee0~jessie+20170705 
rcn-ee.net:repos.rcn-ee.com [armhf])

Conf chromium-browser 
(59.0.3071.109-0ubuntu0.16.04.1289rcnee0~jessie+20170705 
rcn-ee.net:repos.rcn-ee.com [armhf])

Conf chromium-browser-l10n 
(59.0.3071.109-0ubuntu0.16.04.1289rcnee0~jessie+20170705 

Re: [beagleboard] BBB Wireless frequently drops connection

[ags]

I've cleaned the package cache:

sudo apt-get clean

and recovered ~400MB "disk" space.

debian@BBB:/$ sudo apt install firmware-ti-connectivity

Reading package lists... Done

Building dependency tree   

Reading state information... Done

You might want to run 'apt-get -f install' to correct these:

The following packages have unmet dependencies:

 chromium-browser : Depends: chromium-codecs-ffmpeg-extra (= 
53.0.2785.143-0ubuntu1.1307~bpo80+20161016+1) but 
59.0.3071.109-0ubuntu0.16.04.1289rcnee0~jessie+20170705 is to be installed 
or

 chromium-codecs-ffmpeg (= 
53.0.2785.143-0ubuntu1.1307~bpo80+20161016+1) but it is not going to be 
installed

 chromium-browser-l10n : Depends: chromium-browser (>= 
59.0.3071.109-0ubuntu0.16.04.1289rcnee0~jessie+20170705) but 
53.0.2785.143-0ubuntu1.1307~bpo80+20161016+1 is to be installed

E: Unmet dependencies. Try 'apt-get -f install' with no packages (or 
specify a solution).

and of course then this fails without firmware-ti-connectivity installed...

debian@BBB:/$ apt install --only-upgrade --dry-run bb-wl18xx-firmware

NOTE: This is only a simulation!

  apt-get needs root privileges for real execution.

  Keep also in mind that locking is deactivated,

  so don't depend on the relevance to the real current situation!

Reading package lists... Done

Building dependency tree   

Reading state information... Done

You might want to run 'apt-get -f install' to correct these:

The following packages have unmet dependencies:

 bb-wl18xx-firmware : Depends: firmware-ti-connectivity but it is not going 
to be installed

 chromium-browser : Depends: chromium-codecs-ffmpeg-extra (= 
53.0.2785.143-0ubuntu1.1307~bpo80+20161016+1) but 
59.0.3071.109-0ubuntu0.16.04.1289rcnee0~jessie+20170705 is to be installed 
or

 chromium-codecs-ffmpeg (= 
53.0.2785.143-0ubuntu1.1307~bpo80+20161016+1) but it is not going to be 
installed

 chromium-browser-l10n : Depends: chromium-browser (>= 
59.0.3071.109-0ubuntu0.16.04.1289rcnee0~jessie+20170705) but 
53.0.2785.143-0ubuntu1.1307~bpo80+20161016+1 is to be installed

E: Unmet dependencies. Try 'apt-get -f install' with no packages (or 
specify a solution).

I don't see how chromium (et cetera) is related. Is this a side-effect from 
my mistake in the previous (huge, aborted) upgrade run?

Suggestions on how to *just* upgrade what I need for improved wireless 
connectivity (this OP)?


On Wednesday, March 28, 2018 at 3:51:13 PM UTC-7, ags wrote:
>
> More specifics: I see lots of stuff (~450MiB) in /var/cache/apt/archives. 
> Only two are dated today. One is bb-wl18xx-firmware...
>
> Do I "sudo apt-get clean", or delete everything manually from the 
> apt/archive (except bb-wl18xx-firmware...) or something else?
>
>
>
> On Wednesday, March 28, 2018 at 3:42:01 PM UTC-7, ags wrote:
>>
>> This is turning into an "apt" tutorial - but searches haven't helped me 
>> find what I'm looking for.
>>
>> I have killed the upgrade mis-stream. I think it successfully downloaded 
>> all the upgradable packages, and ran out of "disk" space while unpacking 
>> it. I don't know if anything was actually installed.
>>
>> I still have 0% free on /dev/mmcblkXX
>>
>> Is there a way to determine if any package was actually upgraded?
>>
>> Where are the downloaded packages? Can I just delete them presuming they 
>> were the unintended upgrades, and start again with the correct apt command 
>> as you provided in a later post
>>
>>
>> On Wednesday, March 28, 2018 at 2:44:06 PM UTC-7, RobertCNelson wrote:
>>>
>>> On Wed, Mar 28, 2018 at 4:34 PM, ags <alfred.g...@gmail.com> wrote: 
>>> > Sorry if this is obvious. The current situation is that I have no 
>>> "disk" 
>>> > space left and the upgrade is paused (^Z) after fetching 464 MB. I 
>>> have 
>>> > minimal user-installed "stuff" on the system so it appears to have 
>>> been 
>>> > filled up with this upgrade attempt. 
>>> > 
>>> > I thought I would be installing the "firmware-ti-connectivity" package 
>>> (for 
>>> > the first time) and upgrading the "bb-wl18xx-firmware" package to a 
>>> newer 
>>> > version. The former seemed OK, but the latter (apparently) pulled in 
>>> another 
>>> > 200+ packages. Did I do that incorrectly? 
>>>
>>> Yeah i messed that up, it's "install --only-upgrade" 
>>>
>>> sudo apt install --only-upgrade bb-wl18xx-firmware 
>>> firmware-ti-connectivity 
>>>
>>> > 
>>> > Am I to "apt remove  --purge" each of

Re: [beagleboard] BBB Wireless frequently drops connection

[ags]

More specifics: I see lots of stuff (~450MiB) in /var/cache/apt/archives. 
Only two are dated today. One is bb-wl18xx-firmware...

Do I "sudo apt-get clean", or delete everything manually from the 
apt/archive (except bb-wl18xx-firmware...) or something else?



On Wednesday, March 28, 2018 at 3:42:01 PM UTC-7, ags wrote:
>
> This is turning into an "apt" tutorial - but searches haven't helped me 
> find what I'm looking for.
>
> I have killed the upgrade mis-stream. I think it successfully downloaded 
> all the upgradable packages, and ran out of "disk" space while unpacking 
> it. I don't know if anything was actually installed.
>
> I still have 0% free on /dev/mmcblkXX
>
> Is there a way to determine if any package was actually upgraded?
>
> Where are the downloaded packages? Can I just delete them presuming they 
> were the unintended upgrades, and start again with the correct apt command 
> as you provided in a later post
>
>
> On Wednesday, March 28, 2018 at 2:44:06 PM UTC-7, RobertCNelson wrote:
>>
>> On Wed, Mar 28, 2018 at 4:34 PM, ags <alfred.g...@gmail.com> wrote: 
>> > Sorry if this is obvious. The current situation is that I have no 
>> "disk" 
>> > space left and the upgrade is paused (^Z) after fetching 464 MB. I have 
>> > minimal user-installed "stuff" on the system so it appears to have been 
>> > filled up with this upgrade attempt. 
>> > 
>> > I thought I would be installing the "firmware-ti-connectivity" package 
>> (for 
>> > the first time) and upgrading the "bb-wl18xx-firmware" package to a 
>> newer 
>> > version. The former seemed OK, but the latter (apparently) pulled in 
>> another 
>> > 200+ packages. Did I do that incorrectly? 
>>
>> Yeah i messed that up, it's "install --only-upgrade" 
>>
>> sudo apt install --only-upgrade bb-wl18xx-firmware 
>> firmware-ti-connectivity 
>>
>> > 
>> > Am I to "apt remove  --purge" each of the 200+ packages that were 
>> > (apparently) pulled in? 
>>
>> no, many are just updates to pkgs you already have installed.. 
>>
>> > 
>> > Still, how do I perform the upgrade to get the possible fix for my 
>> > connectivity problem within available disk space? (is it impossible?) 
>>
>> i'd kill the upgrade process and do the above 
>>
>> 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/5e6fc98b-2ae8-4e21-bc60-a9fc2a608bed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB Wireless frequently drops connection

[ags]

This is turning into an "apt" tutorial - but searches haven't helped me 
find what I'm looking for.

I have killed the upgrade mis-stream. I think it successfully downloaded 
all the upgradable packages, and ran out of "disk" space while unpacking 
it. I don't know if anything was actually installed.

I still have 0% free on /dev/mmcblkXX

Is there a way to determine if any package was actually upgraded?

Where are the downloaded packages? Can I just delete them presuming they 
were the unintended upgrades, and start again with the correct apt command 
as you provided in a later post


On Wednesday, March 28, 2018 at 2:44:06 PM UTC-7, RobertCNelson wrote:
>
> On Wed, Mar 28, 2018 at 4:34 PM, ags <alfred.g...@gmail.com > 
> wrote: 
> > Sorry if this is obvious. The current situation is that I have no "disk" 
> > space left and the upgrade is paused (^Z) after fetching 464 MB. I have 
> > minimal user-installed "stuff" on the system so it appears to have been 
> > filled up with this upgrade attempt. 
> > 
> > I thought I would be installing the "firmware-ti-connectivity" package 
> (for 
> > the first time) and upgrading the "bb-wl18xx-firmware" package to a 
> newer 
> > version. The former seemed OK, but the latter (apparently) pulled in 
> another 
> > 200+ packages. Did I do that incorrectly? 
>
> Yeah i messed that up, it's "install --only-upgrade" 
>
> sudo apt install --only-upgrade bb-wl18xx-firmware 
> firmware-ti-connectivity 
>
> > 
> > Am I to "apt remove  --purge" each of the 200+ packages that were 
> > (apparently) pulled in? 
>
> no, many are just updates to pkgs you already have installed.. 
>
> > 
> > Still, how do I perform the upgrade to get the possible fix for my 
> > connectivity problem within available disk space? (is it impossible?) 
>
> i'd kill the upgrade process and do the above 
>
> 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/88af7cbb-cebe-408e-993c-213eda6dcc44%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB Wireless frequently drops connection

[ags]

Sorry if this is obvious. The current situation is that I have no "disk" 
space left and the upgrade is paused (^Z) after fetching 464 MB. I have 
minimal user-installed "stuff" on the system so it appears to have been 
filled up with this upgrade attempt.

I thought I would be installing the "firmware-ti-connectivity" package (for 
the first time) and upgrading the "bb-wl18xx-firmware" package to a newer 
version. The former seemed OK, but the latter (apparently) pulled in 
another 200+ packages. Did I do that incorrectly?

Am I to "apt remove  --purge" each of the 200+ packages that were 
(apparently) pulled in?

Still, how do I perform the upgrade to get the possible fix for my 
connectivity problem within available disk space? (is it impossible?)


On Wednesday, March 28, 2018 at 2:19:40 PM UTC-7, RobertCNelson wrote:
>
> On Wed, Mar 28, 2018 at 4:13 PM, ags <alfred.g...@gmail.com > 
> wrote: 
> > I realize there is not an explicit question here... 
> > 
> > I have paused (^Z) the upgrade. Can I terminate and reclaim the disk 
> space, 
> > or is there another option? 
> > 
> > Does the desired package upgrade really require 400+MB of dependencies 
> to 
> > also be upgraded? The output looks like all possible upgrades were being 
> > done. 
>
> Yes, you can recover most of the space 'afterwards'.. 
>
> and use 
>
> sudo apt remove (pkg) --purge 
>
> to cleanup anything you don't use.. 
>
> 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/fd6a0b34-2c71-4e18-9258-97fbc6b3444b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB Wireless frequently drops connection

[ags]

I realize there is not an explicit question here...

I have paused (^Z) the upgrade. Can I terminate and reclaim the disk space, 
or is there another option?

Does the desired package upgrade really require 400+MB of dependencies to 
also be upgraded? The output looks like all possible upgrades were being 
done.

On Wednesday, March 28, 2018 at 1:28:18 PM UTC-7, ags wrote:
>
> Uh oh...
>
> debian@BBB:~$ sudo apt upgrade bb-wl18xx-firmware firmware-ti-connectivity
>
> Reading package lists... Done
>
> Building dependency tree   
>
> Reading state information... Done
>
> Calculating upgrade... The following packages were automatically installed 
> and are no longer required:
>
>   libpci3 libspeechd2
>
> Use 'apt-get autoremove' to remove them.
>
> Done
>
> The following NEW packages will be installed:
>
>   firmware-ti-connectivity libdrm-common
>
> The following packages will be upgraded:
>
>   apache2 apache2-bin apache2-data apache2-utils apt apt-transport-https 
> apt-utils base-files bash
>
>   bb-customizations bb-node-red-installer bb-wl18xx-firmware bind9-host 
> binutils bluetooth bluez...
>
>
> [... and 200+ more]
>
>
>   ...xserver-xorg-video-omap
>
> 242 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
>
> Need to get 464 MB of archives.
>
> After this operation, 102 MB of additional disk space will be used.
>
> Do you want to continue? [Y/n] Y
>
>
> Foolishly I accepted - and now I have 0% space available on my eMMC.
>
> I don't know how to undo this, nor if I will be able to restart without 
> remediating this.
>
>
>
>
> On Wednesday, March 28, 2018 at 8:07:55 AM UTC-7, RobertCNelson wrote:
>>
>> On Wed, Mar 28, 2018 at 9:40 AM, ags <alfred.g...@gmail.com> wrote: 
>> > git:/opt/scripts/:[9d965a5f40ae00774c81164f87a450a678ab79f6] 
>> > 
>> > eeprom:[A335BNLTBWA51650BBWG0378] 
>> > 
>> > model:[TI_AM335x_BeagleBone_Black_Wireless] 
>> > 
>> > dogtag:[BeagleBoard.org Debian Image 2016-11-06] 
>> > 
>> > bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
>> > 2018.03-2-g254339602c]:[location: dd MBR] 
>> > 
>> > kernel:[4.4.113-ti-r148] 
>>
>> > pkg:[bb-wl18xx-firmware]:[1.20161020-0rcnee1~bpo80+20161020+1] 
>> > WARNING:pkg:[firmware-ti-connectivity]:[NOT_INSTALLED] 
>>
>> That's ^ a hint for one of the reason of random dropouts... 
>>
>> sudo apt update 
>> sudo apt upgrade bb-wl18xx-firmware firmware-ti-connectivity 
>>
>> 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/8b38d40b-ffb1-4846-841a-ed240bdd6742%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB Wireless frequently drops connection

[ags]

Uh oh...

debian@BBB:~$ sudo apt upgrade bb-wl18xx-firmware firmware-ti-connectivity

Reading package lists... Done

Building dependency tree   

Reading state information... Done

Calculating upgrade... The following packages were automatically installed 
and are no longer required:

  libpci3 libspeechd2

Use 'apt-get autoremove' to remove them.

Done

The following NEW packages will be installed:

  firmware-ti-connectivity libdrm-common

The following packages will be upgraded:

  apache2 apache2-bin apache2-data apache2-utils apt apt-transport-https 
apt-utils base-files bash

  bb-customizations bb-node-red-installer bb-wl18xx-firmware bind9-host 
binutils bluetooth bluez...


[... and 200+ more]


  ...xserver-xorg-video-omap

242 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.

Need to get 464 MB of archives.

After this operation, 102 MB of additional disk space will be used.

Do you want to continue? [Y/n] Y


Foolishly I accepted - and now I have 0% space available on my eMMC.

I don't know how to undo this, nor if I will be able to restart without 
remediating this.




On Wednesday, March 28, 2018 at 8:07:55 AM UTC-7, RobertCNelson wrote:
>
> On Wed, Mar 28, 2018 at 9:40 AM, ags <alfred.g...@gmail.com > 
> wrote: 
> > git:/opt/scripts/:[9d965a5f40ae00774c81164f87a450a678ab79f6] 
> > 
> > eeprom:[A335BNLTBWA51650BBWG0378] 
> > 
> > model:[TI_AM335x_BeagleBone_Black_Wireless] 
> > 
> > dogtag:[BeagleBoard.org Debian Image 2016-11-06] 
> > 
> > bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
> > 2018.03-2-g254339602c]:[location: dd MBR] 
> > 
> > kernel:[4.4.113-ti-r148] 
>
> > pkg:[bb-wl18xx-firmware]:[1.20161020-0rcnee1~bpo80+20161020+1] 
> > WARNING:pkg:[firmware-ti-connectivity]:[NOT_INSTALLED] 
>
> That's ^ a hint for one of the reason of random dropouts... 
>
> sudo apt update 
> sudo apt upgrade bb-wl18xx-firmware firmware-ti-connectivity 
>
> 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/d4da5b88-3b44-4674-87dc-b4698530f9e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB Wireless frequently drops connection

[ags]

 

git:/opt/scripts/:[9d965a5f40ae00774c81164f87a450a678ab79f6]

eeprom:[A335BNLTBWA51650BBWG0378]

model:[TI_AM335x_BeagleBone_Black_Wireless]

dogtag:[BeagleBoard.org Debian Image 2016-11-06]

bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2018.03-2-g254339602c]:[location: dd MBR]

kernel:[4.4.113-ti-r148]

nodejs:[v6.12.2]

uboot_overlay_options:[enable_uboot_overlays=1]

uboot_overlay_options:[disable_uboot_overlay_audio=1]

uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]

uboot_overlay_options:[enable_uboot_cape_universal=1]

pkg:[bb-cape-overlays]:[4.4.20180322.0-0rcnee0~jessie+20180322]

pkg:[bb-wl18xx-firmware]:[1.20161020-0rcnee1~bpo80+20161020+1]

WARNING:pkg:[firmware-ti-connectivity]:[NOT_INSTALLED]

groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
plugdev users systemd-journal netdev i2c admin spi tisdk weston-launch 
xenomai]

cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
root=UUID=ac4731db-c4db-463f-9129-07e6746b98ba ro rootfstype=ext4 rootwait 
coherent_pool=1M quiet]

dmesg | grep pinctrl-single

[1.213389] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 
568

dmesg | grep gpio-of-helper

[1.214406] gpio-of-helper ocp:cape-universal: Allocated GPIO id=0

[1.214632] gpio-of-helper ocp:cape-universal: Allocated GPIO id=1

[1.214800] gpio-of-helper ocp:cape-universal: Allocated GPIO id=2

[1.214945] gpio-of-helper ocp:cape-universal: Allocated GPIO id=3

[1.215094] gpio-of-helper ocp:cape-universal: Allocated GPIO id=4

[1.215487] gpio-of-helper ocp:cape-universal: Allocated GPIO id=5

[1.215648] gpio-of-helper ocp:cape-universal: Allocated GPIO id=6

[1.215793] gpio-of-helper ocp:cape-universal: Allocated GPIO id=7

[1.215947] gpio-of-helper ocp:cape-universal: Allocated GPIO id=8

[1.216094] gpio-of-helper ocp:cape-universal: Allocated GPIO id=9

[1.216249] gpio-of-helper ocp:cape-universal: Allocated GPIO id=10

[1.216393] gpio-of-helper ocp:cape-universal: Allocated GPIO id=11

[1.216585] gpio-of-helper ocp:cape-universal: Allocated GPIO id=12

[1.216738] gpio-of-helper ocp:cape-universal: Allocated GPIO id=13

[1.216878] gpio-of-helper ocp:cape-universal: Allocated GPIO id=14

[1.217004] gpio-of-helper ocp:cape-universal: Allocated GPIO id=15

[1.217147] gpio-of-helper ocp:cape-universal: Allocated GPIO id=16

[1.217280] gpio-of-helper ocp:cape-universal: Allocated GPIO id=17

[1.217436] gpio-of-helper ocp:cape-universal: Allocated GPIO id=18

[1.217567] gpio-of-helper ocp:cape-universal: Allocated GPIO id=19

[1.217702] gpio-of-helper ocp:cape-universal: Allocated GPIO id=20

[1.217839] gpio-of-helper ocp:cape-universal: Allocated GPIO id=21

[1.217970] gpio-of-helper ocp:cape-universal: Allocated GPIO id=22

[1.218102] gpio-of-helper ocp:cape-universal: Allocated GPIO id=23

[1.218240] gpio-of-helper ocp:cape-universal: Allocated GPIO id=24

[1.218415] gpio-of-helper ocp:cape-universal: Allocated GPIO id=25

[1.218564] gpio-of-helper ocp:cape-universal: Allocated GPIO id=26

[1.218701] gpio-of-helper ocp:cape-universal: Allocated GPIO id=27

[1.218835] gpio-of-helper ocp:cape-universal: Allocated GPIO id=28

[1.218976] gpio-of-helper ocp:cape-universal: Allocated GPIO id=29

[1.219113] gpio-of-helper ocp:cape-universal: Allocated GPIO id=30

[1.219610] gpio-of-helper ocp:cape-universal: Allocated GPIO id=31

[1.219786] gpio-of-helper ocp:cape-universal: Allocated GPIO id=32

[1.219928] gpio-of-helper ocp:cape-universal: Allocated GPIO id=33

[1.220076] gpio-of-helper ocp:cape-universal: Allocated GPIO id=34

[1.220212] gpio-of-helper ocp:cape-universal: Allocated GPIO id=35

[1.220350] gpio-of-helper ocp:cape-universal: Allocated GPIO id=36

[1.220498] gpio-of-helper ocp:cape-universal: Allocated GPIO id=37

[1.220639] gpio-of-helper ocp:cape-universal: Allocated GPIO id=38

[1.220650] gpio-of-helper ocp:cape-universal: ready

END

On Tuesday, March 27, 2018 at 5:06:29 PM UTC-7, RobertCNelson wrote:
>
> On Tue, Mar 27, 2018 at 5:22 PM, ags <alfred.g...@gmail.com > 
> wrote: 
> > I’m experiencing random drops of wirelesss connectivity with BBBW. I 
> have several other wired & wireless SBCs BBB, RPi, etc. and don’t see this 
> with them. This is my only BBBW though. I believe I’ve experienced it since 
> first installing - but am not certain. 
> > 
> > Symptoms are simply not being able to connect (with ssh or other means) 
> or having an open ssh session terminated. Sometimes I can re-establish 
> immediately, sometimes I let ping run for dozens of packets and it is 
> eventually found back online, and sometimes I have to power-cycle to 
> (re)gain access. When inaccessible the power and heartbeat leds are 
> indicating normal operation. 
> > 
> > Is th

[beagleboard] BBB Wireless frequently drops connection

[ags]

I’m experiencing random drops of wirelesss connectivity with BBBW. I have 
several other wired & wireless SBCs BBB, RPi, etc. and don’t see this with 
them. This is my only BBBW though. I believe I’ve experienced it since first 
installing - but am not certain. 

Symptoms are simply not being able to connect (with ssh or other means) or 
having an open ssh session terminated. Sometimes I can re-establish 
immediately, sometimes I let ping run for dozens of packets and it is 
eventually found back online, and sometimes I have to power-cycle to (re)gain 
access. When inaccessible the power and heartbeat leds are indicating normal 
operation. 

Is this a known issue? Is there a fix?

Running 4.4.11x ti 

-- 
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/7f32da93-1ce3-47aa-a870-c1d172af658d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Followed instructions to update to sync config-pin & overlays - now even worse...

[ags]

I've confirmed that all desired functionality with PRU and IOs is restored, 
with full access to all the exposed PRU0 (output) pins. Thanks for the help.

I revisited the elinux.org BB pages, and understand what is being described 
there (for the most part) -- but not why. Is there a group/list/forum where 
the discussion and decisions leading to u-boot overlays (replacing the "old 
way") is available? Here's what I'm trying to understand:

What is benefit of u-boot overlays over the "old way"? Is it that custom 
capes can be specified for loading by u-boot, rather than the script 
workaround that is referred to in the elinux:BB page?

For "non-custom" overlays, how is it different (other than syntax) to 
enable u-boot overlays and then provide directives to enable/disable as 
u-boot overlays -- compared to using the previous capemgr.enable_partno=XXX 
method?

With u-boot overlays, is it still possible to specify the dtb (not overlay) 
that is loaded, rather than what is auto-detected?

The biggest confusion I have is with the overarching strategy: my 
understanding is that DeviceTree exists specifically to avoid a multitude 
of board files and other junk compiled into the kernel for each platform 
derivative. It's been a challenge but I can appreciate the vision and value 
once there. This was done by creating a way to specify the specific 
hardware configuration in a data model (and provide parameters to more 
generic drivers in the kernel to make it all work). IIUC, doesn't building 
capes (by way of overlays) into u-boot go against that concept? Building a 
new u-boot to add an overlay is easier than adding to the kernel (and not 
polluting mainline). But why not have u-boot look in a designated location 
for a specified overlay which it knows nothing about, only to load it? 
[realizing that I may have just "just..." discounted a huge technical 
problem in the way this question is formed - not intentionally, but from 
lack of more detailed understanding of how the pieces all fit together]



On Friday, March 23, 2018 at 6:12:11 PM UTC-7, RobertCNelson wrote:
>
> On Fri, Mar 23, 2018 at 7:59 PM, ags <alfred.g...@gmail.com > 
> wrote: 
> > That *seems* to have fixed it. Will need to run a test to be sure. It 
> does 
> > allow me to configure the audio pin as pruout, and I do see gpio entries 
> and 
> > the uio events in sysfs. 
> > 
> > I was wondering if it was the old U-Boot - I presume the old one doesn't 
> > understand uboot overlays?? 
>
> That is correct.. 
>
> > 
> > (was I correct to remove "cape_universal=enable" from the kernel command 
> > line entry in uEnv.txt (or does it not matter once uboot overlays are 
> > enabled?) 
>
> it'll actually get ignored... 
>
> > 
> > The syntax of the directives I added to uEnv.txt look (to me) like they 
> are 
> > hard-coded into u-boot -- is that correct? That is, rather than generic 
> > directives that look like: 
> > 
> > enable_uboot_overlay= 
> > enable_uboot_overlay= 
> > disable_uboot_overlay= 
> > 
> > we now have: 
> > 
> > enable_uboot_overlays=1# OK, that seems generic... tell 
> > u-boot to handle overlays 
> > 
> > disable_uboot_overlay_audio=1 .#  "audio" is hardcoded in the 
> directive 
> > itself 
>
> onboard devices: 
>
>
> https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Disable_on-board_devices
>  
>
> (these change cape-universal)... 
>
> > uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo # 
> u-boot 
> > even knows about prus? 
>
> pru is special: 
>
> https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_PRU_Options 
>
> > enable_uboot_cape_universal=1 
> > # ... and cape_universal? 
>
> Correct, although i'm working on a project to have that auto-enabled.. 
>
> 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/77780e48-089a-4bb6-b883-ee95a589fe8d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Followed instructions to update to sync config-pin & overlays - now even worse...

[ags]

That *seems* to have fixed it. Will need to run a test to be sure. It does 
allow me to configure the audio pin as pruout, and I do see gpio entries 
and the uio events in sysfs.

I was wondering if it was the old U-Boot - I presume the old one doesn't 
understand uboot overlays??

(was I correct to remove "cape_universal=enable" from the kernel command 
line entry in uEnv.txt (or does it not matter once uboot overlays are 
enabled?)

The syntax of the directives I added to uEnv.txt look (to me) like they are 
hard-coded into u-boot -- is that correct? That is, rather than generic 
directives that look like:

enable_uboot_overlay=
enable_uboot_overlay=
disable_uboot_overlay=

we now have:

enable_uboot_overlays=1# OK, that seems generic... tell 
u-boot to handle overlays

disable_uboot_overlay_audio=1 .#  "audio" is hardcoded in the directive 
itself

uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo # u-boot 
even knows about prus?

enable_uboot_cape_universal=1  
   # ... and cape_universal?



Thank you for the response.


On Friday, March 23, 2018 at 3:44:56 PM UTC-7, ags wrote:
>
> I gave up trying to figure out how to get config-pins, overlays, uboot, 
> etc all in-sync to allow access to all the available pru pins, so I 
> followed previous instructions to update.
>
> What I did:
>
> debian@BBBWl:~$ cd /opt/scripts/tools
> debian@BBBWl:~$ sudo ./update_kernel.sh
>
> edited /boot/uEnv.txt to include:
>
> enable_uboot_overlays=1
>
> disable_uboot_overlay_audio=1
>
> uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
>
> enable_uboot_cape_universal=1
>
>
> and changed this:
>
>
> cmdline=coherent_pool=1M quiet cape_universal=enable
>
>
> to this:
>
>
> cmdline=coherent_pool=1M quiet
>
>
> rebooted and...
>
>
> Last login: Fri Mar 23 22:01:29 2018 from 10.8.0.6
>
> debian@BBBWl:~$ uname -r
>
> 4.4.113-ti-r148
>
> debian@BBBWl:~$ config-pin -l p9.25
>
> default gpio gpio_pu gpio_pd qep pruout pruin
>
> debian@BBBWl:~$ config-pin p9.25 pruout
>
> P9_25 pinmux file not found!
>
> cape-universala overlay not found
>
> run "config-pin overlay cape-universala" to load the cape
>
> checked to see if the bb-cape-overlays had been updated and saw a newer 
> version so installed that:
>
> debian@BBBWl:~$ apt show bb-cape-overlays
>
> Package: bb-cape-overlays
>
> Version: 4.4.20180322.0-0rcnee0~jessie+20180322
>
> Maintainer: Robert Nelson <robertcnel...@gmail.com>
>
> Installed-Size: 2,289 kB
>
> Priority: extra
>
> Section: misc
>
> Download-Size: 66.7 kB
>
> APT-Sources: http://repos.rcn-ee.com/debian/ jessie/main armhf Packages
>
> Description: Device tree overlays for Beaglebone.
>
>  Device tree overlays for Beaglebone /lib/firmware/
>
>
> rebooted and same problem.
>
> I then looked to see if the uio_pruss driver had been installed...
>
>
> debian@BBBWl:/opt/scripts/tools$ ls /sys/class/uio
>
> debian@BBBWl:/opt/scripts/tools$
>
>
> Bad.
>
>
> debian@BBBWl:/opt/scripts/tools$ ls /sys/class/gpio
>
> export  *gpio12*  *gpio13*  *gpiochip0*  *gpiochip32*  *gpiochip64*  
> *gpiochip96*  unexport
>
>
> Worse.
>
>
> So now I have no uio_pruss driver, and just two gpio pins.
>
> Info:
>
>
> debian@BBBWl:/opt/scripts/tools$ sudo ./version.sh 
>
> git:/opt/scripts/:[9d965a5f40ae00774c81164f87a450a678ab79f6]
>
> eeprom:[A335BNLTBWA51650BBWG0378]
>
> model:[TI_AM335x_BeagleBone_Black_Wireless]
>
> dogtag:[BeagleBoard.org Debian Image 2016-11-06]
>
> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
> 2016.11-rc3-2-g73df7f]:[location: dd MBR]
>
> kernel:[4.4.113-ti-r148]
>
> nodejs:[v6.12.2]
>
> uboot_overlay_options:[enable_uboot_overlays=1]
>
> uboot_overlay_options:[disable_uboot_overlay_audio=1]
>
>
> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]
>
> uboot_overlay_options:[enable_uboot_cape_universal=1]
>
> pkg:[bb-cape-overlays]:[4.4.20180322.0-0rcnee0~jessie+20180322]
>
> pkg:[bb-wl18xx-firmware]:[1.20161020-0rcnee1~bpo80+20161020+1]
>
> WARNING:pkg:[firmware-ti-connectivity]:[NOT_INSTALLED]
>
> groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
> plugdev users systemd-journal netdev i2c admin spi tisdk weston-launch 
> xenomai]
>
> cmdline:[console=ttyO0,115200n8 
> root=UUID=ac4731db-c4db-463f-9129-07e6746b98ba ro rootfstype=ext4 rootwait 
> coherent_pool=1M quiet]
>
> dmesg | grep pinctrl-single
>
> [1.179799] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 
> size 

[beagleboard] Followed instructions to update to sync config-pin & overlays - now even worse...

[ags]

I gave up trying to figure out how to get config-pins, overlays, uboot, etc 
all in-sync to allow access to all the available pru pins, so I followed 
previous instructions to update.

What I did:

debian@BBBWl:~$ cd /opt/scripts/tools
debian@BBBWl:~$ sudo ./update_kernel.sh

edited /boot/uEnv.txt to include:

enable_uboot_overlays=1

disable_uboot_overlay_audio=1

uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo

enable_uboot_cape_universal=1


and changed this:


cmdline=coherent_pool=1M quiet cape_universal=enable


to this:


cmdline=coherent_pool=1M quiet


rebooted and...


Last login: Fri Mar 23 22:01:29 2018 from 10.8.0.6

debian@BBBWl:~$ uname -r

4.4.113-ti-r148

debian@BBBWl:~$ config-pin -l p9.25

default gpio gpio_pu gpio_pd qep pruout pruin

debian@BBBWl:~$ config-pin p9.25 pruout

P9_25 pinmux file not found!

cape-universala overlay not found

run "config-pin overlay cape-universala" to load the cape

checked to see if the bb-cape-overlays had been updated and saw a newer 
version so installed that:

debian@BBBWl:~$ apt show bb-cape-overlays

Package: bb-cape-overlays

Version: 4.4.20180322.0-0rcnee0~jessie+20180322

Maintainer: Robert Nelson 

Installed-Size: 2,289 kB

Priority: extra

Section: misc

Download-Size: 66.7 kB

APT-Sources: http://repos.rcn-ee.com/debian/ jessie/main armhf Packages

Description: Device tree overlays for Beaglebone.

 Device tree overlays for Beaglebone /lib/firmware/


rebooted and same problem.

I then looked to see if the uio_pruss driver had been installed...


debian@BBBWl:/opt/scripts/tools$ ls /sys/class/uio

debian@BBBWl:/opt/scripts/tools$


Bad.


debian@BBBWl:/opt/scripts/tools$ ls /sys/class/gpio

export  *gpio12*  *gpio13*  *gpiochip0*  *gpiochip32*  *gpiochip64*  
*gpiochip96*  unexport


Worse.


So now I have no uio_pruss driver, and just two gpio pins.

Info:


debian@BBBWl:/opt/scripts/tools$ sudo ./version.sh 

git:/opt/scripts/:[9d965a5f40ae00774c81164f87a450a678ab79f6]

eeprom:[A335BNLTBWA51650BBWG0378]

model:[TI_AM335x_BeagleBone_Black_Wireless]

dogtag:[BeagleBoard.org Debian Image 2016-11-06]

bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2016.11-rc3-2-g73df7f]:[location: dd MBR]

kernel:[4.4.113-ti-r148]

nodejs:[v6.12.2]

uboot_overlay_options:[enable_uboot_overlays=1]

uboot_overlay_options:[disable_uboot_overlay_audio=1]

uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]

uboot_overlay_options:[enable_uboot_cape_universal=1]

pkg:[bb-cape-overlays]:[4.4.20180322.0-0rcnee0~jessie+20180322]

pkg:[bb-wl18xx-firmware]:[1.20161020-0rcnee1~bpo80+20161020+1]

WARNING:pkg:[firmware-ti-connectivity]:[NOT_INSTALLED]

groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
plugdev users systemd-journal netdev i2c admin spi tisdk weston-launch 
xenomai]

cmdline:[console=ttyO0,115200n8 
root=UUID=ac4731db-c4db-463f-9129-07e6746b98ba ro rootfstype=ext4 rootwait 
coherent_pool=1M quiet]

dmesg | grep pinctrl-single

[1.179799] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 
568

dmesg | grep gpio-of-helper

[1.180937] gpio-of-helper ocp:cape-universal: Allocated GPIO id=0

[1.181098] gpio-of-helper ocp:cape-universal: Allocated GPIO id=1

[1.181110] gpio-of-helper ocp:cape-universal: ready

END


Help please...


-- 
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/126e81d0-43a4-4c5f-81b9-5f65f8de9e6e%40googlegroups.com.
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 <alfred.g...@gmail.com > 
> 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] Re: I2S Audio on the BBB

[ags]

@Graham thanks for posting this. I expect to have to do some things 
differently since my target CODEC is different and overlays are now handled 
differently. In any case, this will give me a good head start and 
foundation to build on.

On Tuesday, December 26, 2017 at 12:54:04 PM UTC-8, 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
>  
> <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 go

Re: [beagleboard] which *.dtb does BBB Wireless use? (4.4.30-ti-r64)

[ags]

I need to enable uio_pruss (you already kindly provided instructions on how 
to do that a few months ago).
I just need to figure out which *.dtb to rebuild. If I make a mistake and 
brick the BBBW, it will be difficult for me to fix it,
so I'm being cautious. However, after posting I realized that if I guess 
the wrong *.dtb, it won't get loaded so shouldn't be a problem.
So I chose am335x-boneblack-wireless.dtb... and of course you will know 
that worked.

I'd still like to understand how the proper *.dtb is specified or 
discovered by uboot.


On Thursday, December 21, 2017 at 9:10:39 AM UTC-8, RobertCNelson wrote:
>
> On Thu, Dec 21, 2017 at 11:06 AM, ags <alfred.g...@gmail.com > 
> wrote: 
> > How can I see which dtb file is being loaded? I've looked at 
> /boot/uEnv.txt 
> > but nothing is specified there - all lines are commented other than 
> > uname=..., uuid=... and: 
> > 
> > cmdline=coherent_pool=1M quiet cape_universal=enable 
> > 
> > I believe I'm using an older uboot. Where/how is the dtb file specified? 
> I 
> > see two likely candidates: 
> > 
> > /boot/dtbs/4.4.30-ti-r64/am335x-boneblack-wireless.dtb 
> > /boot/dtbs/4.4.30-ti-r64/am335x-boneblack-wl1835mod.dtb 
> > 
> > I first tried installing a new version of the "standard" dtb but that 
> didn't 
> > work so I presume it is not the one used for BBBW: 
> > 
> > /boot/dtbs/4.4.30-ti-r64/am335x-boneblack.dtb 
> > 
> > I'm stumped trying to figure out where this is specified. dmesg did not 
> help 
> > either... 
> > 
> > Thanks in advance. 
>
> U-Boot will correctly pick the correct dtb. 
>
> What issues are you seeing? 
>
> 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/bdff871d-6d9a-4449-83c7-6ad247b664a4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] which *.dtb does BBB Wireless use? (4.4.30-ti-r64)

[ags]

How can I see which dtb file is being loaded? I've looked at /boot/uEnv.txt 
but nothing is specified there - all lines are commented other than 
uname=..., uuid=... and:


cmdline=coherent_pool=1M quiet cape_universal=enable


I believe I'm using an older uboot. Where/how is the dtb file specified? I 
see two likely candidates:


/boot/dtbs/4.4.30-ti-r64/am335x-boneblack-wireless.dtb

/boot/dtbs/4.4.30-ti-r64/am335x-boneblack-wl1835mod.dtb


I first tried installing a new version of the "standard" dtb but that 
didn't work so I presume it is not the one used for BBBW:


/boot/dtbs/4.4.30-ti-r64/am335x-boneblack.dtb


I'm stumped trying to figure out where this is specified. dmesg did not 
help either... 


Thanks in advance.


-- 
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/2278bda9-6744-4019-be09-22aca05a2959%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: I2S Audio on the BBB

[ags]

This is very old, but I'm still interested in using I2S to directly drive 
an audio device (software defined radio module).
Could you post your write-up if available? Thanks.

On Tuesday, May 16, 2017 at 11:21:30 AM UTC-7, Graham wrote:
>
> It will be a day or so, but I will post the write-up here.
>
> You will not be able to control the IC independently, since the kernel 
> claims the device.
> The Linux audio system expects to be able to control the audio controls 
> such as volume, etc.
> by reaching into the CODEC through the control bus.  The kernel blocks 
> direct user
> space access to the device.
>
> In fact one way to make sure the device tree loaded correctly is that the 
> "UU" symbol
> appears at the devices' I2C address.
>
> --- Graham
>
> ==
>
> On Tuesday, May 16, 2017 at 10:51:19 AM UTC-5, ags wrote:
>>
>> I would appreciate the writeup, thank you.
>>
>> My project requires interfacing to an IC with I2S input. I planned on 
>> using (something like) aplay to write audio out to I2S/McASP channel (using 
>> built-in driver support) and hoped I could also use the built-in support 
>> (drivers) for SPI and/or I2C using the /dev/spidev or /dev/i2c- 
>> devices to control the IC.
>>
>> On Monday, May 15, 2017 at 6:46:50 PM UTC-7, Graham wrote:
>>>
>>> Yes, I was able to get a CircuitCo Rev.B Audio cape running, using the 
>>> I2S/McASP interface.
>>> I'll write it up for you, if you are interested.
>>>
>>> If you are going to use a different CODEC or other device on the 
>>> I2S/McASP interface,
>>> you will need to see if a driver already exists for it, or if it fits a 
>>> generalized I2S audio interface that
>>> is already inside the kernel can be invoked and controlled from a device 
>>> tree.
>>>
>>> If it is unique, then you will have to write your own Linux driver and 
>>> recompile the kernel.
>>>
>>> If you just want audio, it is a lot easier to just use a USB CODEC.
>>>
>>> --- Graham
>>>
>>> ==
>>>
>>> On Monday, May 15, 2017 at 6:11:11 PM UTC-5, ags wrote:
>>>>
>>>> I'm also interested as I have a project where I will interface directly 
>>>> to the I2S/McASP interface. Did you figure it out?
>>>>
>>>>
>>>> On Tuesday, January 3, 2017 at 8:57:29 AM UTC-8, Graham wrote:
>>>>>
>>>>> I spent most of the weekend down in the rabbit-hole, trying to get a
>>>>> CircuitCo Rev_B Audio cape to work, (unsuccessfully.)
>>>>>
>>>>> Is this cape compatible-with / supported-by Debian 8.6/kernel 4.4 ?
>>>>>
>>>>> Does the BB-BONE-AUDI-02-00A0.dtbo overlay that comes with the current 
>>>>> distribution work?
>>>>>
>>>>> How can you tell if an overlay actually loaded, with 4.4? 
>>>>> /sys/devices/platform/bone_capemgr/slots 
>>>>> as well as the boot log, only shows the first physical four, and no 
>>>>> longer shows the higher numbered "pseudo-capes" and overlay status.
>>>>>
>>>>> I understand that
>>>>> The CircuitCo cape does not have an EEPROM, so everything needs to be 
>>>>> configured explicitly.
>>>>> I need to use a base .dts with HDMI audio disabled, then load the 
>>>>> overlay for the CircuitCo card.
>>>>> I also need to load the asound.state file.
>>>>>
>>>>> Am I approaching this correctly?
>>>>>
>>>>> I can not use a USB-soundcard for audio. I have several applications
>>>>> that need McASP/I2S running for several other codecs, but I thought I 
>>>>> would start 
>>>>> with the CircuitCo cape as a starting point.
>>>>>
>>>>> Thanks,
>>>>> --- Graham
>>>>>
>>>>> ==
>>>>>
>>>>>

-- 
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/3b1bb63a-326a-4822-9835-6bbf3439db63%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[ags]

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?

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.

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

On Wednesday, December 20, 2017 at 1:33:46 PM UTC-8, ags wrote:
>
> I've been building a prototype using the uio_pruss driver and one "test" 
> pin (P9_27) which was easily allocated using config-pin.
> I'm now trying to complete the prototype and need to enable a total of 8 
> PRU pins (pr1_pru0_pru_r30_[0-7]). I am unable to enable most of these pins:
>
> debian@BBB:~$ uname -r
> 4.4.30-ti-r64
>
> debian@BBB:~$ config-pin -a p9_29 pruout
>
> P9_29 pinmux file not found!
>
> P9_29 overlay not found
>
> Loading cape-universala overlay
>
> bash: line 0: echo: write error: File exists
>
> Error loading device tree overlay file: cape-universala
>  
>
> After searching I found this: 
> https://github.com/cdsteinkuehler/beaglebone-universal-io/issues/43
>
> recommending updating overlays ("things have changed")...
>
> So I went here: https://github.com/beagleboard/bb.org-overlays
>
> and did this:
>
>
> debian@BBB:~$ sudo apt update ; sudo apt install bb-cape-overlays
>
>
> debian@BBB:~$ apt show bb-cape-overlays
>
> Package: bb-cape-overlays
>
> Version: 4.4.20171215.0-0rcnee1~jessie+20171215
>
> Maintainer: Robert Nelson <robertcnel...@gmail.com>
>
> Installed-Size: 2,003 kB
>
> Depends: device-tree-compiler
>
> Priority: extra
>
> Section: misc
>
> Download-Size: 59.5 kB
>
> APT-Manual-Installed: yes
>
> APT-Sources: http://repos.rcn-ee.com/debian/ jessie/main armhf Packages
>
> Description: Device tree overlays for Beaglebone.
>
>  Device tree overlays for Beaglebone /lib/firmware/
>
>
> But now have a new problem:
>
>
> debian@BBB:~$ config-pin p9_29 pruout
>
> bash: /sys/devices/platform/ocp/ocp*P9_29_pinmux/state: No such file or 
> directory
>
> Cannot write pinmux file: /sys/devices/platform/ocp/ocp*P9_29_pinmux/state
>
> debian@BBBr0C0-1:~/node$ config-pin -a p9_29 pruout
>
> bash: /sys/devices/platform/ocp/ocp*P9_29_pinmux/state: No such file or 
> directory
>
> Cannot write pinmux file: /sys/devices/platform/ocp/ocp*P9_29_pinmux/state
>
>
> I did read about moving away from kernel overlays to uBoot overlays here: 
> https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
>
> but am no closer to a solution. I am now under time pressure and prefer to 
> make minimal changes to my system. Can anyone help with suggestions to work 
> around this?
>

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

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

[ags]

I've been building a prototype using the uio_pruss driver and one "test" 
pin (P9_27) which was easily allocated using config-pin.
I'm now trying to complete the prototype and need to enable a total of 8 
PRU pins (pr1_pru0_pru_r30_[0-7]). I am unable to enable most of these pins:

debian@BBB:~$ uname -r
4.4.30-ti-r64

debian@BBB:~$ config-pin -a p9_29 pruout

P9_29 pinmux file not found!

P9_29 overlay not found

Loading cape-universala overlay

bash: line 0: echo: write error: File exists

Error loading device tree overlay file: cape-universala
 

After searching I found 
this: https://github.com/cdsteinkuehler/beaglebone-universal-io/issues/43

recommending updating overlays ("things have changed")...

So I went here: https://github.com/beagleboard/bb.org-overlays

and did this:


debian@BBB:~$ sudo apt update ; sudo apt install bb-cape-overlays


debian@BBB:~$ apt show bb-cape-overlays

Package: bb-cape-overlays

Version: 4.4.20171215.0-0rcnee1~jessie+20171215

Maintainer: Robert Nelson 

Installed-Size: 2,003 kB

Depends: device-tree-compiler

Priority: extra

Section: misc

Download-Size: 59.5 kB

APT-Manual-Installed: yes

APT-Sources: http://repos.rcn-ee.com/debian/ jessie/main armhf Packages

Description: Device tree overlays for Beaglebone.

 Device tree overlays for Beaglebone /lib/firmware/


But now have a new problem:


debian@BBB:~$ config-pin p9_29 pruout

bash: /sys/devices/platform/ocp/ocp*P9_29_pinmux/state: No such file or 
directory

Cannot write pinmux file: /sys/devices/platform/ocp/ocp*P9_29_pinmux/state

debian@BBBr0C0-1:~/node$ config-pin -a p9_29 pruout

bash: /sys/devices/platform/ocp/ocp*P9_29_pinmux/state: No such file or 
directory

Cannot write pinmux file: /sys/devices/platform/ocp/ocp*P9_29_pinmux/state


I did read about moving away from kernel overlays to uBoot overlays 
here: https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays

but am no closer to a solution. I am now under time pressure and prefer to 
make minimal changes to my system. Can anyone help with suggestions to work 
around this?

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

[beagleboard] is there a template for BBB capes?

[ags]

I've searched and found nothing. I thought it would be easy to find Eagle 
(or other) PCB files for a cape with the "standard" board size/shape and 
the expansion headers.

I'm using DesignSpark PCB, but can convert from Eagle, OrCAD, maybe others.

-- 
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/40c3ee81-ccf5-437f-9c9b-eabb1a674757%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: I2S Audio on the BBB

[ags]

I would appreciate the writeup, thank you.

My project requires interfacing to an IC with I2S input. I planned on using 
(something like) aplay to write audio out to I2S/McASP channel (using 
built-in driver support) and hoped I could also use the built-in support 
(drivers) for SPI and/or I2C using the /dev/spidev or /dev/i2c- 
devices to control the IC.

On Monday, May 15, 2017 at 6:46:50 PM UTC-7, Graham wrote:
>
> Yes, I was able to get a CircuitCo Rev.B Audio cape running, using the 
> I2S/McASP interface.
> I'll write it up for you, if you are interested.
>
> If you are going to use a different CODEC or other device on the I2S/McASP 
> interface,
> you will need to see if a driver already exists for it, or if it fits a 
> generalized I2S audio interface that
> is already inside the kernel can be invoked and controlled from a device 
> tree.
>
> If it is unique, then you will have to write your own Linux driver and 
> recompile the kernel.
>
> If you just want audio, it is a lot easier to just use a USB CODEC.
>
> --- Graham
>
> ==
>
> On Monday, May 15, 2017 at 6:11:11 PM UTC-5, ags wrote:
>>
>> I'm also interested as I have a project where I will interface directly 
>> to the I2S/McASP interface. Did you figure it out?
>>
>>
>> On Tuesday, January 3, 2017 at 8:57:29 AM UTC-8, Graham wrote:
>>>
>>> I spent most of the weekend down in the rabbit-hole, trying to get a
>>> CircuitCo Rev_B Audio cape to work, (unsuccessfully.)
>>>
>>> Is this cape compatible-with / supported-by Debian 8.6/kernel 4.4 ?
>>>
>>> Does the BB-BONE-AUDI-02-00A0.dtbo overlay that comes with the current 
>>> distribution work?
>>>
>>> How can you tell if an overlay actually loaded, with 4.4? 
>>> /sys/devices/platform/bone_capemgr/slots 
>>> as well as the boot log, only shows the first physical four, and no 
>>> longer shows the higher numbered "pseudo-capes" and overlay status.
>>>
>>> I understand that
>>> The CircuitCo cape does not have an EEPROM, so everything needs to be 
>>> configured explicitly.
>>> I need to use a base .dts with HDMI audio disabled, then load the 
>>> overlay for the CircuitCo card.
>>> I also need to load the asound.state file.
>>>
>>> Am I approaching this correctly?
>>>
>>> I can not use a USB-soundcard for audio. I have several applications
>>> that need McASP/I2S running for several other codecs, but I thought I 
>>> would start 
>>> with the CircuitCo cape as a starting point.
>>>
>>> Thanks,
>>> --- Graham
>>>
>>> ==
>>>
>>>

-- 
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/a4486923-19cb-4a24-aa39-6a54d96a5d01%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] mpg123 1.20.1 crashes getting sample rate (FORMAT command)

[ags]

I am building an interface to mpg123 from another application using the 
Remote command interface. I have observed that if the FORMAT command is 
issued to get the audio sample rate (e.g. 44100) after a file is loaded but 
before starting playback, the mpg123 process will crash when playback is 
started. If the file is loaded and played, then paused, then FORMAT issued, 
playback will continue without error. I've duplicated this using a USB 
audio "card" as well as the build-in mcasp interface.

Linux BBB 4.4.30-ti-r64 #1 SMP Fri Nov 4 21:23:33 UTC 2016 armv7l GNU/Linux
mpg123 version: 1.20.1, installed using apt install mpg123 on BBB running 
jessie 
Log: (inline descriptive comments added to actual log output is designated 
by //)

$ mpg123 -R -a default:Device   // start mpg123 in "Remote command 
mode" with standard mcasp audio device

@R MPG123 (ThOr) v8 // response: normal startup message

LOADPAUSED ./my_file.mp3 // command: "LOADPAUSED/LP" - load a 
file ("my_file.mp3") but do not begin playback

@I ID3v2.title:my_track // response: ID3 information...

@I ID3v2.artist:my_artist

@I ID3v2.album:my_album

@I ID3v2.year:2017

@I ID3v2.comment:12++

@I ID3v2.genre:Country & Folk

@P 1// response: file loaded & paused, 
ready to begin file playback

FORMAT  // command: "FORMAT" - get audio sample 
rate and channel count

@FORMAT 44100 2 // response: 44100 Hz, 2-channel

PAUSE   // command: "PAUSE" - pause/un-pause

@P 2// response: OK, playing file, but...


[alsa.c:230] error: Fatal problem with alsa output, error -5.


[audio.c:614] error: Error in writing audio (Success?)!


[mpg123.c:681] error: Deep trouble! Cannot flush to my output anymore!


Doing the same thing without issuing the "FORMAT" command works fine. Doing 
the same thing, but after loading file, beginning playback, then pausing, 
then issuing "FORMAT" command, then continuing playback (or seeking back to 
the beginning of the file and playing) works fine.


Any ideas how to resolve this, or repair it? I've searched and not found 
anything about this (most issues seemed to be related to alsa).


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/8f05c91a-b0c8-4ee2-8b6c-9b83bc2d1126%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How to reliably push data from ARM host to PRU (shared) memory with predictable (low) latency?

[ags]

@William Hermans I thought I'd share the result of my efforts to reliably 
stream data from ARM host (Linux userspace) to PRU.

I instrumented the PRU ASM code to use the CYCLE register for very precise 
measurements. I ran tests that kept track of how many times, for how long, 
and the "worst offender" when the PRU was stalled waiting for data from the 
ARM host. I used this to test my current implementation using select(), and 
then replaced select() with usleep() (and nanosleep()), and then again a 
loop with no sleep, just a brute-force busy wait that never released the 
CPU. As it turns out, the results were surprising. Using usleep() (and 
similar related methods), the number of stalls, the overall stall time and 
the worst-case stall time were all significantly worse than the 
implementation using select(). Even the busy wait loop w/out sleep() was 
worse. I did a bit of research and sleep() and related methods are 
implemented using a syscall (sleep - used to use alarm in the olden-days 
(so I read)). So getting through the call gate and the context swap happens 
with sleep() just like with select(). My theory is that select() is more 
efficient precisely because of this: one call to select() incurs one system 
call/context swap per interrupt. The process is put on the NotRunning list, 
and the the OS continues on. When a trigger event happens, the OS returns 
the process to the Running list and then control back to user space. For 
the sleep() method, there are many calls per "interrupt", polling some 
memory location looking for the signal from the PRU. So what is handled by 
one userspace->kernelspace->userspace transition with select() could 
require dozens of these transitions using sleep().

I don't claim to be an expert, and if there is a flaw in this theory I'm 
open to hearing what it is. But this is my theory at the current moment.

So what I ended up doing is compress the data so that one "frame" can fit 
in PRU memory at once. The PRU needs to send a full "frame" out with 
precise timing (within microsecond timing) for all data in that frame. 
Between frames, there is slack. By compressing the data, I can load a full 
frame into the PRU0/1 DRAM and shared RAM, and then kick off writing out 
the frame. Now everything is (or appears to be) deterministic in the timing 
of all transfers between registers, scratch and PRU DRAM. So I've 
sidestepped the problem of unpredictable latency waiting for data from the 
ARM host.

I hope this might help someone else with similar requirements.

On Thursday, March 23, 2017 at 12:32:28 PM UTC-7, William Hermans wrote:
>
>
>
> On Thu, Mar 23, 2017 at 5:48 AM, ags <alfred.g...@gmail.com > 
> wrote:
>
>> OK, I will use the busy-wait loop w/ usleep and test. The reason I used 
>> select was I thought it would allow me to do other things (I need to have 
>> another process, thread, or loop in this same application serving out audio 
>> data to another client, synchronized with this data). My understanding was 
>> that the process blocking on select() to return would free the CPU for 
>> other things, but allow a quick wake-up to refresh the buffer as needed.
>>
>
> I thought that select(), and all that should work too, initially. But you 
> have to remember, we're talking about an OS here that has an "expected" 
> latency of 100ms, or more- Depending. I can tell you that one could easily 
> experiment, and find out for themselves. One of the easiest tests one could 
> do for themself. Would be to run a loop, for 10,000 iterations, then 
> compare using select() to a busy wait loop. Then run the cmdline command 
> time on each to see the difference. This of course is not a super accurate 
> test, but should be good enough to show a huge difference in executable 
> completion time. *If* you're more of the scientific type, then get the 
> system time in your test app before, and after the test code, then output 
> the difference between those two times.
>
> Anyway, using an RT kernel, or an xenomai kernel may improve this latency 
> *some*, but it is said that this comes at the expense of *some* other 
> performance aspects of the OS. I've not actually tested that myself, but 
> only read about it.
>
>>
>> BTW, I have only mentioned the problems - but it does *almost* work. In 
>> my tests, I ran 12,500 4KiB buffers from ARM to PRU and measured (on the 
>> PRU side, using the precise CYCLE counter) to see if the PRU ever had to 
>> wait for the next buffer fill. Turns out that the PRU had to wait about 180 
>> times, or about 1.5% of the buffer fill events. The worse case wait (stall) 
>> time was ~5milliSeconds.
>>
>
> One has to be very careful what they use in code when writing an 
> executable that requires some degree of de

Re: [beagleboard] How to reliably push data from ARM host to PRU (shared) memory with predictable (low) latency?

[ags]

OK, I will use the busy-wait loop w/ usleep and test. The reason I used 
select was I thought it would allow me to do other things (I need to have 
another process, thread, or loop in this same application serving out audio 
data to another client, synchronized with this data). My understanding was 
that the process blocking on select() to return would free the CPU for 
other things, but allow a quick wake-up to refresh the buffer as needed.

BTW, I have only mentioned the problems - but it does *almost* work. In my 
tests, I ran 12,500 4KiB buffers from ARM to PRU and measured (on the PRU 
side, using the precise CYCLE counter) to see if the PRU ever had to wait 
for the next buffer fill. Turns out that the PRU had to wait about 180 
times, or about 1.5% of the buffer fill events. The worse case wait (stall) 
time was ~5milliSeconds.

On Thursday, March 23, 2017 at 3:03:47 AM UTC-7, William Hermans wrote:
>
>
>
> On Wed, Mar 22, 2017 at 10:13 PM, ags <alfred.g...@gmail.com 
> > wrote:
>
>> I thought using select() to wait for notification of an event (by 
>> "listening" to the fsys uio files) would free the ARM cpu to do other 
>> things while waiting, but provide the most immediate path to the user space 
>> application to send more data. Is there a better way?
>>
>
> So that select() is probably your whole problem. Unless, you're using 
> other system calls as well. But I've already discussed with you the best, 
> and fastest way to achieve your goal. Several times in fact. Use a bit in 
> memory, *somewhere*.
>
> PRU side:
> while(somewhere & 0x1 )
> usleep(1000);
> /* Do our work after while() fall through */
>
> Userspace side:
> while(! (somewhere & 0x1) )
> usleep(1000);
> /* Do our work after while() fall through */
>
> No need for select(), no need for fancy threading calls, or other magical 
> hand waving. Just two simple busy wait loops waiting for their respective 
> turns. But, don't forget to toggle the bit back, when you're done. Anyway, 
> it's not really Linux that's off in the weeds. Well perhaps it is, but your 
> application is pushing it into the weeds.
>

-- 
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/2c4feb8c-824d-4a64-8c8f-dfbb5c14d962%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How to reliably push data from ARM host to PRU (shared) memory with predictable (low) latency?

[ags]

You've hit the nail on the head. The issue (IMO) is Linux "wandering off 
into the weeds". It comes back, eventually... but while gone, bad things 
happen.

1) I am using a handshake approach between PRU and ARM, using interrupts. 
When the PRU wants more data, it generates an ARM interrupt. The user space 
application listens for the interrupt (using select()) and when received 
sends more data. The PRU is made aware of the data being ready by sending 
an interrupt to the PRU.
2) I am using a ring (though with only two compartments, it seems more like 
a "line") to send the data. I think of it as a tic/tock, or ping/pong 
approach: when one "side" (half) of the data space has been read by the 
PRU, it signals the ARM host to send another (half) buffer full of data. So 
the PRU is always reading from a buffer while the ARM is loading the other.
3) While the average data rate I need to sustain is about 13Mbit/second 
(not a problem) the challenge is ensuring, under all conditions, that I can 
send 262 kbits of data from ARM to PRU, in chunks small enough to fit into 
the 12k PRU shared RAM, in a "timely manner". With my current design, this 
requires sending 4KiB of data from ARM to PRU shared RAM, completing the 
transaction within 960 uSec of the request for more data. The limiting 
factors are the timing (can't starve the PRU of data, otherwise the 
bitstream out will have gaps which corrupt the content for the (extra-BBB 
client)) and the size of the PRU memory (if I could load a full "frame 
buffer" of data at once to ensure not starving the PRU that would work - 
but the PRU shared RAM only holds 1/8 of the data required by the PRU for 
each burst).

I thought using select() to wait for notification of an event (by 
"listening" to the fsys uio files) would free the ARM cpu to do other 
things while waiting, but provide the most immediate path to the user space 
application to send more data. Is there a better way?

On Wednesday, March 22, 2017 at 9:43:24 AM UTC-7, William Hermans wrote:
>
>
>
> On Wed, Mar 22, 2017 at 8:45 AM, Charles Steinkuehler <
> cha...@steinkuehler.net > wrote:
>
>>
>> Note you might need an -rt or -xenomai kernel to achieve reliable
>> operation, I've seen the non-rt kernels occasionally "wander off into
>> the weeds" for several hundred mS at a time.
>>
>> --
>> Charles Steinkuehler
>> cha...@steinkuehler.net 
>>
>>
> "Wander off into the weeds . . ." I get a kick out of that expression 
> every time I see it in this context.
>
> I do agree with Charles, and would like to add that you need to pay close 
> attention to which C, and Linux API function calls you use in your 
> application. Function calls such as printf() which can be handy for quick 
> and dirty text debugging can slow your code down considerably. However, if 
> you pipe the output of such an application into a file. You'll notice a 
> huge performance improvement with that single trick alone. Anything related 
> to threading, file locks( poll(), etc ), etc through Linux API calls is 
> also going to slow you down. Certainly there is more, but these are the 
> three things I've personally tested, and can think of off the top of my 
> head. Also, under certain conditions, using usleep() in your code where 
> you're using a busy wait loop, can help some, but at other times it could 
> potentially backfire. Depending on how busy your system is. Either way 
> though, a busy wait loop without using usleep(), or giving CPU time back to 
> the system will wind up using ~95% processor time. Until "preempted". Just 
> remember that there is only have one core / thread to work with.
>
> You may also need to slim down unneeded processes, services, and kernel 
> modules that are loaded / running by default on a stock beaglebone Linux 
> image. As all of this will be compete for CPU time, which you may not be 
> able to afford, in order to have your application perform as well as you'd 
> like. Basically you need to profile your system, and see what you can get 
> away with.
>
> So from personal experience, I can say with reasonable confidence that the 
> maximum possible latency with an RT kernel is going to be around 50ms. But 
> this number will be if your system is constantly "busy". If you system is 
> extremely busy, it can be more. But I've had an application that was doing 
> a lot of processing in code, but was only using up to 5% processor time. 
> Because I was giving processor time back to the system by using usleep(). 
> But anyway, if you need "real-time" an RT kernel could work fine. Depending 
> on your definition of the term. If you need deterministic, you may need to 
> use xenomai, move into the kernel, or potentially both.
>
> I would probably start by profiling your system to see what all is running 
> in the background, and if everything you do have running is necessary. 
> After that, try installing an RT kernel.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this 

[beagleboard] How to reliably push data from ARM host to PRU (shared) memory with predictable (low) latency?

[ags]

I have an application running on the ARM host that writes to the PRU shared 
memory. The PRU core then manipulates that data and sends it out the EGPIO 
pins with exact timing.

For this to work, I need to have a steady supply of data bursts available 
to the PRU core - about 32 KiB each burst. This won't fit into the PRU 
shared memory (12 KiB), PRU memory (2x 8 KiB), or even spread out over all 
PRU memory (28 KiB total). So it's not possible to load the data into PRU 
memory and then kick off the PRU core to send it out the pins. There will 
be a necessary transfer of additional data from ARM host to PRU memory 
after the PRU has started sending data out through the EGPIO pins.

I've instrumented the PRU PASM code using the CYCLE register, and see that 
there is variable latency when the PRU is waiting for a memory block to be 
received from the ARM host. This can be upwards of 5 milliSec, which won't 
work for this application. I've tried using ionice to set class to realtime 
and priority to 0, but this had no appreciable effect.

Is there some way to reduce the latency of writing from ARM/Linux to the 
PRU memory? I've heard that some projects use DMA to transfer data from the 
PRU to host (ARM, system) DDR (e.g. BeagleLogic project) but nothing about 
the reverse direction. Does this even make sense? Will the kernel already 
be invoking DMA during a memcpy from user virtual address space to the 
mmap'd physical PRU memory address?

I need to  provide about 32 KiB to the PRU within 5 milliSec, repeating 
every 20 milliSec. This seems like it should be easily accomplished, if a 
USB driver can sustain 480 Mbps data rates. I must be approaching this the 
wrong way. Any suggestions on how this should be architected will be 
greatly 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/1ecc3b3e-4986-4120--0d8d49902510%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: How many PRU clock cycles does a LBBO instruction take?

[ags]

Would someone kindly decode what VBUS and VBUSP are? Searched but could not 
find other relevant references. Thanks.

On Tuesday, May 26, 2015 at 6:39:38 AM UTC-7, marcelo...@gmail.com wrote:
>
> Sorry, just saw that you actually mentioned that the shared memory has the 
> same performance as the DRAM.
> Also, I found this: 
> http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit#Load_.2F_Store_Instructions
> where it is said that LBBO should take (1+word count) cycles. If that's 
> right, an LBBO instruction up to 4 bytes should take 2 cycles for VBUS 
> and 3 cycles for VBUSP. For now I need to study more to understand which 
> one is the case, but VBUSP matches with your findings.
>
> Em sexta-feira, 3 de janeiro de 2014 23:05:30 UTC-2, Lenny escreveu:
>>
>> Hello, 
>>
>> I am using a Beaglebone Black. When i measured the number of PRU clock 
>> cycles needed for the execution of various assembler instructions, I found 
>> surprisingly large values for memory access. Here follows a list, in which 
>> one cycle corresponds to a delay of 5ns as expected:
>>
>> Most operations, such as ADD,SUB,QBxx,MOV,JMP etc.: 1 cycle
>>
>> LBBO 1,2,4 Bytes from PRU DRAM: 3 cycles
>> LBBO 8 Bytes from PRU DRAM: 4 cycles
>> LBBO 12 Bytes from PRU DRAM: 5 cycles
>> LBBO 16 Bytes from PRU DRAM: 6 cycles
>>
>> LBCO 4 Bytes from DDR: 43 cycles
>> LBCO 8 Bytes from DDR: 44 cycles
>> LBCO 12 Bytes from DDR: 45 cycles
>> LBCO 16 Bytes from DDR: 46 cycles
>>
>> With PRU DRAM, i mean any addresses between 0x and 0x4000 and 
>> the shared PRU RAM (12 kB starting from 0x0001). Any other address i 
>> tried had the delay stated for "DDR".
>>
>> Can anybody confirm the long DDR (and other delays if possible) readout 
>> times that I have measured? Does anybody have an explanation for these 
>> large delays?
>>
>> Thanks in advance! Lenny
>>
>

-- 
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/e61aacdd-cb01-4230-9a9a-d6fa9cff36ba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Are the am335x_pru_package examples incorrectly (dangerously) accessing DDR memory?

[ags]

Very useful response. At the least it verifies that my conclusions are not 
totally unfounded. I suppose it could be just dumb luck that it works at 
all - but I also wonder if there's not something that kernel gurus know 
about what the first  pages of memory are used for, and the author took 
advantage of that. I also see that on my system, kernel code starts at 
0x08000_8000. Still not a good practice though IMO.

I'm wondering if there isn't some way to use the DT to not only enable the 
PRUSS, but also select a driver, and configure the driver parameters (e.g. 
"extram_pool_sz") automatically. I read that the remoteproc and uio drivers 
conflict, so none is loaded by default. I suppose it would require a change 
to the pruss driver (whatever reads the "ti,pruss-v2" entry in the device 
tree) to support this, but it would be convenient.

Thanks.

On Friday, March 10, 2017 at 11:52:42 AM UTC-8, din...@gmail.com wrote:
>
> Hi,
>
> I believe the example is indeed buggy, and works by accident. You can 
> check "cat /proc/iomem" and see that your mapped region overlaps the 
> kernel code.
>
> If you need to properly allocate and map DDR between ARM and PRU, then I 
> would suggest to:
>
>1. Load PRU UIO with "modprobe uio_pruss extram_pool_sz=2097152" in 
>order to tell it allocate contiguous memory.
>2. Use prussdrv_map_extmem() from ARM side to map the allocated DDR 
>chunk. Example 
>
> <https://github.com/dinuxbg/pru-gcc-examples/blob/master/ov7670-cam/host-uio/pload.c#L294>
>3. Get the physical DDR base address of the chunk by using 
>prussdrv_get_phys_addr(). Example 
>
> <https://github.com/dinuxbg/pru-gcc-examples/blob/master/ov7670-cam/host-uio/pload.c#L297>
>4. Write the physical DDR base address to a pre-defined location in 
>PRU DRAM. If you are using pasm, then just hard-code the pre-defined 
>location. If your firmware is in ELF format, there is a bit nicer way 
>
> <https://github.com/dinuxbg/pru-gcc-examples/blob/master/ov7670-cam/host-uio/pload.c#L207>
>.
>
>
> Regards,
> Dimitar
>
> On Tuesday, March 7, 2017 at 10:07:31 PM UTC+2, ags wrote:
>>
>> I have been able to load/start/run/stop a PRU core from 4.4.30-ti-r64 
>> using just the uio_pruss (& uio) drivers, without any of the prussdrv code. 
>> Big milestone in my project.
>>
>> A long time ago I asked a question about the examples in the pru here: 
>> https://groups.google.com/d/topic/beagleboard/Kv03QMsgOmo/discussion
>>
>> as did someone else here: 
>> https://groups.google.com/d/topic/beagleboard/vnZ9eSzoo6Y/discussion
>>
>> but I found no answer to help me. From a thorough review of the examples 
>> in the am335x_pru_package (using the prussdrv uio-based pru driver) here: 
>> https://github.com/beagleboard/am335x_pru_package/blob/master/pru_sw/example_apps/PRU_PRUtoPRU_Interrupt/PRU_PRUtoPRU_Interrupt.c
>>
>> it *appears* to me that this example (to teach/illustrate proper use of 
>> pru in the BB family) works only by luck - or taking advantage of some bit 
>> of information that is undocumented (from my research).
>>
>> Specifically, when using the L3 DDR (main) memory to share data between 
>> the A8 and PRU, it seems that rather than using the 256KiB size region 
>> starting at 0x9c94_ (on my BBB rev C) it seems to simply hardcode 
>> 0x8000_ and write away. See here:
>>
>> static int LOCAL_exampleInit () {
>>  void *DDR_regaddr;
>>  /* open the device */
>>  mem_fd = open("/dev/mem", O_RDWR);
>>  if (mem_fd < 0) {
>>   printf("Failed to open /dev/mem (%s)\n", strerror(errno));
>>   return -1;
>>  }
>>  /* map the memory */
>>  ddrMem = mmap(0, 0x0FFF, PROT_WRITE | PROT_READ, MAP_SHARED, mem_fd, 
>> DDR_BASEADDR);
>>  if (ddrMem == NULL) {
>>   printf("Failed to map the device (%s)\n", strerror(errno));
>>   close(mem_fd);
>>   return -1;
>>  }
>>  //FLush the flag locations of PRU0 and PRU1
>>  DDR_regaddr = ddrMem;
>>  *(unsigned long*) DDR_regaddr = 0x00;
>>  DDR_regaddr = ddrMem + 0x4;
>>  *(unsigned long*) DDR_regaddr = 0x00;
>>  return(0);
>> }
>> I can understand how this might work "by accident" if these first eight 
>> bytes in DDR are not used. But that's not a good example. Questions: 1) Is 
>> there some "magic" to this physical memory location that I'm missing out 
>> on? Or am I mis-reading the code, and it is *not* just writing to physical 
>> memory 0x0-0x7? 2) Is it correct that the actual DDR physical memory region 
>

Re: [beagleboard] Re: Is there a way to send an interrupt from userspace to the PRU-ICSS?

[ags]

@William Hermans like you I won't be able to dig into the gory details of 
loading Linux. This is an interesting read (albeit high-level and prompting 
more questions). I think I can say a few things without understanding all 
the details:

It is correct (from detailed reading of the TI TRM) that 0x8000 is the 
physical memory address of the L3 DDR.
If Linux is leaving any physical memory unmapped, unused - that's a shame. 
Wasted precious resource.
The PRUSS UIO driver allocates memory and exposes the physical address in 
userspace. If this is not used, it is also a precious wasted resource.

Now comes the subjective stuff:

I'm going to presume that Linux isn't stupid, and not count on it leaving 
permanently-allocated and undocumented physical memory addresses available 
for those that know the secret handshake.
I will use the memory allocated by the PRUSS UIO driver to communicate 
between userspace the PRUICSS.

If someone from TI/BeagleBoard.org responds with clarification on where I'm 
incorrect, I'll adjust my position. As of now, for over two  years I've 
been asking this same question and gotten no definitive response. Anyone 
know who came up with the the am335x_pru_package examples?

Thanks for your input and replies. Much appreciated.

On Friday, March 10, 2017 at 7:30:25 PM UTC-8, William Hermans wrote:
>
> Here is another link that should explain it clear enough. 
> http://processors.wiki.ti.com/index.php/HOWTO_Change_the_Linux_Kernel_Start_Address#Modifying_memory.h
>
> So I would say that it is not by accident that the base address of 
> 0x800 works. In fact, if you think about it a little bit. . Read the 
> opening paragraph labeled "purpose", and replace "DSP" with "PRU", for all 
> intents and purposes. of this discussion.
>
>
> On Fri, Mar 10, 2017 at 7:59 PM, William Hermans <yyr...@gmail.com 
> > wrote:
>
>> OK, according to some dicumentation I was able to find quickly, address 
>> 0x800 is the base address for the start of the DDR memory on the TI EVM 
>> board. Which is very similar to the beaglebone in memory layout.
>>
>> On Fri, Mar 10, 2017 at 7:38 PM, William Hermans <yyr...@gmail.com 
>> > wrote:
>>
>>> Thinking on it for a little longer, I almost want to say that the 
>>> Address 0x800h is actually the start of Linux's virtual memory map. But 
>>> I'm not 100% sure.
>>>  I'm doing my own research for a paying project, so can't really dive 
>>> into documentation for something else right now . . .
>>>
>>> On Fri, Mar 10, 2017 at 7:24 PM, William Hermans <yyr...@gmail.com 
>>> > wrote:
>>>
>>>>
>>>>
>>>> On Fri, Mar 10, 2017 at 2:53 PM, ags <alfred.g...@gmail.com 
>>>> > wrote:
>>>>
>>>>> I've had a hard time getting any definitive responses to questions on 
>>>>> the subject of memory access & latency. It is true that the PRU cores 
>>>>> have 
>>>>> faster access to DRAM that is part of the PRU-ICSS (through the 32-bit 
>>>>> interconnect SCR) - though not single-cycle - than to system DDR. 
>>>>> However, 
>>>>> the ARM core accesses DDR through L3 fabric, but the PRU-ICSS through 
>>>>> L4FAST, so I'm thinking that it can access DDR faster than PRU-ICSS 
>>>>> memory.
>>>>>
>>>>> I've also asked about differences in latency/throughput/contention 
>>>>> comparing PRU-ICSS 12KB shared RAM v the 8KB data RAM. No response. Since 
>>>>> both 8K data RAM is accessible to both PRU cores, I'm not sure what the 
>>>>> benefit of the 12KB shared RAM is (thought I imagine there is, I just 
>>>>> can't 
>>>>> figure it out).
>>>>>
>>>>> Lastly - and even more importantly - is total agreement that you have 
>>>>> to be careful about accessing any memory correctly. I have posted several 
>>>>> times asking about the am335x_pru_package examples (using UIO). In at 
>>>>> least 
>>>>> one (
>>>>> https://github.com/beagleboard/am335x_pru_package/blob/master/pru_sw/example_apps/PRU_PRUtoPRU_Interrupt/PRU_PRUtoPRU_Interrupt.c),
>>>>>  
>>>>> there is hardcoded use of the first 8 bytes of physical memory at 
>>>>> 0x8000_. I don't see how that can be OK. It may be that I don't know 
>>>>> some secrets of Linux internals, but from a theoretical perspective, I 
>>>>> just 
>>>>> don't know how one can make the assumption that any part of main memory

Re: [beagleboard] Re: Is there a way to send an interrupt from userspace to the PRU-ICSS?

[ags]

I've had a hard time getting any definitive responses to questions on the 
subject of memory access & latency. It is true that the PRU cores have 
faster access to DRAM that is part of the PRU-ICSS (through the 32-bit 
interconnect SCR) - though not single-cycle - than to system DDR. However, 
the ARM core accesses DDR through L3 fabric, but the PRU-ICSS through 
L4FAST, so I'm thinking that it can access DDR faster than PRU-ICSS memory.

I've also asked about differences in latency/throughput/contention 
comparing PRU-ICSS 12KB shared RAM v the 8KB data RAM. No response. Since 
both 8K data RAM is accessible to both PRU cores, I'm not sure what the 
benefit of the 12KB shared RAM is (thought I imagine there is, I just can't 
figure it out).

Lastly - and even more importantly - is total agreement that you have to be 
careful about accessing any memory correctly. I have posted several times 
asking about the am335x_pru_package examples (using UIO). In at least one 
(https://github.com/beagleboard/am335x_pru_package/blob/master/pru_sw/example_apps/PRU_PRUtoPRU_Interrupt/PRU_PRUtoPRU_Interrupt.c),
 
there is hardcoded use of the first 8 bytes of physical memory at 
0x8000_. I don't see how that can be OK. It may be that I don't know 
some secrets of Linux internals, but from a theoretical perspective, I just 
don't know how one can make the assumption that any part of main memory is 
not in use by another process unless it is guaranteed by the kernel.

On Wednesday, March 8, 2017 at 4:14:56 PM UTC-8, William Hermans wrote:
>
>
>
> On Wed, Mar 8, 2017 at 4:34 PM, ags <alfred.g...@gmail.com > 
> wrote:
>
>> Correct - to preserve deterministic execution, the PRU cannot be 
>> asynchronously interrupted. Polling (of some form) is required.
>>
>> Back to the OP, there is a way to register a (non-async) interrupt with 
>> the PRU. One can force a system interrupt (any one of the 64 that the PRUSS 
>> recognizes) by setting a bit in the Interrupt Status Register. From 
>> userspace it looks just like writing to the PRU DRAM since it's just 
>> writing a value to mmap()'d physical address. The advantage over what's 
>> been discussed here is that depending on how it's set up, it could be 
>> faster than polling from DRAM. I will have to implement to provide actual 
>> measurements.
>>
>
> So I remember asking Charles, some time ago, if it would be more efficient 
> writting to DRAM, or to one of the shared memory area for the PRU. From the 
> ARM side of things. I think perhaps in this case, writing to one of the 
> PRU's memory area's might be more efficient. In this one case. My reasoning 
> here is that through userspace, one would have to write out to memory 
> through /dev/mem/ anyhow. So why not make that to a memory location where 
> the PRU has single cycle read speeds ? One *would* have to take extra care 
> to make sure this memory location is correct, but no more so than writing 
> into DRAM. . . .
>
> Something to think about anyhow.
>

-- 
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/17e13ff7-4418-4058-9433-f30726d3d922%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Is there a way to send an interrupt from userspace to the PRU-ICSS?

[ags]

Correct - to preserve deterministic execution, the PRU cannot be 
asynchronously interrupted. Polling (of some form) is required.

Back to the OP, there is a way to register a (non-async) interrupt with the 
PRU. One can force a system interrupt (any one of the 64 that the PRUSS 
recognizes) by setting a bit in the Interrupt Status Register. From 
userspace it looks just like writing to the PRU DRAM since it's just 
writing a value to mmap()'d physical address. The advantage over what's 
been discussed here is that depending on how it's set up, it could be 
faster than polling from DRAM. I will have to implement to provide actual 
measurements.

On Wednesday, March 8, 2017 at 2:14:15 PM UTC-8, Justin Pearson wrote:
>
> According to this 2015 video from the Embedded Linux Conference, the PRU 
> does not support asynchronous interrupts:
>
> https://youtu.be/plCYsbmMbmY?t=22m6s
>
> I think there is some sort of PRU interrupt queue, but it does not 
> interrupt the PRU's execution. Your PRU code must explicitly monitor the 
> PRU interrupt queue to check for an interrupt.
>
> Alternatively, I've used a method for ARM/PRU coordination that is similar 
> to what William Hermans described: when the ARM CPU wants to trigger 
> something on the PRU, it writes a 1 to the bottom byte of the PRU data RAM. 
> The PRU continuously monitors this bottom byte to watch for a change. 
>
> -Justin
>
>
> On Wednesday, March 8, 2017 at 8:18:48 AM UTC-8, William Hermans wrote:
>>
>>
>>
>> On Wed, Mar 8, 2017 at 9:04 AM, William Hermans <yyr...@gmail.com> wrote:
>>
>>> For the purpose of this discussion with ags, I do not think the actual 
>>> definition of what an interrupt is, is quite so important, as much as how 
>>> to achieve an end goal. On a single threaded "system", I also do not think 
>>> asynchronous is really ever a factor. But I usually do tend to view 
>>> interrupts as prioritized, and preemptive.
>>>
>>
>> Additionally, what I proposed, should not interfere with system 
>> interrupts much, if at all. But should complete the task as fast as the 
>> system would allow, and is blocking in nature.
>>
>> One thing I did not mention however, is that even though my idea is 
>> blocking in nature, you can give processor back to the system by using 
>> sleep(), or usleep(). Instead of continuously polling to the point that 
>> you're keeping the processor so busy, it has little time to do anything 
>> else.
>>
>> In my use case, I think I used usleep() with a value of 10,000, which 
>> seemed responsive enough for my purpose, and only used 1-3% processor 
>> time.  
>>
>>

-- 
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/ed8bd90f-9265-4002-b9a7-fcde916b2e50%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Is there a way to send an interrupt from userspace to the PRU-ICSS?

[ags]

I see what you are saying. But (from what I've read) it seems that many 
would also say that you can't *receive* interrupts in userspace. I guess 
that's technically true, but uio does provide a way, through sysfs, to 
determine if an interrupt was fired.

Also from what I've read (I've been doing a lot of reading...) I thought 
that remoteproc was using mailboxes to communicate from userspace to the 
PRU - and was wondering if this "reverse-direction" interrupt mechanism 
couldn't also be supported by drivers (say, by writing to /dev/uio - 
analogous to select()/poll() on /dev/uio to detect an interrupt.

Granted, after going through all that machinery, it may well be faster to 
just set a bit in PRU memory and have PRU poll.

If this is just nonsense, even in theory, then I'd welcome an education as 
to why.

On Tuesday, March 7, 2017 at 8:52:27 PM UTC-8, William Hermans wrote:
>
>
>
> On Tue, Mar 7, 2017 at 9:45 PM, ags <alfred.g...@gmail.com > 
> wrote:
>
>> The mechanism for generating an interrupt from a PRU to the A8 (host) is 
>> well-documented. Is there a way to send an interrupt (one of the 64 system 
>> interrupt events documented in the PRU-ICSS literature) from userspace?
>>
>
> No, there are no such things as userspace interrupts, period. 
>
>>
>> From reading the TI documentation, the only two that seem to be 
>> candidates are two "mailbox" interrupts. I  recall reading something about 
>> a version of the remoteproc (or RPMsg, or virtio) drivers that utilized 
>> these mailboxes, but ultimately abandoned them as they are not available on 
>> all platforms. (that may be incorrect).
>>
>> Setting a flag in PRU DRAM or shared RAM is clearly a method that will 
>> work. However, it appears that polling DRAM or shared RAM is a multi-clock 
>> task; if a PRU system interrupt can be generated, it can be polled in one 
>> clock by examining R31 bits 30/31 (if configured correctly). Is this 
>> possible?
>>
>
> I get the feeling however that you're misunderstanding the purpose of an 
> interrupt. An interrupt is a way for hardware to let software know, 
> something has happen that may require attention. Either way you wold 
> probably be better off thinking in the context of setting a bitfield, or in 
> this case, a single bit.
>

-- 
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/f49b6ac0-7cc8-467c-8fcf-3060b65dec05%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Is there a way to send an interrupt from userspace to the PRU-ICSS?

[ags]

The mechanism for generating an interrupt from a PRU to the A8 (host) is 
well-documented. Is there a way to send an interrupt (one of the 64 system 
interrupt events documented in the PRU-ICSS literature) from userspace?

>From reading the TI documentation, the only two that seem to be candidates 
are two "mailbox" interrupts. I  recall reading something about a version 
of the remoteproc (or RPMsg, or virtio) drivers that utilized these 
mailboxes, but ultimately abandoned them as they are not available on all 
platforms. (that may be incorrect).

Setting a flag in PRU DRAM or shared RAM is clearly a method that will 
work. However, it appears that polling DRAM or shared RAM is a multi-clock 
task; if a PRU system interrupt can be generated, it can be polled in one 
clock by examining R31 bits 30/31 (if configured correctly). Is this 
possible?

-- 
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/220a52c3-cc09-4868-b35a-3b8b3ebc7f7c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Are the am335x_pru_package examples incorrectly (dangerously) accessing DDR memory?

[ags]

I have been able to load/start/run/stop a PRU core from 4.4.30-ti-r64 using 
just the uio_pruss (& uio) drivers, without any of the prussdrv code. Big 
milestone in my project.

A long time ago I asked a question about the examples in the pru here: 
https://groups.google.com/d/topic/beagleboard/Kv03QMsgOmo/discussion

as did someone else 
here: https://groups.google.com/d/topic/beagleboard/vnZ9eSzoo6Y/discussion

but I found no answer to help me. From a thorough review of the examples in 
the am335x_pru_package (using the prussdrv uio-based pru driver) 
here: 
https://github.com/beagleboard/am335x_pru_package/blob/master/pru_sw/example_apps/PRU_PRUtoPRU_Interrupt/PRU_PRUtoPRU_Interrupt.c

it *appears* to me that this example (to teach/illustrate proper use of pru 
in the BB family) works only by luck - or taking advantage of some bit of 
information that is undocumented (from my research).

Specifically, when using the L3 DDR (main) memory to share data between the 
A8 and PRU, it seems that rather than using the 256KiB size region starting 
at 0x9c94_ (on my BBB rev C) it seems to simply hardcode 0x8000_ 
and write away. See here:

static int LOCAL_exampleInit () {
 void *DDR_regaddr;
 /* open the device */
 mem_fd = open("/dev/mem", O_RDWR);
 if (mem_fd < 0) {
  printf("Failed to open /dev/mem (%s)\n", strerror(errno));
  return -1;
 }
 /* map the memory */
 ddrMem = mmap(0, 0x0FFF, PROT_WRITE | PROT_READ, MAP_SHARED, mem_fd, 
DDR_BASEADDR);
 if (ddrMem == NULL) {
  printf("Failed to map the device (%s)\n", strerror(errno));
  close(mem_fd);
  return -1;
 }
 //FLush the flag locations of PRU0 and PRU1
 DDR_regaddr = ddrMem;
 *(unsigned long*) DDR_regaddr = 0x00;
 DDR_regaddr = ddrMem + 0x4;
 *(unsigned long*) DDR_regaddr = 0x00;
 return(0);
}
I can understand how this might work "by accident" if these first eight 
bytes in DDR are not used. But that's not a good example. Questions: 1) Is 
there some "magic" to this physical memory location that I'm missing out 
on? Or am I mis-reading the code, and it is *not* just writing to physical 
memory 0x0-0x7? 2) Is it correct that the actual DDR physical memory region 
that is allocated by the uio driver is properly determined by examining 
/sys/class/uio/uio/maps/map1/{addr,size}? If not, how? I think this is 
useful information that would be helpful to others if provided. Perhaps 
even an update to the example, if my assertions are correct.

-- 
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/54e7aca4-5dc6-405a-a2ab-d6ea3718a562%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] help using uio_pruss with 4.4.30-ti-64

[ags]

@RobertCNelson

I found and followed (mostly) the instructions you previously provided 
here: https://groups.google.com/forum/#!msg/beagleboard/l59Dx8ygxNg/GvIzOJSzDAAJ
and I am now able to mmap the PRU memory and read/write to it. Loading PRU 
instructions comes next, and then finally pinmuxing and bit-banging.

I believe it is the uio_pruss driver that creates the /dev/uio devices, 
which are necessary to be able to respond to interrupts from the PRU 
(correct me if this wrong).
However, I don't think this prevented me from accessing the PRU memory 
resources though (?). I searched on the system error messages received 
before I properly enabled the PRUSS and there was discussion of them 
resulting from not having clocks enabled.

I'm assuming that another effect of enabling the PRUSS in the dt is 
enabling the clocks. I see an  pruss_ocp_gclk child node in the 
l4_wkup@44c0 
node. Is there another way to enable the clocks through the device tree?

Finally, following the directions above was close to what I had been trying 
to do on my own (except I was not blacklisting the remoteproc drivers, 
another problem). When I tried to compile the dts I had created, dtc 
complained about not being able to parse the dts file. So I ended up 
cloning your dtb-rebuilder repo - but I have no idea why it was needed. I 
had exactly the same *.dts files and had made mostly the same changes 
(instead of including a *.dtsi to enable the PRUSS, I had done so inline in 
my version of the am335x-boneblack.dts). So I tried building a dtb file 
from the same source as make used in the dtb-rebuilder install - and it 
also gave the same error.

So why is dtb-rebuilder needed, and what is the "magic" that's happening to 
have dtc parse the dts files?

BTW, I did not move to the bone kernel but stayed wit the ti kernel. Not 
sure what the differences are between them.

On Thursday, March 2, 2017 at 9:04:52 AM UTC-8, RobertCNelson wrote:
>
> On Wed, Mar 1, 2017 at 11:42 PM, ags <alfred.g...@gmail.com > 
> wrote: 
> > uname -a 
> > 
> > Linux BBBr0C0-1 4.4.30-ti-r64 #1 SMP Fri Nov 4 21:23:33 UTC 2016 armv7l 
> > GNU/Linux 
> > 
> > 
> > I am trying to use uio_pruss driver with PRUs. I have been able to make 
> them 
> > work "the old way" with 3.8 kernel, which (IIRC) used brute-force 
> /dev/mem 
> > and interrupts exposed through /dev/uio*. 
> > 
> > 
> > I have loaded the PRU cape to enable the PRUs. I have confirmed that I 
> have 
> > loaded the uio_pruss.ko 
> > 
> > 
> > I still don't see any uio* devices. 
> > 
> > 
> > Is there a "how-to" for the 4.4-ti kernel? I've read extensively here, 
> but 
> > not found definitive answers. It seems much of the content is in 
> debating 
> > the pros/cons of the remoteproc/uio differences. 
> > 
> > 
> > My application will require reading data from eMMC/SDcard (ARM 
> > core/userspace) and sending to PRUs for bitbanging output. I plan to 
> have 
> > the PRU use interrupts to indicate readiness for more data (in PRU 
> shared 
> > memory). Based on what I've read, this is a good application for the uio 
> > drivers. 
> > 
> > 
> > Any help/pointers to information that is current/usable for the 4.4-ti 
> build 
> > would be greatly appreciated. 
>
> Just use the v4.4.x-bone kernel: 
>
> cd /opt/scripts/tools/ 
> git pull 
> sudo ./update_kernel.sh --bone-kernel --lts-4_4 
>
> uio_pruss is enabled by default, it's up to you to load the overlay 
> with the pinmux'ing... 
>
> 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/ab6dd3fc-e6f5-4ae8-adf7-54bcc5a60049%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] why is pinmux-helper needed?

[ags]

On Saturday, March 4, 2017 at 5:56:04 AM UTC-8, Charles Steinkuehler wrote:
>
> On 3/3/2017 10:04 PM, ags wrote: 
> ...
> > *I haven't tried it (don't want to damage hardware) but does this mean 
> that 
> > directly poking at the GPIO registers from userspace with /dev/mem & 
> mmap() 
> > won't work? 
> > *if this is correct so far, what prevents loading a series of cape 
> overlays that 
> > change the configuration of a pin with this "old" style of pinmux 
> control? 
>

Using the "old" method, why can't cape overlays be repeatedly used to 
reconfigure pins? (Not that it is a better
method than the universal cape and config-pin utility - just that I must be 
missing something
important in understanding how this works). 

>
> In the "old days", you could do this if you were root.  Now I believe 
> the hardware configuration register space is setup with memory 
> protections so you have to access it from kernel space or you get an 
> exception.  You can still work around this if you're root by playing 
> "tricks" (you can use something like the DMA engine or PRU to write 
> values to the pinmux registers, bypassing the MMU). 
>
> If I map these IO configuration registers using /dev/mem and access, am I 
not enlisting the kernel (with it's privileges)?
(If this opens up an entirely new topic on memory access and user space, 
let'd defer to avoid further scope creep)

> 3) this is where things start being less clear to me: I think I was just 
> > understanding pinmuxing; now I see devices with properties "pinctrl-0;" 
> with no 
> > value. Is that because the devices no longer "own" their pins, but the 
> > config-pin driver does? 
>
> Not every device need to manage pins.  Some devices don't have any 
> pins (a DMA controller, cryptographic acceleartor, etc) and sometime 
> the pins are already setup or are controlled by a different driver 
> (like the pinmux-helper driver). 
>
> OK, that makes sense. But then why is there a pinctrl-0 property at all 
(why not omit that property entirely)?
If the node is configuring a specific device, with it's own driver, then 
the driver could not
even look for that property, as there are no pins associated with the 
device.
Is this a way of reusing existing drivers and avoiding bloat of 
one-driver-per-device?
 

> > 4) the cape-universal node uses the "gpio-of-helper" driver, and 
> apparently has 
> > a node for each header pin, with a 3-tuple. It looks like {mode,?,0} but 
> that's 
> > a guess. I've searched, and found some examples from Pantelis Antoniou, 
> but no 
> > explanation. 
>
> The gpio-of-helper exports the GPIO pins so this doesn't have to be 
> done by the user.  The three values you are referring to describe a 
> particular GPIO pin.  The number of values needed, and their meaning 
> is device specific: 
>
> https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio.txt 
> <https://www.google.com/url?q=https%3A%2F%2Fwww.kernel.org%2Fdoc%2FDocumentation%2Fdevicetree%2Fbindings%2Fgpio%2Fgpio.txt=D=1=AFQjCNH6eOlIiqmOvmMZS_RimDCkCfpD5w>
>  
>
> Thanks, this is a great source of information - though hard to find some 
things in the hierarchy
(as someone that doesn't have enough experience to follow the structure 
without searching around.
ex: gpio-of-helper is not found under ./bindings/gpio. Where can I find 
that?).

If pins are exported using gpio-of-helper, are they then unavailable for 
direct use ("ownership"?)
by devices that are configured in the dt? For instance, if I want to enable 
a UART and configure (pinmux)
pins for it's exclusive use, do I need to modify the dt to not export those 
pins using gpio-of-helper?
Or will they coexist - but then could a user use config-pin and 'steal" 
those pins from the UART?
Has the dt "exclusive-use = ..." concept been deprecated as well?
 

> > Ultimately, I'd like to understand this so that I can create 
> mappings/dts on my 
> > own, rather than just relying on finding something that works offered by 
> someone 
> > else. 
>
> Read through the device tree binding documentation in the kernel 
> source.  It is also helpful to view the full working device tree from 
> your system.  You can take the binary device tree from /boot and 
> convert it into source with dtc.  Then instead of a bunch of dangling 
> references like , you can go to gpio3 and see what it is, which 
> will help you find it's documentation in the kernel's Documentation 
> directory. 
>
> I meant to include in the previous post that I am looking at a complete dt 
(I think) that
I extracted from the running system using the "dtc -I fs" option. 

> -- 
> Charles Stei

Re: [beagleboard] help using uio_pruss with 4.4.30-ti-64

[ags]

Robert, my hope is to learn through doing, and eventually have enough 
understanding of dt and enabling LKM/drivers so that I can maintain what I 
develop through kernel updates and the inevitable progress that will 
continue. So it's not just about getting things to work.

Would you kindly provide guidance, or point me to documentation I can study 
to understand the differences between the ti and bone kernels? 
Specifically, if there is information on how I can enable the uio_pruss 
driver that would be a good start.

I'm trying to take small steps. The first was simple /dev/mem and mmap() 
interface to PRUSS. I realize that I won't be able to get interrupts this 
way, but it's a first step validating my understanding (not relying on 
"driver magic"). What I'm seeing is that I cannot even read/write to the 
PRUSS data ram or shared ram. Searching on the error log messages seems to 
indicate the problem is that the PRUSS clock needs to be enabled. (I 
think). I suspect this is part of what the uio_pruss driver does?

Thanks.

On Thursday, March 2, 2017 at 9:04:52 AM UTC-8, RobertCNelson wrote:
>
> On Wed, Mar 1, 2017 at 11:42 PM, ags <alfred.g...@gmail.com > 
> wrote: 
> > uname -a 
> > 
> > Linux BBBr0C0-1 4.4.30-ti-r64 #1 SMP Fri Nov 4 21:23:33 UTC 2016 armv7l 
> > GNU/Linux 
> > 
> > 
> > I am trying to use uio_pruss driver with PRUs. I have been able to make 
> them 
> > work "the old way" with 3.8 kernel, which (IIRC) used brute-force 
> /dev/mem 
> > and interrupts exposed through /dev/uio*. 
> > 
> > 
> > I have loaded the PRU cape to enable the PRUs. I have confirmed that I 
> have 
> > loaded the uio_pruss.ko 
> > 
> > 
> > I still don't see any uio* devices. 
> > 
> > 
> > Is there a "how-to" for the 4.4-ti kernel? I've read extensively here, 
> but 
> > not found definitive answers. It seems much of the content is in 
> debating 
> > the pros/cons of the remoteproc/uio differences. 
> > 
> > 
> > My application will require reading data from eMMC/SDcard (ARM 
> > core/userspace) and sending to PRUs for bitbanging output. I plan to 
> have 
> > the PRU use interrupts to indicate readiness for more data (in PRU 
> shared 
> > memory). Based on what I've read, this is a good application for the uio 
> > drivers. 
> > 
> > 
> > Any help/pointers to information that is current/usable for the 4.4-ti 
> build 
> > would be greatly appreciated. 
>
> Just use the v4.4.x-bone kernel: 
>
> cd /opt/scripts/tools/ 
> git pull 
> sudo ./update_kernel.sh --bone-kernel --lts-4_4 
>
> uio_pruss is enabled by default, it's up to you to load the overlay 
> with the pinmux'ing... 
>
> 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/b755c40c-2dd3-4909-8fe7-fa86b13d2e52%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] why is pinmux-helper needed?

[ags]

Thank you for the reply. I am beginning to see how this could make things 
easier. If you will bear with me, I'd like to poke a little deeper, to 
further my understanding of exactly how this all works. I'll be referring 
specifically to the BBB, but if there are general embedded Linux 
implications feel free to expand.

TLDR; This got really long. The executive summary might be "can you point 
me towards resources that will help me further understand the new approach 
used by the universal cape and pinmux-helper/gpio-of-helper? (I've left the 
more detailed questions below if you have the patience & generosity to 
review and reply)


Is any of this incorrect/incomplete? -

1) pin configuration ultimately boils down to two steps, for every pin 
(ball on the SoC): what is it internally connected to (and operationally 
configured), and separately, controlling that function once connected.

2) specifying the function/connection and operation is what the 
"traditional" pinmux ("pinctrl-single") entries do. It is accomplished by 
setting values in GPIO control registers, which is just writing values to 
locations in the SoC memory mapped space (with pinmux child nodes using 
"pinctrl-single,pins" driver to specify offset from pinmux base address and 
mode selection, in 2-tuples for each pin being configured). It is a bit 
tricky because this requires privilege and thus a kernel driver (in kernel 
space/ring 0). The selection of function/connection is done by the "mode" 
bits (2:0) in the control register, and the operation by other bits 
(pullup/down, pull-enable, receiver enable, slew rate).

*I haven't tried it (don't want to damage hardware) but does this mean that 
directly poking at the GPIO registers from userspace with /dev/mem & mmap() 
won't work?
*if this is correct so far, what prevents loading a series of cape overlays 
that change the configuration of a pin with this "old" style of pinmux 
control?

3) this is where things start being less clear to me: I think I was just 
understanding pinmuxing; now I see devices with properties "pinctrl-0;" 
with no value. Is that because the devices no longer "own" their pins, but 
the config-pin driver does?
4) the cape-universal node uses the "gpio-of-helper" driver, and apparently 
has a node for each header pin, with a 3-tuple. It looks like {mode,?,0} 
but that's a guess. I've searched, and found some examples from Pantelis 
Antoniou, but no explanation.

Ultimately, I'd like to understand this so that I can create mappings/dts 
on my own, rather than just relying on finding something that works offered 
by someone else.




On Thursday, March 2, 2017 at 5:02:47 AM UTC-8, Charles Steinkuehler wrote:
>
> On 3/1/2017 11:00 PM, ags wrote: 
> > This may be a rudimentary linux/dt question, but doesn't the 
> pinctrl-single 
> > driver already support this? Couldn't one change the pin configuration 
> by 
> > loading a dtc overlay? 
>
> pinctrl-single provides a way to set pinmux values, but not a way to 
> switch between various sets of values. 
>
> And yes, you can change the pinmux values by loading a device tree 
> overlay, but you cannot do this repeatedly (ie: load several device 
> tree overlays in sequence that modify the same pin) and there is no 
> way to control individual pins without having individual device tree 
> overlays for each pin and separating the hardware drivers (ie: timer, 
> uart, etc) from the pinmux overlays.  If you do this, you have 
> basically recreated the cape-universal overlays as a series of many 
> small files instead of a single overlay (except you have to 
> load/unload overlays to change the pin muxing rather than just write 
> to a file in sysfs). 
>
> -- 
> Charles Steinkuehler 
> cha...@steinkuehler.net  
>

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

Re: [beagleboard] why is pinmux-helper needed?

[ags]

This may be a rudimentary linux/dt question, but doesn't the pinctrl-single 
driver already support this? Couldn't one change the pin configuration by 
loading a dtc overlay?

On Wednesday, March 1, 2017 at 12:26:56 PM UTC-8, john3909 wrote:
>
> You need to understand how the pins are configured when defined in the 
> devicetree. It is the driver that does the pin configuration as defined in 
> the devicetree. Without an associated driver, the pins defined in the 
> devicetree won’t do anything. When using PRU, there is no driver, so the 
> pins don’t get configured and hence that is why pinmux-helper is necessary.
>
> Regards,
> John
>
>
>
>
> On Feb 28, 2017, at 9:32 PM, ags <alfred.g...@gmail.com > 
> wrote:
>
> If there is a better place for this post please move - after all, pinmux 
> is for more than GPIO, right?
>
> I've been trying to figure out why pinmux-helper is needed. I've searched 
> and found initial RFC and followup in the early years (by Charles 
> Steinkuehler) and I understand the motivation (I think) as stated, but I 
> don't understand the basics behind the why.
>
> Before pinmux-helper was provided, wasn't it possible to use sysfs to 
> change pinmux and gpio settings for all exported pins? Weren't all pins 
> exported? (If not, couldn't exporting them all have been an alternate 
> solution?) And couldn't loading a device tree fragment be used to change 
> the current state? If changes to pin state were to be made frequently, I 
> can see how those methods would be cumbersome; however, isn't pin state 
> configuration something that is done rather infrequently, as it implies 
> that the BBB is being repurposed and connected to different hardware 
> (physically)?
>
> This question extends to config-pin utility, as well as the cape-universal 
> (and associated) dtb files. Wasn't all this possible already?
>
> Let me be clear that I'm not criticizing the work that has been done - 
> rather I'm trying to use the evolution of capes, cape manager, dtb, drivers 
> etc as a way of better understanding how the underlying drivers, device 
> trees, and sysfs controls work.
>
> -- 
> 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/6ae54709-0f14-4a73-a01b-6efd024f4525%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/beagleboard/6ae54709-0f14-4a73-a01b-6efd024f4525%40googlegroups.com?utm_medium=email_source=footer>
> .
> 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/091d2bde-d90c-4a3b-9653-82e0c27eb8b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] why is pinmux-helper needed?

[ags]

If there is a better place for this post please move - after all, pinmux is 
for more than GPIO, right?

I've been trying to figure out why pinmux-helper is needed. I've searched 
and found initial RFC and followup in the early years (by Charles 
Steinkuehler) and I understand the motivation (I think) as stated, but I 
don't understand the basics behind the why.

Before pinmux-helper was provided, wasn't it possible to use sysfs to 
change pinmux and gpio settings for all exported pins? Weren't all pins 
exported? (If not, couldn't exporting them all have been an alternate 
solution?) And couldn't loading a device tree fragment be used to change 
the current state? If changes to pin state were to be made frequently, I 
can see how those methods would be cumbersome; however, isn't pin state 
configuration something that is done rather infrequently, as it implies 
that the BBB is being repurposed and connected to different hardware 
(physically)?

This question extends to config-pin utility, as well as the cape-universal 
(and associated) dtb files. Wasn't all this possible already?

Let me be clear that I'm not criticizing the work that has been done - 
rather I'm trying to use the evolution of capes, cape manager, dtb, drivers 
etc as a way of better understanding how the underlying drivers, device 
trees, and sysfs controls work.

-- 
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/6ae54709-0f14-4a73-a01b-6efd024f4525%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[ags]

tl;dr

Is it correct that whenever the PRU cores access any resource through the 
32-bit system but, it is subject to varying delay since the other PRU core 
and even the ARM core (through the OCP slave, for instance if the ARM is 
pushing data to the PRU 8k or 12k DRAM) may also be contending for control 
of that bus?

-- 
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/7b012852-4391-4fe7-abb9-141a641fe285%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[ags]

I have a project down the road that will require fast writes from PRU to 
ARM/system DRAM. But I'm not there yet.

For this project, my focus is on reading data (from SD card, eMMC, USB 
stick, network, etc) into DDR and then pushing it to the PRUs and then 
bit-bang out precise timing (using EGP). I am trying to avoid external 
circuit support and thus need deterministic timing. That's what got me very 
interested in the BBB. Perhaps others as well - what a great, low-cost, 
small-footprint combination of the scope/breadth/content/flexibility of 
Linux with these embedded real-time units.

Eventually it dawned on me that there will be some 
latency/non-deterministic timing unless I use the PRUs completely 
fenced-off from the system (ARM, DDR, etc). So I'm trying to identify 
when/where that non-determinism can occur (and conversely, where it cannot).

When I referenced "shared DRAM" I was sloppy, thinking it was clear in the 
context. I mean the 12k shared DRAM that is part of the PRU-ICSS. I see 
that, or the (2) individual 8k DRAMs as the "portal" to the ARM core (along 
with interrupts). I haven't coded it yet, but I think I'm pretty clear on 
pushing the data from userland to the PRUs (mmap() & /dev/mem as was 
offered above). I already have a use planned for the three scratchpad areas 
and using the broadside interface for single-instruction transfers. They 
appear to not be subject to any conflict other than the other PRU.

The point I'm trying to make is that from the TRM, it appears there is the 
possibility of some non-deterministic latency whenever using anything 
connected to the 32-bit PRU-ICSS bus. That is because the system (ARM) can 
access that bus through the OCP slave - and it will have to do that if it's 
going to be pushing data to the 12k or 8k PRU-ICSS DRAM. I think I can 
manage that (using interrupts to trigger the ARM to write the data and not 
start any timing critical steps until I can determine that write is 
complete). But when thinking this through, the question it has raised is 
this:

If I have both PRUs executing, won't they be (potentially) competing for 
access to the single 32-bit PRU-ICSS bus each time they access their "own" 
8k DRAM or the "shared" 12k DRAM? Both PRUs can access all three of these 
memory locations, and the diagram seems to indicate there is only one path 
to them. And if this is true, then other than 12k being bigger than 8k, I 
don't see any advantage (or difference at all, other than having the same 
address in memory for either of the PRUs) between using the 12k or 8k DRAM 
from either PRU.

That's what I'm trying to verify, or be disabused of whatever mistake I've 
made.

To be specific, this is what I think will (can) happen:

ARM writing to 12k PRU shared DRAM can affect timing of PRU read/write to 
it's own 8k DRAM, the other PRU's 8k DRAM, as well as the 12k PRU-ICSS 12k 
shared DRAM
PRU0 reading/writing to either 8k DRAM or 12k DRAM can affect timing of 
PRU1 reading/writing to either 8K DRAM or 12k DRAM, even if the 
source/target of PRU0 is not the same as the source/target of PRU1
Any reads from system resources (through OCP master) are subject to stalls 
(e.g. peripherals, GPIO, ARM DDR)
Any writes to system resources (through OCP master) are also subject to 
stalls (but less likely) if the interconnect fabric has been saturated. (I 
was hoping I could get some rough idea of how much it takes to "saturate 
the interconnect fabric" - and do only writes contribute, or reads as well).

I will look at that BeagleLogic code and see if I can see how that was 
done. I'd still like to understand the underlying operation in more detail. 
Thanks.


On Friday, February 10, 2017 at 8:07:15 AM UTC-8, Charles Steinkuehler 
wrote:
>
> On 2/9/2017 8:42 PM, William Hermans wrote: 
> > 
> > But the point is really this. If you need to get data out of the PRU's 
> into 
> > userland Linux as quickly as possible. Maybe the way to pull that data 
> ot of the 
> > PRU's memory is from the ARM(Linux ) side of things ? 
>
> No, you want to have the PRU doing writes. 
>
> In modern systems, writes are fast (they can get posted so they 
> complete at the initiator side and can take their time working through 
> the various interconnect fabrics to make their way to their ultimate 
> destination).  Reads typically stall the initiator until the data is 
> received. 
>
> If you need to move data quickly from the PRU to the ARM, reference 
> the BeagleLogic code.  That moves data pretty much as quickly as the 
> hardware physically allows (which requires a kernel module): 
>
> https://github.com/abhishek-kakkar/BeagleLogic 
>
> -- 
> Charles Steinkuehler 
> cha...@steinkuehler.net  
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 

[beagleboard] Re: Microsoft Remote Desktop - stuck at "Negotiating Credentials"

[ags]

So I'm thinking that the problem is due to the upgrade to the newer Debian 
release. Any pointers to information that may be available pointing out 
potential differences in the releases in xrdp and how it authenticates?

-- 
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/9919ea7a-f703-4131-ab58-f9f8d7d55e57%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How to prevent flashing SD card image to eMMC?

[ags]

On Tuesday, February 14, 2017 at 1:55:16 PM UTC-8, RobertCNelson wrote:
>
> > I was able to mount the card without knowing the type, apparently mount 
> is 
> > smart enough to determine on its own. Does this mean that despite this 
> > capability, each /etc/fstab entry requires full type 
> specification? 
>
> Yet, you specified the partition number. 
>
> Ugh. Yes, I did. Point being (point taken) that partitioning on the SD 
card is unknowable, so no way to auto-mount the SD card. I suppose the 
first partition could be auto-mounted, but that may or may not be what is 
desired, so best to do nothing. Sorry I missed that obvious issue...
 

> >> /uEnv.txt is just for backwards compatibility with older eMMC images. 
> > 
> > 
> > This confused me (the image on the SD card is a new version, how can 
> > backwards compatibility be needed?) Not arguing, as you certainly are 
> > correct. Can a system running an older version from eMMC be used to boot 
> > from the SD card, requiring a read of the older format uEnv.txt? I'm 
> just 
> > grasping for an explanation with this. 
>
> Well, the am335x bootrom reads the eMMC first on poweron. Thus for 
> older versions of U-Boot in eMMC, the backwards compatibility is 
> needed. 
>
> Does that mean that it's not possible to boot a bone from SD card if there 
is no uboot in eMMC? Or is eMMC uboot needed to provide logic that 
overrides the bootrom search order, bypassing valid boot code that is found 
before reaching the SD card?

>
> >> > 3) If I understand correctly there is another FAT volume on the eMMC 
> as 
> >> > shipped, that is seen as a remote (FAT?) volume when the BBB is 
> >> > connected as 
> >> > a USB client. Is there any way to mount that for access from the bone 
> >> > directly? 
> >> 
> >> It's a raw image file, /var/local/*.img 
> >> 
> > Thanks for this (partial) answer (not sarcasm here). It required that I 
> do 
> > some research to fully understand your response, so I learned even more. 
> I 
> > had assumed it was a separate partition on the SD card, exposed by the 
> USB 
> > client. 
>
> It use to be it's own partition, but this led to other user issues, so 
> it was moved to an *.img file.  That file is also maintained by an apt 
> package, so updates can be pushed. 
>

Clever - particularly being able to push updates. 

>
> > Now I see that there is only one partition on the SD card, and these 
> > "file systems" presented by the USB interface are just image files, 
> which 
> > themselves can be mounted (if you know the magic, i.e. starting sector). 
> I 
> > never tried to modify this content when accessed through USB - I didn't 
> > realize it is read-only. (please correct me if any of this is wrong) 
>
> This will need more study. Thanks for the homework... :-)
 

> or just use losetup/kpartk: 
>
> #find free loop device 
> sudo losetup -f 
> /dev/loop0 
>
>
> sudo losetup /dev/loop0 beaglebone-getting-started-2017-01-25.img 
> sudo kpartx -av /dev/loop0 
>
> sudo mkdir disk 
> sudo mount /dev/mapper/loop0p1 disk/ 
>
> cd disk/ 
> ls -lh 
> total 90K 
> drwxr-xr-x 2 root root 2.0K Feb 14 15:50 App 
> -rwxr-xr-x 1 root root  288 Feb 14 15:50 autorun.inf 
> drwxr-xr-x 4 root root 2.0K Feb 14 15:50 Docs 
> drwxr-xr-x 5 root root 2.0K Feb 14 15:50 Drivers 
> -rwxr-xr-x 1 root root  41K Feb 14 15:50 LICENSE.txt 
> -rwxr-xr-x 1 root root  17K Feb 14 15:50 README.htm 
> -rwxr-xr-x 1 root root  428 Feb 14 15:50 README.md 
> drwxr-xr-x 2 root root 2.0K Feb 14 15:50 scripts 
> -rwxr-xr-x 1 root root  17K Feb 14 15:50 START.htm 
>
> 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/6520eaee-cc45-475f-8f1b-ae6909ee118a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How to prevent flashing SD card image to eMMC?

[ags]

On Tuesday, February 14, 2017 at 10:31:46 AM UTC-8, RobertCNelson wrote:
>
> ... 

> 1) Is there a reason that the SD card isn't in /etc/fstab to make 
> mounting 
> > simple for beginners - or auto-mounted? In other words, is that a bad 
> idea 
> > to be avoided? Perhaps an issue with trying to share a single image for 
> > SDcard and eMMC boooting? 
>
> There's no guarantee users would plug in a microSD with the exact same 
> configuration.. 


I was able to mount the card without knowing the type, apparently mount is 
smart enough to determine on its own. Does this mean that despite this 
capability, each /etc/fstab entry requires full type specification?

>
> > 2) On the image I downloaded and put on the SD card there is both 
> > /boot/uEnv.txt and /uEnv.txt. What is the reason/purpose for the 
> /uEnv.txt? 
> > I'm pretty sure I didn't create/copy it - it's totally different than 
> > /boot/uEnv.txt - from comments it looks like it aims to support older 
> > Angstrom/2014 Debian systems? 
>
> /uEnv.txt is just for backwards compatibility with older eMMC images. 
>

This confused me (the image on the SD card is a new version, how can 
backwards compatibility be needed?) Not arguing, as you certainly are 
correct. Can a system running an older version from eMMC be used to boot 
from the SD card, requiring a read of the older format uEnv.txt? I'm just 
grasping for an explanation with this. 

>
> > 3) If I understand correctly there is another FAT volume on the eMMC as 
> > shipped, that is seen as a remote (FAT?) volume when the BBB is 
> connected as 
> > a USB client. Is there any way to mount that for access from the bone 
> > directly? 
>
> It's a raw image file, /var/local/*.img 
>
> Thanks for this (partial) answer (not sarcasm here). It required that I do 
some research to fully understand your response, so I learned even more. I 
had assumed it was a separate partition on the SD card, exposed by the USB 
client. Now I see that there is only one partition on the SD card, and 
these "file systems" presented by the USB interface are just image files, 
which themselves can be mounted (if you know the magic, i.e. starting 
sector). I never tried to modify this content when accessed through USB - I 
didn't realize it is read-only. (please correct me if any of this is wrong)

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/9a74fd3f-e41f-4e10-be09-f1e1e9dcb362%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How to prevent flashing SD card image to eMMC?

[ags]

Well yes, I can mount and edit. It didn't occur to me that a card inserted 
after boot would be detected. Thanks for that advice. Following up with 
more on the topic:

1) Is there a reason that the SD card isn't in /etc/fstab to make mounting 
simple for beginners - or auto-mounted? In other words, is that a bad idea 
to be avoided? Perhaps an issue with trying to share a single image for 
SDcard and eMMC boooting?
2) On the image I downloaded and put on the SD card there is both 
/boot/uEnv.txt and /uEnv.txt. What is the reason/purpose for the /uEnv.txt? 
I'm pretty sure I didn't create/copy it - it's totally different than 
/boot/uEnv.txt - from comments it looks like it aims to support older 
Angstrom/2014 Debian systems?
3) If I understand correctly there is another FAT volume on the eMMC as 
shipped, that is seen as a remote (FAT?) volume when the BBB is connected 
as a USB client. Is there any way to mount that for access from the bone 
directly?

Thanks for the earlier response.

On Monday, February 13, 2017 at 11:05:33 AM UTC-8, RobertCNelson wrote:
>
> On Mon, Feb 13, 2017 at 1:02 PM, ags <alfred.g...@gmail.com > 
> wrote: 
> > I downloaded a new image onto an SD card and booted my BBB. I then 
> edited 
> > the /boot/uEnv.txt file to remove the comment from the last line to 
> enable 
> > flashing to the eMMC upon reboot. It worked as expected. 
> > 
> > Now I have an SD card with an image that I could use again as a backup 
> boot 
> > device - but I need to re-comment the flasher line. If I boot from the 
> SD 
> > card it will flash again (correct?). How can I get access to the 
> > /boot/uEnv.txt file on the SD card? Can I mount it somehow after booting 
> > from the eMMC? I tried to mount the SD card on a Mac to edit the file, 
> but 
> > only the FAT partition was accessible. 
>
>
> Just plug it in after it boots off the eMMC.. 
>
> 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/1579fe46-4624-4be2-a2dd-49695954dceb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Microsoft Remote Desktop - stuck at "Negotiating Credentials"

[ags]

I have a BBB A6A (2GB eMMC) running 3.8 kernel:


uname -a

Linux BBB-A6A-1 3.8.13-bone50 #1 SMP Tue May 13 13:24:52 UTC 2014 armv7l 
GNU/Linux


I now also have a BBB 0C0 (4GB eMMC) and BBBWireless, both running the 4.4. 
kernel:


uname -a

Linux BBB-WA5-1 4.4.30-ti-r64 #1 SMP Fri Nov 4 21:23:33 UTC 2016 armv7l 
GNU/Linux


Setup of the original BBB to support remote desktop (using xrdp) was 
smooth. I've tried to setup the same access (Microsoft Remote Desktop <-> 
BBB xrdp) with no luck.

Is there a different setup required on the BBB with the new kernel, and if 
so, what is it? It appears to be an access/authentication issue. When 
attempting to connect, I get a "Negotiating Credentials" message, which 
either hangs forever, or immediately terminates the connection attempt. I 
can ssh successfully into both of these new 'Bones.


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/4f4a008d-fc32-4fd1-885a-bf6a132d535b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[ags]

Continued review of documentation has caused me to wonder if I've missed a 
fundamental error in my thinking about what is and isn't deterministic when 
using the PRUs. The PRU-local 32-bit interconnect bus is itself a shared 
resource. If one PRU writes to its own DRAM, and the other PRU writes to 
its own DRAM, won't that potentially cause one to stall waiting for the 
other to complete (particularly with a burst load/store)? That would make 
the dual/triple porting of the shared DRAM also less valuable. If the PRUs 
are being used to get data from the ARM core/main memory and then bit bang 
pins, that too is subject to competition for control of the 32-bit bus. 
Does this make sense or am I still missing something?


-- 
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/08eeb938-f69a-498b-8a46-92fc9d48e99c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[ags]

That makes a lot of sense. Unfortunately, many things that make sense to me 
ultimately turn out to not be true. Does the definitive answer here lie 
with Gerald? I wonder if he (still) monitors this group...

Regarding the PRUSS I have many questions. I'm really trying to nail down 
the timing/latency/determinism of PRU execution and IO. Your work measuring 
latency of IO and # PRU clocks has been very helpful (Thank you for your 
posts). Still, I wish for validation of what has been measured with 
architectural/design detail. Much of the data available (even from TI) 
seems to be conflicting.


On Tuesday, February 7, 2017 at 8:12:08 PM UTC-8, Charles Steinkuehler 
wrote:
>
> On 2/7/2017 8:04 PM, ags wrote: 
> > I'm working on using the PRU for critical signal timing, paired with 
> userland 
> > code that loads data into the PRU local memory. 
> > 
> > I've done a lot of research learning about latency wrt local and system 
> > resources, L3/4 fabric delays, etc. In each case, I haven't seen any 
> difference 
> > in the read/write (load/store from the PRU sense) time (PRU cycles) 
> between the 
> > PRU core-specific 8k DRAM and the shared 12k DRAM. I also see that PRU0 
> can 
> > access PRU1's 8k DRAM, and vice versa. So in effect the 8k DRAM is also 
> shared 
> > between the two PRU cores. So other than providing more memory than the 
> 8k for 
> > each PRU core, why would one use the 12k DRAM? 
> > 
> > [Note: I haven't seen any posts measuring latency of load/store from one 
> PRU 
> > core to the other PRU core's DRAM. Could that be the advantage of the 
> 12k shared 
> > DRAM - same timing when being accessed by either PRU core? If both cores 
> are 
> > accessing either the shared 12k or core-specific 8k DRAM concurrently, 
> would 
> > that cause one to stall?] 
>
> The available TRM is a bit light on specifics, but I would expect the 
> 8K DRAM for each core is single port memory and is highly likely to 
> incur wait states if both PRU cores are trying to read from the same 
> memory bank.  I would expect the 12K shared memory to be at least 
> 2-port (so both PRUs could access it simultaneously without incurring 
> wait states) and possibly triple ported (so the ARM core could access 
> the memory without potential wait states). 
>
> ...and of course 12K is bigger than 8K!  :) 
>
> -- 
> Charles Steinkuehler 
> cha...@steinkuehler.net  
>

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

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

[ags]

I'm working on using the PRU for critical signal timing, paired with 
userland code that loads data into the PRU local memory.

I've done a lot of research learning about latency wrt local and system 
resources, L3/4 fabric delays, etc. In each case, I haven't seen any 
difference in the read/write (load/store from the PRU sense) time (PRU 
cycles) between the PRU core-specific 8k DRAM and the shared 12k DRAM. I 
also see that PRU0 can access PRU1's 8k DRAM, and vice versa. So in effect 
the 8k DRAM is also shared between the two PRU cores. So other than 
providing more memory than the 8k for each PRU core, why would one use the 
12k DRAM?

[Note: I haven't seen any posts measuring latency of load/store from one 
PRU core to the other PRU core's DRAM. Could that be the advantage of the 
12k shared DRAM - same timing when being accessed by either PRU core? If 
both cores are accessing either the shared 12k or core-specific 8k DRAM 
concurrently, would that cause one to stall?]

-- 
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/6c28095e-254d-444e-a75b-e9043495678b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: What are the safe power-down methods?

[ags]

Meaning - power is forcibly removed from the SoC, and eMMC (no orderly 
shutdown, just remove power and you get what you get, corruptions and all) 
but the PMIC does not get the memo so some rails are still live?

On Tuesday, June 24, 2014 4:53:09 PM UTC-7, RobertCNelson wrote:

 On Tue, Jun 24, 2014 at 6:50 PM, John Syn john...@gmail.com javascript: 
 wrote: 
  
  On 6/24/14, 2:52 PM, Robert Nelson robert...@gmail.com javascript: 
 wrote: 
  
 On Tue, Jun 24, 2014 at 4:51 PM, ags alfred.g...@gmail.com 
 javascript: wrote: 
  I will verify on my BBB. 
  
  What is the expected difference between a momentary button press and 
 an 
  8-second press? 
  
 an 8-second press is exactly the same as yanking the power plug out. 
  That is what I thought, but when I pressed the power button for 8 
 seconds, 
  all the LEDS are off, but the SYS_5V and 3V3B pins on the P9 connector 
 are 
  still powered. 

 yeah true.. we just talked about that in the other thread..  So in the 
 world of the eMMC, it's like we janked the power plug. ;) 

 Regards, 

 -- 
 Robert Nelson 
 http://www.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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: What are the safe power-down methods?

[ags]

I will verify on my BBB.

What is the expected difference between a momentary button press and an 
8-second press?


On Friday, June 13, 2014 6:11:03 PM UTC-7, ags wrote:

 I've read what documentation I could find about powering down the BBB. 
 Clearly shutdown -now in a ssh session is safe. Clearly pulling the power 
 is not.

 Pushing the power button momentarily does nothing. Documentation says that 
 software is needed to sense and respond to this action. I presume this 
 means that said software is not part of the Angstrom distribution that 
 shipped (before the switch to Debian). Pushing and holding the power button 
 does cause a power down.

 Question1: Is push-and hold of the power button a safe shutdown method, or 
 is it similar to just pulling the plug?
 Question2: If push-and-hold is not safe, has anyone (and distro) developed 
 the software necessary to sense a button push and initiate a safe power 
 down?


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

[beagleboard] What are the safe power-down methods?

[ags]

I've read what documentation I could find about powering down the BBB. 
Clearly shutdown -now in a ssh session is safe. Clearly pulling the power 
is not.

Pushing the power button momentarily does nothing. Documentation says that 
software is needed to sense and respond to this action. I presume this 
means that said software is not part of the Angstrom distribution that 
shipped (before the switch to Debian). Pushing and holding the power button 
does cause a power down.

Question1: Is push-and hold of the power button a safe shutdown method, or 
is it similar to just pulling the plug?
Question2: If push-and-hold is not safe, has anyone (and distro) developed 
the software necessary to sense a button push and initiate a safe power 
down?

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

Re: [beagleboard] A simple cape to prevent power-interrupt corruption?

[ags]

So perhaps all I'll need is a small battery (recharged when DC power is 
available) attached to the pads on the BBB, and some software. I am looking 
for an orderly shutdown when DC power is removed - the sole purpose of the 
battery is to provide power just until the BBB can be shutdown properly. No 
need to be monitoring for a wakeup event (just power back on when DC power 
is restored). Can you point me to any examples of how to monitor the DC 
status (through I2C as you say below or any other way) and initiate the 
shutdown? Thanks.

On Friday, May 9, 2014 10:12:58 PM UTC-7, Ron B. wrote:

 ...
 So, for the shutdown, the cape itself doesn't do anything since that's a 
 software issue.  But since DC power status is reported through a status 
 register over I2C, I used that in a bash script while toying with a 
 podcast car computer.  I haven't spent much time on it but it definitely 
 turns itself on and off with the car.  I guess the other option would be a 
 kernel module that monitors power good and initiates the shutdown...

 -Ron




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

[beagleboard] Re: How to find DDR physical address for passing data to/from pruss?

[ags]

A shortened version of this question, which I really want to understand for 
this specific project and as general learning for use of Linux in embedded 
systems:

What is the correct way to correctly use memory in userspace to access 
registers and memory used by device drivers (specifically the PRU in this 
case)?

Is the example provided correct, both the app_loader helper code and/or 
the example applications? They seem to be inconsistent with one another?

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

Re: [beagleboard] A simple cape to prevent power-interrupt corruption?

[ags]

Yes, I did find those. From what I read, it seems that both aim at allowing 
the BBB to run when there is no mains power. In my application, I don't 
have a need for the BBB to maintain functionality when there is no power 
(other than battery). I'm simply interested in ensuring a safe shutdown 
sequence when power is removed. It seems from both posts that this has 
still not been addressed. These methods are focused on keeping the BBB 
running on battery power; however, when the battery discharges, I saw no 
discussion about an orderly shutdown occurring. I'm looking for an 
immediate, but orderly shutdown, and don't care about sustaining operation 
(beyond a safe shutdown) when power is removed.



On Friday, May 9, 2014 7:56:01 AM UTC-7, Ron B. wrote:

 Have you seen this 
 posthttp://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/08/10/bbb--rechargeable-on-board-battery-systemand
  discussion?

 Personally, I went the full 
 capehttp://andicelabs.com/beaglebone-powercape/route because it gave me 
 more flexibililty for power-up events as well as a 
 very low power (~80uA) power off state.

 -Ron




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

Re: [beagleboard] A simple cape to prevent power-interrupt corruption?

[ags]

Is anyone aware of someone having already done this? I haven't found 
anything by searching.

On Wednesday, May 7, 2014 1:05:24 PM UTC-7, Gerald wrote:

 Yes it is possible.

 Gerald



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

[beagleboard] A simple cape to prevent power-interrupt corruption?

[ags]

I've read about capes that offer batteries to operate the BBB during power 
interruptions. I've read that there is a RTC in the SoC, but software does 
not support powering with a button cell. I see there is a PMIC onboard, as 
well as solder pads to allow attachment of a battery. I've also read that 
improperly powering-down the BBB can result in corrupt data/OS/eMMC/uSD.

My question: shouldn't it be possible to add just a tiny Li Ion battery 
using the solder pads, and with minor modifications (in userland?) sense 
when 5v power has been removed (USB client or 5v barrel jack), and then 
initiate an orderly, but immediate, shutdown? The small battery would be 
enough for the few seconds until full power down, preventing any memory 
corruption.

This seems so simple I must be missing something. My goal is to be able to 
have my BBB project on a timer. Power will be applied/removed based on a 
rough schedule, an external RTC will provide correct time, and cron will be 
used to run what's needed. When power is removed, the system would be 
properly stopped.

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

Re: [beagleboard] Re: Is memory spec in dts shipped with BBB A6A Angstrom 3.8.13 wrong?

[ags]

Thanks for the reply. I mostly wanted to verify that my understanding of dt 
is correct, and this was confusing. I was also hoping to learn something 
new (why was the specification in the  .dtb file no consistent with the 
actual memory being used) - which you've helped with by pointing out the 
role of u-boot in this (I know nothing about u-boot).

No need to change the .dtb on my behalf now that I understand. However, it 
may avoid future confusion for others if it is made consistent with the 
actual hardware configuration.

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

Re: [beagleboard] Re: Is memory spec in dts shipped with BBB A6A Angstrom 3.8.13 wrong?

[ags]

Can anyone explain how/why the dtc specification of memory size is not 
being used, and/or where the actual size is coming from?

On Friday, April 25, 2014 10:02:40 PM UTC-7, ags wrote:

 Not necessarily an issue. Originally I was wondering if only half of 
 available physical memory was being made available. Still, I'd like to 
 understand why the device tree bindings indicate 256 MB memory, yet it 
 appears that the full 512 MB are available.




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

Re: [beagleboard] Re: Is memory spec in dts shipped with BBB A6A Angstrom 3.8.13 wrong?

[ags]

Not necessarily an issue. Originally I was wondering if only half of 
available physical memory was being made available. Still, I'd like to 
understand why the device tree bindings indicate 256 MB memory, yet it 
appears that the full 512 MB are available.


On Thursday, April 24, 2014 7:23:51 AM UTC-7, RobertCNelson wrote:

 On Thu, Apr 24, 2014 at 9:13 AM, ags alfred.g...@gmail.com javascript: 
 wrote: 
  Any suggestions on where to look next to figure out what's going on 
 here? 
  Seems that either something other than the device tree in file 
  /boot/am335x-boneblack.dts is being read at boot, or there is 
 something 
  else that is overriding later on, or a boot parameter... or the memory 
  specification in the reg property doesn't work as I expect it to. 

 So... What issue are you having with it?  Other then the dts file 
 showing 256Mb and linux showing 512Mb available? 

 u-boot initializes the memory, the kernel just uses what's available. 

 Regards, 

 -- 
 Robert Nelson 
 http://www.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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Is memory spec in dts shipped with BBB A6A Angstrom 3.8.13 wrong?

[ags]

 Any suggestions on where to look next to figure out what's going on here? 
 Seems that either something other than the device tree in file 
 /boot/am335x-boneblack.dts is being read at boot, or there is something 
 else that is overriding later on, or a boot parameter... or the memory 
 specification in the reg property doesn't work as I expect it to.


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

[beagleboard] Re: Is memory spec in dts shipped with BBB A6A Angstrom 3.8.13 wrong?

[ags]

I don't see a dtsi in /boot. I did dtc -I dtb -O dts -o test.dts 
/boot/am335x-boneblack.dtb. Looking at test.dts I still see memory {... 
reg = 0x8000 0x1000 };
However, cat /proc/meminfo returns a first line of MemTotal: 510600 kB 
which seems OK - I suppose. It looks like /boot/am335x-boneblack.dtb is not 
what is used at boot time, or is being overridden somehow?
BTW, find / -name am335x-bone-common.dtsi -print found no such file on my 
BBB.

On Sunday, April 20, 2014 8:49:10 AM UTC-7, robert.berger wrote:

 Hi,

 I don't have access to my lab at the moment, so I can not try it myself, 
 but can you rebuild a fdt and make a change in am335x-bone-common.dtsi?

 Please also do:
 cat /proc/meminfo before and after the change?

 Just search for memory and replace it with:

   memory {
   device_type = memory;
   reg =  0x8000 0x2000 ;/* 512MB RAM */
   };


 Regards,

 Robert


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

Re: [beagleboard] Re: Is memory spec in dts shipped with BBB A6A Angstrom 3.8.13 wrong?

[ags]

On Sunday, April 20, 2014 1:05:03 PM UTC-7, robert.berger wrote:

 Which kernel version do you use? 

 The original installed on flash (shipped in Jan/Feb this year):

I have BBB A6A running Angstrom distro:
Linux beaglebone 3.8.13 #1 SMP Wed Sep 4 09:09:32 CEST 2013 armv7l 
GNU/Linux 

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

[beagleboard] Is memory spec in dts shipped with BBB A6A Angstrom 3.8.13 wrong?

[ags]

Really hard to categorize this.

I have BBB A6A running Angstrom distro:
Linux beaglebone 3.8.13 #1 SMP Wed Sep 4 09:09:32 CEST 2013 armv7l GNU/Linux

I'm working on using DDR to pass information back and forth to PRU, so 
looking at dts and memory assignment.

Either the dts (actually, dtb converted to dts using dtc) is wrong, or I 
don't really understand it as well as I thought, or I can't read hex any 
more...

The BBB ships with 512MB DDR3 RAM. That's 0x2000_. However, the dts(b) 
in /boot/am335x-boneblack.dtb has this entry:

memory { device_type = memory; reg = 0x8000 0x1000l; };

Am I missing something here, or is my bone setup to only use 256MB of the 
512MB available?

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

[beagleboard] How to find DDR physical address for passing data to/from pruss?

[ags]

I'm learning how to use the PRUSS, have most of it under control (or at 
least not stuck). I've followed the examples posted at 
github.com/beagleboard/am335x_pru_package.

Problem is understanding how to pass data in DDR. PRUSS data (shared or pru 
data) makes sense - just look at /sys/class/uio/uio0/maps/map0/addr to find 
the base (physical) address for the PRUSS and use the offsets in the global 
memory map to access data in the PRUSS. But what about using DDR? Examples 
in the package noted above use the magic number of 0x8000_1000 as the 
physical address for DDR for passing data. That seems to work in the 
examples, but how would one determine that programmatically? Is the 
uio_pruss kernel driver setting this up? If so, where is the connection to 
0x8000_1000?

My understanding is that /sys/class/uio/uio0/maps/map0/addr provides the 
physical address for the PRU (which does match the offset in the device 
tree for the pruss - 0x4a30_). Documentation for uio leads me to 
believe that /sys/class/uio/uio0/maps/map1/addr would provide the physical 
address of the next region mapped by the driver, which I would expect 
would be the DDR claimed by the uio_pruss kernel driver (the value is 
0x9cd0_). However, code in the example 
source PRU_memAcc_DDR_sharedRAM.c just uses hardcoded values of 0x8000_ 
for DDR base physical address and 0x_1000 for an offset, and using mmap 
on /dev/mem writes to that location. Likewise, the example 
assembly PRU_memAcc_DDR_sharedRAM.p hardcodes the 0x1000 offset as an 
immediate value loaded into the configurable constant register.

Further complicating understanding, the example loader code seems to ignore 
the ...map1/addr value when building its structure of addresses, instead 
just incrementing the value of ...map0/addr by one page (4096). Also, the 
mmap is not on /dev/mem but instead /dev/uio0.

Finally, I found this that looked 
promising: 
http://hipstercircuits.com/beaglebone-pru-ddr-memory-access-the-right-way/ 
but there is yet another magic number - in this case, subtracting 
0x1000_ from the physical address reported by ...map2/addr (apparently 
this is for the BBW, which had three memory regions (map1 is L3, map2 is 
DDR) and adding 0x1000_ to the size reported by ...map2/size, and mmap 
into /dev/mem.

So the questions are:
1) Is the uio_pruss kernel driver claiming DDR memory?
2) If so, how can I determine it's physical address?
3) Why use mmap on /dev/uio0 rather than /dev/mem?

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