Re: [beagleboard] Re: PocketBeagle Boot Time

2020-05-03 Thread Hans Leeuw
Hi Paul,

I am also trying to make my PocketBeagle startup time faster and after 
disabling a lot of scripts I saw little progress until I disabled 
bonescript-autorun.service

sudo systemctl disable bonescript-autorun.service

You don’t see it when you run 'systemd-analyze blame' but look at the 
output of 'systemctl status'

It is the default Web server and the one that gives you all the info on 
the BeagleBone when you just start with it. If you are not just starting 
with the board you probably don't need it.

My startup time dropped about 14 seconds.

(4.19.94-bone44)


*Before:*
*Startup finished in 7.003s (kernel) + 40.578s (userspace) = 47.581s *
*After:*
*Startup finished in 6.781s (kernel) + 26.379s (userspace) = 33.161s* (in 
reality about 42 seconds from the power button push to my wireless network 
being connected and my program spewing data to the computer.)
See below my message for the complete output of systemd-analyze

TJF mentioned even better boot times by disabling the universal cape. I 
tried this line once:
cape_universal=disable

But ended up with an unresponsive board... (PocketBeagle)
I am still wondering what the generic universal-cape line does in uEnv.txt. 
I have now used:
enable_uboot_cape_universal=0
enable_uboot_cape_universal=1
#enable_uboot_cape_universal=1

And there is no difference at all in the boot time. Is there a way to check 
if it is active?

When I disable serial-getty@ttyGS0.service my boot time reduces again with 
14s:

*Startup finished in 6.726s (kernel) + 12.957s (userspace) = 19.684s * 

The service is recreated though at the next boot. And the actual start time 
of the board (time to wifi connection from button push) still stays at 
about 40 seconds. I wonder if the extra time is actually the Wifi USB 
dongle starting up. dmesg output:

[   19.595409] usb 1-1: Manufacturer: Realtek

[   19.595416] usb 1-1: SerialNumber: 123456

[   33.475816] cfg80211: Loading compiled-in X.509 certificates for 
regulatory database

[   33.490036] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'

[   34.111534] RTW*: module init start*



Then this thread  
seemed interesting to me. It is about the raspberry PI but the question 
posed is if it is possible to start systemd-timesyncd.service later from 
Kosi:

*"So we should rather stay with fake-hwclock for saving/loading last system 
time on boot before systemd-fsck-root.service and use 
systemd-timesyncd.service for network time synchronization only?*
*Then it could be better to change systemd-timesyncd.service dependencies 
to load after network-online.target only to save some time during the boot.*

Code: Select all 


[Unit]
DefaultDependencies=no
#After=systemd-remount-fs.service systemd-sysusers.service
#Before=time-sync.target sysinit.target shutdown.target
After=network-online.target
Before=shutdown.target
Conflicts=shutdown.target
#Wants=time-sync.target

...

[Install]
#WantedBy=sysinit.target
WantedBy=multi-user.target


Best, Hans.


My complete 'system-analyze blame' before and after I disabled the 
bonescript-autorun.service and finally disabling the 
serial-getty@ttyGS0.service

Before:
*debian@beaglebone*:*~*$ systemd-analyze
Startup finished in 6.801s (kernel) + 39.999s (userspace) = 46.800s 
multi-user.target reached after 39.558s in userspace
*debian@beaglebone*:*~*$ systemd-analyze blame
 32.964s generic-board-startup.service
 23.167s dev-mmcblk0p1.device
  2.500s systemd-udev-trigger.service
  1.805s networking.service
  1.345s avahi-daemon.service
  1.316s ssh.service
  1.209s dnsmasq.service
  1.118s systemd-timesyncd.service
  1.115s systemd-logind.service
  1.113s connman.service
  1.051s systemd-journald.service
  1.003s libpruio-lkm.service
   720ms wpa_supplicant.service
   626ms systemd-update-utmp.service
   597ms rsyslog.service
   588ms systemd-user-sessions.service
   478ms systemd-remount-fs.service
   472ms user@1000.service
   466ms fake-hwclock.service
   451ms dev-mqueue.mount
   439ms systemd-modules-load.service
   412ms systemd-tmpfiles-setup.service
   378ms systemd-sysctl.service
   355ms kmod-static-nodes.service
   352ms systemd-journal-flush.service
   351ms systemd-update-utmp-runlevel.service
   337ms systemd-sysusers.service
   328ms systemd-udevd.service
   328ms systemd-tmpfiles-setup-dev.service
   325ms sys-fs-fuse-connections.mount
   317ms systemd-rfkill.service
   303ms sys-kernel-debug.mount
   275ms systemd-random-seed.service
   229ms sys-kernel-config.mount
   164ms ifupdown-pre.service
   117ms user-runtime-dir@1000.service
86ms 

Re: [beagleboard] Is it possible to run TI-RTOS or any RTOS on beaglebone blue?

2020-05-03 Thread 'Mark Lazarewicz' via BeagleBoard
Hello Preetek
Here's the answer from TI E2E forum below.


For TI RTOS development, an emulator is typically required as the development 
environment usually uses CCS IDE and debug would require an emulator. Having 
said that you can load applications using a SD card and use printf to run and 
debug applications but this is quite an inefficient setup that will not provide 
as much insight in the debug.

To use as a starting point, I would recommend that you use the RTOS template 
app that we support for am335x-evm and then modify this to link to bbAM335x 
board library to modify for your platform.
I'll summarize.
a board with JTAG to debug is recommended and you need a board library to Link 
to provided by CCS.
CCS has built in template for supported hardware like EVM. If your board has no 
template in CCS you need to modify one.
Perhaps play with CCS and RTOS SDK see what's available for board's they may 
have Added new board's. Follow an RTOS  tutorial.
If you don't like wasting time you use JTAG listed in the tutorial  doc and 
installation of tools documents.
Out of the box support is there for EVM what TI chooses to add for board 
libraries may vary.
In the past they may have Added every Beaglbone I don't know.
I very much doubt the BBAI is supported but maybe I'm wrong and maybe modified 
template is easy depends on your background.
Poke around and see if you're board has a library and pick a Beaglbone  board 
with working JTAG otherwise soldering has minimal risk buying connectors etc 
etc.
As in my earlier comments a FTDI JTAG is quickest and best chances of working 
you plug in USB and go.
If costs $$$ are an issue: for board's  choose less modifications less risk 
same for JTAG. Or ask in forum about your unique setup.
Appears customer got BB black working but chose to not buy JTAG I don't 
recommend. 
Just IMO
Good Luck hopefully this helps
With suggest set-up you can have an RTOS app running in 5 minutes it sweet.
Mark











  

-- 
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/318256913.448647.1588553664172%40mail.yahoo.com.


Re: [beagleboard] Is it possible to run TI-RTOS or any RTOS on beaglebone blue?

2020-05-03 Thread 'Mark Lazarewicz' via BeagleBoard
Hello Johnny
 the original question was can TI RTOS work on the Beaglbone Blue. I've seen 
many asking about the BBAI as well. Perhaps you can share which Beaglbone board 
you have TI RTOS running on??
 and what you used for JTAG so we can provide some help or support. 
I've experience running TI RTOS SDK on TI EVM board myself . 
I've seen you have a BBAI so please elaborate your hardware running TI RTOS for 
Original question asker please. 
I'm curious myself. I'm just trying to avoid solutions for other's that haven't 
been verified. 
Mark

Sent from Yahoo Mail on Android 
 
  On Sun, May 3, 2020 at 4:50 PM, jonnymo wrote:   You 
asked, if I had experience with TI-RTOS and if I had experience with TI-RTOS 
with other IDEs and I answered yes to those.  However,  I have nothing to prove 
to you or anyone else for that matter that does not provide me with a paycheck. 
 Believe what you want, I could not care less. 
However, you don't need an IDE to use any programmer, be it a Segger or other. 
But, then again you know all so I would expect you already have done this.
Good luck.
Jon 
On Sun, May 3, 2020 at 1:28 PM 'Mark Lazarewicz' via BeagleBoard 
 wrote:

Right Ian and I've had trouble with Segger.They work well for some IDE. I don't 
want people wasting Money like I did.I'm very skeptical Johnny has gotten TI 
RTOS working on any Beaglbone it's not supported.And his claims that SYS BIOS( 
now TI RTOS) which uses autogenerated files compiles outside of CCS are 
dubious. If you stick with one vendor you won't waste weeks of Time fighting 
tool's. I agree  with your assessment. Perhaps I will send Johnny a $20 JTAG 
and ask him to share his BBAI TI RTOS projects online using this $20 JTAG  
with the group.


Sent from Yahoo Mail on Android 
 
  On Sun, May 3, 2020 at 2:50 PM, jonnymo wrote:   You 
must be reading a different Release note then I am reading. This seems to show 
more than just cortex-m 
support.https://www.segger.com/products/debug-probes/j-link/models/model-overview/#supported-cores

 Segger does lists the J-Link EDU Mini with full J-Link support though.  There 
is also the $60 J-Link EDU which is basically the same as the Base without all 
the extra software. 
However, the mini was just tossed out as a suggestion.  Its up the individual 
to do the proper research to see what works best for their environment.
Cheers.
Jon 
On Sun, May 3, 2020 at 8:13 AM Iain Hunter  wrote:

Hi Jonny, Looking at that link from Segger it appears that they only support 
the cortex-M core devices from TI, so that wouldn't help on a BBB.The other 
factor that is important for some of us is that the Segger EDU emulators are 
explicitly for non-commercial use. If you are commercial use then you are 
looking at $400 which makes the TI emulators look like a bargain.Iain

On Saturday, May 2, 2020 at 6:27:29 PM UTC+1, jonnymo wrote:
Segger is an industry standard and if TI  does not support it with CCS then I 
would suggest another MCU vendor. There is this 
though:https://wiki.segger.com/TI_Code_Composer_Studio
Besides, CCS is just a TI version of Eclipse, so anything that can be done in 
CCS can be done in Eclipse.  It may take some work to get the project set-up, 
but it is possible. 


On Sat, May 2, 2020 at 10:10 AM 'Mark Lazarewicz' via BeagleBoard 
 wrote:

More how quickly they suggest using their Segger IDE. That's been my 
experience. Good luck building TI RTOS in anything besides CCS.This is there 
high end JTAG as well.


https://forum.segger.com/index.php/Thread/4869-SOLVED-J-Link-on-Code-Composer-Studio/


Sent from Yahoo Mail on Android 
 
  On Sat, May 2, 2020 at 12:05 PM, 'Mark Lazarewicz' via 
BeagleBoard wrote:   Make Sure Segger comes with 
.gel file for CCS and driver's for CCS.
 When you buy all TI products less head aches and better support as well adding 
the JTAG support to CCS. All this must be verified before buying.


Sent from Yahoo Mail on Android 
 
  On Sat, May 2, 2020 at 11:54 AM, jonnymo wrote:   The 
Segger J-Link EDU Mini is only like $20US.
https://www.adafruit.com/product/3571


On Sat, May 2, 2020 at 9:21 AM 'Mark Lazarewicz' via BeagleBoard 
 wrote:

Right looks like a black or white is best. A board with USB JTAG is cheaper as 
if $$$ are a problem the JTAG is $100+ the EVM supports JTAG over USB that's 
why they support no soldering.

Sent from Yahoo Mail on Android 
 
  On Sat, May 2, 2020 at 11:10 AM, jonnymo wrote:   For 
Ti-RTOS, you might want to start 
here.http://www.ti.com/tool/PROCESSOR-SDK-AM335X

This looks 
interesting:http://huesmanbros.com/marc/2017/09/22/getting-ti-rtos-running-on-the-beaglebone-black/


There is a page for QNX on the Beagleboard site, but perhaps more specific for 
the BB Black or EVM.  It could be possible to try it with the Blue, but I am 
not sure how they compare 
though.https://beagleboard.org/project/QNX+Neutrino+on+OMAP/
http://www.qnx.com/products/reference-design/index.html

There are JTAG pads on the back of the Blue so you would 

Re: [beagleboard] Is it possible to run TI-RTOS or any RTOS on beaglebone blue?

2020-05-03 Thread jonnymo
You asked, if I had experience with TI-RTOS and if I had experience
with TI-RTOS with other IDEs and I answered yes to those.  However,  I have
nothing to prove to you or anyone else for that matter that does not
provide me with a paycheck.  Believe what you want, I could not care less.

However, you don't need an IDE to use any programmer, be it a Segger or
other. But, then again you know all so I would expect you already have done
this.

Good luck.

Jon

On Sun, May 3, 2020 at 1:28 PM 'Mark Lazarewicz' via BeagleBoard <
beagleboard@googlegroups.com> wrote:

> Right Ian and I've had trouble with Segger.
> They work well for some IDE.
>  I don't want people wasting Money like I did.
> I'm very skeptical Johnny has gotten TI RTOS working on any Beaglbone it's
> not supported.
> And his claims that SYS BIOS( now TI RTOS) which uses autogenerated files
> compiles outside of CCS are dubious. If you stick with one vendor you won't
> waste weeks of Time fighting tool's. I agree  with your assessment.
> Perhaps I will send Johnny a $20 JTAG and ask him to share his BBAI TI RTOS
> projects online using this $20 JTAG  with the group.
>
>
> Sent from Yahoo Mail on Android
> 
>
> On Sun, May 3, 2020 at 2:50 PM, jonnymo
>  wrote:
> You must be reading a different Release note then I am reading.
> This seems to show more than just cortex-m support.
>
> https://www.segger.com/products/debug-probes/j-link/models/model-overview/#supported-cores
>
>  Segger does lists the J-Link EDU Mini with full J-Link support though.
> There is also the $60 J-Link EDU which is basically the same as the Base
> without all the extra software.
>
> However, the mini was just tossed out as a suggestion.  Its up the
> individual to do the proper research to see what works best for their
> environment.
>
> Cheers.
>
> Jon
>
> On Sun, May 3, 2020 at 8:13 AM Iain Hunter  wrote:
>
> Hi Jonny,
> Looking at that link from Segger it appears that they only support the
> cortex-M core devices from TI, so that wouldn't help on a BBB.
> The other factor that is important for some of us is that the Segger EDU
> emulators are explicitly for non-commercial use. If you are commercial use
> then you are looking at $400 which makes the TI emulators look like a
> bargain.
> Iain
>
> On Saturday, May 2, 2020 at 6:27:29 PM UTC+1, jonnymo wrote:
>
> Segger is an industry standard and if TI  does not support it with CCS
> then I would suggest another MCU vendor.
> There is this though:
> https://wiki.segger.com/TI_Code_Composer_Studio
>
> Besides, CCS is just a TI version of Eclipse, so anything that can be done
> in CCS can be done in Eclipse.  It may take some work to get the project
> set-up, but it is possible.
>
>
>
> On Sat, May 2, 2020 at 10:10 AM 'Mark Lazarewicz' via BeagleBoard <
> beagl...@googlegroups.com> wrote:
>
> More how quickly they suggest using their Segger IDE. That's been my
> experience. Good luck building TI RTOS in anything besides CCS.
> This is there high end JTAG as well.
>
>
>
> https://forum.segger.com/index.php/Thread/4869-SOLVED-J-Link-on-Code-Composer-Studio/
>
>
> Sent from Yahoo Mail on Android
> 
>
> On Sat, May 2, 2020 at 12:05 PM, 'Mark Lazarewicz' via BeagleBoard
>  wrote:
> Make Sure Segger comes with .gel file for CCS and driver's for CCS.
>
>  When you buy all TI products less head aches and better support as well
> adding the JTAG support to CCS. All this must be verified before buying.
>
>
>
> Sent from Yahoo Mail on Android
> 
>
> On Sat, May 2, 2020 at 11:54 AM, jonnymo
>  wrote:
> The Segger J-Link EDU Mini is only like $20US.
> https://www.adafruit.com/product/3571
>
>
> On Sat, May 2, 2020 at 9:21 AM 'Mark Lazarewicz' via BeagleBoard <
> beagl...@googlegroups.com> wrote:
>
> Right looks like a black or white is best. A board with USB JTAG is
> cheaper as if $$$ are a problem the JTAG is $100+ the EVM supports JTAG
> over USB that's why they support no soldering.
>
> Sent from Yahoo Mail on Android
> 
>
> On Sat, May 2, 2020 at 11:10 AM, jonnymo
>  wrote:
> For Ti-RTOS, you might want to start here.
> http://www.ti.com/tool/PROCESSOR-SDK-AM335X
>
> This looks interesting:
>
> http://huesmanbros.com/marc/2017/09/22/getting-ti-rtos-running-on-the-beaglebone-black/
>
>
> There is a page for QNX on the Beagleboard site, but perhaps more specific
> for the BB Black or EVM.  It could be 

Re: [beagleboard] Is it possible to run TI-RTOS or any RTOS on beaglebone blue?

2020-05-03 Thread 'Mark Lazarewicz' via BeagleBoard
Right Ian and I've had trouble with Segger.They work well for some IDE. I don't 
want people wasting Money like I did.I'm very skeptical Johnny has gotten TI 
RTOS working on any Beaglbone it's not supported.And his claims that SYS BIOS( 
now TI RTOS) which uses autogenerated files compiles outside of CCS are 
dubious. If you stick with one vendor you won't waste weeks of Time fighting 
tool's. I agree  with your assessment. Perhaps I will send Johnny a $20 JTAG 
and ask him to share his BBAI TI RTOS projects online using this $20 JTAG  
with the group.


Sent from Yahoo Mail on Android 
 
  On Sun, May 3, 2020 at 2:50 PM, jonnymo wrote:   You 
must be reading a different Release note then I am reading. This seems to show 
more than just cortex-m 
support.https://www.segger.com/products/debug-probes/j-link/models/model-overview/#supported-cores

 Segger does lists the J-Link EDU Mini with full J-Link support though.  There 
is also the $60 J-Link EDU which is basically the same as the Base without all 
the extra software. 
However, the mini was just tossed out as a suggestion.  Its up the individual 
to do the proper research to see what works best for their environment.
Cheers.
Jon 
On Sun, May 3, 2020 at 8:13 AM Iain Hunter  wrote:

Hi Jonny, Looking at that link from Segger it appears that they only support 
the cortex-M core devices from TI, so that wouldn't help on a BBB.The other 
factor that is important for some of us is that the Segger EDU emulators are 
explicitly for non-commercial use. If you are commercial use then you are 
looking at $400 which makes the TI emulators look like a bargain.Iain

On Saturday, May 2, 2020 at 6:27:29 PM UTC+1, jonnymo wrote:
Segger is an industry standard and if TI  does not support it with CCS then I 
would suggest another MCU vendor. There is this 
though:https://wiki.segger.com/TI_Code_Composer_Studio
Besides, CCS is just a TI version of Eclipse, so anything that can be done in 
CCS can be done in Eclipse.  It may take some work to get the project set-up, 
but it is possible. 


On Sat, May 2, 2020 at 10:10 AM 'Mark Lazarewicz' via BeagleBoard 
 wrote:

More how quickly they suggest using their Segger IDE. That's been my 
experience. Good luck building TI RTOS in anything besides CCS.This is there 
high end JTAG as well.


https://forum.segger.com/index.php/Thread/4869-SOLVED-J-Link-on-Code-Composer-Studio/


Sent from Yahoo Mail on Android 
 
  On Sat, May 2, 2020 at 12:05 PM, 'Mark Lazarewicz' via 
BeagleBoard wrote:   Make Sure Segger comes with 
.gel file for CCS and driver's for CCS.
 When you buy all TI products less head aches and better support as well adding 
the JTAG support to CCS. All this must be verified before buying.


Sent from Yahoo Mail on Android 
 
  On Sat, May 2, 2020 at 11:54 AM, jonnymo wrote:   The 
Segger J-Link EDU Mini is only like $20US.
https://www.adafruit.com/product/3571


On Sat, May 2, 2020 at 9:21 AM 'Mark Lazarewicz' via BeagleBoard 
 wrote:

Right looks like a black or white is best. A board with USB JTAG is cheaper as 
if $$$ are a problem the JTAG is $100+ the EVM supports JTAG over USB that's 
why they support no soldering.

Sent from Yahoo Mail on Android 
 
  On Sat, May 2, 2020 at 11:10 AM, jonnymo wrote:   For 
Ti-RTOS, you might want to start 
here.http://www.ti.com/tool/PROCESSOR-SDK-AM335X

This looks 
interesting:http://huesmanbros.com/marc/2017/09/22/getting-ti-rtos-running-on-the-beaglebone-black/


There is a page for QNX on the Beagleboard site, but perhaps more specific for 
the BB Black or EVM.  It could be possible to try it with the Blue, but I am 
not sure how they compare 
though.https://beagleboard.org/project/QNX+Neutrino+on+OMAP/
http://www.qnx.com/products/reference-design/index.html

There are JTAG pads on the back of the Blue so you would have to carefully 
solder headers to it and then use a JTAG programmer to load it. Again, all 
theory in my case since I have not attempted this with my dead Blue. 
https://github.com/beagleboard/beaglebone-blue/blob/master/BeagleBone_Blue_sch.pdf

Cheers,
Jon

On Sat, May 2, 2020 at 8:53 AM 'Mark Lazarewicz' via BeagleBoard 
 wrote:

HelloWhat I meant is learning TI  RTOS us typically done using CCS and loading 
via JTAG. So using a board without JTAG isn't smart.
As far as your board I didn't see it in the supported hardware doc's you must 
dig deeper to find.
QNX and Free RTOS might support the board.
Any RTOS typically provide Architecture Support Package (ARM) and Board Support 
Package (Beaglbone) so assuming the processor is supported as it's same also 
bad idea.If you search group for RTOS you see others asking to use Beaglbone ( 
white or black or BBAI
As I mentioned it works on TI EVM hardware which is the am35xx I have one it's 
$250 this group is beagleboard org hardware. The board support is different. TI 
RTOS lists 4 boards no mention of Beaglbone.
RTOS vendor test on specific board's typically in TI RTOS official TI EVM 
boards.Here's 

Re: [beagleboard] Is it possible to run TI-RTOS or any RTOS on beaglebone blue?

2020-05-03 Thread jonnymo
You must be reading a different Release note then I am reading.
This seems to show more than just cortex-m support.
https://www.segger.com/products/debug-probes/j-link/models/model-overview/#supported-cores

 Segger does lists the J-Link EDU Mini with full J-Link support though.
There is also the $60 J-Link EDU which is basically the same as the Base
without all the extra software.

However, the mini was just tossed out as a suggestion.  Its up the
individual to do the proper research to see what works best for their
environment.

Cheers.

Jon

On Sun, May 3, 2020 at 8:13 AM Iain Hunter  wrote:

> Hi Jonny,
> Looking at that link from Segger it appears that they only support the
> cortex-M core devices from TI, so that wouldn't help on a BBB.
> The other factor that is important for some of us is that the Segger EDU
> emulators are explicitly for non-commercial use. If you are commercial use
> then you are looking at $400 which makes the TI emulators look like a
> bargain.
> Iain
>
> On Saturday, May 2, 2020 at 6:27:29 PM UTC+1, jonnymo wrote:
>>
>> Segger is an industry standard and if TI  does not support it with CCS
>> then I would suggest another MCU vendor.
>> There is this though:
>> https://wiki.segger.com/TI_Code_Composer_Studio
>>
>> Besides, CCS is just a TI version of Eclipse, so anything that can be
>> done in CCS can be done in Eclipse.  It may take some work to get the
>> project set-up, but it is possible.
>>
>>
>>
>> On Sat, May 2, 2020 at 10:10 AM 'Mark Lazarewicz' via BeagleBoard <
>> beagl...@googlegroups.com> wrote:
>>
>>> More how quickly they suggest using their Segger IDE. That's been my
>>> experience. Good luck building TI RTOS in anything besides CCS.
>>> This is there high end JTAG as well.
>>>
>>>
>>>
>>> https://forum.segger.com/index.php/Thread/4869-SOLVED-J-Link-on-Code-Composer-Studio/
>>>
>>>
>>> Sent from Yahoo Mail on Android
>>> 
>>>
>>> On Sat, May 2, 2020 at 12:05 PM, 'Mark Lazarewicz' via BeagleBoard
>>>  wrote:
>>> Make Sure Segger comes with .gel file for CCS and driver's for CCS.
>>>
>>>  When you buy all TI products less head aches and better support as well
>>> adding the JTAG support to CCS. All this must be verified before buying.
>>>
>>>
>>>
>>> Sent from Yahoo Mail on Android
>>> 
>>>
>>> On Sat, May 2, 2020 at 11:54 AM, jonnymo
>>>  wrote:
>>> The Segger J-Link EDU Mini is only like $20US.
>>> https://www.adafruit.com/product/3571
>>>
>>>
>>> On Sat, May 2, 2020 at 9:21 AM 'Mark Lazarewicz' via BeagleBoard <
>>> beagl...@googlegroups.com> wrote:
>>>
>>> Right looks like a black or white is best. A board with USB JTAG is
>>> cheaper as if $$$ are a problem the JTAG is $100+ the EVM supports JTAG
>>> over USB that's why they support no soldering.
>>>
>>> Sent from Yahoo Mail on Android
>>> 
>>>
>>> On Sat, May 2, 2020 at 11:10 AM, jonnymo
>>>  wrote:
>>> For Ti-RTOS, you might want to start here.
>>> http://www.ti.com/tool/PROCESSOR-SDK-AM335X
>>>
>>> This looks interesting:
>>>
>>> http://huesmanbros.com/marc/2017/09/22/getting-ti-rtos-running-on-the-beaglebone-black/
>>>
>>>
>>> There is a page for QNX on the Beagleboard site, but perhaps more
>>> specific for the BB Black or EVM.  It could be possible to try it with the
>>> Blue, but I am not sure how they compare though.
>>> https://beagleboard.org/project/QNX+Neutrino+on+OMAP/
>>> http://www.qnx.com/products/reference-design/index.html
>>>
>>> There are JTAG pads on the back of the Blue so you would have to
>>> carefully solder headers to it and then use a JTAG programmer to load it.
>>> Again, all theory in my case since I have not attempted this with my dead
>>> Blue.
>>>
>>> https://github.com/beagleboard/beaglebone-blue/blob/master/BeagleBone_Blue_sch.pdf
>>>
>>> Cheers,
>>>
>>> Jon
>>>
>>>
>>> On Sat, May 2, 2020 at 8:53 AM 'Mark Lazarewicz' via BeagleBoard <
>>> beagl...@googlegroups.com> wrote:
>>>
>>> Hello
>>> What I meant is learning TI  RTOS us typically done using CCS and
>>> loading via JTAG. So using a board without JTAG isn't smart.
>>>
>>> As far as your board I didn't see it in the supported hardware doc's you
>>> must dig deeper to find.
>>>
>>> QNX and Free RTOS might support the board.
>>>
>>> Any RTOS typically provide Architecture Support Package (ARM) and Board
>>> Support Package (Beaglbone) so assuming the processor is supported as it's
>>> same also bad idea.
>>> If you search group for RTOS you see others asking to use Beaglbone (
>>> white or black or BBAI
>>>
>>> As I mentioned it works on TI EVM 

Re: [beagleboard] Re: SGX - OPENGL - Buildroot

2020-05-03 Thread jonnymo
I've seen the "Unable to create surface" error when OpenGL can not attach
to a display.  Are you doing this remote or do you have some sort of
display attached to the board and running locally?Also, have you
checked the output of glxinfo or run glxgears to see if it can display the
gears demo?

Cheers,

Jon

On Sun, May 3, 2020 at 5:18 AM Fran H. Sena  wrote:

> https://elinux.org/BeagleBoneBlack/SGX_%2B_Qt_EGLFS_%2B_Weston
>
> El miércoles, 19 de febrero de 2020, 20:40:28 (UTC+1),
> s.cl...@guinault.com escribió:
>>
>> Hello,
>>
>> I'm currently trying to work with the latest configuration for the black
>> beaglebone on buildroot (beaglebone_qt5_defconfig).
>>
>> I am able to build and run the image on the board and the sgx module is
>> loaded :
>>
>>  lsmod | grep pvr
>> pvrsrvkm  389120  0
>>
>> When I try to run sgx demo like OGLES2Water, I get the error : *PVRShell:
>> Unable to initialise EGL*
>>
>> I saw on a forum that error is due to the absence of the mesa EGL
>> library. So I installed the package mesa3d from buildroot with the *DRI
>> swrast driver.*
>>
>> And now I have a new error :* PVRShell: Unable to create surface*
>>
>> I haven't found the cause of this new error and I am stuck at this stage.
>>
>> What is my error to make opengl work with buildroot for the black
>> beaglebone?
>>
>> Thank you
>>
> --
> 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/4860fc70-8804-4b0d-8356-ef183b351ad3%40googlegroups.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/CAG99bkoF98oLSjxrxKMLD9h6yFbQ33Fvz2tOrGS6y-yjMkRYbA%40mail.gmail.com.


Re: [beagleboard] BBB: sharing Internet connection from Linux laptop with USB

2020-05-03 Thread KenUnix

Jason,

I sent you a message a few weeks ago was wondering if you received my 
e-mail regarding web pages?

Ken

-- 
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/a12935f0-0be4-48c6-9ed5-fb8d257e9873%40googlegroups.com.


Re: [beagleboard] Is it possible to run TI-RTOS or any RTOS on beaglebone blue?

2020-05-03 Thread Iain Hunter
Hi Jonny, 
Looking at that link from Segger it appears that they only support the 
cortex-M core devices from TI, so that wouldn't help on a BBB.
The other factor that is important for some of us is that the Segger EDU 
emulators are explicitly for non-commercial use. If you are commercial use 
then you are looking at $400 which makes the TI emulators look like a 
bargain.
Iain

On Saturday, May 2, 2020 at 6:27:29 PM UTC+1, jonnymo wrote:
>
> Segger is an industry standard and if TI  does not support it with CCS 
> then I would suggest another MCU vendor. 
> There is this though:
> https://wiki.segger.com/TI_Code_Composer_Studio
>
> Besides, CCS is just a TI version of Eclipse, so anything that can be done 
> in CCS can be done in Eclipse.  It may take some work to get the project 
> set-up, but it is possible. 
>
>
>
> On Sat, May 2, 2020 at 10:10 AM 'Mark Lazarewicz' via BeagleBoard <
> beagl...@googlegroups.com > wrote:
>
>> More how quickly they suggest using their Segger IDE. That's been my 
>> experience. Good luck building TI RTOS in anything besides CCS.
>> This is there high end JTAG as well.
>>
>>
>>
>> https://forum.segger.com/index.php/Thread/4869-SOLVED-J-Link-on-Code-Composer-Studio/
>>
>>
>> Sent from Yahoo Mail on Android 
>> 
>>
>> On Sat, May 2, 2020 at 12:05 PM, 'Mark Lazarewicz' via BeagleBoard
>> > wrote:
>> Make Sure Segger comes with .gel file for CCS and driver's for CCS.
>>
>>  When you buy all TI products less head aches and better support as well 
>> adding the JTAG support to CCS. All this must be verified before buying.
>>
>>
>>
>> Sent from Yahoo Mail on Android 
>> 
>>
>> On Sat, May 2, 2020 at 11:54 AM, jonnymo
>> > wrote:
>> The Segger J-Link EDU Mini is only like $20US.
>> https://www.adafruit.com/product/3571
>>
>>
>> On Sat, May 2, 2020 at 9:21 AM 'Mark Lazarewicz' via BeagleBoard <
>> beagl...@googlegroups.com > wrote:
>>
>> Right looks like a black or white is best. A board with USB JTAG is 
>> cheaper as if $$$ are a problem the JTAG is $100+ the EVM supports JTAG 
>> over USB that's why they support no soldering.
>>
>> Sent from Yahoo Mail on Android 
>> 
>>
>> On Sat, May 2, 2020 at 11:10 AM, jonnymo
>> > wrote:
>> For Ti-RTOS, you might want to start here.
>> http://www.ti.com/tool/PROCESSOR-SDK-AM335X
>>
>> This looks interesting:
>>
>> http://huesmanbros.com/marc/2017/09/22/getting-ti-rtos-running-on-the-beaglebone-black/
>>
>>
>> There is a page for QNX on the Beagleboard site, but perhaps more 
>> specific for the BB Black or EVM.  It could be possible to try it with the 
>> Blue, but I am not sure how they compare though.
>> https://beagleboard.org/project/QNX+Neutrino+on+OMAP/
>> http://www.qnx.com/products/reference-design/index.html
>>
>> There are JTAG pads on the back of the Blue so you would have to 
>> carefully solder headers to it and then use a JTAG programmer to load it. 
>> Again, all theory in my case since I have not attempted this with my dead 
>> Blue. 
>>
>> https://github.com/beagleboard/beaglebone-blue/blob/master/BeagleBone_Blue_sch.pdf
>>
>> Cheers,
>>
>> Jon
>>
>>
>> On Sat, May 2, 2020 at 8:53 AM 'Mark Lazarewicz' via BeagleBoard <
>> beagl...@googlegroups.com > wrote:
>>
>> Hello
>> What I meant is learning TI  RTOS us typically done using CCS and loading 
>> via JTAG. So using a board without JTAG isn't smart.
>>
>> As far as your board I didn't see it in the supported hardware doc's you 
>> must dig deeper to find.
>>
>> QNX and Free RTOS might support the board.
>>
>> Any RTOS typically provide Architecture Support Package (ARM) and Board 
>> Support Package (Beaglbone) so assuming the processor is supported as it's 
>> same also bad idea.
>> If you search group for RTOS you see others asking to use Beaglbone ( 
>> white or black or BBAI
>>
>> As I mentioned it works on TI EVM hardware which is the am35xx I have one 
>> it's $250 this group is beagleboard org hardware. The board support is 
>> different. TI RTOS lists 4 boards no mention of Beaglbone.
>>
>> RTOS vendor test on specific board's typically in TI RTOS official TI EVM 
>> boards.
>> Here's Link
>> http://www.ti.com/tool/TMDSEVM3517C
>>
>> Board Support Package Engineers port BSP to customer hardware sometimes 
>> easy (your board) sometimes very hard ( custom hardware design's)
>> I was BSP consultant I know This
>>
>> RTOS vendor like Greenhills sell BSP packages.
>>
>> Google group and see someone asking about BBAI won't boot using TI RTOS
>>
>> I'm not such a nice Guy 
>>
>> So I tell you you 

[beagleboard] Re: Garbled image on 16-bit parallel RGB LCD (Sitronix ST7701S)

2020-05-03 Thread raphael


> What I was trying to say, if VS or HS change as the PCLK is rising, then 
> it may not register, but the next PCLK clock should register the VS or HS
>

Good point! In my case, the VS and HS signals are generated on the PCLK's 
falling edge though, so they should be valid on the next rising edge of the 
PCLK. I just measured again to verify. That being said, I also suspect the 
frame sync being off somehow and I've been exploring this possibility in 
detail and will continue to do so.

-- 
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/3cb9a6e4-e214-49aa-baef-baf0df97c0a8%40googlegroups.com.


[beagleboard] Re: SGX - OPENGL - Buildroot

2020-05-03 Thread Fran H. Sena
https://elinux.org/BeagleBoneBlack/SGX_%2B_Qt_EGLFS_%2B_Weston

El miércoles, 19 de febrero de 2020, 20:40:28 (UTC+1), s.cl...@guinault.com 
escribió:
>
> Hello,
>
> I'm currently trying to work with the latest configuration for the black 
> beaglebone on buildroot (beaglebone_qt5_defconfig).
>
> I am able to build and run the image on the board and the sgx module is 
> loaded :
>
>  lsmod | grep pvr
> pvrsrvkm  389120  0
>
> When I try to run sgx demo like OGLES2Water, I get the error : *PVRShell: 
> Unable to initialise EGL*
>
> I saw on a forum that error is due to the absence of the mesa EGL library. 
> So I installed the package mesa3d from buildroot with the *DRI swrast 
> driver.*
>
> And now I have a new error :* PVRShell: Unable to create surface*
>
> I haven't found the cause of this new error and I am stuck at this stage.
>
> What is my error to make opengl work with buildroot for the black 
> beaglebone?
>
> Thank you
>

-- 
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/4860fc70-8804-4b0d-8356-ef183b351ad3%40googlegroups.com.


[beagleboard] Re: Install on emmc or keep on USB?

2020-05-03 Thread graham
Your microSD card is 64 GB in size. 
You can access it all if you follow the instructions to expand the file 
system.
The eMMC is 4 GB in size.
If you need less than 4 GB, then you can use the eMMC.
If you do a lot of writes, then the 64 GB card will last much longer, since 
the write leveling algorithms have more memory to work with.
If you are just using the BBB for learning and experimentation, then you 
will never use it enough to worry about wearing anything out.
With the uSD card, you could have several different cards, with different 
programs or operating systems on them, and easily switch back and forth.
So, as usual, the answer is "it depends on what you want to do, and what 
you care about."



On Saturday, May 2, 2020 at 11:08:10 PM UTC-5, mahendr...@gmail.com wrote:
>
> Im setting up an beaglebone black i have had for sometime.
> I've downloaded the latest image and flashed it to my SD card(Samsung Evo 
> Select 64Gb).  As im following the instruction on this page: 
> https://beagleboard.org/getting-started,  i have come to part where it 
> states:
>
>  "If using BeagleBone Black, BeagleBone Blue, BeagleBone AI or other 
> board with on-board eMMC flash and you desire to write the image to your 
> on-board eMMC, you'll need to follow the instructions at 
> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Flashing_eMMC;
>
> My question is, are there any benefits of writing th image to the eMMC vs 
> running it of my SD?
>
> 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/d303635b-9baa-4a15-b19e-ef3acc80e929%40googlegroups.com.


[beagleboard] Re: Garbled image on 16-bit parallel RGB LCD (Sitronix ST7701S)

2020-05-03 Thread Robert Forsyth
What I was trying to say, if VS or HS change as the PCLK is rising, then it 
may not register, but the next PCLK clock should register the VS or HS

On Sunday, 3 May 2020 11:44:31 UTC+1, Robert Forsyth wrote:
>
> The Densitron DMT040QBHTNT0-1A data sheet has much useful info.
> DE Mode:
> VS and HS are inverted (active low) 
> DE and DOTCLK (active-high)
>
> HV Mode:
> VS and HS are active-low
> PCLK active-high
> DE always 1
>
> SPI:
> SPI has 4 clock modes
> SCK/SCL is active-high (normally low on fall of active-low CS)
> clocks data in on first rising edge
> clocks data out on first falling edge after first rising edge
>
>
>
> On Monday, 30 March 2020 22:34:30 UTC+1, Corey Vixie wrote:
>>
>> Hi folks. For some months now, I've been trying to get a small LCD based 
>> on the Sitronix ST7701S working with the BeagleBone Black. Because the 
>> Linux kernel only includes a MIPI DSI driver for the ST7701 (which is 
>> similar but not identical), I wrote my own SPI driver in Rust. It's 
>> open-source, available here: 
>> https://github.com/ironblock/ST7701S-SPI-Driver
>>
>> My problem is that no matter what kind of image I try and display, the 
>> output is garbled. I see no distinct pixel color values across an entire 
>> column (or maybe they're lines? I'm not sure which way is up).
>>
>> I've connected it using the 16-bit pinmux, since that seemed "safest". My 
>> SPI commands work, and doing things like "turn all pixels on", "turn all 
>> pixels off", "invert colors", etc. all work as expected, but the image is 
>> never clear. 
>>
>> I put 33R resistors on the data lines in case there was some kind of 
>> reflection or interference that was causing the problem.
>>
>> I'm currently powering the LCD driver from P9.3 (VDD 3.3v). The Sitronix 
>> data sheet indicates that this is allowed, but the LCD vendor's data sheet 
>> says 2.8v±0.3v. So, maybe I'm over-volting it?
>>
>> The vendor tells me that the display should be set to 480x480@60Hz. Using 
>> other resolutions like standard VGA shifts the garbled image as though the 
>> porches were being respected.
>>
>>
>> A public link to the data sheet is here. This is the same as the one I've 
>> been provided by my vendor: 
>> https://focuslcds.com/content/ST7701S_SPEC_%20V1.2.pdf
>>
>> The GitHub contains the dts and uEnv.txt files (or I can copy them here, 
>> if linking out is disallowed in this group).
>>
>> I've copied most of my Github issue below: 
>> https://github.com/ironblock/ST7701S-SPI-Driver/issues/1
>>
>> I appreciate any insight anyone may have. I'm honestly not sure what else 
>> to try. As a disclaimer, I'm new to both Rust and hardware development, so 
>> there's a lot I don't know.
>>
>> I'm happy to answer any questions or provide any additional information.
>>
>> Thanks!
>> --Corey
>>
>>
>> ---
>>
>> Using fim to render a pure white png produces this:
>> [image: IMG_6400] 
>> 
>>
>> The OS is Debian Stretch 9.5 IoT from the Beaglebone website.
>>
>> The display is connected as per the normal 
>>
>> The chosen resolution is 480x480@60Hz. I've also tried the CVT RB and CVT 
>> RBv2 variants of standard VGA (640x480@60Hz, which should be supported by 
>> the ST7701S), and the results are the same, just shifted on the display. 
>> All tested configurations are visible in the device tree overlay.
>>
>> Using fim to display other test images produces similar results. My pure 
>> black png is dark, a color test pattern produces some green effects, etc.
>>
>> Testing the signal lines with a logic analyzer shows the expected values 
>> when sampling the MSB for each color. An excellent example is using a test 
>> image like this:
>> [image: image004] 
>> 
>>
>> When zoomed to the level of a single frame, everything looks correct, 
>> like the datasheet. DE, VSYNC, and HSYNC polarity look good and correct. 
>> The VSYNC refresh rate tested at 59.97hz, which should be appropriate for 
>> the display.
>> [image: image005] 
>> 
>>
>> When I zoom in to look at the timings for each line, everything also 
>> looks correct, and you can see the white and black pattern for each line in 
>> the MSB values. My logic analyzer can only sample as fast as 24MS/s, which 
>> does not accurately capture the pixel clock (which is was set to 16.15MHz 
>> for this test).
>> [image: image006] 
>> 
>>
>> Relevant files:
>>
>>- /boot/uEnv.txt 
>>
>> 
>>- Device tree overlay 
>>
>> 

[beagleboard] Re: Garbled image on 16-bit parallel RGB LCD (Sitronix ST7701S)

2020-05-03 Thread Robert Forsyth
The Densitron DMT040QBHTNT0-1A data sheet has much useful info.
DE Mode:
VS and HS are inverted (active low) 
DE and DOTCLK (active-high)

HV Mode:
VS and HS are active-low
PCLK active-high
DE always 1

SPI:
SPI has 4 clock modes
SCK/SCL is active-high (normally low on fall of active-low CS)
clocks data in on first rising edge
clocks data out on first falling edge after first rising edge



On Monday, 30 March 2020 22:34:30 UTC+1, Corey Vixie wrote:
>
> Hi folks. For some months now, I've been trying to get a small LCD based 
> on the Sitronix ST7701S working with the BeagleBone Black. Because the 
> Linux kernel only includes a MIPI DSI driver for the ST7701 (which is 
> similar but not identical), I wrote my own SPI driver in Rust. It's 
> open-source, available here: 
> https://github.com/ironblock/ST7701S-SPI-Driver
>
> My problem is that no matter what kind of image I try and display, the 
> output is garbled. I see no distinct pixel color values across an entire 
> column (or maybe they're lines? I'm not sure which way is up).
>
> I've connected it using the 16-bit pinmux, since that seemed "safest". My 
> SPI commands work, and doing things like "turn all pixels on", "turn all 
> pixels off", "invert colors", etc. all work as expected, but the image is 
> never clear. 
>
> I put 33R resistors on the data lines in case there was some kind of 
> reflection or interference that was causing the problem.
>
> I'm currently powering the LCD driver from P9.3 (VDD 3.3v). The Sitronix 
> data sheet indicates that this is allowed, but the LCD vendor's data sheet 
> says 2.8v±0.3v. So, maybe I'm over-volting it?
>
> The vendor tells me that the display should be set to 480x480@60Hz. Using 
> other resolutions like standard VGA shifts the garbled image as though the 
> porches were being respected.
>
>
> A public link to the data sheet is here. This is the same as the one I've 
> been provided by my vendor: 
> https://focuslcds.com/content/ST7701S_SPEC_%20V1.2.pdf
>
> The GitHub contains the dts and uEnv.txt files (or I can copy them here, 
> if linking out is disallowed in this group).
>
> I've copied most of my Github issue below: 
> https://github.com/ironblock/ST7701S-SPI-Driver/issues/1
>
> I appreciate any insight anyone may have. I'm honestly not sure what else 
> to try. As a disclaimer, I'm new to both Rust and hardware development, so 
> there's a lot I don't know.
>
> I'm happy to answer any questions or provide any additional information.
>
> Thanks!
> --Corey
>
>
> ---
>
> Using fim to render a pure white png produces this:
> [image: IMG_6400] 
> 
>
> The OS is Debian Stretch 9.5 IoT from the Beaglebone website.
>
> The display is connected as per the normal 
>
> The chosen resolution is 480x480@60Hz. I've also tried the CVT RB and CVT 
> RBv2 variants of standard VGA (640x480@60Hz, which should be supported by 
> the ST7701S), and the results are the same, just shifted on the display. 
> All tested configurations are visible in the device tree overlay.
>
> Using fim to display other test images produces similar results. My pure 
> black png is dark, a color test pattern produces some green effects, etc.
>
> Testing the signal lines with a logic analyzer shows the expected values 
> when sampling the MSB for each color. An excellent example is using a test 
> image like this:
> [image: image004] 
> 
>
> When zoomed to the level of a single frame, everything looks correct, like 
> the datasheet. DE, VSYNC, and HSYNC polarity look good and correct. The 
> VSYNC refresh rate tested at 59.97hz, which should be appropriate for the 
> display.
> [image: image005] 
> 
>
> When I zoom in to look at the timings for each line, everything also looks 
> correct, and you can see the white and black pattern for each line in the 
> MSB values. My logic analyzer can only sample as fast as 24MS/s, which does 
> not accurately capture the pixel clock (which is was set to 16.15MHz for 
> this test).
> [image: image006] 
> 
>
> Relevant files:
>
>- /boot/uEnv.txt 
>
> 
>- Device tree overlay 
>
> 
>
>
> Here is the exact hardware setup I'm using:
>
> [image: IMG_6401] 
> 
>
> [image: Screen Shot 2020-03-30 at 10 46 23 AM] 
>