RE: [beagleboard] ioctl messages to Beagle SPI port.

['Mark Lazarewicz' via BeagleBoard]

#  I can't step the machine code past the ioctl system call
Hi John
What are using to step? It's been a long time but I remember being able to go 
as deep as I wanted into the linux OS. The hard part was getting kernel source 
code setup but i had that working requires debugging from linux build machine  
but you don't seem adverse to assembly language. Probally unrelated but each 
high level language passes it's function parameters to the registers in a 
certain order. I know because we switched from PLM 86 to C one was right to 
left the other was reversed I wrote an assembler library to fix this in the 80s.
You should be able to step into into anything in  mixed c and assembler mode.
Sorry if I'm not totally understanding but it sounds like you could get insight 
if you could step into the ioctl
 if its a function you should be able to . C  Macros you can't but it doesn't 
look like what that is. 

Mark

Sent from Yahoo Mail on Android 
 
  On Wed, May 19, 2021 at 11:10 PM, John Dammeyer 
wrote:   #yiv3788565027 #yiv3788565027 -- _filtered {} _filtered {} _filtered 
{}#yiv3788565027 #yiv3788565027 p.yiv3788565027MsoNormal, #yiv3788565027 
li.yiv3788565027MsoNormal, #yiv3788565027 div.yiv3788565027MsoNormal 
{margin:0cm;margin-bottom:.0001pt;font-size:12.0pt;font-family:New;}#yiv3788565027
 a:link, #yiv3788565027 span.yiv3788565027MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv3788565027 a:visited, #yiv3788565027 
span.yiv3788565027MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv3788565027 p 
{margin-right:0cm;margin-left:0cm;font-size:12.0pt;font-family:New;}#yiv3788565027
 p.yiv3788565027Code, #yiv3788565027 li.yiv3788565027Code, #yiv3788565027 
div.yiv3788565027Code 
{margin:0cm;margin-bottom:.0001pt;font-size:8.0pt;}#yiv3788565027 
span.yiv3788565027EmailStyle18 
{font-family:New;color:windowtext;}#yiv3788565027 
span.yiv3788565027EmailStyle20 {font-family:New;color:#1F497D;}#yiv3788565027 
span.yiv3788565027SpellE {}#yiv3788565027 .yiv3788565027MsoChpDefault 
{font-size:10.0pt;} _filtered {}#yiv3788565027 div.yiv3788565027WordSection1 
{}#yiv3788565027 
So to add this so the research I did isn't repeated.

The control message breaks down as follows:

Top two bits are the direction. The 'k' (0x6B) identifies the SPI type.  The 
number of bytes is placed into the 32 bit word with the _IOC_NRSHIFT which in 
itself is also a macro all defined in the asm generic ioctl.h file.

  

   ret = ioctl(fd, _IOC(_IOC_WRITE,('k'),(1),(8), );

#define _IOC(dir,type,nr,size) \

    (((dir)  << _IOC_DIRSHIFT) | \

 ((type) << _IOC_TYPESHIFT) | \

 ((nr)   << _IOC_NRSHIFT) | \

 ((size) << _IOC_SIZESHIFT))

  

The shifts are defined to create this and it's quite convoluted to get there.

SPI_IOC_MESSAGE(1) = 40206B00

  

define _IOC_NRBITS 8

#define _IOC_TYPEBITS   8

  

/*

 * Let any architecture override either of the following before

 * including this file.

 */

  

#ifndef _IOC_SIZEBITS

# define _IOC_SIZEBITS  14

#endif

  

#ifndef _IOC_DIRBITS

# define _IOC_DIRBITS   2

#endif

  

#define _IOC_NRMASK ((1 << _IOC_NRBITS)-1)

#define _IOC_TYPEMASK   ((1 << _IOC_TYPEBITS)-1)

#define _IOC_SIZEMASK   ((1 << _IOC_SIZEBITS)-1)

#define _IOC_DIRMASK    ((1 << _IOC_DIRBITS)-1)

  

#define _IOC_NRSHIFT    0

#define _IOC_TYPESHIFT  (_IOC_NRSHIFT+_IOC_NRBITS)

#define _IOC_SIZESHIFT  (_IOC_TYPESHIFT+_IOC_TYPEBITS)

#define _IOC_DIRSHIFT   (_IOC_SIZESHIFT+_IOC_SIZEBITS)

  

#define _IOC_NRSHIFT    0

#define _IOC_TYPESHIFT  (_IOC_NRSHIFT+_IOC_NRBITS)

#define _IOC_SIZESHIFT  (_IOC_TYPESHIFT+_IOC_TYPEBITS)

#define _IOC_DIRSHIFT   (_IOC_SIZESHIFT+_IOC_SIZEBITS)

  

 

From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of John Dammeyer
Sent: May-19-21 8:44 PM
To: beagleboard@googlegroups.com
Subject: [beagleboard] ioctl messages to Beagle SPI port.

  

The spidev_test.c program from the Exploring BeagleBone by Derek Molloy (chp08) 
tests the SPI port by setting the SPI parameters and then writing out a test 
block.  The text diagnostics I've added show what the macro was that is sent as 
part of the ioctl call.  Trying to break down the macro through multiple files 
turned into a dead end and I'm not exactly sure what the 32 bit word means 
other than byte count and I believe message type.

The program starts out by sending 6 ioctl messages that configure mode, size 
and speed.

Here's the call that returns the 0x4006B00 and below the result of the message.

ret = ioctl(fd, SPI_IOC_MESSAGE(1), );

  

debian@ebb:~/exploringBB/chp08/spi/spidev_test$ ./spidev_test       

SPI_IOC_WR_MODE = 40016B01

SPI_IOC_RD_MODE = 80016B01

SPI_IOC_WR_BITS_PER_WORD = 40016B03

SPI_IOC_RD_BITS_PER_WORD = 80016B03

SPI_IOC_WR_MAX_SPEED_HZ = 40046B04

SPI_IOC_RD_MAX_SPEED_HZ = 80046B04

spi mode: 0

bits per word: 8

max speed: 50 Hz (500 KHz)

SPI_IOC_MESSAGE(1) = 40206B00

  

00 00 00 00 00 00

00 00 00 00 

RE: [beagleboard] ioctl messages to Beagle SPI port.

[John Dammeyer]

So to add this so the research I did isn't repeated.
The control message breaks down as follows:
Top two bits are the direction. The 'k' (0x6B) identifies the SPI type.  The 
number of bytes is placed into the 32 bit word with the _IOC_NRSHIFT which in 
itself is also a macro all defined in the asm generic ioctl.h file.
 
   ret = ioctl(fd, _IOC(_IOC_WRITE,('k'),(1),(8), );
#define _IOC(dir,type,nr,size) \
(((dir)  << _IOC_DIRSHIFT) | \
 ((type) << _IOC_TYPESHIFT) | \
 ((nr)   << _IOC_NRSHIFT) | \
 ((size) << _IOC_SIZESHIFT))
 
The shifts are defined to create this and it's quite convoluted to get there.
SPI_IOC_MESSAGE(1) = 40206B00
 
define _IOC_NRBITS 8
#define _IOC_TYPEBITS   8
 
/*
* Let any architecture override either of the following before
* including this file.
*/
 
#ifndef _IOC_SIZEBITS
# define _IOC_SIZEBITS  14
#endif
 
#ifndef _IOC_DIRBITS
# define _IOC_DIRBITS   2
#endif
 
#define _IOC_NRMASK ((1 << _IOC_NRBITS)-1)
#define _IOC_TYPEMASK   ((1 << _IOC_TYPEBITS)-1)
#define _IOC_SIZEMASK   ((1 << _IOC_SIZEBITS)-1)
#define _IOC_DIRMASK((1 << _IOC_DIRBITS)-1)
 
#define _IOC_NRSHIFT0
#define _IOC_TYPESHIFT  (_IOC_NRSHIFT+_IOC_NRBITS)
#define _IOC_SIZESHIFT  (_IOC_TYPESHIFT+_IOC_TYPEBITS)
#define _IOC_DIRSHIFT   (_IOC_SIZESHIFT+_IOC_SIZEBITS)
 
#define _IOC_NRSHIFT0
#define _IOC_TYPESHIFT  (_IOC_NRSHIFT+_IOC_NRBITS)
#define _IOC_SIZESHIFT  (_IOC_TYPESHIFT+_IOC_TYPEBITS)
#define _IOC_DIRSHIFT   (_IOC_SIZESHIFT+_IOC_SIZEBITS)
 
From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of John Dammeyer
Sent: May-19-21 8:44 PM
To: beagleboard@googlegroups.com
Subject: [beagleboard] ioctl messages to Beagle SPI port.
 
The spidev_test.c program from the Exploring BeagleBone by Derek Molloy (chp08) 
tests the SPI port by setting the SPI parameters and then writing out a test 
block.  The text diagnostics I've added show what the macro was that is sent as 
part of the ioctl call.  Trying to break down the macro through multiple files 
turned into a dead end and I'm not exactly sure what the 32 bit word means 
other than byte count and I believe message type.
The program starts out by sending 6 ioctl messages that configure mode, size 
and speed.
Here's the call that returns the 0x4006B00 and below the result of the message.
ret = ioctl(fd, SPI_IOC_MESSAGE(1), );
 
debian@ebb:~/exploringBB/chp08/spi/spidev_test$ ./spidev_test   
SPI_IOC_WR_MODE = 40016B01
SPI_IOC_RD_MODE = 80016B01
SPI_IOC_WR_BITS_PER_WORD = 40016B03
SPI_IOC_RD_BITS_PER_WORD = 80016B03
SPI_IOC_WR_MAX_SPEED_HZ = 40046B04
SPI_IOC_RD_MAX_SPEED_HZ = 80046B04
spi mode: 0
bits per word: 8
max speed: 50 Hz (500 KHz)
SPI_IOC_MESSAGE(1) = 40206B00
 
00 00 00 00 00 00
00 00 00 00 00 00
00 00 00 00 00 00
00 00 00 00 00 00
00 00 00 00 00 00
00 00 00 00 00 00
00 00
 
Now.  Switch over to a part of the DisplaySPI program in the Lazarus Free 
Pascal pxl library the function call looks the same as do the SPI 
initialization calls to fpioctl.  They are in a different order from the C 
program.
 
Res := fpioctl(FHandle, SPI_IOC_MESSAGE(1), @Data);
 
Six of the ioctl function calls do not return an error.  The main one to send 
data has the correct 
SPI_IOC_MESSAGE(1) value yet it fails.
 
debian@ebb:~/lazarus/pxl/Samples/FreePascal/SingleBoard/Generic/DisplaySPI$ 
./DisplaySPI
UpdateFrequency -- SPI_IOC_WR_MAX_SPEED_HZ is 40046B04
UpdateFrequency -- SPI_IOC_RD_MAX_SPEED_HZ is 80046B04
UpdateBitsPerWord -- SPI_IOC_WR_BITS_PER_WORD is 40016B03
UpdateBitsPerWord -- SPI_IOC_RD_BITS_PER_WORD is 80016B03
UpdateRWMode -- SPI_IOC_WR_MODE is 40016B01
UpdateRWMode -- SPI_IOC_RD_MODE is 80016B01
SPI_IOC_MESSAGE(1) is 40206B00
An unhandled exception occurred at $000330A8:
 ESysfsSPITransfer: Cannot transfer 
<1> data byte(s) through SPI bus.
   $000330A8  TSYSFSSPI__TRANSFER,  line 263 of 
/home/debian/lazarus/pxl/Source/PXL.Sysfs.SPI.pas
   $00032F54  TSYSFSSPI__WRITE, 
 line 241 of /home/debian/lazarus/pxl/Source/PXL.Sysfs.SPI.pas
 
Is there some documentation out there on the ioctl call and what the actual 
parameter means in detail with respect to the BeagleBone processor?  The man 
page states that command is specific to the device.
https://man7.org/linux/man-pages/man2/ioctl.2.html
 
I'm having trouble figuring out why it fails or more specifically where to look 
next.  I can't step the machine code past the ioctl system call so I'd like to 
know what is actually going on inside the OS with this call inside the Beagle.
 
Thanks
John
 
"ELS! Nothing else works as well for your Lathe"
Automation Artisans Inc.
www dot autoartisans dot 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 

[beagleboard] ioctl messages to Beagle SPI port.

[John Dammeyer]

The spidev_test.c program from the Exploring BeagleBone by Derek Molloy (chp08) 
tests the SPI port by setting the SPI parameters and then writing out a test 
block.  The text diagnostics I've added show what the macro was that is sent as 
part of the ioctl call.  Trying to break down the macro through multiple files 
turned into a dead end and I'm not exactly sure what the 32 bit word means 
other than byte count and I believe message type.
The program starts out by sending 6 ioctl messages that configure mode, size 
and speed.
Here's the call that returns the 0x4006B00 and below the result of the message.
ret = ioctl(fd, SPI_IOC_MESSAGE(1), );
 
debian@ebb:~/exploringBB/chp08/spi/spidev_test$ ./spidev_test   
SPI_IOC_WR_MODE = 40016B01
SPI_IOC_RD_MODE = 80016B01
SPI_IOC_WR_BITS_PER_WORD = 40016B03
SPI_IOC_RD_BITS_PER_WORD = 80016B03
SPI_IOC_WR_MAX_SPEED_HZ = 40046B04
SPI_IOC_RD_MAX_SPEED_HZ = 80046B04
spi mode: 0
bits per word: 8
max speed: 50 Hz (500 KHz)
SPI_IOC_MESSAGE(1) = 40206B00
 
00 00 00 00 00 00
00 00 00 00 00 00
00 00 00 00 00 00
00 00 00 00 00 00
00 00 00 00 00 00
00 00 00 00 00 00
00 00
 
Now.  Switch over to a part of the DisplaySPI program in the Lazarus Free 
Pascal pxl library the function call looks the same as do the SPI 
initialization calls to fpioctl.  They are in a different order from the C 
program.
 
Res := fpioctl(FHandle, SPI_IOC_MESSAGE(1), @Data);
 
Six of the ioctl function calls do not return an error.  The main one to send 
data has the correct 
SPI_IOC_MESSAGE(1) value yet it fails.
 
debian@ebb:~/lazarus/pxl/Samples/FreePascal/SingleBoard/Generic/DisplaySPI$ 
./DisplaySPI
UpdateFrequency -- SPI_IOC_WR_MAX_SPEED_HZ is 40046B04
UpdateFrequency -- SPI_IOC_RD_MAX_SPEED_HZ is 80046B04
UpdateBitsPerWord -- SPI_IOC_WR_BITS_PER_WORD is 40016B03
UpdateBitsPerWord -- SPI_IOC_RD_BITS_PER_WORD is 80016B03
UpdateRWMode -- SPI_IOC_WR_MODE is 40016B01
UpdateRWMode -- SPI_IOC_RD_MODE is 80016B01
SPI_IOC_MESSAGE(1) is 40206B00
An unhandled exception occurred at $000330A8:
 ESysfsSPITransfer: Cannot transfer 
<1> data byte(s) through SPI bus.
   $000330A8  TSYSFSSPI__TRANSFER,  line 263 of 
/home/debian/lazarus/pxl/Source/PXL.Sysfs.SPI.pas
   $00032F54  TSYSFSSPI__WRITE, 
 line 241 of /home/debian/lazarus/pxl/Source/PXL.Sysfs.SPI.pas
 
Is there some documentation out there on the ioctl call and what the actual 
parameter means in detail with respect to the BeagleBone processor?  The man 
page states that command is specific to the device.
https://man7.org/linux/man-pages/man2/ioctl.2.html
 
I'm having trouble figuring out why it fails or more specifically where to look 
next.  I can't step the machine code past the ioctl system call so I'd like to 
know what is actually going on inside the OS with this call inside the Beagle.
 
Thanks
John
 
"ELS! Nothing else works as well for your Lathe"
Automation Artisans Inc.
www dot autoartisans dot 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/02a901d74d2a%246b84f600%24428ee200%24%40autoartisans.com.

[beagleboard] Re: Reducing Boottime in Beaglebone Black

[Dennis Lee Bieber]

On Wed, 19 May 2021 09:37:32 -0700, in gmane.comp.hardware.beagleboard.user
"John Dammeyer"  wrote:

>Hi Amit,
>Interesting.  4.19.94 is a only a little bit faster than 4.14.108.  Is there a 
>document somewhere that explains what to do to even just speed up both start 
>up and shut down?
>What did you do to get it to 50 seconds?
> 
>John
> 
> 
>debian@ebb:~$ uname -a
>Linux ebb 4.14.108-ti-r136 #1stretch SMP PREEMPT Mon Jun 8 15:38:30 UTC 2020 
>armv7l GNU/Linux
> 
>debian@ebb:~$ systemd-analyze
>Startup finished in 40.059s (kernel) + 1min 27.889s (userspace) = 2min 7.948s
> 
>debian@ebb:~$ systemd-analyze blame
>1min 47.177s dev-mmcblk0p1.device
>1min 13.819s generic-board-startup.service
> 
>debian@beaglebone:~$ uname -a
>Linux beaglebone 4.19.94-ti-r63 #1buster SMP PREEMPT Fri May 14 16:42:32 UTC 
>2021 armv7l GNU/Linux
> 
>debian@beaglebone:~$ systemd-analyze
>Startup finished in 26.608s (kernel) + 1min 32.506s (userspace) = 1min 59.114s
>graphical.target reached after 1min 32.205s in userspace
> 
>debian@beaglebone:~$ systemd-analyze blame
>1min 20.997s generic-board-startup.service
> 1min 4.519s dev-mmcblk0p1.device
> 11.344s udisks2.service
> 

Just to add a data point: Buster IoT image on uSD card...

debian@beaglebone:~$ uname -a
Linux beaglebone 4.19.94-ti-r48 #1buster SMP PREEMPT Wed Aug 19 17:38:55
UTC 2020 armv7l GNU/Linux

debian@beaglebone:~$ systemd-analyze
Startup finished in 10.915s (kernel) + 1min 961ms (userspace) = 1min
11.877s
graphical.target reached after 1min 668ms in userspace

That's odd -- Did I leave the LXQT image in the board (I have uSD for
both IoT and LXQT)

debian@beaglebone:~$ systemd-analyze blame
 51.745s generic-board-startup.service
 40.798s dev-mmcblk0p1.device
  4.064s nginx.service
  3.587s systemd-udev-trigger.service

From DMESG one finds such ...

[1.668861] ALSA device list:
[1.668877]   #0: TI BeagleBone Black
[1.675450] Freeing unused kernel memory: 1024K
[1.676178] Run /init as init process
[2.664089] [drm] Cannot find any crtc or sizes
[   10.155042] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data
mode. Opts: (null)
[   10.955497] systemd[1]: System time before build time, advancing clock.

EIGHT seconds mounting file system

[   13.203659] EXT4-fs (mmcblk0p1): re-mounted. Opts: errors=remount-ro
[   14.816264] systemd-journald[893]: Received request to flush runtime
journal from PID 1
[   21.928916] net eth0: initializing cpsw version 1.12 (0)
[   22.000769] SMSC LAN8710/LAN8720 4a101000.mdio:00: attached PHY driver
[SMSC LAN8710/LAN8720] (mii_bus:phy_addr=4a101000.mdio:00, irq=POLL)

SEVEN seconds initializing eth0

[   27.071692] configfs-gadget gadget: high-speed config #1: c
[   27.072147] IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready
[   27.277845] IPv6: ADDRCONF(NETDEV_UP): usb1: link is not ready
[   69.566416] remoteproc remoteproc0: wkup_m3 is available
[   69.658941] remoteproc remoteproc0: powering up wkup_m3
[   69.658973] remoteproc remoteproc0: Booting fw image
am335x-pm-firmware.elf, size 217168

FORTY seconds preparing the PRUs with remoteproc

Let me switch uSD card...

debian@beaglebone:~$ uname -a
Linux beaglebone 4.19.94-ti-r48 #1buster SMP PREEMPT Wed Aug 19 17:38:55
UTC 2020 armv7l GNU/Linux

debian@beaglebone:~$ systemd-analyze
Bootup is not yet finished
(org.freedesktop.systemd1.Manager.FinishTimestampMonotonic=0).
Please try again later.
Hint: Use 'systemctl list-jobs' to see active jobs
debian@beaglebone:~$ systemctl list-jobs
JOB UNIT TYPE  STATE
 89 getty.target start waiting
 69 generic-board-startup.servicestart running
 97 serial-getty@ttyGS0.service  start waiting
  2 multi-user.targetstart waiting
  1 graphical.target start waiting
 81 systemd-update-utmp-runlevel.service start waiting
 98 dev-ttyGS0.devicestart running

7 jobs listed.

Hmmm, looks like I need to attach an HDMI cable and monitor to
determine which has the LXQT image...

debian@beaglebone:~$ systemctl list-jobs
No jobs running.

debian@beaglebone:~$ systemd-analyze
Startup finished in 11.355s (kernel) + 1min 24.913s (userspace) = 1min
36.268s
graphical.target reached after 1min 24.632s in userspace
debian@beaglebone:~$ systemd-analyze blame
1min 15.551s generic-board-startup.service
 1min 1.691s dev-mmcblk0p1.device
  9.380s udisks2.service

DMESG output snippets

[1.928371] Run /init as init process
[2.920215] [drm] Cannot find any crtc or sizes
[   10.473694] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data
mode. Opts: (null)
[   11.394359] systemd[1]: System time before build time, advancing clock.

SEVEN and a half seconds mounting filesystem

[   14.116062] EXT4-fs (mmcblk0p1): re-mounted. Opts: errors=remount-ro
[  

RE: [beagleboard] Reducing Boottime in Beaglebone Black

[John Dammeyer]

Hi Amit,
Interesting.  4.19.94 is a only a little bit faster than 4.14.108.  Is there a 
document somewhere that explains what to do to even just speed up both start up 
and shut down?
What did you do to get it to 50 seconds?
 
John
 
 
debian@ebb:~$ uname -a
Linux ebb 4.14.108-ti-r136 #1stretch SMP PREEMPT Mon Jun 8 15:38:30 UTC 2020 
armv7l GNU/Linux
 
debian@ebb:~$ systemd-analyze
Startup finished in 40.059s (kernel) + 1min 27.889s (userspace) = 2min 7.948s
 
debian@ebb:~$ systemd-analyze blame
1min 47.177s dev-mmcblk0p1.device
1min 13.819s generic-board-startup.service
 
debian@beaglebone:~$ uname -a
Linux beaglebone 4.19.94-ti-r63 #1buster SMP PREEMPT Fri May 14 16:42:32 UTC 
2021 armv7l GNU/Linux
 
debian@beaglebone:~$ systemd-analyze
Startup finished in 26.608s (kernel) + 1min 32.506s (userspace) = 1min 59.114s
graphical.target reached after 1min 32.205s in userspace
 
debian@beaglebone:~$ systemd-analyze blame
1min 20.997s generic-board-startup.service
 1min 4.519s dev-mmcblk0p1.device
 11.344s udisks2.service
 
From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of Amit Goradia
Sent: May-19-21 12:00 AM
To: BeagleBoard
Subject: Re: [beagleboard] Reducing Boottime in Beaglebone Black
 
Hi Robert,
Awesome work with the Beaglebone OS and tools. Entry point for a beginier is so 
much simplified using the tools you provide.
I know this topic is OLD.
I have been trying to get my boot times with a BBB down from about 50s to 20s
I have started with a Debian Stretch 9.12 console image. Upgraded it to 
realtime kernel 4.19. Booting from EMMC.
Trying to get a single console app or X11 app open in less than 20-25s
This is my output for systemd-analyze blame
 
debian@beaglebone:~$ systemd-analyze
Startup finished in 1.690s (kernel) + 50.841s (userspace) = 52.532s
debian@beaglebone:~$ systemd-analyze blame
1min 15.560s dev-mmcblk1p1.device
  8.459s generic-board-startup.service
  4.654s systemd-udev-trigger.service
  3.188s loadcpufreq.service
  2.620s networking.service
  2.157s keyboard-setup.service
  1.791s systemd-logind.service
  1.711s dnsmasq.service
  1.631s ssh.service
  1.529s rsyslog.service
  1.429s user@1001.service
  1.418s systemd-journald.service
  1.204s cpufrequtils.service
  1.071s systemd-timesyncd.service
   918ms systemd-fsck-root.service
   597ms systemd-udevd.service
   528ms dev-mqueue.mount
   515ms sys-kernel-debug.mount
   495ms systemd-tmpfiles-setup-dev.service
   469ms systemd-tmpfiles-setup.service
   451ms systemd-sysctl.service
   417ms systemd-modules-load.service
   400ms systemd-user-sessions.service
   388ms sys-fs-fuse-connections.mount
   369ms systemd-journal-flush.service
   355ms slim.service
   324ms systemd-update-utmp.service
   311ms sys-kernel-config.mount
   303ms kmod-static-nodes.service
   300ms systemd-remount-fs.service
   238ms console-setup.service
   210ms systemd-random-seed.service
   140ms systemd-update-utmp-runlevel.service
debian@beaglebone:~$ uname -a
Linux beaglebone 4.19.94-ti-rt-r63 #1stretch SMP PREEMPT RT Fri May 14 16:42:35 
UTC 2021 armv7l GNU/Linux
 
Any advise you can give to reduce the userspace time further?
IT would be really helpful if you could list the optimizations you did for the  
FLIR demo app.
 
Regards,
amit
 
On Monday, 16 July, 2018 at 8:35:57 pm UTC+5:30 RobertCNelson wrote:
On Mon, Jul 16, 2018 at 10:01 AM, sajeevan k  wrote: 
> 
> Hi Robert Nelson, Dennis Lee & Daniel Kulp, 
> 
> 
> Thank You very much for the reply and support. 
> 
> I have been little busy with some other tasks. So I couldn't test with the 
> iot image. 
> I am hopeful in the idea of starting from iot image and build up from it. 
> 
> Will the fix for CVE-2018-1108, affect the normal booting of Beaglebone 
> black? Is there a chance that normal applications access random data at boot 
> time? 

Even with the fix for that CVE, v4.14.x is still faster then v4.9.x.. 
It just use to be 'way' faster.. 

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/989d9ca9-b8c8-424d-a88a-62cac4d4cc36n%40googlegroups.com
 

 .

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google 

Re: [beagleboard] Reducing Boottime in Beaglebone Black

[Amit Goradia]

Hi Robert,
Awesome work with the Beaglebone OS and tools. Entry point for a beginier 
is so much simplified using the tools you provide.
I know this topic is OLD.
I have been trying to get my boot times with a BBB down from about 50s to 
20s
I have started with a Debian Stretch 9.12 console image. Upgraded it to 
realtime kernel 4.19. Booting from EMMC.
Trying to get a single console app or X11 app open in less than 20-25s
This is my output for systemd-analyze blame

debian@beaglebone:~$ systemd-analyze
Startup finished in 1.690s (kernel) + 50.841s (userspace) = 52.532s
debian@beaglebone:~$ systemd-analyze blame
1min 15.560s dev-mmcblk1p1.device
  8.459s generic-board-startup.service
  4.654s systemd-udev-trigger.service
  3.188s loadcpufreq.service
  2.620s networking.service
  2.157s keyboard-setup.service
  1.791s systemd-logind.service
  1.711s dnsmasq.service
  1.631s ssh.service
  1.529s rsyslog.service
  1.429s user@1001.service
  1.418s systemd-journald.service
  1.204s cpufrequtils.service
  1.071s systemd-timesyncd.service
   918ms systemd-fsck-root.service
   597ms systemd-udevd.service
   528ms dev-mqueue.mount
   515ms sys-kernel-debug.mount
   495ms systemd-tmpfiles-setup-dev.service
   469ms systemd-tmpfiles-setup.service
   451ms systemd-sysctl.service
   417ms systemd-modules-load.service
   400ms systemd-user-sessions.service
   388ms sys-fs-fuse-connections.mount
   369ms systemd-journal-flush.service
   355ms slim.service
   324ms systemd-update-utmp.service
   311ms sys-kernel-config.mount
   303ms kmod-static-nodes.service
   300ms systemd-remount-fs.service
   238ms console-setup.service
   210ms systemd-random-seed.service
   140ms systemd-update-utmp-runlevel.service
debian@beaglebone:~$ uname -a
Linux beaglebone 4.19.94-ti-rt-r63 #1stretch SMP PREEMPT RT Fri May 14 
16:42:35 UTC 2021 armv7l GNU/Linux

Any advise you can give to reduce the userspace time further?
IT would be really helpful if you could list the optimizations you did for 
the  FLIR demo app.

Regards,
amit

On Monday, 16 July, 2018 at 8:35:57 pm UTC+5:30 RobertCNelson wrote:

> On Mon, Jul 16, 2018 at 10:01 AM, sajeevan k  wrote:
> >
> > Hi Robert Nelson, Dennis Lee & Daniel Kulp,
> >
> >
> > Thank You very much for the reply and support.
> >
> > I have been little busy with some other tasks. So I couldn't test with 
> the
> > iot image.
> > I am hopeful in the idea of starting from iot image and build up from it.
> >
> > Will the fix for CVE-2018-1108, affect the normal booting of Beaglebone
> > black? Is there a chance that normal applications access random data at 
> boot
> > time?
>
> Even with the fix for that CVE, v4.14.x is still faster then v4.9.x..
> It just use to be 'way' faster..
>
> 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/989d9ca9-b8c8-424d-a88a-62cac4d4cc36n%40googlegroups.com.

[beagleboard] Re: Weird C problem: PRU doesn't respond to host if two variables aren't initialized in loop

[Walter Cromer]

Dennis, 

Thanks again for pointing out the redundancy.   Now that I have this very 
strange problem figured out I'm going to do some work on that and clean it 
up.

Walter

On Tuesday, May 18, 2021 at 8:14:18 PM UTC-4 Dennis Bieber wrote:

> On Tue, 18 May 2021 11:22:20 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user Walter Cromer
>  wrote:
>
>
> >Here's the code snippet with the two variables in bold. If those lines of 
> >code do not exist, the host doesn't hear from the PRU.
>
> Such formatting does not get through the gmane list<>newsgroup
> interface. I'm going to presume you mean the lines with * markers. Posting
> with a client that keeps indentation would also help... hard to keep track
> of what is nested into what when everything is left justified with excess
> blank lines.
>
> Normal recommendation is to condense the code down to the minimum that
> still reproduces the problem, and to post the minimized files completely
> (probably need both PRU and ARM programs). That allows others to attempt to
> run/compare/debug.
>
> >
> > 
> >
> >count = HWREG(SOC_ADC_TSC_0_REGS + TSC_ADC_SS_FIFOCOUNT(0));
> >
> > 
> >
> >for (i = 0; i < count; i++) 
> >
> >{
> >
> >Data = HWREG(SOC_ADC_TSC_0_REGS + TSC_ADC_SS_FIFODATA(0));
> >
> >StepRead = (Data >> 16) & 0xF;
> >
> >RawAnalog = Data & 0xFFF;
> >
> > 
> >
> >switch (StepRead)
> >
> >{
> >
> >case 0:
> >
> > 
> >
> >DetTSampleSet[pnr]=RawAnalog;
> >
> >break;
> >
> >case 1:
> >
> > 
> >
> >*start_of_pulse = 0;*
> >
> >*end_of_pulse = 0;*
>
> Where were these declared?
> >
> > 
> >
> >DetBSampleSet[pnr]=RawAnalog;
> >
> >if ((pnr == end_of_pulse) && (in_pulse == E_YES)) // seen a pulse and at 
> >end of it analyze signal
>
> Where is pnr defined/initialized? Same for in_pulse. 
> >
> >{
> >
> >DetBSignalAverage= AnalyzeSignal(start_of_pulse, pnr);
> >
> >start_of_pulse = -1;
> >
> >end_of_pulse = -1;
> >
>
> If pnr is an index into some buffer, I'd probably use -1 to signal NO
> DATA, and use the pnr values active at the time the pulse is detected for
> start_of_pulse and the when the pulse ended for end_of_pulse
>
> >samples_in_pulse = 0;
> >
> >in_pulse = E_NO;
>
> In a way, all these seem redundant: start at -1 indicates no data,
> no samples, and not in a pulse. Samples_in_pulse at 0 indicates no data, no
> samples, and likely not in a pulse. in_pulse at E_NO implies no data, no
> samples.
>
> So, start are set to the appropriate pnr values... "in_pulse" is
> indicated by start_of_pulse > -1 AND end_of_pulse = -1; "not in_pulse" is
> indicated by (start_of_pulse > -1 AND end_of_pulse > -1) OR (start_of_pulse
> = -1) //presumes you set both start/end to -1 at the same time
>
> >
> >if (start_of_pulse < 0) start_of_pulse = pnr; // set start pointer in 
> ring 
> >buffer if it hasn't already been set for this pulse
> >
>
> Okay, you do set start/end to the instantaneous pnr value... Just
> emphasizes that samples_in_pulse and in_pulse are logically redundant and
> hence a potential source of error (samples_in_pulse should be end - start
> (maybe with a +1; do the math with a sample buffer). Note: if this is a
> circular buffer you'll need to account for wrap-around.
>
>
> -- 
> 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/c8ad6b9c-dff0-4595-ae96-8e31f8e02856n%40googlegroups.com.

Re: [beagleboard] Re: Weird C problem: PRU doesn't respond to host if two variables aren't initialized in loop

[Walter Cromer]

I had a similar thought and tried declaring them as volatile.  No change in 
behavior.
I also tried making them global vs. local.  No change.  It was very strange.

What finally worked was changing their names entirely.  
start_of_pulse became PulseStart 
end_or_pulse became PulseEnd

Now the code works without the two lines of code marked with the '*'.  So 
very, very strange.

On Wednesday, May 19, 2021 at 4:42:11 AM UTC-4 robert.sty...@gmail.com 
wrote:

> Were the variables declared as `volatile`? May be the compiler optimized 
> them out of the loop and you might get different behaviour between DEBUG 
> build and RELEASE build.
>
> I am guessing the ADC data register is volatile, and this triggers.
>
> I am guessing the compiler optimization sees two variables set but never 
> used, so there is no need to include code to set the variables. If declared 
> as volatile, the compiler knows the variables may be set or read elsewhere.
>
> On Wednesday, 19 May 2021 at 02:09:19 UTC+1 wal...@edenconceptsllc.com 
> wrote:
>
>> i’m replying from an email client but I lost the original and most of my 
>> replies using Chrome and directly access the group through it.  I thought 
>> it might not present well but I actually highlighted with the client.  If 
>> you’ll tell me what I should use instead I will start using it for future 
>> posts.  I want to make them as easy to read as possible.  
>>
>> I left all the declarations off but mentioned they are declared as 
>> unsigned int or int. 
>>
>> Yes, this version likely does have some redundancy with 
>> samples_in_pulse.  It is a work in progress that wasn’t making much 
>> progress because of this weird problem. 
>>
>> It appears now that the names start_of_pulse and end_of_pulse were the 
>> problem for some reason.   I changed them to PulseStart and PulseEnd and 
>> the PRU responds now.   I have no idea what the problem with those names 
>> is.  
>>
>> Walter
>>
>> On Tue, May 18, 2021 at 8:14 PM Dennis Lee Bieber  
>> wrote:
>>
>>> On Tue, 18 May 2021 11:22:20 -0700 (PDT), in
>>> gmane.comp.hardware.beagleboard.user Walter Cromer
>>>  wrote:
>>>
>>>
>>> >Here's the code snippet with the two variables in bold.  If those lines 
>>> of 
>>> >code do not exist, the host doesn't hear from the PRU.
>>>
>>> Such formatting does not get through the gmane list<>newsgroup
>>> interface. I'm going to presume you mean the lines with * markers. 
>>> Posting
>>> with a client that keeps indentation would also help... hard to keep 
>>> track
>>> of what is nested into what when everything is left justified with excess
>>> blank lines.
>>>
>>> Normal recommendation is to condense the code down to the 
>>> minimum that
>>> still reproduces the problem, and to post the minimized files completely
>>> (probably need both PRU and ARM programs). That allows others to attempt 
>>> to
>>> run/compare/debug.
>>>
>>> >
>>> > 
>>> >
>>> >count = HWREG(SOC_ADC_TSC_0_REGS + TSC_ADC_SS_FIFOCOUNT(0));
>>> >
>>> > 
>>> >
>>> >for (i = 0; i < count; i++) 
>>> >
>>> >{
>>> >
>>> >Data = HWREG(SOC_ADC_TSC_0_REGS + TSC_ADC_SS_FIFODATA(0));
>>> >
>>> >StepRead = (Data >> 16) & 0xF;
>>> >
>>> >RawAnalog = Data & 0xFFF;
>>> >
>>> > 
>>> >
>>> >switch (StepRead)
>>> >
>>> >{
>>> >
>>> >case 0:
>>> >
>>> > 
>>> >
>>> >DetTSampleSet[pnr]=RawAnalog;
>>> >
>>> >break;
>>> >
>>> >case 1:
>>> >
>>> >  
>>> >
>>> >*start_of_pulse = 0;*
>>> >
>>> >*end_of_pulse = 0;*
>>>
>>> Where were these declared?
>>> >
>>> > 
>>> >
>>> >DetBSampleSet[pnr]=RawAnalog;
>>> >
>>> >if ((pnr == end_of_pulse) && (in_pulse == E_YES)) // seen a pulse and 
>>> at 
>>> >end of it analyze signal
>>>
>>> Where is pnr defined/initialized? Same for in_pulse. 
>>> >
>>> >{
>>> >
>>> >DetBSignalAverage= AnalyzeSignal(start_of_pulse, pnr);
>>> >
>>> >start_of_pulse = -1;
>>> >
>>> >end_of_pulse = -1;
>>> >
>>>
>>> If pnr is an index into some buffer, I'd probably use -1 to 
>>> signal NO
>>> DATA, and use the pnr values active at the time the pulse is detected for
>>> start_of_pulse and the when the pulse ended for end_of_pulse
>>>
>>> >samples_in_pulse = 0;
>>> >
>>> >in_pulse = E_NO;
>>>
>>> In a way, all these seem redundant: start at -1 indicates no 
>>> data,
>>> no samples, and not in a pulse. Samples_in_pulse at 0 indicates no data, 
>>> no
>>> samples, and likely not in a pulse. in_pulse at E_NO implies no data, no
>>> samples.
>>>
>>> So, start are set to the appropriate pnr values... 
>>> "in_pulse" is
>>> indicated by start_of_pulse > -1 AND end_of_pulse = -1; "not in_pulse" is
>>> indicated by (start_of_pulse > -1 AND end_of_pulse > -1) OR 
>>> (start_of_pulse
>>> = -1) //presumes you set both start/end to -1 at the same time
>>>
>>> >
>>> >if (start_of_pulse < 0) start_of_pulse = pnr;  // set start pointer in 
>>> ring 
>>> >buffer if it hasn't already been set for this pulse
>>> >
>>>
>>> Okay, you do set start/end to the 

Re: [beagleboard] Re: Weird C problem: PRU doesn't respond to host if two variables aren't initialized in loop

[robert.sty...@gmail.com]

Were the variables declared as `volatile`? May be the compiler optimized 
them out of the loop and you might get different behaviour between DEBUG 
build and RELEASE build.

I am guessing the ADC data register is volatile, and this triggers.

I am guessing the compiler optimization sees two variables set but never 
used, so there is no need to include code to set the variables. If declared 
as volatile, the compiler knows the variables may be set or read elsewhere.

On Wednesday, 19 May 2021 at 02:09:19 UTC+1 wal...@edenconceptsllc.com 
wrote:

> i’m replying from an email client but I lost the original and most of my 
> replies using Chrome and directly access the group through it.  I thought 
> it might not present well but I actually highlighted with the client.  If 
> you’ll tell me what I should use instead I will start using it for future 
> posts.  I want to make them as easy to read as possible.  
>
> I left all the declarations off but mentioned they are declared as 
> unsigned int or int. 
>
> Yes, this version likely does have some redundancy with samples_in_pulse.  
> It is a work in progress that wasn’t making much progress because of this 
> weird problem. 
>
> It appears now that the names start_of_pulse and end_of_pulse were the 
> problem for some reason.   I changed them to PulseStart and PulseEnd and 
> the PRU responds now.   I have no idea what the problem with those names 
> is.  
>
> Walter
>
> On Tue, May 18, 2021 at 8:14 PM Dennis Lee Bieber  
> wrote:
>
>> On Tue, 18 May 2021 11:22:20 -0700 (PDT), in
>> gmane.comp.hardware.beagleboard.user Walter Cromer
>>  wrote:
>>
>>
>> >Here's the code snippet with the two variables in bold.  If those lines 
>> of 
>> >code do not exist, the host doesn't hear from the PRU.
>>
>> Such formatting does not get through the gmane list<>newsgroup
>> interface. I'm going to presume you mean the lines with * markers. Posting
>> with a client that keeps indentation would also help... hard to keep track
>> of what is nested into what when everything is left justified with excess
>> blank lines.
>>
>> Normal recommendation is to condense the code down to the minimum 
>> that
>> still reproduces the problem, and to post the minimized files completely
>> (probably need both PRU and ARM programs). That allows others to attempt 
>> to
>> run/compare/debug.
>>
>> >
>> > 
>> >
>> >count = HWREG(SOC_ADC_TSC_0_REGS + TSC_ADC_SS_FIFOCOUNT(0));
>> >
>> > 
>> >
>> >for (i = 0; i < count; i++) 
>> >
>> >{
>> >
>> >Data = HWREG(SOC_ADC_TSC_0_REGS + TSC_ADC_SS_FIFODATA(0));
>> >
>> >StepRead = (Data >> 16) & 0xF;
>> >
>> >RawAnalog = Data & 0xFFF;
>> >
>> > 
>> >
>> >switch (StepRead)
>> >
>> >{
>> >
>> >case 0:
>> >
>> > 
>> >
>> >DetTSampleSet[pnr]=RawAnalog;
>> >
>> >break;
>> >
>> >case 1:
>> >
>> >  
>> >
>> >*start_of_pulse = 0;*
>> >
>> >*end_of_pulse = 0;*
>>
>> Where were these declared?
>> >
>> > 
>> >
>> >DetBSampleSet[pnr]=RawAnalog;
>> >
>> >if ((pnr == end_of_pulse) && (in_pulse == E_YES)) // seen a pulse and at 
>> >end of it analyze signal
>>
>> Where is pnr defined/initialized? Same for in_pulse. 
>> >
>> >{
>> >
>> >DetBSignalAverage= AnalyzeSignal(start_of_pulse, pnr);
>> >
>> >start_of_pulse = -1;
>> >
>> >end_of_pulse = -1;
>> >
>>
>> If pnr is an index into some buffer, I'd probably use -1 to 
>> signal NO
>> DATA, and use the pnr values active at the time the pulse is detected for
>> start_of_pulse and the when the pulse ended for end_of_pulse
>>
>> >samples_in_pulse = 0;
>> >
>> >in_pulse = E_NO;
>>
>> In a way, all these seem redundant: start at -1 indicates no 
>> data,
>> no samples, and not in a pulse. Samples_in_pulse at 0 indicates no data, 
>> no
>> samples, and likely not in a pulse. in_pulse at E_NO implies no data, no
>> samples.
>>
>> So, start are set to the appropriate pnr values... "in_pulse" 
>> is
>> indicated by start_of_pulse > -1 AND end_of_pulse = -1; "not in_pulse" is
>> indicated by (start_of_pulse > -1 AND end_of_pulse > -1) OR 
>> (start_of_pulse
>> = -1) //presumes you set both start/end to -1 at the same time
>>
>> >
>> >if (start_of_pulse < 0) start_of_pulse = pnr;  // set start pointer in 
>> ring 
>> >buffer if it hasn't already been set for this pulse
>> >
>>
>> Okay, you do set start/end to the instantaneous pnr value... Just
>> emphasizes that samples_in_pulse and in_pulse are logically redundant and
>> hence a potential source of error (samples_in_pulse should be end - start
>> (maybe with a +1; do the math with a sample buffer). Note: if this is a
>> circular buffer you'll need to account for wrap-around.
>>
>>
>> -- 
>> 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