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

[John Dammeyer]

Alright.
Doing some more research on the web turned up one page where the user is 
referencing the original Molloy book and complaining about $SLOTs in chapter 
six not being relevant but using a current OS which doesn't have $SLOTS.  The 
new edition of the book does not mention $SLOTS but instead config-pin for GPIO 
management.
 
The sad thing is that Derek Molloy's book, only in passing refers to enabling 
the SPI port, and the book, in trying to also deal with the pocket beagle pins 
leaves out things where repetition is actually beneficial.  Maybe somewhere it 
says that you have to use config-pin to set up SPI.  I missed it.  I think in 
Chapter 8 page 363 needs a bit of work.
 
So here's what I did following part of that web page suggestion on the Buster 
image:
debian@beaglebone:~/exploringBB/chp08/spi/spidev_test$ config-pin  p9.17 spi_cs
Current mode for P9_17 is: spi_cs
debian@beaglebone:~/exploringBB/chp08/spi/spidev_test$ config-pin  p9.22 
spi_sclk
Current mode for P9_22 is: spi_sclk 
debian@beaglebone:~/exploringBB/chp08/spi/spidev_test$ config-pin  p9.21 spi
Current mode for P9_21 is: spi
debian@beaglebone:~/exploringBB/chp08/spi/spidev_test$ config-pin  p9.18 spi
Current mode for P9_18 is: spi
 
I hadn't realized that this was needed if the spi device was opened as a fille. 
 I assumed opening a /dev/spi0.0 would automatically claim the pins for SPI.  
So with MOSI connected to MISO and specifying the SPI0 port since SPI1 is used 
by HDMI I get:
 
debian@beaglebone:~/exploringBB/chp08/spi/spidev_test$ ./spidev_test -D 
/dev/spidev0.0
spi mode: 0
bits per word: 8
max speed: 50 Hz (500 KHz)
 
FF FF FF FF FF FF
40 00 00 00 00 95
FF FF FF FF FF FF
FF FF FF FF FF FF
FF FF FF FF FF FF
DE AD BE EF BA AD
F0 0D
 
And that data matches what the scope tells me in the attached photo.  Clock is 
yellow trace. MOSI is Blue.  Green is CS.
 
Oh and none of this explains why the ioctl regardless of C or Pascal can't 
handle more than 4096 data bytes while the Python code can when sending a large 
bitmap to the SPI port.  Nor why, according to this web site
https://learn.adafruit.com/setting-up-io-python-library-on-beaglebone-black/spi
nothing is said about config-pin operations so the python library must do this 
automatically?
 
Now to try this on the Stretch OS based Beagle.
John
 
From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of John Dammeyer
Sent: May-20-21 5:43 PM
To: beagleboard@googlegroups.com
Subject: RE: [beagleboard] ioctl messages to Beagle SPI port.
 
The latest version of Buster does this when I look for SPI bus ports.  The 
older Stretch version doesn't have the 0.0 and 0.1 and everything is scaled up 
by 1.  
 
On either system the scope doesn't show any activity on the SPI0 pins.  No CS, 
no CLK no Data Out.
 
The test program from Exploring Beaglebone with the DI connected to the DO does 
not behave with the table changed from the output stream to input which makes 
sense since there isn't any output on the MOSI or MISO pins.
 
Any suggestions on how to get SPI working?
 
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:~$ ls -l /dev/spi*
crw-rw 1 root spi 153, 0 May 20 17:24 /dev/spidev0.0
crw-rw 1 root spi 153, 1 May 20 17:24 /dev/spidev0.1
crw-rw 1 root spi 153, 2 May 20 17:24 /dev/spidev1.0
crw-rw 1 root spi 153, 3 May 20 17:24 /dev/spidev1.1
debian@beaglebone:~$
 
 
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:~$ ls -l /dev/spi*
crw-rw 1 root spi  153, 0 May 20 16:45 /dev/spidev1.0
crw-rw 1 root spi  153, 1 May 20 16:45 /dev/spidev1.1
crw-rw 1 root spi  153, 2 May 20 16:45 /dev/spidev2.0
crw-rw 1 root spi  153, 3 May 20 16:45 /dev/spidev2.1
 
/dev/spi:
total 0
lrwxrwxrwx 1 root root 12 May 20 16:45 0.0 -> ../spidev1.0
lrwxrwxrwx 1 root root 12 May 20 16:45 0.1 -> ../spidev1.1
lrwxrwxrwx 1 root root 12 May 20 16:45 1.0 -> ../spidev2.0
lrwxrwxrwx 1 root root 12 May 20 16:45 1.1 -> ../spidev2.1
debian@ebb:~$
 
==
 
debian@beaglebone:~/exploringBB/chp08/spi/spidev_test$ ./spidev_test -D 
/dev/spidev0.0
spi mode: 0
bits per word: 8
max speed: 50 Hz (500 KHz)
 
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
debian@beaglebone:~/exploringBB/chp08/spi/spidev_test$
-- 
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 

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

[John Dammeyer]

The latest version of Buster does this when I look for SPI bus ports.  The 
older Stretch version doesn't have the 0.0 and 0.1 and everything is scaled up 
by 1.  
 
On either system the scope doesn't show any activity on the SPI0 pins.  No CS, 
no CLK no Data Out.
 
The test program from Exploring Beaglebone with the DI connected to the DO does 
not behave with the table changed from the output stream to input which makes 
sense since there isn't any output on the MOSI or MISO pins.
 
Any suggestions on how to get SPI working?
 
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:~$ ls -l /dev/spi*
crw-rw 1 root spi 153, 0 May 20 17:24 /dev/spidev0.0
crw-rw 1 root spi 153, 1 May 20 17:24 /dev/spidev0.1
crw-rw 1 root spi 153, 2 May 20 17:24 /dev/spidev1.0
crw-rw 1 root spi 153, 3 May 20 17:24 /dev/spidev1.1
debian@beaglebone:~$
 
 
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:~$ ls -l /dev/spi*
crw-rw 1 root spi  153, 0 May 20 16:45 /dev/spidev1.0
crw-rw 1 root spi  153, 1 May 20 16:45 /dev/spidev1.1
crw-rw 1 root spi  153, 2 May 20 16:45 /dev/spidev2.0
crw-rw 1 root spi  153, 3 May 20 16:45 /dev/spidev2.1
 
/dev/spi:
total 0
lrwxrwxrwx 1 root root 12 May 20 16:45 0.0 -> ../spidev1.0
lrwxrwxrwx 1 root root 12 May 20 16:45 0.1 -> ../spidev1.1
lrwxrwxrwx 1 root root 12 May 20 16:45 1.0 -> ../spidev2.0
lrwxrwxrwx 1 root root 12 May 20 16:45 1.1 -> ../spidev2.1
debian@ebb:~$
 
==
 
debian@beaglebone:~/exploringBB/chp08/spi/spidev_test$ ./spidev_test -D 
/dev/spidev0.0
spi mode: 0
bits per word: 8
max speed: 50 Hz (500 KHz)
 
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
debian@beaglebone:~/exploringBB/chp08/spi/spidev_test$

-- 
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/034801d74dda%2435a8c060%24a0fa4120%24%40autoartisans.com.

Re: [beagleboard] Reducing Boottime in Beaglebone Black

[Robert Nelson]

> removed wpasupplicant and connman and old kernel
>
> sudo apt-get purge linux-image-4.14.108-ti-r134 wpasupplicant connman
>
> debian@beaglebone:~$ systemd-analyze
>
> Startup finished in 13.502s (kernel) + 36.686s (userspace) = 50.188s
>
> I then removed the initrd file in /boot directory (From what I understand 
> this kernel does not necessarily need initrd).
> debian@beaglebone:/boot$ sudo mv initrd.img-4.19.94-ti-rt-r63 
> moved-initrd.img-4.19.94-ti-rt-r63
>
> Removing the initrd gives the max speedup for kernel. From 10s-13s with 
> initrd, it reduces to 1s-2s
> debian@beaglebone:~$ systemd-analyze
> Startup finished in 1.663s (kernel) + 36.385s (userspace) = 38.048s
> debian@beaglebone:~$ systemd-analyze blame
>  1min 4.266s dev-mmcblk1p1.device
>  26.360s generic-board-startup.service
>   3.847s systemd-udev-trigger.service
>   2.824s loadcpufreq.service

You can nuke this ^, it's really only for am57xx, so we can
downclock..  But on am335x, let it run at full speed as these are set:

CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y

>   2.215s networking.service
>   1.647s ssh.service
>   1.396s user@1000.service
>   1.209s rsyslog.service
>   1.189s systemd-journald.service
>999ms dnsmasq.service
>897ms cpufrequtils.service

Same as above..

>855ms systemd-timesyncd.service
>674ms systemd-fsck-root.service
>642ms systemd-logind.service
>505ms systemd-udevd.service
>445ms systemd-user-sessions.service
>408ms systemd-tmpfiles-setup-dev.service
>389ms systemd-update-utmp.service
>375ms hostapd.service

You nuked wpasupplicant, get rid of hostapd..

>365ms systemd-modules-load.service
>326ms dev-mqueue.mount
>324ms systemd-random-seed.service
>312ms sys-kernel-config.mount
>291ms systemd-tmpfiles-setup.service
>274ms sys-kernel-debug.mount
>236ms kmod-static-nodes.service
>231ms sys-fs-fuse-connections.mount
>200ms systemd-remount-fs.service
>190ms systemd-journal-flush.service
>185ms systemd-sysctl.service
>145ms systemd-update-utmp-runlevel.service
>130ms systemd-tmpfiles-clean.service
>
> Next point to attack is the generic-board-startup.service. The main time that 
> process spends is in the file /opt/scripts/boot/am335x_evm.sh
> This takes care of the USB flash, Serial and network gadgets that are 
> initialized. Remove items which are not needed. It also has a lot of generic 
> selections for Beagle family boards which can be removed. I am working on my 
> version for just beaglebone black with only network over USB support.
> Some ideas can be found here 
> (https://github.com/RobertCNelson/boot-scripts/issues/10)
>
> Hope that helps.

-- 
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/CAOCHtYiuY6ECN7pemXO%2B5CRKH4sEixN3%3DKhL6-BijrY7H%2BNoYg%40mail.gmail.com.

RE: [beagleboard] Reducing Boottime in Beaglebone Black

[John Dammeyer]

Thanks. Yes.  It does.
John
 
From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of Amit Goradia
Sent: May-20-21 2:42 AM
To: BeagleBoard
Subject: Re: [beagleboard] Reducing Boottime in Beaglebone Black
 
 
On Wednesday, 19 May, 2021 at 10:07:53 pm UTC+5:30 jo...@autoartisans.com 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
Hi John,
 
I did not do much actually to get to 50s.
Started from  a console Image : 
https://rcn-ee.com/rootfs/bb.org/testing/2020-05-02/stretch-console/bone-eMMC-flasher-debian-9.12-console-armhf-2020-05-02-1gb.img.xz
 replaced the kernel:
cd /opt/scripts/tools/
sudo su
git pull
./update_kernel.sh --ti-rt-channel --lts-4_19
removed wpasupplicant and connman and old kernel
sudo apt-get purge linux-image-4.14.108-ti-r134 wpasupplicant connman
debian@beaglebone:~$ systemd-analyze
Startup finished in 13.502s (kernel) + 36.686s (userspace) = 50.188s
I then removed the initrd file in /boot directory (From what I understand this 
kernel does not necessarily need initrd). 
debian@beaglebone:/boot$ sudo mv initrd.img-4.19.94-ti-rt-r63 
moved-initrd.img-4.19.94-ti-rt-r63 
 
Removing the initrd gives the max speedup for kernel. From 10s-13s with initrd, 
it reduces to 1s-2s
debian@beaglebone:~$ systemd-analyze
Startup finished in 1.663s (kernel) + 36.385s (userspace) = 38.048s
debian@beaglebone:~$ systemd-analyze blame
 1min 4.266s dev-mmcblk1p1.device
 26.360s generic-board-startup.service
  3.847s systemd-udev-trigger.service
  2.824s loadcpufreq.service
  2.215s networking.service
  1.647s ssh.service
  1.396s user@1000.service
  1.209s rsyslog.service
  1.189s systemd-journald.service
   999ms dnsmasq.service
   897ms cpufrequtils.service
   855ms systemd-timesyncd.service
   674ms systemd-fsck-root.service
   642ms systemd-logind.service
   505ms systemd-udevd.service
   445ms systemd-user-sessions.service
   408ms systemd-tmpfiles-setup-dev.service
   389ms systemd-update-utmp.service
   375ms hostapd.service
   365ms systemd-modules-load.service
   326ms dev-mqueue.mount
   324ms systemd-random-seed.service
   312ms sys-kernel-config.mount
   291ms systemd-tmpfiles-setup.service
   274ms sys-kernel-debug.mount
   236ms kmod-static-nodes.service
   231ms sys-fs-fuse-connections.mount
   200ms systemd-remount-fs.service
   190ms systemd-journal-flush.service
   185ms systemd-sysctl.service
   145ms systemd-update-utmp-runlevel.service
   130ms systemd-tmpfiles-clean.service
 
Next point to attack is the generic-board-startup.service. The main time that 
process spends is in the file /opt/scripts/boot/am335x_evm.sh
This takes care of the USB flash, Serial and network gadgets that are 
initialized. Remove items which are not needed. It also has a lot of generic 
selections for Beagle family boards which can be removed. I am working on my 
version for just beaglebone black with only network over USB support. 
Some ideas can be found here 
(https://github.com/RobertCNelson/boot-scripts/issues/10)
 
Hope that helps.
 
-amit
 
 
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: beagl...@googlegroups.com [mailto:beagl...@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:~$ 

Re: [beagleboard] Reducing Boottime in Beaglebone Black

[Amit Goradia]

On Wednesday, 19 May, 2021 at 10:07:53 pm UTC+5:30 jo...@autoartisans.com 
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
>
> Hi John,

I did not do much actually to get to 50s.
Started from  a console Image : 
https://rcn-ee.com/rootfs/bb.org/testing/2020-05-02/stretch-console/bone-eMMC-flasher-debian-9.12-console-armhf-2020-05-02-1gb.img.xz
 replaced the kernel:

cd /opt/scripts/tools/

sudo su

git pull

./update_kernel.sh --ti-rt-channel --lts-4_19

removed wpasupplicant and connman and old kernel

sudo apt-get purge linux-image-4.14.108-ti-r134 wpasupplicant connman

debian@beaglebone:~$ systemd-analyze

Startup finished in 13.502s (kernel) + 36.686s (userspace) = 50.188s
I then removed the initrd file in /boot directory (From what I understand 
this kernel does not necessarily need initrd). 
debian@beaglebone:/boot$ sudo mv initrd.img-4.19.94-ti-rt-r63 
moved-initrd.img-4.19.94-ti-rt-r63 

Removing the initrd gives the max speedup for kernel. From 10s-13s with 
initrd, it reduces to 1s-2s
debian@beaglebone:~$ systemd-analyze
Startup finished in 1.663s (kernel) + 36.385s (userspace) = 38.048s
debian@beaglebone:~$ systemd-analyze blame
 1min 4.266s dev-mmcblk1p1.device
 26.360s generic-board-startup.service
  3.847s systemd-udev-trigger.service
  2.824s loadcpufreq.service
  2.215s networking.service
  1.647s ssh.service
  1.396s user@1000.service
  1.209s rsyslog.service
  1.189s systemd-journald.service
   999ms dnsmasq.service
   897ms cpufrequtils.service
   855ms systemd-timesyncd.service
   674ms systemd-fsck-root.service
   642ms systemd-logind.service
   505ms systemd-udevd.service
   445ms systemd-user-sessions.service
   408ms systemd-tmpfiles-setup-dev.service
   389ms systemd-update-utmp.service
   375ms hostapd.service
   365ms systemd-modules-load.service
   326ms dev-mqueue.mount
   324ms systemd-random-seed.service
   312ms sys-kernel-config.mount
   291ms systemd-tmpfiles-setup.service
   274ms sys-kernel-debug.mount
   236ms kmod-static-nodes.service
   231ms sys-fs-fuse-connections.mount
   200ms systemd-remount-fs.service
   190ms systemd-journal-flush.service
   185ms systemd-sysctl.service
   145ms systemd-update-utmp-runlevel.service
   130ms systemd-tmpfiles-clean.service

Next point to attack is the generic-board-startup.service. The main time 
that process spends is in the file /opt/scripts/boot/am335x_evm.sh
This takes care of the USB flash, Serial and network gadgets that are 
initialized. Remove items which are not needed. It also has a lot of 
generic selections for Beagle family boards which can be removed. I am 
working on my version for just beaglebone black with only network over USB 
support. 
Some ideas can be found here 
(https://github.com/RobertCNelson/boot-scripts/issues/10)

Hope that helps.

-amit

>  
>
>  
>
> 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:* beagl...@googlegroups.com [mailto:beagl...@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 

Re: [beagleboard] Re: Shared PRU Memory and beyond

[TJF]

lazarman schrieb am Dienstag, 18. Mai 2021 um 23:02:58 UTC+2:

> ... maybe TJF will reply.


Hi Bruce,

beside 2x8k DRam and 12k SRam libpruio is using a further memory block 
called ERam (extension or external), find details at

https://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaMemory.html#SecERam

This block is 128k by default and can get configured up to 8MB = 4MS@16Bit. 
Using that block your task is easy:

   1. Send the physical ERam adress to the PRU (DRam).
   2. Fetch by PRU firmware ADC samples and store them in ERam (integer).
   3. Read ERam from ARM side and compute (float).

That's how the MM and RB mode in libpruio works (fetching samples from the 
internal TSC_ADC_SS).

You're talking about 1MS/s. That's 200 PRU cycles per value. It sounds like 
a simple task.

Regards 

-- 
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/5df6d3ee-47ef-49de-8c3a-acf1cab4fcban%40googlegroups.com.

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

[John Dammeyer]

Unlike Delphi or say the 9S12 or PIC debugger the Lazarus shows the source but 
doesn't seem to have a step ability in machine language.  So I can see what 
it's doing and even the registers but nothing more.
 
Given that the C code works perfectly and the Pascal stuff sends the same 
information I suspect the problem isn't with the OS but perhaps pointer 
formatting or something like that.  
 
Still working on it.  Without these kinds of problems I never really learn how 
things are put together.  So it's not a bad thing.  Just annoying.  The system 
can send ioctl messages directly as shown in the log.  But when using the 
transfer function it dies.  
 
So something between 2017 when this code was released and now there is 
something slightly different. 
 
John
 
 
From: 'Mark Lazarewicz' via BeagleBoard [mailto:beagleboard@googlegroups.com] 
Sent: May-19-21 10:43 PM
To: beagleboard@googlegroups.com
Subject: RE: [beagleboard] ioctl messages to Beagle SPI port.
 
#  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:
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