[beagleboard] Re: BBE Industrial 1GB ram

['Luther Goh Lu Feng' via BeagleBoard]

Please share their reply when you receive it. I have their direct email and 
can share if they dont reply you

On Monday, January 7, 2019 at 10:24:05 PM UTC+8, mallets wrote:
>
> Their estimate shipping options has many countries missing, so that's what 
> I was basing it on. Contacted them through the form on their website and 
> waiting of a reply.
>

-- 
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/4f26f972-9fae-4575-a8fc-954b7c269f8e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Are PRUs really deterministic, and well documented, ant not obsolete...

['Mark Lazarewicz' via BeagleBoard]

That looks like old sdk infoIMO these PRU were added because there is  little 
free RTOS support(I don't consider linux realtime) for this chip for the 
hobbyist  hence you have these PRU(processors) that run bare bones programs 
loaded by the ARM and get something NOT bloated downwhich is what most hard 
realtime controllers can provide if you run barebones(the easiest way to 
calculate determinism) or run RTOS with interrupts(worst case timing required). 
In Avionics and other verified/certified environs you need determinism. I can 
tell you having worked in that industry no one runs linux the FCC cost to 
certify it would bankrupt you. I did work at one company that ran Integrity on 
the ARM used the DSP and the PRU unfortunately this costs big $$ here on this 
chip your SW support is this group  and if your app end use fits well with 
linux user model its great. I see the PRU as a TI  marketing to sell hard 
realtime users what you could get buying a non muticore processor and running 
it barebones. If you need all the features linux provides and some real time 
feature the PRU allows it. I will say they seem to have improved programming 
language and maybe even have  jtag support for PRU. Not sure about c source 
level debugging. The PRU used to be programmed mistly in assembler. You have 
the arm dump the program and twiggle gpios to debug.Unless you have many years 
of experience calculating determinism is complex even on simple one chip 
solutions and the fact you ask a question like this after choosing a SoC and 
reading some old docs makes me realize typing this was a waste of time.Is this 
your college assignment run something determinism on Linux?

Sent from Yahoo Mail on Android 
 
  On Tue, Jan 8, 2019 at 7:44 AM, 
daveyjohn...@gmail.com wrote:   Hi, I have read this 
nice ad for PRUs http://www.staroceans.org/documents/TI-sdk/spry264.pdf which 
states how deterministic the PRUs are, 

"each PRU has its own single-cycle I/O" etc. Then I wanted details... 

http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit "Content is 
no longer maintained and is being kept for reference only! "
http://processors.wiki.ti.com/index.php/PRU-ICSS "Please note as of Wednesday, 
August 15th, 2018 this wiki has been set to read only."
http://processors.wiki.ti.com/index.php/PRU_Read_Latencies "The PRU write 
instruction is a fire-and-forget command that executes in ~1 cycle"
that tilde...


"The read latency values at the following links are considered "best-case," 
accounting for the 2 cycle instruction and interconnect introduced latency".

best case

Possibly, there is some doc which states min/max execution times? Deterministic 
or not? etc, etc. Not found. Just not found.

---
I do not want to be pessimistic but neither I want to reverse-engineer 
these "deteministic" units, that do not really look that-deterministic. And 
that docs obsolete or missing??? What is it all about?






-- 
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/8976d66c-9bb4-40b9-aec9-b33874d42b99%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
  

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

[beagleboard] I have a problem with Buildroot

[Talha Ayrancı]

I encountered an error while trying build an image with Buildroot. What is 
the reason of this?

This is the error message on terminal :

...

>>>   Executing post-image script board/beaglebone/post-image.sh
INFO: cmd: "mkdir -p "/home/ubuntu/buildroot/output/build/genimage.tmp"" (
stderr):
INFO: cmd: "rm -rf "/home/ubuntu/buildroot/output/build/genimage.tmp"/*" (
stderr):
INFO: cmd: "mkdir -p "/home/ubuntu/buildroot/output/images"" (stderr):
INFO: cmd: "mkdir -p "/home/ubuntu/buildroot/output/build/genimage.tmp"" (
stderr):
INFO: cmd: "cp -a "/home/ubuntu/buildroot/output/target" "/home/ubuntu/
buildroot/output/build/genimage.tmp/root"" (stderr):
INFO: vfat(boot.vfat): cmd: "dd if=/dev/zero of="/home/ubuntu/buildroot/
output/images/boot.vfat" seek=16777216 count=0 bs=1 2>/dev/null" (stderr):
INFO: vfat(boot.vfat): cmd: "mkdosfs  '/home/ubuntu/buildroot/
output/images/boot.vfat'" (stderr):
INFO: vfat(boot.vfat): adding file 'MLO' as 'MLO' ...
INFO: vfat(boot.vfat): cmd: "mcopy -bsp -i 
'/home/ubuntu/buildroot/output/images/boot.vfat' 
'/home/ubuntu/buildroot/output/images/MLO' '::'" (stderr):
Syntax error at line 5 for drive A: column 9 in file /etc/mtools.conf: 
unrecognized 
keyword
INFO: vfat(boot.vfat): cmd: "rm -f "/home/ubuntu/buildroot/output/images/
boot.vfat"" (stderr):
ERROR: vfat(boot.vfat): failed to generate boot.vfat
Makefile:790: recipe for target 'target-post-image' failed
make: *** [target-post-image] Error 1

-- 
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/8c6b6fa9-aad6-4138-856a-d1a255cdcd1a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] I have a problem with Buildroot

[Talha Ayrancı]

I encountered an error while trying build an image with Buildroot. This is 
the error message on terminal :

...

>>>   Executing post-image script board/beaglebone/post-image.sh
INFO: cmd: "mkdir -p "/home/ubuntu/buildroot/output/build/genimage.tmp"" (
stderr):
INFO: cmd: "rm -rf "/home/ubuntu/buildroot/output/build/genimage.tmp"/*" (
stderr):
INFO: cmd: "mkdir -p "/home/ubuntu/buildroot/output/images"" (stderr):
INFO: cmd: "mkdir -p "/home/ubuntu/buildroot/output/build/genimage.tmp"" (
stderr):
INFO: cmd: "cp -a "/home/ubuntu/buildroot/output/target" "/home/ubuntu/
buildroot/output/build/genimage.tmp/root"" (stderr):
INFO: vfat(boot.vfat): cmd: "dd if=/dev/zero of="/home/ubuntu/buildroot/
output/images/boot.vfat" seek=16777216 count=0 bs=1 2>/dev/null" (stderr):
INFO: vfat(boot.vfat): cmd: "mkdosfs  '/home/ubuntu/buildroot/
output/images/boot.vfat'" (stderr):
INFO: vfat(boot.vfat): adding file 'MLO' as 'MLO' ...
INFO: vfat(boot.vfat): cmd: "mcopy -bsp -i 
'/home/ubuntu/buildroot/output/images/boot.vfat' 
'/home/ubuntu/buildroot/output/images/MLO' '::'" (stderr):
Syntax error at line 5 for drive A: column 9 in file /etc/mtools.conf: 
unrecognized keyword
INFO: vfat(boot.vfat): cmd: "rm -f "/home/ubuntu/buildroot/output/images/
boot.vfat"" (stderr):
ERROR: vfat(boot.vfat): failed to generate boot.vfat
Makefile:790: recipe for target 'target-post-image' failed
make: *** [target-post-image] Error 1



-- 
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/2d6fda8a-0609-41d0-8cb9-c5fdd8ed4954%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Are PRUs really deterministic, and well documented, ant not obsolete...

[Charles Steinkuehler]

The PRUs are mostly deterministic when accessing resources within the
local PRU-ICSS block.  The "mostly" comes from potential contentions
if you have both PRU cores accessing the same resource (eg: PRU0 and
PRU1 both trying to access the local UART) in which case one of the
PRU cores will stall briefly.

The PRUs are less deterministic when accessing resources outside the
PRI-ICSS block (eg: SDRAM or GPIO registers) where the transaction is
subject to synchronization delays, bus congestion on the L3/L4
interconnect, etc.

On 1/8/2019 6:48 AM, daveyjohn...@gmail.com wrote:
> Hi, I have read this nice ad for PRUs 
> http://www.staroceans.org/documents/TI-sdk/spry264.pdf which states how 
> deterministic the PRUs are, 
> 
> "*each PRU has its own single-cycle I/O*" etc. Then I wanted details... 
> 
> http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit "Content 
> is* no longer maintained and is being kept for reference only!* "
> 
> http://processors.wiki.ti.com/index.php/PRU-ICSS "Please note as of 
> Wednesday, August 15th, 2018 this wiki *has been set to read only*."
> 
> http://processors.wiki.ti.com/index.php/PRU_Read_Latencies "The PRU write 
> instruction is a fire-and-forget command that executes in *~*1 cycle"
> 
> *that tilde...*
> 
> 
> "The read latency values at the following links are *considered* 
> "best-case," accounting for the 2 cycle instruction and interconnect 
> introduced *latency*".
> 
> *best case*
> 
> Possibly, there is some doc which states min/max execution times? 
> Deterministic or not? etc, etc. 
> *Not found. Just not found.*
> 
> ---
> 
> I do not want to be pessimistic but neither I want to reverse-engineer 
> these "deteministic" units, that do not really look that-deterministic. And 
> that docs obsolete or missing??? What is it all about?
> 
> 
> 
> 


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

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

Re: [beagleboard] Same Exact Image booting on BeagleBone Black but doing NOTHING on PocketBeagle

[gr . ourumov]

BeagleBoard.org Debian Image 2018-03-05
Kernel is vmlinuz-4.9.82-ti-r102


On Tuesday, January 8, 2019 at 3:52:35 PM UTC+1, RobertCNelson wrote:
>
> On Tue, Jan 8, 2019 at 8:49 AM > wrote: 
> > 
> > Hi, 
> > 
> > Due to corporate requirements we are modifying a Stretch Image from 
> beagleboard.org. Changes include: 
> > 
> > + Several capes have been added. 
> > + Different packages have been pre-installed. 
> > + Configurations. 
> > 
> > 
> > So far, we were working with BBB without any problems. Image ran fine 
> and without problems. 
> > 
> > 
> > 
> > Last week, we started to play with the PocketBeagle. We first used our 
> image and surprisingly it didn't DO ANYTHING. 
> > 
> > By anything I mean that even connected to serial, it reports nothing. 
> > 
> > 
> > Same image, on same card boots perfectly fine on a BBB but in the 
> PocketBeagle NOTHING. 
> > 
> > It doesn't even display the uboot loader message. 
> > 
> > 
> > 
> > 
> > First I thought that was due to the fact that we were using custom 
> capes. Then because of the version of the kernel (4.9.82)... But a 
> standalone image from beagleboard.org (with that same kernel) just boots 
> fine. 
> > 
> > I even tried replacing the entire boot directory... by the one of a 
> working image (with the same kernel of course)... but nothing. 
> > 
> > 
> > All those changes always report the same behaviour: 
> > 
> > They work flawlessly on the Beaglebone Black... But the PocketBeagle 
> does NOTHING. 
>
> Which image (aka the date identifer)? 
>
> 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/af16c787-2511-476a-b625-7fbfd7ba1e5e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: How to connect Beaglebone blue to *any* network, except a simple Wifi

[Alan Corey]

I like these little things, USB - wifi for under $5.  I have a few of the 
little ones like this, but more of the kind with gain antennas about 6 
inches long.  Mostly Realtek, one Ralink.  Some Linux versions don't have a 
decent driver for Realtek, but mostly just Armbian.

https://www.ebay.com/itm/F393-NEW-Realtek-RTL8188ETV-USB-150M-802-11b-g-n-n-Wireless-WiFi-mini-adapter-do/202555327846?epid=15027574714=item2f293d0566:g:kc4AAOSwckVcLWak:rk:6:pf:0

I'm not sure if I've ever plugged in 2 of them at once like if you wanted 
to make a hotspot that's fed by another network,.  I've been using Android 
phones as hotspots for several years, that's my only internet connection.  
Look at the man page for iwconfig for nitty-gritty details.  I have no 
experience with wpa, I run an open network (rural area).

This is old-school but I use an /etc/network/interfaces file that's just

auto lo
iface lo inet loopback
auto wlan0
iface wlan0 inet dhcp
  wireless-essid Moto_lte

For both Raspbian and Debian.  Your first wireless interface becomes 
wlan0.  You add a wired one like:

auto eth0
iface eth0 inet static
  address 192.168.0.59
  netmask 255.255.255.0
  network 192.168.0.0
  broadcast 192.168.0.255

Into the same file.  I like wifi better than I expected to.  It's not as 
fast as wired but it's a lot more convenient.  Unless you're running an 
embassy and the Russians are snooping into what you do with directional 
antennas to steal secrets.

 
On Monday, January 7, 2019 at 11:47:39 AM UTC-5, ith...@gmail.com wrote:
>
> Hi Tarmo, yes one of I like these little thingsthese pages with 
> instructions also informed that network-over-usb it is a non-recommended 
> struggle, which may not even survive a reboot.
>
> Thanks for informing me that a USB-Ethernet dongle will work though, I did 
> not know that.
>
> On Monday, January 7, 2019 at 5:37:02 PM UTC+1, Tarmo Kuuse wrote:
>
>> Hi!
>>
>> On Monday, 7 January 2019 18:17:01 UTC+2, ith...@gmail.com wrote:
>>>
>>> Firstly, via USB. I set a gateway on Beaglebone, but the desktop (host 
>>> Ubuntu) does not care. There are some instructions on the internet, 
>>> followed by "if does not work add use echo 1 > 
>>> /proc/sys/net/ipv4/ip_forward, a thing with iptables, whatever", it all did 
>>> not work, ping 8.8.8.8 on the bone does not work. Someone told that you 
>>> need to put the respective interface to a "trusted zone". I do not know 
>>> where I can found that zone. To add a VPN connection. "Add a VPN 
>>> connection" is grayed on my system.
>>>
>>> I did not want to touch wifi, because I would prefer beaglebone to be a 
>>> hotspot, but if it did not work with the cable...
>>>
>>> Firstly, there is "connman", to make it easier. I tried connman, but the 
>>> wifi network is enterprise tunneled double-authentication etc, connman just 
>>> prints "invalid arguments" when I try to connect. There is some 
>>> wpa-supplicant-like configuration file, added it as instructed, but no 
>>> effect, all I see is still "invalid arguments". No detailed error, no 
>>> problematic file, no problematic line, no list of these arguments, nothing, 
>>> just "invalid arguments".
>>>
>>> Lastly, there is wpa-supplicant itself. I made a respective file, but it 
>>> all starts and stops with
>>>
>>> $  wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -i wlan0
>>> Successfully initialized wpa_supplicant
>>> Could not read interface p2p-dev-wlan0 flags: No such device
>>> nl80211: Could not set interface 'p2p-dev-wlan0' UP
>>> nl80211: deinit ifname=p2p-dev-wlan0 disabled_11b_rates=0
>>> p2p-dev-wlan0: Failed to initialize driver interface
>>> P2P: Failed to enable P2P Device interface
>>>
>>> There is nothing about p2p-dev-wlan0, whatever it is, in 
>>> wpa_supplicant.conf
>>>
>>> Could you please help me? I had never problems with RPi, with BBone 
>>> Black, but Blue, no idea. I am not a network expert and I do not want to be 
>>> one. I just want to apt update etc. Thanks.
>>>
>>
>> Are you trying to connect a Beaglebone to Internet using an USB 
>> connection to your PC? It's going to be a struggle, especially if you don't 
>> want to dive into networking details.
>>
>> I suggest buying a cheap USB-Ethernet adapter and connecting your 
>> Beaglebone to local LAN using that. It usually works just like that. 
>> Something like this:
>>
>> http://www.logilink.eu/Produkte_LogiLink/Aktive_Netzwerkkomponenten/Fast_Ethernet/USB_2_0_to_Fast_Ethernet_RJ45_Adapter_UA0144B.htm
>>
>> --
>> Kind regards,
>> Tarmo Kuuse
>>
>

-- 
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/904c9914-56fe-4c08-abae-828d77e0cbc0%40googlegroups.com.
For more options, visit 

Re: [beagleboard] Same Exact Image booting on BeagleBone Black but doing NOTHING on PocketBeagle

[Robert Nelson]

On Tue, Jan 8, 2019 at 8:49 AM  wrote:
>
> Hi,
>
> Due to corporate requirements we are modifying a Stretch Image from 
> beagleboard.org. Changes include:
>
> + Several capes have been added.
> + Different packages have been pre-installed.
> + Configurations.
>
>
> So far, we were working with BBB without any problems. Image ran fine and 
> without problems.
>
>
>
> Last week, we started to play with the PocketBeagle. We first used our image 
> and surprisingly it didn't DO ANYTHING.
>
> By anything I mean that even connected to serial, it reports nothing.
>
>
> Same image, on same card boots perfectly fine on a BBB but in the 
> PocketBeagle NOTHING.
>
> It doesn't even display the uboot loader message.
>
>
>
>
> First I thought that was due to the fact that we were using custom capes. 
> Then because of the version of the kernel (4.9.82)... But a standalone image 
> from beagleboard.org (with that same kernel) just boots fine.
>
> I even tried replacing the entire boot directory... by the one of a working 
> image (with the same kernel of course)... but nothing.
>
>
> All those changes always report the same behaviour:
>
> They work flawlessly on the Beaglebone Black... But the PocketBeagle does 
> NOTHING.

Which image (aka the date identifer)?

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/CAOCHtYiNtCBWKFzySu%3DyCOJ295NL2ZLE4KTsvgnfzPsE-Wdw%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Same Exact Image booting on BeagleBone Black but doing NOTHING on PocketBeagle

[gr . ourumov]

Hi,

Due to corporate requirements we are modifying a Stretch Image from 
beagleboard.org. Changes include:

+ Several capes have been added.
+ Different packages have been pre-installed.
+ Configurations.


So far, we were working with BBB without any problems. Image ran fine and 
without problems.



Last week, we started to play with the PocketBeagle. We first used our 
image and surprisingly it didn't DO ANYTHING. 

By anything I mean that even connected to serial, it reports nothing.


Same image, on same card boots perfectly fine on a BBB but in the 
PocketBeagle NOTHING.

It doesn't even display the uboot loader message.




First I thought that was due to the fact that we were using custom capes. 
Then because of the version of the kernel (4.9.82)... But a standalone 
image from beagleboard.org (with that same kernel) just boots fine.

I even tried replacing the entire boot directory... by the one of a working 
image (with the same kernel of course)... but nothing.


All those changes always report the same behaviour:

They work flawlessly on the Beaglebone Black... But the PocketBeagle does 
NOTHING.


Any idea?


Thanks in advance,


Enric



-- 
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/eef48c58-91e3-4072-b152-58a4c5583b30%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] UART0 garbage characters

[Sebastián Sáez]

Hey Yiling, thanks for the reply

After check the documantation and use the oscilloscope, with a friend we 
found that this issue is because I use in my custom cape a pull up resistor 
in pin P8-32 (button connected to this pin)

The pin P8-32 is LCD_DATA15 or SYSBOOT15 and the pull up to 3v3 set this 
pint to high. 
When you boot the bbone with the P8-32 not pressed, the processor set the 
cristal at 26MHz and the baud rate is 106500 not 115200
When you boot the bbone with the button in P8-32 pressed, crystal is set to 
24MHz

The weird thing is that with Debian 8 I don't see this 

Here is the documentation

[image: image.png] 





















On Thursday, January 3, 2019 at 11:42:17 PM UTC-3, c2h2 wrote:
>
> correct UART rate and good ground connection?
>
> On Thu, Jan 3, 2019 at 5:37 AM Sebastián Sáez  > wrote:
>
>> Hi everyone!
>>
>> after install the last linux image in the emmc I can't use the UART0 
>> anymore (screenshot attached )
>>
>> All other function are working, I can do SSH using the softAP interface.
>>
>> Any suggestions?
>> I already tried deleting uboot in emmc without lucky
>>
>> This is my system:
>>
>> debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh
>>> git:/opt/scripts/:[0ca42da8c7e3d81e9cbab71b1e2b0fad00bf79ca]
>>> eeprom:[A335BNLTGW1ABBGW16063691]
>>> model:[TI_AM335x_BeagleBone_Green_Wireless]
>>> dogtag:[BeagleBoard.org Debian Image 2018-10-07]
>>> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
>>> 2018.09-2-g0b54a51eee]:[location: dd MBR]
>>> kernel:[4.14.79-ti-r86]
>>> nodejs:[v6.16.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.20190102.0-0rcnee0~stretch+20190102]
>>> pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]
>>> pkg:[kmod]:[23-2rcnee1~stretch+20171005]
>>> pkg:[librobotcontrol]:[1.0.4-git20181227.0-0rcnee0~stretch+20181228]
>>> 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 cloud9ide gpio pwm eqep 
>>> admin spi tisdk weston-launch xenomai]
>>> cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
>>> root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
>>> net.ifnames=0 quiet]
>>> dmesg | grep pinctrl-single
>>> [1.063909] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 
>>> size 568
>>> dmesg | grep gpio-of-helper
>>> [1.075590] gpio-of-helper ocp:cape-universal: ready
>>> END
>>
>>
>>
>> garbage characters
>>
>> [image: uart0.png]
>>
>> -- 
>> 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/49ca35c1-8281-49f3-ba81-d1be214158b2%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> -- 
> Yiling Cao
> http://ariaboard.com/
> http://shanghainovotech.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/db7f1f7e-5789-4692-9ee2-339b57c2a806%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PRUs - not really deterministic, missing docs?

[daveyjohn946]

Hi, I have read an intro about PRUs 
http://www.staroceans.org/documents/TI-sdk/spry264.pdf "each PRU has its 
own *single-cycle I/O*"

Well, nice. Let's look further...

http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit "Content 
is no longer maintained and is being kept for reference only! "
http://processors.wiki.ti.com/index.php/PRU_Read_Latencies "has been set to 
read only"
http://www.ti.com/tool/PRU-SWPKG?HQS=TI-null-null-mousermode-df-pf-null-wwe=yes_url=https%3A%2F%2Fwww.mouser.fr%2F
 
"this software package is no longer being maintained."
Tried to send a message into BeagleBone PRU subforum... it happily 
disappeared forever.

But ok, it is just a possible warning. Let us look into the hard docs.

http://www.ti.com/lit/an/sprace8a/sprace8a.pdf a write instruction 
"executes in *approximately* 1 cycle" "Table 1 through Table 3 are 
considered *"best-case"* read latency values for the PRU"

Now it is not just a warning. It shows that the details of the "real-time" 
are some undocumented unknowns, and that these units might not be 
deterministic at all. "Might", because there are just no precise docs and I 
am not going to reverse-engineer them. It would not give the real-time 
guaranties.

Possibly you could point me to some modern processing unit where there is 
at least a subset of instructions (including basic GPIO read/write and 
intercore communication) with precise execution times?







-- 
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/aa262781-6c9b-49af-94ed-783dbe980629%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Are PRUs really deterministic, and well documented, ant not obsolete...

[daveyjohn946]

Hi, I have read this nice ad for PRUs 
http://www.staroceans.org/documents/TI-sdk/spry264.pdf which states how 
deterministic the PRUs are, 

"*each PRU has its own single-cycle I/O*" etc. Then I wanted details... 

http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit "Content 
is* no longer maintained and is being kept for reference only!* "

http://processors.wiki.ti.com/index.php/PRU-ICSS "Please note as of 
Wednesday, August 15th, 2018 this wiki *has been set to read only*."

http://processors.wiki.ti.com/index.php/PRU_Read_Latencies "The PRU write 
instruction is a fire-and-forget command that executes in *~*1 cycle"

*that tilde...*


"The read latency values at the following links are *considered* 
"best-case," accounting for the 2 cycle instruction and interconnect 
introduced *latency*".

*best case*

Possibly, there is some doc which states min/max execution times? 
Deterministic or not? etc, etc. 
*Not found. Just not found.*

---

I do not want to be pessimistic but neither I want to reverse-engineer 
these "deteministic" units, that do not really look that-deterministic. And 
that docs obsolete or missing??? What is it all about?




-- 
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/8976d66c-9bb4-40b9-aec9-b33874d42b99%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.