On Tue, 25 May 2021 19:16:51 -0700, in gmane.comp.hardware.beagleboard.user
"John Dammeyer" <johnd-5o6ditlojsohvde0pjs...@public.gmane.org> wrote:
>Hi Dennis,
>I tried on the groups site to edit this post and change what I wrote.
While the master copy appears to be a Google Groups entry, it seems to
be propagated outward since gmane is able to copy it and provide NNTP
access (which is how I'm reading -- but about a year ago submitted replies
via gmane were getting rejects from the main group, so I've had to email
replies to Google...).
NNTP spec does offer a CANCEL command to delete posts... BUT most
servers have disabled that (too easy to spoof a user and delete posts one
objects to, perhaps).
Since the messages are on distributed servers, they are essentially
"fire and forget" -- there is nothing one can do once they've hit send...
>It's a good point you make there. However then the SizeOf function might well
>return something different in size to make everything fit. I've also heard of
>systems re-arranging the members of a record to suit. In pascal to make that
>happen you defined it as packed.
>
My concern was that the C code might be packing things differently from
FreePascal, which could mean some of the arguments will not be where the
kernel expects to find them.
OTOH: I believe ARM Cortex architecture is defined to use byte
alignment (even if word/longword alignment is how the memory bus operates),
so both C and Pascal should be generating packed structures.
>Because this example program uses the high speed gpio the fault happens much
>sooner on the Pi without the sudo.
>
>pi@raspberrypi:~/projects/lazarus/TC $ ./TC
>An unhandled exception occurred at $00084EE4:
> ERPiOpenFile: Cannot not open
> file </dev/mem> for memory mapping.
> $00084EE4 TFASTSYSTEMCORE__CREATE, line 451
> of /home/pi/projects/lazarus/pxl/Source/PXL.Boards.RPi.pas
> $00010410 main,
> line 95 of TC.lpr
>
That may be devolving to the similar timing problem as earlier -- if it
is doing memory mapping to get to GPIO rather than using the sysfs access,
it may take time to get memory privileges set up.
https://man7.org/linux/man-pages/man4/mem.4.html
Hmmm, it appears that /dev/mem is a udev victim. Freshly booted a BBB gave
crw-r----- 1 root root 1, 1 Dec 31 1999 mem
but repeating the command a few seconds later shows
crw-r----- 1 root kmem 1, 1 May 25 23:45 /dev/mem
(note that the first is using the system default date, while the second is
after the system synched clocks).
Making the R-Pi user a member of group kmem might improve things; the
Beagle already has kmem for user
debian@beaglebone:~$ groups debian
debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users
systemd-journal input bluetooth netdev i2c gpio admin spi iio docker tisdk
weston-launch xenomai cloud9ide pwm eqep remoteproc
debian@beaglebone:~$
--
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/fagrag9ss0tg8q0vovkcsum29okdgm4k2j%404ax.com.
